企业AI智能体的可靠性取决于背后最混乱的文档

企业AI在很大程度上围绕上下文工程（context engineering）构建。团队连接企业系统、生成文本块（chunks）和嵌入向量（embeddings）、构建检索流水线，并为各个AI应用组装所需的上下文。尽管该方法对孤立的助手（assistants）和副驾驶（copilots）效果良好，但它将企业知识视为特定于应用的上下文，而非一项共享的企业资产。

随着组织部署越来越多 AI应用和智能体（agents），该模型开始失效。不同团队处理相同的文档，维护各自独立的嵌入向量和索引，并对企业同一业务知识形成不一致的表征。挑战已不再仅仅是向AI系统提供上下文——而是管理企业知识本身。

为何仅构建上下文不足以支撑企业AI

当前企业AI的通用做法是为单个应用构建上下文。团队连接企业系统，处理所需信息，生成诸如文本块和嵌入向量等检索表征，并在运行时为智能体组装其所需的上下文。尽管该方法适用于单一应用，但它并未将企业知识作为一项共享的企业资产进行管理。

随着组织部署更多AI应用，该方法因以下三个原因而开始失效。

首先，知识变得不一致。企业知识分散于众多具有不同模式（schemas）、业务定义和更新周期的独立系统中。同一产品、客户或业务流程可能在文档、Jira工单、源代码、CRM系统及元数据中被不同地描述——甚至彼此矛盾。将这些信息提取为上下文并不能解决这些不一致问题；它只是将不一致转移至AI应用，导致不同智能体对企业形成不同的理解。

其次，变更难以传播。企业知识持续演进，但每个应用都维护自身独立的上下文流水线。当文档、代码和业务定义发生变化时，下游的文本块、嵌入向量、索引及智能体上下文各自独立更新，致使AI应用基于同一知识的不同版本运行。

最后，组织反复重建相同的 知识流水线。不同团队处理相同的企业知识，生成相似的嵌入向量，维护各自独立的索引，并为不同应用构建重叠的上下文，从而导致工程工作重复、不必要的基础设施成本以及知识碎片化。

这些问题本质上并非上下文工程问题——而是知识管理问题。企业数据平台（enterprise data platforms）通过一次性管理企业数据并跨应用共享，解决了结构化数据所面临的同样挑战。如今，企业AI也需要同样的架构规范：一个共享的企业知识平台（enterprise knowledge platform），该平台一次性管理知识，并为每个AI应用发布可复用的知识表征。

分层的数据与知识管理系统

企业知识平台相当于面向企业知识的企业数据平台。它并不将文档、源代码、Jira工单、电子邮件、API及其他企业系统视作各个AI应用孤立的输入，而是将其作为一项共享的企业资产进行管理。它通过统一架构摄取、组织、整合、治理并发布企业知识，从而使每个AI应用均消费同一可信的知识基础，而非各自维护其上下文。

为实现这一目标，该平台将知识管理划分为四层，各层职责明确。知识首先以其原始形式保存，随后被规范化为受管知识对象（managed knowledge objects），再连接至统一的企业知识模型（enterprise knowledge model），最终以针对不同 AI应用优化的知识表征形式发布。这种分层设计允许每一阶段独立演进，同时为所有下游应用提供一致的基础。

该平台将企业知识组织为四层：

原始层（Raw）→ 精炼层（Refined）→ 整合层（Integrated）→ 服务层（Serving）

• 原始层（Raw） 保留原始的企业数据源。

• 精炼层（Refined） 将异构数据源转换为受管知识对象。

• 整合层（Integrated） 将跨系统的知识连接为统一的企业知识模型。

• 服务层（Serving） 为AI应用发布可复用且面向智能体特定需求的知识表征。

原始层——保留数据源

原始层从企业系统捕获信息，同时保留其原始形态与来源标识。这可能包括数据库记录与变更事件、PDF及其他文档、Confluence页面、Jira工单、源代码、API响应、电子邮件、图像及事件流。

该层的目的并非使信息直接可供智能体使用，而是维护一个可靠的数据源，以便平台能据此重建下游知识。若提取逻辑发生变更、模型得到改进，或下游表征遭到损坏，信息均可重新处理，而无需依赖某个应用专用的副本。

精炼层——规范化企业知识

精炼层将异构的企业数据源转换为受管知识对象。每个数据源均被规范化为一致的表征形式，同时保留其身份标识、元数据、权限、版本、血缘关系（lineage）以及对原始内容的引用。 

例如，一份产品需求文档被转换为一个结构化知识对象，其中包含文档ID、产品ID、标题、来源系统、作者、版本、权限、标签、创建时间及最后修改时间等元数据，以及与其关联的内容。该表征方式为企业知识管理提供了统一途径，无论其来源是文档、Jira工单、源代码仓库、电子邮件还是API。

在此阶段，平台并不试图连接不同领域。相反，它为每一个企业知识来源建立一个 可复用且受治理的表征 。一旦每个数据源均被规范化为结构化或半结构化的知识对象，整合层即可通过共享的业务实体与关系将它们连接起来。

整合层——构建企业知识模型

整合层将独立的知识对象转化为统一的企业知识模型。它具备两大功能：连接跨系统与跨业务领域的知识，以及建模AI推理所需的业务关系。

