RAG 和 Agent 的边界到底在哪？

作者：程序员马丁

在线博客：https://nageoffer.com

note

Ragent AI —— 从 0 到 1 纯手工打造企业级 Agentic RAG，拒绝 Demo 玩具！AI 时代，助你拿个offer。

如果你跟着 RAG 系列一路走到这里，那么恭喜你，你已经能用纯 Java 手写一套像样的检索增强问答系统了：文档切块、向量检索、重排、会话记忆、意图路由，这些环节你都拆解过、也都跑通过。

但你有没有一种感觉——这套系统再强，本质上还是个会查资料的复读机。

你问它一句，它查一遍知识库，组织一段话回给你。问完这一句，它的使命就结束了。它不会自己去查订单系统，不会根据查到的结果决定下一步干什么，更不会在一件事没办成的时候，换个思路再试一次。

从这一篇开始，咱们进入一个新的系列——《Agent 系列》。整个系列会以一个叫比特严选的电商客服场景贯穿始终，带你一步步手写出一个能自主推理、调用工具、循环决策的智能体——比特严选智能体。

第一篇不写代码，咱们先把一件最基础、但很多人其实没想清楚的事讲透：RAG 和 Agent，边界到底在哪？

先看一个 RAG 答不好的问题

1. 比特严选是个什么场景

先花一分钟把场景立住，后面所有例子都落在这个范围里。

比特严选是一个对标小米商城模式的自营智能硬件电商，有自己的独立 APP。它不是淘宝那种平台，没有第三方商家、没有跨店铺，就是单一平台卖自己的货。商品规模也不大，大概 300 到 500 个 SKU（库存单位，可以粗略理解成在售单品），分成 6 大品类：

手机
平板电脑
笔记本
智能穿戴（手表、手环、耳机）
智能家居（扫地机、智能音箱、摄像头等）
影音配件

小而美，但品类全。正因为品类多，用户的问题就会很自然地跨来跨去——一会儿问手机，一会儿问能不能配个音箱，一会儿又问买回来的扫地机不转了怎么办。

2. 一个真实的客服问题

现在来看一个用户在比特严选 APP 里发来的消息：

我上周买的那台扫地机昨天开始不回充电座了，你帮我看看是不是坏了，要是修不好我想退。

你用 RAG 系统接这个问题，会发生什么？

系统拿这句话去向量库里检索，召回了几个 chunk：扫地机的常见故障排查文档、保修政策、退货政策。然后模型基于这些资料，给你回一段话：

关于扫地机无法回充的问题，您可以检查充电座是否通电、回充路径是否有障碍物。根据保修政策，非人为损坏一年内可免费维修；根据退货政策，签收七天内支持无理由退货……

听起来很合理，但实际跑起来，用户大概率要骂街。

为什么？因为用户要的不是一篇说明书。他要的是：

你先搞清楚他到底买的是哪台——得查他的订单。
你得判断还在不在保修期——得拿订单日期算。
你得一步步带他排查——是不是充电座没通电、是不是被地毯绊住了，根据他的回答决定下一步问什么。
排查下来确实坏了，你得告诉他这台还能不能退、怎么退——又要回到订单和退货规则。

这一整套下来，RAG 系统一个都干不了。它只会查资料、答一句，然后等下一句。它没有能力把查订单、算保修、走诊断树、发起退货这些动作串起来自主执行。

这就是 RAG 的天花板。

RAG 与 Agent 的本质区别

1. 被动检索 vs 主动决策

用一句话概括两者的区别：

RAG 是被动检索，你问一次它答一次；Agent 是主动决策，你给个目标，它自己想办法把事办成。

打个比方。RAG 像图书馆里的查询机：你输关键词，它给你列出相关的书，仅此而已。至于这些书能不能解决你的问题、要不要再查别的、查到之后该干什么，它一概不管。

Agent 更像一个新来的客服专员：你把一个模糊的诉求丢给他，他会自己拆解——先去订单系统查一下、再翻翻保修规则、不确定的地方反过来问你一句、最后该走退货流程就去走。他有一个目标，并且会一步步盘算下一步该干什么、调用手头的工具、根据每一步的结果再决定往哪走。

关键的差别在于一个词：循环。

顺带把名字也点了：这个想-做-看的循环有个正式叫法，叫 ReAct（Reasoning + Acting，推理 + 行动）。后面整个系列就是围着它打转，这里先记住这个词，看到 buildReActPrompt 这种命名时心里有数就行。

ReAct 是目前最常见的 Agent 实现模式，但不是唯一。Agent 的本质是「带循环的自主决策」，而循环具体怎么转，业界还有 Plan-and-Execute（先规划再执行）、Reflexion（带自我反思）等多种范式。本系列选 ReAct 作为主线讲解，是因为它最直观、最易上手——但请记住：Agent 是一类思想，ReAct 只是其中一条路。

RAG 的流程是一条直线，走到头就结束：

Agent 的流程是一个圈，它会反复地想、做、看，直到把事办成：

这个圈，就是后面整个系列要带你手写的东西。

2. 一张图看清两种流程

把两种流程画在一起，差别一目了然。

左边是 RAG，一条道走到黑；右边是 Agent，多了一个会自我驱动的循环。这个系列的核心，就是把右边这个循环讲透、写出来。

3. 从代码上看，差在哪一行

光说概念有点虚，咱们从代码骨架上感受一下。先看 RAG 的核心，本质就是一次性的调用（伪代码，省略了 OkHttp 的细节）：

