Building AI Agents：地基不是模型，是编码、检索和记忆
微信读书《Building AI Agents with LLMs, RAG, and Knowledge Graphs》· Salvatore Raieli、Gabriele Iuculano 著，Packt 出版，中英双语对照版
逐页翻阅 1714 屏 · 4 部 · 2026-11-03
说明：这本书的编排逻辑我很欣赏——它没有一上来就讲 Agent，而是从"文本怎么变成向量"开始。四个部分依次是：文本与模型、Agent 构建、RAG 与知识图谱、生产化。这个顺序本身就是个判断：Agent 是果子，不是根。先有能编码文本的模型，再有能检索的知识，再有能编排的流程，最后才谈得上智能体。缺点是它太全，1714 屏什么都讲，什么都讲不深。
现在讲 Agent 的书，大多从 ReAct 或者某个框架的 hello world 开始。这本书反过来，用整整一部（Part 1）讲怎么把一句话变成一串数字。
一开始我觉得这是凑篇幅。读到后面才明白：作者的用意是让你知道，Agent 的每一个"聪明"，底下都压着一层并不聪明的数学。检索靠的是向量距离，重排靠的是打分，蒸馏靠的是分布差。这些东西不性感，但它们决定了 Agent 在真实场景里是"大概能用"还是"稳定能用"。
一、文本变成向量的四代方案，以及每一代的代价
第一部分梳理了文本表示的四条路，我觉得这个梳理比大多数教程都清楚，因为它不是简单罗列，而是按"丢掉了什么"来排序。
one-hot 编码：一个词一个位置，其余全零。问题是维度爆炸，而且任意两个词之间的距离都一样——"猫"和"狗"的距离，等于"猫"和"量子力学"的距离。这在语义上显然是错的。
词袋（bag-of-words）：把句子变成词频向量。它解决了维度问题，但丢掉了语序——"狗咬人"和"人咬狗"在它眼里是同一个东西。
TF-IDF：给词加权，越罕见的词权重越高。这个改进很聪明，因为它抓住了"区分度"这个概念——"的"出现一百次也没用，"芯片"出现一次就说明这段在讲芯片。但它仍然是词袋，仍然不懂语序，也不懂同义。
嵌入（embedding）：把词映射到一个连续空间，语义相近的词距离近。到这里，"猫"和"狗"终于比"猫"和"量子力学"更近了。书里从 word2vec 讲起，讲了嵌入的性质，以及怎么用它们做情感分析。
我的评价是：这四代不是"越来越好"，而是"用不同的方式丢失信息"。one-hot 丢失了语义关系，词袋丢失了语序，TF-IDF 丢失了上下文，嵌入丢失了精确性（一个词永远只有一个向量，不管它在句子里是什么意思）。理解这一点很重要，因为它解释了为什么今天的 RAG 还是经常检索错——不是检索算法不够好，是"把语义压成一个向量"这个动作本身就有损。
这也顺带解释了为什么书后面要专门讲知识图谱。向量检索擅长"意思相近"，不擅长"关系明确"。你问"张忠谋创立了哪家公司"，向量能给你一堆讲台积电的段落；但你问"谁创立了台积电，他之前在哪个公司"，这就需要"人—创立—公司"这种结构化的关系，向量的模糊匹配就吃力了。知识图谱补的正是这个洞。
二、蒸馏：教师教学生，教的是"分布"不是"答案"
书里讲知识蒸馏那一段，是我认为全书技术含量最高、也最容易被略过的地方。
它的流程分三步：先选一个合适的分词器（书里特意提醒，"尽管 GPT-2 所使用的分词器应用最为广泛，但事实上不同模型需要使用不同的分词器"），然后针对具体任务微调出一个"教师模型"，最后用这个教师去训练一个更小的"学生模型"。
关键在损失函数。书里写得很清楚：
这个蒸馏损失函数用于计算"教师"的 logits 与"学生"的 logits 之间的损失。该函数通常使用 Kullback-Leibler 散度损失来计算两个概率分布之间的差异。
为什么这件事值得单独说？因为它藏着一个很反直觉的洞察：学生学的不是"正确答案"，是"教师认为各个答案分别有多可能"。
举个具体的例子。一张猫的图片，标签是"猫"。如果用普通分类损失训练，模型学到的信号是"猫=1，其他=0"。但教师模型给出的可能是"猫 0.85、猞猁 0.10、狗 0.03、其他 0.02"。这个分布里含有大量信息——它告诉学生"猫和猞猁很像，和狗有点像，和汽车完全无关"。这种信息叫"暗知识"（dark knowledge），它不在标签里，只在教师的输出里。
用 KL 散度去对齐这个分布，学生学到的就不只是"什么是对的"，还有"什么和什么接近"。这就是为什么一个小得多的模型，靠蒸馏能逼近大模型的效果——因为它继承的不是答案，是教师对世界的整个"相似性判断"。
书里还提了一句很实在的话：可以用"一个比教师模型规模更小的预训练模型来进行训练——这样只需使用少量的训练样本即可完成模型的训练"。这句话点出了蒸馏的工程价值：它不是用来提升效果的，是用来在效果基本不变的前提下，把成本打下来的。
这一点我特别想强调。现在很多团队一做 Agent 就想着上最大的模型，结果成本压不住、延迟扛不住，最后项目死在这一步。而蒸馏提供的是另一条路：用大模型做"教师"离线生成高质量数据，用小模型在线服务。这条路的代价是要多做一轮工程，收益是单位成本能降一个量级。这笔账，值得算。
三、高级 RAG 的四个插件：真正有用的是"重排"
书里讲高级 RAG 的那一节，列了四个插件，我用下来觉得它的排序是对的：
Reranker：该功能使我们能够对检索过程中获得的上下文信息进行排序。这是高级问答系统中应用最广泛的功能之一，因为事实证明它能够显著提升检索结果的质量。
重排（Reranker）之所以最有效，原因很朴素：初步检索用的是向量相似度，而向量相似度是"粗筛"——它快，但它只看"意思像不像"，不看"能不能回答这个问题"。重排用的是更贵的模型（通常是 cross-encoder），它把"问题"和"候选段落"放在一起看，判断"这段能不能答这个问题"。
一个是"看起来相关"，一个是"真的能答"。这个差别在简单问题上不明显，在复杂问题上就是生死线。
另外三个插件也各有用途，但优先级低一些：
查询改写（Query transformation）——把用户那句含糊的话改成几个更明确的查询，目的是"扩大检索范围，因为有些相关文档可能会被遗漏"。它解决的是"用户不会提问"这个问题。
查询路由（Query routing）——"这一机制使我们无法对所有查询采用相同的处理方式，而是能够制定相应的规则，从而提升查询效率"。说白了就是分流：简单问题走便宜的路径，复杂问题走贵的路径。这个设计对成本控制非常关键。
混合检索（Hybrid search）——把关键词检索和向量检索结合。前者擅长精确匹配（比如产品型号、人名），后者擅长语义匹配。两者互补，能覆盖单一方法的盲区。
我觉得这四个插件的排列，其实反映了一个成熟工程师的判断顺序：先保质量（重排），再保召回（改写），再控成本（路由），最后补短板（混合）。而大部分教程的顺序是反的——先讲怎么搭向量库，最后才提一句"可以加重排"。这个顺序的差别，就是"能跑"和"好用"的差别。
四、记忆：Agent 最像人的地方，也是最容易做假的地方
书里讲记忆模块，用了三个操作来定义它：读取（memory reading）、写入（memory writing）、反思（memory reflection）。
原文对这个划分写得很细：
内存读取检索信息以支持智能体的决策（增加上下文的连续性和一致性）；内存写入则允许保存对智能体与环境交互有用的信息（从而减少冗余，并克服非显著内存的限制）；而内存反思允许从对已存储信息的分析中得出洞见，从而可以调整行为以实现目标。
这三件事里，我认为"反思"是最被低估的。
读取和写入，本质上是数据库操作——存进去、取出来。任何做过工程的人都能想到。但"反思"不一样，它要求 Agent对自己存下来的东西再做一次加工：不是简单地把记忆取出来用，而是从记忆里归纳出更高层的结论。
举个例子。一个客服 Agent 记录了 20 次用户投诉。读取只能让它知道"这 20 次分别是什么"；反思能让它发现"其中 14 次都提到了同一个物流延迟问题"。前者是检索，后者是洞察。而真正有价值的 Agent，靠的是后者。
书里还提了"混合记忆机制"——短期记忆局限于大语言模型的上下文窗口，长期记忆靠外部存储，"从而让智能体的信息处理能力超出大语言模型的处理范围"。这个设计很实用，但它也暴露了一个现实：所谓"记忆"，本质上是"用外部存储去骗过上下文窗口的限制"。模型本身并没有真的记住什么，它只是每次都重新读一遍你喂给它的东西。
这一点值得警惕。因为市面上很多号称"有记忆"的产品，做的其实就是"把历史对话塞回上下文"。对话一长，塞不下了，就"忘"了。真正的记忆需要取舍——记住什么、忘掉什么、怎么压缩。而取舍是判断，不是存储。书里提到了"避免重复和记忆溢出"，算是点到了，但没有深入。
五、强化学习：不用拆任务，直接给个目标
书里有一段讲强化学习和监督学习的区别，用了一个我觉得特别好的类比。
它说，监督学习是把复杂问题拆成子问题、再制定解决方案；而强化学习是"直接定义一个智能体必须解决的总体问题"。然后给了通勤的例子：
起初，你不会将任务分解为诸如"了解公交时刻表"、"估算步行时间"或"优化出行时遇到的天气状况"之类的子任务。相反，你会将整个目标视为一个整体：每天都能准时到达工作地点。
这个类比之所以好，是因为它把"监督 vs 强化"这个抽象区别，落到了每个人都能体会的经验上。
但它也暴露了强化学习的问题。通勤这件事，你可以靠反复试错学会，因为试错的成本很低——走错一条路，多花十分钟而已。但如果任务错了要赔钱、要伤人、要违法呢？你就不能靠试错了。
这解释了为什么强化学习在游戏、机器人、推荐系统里成功，在医疗、法律、金融这些高风险领域推进得很慢。不是算法不行，是试错的代价不允许。书里没有明说这一层，但我觉得这是读者必须自己补上的一课。
六、从脚本到产品：那句"这还不能算产品"
第四部分讲生产化，开头有一段话说得很不客气，我读完停了几秒：
当我们使用 Python 编写脚本时，虽然可以生成能在电脑上运行的程序，但这还不能算是一款真正的产品……Streamlit 工具能够帮助我们快速搭建应用程序的原型，但这并不适合制作最终产品，尤其是当该产品需要被多名用户同时使用时。
"尤其当该产品需要被多名用户同时使用时"——这句话是整段的关键。单用户跑通和多用户可用，中间隔着的不是"加个界面"，而是一整套工程：并发、隔离、限流、重试、监控、计费。
书里接着讲了 MLOps 和 Docker，然后讲了四种商业模式：SaaS、MaaS、DaaS、RaaS。这一段我觉得写得挺清醒，因为它说了一句很多技术书不愿说的话：
多智能体系统不是孤立的事物，而应被视为一种产品，并且这种产品可以以多种方式营销。
这句话把一个纯技术问题，拉回到了商业现实。你做的不是"一个 Agent"，你做的是一件要卖出去的东西。而要卖出去，你就得先想清楚：客户付的是什么钱？是订阅（SaaS）、是按调用量（MaaS）、是按数据（DaaS）、还是按结果（RaaS）？
这个选择必须"在产品开发之前"做出，因为"它们决定了产品的发展"。这个判断我完全同意。因为不同的收费模式，倒逼出完全不同的架构：按调用量收费，你就得把每次调用的成本算到分；按结果收费，你就得对准确率负责到极致；按订阅收费，你就得保证稳定性和留存。商业模式不是商业部门的事，它从第一天就在决定技术选型。
七、它的短板
这本书内容很全，但"全"恰恰是它最大的问题。我说四点。
第一，1714 屏什么都讲，结果什么都讲不透。从 one-hot 编码讲到 Docker 部署，从 word2vec 讲到 RaaS 商业模式，跨度太大了。每一块大概只有几十屏，够"知道有这么回事"，不够"真的会用"。比如知识图谱那一部分，书名叫里有 "Knowledge Graphs"，但实际篇幅和深度都远不如 RAG 那部分。你读完之后会有一种"我好像什么都见过了"的错觉，但真要动手，还是得回去查文档。
第二，它是一本"技术拼盘"，缺少一条真正的主线论证。四个部分之间的逻辑是"从底到顶"，这个没错，但它更像是"把该讲的都讲一遍"，而不是"论证一个观点"。对比一下那些真正好的技术书——它们会有一个贯穿全书的判断，每一章都在为这个判断服务。这本书没有。它更像一本编写得不错的教科书，而不是一本有观点的书。
第三，案例的工程真实性存疑。书里的代码能跑，但都是"干净的实验室环境"：数据是准备好的、API 是通的、错误是不发生的。真实的 Agent 项目里，80% 的时间花在处理脏数据、调试不稳定的接口、排查"为什么昨天好好的今天不行了"。这些内容书里几乎没有。它教你怎么把东西搭起来，没教你怎么让它不倒。
第四，双语对照排版拖慢了阅读。和上一本 Packt 的书一样，中英逐段对照看起来是照顾两类读者，实际上让两类读者都要不断跳读。而且译文的术语一致性不好，同一个概念在不同章节有不同译法，读的时候需要自己脑补对应关系。
不过话说回来，这本书的定位本来就该是"地图"而不是"手册"。它的价值在于让你知道这个领域有哪些层、每层大概在解决什么问题、彼此怎么衔接。你要盖房子，拿它当地图是够的；你要砌墙，还得去找专门的砖瓦匠。我读它的方式就是：先看目录建立框架，再挑自己缺的那块细读，其余的扫过去。这样读，1714 屏大概三天能过完，而且真的能记住东西。
一句话总结：Agent 的上限不取决于你用了多强的模型，取决于你有没有耐心把底下那三层——编码、检索、记忆——做到不掉链子。
阅读记录：《Building AI Agents with LLMs, RAG, and Knowledge Graphs》，Salvatore Raieli、Gabriele Iuculano 著，Packt 出版，中英双语对照版，微信读书逐页翻阅 1714 屏，四部分读完，从文本表示读到生产化部署与商业模式。2026-11-03。
发表评论: