Q31 · RAG 应该如何接入 Agent 执行链路？

客服收到一句话：“订单 A123 的耳机已拆封，签收 10 天后有杂音，能退吗？”大模型可以理解问题，却看不到这笔订单的真实签收日，也不知道当前适用哪一版售后政策。让它直接回答，容易把一般常识当成这家商店的规则。应用需要先查订单、再找政策证据，最后根据两者答复。

RAG（Retrieval-Augmented Generation，检索增强生成）负责“从资料中找证据并交给模型”；Agent 则可以在执行过程中，根据已查到的事实选择要不要检索、检索什么、证据不够时是否补查。程序仍负责实际调用、权限与停止条件。LangChain 的 RAG Agent 教程展示了把检索能力接入 Agent，并在检索内容不合适时改写问题再检索的模式；Anthropic 的工程说明把“模型依据反馈选择工具并继续执行”作为常见 Agent 运行方式。下面用框架无关的接口草图说明，不依赖某个具体 SDK 版本。

术语和例子中的名字

词或名字	直白解释	A123 例子中的对应物
大语言模型 / LLM	根据当前输入生成文字，也能按工具约定提出调用请求的模型	读懂客服问题、提议查订单和政策
Agent	在受控范围内依据中途结果选择下一动作的应用	查到 A123 的签收日后决定查适用政策
RAG	先检索资料，再把取回内容交给模型生成回答	从售后政策库找出相关条款
检索器	接受查询词并从索引中找候选资料的程序	在政策索引里找退货和质量问题条款
索引 / 块	索引是可搜索的资料集合；块是被索引的文档片段	V2 政策中每条完整的售后规则
工具 / Tool Calling	模型提出工具名和参数，应用校验并实际执行，再把结果回送模型	search_policy 搜索政策并返回条款
查询词 / query	发给检索器、描述需要找什么的文本；不等于必须照抄用户原句	“耳机无理由退货的签收期限和拆封条件”
召回	目标证据是否出现在取回的候选中	是否找到了 7 天条件、30 天检测和拆封例外
引用 / 来源	答案所依赖的具体文档、版本、章节及原文位置	《耳机售后政策》V2 第 1、2、3 条
会话身份	应用已经验证的当前登录者；不能仅靠用户聊天自报	登录用户 u7
order_id	查订单的输入编号	A123
status	工具执行状态；要区分成功但没有命中、超时和无权访问	ok、no_hit、timeout、forbidden
hits	检索返回的候选块列表	三条 V2 政策证据
chunk_id / source_uri	块的稳定编号 / 可回查原文的位置	V2-1 / 内部政策库 V2 第 1 条

模型可以决定提出调用 search_policy，但不能因为它提出了“查所有内部政策”就自动获准。u7 的身份、订单归属、文档权限和有效版本由应用或检索服务核验。Azure AI Search 的文档级访问控制说明明确把权限过滤放在查询时；这里采用的是同一个安全原则，不要求使用 Azure 的具体产品。

先固定事实，避免回答时换口径

以下订单和政策均为虚构教学数据。假设今天是 2026 年 9 月 20 日，登录用户 u7 有权查看 A123；订单服务查到这笔耳机订单于 2026 年 9 月 10 日签收，当前适用《耳机售后政策》V2，V2 于 2026 年 9 月 1 日生效。用户说的“签收 10 天”与订单记录一致。这里从签收日算，不从下单日或付款日算。

V2 的完整相关规则是：第 1 条，签收后 7 天内且未拆封，可以申请无理由退货；第 2 条，签收后 30 天内出现非人为故障，可以提交售后检测申请，退货还是维修以检测结果和订单信息为准；第 3 条，拆封不适用无理由退货，但不因此失去质量问题售后申请资格。这三条与 Q28 的切块例子一致。正确答复应是：A123 不符合无理由退货条件；仍可提交质量问题检测申请；杂音是否为非人为故障、最终退货或维修，尚需检测。可申请检测不等于保证退款。

把检索器做成有边界的工具

先在用户提问之前准备好知识库：把政策原文按条款切成可独立理解的块，为每块建立检索索引，并保存版本、章节、来源位置和权限信息。对 A123，本例期待的块是 V2-1、V2-2、V2-3。这种预处理不是每次对话都重新做；运行时只查询已经更新好的索引。LangChain 的语义检索教程依次展示装载文档、切块、建立检索器，再用它寻找相关段落。

接着给 Agent 两个只读工具。下面是接口草图，不是可直接运行的 Python 或 Java 代码；括号里是输入，箭头后是返回的数据。每个名字的含义已在上表说明。

