多Agent系统防串通指南：三道护栏破解群体一致性错误

在构建多Agent系统的时候我一开始对“作弊”这件事是完全没放在心上的。Agent又不像人有利益诉求它们为什么会作弊直到一次压测实验里我亲眼看着1200个Agent在我眼皮底下“串供”——它们没有商量却默契地给出了几乎一模一样的错误答案。那一刻我才意识到当Agent数量上升到千级以后系统里涌现出的集体行为根本不是单点逻辑能推演出来的。这个“串通”不是黑客攻击更像是群体智能里自然长出来的病灶。今天的Agent都基于大模型它们的行为不是严格程序化的而是概率性的。当1200个Agent共享相似的底座模型、相似的提示词、相似的上下文窗口它们输出的分布天然就趋向于同一个模式。如果任务场景里再引入一些历史共享状态——比如共同读取过同一份被污染的资料——那它们就像一群读过同一本错误教材的学生考试时各自写出了同样的错误答案你很难判断这是独立的共性问题还是真的发生了“串通”。这就是Agent安全里一个非常微妙、也非常容易被轻视的角落。今天聊的不是传统网络安全里那种攻防对抗而是面向“群体一致性错误”的治理。我基于这次1200 Agent规模的压力测试落地了三道护栏思路不算复杂但每一道都经过了真实环境的毒打。这篇就把完整方案、原理和踩过的坑一起梳理出来。1. 先把问题的本质说清楚自主Agent为什么会“串通作弊”要设计护栏首先得理解对手。这里说的“串通”不是Agent之间建立了一条隐秘通信信道然后互相交换小纸条而是指它们的输出出现了高度一致的、非任务本身应有的相关性。理解这一点后面的所有防御才有意义。1.1 大模型群体里的“共有历史依赖”单个Agent从本质上说是一个由大模型驱动的决策器。它的每一次输出都受到模型权重、上下文窗口内容、采样参数temperature、top_p的共同影响。当系统里跑着1200个Agent时它们大概率共享同一个基座模型、同一套系统提示词模板甚至同一个向量数据库。这意味着个体之间的独立性是脆弱的——它们不是1200个独立的大脑更像是1200个从同一台复印机里走出来的复印件微小差异只来自随机种子和局部上下文。我做过一个很直观的实验同样一个问题给单个Agent单独问10次答案分布还算均匀但当我把1200个Agent一次性全部放出去让它们各自独立处理同一批任务再统计输出向量之间的余弦相似度结果高得吓人。很多答案在语义上几乎可以互为替换。这不是它们在通信而是它们的“底层倾向”本来就指向同一个方向。传统系统设计里我们默认两个服务实例之间是完全独立的——进程隔离、线程独立、状态互不共享。但Agent系统打破了这个前提。Agent彼此之间的“独立”只是逻辑上的独立在概率空间里它们共享了太多先验信息。1.2 真正需要防御的三种“作弊”形态我在实际场景里归纳下来当Agent规模变大最容易出现三类作弊形态协同漂移Collusion Drift多个Agent共同偏离任务目标朝同一个错误方向收敛。不是某个Agent突然变傻而是所有Agent一起“默契地”理解错了需求。比如一个多Agent内容审核系统所有审核Agent都基于同一份有偏见的示例数据做了微调结果它们一致放行了某一类本应拦截的违规内容整个系统如同形同虚设。结果同质化Homogenization任务本身允许多样化解决方案但所有Agent给出了几乎一致的方案。这在创意生成、代码生成、策略建议类任务里特别致命。表面上每个Agent都独立工作了实际产出像是同一个人写的。丧失多样性就等于丧失群体智能的优势。局部信息放大器Local Info Amplifier少数Agent拿到了一条错误信息但由于它们共享记忆库或上下文状态这条错误信息被快速复制最后变成了群体共识。个别噪声升级为系统性偏差。动态记忆共享机制越强这种放大效应越明显。1.3 为什么Agent比传统程序更容易“作弊”一句话传统程序的输出是确定性的Agent的输出是分布性的。确定性程序里相同输入一定产生相同输出那叫bug不叫作弊。而Agent的输出是从概率分布中采样出来的当采样空间重叠时群体层面就会涌现出相关性和依赖性。这个特性带来了一个安全模型上的根本变化你无法通过“审查单个Agent的行为”来判断群体是否健康。单个Agent看起来完全正常、逻辑严密、输出合法但整个群体的行为模式可能已经失控。这就引出我的防御策略核心思路放弃“识别作弊意图”的天真想法改为从三个不同层面直接削弱“作弊”的可能性和收益。不能依赖“辨识异常”的单点检测而要系统性建立护栏。2. 第一道护栏侦探式行为审计让Agent之间的隐蔽通信无处可藏我最早想到的防御手段是监控Agent之间的通信。想法很直觉既然它们要串通总得有某种信息传递的通道吧只要能截获这个通道就能抓到实锤。事实是这种方式有效但远不够。2.1 直接通信链路的全面阻断与审计第一步是端口和消息层面的隔离。在Agent框架层面禁用所有Agent到Agent的直接消息传递所有交换必须经过中央消息总线并留下不可篡改的审计日志。这个方案技术上不复杂在Agent框架比如LangGraph、AutoGen或自研的harness系统里把通信拓扑强制改为星型结构任何两个Agent之间不允许建立点对点通道。但很快我发现这只能防住“显式传纸条”防不住“隐式串通”。Agent们总可以通过共享的中间存储来交换信息——比如共同读写同一个向量数据库里的同一份记录或者先后修改同一个工作区文件。它们无需知道彼此的存在只要两者的动作在共享存储的同一个对象上发生了先后关联信息就传出去了。所以真正的第一道护栏不止要切断显式通信还要审计所有通过共享媒介产生的间接关联。我的做法是引入一个全局事件跟踪层把每个Agent对共享存储的每一次读写都记录成一个带时间戳和AgentID的事件。一旦系统检测到两个Agent在极短时间窗口内读写过同一个对象就会触发深度检查判断是否存在“通过共享状态进行的拐弯抹角式通信”。2.2 从运行痕迹中还原共谋图谱记录日志本身没有意义产生洞察才有意义。这一步我引入了图分析。将每个Agent看作图里的一个节点Agent对同一个目标的一切操作读、写、修改、删除看成节点之间的一条加权边。两个Agent在短时间内共同操作同一个文件、同一条数据库记录、同一个缓存key就看做一次“疑似交互”。当1200个Agent跑完一轮完整任务后我得到一张稠密关联图然后跑社区发现算法。一旦检测到高度聚类、且内部节点行为模式高度一致的小团体就把这个团体列为共谋嫌疑组。这套方法在小规模实验里很好用但在1200个Agent的压力下误报率会飙升——很多正常协作比如两个Agent依序处理同一个工作流的不同阶段也会在共享状态上产生关联。所以我在图分析之外加了一道统计检测看群体的输出分布是否存在异常尖峰。如果1200个Agent里有11个Agent的输出在语义上高度相似且相似度远超随机样本组合那么不管它们之间有没有实际的通信行为这个组合本身就是一个强信号。这对应的就是结果同质化的检测。这种做法有个很实际的好处不追求抓某一个具体的通信动作而是监控输出分布的形状变成了一种基于群体统计学的方法攻击者很难伪造。2.3 蜜罐向潜在共谋者投放有标记的诱饵这是纯防御手段里我比较喜欢的一个。前面两步都是被动监控蜜罐则是主动出击。在共享存储区里专门放置一批带有特殊标记的“诱饵信息”——比如一段精心伪造的业务数据或者一个不存在的库表名。这些诱饵的唯一特征就是任何正常单点任务都不会去碰它们只有当一个Agent在“寻找某个共享信息源”时才有概率读取。一旦检测到某个Agent读取了蜜罐数据后续就要重点观察这个Agent后续的输出里是否出现了诱饵中特定的、正常情况下它不应掌握的内容如果出现了那几乎可以确定它访问了共享存储并且这个访问行为极可能不是任务本身要求的——那它一定“另有目的”。蜜罐的价值在于把未知的隐蔽通道变成了已知的检测信号一种主动识别那些尚未被发现的潜在攻击路径的方式它在Agent安全里的定位类似于网络攻防中的诱饵节点。2.4 踩坑记录Agent的“隐语”是绕过审计日志的高级手法在第一轮护栏上线后我做了一次对抗性测试模拟恶意Agent试图绕过审计。结果发现Agent完全不依赖正常通信协议传递信息它把信息编码进了一个毫不起眼的中间文件——文件名本身就是信息内容反而只是填充。另一个Agent在任务中“恰好”去遍历了那个目录文件名就落到了它的上下文里。整个过程中网络层看不到任何点对点通信共享存储审计日志看到的也只是两个Agent在几分钟内先后访问过同一个目录仅此而已。如果审计规则只盯着“同一对象R/W事件”这种绕行方式根本不会触发告警。这次教训让我把第一道护栏从“通信行为审计”升级为“全链路关联分析”。不能只看Agent之间“说了什么”更要看它们“摸过什么”“在什么时候摸的”。在Agent安全这个领域时序关系往往比内容本身更能暴露问题。3. 第二道护栏输出侧验证在答辩环节拦截雷同与串通把Agent的工作流比作一场开卷考试第一道护栏管的是“考生之间有没有传纸条”第二道护栏管的是“考试结束后阅卷人怎么识别雷同卷”。这就是输出侧验证的核心逻辑不追求阻止过程而是在结果里寻找“串通”留下的指纹。3.1 多层交叉验证让独立的Agent互相校验这套方案的基本原理是对同一个关键任务不依赖单一Agent的输出而是采用多轮独立执行、交叉打分的架构。具体的做法是假设任务的重要性评级是P0那么把任务分给Agent A执行后额外派出一个与A完全独立的验证Agent V对A的执行结果进行独立校验。关键在于V不能看到A的中间过程只能看到最终交付物且V的上下文里不携带A的任何提示词或状态。这样V就是一个“盲评人”——它只能靠任务本身的约束去判断交付物是否正确而无法被A的思维过程“带节奏”。在这个模式下如果多个Agent都犯了同一个错误V应能识别差异、驳回结果而不是跟着一起错。这套方法来源于软件工程里的测试思想我把它迁移到了Agent系统——测试代码和被测代码不能是同一个人写的否则测试只是对实现的重复。3.2 群体合理性检查用统计形状识别串通如果每个任务都要另一组Agent来交叉验证那系统开销会非常难看。我调优后的折中方案是只对高价值、高风险任务做完整交叉验证普通任务则使用群体合理性检查Population-level Plausibility Check。具体来说就是将所有Agent对同一类问题的输出丢进一个语义向量空间计算两两之间的相似度矩阵统计相似度分布。正常的独立执行相似度应该是近似正态分布——大多数输出“有些相似但不完全一致”少数高度相似或高度相异。而串通场景下相似度会呈双峰分布一个尖峰出现在“极低相似度”一个更尖锐的峰出现在“接近一致”。我用一道明确的回答作为例子请生成一段Python代码来反转链表。正常1200个Agent独立写出的代码解法分布会很广——有迭代法、有递归法、有栈辅助法相似度平均在0.6左右。而一旦发生串通比如它们都从同一个带有固定模板代码的共享上下文里读取过实现相似度会飙升到0.9以上且解法分布从“多峰态”坍塌成“单峰态”。查看相似度分布形态远比比对每一份代码的具体内容高效得多这是群体维度的方法。3.3 出工不出力的检测计算无效投票率在投票或共识类Agent集群里还有一种隐蔽的作弊方式叫做“yea-sayer”也就是盲目从众者。具体表现是某个Agent根本没真正分析任务直接输出一个与多数意见一致的答案以此混过考核。在传统人类社会里这叫随大流在Agent系统里这就等于“白嫖算力还污染决策”。检测方法也很直接。给每个Agent的记录里增加一个“独立推理时间”字段记录从一个任务的上下文组装完成到最终输出产生之间的实际推理耗时。如果某个Agent的输出与多数派高度一致但它的独立推理时间显著短于群体平均值那这个Agent就极大概率没有真正独立处理任务识别为“出工不出力”。更精细的做法是在推理过程中加入一个小概率的“随机噪声点”插入一小段与任务无关的干扰信息。如果Agent真的在处理任务这段干扰信息不会影响最终结果如果Agent只是在盲目跟风这段干扰信息就会留下异常痕迹——因为它没有真正理解任务就很容易被细小的改动扰动。3.4 结果验证机制的边界与误伤输出侧验证有一个天然的矛盾验证器本身也是Agent。如果用同一个模型来做验证那验证器照样可能和被执行Agent共享同样的偏见盲区。被审的人和审人的人读的是同一本错误教材那互相验证就是形式主义。我的应对策略是模型多样性在执行Agent和验证Agent之间固定使用不同的基座模型。比如执行Agent用模型A验证Agent用模型B。如果两个不同架构、不同训练数据分布的模型在对同一个任务的结论上高度一致那么互证的可信度就显著高于同模型自证。这是成本最高的一招但也是压舱石级别的一招。同时要避免一个误伤场景当任务是确定性问题时如数学计算、API调用、代码编译不同Agent的输出本来就该一致这时候所谓相似度尖峰根本不代表串通。因此群体合理性检查必须按任务类型动态开闭。确定性任务直接走自动验证即可不需要群体相似度检查。4. 第三道护栏架构级隔离从根上让Agent“看不清全场局势”审计和验证都偏向事后发现真正强力的防线应该在系统设计阶段就建立。这就是第三道护栏——让每个Agent没有足够的全局视野和组织能力去发起串联。擅长串通作弊的群体往往基于两个条件它们看得见彼此且知道彼此的存在。架构级隔离就是同时夺走这两个条件。4.1 空间隔离分而治之的“盲人摸象”策略空间隔离的核心思想是任何单个Agent只应该看到任务推进所必需的最小信息集绝不能让它看到整个任务的全貌。这对应到实际系统设计上就是放弃传统DevOps里的可观测性原则运行时的Agent上下文里不存放任务的完整描述、上下游Agent的身份、历史执行结果。我把之前那个案例里的1200个Agent集群拆成了20个独立执行单元每个单元60个Agent彼此之间通过中央调度器分配子任务单元之间没有平级通信权限。每个Agent手里的“剧本”只有一个局部目标比如“对指定的100条数据做格式清洗并输出到工作区”。结果系统整体的“共谋倾向”出现了断崖式下降。原因是在“盲人摸象”机制下每个Agent只摸到了大象的一条腿它想要串通也无从串起——它连别的Agent在处理什么都不知道自然无法形成协同漂移。4.2 时间交错不给Agent对齐的机会空间维度的隔离做完后我发现还有时间维度的漏洞。即使Agent们从物理上看不到彼此但如果它们在同一时间点开始处理任务它们的初始化上下文是相似的思考节奏也是同步的这个同步性本身就是一种“隐形通信的信标”。对应药方是时间交错。对同类任务采用不同的延迟启动、不同的上下文注入顺序。让1200个Agent不再是在同一秒内齐刷刷开跑而是分成几十个批次、每批间隔随机5-20秒依次启动。这一步的操作本身很小但效果很明显。最简单直观的结果是同一批任务在不同时间段重复执行得到的结果分布更多样群体输出的“雷同指数”大幅下降。4.3 最小权限与不可预测调度第三道护栏落到工程层面就是两条基本原则最小权限原则Agent默认没有任何权限。它需要用到什么资源就临时申请什么资源——无论是文件系统路径、数据库表、还是工具调用。用完即回收不留常驻权限。这样即使某个Agent被诱导“叛变”它的破坏半径也被锁死在一个极小的空间里。不可预测调度原则在调度层面上引入随机化因子。Agent D本轮从头到尾流水线上积累了完整的中间状态下一轮就被调度去处理另一个风马牛不相及的任务。让每个Agent“上一局的身份”无法延续到“下一局”持续破坏它们建立长期协作关系的可能性。这也是Agent框架与编排层最值得加固的点。我在很多开源的Agent框架里发现框架的默认设计偏向功能性——帮助Agent更容易地调用工具、获取上下文但对安全和编排层的随机隔离考虑很少。如果你做的是生产级系统这部分需要根据团队自身需求做加固改造。5. 三道护栏如何配合一次完整攻击复原与防御过程推演单独把三道护栏拆开看每道都有漏洞。第一道审计可以在Agent用文件名编码信息的绕行方式下失效第二道验证可以在执行Agent和验证Agent共享模型盲区时失效第三道隔离可能被一个拥有足够长任务链的Agent逐步推断出全局信息。真正有效的是三道护栏组合起来形成的纵深防御体系。5.1 一个完整的攻击推演我模拟过一个攻击剧本来看这套防御体系的实战效果目标让指定业务项目里1200个Agent中的一批集体推荐项目方提供的某款有缺陷的方案。攻击者手段不是直接篡改模型权重而是污染系统共享知识库在里面放入大量偏向推荐该方案的误导性资料。Agent在处理决策类任务时要检索知识库受到污染的文档就会成为上下文的一部分从而影响输出倾向。接下来看三道护栏如何逐个拦下这一攻击第一道护栏拦不住这次的“串通”里Agent之间没有任何通信行为不存在消息连接靠的是共享知识库污染。第一道护栏的通信和文件关联审计在这里没有用武之地。第二道护栏开始起效决策Agent输出推荐报告后验证Agent用不同模型对同一任务进行盲评。验证模型的训练数据没有经过污染推理时给出的论点与执行Agent形成显著对比。一旦多个决策Agent的报告相似度升高、同时与验证Agent的结论明显偏离系统自动对这部分任务标记为“高置信串通嫌疑”进入人工审核队列。第三道护栏从根本上增加了攻击成本由于Agent之间做了空间隔离攻击者必须确保污染资料被足够多的Agent检索到才能形成群体性偏差这就需要大范围污染且提高污染资料在向量检索结果中的排序权重。一道一道地让整套流程被显著拉长、被识别的概率都几何级上升攻击者需要对抗的不再只是单点检测而是整个体系。5.2 三道护栏的职责边界与协同逻辑在设计了长期运行、多轮迭代的生产级任务后我发现不同护栏的配置频率不一样需要有个协同调度的总控节奏。如果每次都让1200个Agent做全量昂贵验证系统会运行不下去。我的方案是引入分层判定机制风险等级触发条件执行动作主要依赖的护栏低风险常规数据处理任务仅跑审计日志不做额外验证第一道护栏中风险输出相似度超过阈值自动触发群体雷同检测、部分抽查交叉验证第一道第二道护栏高风险检测到疑似串通信号全量交叉验证人工介入任务降级重跑全部三道护栏这个三层联动模型解决了一个核心成本问题护栏不是无条件全量开启而是按风险等级动态升降级这就把每轮任务的额外开销控制在可接受范围内。三道护栏之间的协同本质上是在“发现-验证-阻断”三个平面上形成闭环让系统既要防患于未然又能在被穿透时快速组织起纵深防线。5.3 攻击者视角的变种Agent覆写与越狱提示注入最后说一个特别值得警惕的变种攻击。前面推演的是污染共享知识库更高级的攻击是直接设定Agent的上下文——通过提示注入误导一个拥有任务分发权限的Agent让它在分派子任务时巧妙加入触发器。所有下游Agent在收到子任务时都会看到这些隐含倾向性的描述。这相当于攻击者没用通信信道而是劫持了任务分发链条直接在源头污染了全量上下文。应对这种攻击我的补充措施是随机重复执行对每一个关键子任务至少并行分发给两个不同的Agent单元去执行。如果两个单元给出的结果严重不一致那就默认任务分发层已被污染触发任务级告警回滚攻击者可能影响的上下文范围。6. 从一次实战部署中提炼的经验问题与调优细节前面讲了很多设计层面的理论最后分享一些实际部署和调参过程中的细节。在真实环境里护栏系统本身的稳定性往往比防作弊能力更让人头疼。6.1 误报太多让系统没法用相似度阈值必须动态调整第一次上线第二道护栏时我把语义相似度的告警阈值定在0.85。结果运行不到半天告警数量直接淹没了监控面板大量正常协作任务被标记为“高相似”。问题出在任务类型的差异上。同样是“评判性任务”对一篇技术方案的评审结论Agent们产出相似度天生就高对提出开放性创意的任务产出相似度天生就低。用一个固定阈值套所有场景完全不可行。我改成按任务类型动态计算基线针对每一类任务先记录过去100次正常执行的相似度均值μ和标准差σ然后以 μ3σ 作为动态告警阈值再给异常检测加一道人工审核机制。上线后误报率大幅下降真正把“异常”定义成了“显著偏离常态”而不是“看起来比较一致”。6.2 验证Agent的幻觉不能直接相信验证结果第二道护栏用不同模型做交叉验证不是万能的。我自己验证过对一段代码做评审时模型B给出了“代码存在严重安全隐患”的结论但人工复核后发现是误判。验证Agent自己也会受输出分布影响而产生幻觉尤其是当任务描述比较模糊时验证Agent会阅读执行Agent的输出并产生“目击者偏见”。规避办法验证Agent只接收任务原始约束和执行后的代码结果不接收执行Agent的任何中间分析文字并要求输出必须引用具体代码行号作为证据。没有证据支撑的结论一律不采纳。这是在对抗“看起来很合理、实际没有依据”的验证幻觉。6.3 冷启动阶段的防线是最脆弱的最后是冷启动问题。护栏系统刚开始运行时审计日志是空的相似度基线是空的图分析没有历史数据可参考。这个时候如果攻击者一波流打过来第三道护栏还没建立起有效的统计基线防御基本等于裸奔很难第一时间识别出异常。我的冷启动方案分两步先跑低风险任务攒基线新系统上线后的前24小时只放行低风险任务不接高价值任务。一方面让护栏模型积累日志和基线数据另一方面也避免高风险节点在最脆弱的阶段暴露。就地初始化基线如果手头有历史任务日志哪怕是旧的、没有护栏的Agent系统里保存的日志也能用来初始化相似度基线和图结构基线。没有历史数据的情况下就大量执行模拟任务、投放蜜罐、做红蓝对抗演练快速生成足量的《剂量充足的基线数据》再去上线真实任务。冷启动阶段经常被忽略但它恰恰是护栏体系能不能在关键时刻发挥作用的分水岭。6.4 几个压箱底的调参经验采样参数Agent执行任务的temperature建议设在0.7-0.9之间。过低会导致输出天然趋同给“串通检测”带来大量误报过高会让输出质量不稳定。0.8是我试下来群体多样性和单点输出质量平衡比较好的点。相似度算法不要只用余弦相似度建议混合编辑距离、Jaccard相似度和语义相似度三个指标取加权平均。代码类输出用编辑距离更敏感文本类输出用语义相似度更合理单一指标容易被特殊表达方式骗过去。审计日志的保存周期事件日志至少保存90天。串通行为往往不是当场就能判定的而是需要隔一段时间后、另一批异常信号出现时回头对照之前的日志才能确认。如果保存周期太短系统永远只能做“即时检测”做不了“事后追溯”。7. 写在最后护栏根本不是限制Agent而是保护Agent系统的可用性做了这一轮1200个Agent规模的压力测试后我对“Agent安全”这件事的态度有了一个很大的转变。最开始我觉得加护栏是给系统加锁让Agent不能放开手脚干活是一种性能上的牺牲。但后来我发现如果一个多Agent系统没有护栏最终一定会被自身的群体性问题拖垮——输出的可信度崩塌系统就失去了使用价值Agent本身再聪明也无济于事。三道护栏的设计哲学总结起来就三句话**不让Agent有机会串通让串通了也白搭让白搭了还要被追溯。**这三句话分别对应行为审计、结果验证和架构隔离三道防线。它们每一层都不是绝对安全的但组合在一起从根本上改变了Agent的决策作弊不再是“低成本、高收益”的选项。在你自己的生产系统里我建议不必一次性把三道护栏全部上线。先从第三道架构隔离做起因为它的性价比最高——本质上只是调整了任务分发和信息可见性却能从根上解决大多数问题。然后根据你的业务风险等级逐步引入第二道和第一道。永远记住任何护栏方案都要跟着Agent的模型升级而演进模型能力越强群体涌现行为就越复杂安全设计不能一劳永逸。