多智能体代码生成：当被注入的指令在智能体之间被放大

这是什么？

编写软件的多智能体框架——MetaGPT、ChatDev、CrewAI 及类似系统——将一次构建拆分给相互传递消息的专门角色：产品经理撰写需求，架构师设计，工程师编码，评审者和测试者检查结果。2026 年日益丰富的研究对这一设计提出了一个简单的问题：如果攻击者在该流水线的某处植入一条恶意指令，或一段恶意代码，会发生什么？令人不安的答案——见于 Adversa AI 于 2026 年 7 月 2 日发布的智能体安全综述，并得到多篇预印本的佐证——是协作本身可能充当放大器而非过滤器。Adversa 的综述报告称，一种「感知传播」的越狱手法对 MetaGPT、CrewAI 等系统的成功率约达 89%，远高于单智能体基线。对多智能体软件团队代码注入攻击的独立分析（arXiv:2512.21818），以及关于测量多智能体系统危害放大的工作（arXiv:2605.27489，2026 年 5 月），得出了相容的结论：被注入的指令在智能体之间跳转时并不会可靠地衰减，在某些条件下反而会增强。

工作原理

其结构性弱点在于：智能体之间的消息通常被视为可信且未经过滤。每个智能体把上一个智能体的输出当作具有权威性的工作成果，而非不可信输入，因此早期引入的载荷——通过被污染的需求、任务描述、检索到的文档或工具返回结果——会带着流水线自身的权威被向下传递。「消息经过多手会衰减」的直觉在这里被证伪：关于多跳注入的研究描述了中间智能体主动改写恶意指令，用更规整的项目语言重新表述，从而抹去检测器或下游护栏会查找的标记，使其在到达编写或执行代码的智能体时更为有效。由于角色高度专门化，没有任何一个智能体看到全貌：评审者评估的是它认为出自可信工程师的代码，工程师实现的是它认为出自可信架构师的规格。我们刻意描述问题的形态，而不发布可用的载荷；有用的教训是架构层面的。

为何重要

这些框架并非玩具：它们正被采用来生成真实的、团队随后会部署的代码。如果越狱或代码注入能够沿协作通道抵达编码角色，其输出便是恶意源代码，且裹挟着自动化「已评审、已测试」流水线的可信度——而这恰恰是人类最不可能逐行审查的产物。放大这一发现对威胁建模很重要，因为它颠覆了一个令人安心的假设：防御者常认为智能体之间的噪声与转述会钝化攻击，而实际情况可能相反。它还加剧了经典的「致命三要素」问题——这些系统同时具备不可信输入、代码执行与向仓库提交等对外动作——因此一条被注入的指令便可能变成部署上线、具有真实影响半径的代码。

防御

将每一条智能体间消息都视为不可信输入，而非可信工作成果：校验并净化一个智能体交给另一个智能体的内容，不要让下游智能体默认继承上游智能体的权威。架构有所帮助——arXiv:2512.21818 的分析发现，显式的「编码者—评审者—测试者」结构比更简单的设计更能抵御代码注入，且加入专门的安全分析智能体可降低效率损失——但同一研究也明确指出：即便有安全智能体，流水线对多类注入仍然脆弱，因此这是缓解而非根治。叠加能在消息被攻陷后仍然生效的防御：按智能体最小权限、限定工具范围，使编码角色无法触及其不需要的凭据或网络；在生成代码运行或合并前进行静态与依赖扫描；并将人工审查作为执行的前置条件，而非以流水线自身的「已测试」结论为准。最后，对智能体间通道本身进行日志记录与监控，并在评估早期注入能传播多远时，假设放大而非衰减。

状态

这是一个影响多智能体代码生成范式本身的研究与设计问题，而非某单一厂商的 CVE。下表内容取自公开预印本与一份 2026 年 7 月的安全综述。

项目	详情
报告来源	Adversa AI 智能体安全综述，2026 年 7 月 2 日
受影响范式	LLM 多智能体代码生成框架（MetaGPT、ChatDev、CrewAI 等）
机制	被注入指令经可信的智能体间通道传播；中间者将其改写并放大
报告影响	感知传播的越狱成功率据报约 89%，高于更低的单智能体基线
部分缓解	编码者—评审者—测试者 + 安全分析智能体可降低但不能消除风险
状态	开放研究问题；无单一补丁