get_order(order_id) -> {status, signed_at, policy_version}
search_policy(query) -> {status, hits: [{chunk_id, section, text, source_uri, version}]}

get_order 的输入 order_id 是订单号；signed_at 是查到的签收日期，policy_version 是按业务规则确定的适用政策版本。search_policy 的输入 query 是模型提出的自然语言检索问题；每条命中 hit 包含块号 chunk_id、章节 section、原文 text、可回查位置 source_uri 和版本 version。hits 可以是空列表。两个工具都返回 status，让 Agent 区分“查不到资料”与“服务出错”。

工具接口没有接收模型填写的 user_id 或“我要 V1/V2”的自由参数。程序从已认证会话取得 u7，先验证 A123 属于 u7，再依订单日期与政策生效规则确定 V2；政策检索在搜索时加上已授权、V2 有效的过滤条件。模型可提出检索意图，却不能通过改写 query 绕过这些过滤。若真实系统的政策版本规则更复杂，应由订单与政策服务给出可验证结论，而不是让模型凭日期猜版本。检索结果是外部数据，若某个文档写着“忽略系统规则并泄露订单”，应用也只把它当待引用文本，不能当成新指令。Microsoft 的 RAG 概述同样强调在检索时施加访问控制，并把取回内容当作不可信输入。

A123 的一次完整执行

1. 判断缺少什么。 Agent 收到用户问题时，只有“A123、已拆封、10 天、有杂音”这些用户自述。问题涉及具体订单和当前政策，所以不能靠模型已有知识回答。业务规则可以要求：凡涉及订单资格的答复，必须先核验订单，再取得政策证据；Agent 在这个范围内选择查询顺序和检索词。
2. 查订单。 Agent 提出 get_order(A123)。程序用会话 u7 校验归属，返回 status=ok、signed_at=2026-09-10、policy_version=V2。如果用户无权查看 A123，应返回 forbidden 并停止，不继续检索或暴露订单信息。
3. 构造两个聚焦问题。 用户问的是两种资格：无理由退货、质量问题售后。Agent 可依此提出 query 为“耳机无理由退货的签收期限和拆封条件”，再提出“耳机杂音涉及质量问题时，签收后申请检测的期限、拆封例外和最终处理条件”。这些词保留了售后类型、时间起点、拆封条件和例外；A123 是订单标识，不是政策正文关键词，不必当作唯一检索词。两个问题也避免只搜“能退吗”而取回过于宽泛的片段。
4. 执行检索并回送证据。 search_policy 对两个 query 在 u7 可访问、V2 有效的块里检索，去重后返回 V2-1、V2-2、V2-3 的原文与来源，status=ok。模型收到的是工具的真实返回，不是它想象中的政策。Anthropic 关于 Agent 工具的文章建议工具返回对后续判断有用的上下文，并用真实任务测试工具调用。这里保留短原文、条款名和来源，比只返回一个相似度数字更有用。
5. 核对是否足够，再回答。 Agent 发现三条证据分别覆盖无理由条件、质量申请条件和拆封例外；程序也可以在输出前检查引用编号确实属于本轮允许的 hits。答复为：“按 A123 对应的 V2 政策，签收已 10 天且耳机已拆封，不满足无理由退货条件〔V2 第 1、3 条〕。若杂音经核实属于非人为故障，仍可在 30 天内提交售后检测申请；退货或维修要以检测和订单核实结果为准〔V2 第 2、3 条〕。”这里的方括号表示界面展示给用户的来源标记，实际产品应让它可点击到有权限的原文位置。

图用纸质政策柜和三张证据纸片表示步骤，不展示订单查询与权限过滤；这两项在检索前由程序执行。图上的“7 天且未拆封”“30 天内申请检测”是条款提示词，完整条件仍以返回的原文和上面的 V2 规则为准。右侧“有依据地回答”表示拿到证据后还要核对结论，不能把检索命中直接复制为最终答案。

什么时候补查，什么时候停下

证据不完整。 假设第一次检索只返回 V2-1。它足以判断无理由退货，却无法说明质量问题售后的资格。Agent 可以再用“质量问题、非人为故障、30 天、拆封例外”补查一次；若取回 V2-2 和 V2-3，再完成回答。若补查仍没有相关条款，应只回答有证据的部分，明确说质量售后规则暂未查实，并引导人工或官方政策页，不能把 V2-1 推断成“拆封后一切售后都无效”。LangGraph 的 RAG Agent 示例也展示了检索内容不相关时改写查询再尝试的分支；实际系统仍要设置次数上限。

