交接问题：为什么多智能体系统在边界处会失效

Source: Dev.to

当一个 AI 代理完成工作并将其交给下一个代理时，每一步决策背后的推理都会丢失。
接收代理只能看到输出——一个文件、一个结果、一个已转换的数据片段——却毫不知情：

• 试过并被放弃的方案
• 当时的约束条件
• 已经处理过的边缘情况

这就是交接问题，它导致的多代理系统失败比任何模型限制或工具漏洞都要多。

实际交接时会发生什么

想象一个由 3 位代理组成的流水线：Researcher → Analyst → Writer。

• Researcher 找到 40 个来源，筛选出 8 个，因只有它自己知道的原因丢弃了 32 个。
• Analyst 收到这 8 个，构建模型，标记 2 个异常值为可疑——但没有说明原因。
• Writer 获得分析结果并写出与 Researcher 已经检查的内容相矛盾的结论。

Writer 并没有错；只是它不知道 Researcher 所了解的内容。结果是最终输出中包含了看不见的 bug——同一决策在不同方向上被重复做出，却没有人意识到冲突。

修复方案：在每次交接中加入 decisions.json

向每个代理交接包添加一个文件：

{
  "task": "source_research",
  "completed_at": "2026-03-08T04:30:00Z",
  "decisions": [
    {
      "choice": "excluded_arxiv_papers_pre_2023",
      "reason": "outdated model architectures — not relevant to current tooling"
    },
    {
      "choice": "flagged_source_7_as_low_confidence",
      "reason": "single-author blog, no citations, contradicts 3 peer-reviewed sources"
    }
  ],
  "constraints_applied": [
    "max_sources: 10",
    "recency_cutoff: 18_months"
  ],
  "what_was_not_tried": [
    "patent_database_search — not in scope per task brief"
  ]
}

此文件随工作一起传递。每个下游代理在开始之前都会读取它。

为什么这样有效

• 阻止冗余决策。 分析员不会重新评估研究员已经确定的内容；它是在已有推理的基础上构建，而不仅仅是输出。
• 提前发现约束冲突。 如果写手的任务要求引用2023年前的论文，而研究员将其排除，则冲突会立即显现——而不是在最终输出草稿完成后才发现。
• 创建审计追踪。 当出现问题时，你拥有每个决策点的记录，而不仅仅是最终状态。

最小实现

三个简单规则：

1. 每个代理在交接前都要写一个 decisions.json — 即使它只是 {"decisions": [], "constraints_applied": []}。
2. 每个接收代理首先读取 decisions.json — 在读取任何其他输入之前。
3. 决策是累加的 — 每个代理追加自己的决策，而不是替换文件。

追加模式为您提供了整个流水线中每一次选择的完整血统。

成本

• 每次交接额外写入一次文件。
• 每次代理启动额外读取一次文件。

不这样做的代价：最终输出中出现隐形冲突、无法调试的失败，以及运行 20 分钟的流水线后才发现第 2 步中两个代理相互矛盾的痛苦经历。

规模化时的表现

在 5 个代理、每个平均有 3 次交接的情况下，每次管道运行会累计 15 个决策文件。经过 30 天的每日运行：450 条决策记录。

这是一套用于了解管道何时做出正确或错误判断、代理何时持续出现分歧以及何时违反约束的训练数据集。

decisions.json 模式不仅仅解决协作问题——它还能生成您改进整个系统所需的可观测性数据。

交接检查清单

在任何代理向下游传递工作之前，请确认：

• decisions.json 文件存在且至少包含一个条目
• 已记录任务简报中的所有约束条件
• 已填写“未尝试的内容”部分
• 如果上游已有决策，文件应追加而非覆盖

如果您正在运行多代理系统，并且想要经过实战检验的配置，使这些模式在生产环境中有效，完整库位于 askpatrick.co/library。每晚更新，包含真实部署中的真实模式。