我不需要几百个 Codex agent：我要的是能看懂、能审查的改动
把活交给 Codex，最舒服的永远是刚开头那几分钟。你丢给它一个需求，它刷刷刷地改文件、跑命令，你坐在旁边看着，感觉自己一个人就顶了一支团队。
可一旦这个「活」开始变大，另一种焦虑就会冒出来：它到底改了什么？为什么这么改？测试到底跑过没有？
Rafael Pierre 是 Lighthouse AI 的工程师，长期做架构、逆向和实验。他给出的判断和主流的「堆 agent」叙事正好相反：我不需要几百个 Codex agent，我需要的是能看懂、能审查的改动。
把历史留在 GitHub#
一个人写项目的时候，开 issue、提 PR 看起来像多余的行政手续。没有同事在等你的解释，你自己也知道想做什么。
但几周后回来看，你会想理解一个实现背后的约束，而不是去翻当初那段几十万 token 的对话。一条 commit message 能解释一个决定，但只有 issue 和 PR 才能完整保留这个决定是怎么演化出来的：原始需求是什么、考虑过哪些方案、review 时提了什么反馈、后来又改了哪些。
这份历史，在你需要回头改实现、或者追查一个 bug 是怎么溜进去的时候，会格外有用。它也让 agent 之间切换变得更顺滑：你可以把 issue 和 PR 直接丢给 Claude Code、Copilot、Hermes 接着干，而不是从旧对话里重新拼凑上下文。
给 Codex 一个能验收的需求#
也许不算秘密了，但 agentic engineering 的成功率，跟你描述工作的方式直接挂钩。
一个「改进 onboarding」这样的标题，够提醒你自己有个想法，却给 Codex 留下了太多推断空间。它可能为了消歧，对整个仓库做一次全面分析，烧掉一大笔 token；也可能干脆瞎猜，然后惨败。最糟的是两种错一起犯。
作者的办法是把话说全：问题是什么、为什么必须解决、现在表现如何、期望的行为是什么、有哪些约束、结果该怎么验证。Codex 再把这些整理成一个 GitHub issue，对照 backlog 补上合适的 label 和优先级。
他举了一个自己项目的例子：一个聊天前端，突发的事件流偶尔会把健康的响应掐断。这里的需求不止「修好报错」，还包含三条验收标准：正常突发要能完整跑完、卡住的客户端要有受控清理、队列必须保持有界。这些标准给了 Codex 一个具体的靶子，也给了你自己一把衡量实现的尺子。
把仓库规则写进 AGENTS.md#
源码本身不会可靠地告诉你：一个新的后端服务该放在哪、哪些模块必须保持独立、一个改动 ready 之前要过哪些检查。
作者把这些写进 AGENTS.md，覆盖两部分：项目的架构，以及贡献它的流程。于是 prompt 可以聚焦在具体的改动上，剩下的让 Codex 自己按规则去 scope 和跟踪成 issue。
这些规则包括架构边界、隔离的实现方式、验证和 review 要求。它还确立了一个默认的一比一比一：一个 issue、一个分支、一个 PR，并行工作要显式协调。写下来之后，每当有反复出现的错误暴露了规则里的空缺，他就能回去补。
大改动还应该顺带更新它影响到的文档，无论是 AGENTS.md、README、架构笔记还是开发说明。过期的文档误导下一个 agent 的能力，跟误导你自己一样强。把这些更新放进同一个 PR，代码和它的解释就能一起被 review。
两层检查，别只信 agent 的自述#
review PR 的时候，作者布了两层检查。
第一层是经典的工程最佳实践，没什么花活。他的项目大多是 monorepo，Python 加 Vite/React，测试、lint、格式化一应俱全。本地用 Prek 做 pre-commit hook，GitHub CI 再把一部分检查重复跑一遍。本地反馈快，CI 则挂在 PR 上、充当合并门槛。在 GitHub 上跑这些检查，意味着你可以直接看结果，而不必依赖 agent 自述「我到底跑了哪些命令」。
第二层轮到 Codex 自己上场。他让 Codex 在实现过程中就跑检查，这样失败能在相关代码还在手边的时候被当场修掉。PR 把 diff 和检查结果聚到一起，哪些 ready 了、哪些还要补，一目了然。合并的硬门槛是：CI 必须过，Codex 必须 review 当前这个 PR 的 commit，任何一次新 push 都要重新 review。
并行只开到你能 review 的量#
他把并行工作限制在自己能「带着足够注意力读完、理解它们怎么咬合」的数量上。
Git worktree 让这件事在机械层面变轻松：每个任务一个隔离的 checkout，省去了切分支、stash、干扰主目录的麻烦。而且 worktree 在 ChatGPT 桌面端和移动端的支持，目前比 Codex CLI 更好，这也促使他把越来越多的工作流从 CLI 挪走。
他不觉得为自己的项目同时开几百个 agent 有多大价值。大批量、需求清晰、验证可靠、彼此独立的活，也许适合那种打法。可他的工作常涉及共享的抽象、变化的需求、以及一个决定牵动好几个特性的情况。agent 一多，往往留下一堆 PR 排队等 review，多到他根本看不过来。两个 agent 还可能各自 merge 得干干净净，却引入互相打架的抽象，或者彼此矛盾的前提假设。
每份实现他都得读进去一点，才能认出这些差异，再决定怎么收口。启动多少工作，取决于任务依赖，更取决于他自己 review 代码的容量。让这个量保持可控，他才有时间从实现里学东西。Codex 有时会提出一个他从没想过的方案，review 的过程帮他判断它到底该不该进项目。即便最后否决了，把理由想清楚本身也在加深他对代码的理解。要是改动多到把他逼成「没读完就批准」，这些收益就全没了。
随处都能 review#
任务历史和检查都在 GitHub 之后，他就能在终端之外监督更多工作。Codex 最近被并进了 ChatGPT 桌面端和移动端，跟 Claude Code、Claude 应用的做法类似。他可以发起一个任务，之后从别处查看它的 PR、CI 结果、review 评论和文档，再引导进度。只有当改动需要架构决策、或者开始跑偏的时候，他才亲自介入。
对定义清晰的活，issue 和仓库规则往往已经给了 Codex 足够的上下文，让它自己跑到一个有用的 review 点。
我的看法#
这篇文章最戳我的，是它点破了 AI 编程时代一个被忽略的瓶颈转移：agent 把「生产代码」的成本压到极低，却没有同步压低「审查代码」的成本。因为审查必须由人真正读懂，这个成本下不来。于是瓶颈从「写」悄悄挪到了「读」。
作者这套工作流，本质是把「人治」换成「机制治」：用 issue、PR、CI 这些几十年的老工具，给 AI 的输出套上一层可追溯、可审查的骨架。它不依赖任何一个 agent 的私有特性，所以跨工具通用，Codex、Claude Code、Copilot、Hermes 都能接着用。这一点很聪明，因为它赌的是流程，而不是某个模型的短期能力。
还有一条值得单独拎出来：把「可验收」提前到需求阶段。含糊的 prompt 从来不是省事，它只是把成本推迟，改由后面的 token 和返工来偿还。写清楚「问题、原因、现状、期望、约束、验证方式」这六件事，成本在当下，收益贯穿整个任务生命周期。
当然也要提醒一句：这套东西是有开销的。对一次性小脚本、或者玩票性质的实验，issue 加 PR 加 CI 加双 review 的仪式感，可能重到不值得。它真正适合的是「会持续维护、需要你长期理解」的项目。判断标准也很简单：一个月后的你，还想不想搞清楚这段代码当初为什么长这样？想，就按这套来。
写在最后#
当 agent 越来越强，真正的稀缺资源不再是算力，而是「能读懂、能拍板的人」。把历史留在 GitHub、把规则写进 AGENTS.md、把并行压到自己 review 得过来的范围，说到底都是在保护这份稀缺资源。
作者在文末抛了两个问题，值得每个用 AI 写代码的人想想：你的项目现在是怎么处理的？你愿意让 coding assistant 一路把什么做到收尾，又在哪里亲自踩刹车？