小团队如何用 Codex Subagents 分工审查代码

2026年10月4日

你接到一个较大的拉取请求，但团队只有两个人能审查代码。Codex Subagents 可以把阅读工作分成独立线程：一个查正确性风险，一个检查测试，另一个核对文档。大约 30 到 45 分钟后，团队负责人可以拿到附有位置和证据的发现清单，再逐项验证。你需要一个 Git 仓库、Codex 使用权限，以及范围明确的变更。

这是让多个线程并行调查的方法，不是让三个代理同时修改同一个文件。OpenAI 的 Subagents 文档建议先从阅读为主的工作入手，例如探索代码、运行测试、分类问题和总结。每个子代理都会消耗自己的资源，因此并行审查可能比单线程使用更多 token。

准备工作

在 Codex 桌面应用、CLI 或 IDE 扩展中打开仓库。现行文档说明，这些界面支持子代理工作流，但查看线程的方式不同。如果你刚开始使用终端，可先看用 Codex CLI 阅读、修改并验证陌生仓库的指南。

确定要审查的分支、可靠的测试命令和相关文档。先运行 git status，记录尚未提交的改动，再开始分工。

团队还需要统一的缺陷报告格式和严重程度标准。可以写在 AGENTS.md 中，参见在 Codex 中统一团队工作规则的方法。要求具体证据，不能把“看起来危险”当成结论。如果还不清楚代理与聊天机器人的区别，可阅读AI agent 入门文章。

操作步骤

1. 把能够独立回答的问题分开

假设某个拉取请求修改了登录和通知功能，不要让三个子代理都“检查全部内容并直接修复”。应拆成互不依赖的三个问题：

正确性与安全： 登录流程是否跳过权限检查、泄露数据，或错误处理异常情况？
测试与回归： 哪些情况已有测试，哪些没有？现有测试真的能发现可疑问题吗？
文档与外部行为： 变更是否符合 API、框架文档和用户预期？

要求每个线程以相同格式报告：发现、文件及行号、证据、影响和不确定之处。各线程只读不改。主代理等待全部结果后再合并。小改动也许一个 Codex 会话就够了。

2. 用明确请求并行分工

在 Codex 桌面应用、IDE 聊天窗口或交互式 CLI 会话中发送下面的请求。将方括号替换为项目资料：

请使用三个 Codex 子代理，对比[分支或拉取请求]与[基准分支]进行审查。
代理 1 只检查正确性、访问控制和可能影响用户的缺陷。
代理 2 只检查测试缺口及回归风险。可以读取或运行现有测试，但不得修改文件。
代理 3 只将变更代码与[框架或 API]的官方文档核对。如果无法访问文档，请明确说明。
各代理不得修改代码、提交、推送分支，也不得把结果写入同一个文件。
每项发现必须包含文件路径、位置、证据和复查方法。若未发现问题，请说明检查范围及仍未解决的疑问。
等待三个代理全部完成，合并重复发现，按影响排序，并只在验证后提出修改建议。

OpenAI 提供了类似的拉取请求示例，分别让代理检查安全性、测试缺口和可维护性。在 CLI 中，/agent 可用于查看和切换代理线程；桌面应用和 IDE 也能从界面打开各线程。如果一项发现会影响发布决定，不要只读主线程的结论，也要查看原线程的证据。

3. 遵守权限和资源边界

子代理继承主会话的沙箱策略。创建新线程不会赋予主会话没有的权限。分工前先检查当前权限模式与可用工具。如果某个线程只需阅读，请明确写“不得修改”；自定义代理也可配置为只读。

某些操作可能需要批准。在交互式 CLI 中，即使你正在看主线程，也可能看到来自其他线程的批准请求，决定前应先看线程标签。在非交互式流程中，需要新批准的操作可能失败，并把错误反馈给主流程。不要只为让并行工作顺畅就扩大权限。

每个子代理都会消耗资源。拆分过细可能增加成本。未单独配置时，子代理会继承主代理的模型和推理强度。

4. 把结果当作待核实的审查草稿

所有线程结束后，请主代理合并重复发现并指出矛盾。例如，一个代理说没有针对过期会话的测试，另一个却在其他目录找到相关测试。不要选择语气更肯定的一方。打开测试，阅读断言，必要时重新运行，并记录结果。

可以这样要求汇总：

请汇总三个子代理对[拉取请求]的发现。
每项发现需列出影响、文件及行号、代码或测试证据、复查结果，以及谁需要作决定。
只有推断的内容标记为“未经验证”。删除重复发现。
暂不修改代码。最后列出批准前必须手动检查的三个事项。

亲自打开高影响区域的代码，重新运行相关测试，并查看差异。经验证后用 Codex Cloud 提交拉取请求的指南展示了把结果交给审核人前的核对过程。批准与否仍由团队决定。

5. 验证后才安排修改

选择一项已验证的发现，指定修改负责人、能证明问题的测试，以及允许变更的文件范围。如果让 Codex 修复，应把修复阶段与审查阶段分开。每片代码区域只交给一个人或一个线程负责。多个线程在同一工作目录同时修改，容易冲突，也可能让测试读取到不断变化的状态。

修复后运行测试，查看 git diff，并请另一人复查敏感代码。如果测试不稳定，应如实记录为尚未验证。

示例结果

假设一个虚构的拉取请求新增“从新设备登录时发送通知”功能，三个子代理报告：

线程	初步发现	团队验证
正确性与安全	某条执行路径可能在检查账号状态前发送通知。	打开文件，用锁定账号运行测试；问题可复现，批准前需要修复。
测试	似乎没有旧会话过期后的登录测试。	搜索完整测试集；确实没有这一情况，于是补充测试。
文档	通知 API 可能返回临时错误。	核对所用 API 的官方文档；团队确定重试方式并记录限制。

这只是说明性情景，不是 Codex 保证会得到的结果。真正有用的是可复现的问题、有证据的测试缺口，以及仍需团队决定的事项。