这本书站在哪个时间点 — 哪几行不能照敲,哪几条仍然成立
这一章讲三件事: 这本书是在什么时间点上写的; 它有哪几处今天已经对不上了;以及去掉那些之后,它还剩下什么。
它在全书链条里的位置: 这是结账的一章。 前面十二章每一处说「今天怎么样」的地方,都在这一章交代清楚。 本章的主走查是全书唯一一条「反向」的走查:拿书里的代码去对照今天,而不是去解释它。
1. 先说清:这本书写在什么时间点
这一节给一把尺子。后面每一节都要用它量。
书的前言末尾署的日期是2024 年初春1。这个时间点意味着三件事:
第一,它写在那个引爆一切的聊天产品出现之后大约一年零三个月。 书自己反复提到那个日期(2022 年 11 月 30 日),并把它当成起点2。
第二,书里所有的「最新」 都要按那个时间读。 比如它说到当时可选的模型时, 只有两三家的旗舰模型「能勉强符合 Agent 大脑这样的要求」3; 比如它说某个框架当时在代码托管站上的收藏数是 15 万。这些数今天全都变了。
第三,也是最要紧的:书里那些「实验中」「测试阶段」的标注,今天大多有了结果。
第 06 章那套接口标着 Beta,第 09 章那套做法被放在「实验模块」里——
这两处今天各有各的下落,第 3 节和第 9 节分别交代。
一句提醒:本章不是在挑错。 一本讲工具的书过时是必然的; 这一章要做的是把「哪些过时了」和「哪些没过时」分开,免得你把两者一起丢掉。
2. 作者当时给的两条预测
这一节结算书里的预测部分。作者其实只给了两条正经预测,都在原书第 1 章。
第一条:关于热度。
书引了一条业界常用的曲线,叫技术成熟度曲线(也叫炒作周期)—— 一条描述新技术从被追捧到被冷落再到真正落地的曲线。
看这条曲线之前先说一个词:下面几段里的期望就是大家指望它能干什么 (和数学里那个同名的词没有关系)。书列了它的五段4:
| 这一段 | 官方叫法 | 作者自己起的名字 |
|---|---|---|
| 新技术出现,期望开始上升 | 创新触发点 | 希望之春 |
| 媒体大量关注,期望到顶,与实际能力不符 | 期望顶峰 | — |
| 满足不了过高期望,关注下降 | 失望低谷 | 绝望之冬 |
| 问题被解决,开始真正用于实际 | 启蒙斜坡 | — |
| 成熟并被广泛接受 | 生产力高原 | — |
书说,在他引的那张 2023 年的图上, 会自己产内容的那一类、以及被当作地基用的那些大模型,都位于期望顶峰附近5。
然后学生问了一句关键的:那么我们现在谈论的这类程序不会这样吧? 作者的回答是这本书里最像预测的一段话6:
当然不会。它的「希望之春」不仅陡峭,而且「绝望之冬」也不是深渊。 当噱头消失之后,新的进展又会兴起。
这条预测该怎么结算? 本组拆解的态度是:不结算。 「深不深渊」没有可核对的判据,今天说它对或错都是各说各话。
但有一件事可以指出来:这本书自己就是那条曲线的一个样本—— 它写在期望顶峰附近,而原书最后两章那五个开源项目里,今天有三个换了内核: AutoGPT、BabyAGI、MetaGPT(依据在第 11 章第 9 节与第 12 章第 9 节)。
另外两个不算换内核,别一起数进去: AutoGen 进了维护模式, CAMEL 是在原来那套上加了一层。
第二条:关于能力从哪来。
作者在讲模型为什么突然能当这类程序的大脑时,给了一个很具体的证据: 训练时接触的英文资料多、某些小语种的资料少, 但由于各种语言都是相通的,它在小语种环境中也能表现出色; 这说明它可以将某些英文资料中的语言规律迁移到其他语言中7。
这种「学得多了、一通百通」的现象,书里叫泛化—— 指模型对没见过的数据也能做出合理反应的能力8。
这一条比上一条硬得多,因为它有可核对的现象。 而且它直接支撑了全书的前提: 如果模型只会照搬见过的东西,那第 01 章那一圈根本转不起来—— 它必须能读懂一段它从没见过的搜索结果、然后决定下一步。
回头看第 01 章第 8 节那张五级表。 那张表说 L3 到 L4 是从被动到自主的分水岭; 而泛化就是跨过那道分水岭的那块地基。 两处合起来,才是作者完整的主张。
3. 三处代码今天照敲会出事
这一节结算代码。三处,一处比一处严重。
第一处:那套「先列清单再执行」的做法,连同它所在的整个模块,已经不在主仓里了。
第 09 章第 3 节引过:书自己写明这套东西当时被放在框架的「实验模块」里。
补充(不在书里,依据我们的前沿框架书架): 那个实验模块今天已经不在主仓的代码目录下了。 依据: shelf=ai-frontier-reference/langchain @2019bf5ebe50324c548f67c2666a804343f9b772 事实=在这个版本的主仓里,
libs/下只有core、langchain、langchain_v1、model-profiles、partners、standard-tests、text-splitters七个目录, 没有langchain_experimental。9
第二处:第 05 章那个创建函数今天有两个来源,而且都劝你别用。 细节见第 05 章第 9 节,这里只列结论:书里那个已被搬进一个叫「经典」的旧命名空间并挂了警告; 同名的另一个在图执行库里,也挂了弃用提示。两处都指向同一个替代品。
第三处:那个默认 15 的轮数上限,书从没提过。 这一条严格说不是「过时」,是「书里本来就漏了」——但它今天会直接影响你的程序行为, 所以放在这一节一起交代。细节同样见第 05 章第 9 节。
三处并排,给个判断:
判断(我们的,不是书里的): 这三处的性质完全不同,不该一起丢掉。 第一处是整块搬走了,照敲会直接报「找不到」——这种错最好,你立刻就知道; 第二处是名字还在、行为已变,照敲能跑,但你用的是一个官方劝你别用的东西; 第三处是书里根本没写,你不知道有这么个上限,直到某天任务在第 15 步莫名其妙停了。 越是「能跑」的过时,越危险。 如果错,会错在: 如果上游后来又把实验模块挪回去、或者撤回了那两条警告, 这三条结论就要重新核一遍。每一条都标了 commit,可以直接回核。
4. 那份工具说明书,后来被做成了跨厂商的共同规矩
这一节兑现第 04 章第 3 节挂的那个钩子。
第 04 章讲过:你要把一个函数交给模型,得写一份 JSON 格式的说明书, 里面有名字、说明、参数表三样。当时那份说明书的格式是某一家厂商的私有约定—— 换一家,你得重写一遍;而且这份说明书只能给模型看,别的程序读不了。
书里其实预感到了这件事。 原书第 2 章有一段很值得抄下来的话: 作者说他期待我们拥有一套标准的 Agent 工具调用接口, 并猜想新的生态里也许会出现「工具即服务」的概念10。
这件事在书出版之后真的发生了,而且形状和作者猜的差不多。
补充(不在书里,依据我们的协议书架): 有一份跨厂商的共同规矩把「工具长什么样、怎么列、怎么调」定了下来, 而且它的三样和第 04 章那三样一一对应。 依据: shelf=ai-protocol-reference/mcp-spec#03-server-primitives.md @4e67bdc2f3403a8602f72025b28ac27fe7fd4e44 事实=规矩里「列清单」的方法返回每个工具的名字、说明和一份输入格式说明书 (用的正是第 04 章那种 JSON Schema); 「调用」的方法回来的不只是一段文字,还可以带一份结构化数据; 而且工具可以再配一份输出格式说明书,给了的话服务方必须按它返回、 调用方应当据此校验。11
最后那半句请和第 04 章第 8 节那条对读。 那一节说: 它只保证是合法 JSON,不保证符合你要的结构。 而这份规矩里明确写了「必须符合、应当校验」—— 这正是那条空白在今天被补上的方式。
这份规矩的名字在别人的文档里到处都是,所以必须留名。 它叫模型上下文协议,英文缩写是 MCP——一份跨厂商的、 规定「工具长什么样、怎么列出来、怎么调用」的共同约定。
5. 那一圈的外面,今天多了一层
这一节讲一个书里完全没有的层次,而它解释了第 09、11 两章那些麻烦。
回想第 05 章:那 一圈就是一个 while 循环,状态全在内存里那个记事本上。
这带来一个书里从没讨论过的后果:程序一崩,这一趟就全没了。
还有一个更实际的:第 06 章那趟托管调用里,你想在模型点了「下单」工具之后 先让人看一眼再放行——书里没有任何地方支持这件事。
补充(不在书里,依据我们的前沿框架书架): 今天那一圈的外面多了一层:每走一步存一次档,于是能从任意一档接着跑。 依据: shelf=ai-frontier-reference/langgraph#03-persistence-hil.md @1e44bda48ff4982b8ccfeec9c14156ea9e8ae5a2 事实=开了存档之后,每一步末尾都会存下一张完整快照(状态值 + 进度); 恢复一次运行不需要任何内存里的东西,只要这张快照; 快照按一个对话编号分组,复用同一个编号就能让状态跨多次调用累积。12
这一层直接给了三样第 09 章那张「五格全空」的护栏表里缺的东西:
| 第 09 章缺的 | 有了存档之后 |
|---|---|
| 程序崩了怎么办 | 从最后一张快照接着跑 |
| 中途想让人看一眼 | 停在那一步、存档、等人回话再继续 |
| 想知道它到底走了哪几步 | 每一步都有一张档,可以回放 |
第三行顺带引出下一节。
6. 附录那张论文表:编号被系统性排错了
这一节是一条硬警告,而且它是本组拆解在整本书里发现的最严重的一处问题。
书的附录列了两篇综述、一张代表性论文表,正文里还随手引了十几篇论文13。 这些论文的编号,书末的参考文献里全都给了。
问题是:那些编号被系统性地排坏了。 我们逐条核对了参考文献那一页,发现三类错法:
| 错法 | 例子(书里印的 → 实际) |
|---|---|
| 前导零被吃掉 | ReAct 那篇印成 2210-3629,实际是 2210.03629 |
| 前后两截颠倒 | 某篇印成 1691-2204;2204 才是年月,01691 是序号 |
| 两种错叠加 | 某篇印成 2308-2352,而真号是 2308.00352——补零也救不回来 |
为什么这件事严重? 因为这些编号看起来完全正常。
你照着 2210-3629 去查,会查不到;而你多半会以为是自己抄错了,而不是书印错了。
本组拆解的处理办法,已经在前面各章执行过了,这里写死:
- 凡是要落编号的地方,一律不抄书里的数字;
- 能在我们的书架 clone 里找到出处的,照书架写—— 第 03 章第 7 节那个 ReAct 的编号就是这么核出来的;
- 核不到的,照实写「没核到」,并且不写日期、不写编号。
这一轮我们核到了两个,记在这里:
补充(不在书里,依据我们的前沿框架书架): ReAct 那篇的真实编号是 arXiv:2210.03629。 依据: shelf=ai-frontier-reference/langchain@src:libs/langchain/langchain_classic/agents/react/agent.py:28 @2019bf5ebe50324c548f67c2666a804343f9b772 事实=框架源码里那个创建函数的说明文字直接给出了这篇论文的标题和链接。14
补充(不在书里,依据我们的 agent 生态书架): 第 12 章第 8 节那个框架的论文,真实编号是 arXiv:2308.00352。 依据: shelf=ai-agent-reference/metagpt@src:tests/data/search_rsp_cache.json:203 @11cdf466d042aece04fc6cfd13b28e1a70341b1f 事实=该项目自己仓库里存着一份测试用的搜索结果备份,里面记录了指向这篇论文的链接。15
其余的没核到,所以本组拆解一个都不写。
判断(我们的,不是书里的): 这不是排版失误,是一次系统性的格式转换事故。 三类错法(吃零、颠倒、两者叠加)出现在同一页的十几条上, 说明它们是被同一道自动处理弄坏的,而不是有人手抄错了几个。 对读者的实际意义是:这本书的参考文献页整页不可用。 如果错,会错在: 如果这是我们拿到的这一版转码文本在转换时出的问题、 而纸书上的编号是对的,那么这条判断就冤枉了原书。 不过三类错法里有两类(颠倒、两者叠加)不是转码能造 成的—— 转码不会把两截数字调换位置。
7. 写完之后怎么评、怎么看:书给了入口,但只教了怎么点开
这一节结算全书最容易被误判的一格。先把书里真实的状态说清。
书讲了这件事,而且给了完整的动手步骤。 原书第 3 章有一整节讲那个配套平台16:
第一,它是随框架一起来的。 书说:安装那个框架的包的同时也会安装它—— 你不用额外装东西。
第二,四份配置。 这种「写在程序外面、由系统在启动时递给它的设置」叫环境变量; 书把作者自己那份原样贴了出来,一共四项:
OpenAI_API_KEY = '我的 OpenAI API 密钥'
LANGCHAIN_TRACING_V2=true
LANGCHAIN_ENDPOINT=https://api.smith.langchain.com
LANGCHAIN_API_KEY='我的 LangChain API 密钥'
LANGCHAIN_PROJECT=langchain_test # 如果没有指定,则使用默认设置
第三,跑一条链,然后去网页上看。 书跑的是一条三段链 (问「丁香的花语是?」,拿回一串花语),然后说:登录之后能看到配置里那个项目; 打开项目能看到条目,项目的日志记录了每一次链条运行的轨迹; 点进日志里的条目,可以看到模型调用细节17。
书在介绍那个框架的生态时也明写过:这个平台是用于调试、测试、评估和监视的18。 另外在讲检索那一章末尾还补了一句:无论哪个框架, 都可以通过设置日志和调试选项来查看程序与模型交互过程中的细节19。
所以「书完全没讲」是错的。它讲了,而且教到了「点开就能看见」这一步。
那它没给的是什么? 三样,一样比一样要紧:
没给的第一样:轨迹按什么字段落。 书里那个平台是某一家的私有产品,它把一次运行记成什么样、字段叫什么名字, 书没有讲,也没有提到有任何跨 厂商的约定。
补充(不在书里,依据我们的协议书架): 「一次模型调用该记哪些字段」今天有一份公开约定,而且它专门给这类程序留了位置。 依据: shelf=ai-protocol-reference/otel-genai-semconv#02-genai-domain-model.md @384d66161cb18704c729645fa8136a148df9571c 事实=约定里有一个「这是哪种操作」的字段,取值直接对应不同的记录类型, 其中包括调用一个 agent、执行一个工具、统一调度多个 agent; 用量那一块分成五个字段:输入、输出、以及用于推理的那部分输出, 外加两项跟缓存——把算过的东西先存着、下次直接拿——有关的: 从缓存里读到的和写进缓存的; 输入输出的消息必须按发送顺序记录,且一条输出消息对应一个候选答案、不可拆分或合并。20
这份约定本身也在搬家,值得一并记下:
补充(不在书里,依据我们的协议书架): 这套字段已经从原来那个总仓迁到了一个独立的仓库,原仓里只留下一批已标为弃用的定义。 依据: shelf=ai-protocol-reference/otel-genai-semconv#04-the-move-and-deprecation.md @384d66161cb18704c729645fa8136a148df9571c 事实=原仓的相关文档已全部变成十来行的占位页,正文只写「已移到新仓」; 模型定义目录下只剩一个「已弃用」子目录; 定义全留着、但全部标成弃用,是为了不弄坏已经在按老字段上报的程序。21
没给 的第二样:检索质量怎么打分。 这一条第 10 章第 7 节已经完整交代过, 这里只提醒一句:原书第 8 章末尾说程序会「对收集的信息进行评估」,而全书没给做法。
没给的第三样:换一家平台,字段还认不认。 书里那个平台是和那个框架绑定的。你换一个框架、换一家平台,前面记的东西还能不能用? 书没有讨论。 而这个问题今天有一批产品在正面解决:
补充(不在书里,依据我们的前沿框架书架与 agent 生态书架): 同一类平台今天至少有四五家,而且分成两条明显不同的路线。 依据: shelf=ai-frontier-reference/phoenix#index.md @2301e2dc16a878fa3da518d4d35f7c382803d51d · shelf=ai-agent-reference/openllmetry#index.md @62e24c2ffde6c1ee04dc290e52d8d5dbda054cff · shelf=ai-frontier-reference/langfuse#index.md @e68e201a66ac67eaeb2a6dd8f1d36295c092913f · shelf=ai-agent-reference/opik#index.md @70ed188ef4fe7bddba555d5ee7505cf9220b7522 · shelf=ai-agent-reference/langwatch#index.md @a0119d531d4465e704e5ff60fa14d08da819be8c 事实=第一条路是「站在那份公开约定上」:一个自托管平台直接用那套标准把每一步收进来; 另一个更彻底,一行初始化就把各家模型调用自动变成标准记录,并能直接连到通用的监控产品上。 第二条路是自建一套存储与打分闭环:两家分别把轨迹不占主流程、可去重地灌进列式数据库, 再在其上跑「让另一个模型当裁判」或代码规则来打分; 还有一家把每个记录当成一条不可变的命令写进事件日志,再投影成可查询的结果。22
把三样合起来,这一格今天完整的样子是:
- 记什么——按那份公开约定的字段记(操作类型、用量五项、按序的消息);
- 记到哪——自托管或用现成平台,两条路线都成熟;
- 怎么判断好坏——硬检查 + 让模型当裁判(第 07 章第 9 节)+ 检索质量打分(第 10 章第 7 节);
- 裁判本身怎么校准——用人工标注过的一组样本反过来考它(第 07 章第 9 节)。
书讲到了第 2 条的一半,前后都没有。
8. 作者留的六条方向,今天怎么样了
这一节结算附录最后那一节。作者列了六条他认为有潜力的方向,本节只挑与主线相关的两条。
书列的六条是:多模态、人机混合协同、隐私安全、伦理内化、 把这类模型和按规则推理的老办法混起来、以及让它走出实验室持续进化23。
第一条挑「人机混合协同」。 作者的描述是: 它旨在发挥人和机器的互补优势,代表了从「替代」到「增强」再到「协同」的范式升级; 传统的「人定机行」会逐渐过渡到「机器赋能、人机互利」24。
这一条今天有很具体的落法,而且第 5 节那一层就是它: 存档 + 中途停下来等人回话,就是「人机协同」在工程上最实在的一种形状。 书里那句很文学的话,今天对应的是一个技术开关。
第二条挑「伦理内化」。 作者说的是从数据集、训练目标、决策机制几个环节入手, 让它内化人类的价值观和规范;并点名了一种叫「宪法式」的做法—— 通过设计一套基本规则来约束和引导 agent 的行为25。
这一条和第 12 章第 3 节那两段开场提示词是同一件事的两个尺度。 那两段提示词里写满了「永远不要」「必须」——那就是一套写给两个程序的基本规则。 而第 11 章第 6 节证明了这条路的天花板:写在提示词里的硬要求,模型不一定听。
其余四条,本组拆解不展开——它们要么书里没有对应的代码(多模态、隐私安全、 模型与规则混合),要么落在这本书的主线之外(走出实验室持续进化)。 照实写进书卡的「不覆盖」一栏。
9. 主走查:拿原书第 4 章那段代码,逐行走「今天照敲会发生什么」
这一节是本章的主走查。样本就是本拆解第 06 章走过的那趟真实代码(它拆的正是原书第 4 章)—— 助手、线程、消息、轮询、读回 96。下面一行一行对照今天。
样本(与第 06 章同一趟): 造一个叫「鲜花价格计算器」的助手 → 造一个线程 → 加一条消息 「我把每束花定价为在进价的基础上加价20%,当进价为80元时,我的售价是多少。」 → 创建运行 → 轮询到
completed→ 读回「在进价80元的基础上加20%,售价是96元。」
第 1 行 · client.beta.assistants.create(...)
今天还在。 依据是第 06 章第 8 节那条:另一个框架里仍有对象在走这条 beta 通道。
但它已经不是官方主推的写法了。
同一件事在后继写法里是哪几行? 是「配一个 Agent 对象」: 给它指令、工具、交接对象三样,没有「先在服务端创建一个助手」这个动作。
第 2 行 · client.beta.threads.create()
今天还在,而且我们核到了具体的调用点(第 06 章第 8 节引的那条)。
同一件事在后继写法里是哪几行? 是一个「会话」对象。 关键差别值得记住: 那套会话约定只要求四个方法, 而且默认存在你自己的本地数据库里——线程从服务端搬回了你这边。
第 3 行 · client.beta.threads.messages.create(role="user", content="…80元…")
今天还在。 那句「进价 80 元加价 20%」原样敲进去仍然成立。
同一件事在后继写法里是哪几行? 是把这句话作为一次运行的输入传进去; 历史由那个会话对象自动合并,不需要你先往一个远端容器里加消息。
第 4 行 · client.beta.threads.runs.create(thread_id=…, assistant_id=…)
今天还在,但这是六行里差别最大的一行。
它返回时状态是 queued,你必须自己转圈问(第 06 章第 5 节)。
同一件事在后继写法里是哪几行? 是一次「跑到底」的调用—— 它内部就是第 01 章那一圈,你不用管状态机、不用轮询。
第 5 行 · 那个 while True 轮询循环
今天照敲还能跑,但它是第 06 章第 6 节那个 101 次死循环的原始出处。 同一件事在后继写法里是哪几行? 不存在这几行。
第 6 行 · 读回消息列表,取最新一条,拿到「96 元」
今天还在。 而这个 96 本身仍然是对的:80 × 1.2 = 96。
现在换一个角度问:同一件事在状态图那一层是哪个节点、哪次存档?
托管那一套(书里) 今天的状态图那一层(第 5 节)
───────────────────── ────────────────────────────
创建线程 ↔ 给一个对话编号
加一条消息 ↔ 把输入交给图
创建运行 → queued ↔ 图开始跑
in_progress ↔ 第一个节点在跑
★ 每一步之后:什么都没有 ↔ ★ 每一步末尾:存一张快照
completed ↔ 图跑到终点
读回最新消息 ↔ 读最后一张快照里的状态
★ 那一行是全部差别:书里那一趟中途一次档都没存,
所以它崩了就只能整趟重来;而且你没法在中间停下来给人看一眼。
最后一问:同一个工具接入,在协议化之后由谁提供?
第 06 章那个助手挂的是内置的代码解释器;第 04 章那趟挂的是你自己写的查库存函数。 两种都由「你这一侧」提供。
而第 4 节那份共同规矩之后,工具可以由一个独立的提供方提供—— 它按规矩把「有哪些工具、每个长什么样」报出来,你的程序去列、去调; 换一家模型厂商,这些工具不用重写。
这一趟六行代码的结账:
行 书里写的 今天还在吗 后继写法有没有这一步
1 创建助手 在 没有(配一个对象,不往服务端注册)
2 创建线程 在 有,但搬回本地,协议只要四个方法
3 加消息 在 有,但历史自动合并
4 创建运行 在 有,变成「跑到底」一次调用
5 轮询循环 在 ✗ 不存在
6 读回 96 在 有
图说:六行里五行都还能跑 —— 这正是第 3 节那个判断说的:
**越是「能跑」的过时越危险。** 你会以为一切正常,
而实际上你在用一套官方已经不推荐、并且缺了存档和人工确认的写法。
10. 去掉过时的部分,这本书还剩什么
这一节是全书的落点。四条,每一条都不依赖任何具体的接口。
第一条:那一圈的形状。 问模型 → 它派活 → 外面去跑 → 结果塞回去 → 再问, 直到它不再派活。 第 01 章那五步在今天每一个框架里都成立, 因为它不是某家的设计,它是「模型只吐文字」这个事实的直接后果。
第二条:出错不抛,把错变成下一份输入。 第 05 章第 5 节那条。 今天的框架把它做得更全(连工具自己抛异常也走这条路),但思路一模一样。
第三条:提示词是建议,不是规则。 第 11 章第 6 节那个反例 (明写「不要删任何任务」,它照样删了)在今天依然成立, 而且第 12 章第 5 节那套「让模型挑发言人还要配重试」就是照这条设计的。
第四条,也是最值钱的一条:这本书把翻车的现场原样印出来了。 101 次轮询的死循环、8 步里 6 步查同一个库存、凭空报出的 18°C、 一朵花的价格被写成 50 朵的价格——这些不是它讲得不好,是它没有粉饰。
判断(我们的,不是书里的): 这本书真正的价值不在它教的那七个框架与开源项目, 在 它印出来的那些原始轨迹。 框架会换、接口会改,但「一个没有护栏的自主程序会怎么跑飞」这件事不会变; 而这本书是我们见过的中文材料里,把这类现场记录得最完整的一本。 反过来说,它的问题也在同一处:它把这些现场印出来了,却几乎没有解读它们—— 12.0 那个错数、18°C 那个编造、第 5 轮那次删除,作者一个字的评论都没有。 如果错,会错在: 如果作者在别处(比如配套代码仓库或后续文章)对这些现场做过解读, 那么「没有解读」这个说法就只适用于书本身。
最后引一句作者自己的话作结。 他在后记里说这类程序仍然处在**「猿人期」**, 目前许多看似高级玩具,但其真正的潜力远未被发掘26。 这句话写在 2024 年初春;两年之后回头看,「猿人期」这个判断至今没有被推翻。
11. 可带走的
- 这本书封笔在 2024 年初春,所有的「最新」都要按那个时间读;
- **作者只给了两条正经预测:**热度会走炒作周期但低谷不深(不可核对)、以及规律会跨语言迁移(可核对,而且是全书的地基);
- **三处代码今天照敲会出事:**实验模块整块不在主仓了、那个创建函数有两个来源且都劝你别用、一个默认 15 的上限书里从没提;
- 越是「能跑」的过时越危险——报错的那种你立刻知道,能跑的 那种你永远不知道;
- 那份工具说明书后来被做成了跨厂商的共同规矩,而且补上了第 04 章那条空白:给了输出格式说明书就必须照它返回、应当据此校验;
- 那一圈的外面今天多了一层:每走一步存一次档,于是能崩溃续跑、能中途停下等人回话、能回放走过的每一步;
- **附录那张论文表的编号被系统性排错了:**吃零、颠倒、两者叠加三类错法;整页不可用,一个数字都别抄;
- **「书完全没讲怎么评怎么看」是错的:**它讲了那个配套平台,四个环境变量、跑一条链、去网页上看轨迹和模型调用细节;
- **它没给的是三样:**轨迹按什么字段落、检索质量怎么打分、换一家平台字段还认不认;
- 主走查的结论:那六行代码今天五行还能跑,但你用的是一套官方已不推荐、且缺了存档和人工确认的写法;
- **去掉过时的部分,还剩四条:**那一圈的形状、出错变输入、提示词是建议不是规则、以及一整批没有粉饰的翻车现场;
- 这本书最大的遗憾是把现场印出来了却几乎没有解读——那些数字和轨迹的价值,要靠读者自己去挖。
12. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 成书时间 | 前言 一个新纪元的黎明 | text/04-fm.txt:85(搜「2024年初春」) |
| 那个引爆一切的日期 | 3.2 何谓LangChain | text/26-ch03-02-3-2-langchain.txt:5(搜「2022年11月30日」) |
| 当时只有两三家模型够格 | 3.1 何谓OpenAI API | text/25-ch03-01-3-1-openai-api.txt:101(搜「勉强符合“Agent大脑”这样的要求」) |
| 炒作周期五段、位置、那句预测 | 1.3 Agent的大脑：大模型的通用推理能力 | text/10-ch01-03-1-3-agent.txt:101(搜「AI技术成熟度曲线」) · text/10-ch01-03-1-3-agent.txt:103(搜「希望之春」) · text/10-ch01-03-1-3-agent.txt:115(搜「期望顶峰附近」) · text/10-ch01-03-1-3-agent.txt:123(搜「希望之春」) |
| 泛化与小语种那一段 | 1.3 Agent的大脑：大模型的通用推理能力 | text/10-ch01-03-1-3-agent.txt:169(搜「小语种」) · text/10-ch01-03-1-3-agent.txt:173(搜「泛化是机器学习的一个重要概念」) |
| 期待标准的工具调用接口 | 2.4 Agent的核心技能：调用工具 | text/20-ch02-04-2-4-agent.txt:35(搜「一套标准的Agent工具调用接口」) |
| 那个平台随框架一起装、四个环境变量 | 3.2 何谓LangChain | text/26-ch03-02-3-2-langchain.txt:193(搜「安装LangChain包的同时也会安装LangSmith」) · text/26-ch03-02-3-2-langchain.txt:200(搜「LANGCHAIN_TRACING_V2」) |
| 跑一条链、看轨迹、看模型调用细节 | 3.2 何谓LangChain | text/26-ch03-02-3-2-langchain.txt:222(搜「丁香」) · text/26-ch03-02-3-2-langchain.txt:230(搜「每一次链条运行的轨迹」) · text/26-ch03-02-3-2-langchain.txt:234(搜「模型调用细节」) |
| 它是用来调试测试评估监视的 | 3.2 何谓LangChain | text/26-ch03-02-3-2-langchain.txt:21(搜「用于调试、测试、评估和监视」) |
| 两个框架都能开日志和调试 | 3.3 何谓LlamaIndex | text/27-ch03-03-3-3-llamaindex.txt:188(搜「Logging和Debug」) |
| 附录:两篇综述与那张论文表 | A.1 两篇高质量的Agent综述论文 与 A.2 论文选读 | text/69-fm-a-1-agent.txt:7(搜「中国人民大学高瓴人工智能学院」) · text/70-fm-a-2-agent-agent-agent.txt:7(搜「Agent研究领域代表性论文」) |
| 六条未来方向 | A.3 小结 | text/71-fm-a-3.txt:9(搜「多模态Agent」) · text/71-fm-a-3.txt:11(搜「人机混合协同」) · text/71-fm-a-3.txt:15(搜「伦理内化」) |
| 主走查的那段代码 | 4.3 Assistants API的简单示例 | text/32-ch04-03-4-3-assistants-api.txt:71(搜「鲜花价格计算器」) · text/32-ch04-03-4-3-assistants-api.txt:233(搜「进价的基础上加价20」) · text/32-ch04-03-4-3-assistants-api.txt:441(搜「售价是96元」) |
| 猿人期 | 后记 创新与变革的交汇点 | text/73-fm.txt:15(搜「猿人期」) |