一句话定位 ：全书地基------从核心公式
Agent = LLM + 上下文 + 工具出发，带你理解 ReAct 循环、Harness 工程、三层护栏和五个设计模式。上一页：AI Agent时代与全书地图，下一页：第02章-上下文工程。
小白入门：Agent 到底是怎么工作的？
假设你让一个 AI Agent 帮你做一件事："计算公司年度总收入，Q1 是 2.5M 美元，Q2 是 2.1M 欧元，Q3 是 1.8M 英镑。"
一个普通的聊天机器人会怎么做？它可能直接在对话里估算一个数字给你------但汇率是多少？它用的是哪天的汇率？算对了吗？你不知道。
一个真正的 Agent 会怎么做？
- 思考："这三个数字货币不同，我需要先统一换成美元"
- 行动：调用汇率转换工具，把欧元和英镑都转成美元
- 观察：看到工具返回的结果------EUR→USD: 2,282,608.70，GBP→USD: 2,278,481.01
- 再思考："现在三个数字都是美元了，加起来就行"
- 再行动：调用计算器工具，把三个数字相加
- 再观察：工具返回总和
- 最终回答："年度总收入 $7,061,089.71"
这就是 Agent 的工作方式------思考→行动→观察→再思考→再行动......直到完成 。这个循环有个名字，叫 ReAct 循环，是本章的核心概念之一。
本章将带你从零开始理解 Agent 的完整工作原理，包括三个层面：
- Agent 是什么（核心公式）
- Agent 怎么跑（ReAct 循环）
- Agent 怎么跑得可靠（Harness 工程）
一、Agent = LLM + 上下文 + 工具
引言中已经介绍了这个公式，本章把它拆开讲透。先看全景图：
┌──────────────────────────────────────────────────────────────┐
│ Agent ↔ Environment 闭环 │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ Agent 边界 │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────────┐ │ │
│ │ │ LLM │ │ 上下文 │ │ ┌──────────┐ │
│ │ │ （大脑） │←─│ （眼睛） │ │←──│ Environment│ │
│ │ │ │ │ │ │ │ （环境） │ │
│ │ │ 思考决策 │ │ 系统提示词 │ │ │ │ │
│ │ │ │ │ 工具定义 │ │ │ 网页 │ │
│ │ └────┬─────┘ │ 对话历史 │ │ │ 文件系统 │ │
│ │ │ │ 工具结果 │ │ │ 数据库 │ │
│ │ ↓ └──────────────┘ │ │ 用户 │ │
│ │ ┌──────────┐ │ │ API │ │
│ │ │ 工具 │──────────────────────│──→│ │ │
│ │ │ （手脚） │←─────────────────────│───│ │ │
│ │ │ │ │ └──────────┘ │
│ │ │ 搜索 │ │ │
│ │ │ 代码执行 │ │ │
│ │ │ 文件操作 │ │ │
│ │ └──────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────┘ │
│ │
│ 观察通道（环境 → Agent）：上下文承载 │
│ 行动通道（Agent → 环境）：工具承载 │
└──────────────────────────────────────────────────────────────┘Agent 和环境之间只有两条通道：
- 观察通道（环境 → Agent）：通过"上下文"传递，决定 Agent 能看到什么
- 行动通道（Agent → 环境）：通过"工具"传递，决定 Agent 能做什么
关键论断 ：
没有通过观察通道进入上下文的信息，对模型来说就像不存在。
这句话很重要------如果环境里有某条信息，但它没有被放进上下文，Agent 就完全不知道它。就像你面前有一份文件，但被遮住了------文件确实存在，但你看不到，就等于不存在。
1.1 观察空间与动作空间
在强化学习（RL）的术语里：
- Agent 能看到的所有信息 = 观察空间（Observation Space）
- Agent 能执行的所有操作 = 动作空间（Action Space）
| 通俗说法 | RL 术语 | 比喻 |
|---|---|---|
| 上下文（眼睛） | 观察空间 | 你能看到的世界 |
| 工具（手脚） | 动作空间 | 你能做的所有动作 |
全书最重要的工程论断之一 ：
在底层模型固定时，提升 Agent 任务表现最主要的系统工程手段，往往就是重新定义或扩展观察空间与动作空间。
翻译成大白话：当模型不变时，让 Agent 变强的最有效方法，是给它更多信息和更多工具。
类比：你是一个新员工，能力不变（同一个大脑），但如果公司给你更多权限（动作空间扩大）和更多信息访问权（观察空间扩大），你能完成的工作就更多了。
产品能力的演进往往就是观察空间和动作空间的演进。------Manus、OpenClaw 等产品的进步，本质上都是在扩展这两个空间。
1.2 工具：Agent 的手脚
工具决定了 Agent 能做什么。原书将工具分为五大类：
| 类别 | 作用 | 例子 | 详细章节 |
|---|---|---|---|
| 感知工具 | 获取环境信息 | 网页搜索、文件读取、数据库查询 | 第4章 |
| 执行工具 | 改变环境状态 | 写文件、运行代码、调用API | 第4章 |
| 协作工具 | 与其他 Agent 交互 | 消息发送、任务委托 | 第6章 |
| 用户沟通工具 | 与用户交互 | 发通知、请求确认、展示结果 | 第6章 |
| 事件触发工具 | 响应外部事件 | 定时器、Webhook、文件监听 | 第6章 |
前两类是基础（感知+执行），后三类是进阶（协作+沟通+事件），在第6章展开。
工具设计的关键原则 ：工具接口要从 Agent 的视角设计，而不是从程序员的视角。这叫 ACI（Agent-Computer Interface） ，就像手机 SIM 卡的缺角设计------让卡片只能从一个方向插进去，错误根本无法发生。这种"用设计消除错误"的思路在制造业叫防呆（Poka-yoke），源自丰田生产体系。
1.3 LLM：Agent 的大脑
LLM 是 Agent 的智能核心，负责理解任务、规划步骤、做出决策。关于 LLM 有几个要点：
- 绝大多数 Agent 需要支持"思考"（Reasoning）的模型：Agent 要做多步思考、工具选择等复杂决策，不带思考能力的模型在这些任务上表现很差
- "模型即 Agent"趋势：通过强化学习（RL）训练，模型把"何时调用工具、调用哪个、传什么参数"这些决策策略内化为原生能力------就像一个人经过训练后，不需要刻意思考就能做出正确判断
重要澄清 ：RL 内化的是决策策略 （何时调用工具、调用哪个），而工具本身及其执行仍在 Agent 框架（模型之外的基础设施）中完成。就像你学会了"什么时候该用搜索引擎"这个判断，但搜索引擎本身不是你大脑的一部分。
1.4 上下文：Agent 的眼睛
上下文是 Agent 在每次调用 LLM 时传入的完整信息。它由五个组件构成，分为两大类：
┌──────────────────────────────────────────────────────────┐
│ Agent 上下文的五个组件 │
│ │
│ ┌────────────────────────────────────────┐ │
│ │ 静态前缀（每次调用都一样） │ │
│ │ │ │
│ │ 1. 系统提示词（角色、规则、目标） │ │
│ │ 2. 工具定义（有哪些手脚可用） │ │
│ └────────────────────────────────────────┘ │
│ + │
│ ┌────────────────────────────────────────┐ │
│ │ 动态轨迹（随交互不断增长） │ │
│ │ │ │
│ │ 3. 用户消息（你说了什么） │ │
│ │ 4. 模型回复（Agent 思考了什么、做了什么）│ │
│ │ 5. 工具执行结果（环境返回了什么） │ │
│ └────────────────────────────────────────┘ │
│ │
│ Agent 上下文 = 静态前缀 + 轨迹 │
└──────────────────────────────────────────────────────────┘为什么这个区分重要？ 因为静态前缀在每次调用时都一样（可以缓存优化），而轨迹不断增长（需要持续管理）。当对话很长时，轨迹可能变得非常庞大，如何管理上下文就成了核心工程问题------这是第2章"上下文工程"的主题。
关键论断 ：
上下文决定了 Agent 能看到什么，而 Agent 只能基于它看到的信息做决策。
更隐蔽的危险 ：给出了回答不等于完成了任务------当上下文残缺时，Agent 可能给出一个看起来完全正确、但实际基于不完整信息的答案。这种无破绽的错误答案是最危险的，因为你很难发现它错了。
二、ReAct 循环：Agent 是怎么一步步干活的
2.1 什么是 ReAct？
ReAct = Re asoning（推理）+ Acting（行动）。核心思路极其简单：
┌──────────────────────────────────────────┐
│ ReAct 循环 │
│ │
│ ┌─→ 思考（Reasoning） ──┐ │
│ │ ↓ │
│ │ 行动（Acting） │ │
│ │ ↓ │
│ │ 观察（Observation） ─┘ │
│ │ │ │
│ └──── 还没完成？ ───────┘ │
│ │
│ 完成了 → 输出最终答案 │
└──────────────────────────────────────────┘用前面那个多币种计算的例子来走一遍：
bash
第1轮：
用户："计算年度总收入：Q1 $2.5M, Q2 €2.1M, Q3 £1.8M"
Agent 思考："需要将 EUR 和 GBP 转换为 USD，再汇总计算"
Agent 行动：调用 convert_currency(2.1M, "EUR", "USD")
调用 convert_currency(1.8M, "GBP", "USD")
观察：EUR→USD: 2,282,608.70
GBP→USD: 2,278,481.01
第2轮：
Agent 思考："已获得汇率，调用代码解释器汇总"
Agent 行动：调用 code_interpreter("total = 2.5M + 2.28M + 2.28M")
观察：Total: $7,061,089.71
第3轮：
Agent 思考："所有计算完成，总结结果"
Agent 输出："年度总收入 $7,061,089.71，季度均值 $2,353,696.57"整个过程只用了 3 次迭代、4 次工具调用。
2.2 轨迹（Trajectory）：Agent 的"工作记忆"
在 ReAct 循环中，每一轮的思考、行动、观察都会被记录下来，形成一条轨迹。这条轨迹就是 Agent 的"工作记忆"------每次调用 LLM 时，它都能看到完整的轨迹，知道自己进行到了哪一步、之前尝试过什么、得到了什么结果。
轨迹的结构：
css
轨迹 = [ {role: "user", content: "用户的请求"}, {role: "assistant", reasoning: "Agent的思考", tool_calls: [...]},
{role: "tool", content: "工具执行结果"},
{role: "assistant", reasoning: "下一步思考", tool_calls: [...]},
{role: "tool", content: "工具执行结果"},
{role: "assistant", content: "最终回答"}
]每次 LLM 调用时，传入的完整上下文 = 静态前缀 （系统提示词 + 工具定义）+ 轨迹（不断增长的消息历史）。
轨迹的价值不仅在于运行时：分析大量轨迹可以发现 Agent 的行为模式、优化决策路径、改进工具设计；轨迹还可以沉淀进知识库，或用于强化学习训练更好的模型------形成从经验中学习的闭环。
2.3 实验：Kimi K3 和 GPT-5.6 的原生 Agent 能力
原书做了两个实验来展示"模型即 Agent"的新范式：
实验1-2：Kimi K3
- Kimi K3 是约 2.8 万亿参数的混合专家（MoE）模型------可以把 MoE 想象成一个专家团队：面对不同类型的问题，系统自动选择最合适的几位专家来作答，不需要所有专家同时上阵
- 拥有 100 万 token 的上下文窗口、原生视觉理解能力、始终开启的思考模式
- 突出优势：能连续执行 200~300 次工具调用而保持思考一致性，远超多数模型在数十次调用后就开始退化的表现
实验1-3：GPT-5.6
- 配合 Responses API 的内置工具（网络搜索 + 代码解释器），在服务端形成"搜索→阅读→分析→再搜索"的闭环
- 引入意图澄清过程：不会立即动手执行，而是先问清楚你的真实需求
- 支持自由格式工具调用：传统方式必须把参数打包成严格 JSON 格式（像填表格），自由格式允许直接发送原始文本（像写便条）
两个实验的共同启示 ：RL 训练让模型把
何时调用工具、调用哪个、传什么参数的决策内化为原生能力。但工具本身（web_search、code_runner 的真实实现、代码沙盒环境）仍在模型之外的基础设施中完成。决策权交给模型，执行权仍在框架。
三、Harness 工程：模型之外的竞争力
3.1 为什么需要 Harness？
前面讲的 ReAct 循环看起来很简单，但"一个能跑的 Demo 和一个可靠的产品之间还有巨大的鸿沟"。模型可能：
- 产生幻觉（编造不存在的工具或参数）
- 选错工具
- 遇到错误时无法自我恢复
这些脆弱点正是 Harness 工程要解决的问题。
Harness 是什么？ 在 Agent 边界内、模型之外的运行与治理层。用公式表达：
ini
Agent = Model + Harness
Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正
arduino
┌──────────────────────────────────────────────────────────┐
│ Harness 五要素 │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ 上下文管理 │ │ 工具接口 │ │ 约束 │ │
│ │ （让Agent │ │ （让Agent │ │ （让Agent │ │
│ │ 能看到） │ │ 能做事） │ │ 不越界） │ │
│ └────────────┘ └────────────┘ └────────────┘ │
│ │ │
│ ┌────────────┐ ┌────────────┐ │ │
│ │ 验证 │ │ 纠正 │←───────┘ │
│ │ （让Agent │ │ （让Agent │ │ │
│ │ 做得对） │ │ 能改错） │←────────┘ │
│ └────────────┘ └────────────┘ │
│ │
│ 前两个让 Agent "能做事" │
│ 后三个让 Agent "不做错事" │
│ 五者构成闭环 │
└──────────────────────────────────────────────────────────┘| 功能 | 职责 | 实际例子 | 详见 |
|---|---|---|---|
| 上下文管理 | 为模型提供充分信息 | 系统提示词、知识库、状态栏 | 第2、3章 |
| 工具接口 | 提供观察与行动手段 | MCP 工具、代码解释器、搜索 | 第4章 |
| 约束 | 设定行为边界，默认关闭所有能力 | Claude Code 每个工具需用户授权 | 第4章 |
| 验证 | 自动判断结果对错，只看结构化数据 | Linter 检查、类型系统、结果校验 | 第5、6章 |
| 纠正 | 发现问题时自动修正或回退 | 静默重试、接续生成、熔断机制 | 第2、5章 |
约束的原则：采用故障安全默认值------所有能力默认关闭，必须显式开放。就像手机 App 权限管理，不会自动给你所有权限，需要你主动授权。
验证的关键：安全检查只看结构化数据（如工具返回的 JSON 字段），不看模型自由生成的文本------因为后者可能已被提示注入操纵。
纠正的原则：在确认无法恢复之前不暴露中间态------工具调用失败时先静默重试，不把半成品结果展示给用户。
3.2 工程范式的演进：五层包含关系
AI 应用工程的发展经历了五个阶段，每一层都是前一层的超集：
vbnet
┌──────────────────────────────────────────────────────────┐
│ 工程范式演进：层层包含 │
│ │
│ ┌─ Graph 工程 ──────────────────────────────────────┐ │
│ │ ┌─ Loop 工程 ─────────────────────────────────┐ │ │
│ │ │ ┌─ Harness 工程 ────────────────────────┐ │ │ │
│ │ │ │ ┌─ 上下文工程 ───────────────────┐ │ │ │ │
│ │ │ │ │ ┌─ 提示工程 ──────────────┐ │ │ │ │ │
│ │ │ │ │ │ 优化输入给模型的指令 │ │ │ │ │ │
│ │ │ │ │ └─────────────────────────┘ │ │ │ │ │
│ │ │ │ │ + 系统管理模型看到的所有信息 │ │ │ │ │
│ │ │ │ └───────────────────────────────┘ │ │ │ │
│ │ │ │ + 约束/验证/纠正/工具接口 │ │ │ │
│ │ │ └────────────────────────────────────┘ │ │ │
│ │ │ + 跨轮次持续自主运转 │ │ │ │
│ │ └────────────────────────────────────────┘ │ │
│ │ + 执行图编排（节点+边+状态） │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ 提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程 ⊂ Graph 工程 │
└──────────────────────────────────────────────────────────┘| 阶段 | 关注什么 | 核心问题 |
|---|---|---|
| 提示工程 | 优化输入指令 | 怎么跟模型说话效果最好？ |
| 上下文工程 | 系统管理模型看到的所有信息 | 模型需要看到什么才能做好决策？ |
| Harness 工程 | 模型之外的运行与治理 | 如何让 Agent 可靠地运行？ |
| Loop 工程 | 跨轮次持续自主运转 | 如何让 Agent 持续工作而不失控？ |
| Graph 工程 | 执行图编排 | 如何把多个 Agent 和流程组织成可控的图？ |
关键趋势 ：
当各家模型的能力越来越接近、不再是决定性的差异因素时，竞争优势就转移到了模型之外的工程实践。
实证案例 ：LangChain 在 Terminal Bench 2.0（评估 Agent 在终端环境中完成复杂任务能力的基准测试）上，得分从 52.8% 提升到 66.5%（从排行榜 30 名开外跃升至前 5），改变的不是模型，而是 Harness------让 Agent 自动检查执行结果、检测是否陷入重复循环、优化思考策略等工程手段。
3.3 Anthropic 三原则：构建有效 Agent 的核心原则
根据 Anthropic（Claude 的开发公司）的经验，成功的 Agent 系统遵循三个核心原则：
| 原则 | 含义 | 类比 |
|---|---|---|
| 保持简单 | 从最简单方案开始，只在确实必要时才增加复杂度。直接 API 调用优于复杂框架，清晰代码优于聪明抽象 | 做菜------先学会炒鸡蛋，再学分子料理 |
| 保持透明 | 明确显示 Agent 的规划步骤、执行日志和决策轨迹。黑箱里的错误一旦发生，外部观察者既无法定位也无法纠正 | 开放厨房------顾客能看到厨师怎么做菜 |
| 设计好 ACI | 从 Agent 视角设计工具接口，让错误从设计上就无法发生（防呆/Poka-yoke） | SIM 卡缺角------只能从一个方向插入 |
每多一层抽象都会成为以后调试时新的盲区。------保持简单的深层原因
3.4 模型选型：不只是看排行榜
选模型时容易犯的错：只看排行榜。实际上需要考虑多个维度：
| 维度 | 要考虑什么 |
|---|---|
| 思考能力 | 绝大多数 Agent 需要支持 Reasoning 的模型，只有极简单场景例外 |
| 输出速度 | Agent 往往需要多轮推理，每轮都要等模型输出完成才能执行下一步，速度直接决定端到端延迟 |
| 多模态 | 是否需要处理图像、音频等 |
| 策略边界 | 模型在基准测试中具备某种能力，不代表产品一定允许你调用------不同厂商对网络安全、隐私数据、高风险操作有不同限制 |
| 闭源 vs 开源 | 闭源领先但贵；开源差距 6 个月内且便宜，可私有化部署、支持微调定制 |
| 必须实测 | 在自己的真实任务上测试------模型是否愿意执行、接口是否暴露所需能力、服务条款是否允许 |
关键提醒 ：
模型选型不能只比较准确率、价格和速度，还要在自己的真实任务上测试。排行榜上的能力不等于你在实际产品中能调用的能力。
3.5 编排模式：工作流 vs 自主 Agent
| 工作流（Workflow） | 自主 Agent | |
|---|---|---|
| 决策方式 | 确定性路径，预先定义好步骤 | ReAct 实时决策，每步自主选择 |
| 适合场景 | 强流程控制、攻击面小、缺变通 | 开放式任务、需明确停止条件 |
| 优缺点 | 可靠但不够灵活 | 灵活但可能跑偏 |
两者可以混合使用------比如 n8n 平台支持工作流中嵌入 Agent 节点，或者"Agent 先写工作流再执行"的模式。
框架谱系（2026 时点）：
| 框架 | 特点 |
|---|---|
| Codex Harness | 开源运行时 |
| Claude Agent SDK | Harness 不开源 |
| LangChain-LangGraph | 主流开源框架 |
| n8n | 可视化工作流 + Agent 混合 |
| Dify | 低代码 Agent 平台 |
| CrewAI | 多 Agent 协作框架 |
| OpenClaw | 本地优先，20+ 消息渠道 |
| DeepSeek Harness | "一切皆插件"理念 |
| Pi | 极简框架 |
3.6 三层护栏：Agent 的安全保障
护栏是 Harness 工程中关于安全的核心机制。为什么需要三层？因为处在同一个上下文里的 Agent，很难判断自己是否已经被注入------上下文层护栏给不出保证，所以需要多层防御。
┌──────────────────────────────────────────────────────────┐
│ 三层护栏（按被绕过难度递增） │
│ │
│ ┌────────────────────────────────────────┐ │
│ │ 第一层：上下文层护栏 │ │
│ │ 管什么：Agent 能看到什么 │ │
│ │ 机制：系统提示词中的安全规则 │ │
│ │ 弱点：提示注入可以绕过------同一上下文里的 │ │
│ │ Agent 很难判断自己是否已被注入 │ │
│ └────────────────────────────────────────┘ │
│ ↓ 被绕过难度递增 │
│ ┌────────────────────────────────────────┐ │
│ │ 第二层：执行层护栏 │ │
│ │ 管什么：Agent 能做什么 │ │
│ │ 机制：须上下文之外的机制复核 │ │
│ │ 例子：权限控制、工具调用审批 │ │
│ └────────────────────────────────────────┘ │
│ ↓ 被绕过难度递增 │
│ ┌────────────────────────────────────────┐ │
│ │ 第三层：数据层护栏 │ │
│ │ 管什么：世界最终被改成什么样 │ │
│ │ 机制：数据库级强制约束 │ │
│ │ 例子：外键约束、唯一性约束、事务回滚 │ │
│ └────────────────────────────────────────┘ │
│ │
│ 三层各自独立，互为兜底 │
└──────────────────────────────────────────────────────────┘| 层级 | 管 | 机制 | 被绕过难度 |
|---|---|---|---|
| 上下文层 | Agent 能看到什么 | 系统提示词中的安全规则 | 最容易（提示注入可绕过） |
| 执行层 | Agent 能做什么 | 上下文之外的机制复核（权限、审批） | 中等 |
| 数据层 | 世界最终被改成什么样 | 数据库级强制约束（外键、事务） | 最难 |
为什么需要三层？ 因为任何单层都可能被绕过：
- 上下文层：提示注入攻击可以在上下文中植入恶意指令，而同一上下文中的 Agent 很难察觉
- 执行层：如果攻击者成功让 Agent 发出了危险的工具调用，执行层的权限控制可以阻止它真正执行
- 数据层：即使工具调用通过了权限检查，数据库约束也能防止不合法的数据修改
四、五个贯穿全书的设计模式
这五个模式在全书每一章都会反复出现，是 Agent 设计的"通用语法"：
| 模式 | 核心思路 | 类比 | 解决什么问题 |
|---|---|---|---|
| 提议者---审核者 | 产出和评判由两个不共享上下文的角色承担 | 论文审稿------作者写初稿，审稿人独立评审 | 自审不可靠 |
| 渐进式披露 | 目录常驻、细节按需加载 | 图书馆------书架目录永远在，具体书页只有打开时才看到 | 上下文空间有限 |
| 只增不改 | 可缓存、可重放、可审计 | 银行流水------只追加记录，不修改历史 | 需要可追溯和可回放 |
| 边界集 + 保留集 | 改与不该影响的两批样本都要测 | 修水管------修了厨房的水管，也要确认卫生间的水没坏 | 改动可能影响预期之外的地方 |
| 最小 diff + 可回滚 | 每次只改一小步，出问题立刻回退 | 版本控制------每次 commit 只改一小部分 | 需要归因和回退能力 |
为什么这些模式能穿越模型迭代周期？ 因为它们描述的不是某个模型的用法，而是智能系统与世界交互的基本模式。不管底层模型如何升级，这些模式依然适用。
五、三条学习路径：Agent 如何变得越来越强
Agent 的能力提升有三条路径，对应全书的不同章节：
arduino
┌──────────────────────────────────────────────────────────┐
│ Agent 的三条学习路径 │
│ │
│ 路径1：任务内上下文适应（第2章） │
│ → 在单次任务中，通过管理上下文让 Agent 做得更好 │
│ → 压缩历史、注入知识、管理注意力 │
│ │
│ 路径2：跨任务外部产物更新（第3、9章） │
│ → 把一次任务中学到的经验保存下来，供下次使用 │
│ → 更新文档、Prompt、Skill、程序 │
│ │
│ 路径3：参数更新（第8章） │
│ → 通过后训练（SFT + RL）让模型本身变得更强 │
│ → "SFT 记忆、RL 泛化" │
│ │
│ 从左到右：改动范围越来越大，见效周期越来越长 │
└──────────────────────────────────────────────────────────┘| 路径 | 改动范围 | 见效速度 | 对应章节 |
|---|---|---|---|
| 任务内上下文适应 | 单次任务 | 立即 | 第2章 |
| 跨任务外部产物更新 | 跨任务/跨会话 | 中等 | 第3、9章 |
| 参数更新（后训练） | 模型本身 | 最慢 | 第8章 |
六、对《苦涩的教训》的态度
Richard Sutton 的《苦涩的教训》主张：利用计算和学习的通用方法最终会胜过人工设计的特定方法。作者的态度是：方向认同，节奏务实。
模型还做不稳的，Harness 先补上；模型每内化一层，Harness 就卸下一层。
历史上已经多次发生这个模式：
- Few-shot 技巧 → 被模型内化，不再需要手动写示例
- JSON 容错 → 被模型内化，不再需要重试逻辑
- 提示词改写 → 被模型内化，不再需要复杂提示工程
类比：就像辅助驾驶------当自动驾驶还不够可靠时，先靠人类辅助；当技术进步后，逐步把控制权交给机器。不是一步到位，而是渐进过渡。
七、小结
本章建立了理解全书的基础框架：
- Agent = LLM + 上下文 + 工具（大脑 + 眼睛 + 手脚）
- ReAct 循环：思考→行动→观察，直到完成
- Harness 工程：模型之外的运行与治理层（上下文管理 + 工具接口 + 约束 + 验证 + 纠正）
- 三层护栏：上下文层 → 执行层 → 数据层（被绕过难度递增）
- 五个设计模式：提议者-审核者、渐进式披露、只增不改、边界集+保留集、最小diff+可回滚
- 三条学习路径：任务内适应 → 跨任务更新 → 参数更新
行业趋势 ：
行业正从'能做事'向'可靠地做事'转变，Harness 工程因此成为核心竞争力。
思考题要点（10 题选摘）
- ReAct 累计缓存读取量近似二次增长------因为每轮都要把之前所有历史重新读一遍。如何降低？（→ 第2章 KV Cache）
- "模型即 Agent"与"Harness 重要性上升"两个趋势如何共存？------RL 内化的是决策策略，工具执行和可靠性保障仍需 Harness
- 工具风险随参数动态变化（delete_file 删普通文件 vs 系统文件）→ 需要动态风险评估
- 举例说明某个工程手段会随模型进步而过时------对应"原则穿越迭代周期"的挑战
- 上下文层护栏为什么不够？------同一上下文中的 Agent 很难判断自己是否已被注入