2026-05-27 20:14
扫码打开虎嗅APP
本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《Agent 需要 RAG 吗？》
依旧延续周一TGO闭门会的分享思考，核心话题是：如何真正蒸馏一个人+如果完成了蒸馏动作，应该如何形成企业级Agentic RAG数据库类应用？
怎么说呢，现阶段为了适应Agent发展，模型本身已经往前走了很大一步，最核心的两个能力：
一个来自于模型本身，提供了百万级上下文窗口；
一个来源于工程能力优化，Skills缓解了模型不稳定问题；
现阶段Agent，在数据处理一块有了很大的进步，甚至说可以解决80%的问题（也就是数据正确率会在80%左右），于是现有经典架构就出来了：
上图是前些日子爆火的小龙虾OpenClaw的大概架构和解决的问题，如图所示，就可以前些日子各个老板所谓“养虾”是个什么意思，其实就是在梳理工作流/SOP。
在这个基础之下就衍生出来了同事.skill，大家想要用这个方式去蒸馏员工，我们只是从底层架构来说，就不太可能，但这里依旧有一些不错的衍生实践，比如obsidian+Claudian组合：
类似于obsidian+Claudian这种模式都可以归类于Workspace Agent/知识工作区Agent/文件系统型Agent，他属于：
以私有工作空间为上下文，以文件系统为操作对象的协作型知识Agent
这里最为核心的问题就产生了：过往，我们使用RAG去引入私有数据，而且RAG有很多复杂、烦躁的技术流程、而现在我们直接上传数据即可，效果貌似也挺好了，于是乎最本质的问题来了：
既然，Workspace Agent效果这么好，是否Agent就不需要RAG了?
这背后涉及了两套完全不一样的Agent类型和技术范式：
从用户角度出发，Agent对数据的使用可以分为两类：
第一类是协同类Agent，典型代表是AI Coding Agent，他需要使用者对AI输出内容具备良好的评价/判断能力，也就是说个人专业能力越强，那么这类Agent工具会用得越好；
第二类是知识输出（高可信）类Agent，典型代表是垂直领域的应用如AI医生/AI律师，他不需要你去协同，也不需要你具备专业评价能力，他只需要你被他引导，然后输出最正确的答案。
这里有两个核心差距：
第一是是否需要协同共创
第二是是否保证知识输出的正确性
比如Claude/CodeX这种都属于协同共创类Agent，现在的主流技术架构是：Workspace Agent；
另一方面，一些复杂的行业应用（如AI医生）、AI客服，都还是采用的第二套技术路径Agent+RAG，只不过这里的RAG和大家以为的RAG会相去甚远，其复杂度会高非常多。
在这个基础上，我们再来聊聊Workspace Agent与Agent RAG的一些差异和应用场景：
协同：生产力工具属性
我们对于协同型Agent的核心假设是：使用者需要并具备评判能力，这里的意思是代码写得好不好，接下来怎么改，我们是门清的，AI在这里的意义是杠杆作用，让我们做这件事的效率更高了。
因为是协作共创，所以他是允许错误的，于是对于数据的诉求是：广度和探索性。也就是他没办法给你唯一答案、甚至是稳定的正确答案，比如相同输入拿不到相同输出。
专家：替代的是判断本身
而严肃的Agent RAG面对的场景就很严苛了，比如AI医生/律师，这里的核心假设是：用户不需要也不应该具备专业能力判断，他们应该完全的相信AI的输出；
只要是严肃领域的AI，毋庸置疑追求的一定是：精度和权威性。它要求的是99.9%以上的准确率，且每个结论都必须有据可查，能溯源到权威文档的具体章节，80%的正确率在这里绝对不可接受的！
从实现上，高可信Agent追求的是：
可解释性，必须能准确指出结论来自哪份文档的哪一条，并且还要说清楚CoT是什么，这里可不是那种半吊子思维链，而是必须要符合行业逻辑的思维链
在这个基础上对数据的需求就会变得很苛刻，至于这里数据怎么做，就是各个行业的KnowHow与价值所在了。
综上，我们整个Agent架构选择的递进逻辑就出来了,场景决定需求→需求筛选范式→范式选择架构：
如果你是放大能力，选协同类，走Workspace Agent路线。
如果你是替代判断，选稳定输出类（高可信Agent），走Agentic RAG路线。
接下来，我们再说两者差异导致的优劣问题：
Workspace Agent与Agentic RAG都具备使用私有数据的能力，但他们对待数据的态度就成了他们的核心差异：
Workspace Agent把数据当成工作材料，重要的是协同；
Agentic RAG把数据当成证据来源，重要的是CoT；
工作材料或者证据来源的背后是数据严苛态度，其最终会表现为：技术便利性与数据成本：
你愿意为开箱即用付出什么代价，又愿意为高可信投入多少成本
便利性>正确性
Workspace Agent的最大魅力，在于它几乎消解了数据接入的所有前置成本。
你不需要对私有数据进行复杂的预处理，不需要设计切片策略、不需要TopK...
直接把文件拖进去，Agent就能开始工作。这种上传即用的体验，是大家推崇他的原因。
但这份便利性的背后肯定是有代价的：它要求使用者本身具备评判能力。
也就是，从底层设计上Workspace Agent就追求的是便利性，他把数据准备成本转移到了使用者的判断力，用起来很方便的前提是，你得有本事接住它的输出
严肃性>>便利性
高可信Agent走的是完全相反的路径。它要求在数据进入系统之前，就完成严格的知识建模。
这可不是简单的切片和向量化，我在国外处理过程中有很多心得可供分享：
第一，知识库设计尤为关键，其中最难的是缺点边界与结构，所谓边界是你的AI系统到底要完成什么任务，必须穷举定死；所谓结构，就是知识要能匹配这套系统；
第二，知识梳理的时候要考虑逻辑关系链、要设计实体结构，要找到切入知识库的核心，比如用一个不重样的关键词将知识实体搜索出来，再根据实体结构的逻辑链找到各种关系，只要逻辑链清晰，提示词就好设计，AI就会聪明很多；
第三，在做知识库实体结构时，类型不要太多，如果产生层级，层级也不能太多，因为关系越多工程实现越复杂、层级越多知识库处理越复杂。做AI应用要平衡真实世界的模拟与数据工程实现的ROI，也就是如果工程实现复杂度过高，就要在数据复杂度层面做取舍；
第四，在前三点的基础下需要考虑的是架构实现问题，这里必须由一号位自己写文档做产品甚至是架构设计，不用你写代码，但你文档写完需要相当于伪代码写完了，不然下面产品和技术没那个能力做出来的。这里的架构设计核心是你的知识，如何让AI每次都能拿到、拿对、拿全、不拿多；
第五，在知识齐全的情况下，如何让AI聊得像个人是个封闭性问题，他的前提是知识是对的，如何像人一样表达这段知识，需要考虑什么，需要建模，或者说需要设计策略；
这套成本极高，且高度依赖行业KnowHow。但一旦建成，它的收益也极其明确：输出可解释、可溯源、可审计。
对于不能容忍大概对的场景，这种前期投入是必须的，总结一下就是：高可信RAG，将正确率的成本投入了前期的数据建设，所以就不需要用户有独立判断了。
人有个特点，可以偷懒的话绝不会想要多动一下，所以这里就会有个问题：既然Workspace Agent做知识库表现已经很不错了，是不是RAG那一套就没用了？
额，可能还真不是那么回事，至少现在Workspace Agent更适用的场景是：个人工作空间。
在个人工作空间里面你想怎么玩就怎么玩，但一旦上10个人你再试试，大家会发现，相同的问题就一定有很多不同的理解，那到时候是听叶老师的还是听听王老师的呢？
所以，只要Workspace Agent想要去组织企业的知识库，那么会遭遇很多复杂的工程问题，那么也就失去了他的便利性了；类似的问题在NoteBookLM这种产品里面也会发生。
所以在企业视角来说，技术选择会更倾向于融合，是一种共生关系，这里跟我们之前做生产级AI客服的经验是温和的：80%客户的问题会围绕着20%的场景不停做展开。
其实就算是严肃场景也是一样，最核心的流程使用高可信Agent，其他80%非核心流程敞开聊，让AI自由发挥就好。
这种方式是比较兼顾知识有效性以及数据工程实现成本的方法，因为高可信RAG本质依赖的是行业KnowHow形成的核心SOP/Workflow，与他配合的就是公司那套可信知识内核了。
这个可信知识内核，是企业真正有价值的资产，你要相信着不是一个路人甲员工能够提供的。
跟进一步，高可信不是一个产品形态而是一种风险分层策略。比如AI医生，其实也并不是所有任务都要求那么严苛，他只是在核心流程追求99.999%，比如：诊断、用药、治疗方案...
但其实还有些泛医疗场景包括，运动、饮食建议，其实是不会进入核心逻辑的，这里就会因为风险等级不一样而选择不一样的技术选型。
当然，具体到如何做，这里就展开了，总而言之，复杂度挺高的...
写到这里，可以正面回答那个最本质的问题了：Agent是否需要RAG？
这里其实行业有相对成熟的案例：在Coding Agent这个最成熟的协同类Agent领域，传统RAG正在被主流产品集体抛弃。
Claude Code官方提到过：他们早期版本也在用RAG但效果不好，取而代之的是一种Agentic Search的技术（也就是现在比较主流的技术），让模型自己玩，最后效果比RAG好多了...
这在之前3月份Claude Code代码泄露中有相关证据链，也就是我们是看不到RAG相关技术的痕迹的。
如果从这个角度看，传统RAG似乎确实不是Agent的必要组件。
但是大家要注意，按照我们之前的逻辑，这里的Coding Agent是协作型Agent，他本来就不需要......
所以，如果只用这类的Agent去评判是有点不合理的，如果是高可信Agent，RAG依旧是必须的，但是这个RAG的复杂度却不可同日而语。
两者的核心差异在于对检索这件事的目标和要求完全不同：
Agentic Search追求的是探索效率和覆盖面，模型自己去走ReAct循环，决定搜什么、读什么、要不要再搜一轮。
这套逻辑在处理代码、文档类材料型数据时非常高效，因为数据本身就是给人读的，上下文完整，逻辑自洽。
但高可信场景要的不是这个，它要的是每一次检索都必须拿到、拿对、拿全、不拿多。少拿一条关键证据，结论就可能出错；多拿一条无关信息，反而干扰模型判断，这不是grep加glob能解决的事。
所以，高可信Agent场景下的RAG，肯定不是检索，更确切的说法是知识工程，这里的难点或者工作量在搜索之前就决定了：边界在哪、实体结构如何设计、关系链要完整到什么程度、AI代码工程如何与数据工程做结合......
综上，Agent没有不需要RAG技术，只不是不需要之前那个RAG技术...
回归一下，第二大脑如何做、到底怎么去蒸馏一个人、同事.skill的局限性在哪、他们各自到底在说什么？
我认为今天的内容是有一个不错的回答的：
同事.skill有价值，但它蒸馏的是工作流，这种先做什么、后做什么属于之前数字化转型的延续，核心是吃掉重复工作，目标是降本增效；
要真的蒸馏一个人，这里的关注点就不是动作了，而是要去思考他为什么这么判断、怎么取舍、遇到异常如何决策。
这需要从Workflow再往上走一步，把判断标准、分类逻辑、案例边界等等全部考虑到位，这个就是我们之前说的高可信Agent依赖的数据工程了。
至于Agent需不需要RAG，那是当然需要的，只不过又换了个名字罢了...
