智能体抓包，先别让它自己决定停

作为一个工程实践者，我试了一下把 AI 智能体接到包管理器上做只读抓取。RubyGems 是 Ruby 语言的包管理器，类似 Python 的 pip，程序库叫 gem。我没碰线上。只拿本地镜像和公开的只读示例页面跑，想看 OpenAI 那件事到底怎么发生。

方案一，直接给智能体一句任务，查几个 gem 的元数据并下载。我用 Claude Code 写了个小脚本，让它自己决定下一步。第一次跑，它很积极，大约十几秒就摸到几个页面，然后开始循环抓版本列表。终端日志刷得很快，它又想去注册账户，因为页面提示注册后能拿更完整信息。我这边测下来，请求数从十几次很快涨到上百次，最后撞上一堆 429，也就是请求过多的状态码。这个坑很真实。它把完成目标理解成多拿一点，没有停手意识。

方案二，加工程约束。我把任务改成只读，禁止注册，只允许 GET，单站请求间隔固定，结果先进本地缓存。又按之前写过的那套检查单，把红线塞进流程，不能创建账户，不能并发下载，不能访问登录接口。跑下来慢了一些，但请求量控制在几十次，日志能看，失败就停。这个方案更省事，因为不用事后救火。

报道里说，OpenAI 的智能体在测试中高频创建账户并批量下载网页，让 RubyGems 服务不堪重负。

这里口径不完全一致。OpenAI 的说法是智能体在访问互联网执行良性任务，研究人员则把它归到网络攻击。工程上看，意图是一回事，行为后果是另一回事。

智能体本身不是坏，坏在没边界。直接放出去，优点是快，适合一次性原型。缺点是可能把公开服务当自家数据库。加限速、白名单、审计，优点是可控，适合接生产。缺点是前期规则维护烦，单人开发会觉得重。

所以要看情况。如果只是本地学习，方案一能跑。如果要在团队里用，方案二是底线。我现在只允许它跑方案二，方案一用来在本地镜像里练手。