先模拟，再放行：SAIGuard 如何拦截多 Agent 系统中的风险级联

6 月 10 日，吉林大学联合香港中文大学（深圳）、澳大利亚 Griffith University 发布论文 《SAIGuard: Communication-State Simulation for Proactive Defense of LLM Multi-Agent Systems》。

https://arxiv.org/pdf/2606.12474

这篇文章讨论的是一个非常具体但正在变得重要的问题：当多个 Agent 通过消息协作完成任务时，风险可能不再停留在某个单点 Agent 上，而是沿着 Agent 之间的通信链路传播，最后演化成系统级失控。

这篇论文提出的 SAIGuard，可以理解成一种面向多 Agent 系统的“通信安全闸门”：每一条消息真正进入系统之前，先在一个模拟环境里跑一遍，预测它会如何影响多个 Agent 和整个系统状态；如果模拟结果偏离正常通信模式，就阻断、清洗或要求重新生成消息。

多 Agent 系统的风险，正在从“单点异常”变成“通信级联”

单 Agent 场景下，我们通常关注的是模型是否被提示注入、是否泄露隐私、是否调用了危险工具、是否输出了违规内容。

到了多 Agent 系统里，问题会复杂很多。一个 Agent 可能只是被轻微污染，输出看上去也没有明显异常，但它会把这条信息传给下游 Agent。下游 Agent 再结合自己的角色、记忆、工具权限继续处理，风险就可能被重写、扩散和放大。

论文把多 Agent 系统里的安全风险分成三层：

第一层是 Agent-level Security Risk，也就是单个 Agent 被攻击，例如提示注入、工具滥用、记忆投毒。

第二层是 Communication-level Security Risk，攻击者不一定直接控制 Agent，而是篡改 Agent 之间传递的消息。

第三层是 System-level Security Risk Cascade，局部风险通过通信结构扩散，最终造成系统级失败。

这也是这篇论文最值得关注的地方：它没有继续把 Agent 安全只理解为“检测某个 Agent 是否有害”，而是把注意力转向了 Agent 之间的通信过程。

换句话说，多 Agent 安全的核心问题之一，已经变成：

一条消息在进入系统之后，会不会被多个 Agent 接力传播，最终引发系统级偏航？

传统防御的问题：发现得太晚，处理得太重

论文认为，现有多 Agent 防御方法大多属于反应式防御。

所谓反应式，就是等 Agent 已经执行完、已经输出结果、甚至已经调用工具之后，再去判断哪个 Agent 有害，然后隔离这个 Agent，或者剪断它和其他 Agent 的通信边。

这种思路有两个明显问题。

第一个问题是 检测滞后。如果一个 Agent 已经调用工具泄露了敏感信息，事后再检测到它有问题，数据已经泄露，损失无法回滚。论文也明确举了这个例子：一旦有害 Agent 通过工具调用泄露敏感信息，之后再检测已经无法恢复暴露的数据。

第二个问题是 处置粗糙。多 Agent 系统之所以能工作，就是因为不同 Agent 之间需要通信和协作。直接隔离某个 Agent，或者剪掉通信链路，可能会破坏原本有用的信息流，尤其当这个 Agent 是协作网络中的中心节点时，系统整体能力会明显下降。

传统反应式 MAS 防御与 SAIGuard 的差异：前者事后隔离 Agent，后者在消息传播前进行模拟和拦截。

所以，SAIGuard 想回答的问题非常清楚：

如何在风险真正传播之前拦截它，同时尽量保留多 Agent 系统的协作能力？

一个关键观察：局部扰动会被系统放大 17 倍以上

为了说明这个问题，论文做了一个 pilot study。

作者构建了一个 6 Agent 协作网络，然后向其中一个入口 Agent 注入工具攻击。这个攻击在局部 Agent 上造成的状态偏差并不大，单个 Agent 最大偏差只有 3.00%。但经过多轮通信传播之后，聚合后的系统状态偏差达到 51.78%，超过局部最大偏差的 17 倍。

这个结果很有启发性。

因为它说明，多 Agent 风险并不一定以“某个 Agent 明显变坏”的方式出现。很多时候，单个 Agent 看上去只是轻微偏移，但多个 Agent 的状态组合到一起，整个系统已经明显偏航。

局部扰动的系统级放大：单个 Agent 偏差很小，但系统聚合状态发生显著偏移。

这也是 SAIGuard 采用“通信状态模拟”的直接原因：不能只看入口 Agent 有没有异常，还要预测这条消息进入通信图之后，会不会影响整个系统状态。

SAIGuard 的核心思路：消息进入系统前，先做一次影子传播

SAIGuard 的整体架构分成两个阶段：

第一阶段是 Communication-State Simulation，通信状态模拟。

