多 Agent 协作：协调失败数据的构建与格式设计

背景：协调失败，才是真正的瓶颈

当前 LLM 多 Agent 系统的主流叙事是「分工提效」：把复杂任务拆解，交给多个专职 Agent 并行处理，用 Orchestrator 统筹调度。Anthropic 的 multi-agent 框架、OpenAI 的 Swarm，走的都是这条路。

但在实际部署中，系统崩溃的方式往往不是某个 Agent 不够聪明——而是 Agent 之间出了问题：一个 Agent 传给下一个的上下文不完整，导致后续步骤跑偏；任务链条拉长之后，末端 Agent 已经不清楚自己到底在服务谁的目标；两个 Agent 同时认为某个子任务是「对方的责任」，结果谁都没做。

这三类问题——信息不对称、目标漂移、责任边界模糊——构成了多 Agent 系统的协调失败三角。它们几乎不可能靠单 Agent 能力的提升来解决，因为问题根源在于 Agent 之间的接口，而不在于 Agent 自身。

解决这个问题，需要数据。但目前没有人系统性地构建过以协调失败为核心的多 Agent 训练数据。本文是一个研究提案，试图填补这个空白。

---

一、协调失败的三种模式与对应数据构建

1.1 信息不对称：handoff 时关键上下文丢失

问题描述：Agent A 完成一个子任务后，将控制权交给 Agent B（即 handoff）。但 A 传递的摘要不完整，导致 B 在错误的假设下工作。这是最常见、也最难被发现的协调失败形式——因为 B 不知道自己不知道什么。

数据构建方法：

构造「上下文传递」对比任务。具体做法：设计一批任务，其中关键信息被刻意分布在 Agent A 的操作历史中（如：搜索结果中的一个约束条件、工具返回值里的一个异常字段）。分两组：

• 完整传递组：Agent A 在 handoff_summary 中包含该关键信息；
• 截断传递组：handoff_summary 仅包含表面结论，遗漏关键细节。

然后让 Agent B 在两种条件下执行相同任务，记录最终输出差异。差异显著的样本即为高质量的「信息不对称」训练数据。

自动检测 handoff 质量：

设计一个轻量级 Judge Agent，专门验证 handoff_summary 的信息完整性。具体实现：

1. 从 Agent A 的完整轨迹中自动提取「关键决策节点」（凡是影响后续步骤的工具调用结果或条件判断）；
2. 用 LLM 对每个关键节点判断：该信息是否在 handoff_summary 中有所体现？
3. 计算覆盖率得分作为 handoff 质量指标。

handoff_summary 字段设计原则：

不是「做了什么」的流水账，而是「后续 Agent 需要知道什么」的精炼清单。包含：完成状态、关键约束（尤其是负面约束：「不能用方案 X 因为……」）、未解决的不确定性、以及下游 Agent 应重点关注的风险点。

---

1.2 目标漂移：长链路中目标理解逐渐偏移

问题描述：在 5 步以上的任务链中，每个 Agent 都基于前一个 Agent 的输出工作，而非直接参照原始目标。累积效应下，末端 Agent 的行为可能与用户的真实意图相去甚远——即使每一步的局部逻辑都是「合理的」。

构造多步骤任务检测目标漂移：

使用目标扰动注入法：在任务链中间某个步骤，故意引入一个与全局目标存在细微张力的局部优化（例如：全局目标是「以最低成本完成部署」，但在第 3 步注入「优先保证响应速度」的局部优化）。

对比两条轨迹：

• 目标锚定组：每个 Agent 在 prompt 中都携带 global_goal 字段，遇到局部优化冲突时主动检查；
• 无锚定组：每个 Agent 只看上一步的输出，不持有全局目标引用。

记录末端输出与原始 global_goal 的偏离程度，差异大的样本即为目标漂移正样本。

目标一致性检验步骤的数据格式：

在轨迹的关键节点插入 goal_alignment_check 步骤，要求 Agent 显式声明「我当前的行动如何服务于全局目标」。若 Agent 无法给出清晰对应，则触发目标重新对齐。这个步骤本身也作为训练数据的一部分，训练模型的自我校准能力。

---

1.3 责任边界模糊：任务遗漏与冲突

问题描述：当多个 Agent 的职责域存在重叠或间隙时，任务要么被两个 Agent 都认为是「对方负责」而遗漏，要么被两个 Agent 各自执行一次产生冲突。

系统性构造「边界模糊」场景：

设计一套边界条件矩阵：对于每个任务类型，穷举其责任归属的模糊情形。例如：

• 间隙型：任务 T 既不在 Agent A 的角色描述范围内，也不在 Agent B 的范围内；
• 重叠型：任务 T 既可被 Agent A 处理，也可被 Agent B 处理，但执行方式不同；
• 依赖型：任务 T 需要 Agent A 的输出才能由 Agent B 完成，但 A 不知道 B 在等待。

每类场景合成 50-100 个具体实例，覆盖不同领域（代码、数据分析、内容生成等）。

冲突检测的数据标注方案：

对每条多 Agent 轨迹，增加结构化标注层：

• coverage_map：记录每个子任务被哪些 Agent 认领；
• conflict_flags：标注发生重叠执行的步骤；
• gap_flags：标注被遗漏的子任务；
• resolution：标注正确的责任分配方案（正例）或失败的分配（负例）。

---

二、多 Agent 轨迹格式设计

这是整个研究提案中最关键的工程问题。没有标准化的轨迹格式，数据无法大规模复用，模型也无法从中学到跨 Agent 的协调模式。

从单 Agent 到多 Agent 的格式扩展

单 Agent 轨迹的基本单元是：

[observation → thought → action → observation → ...]

多 Agent 场景需要在这个基础上新增四个关键字段：

字段	含义
global_goal	整个协作任务的全局目标，所有 Agent 共享，不可修改
agent_role	当前 Agent 在协作中的角色定义和职责边界
peer_context	其他 Agent 的当前状态摘要（由 Orchestrator 维护和推送）
handoff_summary	当前 Agent 完成工作后向下游传递的结构化摘要

完整 JSON 数据结构示例

以下是一个「代码审查 + 修复」多 Agent 协作场景的完整轨迹示例，包含两个 Agent（Reviewer 和 Fixer）以及一次 handoff：

{
  "trajectory_id": "traj-20260330-0042",
  "task_type": "code_review_and_fix",
  "global_goal": "审查 pull_request #472，修复所有安全漏洞，确保代码可合并",
  "agents": [
    {
      "agent_id": "agent_reviewer",
      "agent_role": "代码安全审查员，负责识别安全漏洞，不负责修复代码",
      "steps": [
        {
          "step": 1,
          "observation": "PR #472 包含 3 个文件变更：auth.py, db.py, api.py",
          "thought": "需要逐文件检查，重点关注认证逻辑和 SQL 查询",
          "action": {
            "type": "tool_call",
            "tool": "read_file",
            "args": { "path": "auth.py" }
          }
        },
        {
          "step": 2,
          "observation": "auth.py 第 47 行存在硬编码密钥；db.py 第 23 行存在 SQL 注入风险",
          "thought": "发现两处高危漏洞，需要在 handoff_summary 中清楚标注位置和风险等级",
          "action": {
            "type": "handoff",
            "target_agent": "agent_fixer"
          }
        }
      ],
      "handoff_summary": {
        "completed": "安全审查完成，发现 2 处高危漏洞",
        "critical_findings": [
          {
            "file": "auth.py",
            "line": 47,
            "issue": "硬编码 API_SECRET，应改用环境变量",
            "severity": "HIGH"
          },
          {
            "file": "db.py",
            "line": 23,
            "issue": "字符串拼接构造 SQL 查询，存在注入风险，应使用参数化查询",
            "severity": "HIGH"
          }
        ],
        "negative_constraints": "不要修改 api.py，该文件无问题且涉及敏感配置",
        "unresolved_uncertainties": "auth.py 第 89 行的 token 过期逻辑可能有问题，但不确定是否属于安全漏洞，建议 Fixer 关注",
        "downstream_risks": "db.py 修改后需重新运行集成测试，测试配置在 tests/db_integration/"
      }
    },
    {
      "agent_id": "agent_fixer",
      "agent_role": "代码修复员，根据审查报告修复漏洞，不负责发现新问题",
      "peer_context": {
        "agent_reviewer": {
          "status": "completed",
          "summary": "发现 2 处高危漏洞，见 handoff_summary"
        }
      },
      "steps": [
        {
          "step": 1,
          "goal_alignment_check": "我当前的任务是修复 auth.py#47 和 db.py#23，服务于全局目标「修复所有安全漏洞」，范围清晰",
          "observation": "接收 handoff_summary，读取 auth.py#47",
          "thought": "硬编码密钥替换为 os.environ.get() 调用，需确保环境变量在部署文档中有记录",
          "action": {
            "type": "tool_call",
            "tool": "edit_file",
            "args": {
              "path": "auth.py",
              "line": 47,
              "old": "API_SECRET = 'sk-hardcoded-key-12345'",
              "new": "API_SECRET = os.environ.get('API_SECRET')"
            }
          }
        },
        {
          "step": 2,
          "observation": "auth.py 修复完成，转向 db.py#23",
          "thought": "将字符串拼接改为参数化查询，注意保持原有业务逻辑",
          "action": {
            "type": "tool_call",
            "tool": "edit_file",
            "args": {
              "path": "db.py",
              "line": 23,
              "old": "cursor.execute(f'SELECT * FROM users WHERE id = {user_id}')",
              "new": "cursor.execute('SELECT * FROM users WHERE id = ?', (user_id,))"
            }
          }
        }
      ],
      "final_output": {
        "status": "success",
        "fixed_issues": ["auth.py#47", "db.py#23"],
        "skipped": ["api.py — 遵照 handoff 约束，未修改"],
        "follow_up": "建议运行 tests/db_integration/ 验证修复"
      }
    }
  ],
  "coordination_annotations": {
    "handoff_quality_score": 0.92,
    "goal_drift_detected": false,
    "coverage_map": {
      "auth.py#47": ["agent_fixer"],
      "db.py#23": ["agent_fixer"],
      "api.py": []
    },
    "gap_flags": [],
    "conflict_flags": []
  }
}

