Codex Subagents：把复杂任务拆给多个专门助手处理

适用场景

这篇手册适合需要处理大型任务的用户。Subagents 的价值是把复杂任务拆给多个专门助手，让它们并行阅读、分析或探索方案。

OpenAI 官方文档提供了 Codex Subagents 说明。具体可用方式会随产品表面变化，使用时以当前 Codex 界面或 CLI 能力为准。

步骤 1：判断是否需要 subagent

适合使用 subagents：

• 大型代码审查。
• 多模块 bug 定位。
• 多个方案并行探索。
• 多篇文档资料整理。
• 安全、性能、可访问性分角色审查。

不适合：

• 改一个小文案。
• 修一个明确类型错误。
• 修改同一个文件的几个相邻行。
• 需要连续人工交互的 UI 操作。

如果一个人能快速做完，就不要拆。

步骤 2：给每个 subagent 明确角色

不要让多个 subagent 做同一件事。

示例分工：

Subagent A：只检查内容 frontmatter 和 SEO。
Subagent B：只检查路由、sitemap、RSS 和搜索。
Subagent C：只检查 UI 是否符合设计规范。

分工越清楚，最终结果越容易合并。

步骤 3：优先让 subagent 做只读分析

并行写文件容易冲突。大型任务可以先让 subagent 只读。

示例：

请只读分析，不要修改文件。
输出发现的问题、相关文件和建议修复顺序。

主线程再根据分析结果统一改动，风险更低。

步骤 4：如果允许修改，限定文件范围

如果确实要让 subagent 修改文件，必须限定范围。

示例：

你只允许修改 content/manual 下新增文章。
不要修改 src、public 或已有文章 slug。

另一个 subagent 可以负责：

你只允许修改 src/components/manual-sidebar.tsx。
不要修改内容文件。

这样能降低冲突。

步骤 5：主线程负责合并和验证

Subagents 给出结果后，主线程要负责：

• 去重。
• 判断冲突。
• 合并结论。
• 运行验证命令。
• 输出最终变更摘要。

不要把多个 subagent 的结论直接当成最终答案。

常见错误

不要把小任务拆成多个 subagent，协调成本会超过收益。

不要让多个 subagent 同时改同一个文件。

不要忽略最终验证。并行分析结束后仍要 lint、测试或 build。

不要让 subagent 接触不必要的敏感信息。

小结

Subagents 适合大型、可拆分、可并行的任务。最佳实践是明确角色、优先只读、限定文件范围，并由主线程统一合并和验证。