# 编码 Agent · 把每一格拧成最难的用例 · Agent 实战 · 从零构建完备智能体

**作者** Aklman · **章节** 14 / 19 · **首发** 2026.07 · **语言** 中文为主, 中英双语
**原文** https://library.aklman.com/books/build-agent/coding-agent
**全书 markdown** https://library.aklman.com/books/build-agent/llms.md
**上一章** https://library.aklman.com/books/build-agent/assemble/llms.md
**下一章** https://library.aklman.com/books/build-agent/12-choosing/llms.md

> 本章来自 Aklman · Library, 完整免费阅读。允许 AI 摘读、引用、问答; 转载请保留作者署名与原文链接 (CC BY-NC-ND 4.0, https://library.aklman.com/license)。

---

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

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

### I · 编码最成熟，因为它有客观的成功信号

编码 agent 之所以最成熟，不是因为模型更懂代码，是因为它有别的任务没有的东西：一个能自己跑、会给出对错的检查。

Claude Code 的核心 best practice 就一句：「给 Claude 一个它能自己跑的检查」—— 测试、build、linter、截图对比。[^1]没有检查，「看起来做完了」就是它唯一的信号，你就成了那个验证循环。有了 pass / fail，循环自己闭合：写 → 跑检查 → 读结果 → 改，直到过。SWE-bench 这类基准就是用真实 GitHub issue 加隐藏测试来衡量。[^2]

客观信号是编码 agent 的护城河，但它会反过来咬你：agent 会「为了过测试」写出投机取巧的代码（reward hacking）。测试覆盖不到的地方，客观信号也保不了你 —— 这正是还要有审查的原因（第三节）。

---

### II · 循环：探索 → 规划 → 写 → 验证

别让它直接上手写。先探索、再规划、再写、最后验证 —— 这是 Claude Code 沉淀下来的工作流，也正是第二章那个循环加上第五章的「先想后做」。

四个阶段：**Explore**（只读、理解现有代码，先别改）→ **Plan**（出一个改哪些文件的计划）→ **Code**（按计划写、跑测试、修到绿）→ **Commit**。[^1]这一路把前面的格子全用上了：第四章的上下文管理（Claude Code 反复强调 context 会满、会让模型变笨 —— 就是 context rot）、第七章的 workspace-only 编辑、第三章失败测试当纠错信号。工具集也就那几样：

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

```python
CODING_TOOLS = [
 {"name": "read_file", "description": "读一个文件的内容。"},
 {"name": "grep", "description": "在仓库里按模式搜代码。"},
 {"name": "edit_file", "description": "改一个文件（只许在工作区内，呼应第七章）。"},
 {"name": "run_tests", "description": "跑测试，返回通过/失败与失败详情。"},
]
# 循环就是第二章那个,只换两处:
# 停止条件:从「模型说完成」换成「run_tests 全绿」
# 纠错信号:失败的测试输出喂回去(第三章 is_error / 第五章自我纠错)
```

```

规划是有 overhead 的。一行能描述的改动（改个 typo、加条日志）别规划，直接做；规划留给「跨多文件、你不熟那段代码、approach 不确定」的活。[^1]另外给它一份简洁的 CLAUDE.md（持久项目上下文），标准是「删了这条它会犯错吗」—— 不会就别写，臃肿的上下文反而让它忽略真正的规则。

---

### III · 写手 + 审查：让评判的不是动手的那个

编码 agent 最实用的多 agent 模式，是一个写、一个审 —— 关键在于审查的那个用干净的上下文，只看 diff，不看产生它的推理。

这正好用上第八章的 handoff 加第四章的子 agent 干净窗口：reviewer 在新上下文里只拿 diff 和标准，「让动手的那个不是给自己打分的那个」，新上下文也不会偏袒它刚写的代码。[^1][^3]但 Claude Code 也提醒一句反话：专门让它挑毛病，它总能挑出一些，追着每条改会过度工程 —— 只收「影响正确性或需求」的，其余当可选。

然后就接上了下一章：自己手写这套写手-审查，还是用 Claude Code / Cursor / Codex 现成的？编码 agent 的产品化已经很成熟，多数人该用现成的。你从零写它，是为了懂它每一格 —— 不是为了取代 Cursor。

动手 · 用你建的 agent 修一个真 bug：

- **指一个有失败测试的真实小 bug**:
 给 agent 三个工具（read_file / grep / run_tests / edit_file），挑你仓库里一个有失败测试的小 bug，让它探索 → 规划 → 改到测试绿。

- **开一个干净上下文的 reviewer 审 diff**:
 另起一个只看 diff 和需求的 reviewer agent，让它只报「影响正确性」的问题，别追风格。

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

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

## 引用与参考

01 · Anthropic 文档 · Claude Code best practices —— agentic 编码工作流 Explore → Plan → Code → Commit；核心一句「给 Claude 一个它能自己跑的检查」(测试 / build / linter / 截图)让循环自己闭合;写手-审查(reviewer 用干净上下文只看 diff);CLAUDE.md 持久上下文;auto mode / allowlist / sandbox 限权。截至 2026-05。  (Anthropic · Claude Code best practices)
02 · SWE-bench（swebench.com）—— 用真实 GitHub issue + 隐藏测试衡量编码 agent 的基准;测试通过与否是客观的成功信号,这是大多数 agent 任务没有的。  (SWE-bench)
03 · Anthropic · 「Building Effective Agents」（2024-12-19）—— 反馈循环、独立的验证 / 审查（让评判的不是动手的那个），以及别为审查者挑出的每条都过度工程。  (Anthropic · Building Effective Agents)

---

*编码 Agent · 把每一格拧成最难的用例 · Agent 实战 · 从零构建完备智能体 · Aklman 著 · CC BY-NC-ND 4.0 · https://library.aklman.com/books/build-agent/coding-agent*