Aklman · Library

14 / 第十四章

编码 Agent · 把每一格拧成最难的用例.

编码是 agent 最难、也最成熟的用例 —— 因为它有一样别的任务没有的东西:测试这种客观的「对不对」信号。这一章用它给全书收口。


到这里,前面每一格你都建过了。这一章把它们拧到一个用例上 —— 编码。编码 agent(Claude Code、Cursor、Codex 是它的产品化)是 agent 最难、也最成熟的场景,因为它有一样大多数 agent 任务没有的东西:一个客观的「对不对」信号。这一章用编码做收口,看这些能力怎么合体。

I

编码最成熟,因为它有客观的成功信号.

编码 agent 之所以最成熟,不是因为模型更懂代码,是因为它有别的任务没有的东西:一个能自己跑、会给出对错的检查。 Claude Code 的核心 best practice 就一句:「给 Claude 一个它能自己跑的检查」—— 测试、build、linter、截图对比。1注 1Anthropic 文档 · Claude Code best practices —— agentic 编码工作流 Explore → Plan → Code → Commit;核心一句「给 Claude 一个它能自己跑的检查」(测试 / build / linter / 截图)让循环自己闭合;写手-审查(reviewer 用干净上下文只看 diff);CLAUDE.md 持久上下文;auto mode / allowlist / sandbox 限权。截至 2026-05。没有检查,「看起来做完了」就是它唯一的信号,你就成了那个验证循环。有了 pass / fail,循环自己闭合:写 → 跑检查 → 读结果 → 改,直到过。SWE-bench 这类基准就是用真实 GitHub issue 加隐藏测试来衡量。2注 2SWE-bench(swebench.com)—— 用真实 GitHub issue + 隐藏测试衡量编码 agent 的基准;测试通过与否是客观的成功信号,这是大多数 agent 任务没有的。 客观信号是编码 agent 的护城河,但它会反过来咬你:agent 会「为了过测试」写出投机取巧的代码(reward hacking)。测试覆盖不到的地方,客观信号也保不了你 —— 这正是还要有审查的原因(第三节)。

II

循环:探索 → 规划 → 写 → 验证.

别让它直接上手写。先探索、再规划、再写、最后验证 —— 这是 Claude Code 沉淀下来的工作流,也正是第二章那个循环加上第五章的「先想后做」。 四个阶段:Explore(只读、理解现有代码,先别改)→ Plan(出一个改哪些文件的计划)→ Code(按计划写、跑测试、修到绿)→ Commit1注 1Anthropic 文档 · Claude Code best practices —— agentic 编码工作流 Explore → Plan → Code → Commit;核心一句「给 Claude 一个它能自己跑的检查」(测试 / build / linter / 截图)让循环自己闭合;写手-审查(reviewer 用干净上下文只看 diff);CLAUDE.md 持久上下文;auto mode / allowlist / sandbox 限权。截至 2026-05。这一路把前面的格子全用上了:第四章的上下文管理(Claude Code 反复强调 context 会满、会让模型变笨 —— 就是 context rot)、第七章的 workspace-only 编辑、第三章失败测试当纠错信号。工具集也就那几样:
CODING_TOOLS = [
    {"name": "read_file", "description": "读一个文件的内容。"},
    {"name": "grep",      "description": "在仓库里按模式搜代码。"},
    {"name": "edit_file", "description": "改一个文件(只许在工作区内,呼应第七章)。"},
    {"name": "run_tests", "description": "跑测试,返回通过/失败与失败详情。"},
]
# 循环就是第二章那个,只换两处:
#   停止条件:从「模型说完成」换成「run_tests 全绿」
#   纠错信号:失败的测试输出喂回去(第三章 is_error / 第五章自我纠错)

编码 agent 的工具集 + 停止条件

规划是有 overhead 的。一行能描述的改动(改个 typo、加条日志)别规划,直接做;规划留给「跨多文件、你不熟那段代码、approach 不确定」的活。1注 1Anthropic 文档 · Claude Code best practices —— agentic 编码工作流 Explore → Plan → Code → Commit;核心一句「给 Claude 一个它能自己跑的检查」(测试 / build / linter / 截图)让循环自己闭合;写手-审查(reviewer 用干净上下文只看 diff);CLAUDE.md 持久上下文;auto mode / allowlist / sandbox 限权。截至 2026-05。另外给它一份简洁的 CLAUDE.md(持久项目上下文),标准是「删了这条它会犯错吗」—— 不会就别写,臃肿的上下文反而让它忽略真正的规则。

III

写手 + 审查:让评判的不是动手的那个.

编码 agent 最实用的多 agent 模式,是一个写、一个审 —— 关键在于审查的那个用干净的上下文,只看 diff,不看产生它的推理。 这正好用上第八章的 handoff 加第四章的子 agent 干净窗口:reviewer 在新上下文里只拿 diff 和标准,「让动手的那个不是给自己打分的那个」,新上下文也不会偏袒它刚写的代码。1注 1Anthropic 文档 · Claude Code best practices —— agentic 编码工作流 Explore → Plan → Code → Commit;核心一句「给 Claude 一个它能自己跑的检查」(测试 / build / linter / 截图)让循环自己闭合;写手-审查(reviewer 用干净上下文只看 diff);CLAUDE.md 持久上下文;auto mode / allowlist / sandbox 限权。截至 2026-05。3注 3Anthropic · 「Building Effective Agents」(2024-12-19)—— 反馈循环、独立的验证 / 审查(让评判的不是动手的那个),以及别为审查者挑出的每条都过度工程。但 Claude Code 也提醒一句反话:专门让它挑毛病,它总能挑出一些,追着每条改会过度工程 —— 只收「影响正确性或需求」的,其余当可选。 然后就接上了下一章:自己手写这套写手-审查,还是用 Claude Code / Cursor / Codex 现成的?编码 agent 的产品化已经很成熟,多数人该用现成的。你从零写它,是为了懂它每一格 —— 不是为了取代 Cursor。 动手 · 用你建的 agent 修一个真 bug:
01

指一个有失败测试的真实小 bug

给 agent 三个工具(read_file / grep / run_tests / edit_file),挑你仓库里一个有失败测试的小 bug,让它探索 → 规划 → 改到测试绿。
02

开一个干净上下文的 reviewer 审 diff

另起一个只看 diff 和需求的 reviewer agent,让它只报「影响正确性」的问题,别追风格。
03

记下它最想投机取巧的那一步

看它在哪一步最想「为过测试」而不是「修根因」—— 那一步就是客观信号保不了你、必须人看或加审查的地方。

编码 agent 强, 不是因为它聪明,是因为测试会告诉它错了。.

Coding agents are strong not because they're smart, but because tests tell them they're wrong..

Aklman Library

讨论

讨论.

评论区初始化中…