探讨下百度网盘机器人的实现

最近买了个某人在百度网盘搭的自动发货的会员，就是加入他的百度网盘群，发送文件 ID 号，他自动分享链接出来。（这里的文件 ID 是固定长度，第三方来源，跟百度分配的 fs_id 不是一回事）

因为资源基本盘非常大，文件数量多，且分享出来的是很快过期的临时链接，所以不是手动分享 N 个文件得到链接，然后按关键词回复的那种。

他这个服务不稳定，有时很久没反应，有时明明网盘里面有（从别的渠道确认），但回复说没找到，所以很疑惑他后端支持是怎么做的。因为百度网盘现在提供给个人的开发接口是没有分享功能的，估计他是利用了 workaround 办法勉强实现的。猜测了一下其实现思路，跟大家探讨。

猜测或了解到的一些基本情况：

1. 他的软件形态可能是一个内嵌浏览器窗口的桌面软件，也可能是一个模拟 http 请求的爬虫。
2. fs_id 是百度给文件指定的 ID，同一个文件被不同用户保存后，这个 fs_id 是不同的。
3. 他通过其在群组内的账号发送查询结果，为防止查询、分享太频繁，被百度封号，他会把好几个自己的账号拉进来，轮次执行任务。

其关键步骤可能是这样：

1. 软件监视群组内的消息，收到符合某规则的文本后，取出关键词；
2. 如果线下维护了一个关键词和百度文件 fs_id 的映射表，直接将分享任务加入人物列表；如果没有此类映射表，执行搜索，如果没找到，用其在群组内的某个账号直接回复未找到，做一下与请求账号相关的记录工作后结束；
3. 一个队列消费服务从任务列表取出任务，分配给某个账号，用这个账号的 cookie 发送文件分享的 post 请求，关键参数就是 fs_id，得到分享链接
4. 用群里的某个账号把结果发出来

百度面向企业的开发接口是有文件分享功能的，但监管严，估计没人用来做这种侵权的服务。而他目前这种实现有难以克服的弱点：

1. 要准备多个账号，都存入相同的资源；
2. 为避免搜索，实现快速响应，要抓取全部文件的 fs_id，维护几个不小的数据表供线下查询用；
3. 如果不维护映射表，就要利用百度的搜索功能，结果可能不稳定，且查询太多了，后面出现验证码什么的很麻烦；
4. 分享太多、太快的话，账号有被封的风险；

目前想到这些，跟大家探讨，也许有了解这行的朋友，请不吝指教。