# 一片不吹不黑，中性探讨 Agent 编程的文章

> 本文公开全文。

原文：https://utgd.net/article/21182

🔗 原文链接

在 AI 工程师社区里，最引人注目的趋势，或许不是哪个模型又打破了 benchmark，而是越来越多开发者开始认真地重新理解“写程序”这件事本身。David Crawshaw 的这篇《How I program with Agents》写得相当诚实，也不乏热情——他没有用抽象术语包装技术进展，而是从一个程序员的视角，讲述了什么是 Agent、它为什么比普通的 LLM 更接近“工具”，以及它如何正在改变他写代码的方式。

## Agent 不神秘，只是“能试错的 LLM”

文章开头，David 就试图给“Agent”这个被市场炒作得几近玄学的词一个朴素的定义：“一个包含 LLM 调用的 for 循环。”就是这样简单：模型发出指令，运行后读取结果，再决定下一步该做什么。区别在于，它能看到环境反馈，就像一个程序员能看到自己代码编译出错的原因，再回去改代码一样。

他打了个比喻——让 LLM 写代码，就像让人站在面试白板前写 UTF\-8 检查函数。你不能试跑，不能查文档，只能靠脑海里残存的标准记忆。“这件事我真做过，”他说，“当时我表现如何，完全取决于我记得多少细节，还有我掩盖模糊记忆的能力。”普通 LLM 也面临类似窘境，它固然能“编出”程序，但像是在光滑的黑板上舞蹈，没有真实世界的摩擦。

Agent 则不一样。它可以运行编译器、调用 grep 查文件、编辑多个文件、甚至自己运行测试并修复失败的用例。换句话说，它获得了一双“看见结果”的眼睛，也拥有了一对“伸出去修改”的手。

## 第一次用 Agent 是“边吸尘边写代码”

但 Agent 真有那么有用吗？David 回忆起一次自己用 Agent 写 GitHub App 授权流程的经历。

他用 Agent 工具 sketch\.dev，在网页上点击几下，提供了三四句反馈，Agent 就完成了 GitHub App 授权机制的第一版实现。整个过程甚至包括了他当时的一个奇怪要求：不要存用户的 token，而是仅用 App 的全局凭据完成所有交互——这简化了数据库设计。Agent 居然实现了，而且能跑起来。

但 Agent 写出的代码当然不是完美的。它在逻辑上留下了一个严重的安全漏洞：任何授权用户都能访问所有被授权的仓库，无论是否拥有权限。“如果我们早点开始测试，看到自己私人仓库出现在别人账户下，肯定能发现问题。”David 很庆幸他及时发现，并用一句简单的话提醒了 Agent，后者迅速重构代码，补上权限验证逻辑。

接下来又遇到性能问题。Agent 写的逻辑，要查询一个用户能访问的 repo，竟然是对每一个 app 安装下的所有 repo 调用 API，再逐个验证用户是否是协作者。这个复杂度会随着用户量线性膨胀。“这不能用啊，”他说。

问题追溯到最初的“不要存用户 token”的要求，事实证明，在 GitHub 的 API 设计中，如果不保存用户凭据，就不能高效地判断权限。David 决定撤回这一要求，再次告诉 Agent 改为存储 token。Agent 随即生成了效率更高的新实现。

> “这整个过程写成故事比我在 sketch\.dev 中实际输入的文字还多。”

他感叹，真正的代码审查、合并、测试都很流畅。如果手动完成，他可能需要一周时间；而这次，一天内搞定了，“连孩子的房间都顺便吸了尘。”

## Agent 不是只会“生成”代码，它会理解你写的规范

另一个更微妙的例子，是 Agent 在生成 SQL 表结构时的“风格混乱”。

David 曾在 Tailscale 学到一个写 SQL 的怪招：把每个表的数据都塞进一个 JSON 字段里，再用虚拟字段 AS 从 JSON 中解析实际列。这种做法有很多优点，但也容易让人困惑。而 Agent 明显困惑了。有时它按这种方式生成，有时又完全照传统方式来写。

解决方案意外地简单——他在 schema 文件顶部加了三句话说明这个风格。关键一句是：“每张表都有一个实际的 JSON 字段，其他字段都是从中派生出来的。”再在特例表中加注释说“这是例外”。从此 Agent 表现就大幅改善了。

他反思：LLM 似乎比人类更“尊重注释”。现实中工程师往往会忽略注释，而更依赖“提 PR 被打回”的训练方式。Agent 却读注释、记住风格，这种反差让人印象深刻。

## 我们是否高估了“维护旧代码”的难度？

批评者常说，写代码只是编程工作的一小部分，维护才是大头。而 Agent 的能力集中在“生成”，维护没啥帮助。但 David 不完全认同。他认为不能把“大公司里维护遗留系统”的经验，推而广之成整个行业的画像。

> “绝大多数程序根本不会活那么久。”

Agent 不仅能生成新代码，它也能读懂现有代码并进行修改、删减。只要目标是“改变”，Agent 就有发挥空间。“它并不只会加代码，也会删。”

他还提到一个不那么光彩的行业现象：某些人刻意使用复杂工具来设门槛，让项目难以介入。他说：“你加不了依赖，是因为没人搞得清怎么加。”Agent 则是“降低门槛”的反方向力量。

## 为什么 Agent 是 2025 年才爆发的？

反馈驱动、工具调用的想法其实并不新鲜。但关键差别在于：模型本身终于准备好了。

2023 年的 LLM 还不能稳定地调用工具，不知道什么时候该抓日志、什么时候该执行测试。2025 年的新模型，则已具备了这些能力。David 明言，现在最好的能力还在闭源模型上，开源尚在追赶。但他相信，用不了半年，差距就会拉平。

## Agent 工作方式仍需重塑

尽管 Agent 很强，它也并非没有弱点。主要有两个：

- 安全问题：真实开发机上跑 Agent，容易误操作暴露生产密钥；

- 效率问题：每轮执行几分钟，难以并行多个任务。

David 的解决方案是：容器化运行 Agent。sketch\.dev 会在容器中创建临时开发环境，用 git diff 提交变更。他举了个例子：

> “我在改 GitHub 授权代码时，顺手把一个丑 UI 截图发给另一个 Agent，说‘这个表单好丑，能不能好看点’。半小时后我回头一看，居然真有改善，就让它 rebase 合并了。”

## IDE 会变成什么？

“IDE 在 Agent 时代会变成什么？”David 提出了几个新尝试：

- 在 diff 右侧直接修改代码；

- Web Terminal 或 VSCode SSH 链接，深入容器微调；

- 直接在 diff 上写评论，反馈给 Agent 改进。

这套交互方式远比“人写代码，Agent 给建议”更接近生产实践。

## 结语：一场思维的重构，而非工具升级

文章最后，David 写下了最动情的一段话：

> “我从不讨厌行业的变革。多核处理的到来、SSD 替代机械硬盘、网络一体化，这些都改变了程序的结构，也让我乐于重新学习……但 Agent 改变的是我写程序的方式本身。它挑战了我所有根深蒂固的工作习惯，有时让我觉得‘不如一开始就不会写代码’。”

这不是一个工具升级，而是一次思维方式的重构。他坦言一切远未稳定，但变化正在逼近。他呼吁程序员保持好奇、保持谦逊，远离喧哗的论坛，多去实践。

> “写下那几句 prompt 时，我还顺手吸了地。Agent 让我有时间去做以前没空做的事。我们都该有这样的幸运。”

---

[前往标准阅读页](https://utgd.net/article/21182?audience=web)