这本书的核心公式一句话：Agent = LLM + 上下文 + 工具，对应大脑、眼睛、手脚。
全书十章围绕这个公式展开，配了 109 个能自己跑的实验，正文开源在 GitHub 上。
跟同类书比，它讲的不是「怎么用框架搭一个 Agent」，而是这套系统在工程上会遇到什么。
看完最大的收获是三个判断：
- 上下文的缓存一致性会反过来主导架构；
- 上下文学习在机制上更接近检索而不是推理；
- Coding Agent 的优势来自软件工程攒了几十年的验证基础设施，而不是代码生成模型特别强。
也有几处我读完没被说服，写在对应的地方了。
1. 骨架
作者给的演进框架是层层包含的：软件工程 → 提示工程 → 上下文工程 → Harness 工程 → Loop 工程。
后一层包含前一层，不是替代关系。Harness 指「上下文 + 工具」之外的那套保障机制，作者把它拆成约束、验证、纠正三件事。
有个判断我划了重点：实践在前，命名在后。
Skill、Harness、Loop Engineering 这些词，不是先有理论再有实践，
是大量 Agent 早就在这么做，Anthropic 才把它们提炼成设计原则。
作者的立场是八个字：方向认同，节奏务实。
他不怀疑模型会一层层把 Harness 吃掉，只是认为这个「吃」比直觉慢得多：训练以月计，模型没法一次内化真实业务里所有的约束和偏好。
模型此刻的能力边界，就是 Harness 此刻的价值所在。
2. 上下文：既是能力上限，也是成本中心
上下文分两段：静态前缀（系统提示词 + 工具定义）和轨迹（模型输出、工具调用、工具结果）。前者固定，后者随轮次增长。
缓存一致性会反过来主导架构
书里最实用的一句：当 Prompt Cache 的经济效益足够显著时，缓存一致性会反过来主导架构选择。
KV Cache 处理单次请求内的 token 生成，Prompt Cache 处理跨请求的重复计算。
服务商对请求前缀做匹配，前缀相同就直接复用算好的 KV。
推论很硬：系统提示词和工具定义不要改；动态信息永远追加到末尾；不要自己拼接消息格式，用标准 API。
这也解释了我之前在 Eino 运行时分析 里没想透的一件事：为什么 Agent 的状态更新要走追加而不是替换。
每轮替换确实永远最新，代价是尾部缓存持续失效。
书里把这条总结成一句：缓存经济性不是事后优化，而是前置约束。
上下文怎么拼、预算怎么分，我在生产级 Agent 架构里排过一版。
上下文里没有「结论」
作者用注意力机制的特性解释状态栏为什么有效：上下文学习更像检索而非推理。模型擅长从已有内容里查找信息，不擅长主动归纳总结。
于是有个反直觉的推论：上下文里的东西不会被自动数一遍、建个索引、或者就地总结成一条结论。
像「一共多少条、有没有超标、进展到哪一步」这类问题，模型每次要用都得从原始记录里现算，代价随内容量一起涨。
状态栏就是冲着这个来的：把散落在上下文各处的隐式状态，提炼成可以直接取用的显式知识。
实现上它是一条 user 角色的消息，插在上下文末尾，而不是改开头的 system 消息。
这条我一开始没看明白，后来想通了：Harness 借了 user 这个消息槽位，注入框架生成的状态信息。
另一个推论是隔离优于压缩。与其费劲压中间产物，不如把产生海量内容的任务委派给子 Agent，只回传几百 token 的结论摘要。
我的质疑
作者说「模型能力是基础，上下文质量是 Agent 能力的上限」。我不太同意。
按这个划分，Harness 那套约束、验证、纠正就成了锦上添花，但 Claude Code 里绝大部分代码都是干这个的，按书里的描述，工具本身（读写、执行、搜索）只占一小部分。
更让我卡住的是另一处。书里一边说上下文学习是检索而非推理，一边又讲「上下文感知压缩」，也就是把当前查询意图和已积累信息纳入压缩的决策过程。
这两个说法在逻辑上是打架的：如果模型不擅长归纳总结，那它凭什么判断哪些内容跟当前意图相关、可以压掉？
还是说压缩这一步本来就该交给代码或另一路模型去做，不能算在「上下文学习」的能力里？我停下来想了很久，书里没给答案。
3. 记忆和知识库
用户记忆和知识库是两回事。
- 前者针对单个用户
- 后者是所有用户共享的
作者的说法是「一个让 Agent 成为懂你的助手，一个让 Agent 成为领域专家」。
有个区分我觉得挺准：
- 轨迹是单次运行的完整原始记录，按时间追加不修改；
- 长期记忆是跨会话提炼出来的稳定信息，会被反复改写、合并、淘汰。
前者是流水账，后者是档案。
做 Agent 平台的时候这两者经常被混在一张表里，混完之后查询和更新都会变形。
作者对「把原始文档丢进向量库」批评得很直接，理由是模型的注意力机制是基于相似度的软检索，不是能主动总结归纳的思考引擎。
所以要先做结构化：RAPTOR 那种自下而上的递归抽象，或者 GraphRAG 那种实体加关系的图谱。
不过他给了收手线：
- 如果查询主要是「找到包含某条信息的片段」，混合检索就够了；
- 只有跨文档综合或者多层次导航，才值得为结构化索引付那笔 LLM 调用的成本。
这个分寸感比结论本身有用。我见过不少项目一上来就上知识图谱，最后卡在维护成本上。
书里还提到跨文档聚合的错位：统计类问题需要数遍所有文档，而检索的本性是找最相关的几个，两者天然矛盾。
这个问题在数据类问答里很常见，靠检索本身解决不了。
4. 工具
选错工具，先检查描述
书里的主张：当 Agent 频繁选错工具时，优先检查工具描述，而不是怀疑模型能力。
大多数选择错误的根因在描述：边界不清、缺少反例、参数含义模糊。修描述的投入产出比，通常远高于换一个更强的模型。
描述要回答的是「什么时候用」和「什么时候不用」，而不只是「这是什么」。
搜索工具写「搜索相关内容」，远不如写「当需要获取实时信息或查找未知事实时使用」。
另一条是通用工具优先于专用工具，而且模型越强这个结论越成立。
作者的例子是：与其做一个专用计算器，不如给一个 Python 解释器；与其做记录工作日志的工具，不如给文件读写加一个虚拟文件系统。
审批拒绝不该重试
这条我印象很深。工具调用要人工审批时，审批失败后不该简单重试，而应该把拒绝理由当作工具调用的返回值写回轨迹。
作者的论证是从提议模型的视角出发的：在它看来，审批拒绝就是一次工具调用失败，返回了错误信息和修正建议，
而 Agent 本来就具备处理工具失败的能力，审批只是多了一个输入源。
这个视角比我以前想的「拦一道」要顺。拦下来之后如果不把原因喂回去，模型下一轮还会提同样的请求。
配套还有一条原则：如果操作结果可以被验证，就应该自动验证。
写完文件立刻按类型调 linter，把输出解析成结构化错误列表随返回值一起给模型。
异步是模型的原生缺陷
书中判断，当前模型在异步环境上有原生缺陷，提示工程补不了。原话是「编排让行为成为可能，训练让行为变好」。
作者给了一套让同步模型支持异步打断的工程方案，其中一条是：LLM 思考中被新事件打断时，直接丢弃当前思考、不写入轨迹。
那被打断的任务，后续就只能只能重新开始。
5. Coding Agent
可验证性才是优势来源
作者说，面向开放任务的通用 Agent，其核心是一个 Coding Agent 加一个文件系统。
理由是所有高效的内容生成最终都要落到代码上：PPT 是 OOXML，Word 和 PDF 可以代码生成，数据分析靠 Python，连浏览器操作序列都能固化成可复用的代码。
但真正让我改变看法的是这个判断：Coding Agent 成熟度高，不是因为代码生成模型特别强，
而是因为软件工程几十年攒下的基础设施（测试套件、类型系统、版本控制）天然构成了一套强 Harness。
这条把「模型能力」和「工程红利」剥开了。以前我默认 Coding Agent 好用是因为代码数据多、模型训得好，忽略了另一半原因：我们早就为代码准备好了可验证性。
代码还有一层价值，作者叫它元能力：代码是「能创造其他能力的能力」。
Agent 用它当场写出新工具、新约束、新表达形式，不必事先把所有能力预制好。业务规则那部分尤其贴切。
「购买后 7 天内可退款」看着清楚，7 天是自然日还是工作日、购买是下单还是发货都没界定，写成代码就没有歧义，要么跑通要么抛错。
可靠性不是不犯错
书里关于错误处理的那段我几乎是逐条记的。
故障分四层：
- API 层（限流）
- 工具层（幻觉调用）
- 上下文层（溢出、压缩失败）
- 控制流层（死循环）
检测分两步，先分类再计数。单次错误之外还要检测模式，典型手法是对「工具名 + 参数」算指纹，同一指纹反复出现就是无进展循环的明确信号。
恢复走分级升级，终止靠熔断器加全局上限加人工升级。
落点是一句话：Agent 的可靠性不取决于它犯不犯错，而取决于每类错误是否都有对应的检测、恢复与终止路径。
这个框架跟我之前在稳定性那篇里想说的是一回事，只是当时没有把「检测、恢复、终止」这三段分得这么清楚。
还有一个工程细节值得记：SDK 的超时机制往往只覆盖初始连接、不覆盖传输过程，所以生产级 Agent 需要自己加一个空闲看门狗，
超过设定时间没有新输出就判定卡死，主动杀掉挂起的流再重试。这个坑很隐蔽，出问题时看起来像模型不响应。
6. 评估
评的是模型加 Harness
书里第一句话就把评估对象改了：评估对象不应只是模型，而应是模型与 Harness 的组合体。
同一模型在不同 Harness 里表现可以悬殊，有些团队仅靠优化 Harness 就显著提升了它在终端类任务上的表现。
有两条我觉得可以直接贴在工作台上的话：
评估体系不是为了给模型打分，而是让你快速、可靠地跟上模型的演进。
外部评估告诉你「Agent 有多好」，内部评估基础设施告诉你「哪个改变让它变好了」。
我读这一章本来是想补面试的知识点，这块问得不少，我一直没系统梳理过。
读完发现更有价值的是这个区分：外部榜单回答的是选型问题，内部回归回答的是迭代问题，两件事需要完全不同的投入。
评估环境是舞台，数据集是剧本
书里的原话是：剧本设计的好坏往往比舞台本身更能决定评估的价值，一个设计糟糕的数据集，即使跑在完美的环境里，得到的也只是噪声。
具体手法上，Rubric 评分是四维度各 1 到 4 分：操作正确性、政策合规性、信息完整性、幻觉检测。
四条设计准则里有一条是自包含，每个评价项独立可操作，不依赖评价者的领域知识。
这条在做 LLM-as-judge 时特别关键，否则评判模型自己就得靠猜。
书里还讲了奖励作弊的防范，明确要惩罚三类行为：幻觉、讨好用户、关键词堆砌。
以及古德哈特定律，当一个度量指标变成优化目标时，它就不再是好指标。
Agent 越是在某个评分系统上训练，就越倾向钻这个系统的漏洞。
应对办法是多评委独立打分加红队对抗式评审，
构造三类样本：
- 表面完美但含隐蔽错误的
- 靠关键词堆砌蒙混的
- 利用评判模型已知偏见骗高分的
这个思路有点像混沌工程，主动制造难看的样本，而不是等着线上出问题。
评估和训练是同一件事的两面
这一章最有意思的连接是：仿真环境是评估到后训练的桥梁。
一套定义清晰的 Rubric 或者验证器，就是一个可验证奖励的奖励函数，判分脚本可以直接当奖励脚本用。
评估环境与后训练环境往往同源。设计良好的评估环境稍加改造就能变成训练环境，SWE-Gym 就是基于 SWE-Bench 构建的训练任务。
这意味着评估的投入产出比，比看起来高得多。如果评估集做得好，它同时是回归测试、选型依据，也是后面训练的场地。
7. 后训练
SFT 记形，RL 求神
书里对两个阶段的定位很干净。
SFT 用极高的样本效率，把一套稳定的输入输出映射和协议固化进参数，它固化的是格式、风格、流程这类「怎么说、怎么做」的知识。
RL 是在此基础上探索策略、获取泛化。
作者打了个比方：
- SFT 是在别人画好的地图上临摹，最多和地图一样好；
- RL 是自己拿着指南针探路，有机会走出地图。
两阶段是顺序依赖，不是可替换。SFT 先把话说利索，输出格式稳定可解析了，RL 才有能打分的起点。
数据和环境比算法重要
这条是工业界的反直觉经验：算法的重要性远不及仿真环境的保真度、训练数据的质量、基础模型的能力。
合理的用力顺序是先选强基础模型，再打磨环境和数据，最后才在算法和超参上做边际优化。
动手调算法之前应该先自问：我的仿真环境像真实世界吗？书里举的反例是「客服复读机」，环境不保真，策略必废。
还有个数字上的不对称值得记：RL 的成本大概是 SFT 的几十倍。
奖励的不对称性
这一节是我觉得整章最锋利的地方：既然检测坏动作便宜可靠、判定进展昂贵易错，那么环境能可靠提供的密集信号，就是路径上的惩罚，而不是进展上的奖励。
这个不对称性决定了方法的形状。所以有「奖励结果、约束过程」这类做法，而不是硬去给中间步骤打正分。
8. 持续进化
学习不会自动发生
这一章从一个反问开始：如果上下文窗口无限长，把 Agent 经历过的所有对话和工具调用结果都塞进去，它是不是就自动学会一切？
作者的答案是不行，而且理由比「窗口不够长」更根本：哪怕上下文真的无限大，这道鸿沟依然存在，信息就在那里，却没人替模型完成从具体记录到一般模式的那步压缩。
我在旁边补了一句自己的理解：注意力擅长查找，不擅长统计，上下文越长噪声越多，注意力会被稀释。所以这不是窗口大小的问题，是机制的问题。
结论是：学习必须被显式设计出来。闭环四步是完成任务、提炼经验、存入外部系统、检索复用。
最容易被忽略的一条路径
作者说外部化学习是开发者最容易忽略的一条路径，把知识沉淀到模型之外的文件、知识库和工具里，持久、可解释、可随时修正。
Skills 的价值就在这：用人类可读的文本承载知识，于是更新快（不用重训）、可审查（专家能直接改）、可迁移（换模型换系统都能用）。
Anthropic 还有个 Skill Creator，让 Agent 通过观察和总结把领域操作知识提炼成结构化 Skill，不光能用 Skill，还能造 Skill。
有个我卡住的问题，作者也在前面留成了思考题：沉淀下来的规则会随时间膨胀，怎么做垃圾回收？
清理冗余或过时的条目，由谁做、按什么标准做。
可能随着模型越来越强，以前很多的约束、或者引导，都可以去掉。
用官方提供的 RSI 工具可能会比较好。
9. 交互与多 Agent
实时性把多模态问题变难的地方集中在三个场景：语音对话、GUI 操作、机器人控制。
语音架构有级联、端到端全模态、全双工三种范式，真正的矛盾在毫秒级的响应期待和秒级的深度思考之间。
多 Agent 那一章我认为最有用的一句是「关键是上下文隔离」。
Agent 之间不共享上下文，通信走三条通道：工具调用的参数、共享文件系统、消息总线。
多智能体怎么拆，我在《Agent Orchestration》里按「要隔离什么」分过三种。
协调方的上下文预算是具体的：Manager 只装任务的整体描述和目标、各阶段的执行计划、每个 Agent 的调用记录和返回结果、当前进度，不装每个子任务的完整内容。
移交时要传三类：
- 任务描述（含验收标准）
- 事实与约束（用户偏好、业务规则、前序决策）
- 结构化产物的引用（给文件路径而不是文件内容，接收方按需读）。
第三条是我以前做得不够的地方，直接传内容会让上下文迅速膨胀。
关于多 Agent 的去中心化，作者的收束是「分布式执行 + 集中式契约约束」，让 Agent 在确定的协议、有限的预算和显式的责任链条内自由协作。
他的理由是：人类社会的历史证明，绝对的无层级自由往往导致混乱。
我的反驳
作者对 Harness 的未来是看衰的，认为模型会一层层把它吃掉，收尾处也留了这个问题。
我不太同意。智能越来越高、工具越来越复杂，但工具从没消失过，只是换了个层次。
今天的程序员不直接操作寄存器，可寄存器这层还在，只是被封装了。
模型吃掉的是当前这层 Harness 的具体实现，不是 Harness 这个层次本身。
等到模型能力更强，上面会长出新的约束和验证需求，因为这些需求来自业务和责任划分，不来自模型能力不足。
10. 参考
- bojieli/ai-agent-book · 全书正文与 109 个配套实验，本文引用的判断与数据均出自此书
- LoCoMo 基准 · 超长多轮对话的记忆评估基准
- Mem0 · 提取、对比、决策三阶段的记忆框架