核心问题

一个人 + 多个 AI Agent，最大的优势是并行，最大的坑也是并行—— 任务切不好，Agent 之间互相踩脚，产出合并不了，返工比单干还慢。 这篇记录我们从实战里总结的分工方法。

分片原则

• 按模块域切：每个 Agent 负责一组相关文件/功能，互不重叠（比如：服务层 / CLI 层 / 集成层）。
• 按依赖切：有依赖关系的任务排串行，独立的排并行。先做接口定义，再并行实现。
• 粒度合适：一个 Agent 的任务要在 10-30 分钟内能完成。任务太大拆不动，太小并行开销大于收益。

子代理任务书模板

任务书是并行协作的关键。我们的模板固定五个部分，缺一不可：

目标：一句话说清要交付什么
范围：负责哪些文件/模块（明确排除哪些）
上下文：相关背景、约束、已有哪些约定
输出要求：交付物的具体格式（文件+行号+代码/测试）
验收标准：什么样算完成（能跑测试？能过评审？）

验收：不信任，只验证

Agent 的自述报告不可信。我们坚持「可验证交付物」原则：

• 代码任务：必须能跑通测试，要有真实执行输出
• 审计任务：每个发现必须有文件+行号+复现思路
• 写作任务：必须是完成稿，不是大纲

主代理或人工负责交叉验证——把两个 Agent 的结果互相核对， 比如让审查 Agent 复核开发 Agent 的代码，再让开发 Agent 修复审查发现的问题。 这个「开发-审查」循环是质量的核心。

真实案例：35 bug 审计

把一个 FastAPI 项目切成三片（服务层/CLI/集成层），三个审计 Agent 并行扫描， 主代理人工预扫核心文件。结果：三个 Agent 共报 17 个候选， 人工筛出 7 个可写失败测试的确定性 bug，全部先红后绿验证。 并行把原本需要数天的审计压缩到数小时。

踩过的坑

• 任务书太模糊：「看看有没有问题」= 没有产出。要具体到「报告文件+行号+复现思路」。
• 重复劳动：两个 Agent 扫同一文件，报同一批 bug。分片要明确边界。
• 合并冲突：并行分支改同一文件，合并不了。约定「各 Agent 只碰自己范围的代码」。

结论

多 Agent 协作不是「放出去不管」，而是「拆得清楚、写得明确、验得严格」。 流程到位，并行是加速器；流程缺失，并行是灾难。