《Agentic Engineering Patterns》
Simon Willison 这套《Agentic Engineering Patterns》我是连续读完的。读完之后最大的感觉：很多人一开始就把题目做偏了。
现在最不缺的，是让模型多写一点代码。真正稀缺的，是有人把这些代码接住。
Simon 对 agent 的定义很简单：在循环里调用工具，朝着目标继续往前跑。放到 coding agent 身上，差别就在一个地方：它不只会写代码，还会自己去跑。
不会执行代码的 LLM，更像建议生成器。它能给你思路，能补几个函数，也能讲得头头是道，但它并不知道自己写出来的东西到底能不能跑。会执行代码的 agent 就不一样了。它能改，能跑，能看报错，也能顺着错误继续试下一版。走到这一步，问题就不再是“它会不会写”，而是“你怎么管它”。
Simon 这套指南好就好在这里。他没把 agent 写成什么新物种，还是老老实实放回软件工程语境里看。代码执行只是起点。真正的问题是，跑完之后你拿什么证明这次改动值得留下。
Simon 有一句话我很认同：写代码现在变便宜了。
以前很多工程直觉都建立在“编码时间很贵”这个前提上。改个命名、补一组边界测试、顺手做个小工具、试一个不确定值不值得的方案，脑子里都会先算一遍时间账。现在这笔账变了。agent 把大量机械输入和样板改造的成本压得很低，很多以前嫌麻烦的事，现在十分钟就能拉个会话试一下。
但便宜的是“把代码敲出来”这一步，不是判断本身。
好代码还是贵。你照样得确认功能能跑、边界被覆盖、文档没过期、设计不会把以后的改动搞得更难受。Simon 这套指南一直在强调这件事。我自己读下来，最大的提醒就是别把“编码成本下降”误读成“质量也可以顺便打折”。
很多团队后面翻车，往往就翻在这里。不是 agent 不够强，而是人先默认“反正做得快，差不多就行”。可一旦进了真实项目，要维护、要回归、要交接、要 review，那些没立住的门禁还是会回来找你。
这本书里我觉得最好用的，反而是那些很短的小指令。
比如 First run the tests。这四个词的价值，不只是让 agent 先跑一遍测试，而是先把它扔进一个严肃项目的上下文里。它得先搞清楚测试怎么启动、项目复杂度大概在哪、相关测试散在什么地方。跑完这一轮，后面它再改代码，天然就更容易带着回归意识做事。
再比如 Use red/green TDD。Simon 特别强调，一定要先看到测试失败。很多人只记得“让 agent 帮我写测试”，却直接跳过 red 这一步。结果就是测试看起来齐全，实际上根本没真的碰到新需求，agent 只是顺手写了点让人安心的装饰。
这套方法的好处就一个：把“看起来像完成了”换成“有证据说明它真的完成了”。
Simon 还专门讲了 agent 主导的手工测试。自动化测试重要归重要，但它从来没重要到可以代替肉眼确认。页面没显示、服务一启动就崩、接口返回结构有偏差，这些问题都很常见。你不能因为一排测试绿了，就默认功能一定没事。
所以他会让 agent 去做很具体的验证：
- 用
python -c打边界 case - 启动开发服务器后用
curl探接口 - 用 Playwright 或 Rodney 看真实页面
- 用 Showboat 记录命令、输出和截图
这套东西一点也不浪漫，但很管用。少听汇报，多看执行痕迹，很多幻觉到这里就藏不住了。
你给的参考里提到 Git，得补进来——Simon 原文也专门花了一章讲。
很多人把 Git 当成另一个话题，觉得那是工程基础设施，和 AI 编码没什么关系。但 agent 越强，Git 越重要。你现在可以让 agent 以很低的成本同时做很多改动，重构、拆文件、补测试、试方案，全都变快了。越是这样，你越需要一个能随时回头、随时定位、随时收束范围的安全网。
Simon 对 Git 的看法很实用，不是教你背命令，而是提醒你别浪费这套能力。让 agent 提交 commit、帮你理顺冲突、看最近几次变更、用 git bisect 找 bug 是哪一版引进来的，这些事情放在今天，比过去轻松多了。
Git 在 agent 时代帮你把试错变得可逆。你敢放手让它干活，底气就来自一路都有锚点，出了问题能退能查。
所以我现在越来越习惯一个做法：每推进一段，就让 agent 留下清晰 commit。后面真出事时，你手里有东西可抓。
Simon 还有个我很喜欢的习惯：hoard things you know how to do。
这句话我第一次看到时觉得有点怪，后来越想越对。所谓囤积，不是囤知识卡片，也不是囤十篇没跑过的教程，而是把自己真正做成过的东西留下来。一个实验仓库、一段脚本、一个小工具、一篇把来龙去脉写清楚的 TIL，价值都很高。
因为 agent 最吃这类材料。你给它一段抽象描述，它当然也能猜；但你给它两个已经跑通过的 working example，让它把两者拼起来，稳定性和命中率都会高很多。
Simon 拿 PDF.js 和 Tesseract.js 的例子说明这一点，很直观。模型在这里不是从零发明，更像是在重组。前提是你手里得先有真积木。
回过头来看，这也是在提醒工程师：最管用的还是你自己验证过的经验。到了 AI 时代，这些经验终于能被更大规模地复用。
这套指南还有一层意思：它没有停在“让 agent 产出代码”，而是继续追问——那你自己还看得懂吗？
subagent、linear walkthrough、interactive explanations 这些章节，表面上看有点散，实际上都在解决同一个问题。一个是上下文会爆，另一个是人脑也会爆。
子代理的意义在于把搜索、探路、测试输出这种高噪声工作隔出去，别把主上下文挤爆，并行加速倒是其次。线性拆解和交互式解释也一样。既然 agent 参与了实现，你最好也让它参与解释，不然“看起来能用”的黑箱迟早会反噬你。
vibe coding 最危险的地方，不是偶尔写错，是它太容易制造一种“已经做完了”的错觉。页面跑起来了，按钮能点，看着像没问题。但过一周再回来，作者自己都未必说得清关键路径怎么走、为什么这么分层、哪里是补丁、哪里是设计。债就是这样埋下去的。
Simon 在反模式那章里点得很直接：不要把没审过的 agent 代码直接丢给同事 review。
这句话一点都不新，甚至有点老土，但今天反而更重要。因为未审查代码的生产成本实在太低了，低到你随手就能造出一个几百行、上千行、说明文档还写得像模像样的 PR。问题是，如果你自己都没确认过它能不能跑、描述准不准、边界在哪，那你其实只是把最费脑子的活转嫁给下一个人。
Simon 给的标准蛮实用。一个像样的 Agentic PR，至少得满足几件事：
- 你自己确认过代码能跑，改动规模可 review，不是一坨大包裹
- 上下文说明清楚，PR 描述你自己也读过，别人知道你为什么这么改
如果还能顺手附一点证据，比如怎么测的、哪里特别留意过、截图或录屏长什么样，review 质量会高很多。说到底是成本分配问题。你省下来的时间，不该变成别人的认知负担。
Vibe Coding 往下走，方向大概就是把 agent 纳入一套有门禁、有回滚、有验证证据的工程流程。这和我之前写的从 Vibe Coding 到 Skill Workflow 是同一个方向。模型能力当然还会继续涨，但最后分出高下的，多半还是工程师能不能把这些能力变成稳定流程。
我的做法越来越简单：先跑测试再让它改，关键步骤留 commit，能用真样例就少用抽象描述，UI 和接口改动留执行证据，大任务拆子代理逼它把过程讲清楚。prompt 会一直变，工具也会一直变。最后能留下来的还是老东西：测试、Git、review、上下文控制，还有你自己愿不愿意对结果负责。