研究提案

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

当前多 Agent 系统的核心瓶颈不在于单 Agent 能力，而在于协调失败。本文提出一套针对协调失败模式的训练数据构建方案，包括轨迹格式设计、数据构建路径及与现有工作的对比分析。

multi-agent training-data LLM coordination agent-trajectory

多 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 应重点关注的风险点。

🔄 [v2 改进] handoff_summary 质量评分体系

原文提出了「Judge Agent 自动检测」的思路，但缺乏可操作的质量评分标准。引入三维度量化评分：

评分维度定义：

维度含义度量方式
关键信息完整率下游 Agent 需要的信息是否都在摘要里以「下游 Agent 完成任务的成功率」作为代理指标：完整 handoff 组 vs 截断 handoff 组的成功率差
冗余率摘要里不需要的信息比例由 Judge Agent 标注「该信息是否对下游决策有影响」，无影响信息数 / 总信息数
负向约束传递准确率「不要做 X」是否被准确传递给下游枚举所有 negative_constraint 字段，验证下游 Agent 是否遵守

合格 handoff_summary 的准入标准：

  • 关键信息完整率 > 80%
  • 冗余率 < 20%
  • 负向约束传递准确率 > 90%（负向约束是高价值信息，漏传代价最大）

不满足准入标准的 handoff_summary 视为负样本，用于训练模型识别「劣质交接」并触发重新请求完整上下文的行为。

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 后任务是否仍可完成？若是，则协作必要性不足）。

🔄 [v2 改进] 协作必要性量化验证

原文提出了「去掉任一 Agent 后任务是否仍可完成」作为协作必要性的检验标准，但没有定义「有显著优势」的量化门槛，导致筛选标准模糊。以下为可操作的量化验证方案：

单 Agent 对照组实验：

  • 对每个候选任务，先在单 Agent 模式下跑基线（同一个能力全面的 Agent 独立完成）；
  • 再用多 Agent 协作模式运行相同任务；
  • 记录两组的输出质量分（由 Judge 评分，0–10）和完成时间（秒）；

协作收益量化门槛：

收益类型门槛说明
质量提升> 15%多 Agent 输出质量分 / 单 Agent 质量分 - 1 > 0.15
速度提升> 30%单 Agent 完成时间 / 多 Agent 完成时间 - 1 > 0.30

只有满足至少一项门槛的任务，才具备「协作必要性」，可纳入训练数据。

筛选流水线：

  1. 构造 50 个候选任务（跨代码协作、信息检索、内容生成等领域）；
  2. 跑单 Agent 基线，记录质量分和时间；
  3. 按门槛筛选，预期约 60–70% 的候选任务通过（过低说明任务设计问题，过高说明门槛太松）；
  4. 通过筛选的任务进入多 Agent 数据构建流水线。

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

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

拆分策略：

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

🔄 [v2 改进] 从单 Agent 日志改造的具体算法

原文的拆分策略停留在原则层面，缺乏可执行的算法步骤。以下为完整的四步改造算法：

Step 1：按工具类型做语义聚类

工具分类规则（示例）：
  搜索类：web_search, read_doc, query_db, list_files
  分析类：run_code, calculate, compare, evaluate
  生成类：write_file, edit_file, send_message, create_summary

实现：对单 Agent 轨迹中每个 tool_call，打上类别标签（搜索/分析/生成）

Step 2：识别自然的「阶段边界」

边界定义：相邻两步的工具类别不同（即工具切换点）
  示例：step_3=搜索类，step_4=分析类 → 在 step_3/4 之间存在阶段边界

注意：连续同类工具调用不切分（避免过度碎片化）
过滤：单段工具序列长度 < 2 的边界不采用（太短的段没有意义）

Step 3：在边界处插入 handoff_summary 生成

在每个识别到的阶段边界处：
  1. 将边界前的完整轨迹（含工具返回值）送入 LLM；
  2. Prompt：「请总结以上操作步骤中，对后续任务最重要的 3–5 项关键信息，
             特别注意：负向约束（不能做什么）和未解决的不确定性」；
  3. LLM 输出即为 handoff_summary 初稿；
  4. 人工抽样 10–20% 进行质量复核。

Step 4：注入故障生成负样本

对 Step 3 生成的 handoff_summary，执行以下故障注入（随机选择）：
  - 截断注入：保留 handoff_summary 前 50%，丢弃后 50%（模拟上游 Agent 草率交接）
  - 关键信息删除：识别 critical_findings 字段，随机删除其中 1–2 项
  - 负向约束翻转：将 negative_constraint 中的限制条件改为允许（模拟理解错误）

每条正样本对应 1–2 条负样本，保持正负比约 1:1.5。

四、与现有工作的关系

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 领域缺乏的不是研究兴趣，而是一套被广泛接受的轨迹格式标准，使得不同机构构建的数据可以互操作、可以被统一评估。

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

六、评估闭环（v2 新增）

🔄 [v2 改进] 多 Agent 协调评估闭环设计

原文结语提及「开展消融实验，验证数据对多 Agent 协调能力的提升是否可量化」，但没有给出具体的评测集构造和对比实验设计。以下为完整方案：

多 Agent 协调评测集构造

按三类协调失败场景均匀构造，共 90 条：

失败类型数量构造方式核心检验点
信息不对称30 条截断 handoff_summary 至完整版的 50%下游 Agent 是否能检测并请求补全
目标漂移30 条在任务链第 3 步注入与全局目标冲突的局部优化末端 Agent 是否检测到偏离并纠正
责任边界模糊30 条构造间隙型/重叠型场景，不在任何 Agent 的角色描述中明确责任任务是否被遗漏或重复执行

核心评估指标

指标计算方式目标值
协调成功率90 条测试用例中最终输出符合 global_goal 的比例≥ 75%
handoff 质量分Judge Agent 对每个 handoff_summary 评分（完整率/冗余率/负向约束准确率综合）均值 ≥ 0.80
目标漂移检测率目标漂移组中 Agent 主动触发 goal_alignment_check 的比例≥ 70%

对比实验设计：验证协调数据的独立贡献

关键对照：单 Agent 能力不变，只改变协调训练数据。

实验设置：

  • 基线组（Base）：用标准单 Agent SFT 数据训练，然后直接组合成多 Agent 系统；
  • 实验组（+Coord）：在相同基础上，额外加入本文构建的协调失败数据进行 SFT；
  • 两组模型的单 Agent 能力（代码、搜索、分析）保持等同，仅 SFT 数据的协调部分有差异；

预期结论：若实验组在协调成功率上显著高于基线组（期望差异 >20pp），则可证明协调训练数据对多 Agent 系统的贡献是可量化且独立于单 Agent 能力的。

消融变量建议：

  • 仅加信息不对称数据 vs 仅加目标漂移数据 vs 全部三类数据 → 分析哪类失败数据贡献最大；
  • handoff_summary 质量评分准入门槛放宽至 60% vs 80% → 验证数据质量过滤的必要性。

结语

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

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

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

原始版本：multi-agent-coordination-training-data