跳到主要内容

从 RAG 到 agent — 检索变成一个工具

这一章讲三件事: agent 这个词从 1973 年走到 LLM 时代的谱系; 一个 agent 系统的三层结构与「单 agent 还是多 agent」的取舍; 以及工具调用(tool calling)这个让模型能「动手」的机制, 连同标准化它的两个协议 MCP 与 A2A。 读完你会理解:agentic RAG 不是另一种 RAG 管线, 而是把 RAG 变成 agent 手里的一个工具。

1. 顶层全景:从「一次检索」到「一个循环」

经典 RAG 的检索发生在管线开头,一次。而有一类问题它答不了—— 比如「收购了 Startup X 的那家公司,总部在哪?」需要先查到收购方, 再拿收购方去查总部,两步检索,第二步依赖第一步的答案1

agentic RAG 的回答是把检索降级成一个工具,把决策权交给模型:

┌──────────────── agentic loop ────────────────┐
│ ① observation(观察):当前状态是什么 │
│ ② reasoning & planning(推理与规划): │
│ 目标 + 记忆 + 新观察 → 下一步做什么 │
│ ③ action(行动):调用一个工具 │
│ (检索、查数据库、搜网页、发邮件……) │
│ 工具结果回到 ①,循环,直到判定目标达成 │
└───────────────────────────────────────────────┘

图说:这就是本章主走查的骨架。书里的演示:问「GPT-2 有多少参数、
如何影响性能?」——agent 拆成两个子问题,各调一次检索工具,再汇总。

AI agent 的定义书里给得很准:以 LLM 为核心推理引擎的(半)自主软件系统; 能力来自「现场推理规划 + 实时信息工具」的组合2

2. 核心原理(一):agent 不是 LLM 时代的发明

书里给了一段简史,每个节点一句话3:

年代节点一句话
1973Actor Model(Carl Hewitt)异步消息传递的自主组件——agent 的理论起点
1980s「agent」四特征:当时公认的四个性质自主/社交/反应/主动;但符号 AI 靠手写规则驱动,系统脆弱
1990sBDI(Belief-Desire-Intention)信念-愿望-意图模型;头一批多 agent 系统
2010sSiri/Alexa自然语言接口,但纯反应式——「语音遥控器」
2022+LLM + ReAct灵活通用的推理引擎出现了;ReAct 证明 LLM 可以被 prompt 成自主循环

这条谱系的重点在最后:旧系统的智能是「programs, not learned」—— 手写规则所以脆弱;LLM 第一次提供了一个不脆的通用推理引擎4

3. 核心原理(二):三层栈

书里把 agent 系统画成三层5:

① reasoning LLM(大脑):理解意图、分解目标、规划、决策、汇总工具结果
② agent orchestration(编排层,中枢神经):接收模型的工具调用请求、
真的去执行、把结果格式化回传,驱动下一轮循环
③ tools(工具层,与世界的接口):天气/股价 API、text2SQL、RAG 查询、
网页搜索、订票发邮件等行动工具

一句要记住:「工具层的丰富与可靠,直接定义 agent 的实际能力」6。 编排层的开源生态有 LangChain、LlamaIndex、AutoGen、smolagents、CrewAI、 Pydantic AI 等7

4. 核心原理(三):单 agent 还是多 agent

书里的取舍表8:

单 agent多 agent
开销无 agent 间通信,token 省,响应快 30-50%每个 subagent 上下文更紧、更专精
适合time-to-first-token 是关键 KPI 的场景(基础客服)长程(long-horizon)任务、多种专长协作
代价能力上限complexity tax」:通信延迟、token 成本、难追踪的并发(多个任务同时进行时的) bug;出错要靠复杂追踪定位是哪个 subagent 坏的

多 agent 的两种拓扑:supervisor(主管分解任务派给专职 worker)与 collaborative(对等协作,任何 agent 决定下一个找谁,更动态也更难测)9

书里给了「什么时候才值得多 agent」的三个条件,很克制10:

  1. different security domains:敏感数据必须隔离;
  2. vast tool surfaces:工具多到「tool dilution」(工具稀释——工具太多, 模型选错或幻觉出工具);
  3. organizational boundaries:不同团队独立开发维护各自的子任务逻辑。

否则:从一个健壮、prompt 良好的单 agent 开始。 稳妥的进阶路径是 orchestrator-worker 模式:中央编排器分解任务、并行调用 subagent,subagent 之间不直接通信——可预测、上下文隔离11

5. 核心原理(四):agentic loop 与 RAG 工具的两种切法

主走查:GPT-2 论文那个问题