第二阶段是 System Deviation Intervention，系统偏差干预。

可以把它理解成一个“影子运行环境”。

真实多 Agent 系统里，消息还没有真正发给目标 Agent。SAIGuard 会先在模拟空间中，把这条消息放入目标 Agent 的状态里，然后根据 Agent 通信图，用一个多层 GNN 模拟它在多跳通信中的影响。

这个 GNN 不需要完整复现每个 LLM Agent 的全部推理过程，它更像是一个拓扑感知的传播近似器：通过 L 层图传播，估计这条消息可能影响哪些 Agent，以及最终会形成怎样的全局系统状态。论文明确说，SAIGuard 用 L-layer GNN 作为 topology-aware surrogate simulator，用来估计 incoming message 的 L-hop influence。

简单说，就是：

• 消息先不进真实系统
• 先进入一个模拟 MAS
• 在模拟 MAS 里沿通信图传播
• 再看传播后的状态是否偏离正常模式。
• 这就是标题里的“先模拟，再放行”。

第一层：通信状态模拟，预测消息的传播后果

SAIGuard 会把多 Agent 系统建模成一个有向交互图。

每个节点是一个 Agent，每条边是一个通信通道。每个 Agent 的状态包括角色、记忆、工具、历史交互等信息。对于一条 incoming message，SAIGuard 会将消息编码后注入接收方 Agent 的模拟状态，再通过 GNN 聚合邻居信息。

这里要注意，SAIGuard 关心的并不是“这条消息文本本身是否像攻击指令”。

它真正关心的是：

这条消息进入当前 MAS 之后，会让哪些 Agent 的状态发生变化？会不会让全局系统状态出现异常偏移？

这就比普通内容审核更进一步。

普通护栏看的是消息内容，SAIGuard 看的是消息后果。

普通护栏回答的是“这句话危险吗”，SAIGuard 回答的是“这句话放进这个多 Agent 系统里，会不会造成危险传播”。

第二层：系统偏差干预，用正常通信模式做基线

模拟传播之后，SAIGuard 还需要判断结果是否异常。

它的做法是先学习正常 MAS 的通信模式。也就是说，先用干净的多 Agent 执行轨迹，训练一个重构模型，让模型知道正常情况下 agent-level 状态和 system-level 状态应该长什么样。

当一条新消息进入模拟流程后，SAIGuard 会得到一组模拟后的 Agent 状态和一个全局系统状态。随后，它用 decoder 去重构这些状态。如果重构误差很大，就说明这条消息诱导出的通信状态不符合正常模式。

论文同时计算两类异常分数：

一类是 Agent-level Anomaly Score，看单个 Agent 状态是否异常。

另一类是 System-level Anomaly Score，看整个 MAS 聚合状态是否异常。

只要系统级误差超过阈值，或者任意 Agent 级误差超过阈值，这条消息就会被标记为异常。

为了降低异常值对阈值的影响，论文没有简单使用均值方差，而是使用了 median + MAD 的鲁棒阈值。阈值形式是：

τ = median(S) + k × 1.4826 × MAD(S)

其中 k 控制检测敏感度，论文默认设置为 3。

这个设计在产品上也很有现实意义。Agent 系统的运行状态天然波动很大，如果阈值太敏感，会产生大量误报；如果阈值太宽松，又会漏掉真实攻击。SAIGuard 用 MAD 做鲁棒阈值，本质上是在安全性和可用性之间找一个更稳定的平衡点。

SAIGuard 的处置粒度：处理消息，而不是直接封 Agent

我觉得这篇论文最有工程味的设计，是它没有默认把异常归因到 Agent 本身。

在传统方案里，一旦发现某个 Agent 输出异常，常见做法是隔离这个 Agent，或者剪掉它的通信边。但在多 Agent 系统里，一个 Agent 可能只是接收了污染消息，或者通信链路被篡改了。这个时候直接封 Agent，可能会误伤正常协作能力。

SAIGuard 的处置策略更细：

对于外部恶意消息注入，也就是攻击者直接把恶意消息打到某个 Agent，SAIGuard 会在系统边界阻断这条消息。

对于通信劫持，也就是两个正常 Agent 之间的消息被篡改，SAIGuard 不会直接隔离发送方 Agent，而是删除被污染的消息，并要求原 Agent 重新生成消息。

SAIGuard 的两类干预策略：外部恶意消息直接阻断，内部通信劫持触发消息重生成。

这个设计非常适合和企业里的 Agent Gateway、Tool Gateway、Workflow Orchestrator 结合。

四类攻击：提示注入、工具攻击、记忆投毒、通信劫持

论文的实验部分覆盖了四类攻击场景。

