Agentic AI与RAG根本不是一回事

至少每月一次，会有客户发来同样的问题："我们该用 RAG 还是 Agent？"这个问题可以理解，但表述方式是错的，因为它们并非同一事物的两个版本。RAG 从你的知识库中回答问题，Agent 则为一个目标采取行动。两者正面比较，就像把图书馆的咨询服务台比作一个恰好也读遍了图书馆的个人助理——一个提供信息，另一个负责办事。

我理解这种混淆为何存在。两者都是 2020 年代 LLM 的模式，都涉及对模型进行提示，都被归类到各个服务落地页的"AI 集成"中。但它们解决的是不同的问题，失败的方式也各不相同，把它们混为一谈，正是你会得到一个每月 3000 美元的"Agent"（本来一个 0.20 美元的 RAG 管道就够了）的途径——或者更糟，一个产生幻觉并擅自采取了未授权行为的 RAG 管道。

所以让我做一个好的对比应该做的事：把它们并列，诚实地打分，最后给出一个你真正能用上的决策规则。

那句话版本：RAG 控制模型"知道"什么；Agent 控制模型"做"什么。其他一切——成本、延迟、失败模式——都从这唯一一个差异衍生出来。

RAG 是什么

RAG 是一种将你自己的文档注入 LLM 回答的方式。流程简短且确定性：

user question → embed → vector search → top-k chunks → prompt → answer

你将文档（政策、手册、产品规格）作为嵌入向量存储在向量数据库中。每次查询时，检索相关片段并塞进提示词。然后模型从你给它的内容中作答，而非从训练数据中。做得好的话，这能消除关于你自己内容的大部分幻觉——回答中引用的片段确实存在。

诚实的优势：便宜（每次查询 0.01–0.05 美元），快速（一次往返），易于推理（一个提示词），每个回答都能追溯到来源片段。一个好的 RAG 系统是一个内容系统，而内容系统是可预测的。

诚实的劣势：RAG 不能行动。它能告诉你退款政策，但不能签发退款。它能总结日志文件，但不能轮换它刚发现的已被泄露的凭证。一旦"告诉我"变成"去做"，RAG 就没有相应的机制了。

什么是 Agentic AI

Agent 是一个循环，而非单次调用：

while goal not met:
    observe → reason → call tool → use result → repeat

模型决定调用哪个工具以及传递什么参数——查询余额、发送邮件、更新记录、触发工作流。它在每个动作之后重新观察，持续运行直到目标达成、预算耗尽或升级。决定性属性是自主性：多步骤行动，无需人类预先编写每个步骤。

诚实的优势：Agent 可以做事。它能分拣支持收件箱、协调两个系统、起草并发送报告，或引导用户完成一个有真实副作用的流程。这是 RAG 无法触及的一类价值。

诚实的劣势：Agent 的知识取决于它能看到什么——默认情况下，是它的训练数据加上工具返回的任何内容。如果不问它关于你私有策略的问题，它就会凭感觉作答。更糟的是，Agent 可以基于那种感觉采取行动。这就是为什么在生产环境中，大多数 Agent 悄悄地在内部包含了一个 RAG 管道。

诚实的数字打分

在决定生产结果的那些维度上：

自有内容的回答质量 — RAG 4，Agent 4。当 Agent 包含 RAG 时，两者同样有据可查。当不包含时，Agent 是 1 分且自信地错误。这个维度并非真正的竞争——而是一种依赖关系。

行动能力 — RAG 1，Agent 5。这里没有 nuance。如果任务需要改变世界（创建记录、发送消息、变更状态），RAG 做不了而 Agent 可以。这是让 Agentic AI 值得其成本的唯一维度。

每个任务的成本 — RAG 5，Agent 2。一个执行五步任务、两次工具调用的 Agent 大约是一次 RAG 生成的 5–10 倍。加入长上下文和重试，差距会进一步拉大。如果你不需要行动能力，你就是在为你从未使用的功能支付高昂溢价。

延迟 — RAG 5，Agent 3。一次生成耗时一到两秒。Agent 循环耗时几秒到几分钟。对于正在观看聊天的用户来说，差异在第一次交互中就能感受到。

可预测性与治理 — RAG 4，Agent 3。RAG 的风险是一句错误的话；Agent 的风险是一个错误的动作。行动需要预算、权限层和人工审批门，而 RAG 从不需要考虑这些。爆炸半径完全不是一个量级。

