再次强烈推荐「Agentic Engineering Patterns」

作者 @simonw 2026 年 2 月起撰写，每周约新增 1-2 章，目前仍在演进。文字由他本人撰写，示例与代码借助 LLM 辅助。

在线阅读： https：//simonwillison.net/guides/agentic-engineering-patterns/

核心目标：如何用好 Claude Code、Codex 这类能写代码、也能执行代码的 coding agent，拿到可靠、可维护的结果。

# 核心概念：Agentic Engineering ≠ Vibe Coding

Vibe Coding vs Agentic Engineering · 定义来源：Karpathy 提出 vs Willison 提出的专业实践 · 适用人群：常与非程序员原型相关 vs 专业工程师放大既有能力 · 代码质量：未审查、原型级 vs 审查、测试、可上线 · 人的角色：几乎不参与代码理解 vs 定义问题、验证结果、持续改进 harness

Agent 的定义： 在循环中调用工具以达成目标。Coding agent 的关键差异是能执行代码--没有执行能力，LLM 输出价值有限；有了执行，agent 才能迭代到"确实能跑"的软件。

人的工作并未消失，而是上移： · 决定写什么代码（问题空间有数十种解法与权衡） · 提供工具与足够细的规格 · 验证结果是否稳健可信 · 把经验写回指令与 harness（LLM 本身不会从错误中学习，但系统可以）

# 全书最重要的一个判断 写代码变便宜了，写好代码并没有。

过去几十年，工程习惯都建立在"代码昂贵"之上： · 宏观： 大量设计、估算、排期，功能必须数倍覆盖开发成本 · 微观： 是否重构、写测试、补文档、做 debug UI--每个决定都受时间约束 Agent 把这个约束打碎。一个人还能并行跑多个 agent，同时实现、重构、测试、写文档。

但"好代码"仍有明确标准： · 能跑、且被证明能跑 · 解决对的问题 · 处理错误路径，不只 happy path · 简洁、可维护 · 有测试与合适文档 · 设计留出演进空间（YAGNI 与可扩展性的平衡） · 满足安全、可观测性等 non-functional 要求

新习惯： 当直觉说"不值得做"时，不妨开个异步 agent 试一下--最坏情况是浪费几分钟 token；很多过去"不划算"的改进，现在值得做。

# 五大原则层（Principles）

1. 定义边界 Agentic Engineering 是专业工程师用 coding agent（能写能跑）放大能力；不等于 vibe coding（不审代码的原型玩法）。人的核心工作：定目标、给工具、验结果、把经验写回 harness。

2. 接受新约束 写代码几乎免费，写好代码仍然贵。旧习惯（过度规划、跳过测试/文档/重构）要推翻；直觉说「不值得做」时，不妨开个异步 agent 试一下。

3. 囤积可复用解法 积累带可运行证明的代码片段（仓库、笔记、小工具）。最强用法：把两个已验证例子拼进 prompt，让 agent 组合出新方案；每个技巧人类只需解决一次。

4. 质量应上升，而非下降 技术债、命名混乱、大文件拆分等「简单但耗时」的清理，交给后台 agent 做，成本已低到可零容忍 code smell；用原型并行验证技术选型；任务结束做回顾，把有效做法写进指令（复合工程）。

5. 严守反模式 绝不提交自己没审过的 PR。合格标准：确信能跑、体量小、有上下文、描述自己读过、附测试证据。否则只是把活甩给 reviewer。