知识 通过共享的业务标识符（例如产品ID或客户ID）、显式的跨系统引用（例如Jira与Git链接），或在不存在直接关系时采用基于AI的实体解析技术实现连接。例如，一份描述‘批量发票上传’功能的产品需求文档、一个标题为‘实现发票上传API’的Jira用户故事，以及一份宣布同一功能的发布说明，尽管彼此之间并无显式关联，但可能均指向同一项业务能力。

连接完成后，该平台依据业务逻辑（例如‘由……实现’）对业务关系建模_by、contains（包含）、belongs_to（属于）、affects（影响）、depends_on（依赖于），从而捕捉企业实际运营方式，而非仅记录数据条目之间的链接方式。

与传统的主键和外键关系不同，这些关系描述的是业务工作流、依赖关系、所有权归属及业务影响。它们使AI能够借助对企业整体的统一理解，在工程、产品、客户支持、财务及其他领域间追踪知识。

服务层——向AI发布知识

服务层类似于许多企业级AI应用中所用的上下文层，但其构建于受管的企业知识基础架构之上。它将企业知识模型转换为针对不同AI工作负载优化的表示形式。这些表示形式分为两类。

第一类是共享的企业级表示形式，为所有AI应用提供通用的知识基础。示例包括SQL视图、搜索索引、文本块（chunks）、嵌入向量（embeddings）、图模型及API——这些组件仅需创建一次，即可在整个组织内复用。

第二类是代理专用表示形式。该平台并非为每个AI代理维护独立的企业知识副本，而是根据各代理的具体任务需求，动态地从集成的知识模型中组装出任务专属的上下文。产品代理（Product Agent）、营收代理（Revenue Agent）与客户支持代理（Customer Support Agent）均可消费相同的企业知识基础，同时接收各自职责所定制的不同上下文。

该示意图清晰定义了服务层的高层级模型：

                          企业知识模型                                         │                 ┌─────────────────────┴─────────────────────┐                 │                                               │                 ▼                                               ▼     共享的企业级表示形式         代理专用表示形式   ┌───────────────────────────────┐         ┌──────────────────────────────┐   │ SQL视图                        │         │ 产品上下文                 │   │ 搜索索引                     │         │ 营收上下文                 │   │ 文本块                         │         │ 客户上下文                │   │ 嵌入向量                       │         │ 规划上下文                │   │ 图模型                          │         │ 编码上下文                  │   │ API                             │         │ ……                         │   └───────────────────────────────┘         └──────────────────────────────┘                 │                                                │                 └──────────────────────┬─────────────────────┘                                         │         ┌────────────────────────────┼────────────────────────────┐         ▼                               ▼                               ▼   产品代理                   营收代理                 客户代理

受管知识平台：AI的数据基础

当前大多数企业 知识系统 是为人而非AI而构建的。Confluence页面与文档帮助员工记录并共享知识；Jira使团队得以规划工作并协作；元数据系统则协助分析师理解数据资产。这些系统组织信息的方式，旨在便于人类凭借自身经验、知识与判断力进行搜索、解读与关联。

大语言模型从根本上改变了企业知识的消费方式。机器如今已能理解自然语言、对文档进行推理，并以过去仅人类可实现的方式与企业知识交互。这一转变所需远不止新的AI应用——它更需要一种新型数据基础架构，即将企业知识作为基础设施加以管理，而非将其视为单一嵌入向量。

这一受管的企业知识平台为AI代理提供了数据基础。它通过将企业知识组织成一致、可复用且受治理的数据平台，将面向人类的知识系统转化为面向AI就绪的基础设施。 

这一基础架构使得某些系统能力成为可能——而若每个AI应用都自行构建并管理其上下文，则这些能力将难以甚至无法实现。

该平台还为代理系统中的人在环（human-in-the-loop）与强化学习工作流提供基础。AI代理生成的反馈可重新摄入平台，经验证 、治理，并整合进企业知识模型，随后再发布至下游AI应用。这形成了闭环反馈机制，持续提升企业知识质量，并推动AI代理不断演进。

下一竞争优势在于企业数据基础

自2022年底ChatGPT-3发布以来，业界已在基础模型、RAG架构、向量数据库、嵌入向量、MCP及多代理框架等领域投入巨大努力。这些技术显著提升了AI应用的构建与部署效率。如今，AI应用栈正迅速走向成熟。

下一个瓶颈已不再是模型或代理框架，而是支撑它们的企业数据基础。AI代理的能力上限取决于其所消费的数据与知识质量。更优的模型无法弥补零散的文档、不一致的业务定义、相互割裂的系统或管理不善的企业知识。如同此前所有数据驱动型系统一样，企业AI最终遵循同一原则：垃圾进，垃圾出（Garbage in, garbage out）。

对企业而言，最重要的投资已不再是构建更多AI代理，而是构建支撑 每一个 智能体（agent）。将企业知识视为共享基础设施而非特定应用上下文的组织，将构建出更可靠的AI系统，更快地开发新应用，并在企业范围内规模化部署AI，而无需反复重建相同的知识基础。

企业AI领域的下一项竞争优势将不来自构建更多智能体（agent），而将来自构建每个智能体所依赖的数据与知识基础。

徐淑华（Shuhua Xu）是首席数据工程师。

欢迎加入VentureBeat社区！

我们的客座投稿计划旨在邀请技术专家分享洞见，提供中立、无利益关联的深度分析，主题涵盖人工智能、数据基础设施、网络安全及其他塑造企业未来前沿技术。

阅读更多 来自我们的客座投稿计划——并查看我们的 投稿指南 若您有意撰写并投稿自己的文章，请参阅相关指南！