what is a rag based agent

搜 what is a rag based agent 的时候，多半是你已经知道 RAG 能查资料，但看到「RAG Agent」「MCP」这些词就懵了，不知道哪个是模型、哪个是框架、哪个只是接口约定。这篇不堆概念，先把三个词各自的边界划清楚，再给你一套判断顺序：什么场景只要检索就够、什么场景得让模型自己决定调几次检索、什么场景用现成协议接工具更省事。

搜 what is a rag based agent 的时候，多半是你已经知道 RAG 能查资料，但看到「RAG Agent」「MCP」这些词就懵了，不知道哪个是模型、哪个是框架、哪个只是接口约定。先把最容易混的一点说清楚：这三个词并不在同一层。rag 模型讲的是参与检索增强的模型分工，RAG Agent 讲的是控制流程怎么走，MCP 讲的是外部工具怎么接进来。混着理解，选型时就会拿接口约定去比较模型能力，越比越乱。

下面按「先分清三个词、再判断要不要上 Agent、然后看循环里必须定哪些参数、最后过一遍上线检查表」的顺序写。你如果只想知道结论：资料单一就老老实实做固定流程的 RAG，多跳任务再让模型自己编排检索，接现成系统时优先用现成协议而不是自己造一套调用格式。具体到各家模型和工具的价格、能力差异，到站内的资料库和价格追踪页核对当时的数字，这里不写死。

三个词各指什么：rag 模型、RAG Agent、MCP

rag 模型不是一个具体产品的名字，而是一类用途的统称。一套检索增强链路里通常不止一个模型：嵌入模型把文本变成向量存进检索库，重排模型把召回的候选片段重新排序，生成模型拿着排好的片段写答案。有时候前两个环节合成一个服务，有时候分开部署。所以你问「rag 模型是哪个」，正确答案是「看这一段用在哪一环」，而不是某个固定名字。到站内的模型资料库翻一下，能看到各家在这些环节上的定位差别。

基于 RAG 的 Agent 则完全是另一回事，它描述的是控制方式。固定流程的 RAG 是一条直线：先检索、再拼上下文、再生成，每一步顺序写死。RAG Agent 把检索包成一个工具交给模型，模型在循环里自己决定要不要查、查几次、第一次结果不够要不要换个关键词再查。区别不在用了什么模型，而在「谁决定下一步」。

MCP 是模型和外部工具之间的连接约定。检索器、数据库、内部工单系统，都能按这套约定包成一个服务暴露出去，模型侧用统一方式调用。它解决的是「怎么接」，不解决「检索质量好不好」。接得再规范，切片切得乱七八糟，召回照样是废的。三者关系可以这样对照：

什么情况只做 RAG 就够，什么情况才上 Agent

判断标准很朴素：看你的问题是不是落在一批资料里、一次召回能不能覆盖。如果用户问的都在同一份文档集或同一张表里，一次检索基本能拿到足够上下文，那固定流程的 RAG 更稳，也更好排查——出错时你知道是召回错了还是生成错了，链路只有一条。硬塞一个 Agent 进来，只会多出几轮不可控的工具调用，延迟和费用一起涨，问题定位还更难。

什么时候值得让模型自己编排检索？典型特征是任务需要多跳：先查一个东西，拿结果去查第二个数据源，中间可能还要算一下再回头补查。这类任务写死顺序很难覆盖所有分支，让模型在循环里决定反而更实际。另一个信号是数据源本身就有多个，用户一句话可能要落到文档库、工单系统、结构化表里，硬编码路由规则会越写越臃肿。

• 资料单一、问题集中：固定流程 RAG 就够，别加 Agent
• 需要跨多个数据源取数：考虑让模型编排工具调用
• 需要先查再算再查的多跳任务：Agent 的循环更合适
• 资料本身没整理干净、切片和字段是乱的：先做进料质量，换 Agent 也救不回来
• 调用预算和延迟卡得死：Agent 的轮次不可控，先估算再决定

要特别注意不适用的情况。很多人以为答案不准是因为没上 Agent，实际上问题出在数据侧：文档没清洗、表格字段命名混乱、切片把一句话拦腰截断。这种时候上 Agent 只会让模型多查几次同样烂的数据，输出照样不对，还多花了几轮调用。先把进料质量做上去，再谈编排。

把检索嵌进工具调用循环：几个必须定的参数

决定上 Agent 之后，最先要定的不是提示词，而是几个硬约束。第一个是最大调用轮数：不给上限，模型容易反复查同一件事，一轮接一轮，延迟和费用都失控。按任务复杂度设一个合理上限，超了就返回当前最好结果并说明信息可能不全。第二个是单轮返回条数上限：条数太多会挤爆上下文，还会稀释真正有用的片段。

第三个是工具描述本身。模型靠这段文字决定要不要调检索、用什么词调。描述里要写清楚这个工具覆盖哪些资料、什么样的关键词命中率高、什么内容它查不到。描述写得含糊，模型就会在不该查的时候查、该换关键词的时候死磕原句。第四个是返回值里带来源标识，方便在答案里标出处，也方便出问题时回查是哪一段召回错了。

最大调用轮数

给模型反复查同一件事设硬上限，超限就返回现有结果并说明信息可能不全

单轮返回条数

控制塞进上下文的片段数量，太多会稀释关键信息，太少可能覆盖不全

工具描述

写清覆盖范围、高命中关键词和查不到的内容，模型靠它决定调不调

来源标识

返回值带片段出处，便于标注引用和事后定位是哪一段召回出了错

1. 先设轮数和条数上限把最大调用轮数和单轮返回条数写进工具配置；用一个多跳问题跑一遍，看模型实际调了几轮、有没有重复查同一句话
2. 再打磨工具描述拿几条真实问题试，观察模型是否在合适的时机调检索；如果它该查不查或该换词不换，先改描述而不是改提示词主段
3. 最后加来源标识在返回值里带上片段出处，生成答案时要求标注；抽查几条回答，确认标出来的出处确实支撑了对应结论

上线前对照表：五件事逐条过

链路跑通不等于能上线。下面这几项建议逐条过一遍，缺哪个补哪个。重点是先保证出问题时你能看见、能兜住，再谈效果优化。

超时和降级是最容易漏的两项。检索和生成要分别设超时，不要图省事用同一个值——两者耗时特性完全不同。检索服务挂掉的时候，要有兜底回答或降级到纯生成，而不是让整个链路直接报错给用户看。日志至少要留下查询原文、命中片段标识、模型调了几轮工具这三样，缺任何一项，事后复盘基本靠猜。

评测这一项值得单独说：攒二十来条真实问题当固定用例，每次改切片、改工具描述、改提示词之后跑一遍对比。别看单次体感，体感会被最近一次成功回答带偏。这五项里没有一项依赖你选了哪个模型，换模型之前在工程侧补齐，收益更确定。