// RAG：一问一答，没有循环
public String ragAnswer(String question) {
    // 1. 检索
    List<String> chunks = vectorStore.search(question, 5);
    // 2. 拼 Prompt
    String prompt = buildPrompt(question, chunks);
    // 3. 调一次模型，拿到答案就结束
    return llmClient.chat(prompt);
}

注意，从头到尾，模型只被调用了一次，没有任何分支和回头路。

再看 Agent 的核心骨架，差别就在那个 while：

// Agent：循环地想、做、看，直到完成
public String agentRun(String userGoal) {
    List<String> trace = new ArrayList<>();   // 记录走过的轨迹
    trace.add("用户目标：" + userGoal);

    for (int step = 0; step < MAX_STEPS; step++) {
        // 1. 想：让模型基于当前轨迹，决定下一步动作
        String thought = llmClient.chat(buildReActPrompt(trace));

        // 2. 判断模型是不是已经给出最终答案
        if (isFinalAnswer(thought)) {
            return extractFinalAnswer(thought);
        }

        // 先把这步思考记进轨迹，再去执行动作
        trace.add(thought);

        // 3. 做：解析出要调用哪个工具，执行它
        Action action = parseAction(thought);
        String observation = toolRegistry.execute(action);

        // 4. 看：把工具结果塞回轨迹，进入下一轮思考
        trace.add("Observation：" + observation);
    }
    return "抱歉，超过最大步数仍未完成任务。";
}

你可能会问：说好的「自己规划」呢，代码里怎么没看到一份计划？其实它就在 thought 那一行。ReAct 的规划是走一步规划一步，摊在每一轮的「想」里——模型每轮基于当前轨迹盘算下一步该干什么，做完看了结果再盘算下一步，而不是一上来先列好 1234 步。那种先生成完整计划、再逐条执行的显式规划，是后面《规划》那篇要专门讲的事，这里先不掺进来，免得冲淡主线。

先不用纠结每个方法怎么实现——buildReActPrompt、parseAction、toolRegistry 这些后面都有专门的篇章手写。这里你只要抓住一个直觉：

RAG 是调一次模型；Agent 是把模型放进一个循环里，让它自己决定要调几次、每次调用之间干点什么。

多出来的这个循环，就是从被动响应到主动决策的全部秘密。

那 RAG 是不是没用了

看到这你可能会想：既然 Agent 这么强，那我之前学的 RAG 是不是白学了？

恰恰相反。

RAG 不仅没过时，它还会成为 Agent 手里最重要的一件工具。回到前面扫地机那个例子——Agent 在排查故障的时候，要查的故障知识库、保修条款、退货政策，靠的还是检索。区别只在于：

以前是系统强制每次都去检索，不管该不该查。
以后是 Agent 自己判断这一步该不该查、查什么，把检索当成众多工具里的一个来调用。

这件事咱们在第三部分会专门写一篇《把 RAG 变成 Agent 的一个工具》。所以你大可以把 RAG 系列学到的东西揣好，它在 Agent 里有大用。

下面用一张表把两者的定位彻底理清：

维度	RAG	Agent
核心模式	被动检索，一问一答	主动决策，循环执行
模型调用次数	通常一次	多次，由任务自己决定
是否有循环	没有，直线流程	有，想-做-看的循环
工具能力	一般只有检索（可加 MCP）	检索只是工具之一，还能查订单、发起退款等 MCP
能否多步	单步	多步，可串联多个动作
出错处理	答错就答错了	可以根据结果反思、换思路重试
典型场景	产品问答、政策咨询	故障诊断、跨品类推荐、订单售后全流程
复杂度与成本	低，可控	高，循环带来不确定的 Token 与时延开销

从这张表也能看出来：Agent 不是来取代 RAG 的，而是把 RAG 这类能力装进一个会自主决策的壳子里。能力更强，代价是复杂度和成本也更高——什么时候该上 Agent、什么时候一个 RAG 就够了，这是你做技术选型时要拿捏的。简单的产品问答，老老实实用 RAG；要把查订单、算保修、走诊断、发退款串成一条龙的活儿，才轮到 Agent 出场。

文末总结

这一篇咱们没写多少代码，但立住了两件最重要的事。

第一，看清了 RAG 的边界：它是被动检索，擅长一问一答，但没法把多个动作自主串起来办成一件事。比特严选里那个扫地机退货的例子，就是 RAG 接不住的典型。

第二，理解了 Agent 的本质：它在 RAG 的基础上多了一个想-做-看的循环，能自主推理、调用工具、根据结果决定下一步。这个循环，就是后面整个系列的主角。

一句话收尾：RAG 只会固定形式答，Agent 会自主规划还能执行操作。差别就在那个让模型自己转起来的循环。

下一篇，咱们会把镜头拉远，用一张图看懂 Agent 的架构全貌——LLM 大脑、工具手脚、记忆、规划这四个要素分别是什么、怎么配合。把全景图装进脑子里，后面一篇篇拆解的时候你才不会迷路。

我们下一篇见。

先看一个 RAG 答不好的问题​

1. 比特严选是个什么场景​

2. 一个真实的客服问题​

RAG 与 Agent 的本质区别​

1. 被动检索 vs 主动决策​

2. 一张图看清两种流程​

3. 从代码上看，差在哪一行​

那 RAG 是不是没用了​

文末总结​

Table of Contents