第一类是 Prompt Injection，基于 GSM8K 的对抗样本

第二类是 Tool Attack，基于 InjecAgent 构造工具攻击

第三类是 Memory Poisoning，参考 PoisonRAG 配置记忆投毒

第四类是 Communication Hijacking，在 MMLU 上模拟 Agent 之间正常通信内容被拦截并篡改为恶意内容

这四类攻击基本覆盖了当前多 Agent 系统里最常见的几条风险链路：入口提示污染、工具调用滥用、长期状态污染、通信链路篡改。

对比基线方面，论文选了 G-Safeguard、Dominant、PREM、TAM、BlindGuard、XG-Guard 六个反应式 MAS 防御方法。评估指标主要包括 ACC 和 ASR：ACC 衡量任务可用性，ASR 衡量攻击成功率。

论文还在 Chain、Tree、Star、Random 四种通信拓扑，以及 GPT-4o-mini、DeepSeek-V3、DeepSeek-V3.2、Qwen-30B-A3B 等不同底座模型上做了实验。默认设置下，系统 Agent 数量为 8，攻击实例数量为 3，阈值 k 设置为 3。

实验结果

从 Table 1 看，SAIGuard 的整体平均 ACC 为 89.83，整体平均 ASR 为 5.37。作为对比，最强基线 XG-Guard 的整体平均 ACC 为 80.13，整体平均 ASR 为 16.51。论文总结为：相对最强基线，SAIGuard 平均 ACC 提升 11.96%，平均 ASR 降低 67.47%。

分攻击类型看，几个结果尤其值得注意：

在 Memory Poisoning 场景下，SAIGuard 的 ASR 为 3.36，明显低于 G-Safeguard、BlindGuard、XG-Guard 等方法。

在 Communication Hijacking 场景下，SAIGuard 的 ASR 为 0.00。

在 Tool Attack 场景下，SAIGuard 的 ACC 达到 88.16，同时 ASR 为 9.62。

这组结果说明，SAIGuard 对“传播型风险”确实更友好。尤其是记忆投毒和通信劫持，这两类攻击本来就不一定在单点输出上立刻暴露，而是更容易在多轮通信中累积影响。

RQ1：不同攻击和不同底座模型下是否有效？

论文第一个研究问题，是 SAIGuard 在不同攻击类型和不同设置下是否具备更强防御能力。

结果显示，SAIGuard 在四类攻击上都取得了最好的整体表现；同时在不同通信拓扑和不同底座模型上，它的 ASR 也保持较低。论文的 Figure 6 进一步展示了不同拓扑和不同 LLM 下的 ASR 对比，SAIGuard 在 Chain、Tree、Star、Random 等拓扑下都保持较低攻击成功率。

不同通信拓扑和不同底座模型下的 ASR 对比：SAIGuard 对拓扑变化具备较强鲁棒性。

这对真实系统很关键。因为企业里的 Agent 网络不会只有一种固定结构。有的是链式工作流，有的是中心调度，有的是树状分工，还有的是多个 Agent 动态协作。如果防御方法只能适配单一拓扑，落地价值会有限。

RQ2：Agent 数量变多后，还能不能压住风险扩散？

第二个研究问题是可扩展性。

论文把 MAS 规模扩展到 20、50、80 个 Agent，并在 Chain、Tree、Star 拓扑下测试。结果显示，没有防御时，ASR 会随着对话轮次增加而上升，说明多轮交互会持续放大风险；XG-Guard 可以部分缓解，但不同设置下不够稳定；SAIGuard 在不同规模和拓扑下都能保持最低 ASR，即使在 80 个 Agent 场景下也能压住攻击传播。

Agent 数量扩展到 20、50、80 后，SAIGuard 仍能抑制多轮风险传播。

这个结果可以和企业 Agent 平台直接对应起来。

当企业内部只有一个简单客服 Agent 时，传统内容安全护栏也许还能覆盖大部分风险。但当系统里出现研发 Agent、运维 Agent、数据分析 Agent、审批 Agent、知识库 Agent、工单 Agent，且它们之间可以互相发消息、互相调用工具时，风险就会从“单点检测问题”变成“系统传播控制问题”。

SAIGuard 的意义，正是把多 Agent 系统当成一个通信网络来治理。

RQ3：真正起作用的是哪个模块？

论文第三个研究问题是消融实验。

完整 SAIGuard 的 Precision、Recall、F1 分别为 98.36%、99.01%、98.68%。去掉 Communication-State Simulation 后，F1 降到 95.95%，这是所有消融项里下降最大的。去掉系统级 loss、Agent 级 loss、MAD 阈值，也都会降低效果。

消融实验：通信状态模拟是 SAIGuard 中最关键的组件。

