编程 agent

编程 agent 比其他大多数 agent 应用都更好用。这不是因为代码简单——而是因为软件开发恰好具备 agent 需要的四个性质。

搞清楚这几个性质，你就能判断 agent 还能用在哪些地方，以及哪些地方不行。

代码为什么占优

验证是自动的。 测试要么通过要么失败，代码要么编译得过要么编译不过。agent 每做一步都能拿到标准答案信号，不需要人在回路（HITL）。这一条最关键——大多数领域没有等价物。

动作可以撤销。 有版本控制，一次改错代价只是一次回滚。对比发邮件或退款，那里的自信的错误操作是无法挽回的。

反馈很快。 以秒计，不是以天计。紧凑的循环让多步任务变得可行。

训练数据极其充足。 公开仓库、issue 和评审数据量惊人，而且代码的结构很一致。

一个领域如果缺了这些——没有自动验证、动作不可撤销、反馈慢——agent 的表现会急剧下降。这才是能迁移到其他领域的结论。

工具有哪些

编程 agent 就是围绕一小组工具的 agent 循环：读文件、搜索代码库、改文件、跑命令、跑测试。

有两个细节比这份清单本身更重要。

搜索质量决定一切。 找不到相关代码的 agent 就修不好它。好的搜索——按符号、按模式、跨整个仓库——决定了 agent 是能干活还是瞎扑腾。这是最被低估的一环。

跑测试是价值最高的工具。 它把猜测变成验证。能跑测试套件的 agent 会自我修正；不能的，就是在闭着眼睛写代码。

它们擅长什么

描述清楚的改动。 把这个改名，在所有地方都加上这个参数，把这个模式扩展到这些场景。跨多个文件的机械性工作。

有测试覆盖的 bug 修复。 一个失败的测试就是完美的目标——agent 很清楚自己什么时候算完成。

样板代码。 新的 endpoint、迁移脚本、照现有模式搭的测试脚手架。

代码库问答。 这个功能实现在哪里、谁调用了它、这条流程是怎么走的。搜索加阅读，不涉及修改。

增量重构，在一个清晰的模式之内。

它们在哪里不行

含糊的需求。 只说「把它弄快一点」却不给目标，产出的改动看着合理，实际效果未知。

架构决策。 权衡取决于 agent 并不掌握的上下文——团队约定、路线图、运维约束。

没有测试的代码。 没有验证，循环最主要的优势就消失了。agent 产出的代码看起来是对的，这正是危险的中间地带。

大范围的横切改动。 跨多个文件的协同修改，超出了单次运行中可靠性累积所能允许的范围。

微妙的正确性。 并发、数值精度、安全敏感的逻辑。通过测试但其实是错的代码。

怎么和它们高效协作

一开始就把验收方式说清楚。 「让 auth_test.py 里那个失败的测试通过」比「修一下认证」好得多。给 agent 一个能知道自己成功了的判据。

把范围压窄。 一次运行只做一处定义清楚的改动。可靠性随步数下降，所以短任务的成功率更高。

看 diff，别看解释。 agent 对自己做了什么的叙述是生成的文本，不是可靠的审计记录。去读实际的改动。

显式地提供上下文。 该遵守的约定、该照搬的模式、该避开的文件。很多项目级工具支持一个常驻的说明文件，正是为了这个——这是性价比最高的配置步骤。

预期会遇到「看着对但是错」的失败。 能编译、能过测试、却漏掉一个边界情况的代码，就是它的典型产出。差一错误、没处理的 null、被漏掉的分支，都能从验证中溜过去。

给有后果的命令加上关卡。 读取和编辑撤销起来很便宜。rm -rf、强制推送、部署则不然。参见人在回路的设计。

要点回顾

• 编程 agent 之所以好用，是因为软件有自动验证、可撤销的动作、快速反馈和充足的训练数据。
• 缺了这些性质的领域，就是 agent 表现下滑的地方——这才是能迁移到其他领域的结论。
• 搜索质量和测试执行是最重要的两个环节。
• 擅长描述清楚的改动、有测试覆盖的修复、样板代码和代码库问答。
• 不擅长含糊需求、架构决策、没有测试的代码、大范围横切改动和微妙的正确性。
• 给出明确的成功判据、把范围压窄，并且看 diff 而不是看解释。

下一篇： 操作电脑的 agent