复合智能体不是更聪明，是把活分给几个专职的
阅读方式：微信读书网页版，从版权页翻到第 13 章末，共 571 屏、13 章、11 分 46 秒。 十三章：技术基础、系统结构、大模型开发、LangChain、LangGraph、RAG、MCP、单智能体实战、多智能体实战、A2A、扣子、部署维护、复合系统项目。
这是我读的这一批 AI 书里，最"工程"的一本。
大部分智能体的书，讲完 LangChain 和几个案例就收尾了。这本不一样：它从 Transformer 的注意力机制讲起，中间过一遍 LangGraph 和 RAG，然后专门用三章讲 MCP、A2A、部署维护，最后收在一个复合系统的完整项目上。
换句话说，它不止讲"怎么搭出来"，还讲"怎么让它活下去"。
而它最有价值的一个判断，藏在一个用词上——"复合"。
一、"复合"不是更聪明，是分了工
第 13 章的项目叫"从零实现一个复合智能体系统"。读之前我以为"复合"是指能力更强，读完发现不是。
它的意思很朴素：把一个大任务切成几段，每段交给一个专职的智能体，再用协议把它们接起来。
书里第 9 章（多智能体实战）和第 10 章（A2A 协议）把这个思路摊得很开。A2A 的定位是"智能体之间的协作语言"，而它最实在的设计是消息里的两个字段：
auth 与 capability
书里的解释是：这两个字段分别携带智能体的身份令牌、签名信息，以及服务能力描述；权限受控要靠它，任务路由也要靠它。
再往下看一层，"能力声明"要求每个智能体在注册时对自己的功能做结构化描述：可用工具、语言模型支持、任务范围、调用接口。
我认为这是全书最"像真实系统"的一处设计。因为它回答了一个非常实际的问题：你怎么知道对面那个智能体会干什么？
不是靠文档，不是靠约定，而是靠它注册时自己申报。这一手，把"多智能体协作"从口头默契变成了可校验的接口。
顺带也说明了为什么"复合"不等于"更强"：一个系统里智能体越多，接口越多，出错的面越大。能让它成立的不是模型多聪明，是每个接口都说清楚了。
二、五个模块，不是三个
第 2 章讲智能体的组成。常见的讲法是"感知—决策—执行"三段，这本书给了五个核心模块：感知、认知、执行、记忆、接口。
多出来的两个，恰好是最容易被跳过、又最决定成败的两个。
记忆模块管上下文与持久状态。书里在第 2.2 节把生命周期拆成四段：启动与初始化、对话状态追踪、中断恢复与持久化上下文、注销与资源释放。
这四个词里，我认为第三个是分水岭。
能不能中断恢复，决定它是玩具还是系统。
原因很直白：如果它每一步都得从头再来，那它就只适合"一次问完"的场景；一旦涉及多轮、跨天、需要人工介入的流程——比如审批、跟单、排障——没有持久化上下文，就等于每次都要重新认识你一遍。
而这件事跟模型能力一点关系都没有，纯粹是工程。
接口模块同理。书里在第 2 章列了四种集成方式：Web API 与插件、数据库读写、文件系统与代码执行环境、UI 输入输出的中间层。
前三个是"能做什么"，最后一个是"怎么让人看见"。很多智能体做出来没人用，问题往往在第四个——能力都在，但没地方显示。
三、从链到图：真正的需求是"能返工"
第 4 章讲 LangChain，第 5 章讲 LangGraph。两章连起来读，能看出一个很清楚的演进逻辑。
LangChain 的基本单位是"链"：工具封装成独立函数，接口清晰，按顺序串起来跑。书里有个例子是查书——先调 OpenLibrary 的搜索接口查书名，再拿书名去查详情。两步，顺序固定。
这种结构对"几步就能干完"的活很好用。但它有个隐含前提：你得事先知道该按什么顺序走。
LangGraph 换的就是这个前提。它把流程表达成一张状态图：节点是动作，边是跳转，可以回头、可以分支。
为什么需要"回头"？因为真实任务不是流水线。检索结果不对，得回去改写查询；校验没通过，得回到上一步重做。用链去表达这种事，只能写成嵌套的 if-else，越写越像一坨。
书里还有一段讲"动态链路"，我觉得是这两章的落点：把推理与行动（Reasoning + Action）组合成指令，由执行器自己判断该调哪个工具、传什么参数，拿到返回后继续推理。
翻译一下：顺序是它选的，不是你写死的。
这句话听着很强，但它同时解释了为什么需要 LangGraph——既然顺序是它选的，那你就必须给它一张能做判断的图，而不是一条只能往前的链。
四、三张协议，各接一头
这本书在结构上最聪明的一处，是把三个"接"分给了三章：
MCP 接工具（第 7 章）。模型上下文协议，把"能调什么、怎么调"标准化。它解决的是以前每个工具写一套胶水的麻烦。
A2A 接伙伴（第 10 章）。智能体之间的协作语言，靠 auth 和 capability 做身份与能力的双向验证。
RAG 接知识（第 6 章）。书里的定义是：在生成答案之前，先通过语义检索从外部知识库拿到相关片段，再把这些片段和原始提问一起输入模型。
RAG 那章给的链路是五步：文本分割与编码 → 向量索引构建 → 查询时检索相似语料 → 上下文拼接 → 调用模型生成。
五步都眼熟，但我要指出一个现象：大部分 RAG 项目失败，坏在第四步"拼接"，而非第一步"分割"。
因为前三步是技术，第四步是判断——检索回来的五段话，哪段该放前面、哪段该删、冲突了听谁的？ 这一步没有标准答案，它取决于你对业务的理解，而不是你对 Faiss 的理解。
三张协议放在一起看，逻辑就清楚了：一个智能体要活下来，必须同时接住三样东西——工具、伙伴、知识。缺一样，它就只能待在一个很小的场景里。
五、从单到多，再到上线
第 8、9 章分别是单智能体实战和多智能体实战，第 11 章讲扣子，第 12 章讲部署、扩展与维护。
这四章的顺序本身就在传递一个态度：先能跑一个，再谈协作；先能上线，再谈规模。
关于"多智能体"，我想补一句书里没直说、但从第 9、10 章能推出来的判断：多智能体成立的前提是任务能切开。
切得开的标志是：每段的输入输出能定义清楚，段与段之间不来回改。切不开就加人，只会多几张嘴吵架——你会得到一堆互相等待、互相甩锅的智能体，比单智能体还慢。
第 11 章讲扣子（低代码平台），作者的态度很务实：它适合快速搭、快速验。我认为这类平台真正的价值不是"省事"，而是让业务方自己改——这一点比技术先进重要得多，因为需求永远比开发快。
第 12 章讲部署、扩展、维护，是全书最不"性感"、却最该读的一章。并发、会话状态、成本、监控——demo 到线上之间，隔着的就是这一整套东西。
六、这本书的短板
一是代码占比过高。 571 屏里，第 3、4、5、6、8、9 章大量是 Python 代码。好处是能照着跑，坏处是代码会过时，而判断不会——这本书真正值钱的是第 1、2、7、10、12 章的结构性内容。
二是术语密度大，且没给对照表。 MCP、A2A、RAG、LangGraph、Function Calling 这些词分散在不同章节，书里没有一处把它们放在同一张表里说清"谁管哪一层"。读者得自己拼——我上面那张图，就是替它拼的。
三是部分章节的"实战"水分偏多。 第 8、9 章的实战，流程是完整的，但场景偏教学（查书、问答），离真实业务的复杂度还有距离。第 13 章的复合系统项目，是全书唯一一个"像真活儿"的案例。
它的优点是：把智能体当系统讲，而不是当技巧讲。 大部分书停在"提示词怎么写、工具怎么调"，这本一路讲到了"中断了怎么恢复、上线了怎么扩容"。技巧让人做出 demo，系统让人交出产品。
七、一句话
"复合智能体"这个词容易让人往"能力更强"上想，但书里的意思恰好相反：它是把一个任务拆开，让每段都由一个只干这件事的智能体负责，再用三张协议把接口焊死。 所以这套东西的难点从来不在模型——在你有没有把活切清楚、把状态存下来、把能力声明写明白。三件事全是工程，一件都不玄。看清这一点，就不会再指望换个更强的模型来解决架构问题。
阅读记录：微信读书网页版逐页翻阅，571 屏 / 13 章 / 11 分 46 秒。
本书知识图谱见文中配图，原图地址：https://www.jiangtian.top/zb_users/upload/kg/agent-composite-map.png
发表评论: