Skip to content

如何评估多智能体系统

评估多智能体 LLM 系统的实用指南：把失败归因到负有责任的智能体和交接、审查交互图，以及为每个智能体和整个团队打分。

一个多智能体系统是若干个 LLM 智能体（规划者、编码者、审查者等）协作完成同一项任务。评估它不只是为最终答案打分，因为真正重要的失败发生在智能体之间：交接处丢掉的某个约束、错误的智能体接管了任务、一个从不验证自身工作的团队。有用的判断单元是哪个智能体、哪一步、哪次交接。 Potato 是一款用于对多智能体运行进行人工评估的开源工具，为团队结构提供了一组专门构建的标注界面。

这里的多智能体系统指的是一个由 LLM 驱动的工作流，其中各自有角色的智能体交换消息并交接控制权。关于这些系统为何失败的研究（MAST 分类体系，Why Do Multi-Agent LLM Systems Fail?）发现，相当大一部分失败是智能体间的：规范问题、智能体之间的失配，以及缺失验证。一段扁平的对话记录恰恰会把这些隐藏起来。

为什么单智能体评估还不够？

当你评估一个智能体时，你判断的是单一序列的思考、工具调用和观察。一个团队会增加只存在于智能体之间的失败模式：

  • 交接丢失：智能体 A 知道一个约束，而智能体 B 从未收到它。
  • 错误归因：运行失败了，但负有责任的智能体处在错误浮现位置的上游。
  • 协调失败：每个智能体单独看都很称职，团队却循环、停滞，或从不验证。
  • 资源争用：两个智能体同时触及同一个工具或文件并死锁。

只为最终输出打分只能告诉你团队失败了，而不是失败发生在哪里。归因才是让数据对调试或训练有用的关键。

我如何归因一次多智能体失败？

失败归因文献（Zhang 等人，Which Agent Causes Task Failures and When?，ICML 2025）将标签构建为一个三元组：负有责任的智能体、决定性步骤和一个原因。在 Potato 中，failure_attribution schema 由轨迹本身填充智能体和步骤选择器，因此标注者从实际发生过的智能体和步骤中进行选择：

yaml
annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

将结果 schema 与归因搭配，意味着这个三元组只在实际失败的运行上收集。

我如何审查团队结构，而不只是对话记录？

两个界面让结构可见。交互图把智能体渲染为节点、把交接渲染为边，标注者标记关键路径并标出有问题的边。交接审查把每一次控制权转移都变成一张卡片，用以标记失配并评定质量：

yaml
annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

在打分方面，agent_scorecard 在角色忠实度、贡献度和协调性上为每个智能体评分，并在团队自身的维度上为团队打分，这样一个处在协调糟糕的团队中的强势个体智能体就会在数字中显现出来。

我该使用哪种方法？

  • 调试一条流水线：从交互图和失败归因入手，定位运行在哪里崩溃。
  • 对比编排模式：加入评分卡，在相同任务上为顺序型 vs. 层级型 vs. 群聊型设计打分。
  • 构建训练或奖励数据：在步骤粒度上用 MAST 模式标记失败（通过 trajectory_eval），使标签附着到行动智能体和步骤上。
  • 并发缺陷：用工具争用时间线捕捉对话记录无法显示的死锁和竞态。

像对待任何主观标签那样衡量归因上的一致性；参见标注者间一致性。

延伸阅读