AI Agents in Practice：代理是四层设施，不是更强的模型
微信读书《AI Agents in Practice》· Packt 出版 · 中英双语版
逐页翻阅 814 屏 · 9 章 · 2026-11-03
说明：这是一本写给工程师的实操书，结构是"工作流演进 → 代理崛起 → 编排器 → 记忆 → 工具 → LangChain 实战 → 多代理 → 协议 → 伦理"。我的结论是：它的分解方式值得抄，它的排版和译名不值得买。下面分清楚哪一段是真东西、哪一段是凑数。
读这本书之前，我以为它会是又一本"教你用 LangChain 搭个助手"的书。读到第 3 章我才确认它不是——它做的是一件更基础的事：把"代理"这个词拆开，拆成四个各自可以单独施工的部件。
拆法是：编排器（orchestrator）、记忆与上下文（memory & context）、工具与外部集成（tools & integrations）、协议（protocol）。四件东西，四章，一个不多一个不少。
这个拆法值钱，因为它把一句空话变成了四个可验收的问题：谁来拆任务？记什么、记多久？能碰哪些外部系统？跟别的代理怎么说话？任何一个号称做了 Agent 的团队，被问这四个问题时答不上来，那它做的就不是代理。
但这本书也止步于此。它把四件东西讲清楚了，却没讲它们怎么互相打架——而这恰恰是工程上真正花钱的地方。我先说它做对的部分，再说它没做的部分。
一、它先讲工作流，再讲代理，这个顺序本身就是论证
第 1 章叫"GenAI 工作流的演进"，第 2 章才叫"代理的崛起"。很多同题书会把这两块揉在一起讲，结果读者永远分不清"我到底需要一个工作流还是一个代理"。这本书把它们排成前后两章，等于先给你一条基线，再告诉你基线在哪里断掉。
这个顺序里藏着一个判断：代理不是工作流的升级版，是工作流的替代方案。它俩不是同一条路上的两代产品，是两种不同的控制结构。工作流的下一步是写死的（书里的索引条目直接就叫"条件式工作流 / conditional workflows"），代理的下一步是运行时算出来的。
而这本书最诚实的一页，出现在第 2 章讲术语的那一段。它没有假装这个领域的词汇是统一的，反而直接把混乱摊在桌上：
在谈论人工智能代理时，你经常会听到"任务"、"工具"、"技能"、"插件"、"功能"和"动作"这些术语，它们其实都可以用来指代代理"执行任务"的能力。此外，不同的人工智能协调器会使用不同的术语来描述同样的概念。让我们试着把这些术语弄清楚吧。
这段话看起来只是术语梳理，其实是在承认一件事：这个领域到目前为止，连"代理能干什么"这件事都没有一个共同说法。
我要在这里加一句自己的判断：术语混乱从来不只是语言学问题，它是责任边界问题。当一家厂商管能力叫 tool、另一家叫 skill、第三家叫 action，你把这些代理拼在一起时，"谁能调用什么"就没有统一的落点了。审计的时候你问"这个代理有没有权限删库"，三家给你的答案格式都不一样。安全团队被迫给每一家写一套适配器——这就是词汇不统一的实际代价。
作者显然知道这一点（不然不会专门辟一段讲），但他停在了"让我们弄清楚"，没往下走到"所以应该约定什么"。这是全书的一个典型模式：他总能准确指出混乱在哪里，然后礼貌地绕开。
二、编排器：全书最重要的一章，缺了最关键的一问
第 3 章的标题是"The Need for an AI Orchestrator"——注意是"需要"，不是"如何实现"。这个措辞很说明问题：这一章的任务是说服你"必须有这个东西"，而不是教你"怎么造这个东西"。
章节顺序也很有意思：编排器（第 3 章）排在记忆（第 4 章）和工具（第 5 章）之前。这是在暗示一个优先级——先决定"谁指挥"，再决定"记什么""能碰什么"。我认为这个优先级是对的。反过来做（先接一堆工具再想谁来调度）的团队，最后都会得到一个庞大的 if-else 树，然后管它叫"编排"。
但这一章缺了一个问题，而且是致命的那一个：编排器凭什么判断任务已经完成了？
这不是抬杠。工作流的终止条件是写死的——跑完第 7 步就结束，错了也是结束。代理的终止条件必须靠自评："我觉得做完了。"自评一旦偏，会掉进两种坑：一种是提前收工（明明还有两个子任务没做，它认为完成了），另一种是无限循环（它永远觉得还差一点）。
这两种坑我都踩过。前者更隐蔽，因为系统会给你一个"成功"的状态码，只是结果是错的；后者更贵，因为它在烧钱，而你往往是在账单出来之后才知道。
还有一层更细的难点，书里同样绕开了：拆到什么粒度算对？拆太粗，子任务本身还是要模型一次性想清楚，等于没拆；拆太细，编排器自己的调度开销就超过了干活的时间，而且每一步都要把上下文重新载入，成本翻倍。书里给的是"拆任务—派活—汇总"三步，没给粒度判据。我的经验判据只有一条：一个子任务如果失败后可以独立重试、不用重跑别的，这个粒度就是对的。
书里把编排器该做的事列得很全（拆任务、派活、汇总），但没给"验收"这一步任何方法论。而在我看过的真实系统里，编排器 80% 的工程量都花在验收上，不是拆解上。拆解靠模型能力，验收靠工程约束——后者才是你自己要写的那部分代码。
三、记忆那一章，是全书最接近工程的部分
第 4 章讲记忆，是我读得最慢的一章，也是我认为唯一可以直接拿去用的部分。它把记忆分成短期和长期两层，说得很干净：
虽然短期记忆处理的是当前信息，而长期记忆则着眼于时间上的连续性。它使主体能够在不同的时间段内回忆起信息，从而实现个性化处理、保持知识的持续性，并有助于做出更好的决策。
紧接着它说，长期记忆通常由持久化存储支撑——向量数据库、知识图谱或结构化存储；而其中最有效的技术之一是检索增强生成（RAG），代理从存储中取出相关知识来支撑回答。
这段话把 RAG 的位置摆对了：RAG 是长期记忆的一种实现手段，不是长期记忆的同义词。我见过太多方案把这两个词当等号用，然后在评审会上被问"你的记忆模块怎么处理信息冲突"时哑住——因为 RAG 只负责"取回来"，不负责"判断哪条是对的"。
但这一章也就到此为止了。它把记忆当成一个存储问题，没有当成一个遗忘问题。
而工程上真正难的是遗忘。我给一个具体场景：用户三个月前说"我不吃辣"，系统记下了；上个月他说"最近开始吃辣了"，系统也记下了。两条记忆都在向量库里，语义相似度都很高，检索时一起被取出来。模型看到互相矛盾的两条，会怎么办？大概率是各取一半，给出一个"微辣"的糊涂答案，或者干脆挑了那条向量距离更近的——而距离近不代表时间新。
正确的做法需要三样东西，书里一样都没提：时间权重（新记忆覆盖旧记忆）、冲突消解（同一实体同一属性只保留一条）、失效机制（什么条件下记忆该被删）。这三样都不是模型能力问题，是数据建模问题。
再往深一层：记错了比记不住更贵。记不住，用户重说一遍就行；记错了，系统会用一年前的偏好去猜他现在想要什么，而且猜得很有自信。用户在那一刻的感受不是"这 AI 不够聪明"，是"这 AI 在冒犯我"。这个差别，决定了产品是"不好用"还是"不能用"。
四、语义函数：把提示词当代码管，这个想法值得抄
第 5 章讲工具与外部集成，里面有一小节讲"语义函数"（semantic functions），我认为是全书最有迁移价值的一段：
语义函数是用自然语言描述的，但在内部被转化为代码形式。在诸如"语义内核"这样的框架中，这种机制尤为有效：在该框架中，分类体系是将各种插件视为一组功能来处理的。
然后它拿 Semantic Kernel 内置的 WriterPlugin 举例，给了一个目录结构：插件目录下面是各个能力目录（比如 Acronym），每个能力目录里放一个 config.json 和一个 skprompt.txt。
这个结构看起来平平无奇，但它做了一件很重要的事：把"提示词"从代码里赶了出去，变成了一个独立文件。
为什么重要？因为提示词是这套系统里最不稳定、最需要反复改、最需要 A/B 对比的东西。它如果躺在 Python 字符串里，改动就没有历史、没有责任人、没法灰度。它一旦变成 skprompt.txt，它就能进 git，能 diff，能 review，能回滚——它从"代码的一部分"变成了"配置的一部分"，而配置是可以被非工程师改的。
我在实际项目里最深的体会是：一个 AI 功能上线后，80% 的迭代都是在改提示词，而不是改逻辑。如果改一次提示词要走一次完整的发布流程，这个产品就死定了。这本书用一个小节把这件事说清楚了，虽然它自己可能没意识到这有多重要。
但这里也有一个明显的缺口：它给了结构，没给测试。提示词既然是代码，就该有单元测试；书里一个都没有。这等于把最不确定的东西塞进了最确定性的工程流程里，然后假装它已经工程化了。
提示词的测试怎么做？业界的做法无非三种：固定输入比对输出（脆，模型一升级就全红）、模型评模型（便宜，但你在用一个不确定的东西验证另一个不确定的东西）、人工抽检加回归集（贵，但唯一可信）。这三种各有代价，书里一条都没讨论。它教你把提示词管起来，却没教你怎么知道改坏了没有。
五、追踪：代理的 bug 只能靠轨迹抓，这段是真功夫
第 6 章用 LangChain 搭第一个代理，其中讲 LangSmith 的那几页，是全书唯一让我觉得"作者真在一线干过"的地方：
我们已经可以看到一些有趣的统计数据，比如错误率、总成本、运行次数等等。现在让我们从 AskMamma 项目的概述中获取更多详细信息。
截图里那个面板确实给了这些东西：7 天内的运行次数、总成本、中位 token 数、错误率、P50 与 P99 延迟、首次 token 时间。逐条 trace 里能看到每一次 LLM 调用的输入输出、耗时、有无报错。
为什么我说这段是真功夫？因为代理的失败是概率性的，天生不可复现。同样的输入，今天跑成功，明天跑失败，后天又成功。传统的调试手段在这里全部失效：你打断点没用（它不一定会走到那一行），你复现不了（温度不为零），你看日志也没用（日志只记结果，不记它为什么这么想）。
唯一可行的手段是留全轨迹，然后事后逐层看：它第一步理解错了？第二步选错了工具？第三步工具返回了但被它误读？这三层的修法完全不同——第一层改提示词，第二层改工具描述，第三层改返回值的结构化方式。没有轨迹，你连"该改哪一层"都判断不了，只能凭感觉乱改，然后越改越乱。
但这段也有个问题：它教你看，没教你判。
错误率 10%，这个数字是好是坏？没有基线，就无从判断。一个内部文档问答系统，10% 的错误率可能可以接受（用户自己会核）；一个自动退款代理，1% 的错误率就是灾难。书里给了仪表盘，没给刻度。而刻度恰恰是工程管理的核心——没有 SLO 的监控，只是一块会发光的屏幕。
六、成本这件事，它知道重要，但只敢放在第 1 章讲
全书唯一正面谈成本的地方，不是在任何一章的正文里，而是在第 1 章讲模型演进时顺带提到的"蒸馏"：
学生模型训练：利用软标签以及真实标签来训练一个较小的模型，这些标签能够提供丰富的信息与细致的预测结果。
优化与微调：对子模型进行进一步改进，以提高其准确性和效率。
配的图是那张经典的蒸馏框架图：教师模型蒸馏出软标签，迁移给学生模型，数据回流。
技术上讲得没错，但位置很说明问题。把成本控制放在"模型演进史"里讲，等于把它当成一个技术背景，而不是一个工程决策。而实际上，对代理系统来说，成本是第一顺位的架构约束，不是可选优化。
原因很简单：代理的成本结构是"轮次 × 上下文长度"。工作流跑 3 步，代理可能跑 15 步；每一步都要把之前的全部对话塞回去，于是第 15 步的输入长度是第 1 步的十几倍。多代理更狠——三个代理互相通信，消息量是平方级涨的。这不是"贵一点"，这是架构级的分叉：同样一个任务，用工作流做每次 0.002 美元，用多代理做可能每次 0.4 美元，差 200 倍。
真正能压住成本的其实不是换小模型，是压缩上下文。代理跑到第 10 轮时，输入里往往有 90% 是前面九轮的残渣——工具的原始返回、失败的尝试、被推翻的计划。把这些东西在进入下一轮之前摘要成一份结构化状态（当前目标、已完成、待办、已知约束），效果比蒸馏强一个数量级，而且当天就能做。书里把成本问题推给了模型层（蒸馏、微调），这是把一个工程问题当成了训练问题。
书里没有一张成本估算表，没有一条"什么任务值得上代理"的判据。它在第 3 章花整章论证"你需要一个编排器"，却没论证"你需要它的代价是多少"。这是这本书最大的结构性缺陷：它论证了必要性，回避了代价。
七、协议层：Agent Card 解决的是"信任之前的发现"
第 8 章讲代理协议，用的是 A2A 那一套。它把 Agent Card 的字段一个个列出来：url 是代理接收点对点协议请求的端点地址；version 是代理或 A2A 协议的版本；capabilities 说明支持哪些特定功能——streaming（通过服务器推送事件做实时数据传输）、pushNotifications（向客户端发送异步更新）、stateTransitionHistory（记录任务状态变更的历史）；authentication 则指明支持 bearer 令牌还是 API key。
这几个字段我认为挑得准。它们正好覆盖了"一个陌生代理接入时你需要知道的全部"：它在哪、它是什么版本、它能干什么、它能不能异步、它干过什么、它认什么证。
但我注意到一个细节，而且我认为这个细节暴露了作者的思路顺序：认证排在最后。
在书的叙述里，先讲"能连上"，再讲"能谈"，再讲"能异步"，再讲"能追责"，最后才讲"认什么证"。这是一个"能力优先"的顺序，很符合开发者探索一个新协议时的心态。
而工程上正确的顺序恰恰相反。真实世界里，两个不同厂商的代理要互相信任，第一个要回答的问题是："我凭什么相信你？"——这不是技术问题，是责任问题。你让一个外部代理去查你的库存、改你的订单，一旦它改错了，谁赔？协议里如果没有"权限边界"和"操作留痕"的强约束，任何跨组织的代理协作都只能在 demo 里跑。
书里给了 stateTransitionHistory（状态变更历史），这算半个答案——它至少让事后追责有了依据。但它没有讨论"越权"：一个代理拿着 bearer 令牌，能做的事和令牌主人的权限完全一致，这在多代理编排里是非常危险的模型。正确的做法应该是"按任务授最小权限、任务结束即回收"，也就是能力令牌那一套。书里一个字没提。
更根本的问题是：这一章写成了字段说明书，没写成失败模式分析。协议的真正价值不在它规定了什么，而在它规定了"出错时怎么办"——对方超时了怎么重试、重复请求怎么幂等、状态不同步怎么对齐。这些才是协议存在的理由。书里把"是什么"讲完了，把"会怎么坏"留白了。
下面这张图，是我把 9 章压成 12 个格子之后的样子。
这张图里左边两列是它讲清楚的部分，第三列是它讲了一半的部分，第四列是它欠读者的部分。
八、它的短板
下面这五条，是我认为掏钱之前必须知道的。
第一，双语排版把 814 屏注水成了两倍。这本书每一段英文后面都跟一遍中文译文，一段一段交替往下排。结果是一本 9 章的书占了 814 屏——按正常排版，这个内容量大概 400 屏就够。更离谱的是索引也印了两遍：随手翻到附录，"backpropagation / 反向传播""Bilingual Evaluation Understudy (BLEU) / 双语评估指标（BLEU）""blockchain / 区块链"——每一条都是英文一行、中文一行。读者付的是两本书的纸钱，拿到的是一个半的信息量。
第二，译名各行其是，导致你搜不到东西。"AI Agents"在这本书里被译成"人工智能代理"，第 4 章里那句"人工智能代理如何能在多次互动中保持长期的上下文连贯性"就是例子；"orchestrator"译成"协调器"；"Semantic Kernel"译成"语义内核"。而国内工程界通行的叫法是"智能体""编排器"。这不是翻译水平问题，是可用性问题——你读完这本书，去搜"智能体 记忆"，搜"编排器 实现"，你会发现社区里的词和书里的词对不上，书变成了一个孤岛。一本工具书最怕的就是这个：它自己内部自洽，跟外部世界不通。
第三，代码停在"能跑"。第 6 章"用 LangChain 搭你的第一个代理"，定位就是 demo。它让你看到代理跑起来，但没让你看到代理跑砸了怎么办：没有重试、没有超时、没有幂等、没有错误分类、没有降级。而生产环境里，一个代理 90% 的代码都在处理"如果这一步失败了"。书里教的是点火，没教刹车。
第四，伦理章是模板，可以套在任何一本 AI 书上。第 9 章讲内容过滤，给的理由是法律与声誉：公司有义务遵守法律法规，也要避免 AI 生成引发争议的内容，"如果用户向某公司的人工智能提问后得到的回复满是辱骂性语言或虚假信息，承担负面后果的将是该公司"，所以内容过滤机制"相当于品牌的'良知'和法律合规保障机制"。
这段话本身写得不错，比喻也准。但它跟"代理"没有关系——它讲的是聊天机器人的风险。代理特有的伦理问题是另一套：一个能自己下单的代理，误买了一百台服务器，责任在写提示词的人、在模型供应商、还是在批准上线的经理？代理的伦理核心是"自主行动的边界"，不是"输出的内容是否得体"。这一章写成了通用合规章，等于占了篇幅没给答案。
第五，全书没有一个失败案例。9 章读下来，所有例子都是"我们这样做，然后它工作了"。没有一节讲"我们这样做，然后它炸了，我们才知道原来是这样"。而对工程书来说，事故复盘比成功案例值钱十倍——因为成功各有各的运气，失败往往有共同的结构。一本没有失败案例的工程书，读者只能靠自己去踩那些坑。
写到这里，我的结论其实很简单：
这本书的正确用法，是把第 3、4、5、8 章当成一张检查表来用。你手上有一个"Agent 项目"，拿这四章的标题挨个问自己：编排器在哪？记忆怎么过期？工具权限怎么收？跟外部代理怎么互信？四个问题答不出来的，项目大概率会在三个月后变成一堆提示词。
而它的错误用法，是当参考手册。因为它不给版本、不给测试、不给成本、不给失败模式——这四样缺了，照着抄出来的东西只能跑在你自己机器上。
一句话收尾：它把"代理是四层设施"这件事讲明白了，却始终没回答那句最要紧的话——这四层设施互相打架的时候，谁说了算？
阅读记录：《AI Agents in Practice》，Packt 出版，微信读书中英双语版，逐页翻阅 814 屏，九章按"工作流演进—代理崛起—编排器—记忆与上下文—工具与集成—LangChain 实战—多代理—协议蓝图—伦理"通读。重点核对了第 2 章的术语梳理、第 4 章的短期/长期记忆划分、第 5 章的语义函数与 WriterPlugin 结构、第 6 章的 LangSmith 追踪面板、第 8 章的 A2A Agent Card 字段，以及第 9 章的内容过滤论述。2026-11-03。
发表评论: