A6.1 代码智能体：终端 + 编辑器 + 测试
最出圈的智能体，都在写代码
2024 到 2026 年，最先走出 demo、真正天天有人用来干活的智能体，几乎都是写代码的：修一个 bug、实现一个功能、读懂一个陌生代码库、甚至独立处理一整个 GitHub issue。
有意思的是，它们的工具箱朴素得让人意外——没有什么专为 AI 设计的黑科技，就三样东西：
- 一个终端（跑命令：搜索、运行、测试）；
- 一个文件编辑器（读代码、改代码）；
- 一套测试（判断改得对不对）。
这跟一个人类程序员的桌面几乎一模一样。代码智能体不是发明了新工作方式，而是学会了程序员既有的工作方式。
它的标准循环：一次修 bug 的全程
代码智能体的工作循环，正是前几章零件的合体——A0 的行动循环 + A1 的工具调用 + A2 的反思：
读任务（issue）→ 在代码库里搜索定位 → 改文件 → 跑测试看反馈 → 没过就改 → 过了就提交
这就是 2024-2025 年 SWE-agent、Claude Code 这类工具的基本范式。光看文字没感觉，步进看一次真实感的修 bug 全程：
请一路点到底，重点盯第 8 到第 10 步。智能体找到嫌疑后，第一次的改法是「把满减门槛从 40 改成 41」——看起来能让当前这个 bug 消失。但它跑完整测试套件时，另一条用例「正好满 40 的订单」立刻失败了：这个改法误伤了正常订单。测试当场把这个「治标不治本」的修复拦了下来。于是它回到根因，发现真正的问题是 cart.py 把每件商品的价格逐件四舍五入（round()），两件 19.90 被凑成了 40。改掉这行、全程用精确金额，47 个测试全绿，收工。
这里藏着代码智能体的核心秘密：测试就是它的眼睛。没有测试，它在第 8 步就会心满意足地提交那个错误修复，因为对着那一个 bug 它「看起来是对的」。是测试的即时反馈，让它看见了自己看不见的错误。
代码智能体 = 行动循环（A0）+ 代码工具（A1）+ 测试驱动的反思（A2）。测试是它区别于「聊天式写代码」的关键——前者能自己判断对错并改正，后者只能一次性吐出代码等你去试。
为什么工具是「终端」而不是花哨 IDE
你可能会想：给它一个装满按钮的图形化 IDE 不是更强？恰恰相反。文本接口才是模型的母语。 模型是在海量的代码、命令行操作、Git 提交记录上训练出来的（上篇 4.1 讲过代码数据如何练出逻辑能力）——它对 grep、pytest、diff 这些文本命令的熟悉程度，远超任何图形按钮。把工作台做成纯文本，等于让它在最擅长的语言里工作。
小结
- 代码智能体是最成熟的一类智能体，工具箱朴素：终端 + 编辑器 + 测试。
- 它的循环 = 行动循环 + 代码工具 + 测试驱动的反思；测试是它的眼睛，让它能自己发现并改正错误。
- 文本接口（终端/命令）比图形 IDE 更贴合模型的「母语」，因为它在海量文本代码上训练而来。
上面的轨迹是教学构造的干净版。真实代码智能体远没这么顺：在几十万行的陌生代码库里会迷路（找不到该改的地方）、会改出难以察觉的副作用（改好了 A 却弄坏了没有测试覆盖的 B）、会被庞大的上下文拖垮（A3 的老问题）。它真正擅长的是边界清晰、测试完备的任务，而不是「帮我重构整个系统」这种没有明确终点、没有测试兜底的活。
延伸阅读
- SWE-agent（2024）——把「智能体—计算机接口」讲清楚的开源项目，代码智能体范式的代表。
- SWE-bench——真实 GitHub issue 评测基准，观察代码智能体进展的窗口。
- 下一节 A6.2 为什么代码最成熟：把「测试是眼睛」这件事，上升成一条贯穿全书的规律——可验证性。