# 验收 · 怎么收 agent 交回的活 · Codex · 多 Agent 的异步编码工作流 **作者** Aklman · **章节** 10 / 12 · **首发** 2026.08 · **语言** 中文为主, 中英双语 **原文** https://library.aklman.com/books/codex/10-review **全书 markdown** https://library.aklman.com/books/codex/llms.md **上一章** https://library.aklman.com/books/codex/09-automate/llms.md **下一章** https://library.aklman.com/books/codex/11-cadence/llms.md > 本章来自 Aklman · Library, 完整免费阅读。允许 AI 摘读、引用、问答; 转载请保留作者署名与原文链接 (CC BY-NC-ND 4.0, https://library.aklman.com/license)。 --- > 多处派活的代价,是每处都有活等你收。扫两眼 diff、看它说「测试过了」、合并 —— 那不是验收,是祈祷。这一章是全书的书眼:验收标准在派活时就写死,交付要带证据;本地 /review 用独立 reviewer 审 diff,应用里一字一行的小修直接行内编辑,要追根因的反馈留评论送回下一轮,侧栏 PR review 再把本地改动与 PR 收到一起;GitHub 上 @codex review 与 automatic reviews 负责自动底审。最后把反复出现的错误沉淀进 AGENTS.md 的 Review guidelines。 多处派活的代价,是每处都有活等你收:编辑器里一份 diff、云端一摞 PR、CI 里一条自动改动、定时任务的一份夜间班报。扫两眼、看它说「测试过了」、合并 —— 那不是验收,是祈祷。这一章是全书的书眼:会派活的人已经太多,能系统性验收 agent 的人还太少。它讲怎么把「看一眼就合」升级成一套真正的收活工作流,并接上《Agent 实战》里评测那一章 —— Codex 是你派活的地方,评测是你确认没被坑的地方。 ### I · 底线:一条能复跑的检查 没有检查的时候,「看起来做完了」是它唯一的停机信号,而你是唯一的验证回路 —— 每个错误都躺在 diff 里,等你亲眼看见。官方最佳实践把这条说得很直:别停在让它改,让它写 / 更新测试、跑该跑的检查、确认结果、审自己 diff 里的 bug 与回归,再由你接受 —— 但它得知道「好」长什么样,这靠你的 prompt 或 AGENTS.md 告诉它。[^1]有了能返回过 / 不过的信号,回路才闭合:它干活、跑检查、修到过为止。 纪律有两条。其一:**验收标准在派活时就写死** —— 第 3 章那个四件套里的「完成标准」,就是为这一刻准备的。其二:**要证据,不要断言**。让它交测试输出、贴跑过的命令和返回,而不是一句「搞定了」;看证据比你亲手重跑一遍快,也是你敢不盯着它的前提。这两条尤其在云端与无人值守(第 8、9 章)时救命 —— 那些活你根本没在场看它跑。 **提示词 · 派活时把验收一起派下去** ```text 这件活的验收标准:<一条可检验的标准>。 做完后跑 <检查命令>,把完整输出贴给我。 没验证过的部分明说「没验证」,不要写「应该可以」。 检查跑不过就修到跑过再交,别把失败的输出藏起来。 最后列出你改过的每个文件和一句为什么。 ``` **示例** ```text 这件活的验收标准:CSV 导出的用例全部通过,已有 JSON 导出测试仍然全绿。 做完后跑 pnpm test -- src/export,把完整输出贴给我。 没验证过的部分明说「没验证」,不要写「应该可以」。 检查跑不过就修到跑过再交,别把失败的输出藏起来。 最后列出你改过的每个文件和一句为什么。 ``` --- ### II · 对着计划审,换个脑子审 检查证明「它能跑」,证明不了「是你要的」。跑得过测试的代码,也可能顺手重构了你没让它动的模块、绕开了你点名的方案。第二层验收要有基线 —— 最现成的基线,是第 3 章计划模式里你批准过的那份计划:把 diff 对着它逐条核,要求都实现了吗、点名的边界情况有测试吗、范围之外的东西动了没有。[^1] 这层审最好换个脑子来。本地 `/review` 起一个**专门 reviewer** 读选定 diff、按优先级报告发现,而且**不改工作区**。[^2]第 6 章的自定义 reviewer 则让模型、推理力度、只读沙箱与 docs MCP 固定下来。应用内要分两类反馈:确定的一字一行小修,直接在 diff 里行内编辑;需要 agent 追原因、补测试的,留行内评论喂回下一轮。侧栏 PR review 把 PR 与本地改动放在同一收活位置,多仓库项目还能一次看齐各仓 diff。[^7] > 一条反向纪律:被派去找碴的 reviewer,几乎总会交出几条碴 —— 哪怕活本身是好的,因为找碴就是它接到的任务。逐条照办会把你推向过度工程。GitHub 上 Codex 的做法值得抄:它只标 P0 和 P1 高优先级问题,把噪音挡在外面。[^3]给你自己的 reviewer 也划同一条线:只报影响正确性和既定要求的,其余当可选建议。这不是把审查放松,是把「找什么」说清楚。 --- ### III · 在 GitHub 上收一批,再把错固化 第 8 章一批 PR 涌回来时,你需要的不是逐个手审,是一道自动底审。在 chatgpt.com/codex 的设置里为仓库开启后,PR 评论里 `@codex review` 就触发一次:Codex 先给个 👀、再像队友一样贴出审查,只标 P0 / P1。[^3]开 Automatic reviews,每个新 PR 都自动过一遍,不用你 @ —— 这正是 OpenAI 自己「审 100% 的 PR」的做法。[^1]而且它跟着你最近的 AGENTS.md 里的 `Review guidelines` 走(第 5 章那段不是摆设);看到问题,一句 `@codex fix the P1 issue` 就让它起云端对话把修复推回分支。[^3] 验收做到第三遍,就该问:哪部分能固化?按约束力从软到硬,有三个台阶。最软是 `AGENTS.md` 的 `Review guidelines`:把「同一个错」写成一条审查规矩,下次自动审时就替你盯着 —— 但它是请求,不是保证(第 5 章那条记忆的边界)。硬一点是第 9 章的 hook:收工前必跑的校验,harness 执行、跳不过。最硬的一格,是把犯过的错写成一条测试:从此那个错不归你拦,归测试拦。 --- ### IV · 一次对了不算数:接上评测 单件活的验收到此闭环。但多处自动化意味着你迟早在重复派同一类活 —— 每周的依赖升级、每个 PR 的安全审、每天的日志巡检。这时候该换单位了:单件问「这次对不对」,批量要问「这类活它多稳」。τ-bench 给这个直觉起了正式的名字:**pass@k** 量「k 次里至少对一次」,是能力上限;**pass^k** 量「k 次全对」,是可靠性。实测扎心:当时最强的 function calling agent 任务成功率不到 50%,retail 域连续 8 次全对的 pass^8 掉到 25% 以下。[^5]跑对一次和次次跑对之间,隔着「你敢不敢把它设成定时任务」的全部距离。 第二个坑在「改进」上。你换了模型、改了 AGENTS.md、加了个 skill,感觉变好了 —— 感觉不算数。评测是实验,实验自带噪音:报成功率要带标准误;比较改动前后,用同一批任务的逐题配对差,而不是两个总分相减;想在 80% 功效下检出 3 个点的差距,大约要 1000 道题。[^6]日常尺度记一条就够:**小样本上的个位数点差,不构成「变好了」的结论** —— 它只构成「再跑几遍」的理由。 落地不用自建 harness。把 Codex 坑过你的每个案例攒下来 —— 十几二十条,每条带上第 I 节那样的可检验标准,就是你的回归集;每次动配置,用 `codex exec` 把这批活重跑一遍、`--output-schema` 拿结构化结果对一对。[^4]这正是《Agent 实战》里 golden set 加回归的家用版,也是两本书真正合流的地方:那本书教你把评测建成产线,这本书把它接到你每天派活的本地、云端与 GitHub —— Codex 是你派活的地方,评测是你确认没被坑的地方。 动手 · 把这章装进你的下一次派活: - 给你最近派出的一件活补一条能复跑的检查,并要它交证据(输出、命令)—— 不收「搞定了」。 - 挑一份你本来打算直接合的 diff,先用 /review 对着计划审一遍,数数它找出几条你没看到的。 - 把 Codex 最近一次坑你的错沉淀掉:进 AGENTS.md 的 Review guidelines、变成一条 hook,或写成一条测试。 > 派活的人已经过剩, > 验收的人还稀缺 ## 引用与参考 01 · OpenAI Codex 文档 · Best practices —— 别停在让它改;让它写 / 更新测试、跑该跑的检查、确认结果、审 diff 里的 bug 与回归,再由你接受 —— 但它得知道「好」长什么样,这靠 prompt 或 AGENTS.md。/review 给几种审法:对基线分支审(PR 式)、审未提交改动、审某个 commit、按自定义指令审。原话:「在 OpenAI,Codex 审 100% 的 PR。」截至 2026-08-05。 (OpenAI · Best practices) 02 · OpenAI Codex 文档 · Code review —— 提交 / 推送前审代码。本地 /review 起一个专门的 reviewer 读选定的 diff、报按优先级排序的发现,不改你的工作区。应用里有 review pane:按 Unstaged / Staged / Commit / Branch / Last turn 看,可按文件 / 按 hunk stage 或 revert,行内评论会作上下文喂回下一轮 Codex。可设 review_model 让审查用不同模型,或设 detached 起独立审查对话。截至 2026-08-05。 (OpenAI · Code review) 03 · OpenAI Codex 文档 · Codex code review in GitHub —— 在 chatgpt.com/codex 的 code-review 设置里为仓库开启后,PR 评论里 @codex review 触发一次审查:Codex 先给 👀、再像队友一样贴一条审查,GitHub 上只标 P0 与 P1 高优先级问题。开 Automatic reviews 则每个新 PR 自动审、无需 @。审查跟随最近的 AGENTS.md 里的「Review guidelines」;可「@codex fix the P1 issue」让它起云端对话推修复。截至 2026-08-05。 (OpenAI · Codex in GitHub) 04 · OpenAI Codex 文档 · Non-interactive mode —— codex exec 非交互跑一次;--json 出 JSONL 事件流,--output-schema 让最终响应符合 JSON Schema,-o 写最终消息到文件;文档场景为脚本与 CI/CD。适合把一批攒下的回归用例重跑、拿结构化结果对比。截至 2026-08-05。 (OpenAI · Non-interactive mode) 05 · Yao et al. · 「τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains」(2024,arXiv:2406.12045)—— 提出 pass^k「度量 agent 行为在多次试验下的可靠性」(k 次全部成功的概率,区别于 pass@k 的至少一次);实测当时最强的 function calling agent(gpt-4o)任务成功率不到 50%,retail 域 pass^8 低于 25%。 (arXiv · τ-bench / pass^k (2406.12045)) 06 · Miller · 「Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations」(Anthropic,2024-11,arXiv:2411.00640)—— 把评测当实验:报成功率要带标准误;比较两个配置,用同一批题上的题级配对差做推断,而不是两个总分相减;动手前先算最小可检测效应(MDE)—— 论文算例:80% 功效下检出 3 个点的差距约需 1000 题。 (arXiv · Adding Error Bars to Evals (2411.00640)) 07 · OpenAI · What's new / ChatGPT release notes —— 合并后的桌面 Codex 支持 diff 内联编辑和侧栏 PR review;多仓库项目随后支持在一次 review 中查看所有仓库的 diff。行内小修可直接改,需要 agent 推理的反馈再作为评论送回下一轮。截至 2026-08-05。 (OpenAI · What's new) --- *验收 · 怎么收 agent 交回的活 · Codex · 多 Agent 的异步编码工作流 · Aklman 著 · CC BY-NC-ND 4.0 · https://library.aklman.com/books/codex/10-review*