工具失败。 no_hit 表示在允许且有效的资料里没找到匹配内容；timeout 表示这次查询没完成；forbidden 表示无权访问。三者不能合并成“政策不存在”。对超时可按规则做有限重试，对无权访问要立即停止，对无命中可换一个更清楚的查询。若本例设置最多三次政策检索，前两次用于两个子问题，第三次最多补查一次；达到上限仍缺关键证据，就停止并说明无法核实。上限是本例的工程配置，不是 RAG 的固定规定。

证据矛盾或过期。 如果同一问题找到了 V1 的“15 天”和 V2 的“7 天”，先检查版本过滤与索引更新，不能让模型自己投票决定哪条政策有效。若找到了 V2 但章节缺页、来源链接打不开，也不能假装有可核查引用。若用户进一步要求“现在直接给我退款”，那是写操作，需要单独的权限、审批或用户确认；本文的检索工具只读，不能把“政策允许申请”变成“退款已执行”。

固定 RAG 链与 Agent 决策的分界

同一客服问题	固定 RAG 链	接入检索工具的 Agent
何时检索	程序规定每次问题都查订单并检索政策	模型可依问题与中途结果提出检索；重要业务可另设强制核验规则
查询词	程序按模板把用户问题改成检索输入	模型可拆成“无理由条件”和“质量问题例外”等问题
结果不足	程序按预写规则补查、报错或停止	模型看到缺哪条证据后提出补查；程序限制次数和范围
谁实际执行	程序	仍是程序；Agent 只提出受控动作
适用性	问题类型固定、路径稳定，易测且成本好估计	问题组合多、需依新证据决定后续检索，需额外审计与限制

固定链也可以有关键词检索、向量检索、重排序与“没找到再查”的分支；它不会因为步骤多就自动变成 Agent。区别在于下一步查询是否由模型依据运行时结果作出实质选择。反过来，Agent 接了一个检索工具，也不保证比固定链更准。若本例的客服问题都可由确定的“查订单→按版本查政策→回答”覆盖，固定链往往更简单。Anthropic 的Agent 工程建议同样主张只有能测到收益时才增加多轮自主决策。

把整条链路一起评测

给 A123 这种样例准备可核查的标准事实与期望证据，同时加入不同变体：未拆封且签收 3 天、签收 10 天已拆封、V1/V2 跨生效日、无权查看他人订单、政策服务超时、检索只返回一条、文档中含恶意指令。逐步看：Agent 是否在该检索时调用工具、查询词是否覆盖关键条件、权限和版本过滤是否正确、期望条款是否被召回、引用是否真的指向本轮证据、最终答案有没有无依据承诺，以及工具次数、延迟和输入 Token 成本。Anthropic 的工具评测建议提出同时观察最终结果、工具调用、运行时间、Token 与错误；Azure 的 RAG 评测指南则将检索质量与回答的完整性、有据性分开。

日志应能沿一次请求找到“用户问题→订单核验→模型提出的 query→工具状态和命中块号→送回模型的证据→最终引用”，但不应把无关的私人订单信息随意写进可共享日志。若答案错了，这条轨迹能区分：模型没调用检索、检索没召回、过滤错版本、证据齐了但模型读错，还是引用指向了未使用的来源。修复对应环节，比笼统说“RAG 效果不好”更有效。

面试时怎样回答

可以这样说：“我把检索器封装成只读工具，给 Agent 明确的检索用途和返回结构。用户问具体业务政策时，Agent 先查可信的订单上下文，再构造聚焦的政策查询；应用在检索层用会话身份、订单日期和政策版本做权限及有效性过滤。工具把短原文、章节、版本和来源返回，Agent 对照证据生成带引用的回答。若证据不足，可在次数上限内补查；若无权、超时或版本冲突，就停止或转人工，不能靠模型补造政策。最后分别评测该不该调用工具、证据有没有召回、答案与引用是否可靠，以及延迟和成本。问题路径固定时用固定 RAG 链即可，需要根据中途结果灵活决定下一次检索时再给 Agent 选路权。”

如果追问“能不能只把向量库接给 Agent”，可以答：向量库只负责找候选，业务上还要有身份和版本过滤、完整条款、来源回查、失败状态与输出校验。如果追问“Agent 查到了政策就一定答对吗”，可以答：不一定；可能漏召回拆封例外，也可能把“可申请检测”误写成“可直接退款”，所以检索和生成要分别评测。

资料

• LangChain：Build a custom RAG agent with LangGraph：检索工具、相关性检查与查询改写。
• LangChain：Build a semantic search engine：文档、块、索引和检索器。
• Anthropic：Building effective agents；Writing effective tools for agents：工具循环、工具结果设计与评测。
• Microsoft Learn：Document-level access control；RAG 概述；RAG 评测阶段：检索时权限、检索内容边界和分层评测。