AI-Agent-第1章学习笔记
深入理解 AI Agent · 第 1 章学习笔记:AI Agent 入门
📖 原书:《深入理解 AI Agent:设计原理与工程实践》(李博杰 著,v2.0)
📌 本章定位:全书的概念地图——快速引入 Agent 的核心公式、运行循环、工程框架和设计模式
🎯 一句话总结:Agent = 大脑 + 眼睛 + 手脚;模型正在商品化,真正的竞争力在 Harness 工程。
一、核心公式:现代 Agent = LLM + 上下文 + 工具
这是全书的基石公式,可以从三个层次理解它:
| 层次 | 表述 | 含义 |
|---|---|---|
| 工程层 | LLM + 上下文 + 工具 | 最小可运行实现 |
| 直觉层 | 大脑 + 眼睛 + 手脚 | 大脑思考决策,眼睛决定看什么,手脚决定做什么 |
| 学术层 | Policy + Observation Space + Action Space | 强化学习的经典形式化语言 |
两个重要补充:
- 公式只描述 Agent 边界内部,不包含环境(Environment)。Agent 与环境是闭环交互的两方:环境给观察 → Agent 行动 → 环境状态改变 → 新的观察……
- 生产形态下,公式展开为
Agent = Model + Harness,其中Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正。
最关键的一个洞察:扩展接口 > 换更强的模型
在底层模型固定时,提升 Agent 任务表现最主要的系统工程手段,往往就是重新定义或扩展观察空间与动作空间。许多看似需要"更聪明模型"的问题,其实只是接口问题。
书中用两个产品证明这一点:
- Manus:率先把 Deep Research、Coding、Computer Use 三条独立路线放进同一个 Agent——虚拟浏览器扩大观察空间,文件系统/代码执行扩大动作空间。它没有靠换更强的模型成为通用 Agent,而是取了三个空间并集。
- OpenClaw:把接口延伸到用户的数字生活——通过 WhatsApp、Telegram、iMessage 等消息渠道接收任务,通过本地 Gateway 连接 Google Drive、Notion 和本地文件系统。分散在各处的数据都进入同一个 Agent 的观察空间。
二、三大组件逐一拆解
1. 工具:Agent 的手脚
按交互方向分五类:
| 类别 | 作用 | 例子 |
|---|---|---|
| 感知工具 | 让 Agent 访问信息 | 搜索引擎、文件系统、API |
| 执行工具 | 让 Agent 改变世界 | 代码执行、文件操作、外部 API 调用 |
| 协作工具 | 与其他 Agent/人分工 | 委托子 Agent、请求人类确认 |
| 事件触发工具 | 外部输入驱动 Agent(被动激活) | 新邮件、定时任务、Webhook |
| 用户沟通工具 | 主动向用户传递信息 | 文字消息、语音通话、邮件 |
工具调用四步流程:① 在上下文声明工具 → ② 模型自主决定调不调、调哪个、传什么参 → ③ 结果追加回上下文 → ④ 模型决定下一步。这就是 ReAct 的基础。
工具设计的核心原则:
- 通用基础能力用于组合与探索(如代码解释器——任务升级时不用堆专用工具)
- 专用工具用于约束高风险和强业务规则操作(支付、删数据、发邮件——参数明确、权限受限、全程可审计)
- 通用性扩大出错面 → 代码必须跑在沙盒里,默认无网络、限路径、限资源
2. LLM:Agent 的大脑
- LLM 的能力 = 预训练积累的世界知识 + 后训练固化的决策策略
- 独特能力:内部思考——行动前先规划推演,不改变环境却显著提升行动质量
- "模型即 Agent"范式:Kimi K3、GPT-5.6 通过 RL 把工具调用决策内化为原生能力(何时调用、调哪个、传什么参数),编排循环从客户端移到了服务端
- ⚠️ 澄清一个常见误解:RL 内化的是"决策策略",不是"工具执行机制"——web_search、code_runner 的真实实现仍在模型之外的 Harness/基础设施里
值得反复品味的观点:Harness 会被模型"吃掉"吗?
书中的立场:方向认同,节奏务实。
方向:不怀疑模型会持续吃掉 Harness(工具调用、长程规划都曾靠外部编排,如今已是模型原生能力)。但这个过程远比想象中慢——模型此刻的能力边界,就是 Harness 此刻的价值所在。模型每内化一层,Harness 就卸下一层,转而兜底新的能力前沿。
Harness 原指马具(缰绳与挽具)——不是限制马奔跑,而是把力量引导到正确方向。
Agent 行为改变的三条路径
| 路径 | 载体 | 特点 |
|---|---|---|
| 上下文适应 | 当前上下文(示例、状态、检索结果) | 即时、低成本;任务结束不保留 |
| 外部产物更新 | 知识文档、Prompt/Skill、程序/Harness | 跨任务持久、可审计 |
| 参数更新 | 模型权重(SFT、RL) | 高维能力、广泛泛化;成本高 |
三者协同:临场适应 + 可控积累 + 能力内化。
3. 上下文:Agent 的眼睛
每次调用 LLM 的上下文由五部分组成:
┌─ 静态前缀 ─────────────┐
│ ① 系统提示词(岗位说明书) │
│ ② 工具定义(可用的手脚清单)│
└────────────────────────┘
┌─ 动态轨迹 ─────────────┐
│ ③ 用户消息(含 RAG 注入知识)│
│ ④ 模型回复(reasoning + content + tool_calls)│
│ ⑤ 工具执行结果 │
└────────────────────────┘
消融实验(实验 1-1)的结果——每个组件都不可替代:
| 去掉的组件 | 后果 |
|---|---|
| 工具定义 | ❌ 无法调用任何工具 |
| 工具结果 | ❌ 盲目执行、陷入无限循环 |
| 思考过程(reasoning) | △ 决策不连贯、前后矛盾 |
| 历史消息 | △ 重复操作、重复犯错 |
核心洞察:上下文决定了 Agent 能看到什么,而 Agent 只能基于它看到的信息做决策。 就像人蒙住眼睛就无法做出合理判断。
三、ReAct 循环:想 → 做 → 看
Agent 执行任务的核心模式。名字只含 Reasoning + Acting,实际是三环节:
思考(下一步做什么)→ 行动(调用工具)→ 观察(工具结果)→ 思考 → …直到任务完成
关键事实:Agent 的上下文 = 静态前缀 + 轨迹(trajectory)
- 轨迹 = 不断追加的消息历史(用户消息 + 模型回复 + 工具结果)
- 每轮 LLM 调用都能看到完整轨迹 → 清楚任务进行到哪一步
- 结构化轨迹带来三个好处:易解释调试、可分析行为模式、可沉淀为训练数据(形成从经验中学习的闭环)
书中用"多币种收入汇总"的例子展示了完整轨迹:汇率转换 → 代码汇总 → 最终回答,3 次迭代、4 次工具调用。
四、Harness 工程:模型之外的竞争力
一个能跑的 Demo 和一个可靠的产品之间还有巨大的鸿沟——模型会幻觉(编造不存在的工具)、选错工具、出错后无法自我恢复。这些脆弱点正是 Harness 工程要解决的。
Harness 五要素
Agent = Model + Harness
Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正
| 要素 | 职责 | 例子 |
|---|---|---|
| Context(上下文) | 提供充分感知信息 | 系统提示词、知识库、Agent 状态栏 |
| Tools(工具接口) | 接口清晰、命名直观、参数有例子 | MCP 工具、代码解释器 |
| Constrain(约束) | 故障安全默认值,能力默认关闭、显式开放 | Claude Code 每个工具默认需授权 |
| Verify(验证) | 只看结构化数据,不信模型自由文本 | Linter、类型检查、调用结果校验 |
| Correct(纠正) | 静默重试、失败回退,不暴露中间态 | 熔断器、接续生成、人工兜底 |
"能做事"(上下文+工具)与"不做错事"(约束+验证+纠正)的重要性是不对称的:Claude Code 的 Harness 中绝大部分代码是约束、验证与纠正——工具本身只是一小部分,围绕工具的保障机制才是核心。
工程范式的演进(层层包含,不是替代)
提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程 ⊂ Graph 工程
一个有力例证:LangChain 在 Terminal Bench 2.0 上得分从 52.8% → 66.5%(30 名开外 → 前 5),改变的不是模型,而是 Harness(自动检查执行结果、检测重复循环、优化思考策略)。
构建 Agent 的三大原则(Anthropic 经验)
- 保持简单——直接的 API 调用优于复杂框架;每多一层抽象都是调试时新的盲区
- 保持透明——显示规划步骤、执行日志、决策轨迹;黑箱里的错误无法定位也无法纠正
- 设计好工具接口(ACI)——从 Agent 视角设计接口而非程序员视角;用"防呆"(Poka-yoke)思路让错误无法发生(如 SIM 卡缺角设计)。模型与工具之间唯一的沟通通道就是接口本身,模糊的接口会被模型放大成系统性错误。
编排模式:工作流 vs 自主 Agent
决策顺序(从简单到复杂):单次 LLM 调用 → 工作流 → 自主 Agent
| 工作流 | 自主 Agent | |
|---|---|---|
| 执行路径 | 代码写死、确定性 | 模型根据环境反馈实时决定 |
| 优势 | 流程可控、攻击面限于单节点、业务规则代码强制 | 灵活、适合开放式问题 |
| 劣势 | 缺乏变通,预设外的情况只能交还人类 | 高成本、复合错误风险、可能死循环 |
| 适用 | 订票流程、合规要求严格的流程 | Coding、Computer Use、迭代研究 |
- 自主 Agent 的本质 = 在循环中使用工具的 LLM(即 ReAct),必须设计明确的停止条件
- 实践中常混合使用:关键流程用工作流,灵活部分用自主模式(如 n8n)
护栏与安全性:三层防线
按被绕过的难度分层(越往下越不依赖模型自己的判断):
| 层 | 管什么 | 典型机制 |
|---|---|---|
| 上下文层 | 模型能看到什么(进入上下文前拦截) | 相关/安全分类器、越狱与提示注入检测、Constitutional Classifiers |
| 执行层 | 模型能做什么(动作生效前验证) | 工具风险评级、独立审查进程、沙盒隔离、人在回路、PII 过滤 |
| 数据层 | 世界最终能被改成什么样 | 数据库行级安全、约束校验、受控视图 |
关键区分:越狱 = 用户自己绕过限制;提示注入 = 攻击者通过外部数据(网页、文档)间接操纵模型。
**人工干预(人在回路)**的两种触发:超过失败阈值(重试/操作次数上限)、高风险操作(大额退款、付款)。
五、贯穿全书的五个设计模式
| 模式 | 核心思想 | 应用场景 |
|---|---|---|
| 提议者—审核者 | 产出与评判由两个不共享上下文的角色承担;自审不可靠 | 知识更新、工具调用审批、PPT/视频/日志实验、评估 |
| 渐进式披露 | 先给可检索目录,按需加载细节;同时优化上下文预算与选择精度 | Agent Skills、分层检索、主动工具发现 |
| 只增不改 | 状态只追加、不回头修改;换来可缓存、可重放、可审计 | KV Cache 前缀稳定、事件式记忆、schema 追加到轨迹末尾 |
| 边界集 + 保留集 | 每次修改同时验证"该变的样本"和"不该变的样本" | 回归任务、训练/评估隔离、更新提案验证 |
| 最小 diff + 可回滚 | 修改尽量小、带来源、可单独回滚;让归因成为可能 | 知识更新、代码补丁、Prompt 更新 |
六、本章小结(核心要点回顾)
- Agent = 大脑 + 眼睛 + 手脚,三者缺一不可
- 扩展眼睛和手脚是最主要的能力杠杆——接口问题常被误认为模型问题
- 眼睛(上下文)是决定性因素——静态前缀 + 动态轨迹,消融任何组件都会显著退化
- Harness 是竞争力所在——模型商品化时代,约束/验证/纠正决定"可靠地做事"
- 从简单到复杂:先提示词 → 再工作流 → 最后自主 Agent
- 五个设计模式贯穿全书:提议者—审核者、渐进式披露、只增不改、边界集+保留集、最小 diff+可回滚
- 安全是架构问题——从第一行代码考虑,三层护栏(上下文/执行/数据层)
七、我的思考
- 💡 "模型此刻的能力边界,就是 Harness 此刻的价值所在" 这句是我认为全章最有分量的话——它同时回答了两个问题:为什么 Harness 不会消失(模型内化是慢变量),以及 Harness 工程师该做什么(盯住能力前沿,持续"兜底")
- 💡 消融实验的方法论值得学:怀疑某个组件没用,不要猜,做对照实验。这比任何经验讨论都有说服力
- 💡 "产品能力的演进往往就是观察空间和动作空间的演进"——用这个视角重新看任何 Agent 产品的版本更新,都能看懂它到底在扩张什么接口
八、遗留问题(书中思考题摘选)
- 只能增强一项:更强的模型 / 更丰富的上下文 / 更多的工具,你选哪个?什么条件下会改变?
- "模型即 Agent"与 Harness 重要性上升,这两个趋势如何共存?框架未来的核心价值在哪?
- 除了工具结果缺失,还有哪些情况会导致 Agent 无限循环?如何设计检测和终止机制?
- 一个低风险工具在特定参数组合下变为高风险(如
delete_file删系统文件),如何做动态风险评估?
下一章预告:第二章《上下文工程》——全书最关键的一章,深入 KV Cache 原理、提示工程、Agent Skills 与上下文压缩。
