子智能体编排：拆分、隔离与汇总

多 Agent 不会自动提高质量。任务强耦合、输入不完整或多人修改同一文件时，并行只会制造冲突和重复上下文。默认从单 Agent 开始，确认有独立工作面后再拆分。

适合拆分的信号

• 两个子任务读取不同模块，可以独立得出结论；
• 实现与只读审查可以使用不同上下文；
• 多个平台验证互不依赖；
• 调研候选方案后可由主 Agent 统一决策；
• 单个任务足够大，且每个子任务都有可测试产物。

不适合拆分：下一步依赖上一结果、多个 Agent 必须频繁协商、或都要编辑同一核心文件。

子任务契约

每次派发至少包含：

目标：
输入与已确认事实：
文件/模块所有权：
允许的工具与权限：
不得做的事：
交付格式：
验收证据：

不要把整段主会话无差别复制给每个子 Agent。给它完成任务所需的最小上下文，并指出来源位置。

三种常用拓扑

1. 调研扇出

多个只读 Agent 分别调查 Provider、工具、安全边界，主 Agent汇总。适合独立信息源，不产生文件冲突。

2. 实现者 + Reviewer

实现者交付 diff 与测试；Reviewer 只读检查任务契约和反例。主 Agent 决定修复哪些问题。

3. 规划者 + 专项执行者

规划者先建立依赖图，再把互不重叠的文件或平台分给执行者。共享文件由单一所有者负责最终合并。

主 Agent 的责任

编排者不能只转发子结果。它需要：

1. 检查每份交付是否引用真实证据；
2. 解决相互矛盾的假设；
3. 验证共享边界和集成测试；
4. 汇总改动，而不是拼接重复文字；
5. 对最终结果和未验证部分负责。

防止冲突

• 明确文件或模块所有权；
• 子 Agent 不撤销其他人的未知改动；
• 共享接口先确定 Schema，再并行实现；
• 使用独立工作树、分支或只读任务隔离；
• 汇总前检查实际 diff，不根据口头报告合并。

练习：双重审阅

选择一个小修改：

1. 主 Agent 写任务契约与基线测试。
2. 实现者只负责指定文件。
3. Reviewer 只读，寻找任务范围、错误路径和测试缺口。
4. 主 Agent复现 Reviewer 的每个阻塞问题。
5. 只由文件所有者修复，再运行集成验证。

若协调成本超过单 Agent 完成时间，记录原因并回退为串行流程。编排是可选择的优化，不是成熟度勋章。

最后一篇将这些概念落到第一个 Cordis 工具插件。