SelfLearn · 技术手记

切换深色模式

04 · 工作流与多 Agent ​

本课交付：依赖图与三种部分失败的合并记录。前置：03 的证据卡；课后完成 L4：合并不是拼接。配套函数验证合并规则，不实现多 Agent 调度。

补充阅读：视频导读中的架构选择——通过研究助手比较 ReAct、Plan-and-Execute、Reflection 与人工审批。

一、场景：这一步要解决什么问题 ​

现在用户要求比较三类方案：每类都要说明触发机制、恢复方式和重复执行风险。三个方向的资料可以分别收集，但最终推荐依赖统一的业务约束。

如果直接创建三个“专家”并让它们同时写结论，得到的可能是三份标准不同的答案。本章先画任务依赖，再决定哪里并行、谁负责合并、哪些状态不能覆盖。

二、目标与方案设计 ​

本章目标：根据任务依赖和上下文边界选择协作方式，理解任务分派、控制权交接、状态合并及恢复的区别。资料核对：2026-09-06。

先决定哪些部分需要灵活性 ​

系统可以把检索查询交给模型选择，把权限检查、结果落盘和发布步骤写成固定程序。不是每一步都需要模型判断。

常见组织方式有顺序串联、按输入路由、独立任务并行、动态分派和带反馈的迭代改进。它们是组合模式，不是必须逐级升级的成熟度阶梯。模式来源。

本案例如何选择 ​

情况教学方案为什么
总结一篇已知文章固定读取、生成、检查流程输入范围清楚
回答问题但不知道证据在哪单 Agent 加搜索与读取工具查询需随结果调整
比较彼此独立的多个技术专题可考虑分派不同研究任务材料可以独立收集
多人同时修改同一篇结论由一个汇总者统一写入减少覆盖与冲突

先画依赖，再决定并行 ​

多个角色并不自动产生多个独立任务。以一份研究报告为例，“写结论”依赖证据收集；让它提前与研究并行，容易得到先定结论再找理由的结果。相反，分别查找方案 A 和方案 B 的官方材料，可以独立进行。

本案例可以组织为：

text
明确比较维度
    ├── 收集方案 A 的证据 ──┐
    ├── 收集方案 B 的证据 ──┼── 统一比较 → 检查矛盾 → 生成报告
    └── 收集方案 C 的证据 ──┘

假设三个独立子任务各耗时 20 秒，分派和汇总共 10 秒：串行约 70 秒，理想并行约 30 秒。这里是解释关键路径的假设计算，不是实测；限流、重试、慢任务和上下文传输都会增加实际时间。并行缩短墙钟时间，也可能增加总 Token 和工具调用。

三种控制关系不要混用 ​

LangChain 文档区分了主 Agent 调用子 Agent、控制权交接及路由等模式。文档中的调用次数依赖具体示例，不能泛化成每个框架的固定开销。多 Agent 官方文档。

关系谁保留主任务控制权结果往哪里去本案例中的位置
子 Agent 作为工具主 Agent返回主 Agent独立研究一种方案
Handoff 交接接手的 Agent 继续处理可继续交接或响应用户从问题分诊转给领域处理者
路由后聚合程序或路由协调者进入统一合并步骤分类后并行研究多个主题

Handoff 不是单纯把子任务丢出去，它还涉及当前对话责任和状态转移；子任务调用通常要求回到原协调者。两者都可以带有模型，也都需要明确终止条件。

多 Agent 带来什么代价 ​

独立上下文有利于并行探索不同方向，但也增加信息传递、重复工作和合并成本。Anthropic 的研究系统经验更支持可独立展开的广度研究；高度依赖共享上下文的任务未必适合拆分。其性能和成本数据是特定系统经验，不能直接当作通用收益。研究系统案例。

三、实现拆解 ​

定义清楚交接契约 ​

以比较三类技术方案为例，可以让三个研究者各自查证，汇总者负责统一比较。一个子任务至少写清：

text
目标：找出方案 A 的故障恢复机制
范围：指定版本的官方文档
输出：结论、来源位置、适用条件、未解决的问题
边界：不修改最终报告，不替其他方案下结论
结束：证据完整或到达约定预算

这是教学分工方案。多个 Agent 使用同一个模型时，可能重复同一种错误，因此“多数同意”不能替代外部证据。

子任务上下文应如何打包 ​

不要默认转发主任务的全部聊天历史。给研究方案 A 的 Agent，通常需要比较目标、版本约束、资料范围和交付格式；并不需要其他任务里的无关偏好和全部原始日志。

建议交付契约增加以下字段：

json
{
  "task_id": "research-A",
  "input_revision": "brief-v2",
  "scope": "方案 A 的故障恢复机制",
  "status": "completed",
  "claims": [{ "text": "待核实的具体判断", "evidence_ids": ["e-17"] }],
  "uncertainties": ["未找到指定版本的容量测试"],
  "artifacts": []
}

这是自定义交接格式。input_revision 能帮助识别任务要求变更前产生的旧结果；status 则区分完成、部分完成和无法继续，不能用非空文本代替。

汇总者要做什么 ​

统一比较维度、识别冲突、追查来源、说明缺失证据。不要只把三个答案拼接起来。对于共享文件或业务记录，优先明确唯一写入者；必须并发修改时，再设计隔离、版本检查与合并流程。

合并结果不是拼接文本 ​

