《On the Resilience of LLM-Based Multi-Agent Collaboration with Faulty Agents》
发表于 International Conference on Machine Learning. PMLR, 2025: 26202-26226
开源地址：https://github.com/CUHK-ARISE/MAS-Resilience 本文假设多智能体协作中存在恶意/故障的智能体。
摘要&引言
文章探究：
1.什么样的结构更有“弹性”（弹性越高，有问题的智能体对整体任务成功率的损害越低） 2.如何增加多智能体协作系统的安全性 3.哪种下游任务更易受影响
其中，关于系统弹性的解释
the capacity to handle internal errors and maintain overall operation without being affected by a single failure
借助两个东西来研究多智能体应对单节点agent故障的弹性， 一个是AUTOTRANSFORM用于将指定agent变为故障agent， 一个是AUTOINJECT用于直接注入错误信息到正在多智能体间传播的信息中 本文的方法也是围绕AUTOTRANSFORM、AUTOINJECT展开。 借助多个智能体框架和下游任务，探究哪种结构更具弹性，哪种下游任务更具弹性（受影响最小） 下图给出了本文中实验的几种多智能体结构、下游任务。 拦截所有信息再通过检查&修正信息来监督AUTOINJECT
数学表达
借助数据结构中图的描述来数学化3种结构Linear、Flat、 Hierarchical。具体是图的节点、边集合。有向图的出度、入度。（不看，对文章理解影响也不大）
方法
介绍了AUTOTRANSFORM、AUTOINJECT是怎样做的。
AUTOTRANSFORM
分析原有的agentProfile，生成一个不易被发觉的、产生错误的Profile部分的提示词；该方法通过在agentProfile中插入一段恶意提示词来完成
AUTOINJECT
AUTOTRANSFORM产生的错误过于随机，而AUTOINJECT用于注入恶意指令，能够产生具体的错误结果（精确的控制，错误信息的条数，错误信息占一条信息的比例，错误的类型）；
AUTOINJECT是一个额外的agent（类似中间人的意思）能够拦截多智能体通信中的每一条信息，并修改产生错误的结果。
衡量具体错误的尺度：error rate and error type.
前者规定了故障agent产生的错误信息的占比（占总信息条数的多少$P_m$），错误量的占比（单条信息中错误的比例$P_e$）
后者规定了故障agent产生的错误类型，如代码生成中的语义、语法错误。
下图c，d分别展示了两种方法的破坏过程。
实验
6种框架（MeatGPT、Camel等）3种agent组织结构（第一张图提到的），4种下游任务（代码生成、数学解题、翻译、文本评估）
思考：
从下图看，精确率并不是全部都大幅度降低，但是，这里巧妙的引入弹性，比较的是哪种结构下受影响更低。
实验回答的4个问题：RQ1-4
| 研究问题 | 核心研究内容（人话） | 关键结论（人话） | 影响程度 / 排序 |
|---|---|---|---|
| RQ1 系统结构影响 | 线性、扁平、层级三种结构，哪种更有弹性在面对恶意智能体时 | 层级结构最稳，性能仅下降 5.5%；扁平下降 10.5%；线性最差，下降 23.7% | 层级 > 扁平 > 线性 |
| RQ2 任务类型影响 | 代码、数学、翻译、文本评估四类任务，谁更容易被错误影响 | 客观严谨任务更脆弱：代码生成受影响最大 (-22.6%)，数学次之；翻译 / 文本评估影响很小 | 代码 > 数学 > 文本评估 > 翻译 |
| RQ3 错误率影响 | 错误消息条数占比 ($P_m$)、单条消息错误比例 ($P_e$)，谁的破坏更大 | 错误消息越多，系统崩得越狠；单条消息内错误数量的影响更小，错误太明显还会被自动修正 | $P_m$ (错误消息占比) > $P_e$ (单条错误量) |
| RQ4 错误类型影响 | 语法错误、语义错误，哪种对系统伤害更严重 | 语义错误更致命（逻辑正确但功能错误，难发现）；语法错误易被识别修复 | 语义错误 » 语法错误 |
Case Study
刻意注入的显性错误可触发系统自检，连带修正原有隐藏错误，使任务表现提升。 当前 LLM 存在偏好自然语言注释、忽视代码逻辑的缺陷，易被误导产生漏检。 高层级代理出错的破坏性显著高于底层执行代理，且通信轮次多少与系统抗错能力无关。
Improving System Resilience
提出两种方法来改善系统的弹性
- 引入“Challenger”提示词（置入到每个agent内），来质疑每一个消息（0信任）
- 引入“Inspector,”agent，来拦截所有agent的信息来检查、修改
思考
idea：这里多智能体安全的方法，我有了一个思路，即借鉴前后端开发中的鉴权机制，统一一个“Inspector,”只拦截、转发，不修改通信中的所有消息。那么被拦截不转发的怎么办？目前想法是回滚，回滚到该agent（有问题的agent）收到消息进行处理之前。
疑问：同样的，本文也没有对比实验，上次那篇包含对比实验的是针对单个agent的攻击。 成功率不高，换个说法？
关于攻击实验中成功率的说法，若指定场景下攻击成功率不高，我们就转而分析系统弹性，即列出未被攻击的分数（准确率），攻击后的分数（准确率），评估下不同结构下、不同任务中，甚至还可以引入不同LLM下的系统弹性。
