刚接触 AI 应用的人最容易卡在这一步：手上有一堆资料要问答，又在别处看到 Agent 能自己调工具、自己决定下一步，于是不知道项目该往哪边搭。也有人反过来，明明只是查文档，却硬套一个多步智能体循环，结果又慢又贵还不好调。这篇按工程视角把两者的职责边界拆开，给出判断清单、混合做法的落地顺序和不适用的情况。
刚上手的时候，最容易把这两件事搅在一起。手上的场景明明就是一堆内部文档要问答，却在别处看到 Agent 能自己调工具、自己决定下一步，于是犹豫要不要直接上智能体；反过来也有，明明是一件事要跨好几个系统分步做，却硬套一条检索链，结果怎么调都不对。
这篇按工程视角把两者的职责边界拆开：它们各自在解决什么问题、输入输出的形状差在哪、怎么用一张清单判断自己该往哪边搭，以及两个一起用的时候先做哪一步。判断类的内容都会写清什么情况下不适用，方便你对着自己的项目排除。
先分清它们各自在解决什么问题
把两者当成两类不同的活儿来看，会清楚很多。检索增强管的是「模型不知道你私有资料」这一件事，它的核心动作是查，查出相关片段再交给模型组织语言，最后吐出来的还是一段回答。智能体管的是「一件事要分好几步做、中间还得看情况改主意」，核心动作是决策加调用工具，最后交出来的可能是查到的结论，也可能是改完之后的状态。
- 流程画出来是一条直线，从问题到检索到回答，多半是检索增强的活
- 流程画出来有分叉、有回头箭头，比如查完发现信息不够要再查一次，多半需要智能体
- 两者不互斥，检索本身就完全可以被包装成智能体手里的一个工具
- 别一上来就选边站，先把「谁做决策、谁只负责取数」这个问题回答清楚
从输入输出的形状上看差别
形状的差别直接决定了你后面怎么记日志、怎么估成本。检索增强这一路，输入通常就是一个用户问题，输出是一段带依据的回答，中间基本只有一次检索；智能体这一路，输入是一个目标，输出是若干次工具调用之后的结果，中间走几步事先说不准。
| 对比项 | 检索增强 | 智能体 |
|---|---|---|
| 输入 | 一个具体问题 | 一个目标，可能很模糊 |
| 输出 | 带依据的一段回答 | 多次工具调用后的结果 |
| 中间步数 | 基本固定，通常一次检索 | 不确定，取决于模型判断 |
| 日志重点 | 召回了什么、命中没命中 | 每一步为什么这么走、工具返回了什么 |
| 延迟与成本 | 相对可预估 | 随步数放大，波动大 |
表格里最需要先接受的是最后一行。不确定步数意味着延迟和成本都不可预估，如果你连「这一步为什么被调用」都还没法记录，那说明日志基础还没打好，选型要往后放一放。
一张判断清单：你的需求属于哪一类
下面这几条可以直接对着自己的需求勾。勾中的条数越多，方向越明确；如果两边都勾中，那就是要做结合，而不是二选一。
| 你的情况 | 建议方向 |
|---|---|
| 问题只依赖已有文档，答案有明确出处 | 检索增强 |
| 需要查数据库、调外部接口、改状态（下单、建单、发消息） | 智能体 |
| 既要查私有资料，又要动手改东西 | 两者结合，把检索做成工具 |
| 要求快、一次搞定、不允许多花时间 | 不建议上智能体循环 |
| 合规要求每一步可解释可审计 | 智能体步数要设上限并留完整日志 |
注意最后两行是「否决项」而非「加分项」。它们不是让你换个方案，而是直接排除了某条路，先把它们过一遍能省掉很多返工。
判断口诀：只查不改，先想检索；要动手改状态，再考虑智能体。
什么时候不该上 Agent
新手最常见的过度设计，就是给一个本该一条直线跑完的流程套上循环。以下几种情况，绕开智能体反而更稳、更好调、更容易向别人解释。
- 流程本身固定、分支可以写死，用普通代码加一次模型调用更省事，也更好复现
- 资料量不大、问题集中在少数几篇文档，直接把内容塞进上下文，可能比搭整套检索链路更简单
- 团队还没有日志和评测基础，先把召回的准确率和漏召回摸清楚，比急着搭循环更划算
- 对延迟极敏感的场景，多轮工具往返通常撑不住，用户等不起
- 每一步都要人工确认才能继续的场景，硬做自动循环只会制造麻烦
不适用的情况也要说清：如果你的需求里确实存在「必须先看结果才知道下一步做什么」的环节，那前面这些理由都不成立，该上智能体还是得上，只是要把步数上限和超时先定好。
什么时候光靠 RAG 会卡住
反过来，如果你的场景里出现下面这些信号，说明只做一次检索是覆盖不了的，需要引入决策那一层，或者至少要把检索之外的动作补上。
- 答案需要跨系统取数，文档里写了规则，但具体数字在另一个业务系统里
- 同一轮对话里要先查、再算、再写回，这种链路一次检索覆盖不了
- 用户问题本身需要澄清或反问，这属于决策行为，不是检索行为
- 资料更新频繁且要求实时，检索链路的索引刷新节奏跟不上
- 同一个问题在不同条件下要走完全不同的取数路径，写死分支会越来越臃肿
还有一类容易被忽略：问答本身没问题，但用户期待的是「帮我把这事办了」，比如查完政策直接帮忙提交申请。这时候检索只是链路里的一环，主体已经是智能体了。
两个一起用时的落地顺序
确定要结合之后，顺序比技术选型更重要。按下面这几步走，能让每一层都能单独验证，出问题也知道卡在哪。
- 先把检索做成独立可测的工具输入一个问题，输出相关片段，单独跑一轮评测。这一层没过关之前不要往下走，否则后面所有问题都会混在一起看不清。
- 给工具定义清晰的入参和返回结构别让模型猜字段名和格式，明确写清参数含义、返回哪些字段、空结果怎么表示。
- 再搭循环允许模型自己决定何时检索、检索几次，把决定权交给它，而不是在代码里写死调用次数。
- 加约束最大步数、单次工具超时、整轮成本上限都要设，超了就按预设的降级路径返回一个保守结果，而不是无限重试。
- 补日志每一步的输入、工具名、返回摘要、耗时都落盘，这是后面排查和优化唯一的依据。
实际做的时候，前三步可以并行推进，但第四步的约束一定要在正式上线前落地。约束不是限制能力，是让你在出问题时还知道怎么停。
成本、延迟和日志这三件事怎么管
检索这一步本身多出来的是几次调用加一次向量查询，延迟相对好估；智能体的延迟会随步数成倍放大，这是两套完全不同的账。算账时别凭印象，具体单价换算到站内的 模型成本计算页（/tools/model-cost-calculator） 核对当时的数字。
| 要管的事 | 做法 | 验证方式 |
|---|---|---|
| 成本 | 按请求记录 token 与工具调用次数 | 把一轮会话的总消耗打出来看 |
| 延迟 | 分步埋点，记录每一步耗时 | 能回答「慢在哪一步」 |
| 日志 | 记录输入、工具名、返回摘要、耗时 | 随机抽一条会话能完整复现路径 |
| 预算 | 给每次会话设总上限，到点截断 | 构造一个会触发的用例看行为 |
预算这件事值得单独说一句：事后对账永远不如事前截断有用。设一个总数，到了就返回当前已有的最好结果，比让它在后台一直转下去要划算。
怎么验证你做对了
两边的验证目标不一样，别用同一套指标去卡。检索侧看的是「该出现的有没有出现」，智能体侧看的是「该走的路径有没有绕远」。两边都要单独准备一小批固定用例。
- 检索侧测召回：拿一批已知答案的问题，看正确答案是否被召回进前排
- 智能体侧测路径：给定目标，看它选的工具顺序是否合理、有没有不必要的往返
- 两边都要测失败情况：检索不到时怎么答、工具报错时怎么退
- 准备一小组固定用例，每次改动都跑一遍对比，别只看单次演示效果
- 把失败用例也留档，它们往往比成功用例更能说明系统边界
验证这一步不用一开始就做得很重。一条先跑通、能对比、能看出退步的最小用例集，比一套还没用起来的评测框架更有价值。
下一步如果你还在犹豫该按哪条路搭，可以先到工具目录里把检索侧和智能体侧常用的组件过一遍，看清楚每一层各自要准备什么，再回来对着上面的清单勾。→常见问题
只用 RAG 不用 Agent，能算智能体吗？
不算。RAG 是一条固定的检索加生成链路，每一步都由你的代码决定。智能体的关键特征是模型自己决定下一步做什么。如果你的流程里没有「模型选择动作」这个环节，那它就是一条检索管线，叫它 Agent 只会让沟通变混乱。
只用 Agent 不做检索，能回答私有资料吗？
能，但要看你把资料放在哪。如果资料能被包装成一个查询工具（比如数据库、内部搜索接口），Agent 通过调工具就能拿到。差别在于你要自己维护那个查询入口，而不是靠向量检索自动匹配语义相似度。
两个都上会不会太复杂，小团队扛得住吗？
可以分阶段上。先把检索做稳、评测跑通，再在它外面加一层工具调用循环，出问题时也容易定位是检索不行还是决策不行。一上来就做完整的智能体加检索，调试成本会翻倍。
怎么判断我的问题到底需不需要多步？
拿十个真实问题手写一遍理想流程。如果每个问题都是一问一答、不需要中途换动作，就不需要多步。超过一半的问题需要先查A再查B再算，才值得上循环。这个判断比看别人的架构图靠谱。
混合方案里，检索结果要不要全部塞给模型？
不必。先按相关度取一个较小的集合，再让模型决定要不要继续检索。一次塞太多会挤占上下文、拖慢响应，也更容易让模型忽略关键段落。具体留几条，取决于你的文档颗粒度和问题类型，可以拿评测用例试出来。
