一句话先讲透：Subagents 的价值不是更多分身，而是更好的分工
真正拉开效率差距的，往往不是单个 agent 写得多快，而是你有没有把复杂任务拆成“主线程 + sidecar”的结构。 关键判断、架构决策、下一步阻塞问题仍然留在主线程； 只读摸底、范围明确的小 patch、并行验证这类工作才适合分给 subagents。
这页最值得记住的 3 句
- • 先拆任务，再开分身。
- • 一个 subagent 只做一件事。
- • 要结果，不要作文。
适合谁看
适合已经在用 Codex、Claude Code 或其他 coding agent 的人，尤其是正在处理多文件修改、测试补全、回归验证与复杂需求澄清的人。
先拆任务，再开分身
先判断什么能并行，什么必须留在主线程，不要一上来就把关键判断外包出去。
- 读多写少的上下文摸底：例如梳理旧逻辑、查相邻模块、比对调用链。
- 范围明确的小 patch：例如只补一组错误处理、只修一类权限重复判断、只补三条测试。
- 与主线程并行的验证任务：例如回归检查、只读 review、补充测试、变更影响扫描。
- 会阻塞下一步的关键判断：比如数据库 schema、接口边界、核心抽象是否成立。
- 需要最终拍板的技术选择：是否保旧接口、是否接受风险、是否缩 scope。
- 仍然模糊的大目标：像“把登录系统都搞定”这种话，更像模糊委派，不是 delegation。
核心判断： 如果你马上就要根据这个问题决定下一步，那它通常属于主线程； 如果它可以在你继续推进主线时同步补齐材料，它就更像 sidecar 工作。
一 agent 一职责，边界越窄越稳
Subagent 最需要的不是宏大目标，而是明确的文件边界、约束条件与交付格式。
不推荐的写法
“你去把登录系统都搞定。”
这不是 delegation，而是把范围、判断和责任一次性丢给 agent，最后你只会得到一大块难以验收的改动结果。
更稳的写法
- • 你只负责 auth controller 的错误处理。
- • 你只检查 billing 模块里有没有重复权限校验。
- • 你只补 POST /projects 的三条测试。
Subagent 委派模板（可直接改） 目标： - 只完成 [具体子任务] 可读 / 可改： - 相关文件：[文件或目录] - 禁改范围：[文件或目录] 约束： - 不要增加 scope - 如果遇到会阻塞下一步的关键判断，立即返回主线程 - 你不是一个人在代码库里，不要覆盖别人可能正在修改的内容 交付： 1. 改了哪些文件 2. 为什么这样改 3. 跑了什么验证 4. 还剩什么风险
给足上下文，但别喂成一锅粥
Subagent 不是读得越多越准，而是越知道自己只该看哪一块越准。
任务目标
要它解决什么问题，产出是什么，不要只给一个宽泛方向。
相关文件
只给与当前子任务直接相关的模块、配置、测试或参考实现。
约束条件
哪些文件能改、哪些不能改、哪些接口必须兼容、哪些规则不能越界。
验收标准
需要跑什么测试、什么结果算完成、还要标出哪些剩余风险。
常见误区： 一紧张就把半个仓库背景全塞进去，看似“给足上下文”，结果反而让 subagent 不知道重点在哪里。真正高价值的是“相关”而不是“更多”。
主线程守关键路径，subagents 去做 sidecar
并行的价值，是让你主线写完时，侧面的材料也已经补齐，而不是让主线程变成等待线程。
关键路径
继续推进主流程实现，保留关键判断、接口选择和最终范围控制。
上下文摸底
梳理旧代码、相邻模块、调用链或历史行为，给主线程补“看清楚再改”的材料。
测试与验证
补测试、做只读 review、扫回归点，让主线完成时同步拿到质量保障。
主线程 + sidecar 的一个常见分工 主线程：先改主流程 / 核心逻辑 Subagent A：摸清旧代码与相邻模块 Subagent B：补当前变更需要的测试 Subagent C：做只读 review 或回归检查 目标不是“把思考全部外包”， 而是让主线程不被摸底、补测、回归这些侧面工作反复打断。
要结果，不要作文
Subagent 回来的最好不是长报告，而是可以直接被主线程消费的交付物。
建议固定回收格式
- • 改了哪些文件
- • 为什么这样改
- • 跑了什么测试或验证
- • 还剩什么风险没有处理
为什么要这么做
如果回收结果只是一篇长报告，却没有 diff、没有结论、没有下一步，你只是把执行成本换成了新的阅读成本。
结果回收模板（可直接贴给 subagent） 请按下面格式交付，不要写成长报告： - 文件：改了哪些文件 / 没改哪些但检查过 - 原因：为什么这样改 - 验证：跑了什么测试 / review / 回归检查 - 风险：还剩什么没处理，需要主线程做什么判断
最后的一句自检
区别会不会用 subagents 的人，不在于开了几个窗口，而在于有没有把大任务改写成几件可以并行的小事。
如果你想让 Codex 干得更快， 先问自己一句：这件事，能不能拆给两个分身同时做？
真正的并行，不是把关键判断全部外包出去，而是把摸底、补测、验证这些辅助性工作拆出去， 让主线程继续推进最贵、最难、最依赖你判断的那一段关键路径。
可直接点击的相关入口
参考资料
这页聚焦复杂编码任务中的并行委派规则，并保留最小必要来源，便于继续查看原始讨论。