temp
最后更新于
最后更新于
《Why Do Multi-Agent LLM Systems Fail?》（https://arxiv.org/pdf/2503.13657），通过对对5种流行MAS框架、150多个对话轨迹的分析，经过6位专业标注，确定3类共14种故障模式。
代理系统的良好功能激发了对特定代理挑战的研究。例如，Agent Workflow Memory通过引入工作流内存来解决Long-Horizon网络导航问题。DSPy和 Agora解决了通信流中的问题，StateFlow专注于代理工作流中的状态控制，以提高任务解决能力。
为了系统地、无偏见地发现故障模式，我们采用了GT理论方法，这是一种定性研究方法，它直接从经验数据构建理论，而不是测试预定义的假设。GT 的归纳性质使故障模式的识别有机地出现。我们通过理论抽样、开放式编码、持续比较分析、备忘和理论化迭代收集和分析 MAS 执行轨迹。
在获得 MAS 轨迹并讨论初步发现后，我们通过收集观察到的故障模式得出初步分类法。为了完善分类法，我们进行了inter-annotator一致性研究，通过添加、删除、合并、拆分或修改定义来迭代调整故障模式和故障类别，直到达成共识。此过程反映了一种学习方法，其中分类法不断完善，直到实现稳定性，通过 Cohen 的 Kappa 分数通过Annotator间一致性来衡量。此外，为了实现自动故障识别，我们开发了一个基于 LLM 的Annotator并验证其可靠性。
规范与系统设计故障：系统架构设计缺陷、对话管理不佳、任务规范不明确或违反约束条件，以及代理角色和职责定义不充分或不遵守而引起的故障。有五种故障模式：
不遵守任务规范。未能遵循给定任务的指定约束或要求，导致次优或不正确结果。
不遵守角色规范。未能遵守分配角色的定义职责和约束，可能导致一个代理表现得像另一个代理。
步骤重复。在流程中对已完成步骤的不必要重复，可能导致任务完成过程中的延误或错误。
丢失对话历史。意外的上下文截断，忽略最近的互动历史，并回到之前的对话状态。
不了解终止条件。缺乏对应当触发代理互动终止的标准认可或理解，可能导致不必要的继续。
违反任务规范：当被要求设计一款以经典国际象棋走法符号（如“Ke8”、“Qd4”）作为输入的双人国际象棋游戏时，MAS 框架 ChatDev 会生成一款以 (x1, y1)、(x2, y2) 作为输入的游戏，这些符号表示棋盘上棋子的初始坐标和棋子的最终坐标，因此无法满足初始要求。
未遵守角色规范：在 ChatDev 的需求分析阶段，CPO 代理偶尔会通过单方面定义产品愿景并做出最终决策来承担 CEO 的角色。
代理间不一致：包括由于沟通无效、协作不佳、代理间的冲突行为以及逐渐偏离初始任务而产生的故障，有六种故障模式：
对话重置。意外或无正当理由的对话重新开始，可能丢失上下文和互动中取得的进展。
未能请求澄清。在遇到不清晰或不完整数据时无法请求额外信息，可能导致错误行动。
任务脱轨。偏离既定任务的预期目标或焦点，可能导致无关或无效的行动。
信息隐瞒。未能共享或传达代理拥有的重要数据或见解，如果共享可能会影响其他代理的决策。
忽略其他代理的输入。忽视或未能充分考虑系统中其他代理提供的输入或建议，可能导致次优决策或错失合作机会。
推理与行动不匹配。逻辑推理过程与代理实际采取的行动之间的差异，可能导致意外或不期望的行为。
多智能体系统经常遭受对话效率低下的问题，智能体会进行无效的交流，消耗计算资源却没有取得有意义的进展：在涉及创建类似 Wordle 的游戏的 ChatDev 跟踪中，程序员智能体在七个周期内与多个角色（CTO、CCO 等）进行了交互，但未能更新初始代码。由此产生的游戏可玩但缺乏稳健性，只有五个简单的单词，破坏了可重玩性并导致额外的通信轮次浪费。
此类别中的另一种故障模式是智能体隐瞒有价值的信息：主管智能体指示电话智能体使用电子邮件 ID 作为用户名来检索联系信息。电话智能体在阅读文档并发现正确的用户名应该是电话号码后，仍然使用错误的凭据继续操作，导致错误。
任务验证与终止：包括由于过早执行终止导致的失败，以及缺乏足够的机制来保证互动、决策和结果的准确性、完整性和可靠性，有三种故障模式：
过早终止。在所有必要信息尚未交换或目标尚未达成之前结束对话、互动或任务，可能导致不完整或不正确的结果。
未进行或未充分验证。（部分）省略对任务结果或系统输出的适当检查或确认，可能使错误或不一致未被检测到而传播。
错误验证。在迭代过程中未能充分验证或交叉核对关键信息或决策，可能导致系统中的错误或漏洞。
我们强调，没有任何单一错误类别占主导地位，这表明故障发生具有多样性，并且用于对故障进行分类的分类法具有稳健性。不同的 MAS 表现出不同的故障类别和模式分布。
与规范和验证问题相比，AG2 的代理间错位实例较少，而 ChatDev 遇到的验证问题比规范和代理间错位挑战少。这些差异源于不同的问题设置，这会影响系统拓扑设计、通信协议和交互管理。反过来，这些因素塑造了具有自身优势和劣势的系统。
都是验证者的错吗？可以说，归根结底，每个故障都可能源于缺乏适当的验证或不正确的验证流程。如果我们假设验证代理功能完美，那么所有故障都是可检测的，因此可以避免。在许多情况下，我们可以将验证视为防止故障的最后一道防线。但并非每个问题都可以完全归因于这一因素。其他因素，例如规格不佳、设计不足、沟通效率低下，也会导致故障。因此，全面理解和解决 MAS 故障的方法必须考虑更广泛的因素，而不仅仅是验证缺陷。
我们发现 MAS 面临与复杂人类组织类似的问题的证据，因为故障模式与人类组织中观察到的常见故障模式一致。
Roberts & Rousseau (1989)确定了高可靠性组织 (HRO) 共有的八个主要特征。
不遵守角色规范，违反了 HRO 特征“极端层级分化”
未能要求澄清，破坏了 HRO “尊重专业知识”
MAS 代理的提示应提供清晰的指令描述，并应明确指定每个代理的角色。提示还可以明确角色和任务，同时鼓励主动对话。
如果出现不一致，代理可以重新参与或重试，完成复杂的多步骤任务后，在提示中添加一个自我验证步骤，通过重述解决方案、检查条件和测试错误来追溯推理过程。如下提示词所示。
另一套交叉验证的策略方法包括多次 LLM 调用，并进行多数表决或重采样，直到验证完成。然而，这些看似简单的解决方案往往被证明是不一致的
薄弱或不充分的验证机制是导致系统故障的重要因素。创建一个通用的验证机制仍然具有挑战性。
验证的补充策略是建立标准化的通信协议。基于 LLM 的代理主要通过非结构化文本进行通信，这会导致歧义。明确定义意图和参数可增强一致性，并在交互期间和之后进行正式的一致性检查。
同样，开发一种学习选择性通信协议，以提高合作效率。
使用强化学习对 MAS 代理进行微调。代理可以使用特定于角色的算法进行训练，奖励与任务一致的操作并惩罚效率低下的行为。
MAPPO优化了代理对定义角色的遵守。同样，SHPPO在应用异构决策层之前使用潜在网络来学习策略。Optima通过迭代强化学习进一步提升沟通效率与任务效果。
将概率置信度度量纳入代理交互可以显著提高决策和通信可靠性。从 Horvitz 等人提出的框架中汲取灵感。代理可以被设计为只有当其置信度超过预定义的阈值时才采取行动。相反，当置信度较低时，代理可以暂停以收集更多信息。此外，系统可以从自适应阈值中受益，其中置信度阈值是动态调整的。
尽管记忆和状态管理通常被视为单智能体属性，但对于多智能体交互来说，它们至关重要，可以增强上下文理解并减少交流中的歧义。
要想实现智能体不仅仅需要大模型具备“思考”的能力，同时还需要大模型能够使用外部工具，简单来说就是第三方接口。关于大模型调用外部工具接口的技术，就叫做function call 也就是函数调用；是通过给大模型提供一个函数列表，这个函数列表中描述了每个函数的功能，参数等
简单来说，你想实现一个Agent智能体，然后根据功能定义了一堆函数列表；然后告诉大模型根据用户输入的问题，去自主判断调用那个函数。
也就是说，你要查天气就去调用天气接口，你要查地址就去调用地图接口；而不是在查天气的时候调用地址接口或者在查地址的时候调用天气接口，这就是意图识别。
如果说你的智能体涉及的功能比较少，需要调用的接口也比较少；可能还不会出现这个问题，但如果当你智能体的功能比较复杂时，需要调用多个不同的接口；这时大模型可能就会偶尔抽风，出现不知道或者调用错误的接口。
当然，这种现象并不仅仅只是大模型的问题，我们人类同样也有可能出现这种问题。举例来说，有一辆三轮车和一辆小货车，然后我说要拉东西你去把车开过来一下；这时你应该开三轮车还是小货车？
说实话这种问题目前还没有一个完美的解决方案，即使放到我们人类身上偶尔也会因为沟通或理解的问题导致出错，在大模型上这种错误概率更是会被无限放大。而我们只能尽可能的去避免这种问题的出现，而具体的解决办法大概有以下几种：
使用准确清晰的描述：那个函数到底的干啥的，有什么具体的功能，最好使用最细致的描述，使歧义尽可能的降低
使用多轮对话：通过多次交流，使得能够更准确的理解需求；而这也是我们平常沟通过程中经常用的的方法。
使用分类模型：说白了意图识别问题，本质上就是一个分类问题；你的描述越模糊分类越困难，因此可以使用专业的分类模型，来让大模型确定自己的需求。
使用规则引擎：帮助大模型设计一套规则引擎，简单来说就是当大模型出现模糊判断的时候，应该怎么进行兜底；比如说增加人工判断或者重新选择的机会等。或者使用某种规则，不管意图什么样，只要满足规则需求就去执行。