一、为什么”给 AI 喂上下文”已经不够了

第一个问题,知识是互相打架的。同一个产品、同一件客户业务、同一段流程,在不同文档里写的不一样——有时甚至自己跟自己矛盾。把这些信息抽出来塞进 context,矛盾也跟着塞进去了,不同 agent 对同一件事会形成不同的理解。

第二个问题,变更很难传下去。企业知识天天在变,但每个应用都有自己那一套 context pipeline。文档一改、代码一 commit、CRM 字段一调,下游的 chunk、embedding、index 各自更新,各 agent 跑在不一致的”知识版本”上。

第三个问题,大家在重复造同一套管线。A 团队做一份 embedding,B 团队做一份很像的,C 团队也做一份。每条管线独占一个 index、一份存储、一套 retrieval。算力、钱、人力全在重复消耗。

给这三件事的定性很明确:“这不是 context engineering 的问题,这是 knowledge management 的问题。”

企业数据平台当年解决过同一个问题——结构化数据”管理一次、消费多次”,这是 BI 时代的常识。AI 这件事现在也走到同一关:企业知识也要”管理一次、消费多次”。要做的是建一个”企业知识平台”,把企业知识当作共享基础设施来管,而不是让每个 agent 自己攒一份。

二、四层架构:Raw → Refined → Integrated → Serving

这套平台拆成了四层,每层职责互不重叠,可以各自迭代。

Raw 层:原样保留。数据库、PDF、Confluence、Jira、源代、API 返回、邮件、图片、事件流——抓进来之后保持原貌、原出处。这一层不为了”伺候 agent”,是为了”未来能重新处理”——模型升级了、retrieval 逻辑改了、下游某层坏了,都能从这一层从头再来,不用依赖某一两个 agent 的本地副本。

Refined 层:规范化。把异构源数据转成统一的”知识对象”。每条数据带 metadata:文档 ID、产品 ID、源系统、作者、版本、权限、tags、创建时间、修改时间。原始出处保留,身份不丢,版本可追溯。这一层的目的是给”每一条企业知识”一个统一且可治理的形态,不是把它们拼起来。

Integrated 层:建企业级知识图谱。这一步把独立的知识对象连成一张网,按两条线连:一是用业务 ID(产品 ID、客户 ID 等)做硬连接,或者用显式的跨系统引用(Jira 和 Git 之间的 link),或者在完全没有显式关系时用 AI 做 entity resolution。二是按业务逻辑建关系:implemented_by / contains / belongs_to / affects / depends_on——这不是数据库那种外键关系,而是真正描述”业务怎么运转”的关系:谁实现了什么、哪个工作流包含哪几步、哪个服务影响哪个客户。

Serving 层:对外发布,分两类。第一类是共享表示:SQL views、search index、chunks、embeddings、graph、APIs——一次生成,所有 AI app 复用。第二类是agent 专用表示:不再为每个 agent 维护一份独立副本,而是从”企业级知识模型”动态按需组装 context。Product Agent 拿的是 Product Context,Revenue Agent 拿的是 Revenue Context,Customer Support Agent 拿的是 Customer Context,底层是同一份治理过的企业知识。

翻译过来:Raw 是数据湖,Refined 是数据仓库,Integrated 是数据建模,Serving 是数据 API。这套四层架构本质上就是把数据管理的整套范式,套到”企业知识”这件 AI 时代的事上。

三、这套平台到底给企业带来什么

生命周期管理。增量加载、变更传播、版本管理、历史推理——任何一个 agent 都不再需要”每改一次文档就重跑自己的 pipeline”,平台会替你把变更推给所有 agent。

治理和信任。端到端血缘、可追溯、权限、所有权、质量控制、AI 回答可解释性——每个 agent 的输出都能回溯到原始出处,这是合规、上线审查的基础。

可复用的知识服务。共享的 search index、embeddings、graph、SQL views、APIs、动态 context 组装——一次搭好,所有 agent 用,而不是每个 agent 重新搭一套。

持续演化。存储、retrieval、embedding、agent 这些层可以独立升级,反过来 agent 的反馈还能回流到平台里,让企业知识本身越用越准。这就是所谓的”闭环反馈”。

说白了,卖的不是”更好的 RAG”,是”把 RAG 从一个 app 的 feature,升级成企业级的 data platform“。这跟当年”自己写 SQL”→”上数仓”是同一波迁移。

四、下一波竞争点不在 agent,在数据底座

ChatGPT 3 出来到现在快 4 年,行业把几乎所有钱和人砸在了基础模型、RAG 架构、向量库、embedding、MCP、多 agent 框架。这些技术确实把 AI 应用的搭建方式往前推了一大截。但下一波瓶颈不在模型,也不在 agent 框架,是支撑它们的那一层企业数据底座。

AI agent 强不强,完全取决于它吃进去的数据和知识。更好的模型,救不回一份稀烂的文档、不一致的业务定义、断成一片的旧系统。“Garbage in, garbage out” 这条 AI 时代的金科玉律,跟数据仓库时代一模一样。

具体建议:下一波值得投的不是更多 agent,是”每只 agent 都依赖的那个底层”。把企业知识当基础设施来管,而不是当应用级 context 来攒,出来的 AI 才更稳、上线才更快、规模化才不打补丁。

“这本质上不是 RAG 工程问题,是知识管理问题。” 翻译过来就是:从 2023 年到现在我们搭过的所有 RAG、chunking、embedding pipeline,放在”一只 agent + 一个知识库”的场景下都是 work 的;但当 agent 数量一上去、跨系统协作一发生、文档版本一乱,这些 pipeline 之间的不一致就开始反噬。

对大多数企业来说,真要做的事不是再叠一层 RAG,而是退一步:承认”企业知识”本身就是一类新数据,值得用管数据的那套架构去管它。Raw、Refined、Integrated、Serving——这四个词听起来朴素,但把企业知识当成一个独立的数据栈,这件事很多 2026 年的大厂都还没做完整,中小企业更不用说。

如果你正打算今年上 5 个以上 agent,先停一下:你那套 RAG 是不是已经在管 5 份互相不一致的 chunk 仓库了?如果是,”四层架构”是一个值得抄的答案。