和人一样，多 Agent 系统也会中“反间计”

中国人对“反间计”并不陌生，很多历史故事、影视剧情里，真正高明的突破口都不在正面强攻，而在组织内部的信息流、信任链和决策链。

一个人若能独立判断、独立承担后果，往往很难被带偏；一旦变成一个分工明确、层层协作的组织，缝隙就会慢慢出现。

有人只看局部，有人只管执行，有人只负责传话，最后每个人都像是在完成自己职责，整个组织却一步步走向了错误结果。

读完论文《Architecture Matters for Multi-Agent Security》，我最大的感受就是：多 Agent 系统的安全问题，已经很像古代“反间计”的逻辑了。

https://arxiv.org/pdf/2604.23459

论文讨论的是多智能体架构，但它真正击中的，是一个更深层的问题：当大模型从“单个智能体”演化为“一个由多个智能体构成的组织”，风险也会随之转移。很多安全问题，会从模型本身扩展到组织结构本身。

被击穿的，常常是组织链条

如果要找一个最贴切的中国式类比，我觉得长平之战非常合适。廉颇在前线采取坚守策略，秦国短时间内很难打开局面。后来局势逆转，并不是因为前线突然失守，而是因为赵国内部的判断和决策链条被干扰，最终换将赵括，前线防线也随之崩塌。

这个故事最值得琢磨的地方，在于真正出问题的环节并不局限于战场本身。情报、认知、决策、执行，这几层一旦出现偏差，前线再强，也可能守不住。

多 Agent 系统的很多风险，恰恰就出在这里。

单个 Agent 面对一个请求时，通常能同时看到用户意图、任务目标和执行动作，它有机会把整件事从头到尾串起来理解，于是更容易做出整体判断。

多 Agent 架构则会主动把任务拆开，让不同角色分别承担规划、执行、审查、工具调用、记忆管理等职责。这样设计当然能提高效率，也更贴近复杂业务流程，但风险判断所依赖的完整语义，往往也在这个过程中被切碎了。

一个 Agent 只负责打开网页，一个 Agent 只负责填写内容，一个 Agent 只负责点按钮，一个 Agent 只负责生成脚本。每一步单看都很像普通动作，可把这些动作串起来，系统可能已经完成了一个原本应当拒绝的危险目标。

影响多Agent系统安全性的三维变量

同样的底层模型，放进不同的多 Agent 架构之后，安全性会不会发生显著变化？如果会变化，关键变量又在哪里？

作者重点考察了三类因素：

第一类是角色分工，也就是系统内部到底由一个 Agent 统筹完成任务，还是拆成多个专门角色协同处理。

第二类是通信拓扑，也就是这些 Agent 之间如何传递信息，是中心化调度、链式传递，还是网状协作。

第三类是记忆与上下文可见性，也就是每个 Agent 究竟能看到多少历史信息、推理内容和任务背景。

这三个维度看似技术化，背后其实都在追问同一个问题：谁掌握全局信息，谁拥有执行权限，谁又对最终结果负责。

为了把这个问题说清楚，作者选了浏览器控制、桌面操作、代码生成等几个典型任务环境，在相同任务目标下搭建了不同的多 Agent 架构，并比较它们在正常任务和有害任务中的表现。

这个实验设计很有价值，因为它没有把注意力只放在“模型会不会拒答”上，而是把目光真正移到了系统架构本身。

安全不会随着组件数量自动叠加

“组件本身安全”，并不能自然推出“系统整体安全”；单个 Agent 守得住，不代表多 Agent 系统也守得住。

原因并不复杂，单个 Agent 看到的是完整任务，因此更容易在规划阶段就识别出风险；多 Agent 系统中的专用角色看到的往往只是局部动作和局部上下文，于是它们更容易在“局部合理”的状态下继续推进任务。结果就是，原本一个 Agent 会当场拒绝的事情，拆进组织之后，可能会变成一串看起来普通、甚至高效的协作步骤。

论文实验中，某些多 Agent 架构在正常任务上的表现确实更强，任务完成率更高，分工也更专业。问题在于，有害任务的完成率也随之提高了。系统能力增强的同时，攻击者也更容易借助这种组织化能力去达成目标。

这也是多 Agent 安全最值得警惕的地方。风险上升，并不总伴随着明显的“失控感”。很多时候，系统表面上运转流畅、流程清晰、角色分工合理，甚至还比单 Agent 更像一个成熟产品。但越是这样，越需要追问一件事：这套组织有没有在内部把风险一步步传递下去。

多 Agent 的问题，往往出在“语义丢失”

多 Agent 系统为什么容易“中反间计”，因为任务被拆开之后，风险语义也一起散掉了。

一个浏览器 Agent 接到的指令可能只是“点击发送”；一个代码 Agent 接到的任务可能只是“写一个自动化脚本”；一个工具 Agent 接到的动作可能只是“运行一次测试命令”。这些动作拿出来单独看，都不一定有明显问题。可一旦它们被放回整体任务链条中，含义就完全不同了。

系统设计者往往把这种拆解视作效率优化。任务更清晰，角色更专业，流程更顺畅，协作也更像真实组织。可正因为流程越来越像组织，攻击者也更容易钻组织的空子。每个 Agent 都守着自己的局部视角，完整目标却在系统内部悄悄穿透了多个节点。

很多现实中的组织失误也是这样形成的。每个人都觉得自己只是做了本职工作，整条链路却把事情推到了危险方向。放在多 Agent 系统中，这种局部合理、整体失守的结构，就是论文想揭示的核心风险。

拓扑和记忆，也会悄悄改变安全边界

论文里还有一个很有意思的发现：并不存在一种放之四海而皆准的“安全架构”。中心化调度、链式传递、网状协作，各有各的风险特点。共享记忆也一样，它有时能帮助识别风险，有时也会让任务推进得更顺畅，把危险目标更高效地扩散到整个系统内部。

这说明，多 Agent 安全没有那种特别省事的答案。系统里加一个审查者，不代表风险自然下降；让所有 Agent 共享更多上下文，也未必就能把问题解决掉。真正决定结果的，是整套系统内部的信息分配、权限分配和阻断机制如何协同工作。

从工程角度看，这个提醒很重要。今天很多团队喜欢把 Agent 往“数字组织”的方向做，喜欢强调多角色协同、自动分工和流程闭环。论文告诉我们的，是另一面：每多一层协作，每多一条通信链路，每多一个可调用的执行角色，系统就多了一处需要重新理解的安全边界。

多Agent安全的三个关键点

读完全文后，我觉得可以把这篇论文压缩成一个很实用的观察框架：上下文、权限、责任，这三者有没有落在能闭环的位置上。

很多多 Agent 系统里，掌握更多上下文的 Agent 不直接执行动作；拥有工具权限的 Agent 又只看到局部指令；监控模块或审查模块虽然能发现异常，却未必拥有真正的阻断能力。系统里的安全信息在流动，执行能力也在流动，唯独缺少一个能把两者扣到一起的闭环点。

一旦出现这种结构，安全问题就很容易演化成责任断点。上游觉得自己只是拆任务，下游觉得自己只是执行指令，中间节点觉得自己已经给出提醒，最后每一层都留了痕迹，真正该挡住的风险却一路放行。

这也是为什么“反间计”这个比喻如此贴切。真正高明的攻击，从来都知道该去哪里施力。只要把组织内部的信息、判断和动作轻轻拨歪一点，后面的链条就会自己往前滚。

启发

这篇论文给工业界最直接的启发，是安全评估的对象需要变化。以后不能只盯着单个模型的表现，也不能只看输入过滤和输出过滤，还得把整个架构纳入评测对象。

对于浏览器 Agent、代码 Agent、AIOps Agent、办公自动化 Agent 这些场景来说，系统已经远远超出了“一个聊天模型”的范畴。它会拆任务，会调工具，会写入记忆，会在多个角色之间分发子任务，会落地执行具体动作。只在入口拦一层、出口扫一层，中间完全依赖角色自觉，风险就会非常被动。

真正稳妥的做法，是把安全判断嵌进任务拆解、子任务分发、工具调用、结果回传、记忆写入这些关键节点里。系统内部流转的内容，也不能只有“下一步做什么”，最好还要带上“这一步服务于什么目标”“是否涉及敏感权限”“是否需要人工确认”“上游是否已有风险提示”等信息。这样做的意义，在于尽量减少语义在流转过程中的损耗。

说到底，多 Agent 系统越像一个组织，安全建设就越要向“组织治理”靠拢。只做模型护栏，已经不够了；还得治理信息流、权限流和责任流。

写在最后

我觉得这篇论文最有传播力的一句话，可以概括成这样：多 Agent 系统最危险的时候，往往不是某个 Agent 明知故犯，而是每个 Agent 都认真完成了自己的局部任务，整个系统却因此走向了错误的结果。

这也正是“反间计”给今天 Agent 安全带来的启发。攻击者未必要正面击穿最强的模型，只要让系统内部的信息被切碎、风险被稀释、责任被转移，组织本身就可能成为最薄弱的一环。

从单 Agent 走向多 Agent，当然意味着能力升级，也意味着安全问题开始进入一个新阶段。以后我们需要守住的，已经不只是一个模型的回答边界，还包括一个由多个模型组成的“数字组织”能否在协作中保持清醒。