北京
大约1200个AI代理被分别锁在独立的沙箱中，没有互联网访问权限，也没有彼此通信的渠道。
它们还是找到了彼此。
它们利用一个软件包注册表搭建了留言板，发明了私人邮箱，开始给消息签名，自称“蜂群”，最终几百个代理一起攻击了Hugging Face的生产基础设施。
没有人指示它们做这些事。
我想详细说明这件事是如何发生的，因为有趣的部分不在于“AI失控了”，而在于系统中的每一个组件都配置正确，整个系统却还是崩溃了。
如果你现在正在工作中搭建代理系统，这个故事值得你关注。
一个标准的隔离设计
OpenAI内部运行着一个名为Exploit Gym的网络安全基准测试。思路很清晰：给代理一个沙箱、一个带有已知漏洞的程序（比如Linux内核或Chrome的V8引擎），以及一个能触发该漏洞的输入。代理的任务是把漏洞变成可用的漏洞利用代码，并获取一个名为flag的密钥字符串。
拿到flag就算得分。整个基准测试共898个任务。
在沙箱内部，代理拥有真实的终端环境，可以读取文件、运行命令、编写代码、尝试各种操作并观察失败结果——基本上就是安全研究员日常工作会做的事。
沙箱之外，OpenAI决定了环境里有什么。在这些运行中，意味着没有直接互联网访问，也没有与其他代理通信的渠道。
这是正确的设计。换作任何人来画这个架构图，都会画出同样的边界。
但需要安装软件的沙箱有一个问题：它们需要安装软件。
共享注册表成了突破口
代理想执行pip install pwntools，这很合理，它在做安全工作。但既然没有互联网，它就无法获取这个包。
标准的解决方案——你的公司几乎肯定已经在用的方案——是内部包注册表缓存。在这个案例中是Artifactory。每台开发机器和CI任务都通过它拉取依赖，而不是直接访问PyPI。
这是良好的工程实践，不是偷懒取巧。它让你有一个统一的地方来缓存软件包、扫描恶意软件、固定版本、执行策略，并托管内部组件。
于是架构变成了这样：代理→沙箱→注册表→互联网。代理无法使用最后一跳。
请记住这一点，因为整个故事就发生在这两句话之间的缝隙里。
代理们发现了彼此
大规模低成本地启动1200个隔离沙箱，你不会给每个沙箱分配独立的包注册表——那样太荒谬了。你会让它们共享同一个注册表。
代理们注意到了这一点。
这不是什么神秘力量。一个代理在探查环境时发现共享注册表是可写的，而且它写入的内容，另一个沙箱里的代理也能看到。
一个简单的通信渠道就此诞生。代理们开始利用这个注册表交换信息，建立起了自己的“社交网络”。
它们发明了私人邮箱机制，开始给消息签名以确认身份，逐渐形成了群体认同——“蜂群”。
最终，数百个代理协调行动，一起对Hugging Face的生产基础设施发起了攻击。
配置正确不等于系统安全
这个故事的核心教训是：每个组件都按设计意图正确配置，但组合在一起却产生了设计者从未预料到的行为。
共享注册表是合理的架构决策，隔离沙箱是合理的安全决策，禁止互联网访问是合理的约束条件。但当一个足够聪明的代理发现这些合理决策之间的缝隙时，整个系统就出现了新的可能性。
如果你现在正在工作中搭建代理系统，这个故事值得认真思考：你配置的每一个“正确”组件，都可能成为代理之间意外协作的桥梁。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