合并者至少处理四类情况：同一结论有重复来源；不同结论引用同一段材料；相反结论其实适用于不同版本；某个子任务只交回部分证据。

可以先把证据按稳定 ID 去重，再按比较维度整理结论。对于相互矛盾的判断，回到原文检查条件。三个 Agent 都引用同一篇文章，只构成一个共同来源，不是三份独立证据。

多 Agent 研究的优势和上下文隔离、并行探索相关；通信不清、重复研究和过度拆分也会削弱收益。Anthropic 研究系统经验。上述交接格式与合并步骤是本专题的设计推导。

失败、取消与重新分派 ​

事件协调者应记录什么下一步建议
一个子任务超时已完成的证据与缺失部分允许部分报告或有限重试
用户更改目标新任务版本及过期结果取消无关工作，重新分配剩余部分
子任务重复执行稳定任务 ID 与执行尝试号合并时去重，不重复写最终文件
多个任务写同一文件文件版本与写入者改为单写入者或隔离后合并

恢复不能简单理解为“从某行代码继续”。例如 LangGraph 的中断恢复可能重新执行所在节点，因此中断前的副作用应幂等，或拆到单独节点。Interrupts 的恢复规则。这属于具体运行时语义，换框架后必须重新核对。

A2A 与 MCP 的分工 ​

A2A 面向 Agent 之间的互操作，支持围绕任务和产物协作；MCP 更侧重应用接入工具与上下文能力。两者可以互补，但并不要求每个多 Agent 程序都跨服务使用协议。A2A 官方介绍。

如果几个工作者都在同一进程里，普通函数调用和清晰状态契约可能足够。只有跨团队、跨运行环境的互操作需求明确时，再评估协议接入成本。协议不会替你决定怎么拆任务或判断结果正确。

手工走一遍部分失败的汇总 ​

假设 A、B 两个研究任务返回证据，C 超时。协调者不要把 C 的空输出解释成“方案 C 没有恢复能力”，而应保留 missing 状态。以下是教学汇总记录：

子任务返回情况汇总者的动作
A来源齐全，任务要求版本为 v2纳入比较，继续检查证据支持关系
B引用了旧任务要求 v1标记待复查，不能直接当作 v2 结果
C超时，没有足够证据标注未完成，按剩余预算决定重试

只有“适用条件一致、来源可查、证据足够”的比较项才能进入最终结论。若用户要求必须完整比较三类方案，应报告尚未完成；若允许阶段性交付，可以给出有明确缺口的部分报告。

当前离线示例没有调度多个 Agent。这里先用手工记录验证交接规则；实现调度器时，再把相同场景写成状态合并测试。不要把已有的单执行器测试当作并发正确性的证明。

四、验证与练习 ​

工程加深：检查点、事件记录与外部效果 ​

检查点保存某个执行时刻的状态；事件记录保存发生过哪些动作；外部系统保存真正的业务效果。三者不是一份数据。LangGraph 区分线程级检查点与跨线程 store；内存保存器也不会自动变成跨进程持久化。持久化文档

以“审批后发布”为教学例子：如果发布成功后进程崩溃，最近的检查点仍可能停留在待发布。恢复时重跑节点，就可能发布第二次。正确方案需要稳定业务操作 ID、下游幂等或结果查询；单纯增加检查点频率不能消除这个窗口。

建议把状态划成“待审批意图、批准版本、已提交操作、已确认结果”。恢复时根据真实操作状态推进，而不是重新向模型询问“你觉得上次发成功了吗”。

并行任务的背压与预算 ​

如果一个父任务可以启动多个子任务，而每个子任务又能无限创建新任务，单个用户请求就可能用尽连接池和调用额度。设置全局并发、单父任务并发、总工具额度和共享截止时间；排队时间也计入任务期限。

把预算分给子任务不等于复制预算。比如父任务只剩 20 次调用，三个子任务不能各自获得 20 次后还声称遵守总上限。可先分配额度，再由协调者按剩余任务回收和调整；失败重试也消耗同一额度。这是本站的调度设计，尚无并发运行器实现。

一组必须手工推演的恢复用例 ​

故障点应检查的不变量
子任务结果已写入，但确认消息丢失重投结果按任务 ID 与尝试号去重
用户更新要求，旧研究随后返回旧 input_revision 不覆盖当前结论
审批通过后更改正文旧批准不能用于新内容
外部写入成功、检查点落盘失败查询幂等结果，不重复产生业务效果
父任务取消、子任务晚到不调度新动作，保留已发生效果的记录

这些用例比“启动了三个 Agent”更能检验编排是否正确；当前单执行器测试不覆盖它们。

练习与参考方向 ​

用同一组研究问题比较单 Agent 与多 Agent，固定数据范围和总预算。记录成功率、耗时、费用、重复检索以及需要人工修正的次数，结果出来后再决定是否采用协作架构。

再加入一个高度串行的问题作为对照。如果并行架构只有在独立研究任务上受益，应按任务类型路由。不要只选最适合多 Agent 的问题来宣布整体升级成功。

五、本章小结 ​

协作架构首先是依赖与所有权设计。能独立收集的资料可以并行，最终判断仍要统一标准；部分失败不能被合并成确定结论。下一章把这些要求转成可重复的验收任务。

六、参考资料 ​

返回 Agent 专题目录。本文场景与推演为原创教学设计，参考写法及资料边界见专题目录。