复杂度 — RAG 4，Agent 2。RAG 管道是向量存储、一次嵌入调用和一个提示词。Agent 增加了循环、工具 schema、记忆、预算和可观测性。用同样的投入，团队一周能上线一个 RAG 系统，而一个月才能上线一个生产级 Agent。

实例：同时使用两者的支持管道

不再停留在抽象层面，这是我为一家物流公司实际构建的系统，因为这是证明两者是层级而非竞争对手的最清晰例证。

第一个版本是纯 RAG。客户询问配送政策，系统从存储在向量数据库中的政策手册中作答。它让每个回答都基于检索到的片段，精准、便宜地处理了大部分咨询量——关于海关、时间线和文件的重复问题。那是 RAG 做了 RAG 该做的事。

然后客户提出了更难的 20%：客户需要采取行动的情况。包裹卡在海关、地址纠错、申请人工回拨。这些用一段政策文字来回答是不够的。那就是 Agent 入场的地方——不是作为替代，而是作为上层。Agent 的工具是：查询货运记录、更新配送地址、创建后续工单。关键的是，Agent 的第一个工具是现有的 RAG 检索器，因为行动之前它需要政策和历史。

结果是这样一个管道：

question
  ├─ RAG path → answer from policy (bulk of traffic, cheap, fast)
  └─ agent path → retrieve policy via RAG → call shipment tools → act or escalate

RAG 路径从不采取行动，所以不需要权限门。Agent 路径有预算、权限层，对于任何变更货运的操作有人工审批路径。两个系统，一个产品，零竞争。这是诚实的架构，在生产环境中这比纯粹的"RAG 或 Agent"二选一要常见得多。

两者一起打分

如果你问先建哪个，诚实的答案几乎总是 RAG。它更便宜、更快、更安全，上线当天就能交付价值。只有当你正在做的工作从"回答"变成"做事"时，你才加入 Agent——而到那时，你已经构建的 RAG 层就成了 Agent 的记忆。我数不清有多少项目，团队建了一个 Agent，看着它对自己的政策产生幻觉，然后花了一个月事后补救检索。先构建 RAG 不是妥协，而是通往同一目的地的便宜路径。

两者没有"更好"。它们是不同的层级，在严肃系统中是组合使用的：RAG 是 Agent 的长期记忆，Agent 是有手脚的 RAG。

当任务属于"从我们的知识中准确作答"时用 RAG。支持回答、政策查询、文档问答、有引用的聊天。更便宜、更快、更安全，不需要任何 Agent。

当任务属于"完成一个多步骤目标"时用 Agent。工作流、工具调用助手、任何有副作用的东西。而当你这样做时，把 RAG 螺栓连接进去，这样 Agent 的决策就基于你真实的而非训练数据。这是一个常见的现实设计——Agentic RAG——即一个工具包含检索器的 Agent：它在决定之前先检索，所以它基于证据行动。这不是第三个类别；而是正确使用 Agent 模式的方式。

我曾为一个项目提供咨询，客户坚持他们需要"一个 Agent"，并为此做了预算。实际需求是：从保修手册中回答客户问题。我们构建了 RAG，一周上线，每天推理成本约两美元。他们报价的"Agent"成本会是十倍以上，而且为一个没有行动的任务引入了行动风险。

按顺序走一遍这个清单，它会正确地引导你：

任务需要改变什么吗——发送、创建、更新、触发？没有 → 构建 RAG。在这里停下。不要加入 Agent 机制。

是单一决策，还是需要工具调用的多步骤序列？单一决策、不需要行动 → RAG。多步骤、需要工具和重新观察 → 转第 3 步。

Agent 需要真实的 facts 才能决策良好吗？需要 → 构建一个内部包含 RAG 工具的 Agent。这是默认的生产设计。

最后，给行动加门。无论什么架构，任何能采取行动的系统都需要预算、权限检查，以及高风险行动的人工审批路径。

我给客户画在白板上的简化版本：如果用户离开交互时知道得更多，那是 RAG。如果世界在交互结束时改变了，那是 Agent——而且它最好先检索过。

规则一句话：用 RAG 检索，用 Agent 行动，永远不要让 Agent 基于未检索的知识采取行动。

这就是诚实的对比。下次有人问你"RAG 还是 Agents？"时，你可以回答真正的问题：你需要知道，还是需要做？