做 Agent 选型时最容易卡住的一步：模型明明能调工具、能查数据库，为什么还要再套一层 RAG？反过来，知识库已经建好了，是不是非得塞进 Agent 里？这篇不讲原理，只讲判断：RAG 在智能体里承担的职责、它和能力扩展手段的边界、以及选型时该看哪几项工程指标。
做 Agent 选型时最容易卡住的一步：模型明明能调工具、能查数据库，为什么还要再套一层 RAG？反过来，知识库已经建好了，是不是非得塞进 Agent 里？先把结论说前面：RAG 在智能体里不是万能插件，它只解决一类问题——决策需要外部、非结构化、变化不快的资料。不符合这个前提，加检索层基本是给自己找延迟和故障面。
这篇不讲向量原理，只讲判断。先看 RAG 在智能体里到底承担什么职责，再看它和工具调用、能力扩展手段的边界，最后给一份落地前必须定的清单，以及什么情况下这个选型根本不成立。看数字、看各家实现口径的，直接到站内对应页面核对当时的版本和参数，别信任何写死的结论。
RAG 在智能体里不是外挂，是给决策提供事实底座
普通问答里的 RAG 只负责「查完塞进上下文」，一次检索换一段回答，链路是线性的。智能体里不一样：检索结果会参与「下一步做什么」的判断，直接影响工具选择和参数填写。同样是查一段内部规范，问答模式只关心答案对不对，智能体模式还要关心「查到这条之后该不该调审批接口、参数按哪套字段填」。
区别在调用时机。问答是被动触发一次检索；智能体可能是先检索再决定调哪个工具，也可能是工具执行失败后回检索找原因。这意味着检索不是一个固定前置步骤，而是一个可以被决策过程反复调用的动作。如果你的框架只支持「每轮固定预检索」，复杂一点的任务里它会拖慢所有链路。
- 选型第一个要问的不是「用哪家向量库」，而是「这个任务的决策依据是不是外部资料」；依据全在 API 返回值里，检索层帮不上忙
- 决策依据是外部资料，但资料是实时的、结构化的、以数值为主，优先考虑工具调用而不是检索
- 决策依据是人写的文档、规范、话术、历史记录，且变化频率不高，这才是检索的主场
- 两者都存在时，先分清哪些字段必须精确、哪些只需要背景解释，这决定了两条路各自的边界
和工具调用、MCP 的职责怎么分
一条简单的分法：需要「读到人写的、变化不快的资料」走检索；需要「拿到实时的、结构化的、可执行的结果」走工具调用。库存数、账户余额、订单状态这类必须走工具，制度文档、客服话术、产品说明这类走检索。分不清时，问一句「这个值会不会在一分钟内变」，会变就走工具。
| 需求特征 | 走检索 | 走工具调用 |
|---|---|---|
| 数据类型 | 文本、半结构化文档 | 结构化字段、数值、状态 |
| 时效要求 | 分钟到天级可接受 | 秒级、必须实时 |
| 返回形式 | 自然语言片段 | 确定的值或可执行结果 |
| 失效后果 | 答得不够准，可人工兜底 | 算错就是错的，必须精确 |
| 典型场景 | 规范、话术、历史记录 | 账户、库存、下单、审批 |
两者常同时出现，边界在于谁来兜底：工具给你准确数值，检索给你背景和解释。混在一起最容易出的问题是模型拿旧文档里的数字当真——文档里写过「默认额度是某个值」，接口返回了另一个值，模型选了文档。规避办法是要求所有数值类结论必须来自工具返回，检索结果只作为解释性文本，不参与数值决策。
选型时要确认框架是否支持「检索作为一个工具」被调用，而不是框架强制每轮都预检索。强制预检索在简单任务上是纯开销：明明不需要资料的轮次也去查一遍，延迟白涨。拿不准时先看站内 /stacks/frameworks 里的框架能力说明，再对比 /stacks/agent-apis 看工具侧接口够不够用；具体能力口径以这些页面当时的记录为准。
落地前必须定的四件事
- 定超时预算检索和模型生成通常共用同一个请求超时，检索慢会把模型逼到截断。先用 /tools/speed-test 量出你这条链路的延迟基线，再把预算拆开：检索占多少、生成占多少，超时触发后走哪条分支。
- 写死降级路径检索挂了、向量库连不上时，是退回纯模型回答、还是直接报错拒答，必须在代码里显式写死。靠框架默认行为，线上表现会随版本变化，排查时找不到原因。
- 补齐日志字段至少要能复盘「这一轮检索召回了什么、模型最终引用了哪条」。没有这个，线上答错时无法区分是召回问题还是生成问题，只能靠猜。
- 准备评测集挑一小批真实问法，改切分或换嵌入模型后跑一遍，看命中变化。嵌入模型口径可以到站内 /embeddings 对照，具体参数和当时的榜单数字去那个页面核对。
什么情况下这个选型不成立
下面几种情况，先别上检索层，省下来的时间用在进料清洗或直接写死逻辑上更划算。判断标准只有一个：加这层之后，任务的失败率和延迟有没有变好。没变好就是浪费。
- 资料量很小（几十页以内）且很少更新：直接整段塞进上下文更省事，维护一套索引的收益为负
- 答案必须百分百可追溯且不允许改写：更适合走结构化查询，语义检索的相似度机制天然会带进近似内容
- 文档以扫描件、表格、流程图为主：进料清洗成本会远高于检索本身，先解决解析再谈智能体
- 团队没有人力维护索引更新：知识库会腐化，没人管的话召回质量随时间下滑，不如先不做
- 任务本身靠模型常识或纯计算就能完成：硬加检索层只会增加延迟和失败面
还要提醒一个容易被忽略的不适用场景：当「检索不到」本身就是有效答案时，检索层的默认行为往往相反——它总会返回几条最相似的，哪怕相关性很低。这种情况要在流程里显式加阈值和拒答分支，否则模型会把无关内容当成依据。
下一步把上面四件事对应到你手上的框架和接口上，先跑一遍延迟基线，再决定要不要上检索层。→常见问题
有了 RAG 是不是就不需要工具调用了？
不是，两者解决的不是同一个问题。检索负责把外部资料找出来当参考，工具调用负责真正去执行动作、拿实时数据。智能体里常见的是先检索定位背景、再调工具处理具体对象，缺哪一个都会让任务做不完整。
智能体里的 RAG 和普通问答的 RAG 差别在哪？
主要差别是触发方式和用途。普通问答基本是问一次查一次，检索结果直接喂给模型生成答案；智能体里的检索可能要反复触发，结果用来决定下一步调哪个工具、传什么参数，所以对召回的准确度和延迟都更敏感。
怎么判断检索这一层到底有没有提升效果？
别只看感觉。挑一批你业务里真实的问题，固定模型和提示词，分别跑一次「带检索」和「不带检索」，人工看答案是否引用了正确资料。改完切分或换嵌入模型后重复同一批问题，看变化方向，而不是看单次回答好不好。
