Agent是否需要RAG技术架构解析

延续周一TGO闭门会的分享思考，核心话题是：如何真正“蒸馏”一个人，以及如果完成了这个动作，又该如何构建企业级的Agentic RAG数据库应用。

怎么说呢，为了适配Agent的发展，模型本身已经向前迈了一大步。最核心的两个能力提升显而易见：

1. 模型本身提供了百万级上下文窗口；
2. 工程能力优化带来的Skills机制，有效缓解了模型输出的不稳定问题。

现阶段，Agent在数据处理方面进步显著，甚至可以说能解决80%左右的问题（数据正确率约80%）。于是，经典的架构范式就浮出水面了。

上图是前段时间爆火的“小龙虾”OpenClaw的大致架构和解决的问题。如图所示，就能理解前阵子各位老板口中的“养虾”到底是什么意思——本质上就是在梳理工作流和SOP。

在这个基础上，衍生出了同事.skill这类概念。很多人想用这种方式去“蒸馏”员工，但从底层架构来看，可能性不大。不过，这里倒是有一些不错的衍生实践，比如Obsidian + Claudian的组合。

类似Obsidian + Claudian这种模式，都可以归类为Workspace Agent（工作区Agent）/知识工作区Agent/文件系统型Agent。它的定义是：

以私有工作空间为上下文，以文件系统为操作对象的协作型知识Agent。

于是，一个最核心的问题产生了：过去，我们依赖RAG来引入私有数据，过程复杂且繁琐；而现在，直接上传数据似乎效果也不错。那么，最本质的问题来了：

既然Workspace Agent效果这么好，Agent是否就不再需要RAG了？

这背后，其实是两套截然不同的Agent类型和技术范式。

协同 VS 高可信

从用户视角出发，Agent对数据的使用可以分为两类：

第一类是协同类Agent，典型代表是AI编程助手（AI Coding Agent）。这类工具要求使用者对AI的输出内容具备良好的评价和判断能力。换句话说，个人专业能力越强，这类Agent工具就越好用。

第二类是知识输出（高可信）类Agent，典型代表是垂直领域的应用，比如AI医生或AI律师。它不需要你协同，也不要求你具备专业判断力，它只需要引导你，并输出最正确的答案。

这里有两个核心差异：

第一，是否需要协同共创。

第二，是否必须保证知识输出的绝对正确性。

像Claude、CodeX这类都属于协同共创类Agent，目前的主流技术架构是Workspace Agent。

另一方面，一些复杂的行业应用（如AI医生）、AI客服，仍然采用第二套技术路径——Agent + RAG。只不过，这里的RAG和大家通常理解的RAG相去甚远，其复杂度要高得多。

基于此，我们可以进一步探讨Workspace Agent与Agentic RAG的差异和应用场景。

协同：生产力工具属性

我们对协同型Agent的核心假设是：使用者需要并且具备评判能力。这意味着，代码写得好不好、下一步怎么改，使用者心里是清楚的。AI在这里的意义是发挥杠杆作用，提升我们的工作效率。

因为是协作共创，所以它是允许犯错的。因此，它对数据的诉求是：广度和探索性。它无法给你唯一答案，甚至无法保证稳定的正确答案，比如相同的输入可能得不到相同的输出。

专家：替代的是判断本身

而严肃的Agentic RAG面对的场景则严苛得多，比如AI医生或律师。这里的核心假设是：用户不需要、也不应该具备专业判断能力，他们应该完全信任AI的输出。

只要是严肃领域的AI，毋庸置疑，追求的一定是：精度和权威性。它要求99.9%以上的准确率，并且每个结论都必须有据可查，能溯源到权威文档的具体章节。80%的正确率在这里是绝对不可接受的！

从实现上看，高可信Agent追求的是：

可解释性。必须能准确指出结论来自哪份文档的哪一条，并且还要说清楚思维链（CoT）是什么。这里可不是那种半吊子的思维链，而是必须符合行业逻辑的严谨推理过程。

在这个基础上，对数据的需求就会变得极其苛刻。至于数据具体怎么做，这就是各个行业的Know-How与价值所在了。

综上所述，整个Agent架构选择的递进逻辑就清晰了：场景决定需求 → 需求筛选范式 → 范式选择架构。

1. 如果你的目标是放大个人能力，选择协同类，走Workspace Agent路线。
2. 如果你的目标是替代专业判断，选择稳定输出类（高可信Agent），走Agentic RAG路线。

接下来，我们聊聊两者差异导致的优缺点。

优缺点

Workspace Agent与Agentic RAG都具备使用私有数据的能力，但它们对待数据的态度构成了核心差异：

1. Workspace Agent把数据当成工作材料，重点是协同；
2. Agentic RAG把数据当成证据来源，重点是思维链（CoT）。

