用一个子 Agent 审核 Codex 的实施计划

最近发现了一个能提升 Codex 写代码稳定性的小技巧：在正式实施之前，让一个子 Agent 先审核主 Agent 的计划。

只需要把下面这段要求发给 Codex：

如果任务需要正式 plan，请先由主 Agent 生成完整计划，再启动且仅启动一个子 Agent 审核计划。审核完成后，由主 Agent 吸收合理意见、更新计划并独立完成实施和验证。

它是怎么工作的？

整个流程可以概括为：

1. 主 Agent 分析需求并生成完整的实施计划。
2. 启动一个子 Agent，专门检查计划中的遗漏、错误假设和潜在风险。
3. 主 Agent 评估审核意见，吸收其中合理的部分并更新计划。
4. 子 Agent 结束工作，后续的编码、测试和验证由主 Agent 独立完成。

这里的关键不是让多个 Agent 同时写代码，而是增加一道“实施前评审”。子 Agent 只负责审查计划，不参与修改文件，因此可以减少多人并行编辑带来的冲突和上下文分散。

为什么可能更稳定？

主 Agent 在制定计划时，可能会遗漏边界条件、测试要求或兼容性风险。让另一个 Agent 从审查者的角度重新阅读计划，通常更容易发现这些问题，例如：

• 需求是否被完整覆盖；
• 是否存在未经验证的假设；
• 有没有可以复用的现有模块；
• 是否遗漏安全、兼容性或数据风险；
• 测试与验收标准是否足够明确。

审核完成后仍由主 Agent 统一实施，也能保持上下文和代码风格的一致性。

什么时候适合使用？

这种方式比较适合：

• 涉及多个文件或模块的功能开发；
• 架构调整、数据迁移或接口改造；
• 需求复杂、边界条件较多的任务；
• 出错成本较高、需要充分验证的修改。

对于改文案、调整一个配置值或修改少量样式之类的简单任务，正式计划和额外审核的成本可能高于收益，可以直接由主 Agent 完成。

更严格的提示词版本

如果希望审核更聚焦，可以使用下面这个版本：

如果任务需要正式 plan，请先由主 Agent 生成完整计划，再启动且仅启动一个子 Agent 审核计划。

子 Agent 只检查以下内容：
1. 需求覆盖是否完整；
2. 是否存在未经验证的假设；
3. 是否遗漏复用机会、架构或兼容性风险；
4. 是否存在安全或数据风险；
5. 是否缺少测试与验收标准。

审核意见最多五条，并标记为“阻塞”“重要”或“可选”。子 Agent 不得修改文件、实施代码、扩大任务范围或继续启动其他子 Agent。

审核完成后，由主 Agent 判断哪些意见合理，更新计划，并独立完成实施和验证。

总结

这个技巧本质上是给 Codex 增加一次轻量的“计划评审”：主 Agent 负责方案和落地，子 Agent 只负责在动手前找问题。

它不能保证代码一定没有错误，但对于复杂任务，通常能让计划覆盖得更完整，也能更早暴露风险。