Appearance
Codex Plan Mode 与 Subagents：复杂任务怎么拆
当任务同时涉及多个模块、外部接口和测试时，直接让 Codex“全部完成”通常会让上下文变长，也更难定位错误。更稳定的做法是先让 Codex 建立计划，再把互相独立的工作拆给不同的 Subagent，最后由主任务统一审查和验证。
Plan Mode 解决什么问题
Plan Mode 适合在修改代码前回答三个问题：目标是什么、需要改哪些文件、怎样证明改对了。它尤其适合数据库迁移、跨模块重构、接入第三方 API 和影响面不明确的 bug。
可以这样开始：
请先只分析当前仓库，不修改文件。阅读相关代码和测试，给出实现计划、风险、需要确认的假设，以及完成后要运行的验证命令。
拿到计划后，检查它是否包含入口文件、数据流、失败路径和测试位置。计划没有提到验证命令时，先补充验证要求，再进入实现阶段。
什么时候使用 Subagents
一个子任务应当有清晰的输入、输出和文件边界。例如：
- 一个 agent 查找现有认证流程并总结调用链。
- 一个 agent 为独立模块补测试。
- 一个 agent 检查文档、迁移说明和示例是否需要同步。
不适合拆分的情况包括：多个任务会同时改同一个核心文件、后一个任务依赖前一个任务尚未确定的接口，或者任务本身只有几行改动。拆分的成本不应超过任务本身的复杂度。
一份可复用的拆分提示词
text
目标：为支付回调增加幂等处理。
请只分析，不修改文件。
范围：src/payment、tests/payment。
请输出：现有调用链、可能的重复请求入口、建议的状态字段、测试用例和风险。
不要假设数据库字段已经存在。主任务收到结果后，应明确采用哪些结论，哪些假设需要自己验证。不要把多个 agent 的输出直接拼成最终实现。
并行任务的边界
并行处理最适合只读调查和互不重叠的文件。若两个任务需要修改同一个文件，优先让一个任务完成修改，另一个任务做审查或测试。合并前检查 git diff，确认没有覆盖掉对方的改动。
每个子任务都应该返回：完成了什么、改了哪些文件、运行了什么命令、还有什么未验证。这个格式能让主任务快速判断结果是否可用。
最后的统一验证
计划和子任务都完成后，主任务仍然要重新检查整体行为：
- 阅读完整 diff，确认接口和命名一致。
- 运行受影响模块的测试，再运行构建或类型检查。
- 检查错误处理、权限、日志和兼容性。
- 用一个最小真实场景手动验证关键路径。
Subagents 可以减少等待时间，但不能替代最终责任。主任务最了解用户目标，也最适合决定哪些建议应该进入代码。
常见误区
一开始就拆成很多 agent
先做任务地图。只有存在独立边界时才拆分，否则会增加上下文同步和合并成本。
让 agent 自己扩大范围
在提示词中写清目录、禁止修改的文件和输出格式。范围越模糊，越容易产生无关改动。
把计划当成事实
计划是基于当前代码的假设。实现前仍需读取真实调用方、锁文件和测试，发现不一致时更新计划。
FAQ
Plan Mode 会自动修改代码吗？
取决于当前产品界面和你发出的指令。要求“只分析、不修改文件”可以明确把计划阶段限制为只读。
Subagents 能共享未提交的修改吗？
取决于运行方式和工作区隔离设置。不要假设它们自动看到彼此的改动；任务结果应通过明确的文件、提交或消息传递。
复杂任务一定要用 Subagents 吗？
不一定。小型改动用一个主任务更快。只有调查、实现或验证之间存在真正独立性时，并行才有价值。