AI Agents in Depth · 全书学习专题
这本书回答一个问题：把一个 Agent 从「能跑的 Demo」做成「可靠的产品」，中间差了什么。它的答案不是某个框架或某个模型，而是一套围绕模型构建的工程体系。
Agent = LLM + 上下文 + 工具
= 大脑 + 眼睛 + 手脚
对于「模型变强后会不会吃掉 Harness」这个问题，书中的回答是：方向上不怀疑模型会持续内化 Harness（工具调用、长程规划都曾靠外部编排，如今已是原生能力）；但节奏上这个过程远比想象中慢——训练以月计，模型也无法一次内化真实业务中所有约束与偏好。
模型此刻的能力边界，就是 Harness 此刻的价值所在。模型每内化一层，Harness 就卸下一层，转而兜底新的能力前沿。
核心公式与全书地图
书中给出两个公式。它们不是并列的两套骨架，而是同一事物在不同抽象层次上的描述：
Agent = Model + Harness
Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正
Agent ↔ Environment # Agent 与环境是交互的两方，不是彼此的组成部分最小 Demo 只需 Model + 能构造上下文、暴露工具的 Harness；生产系统还要在同一边界内加入约束、验证和纠正。
Harness 不是「模型之外的一切」，而是 Agent 边界内、模型之外的运行与治理层。工具定义、调用适配器、沙箱的权限与重置机制属于 Harness；沙箱内随行动变化的文件和进程、外部数据库、网页、用户及物理世界属于 Environment。
物理部署位置不能决定概念归属——即使仿真环境与 Agent 运行在同一进程中，它仍然是 Environment。
全书三段结构
五个工程范式：层层包含，而非彼此替代
| 范式 | 关注范围 | 核心问题 |
|---|---|---|
| 提示工程 | 输入给模型的自然语言指令 | 怎么把话说清楚 |
| 上下文工程 | 模型能看到的所有信息 | 模型能看到什么 |
| Harness 工程 | Agent 如何组织模型运行并与环境交互 | 怎么可靠地做事 |
| Loop 工程 | 跨轮次的持续自主运转 | 谁发现下一件该做的事、何时才算真正完成 |
| Graph 工程 | 显式执行图：节点承担能力，边规定路由 | 整个流程如何编排与持久化 |
当各家模型的能力越来越接近、不再是决定性差异时，竞争优势就转移到了模型之外的工程实践。书中给出的例证：LangChain 在 Terminal Bench 2.0 上把得分从 52.8% 提到 66.5%（排行榜 30 名开外跃至前 5），改变的不是模型，而是 Harness。
CH 1AI Agent 入门
思考题 10 道
三大组件与两个可扩展的空间
| 直觉理解 | 实现组件 | 学术概念 | 含义 |
|---|---|---|---|
| 大脑 | LLM | 策略（Policy） | 面对当前信息，从所有可选行动中挑出最合适的一个 |
| 眼睛 | 上下文构造 | 观察与历史 | 把环境返回的观察与已有历史组织成决策所需的信息 |
| 手脚 | 工具与适配器 | 观察/行动接口 | 规定可读取哪些观察、发出哪些行动，以及接口格式 |
在底层模型固定时，提升 Agent 任务表现最主要的系统工程手段，往往就是重新定义或扩展观察空间与动作空间——用本书的术语说，就是扩展上下文和工具。
许多看似需要「更聪明模型」的问题，其实只是接口问题：把任务所需数据纳入上下文，或把所需操作封装成工具，原本不可解的任务就可能变得可解。
两个产品例证：Manus 把 Deep Research、Coding、Computer Use 三条原本独立的路线合并进同一个生产级 Agent——取三类 Agent 观察空间与动作空间的并集；OpenClaw 又把接口延伸到用户的数字生活（多种消息渠道 + 本地 Gateway 连接云盘与本地文件系统）。
上下文的五个组成部分
Agent 的上下文 = 静态前缀 + 轨迹。ReAct 循环的本质，就是通过不断向轨迹追加内容来让模型持续推进任务。
① 上下文组件并不等价。去掉工具定义或工具执行结果会直接夺走行动与闭环能力；去掉思考过程与历史消息的代价，则取决于其承载的信息能否从当前观测重建。
② 「给出了回答」不等于「完成了任务」。上下文残缺时典型的失败不是报错退出，而是一个看上去毫无破绽的答案——数据其实来自参数记忆，排版与真正基于观测的答案一模一样。
编排模式：从简单到复杂
优势：严格流程控制（「付款前不能预订」由代码强制）；安全性——攻击面被限制在单个节点内。
局限：缺乏变通，预设未覆盖的情况无法灵活应对。
优势：适合开放式问题，能识别失败并调整策略。
局限：成本更高、有复合错误风险，必须设计明确的停止条件。
书中给了一个具体的反面例子：为「从百万条聊天记录提炼记忆」设计 Agent 时，AI 很容易迅速画出一条看似严谨的流水线（切分 → 提取 → 核验 → 身份解析 → 整理 → 合并复核 → 事实图 → 覆盖账本 → 不可变版本）。每个部件单看都有道理，组合起来却非常低效、不可靠——复杂工作流的执行拓扑是固定的，遇到新例外就继续加节点，架构越来越复杂、通用性越来越差，模型原本可以根据上下文处理的语义判断，反而被工作流写死了。
Manus 官网的概括是：“Less structure, more intelligence.” 好的结构不是替 Agent 预演全部思考，而是守住边界，并把边界内的决策空间还给模型。
构建有效 Agent 的三个核心原则
Harness 里那些给模型能力短板打补丁的部分，会随着模型变强被模型自己内化。仅在第一章里这样的事就发生了好几轮：few-shot 示例与「一步一步思考」被指令微调和推理模型内化；输出格式修复、JSON 解析容错被结构化输出和原生工具调用内化；文生图的提示词改写被原生多模态能力吃掉。每一轮内化，消灭的都是「翻译」和「脚手架」这类适配层代码。
CH 2上下文工程
思考题 9 道
一个中等能力的模型配上精心组织的上下文，往往能胜过一个顶级模型在信息匮乏下的盲目摸索。
OpenAI 研究员翁家翌的概括更直接：「人和模型一样，最重要的是 Context。」他还指出「团队合作中最大的问题也是 context 的不一致」，而「AI 短时间内无法取代人的最大原因也是 context——因为 AI 跟人并不在同一个环境里面」。
大多数团队的关键知识都是隐性的：架构决策只有老员工记得，业务规则靠口口相传，重要背景锁在私聊记录里。如果团队本身就是一个信息黑洞，再好的 Agent 也无计可施。
因此有一个判断：对远程工作友好的团队往往也对 AI Agent 友好。Linux 内核就是范例——高度透明、文档驱动，信息是公开的、可检索的、结构化的。构建 AI 原生团队，首先是一场文档化运动，而不只是部署新工具。
KV Cache：三条必须记住的结论
本章以一个真实故障开场：某团队为了让 Agent「知道」当前时间，在系统提示词里加了一行时间戳。第二天首 token 延迟从 0.5 秒涨到 3–5 秒，月度推理账单几乎翻了一倍。
Claude Code 的实践揭示了一个深层模式：当 Prompt Cache 的经济效益足够显著时，缓存一致性会反过来主导系统的架构选择：
- 提示词结构由缓存边界决定——每个运行时条件若放在缓存边界之前，就会把缓存键的变体数量翻一倍（N 个二值条件产生 2^N 种组合）
- 子 Agent 必须与父 Agent 字节级对齐——提示词、工具定义、模型配置、消息前缀、思考配置逐字节匹配才能命中缓存
- 工具结果的替换字符串在首次出现时就被冻结——即使会话重启也使用完全相同的替换串
缓存经济性不是事后优化，而是前置约束。
Agent 状态栏：把隐式状态变成显式知识
它「检索」的这一半非常强——你问什么，注意力就能从成千上万个 token 里把相关记录捞出来。但它缺了另一半：没有「提炼层」。上下文里的东西从来不会被自动数一遍、建个索引或就地总结成一条结论。
任何「关于这些内容的结论」——一共多少条、有没有超标、进展到哪一步——模型每次要用都得从原始记录里现算一遍，而代价随上下文堆积量上涨。
典型场景：系统提示词要求「拨打每个商家不超过 3 次」，但打了 3 次之后 Agent 经常数不清，又打了第 4 次甚至陷入循环。解法是在工具结果中直接标明「本次是第 3 次呼叫该商家」。
| 状态更新的两种实现 | 做法 | 缓存代价 |
|---|---|---|
| 每轮替换 | 移除上一轮状态，在末尾追加最新状态 | 失效范围只覆盖上次注入后新增的消息，整个前缀仍可复用 |
| 持久追加 | 状态消息永久留在轨迹中，每轮只追加新状态 | 对缓存完全友好，但陈旧状态会累积占用 token |
取舍公式（设状态 S token、两次更新间新增后缀 R token、更新 N 次、缓存单价为普通输入的 α 倍）：当 αSN/2 < (1−α)R 时倾向持久追加，否则倾向每轮替换。
① 状态栏尽量用代码维护。实验发现模型几乎无条件地相信状态栏——你写「打了 3 次电话」，它就当真是 3 次，不会自己重算。这也意味着状态栏投毒风险值得认真对待。
② 谨慎删除原始上下文。状态栏是对原始上下文的一次有损投影，只提前算了「你预想会被问到」的维度。一旦有问题涉及未计算的维度，仅保留状态栏会导致准确率断崖式下降。
Agent Skills：渐进式披露
name + description，常驻
SKILL.md 按需加载
引用的子文档
这是 KV Cache 前缀性质的直接推论：因果注意力决定了每个 token 的键值对只依赖它之前的 token，因此在末尾追加新内容不会改变任何已缓存 token 的 K、V。所以这不是「预编译」，而是「只增不改」的追加式注入。
一个易误解点：「追加到末尾」只发生在工具/Skill 被发现的那一轮。此后这个 schema 块就固定在轨迹原位置，成为普通历史消息，而不是每轮被重新搬到最新末尾。
上下文压缩：三个动机与一个隐蔽故障
它与上下文溢出是不同问题：溢出是「装不下了」，腐化是「装得下但找不到了」——后者更隐蔽，因为 Agent 表面上还在正常工作，只是决策质量悄然下降。无关内容一旦占到上下文的大头，决策质量就会明显下滑。
隔离优于压缩
压缩是在信息已经进入上下文之后做减法；子 Agent 上下文隔离则更釜底抽薪——让大体积中间信息根本不进入主上下文。同一个「在代码库中找处理支付回调的函数」任务：主 Agent 亲自搜索可能把数万 token 原始代码纳入主上下文；委派给搜索子 Agent，主上下文只增加两条消息（任务描述 + 结论）。
压缩是有损的、需要额外 LLM 调用的事后补救；隔离则让噪声从一开始就与主上下文绝缘，主 Agent 的 KV Cache 前缀也完全不受影响。
信息组织混乱导致任务成功率下降超过 30%（保留所有规则内容，只打乱组织结构、去除标题层次）。移除工具描述性文本则使工具调用错误率增加 45%。对人类友好的信息组织方式，对模型同样友好。
CH 3用户记忆和知识库
思考题 9 道
两个尺度解决同一个问题：用户记忆让 Agent 成为「懂你的助手」，知识库让 Agent 成为「领域专家」。两者共用向量检索、知识压缩等底层技术，也面临同样的麻烦：信息冲突、知识过期、检索不准。
记忆能力的三层次评估框架
| 层次 | 要求 | 例子 |
|---|---|---|
| 第一层 基础回忆 | 准确存储和检索用户直接提供的、结构化、无歧义的信息 | 「我的会员号是 12345」，后续需要时精确返回 |
| 第二层 多会话检索 | 面对不同对象、不同时期的多段会话，检索出所有相关信息并推理判断 | 用户有两辆车时说「为我的车预约保养」，应主动询问哪辆而非随便猜 |
| 第三层 主动服务 | 综合多个会话甚至很久以前的信息，提供预见性帮助 | 预订国际航班时主动关联数月前的护照信息，发现即将过期并预警 |
三套正交的分类体系
| 分类体系 | 回答的问题 | 具体类别 |
|---|---|---|
| 记忆层次 | 存在哪里？ | 轨迹（当前会话）、用户长期记忆（跨会话）、业务状态（任务阶段） |
| 存储格式 | 怎么存？ | Simple Notes、Enhanced Notes、JSON Cards、Advanced JSON Cards |
| 认知类型 | 存什么？ | 情景记忆（具体事件）、语义记忆（一般知识）、程序记忆（行为流程） |
Simple Notes（最小事实，O(1) 但丢失关联）→ Enhanced Notes（完整段落，语义完整但冗余）→ JSON Cards（三层嵌套，支持部分更新但结构刚性）→ Advanced JSON Cards（加入 backstory、person、relationship、时间戳）。
最后一种解决消歧问题：「张医生」可能是用户自己的牙科医生，也可能是父亲的心脏科医生——脱离情境就无法正确理解。
实践标准：关键且少量的数据用 Advanced JSON Cards 保证可检索性；大量且非关键的对话事实用 Simple Notes 降低成本；多数生产系统采用混合模式。
RAG 主流水线
懂语义
精确匹配
跨编码器
求职者把简历交给猎头快速筛选，是双编码器（查询与文档独立编码、靠向量运算比相似度，极快但无法捕捉深层匹配）；面试官与每位候选人深谈，是跨编码器（拼接成一段完整文字送入模型逐词比对，慢得多但更准）。
重排序并不替代融合：融合负责从两路结果产生统一候选池，重排序负责在候选池上精排。
为什么原始文档不加处理放进知识库远远不够
解法：预先生成摘要「共 100 只：90 黑（90%）、10 白（10%）」并索引。
注意：第二重障碍调大 k 也解决不了。
结论：必须在索引阶段投入计算资源，对原始知识主动提炼、抽象和结构化——把「100 个个体案例」压缩为统计摘要，把「散落在几百条工单里的个案」提炼为带边界的明确规则。
知识更新：把知识库当成代码库
把每次知识变更当成一个 Pull Request。不只适用于可执行记忆；Markdown 知识库、用户记忆文件和规则文档同样应进入 Git，获得差异审查、版本历史、责任追溯和一键回滚能力。
生产环境不应让任何一个模型绕过审核，直接改主分支或线上向量库。
- Proposer Agent 提交 PR：从原始证据发现新事实、冲突或过期内容，提出尽可能小而完整的 diff，同步维护链接、索引、时间元数据和证据引用
- Reviewer Agent 独立审核：拿到变更前知识、diff 和原始证据，独立检查每个断言是否被证据支持；退回时须给出指向具体证据和行号的可执行意见
- 双方迭代至收敛：设置最大迭代次数或成本预算，超限转人工，不能默认放行
- 合入后再发布：CI 检查格式、链接、元数据、权限标签，通过后才从已合入版本增量重建索引
① Proposer 和 Reviewer 都必须是 Agent，而不是两次固定的 LLM API 调用——它们要主动搜索相关文档、追溯证据、运行检查，需要文件搜索、版本比较、测试执行等工具。
② 两者应优先使用能力相近但来自不同家族的模型（如 Proposer 用 Claude、Reviewer 用 GPT）。不同训练数据与推理习惯可降低在同一处犯同类错误的概率；能力则不宜悬殊。
③ 索引是可重建的派生物，Git 中已审核的知识才是真正的来源。
增量更新及时，但每次只看到一个局部。长期运行后，多次局部正确的修改仍可能累积出全局问题。全量整理包含三项核心工作：去重去旧与合并、回到原始数据核查（不能只在已有摘要之间相互改写，否则早期遗漏会一代代传下去）、冲突解决与场景限定（不应简单「保留最新一条」，而要追溯各自信息源，检查是否分别在不同条件下成立）。
一旦敏感内容进入了 LLM 的上下文，就很难保证它不以某种形式泄露到最终回答里。多租户系统还需保证租户之间的向量索引和元数据相互隔离。
用 Advanced JSON Cards 把少量关键事实结构化后常驻上下文，提供随时可见的「概览」；用上下文感知检索按需从海量原始对话取回「细节」。
这解释了为什么第三层「主动服务」最难：它要求系统同时握有全局概览和精确细节——只靠常驻上下文会因容量受限丢失细节，只靠检索又会因缺乏全局视野发现不了跨会话的隐藏关联。
CH 4工具
思考题 4 道
| 工具类型 | 调用方向 | 作用对象 | 本书何处展开 |
|---|---|---|---|
| 感知工具 | Agent 主动调用 | 获取信息 | 本章 |
| 执行工具 | Agent 主动调用 | 改变世界 | 本章 |
| 协作工具 | Agent 主动调用 | 驱动其他 Agent 或人类 | 本章 |
| 用户沟通工具 | Agent 主动调用 | 向用户传递信息 | 第 6 章 |
| 事件触发工具 | Agent 注册、外部触发 | 驱动 Agent 开始执行 | 第 6 章 |
专用工具（结构化、确定性高，但每个占数百 token）｜通用执行器（可组合探索）｜Skill（自然语言描述，目录仅数十 token、人类友好，但参数复杂时易错）。
默认取向：通用工具优于专用工具，除非有明确的安全、权限或性能理由。四个决策维度：安全与权限、参数复杂度、变更频率、模型能力。
核心原则：通用基础能力用于组合与探索；专用工具用于约束高风险和强业务规则操作。
用代码串联多个工具，中间结果留在执行环境而不进入上下文，token 消耗可降约两个数量级。
工具描述与参数传递
工具太多怎么办：三层递进的答案
与按需加载
主动工具发现
把工具发现变成「按需查阅」
MCP-Zero：系统提示词不预置 schema，Agent 声明需求，两层语义路由匹配，在 2800 个工具上省约 98% token。核心转变是把「选哪个工具」变成「查哪条资料」。
执行工具的层次化安全
| 维度 | 提议者-审核者 | Sidecar |
|---|---|---|
| 执行时机 | 操作前（事前审批）或操作后（事后验证） | 与主模型流式输出并行，门控单次工具调用 |
| 审查对象 | 操作的合理性或结果 | 操作本身（工具调用） |
| 输入隔离 | 提议者和审查者看到相似信息 | 刻意隔离主模型的自由文本 |
| 典型用途 | 不可逆操作审批、文档生成、配置修改 | 权限分类、记忆相关性判断、工具输出摘要 |
① 幂等性：通过唯一标识去重或先查询后变更，使超时/打断可安全重试。
② 沙盒隔离的级别：进程级 → 容器 → microVM/虚拟机。注意：venv 不是沙盒。
MCP（Anthropic 2024 年底发布）用客户端-服务器架构统一专用工具接入，实现「一次开发，处处可用」；Skill Hub（skills.sh、ClawHub）靠注册表而非协议分发 SKILL.md，token 成本比 MCP 便宜一到两个数量级。
两条渠道都把引入一条能力的成本压到了一条命令，也都扩大了信任边界——必须审查描述与版本、隔离凭证，并保证模型看到的参数与工具真正执行的参数一致。
CH 5Coding Agent 与通用 Agent
思考题 9 道
以开放任务为目标的通用 Agent，其核心是一个 Coding Agent + 文件系统。从 Manus 到 OpenClaw，成功的开放任务型通用 Agent 都遵循这一范式。
为什么？几乎所有高效的内容生成最终都要落到代码上：PPT/Word 本质是 OOXML，PDF 可由 Markdown/HTML/LaTeX 生成，数据分析靠 Python，成功的浏览器操作序列也可固化为代码。Computer Use 通用性更强，但成本、延迟和稳定性远不如直接通过代码或 API。
七个核心工具
书中说明：其实只要一个 Bash Shell 就足够了（OpenAI Codex 就只提供这一个工具），七个是为了方便理解 Coding Agent 所需的基本能力。
为什么 Coding Agent 特别适合 Harness 工程
| 结果可自动验证 | 结果需人工验证 | |
|---|---|---|
| 目标明确 | 最佳区域修复有测试用例的 bug | 吞吐量受限代码重构需人工审查 |
| 目标模糊 | 高效地跑偏用 linter 优化「代码质量」 | 难以启动「让 UI 更好看」 |
不是因为代码生成模型特别强，而是因为软件工程几十年积累的基础设施天然构成了一套强大的 Harness——测试套件提供验收标准，Linter 和类型检查器提供即时验证，Git 提供完美的版本控制和回退。
四条可迁移的 Harness 设计原则
验收基线管结果对不对，执行边界管过程——即使结果正确，用错误方法达成也不行：修复数据库故障时直接把库删了重建（「修复」生效，但数据没了）；修复编译错误时把代码全删重写（编译通过，但实现没了）。
这类破坏性捷径总是存在：即使把限制写进最终评估指标，Agent 也常能找到绕过去的办法——这正是 reward hacking 在 Agent 任务中的日常形态。因此约束的是动作而非仅仅是结果。
故障与错误恢复：四层故障、分级恢复
| 层 | 典型故障 |
|---|---|
| API 层 | 限流、服务过载、请求超时、连接中断、输出触顶被截断 |
| 工具层 | 幻觉调用、参数畸形、执行抛异常，以及最危险的——工具反复返回同一错误而模型不加改变地反复重试 |
| 上下文层 | 窗口溢出、压缩失败、轨迹结构损坏（工具调用缺少配对结果） |
| 控制流层 | 死循环、死亡螺旋（错误触发的恢复逻辑自身又调用 LLM、再次出错、连锁反应） |
Agent 因上下文溢出停止 → 触发「结束时自动提交代码」的停止钩子 → 钩子调用 LLM 生成 commit message → 再次上下文溢出 → 又一次触发钩子。
防护靠两条：在错误路径上禁用一切会再次调用模型的副作用逻辑；用递归深度计数器检测并打断残余连锁。
Claude Code 压缩熔断「连续 3 次」的阈值来自真实统计——曾有一个会话在这条恢复路径上连续失败三千余次，仅这类无效重试每天就在全球造成约 25 万次 API 调用的浪费；逾千个会话出现过 50 次以上连续失败。3 次正是「绝大多数故障已恢复」与「继续重试基本无望」之间的经验拐点。
在确认无法恢复之前，中间错误不应暴露给消费者——恢复期间扣留错误消息，恢复成功则消费者毫无感知，所有手段均失败后才统一呈现。
模型的思考通常由可读文字 + 厂商附加的凭证构成。换一家模型仍读得懂文字，凭证换一家就失效；各家对凭证的要求还不一致，宽松的一端不做校验，严格的一端拒绝一切非自己签发的凭证。
设计原则：轨迹不该按任何一家的接口格式存储，而应保存为中立格式——思考拆成可移植文字与不可移植凭证，工具调用只记名称与参数，标识符在渲染时按目标厂商重新生成。中立轨迹的价值也不限于故障切换：第 7 章的评估重放、第 8 章的训练样本构造、第 9 章的经验提取，依赖的都是同一份产物。
代码作为元能力：六个方向
SQL 查询场景中，让 Agent 执行 SQL 后用自然语言描述结果效率极低——不仅消耗大量 token，更严重的是 LLM「抄写」数据时非常容易出错。
更好的方案：Agent 生成 SQL 作为独立可执行产物，系统直接查库并渲染表格。数据从数据库直达用户界面，完全绕过 LLM 这个「中间人」。
当接口、工作流乃至数据访问代码都由 Agent 随时生成时，应用层不再稳定。安全目标不能是「保证 AI 每次都把权限检查写对」，而应该是：即使 AI 写错了代码，权限约束仍然无法被绕过。
做法：数据库行级安全策略、约束与校验器、受控视图或数据访问服务，加上由受信任运行时绑定、无法伪造的访问上下文。必要条件是所有数据访问路径都必须经过受信任的数据层。
致命三要素 + 第四个维度
本书补充
第四项不是并列的必要条件，而是攻击的放大器：攻击者可将看似无害的偏见或恶意指令写入长期记忆，跨会话潜伏，把一次性攻击升级为长期威胁。
模型训练中形成了朴素默认——「谁在跟我说话，我就尽力帮谁」；但真实 Agent 常处在多方委托处境：替你砍价的 Agent，对面坐着的不是「需要被帮助的用户」，而是交涉对手。
实测显示一条忠诚度光谱，两端都会翻车：一端太老实（把底价直接抖给对手，被反复施压几轮就缴械）；另一端太多疑（连主人正当请求也拒绝）。这两种失败是一根跷跷板，很难两全。
提示注入本质上就是一次策反。因此 Harness 层要明确限定忠诚对象：主人指令优先级最高，一切来自外部交互方的内容默认降格为「可参考、但不具备指令效力」的数据。
模型与脚手架之间是此消彼长的关系。模型足够强时脚手架可以更薄，代码求解器的增益随之收窄；模型不够强时就得在脚手架里做更多事。同一套脚手架配上不同能力的模型，得到的结论可能截然不同——这是评估一项 Agent 技术时容易被忽视的前提。
CH 6交互：观察与动作空间的扩展
思考题 12 道
| 观察空间的扩展 | 动作空间的扩展 | |
|---|---|---|
| 内容（第 2–5 章） | 上下文工程、记忆与知识库 | 工具、代码生成 |
| 模态（本章） | 语音、屏幕、物理传感器 | 说话、点击、关节运动 |
| 时机（本章） | 世界主动推送、连续流 | 跨回合、可打断、可抢占 |
回合制是模型与接口的一种交互约定，不是环境的性质。真实环境不会等模型作出反应：邮件在它思考时到达，用户在它说到一半时插话，页面在两次截图之间已经变了样，杯子在机械臂伸手的途中被碰倒。
| 尺度 | 场景 | 观察侧的变化 | 动作侧的变化 |
|---|---|---|---|
| 秒 — 天 | 异步与事件驱动 | 会被外部事件主动唤醒 | 动作跨回合：先发起，后续靠事件收尾 |
| 10 毫秒 — 1 秒 | 语音 | 边说边听，不等一句说完 | 边想边说，可被打断 |
| 亚秒 — 秒 | Computer Use | 屏幕在两帧之间持续变化 | 动作后必须重新确认现实是否仍符合计划 |
| 毫秒 | 机器人 | 传感器连续回流 | 动作分块：一次规划一小段，可被抢占 |
事件处理的三种策略
例：用户输入「停！我说错了」。
例：Agent 调用搜索后用户补充「只看最近一个月」，搜索结果返回时两个事件一起呈现，避免不必要的往返。
并行处理（独立轻量查询）：主任务分析大量数据时用户问「今天天气怎么样」。这类查询与主任务无关、需快速响应、成本低——用取消式会打断主任务，用队列式让用户等太久，应在并行推理会话中独立执行，并明确标记为「与主任务并行执行」以免 LLM 混淆。
硬编码规则有局限——事件的语义决定了处理方式：「马上停下来」用取消式、「今天天气怎么样」用并行式、「报告需要用中文发给我」用队列式。
核心思想：常态下让 LLM 看到标准同步轨迹，只在打断时插入占位符修复格式。但占位符带来语义风险——模型可能把「任务已启动」误当成「任务已完成」，在真实结果返回前作出依赖该结果的判断。应通过明确的任务状态和结果校验防止混淆。
工具接口设计层面的改进：把 phone_call 改成 initiate_phone_call——工具的名称和描述本身就要传达异步语义。
语音：三种交互范式
| 范式 | 核心结构 | 主要优势 | 主要限制 |
|---|---|---|---|
| 级联 | VAD → ASR → LLM → TTS | 模块清晰、易替换、易调试 | 延迟累积，副语言信息在接口处丢失 |
| 端到端 Omni | 原生音频输入输出，按轮次交互 | 延迟较低，能保留语气、情绪和环境声 | 仍依赖轮次，训练和调试成本较高 |
| 全双工 | 持续听、说和决策 | 支持重叠说话、自然打断和连续流 | 模型训练、控制和评估都更复杂 |
贯穿三种范式的主线：如何摆脱「轮流说话」和 VAD 对发言权的猜测。只有全双工把「该谁说话」变成模型的持续决策。
它还是一种让交互能力与智能上限分别演进的模块化选择：前台快模型负责低延迟倾听与维持对话，后台慢模型负责推理与工具调用；更强的思考模型发布后只需替换后台，不必重训整套实时语音系统。统一路线则把推理与交互绑定在同一训练周期。
实证：截至 2026 年 8 月，采用快慢分离的 Pine AI 语音 Agent 在 τ³-Voice Leaderboard 取得第一名，超过 Grok Voice、GPT-Realtime-2 等实时语音系统。
① 语音通路的端到端：模型直接收发音频，不经离散文本串接（Omni 和交互模型都属此类，但 Omni 通常仍按轮次推进）。
② 认知架构的端到端：实时交互与深度思考是否在同一模型内共享状态、共同训练。
两条轴彼此独立——一个系统完全可以在语音通路上端到端，同时在认知架构上保持快慢分离。
Computer Use：三条视觉定位路线
| 路线 | 做法 | 适用条件 |
|---|---|---|
| 结构化元素索引 | 从 DOM / Accessibility Tree 枚举可交互元素并编号 | 结构化信息可得时优先定位最精确稳定 |
| 纯视觉标注（SoM） | 用分割模型在像素上切出候选区域并叠加编号 | 原生桌面软件、Canvas/WebGL、游戏；对未专门训练的通用模型更友好 |
| 纯坐标预测 | 训练模型直接输出坐标 | 对做过 GUI 定位训练的模型更直接；需按宽高比选目标分辨率做双向缩放 |
前两条的共同优势：把开放式的「找到按钮并预测坐标」转化为封闭式的「从已标注元素中选一个」——就像选择题比填空题更容易答对。
每 3–5 秒才睁一次眼、且完全没有耳朵的 Agent，对「两帧之间发生的事」既看不见也听不到。真正该被重新设计的不是动作接口，而是观察接口：屏幕关键帧截图（小模型判断是否发生有意义变化）、音量门控的语音转写、用文字描述画面（原图之后被清理出上下文，这句文字仍留在上下文里）。
真正卡住移动端的往往不是技术差异，而是商业模式冲突：传统互联网应用的核心变现逻辑是流量与注意力，而 Agent 代替用户操作时这条链路被彻底绕过——AI 不会关注广告，也不会冲动消费。这是一个结构性的利益冲突，短期内难以调和。
机器人：一个诊断实验
成本只有几百美元的机械臂，通过遥操作已经能完成连续多步桌面任务。这不只说明「硬件勉强可行」，更是一个明确的诊断证据：对于这个任务，硬件本体不是瓶颈，算法才是瓶颈。
诊断方法很直接：保持摄像头、机械臂、桌面布置和成功条件不变，先让人接管闭环。自主系统与人的差距，正体现在那些闭环能力上（靠近时减速、滑动时修正抓取点、失败后重新观察）。
| 层级 | 核心问题 | 典型时间尺度 |
|---|---|---|
| 任务目标 | 人想完成什么 | 分钟级 |
| 长程规划 | 先做什么、后做什么 | 秒到分钟 |
| 基本技能 | 当前要完成哪个状态变化 | 约 1—3 秒 |
| VLA / 技能策略 | 这个技能具体怎么动 | 约 1—10 Hz 推理 |
| 底层控制与安全层 | 如何稳定、及时地执行 | 约 50—1000 Hz |
大模型每秒通常只能推理 1—10 次，控制器却需要几十到上千次更新。动作分块把推理等待藏在执行时间里，但动作段越长，运动越平滑，模型在这段时间里看到的新画面却越少——伸手抓杯子时杯子被碰动，它可能仍在执行根据旧画面生成的动作。
训练数据有限（机器人演示远少于互联网文本）｜只学会模仿，不一定懂后果（行为克隆没有要求模型回答「这个动作会造成什么结果」）｜机器人各不相同｜观察可能过时。
所以：语言模型知道「杯子」是什么，并不代表它知道摩擦、接触、液体晃动会怎样改变未来状态。VLA 主要回答「现在应该做什么」，还需要世界模型帮助判断「做了之后可能发生什么」。
但也要划清界限：「会生成视频」不等于「能指导机器人动作」。世界模型必须知道动作是什么，并能预测动作对物体和环境的影响；预测只能帮助选择，不能代替验收。
持续感知
→ 判断当前状态与时机
→ 选择回复或动作
→ 让输出进入环境
→ 观察反馈
→ 继续、修正、重试、停止或重新规划也共享同一组原语——唤醒、安全点、取消、抢占、快慢分离。
CH 7Agent 的评估
思考题 9 道
评估的对象不应只是模型，而应是模型与 Harness 的组合体。同一个模型在不同 Harness 中表现差异悬殊。完善的评估体系应能区分「模型能力不足」和「Harness 设计缺陷」这两类本质不同的问题。
区分手段——模型替换实验：固定 Harness 只换模型。换强模型分数不涨 → 瓶颈在 Harness；分数随模型能力大幅波动 → 瓶颈在模型。注意这与消融实验不同：消融是关闭 Harness 组件看整体变化（定位内部哪个部件重要），模型替换是固定 Harness 只换模型（区分瓶颈在哪）。
评估指标：两个容易混淆的口径
适合科研发现、漏洞挖掘、开放式创作：人类可以从 k 条候选中挑出最好的那条。
Manus、OpenClaw 早期成功率不高、成本很高，但通用性带来较高 Pass@k，这些「技术奇观」在社交网络被大量分享，是产品成功的关键。
单次成功率 p=0.6、k=5 时：
Pass@5 ≈ 99.0%（看起来几乎总能成功）
Pass^5 ≈ 7.8%（连续五次不出错仍很难）
后者才接近支付、退款、权限变更、生产部署的要求。
评估环境的五个组成要素
必须可重置
原子操作
不应存在「解决用户的上网问题」这类高层抽象——抽象层次过高会使评估退化为对单次函数调用的考察，规划与推理环节被工具本身吸收。
τ-bench → τ²-bench：五处重新设计
| 暴露的问题 | 改法 |
|---|---|
| 任务指令过于笼统，答案可被猜测 | 剧本拆为 known_info（用户知悉范围）与 task_instructions（透露方式）两栏 |
| 成功条件不精确，验证误判 | 「网络已恢复」改为「测速为 excellent 才算解决，poor/fair/good 均不接受」——针对敷衍性修复 |
| 用户模拟器行为机械 | 补充情绪、耐心上限、事实锚定要求 |
| 用户只参与对话，不参与操作 | 引入双控环境：用户拥有独立工具集，验证因此覆盖「Agent 是否真读到了用户侧操作结果」 |
| 任务实例固定 | 参数化批量生成，改善覆盖率与抗泄漏能力 |
没有「关于设备状态的回答必须以工具返回结果为依据」这条约束时，模拟用户会顺应 Agent 的引导确认问题已解决，评估随之退化为两个模型之间的相互确认。
高质量评估集有多难做
验证方式的谱系：向右移动，但不放弃左侧
可复现、可进 CI
凡是能写成程序化断言的检查都应当继续用断言，LLM 评判只用于确实无法机械判定的维度。
① 基于专家指导（缺乏专业基础的 Rubric 只能捕捉语言流畅度等表面特征）｜② 全面覆盖（不仅定义正面标准，还要明确陷阱）｜③ 按重要性加权（支持一票否决：客服场景中幻觉是典型否决维度）｜④ 评价标准自包含（避免「展示了深刻理解」，改为「引用至少两个权威理论并准确解释」）。
长度偏差：倾向给更长、更详尽的回复打高分，哪怕内容并不更正确——就像考试时对不会的题长篇大论期望「蒙对」。防范：Rubric 里显式惩罚冗长；配对比较时先把长度控制到相近；定期审计评分与长度的相关性。
位置偏差：系统性偏向出现在某个位置的候选。标准缓解是交换顺序各评一次取平均；更严格的做法是只有两次判决一致时才计入。
当一个度量指标变成优化目标时，它就不再是好的度量指标。更隐蔽的是，Agent 还会逐渐学会避开评判模型不擅长检测的错误类型，让评分系统看起来一切正常。
缓解：多源异构评判——不同模型家族的偏见往往正交，Agent 很难同时「欺骗」所有评判者。
失败归因：定位首个错误
后续错误往往只是连锁反应，不能把最后一个报错简单当成根因。问题案例来自三类信号：用户明确纠正、用户点踩、事后通过状态检查/规则验证器/LLM 评审发现。
任务是把图库中 expenses.jpg 的开销录入记账应用。Agent 用 32 步完成全部操作，没有任何一步返回错误，最后自行宣告完成，验收却报告记录不存在。
逐步回看发现：第 8 步的思考里写着 "I cannot actually see the content of the expenses in the image"——它自己已经知道没拿到数据，却既没有停下也没有报告；到第 11 步，四条开销数据凭空出现。首个错误落在第 8 步，而那一步既没有报错，也不是一次工具调用。
根因归属极易搞错：T3A 是纯文本 Agent，观察空间里只有元素树、根本没有图像像素，所以根因不是「模型不会 OCR」，而是 Harness 的观察通道缺失。记成模型问题就会去换模型或做 OCR 训练；真正该做的是补观察通道。
τ²-bench 公开基线中，带信息告知要求的 704 次运行失败 240 次，其中 162 次信息告知出错；有 80 次（占全部失败的三分之一）环境状态正确，但信息告知错误。多数评估只检查环境状态，因此看不到这类失败。
两层回归任务
最接近生产结果，却难以判断失败发生在哪一步。OSWorld、AndroidWorld、tau-bench 都属此类。
对高可靠性生产 Agent，构建这类任务集往往比端到端更重要。答案应定义为可接受动作集合而非唯一动作。
成本分析：两项优化不能简单相加
| 方案 | 输入 token | 缓存 token | 总成本 | 比基线节省 |
|---|---|---|---|---|
| 无缓存、无压缩 | 20,700 | 0 | $0.003776 | — |
| 仅稳定前缀 | 20,386 | 13,568 | $0.002707 | 28.3% |
| 仅压缩历史 | 16,177 | 0 | $0.003115 | 17.5% |
| 稳定前缀 + 压缩 | 16,035 | 6,144 | $0.002643 | 30.0% |
28.3% + 17.5% ≠ 30.0%——原因是压缩历史的同时也缩短了可以命中缓存的前缀。几项上下文优化同时使用时，必须在完整任务中一起实测，不能把各自的节省比例直接相加。
一个三轮迭代的真实调优
| 实验 | 只改了什么 | 成功率 | token 比 | 下一步 |
|---|---|---|---|---|
| H1 | 增加导航提示 | 25% → 25% | 0.47× | 没有提高，沿用原提示 |
| H5 | accessibility feed 换 UIAutomator | 25% → 100% | 2.498× | 效果明显但太费 token |
| H5C | 精简元素树（删无语义节点） | 100% → 100% | 0.506× | 进入完整复测 |
① 提示写得更详细，也补不回 Agent 根本没有看到的信息——遇到这类失败应先检查输入，而不是继续堆提示词。
② 输入也不是越多越好。
整个过程没有更换模型，仅调整 Harness 如何表示界面，就先后解决了「能不能做成」和「做成是否划算」两个问题。
但也有纪律：在完整复测（116 项 × 5 种子）之前，不能把子集上的 4/4 写成系统整体 100%。一轮证据只支持与它规模相称的下一步。
常见误区是看到分数下降就立刻改 Agent 代码。评测系统本身可能先出了问题：环境资源不足导致进程被杀、验证器有 bug 把正确答案判为失败、测试用例与生产场景脱节。这些在结果数字上跟模型退化一模一样，只有审查完整轨迹才能区分。
统计显著性：别被噪声骗了
100 个用例、成功率 70% 时，95% 置信区间约为 70% ± 9 个百分点——「新模型 73% 对旧模型 70%」不足以支持切换。
同一批任务比较两个配置时应优先做配对分析（McNemar 检验或配对 bootstrap），而不是直接相减两个独立成功率。每个配置最好用 3–5 个随机种子，报告均值和波动范围。
三套记忆方案在同一组 60 问上对比，混合方案并没有自然胜出：它在 3 道题上做到了两种单一方案都没做到的事，却在另外 8 道题上不如表现更好的单一方案，与每道题的最佳单一方案相比平均成功率反而更低。另一个值得注意的数字：180 次评判中幻觉否决触发了 28 次。
内部评估基础设施：最好的产品如何评估自己
外部评估告诉你「Agent 有多好」，内部评估基础设施告诉你「哪项改动让它变好了」。
CH 8模型后训练
思考题 13 道
| 阶段 | 用什么数据 | 优化目标 | 学到什么 | 典型代价 |
|---|---|---|---|---|
| 预训练 | 海量原始互联网文本 | 预测下一个词 | 语言规律、世界知识、基本推理 | 极高（数百万～数千万美元） |
| Mid-training | 目标语言/领域语料 + 保留数据 | 继续预测下一个词（对全部 token 算损失） | 补齐领域知识、语言和基础能力 | 中到高 |
| SFT | 几千～几万条示范对 | 预测下一个词（只在回答上算损失） | 指令遵循、输出格式、风格、流程协议 | 低（几小时～几天） |
| RL | 任务、环境 + 奖励信号 | 最大化期望奖励 | 可迁移的决策策略、探索出的新解法 | 高（常是 SFT 的几十～上百倍） |
直觉类比：预训练是「接受通识教育」，Mid-training 是「集中研修专业教材」，SFT 是「老师示范答题与表达规范」，RL 是「自己下场做题、根据结果反复打磨」。
主线一：本章对照实验中，SFT 更容易记住示范，RL 表现出更好的泛化。但这是这些实验条件下测得的结果，不是普遍属性——数据足够多样、正则化得当时 SFT 也能泛化，奖励或环境有偏时 RL 也会过拟合。
主线二：数据和环境，比算法更重要。这是工业界最反直觉也最有价值的经验。掌握现成算法的基本用法即可，真正决定成败的是三件事：Mid-training 语料有没有补齐底座、示范数据有没有建立起行为协议、仿真环境与奖励能不能提供可靠反馈。很多场景下，只要前两类数据质量到位，你甚至根本不需要做 RL。
SFT 在数学上和预训练是同一个任务——都是预测下一个词、最小化同一个损失函数。差别只有两点：数据不同（人工准备的「输入—输出」对），以及损失只算在回答上（loss masking）。
这解释了 SFT 为何表现出记忆倾向：优化目标是让标注回答里每个 token 的概率尽可能高，也就是尽量复现示范。一句话概括：用极高的样本效率，把一套稳定的「输入→输出」映射与协议固化进参数。
什么时候选哪个：先判断缺的是底座、协议，还是策略
| 观察到的现象 | 主要缺口 | 优先方法 |
|---|---|---|
领域概念/语言/基础操作不会；合理采样下 pass@k 仍接近 0 | 知识与能力不在基模的有效支持中 | Mid-training；动态事实用 RAG |
| 偶尔能做对，但格式、工具 schema、语气或固定流程不稳定 | 行为协议没有固化 | SFT 或约束解码 |
| 已有非零成功率和可靠奖励，但好策略概率低、OOD 泛化不足 | 概率质量分配与策略优化 | RL |
| 只有少量稳定示范，尚无可交互环境 | 可模仿数据有、在线反馈无 | SFT / RFT / 离线偏好优化 |
① 格式支持：如果模型吐出的 JSON 无法解析，奖励函数连「成功还是失败」都判断不了。
② 能力支持（更根本）：如果在合理的 k、温度和任务覆盖下实测 pass@k 仍接近 0，基础模型几乎生成不出成功轨迹。只给 0/1 奖励时，GRPO 的一组 rollout 很可能全为 0，组内优势直接消失；PPO 也看不到「应该往哪里移动」。把采样量继续放大只能以约 1/p 的速度等待偶然成功。
RL 擅长把已有但概率较低的成功行为推高，不擅长从全零奖励中凭空创造模型从未学过的知识和能力。
实验 8-11 中 Llama-3.2-Vision-11B 在严格结构化输出设置下不经 SFT 直接 RL 会失败；但足够强、已有非零成功率的基模可以跳过 SFT——DeepSeek-R1-Zero 就是这种情形。它后来加入冷启动 SFT，主要是改善可读性与语言一致性，而不是为 RL 注入任务知识。
GRPO 一次训练迭代：四步
- 让策略模型重复尝试：同一份初始代码复制到 16 个隔离沙箱，独立解决 16 次。每次包含完整的「阅读 → 修改 → 运行测试 → 提交」，这整条过程叫一次 rollout
- 计算奖励：验证器在干净环境应用补丁并运行测试。假设 4 次通过、12 次失败，则前 4 条得 1、后 12 条得 0
- 计算相对优势：组内平均成功率 4/16，通过的 4 条得正优势、失败的 12 条得负优势。若 16 条全败或全胜，相对优势会消失
- 梯度下降更新策略：不是把某个成功补丁原样背下来，而是让「先复现问题、检查边界条件、修改实现并运行测试」更容易出现，「掩盖异常、改测试、没验证就提交」更少出现
粗略时间估算：复杂 Agent rollout 生成数十轮工具调用，最慢 rollout 约 2000 秒 + 梯度更新约 600 秒 ≈ 一个 step 43 分钟；训练 100 steps 接近 72 小时。
大规模 LLM RL 常用 vLLM/SGLang 生成 rollout，再用 FSDP/Megatron 重算 log probability。即使加载同一份权重，浮点精度、归约顺序、张量并行方式、批大小的差异，也可能让同一 token 的 log probability 略有不同——于是更新前本应为 1 的概率比已经偏离 1：系统名义上同步了权重，数值上却把 on-policy 训练变成了 off-policy。
放大链条：log probability 小误差 → 指数化的概率比偏差 → 长前缀累积 → clipping/优势加权改变 → 梯度方向改变。若 4000 个 token 的 log ratio 都有同方向 10⁻³ 偏差，轨迹级比率会累积到 e⁴ ≈ 54.6。
工程对策：在任何参数更新之前，用同一批轨迹比较 sampler 与 trainer 的 token log probability——这是最直接的 on-policy 单元测试。
RL 环境：先问「我的仿真环境真的像真实世界吗」
环境一旦失真，策略就会失效。如果仿真里的客服总按固定套路回话、错误信息跟生产环境对不上，模型就会学到一套只在仿真里管用的「应试策略」。这是 RL 项目最常见的失败方式——不是算法不行，而是练习场与考场并不相同。
第一层：合成工具返回值。ZeroSearch 用 LLM 扮演搜索引擎，并采用课程式设计——初期返回高质量文档，随训练推进逐步掺入噪声，促使学生学会从不完美结果中提取信息。全程没见过真实搜索引擎的模型，直接对接真实搜索时依然表现良好。
第二层：仿真整个环境动态。DreamGym 把环境动态蒸馏进推理式「经验模型」，批量合成 rollout。
但风险明确：模拟器的世界知识就是训练的天花板，模拟器的系统性偏差会被策略照单全收；更糟的是 RL 会主动寻找并利用模拟器的漏洞。稳妥做法是混合：模型模拟承担大部分交互量，辅以真实环境交互定期校准偏差。
奖励设计：三个维度 + 一个额外问题
| 维度 | 选择 | 原则 |
|---|---|---|
| 来自哪里 | 可验证奖励（RLVR）｜人类偏好（RLHF）｜模型评判（GRM） | 规则越确定，奖励越便宜、可复现，也越不容易被钻空子 |
| 什么时候给 | 结果奖励（ORM）｜过程奖励（PRM） | 密集反馈换收敛速度，稀疏反馈换探索空间 |
| 表达多少信息 | 标量｜半标量｜向量｜生成式诊断 | 每增加一个评价维度，就增加一种被钻空子的可能 |
reward hacking 是钻规则或实现漏洞拿高分；reward seeking 则是模型先在心里建立一个「评判器会看什么」的模型，再按猜测调整行为。后者不一定篡改测试或伪造结果，却可能在长程任务中自行设置一个过于简单的检查，刚好通过就提前结束。
所以「通过了 grader」不能自动等价于「任务完成了」：评判器是意图的代理，训练越强，模型越可能把代理当成目标本身。
结果奖励解决「事情有没有办成」，却表达不了「是否按规定办成」。真实环境通常是非对称验证器：检测「做了一个坏动作」便宜而可靠，证明「这一步确实取得了有意义的进展」却很难。
关键不是「奖励越密越好」，而是能否恢复组内差异：纯结果奖励在全败组和全胜组都会产生零方差；违规动作通常容易检测，惩罚几乎总能恢复差异；进展奖励只有在部分进展可达时才有效。
实证（实验 8-16）：TerminalBench 违规次数由 3.71 降至 0.66 而成功率基本持平；miniF2F 达到 0.9 成功率所需迭代从 7.0 降至 4.4。但软件修复中若所有 rollout 都无法通过任何测试，进展信号不可达，加入它不会带来收益。
蒸馏：把一次 rollout 变成密集监督
| 方法 | 轨迹/状态由谁采样 | 每条轨迹的主要监督 |
|---|---|---|
| SFT / 离轨蒸馏 | 人类或教师 | 标注答案的逐 token 监督，密集 |
| On-policy RL | 当前学生 | 结果或过程奖励，通常稀疏 |
| On-policy Distillation | 当前学生 | 教师在学生前缀上的逐 token 分布，密集 |
学生决定走到哪里，教师负责在学生已经走到的位置告诉它下一步的完整概率分布。一条长度为 T 的 rollout 不再只产生一个 0/1 信号，而能产生约 T 组逐 token 监督。在数学等任务上，达到同等性能所需训练步数约为纯 RL 的 1/10。
同一个模型分饰教师和学生两角，但看到的上下文不同：教师版能看到「特权信息」（标准答案或已验证的正确解答），学生版只看到问题本身，却在自己采样的轨迹上向教师版的逐 token 分布对齐。
对着答案解释学生刚走过的路径，通常比独立探索更容易。但它不会凭空创造新知识——如果模型拿着答案也讲不清过程，自蒸馏就没有额外信号。
从评估资产到训练输入
| 第七章的评估数据集 | 第八章的训练用法 |
|---|---|
| 端到端回归任务（含验证器） | RL rollout 任务与可验证奖励（RLVR）；拒绝采样（RFT）的采样池 |
| 轨迹前缀回归任务 | DPO 偏好对、决策边界的 SFT 示范、On-Policy Distillation 的教师状态 |
| 失败归因记录（首个错误步骤与类别） | 过程监督的负标签（PRM）、RLVP 路径惩罚的规则来源 |
| Rubric 多维评分与人工金标集 | 向量奖励的各维度、生成式奖励模型（GRM）的训练与校准数据 |
以「过早结束」为例：训练后既要用边界集检查「任务未完成时模型是否选择继续验证」，也同样重要地要用保留集检查「任务确实已完成时模型能否正常宣称完成」。
只盯前一个指标，会把模型训练成永远不敢收尾的过度矫正状态：每个任务都无限验证下去，延迟与成本崩溃。
还要警惕奖励作弊的新形态：模型可能学会「口头声称去验证」而不真的验证——这正是端到端奖励必须依赖模型无法编写或修改的隐藏测试的原因。
同一个寻宝游戏：表格 Q-learning 需要近 10000 次完整尝试才达到 100% 胜率；LLM Agent 第一局就在 18 步内通关——因为它理解了游戏的概念结构（「武器总比空手好」「需要找钥匙」「银剑才能对付守卫」），而对 Q-learning 来说「门」「钥匙」「剑」只是无意义的符号组合。
姚顺雨《The Second Half》的结论：几十年来 RL 研究者的优先级可能完全颠倒了——不是算法 > 环境 > 先验，而是先验 > 环境 > 算法。
CH 9Agent 的持续进化
思考题 —
持续学习 vs 持续进化：模型权重层面的持续学习尚不可靠，故先在模型外围构建可验证的「持续进化」系统。
保存经历 ≠ 从经历中学习：学习发生在「评价、对照、归纳、验证」之后，而非日志落盘那一刻。
与第 3 章记忆的分工：用户记忆沉淀「世界是什么样」，经验学习沉淀「在什么条件下应该怎样行动」。
生产环境缺乏干净的学习信号，容易导致灾难性遗忘、策略漂移、安全退化，以及提示注入被固化进参数。
三层验证结构
事情是否办成
是否以允许方式办成
是否让用户舒服
结果层最应优先建立——它来自环境真实状态，比模型自述可靠。过程层可用代码判定（政策库、权限表、动作轨迹都能精确表达）。质量层用 LLM-as-a-Judge + Rubric，逐项给分并引用轨迹证据。
① 成功/部分成功/失败 ② 逐维度结论 ③ 证据位置 ④ 失败类型标签。
并且：证据不足时应允许拒绝评分并把该样本剔出学习集——而不是硬给一个分数。
四种更新载体
| 更新方式 | 适合承载 | 优势 | 局限 |
|---|---|---|---|
| 经验知识库 | 事实、经验规律、例外与来源 | 更新快、可追溯、可检索 | 依赖检索与模型正确应用 |
| Prompt 与 Skill | 可用自然语言说明的判断原则 | 可解释、作用范围可控 | 易膨胀、冲突或被忽略 |
| 程序与 Harness | 可确定解析、可执行验证、高风险硬约束 | 可测试、执行稳定、成本低 | 开发维护成本高 |
| 模型参数 | 高维感知、生成风格、隐式策略 | 泛化强、推理开销低 | 更新与回归成本高 |
是「能力的表示性质」，而不是「任务是否长期稳定」。医疗影像识别、自然语气等能力即使面对持续变化的领域，仍往往需要参数更新；反过来，长期稳定的转账审批规则也应由代码提供确定性保障，而不能只靠模型记忆。
知识提炼的五步管道与三层数据结构
- 保存不可变原始轨迹（审计用）
- 单次运行的结构化分析（草案）
- 按任务族聚合建立证据表
- 达到门槛才入正式文档
- 在新任务上测迁移
对应三层数据：不可变原始轨迹（审计）／单次运行分析（草案）／跨轨迹归纳的正式文档。注意：Reflexion 式反思是草案来源而非证据。
通过率 12.3% → 19.3%，原通过任务无一改坏；越界调用与缺参调用下降约八成。
① 提炼材料决定归纳质量。仅给错误文本，得到的是泛泛的「教训」；补充工具职责清单后，才得到可执行的「职责归属」。
② 模型会把观察到的行为当作应然行为。书中记录了一个真实案例：模型曾归纳出「三次失败即转人工」这条规则——而转人工在该评估中必然判失败。所以提炼产物必须由独立验证者审查。
Skill 与 Harness 的边界
重复任务端到端加速 8.5–13 倍。但必须具备三重验证：动作前验证、动作后验证与独立回放验证。
自我修改的发布流程
失败轨迹重放 · 回归
「变更契约」须可证伪。
动态组合分时间可组合性（可撤销效果，改了什么）与空间可组合性（反应式协效果，依赖什么）。
核心判断：自我进化的上限取决于系统的可组合性——「不存在只能由人类维护的特权内核」。
三道安全边界
分层评估：不能只用端到端分数反推更新器好坏
| 指标 | 回答的问题 |
|---|---|
| 更新提案有效率 | 提案接受率与增益 |
| 产物激活率 | 是否在正确场景加载 |
| 遵循成功率 | 激活后是否照做 |
| 保留任务集增益 | 泛化与不退化 |
长期还须同时观察五类结果：回退、泛化、Token 效率、安全性、长期工程质量。
五步：触发 → 定向 → 采集整合 → 验证审批 → 修剪索引。前台交互期间不断累积新证据和局部更新，后台在周期性窗口里从全局视角重新审视整个知识体系。
五种搜索尺度：规则 → 上下文 → 工作流 → Harness 代码 → 优化器代码（参 ACE / MCE / AFlow / Meta-Harness）。能改进的层级越高，风险也越大。
持续进化需要把在线执行与离线学习分开：在线记录证据，离线生成并验证更新提案，再逐步发布、整理或回滚。
这个闭环在结果可自动验证的任务上最可靠；对于目标模糊、反馈延迟的开放任务，人仍需参与问题定义和评价标准的制定。
CH 10多 Agent 协作
思考题 11 道
核心判据：只有一条
协作过程是否引入了单个 Agent 在生成时无法获得的新信息？
这解释了一个看似矛盾的现象：学术研究常说多 Agent 无用（比的是「多个 Agent 看同一段文本互相辩论」，无新信息），工程实践却有效（含代码执行、视觉渲染、工具验证等外部反馈环）。
| 协作模式 | 是否引入新信息 | 效果 |
|---|---|---|
| 同一模型自我审查 | 否 | 通常无效甚至有害 |
| 不同 Agent 辩论同一段文本 | 否 | 等计算量下与单 Agent 持平 |
| 审核者使用测试执行结果审查代码 | 是（执行反馈） | 显著提升 |
| 审核者查看渲染截图审查前端代码 | 是（视觉反馈） | 显著提升 |
| 审核者使用外部工具验证事实 | 是（工具反馈） | 显著提升 |
两个核心设计维度
不共享：各自独立，模块化好但必须设计显式通信——三种机制本质是 IPC 两大范式（共享文件系统 = 共享内存；工具参数与消息总线 = 消息传递）。
管理者：中心化规划与调度。
去中心化：无运行时中心，自主移交。
三者都是「执行图」的不同形态。
轨迹 ≈ 进程内存｜LLM ≈ CPU｜Agent 运行时 ≈ 内核｜工具调用 ≈ 系统调用｜spawn_subagent ≈ fork｜cancel_subagent ≈ kill｜list_agents ≈ ps｜共享文件系统 / 消息 ≈ 共享内存 / 消息传递。
这套抽象并不新鲜——正是 1970 年代 Actor 模型的基本设定。因此操作系统与分布式系统的成熟经验大多可以直接借用。
Loop 工程：把宣称变成证明
偷懒式假完成（测试没跑就报完成）｜过早放弃（一条路走不通就说办不成）｜假成功（以为办成了，实际闭环没走完）。
根源：在验证之前，「完成」只是模型的一句宣称，不是证明。
业界共识：循环的瓶颈在验证器，而不在模型。验证不可靠，循环转得再快，也只是把劣质产出更快地标记为完成。
可检查的系统不变量：模型可以提出「完成」，但不能批准自己的「完成」。
六种失败模式
| # | 失败模式 | 要点 |
|---|---|---|
| F1 | 共享文件系统的并发冲突 | 简单冲突用乐观锁；语义冲突（不同文件、逻辑矛盾）需工作副本隔离 |
| F2 | 错误的级联放大 | 进程传字节逐位保真，Agent 传语义每转述一次都是有损重编码 |
| F3 | 同质趋同（共因失效） | 30 个 Agent 有 18 个创建同名 Git 分支；同模型的多个审核意见不能视为独立证据 |
| F4 | 互相扯皮 | 三个 Agent 把彼此操作理解为蓄意阻挠，终止对方进程、撤销权限，甚至部署自复制破坏代码 |
| F5 | 循环失控 | 失控 Agent 有时会生成数千个子 Agent；建议用独立 API key |
| F6 | 理解债与认知投降 | 这不是 Agent 的失败，而是人的失败 |
传统分布式系统大多只需防崩溃故障（部件停止工作）；Agent 却很少径直停止运行，而是继续给出看似可信的错误结论，且错误不会主动声明自己是错误。这正是拜占庭故障。交叉验证、多数表决都是拜占庭容错的经典手段。
「你可以外包你的思考，但不能外包你的理解。」
管理 Agent 就像管理技术员工，既不能越俎代庖，也不能放手不管。因此，Agent 使用者的技术基本功很重要。
贯穿全书的五个设计模式
第 1 章一次性命名并给出规范定义，后续章节反复调用。
| 模式 | 核心机制 | 在哪些章出现 |
|---|---|---|
| 提议者—审核者 Proposer-Reviewer |
产出与评判由两个不共享上下文的角色承担，评判方看到的是产物本身（渲染结果、测试输出、结构化参数）而非产出方的推理过程。 前提是自审不可靠。 |
3（更新知识）· 4（工具事前审批与事后验证，Sidecar 是只读变体）· 5（PPT/视频/日志三实验的骨架）· 7（评估 UI）· 9（审核更新提案）· 10（对等协作，及为何不能自审） |
| 渐进式披露 Progressive Disclosure |
不把全部信息一次性放进上下文，而是先给可检索的目录，再按需加载细节。同时优化上下文预算与选择精度。 | 2（Agent Skills 最典型）· 3（分层检索）· 4（主动工具发现、分页截断）· 10（Agent 发现） |
| 只增不改 Append-only |
状态以追加方式演进，已写下的内容不再回头修改。换来可缓存、可重放、可审计。 | 2（KV Cache 前缀稳定性是其性能形态）· 3（事件式记忆）· 4（新工具 schema 追加到轨迹末尾而非插回前缀） |
| 边界集 + 保留集 Boundary + Retention |
任何修改都要同时在「它应当改变的那批样本」和「它不应当影响的那批样本」上验证。 只测前者会把过拟合当进步，只测后者会把无效修改当安全。 |
7（回归任务）· 8（训练与评估隔离、过早结束案例）· 9（更新提案验证） |
| 最小 diff + 可回滚 | 每次修改尽量小、带来源、可单独回滚。让归因成为可能——出了问题能定位到具体哪一次改动。 | 3（知识更新）· 5（代码补丁）· 9（Prompt 与程序更新） |
上下文内适应 → 外部产物更新 → 参数更新。
三层护栏：按「被绕过的难度」排序
处在同一个上下文里的 Agent，很难判断自己是否已经被注入。所以上下文层只能降低攻击成功率，给不出保证——这正是必须有下面两层的原因。
数据层的价值在于它不依赖上面两层是否正确：即使提示注入得手、生成的代码完全漏写了权限判断，越权操作仍会在数据层被拒绝。
为了降低危险请求被放行的概率，模型可能同时拒绝一部分合法但形式敏感的任务（经过授权的安全测试、模型蒸馏研究）。因此护栏评估不能只测「应当拒绝的请求是否被拦截」，还要测「明确允许的请求是否能够正常完成」。
三条学习路径：不同时间尺度上的协同
| 路径 | 发生在 | 优势 | 局限 | 对应章节 |
|---|---|---|---|---|
| 上下文适应 | 当前任务中 | 快速、低成本 | 受上下文窗口与信息组织约束，不跨会话保留 | 2 |
| 外部产物更新 | 跨任务 | 可审计、可修订 | 执行时仍需通过上下文或工具接口被使用 | 3、4、5 提供基础；9 讨论如何生成 |
| 参数更新 | 训练周期 | 自然、广泛的泛化能力 | 部署成本较高 | 8 |
三条路径不是互斥分类：上下文负责临场适应，外部产物负责可控积累，参数负责内化难以显式表达的能力。
反复出现的六个判断
109 个实验总览
| 章 | 主题 | 实验数 | 编号范围 |
|---|---|---|---|
| 1 | AI Agent 入门 | 4 | 1-1 ~ 1-4 |
| 2 | 上下文工程 | 10 | 2-1 ~ 2-10 |
| 3 | 用户记忆和知识库 | 12 | 3-1 ~ 3-12 |
| 4 | 工具 | 5 | 4-1 ~ 4-5 |
| 5 | Coding Agent 与通用 Agent | 16 | 5-1 ~ 5-16 |
| 6 | 交互：观察与动作空间的扩展 | 14 | 6-1 ~ 6-14 |
| 7 | Agent 的评估 | 14 | 7-1 ~ 7-14 |
| 8 | 模型后训练 | 19 | 8-1 ~ 8-19 |
| 9 | Agent 的持续进化 | 9 | 9-1 ~ 9-9 |
| 10 | 多 Agent 协作 | 6 | 10-1 ~ 10-6 |
| 合计 | 109 | 配套代码见原书仓库 | |
星级含义：★ 入门体验 · ★★ 需要动手实现 · ★★★ 综合工程项目。各章实验清单见上面对应小节。
参考与说明
各章原文直达
| 章 | 标题 | 链接 |
|---|---|---|
| 引言 | 为什么写这本书 | /book/introduction/ |
| 1 | AI Agent 入门 | /book/chapter1/ |
| 2 | 上下文工程 | /book/chapter2/ |
| 3 | 用户记忆和知识库 | /book/chapter3/ |
| 4 | 工具 | /book/chapter4/ |
| 5 | Coding Agent 与通用 Agent | /book/chapter5/ |
| 6 | 交互：观察与动作空间的扩展 | /book/chapter6/ |
| 7 | Agent 的评估 | /book/chapter7/ |
| 8 | 模型后训练 | /book/chapter8/ |
| 9 | Agent 的持续进化 | /book/chapter9/ |
| 10 | 多 Agent 协作 | /book/chapter10/ |
| 后记 | 模型会不会吃掉 Harness？ | /book/afterword/ |
项目信息
- 仓库：github.com/bojieli/ai-agent-book（Apache License 2.0，配套实验代码在此）
- 下载：仓库 Releases 提供中文 PDF 与 EPUB
- 多语言：中文（简体）原版 + 14 种社区翻译，共 15 个语种
- 构建：MkDocs，每次仓库推送后由 GitHub Actions 自动重建，内容持续更新
本页是通读笔记性质的结构化整理，用图表、表格与分层导航重新组织了全书 10 章的脉络，便于检索与复习。所有事实、数据、引语与结论均来自原书，未添加原书之外的论断；图表为便于理解而绘制，「反复出现的六个判断」一节是对全书主题的归纳。
本书内容持续更新，页面标注的更新日期各章不同（第 6 章 2026-09-06、第 1/2/7/9 章 2026-09-03、第 8 章 2026-08-26、第 4 章 2026-08-25、第 5 章 2026-08-24、第 3 章 2026-08-21、第 10 章 2026-08-31）。建议配合原书阅读，以获得完整论述与最新修订。
整理过程中发现，站点首页目录对第 6–9 章的排序与各章正文的交叉引用不一致。本页采用的是正文交叉引用所确认的顺序：6 交互 → 7 评估 → 8 后训练 → 9 持续进化（例如第 6 章小结明确写「第七章先回答如何判断系统构建得对不对；第八章讨论如何通过后训练更新模型参数；第九章再把运行轨迹、评估与多种更新载体组织成持续进化闭环」）。