智能体工程模式

这篇文章总结自 Simon Willison 的博客 原文

总结

• 原则
  • 编码的成本降低了，通过多代理，一个人甚至可以同步实现多个想法。不过作者认为，你更需要花费精力去衡量每个想法的价值
  • 需要维护优秀的代码标准，作者给出了他的标准。我感觉看起来还不错可以参考，或者稍作修改丢给你的编程代理，应该也不错
  • 积极记录你的想法，并通过代理快速实现demo。积累下来的点子，之后或许能快速的编排出新的功能（作者给出了一个他做的工具，自动爬取网页截图，然后通过OCR制作成PDF）
  • 不要只做AI生成代码的提交人，而是参与进去，至少要验证一下修改是否是好的。如果你只是点了一下合入，那不如将代理提权，并完善他的职责和工作范围
  • 一个好的MR应该具备的素质：
    • 代码正常运行的证据
    • 改动量不大，review的负担也不大。对于代理来说，可以通过流程控制，令其将修改分解为多个MR
    • MR需要描述修改的背景，以及服务的目标
    • 代理往往会写看起来有道理的提交信息，但是你应该阅读并认可它。而不是提交上去，让别人看你都没有看过的描述信息
• 质量保障
  • 使用红绿测试驱动方法，作者认为先写用例对agent是很好的，因为很多agent写完的代码运行不起来
  • 红绿测试的重点是你要确保每个新的用例一开始是执行不通过的，完成代码修改后，全量的用例包括这个新的用例都会成功，这样你才能确保这个用例是有价值的
  • 在提示词中，你只需要说使用 使用红绿测试驱动开发 (TDD) 就好了
  • 开始编程前总是先执行测试，这样有三个好处：建立健康的基准；确认当前的AI代理知道如何验证；设定了明确的停止条件（红绿测试）
• 理解代码
  • 作者推荐让AI总结代码，他给出了他开发的一个工具。这个工具的价值有两个：让你更容易理解代码；让AI通过这个工具记录他的行为，而不是完成后自己编写总结，这样更加可靠
  • 作者认为交互性解释的效果更好，他给了一个例子，让claude opus 4.6做了一个网页一步步的实现词云，作者通过这个例子理解了困扰他很久的算法原理（不过我在看了这个例子后觉得这个点并不是很有说服力，感觉这个点的价值因人而异，可能也要看实际场景）
• 带注解的提示词
  • 这里作者主要是举了个例子，有他用的提示词和对整个开发流程的描述可以参考。
  • 作者的提示词包含要做的事情以及作者的注解，比如作者认为比较重要的功能点或者告诉AI要怎么进行测试。
  • 但是作者不会给出详细的实现细节，而是让Agent自己去试。
  • 作者还提到他会不时的看一下AI的进度，在适当的时候给出建议，而不是完全放开。
  • 老实说我觉得这个章节并没有太大的价值对我来说，可能因为作者描述的使用流程跟我平时的做法相似，我也不太清楚别人会怎样用AI代理，总之如果感兴趣可以看看原博文的详细描述。

后记

Simon 在他的这个博客专题中记录了很多有价值的内容。在某些点上可能还存在不完善的地方，但他的工程化思维我认为是非常有价值的。我之前看到过的一些文章（比如这个）尝试从项目管理的角度分析应该如何处理人和编程代理的关系。而Simon的这个系列博客更加的详细，他直接给出了很多自己的实践细节。比如如何制定标准流程；如何确保代理进行测试；如何审计代理采取的行为等。并且作者使用中遇到的问题很多采用了主动优化流程标准来解决的方式。比如我们都知道大模型有幻觉，作者于是引入了自己的工具，不依赖模型自己写流程，而是让他采用工具调用这样更确定的方式。当然，这背后也涉及到复杂的价值考量，不断引入标准的优化会导致流程的复杂性，这里需要有一定的工程意识来判断什么是真正有价值的流程步骤。

其他

最后，作者在他的这个博客中推荐了自己参加的斯坦福战略沟通课程。我觉得似乎不错，但这个课程没有网上的公开课，我只找到了一个类似的课程。后续有时间可能会看一下，或者可能在博客中更新。