第十七章：多代理协作先解决所有权和证据

17.1 拆成多个 Agent 不会自动提高质量

多个 Agent 可以并行研究独立问题，但也会增加上下文同步、结果合并和资源竞争成本。把同一含糊任务发给四个代理，得到四份相似总结，并不等于完成了四倍工作。

更好的拆分是按可独立验收的产物划分：一个代理定位调用路径，一个分析权限，另一个设计故障测试。汇总者负责核对接口和证据，而不是仅把文字拼接起来。若多个代理都要写同一文件，需要额外的所有权或合并策略。

17.2 委派消息是一份小型任务契约

至少说明目标、允许读取或修改的范围、期待产物、验收方式与取消条件。返回结果应包含文件路径、版本或引用、已完成检查以及未决问题。只返回“已经处理好”会把证据问题重新推给汇总者。

本书建议把委派与工具调用一样赋予稳定身份。子代理的开始、完成和失败需要可关联；汇总者取消后，子代理是否仍在执行，也应通过真实运行时状态核实，而不是根据一条旧消息判断。

17.3 父子权限不应隐式扩大

子代理需要哪些工具、工作目录和凭据，应由宿主明确提供。父代理有某项能力，不代表每个子代理都需要同样权限；反过来，子代理更换模型也不应绕过原先的执行边界。

作用域、步骤快照与日志思想在这里继续适用。DeepSeek 的 Agent scope 和 Codex 工具计划提供了阅读相关边界的入口，但本书没有对四套项目的全部多代理机制做行为验证，因此不据此作跨项目安全排名。DeepSeek Harness · agent.ts L96–110 Codex · router.rs L83–97

17.4 合并前核对当前状态

子代理在旧版本读取文件后给出建议，主代理可能已经修改同一位置。汇总时应检查它依据的版本，必要时重新读取或运行测试。工作树隔离可以减少同时写冲突，却不能自动证明两个修改的业务语义相容。

任务表中的完成标记也不是最终成果。若子任务要求生成 EPUB，实际文件是否存在、能否打开、与正文是否一致，都需要独立核查。这个例子和编程任务的测试产物遵循同样原则。

17.5 什么时候保持单代理

任务较小、资源高度共享、上下文难拆或验收依赖完整调用链时，单代理顺序推进可能更有效。先记录瓶颈，再考虑并行：是检索耗时、模型推理耗时，还是执行端资源有限？不清楚瓶颈时增加代理，往往只会增加协调日志。

练习：把“研究四套框架并写一章对比”拆成可合并子任务。参考答案应让每项产物有同一问题模板、固定源码版本和清楚的结论范围，避免各自使用不同名词和版本形成不可比的材料。