这个格式的设计核心是：每个 Agent 的局部轨迹是自洽的，同时整条轨迹在全局层面是可审计的。

---

三、数据构建的两条路径

路径 A：从头合成

难点不在于生成任务，而在于保证「协作必要性」——即任务在结构上必须由多个 Agent 协作才能完成，而不是一个 Agent 独立处理更高效。

保证协作必要性的设计原则：

1. 信息隔离约束：不同 Agent 只能访问任务信息的不同子集（模拟真实的权限隔离或专业分工）；
2. 能力互补约束：某些操作（如代码执行 vs 文档检索）被显式分配给不同 Agent；
3. 时序依赖约束：Agent B 的输入在逻辑上依赖 Agent A 的输出，而非可并行。

合成流水线：用 LLM 生成任务骨架 → 注入上述约束 → 用规则引擎验证协作必要性（检查：去掉任一 Agent 后任务是否仍可完成？若是，则协作必要性不足）。

路径 B：从现有单 Agent 系统改造

大量公司已有真实 Agent 运行日志，但都是单 Agent 格式。把这些日志拆分重构为多 Agent 轨迹，是获取真实场景数据的最快路径。

拆分策略：

1. 按工具类型拆分：将同一轨迹中不同类型的工具调用（如搜索 vs 代码执行 vs 文件操作）归属给虚拟的不同 Agent；
2. 按阶段拆分：将长轨迹按「分析 → 规划 → 执行 → 验证」等阶段拆分为多个 Agent 的串行协作；
3. 注入故障：在拆分后的 handoff 节点人工或自动截断 handoff_summary，制造信息不对称的负样本。

---

四、与现有工作的关系

Anthropic Multi-Agent 与 OpenAI Swarm 的局限

这两个框架都专注于运行时协作机制的设计（如何调度、如何路由），但对训练数据几乎没有涉及。更关键的是，它们都假设每个子 Agent 已经具备良好的协调能力——但这个能力从哪里来？

两个框架都没有处理协调失败数据问题。它们的 Agent 仍然是用单 Agent 数据训练出来的，然后被「组合」到多 Agent 场景中。这就像把只接受单人训练的运动员组成一支团队，然后期望他们自然会打配合。

MARL 与 LLM Multi-Agent 数据的本质差异

多智能体强化学习（MARL）的数据是稀疏奖励信号驱动的行为序列，Agent 通过大量试错在博弈环境中隐式学习协作策略。LLM 多 Agent 的数据则需要是语言可解释的协作过程——因为我们不仅要让模型学会协作，还要让它能理解并表达协作意图。

这个差异是本质性的：MARL 中「协调」是涌现出来的，在 LLM 场景中「协调」需要被显式编码进训练数据。这也是为什么直接将 MARL 的思路迁移过来行不通。

---

五、为什么「格式先于数据」

在实际执行中，数据构建的冲动往往先于格式设计：先收集数据，再想怎么用。这在单 Agent 场景里勉强可行，但在多 Agent 场景里会带来灾难性的路径依赖。

格式定义了「什么是好的协作」。如果没有 handoff_summary 的标准，你就无法判断一次 handoff 是否成功；如果没有 global_goal 字段，你就无法检测目标漂移；如果没有 coordination_annotations，你就无法在数据层面区分协调成功和失败的轨迹。

数据格式是研究社区的公共语言。当前 LLM 多 Agent 领域缺乏的不是研究兴趣，而是一套被广泛接受的轨迹格式标准，使得不同机构构建的数据可以互操作、可以被统一评估。

这就是为什么本文的核心贡献不是「我们构建了多少数据」，而是「我们提出了一套能够捕获协调失败的数据格式」。格式设计是可复用的基础设施，数据构建是在这套基础设施上的一次具体实例化。

---

结语

协调失败是多 Agent 系统最难被发现、也最难被修复的问题——因为它不发生在任何单个 Agent 内部，而发生在 Agent 之间的缝隙里。解决它需要专门设计的训练数据，而设计训练数据的前提是定义清楚「协调」到底长什么样。

本文提出的三失败模式框架、轨迹格式设计和双路径数据构建方案，是朝这个方向迈出的第一步。接下来的工作是：实现自动化数据构建流水线，在具体任务域（代码协作、信息检索、内容生成）上验证数据质量，并开展消融实验，验证这些数据对多 Agent 协调能力的提升是否可量化。

---

[WIP — 本文为研究提案初稿，欢迎讨论与反馈]