“工作材料”还是“证据来源”，背后是对数据严苛程度的不同，最终会体现在技术便利性与数据成本上：

你愿意为开箱即用付出什么代价？又愿意为高可信投入多少成本？

便利性 > 正确性

Workspace Agent的最大魅力，在于它几乎消解了数据接入的所有前置成本。

你不需要对私有数据进行复杂的预处理，不需要设计切片策略、不需要调优TopK参数……直接把文件拖进去，Agent就能开始工作。这种上传即用的体验，是它备受推崇的原因。

但这份便利性的背后肯定有代价：它要求使用者本身具备评判能力。

也就是说，从底层设计上，Workspace Agent追求的就是便利性。它将数据准备的成本，转移到了使用者的判断力上。用起来很方便的前提是，你得有本事接住它的输出。

严肃性 >> 便利性

高可信Agent走的是完全相反的路径。它要求在数据进入系统之前，就完成严格的知识建模。

这可不是简单的文本切片和向量化。在实践中有几个关键心得：

第一，知识库设计尤为关键，其中最困难的是定义边界与结构。所谓边界，就是你的AI系统到底要完成什么任务，必须穷举并确定下来；所谓结构，就是知识组织方式必须匹配这套系统的运行逻辑。

第二，梳理知识时要考虑逻辑关系链、设计实体结构，并找到切入知识库的核心。例如，用一个不重复的关键词将知识实体检索出来，再根据实体间的逻辑链找到各种关系。只要逻辑链清晰，提示词就好设计，AI的表现也会聪明得多。

第三，构建知识库实体结构时，类型不宜过多。如果产生层级，层级也不能太深。因为关系越多，工程实现越复杂；层级越多，知识库处理越复杂。做AI应用要平衡真实世界的模拟与数据工程实现的投资回报率（ROI）。如果工程实现复杂度过高，就要在数据复杂度层面做取舍。

第四，在前三点的基础上，需要考虑架构实现问题。这里必须由一号位亲自撰写文档，进行产品和架构设计。不需要你写代码，但你写完的文档需要相当于伪代码完成了。否则，下面的产品和技术人员很难实现。这里的架构设计核心是：如何确保AI每次都能拿到、拿对、拿全、不拿多所需的知识。

第五，在知识齐全的情况下，如何让AI的对话像人一样自然，这是一个封闭性问题。前提是知识是对的，而如何像人一样表达这段知识，需要考虑什么，需要建模，或者说需要设计策略。

这套体系的构建成本极高，且高度依赖行业Know-How。但一旦建成，它的收益也极其明确：输出可解释、可溯源、可审计。

对于不能容忍“大概对”的场景，这种前期投入是必须的。总结一下就是：高可信RAG，将保证正确率的成本投入了前期的数据建设，因此就不再需要用户具备独立判断能力了。

二八逻辑

人性有个特点：能偷懒就绝不会多动一下。所以这里会产生一个问题：既然Workspace Agent做知识库表现已经很不错了，是不是RAG那一套就没用了？

嗯，可能还真不是那么回事。至少目前来看，Workspace Agent更适用的场景是：个人工作空间。

在个人工作空间里，你想怎么玩都行。但一旦扩展到10个人的团队，问题就来了。大家会发现，相同的问题一定会有很多不同的理解。到时候，是听叶老师的，还是听王老师的呢？

所以，只要Workspace Agent试图去管理企业的知识库，就会遭遇许多复杂的工程问题，从而失去其最大的优势——便利性。类似的问题在NoteBookLM这类产品中也会发生。

因此，从企业视角来看，技术选择会更倾向于融合，是一种共生关系。这与之前做生产级AI客服的经验是吻合的：80%的客户问题，会围绕着20%的核心场景不断展开。

其实，即便是严肃场景也一样。最核心的流程使用高可信Agent，其他80%的非核心流程则可以敞开聊，让AI自由发挥就好。

这种方式是比较兼顾知识有效性以及数据工程实现成本的方法。因为高可信RAG本质上依赖的是由行业Know-How形成的核心SOP/工作流，与之配合的正是公司那套可信的知识内核。

这个可信知识内核，是企业真正有价值的资产。要相信，这不是一个普通员工能够轻易提供的。

更进一步说，“高可信”不是一个产品形态，而是一种风险分层策略。比如AI医生，也并非所有任务都要求那么严苛。它只是在核心流程（如诊断、用药、治疗方案）上追求99.999%的准确率。

但实际上，还有一些泛医疗场景，比如运动、饮食建议，并不会进入核心逻辑。这里就会因为风险等级不同，而选择不同的技术方案。

当然，具体到如何实施，这里就不展开了。总而言之，复杂度相当高。

Agent是否需要RAG

写到这里，可以正面回答那个最本质的问题了：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？当然是需要的，只不过，它又换了个名字罢了。