你大概率遇到过这种局面：想让模型自己查资料再动手干活，结果检索、工具调用、外部服务三件事搅在一起，代码越写越乱。这篇不讲概念定义，只讲三者在一条请求里谁先谁后、各自负责什么，以及按什么顺序接进来最省事；具体参数和接口字段到站内对应页面核对。
你大概率遇到过这种局面：想让模型自己查资料再动手干活，结果检索、工具调用、外部服务三件事搅在一起，代码越写越乱，排查时也说不清是哪一环出的问题。这篇不讲概念定义，只讲这三者在一条请求里谁先谁后、各自负责什么，以及按什么顺序接进来最省事。
先说一个判断：三者不是必须同时用的套装。很多人一上来就三件套全上，结果调不动还找不到原因。正确的思路是先想清楚你缺的是哪一块，缺事实就补检索，缺决策就补 Agent，缺外部服务通路就补 MCP。具体框架选型和参数字段，到站内对应目录页核对当时的资料。
先分清三件事各自管什么
| 角色 | 负责的事 | 典型失败表现 |
|---|---|---|
| RAG | 把私有资料检索出来塞进上下文 | 检索出来的片段跟问题不沾边 |
| Agent | 决定下一步做什么、什么时候停 | 来回绕圈，任务目标忘了 |
| MCP | 把外部服务按统一方式暴露给模型 | 每个工具各写一套适配，维护爆炸 |
一句话对照：检索提供事实依据，Agent 提供决策，MCP 提供手脚。缺哪个补哪个，不要一上来三个一起上。判断方法很简单：如果你的问题是「模型不知道我这份文档里写了什么」，那是缺检索；如果问题是「模型知道该查但还是不动手」，那是缺 Agent；如果问题是「每次接新服务都要重写一遍调用代码」，那才是缺 MCP。
- 检索解决的是资料不在模型知识范围内的问题，跟会不会调用工具无关
- Agent 解决的是流程编排问题，它本身不产出事实，只负责决定去取什么
- MCP 解决的是接入标准化问题，它不改变模型能力，只改变接入成本
- 三者可以单独用：只用检索能答文档问答，只用 Agent 加工具能跑任务流，单独用 MCP 也能给已有系统换接口
一条请求里它们怎么串起来
- 接收提问用户输入先进 Agent 的决策层，由它判断这个任务要不要外部资料、要不要调工具。
- 决定是否检索需要资料就走检索，把命中的片段作为上下文附上；不需要就跳过，别硬查。
- 组装上下文把检索结果和可用工具清单一并交给模型，让它同时看到依据和可选动作。
- 选择并调用工具模型选定工具后，通过统一协议去调用外部服务，拿到返回值。
- 判断是否继续拿回结果后判断任务是否完成，没完成再进下一轮，直到满足停止条件。
关键边界要记住：检索结果只是上下文，不是指令；工具返回的内容同样当数据看，别让它悄悄覆盖掉你原本设定的任务目标。这是提示注入最常见的入口。想看清某一步的实现细节，可以到 Agent 框架与 SDK 目录（/stacks/frameworks） 和 向量数据库目录（/stacks/vector-dbs） 对着挑，具体版本对比和接入方式那边有整理。
入门接入的推荐顺序
- 第一步先跑通检索：资料切好、能稳定检索出相关片段，再谈后面的决策层；资料质量差的话后面全白搭
- 第二步把工具收窄：只给 Agent 两三个必要工具，跑通再扩，工具越多模型选错的概率越高
- 第三步再引入 MCP：把已经跑通的那几个工具改造成统一协议服务，避免一开始就做协议改造
- 每步都留一条退路：某一步失败时能降级成只用检索回答，而不是整条链路一起报错
为什么建议按这个顺序？因为排查成本是递增的。检索出问题，你能直接看命中的片段对不对；Agent 出问题，你要看它每一步的决策；MCP 出问题，你要看协议和权限。越靠后的环节，出错时越难定位，所以先让前面的环节稳定下来。
什么时候不适用这个顺序
如果你已经有成熟的检索系统，只是缺工具调用通路，那直接做 MCP 接入就行，不必回头重跑前两步。反过来，如果你手上根本没有私有资料，全是公开常识类问题，检索这一步可以直接跳过，把精力放在决策逻辑和工具适配上。
踩坑最多的四处
| 坑 | 怎么提前防 |
|---|---|
| 循环停不下来 | 给步数和重试次数设硬上限，命中不到就退出 |
| 上下文被撑爆 | 检索片段条数设上限，超了先摘要再拼 |
| 工具权限过宽 | 只读的就别给写权限，该限域就别开全网 |
| 日志缺失 | 记录命中了什么、调了哪个工具、结果多大 |
日志这栏最容易被忽略，但它是排查的唯一抓手。至少要把检索命中的片段、每轮选中的工具、返回结果的大小记下来，出问题时才不用靠猜。监控哪几项指标，可以对着 评分规则（/tools/verify#scoring-rules） 想清楚，那边列了常见的观测维度，具体阈值按你业务的数字去 价格与消耗追踪（/price-watch） 核对当时的用量情况。
最后提醒一句：这三件事的边界会随着任务变化。简单文档问答不用决策层，纯工具调用不用检索，别把某一种组合当成唯一正确解。真正的判断标准是看你的失败案例落在哪一环，然后在那一环加东西。
下一步如果你已经跑通检索，想知道工具接入该怎么统一，去站内工具目录看看各类接入方式的对照，再决定要不要上协议层。→常见问题
三个都得上吗，能不能只用其中一个？
不必。只是让模型回答你文档里的内容，RAG 单独用就够；只是让模型代你点几个按钮调接口，Agent 加工具调用就行，MCP 只是让工具接入更省事的可选做法。三个一起上是复杂度成本，只有当任务既需要私有资料、又需要多步决策、还要接多个外部服务时才划算。
MCP 和普通 API 调用有什么区别，非要用 MCP 吗？
普通 API 调用是你自己写适配代码，一个服务一套逻辑；MCP 是把这些适配统一成一种描述方式，客户端换个服务不用重写。如果你只接一两个自家接口，直接写 API 调用更直接；工具数量多、要跨客户端复用时 MCP 才体现价值。具体差别可以对照 MCP 服务器大全（/mcp） 里现成的服务看。
怎么判断是检索的问题还是 Agent 的问题？
把 Agent 摘掉单独测检索：给同一个问题，看检索出来的片段里有没有答案。有答案但最终回答不对，问题在生成或拼装；检索里就没答案，那先回去修分块和召回，别急着调 Agent 的提示词。这条排查顺序能省掉大量瞎改的时间。