这个结果说明，SAIGuard 的效果并不只是来自一个普通异常检测器，而是来自“预执行通信模拟 + 局部/全局偏差检测”的组合。

特别是 Communication-State Simulation，它让系统可以在消息真正影响真实 Agent 之前，提前观察潜在的传播后果。

RQ4：阈值 k 是否敏感？

论文第四个研究问题是阈值敏感性。

SAIGuard 使用 k 控制 MAD 阈值的敏感度。论文测试了 k 从 1 到 6 的效果，结果显示 k 在 2 到 4 之间性能比较稳定；k 太小会导致阈值过严，误报增加，Precision 下降；k 太大则会导致阈值过松，漏报增加，Recall 和 F1 下降。论文认为默认 k=3 是一个比较稳健的设置。

阈值 k 的敏感性分析：k=2 到 4 是相对稳定的工作区间。

这个地方可以延伸到实际产品经验：安全系统很少只有“检得准”一个目标，它还必须控制误报。尤其在 Agent 工作流中，如果每条消息都被频繁误拦截，业务侧很快就会关闭安全策略。

所以，SAIGuard 的 MAD 阈值虽然看起来只是一个技术细节，但背后对应的是安全产品最核心的平衡：安全性、可用性和连续性。

这篇论文对企业 Agent 安全的启发

SAIGuard 最重要的启发，是把多 Agent 安全的治理对象从“Agent 个体”进一步推进到“Agent 通信”。

以前我们谈 Agent 安全，常见抓手包括：

• 模型输入输出审核
• 工具调用权限控制
• Agent 身份治理
• 记忆和知识库污染检测
• 运行时日志审计
• 异常 Agent 隔离。

这些都很重要，但如果 Agent 之间已经开始形成复杂通信网络，还需要增加一层新的安全能力：

通信级运行时防御。

这层能力至少应该回答几个问题：

第一，每条消息从哪里来，要发给哪个 Agent？

第二，这条消息是否改变了接收方 Agent 的任务意图、权限边界或工具调用路径？

第三，这条消息是否会影响下游多个 Agent？

第四，消息本身可疑，还是发送方 Agent 可疑，还是通信链路被污染？

第五，处置策略应该是阻断消息、重写消息、要求重新生成，还是隔离 Agent？

SAIGuard 给出的答案，是把消息放到通信图里做模拟，再通过系统偏差判断风险。这条路线和企业里的 Agent Gateway、Tool Gateway、Workflow Engine、MCP Gateway 都有结合空间。

未来企业如果要建设 Agent 安全架构，不能只在“用户输入”和“最终输出”两端做检测。Agent 和 Agent 之间的中间消息，也应该成为安全控制点。

局限性

论文也明确承认了一个限制：当前 SAIGuard 主要关注文本通信，而真实世界的多 Agent 系统可能会处理图像、音频、视频等多模态输入。因此，它可能无法完全捕捉隐藏在非文本模态中的风险，例如视觉提示注入和误导性视觉内容。作者认为，未来可以把多模态编码器接入 SAIGuard，用于扩展到多模态 MAS。

除此之外，从工程落地角度看，我认为还有几个问题需要继续验证。

• 第一，它依赖正常通信轨迹。如果企业 Agent 的任务变化频繁，正常模式本身会不断漂移，阈值和重构模型就需要持续更新。
• 第二，GNN 只能近似传播影响。真实 Agent 的推理过程受到模型能力、提示词、记忆、工具状态、外部环境等多因素影响，模拟传播不可能完全等价于真实执行。
• 第三，每条消息都做模拟和重构，会带来额外延迟。对于高频 Agent 通信系统，这个成本需要被产品化评估。
• 第四，通信劫持场景下要求原 Agent 重新生成消息，但如果原 Agent 的上下文已经被污染，重新生成也可能继续带出风险。

所以，SAIGuard 更像是一个很有价值的研究方向：它证明了“通信前置模拟”有助于降低多 Agent 系统中的风险级联。但在真实企业系统中，它还需要和身份、权限、工具网关、日志审计、沙箱执行、人工复核等机制一起使用。

Agent 安全开始进入“通信治理”阶段

SAIGuard 这篇论文的价值，不只在于提出了一个新模型。

当 Agent 数量越来越多，通信拓扑越来越复杂，安全治理就不能只盯着单个 Agent 的行为。我们需要看到消息如何流动，风险如何扩散，局部异常如何被系统放大。

SAIGuard 给出的思路是：

先模拟，再放行；先预测传播后果，再决定是否让消息进入真实系统。

这可能会成为多 Agent 安全架构中的一个重要方向：从单点护栏，走向通信级防御；从事后隔离，走向前置拦截；从看内容是否危险，走向看消息进入系统之后会造成什么后果。