复杂任务如何拆解与协作：AI Coding 的多 Agent 工作流
先说结论：你大概率不需要多个 Agent
假设你的前端和后端都在同一个仓库里。你让 Codex 或 Cursor 给订单页面增加 CSV 导出，同时说明权限、审计要求和验证方式。
一个 Agent 完全可以查清调用链，修改前后端，补测试，再把应用跑一遍。对于规模不大、模块耦合较强的项目，这通常就是最简单、也最好的工作方式：上下文是连续的，没有交接，也没有合并成本。
工具内部是否悄悄启动了 Subagent，你通常也不需要操心。真正值得你检查的，还是普通的工程问题：
- 它是否理解了需求？
- 是否改对了代码？
- 测试和真实用户流程是否通过？
- 你能否看懂并复查它的改动？
那为什么还要谈多 Agent？
因为有些任务最终不再是一件连贯的工作，而变成一串半独立的事情：要查两个仓库，要等构建，要改 API、页面和数据库，还要做安全审查。一个 Agent 当然也能做，但它只能大多按顺序推进，同时背着越来越嘈杂的上下文。
只有当多 Agent 能消除某个明确的瓶颈时，它才值得使用。它本身不会凭空增加智能。
一个 Agent 能否在一次连贯闭环中理解、实现并验证任务？
├─ 能 → 继续使用一个 Agent
└─ 不能，或等待时间明显过长
├─ 上下文太多 → 使用聚焦的 Subagent
├─ 独立工作排队 → 并行运行 Worker
├─ 仓库或环境不同 → 使用隔离会话
└─ 需要另一个视角 → 使用 Reviewer Agent这就是全文的中心观点：一个 Agent 是默认方案；多个 Agent 是针对明确瓶颈的优化手段。
多一个 Agent，到底解决了什么？
回到“订单导出”这个需求。成熟一点的产品往往还要处理：
- 页面上的按钮、进度状态和错误提示；
- 使用当前筛选条件、并且经过权限检查的 API；
- 包含操作者和请求 ID 的审计事件；
- 空数据、大数据量、权限和客户端失败测试；
- 足以解释“为什么导出不完整”的日志。
一个要求写得好的 Agent 可以把这些事情全部完成。第一选择仍然应该是让它自己完成。
但如果后端和网页是两个仓库，数据库迁移每次验证要等十五分钟，发布前还需要独立安全审查，情况就变了。一个 Agent 会不停切换上下文和等待；API 与 UI 可以同时推进，Reviewer 也可以在构建运行时先检查契约。
另一个 Agent 通常只提供四种实际帮助：
在第一个 Agent 忙的时候先做另一件事。 这就是并行，但只有工作真的互相独立时才有用。
把嘈杂的探索隔离出去。 Subagent 可以搜索大型仓库、检查日志或比较测试失败，最后只返回带证据的结论，不把整个过程塞进主会话。
在另一套环境里工作。 独立会话或云端 Agent 可以使用不同仓库、分支、依赖或长时间运行的机器，而不干扰主工作区。
作为没有参与实现的 Reviewer。 新的 Agent 可以从安全、测试或产品验收角度阅读最终 Diff。它不一定正确，但至少不会带着作者的全部过程和假设继续往下看。
每增加一个 Agent，也会增加解释任务、同步决策、检查结果和合并代码的工作。如果一个功能二十分钟就能完成，协调成本很容易超过节省的时间。
多个 Agent 怎样合作，才不会把仓库弄乱？
有用的心智模型不是“几个模型在群里聊天”，而是一套很小的交付流程。
需要有一个角色始终看着完整功能。可以叫它编排者、负责人或主 Agent。它负责判断哪些工作能拆开，给每个 Worker 足够的上下文，并承担最后的集成责任。
Worker 拿到的是边界明确的工作。例如，一个实现 API，一个准备数据库迁移，另一个设计针对异常情况的测试。它们不应该各自重新发明产品设计。
还需要一份很小的共享契约，记录所有部分必须一致的决定。订单导出可以先写下这些内容：
路由：GET /api/orders/export
权限：orders:export
审计事件：orders.exported
操作者字段：actor_id、actor_type、request_id
成功规则：响应开始前不要记录“导出成功”
输出：UTF-8 CSV，即使没有数据也要包含表头它不必是正式规范，几行 Markdown 就够了。作用是避免 API Worker、UI Worker 和测试 Worker 对同一个问题给出三种答案。
最后还要有一个集成者，把结果合到一起并验证完整行为。实现可以并行，整体验证仍然必须有人负责。
值得拆分的任务，应该有清楚的“接缝”
不要按文件数量拆。“你改 orders.ts，我改 export.ts”并没有说明谁对什么结果负责。
更好的拆法是按可以单独完成和检查的结果：
P0 看懂现有流程，确定共享契约
P1 实现经过权限检查的导出 API
P2 增加审计事件和数据库迁移
P3 增加页面交互
P4 设计跨模块和安全测试
P5 集成并验证真实用户流程P0 完成后，P1、P2、P3 可以并行；P4 可以提前准备测试场景，但最终执行要等实现完成；P5 仍然串行，因为很多不兼容假设只有在这里才会暴露。
可以用三个问题判断一项工作是否适合交给另一个 Agent：
- 不读完整仓库，它能否推进？
- 它能否返回一个稳定产物，例如 Commit、报告、契约或测试结果？
- 它能否避免和另一个 Worker 反复修改同一批文件？
如果答案是否定的，就先不要拆。例如线上偶发死锁，通常应该先由一个 Agent 集中调查，等证据足够后再拆成更小的实验。五个 Agent 各自给出一个猜想，不叫协作，只是多了一堆不确定性。
给 Worker 一项它能做完的工作
“负责后端”不是一个好的交接。Worker 不知道自己拥有哪些文件、哪些地方不能动，也不知道什么叫完成。
一份好的工作请求可以很短：
实现经过认证的订单导出端点。
请阅读：
- `services/orders/`
- 现有权限中间件
- `docs/orders-export.md`
不要修改前端和审计 Schema。
完成标准：
- 未授权调用返回统一的 403；
- 空结果返回包含表头的 CSV；
- 聚焦测试通过；
- 返回 Commit、执行过的命令、结果、风险和未决问题。最后一行很重要。“完成”必须让下一个人知道改了什么，以及怎样检查过。
如果任务比较长，让每个 Worker 留一份短报告：
# API 交接
- Commit：abc1234
- 修改：导出控制器、服务、测试
- 使用契约：docs/orders-export.md
- 验证：pnpm test orders-export → 12 passed
- 剩余风险：没有覆盖流式响应中客户端断开
- 未决问题：无这比复制整段聊天记录有用得多。Transcript 里有搜索、试错和猜测；交接报告应该只留下结论、证据和未解决的风险。
从需求到合并：一套够用的流程
整个流程不需要很复杂。
1. 先让一个 Agent 看懂完整改动
并行编码之前，先让主 Agent 梳理现有行为：
找出订单筛选路径、权限边界、迁移约定、页面入口和验证命令。
提出最小共享契约，并标出需要人决定的问题。先不要修改文件。这一步看起来比立刻启动三个 Worker 慢，但它能避免三个人各自找到一个不同的“主订单查询”。
2. 只并行已经准备好的部分
路由、权限、事件名称和成功规则确定后，API、持久化和 UI 才适合并行。仓库探索和测试设计也适合并行，因为它们通常输出报告，不会互相覆盖代码。
仍在变化的决策、共享 Schema、冲突处理和最后的端到端验证，最好由一个 Owner 负责。
一个实用规则是：集成前，每个文件只有一个编辑 Owner。 第二个 Agent 可以审查或写测试，但不要让两个人反复重写同一个文件。
3. 按依赖顺序集成，不要按完成时间集成
最先完成的分支不一定最先合并。这个例子里，集成者可以先合并迁移和契约测试，再合并 API，然后根据真实响应调整 UI，最后加入跨模块测试。
遇到 Git 冲突时，先看共享契约，再决定保留哪一行。很多 Merge Conflict，其实是披着 Git 外衣的设计分歧。
4. 让一个新的 Agent 阅读完整 Diff
不要只问 Reviewer 一句“看起来没问题吧”。把验收条件给它，并提出具体问题：
只审查合并后的改动，不要修改文件。
重点检查权限、审计真实性、CSV 注入、大结果处理、
客户端断开和前后端路由一致性。每个问题都指出文件、
违反的要求和最小复现检查。最后仍由人决定哪些问题必须修。两个使用相似模型的 Agent 可能共享同一个盲区，尤其是需求没有写清楚的业务规则。
Codex、Cursor 和 Claude Code 各自适合放在哪里？
先记住工程方法，再看产品名称。契约、Commit 和验证证据都应该尽量保持可移植；工具只负责提供不同的运行方式。
在 Codex 里，主 Agent 可以把“梳理权限路径”“实现迁移”“审查最终 Diff”这类窄任务交给 Subagent，同时继续掌握全局。长时间修改可以使用 Worktree 或独立任务。如果要把流程做成可持久运行的自动化编排，可以把 Codex SDK 当作编排层；官方也提供了 Codex Subagents 和 Worktrees 文档。
在 Cursor 里，Subagents 适合做聚焦探索、测试或不会把主会话塞满的局部实现；需要独立机器、独立分支、并行执行或多仓库时，可以考虑 Cloud Agents。
在 Claude Code 里，可以用自定义 Subagent固化 API Builder、测试设计或安全审查等角色；并行修改同一仓库时使用独立会话和 Worktree。Agent Teams提供共享任务和会话间通信，但官方文档目前仍标记为实验性，因此保留“独立会话 + 分支 + 报告”这条备用路径更稳妥。
你不需要在开始使用这些工具之前，把所有机制都学完。先用一个 Agent；上下文变得嘈杂时再学 Subagent；并行修改开始冲突时再学 Worktree；简单方式确实不够用时，再考虑团队编排。
多 Agent 常见的失败方式
最常见的是拆得太早。如果路由、数据结构和成功规则还在变，所有 Worker 都是在移动的靶子上开发。先停止并行，确定共享决策，再重启受影响的工作包。
第二种是职责重叠。如果所有人都改同一批文件，多 Agent 带来的不是产出，而是合并工作。恢复一个 Owner，让其他 Worker 转做审查或测试。
第三种是交接太弱。“完成了”如果没有 Commit、测试结果和已知风险，集成者就必须重新调查。没有证据，就还不能算完成。
第四种是把 Agent 当成权限边界。Prompt 里写“不要部署”并不能阻止部署。应限制凭证和工具，在宿主支持时使用执行前拦截，并在 GitHub、云平台、数据库和制品仓库真正限制生产权限。
当然，也可能只是更慢。这同样是有价值的反馈：合并工作包，回到一个 Agent。
拆分前问自己五个问题
- 我希望另一个 Agent 消除的瓶颈是什么？
- 哪些决策必须让所有人保持一致？
- 每个 Worker 能否独立返回 Commit 或验证证据？
- Worker 是否会反复修改同一批文件？
- 节省的时间是否真的大于协调和审查成本？
如果这些问题还答不上来，就先不要拆。
多 Agent AI Coding 真正有用，是在任务已经超出“一次干净的执行闭环”之后。它的优势不是几个模型天然比一个模型聪明，而是让独立工作同时发生，让嘈杂上下文彼此隔离，让不同环境互不干扰，并让最终改动得到一次新的审查。
除此之外，一个需求清楚、验证认真、能够从头看到尾的单 Agent，仍然是很好的选择。