我来把这事儿说清楚，最近大家老说RAG是不是凉了？其实没那么玄乎，它只是不想再戴着高帽子当摆设了，彻底回归到最基本的大数据基建上去。你看这几年 Skill 和 OpenClaw 这类工具兴起之后，老一代的 RAG 确实是被讨论得少了，大家都觉得它过时了。但你要是问我这个深耕企业知识库的工程师怎么看，我得说它真没死，反而把那些花哨的外衣都脱了，露出了扎实的数据底子。 说到现在的技术底座已经变样了，基座模型的 Zero-shot 推理能力超强，指令执行得也很听话，长文本上下文窗口能突破老界限，信息提取衰减也逼近了工程师能接受的范围。最关键的是用 token 的成本还在不停地往下掉。这下好了，RAG 那个负责生成内容的环节（G），已经没多大必要让程序员去做那么多干预了。 以前因为模型能力不行，我们在生成端不得不多加小心——提示词工程、风格控制、多轮对话管理之类的都干了一遍，想让模型回答得漂亮点。但现在模型自己本来就专业还懂逻辑，我们加的这些外部约束反而是在给它设限。 大家追捧的 Agentic RAG 其实也不是万能的，非要人工排定那么复杂的 Workflow 或者构建智能路由器，本质上就是对控制流的执着太深了。这很快就会变成系统的一个大累赘。 真正的出路是把那些复杂的事都推到数据治理层面去处理。让模型面对那些已经整理好的、信噪比很高的知识体系就好。 未来知识库长啥样？它会变成智能体的数据代理（Data Proxy），作为一个 Skill 或者遵循 MCP 协议的服务器存在。以后探索企业里的各种异构数据时，就靠着这唯一的标准代理去办。 核心其实就两点： 第一是要把那些杂乱无章的数据治理好，重新塑造一下“知识单元”的概念。你得按照文档的原始结构去搭建节点，还得把图表、附件这些资源都挂上去，把完整的业务逻辑全都留着。 第二是搞渐进式搜索。把搜索能力给那些知识节点加上去，让它们有个“可展开”的属性。然后向模型开放 Search（全局定位）和 Explore（局部下钻）的 API，让模型自己在里面闲逛探索。 这样做虽然会让交互稍微慢点，但现在 token 用得便宜了，换来的是复杂问题回答的绝对准确性。在 ToB 这种商业场景下这么权衡是合理的。 RAG 没消失，只是干完了它那个阶段的活儿。知识库工程师以后的主战场变了，不再是绞尽脑汁教模型怎么说话了。咱们要的是给企业数据铺路修条高速公路，让它读取起来又快又准。