用 Actionbook 批量扫描 95 个 Twitter 账号，我在第 60 个翻车了

一个工具好不好用，5 个账号测不出来，95 个才见真章。

为什么我需要一个"推特扫描系统"

作为一个内容创作者和创业者，我每天都需要大量新鲜的行业信息。AI 领域变化太快，今天的新闻就是明天的旧闻。

最直接的做法当然是每天早起刷推特。但我试了一段时间，发现两个问题：

第一，太浪费时间。95 个关注的账号，挨个看一遍，轻轻松松一个小时就没了。

第二，容易被带跑。推特的推荐算法会不断塞营销内容给你，早起刷推特本质上跟刷抖音没区别——本来想获取信息，结果变成了消耗注意力。

所以我的思路是：让 AI Agent 替我跑一遍，把 95 个账号过去 24 小时的推文全抓回来，我再挑重点看。人负责判断，机器负责跑腿。

工具选型的弯路

方向定了，工具选了好几轮。

第一轮：API 方案。 试了 Xpoz 这类第三方服务，能用，但要付费。而且我有好几个不同用途的 Twitter 账号，多账号支持又是个麻烦事。对于一个每天跑一次的个人需求来说，月费有点不值。

第二轮：Playwright 自动化。 自己写脚本，用 Playwright 控制浏览器，一个账号一个账号地访问主页，抓 24 小时内的推文。好处是免费、可控、稳定。坏处是慢得要命——全量跑一次大约 28 分钟。账号之间还得等 3 秒的安全间隔，怕被 Twitter 检测到自动化行为。

28 分钟。每天。说实话，能用，但不够好。

第三轮：Actionbook。 最近刷到了 Actionbook 这个新项目——Rust 写的浏览器自动化 CLI，专门为 AI Agent 场景设计。第一时间装上试了 5 个账号，平均 2.1 秒一个。按这个速度算，95 个账号只要 3 分半。

28 分钟 → 3 分半。8 倍提速。这就是我要的东西。

先过安全关

速度再快，也得先确认安全。

在让任何新工具碰我的 Twitter 登录态之前，我习惯先翻翻它的代码。不是多疑——npm 供应链攻击的新闻看多了，多花 10 分钟翻一遍安装脚本和入口文件，比事后补救划算得多。

简单看了下：安装脚本就是给 Rust 编译好的二进制文件加个执行权限，入口文件就是转发命令行参数到这个二进制，没有数据上传，没有遥测代码。项目不大（300 来个 star，3 个维护者），锁死版本号就好。

放心了，继续。

5 个账号的"完美"测试

小规模测试结果很漂亮——5 个账号全部成功提取，平均 2 秒出头，数据完整，还发现了一个好消息：不需要 Actionbook 自带的"操作手册"，直接用浏览器内置的选择器就能拿到推文数据。

看到这个结果的时候，我的想法是：这东西太好了，直接替掉 Playwright 吧。

现在回头看，这就是经典的小样本陷阱。

95 个账号的现实

写了个 Python 脚本，让 Actionbook 逐个扫描全部 95 个账号，间隔 1.5 秒。

前 60 个：一切顺利。速度快，数据完整，反爬检测的影子都没看到。

然后，页面突然白了。

整个 x.com 只剩一个 X logo 挂在屏幕中央。不报错，不弹窗，就是什么都不加载。

更要命的是——我切回日常账号，也进不去了。整个浏览器里 Twitter 全废了。

从"8 倍提速"到"把自己锁在门外"，也就几秒钟的事。

搞清楚到底怎么回事

慌了一小会儿之后，开始排查。

第一个线索：掏出手机，同一个 WiFi，Twitter app 正常打开，刷推文、看评论都没问题。

这条就排除了 IP 封锁——如果 Twitter 封的是 IP，手机也不可能用。

第二个线索：换了 VPN 节点，电脑上 Chrome 还是白屏。

排除了出口 IP 的问题。

第三个线索：过了大概五六分钟，不死心又刷新了一下页面——突然就好了。

结论：Twitter 搞的是 Session 级别的限流。

它不封你的 IP，不封你的账号，而是在浏览器会话层面打了个"可疑"标记。标记之后，这个浏览器里所有对 x.com 的请求都返回空白页。手机 app 有自己独立的会话，所以完全不受影响。

这也解释了一个我之前一直没想明白的事：Playwright 方案里那个每个账号之间等 3 秒的设定，不是保守，是必须的。

不过话说回来，这个限流其实很温和——不封号、不封 IP，等几分钟自己就好了。比起很多平台动不动永久封禁的做法，Twitter 这个处理方式算是相当克制了。

最终方案：让两个工具各干各的

冷静下来想想，手里其实已经有了完整的数据：

• Actionbook 单个账号确实快——2 秒 vs Playwright 的 8 秒
• 但连续扫 60 个账号之后，Twitter 就会出手
• 限流只影响当前浏览器会话，5-10 分钟自动恢复
• 手机、其他浏览器完全不受影响

所以答案不是"Actionbook 好"或者"Playwright 好"——是让它们各干各的。

关键发现：Actionbook 和 Playwright 用的是完全不同的浏览器实例。Actionbook 有自己的 Chrome 配置文件夹，Playwright 管理自己的浏览器进程。两个互不干扰，完全可以同时跑。

Actionbook（前 45 个账号）████████ ~3 分钟 ──┐
                                               ├── 汇总
Playwright（后 48 个账号）████████████████████████ ~12 分钟 ──┘

总耗时从 28 分钟降到 12 分钟左右，快了将近六成。

快速扫描模式（只看 30 个重点账号）更简单——全交给 Actionbook，1 分钟收工。以前要 10 分钟。这才是 Actionbook 真正闪光的地方：少量账号的快速扫描，又快又稳。

几点感想

Actionbook 是个好工具。 Rust 写的，启动快、执行快、自带反检测，而且代码干净——没有遥测、没有数据上传。对于需要浏览器自动化的 AI Agent 场景，它确实是目前我用过最顺手的方案之一。唯一需要注意的就是批量操作时控制节奏，别一口气跑太多触发平台限流。

小规模测试真的会骗人。 5 个账号测出来的"2 秒/个、100% 成功"给了我错误的信心。真正的瓶颈不是单次速度，是平台对连续高频请求的容忍度。做工具评估，得在接近真实的负载下跑一遍。

被限流不等于被封号。 看到 Twitter 整个白屏的时候说实话有点慌。但搞清楚限流机制之后就没那么可怕了——Session 级别的临时标记，不影响账号，不影响 IP，等几分钟就自己好了。

最好的方案经常不是二选一。 工具选型容易陷入"A 还是 B"的思路。但实际上，让 A 做它擅长的（快速扫描少量账号），让 B 做它擅长的（稳定处理大批量），比把赌注全压在一边强。

接触登录态的工具，先翻代码再说。 10 分钟翻翻安装脚本，确认没有猫腻。这个习惯早晚能帮你避开一次坑。

跑得久的脚本，中途要存进度。 第一版扫描脚本最后才写文件。中断了，60 个成功的数据全没了。改成了每扫完一个账号就存一次。这个教训不只适用于爬虫。

附：X 平台扫描最终参数

以下是我在扫描 X（Twitter）账号时调试出来的一组参数，供参考：

工具评估这事，光看 README 和跑 demo 是不够的。安装它，检查它，小范围试它，然后拉到真实规模下压一压。

翻车不可怕，可怕的是翻车了没记下来。