RAG 做成固定链路、流程节点还是 Agent 工具，区别在哪？
简化版
区别在于谁决定「查不查、查什么、查几次」。固定链路里是代码决定：每次提问都检索一次，用原问题检索，行为和成本都可预期，适合问答入口单一的知识库和客服。流程节点里是编排者决定：检索放在流程的某个位置，查询词从流程上下文里取，结果写回上下文给下游节点引用，适合审批、工单处理这类步骤固定的业务流程。Agent 工具里是模型决定：它在推理循环里判断需不需要查、用什么词查、要不要换个词再查，最灵活，但步数和成本不可控，必须有调用上限、空转检测和过程留痕。三种方式可以复用同一套检索实现，差别只在控制权交给谁。
详细版
| 维度 | 固定链路 | 流程节点 | Agent 工具 |
|---|---|---|---|
| 谁决定检索 | 代码，每次必查 | 编排者，在流程里放位置 | 模型，按需调用 |
| 查询词从哪来 | 用户原问题 | 流程上下文里的某个变量 | 模型自己生成 |
| 检索次数 | 1 次 | 流程里放几个节点就几次 | 不固定，可以换词重查 |
| 结果去哪 | 直接拼进 Prompt | 写回上下文变量，下游节点引用 | 作为观察结果回到推理循环 |
| 成本可预期 | 高 | 高 | 低 |
| 需要的护栏 | 阈值、拒答 | 空查询兜底、变量校验 | 调用上限、空转检测、过程落库 |
| 适合 | 知识问答、客服 | 固定步骤的业务流程 | 需要多步取证、边查边判断的任务 |
固定链路：问题 → 检索 → 拼 Prompt → 生成
流程节点：[开始] → [知识检索节点] → context.knowledgeContext → [LLM 节点引用 {knowledgeContext}] → …
Agent： 思考 → 调知识检索工具(query=…) → 观察 → 思考 → 再调别的工具或换词重查 → … → 最终回答完整版教学
一、同一套检索，三种控制方式
先把「检索实现」和「检索控制」分开。检索实现包括向量化、候选收窄、相似度计算、取 topK，这部分三种方式完全可以共用。区别在控制层：
检索实现（共用）：search(query, scope, topK) → 片段列表
控制层（三选一）：
固定链路：代码每次都用用户原问题调一次 search
流程节点：流程执行到这个节点时，从上下文取变量调 search
Agent 工具：模型决定何时调、传什么 query这样设计的好处是检索质量只需要维护一处，调试页面、流程节点、Agent 工具看到的检索结果完全一致。
二、固定链路：可预期是最大的优点
每次提问都检索一次，检索参数固定，结果直接进 Prompt：
| 优点 | 局限 |
|---|---|
| 行为可预期：同样的问题走同样的步骤 | 每次都检索，闲聊类问题也会查 |
| 成本可预期：一次向量化 + 一次生成 | 只用原问题查，多轮追问的指代要额外处理 |
| 易于调试：出问题只看检索结果和 Prompt | 一次查不到就结束，不会换个问法再查 |
知识问答、客服这类「用户问、系统答」的场景，固定链路通常就够了。与其换成 Agent，不如先把阈值、拒答、引用做扎实。
三、流程节点：检索是流程里的一步
在工作流里，检索和「生成回复」「调用接口」「条件判断」一样是一个节点。节点配置通常包括：
{
"knowledgeBaseId": 1,
"queryKey": "customerQuestion",
"topK": 5,
"outputKey": "knowledgeContext"
}执行时从上下文取 customerQuestion 作为查询词，检索结果拼成一段文本写回 knowledgeContext，下游 LLM 节点的 Prompt 里写 {knowledgeContext} 引用它。
流程节点的关键点：
- 变量名要能对上：上游没产出
customerQuestion，检索节点就拿到空查询。要规定空查询时的行为（报错，或按默认排序返回前几条并标明不是检索结果）。 - 结果格式要稳定：下游节点按固定格式引用，拼接格式（如每条「【标题】内容」）不能随意变。
- 可以预览：配置流程前先用同一个检索接口试一下这个问题能不能召回想要的片段，再去连节点。
记忆钩子：固定链路是「每次都查」，流程节点是「在这里查」，Agent 工具是「需要时查」。
四、Agent 工具：模型决定查不查、怎么查
把检索包装成工具交给 Agent：
{
"name": "knowledge_retrieve",
"description": "按问题检索医学知识库，返回相关的指南片段、标题和相似度。需要判断症状对应科室或就诊建议时使用。",
"parameters": { "query": "检索问题", "kbId": "知识库ID，可选", "topK": "返回条数，默认 5" }
}模型在推理循环里可以做到固定链路做不到的事：先查症状标签，再用标签里的关键词查指南；第一次查询结果不理想，换个说法再查；判断不需要知识时直接跳过。代价是：
| 风险 | 护栏 |
|---|---|
| 反复调用同一个工具 | 同一工具 + 相同入参连续 N 次判为空转，终止 |
| 调用次数失控 | 单次运行的工具调用总次数上限 |
| 过程是黑盒 | 每次工具调用落一条步骤记录：工具、入参、返回、耗时 |
| 工具说明写得含糊 | 说明要写清「什么时候用、返回里看什么」，并且能在后台修改后立即生效 |
空转检测要比对入参：换一个词重新检索是有意义的探索，只有同样的参数反复调用才是空转。
五、工具返回给模型的内容怎么定
作为工具时，检索结果要作为「观察结果」回到模型的上下文，有几个取舍：
- 片段完整返回：模型要据此做判断，截断的片段可能丢掉关键条件；
- 带上来源和相似度：模型可以引用来源，也能看出命中是否可靠；
- 控制条数：返回太多会挤占上下文，默认 5 条左右，允许模型在需要时调大。
六、怎么选
入口单一、每次都要依据知识回答 → 固定链路
业务步骤固定、检索只是其中一步 → 流程节点
需要多步取证、要根据中间结果决定下一步查什么 → Agent 工具三者也可以组合：Agent 内部调用的某个工具本身就是一条固定的检索链路；工作流里的某个节点可以是一个小型 Agent。关键是把控制权交给真正需要做判断的一方：能用规则定下来的，就不要交给模型。Agent 怎样判断证据够不够、什么时候停止检索，见「Agentic RAG 与普通 RAG 有什么区别？如何决定继续检索还是停止？」。
七、观测要跟着控制方式走
三种方式需要记录的东西不同：
| 方式 | 至少要记录 |
|---|---|
| 固定链路 | 问题、命中片段与相似度、最终回答 |
| 流程节点 | 每个节点的输入、输出变量、耗时 |
| Agent 工具 | 每一步的工具、入参、返回、耗时，以及整次运行的步数和终止原因 |
越是把控制权交给模型，越需要完整的过程记录，否则出了问题无法复盘「模型当时看到了什么、为什么这样查」。
八、常见误区与追问
- 误区：Agent 工具一定比固定链路高级。 多数知识问答每次都要查一次，固定链路更稳、更便宜，Agent 适合需要多步取证的任务。
- 误区：三种方式要写三套检索代码。 检索实现可以共用，差别只在控制层。
- 误区：流程节点拿到空查询时照常检索。 要明确空查询的行为，否则下游拿到的是不相关的内容。
- 误区：Agent 重复调用检索工具就是空转。 换词重查是有效探索，只有相同入参反复调用才是空转。
- 误区：工具返回的片段越短越省 Token。 截断会丢掉判断依据，片段要完整返回，用条数来控制总量。
- 追问：为什么工具说明要能在后台修改？ 模型是否调用工具只看说明文字，说明含糊就会漏调或错调，需要改完立即验证。
- 追问：怎么保证调试时看到的检索结果和运行时一致？ 预览页面和节点、工具调用同一个检索接口。
九、加强记忆
三种接入方式的区别是控制权：固定链路由代码每次必查，可预期、易调试，适合问答和客服；流程节点由编排者决定位置，查询词取自上下文变量，结果写回变量给下游引用，要处理空查询和格式稳定；Agent 工具由模型按需调用、可以换词重查，最灵活但要有调用上限、比对入参的空转检测和逐步落库。检索实现三者共用，预览和运行走同一接口。按任务选：每次都要查用链路，固定步骤用节点，多步取证用工具，能用规则定的不交给模型。
项目实战落地
项目里怎么做的
《AI Agent 智慧医院智能导诊就诊系统》把医学知识检索做成分诊 Agent 的一个工具：
- 工具注册在表里：
medical_knowledge_retrieve登记在mcp_tool表，入参说明为「知识库 ID、检索问题、返回条数」；每次分诊前按启用状态查表构建工具池，停用后模型真的调不到； - 复用同一套检索：执行器把参数翻译成检索请求，调用知识库页面用的同一个
search（同源向量化 → 按知识库收窄 → 内存算余弦 → 取 topK），缺query直接报错，topK默认 5；命中片段以标题、完整正文和相似度返回给模型，正文不截断； - 模型决定调不调：分诊 Agent 在 ReAct 循环里和患者档案、症状标签、科室、排班等工具一起选择调用顺序；
- 护栏与留痕：工具总调用次数上限 20 次，同一工具携带相同入参连续 4 次判为空转；每次调用写
agent_step和mcp_tool_call_log。
《AI企业流程编排系统》用的是流程节点：知识检索节点配置知识库、查询变量名和 topK，执行时从上下文取查询词，命中片段拼成「【标题】内容」写回 knowledgeContext，下游 LLM 节点引用；知识片段页的检索预览和节点走同一个接口。
为什么这样取舍
- 分诊用工具：一次分诊要读档案、查症状标签、查科室和排班，要不要再查指南、用什么词查，取决于前几步拿到了什么，写不成固定顺序。
- 流程编排用节点：业务流程的步骤由人配置，检索放在哪一步是编排决定的，结果要作为变量供后面的节点使用。
面试官还会追问
- 模型调用知识库检索工具时传了 topK=50、或者没传知识库 ID，工具实际会怎么检索？
- 被检索的知识库还一条向量都没生成时，分诊 Agent 调用这个工具会发生什么？
学完《AI Agent 智慧医院智能导诊就诊系统》，上面这些追问你都会迎刃而解。