先理解
刚接触这个知识点
补齐先备概念，读原理与反例，再用自己的话解释为什么。
从核心原理开始 →知识目录选择核心方向与细分内容
理解 → 实现 → 排错 → 取舍
多 Agent 的分工收益与协调成本
考察任务可并行性、协调成本、证据合并和对照实验。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-02
建议先理解：
任务契约与独立验收 →确定流程与局部探索的组合 →这个知识点，你想学到哪一步？
按当前基础选择起点，也可以依次深入。遇到不熟悉的概念，先回到核心原理；完成后用知识练习检查理解。
知识单元目录
LEARN · PRACTICE · REFLECT
知识学习与个人记录
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 多 Agent 的分工收益与协调成本
先理解核心原理
先备概念：并行任务、依赖图、效果评测
多 Agent 的价值来自可以独立展开的推理与上下文，而非名字或数量。只有新增探索收益超过协调、重复调用和合并损耗，拆分才有意义；共享错误来源不会因为多次投票变成独立证据。
工具并行和推理并行不同
一个 Agent 同时查询三个固定接口，已经获得 I/O 并行，不必给每个接口加一个模型。多个子 Agent 更适合分别追查不同证据、形成候选方案或使用独立上下文。若步骤强依赖同一份实时状态，拆分反而增加同步成本。
成本应算到最终可用结果
子任务输出还需要合并和核查，协调者消耗的上下文、冲突处理时间以及重复搜索也算成本。让三个 Agent 用同一提示词读同一网页，通常只是复制路径；换视角必须落实为不同资料范围、反例任务或验证职责。
用对照决定是否拆分
在同一任务集和预算范围比较单 Agent、单 Agent 并行工具与多 Agent。关注最终正确率、证据遗漏、延迟和费用，而非子任务产出数量。Anthropic 的研究系统说明独立探索可能获益，但其内部评测和成本数据不能直接当成我们的收益承诺。
用一个问题检查理解
把单 Agent 改成五个 Agent，效果一定更好吗？怎样证明值得拆分？
先判断子任务是否能独立完成、接口是否能明确定义，以及单 Agent 的失败是否来自上下文或并行能力不足。我会固定任务集和总预算，对比单 Agent、单 Agent 并行工具、多 Agent 三种方案，按验收通过率、尾延迟与每个成功任务成本做选择。拆分只有在收益超过协调和错误传播成本时才成立。
实现与取舍
先定位需要拆分的原因
假设调研任务要覆盖三个互不依赖的市场，可以按市场分工；若是修改同一个数据库事务，多个角色轮流讨论未必带来收益。先给单 Agent 的失败分桶：漏检资料、工具选错、上下文过载、步骤串行。并行工具可能已经能解决等待问题，不必立即引入独立决策者。每增加一个 Agent 都会增加输入构造、结果传递、重试和验收的复杂度。
子任务交付契约
给每个分支明确问题边界、允许工具、截止时间、预算和输出结构。结果包含结论、证据引用、未解决问题和执行状态。协调者不能把一句“研究完成”当合格产物，也不能把同一网页经三个分支转述视为三份独立证据。用原始来源标识去重，并把互相矛盾的结论保留下来进一步核对。
做公平比较
准备覆盖简单查询、独立检索和强依赖写操作的任务集。三种方案使用相同工具权限、质量验收和费用口径，每个任务重复运行。比较成功率、P95 时延、失败类型和总费用除以成功任务数；不能只展示多 Agent 最好的一次。先给各分支分配预算，协调阶段留出余量，避免子任务把全部额度耗尽。
决策与退出条件
如果收益只出现在独立检索类任务，就按任务类型路由，其他任务保持简单执行。灰度中监测分支重复率、协调轮次和引用错误；达到上限时返回部分结果及缺口。资深回答应解释什么时候减少 Agent，以及某个分支失败时是否允许部分交付，而不是用角色名称证明架构先进。
工程推演
- 场景
- 面试假设：行业报告有三个独立调研方向，当前单 Agent 常遗漏其中一个。
- 设计决策
- 对比三种执行结构，为每个分支定义证据格式和预算。
- 验证目标
- 验收关注覆盖完整性、引用正确性和每次成功交付成本。
- 适用边界
- 假设数据需在本团队任务集上测量，不能外推其他产品的提升比例。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层如果单 Agent 并行工具与多 Agent 效果相同，你选哪个？
先证明需要独立推理，避免把 I/O 并行收益误归因给多 Agent。
参考解答
若质量、延迟和成本差异没有实际价值，我选单 Agent 并行工具，减少上下文重复与合并故障。保留清楚的工具结果契约，未来只有遇到独立研究空间或上下文隔离需求再拆分。若多 Agent 唯一优势是故障隔离，也应比较进程或任务队列能否更简单地提供。
第 1 层两个分支用同一来源得出相反结论怎么办？
拆分后最难的是证据合并，来源一致不能保证解释一致。
参考解答
回到同一原文与版本，检查两者引用位置、适用条件和推导步骤。先把“原文事实”与“方案判断”分开：不同时间、对象或前提可使两个结论同时成立；若真正冲突，安排定向核查，不按多数票决定。同源结论不是独立证据，最终报告保留未解决争议。
沿着这个回答继续深入
第 2 层协调者也读不懂原文，增加三个同模型 Agent 投票有效吗？
合并失败引出相关性问题，增加数量不一定增加信息。
参考解答
可能帮助发现思路，但不能把票数当可信度。改为明确争议命题，让一方找支持、一方找反例，再用原始规范、可执行验证或领域审阅裁决；无裁决能力时标记不确定。相同模型、资料和提示带来的错误高度相关。
沿着这个回答继续深入
第 3 层无法取得独立资料，却必须在截止前交付怎么办？
证据无法增强时，需要调整结论范围而不是制造确定性。
参考解答
交付已验证部分，把争议结论写成条件判断，明确证据不足及其影响；高影响动作不基于该结论自动执行。若任务允许探索性建议可提出待验证方案，若要求确定结论则以证据不足结束。截止时间决定停止点，不能提高证据强度。
第 1 层一个分支超时，协调者应该等多久？
子任务并行之后，全局交付仍有依赖和时间约束。
参考解答
使用任务入口的绝对截止时间，并预留协调者合并和核查时间。必要分支缺失时最终结果不能完整成功；可选分支超时则返回已有证据与覆盖缺口。超时后禁止该分支继续产生新动作，迟到只读结果按版本决定能否纳入，不能无限等到全部返回。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
共同修改同一模块
改变的条件：分支从独立研究变为共享可写状态
延伸问题：还能直接并行拆给多个 Agent 吗？
推导与参考解答
先按不重叠文件或明确接口拆分，固定基线，各分支交补丁由单一整合者合并验证。若修改强耦合且频繁相互依赖，改为串行协作更合理。并行编辑速度不等于交付速度，冲突修复和整体测试应纳入对照。
保持不变的原理：拆分需要真实独立性，共享状态的协调成本会吞掉收益。
单个长证明或连续推导
改变的条件：任务几乎不可分解
延伸问题：是否用多个角色分担上下文？
推导与参考解答
保留一个主推导链，可让另一 Agent 针对固定版本检查反例或关键一步。不要按任意段落切断依赖后拼接；审查者的不同职责能提供价值，数量本身不能解决前提丢失。比较检查带来的缺陷发现与额外成本再决定保留。
保持不变的原理：独立验证比复制同一推理更可能增加有效信息。
易错点
- 用角色数量衡量能力
- 以更高预算跑出的效果直接比较
- 把重复来源当交叉验证
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 能结合任务依赖说明可并行边界与新增协调成本。
- 中高级信号
- 提出固定预算、重复运行和失败分桶的对照实验。
- 资深信号
- 能按任务类型设路由、协调预算、部分交付和撤回条件。
动手验证 按需完成 · 建议 15 分钟
画出三分支调研的交付结构；让其中一支超时、一支返回无引用结论，说明最终结果。
展开验收要求与检查点
- 无引用分支不进入已验证结论
- 超时分支有明确终态和缺口
- 全局预算覆盖协调开销
重点检查
- 识别独立任务与共享状态任务
- 给出同预算对照方案
- 定义分支失败和证据合并规则