RAG和Agent的边界到底在哪
比特严选的在线咨询后台，今天上午收到这么一句话：
我上周买的AirPods Pro左耳突然没声音了，放回充电盒也没用，你帮我看看是不是坏了，要是修不好我想退。
这句话丢给一套调得不错的RAG系统，它确实能答——退换货政策检索得到，AirPods故障排查文档也检索得到，生成出来的回复挑不出硬伤。但用户看完多半还得再问一句，因为他的问题没有被解决。
这一篇要讲清楚的是：这类问题的形状长什么样，为什么RAG接不住，以及业界拿什么来补。
先把场景立住
1. 比特严选是个什么地方
整个系列都用同一个业务背景，先花一分钟交代清楚，后面所有例子都落在这个范围里。
比特严选是一家Apple授权经销商，自己进货、自己发货、自己售后，有独立APP，没有第三方商家，也没有跨店铺的概念。在售的是Apple全线产品与精选第三方配件，分八个品类：
- 手机（iPhone 16 / 17 / 17e / 18 Pro / 18 Pro Max / Air / Duo）
- 平板（iPad / iPad Air / iPad mini / iPad Pro）
- 电脑（iMac / Mac mini / Mac Studio / MacBook Air / MacBook Neo / MacBook Pro / Studio Display）
- 智能手表（Apple Watch SE 3 / Series 12 / Ultra 4）
- 耳机音频（AirPods 5 / AirPods Max 2 / AirPods Pro 3）
- 智能家居（AirTag / HomePod / HomePod mini）
- 空间计算（Apple Vision Pro）
- 配件
为什么选Apple？上一版数据集用的是虚构的智能硬件品牌，扫地机器人、智能门锁这些品类大家日常接触少，测试的时候部分同学反馈说光看配置参数分不清对错。这一版换成Apple iPhone、Mac、AirPods这些大家天天在用的东西来举例，问答质量好不好、参数对不对，一眼就能判断。
三句话交代一下这个业务背景怎么来的，免得大家在后面的例子里较真。
-
比特严选是为这个系列虚构的品牌。商品型号与价格取自Apple中国官网，退换货与保修条款是自己写的教学素材。你要把这套东西写进简历或者做成自己的项目，换成你实际想做的商城或者手头真实的业务就行——这个系列讲的是Agent怎么落地，业务壳子是可替换的。
-
比特严选的完整商品库有695个SPU（商品款）和1420个SKU（可下单配置），知识库有30+ 篇产品详情文档。演示数据要能读、能复现、能一眼看出边界在哪。30篇详情覆盖了上面八个品类的主力型号，每一款在知识库里都有一篇详情文档与之对应，业务库里查得到它的实时价格和库存。缩规模不影响任何一条Agent链路，只影响你能挑的商品有多少。
-
文中的订单号和日期是为了把流程讲顺手写的，不必和数据集里的实际单号一一对应。涉及真实演示时，我会明确说是哪一单。
商品库的SKU和SPU以及产品详情文档，后续会适当新增。
2. RAG会怎么答开头那句话
按RAG的路子，那句话会这么走：先改写成一个独立问题，拿去做检索，命中知识库里的《退换货政策》和《AirPods Pro常见故障处理》两篇文档，把召回的chunk塞进提示词，模型生成一段回复。
回复大概长这样：
关于AirPods Pro左耳无声的问题，建议您先检查左耳耳塞是否正确安装、充电盒与耳机触点是否有污渍，也可以尝试将两只耳机放回充电盒后长按背部按钮重置。根据我们的退换货政策，商品自签收之日起7天内，在不影响二次销售的前提下可申请无理由退货；非人为损坏的质量问题，一年内可免费维修。
这段话没有一句是错的。政策是对的，排查步骤也是对的。
但用户要的不是一篇说明书。他要的其实很具体：
- 先搞清楚他买的是哪一副。这得查他的订单。
- 判断还在不在能退的窗口里。这得拿签收日期和今天的日期相减。
- 一步步带他排查。是不是耳塞没装好、是不是蓝牙配对出了问题，根据他的回答决定下一步问什么。
- 排查下来确实坏了，告诉他这副能不能退、怎么退。这又要回到订单和退货规则。
这四件事，RAG一件也做不了。
3. 不是答得不好，是形状不对
把RAG的执行形状画出来，是一条直线：
这条线上每一环都可以做得很复杂。检索可以三路并发再融合，改写可以拆子问题，生成前可以过一道证据闸门。但不管中间多复杂，它的拓扑是固定的：走完一遍就结束，没有回边。
固定拓扑带来一个硬约束：要查什么这件事，必须在检索发生之前就定下来。
多数问题这不成问题。“七天无理由退货的条件是什么”，查什么很清楚，检索一次就够。但只要问题里藏着第二步，这条直线就断在第一步上。
有三类问题会稳定地断在这里。
第一类，得先查一个东西，才能算出答案。
“我这单还能退吗”。要回答它，得先知道订单什么时候签收的，再知道今天几号，两个日期一减，跟政策里的7天比一比。检索能捞到政策文本，捞不到这个用户的签收日期，更给不出今天的日期。模型的权重里没有当前时间这个东西，你不给它，它就会编一个出来，而且编得很自然，一点也不像编的。