书里用 LangChain 搭了一个 agent,语料是 GPT-2 论文,检索包装成工具 rag_gpt_tool,大脑是 GPT-4o,按 ReAct 方式运行12:

问题:「GPT-2 有多少参数?这如何影响它的性能?」

循环第 1 轮:agent 把问题拆成两个子问题,调 rag_gpt_tool(参数量)
→ 观察:1,542 million 参数
循环第 2 轮:调 rag_gpt_tool(性能影响)
→ 观察:8 个数据集中 7 个 zero-shot(零样本:不给例子直接做)SOTA;
答对率是最小模型的 5.3 倍……
循环第 3 轮:agent 判定信息足够 → 汇总两条观察,生成最终答案

图说:经典 RAG 会对整个复合问题检索一次;agent 把它拆开、逐个检索、再综合。
这就是「检索从管线动作变成工具」的具体样子。

RAG tool vs retrieval tool

书里一个精细的区分13:

  • retrieval-as-a-tool:工具只返回文档/块,推理与综合留给 agent—— 可控、透明,适合复杂探索;
  • RAG-as-a-tool:工具内部完成检索+生成,返回带引用的有据答案—— grounding(接地)逻辑集中,一致性好,agent 侧编排少。

没有谁「更 agentic」——按职责切分选,也可以混用。

调试的要害

循环结构意味着:一次失败的 action 会级联成下一轮的 flawed observation (带错的观察)——没有插桩(instrumentation)几乎无法定位根因14。 这是第 13 章可观测性那一大节的伏笔。

6. 核心原理(五):tool calling 与两个协议

工具调用怎么工作

工具调用(tool calling / function calling)的机制:开发者用 JSON Schema (一种描述数据结构的标准格式)声明每个工具的名字、参数、描述; 模型在生成时输出一个结构化的「调用请求」而不是自然语言; 编排层看到请求、真的执行、把结果回传15

三个路标:Toolformer(Meta,2023 初:模型自学何时调哪个 API); ReAct(Google Brain:thought→action→observation 交错); OpenAI function calling(2023 年中,实用化的标志)16

书里的 get_weather 走查:用户问「What's the weather like in Oakland today?」, 模型输出 get_weather(latitude=37.8044, longitude=-122.2711) ——注意,模型自己把「Oakland」翻译成了经纬度; 编排层执行真函数拿到天气,回传模型生成自然语言答复17

工具定义的质量决定可靠性:名字要语义化——一个叫 data_lookup 的 泛型名会造成「tool confusion」(工具混淆)18。 生产风险清单:错误工具选择/参数;模型升级(同族 GPT-4→GPT-5 或换厂) 会让相同工具描述触发不同结果;要加「max turns」(最大轮数)防成本失控。 书里一句忠告:把 tool call 当「必须消毒的不可预测输入」对待19

MCP:垂直方向的协议

