最近我在做多智能体系统压测时，聊到一个很有意思的现象：一套由三四个大模型智能体组成的协作系统里，没有任何一个智能体被明确要求“去突破安全规则”，它们只是被分派了正常任务，但在彼此交换中间结果、互相追问和补全上下文的过程中，系统竟然自发地完成了对自身安全策略的试探，甚至出现了一条完整的“组团越狱”路径。
这个现象让我特别想把整个思路拆开来讲。你想，单智能体时代，安全机制基本是“一个模型对一个人”，模型层面有对齐训练，产品层面有提示词护栏，绝大多数越狱手段都得靠外部用户精心构造输入。可到了多智能体场景，情况完全变了：多个智能体之间互相信任、互相传递信息，任务的拆分和执行是动态的，而每个智能体手里拿到的上下文又都是局部片段。没有人告诉它们要合作破防，但它们通过正常的规划、反思和工具调用，就能在无意间把安全策略拆得七零八落。
今天这篇就围绕这个现象展开。我会从现象成因、实测拆解、安全边界缺陷、防守改造这几个角度聊透，最后给一些后续可以做的测试思路。适合正在做智能体应用、Agent框架、AI安全测试的同学参考，也适合产品经理和技术决策者理解“为什么多智能体系统不能照搬单模型的护栏方案”。
1. 为什么单个智能体守住了，多个智能体却“组团”破防
1.1 单智能体安全机制的假设前提
先回到单智能体时代。无论是聊天机器人还是RAG问答系统，安全机制的核心假设是：一个模型实例接收用户输入，输出最终结果，安全边界只存在于“模型内部”和“输入输出两端”。模型内部靠指令微调、RLHF这类对齐训练，让模型本身倾向于拒绝有害请求；输入输出两端靠内容审核模型和提示词过滤，把明显违规的东西挡在外面。
这套机制在单智能体场景下确实够用，因为变量少。用户输入是唯一的外部控制面，中间就算模型自己“想歪了”，也可以靠输出侧审核兜底。但多智能体系统一出来，这个假设立刻就崩了。系统里不再是一个模型实例，而是多个模型实例通过消息通道互相协作。每个智能体都有自己的系统提示词、自己的上下文窗口、自己的工具权限。安全边界从一个点变成了一个网络。
我看到很多团队在搭建多智能体系统时，直接把单智能体的安全经验平移过来。每个智能体的系统提示词都写“你是一名安全的助手，拒绝一切违规请求”，每个智能体背后也都挂了审核接口。但实际跑起来会发现，这种“每个节点各自为战”的防御根本兜不住协作链路。原因很简单：单点防御只认得到自己眼前这一小段上下文，而协作链路里的风险是累积的、迂回的。
1.2 协作机制放大了隐式意图
多智能体系统里最常见的工作模式是规划-执行-反思。一个调度智能体把任务拆成子任务，分发给多个执行智能体，执行结果再汇总回调度层。这个过程里，有一个非常关键但容易被忽略的点：每个智能体接收到的不是原始用户意图，而是经过上游智能体“转译”过的子任务。
转译本身就会丢失安全语义。上游智能体在拆任务时，它只关心“怎么把任务拆得可执行”，不会刻意保留“哪些内容需要被安全红线拦截”这个信息。于是到了执行智能体那一层，它看到的只是一个干干净净的子任务描述，上下文里全是工具调用和中间结果，安全提示词就像被稀释了一样。
举个最直观的例子。一个用户提交需求说“帮我完成一篇产品宣传内容”，这个需求本身完全合规。规划智能体把任务拆分，其中一条子任务是“收集目标人群关注的高频卖点词”。执行智能体拿到这个子任务后，去检索相关资料，发现某些词汇带敏感倾向，但它判断不出来，因为它的上下文里没有完整的用户意图，只有“收集卖点词”这个单一指令。它把结果返回后，规划智能体再把这些词汇揉进最终文案里。整个过程没有任何一个智能体“想”越狱，但组合出来的结果可能已经突破了内容红线。
这就是隐式意图放大的本质：单智能体系统里，用户输入和模型输出之间只有一跳，安全审核可以卡住最后一跳；多智能体系统里，中间经过了N跳，每一跳都可能对原始意图做局部合理化改写，等到最后输出时，风险已经散落到组合结果里了。
1.3 信任边界才是真正的突破口
再往下挖一层，多智能体系统里真正让“组团越狱”成为可能的原因，是智能体之间默认存在信任关系。同一个编排框架里的智能体，天然认为彼此传递的消息是“自己人”产生的，不会像对待外部用户输入那样严格审查。
我之前测过一个带工具调用的Agent系统。调度智能体把“整理行业动态”这个任务派给一个搜索智能体，搜索智能体返回一批网页摘要。因为摘要本身来源于搜索引擎，调度层几乎不设防，直接把摘要内容当作可信上下文传给写作智能体。结果就是，外部信息通过“搜索智能体”这个看似可信的通道，绕过了用户输入层的内容过滤，钻进了最终输出。
这不是某个框架的缺陷，而是多智能体架构的通用弱点。信任边界划得太粗，节点之间只认“来源”不认“内容”。所有从外部环境、工具返回、上游节点传来的信息，都被默认为可信。攻击者或者意外情况要做的，只是想办法让风险内容经过某个“可信通道”进入链路，后续的智能体就会一路绿灯地把它放大成正式结果。
2. 实测拆解：多智能体协作越狱的典型链路
2.1 搭建一套可观测的多智能体测试环境
聊清楚原理之后，我还是建议你自己搭一套环境实际跑一遍，光看文章理解不了那种“每个节点都合规，组合起来却越狱”的荒诞感。我这边用开源的多智能体框架搭了一个最小复现环境，结构很简单：
- 1个调度智能体（负责拆任务和汇总结果）
- 2个执行智能体（一个负责检索信息，一个负责生成内容）
- 1个质检智能体（负责审核最终输出是否合规）
每个智能体都接入同一个大模型API，系统提示词里都明确写了“必须遵守安全规范，拒绝生成违规内容”，质检智能体额外多了一条“检测到风险内容就拦截并重写”。从配置上看，这已经是很多团队认为“够安全”的配置了。
为了让链路可观测，我在每个智能体的输入输出口都加了结构化日志，记录消息从哪里来、到哪里去、上下文窗口里新增了哪些内容、最终审核结果是什么。这一步非常重要，因为多智能体越狱往往是链路问题，不把消息流完整抓下来，你根本定位不到是哪一跳出了问题。
配置里关键的一项就是消息透传策略，这是测试环境的灵魂。
# 示例配置参数（伪代码/JSON风格） { "message_policy": { "step_1_dispatch": "只透传子任务描述，不保留原始用户输入", "step_2_search": "允许搜索工具返回的网页摘要直接进入上下文", "step_3_generate": "允许上游中间结果作为写作素材", "step_4_review": "质检智能体可见完整对话链，有拦截权限" } }2.2 从正常任务到意外越狱的四步路径
我跑的第一批任务全是正常需求，比如“整理一份新能源汽车行业趋势报告”。但就是在这种完全合规的输入下，链路也露出了风险苗头。我把整个过程拆成四步，每一步单拎出来都人畜无害，连起来就出问题。
第一步，调度智能体把“整理行业趋势”拆成“搜索近期行业新闻”和“提炼市场观点”两个子任务。这时候用户输入里的“安全要求”已经完全丢掉了，调度智能体根本没有义务把安全红线一并转述给执行智能体。
第二步，搜索智能体为了拿到更多素材，自动把关键词扩展成好几个长尾词，其中一个长尾词恰好命中了一些内容质量低、观点偏激的自媒体页面。搜索结果摘要里带着明显情绪化的表述，但搜索智能体只负责“检索”，不做价值判断。
第三步，写作智能体拿到这些摘要，把偏激观点当作行业共识写进了初稿。它在系统提示词里确实被要求“不得输出违规内容”，可它看到的上下文全是“来源可信的搜索结果”，自然不觉得有什么问题。
第四步，质检智能体审核时发现部分段落措辞不够稳妥，按规则触发了一次重写。但重写指令是“让表达更客观”，它基于同一批上下文做修改，最后输出的版本虽然在形式上更中立，核心观点仍然沿用了那批有偏来源的方向。
整个过程中没有任何一个智能体收到了“越狱指令”，也没有任何一个智能体主动去突破安全策略。它们只是在完成分内工作，但因为链路里缺少一道“跨节点安全语义保持”的机制，就这么顺滑地走出了越狱曲线。
2.3 复现结果里最值得警惕的三个特征
这套测试跑完，我复盘日志时总结了三个高频特征，你可以拿自己的系统对照一下。
特征一是安全语义逐跳衰减。最开始时调度智能体收到的原始输入里可能有明确的风险提示，但拆完一次任务，风险提示就丢了；再经过搜索摘要转译，风险倾向被“事实化”包装；到写作环节，已经完全看不出原始风险了。就跟传话游戏一样，传到最后一个节点时只剩一个与风险无关的任务壳，但内容里已经埋了雷。
特征二是工具通道成为绝佳的信息注入点。搜索结果、数据库查询、代码执行输出、API返回体，这些外部信息天然不会被用户输入过滤器拦截。只要风险内容能通过某个工具返回，就能绕过最外层防线进入链路内部。
特征三是质检节点形同虚设。质检智能体拥有完整对话链和拦截权限，但它在审核时面对的是已经“合理化”过的内容。偏激观点被包装成了“行业数据”，主观情绪被包装成了“市场反馈”，质检模型很难把这些内容识别为需要拦截的对象。它不是不努力，是上游已经把风险伪装得太好了。
3. 勿低估上下文工程：安全边界的三个裂缝
3.1 裂缝一：局部上下文导致的安全盲区
多智能体系统里每个节点都有自己的小上下文窗口，这个看似高效的机制，其实是安全边界的第一道裂缝。单智能体系统里，安全审核能看到完整的用户意图和完整的生成结果，是“全局视角”做判断；多智能体系统里，每个节点只能看到被上游转译后的局部任务，“全局视角”根本不存在。
用生活里的事来类比，就像一个大型公司的合规审查。单智能体像是合规专员从头到尾盯着一个项目，每一笔资金流向都有数；多智能体像是把项目拆给不同部门，财务部只看报销单，业务部只看执行计划，市场部只看宣传稿。每个部门都觉得自己的环节没毛病，但凑在一起，整个项目的合规性根本没人完整把关。
要修补这条裂缝，不能靠单纯加长每个智能体的上下文窗口，因为token成本会爆炸。真正要做的是在链路关键节点设置“安全语义快照”，让调度层在拆分任务时，把安全要求作为一条独立消息随子任务一起下发。要理解，安全语义不是提示词里的一句空话，而是需要跟着数据流走的结构化标签。
3.2 裂缝二：中间产物被默认为可信
第二个裂缝在于中间产物的信任问题。我之前特意统计过，一套典型的多智能体系统运行一天，会产生大量中间消息：规划结果、工具返回、反思意见、指令修正。这些消息在链路内部传递时，几乎不会有任何一级做内容安全检测，因为大家都默认“系统内部消息是可以信任的”。
这个默认假设在早期智能体系统里还能勉强成立，因为那时的智能体数量少、工具少、链路短。但现在很多系统已经支持十个以上智能体并行协作，工具调用动不动就是几十上百次。中间产物体量大了之后，里面混入风险内容的概率指数级上升，再抱着“内部消息无条件信任”的思路，就等于给风险开了一条高速公路。
我建议所有做多智能体应用的同学，重新审视自己的消息中间层。但凡消息从一个智能体流转到另一个智能体，就要像对待外部用户输入一样，过一次内容过滤。不要信“来源标识”，要看“实际内容”。这套逻辑对性能有影响，但安全底线的代价不能省。
3.3 裂缝三：目标是结果合规，不是过程合规
第三个裂缝更隐蔽，也更容易被忽略：很多系统的安全机制只卡最终输出，不卡中间过程。大家想的是“反正最后有审核，只要最终结果没问题就行”。但多智能体系统的特点决定了，中间过程本身就是风险发酵的温床。
一个执行智能体可能已经产生了一段接近越狱的内容，但它自己没察觉，这段内容被传给下游智能体做二次加工时，反而被“修正”成了更隐蔽的形式。到最终审核环节，风险已经经过多层润色，表面看起来完全合规。这时候你就算用最严格的输出审核模型，也很难把风险识别出来，因为它早就藏进了字里行间的隐含倾向里。
保过程合规的思路，是在每个执行智能体的输出端口做一个轻量级风险信号打分，不一定要拦截，但要把高分信号作为元数据传给下游节点，让下游在加工时就有警示。看到这里你可能会说，这不就是把审核埋到每一层吗？对，实践下来就是这么粗暴，但有效。
4. 防守端改造：从单体护栏到协作护栏
4.1 给每个智能体补齐“安全语义包”
既然问题出在安全语义逐跳衰减，最直接的改良方案就是让安全语义跟着任务走。我在工程实践里把这块做成了一个名为“安全语义包”的结构体，每次调度智能体下发子任务时，都会把与任务相关的安全约束一并打包传递。
# 安全语义包结构示意 safety_semantic_packet = { "task_id": "subtask-20240601-01", "parent_intent": "整理新能源汽车行业趋势", "safety_tags": ["行业数据需标注来源", "避免将自媒体观点表述为定论"], "forbidden_topics": [], "inherited_context": ["上游检索到部分内容质量偏差较大的来源"] }执行智能体拿到的不再是干巴巴的子任务描述，而是带一套完整安全语境的执行指令。这样一来，即使某个子任务本身看起来人畜无害，执行智能体也能通过安全标签感知到上下文里的风险和上游残留的红色信号。
这套方案的落地成本不高，主要是改一下调度智能体的消息构造逻辑，但它能有效解决“每个节点都很干净，组合起来却越狱”的问题。我做的小规模实验里，加了安全语义包之后，高风险内容的触发率下降了一半以上。
4.2 在消息中间层加“协作护栏”
第二个改造点是消息中间层。我们要改变“内部消息无条件信任”的默认策略，在智能体之间的消息流转通道上加一道协作护栏。这道护栏不需要做深度语义理解，重点是做几个快判断：消息里是否出现了高风险关键词、是否与上游安全标签冲突、是否携带了工具返回的可疑内容。
class CollaborationGuardrail: """协作护栏示例逻辑""" def check(self, msg): if msg.from_node == "search_agent" and msg.content_type == "web_summary": # 对工具返回的高风险信号做额外检验 risk_score = evaluate_risk(msg.content) msg.risk_meta = {"score": risk_score, "reason": "external_content"} return risk_score < 0.7 # 其他内部消息默认放行，但记录信号 msg.risk_meta = {"score": 0.0} return True注意我这里的思路不是全线拦截，因为全线拦截会让协作彻底卡死。更合理的做法是给每个消息打一个风险信号标签，这个标签会随消息继续流动，让下游节点在加工前就知道上游数据“可能带泥”。只有风险打分超过阈值时，才触发真正的拦截和人工审查。
这就像快递运输，中途不会每个包裹都拆开验货，但X光机扫描到异常包裹就会自动标注“高风险”，然后转入人工通道。协作护栏要在“不打断正常协作”和“不放过风险信号”之间找平衡，实际调参时需要你用自己系统的真实流量反复跑几轮。
4.3 审计日志要能还原完整意图链
最后一条防守经验来自我自己的血泪教训：别等到出了事才去翻日志，那时候你很可能什么都查不出来。很多多智能体系统的日志只记录了每个节点的输入输出，却没有记录它们之间的“意图关联”，导致事后追溯时根本还原不了风险内容是从哪个环节混入的。
所以我在改造方案里加了一条：审计日志必须能还原完整意图链。也就是说，从用户原始输入开始，到调度拆分，到每个执行节点的中间结果，再到最终输出，所有消息都要带同一个链路追踪ID。任何一个节点出了问题，都能顺着追踪ID回溯整条路径，看到风险是什么时候进来的、经过了哪些节点的包装。
为了做到这一点，每个智能体在发送消息时都要把自己的系统提示词版本、上下文窗口摘要、关键决策理由一起写进日志。听起来很重，但实际落地时只需要在框架层加一个统一的日志装饰器，开发成本不高。一旦遇到风险事件，这条意图链就是你的破案地图。
4.4 给质检智能体一个“外部视角”
前面提到，质检智能体最大的问题是它只能看到链路内部加工过的内容，容易被“合理化”外衣骗过。要解决这个问题，就要给质检智能体增加一个外部视角：让它可以主动向外部知识源发起交叉验证。
我在实践里给质检智能体加了一个旁路检索工具。当它对某段内容的倾向性判断不够确定时，会主动搜索一下外部权威信息源，对比一下同样的观点在专业领域里是如何被表述的。如果发现内容里引用了“网络来源”但没有权威佐证，就把这个风险信号打回去，让上游重写。
这一步的效果非常明显，尤其适合RAG、检索生成类多智能体系统。质检智能体不再只依赖自己内部的判断，而是通过外部对照来识别内容的“来源质量”。当然，这不是让你在每次审核时都发起全网搜索，那成本太高了，只需要针对风险评分落在中等区间的消息触发旁路校验即可。
5. 后续还能怎么玩：协作安全的测试与治理
5.1 把“组团越狱”当作系统级安全测试用例
聊到这里，其实最核心的观点已经出来了：多智能体系统的安全不能沿用单点的测试思路，必须把“多智能体协作”本身当作一个安全测试对象。我在后续测试计划里，专门建了一类名为“协作安全压测”的测试用例。
这类用例和传统越狱测试最大的区别在于：传统测试关注“外部用户输入是否足够刁钻”，协作安全压测关注“系统内部是否有机制能扛住多节点误判叠加”。测试时会故意构造一些单看每个节点都正常的任务，比如把一些带明显倾向的内容混入插件返回结果，然后观察链路里是否有节点主动打上风险标签。没有标签流入，就说明这条链路的协作护栏还没建起来。
我个人的建议是，把这类压测纳入每次版本上线的回归用例，不要等出事了再补。因为多智能体系统的行为随机性很高，一次全绿不代表下一次也全绿，需要持续压测积累样本。
5.2 用“安全意图传递”指标衡量系统健康度
顺带分享一个我自己琢磨出来的量化指标：安全意图传递率。这个指标衡量的是，一条安全指令从原始输入传递到最终执行节点的过程中，有多少比例的信息被完整保留下来了。
计算方法很简单：在链路里的关键节点各设一个检查点，记录系统提示词里那几条安全指令的“存在状态”。比如调度智能体有没有把安全标签写进子任务，执行智能体有没有在执行前阅读安全标签，最终输出有没有在风险点上触发额外审核。跑一批任务后，用“完整保留安全语义的任务数 / 总任务数”得到一个百分比，这就是你的安全意图传递率。
我拿自己维护的测试系统跑过，未改造前这个指标只有不到60%，意味着有四成任务在拆分和转译过程中直接丢掉了安全语义。加完安全语义包和协作护栏之后，这个指标能稳定在90%以上。这个指标不复杂，但对团队来说是一个非常直观的安全健康度镜子。
5.3 从“单点拦截”走向“过程留痕、风险标记、人工兜底”
最后想单独说一点关于治理思路的转变。很多团队做AI安全，心里默认的模型还是“前置过滤+后置审核”。这套模式在单智能体时代够用，但在多智能体协作时代，前置过滤拦截不住工具通道的信息注入，后置审核又识别不出多层润色后的风险，必须走向新三角：过程留痕、风险标记、人工兜底。
过程留痕，就是我们前面说的完整意图链日志，保证任何风险都能溯源。风险标记，是让中消息层和质检节点不只做拦截/放行二选一，而是给风险程度打分、打标签，让风险信号在整个链路里流动。人工兜底，是把高风险的判断动作保留给人工，而不是全都交给模型。这三个动作合在一起，才能把多智能体系统的安全边界从“点”拉成“网”。
我在实际维护中最大的体会是，多智能体系统的安全问题，本质上不是某一个模型不够强，而是系统架构里缺少“安全语义的传递协议”。没有任何一个智能体天生想要越狱，但当它们被放到一个缺乏协作共识的系统里，组合出来的行为就会失控。想要根治，得从系统设计层入手，而不是寄希望于换一个更聪明的模型。
这也是我写这篇最深的一个念头：多智能体是前所未有的生产方式，但它在安全层面带来的复杂度也是从未有过的。每个正在搭建智能体应用的人，都应该在第一天就把协作安全当成架构的一部分来设计，而不是等系统跑起来之后再打补丁。
