多 Agent 编排：先解决交接和恢复，再增加角色

工程学习与设计笔记。示例使用合成场景；适用版本与参考资料见正文。

把一个 Agent 拆成“规划者、专家、审查者”，不一定更可靠。三个角色如果反复转述同一份摘要，错误会在接力中变得更确定。多 Agent 值得采用的前提，是任务确实能拆成多个相对独立的证据来源，并且汇总者能够发现分歧。

以“行为事件关联率下降”为例，输入接入、维表更新、任务运行状态可以并行调查；最后的因果判断却需要统一口径，不能简单投票。

拆任务时同时定义交付物

接入调查关注媒体输入量、字段缺失和版本变化；维表调查关注命中率、更新延迟与键空间；运行调查关注错误、背压和发布记录。任务说明应共享同一事件窗口和关联率定义，分别指定可用工具、截止时间、查询预算、必交证据和停止条件。

Anthropic 的公开工程文章将多 Agent 研究场景中的并行探索作为一种有效模式，同时指出协调和资源消耗问题。这里借鉴的是任务隔离思路，不把其内部评测收益当作其他业务的预期收益。多 Agent 研究系统。

一种紧凑的任务契约如下：

task_id: association-incident/input-check
window: [2026-11-06T09:00:00Z, 2026-11-06T10:00:00Z]
question: 缺失关联键是否集中在特定输入版本
allowed_tools: [query_quality_metrics, read_schema_history]
budget: {queries: 6, deadline_seconds: 90}
deliverable: evidence_bundle_v1
stop_when: 已证实、已证伪或预算耗尽

固定分工已足够时，用普通并发工作流即可。只有调查分支需要根据中间证据动态生成时，再引入模型规划。这样能减少“为了协调而协调”的调用。

交接事实、推断和未决项

交接不能只有一句“我判断是 schema 变更”。至少包含：

{
  "task_id": "association-incident/input-check",
  "status": "completed",
  "facts": [{
    "claim": "演示数据中 v3 的缺键比例高于 v2",
    "evidence_id": "query-demo-18",
    "metric_version": "missing_key_v1",
    "population": "已授权样本"
  }],
  "hypotheses": ["字段映射变更可能影响关联"],
  "unknowns": ["尚未验证实际关联失败样本"],
  "artifacts": ["evidence://incident/input/18"]
}

证据引用指向受权限控制的原始查询与结果快照，摘要只是导航。聚合者需要读取关键证据，验证时间范围、样本覆盖和指标口径。两个 Agent 得出相同结论，也可能来自同一个错误查询，不能按两份独立证据计数。

冲突时先核对定义。例如一个 Agent 按事件时间统计，另一个按接入时间统计；迟到数据足以让两份结果方向相反。保留两个版本并发起定向核查，比让第三个模型选“更可信的一方”更有效。

编排状态也是业务数据

建议持久化任务状态 PENDING → RUNNING → SUCCEEDED / FAILED / TIMED_OUT，以及 attempt、输入哈希、产物位置和租约期限。超时任务重试时沿用逻辑任务 ID，增加 attempt；汇总者只接收满足当前输入版本的有效结果。

在工作节点被重启、消息被重复投递时，任务可能执行不止一次。只读调查通常可以重跑，但创建工单、修改配置等动作需要单独的幂等操作 ID。框架保存 checkpoint，不代表外部 API 自动拥有 exactly-once 语义。LangGraph 文档专门区分重试、幂等键和缺失确认的未知状态。Fault tolerance 。

完成任务：
  校验 task_id、input_hash、attempt 仍有效
  将证据包写入不可变产物位置
  条件更新 RUNNING -> SUCCEEDED，并保存产物哈希
  重复完成通知只返回同一结果

恢复任务：
  找出租约过期且未完成的任务
  判断外部动作是否存在未知结果
  可安全重试则创建新 attempt，否则转核对流程

不要只使用一大段共享聊天记录作为状态。结构化状态便于恢复和校验；原始对话保留给调试。敏感样本应留在授权存储中，以受控引用交接，避免复制到每个 Agent 的上下文。

控制并行度，也控制结论强度

共享查询服务可能成为瓶颈。可以设置全局并发、每个数据源的限额和任务总成本预算，先做便宜的分桶检查，再对异常桶深挖。慢分支可以在截止时间后返回部分证据，但最终报告必须标注未覆盖区域，不能默默把超时当成“无异常”。

衡量多 Agent 是否值得，应该在同一任务集比较单 Agent 与并行方案：正确完成率、关键证据覆盖率、错误断言数、P95 时延和每个成功任务的成本。若只是更快地产出更长答案，而证据更难追踪，复杂度就没有兑现。

多 Agent 的核心不是角色数量，而是让每条支线有明确边界、每次交接可核对、每次失败可恢复。做好这些以后，模型能力的提升才能稳定传递到最终结果。

参考资料

Anthropic：How we built our multi-agent research system ，并行探索及协调经验。
Anthropic：Building effective agents ，固定工作流与动态编排的区别。
LangGraph：Fault tolerance ，重试、超时和幂等边界；本文不依赖特定版本 API。