MCP(Model Context Protocol,模型上下文协议——一个开放协议)是标准化 「LLM 调工具、访问数据」的开放协议。它把 agent 与工具的实现细节解耦: 任何数据源经统一接口变得「agent-ready」20。三个原语:

  • tools:可执行函数——动作 + 动态读数据;

  • resources:资源——可供读取的数据层。

    每样数据用 URI(统一资源标识符——标识一个数据位置的一串字符,如 file://postgres://)来标识;长数据不塞进单个工具响应,返回 URI 让模型分开读;

  • prompts:预定义可复用的指令模板。

架构与传输:client-server 两端

架构是客户端-服务器:host(AI 应用,如 VSCode)、client(host 内的协议组件)、 server(轻量适配器——把标准请求翻成底层系统命令的中间层,比如 Text2SQL server)。

传输走 stdio(本地进程经标准输入输出——程序最基础的输入/输出通道——直接通信);

远程场景走 Streamable HTTP(通过网络远程连 server 的传输方式);认证授权刻意留在协议外,交给部署环境21

企业价值:MCP 在 agent 与企业系统之间立起一道 trust boundary(信任边界) ——治理、审计、RBAC 都有了落点;把遗留系统「包」进 MCP server, 不用颠覆性改造22

A2A:水平方向的协议

MCP 管「垂直」(agent↔工具),A2A(Agent-to-Agent)管「水平」 (agent↔agent)。每个 agent 有一张 Agent Card(数字档案:技能、 能处理的任务与数据),agent 互查卡片找能力匹配者,再发起结构化对话 委派任务。Google 与多家厂商共同开发,现归 Linux Foundation23

补充(不在书里,依据我们的协议书架):MCP 与 A2A 我们都有规范级拆解。 依据: shelf=ai-protocol-reference/mcp-spec#index.md 与 shelf=ai-protocol-reference/a2a-protocol#index.md 事实=两份拆解分别覆盖 MCP 的消息/原语/传输与 A2A 的 Agent Card/任务生命周期。

7. 作者的判断与证据

  • 「30-50% 更快」是作者方给出的经验数,无公开基准,作判断读;
  • 三条件(安全域/工具面/组织边界)是清晰的决策框架,我们认为是本章 最可带走的部分;
  • coding agent 一节的数字(McKinsey 的「常规任务时间减半」、Anthropic 「每日合并 PR 增 67%」)来自第三方与厂商自报,书里照引,我们也只照引24;
  • Andrew Ng 的判断(软件变便宜 → 「能决定造什么的人」需求上涨)是推文观点, 书里注明了出处25

8. 边界与局限

  • 书里所有 agent 代码例(LangChain/LlamaIndex/Vectara/CrewAI)都是玩具规模; 生产的一手经验在「监控防无限循环」「全链路追踪」两句忠告里,细节在第 13 章;
  • agent 在监管行业的自主性是负债:「black box」推理对合规是非启动项, HITL(人在环:不可逆动作前必须人工批准)是首选桥26;
  • MCP/A2A 都还在快速演化,书里版本是 2026 年快照。

9. 可带走的

  1. agentic RAG = 把检索降级为工具,循环(观察→推理→行动)替代一次性管线;
  2. 三层栈:大脑、编排、工具;「工具层的丰富与可靠定义 agent 的实际能力」;
  3. 默认单 agent;多 agent 只在三个条件下值得:安全域、工具稀释、组织边界;
  4. orchestrator-worker 是进入多 agent 的稳定路径;
  5. RAG-as-tool vs retrieval-as-tool 是职责切分问题,不是高下问题;
  6. 工具定义质量决定可靠性:语义化名称、精确类型、边界清楚的描述;
  7. 把 tool call 当不可预测输入消毒;max turns 防失控;
  8. MCP 管垂直、A2A 管水平;MCP 的企业价值是信任边界与遗留系统包装;
  9. 失败的 action 会级联成带错的观察——调试 agent 没有插桩等于盲调。

10. 原文地图

主题原书章原文位置
agent 简史Chapter 7text/81-ch07-chapter-7-from-rag-to-ai-agents.txt:6(搜「Carl Hewitt」) · :9(搜「ReAct」) · :12(搜「BDI」)
agentic RAG 定义Chapter 7text/81-ch07-chapter-7-from-rag-to-ai-agents.txt:35(搜「agentic RAG」)
三层栈The Agentic Stacktext/82-fm-the-agentic-stack.txt:14(搜「orchestration」)
单多 agent 取舍Single-Agent Versus Multi-Agent Systemstext/83-fm-single-agent-versus-multi-agent-systems.txt:14(搜「30–50%」) · :36(搜「supervisor」) · :42(搜「complexity tax」) · :57(搜「tool dilution」)
agentic loop 三阶段AI Coding Agentstext/87-fm-ai-coding-agents.txt:63(搜「reasoning」)
RAG tool 两种切法AI Coding Agentstext/87-fm-ai-coding-agents.txt:71(搜「RAG tool」)
调试级联AI Coding Agentstext/87-fm-ai-coding-agents.txt:85(搜「cascades」)
Toolformer/ReAct/function callingTool Callingtext/88-fm-tool-calling.txt:7(搜「Toolformer」) · :4(搜「function calling」)
get_weather 走查Tool Callingtext/88-fm-tool-calling.txt:22(搜「get_weather」)
并行调用与风险Tool Callingtext/88-fm-tool-calling.txt:68(搜「parallel」)
MCP 三原语与架构Model Context Protocol / Architecturetext/89-fm-model-context-protocol.txt:17(搜「resources」) · text/90-fm-model-context-protocol-architecture.txt:34(搜「stdio」)
MCP 企业价值MCP in Enterprise Agentic AItext/91-fm-mcp-in-enterprise-agentic-ai.txt:10(搜「trust boundary」)
A2A 与 Agent CardAgent-to-Agent Communicationtext/92-fm-agent-to-agent-communication.txt:26(搜「Agent Card」) · :16(搜「Linux Foundation」)
LangChain GPT-2 走查AI Chatbots Using LangChaintext/93-fm-ai-chatbots-using-langchain.txt:92(搜「1,542」)
LlamaIndex 三工具Document Generation Agent with LlamaIndextext/94-fm-document-generation-agent-with-llamaindex.txt:9(搜「Tavily」)
CrewAI 多 agentBuilding a Multi-Agent System with CrewAItext/96-fm-building-a-multi-agent-system-with-crewai.txt:10(搜「backstory」)

Footnotes

  1. 出处:「Retrieval Failures」第 102 段(text/62-fm-retrieval-failures.txt:102,搜「multi-hop」)。

  2. 出处:「Chapter 7. From RAG to AI Agents」第 48 段(text/81-ch07-chapter-7-from-rag-to-ai-agents.txt:48,搜「semi-autonomous」)。

  3. 出处:「Chapter 7」第 6-32 段(text/81-ch07-chapter-7-from-rag-to-ai-agents.txt:6,搜「Carl Hewitt」;:9,搜「ReAct」;:12,搜「BDI」)。

  4. 出处:「Chapter 7」第 23 段(text/81-ch07-chapter-7-from-rag-to-ai-agents.txt:23,搜「brittle」)。

  5. 出处:「The Agentic Stack」第 8-22 段(text/82-fm-the-agentic-stack.txt:14,搜「orchestration」)。

  6. 出处:「The Agentic Stack」第 22 段(text/82-fm-the-agentic-stack.txt:22,搜「tools」)。

  7. 出处:「The Agentic Stack」第 37-43 段(text/82-fm-the-agentic-stack.txt:40,搜「LangChain」)。补充(不在书里,依据我们的 frontier 书架):LangChain 的 agent 循环拆解见 shelf=ai-frontier-reference/langchain#01-agent-loop.md;CrewAI 的角色/流程模型见 shelf=ai-frontier-reference/crewai#02-crew-orchestration.md。事实=两个文件各自存在。

  8. 出处:「Single-Agent Versus Multi-Agent Systems」第 14 段(text/83-fm-single-agent-versus-multi-agent-systems.txt:14,搜「30–50%」)与第 42 段(同文件,搜「complexity tax」)。

  9. 出处:「Single-Agent Versus Multi-Agent Systems」第 36-39 段(text/83-fm-single-agent-versus-multi-agent-systems.txt:36,搜「supervisor」)。

  10. 出处:「Single-Agent Versus Multi-Agent Systems」第 45-68 段(text/83-fm-single-agent-versus-multi-agent-systems.txt:57,搜「tool dilution」)。

  11. 出处:「Single-Agent Versus Multi-Agent Systems」第 71 段(text/83-fm-single-agent-versus-multi-agent-systems.txt:71,搜「orchestrator–worker pattern」)。

  12. 出处:「AI Chatbots Using LangChain」第 4-124 段(text/93-fm-ai-chatbots-using-langchain.txt:92,搜「1,542」)。

  13. 出处:「AI Coding Agents」第 71-77 段(text/87-fm-ai-coding-agents.txt:71,搜「RAG tool」)。

  14. 出处:「AI Coding Agents」第 85 段(text/87-fm-ai-coding-agents.txt:85,搜「cascades」)。

  15. 出处:「Tool Calling」第 16 段(text/88-fm-tool-calling.txt:16,搜「metadata」)。

  16. 出处:「Tool Calling」第 7-13 段(text/88-fm-tool-calling.txt:7,搜「Toolformer」;:4,搜「function calling」)。

  17. 出处:「Tool Calling」第 22-65 段(text/88-fm-tool-calling.txt:22,搜「get_weather」)。

  18. 出处:「Tool Calling」第 16 段(text/88-fm-tool-calling.txt:16,搜「tool confusion」)。

  19. 出处:「Tool Calling」第 71-74 段(text/88-fm-tool-calling.txt:74,搜「max turns」)。「并行工具调用」(一轮调多个工具)见同文件第 68 段。

  20. 出处:「Model Context Protocol」第 4 段(text/89-fm-model-context-protocol.txt:4,搜「open protocol」)。

  21. 出处:「Model Context Protocol Architecture」第 8-36 段(text/90-fm-model-context-protocol-architecture.txt:34,搜「stdio」)。

  22. 出处:「MCP in Enterprise Agentic AI」第 8-27 段(text/91-fm-mcp-in-enterprise-agentic-ai.txt:10,搜「trust boundary」)。

  23. 出处:「Agent-to-Agent Communication」第 4-29 段(text/92-fm-agent-to-agent-communication.txt:26,搜「Agent Card」;:16,搜「Linux Foundation」)。

  24. 出处:「AI Coding Agents」第 16 段(text/87-fm-ai-coding-agents.txt:16,搜「67%」)。

  25. 出处:「AI Coding Agents」第 26-29 段(text/87-fm-ai-coding-agents.txt:22,搜「Andrew Ng」)。

  26. 出处:「AI Coding Agents」第 39 段(text/87-fm-ai-coding-agents.txt:39,搜「human-in-the-loop」)。