本文是对《引言》的学习记录。它不是原文摘要，而是我读完后重新整理的一张“认知地图”。

刚开始接触 Agent 时，我很容易被名词牵着走：Skill、Harness、Loop Engineering、Multi-Agent……每隔一段时间，行业似乎都会发明一套新的语言。

但这篇引言给我的第一个提醒恰好相反：不要从热词出发，要从问题出发。 很多后来被正式命名的工程方法，早已在真实系统中出现。名称会变，模型会升级，但复杂任务里的可靠性、安全性和可审计性不会凭空消失。

一句话读懂全书

如果只能从引言里带走一个公式，我会选：

Agent = LLM + 上下文 + 工具

它可以被翻译成三套彼此对应的语言：

直觉层 工程层 强化学习视角
大脑 LLM Policy（策略）
眼睛 上下文 Observation Space（观察空间）
手脚 工具 Action Space（动作空间）

这是一种帮助入门的直觉映射，并非严格的一一等同：上下文承载具体观察与历史，工具则提供观察和行动的接口。模型再聪明，如果看不到必要信息，就只能猜；信息再完整，如果没有行动接口，也只能给建议；工具再丰富，如果缺少能做判断的模型，只会变成一堆孤立的 API。

真正的 Agent 能力来自三者协同，而不是某一个组件单独“堆料”。

这本书为何强调“实践在前，命名在后”

这本书源自 2025 年的 AI Agent 实战课程，也源自 Pine AI 在账单协商、退款投诉、订阅取消等真实业务里的长期实践。这样的任务有几个共同点：

  • 流程可能持续数小时甚至数周；
  • 需要和真人进行多轮沟通；
  • 中间一步出错，就可能带来实际经济损失；
  • 最终结果必须可验证、可追踪、可恢复。

也正因为业务“足够难”，系统才不能满足于做出一个看上去不错的 Demo。动态加载提示词、命令行工具、状态栏、验证与纠错循环等做法，都是被真实问题逼出来的，后来才分别归入 Skill、Harness、Loop Engineering 等概念。

我对“实践在前，命名在后”的理解是：名词负责压缩共识，问题才负责推动设计。 如果只追逐名词，很可能学会了最新的表达，却没有建立判断架构好坏的尺度。

两个容易被忽略的前提

引言提出，要更早发现真正重要的 Agent 工程问题，需要两个条件。

1. 选择足够困难的真实任务

简单业务很容易被下一代模型直接覆盖，也很难暴露系统性短板。只有任务足够长、风险足够高、反馈足够真实，团队才会认真面对权限、恢复、状态管理和审计等问题。

这也解释了为什么“能回答”不能等同于“能办事”。聊天机器人可以用自然语言掩盖不确定性，但执行型 Agent 最终要接受环境结果的检验：钱是否退回、表单是否提交、代码是否通过测试。

2. 建立 Evaluation 机制

没有评估，一次改动后的“感觉更好”可能只是随机波动。评估把 Agent 开发从经验判断变成可比较、可复现的工程过程。

这里有一个很实用的顺序：

  1. 先定义任务完成的证据；
  2. 再运行 Agent；
  3. 保存过程与结果；
  4. 最后判断改动是否真的提升了系统。

也就是说，评估不是项目最后补上的考试，而应该是设计工作的起点。

我眼中的全书地图

全书十章可以压缩为两条主线：

主线 章节 要回答的问题
构建 Agent 第 1—6 章 Agent 如何获得大脑、眼睛和手脚，并与环境稳定交互？
提升 Agent 第 7—10 章 如何度量能力，并通过训练、经验和协作持续提升？

再展开一点：

  • 第 1 章先建立概念地图；
  • 第 2—4 章分别深入上下文、记忆与知识、工具；
  • 第 5—6 章把 Agent 扩展到代码、文件系统、图形界面、语音和物理世界；
  • 第 7 章用评估建立反馈；
  • 第 8—9 章分别讨论模型参数与外部产物如何进化；
  • 第 10 章把单体能力扩展成多 Agent 协作。

这个结构让我意识到，本书并不只是一本“如何调用 LLM API”的教程。它真正关心的是：智能系统如何观察世界、采取行动、接受反馈，并在工程约束下持续变好。

Whisper Coding：写作方式本身也是案例

引言中一个很有意思的细节是，本书采用了大量 whisper coding（口述式协作）：作者口述提纲，语音 Agent 调研资料并形成草稿，再结合课程反馈反复核查与修订。

这不是“让 AI 代写”，而是一种新的知识生产流水线：

提出问题 → 口述想法 → Agent 检索与整理 → 形成草稿 → 人工核查 → 继续迭代

Agent 降低的是“把想法外化”的摩擦，而人仍然负责问题意识、事实核验和最终判断。对我来说，这也是使用 Agent 时很值得保留的边界：把生成和整理交给系统，把责任和判断留给人。

我的阅读策略

结合引言给出的建议，我会这样读：

  • 第一遍先读第 1、2 章，建立 Agent 与上下文工程的整体框架；
  • 第二遍边读边运行每章实验，不把“看懂”误当作“会做”；
  • 第三遍从自己的项目中选一个真实失败案例，用书中的架构原则重新分析；
  • 遇到 KV Cache、后训练等偏底层内容时，先记核心结论，再按需要补原理。

配套实验入口在第一章实验导航，完整代码仓库按 chapter1/ 到 chapter10/ 组织。

读完后，我留下的三个问题

  1. 我的 Agent 当前失败，究竟是模型不够强，还是它看不到信息、没有合适工具？
  2. 我如何证明一次 Prompt、工具或流程修改真的有效，而不是“这次刚好运气好”？
  3. 当模型升级后，哪些 Harness 应该删除，哪些安全边界仍然必须保留？

写在最后

这篇引言最打动我的，不是某个具体框架，而是一种很朴素的工程观：让真实问题暴露差距，让评估提供反馈，让设计原则穿越模型迭代。

模型能力变化太快，背诵今天最流行的产品和术语注定会过时。更值得学习的是判断方法：Agent 看到了什么、能做什么、如何知道自己做对了，以及失败之后能否安全恢复。

带着这四个问题进入第一章，会比带着一长串框架名字更有用。

继续阅读：第一章学习笔记：从会聊天，到真正把事情办完。