深入理解 AI Agent — 本课题摘录
读了哪几章: 第 2 章(上下文工程)、第 4 章(工具)、后记。 全书十章,其余各章本轮没读。
这本 2026 年的中文书是本轮唯一一份"把整件事的框架先立起来"的材料。前面读的都是"某一家怎么做",这本给的是"该分成几件事来想"。
它对本课题回答了什么
一个可以直接当讲义骨架的公式
它的公式是:agent = 大模型 + 上下文 + 工具。
对应三个问题:它看到什么、它能做什么、怎么验证它做得对不对。
书自己的话:这三个问题不会过 时——它们描述的不是某个模型的用法,而是一个智能系统与世界交互的基本方式。 (依据:书 · 深入理解 AI Agent:设计原理与工程实践 §后记 —— 全书公式是「Agent = LLM + 上下文 + 工具」,对应「看到什么、能做什么、如何验证做得对不对」三个问题,书称这三个问题不会过时因为它们描述的是智能系统与世界交互的基本方式)
这和本课题自己定的"一个内核 + 四圈外壳"高度重合,而且是独立得出的:
- 它的"上下文" = 我们的"喂它什么";
- 它的"工具" = 我们的"它能做什么";
- 它的"如何验证" = 我们的"怎么知道它好不好"。
它没有单列我们那圈"人怎么看见与插手"——这一点上我们的划分更全。
决定一:一次请求被切成"静态前缀 + 轨迹"
上半部分(系统提示 + 工具定义)在整个对话过程中保持不变;下半部分(对话历史)随着交互不断增长。
书里的原话:理解了这个结构,就能理解为什么"前面不能动、后面可以压缩"。 (依据:书 · 深入理解 AI Agent:设计原理与工程实践 §2 —— 一次 API 调用的上下文由「系统提示词 + 工具定 义」构成的静态前缀与「用户消息 + 模型回复 + 工具结果」构成的动态轨迹两半组成,书称理解这个结构就能理解为什么「前面不能动、后面可以压缩」)
这跟 kun 的"请求被硬切成两段"是同一句话,而这本书把它讲成了一条可教的原理而不是某一家的实现。 讲义可以用这本书的表述方式来开这一节。
一个能当反面教材的真实翻车故事
某团队的客服 agent 每天处理十万次对话。工程师为了让它"知道"当前时间,在系统提示里加了一行实时时间戳。
第二天:所有对话的首个词的延迟从 0.5 秒涨到 3~5 秒,月度推理账单几乎翻了一倍。
代码没问题,模型也没换——问题是那一行时间戳让前缀缓存在每次请求都完全失效。 (依据:书 · 深入理解 AI Agent:设计原理与工程实践 §2 —— 书里的案例是在系统提示词里加一行实时时间戳导致首 token 延迟从 0.5 秒涨到 3-5 秒、月度推理账单几乎翻倍,原因是前缀缓存每次请求都完全失效)
本课题已经四次撞上"每轮都变的东西不能进前缀"(kun、agentscope、nanobot、hermes 的日期降精度)。 这本书给了这条规律的代价数字。讲义讲这一节时,应该用这个故事开头,而不是用抽象的道理。
决定一的一条实验证据:信息怎么组织,比措辞重要得多
它做了一组消融实验(逐项关掉组件看影响):
| 改什么 | 结果 |
|---|---|
| 只改语气与风格(专业中立 / 夸张自信 / 轻松加表情) | 影响相对有限 |
| 只打乱信息组织(内容全保留,去掉标题层次,把有序流程拆成无序规则集合) | 成功率下降超过 30% |
| 只移除工具描述文字(保留函数签名和参数定义) | 工具调用错误率增加 45% |
(依据:书 · 深入理解 AI Agent:设计原理与工程实践 §2 —— 基于 Tau-Bench 的消融实验显示——改语气与风格对任务完成率影响相对有限、打乱信息组织(内容不变去掉标题层次)成功率下降超过 30%、移除工具描述文字(保留签名)工具调用错误率增加 45%)
书给的解释:当规则以无序方式呈现时,模型难以识别其中的优先级和依赖关系——例如"先验证身份再处理退款"这条被拆散后,agent 有时就会跳过身份验证直接退款。
它的原则句:对人类友好的信息组织方式,对模型同样友好。
这跟 onyx 的"同一句指令换个位置,遵从率从九成掉到三成"是同一族证据的两个角度:
- onyx:一条指令放哪儿;
- 这本书:整篇提示怎么组织。
两条合起来是本课题第一个决定最有分量的经验证据。
方法论比结论更值钱:书自己说——当 agent 表现不佳时,与其全面重写提示词,不如先做消融实验,逐项关掉各个组件,看哪个影响最大。
这条我们要用:原型跑起来之后,评估不该是"感觉好像变好了",而是"关掉这一项,分数掉多少"。
决定四:最小循环长什么样,以及它自己在注释里承认缺了什么
书给了一个二十行的最小循环:调模型 → 有工具调用就逐个执行、把结果按 id 追加回消息 → 没有就打印并跳出。
关键在它的注释:生产代码这里需要一个轮数上限——因为 agent 会陷入反复调用同一个工具的死循环。 (依据:书 · 深入理解 AI Agent:设计原理与工程实践 §2 —— 书给出的最小 agent 循环是 while True 调模型、有 tool_calls 就逐个执行并按 tool_call_id 追加 role=tool 消息、没有就输出并 break;代码注释明写生产代码需要 max_iterations 上限,因为 agent 会陷入反复调用同一个工具的死循环)
它对循环职责的总结句:agent 框架的核心工作就是管理这个消息列表——在合适的时机往里追加消息, 然后把整个列表送给模型。后续所有的上下文工程技术,本质上都是在优化这个列表的内容和结构。
这句话可以直接当讲义第一节的收束句。 "循环 = 管理一个列表"是本课题最朴素也最准确的一句概括。
还有一条分工说得很干净:模型负责决策(调用什么工具、传什么参数),框架负责执行(实际调用接口、运行代码)。
决定二:工具定义也在走"按需披露",而且已经是接口层的原生能力
2026 年以来,工具定义本身在向"渐进式披露"演进:静态前缀里只保留工具的名称和简述,完整定义在模型按需请求后追加到轨迹末尾。
它解释了为什么追加到末尾不破坏缓存:每个词的中间结果只依赖它之前的内容,所以在末尾追加不会改变任何已缓存的部分。
一个容易误解的点它专门澄清了:"追加到末尾"只发生在工具被发现的那一轮。此后这个定义就固定在轨迹里的原位置,不是每轮都被重新搬到最新的末尾。 (依据:书 · 深入理解 AI Agent:设计原理与工程实践 §2 —— 工具定义的按需披露已是 API 层原生能力,静态前缀只留名称与简述、完整 schema 在模型请求后追加到轨迹末尾; 且只在被发现的那一轮追加,此后固定在原位置不再每轮搬运,否则每轮都要重新计算前缀、缓存失去意义)
这一条比 cherry-studio 的"折叠成三把元工具"更进一步:那是框架补丁,这是接口原生。 而且"只在发现的那一轮追加、之后固定在原位"这个细节,是自己实现折叠时最容易搞错的地方。
它还给了这套机制的一条约束:模型必须在训练中见过"工具定义出现在对话中间"这种模式——所以只有较新的模型支持。
决定三最值得记的一条:静默改写参数是最隐蔽的坑
它举了一个真实案例:某编辑工具的参数传递层会把中文弯引号静默转换成英文直引号。
于是:模型通过读取工具看到文件里的弯引号(读取工具原样返回),把它原样传进替换工具;但参数传递层已经把它转成了直引号,与文件实际内容不匹配,工具返回"未找到匹配"。
模型反复尝试、反复失败——它无法理解为什么自己明明看到的内容工具却找不到。 (依据:书 · 深入理解 AI Agent:设计原理与工程实践 §4 —— 静默输入转换的案例是编辑工具的参数传递层把中文弯引号静默转成直引号,导致模型从读取工具看到的内容与替换工具能匹配的内容系统性不一致,模型反复失败且无法 自行诊断;另一种是静默参数注入——bash 工具给所有提交命令自动追加一个参数,旧版本不支持就一直报错)
它由此提出一条基础原则:模型感知到的世界与工具操作的世界之间,不能存在系统性的偏差。
这条对本课题第三个决定是必修,而且比"结果怎么回填"更底层: 读取工具看到的和写入工具接受的,必须是同一套字节。
它还给了补救办法:如果确实需要规范化处理,必须在工具描述里说明,并在工具返回中明确告知模型。
决定二:工具描述的核心是"什么时候用",不是"能做什么"
| 原则 | 说的是 |
|---|---|
| 讲清什么时候用 | "搜索相关内容"远不如"当需要获取实时信息或查找未知事实时使用" |
| 边界比能力更重要 | 大多数调用失败的根因不是模型不知道工具能做什么,而是不知道工具不能做什么 |
| 参数用具体例子代替抽象规范 | 写出一个真实的取值,模型可以直接套用,无需额外思考 |
| 注明执行代价 | "大型网站可能需要 5~10 秒;如果只需要元信息,请考虑用另一个工具" |
| 附 1~5 个真实调用示例 | 参数结构说 明只能描述类型,表达不了典型的参数组合与隐式约定 |
(依据:书 · 深入理解 AI Agent:设计原理与工程实践 §4 —— 工具描述的核心是让模型知道「什么时候用」而非只是「能做什么」,清楚列出边界(做不到什么、不接受什么输入)往往比描述能力更重要,因为大多数工具调用失败的根因是不知道工具不能做什么)
一条实用的调试原则:当 agent 频繁选错工具时,应优先检查工具描述而不是怀疑模型能力。修正工具描述的投入产出比,通常远高于换一个更强的模型。
它没回答什么
- 循环出问题时怎么办——第 2 章讲了循环长什么样,但重试、回滚、打断、审批都不在这一章。
- 并发的判据——只提了"两个工具没依赖就能并行",没讲怎么判断有没有依赖。
- 其余八章——入门与编排光谱、记忆与知识库、代码生成、评估、后训练、持续进化、多模态、多 agent,本轮都没读。
坑与代价
- 它是一本书,给的是原理和案例,不是可运行的实现。 那二十行最小循环之外,它没给任何完整代码。
- 接口示例绑在特定厂商的写法上。 换一家要重新对照。
- 它的很多数字来自它自己做的实 验(消融实验的三成与四成五)。这些是它的实验条件下的结果,不是普适常数。
判断(无锚): 这类数字的价值在于告诉我们"该去测哪一项",不在于数值本身。我们自己的原型要重跑一遍才算数。 如果错,会错在: 如果我们的提示词本来就只有几十行、结构简单,那"信息组织"这一项根本没有可打乱的余地,消融实验测不出差别。
- 后记的两朵乌云(做不到实时交互、学不会持续积累经验)提醒了一件事:本课题划出的六条边界里,"不管流式"这一条正好落在它说的第一朵乌云上。 这个边界短期成立,但不会长期成立。