RAG 解决的是“回答前从外部资料找依据”，智能体解决的是“面对目标时选择下一步并调用工具”。两者可以组合：企业文档问答可先用 RAG 找制度原文；如果读者还要求创建审批单，才需要让有权限的智能体调用业务系统。选型时先问：用户要的是有出处的答案，还是一项真正执行的操作？
同一个问题，三种不同的任务
假设一家公司的知识库有差旅制度，业务系统里有每位员工的剩余额度。下面的例子用于说明设计方法，不代表本文接入或测试过任何真实公司系统。
| 用户提问 | 需要的能力 | 怎样判断结果 |
|---|---|---|
| “出差住宿上限是多少？给我制度出处。” | 检索现行制度，再生成带来源的回答 | 能打开引用的制度条款，数字和适用地区相符 |
| “我的剩余额度是多少？” | 在确认身份后查询个人业务数据 | 与本人在权威系统中的余额一致 |
| “按这张发票创建报销申请。” | 读取规则、校验字段，并在授权后调用创建接口 | 业务系统返回可追踪的真实申请编号 |
第一行主要是 RAG 问答；第二、三行涉及身份、权限和工具调用，不能仅靠一段检索出的文字假装完成。创建报销单这类写操作还应有人确认、重复提交保护和失败回读，不能把模型说“已提交”当作成功。
RAG 到底做了什么
典型流程是：把授权可用的资料整理并建立索引；收到问题后检索相关片段；把片段和问题交给模型生成答案；让读者能回到原文核对。微软的RAG 说明特别提到查询理解、多来源资料、有限上下文、引用与访问控制等实际难点。检索命中不等于答案正确，还要检查版本、权限和引用是否支撑结论。
例如“住宿上限”可能因城市、职级和生效日期而不同。一个可用的答案应先问清缺失条件，或分别列出适用范围，并引用对应条款。把整份制度塞进提示词、不注明来源，不能算可靠的企业知识库问答。
智能体与普通检索的分界
智能体可以把目标拆成步骤，根据中间结果选择工具，并维护执行状态。OpenAI 的Agents 文档将规划任务、使用工具和跨步骤保持上下文列为其能力。具体产品是否能执行某个动作，仍取决于你给它接了什么工具、授予什么权限、如何处理失败。
在报销场景里，智能体可能先查制度，再读取用户已授权的余额，最后准备创建申请。它完全可以把 RAG 作为其中一步；RAG 与智能体并非二选一。反过来，只有制度问答需求时，先做检索、引用和权限过滤，通常比引入自动执行链更容易验收。
用一张清单做选型和验收
- 写下读者真正想得到的结果：一段带出处的答案、一个实时数值，还是业务系统中的新记录。
- 列出知识来源及更新责任人。过期制度和越权文档必须在检索层排除，不能靠模型自行判断。
- 若要执行动作，列出工具名称、可读可写范围、需不需要人确认，以及失败时怎样查回真实状态。
- 先准备小型验收集：含明确答案的问题、缺少条件的问题、无权查看的问题和会改变业务状态的请求。分别检查引用、拒答、权限与实际系统结果。
开始时可以先取一份可公开给测试人员的制度，做 5 个带答案出处的问题。若答案找不到原文，先修检索和资料；若答案正确却无法完成“创建申请”，再设计有权限的工具调用。这个顺序有助于定位问题在哪一层，但具体效果仍需用你自己的资料实测。
常见问答
有了智能体，还需要 RAG 吗？
如果任务依赖经常更新的企业文档，智能体仍需要一个可追溯、带访问控制的资料获取方式；RAG 可以承担这一步。若任务只依赖明确的结构化业务接口，也不必为了“有 RAG”而额外建知识库。
RAG 能直接修改业务数据吗？
检索与生成本身不会产生可信的业务写入结果。需要修改数据时，应接入受权限控制的业务接口，并以接口回读和业务流水验收。
本文是方案判断示例，没有在真实企业系统做权限或业务写入测试。若还想区分大模型、智能体和预设工作流，可参看本站的客服工单示例。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/29736.html
