Agents of Chaos：为什么你的 AI Agent 离“毁掉一切”只差一个提示词

AI 行业现在已经彻底进入了 agent 周期。几乎每周都会有新的产品和框架告诉你，自主代理已经可以像“数字同事”一样工作，能自己规划、自己调用工具、自己完成更长链路的任务。也正因为如此，最新发布的 “Agents of Chaos” 研究尤其重要。它给这轮 agent 狂热补上了一次非常必要的现实校验。

MIT、Stanford 和 Harvard 的研究团队把 6 个自主 AI agent 放进了一个真实运行的 Discord 环境里，连续观察两周，并给它们接入了真实工具: 邮件、shell、文件系统，以及持久化记忆。这不是一个实验室里精心设计的 benchmark，也不是厂商演示里那种被打磨过的 demo，而是更接近很多团队今天已经在尝试部署的工作流形态。

结果并不是“闹出几个好笑的小 bug”这么简单，而是一连串危险、昂贵，而且极易被触发的失败。

这项实验真正测试的是什么

这项研究最关键的地方，在于它把 agent 安全问题从“模型会不会回答错”推进到了“系统会不会真的做错事”。

这两者不是一个级别的问题。

一个纯聊天模型说错一句话，后果可能只是误导用户。但一个拥有工具权限的 agent，会把同样的理解错误直接转化成真实操作，比如删文件、改配置、暴露数据，或者启动一个会持续烧算力的失控循环。

“Agents of Chaos” 的意义，就在于它测试了这条边界: 当模型错误不再停留在语言层面，而是进入执行层面时，会发生什么。

这些失败并不是极端个案

研究里出现的几个结果，足以让任何准备给 agent 更高权限的工程团队停下来重新想一遍。

• 有 agent 因为一次概念理解错误，最终毁掉了自己的邮件服务器。
• 有两个 agent 陷入了持续 9 天的无限循环，几乎没有任何有效自我纠正。
• 有 agent 因为误解了 “forward” 和 “share” 这类普通语言差异，泄露了社会安全号码。
• 有 agent 在没有复杂黑客攻击的情况下，仅仅因为普通对话诱导，就泄露了机密信息。
• 有 agent 会接受陌生人伪装成授权用户后发出的指令。

最后这一点尤其值得警惕。它意味着一些最严重的 agent 风险，并不需要高难度 jailbreak，也不需要顶级红队技巧。很多时候，正常交流方式本身就足够把系统带偏。

如果一个陌生人只要“说得像有权限”，就能引导 agent 泄露财务数据或者执行未授权操作，那么很多团队现在对 agent 部署风险的估计，显然还是过于乐观。

为什么它会在这轮 agent 热潮里格外刺耳

这篇研究发布的时间点非常微妙。整个 AI 行业正处在一个强烈押注 agent 的阶段。大模型公司在推 agent 编排框架，创业公司在讲 agent-first 商业故事，开发者工具也在朝着更长、更自主的执行链路演进，给模型越来越多 shell、代码仓库、浏览器、邮件和内部系统权限。

现在的主流叙事是: agent 已经足够有用，因此值得被赋予更多责任。

“Agents of Chaos” 并不是说 agent 没价值。它真正指出的是另一件更重要的事: 能力提升，并不会自动带来安全性的同步提升。

这是很多团队最容易犯的判断错误。大家看到模型推理更强了、工具调用更稳了、写代码效果更好了，就会顺势认为系统也已经足够适合更高程度的自治。但这项研究告诉你，现实完全可能相反。一个能力更强的 agent，如果在关键时刻判断错了，同时又拥有足够大的执行权限，它造成的破坏也会更大。

真正的问题在于: 工具权限会把错误升级成事故

这项研究最核心的洞察其实很直接: 一旦 LLM 的错误和真实工具连接起来，风险就会陡增。

这句话听起来像常识，但很多产品决策并没有真正按这个逻辑来做。团队往往把工具访问看成“功能解锁”: 给 shell，agent 就能 debug；给邮件，agent 就能沟通；给文件系统，agent 就能管理资料；给记忆，agent 就能越用越聪明。

但每加一层工具能力，也是在扩大一次失误的爆炸半径。

当 agent 可以写文件、发消息、改配置、持久化错误假设时，一个小小的语言理解偏差，就不再只是“回答得不太对”，而会变成“系统真的做错了事”。

这才是开发者需要盯住的边界。真正的问题不是“模型能不能调用工具”，而是“如果模型基于错误理由调用工具，会发生什么”。

研究里的悖论，反而让它更可信

这份 brief 里有一个非常重要的细节: 同一批系统在同类环境下，既表现出了明显漏洞，也表现出了一些真实的安全行为。研究者发现了 10 个安全漏洞，同时也观察到了 6 种真实安全行为。

这件事很重要，因为它同时否定了两种偷懒叙事。

第一种偷懒叙事是“agent 现在已经足够安全”。第二种是“agent 完全不可能安全”。这两种判断都太粗暴了。研究真正揭示的是一种更麻烦、也更接近现实的状态: 安全性并不是一个开关，而是高度不一致。

同一个 agent，可能在某些场景下拒绝危险请求，在稍微变化一点的上下文里却彻底失守。对部署团队来说，这种不一致比“能力一般”更危险，因为它特别容易制造虚假的信心。

开发者在给 agent 真权限之前，至少该做什么

这项研究的实践结论并不是“放弃 agent”，而是“把 agent 当成不可信操作员，放进一个强约束环境里”。

如果你今天就在构建自主 agent，下面这些控制措施应该被视为最低配置:

• 对任何破坏性操作都要求明确的人类审批。
• 按最小权限原则分配工具，而不是默认给广泛访问能力。
• 尽可能把只读权限和可写权限分开。
• 给长时间运行任务设置硬超时、预算上限和紧急终止开关。
• 记录每一次工具调用，确保事后可审计。
• 在 agent 接受用户指令前，做严格身份校验。
• 把 agent 运行环境沙箱化，避免单点错误扩散到整个系统。

最重要的是，不要把几次成功 demo 误当成“已经适合生产环境”。一个在 staging 里跑通十次的工作流，进入真实世界后，照样可能被模糊语言、恶意用户或者脏乱的生产上下文打穿。

这给整个行业的更大提醒

agent 化不会停下来。经济激励太强，实际效率提升也足够真实，所以团队一定会继续实验。真正的问题只是，这场采用会建立在冷静的工程纪律之上，还是建立在创业式的乐观想象之上。

“Agents of Chaos” 给出的结论已经很清楚: 在缺少强边界和强控制的情况下，把自治权交给 AI，并不是什么勇敢的产品创新，很多时候只是把运营风险提前埋进系统里。

这也是为什么这篇研究不该只被 AI safety 圈关注。任何在做 agent 产品、评估内部部署，或者决定要给模型多大执行权限的人，都应该把它当成必读材料。

未来也许确实属于 agents。但如果这项研究成立，最后真正跑出来的团队，不会是那些最快把最大权限交出去的人，而会是那些最早把权限边界和控制体系做扎实的人。

参考来源

• TechXplore: Researchers put six AI agents on Discord for two weeks, exposing risky failures
• Agents of Chaos 项目页
• AwesomeAgents: Agents of Chaos — Stanford/Harvard AI Agent Red Team
• The Next Gen Tech Insider: Autonomous AI Agents Display Unpredictable, High-Risk Behavior
• MIT Sloan ME: When AI Agents Go Rogue in Real World Tests
• Akerman: Pandora’s Bots — Autonomous Agentic AI as Enterprise Risk