20｜多Agent：并行的收益与交接的损失
本章目录
本章预备知识
多个Agent不是把一个大脑免费拆成几个。每个子任务要提供信息、拿回证据并整合结果；共享文件还会出现并发覆盖问题。
本章各题列出所需基础。可先完成相应基础课，也可通过自检确认掌握程度。
进入深读前的小检查：把两个可独立分析的模块与同一个必改配置分开，说明哪些可并行、哪些需要交接或串行提交。
术语带虚线时可点击速查。公式中的字母先看定义；不要用猜缩写替代推导。
多Agent不是把一个问题复制给更多模型。它引入独立上下文、并发任务、合并与恢复，也可能放大重复工作和相关错误。[MULTI]
沿着对象与状态理解本章
并行只有在子任务相对独立、交接损失可控时才有收益。下图同时给出变快和变慢的条件；后文DAG不是越碎越好，共享文件或共享假设可能把任务重新串行化。
下方图解的固定输入在“输入与适用条件”中声明。它用于解释本章机制，不与本章其他独立例子的数值暗中接续。
多Agent：可并行的工作，比Agent数量重要
为什么任务拆得更细，有时完成得更慢、更差？
并行能缩短独立子任务的关键路径，却增加委派、重复取证、结果整合和共享状态成本。子Agent拥有独立上下文还会引入交接损失。先找确实能分开的工作，再设计明确交接；简单集中任务往往单Agent更容易做好。
输入与适用条件：固定A6秒、B8秒、集成3秒；第二/三帧仅改变交接成本2→8秒。这是教学算账，不是商业多Agent实测。
1 / 4 · 顺序完成两个独立子任务
窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。
任务A6秒、B8秒、集成3秒，顺序耗时17秒。先假定两项确实独立、都必需。
交接开销=0秒；顺序=17秒默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。
为什么需要
利用真正独立的研究或实现方向，并隔离无关上下文。
怎样实现
按依赖和写入边界分工，交接必要证据，主任务核验整合结果。
可能的代价与误解
重复搜索、同文件覆盖、相关错误和过度委派会提高时间与Token成本。
如何判断是否做对
与单Agent同任务同预算对照，记录集成缺陷和重做次数。
Q077｜子Agent收到什么，主Agent又拿回什么？交接包应包含哪些内容？
核心回答
子Agent通常收到明确任务、必要上下文和自身可用工具配置，不应假设自动拥有主Agent全部历史与权限；返回应包含结论、证据、产物和未决问题。交接是信息选择过程，天然可能有损。[SUBAGENTS]
一份能执行的交接与一份不能执行的交接
“帮我看看数据库问题”太宽泛。更可执行的教学交接是：目标为确认重复退款是否由重试导致；范围为payment模块和调用方；不要修改代码；当前观察是同订单出现两次远端请求；提供相关trace ID；返回可证伪根因、证据路径、未确认点。
返回“是重试导致”仍不足。应说明在哪个版本看到哪个分支、哪条日志显示相同业务ID重复、是否排除了两个独立订单、需要什么测试。主Agent才能基于结果修改，而不必重新完成整个研究。
交接内容不能无限详细，否则多Agent只是复制大上下文。把关键事实与定位引用传入，允许子Agent按需读取；最终返回压缩后的证据摘要与可追溯原始输出。摘要保真问题在多Agent交接中同样存在。
子Agent交回“没问题”，为什么无法安全整合
输入与条件。父任务要修复两个模块。子任务A只返回“测试通过”，没说代码版本、测试命令或修改路径。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1检查缺项 | 无法确定验证覆盖哪个版本 | 父Agent不能直接当作最终证据。 |
| 2改交接对象 | 返回目标、修改文件、版本、测试命令、退出状态与限制 | 每项服务于合并决策。 |
| 3压缩范围 | 只交关键日志片段和完整日志路径 | 不复制所有探索历史。 |
| 4父级整合 | 检查A与B修改是否冲突 | 各自通过并不证明组合通过。 |
| 5最终验证 | 在合并后的版本重新运行必要测试 | 交接完成不等于整体完成。 |
把过程连起来。子Agent输出需要足够支持后续动作，而不是语言上的总结态度。
边界与反例。字段是简洁交接建议，任务很小时可自然语言包含，不强制引入庞大模板。
依据与适用范围：[CLAUDE-SUB]。示例输入和场景由本书明确设定。
追问：把子Agent全文对话回传最安全吗？
保留全文作为可追溯记录有价值，但全部进入主上下文可能淹没任务。主线程需要结论、证据和未决项；必要时再展开全文。原始记录与当前上下文的职责应分开。
追问：子Agent的结论能直接写进长期记忆吗？
应先确认来源与结果。子Agent也会猜测和误读；未经验证的结论直接升级为记忆会传播错误。可以保存为候选经验，待主任务结果和证据支持后激活。
追问：为什么权限要显式核对？
子Agent运行环境、工具集合和审批模式可能不同。没有权限时应报告缺口，而不是假装完成，或改用更高权限绕过。交接包描述任务不能自行授予外部系统权限。
Q078｜任务DAG怎样决定并行？为什么切得越细不一定越快？
核心回答
DAG表示子任务依赖，只有输入已满足且资源不冲突的任务才能安全并行。总时延受关键路径、协调开销与资源竞争影响；拆分增加交接和合并成本，不会自动提高质量。
算一个简单关键路径
任务A定位接口需2单位时间；B修改实现需4；C补测试需3；D集成验证需2。若C依赖B才能知道新契约，则链A→B→C→D共11。若A后已明确契约，B和C可独立并行，则约A2+max(B4,C3)+D2=8，尚未计沟通与冲突。
若每次交接增加1，且B/C修改同一文件导致2单位合并，理论节省3可能被吃光。更糟的是并行任务对契约理解不同，最终需要重做。任务独立性必须来自稳定输入与边界，不是把标题分成几行。
不同子任务共享模型速率限制、工具服务器、数据库和Git工作树。即便逻辑独立，也可能争用资源。调度应有并发上限和取消机制，避免一次用户任务耗尽全部配额。
两条并行任务加合并，关键路径怎样算
输入与条件。任务A耗时3秒，B耗时5秒，彼此独立；合并C耗时2秒，必须等A、B都完成。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1串行 | 3+5+2 | 10秒。 |
| 2并行启动A/B | 开始时刻都为0 | A在3秒结束，B在5秒结束。 |
| 3C开始 | max(3,5)=5 | C在7秒结束，理想墙钟7秒。 |
| 4操作总量 | 仍然3+5+2=10秒 | 并行不把总工作量变成7。 |
| 5加入开销 | 如果交接与重复检索额外4秒落在关键路径 | 变11秒，反比串行慢。 |
把过程连起来。并行收益来自独立工作重叠，协调开销和依赖会吃掉收益。
边界与反例。理想时间线不含资源竞争，真实服务需测排队、并发上限与相关失败。
依据与适用范围：[DERIVE]。示例输入和场景由本书明确设定。
追问：应该先完整规划DAG再开始吗？
依赖清晰的任务可以预先规划；探索性任务应允许边做边调整。过早拆出几十个节点可能基于错误假设，产生无效执行。可以先完成最关键定位，再并行真正独立的部分。
追问：如何避免每个子任务都重复Analysis→Task→Review？
把共用分析与约束集中形成可复用证据，子任务只补局部缺口；按风险选择验证，不机械复制整套流程。小问题可在实现或Review中直接修复，只有改变核心假设或边界时才返回重新设计。
追问：多Agent加速怎样公平计算？
比较相同质量目标下的墙钟时间、总Token、模型调用和工具资源，不能只看最长子任务完成时间。把并行消耗的总成本忽略，会产生“更快且更便宜”的错觉。
Q079｜多个Agent改同一个仓库，怎样避免覆盖与错误合并？
核心回答
隔离工作树或明确写入范围，记录共同基线，对合并后的版本重新验证。Git无冲突只说明文本可以合并，不说明语义正确。
一个没有文本冲突的语义冲突
Agent A把函数返回值从列表改为迭代器，Agent B在调用方增加len(result)。两人修改不同文件，Git可自动合并，但运行时可能失败。共享接口契约比文件边界更重要。并行任务开始前应尽量固定契约，变更契约时通知依赖任务。
工作树隔离避免直接覆盖，但仍要合并。每个子任务保存基线、diff和测试证据；集成时检查基线差异、冲突和相关依赖；合并后运行覆盖交互行为的测试。子任务各自测试通过不等于组合通过。
对同一共享文件的简单编辑，可以串行或用版本条件避免覆盖。无需为每个小任务创建复杂分支体系；关键是明确谁在何时拥有写权限，以及冲突后怎样恢复。
两个Agent都从v7写同一文件，后写入会发生什么
输入与条件。v7文件包含a=1,b=1。Agent A想改a=2，B想改b=2，二者都读了v7。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1A生成完整文件 | a=2,b=1 | 基于v7。 |
| 2B生成完整文件 | a=1,b=2 | 也基于v7。 |
| 3顺序覆盖 | 先写A再写B | 最终a又退回1，A修改丢失。 |
| 4版本检查 | B提交时发现基线不再v7 | 重读并合并，而不是盲写。 |
| 5独立工作树 | 两边各保存diff后明确合并 | 最终应a=2,b=2，并对组合版本测试。 |
把过程连起来。看起来改不同字段也可能因为全文件写入产生丢失更新。
边界与反例。文件的原子替换只能避免半写文件，不会自动解决多个写入者的逻辑合并。
依据与适用范围：[OS]。示例输入和场景由本书明确设定。
追问：为什么不能让主Agent直接相信子Agent的“已测试”？
测试可能针对子分支版本，合并后条件改变。需要证据中的命令、工作目录、版本和结果，并在最终集成版本上补必要验证。口头汇报不是可复用的验证凭证。
追问：自动解决冲突的模型能否直接提交？
冲突解决本身就是新的代码修改，需要检查语义和测试。模型可能选择一边而丢掉另一边功能。高风险冲突可要求人工审查；普通局部冲突则可在同任务内解决并验证，不必无限重新规划。
追问：并行读取是否也有一致性风险？
有。一个Agent读取文件时另一个正在修改，可能得到跨版本证据集合。只读研究也应知道快照范围；关键分析最好基于稳定版本，或在结论使用前重读相关文件。
Q080｜独立Reviewer为什么可能仍犯相同错误？A2A解决了什么，又没解决什么？
核心回答
不同Agent可能共享模型、Prompt、证据和偏见，因此错误相关；多一个Reviewer不等于独立概率保险。跨Agent通信协议可以标准化发现、消息和任务状态，但不会自动解决证据可信度、权限和结论正确性。[MULTI]
让Review提供新信息而不是第二次赞同
如果Reviewer先看到实现者的完整理由，很容易沿同一路径确认。可以让它先从需求、diff和测试独立判断，再看解释；给它不同目标，如检查反例、兼容边界或并发，而不是笼统“看看是否有问题”。独立性来自证据与检验方式，不只是Agent名字不同。
确定性检查往往比再问一个模型更独立：类型检查、性质测试、构建、静态分析或真实运行。模型适合补这些工具难覆盖的设计判断，但也会误报。Review收益要同时测漏检、误报和返工成本。
A2A类协议关注Agent之间的能力发现、消息/任务及产物交换。MCP偏向Host与工具/资源服务的接口，两者抽象层不同。即便通信通了，接收方仍须判断请求身份、任务范围、产物来源和副作用授权；协议不把远端Agent变成可信同事。[A2A]
三个审查Agent同意，为什么不等于三份独立证据
输入与条件。三个Agent都只阅读同一条过期摘要“v8测试通过”，实际上测试只覆盖v7。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1共同输入 | 三者都依赖错误摘要 | 错误来源高度相关。 |
| 2各自输出 | 都判断可以交付 | 多数票只是重复同一错误前提。 |
| 3增加独立证据 | 让验证工具读取实际测试版本或重跑v8 | 产生不同来源的信息。 |
| 4校正结论 | 发现当前版本未测 | 一个确定证据足以否定三个未经核实的意见。 |
| 5A2A通信 | 协议让消息可传输 | 不自动保证交接内容真实或审查独立。 |
把过程连起来。多个角色名不等于独立性；独立输入、方法或外部验证才可能增加新的证据。
边界与反例。不主张完全取消多Agent审查，只要求把额外成本与真实新增证据联系起来。
依据与适用范围：[DERIVE]。示例输入和场景由本书明确设定。
追问：两个模型都说正确，置信度能相乘吗？
只有满足明确独立性和校准假设才可做某些概率组合；实际共享训练和证据时通常不满足。应通过真实任务统计评估联合检出率，不能把两个90%简单算成99%。
追问：Reviewer发现小问题后一定要重新Analysis吗？
不必。清楚、局部、低风险的问题可直接修复并补验证；只有推翻关键设计、涉及权限或跨模块契约时才需要重新分析。流程应围绕问题大小，而不是维护形式完整。
追问：子任务已无价值，怎样取消才可靠？
通知停止、停止调度新调用、处理正在运行的工具，并记录实际已发生副作用。取消不等于回滚；如果子Agent已改文件或发远端请求，主Agent必须知道这些状态。否则“节省成本”的取消可能留下不一致产物。