通读笔记(三):第 5–7 章(PART 1 收尾 + PART 2 前两章)
接
reading-notes-2.md。第 5 章 =text/08-ch05…(1157 行)· 第 6 章 =text/09-ch06…(1317 行)· 第 7 章 =text/10-ch07…(953 行)
第 5 章 Fine-Tuning(PART 1 的最后一格)
1. 开场三句抱怨(全书最好的开头技巧,值得学)
「这个模型结果还行,但对我们的医学术 语不够精确。」 「AI 生成的文字不错,但它不懂我们公司的内部黑话。」 「法律文档要更高的准确度,通用模型会犯太多细微的错。」(
:11–:16)
三句抱怨对应三种「提示词和 RAG 都救不了」的场景。这是第 5 章存在的理由。
微调的定义:在预训练好的模型上,拿你自己的数据继续训练,以适配特定用途 ——
真的去改模型的权重。(:32、:48)
书给的量级参照:OpenAI 发现,只用几百个例子微调 GPT-3 就能显著超过零样本;
他们建议至少 50–100 个好例子才能看到明显收益。(:51)
2. 三条路怎么选(表 5.1 在 :62,全书最有用的一张表)
| 提示词 | RAG | 微调 | |
|---|---|---|---|
| 改权重吗 | 否 | 否 | 是 |
| 领域知识 | 有限 | 来自外部源 | 烧进模型里 |
| 成本 | 最便宜 | 中(要基础设施) | 最高(要数据+算力+前期投入) |
| 控制语气/风格 | 难控 | 控制有限 | 精确可控 |
| 知识新鲜度 | 静态 | 动态 | 静态,除非重训 |
| 什么时候用 | 快速试验、基础任务 | 动态事实、知识落地 | 领域专长 、内部工作流 |
决策框架(5.1.1,三问,拆解可以直接照用):
- 提示词测试: 「换个更好的提示词,结果能接受吗?」
具体到可执行:写个更好的提示词,拿 10 个真实例子跑一遍;10 个里有 8 个过质量线就到此为止。
提示词只要几分钟,不花钱。(
:92) 例子:电商机器人太像机器人 → 系统提示加一句「永远专业而温暖地回应,像在帮一位重要的朋友」 → 5 分钟解决。 - 数据新鲜度: 「问题涉及的事实会经常变吗?」
书给的例子极犀利:今天你有 50 件蓝衬衫,明天卖光了。
用 RAG,机器人实时查库存;用微调,机器人会永远自信地告诉顾客「我们有 50 件蓝衬衫」。(
:107) - 一致性挑战: 「需要模型稳定地遵守某种格式或风格,或用专业领域知识吗?」
例子:法律助手必须按 Bluebook 格式引注、绝不编造判例。
详细的提示词试过了,但对话一长模型就忘了格式或编出案子。
拿 500 个正确引注的例子微调之后,即使 50 轮对话格式也不走样。(
:118)
混合(5.1.2): 生产系统常常两个都用 —— 理财顾问机器人微调来遵守特定的规划原则和风险框架,用 RAG 拉当前利率和税法。
⚠️ 一条重要的限制(书说得很好,拆解必须留):
微调过的模型没法在回答里引用具体文档,因为知识被烧进权重里、不带来源标注。 需要可核实、带文档引用的回答,就必须把微调和 RAG 或 agent 工具组合起来用。(
:131)
3. 三个案例
| 案例 | 做法与结果 | 书自己给的警告 |
|---|---|---|
| 医疗:Med-PaLM 2 | 拿医学知识、考题、临床指南微调 PaLM 2,美国医师执照考试 91% 准确率,超过医生平均分 | 「基准表现强不保证真实世界可靠」—— 拿考题训出来的模型,碰到考卷上没有的新病例可能很脆 |
| 金融:BloombergGPT / FinGPT | 500 亿参数、拿金融数据训;FinGPT 用 LLaMA + 5 万条财经新闻标题就在市场情绪分析上超过更大的通用模型 | 金融术语太独特,大量训练会覆盖掉模型的通用知识 —— 这叫「灾难性遗忘」;训练数据必须小心地掺入通用样本 |
| 代码:Codex | 拿源码微调 GPT | 微调过的代码模型擅长模式匹配和样板代码,复杂逻辑仍需人工细审 |
4. 数据准备(5.3.1)
「垃圾进,垃圾出」。(:207)
三条收集策略(:218):用已有数据(客服对话日志、FAQ、公开法律数据集)/
人工标注(分类任务、质量排序)/ 保证覆盖与平衡。
TIP 明说:宁可少而精,不要多而杂;领域专家应当参与数据审阅。(:235)
数据里的偏见会被微调放大。(:241)
格式:prompt-completion 对(JSONL,一行一个 JSON)。
书给 了具体样例(:275)。三条要求:
- 格式必须一致 —— 有的例子用
Q:有的用User:,模型会糊涂; - 注意 token 上限 —— prompt + completion 要在上下文长度内,而且最好远低于上限, 因为训练时可能把多个例子拼进一个 batch;
WARNING:如果模型有时该输出不同格式(有时只给答案、有时给要点列表), 每种格式都要给多个例子。只给一个要点列表的例子,它不会泛化。(:301)
训练/验证集切分: 留 10–20% 做验证集,分布要和训练集一致。
「验证损失开始上升就说明可能过拟合了」 —— 这是决定何时停训的信号。(:307)
小心数据泄漏: 验证集里的例子不能同时在训练集里。(:320)
5. 微调三种做法(5.3.3,本章的技术核心)
| 方法 | 训多少参数 | 效果 | 内存 | 什么时候选 |
|---|---|---|---|---|
| 全量微调 | 100% | 最高 | 最高 | 有多块高端 GPU,且要最大限度适配 |
| LoRA | ~0.1–1% | 很高(全量的 95–99%) | 低 | 有一块像样的 GPU,要强性能 |
| QLoRA | ~0.1–1% | 高(全量的 90–95%) | 最低 | GPU 资源有限但 要微调大模型 |
全量微调的代价有具体数字:训一个 70 亿参数的模型,全精度下至少要 28GB 显存,
否则得多卡协同。(:500)三个缺点:内存要求巨大、算力昂贵、有灾难性遗忘的风险。
LoRA(Low-Rank Adaptation,低秩适配)是怎么回事(:519):
「与其重写整本书(模型),不如只贴几张写着改动的便利贴。 这些便利贴(小矩阵)足以教会模型新行为,而且训起来又快又便宜。」
三步:冻住原模型 → 在特定部位加两个小矩阵(适配器)→ 只训这两个小矩阵,其余不动。
效果:只训 0.1%–1% 的参数,内存省到十分之一,还能拿到全量微调 95% 以上的效果。(:531)
QLoRA 在 LoRA 之上再压三层(:534):
- 4-bit 量化:权重从 16/32 位降到 4 位,光这一项就省约 75% 内存。 书给「量化」下了个好定义:就像压缩高分辨率图片 —— 丢一些细节,换来体积大幅缩小。
- NF4 格式:一种「聪明的压法」,缩小之后仍尽量保住最重要的权重信息。
(后文补充了原理:nf4 按正态分布来分配量化区间,对接近零的值精度更好 ——
而神经网络里的值大多接近零。
:672) - 双重量化:连量化的配置参数本身也压一遍,「像给 zip 文件再 zip 一次」。
训练时权重虽然存成 4 位,计算却在 float16 这类更高精度下进行,以保持稳定与准确。(
:548)
成果的量级:QLoRA 让你在一块 24GB 的消费级 GPU 上微调 70 亿参数模型,
在单块 80GB GPU 上微调 700 亿参数模型 —— 这以前只有大数据中心做得到。(:550)
⚠️ 一条反直觉的警告(书特意点出「与常见看法相反」,拆解必须留):
LoRA / QLoRA 在某些场景下的遗忘风险比全量微调更高 —— 因为只更新一小撮参数,如果那些参数恰好承载着通用能力,模型就可能把通用能力丢掉。 缓解:在训练数据里掺入原领域的「提醒」样例。(
:557)
6. 项目:QLoRA 微调 LLaMA-2-7B 做客服助手
选型理由说得很实在: LLaMA-2-7B 在对话任务上够好,又能在 24GB 消费级 GPU 上训;
13B / 70B 就得多卡或上云。(:590)
⚠️ 一条极重要的工程警告(书用粗体 Important 标出,:637):
虽然生产上可以部署量化模型,但微调永远要从全精度(FP32)或半精度(FP16/BF16)的基座开始。 绝不要在一个「已经被量化并那样保存下来」的模型上微调。 理由讲得很清楚:量化会在权重里引入小的舍入误差;你在这些已经有偏差的值上继续微调, 优化器调的是本来就略微错的权重,每一步训练都在累积这些不准,而不是纠正它们。 QLoRA 是在训练时加载模型时做量化,原始权重本身没被量化 —— 这两件事不一样。
LoRA 六个参数(书逐个解释了,拆解可以照用)(:694–:749):
r=8秩(rank):决定适配容量,即微调的「表达力」。 4–8 省内 存但学习容量有限;16–32 能抓更复杂的模式但更耗资源。lora_alpha=16缩放因子:控制适配对原模型的影响强度。 实际缩放 = lora_alpha ÷ r(这里 16/8 = 2)。target_modules=["q_proj","v_proj"]:只适配注意力里的 query 和 value 投影矩阵 —— 「这两个部件帮模型聚焦到相关信息上,微调它们通常收益最好」。 最新的最佳实践建议把所有线性层都纳进来(加 k_proj、o_proj、gate_proj、up_proj、down_proj), 内存代价不大。先从 q_proj / v_proj 起步,想更逼近全量微调再扩。lora_dropout=0.1:训练时随机关掉约 10% 的连接,防过拟合。bias="none":不训偏置项。书顺带把权重和偏置讲清楚了:输出 = (输入 × 权重) + 偏置,偏置管的是「基线该挪到哪」; 对微调这类适配任务,偏置通常没有权重重要。task_type="CAUSAL_LM":标准的自回归语言模型(预测下一个 token)。
结果:只加了原模型约 0.1% 的可训练参数 —— 70 亿里的三四百万。(:750)
训练基础(5.3.4 里插的那一小节,是全书对新手最友好的一段)(:754–:799):
四步循环 —— 前向传播(数据流过模型出预测)→ 算损失(比对正确答案,量化错得多离谱,越低越好)→
反向传播(算出每个参数对这个错误贡献了多少)→ 更新参数。
配的比方是扔飞镖:扔一镖(前向)→ 看偏了多远(损失)→ 分析动作哪里不对(反向)→
调整瞄准(更新)。
四个概念:批大小(一次处理几个例子再更新)/ 学习率(每步挪多大;太大会冲过头,太小训得慢)/
轮数 epoch(整个数据集过几遍;太多会过拟合)/
梯度累积(内存省法:攒几个小批的梯度再一起更新,等效于用更大的批)。
训练配置的实际值(:804):batch_size=1 + gradient_accumulation_steps=4(等效批大小 4)、
num_train_epochs=1、learning_rate=2e-4(比全量微调高,因为 LoRA 更新的参数少、需要更强的信号)、
fp16=True。
1000 个例子在 24GB 消费级 GPU 上跑 15–30 分钟,而全量微调可能要数小时到数天。(:868)
⚠️ 格式很关键: LLaMA-2 要 <s>[INST] 指令 [/INST] 回答 </s> 这个特定格式。
「用错格式会显著恶化微调效果。每个模型家族(LLaMA、Mistral、Falcon)结构都不一样。」(:850)
7. 知识蒸馏(5.4)
问题: 微调过的旗舰模型准,但太大、太贵、太慢,规模化服务不现实。(:977)
做法:把强大但笨重的「教师模型」的行为,转移到更小更快的「学生模型」上。
关键的简化(书讲得好):
经典机器学习里的蒸馏是让学生去匹配教师的软概率输出。 但对大型闭源模型,你根本拿不到内部概率。好在你不需要。 现代 LLM 蒸馏简单得多:学生只学着模仿教师的最终输出 —— 不要 logits,不要温度缩放, 不需要特殊权限。这叫序列级蒸馏(sequence-level distillation)。(
:990)
三步:拿一批领 域提示词过教师模型、把它的回答记下来 → 用这些输入-输出对微调一个小的学生模型 → 学生学会在同样输入下产出同样输出。
为什么对部署重要(三个数)(:1011):
- 成本:蒸馏出的模型通常比教师小 5–20 倍,内存和算力需求更低;
- 延迟: 小模型答得快,对聊天这类实时应用是关键;
- 灵活: 能跑在教师跑不了的普通硬件上 —— 小 GPU 实例、纯 CPU 服务器,甚至边缘设备。
OpenAI 的蒸馏流水线四步(:1044):捕获教师的补全(store=True 自动存)→
定义评测基准 → 微调学生 → 评测学生。
四条最佳实践:教师要够强(学生学不到教师没演示的东西)/ 样例要多样 /
频繁评测(不只看准确率,还要看语气、格式)/ 领域变了就重新生成数据、更新学生。
第 6 章 Creating Effective AI Agents(PART 2 的开门章)
1. 三个限制,一个一个来(6.1,这一章的骨架)
开场: 让 LLM 帮你订机票 —— 「帮我找下周二从纽约到旧金山的 早班机」,
它答「你可以试试达美或捷蓝」。「这几乎没什么用。它听懂了问题,却连不上航班 API、
查不了实时时刻、也订不了票。」(:16–:24)
| 限制 | 书给的具体场景 | 症结 |
|---|---|---|
| ① 静态知识 | 问「特斯拉和苹果现在的股价」→「抱歉,我没有实时股价」 | 训练时吸收的知识是冻结在某一时刻的快照。书的比方:一座巨大的图书馆,但所有书都是同一天印的 |
| ② 无法行动 | 「帮我明天下午三点约个团队会」→「建议:给你的团队发封邮件说明会议细节」 | 它隔着一堵玻璃墙 —— 看得见、描述得了数字系统和 API,却伸不过去 |
| ③ 无法管流程 | 「找下周二纽约到旧金山的航班,再订个 SFO 附近的酒店」→「我得说明一下:我没法访问实时订票系统」 | 它拆不出子任务(搜航班 → 筛结果 → 查酒店),更没法按序执行 |
agent 就是在 LLM 之上加的三样能力:接外部工具、执行动作、编排流程。(:128)
书给的一句话对照:「区别就在于,一个同事能给你讲清怎么订机票,另一个同事能真的替你订了。」(:136)
一个进度数字(值得引):
斯坦福 AI Index 报告:AI agent 处理真实计算机任务的成功率,一年之内从 12% 涨到 66%。 (
:210,引 [10] Stanford HAI AI Index Report 2026) ⚠️ 需要核实。这个数字没有给出具体是哪个基准。
2. 可靠 agent 的三个部件(6.2)
记忆(跨轮保住上下文) + 工具集成(接 API/数据库/外部系统) + 决策框架(编排动作与流程)
① 记忆
开场例子极简洁:「帮我找下周二去纽约的航班」→ 给了几个选项 → 「哦,要靠窗的座位」。
没有记忆:「抱歉,我不知道你指的是什么。」有记忆:「好的,现在按靠窗筛选。」(:238–:263)
| 短期记忆 | 持久记忆 | |
|---|---|---|
| 存多久 | 一个会话内,会话结束就丢 | 跨会话保留 |
| 比方 | 一张便签,随手记下关键细节 | 一本日记,记住每个用户的偏好与习惯 |
| 怎么实现 | 一个列表或字典存对话历史,轻量,不需要持久化存储 | 需要数据库(SQLite / MongoDB),数据要结构化并建索引 |
| 特有的坑 | 挤占有限的上下文窗口 | 隐私合规(GDPR):敏感数据要匿名化,用户要能控制记住什么 |
「什么时候把会话里的信息升级成长期记忆」这个设计问题,书给了三个触发条件(:366):
① 用户明确说要记住(「记住我喜欢靠窗」);② 跨多个会话被反复引用的信息;
③ 能改善未来交互的重要上下文。
实现上通常有一个抽取步骤:agent 从对话里识别出关键事实,存成结构化格式备用。
两种历史管理模式(6.2.2):
- buffer 缓冲:一个消息列表,原样存下每一轮。完整召回、零框架开销,
但内存随对话长度线性增长,适合短对话。
书特意说明:不需要什么专门的 memory 类,LangChain 模型直接吃
HumanMessage/AIMessage的列表。(:382) - summary 摘要:用一个 LLM 把对话压成一段滚动摘要。
代价说得很老实:每次摘要都是一次 LLM 调用,增加延迟和成本。
短对话用 buffer 更简单也更便宜;只在会话经常超出上下文窗口时才上摘要。(
:455) 生产上很多团队先用 buffer,撞到上下文上限了再加摘要。(:462)
⚠️ 一条时代注脚: 书自己说 LangChain 的这些记忆原语已经演进了 ——
LangGraph(建在 LangChain 之上的图式编排层)现在提供更健壮的状态管理:
检查点(暂停与恢复 agent 执行)、人在环审批、跨会话持久记忆。
生产 agent 建议用 LangGraph 的状态管理,而不是这里展示的独立记忆类。(:474)
② 工具集成
核心论断:工具集成是减少幻觉最有效的手段之一。
幻觉的三个成因(和第 1 章呼应):无法验证自己的回答 / 无法访问外部知识 / 无法提供可核实的证据。(:496)
一个重要的区分(6.2.3,拆解要抓):
被动检索 vs 主动动作。 RAG 是被动地取信息; agent 能主动执行会改变外部系统状态的工具 —— 取到航班选项(被动检索)之后,agent 能真的调订票 API 订下来、 通过邮件服务发确认信、更新用户日历。这些是 RAG 单独做不到的。 这种「能行动」的能力,才是把信息检索系统变成真正的 agent 的那一步。(
:523)
天气 API 的前后对照(可直接做走查)(:532):
- 无工具:问「巴黎现在天气怎么样」→「巴黎现在晴,25°C」—— 这是幻觉,它其实不知道;
- 有工具:「让我帮你查一下」→(调天气 API)→「巴黎现在 20°C,多云」。
书引的两项研究(:562):
- 一个装了自我评估机制的 LLM,对 77.2% 的「它不知道的问题」正确地选择了去查 API;
- 给代码生成模型接上实时 API 文档检索能提升表现,尤其是对冷门 API —— 那正是幻觉率最高的地方。
三条工具可靠性策略(6.2.4,给了完整代码): ① 把回答锚在工具上; ② 失败兜底(fallback) —— 超时、限流、网络故障都会发生, 兜底逻辑保证 agent 优雅地失败而不是编一个答案; ③ 校验工具输出 —— 书给的例子很具体:天气 API 返回的温度必须在 −90 到 60°C 之间, 超出范围就当无效数据丢掉。
③ 决策(6.2.5) 「记忆和工具让 agent 能用,决策才让它聪明。」
| 规则式 | AI 驱动 | |
|---|---|---|
| 怎么做 | 预设逻辑:提到「flight」就调订票 API | 让模型自己推理该走哪几步、用哪些工具 |
| 优点 | 简单、透明 | 灵活、可扩展、能处理复杂查询 |
| 命门 | 僵硬。「帮我找 Union Square 附近能带宠物的酒店」—— 没显式编程就处理不了「能带宠物」 | 需要强模型、算力,以及仔细的评测才能保证可靠 |
ReAct 框架(Reasoning + Acting)—— PART 2 的承重概念:
四步循环(:729):推理(想下一步该干什么)→ 行动(执行,比如调工具)→
观察(看结果并纳入下一轮推理)→ 重复,直到给出最终答案。
书给的完整走查(:739):
「找下周二纽约到旧金山的航班,再订个 Union Square 附近的酒店」
→ 推理「用户要机票和酒店,先办机票」→ 行动:调订票 API → 观察:拿到航班选项
→ 推理「到了以后要住 Union Square 附近,查酒店」→ 行动:调酒店 API → 观察:拿到酒店选项
→ 推理「把最好的选项整理给用户」→ 最终答案。
ToT 在 agent 里的用法(和第 2 章的 ToT 是同一个东西,这里是应用): 不确定性高、有多个有效答案时,并行探索多个分支。 例子:「怎么降低欧洲客户的运费?」→ 分支 1 换承运商 / 分支 2 仓库整合 / 分支 3 批量折扣。
3. Agentic RAG(6.3)
开场比方很好: 传统 RAG 像一位只能引用馆内藏书的博学图书管理员 ——
它能告诉你埃菲尔铁塔高 324 米、巴黎春天很美,
但它没法告诉你现在是不是在下雨,或者明天的塔顶门票还有没有。(:780–:786)
项目:travel assistant,两个工具 —— travel_knowledge(查向量库里的旅行资料)+
weather_service(调实时天气 API)。
关键演示:问「跟我讲讲埃菲尔铁塔,以及巴黎现在的天气」时,
agent 自己判断出这需要两类不同的信息,分别选对工具,再把两份结果合成一个回答。(:962)
⚠️ 6.3.2–6.3.7 的代码是 TypeScript(书自己解释了:因为它要建一个 React 聊天界面,
把 agent 的推理步骤直接渲染在浏览器里给用户看),Python 等价实现在配套代码 ch06_agentic_rag.py。
这在拆解里不必照搬语言,但「把推理步骤显示给用户」这个设计要留。
4. 四条防幻觉的进阶手法(6.4)
| 手法 | 干什么 |
|---|---|
| 交叉核对(cross-referencing) | 拿多个独立工具/来源的结果比对,不一致就标出来让用户澄清或转人工。书举股价:两个 API 都说 800 才算「已核实」 |
| 护栏(guardrails) | 内容过滤,把 agent 约束在能力边界和安全边界内 |
| RLAIF(从 AI 反馈中强化学习) | 收集对输出的反馈来迭代改进推理与决策。留到第 11 章 |
| 多步推理的透明化 | 把中间推理步骤显示出来(「我要用 weather_service 工具查巴黎当前气温」) |
⚠️ 书自己给护栏那段打了补丁,很诚实:
「虽然这个例子用的是简单的规则法,**关键词匹配在生产里很脆: 用户换个同义词或换个说法就能绕过去。生产系统通常用 LLM-as-a-judge 式的护栏 (LlamaGuard、NeMo Guardrails),按语义而不是关键词表来判断。**第 10 章会讲多层安全系统。」(
:1099) 这是又一处要核对的许诺。
透明化的实例:Perplexity —— 它把 agent 用了哪些来源、走了哪些步骤显示给用户。
「同时展示来源和推理步骤,已经成为现代 AI 界面的重要特性。」(:1126)
5. 生产案例(6.4.5)
| 组织 | 做了什么 | 数字 |
|---|---|---|
| Mass General Brigham | 环境记录(ambient documentation)agent,录下医患对话自动生成临床病历 | 从 20 位医生的概念验证起步 → 原计划推 400 人,需求太旺扩到 800+;职业倦怠率下降 21%;五分之三的医生说更可能延长临床生涯;80% 的医生在问诊时终于是在看病人而不是敲键盘 |
| JPMorgan Chase | 450+ 个 AI 用例的生态;LLM Suite 服务 20 万员工;Coach AI;呼叫中心的 EVEE 问答 agent | 每天 8 万亿美元流经其系统、技术预算 170 亿;Coach AI 的响应时间改善 95%;开发者生产力提升 10–20%;预测三到五年内每位理财顾问能多服务 50% 的客户 |
| SS&C Technologies | 20 个专门的文档处理 agent | 2024 年 11 月单月处理 5 万份文档;贷款文档自动化率超过 90%,人只看 AI 标出来的少数边缘情况 |
| H&M | 个人购物助理 agent | 处理尺码、配送、退货这类 常规问题,人工客服专注复杂问题;购物车放弃率和客服成本都显著下降 |
行业整体(:1211):超过一半的企业用 AI 编程助手;近三分之一的公司上了客服机器人;
RAG 架构的采用率一年之内从 31% 涨到 51%;12% 的 AI 实施已经用上真正的 agentic 架构
(能自主规划、执行、调整);超过 10 万家组织在用 Microsoft Copilot Studio 自建 agent。
agent 框架格局(:1225,这是书里最新的一段,拆解要点名):
- LangGraph:图式编排 + 检查点 + 人在环,适合复杂有状态流程;
- OpenAI Agents SDK:干净的 agent 间交接,内建追踪和护栏;
- Anthropic Claude Agent SDK:安全优先,工具调用链;
- CrewAI:基于角色的 API,做多 agent 原型最快;
- Google Agent Development Kit(ADK):接 Vertex AI,支持 A2A(Agent-to-Agent)协议。
第 7 章 Tool Integration and MCP(全书最短的一章,47.6k 字符)
1. N×M 问题(这一章的全部理由)
开场: 「你的 AI 助手又崩了。顾客让它查库存、发 Slack 通知、处理一笔付款 —— 三件简单的事。
但你的代码里有 500 行自定义的 Stripe 集成、300 行 Slack webhook,
而且它们各崩各的。」(:30)
具体的账(:42):5 个 AI 应用(客服机器人 / 内部邮件助手 / 日程 agent /
文档摘要工具 / 电商助手)× 10 个外部系统(Salesforce / Slack / Google Calendar /
Shopify / Stripe / 内部数据库…)= 50 套自定义集成。改一处,到处重构。
一个佐证数字: 「74% 的企业在管理或计划管理超过 500 个数据源」(Fivetran 报告,:34)。
⚠️ 参考文献 [1] 指向的 Fivetran 新闻稿标题是「近一半企业 AI 项目因数据就绪度差而失败」,
和这个 74%/500 个数据源的说法对不上 —— 需要核。
2. MCP 是什么
Model Context Protocol(模型上下文协议)= 即插即用的集成标准:一个应用一个连接器,
一个 API 一个连接器。50 变 15。(:72)
MCP Server(服务端):每个外部 API/工具暴露成一个标准服务器
MCP Client(客户端):每个 AI 应用用同一套客户端逻辑 去连
「它就像 AI 世界的 USB。」(:80)
⚠️ 一条极重要的边界(书说得很清楚,拆解一定要留,因为读者最容易误解这一点):
协议管的是 schema 校验和错误格式,但认证、授权、以及 MCP 端点的安全仍然是你自己的责任。 MCP 标准化的是接口,不是安全模型。(
:80) 后面还补了一句:MCP 大幅减少样板代码,但每个工具背后真正的执行逻辑仍然要你自己写。 MCP 标准化的是 AI 和工具之间的接口,并不意味着模型在生成或执行后端代码。 目标是让集成变简单,不是变自动。(:120)
采用状况(:137):Anthropic 在 2024 年末开源,现在托管在 Linux 基金会之下,
OpenAI、Google、微软、AWS 都支持;官方注册表里有数千个 MCP 服务器;
LangGraph、OpenAI Agents SDK、Claude Agent SDK 都原生支持。
3. 动手建第一个 MCP 工具(7.3)
用 FastMCP(Python 框架,用装饰器把普通函数变成 MCP 工具)+ pandas + 一个 CSV。
为什么用 CSV 而不是真 API,书解释得好:「谁都能跑你的代码,不需要凭据、不需要联网、
不需要平台特定的配置。」(:154)
七行产品目录 CSV → 一个 search_products(query, max_price, limit) 工具,
过滤标题、过滤价格、只留有货的、截断到 limit、转成 dict 列表返回。
「这正是 LLM 最好用的格式:简单、结构化、像 JSON 的数据,它能遍历、能推理、能讲给用户听。」(:244)
⚠️ 参考文献 [4] 把 FastMCP 的仓库写成 https://github.com/langchain-ai/fastmcp。
这是错的 —— FastMCP 不是 LangChain 的项目。拆解里不能照抄这个地址,要核对后改正或不引。
4. 模型怎么发现工具(7.5,本章最该讲透的机制)
和 function calling 的关键区别:
- function calling:你在每次请求里内联地定义函数 —— 名字、参数、描述;
- MCP:服务器自己提供工具清单。每个 MCP 服务器都实现一个
/tools/list端点, 返回每个工具的机器可读描述:名字、输入参数、输出格式、用途。(:328)
运行时的完整链路(:352,这是全章的主走查):
用户说人话:「我要一件 100 美元以下的轻便马甲。」
↓ 请求里 tools 数组含一个 {"type":"mcp","server_url":"http://localhost:8000"}
OpenAI 运行时 → 去查你服务器的 /tools/list
↓ 服务器返回 search_products 的 schema(query / max_price / limit 及其类型)
模型推理 → 构造调用 {"name":"search_products","arguments":{"query":"lightweight vest","max_price":100}}
↓ 运行时自动把调用路由到 http://localhost:8000/tools/search_products
服务器执行 → 返回 JSON
↓
模型写回答:「我找到一件 100 美元以下的轻便马甲:女士便携马甲,79.99 美元,现货。」
⚠️ 一条安全警告(书用 Important 标出):示例里 require_approval 设成 "never" 是为了简化。
在生产里这意味着 AI 可以不经人类监督执行任何工具调用 —— 包括修改数据、下单、发送通讯。
敏感操作要用 "always",或实现自定义的审批逻辑,高风险动作必须人工确认。(:373)
5. 工具设计就是接口设计(7.5.4 + 7.6)
「你的 MCP 服务器不是一堆端点的集合,而是一个面向语言模型的 API 表面。
工具怎么命名、怎么描述、参数怎么设计,都在影响模型怎么用它。」(:428)
反例:参数叫 x,模型不知道那是什么、也不知道什么时候该用这个工具。
工具链式调用(7.6.1,给了完整走查):
问「你们有防水夹克吗?最便宜那件有货吗?」
→ 推理「我得先找防水夹克」→ 调 search_products(query="waterproof jacket")
→ 拿到 [{id:2, title:"Waterproof Rain Jacket", price:79.99}]
→ 推理「我该确认最便宜那件有没有货」→ 调 check_inventory(product_id=2)
→ 拿到 {found:true, product:{available:true, status:"In Stock"}}
→ 答「有的!防水雨衣 79.99 美元,现在有货。」
「这个链式调用是自动发生的,你不需要写编排代码。模型根据问题和工具描述,
自己决定调哪些工具、按什么顺序调。」(:520)
工具描述就是路由指令(:524):
search_products「搜索产品目录」用于发现;check_inventory「查某个具体产品的库存状态」用于核实。
「如果两个都起个含糊的名字(get_products、get_product_info),模型就会选错。」
6. 优雅地失败(7.7,这一节是本章的可靠性落点)
核心洞见(书自己加粗的):
工具失败时,模型需要的是关于「 哪里出错了」的结构化信息,不是一段 Python 堆栈。(
:539)
统一的响应结构(:653):
{ "success": true/false, "error": null 或 "错误码",
"message": "给人看的解释", "results": [...] }
三个好处:模型能查 success 知道成没成功;能直接把 message 用进给用户的回答;
能按错误码决定下一步 —— 重试、请用户澄清、还是给替代方案。
书给的前后对照(极好的走查):
- 无结构化错误:工具抛
TypeError: 'NoneType' object is not iterable→ AI 说「我在搜索时遇到了一个错误」(没用); - 有结构化错误:工具返回
{"success":false,"error":"invalid_price","message":"Price must be greater than zero."}→ AI 说「我没法搜索 0 美元以下的产品。你是不是想设一个别的价格上限?」(有用)。
⚠️ 一个「常见错误」值得单独讲(:681):把「没有结果」当成错误。它们是两回事。
- 错误 = 出了岔子(数据库挂了、输入非法、超时)→
success: false; - 空结果 = 搜索本身正常完成,只是没匹配上 →
success: true+ 一条建议 (「试试更宽泛的搜索词,或去掉价格过滤」)。 模型看到success:true加空结果,就能说「50 美元以下没找到夹克,不过这里有一些价位高一点的选择……」 并再发一次工具调用;看到success:false,它就知道有东西坏了,该道歉并建议稍后再试。
超时与限流(:715):给了一个 with_timeout(5.0) 装饰器。
并且明确:生产上还要有指数退避的重试 —— 一次瞬时网络错误不该让整个请求失败;
常见做法是最多重试三次,间隔 1 秒、2 秒、4 秒,然后才把超时错误返回给模型。
7. 7.8「harness(载具)」—— 全书最新、最有前瞻性的一节
这一节写于 2026 年,内容在别处几乎看不到,是这本书的独特价值所在。
核心区分(:776):
单独的 LLM 拿一个提示词、返回一个回答。 harness(载具)把它变成 agent:加上会话与状态管理(串起多轮任务)、记忆机制、 工具系统(调浏览器、终端、文件、外部 API)、以及输出通道(把结果写回系统而不只是返回文本)。 引的一句话:「模型提供推理,harness 提供能力。」(
:780)
架构上的关键洞见:控制面(control plane)与计算面(compute plane)分离。(:788)
harness(控制面) sandbox(计算面)
agent 循环 读写文件
工具路由 跑 shell 命令
审批 执行代码
追踪 ——
状态 【模型生成的代码在这里跑】
【凭据与敏感数据留在这里】
任务向右流,结果向左流。sandbox 崩了,harness 从上一个检查点恢复并继续。
安全上的意义:凭据和敏感数据留在 harness,绝不进入模型生成的代码运行的那个 sandbox。
书说这个模式在 2026 年初被业界独立地收敛出来:
- OpenAI 在 Agents SDK 和 Codex CLI 里把它形式化了;
- OpenClaw —— 书称它「GitHub 星标破 30 万,成为平台上星标最多的软件项目」,
模型无关(能配 Claude、GPT、DeepSeek、经 Ollama 跑 Llama)、本地优先、社区可扩展,
有 40 多个消息渠道集成。「模型是可互换的模块,harness 才定义产品。」(
:799) - NVIDIA 的 NemoClaw 把这个模式推向企业部署,agent 跑在 OpenShell 这个沙箱运行时里, 在内核层面强制精确的权限边界,让敏感工作负载留 在组织自己的基础设施内。 ⚠️ OpenClaw 的 30 万星、NemoClaw、OpenShell 都需要核实 —— 这是 2026 年的新事物。
「agent 可读环境(agent legibility)」四条实践(:814):
书引 OpenAI 的一个团队:用 Codex agent 建了一个生产软件产品,零手写代码,
约一百万行(应用逻辑、测试、CI、工具链),平均每位工程师每天 3.5 个 PR。
他们的核心发现:
「出问题时,解法几乎从不是『再努力一点』,而永远是 『缺了什么能力,以及我们怎么让它对 agent 变得可读』。」(
:821)
| 实践 | 说的是什么 |
|---|---|
| 给 agent 一张地图,不是一本百科 | AGENTS.md 这个约定;单体式的说明文件必然失败:它挤占真正的任务上下文、agent 分不清哪些还有效、而且烂得比谁都维护得快。最好把它写成约 100 行的目录,指向 docs/ 下更深的文档。 OpenClaw / AlphaClaw 这类工具则把结构化的「技能文件」每一轮注入 agent 上下文 —— 小而聚焦的指令集 |
| 让仓库成为唯一事实来源 | 「从 agent 的视角看,任何它在上下文里拿不到的东西,实际上就不存在。」 活在 Slack 线程、Google Docs、人脑子里的知识对系统是不可见的。设计决策、架构约束、执行计划、质量标准都要成为 agent 能发现并推理的带版本的产物 |
| 不变量靠机器强制,不靠文档 | 用 linter 和结构化测试强制架构规则,而不是写在文档里。自定义的 lint 报错信息被写成「直接把补救指令注入 agent 上下文」的形式。 这和 7.7 的结构化错误响应是同一个道理 |
| 偏好无聊、可组合的技术 | API 稳定、文档齐全、在训练数据里出现得多的技术,agent 用起来更可靠。有时候自己重实现一个简单功能,比绕开一个不透明的上游库更划算 —— 因为一个自建的、测试完备的实现,对未来的 agent 运行来说更可读 |
安全缺口(7.8.3):
79% 的组织已经在用 AI agent,但只有 14.4% 的 agent 部署拿到了完整的安全批准; 83% 的组织计划部署 agentic AI,只有 29% 觉得自己已经准备好安全地这么做。(
:861) 「你建的 MCP 工具就是攻击面:每一个能读文件、查数据库、调外部 API 的工具都是潜在的入口。 agent 系统的设计要预设会有提示词注入和数据外泄的尝试。」
新增的「书没讲透」的缺口(累计)
arXiv:2603.08274/ Stanford AI Index 的 12%→66% / OpenClaw 30 万星 / NemoClaw / OpenShell / Fivetran 的 74% 与 500 个数据源 / Cisco 与 Gravitee 的两组安全数字 —— 这批 2026 年的数字全部需要核实,核不到就写明「书里的说法,我们没核到」。- 参考文献 [4] 把 FastMCP 写成
github.com/langchain-ai/fastmcp—— 地址存疑,不能照抄。 - MCP 的规范细节(
/tools/list之外的部分:resources、prompts、传输层、 stdio vs SSE vs streamable HTTP)书完全没讲。 我们的ai-protocol-reference有 完整的 MCP 规范拆解 + clone 的 mcp-spec 源码仓, 这是补起来最有把握的一处。 - A2A(Agent-to-Agent)协议只在第 6 章出现一次名字(
09-ch06:1232),没有任何解释。ai-protocol-reference里有 A2A 的拆解。 - RLAIF 在第 6 章只有一段,说「第 11 章讲」 —— 要核对第 11 章是否兑现。
- 护栏「第 10 章会讲多层安全系统」(
09-ch06:1099)—— 要核对。 - LoRA 的「低秩」到底低在哪、为什么低秩就够,书只给了「贴便利贴」的比方, 没讲「权重更新矩阵可以分解成两个瘦矩阵之积」这一层。 原论文 arXiv:2106.09685 书里给了,可以直接用来补。
- 知识蒸馏的「软概率输出」为什么在经典做法里比硬标签更有信息量,书一句带过。