各行各业的企业正在大力投资语义层，以确保 AI 能够理解企业的语言。在《为何你的 AI 战略存在语义问题》一文中，我曾指出，要实现 AI 的规模化应用，必须构建一个强大的语义层。这一观点依然成立，但这仅是问题的一半。解决了语义问题的企业，其智能体能够就数据的含义达成一致；然而，它们仍然缺少能够理解企业运作机制的智能体：即连接决策与结果的流程链条、将供应商延迟与现金流影响关联起来的实体关系，以及规定 AI 智能体可以做什么和不可以做什么的组织政策。这正是业务上下文层，它是企业级 AI 不可或缺的一环。

VentureBeat 2026 年的调查显示，68% 的企业在过去六个月内发现，智能体给出的自信但错误的回答，根源在于缺失或不一致的业务上下文。这一差距并非模型本身的问题；模型本身完全具备相应能力。这是一个上下文问题：不了解业务运作机制的智能体，无法被委以生产决策的重任。而业务上下文层正是弥合这一差距的关键。

流程智能鸿沟：AI 了解数据，却不懂业务

任何企业的业务上下文都不可能完全存在于单一系统之中。每家企业都依赖于相互关联的流程运转，经验丰富的员工能够凭直觉驾驭这些流程——采购审批链、财务结账程序、客户升级路径，以及数百种其他从未被完整记录但执行者却深谙其道的工作流。如果一个 AI 智能体缺乏这种流程智能，其运行方式就如同一名新入职员工，虽然能访问文件系统，却不知决策是如何做出的——它生成的结果在事实上正确，但在实际操作中却是错误的。它会释放一笔因合规冻结而被阻断的付款，而该冻结信息并未体现在任何数据字段中；它会启动一项供应链调整，却违反了存于 PDF 文档（而非 ERP 系统中的表格）中的供应商合同条款；它会提出一项人力配置建议，却与人力资源政策相悖，而这项政策从未被录入系统，因为它只是“我们这里一贯的做法”。

SAP Knowledge Graph 通过将 SAP 业务流程编码为机器可读的企业运营连接地图，直接解决了 SAP 流程智能的缺失问题。当智能体遍历一个流程链——采购申请 → 审批工作流 → 采购订单 → 货物收货 → 发票校验 → 付款——时，它并非从历史数据的统计模式中推断关系，而是遵循一套受控且明确的流程运作方式及其依赖关系的地图。而是遵循一份受治理的明确图谱，清晰呈现该流程的运作方式以及各项依赖关系。对于来自非 SAP 系统的更广泛流程上下文，SAP Business Data Cloud（BDC）支持在 SAP HANA Cloud [HANA 云] 中构建自定义的知识图谱。

业务上下文层必须从所有可能存在的位置——无论是 SAP 系统还是非 SAP 系统——提取流程智能，并在 AI 智能体部署前为其提供一致且受控的企业视图。碎片化的上下文会导致决策不一致，而事后补救的成本远高于前期编码。

机构记忆危机：人员离职后留下的空白

每家企业都拥有两类知识。第一类是显性知识——记录在系统中、编码在政策里、存储于数据库中——AI 可以直接访问这些信息。第二种是制度性知识。这种知识存在于经验丰富的员工头脑中，包括积累的判断、非正式规则和组织智慧，而所有 AI 系统都无法查看这些内容。当这些经验丰富的员工离职时，那些隐性知识——例如如何在标准合同条款之外处理供应商纠纷、当常规审批路径不可用时应选择哪条替代路径、CFO 对资本支出例外的实际容忍阈值等——并不会传递给接替他们的团队，更不用说传递给如今被期望自动化这些工作流的 AI 智能体了。其后果十分严重：一个每月处理 10,000 次采购决策的智能体，必然会遇到超出其明确流程逻辑的边缘情况。如果缺乏编码在上下文层中的制度性知识，该智能体要么将所有问题都转交给人类处理，从而破坏自动化的效率优势；要么反复做出看似合理但实际违反未明文规定的组织规则的决策，直到有人注意到为止。

SAP Company Memory 是一种机制，使组织能够将其特有的政策、审批层级和制度规则编码到 AI 的上下文层中，从而使智能体基于其所在组织特定版本的业务知识运行，而不仅仅是遵循 SAP 的标准流程逻辑。作为一种受控的知识资产，它具有明确的所有权和定期维护机制，这正是那些 AI 能力随时间提升的组织与那些因机构知识流失而导致 AI 性能下降的组织之间的关键区别。

非结构化上下文问题：当业务逻辑存在于文档中

组织的大量业务上下文并未存储在结构化系统中，而是存在于合同、合规指南、高管备忘录和标准操作规程等文件中——这些文件定义了实际允许、优先和预期的行为。这种非结构化的上下文往往决定了一个 AI 决策是否具备法律可辩护性，还是可能带来责任风险。如果 AI 智能体在推荐采购行动时无法访问相关合同条款，那么它做出的并非明智决策，而只是基于统计可能性的猜测，却可能带来实际后果。

SAP HANA Cloud 向量引擎结合 RAG 技术，可在同一受控且具备访问权限管理的环境中，将企业文档的向量嵌入与结构化业务数据一同存储和处理——这意味着文档上下文会自动继承现有的访问控制和合规规则。其结果是一种混合架构，能够模拟经验丰富的决策者的工作方式：在行动前同时参考明确的流程知识和相关文档。

多智能体流程级联：当上下文缺失大规模发生时

单个智能体的 AI 故障是可见且可控的，而多个智能体的故障则不然。在一个协调的工作流中——例如采购智能体、财务智能体和供应链智能体依次执行一个关联流程的不同步骤——第一个智能体出现的上下文缺失不会孤立存在。它会成为第二个智能体的输入，后者将其视为权威信息，并以此生成输出，再作为第三个智能体的输入。等到整个流程完成时，最初的上下文错误已被放大，并在多个系统中被执行，往往在任何人工干预之前就已造成影响。对 IT 领导者而言，其含义十分明确：业务上下文层不仅仅是单个智能体质量提升的手段，更是防止流程错误在互联的工作流中引发连锁故障并造成不可逆后果的治理机制。

每一次缺乏共享且受控的流程上下文的交接，都是潜在失败的节点。而共享的业务上下文层是唯一能在执行前中断这一风险的架构机制。

领域所有权——上下文的组织架构

构建可信上下文的责任需要两个层面的所有权：一是业务层面的所有权，由各领域负责人定义并验证组件的含义；二是数据架构师和数据所有者负责在系统间维护、治理并强制执行这些定义。财务部门拥有期末结算流程的定义权，采购部门拥有审批链规则的所有权，人力资源部门掌握员工政策约束的所有权，中央 IT 则可提供基础设施与治理框架。这意味着各业务领域团队需对其流程定义的准确性负责，而中央 IT 则负责制定标准、版本管理协议和质量控制措施，以确保各领域之间的一致性。这种方式有助于上下文层及时更新，紧跟每一次流程变更，而不是滞后。如果企业将上下文视为中央 IT 的职责，则随着业务不断发展，其上下文层将始终处于过时状态。

SAP BDC 通过为每个业务领域提供独立且受控的工作空间，使其能够自主定义并维护自身的流程规则和上下文定义，同时提供预先构建、由 SAP 管理的领域数据产品，从而避免从零开始编码核心业务逻辑。中央 IT 负责治理共享基础设施、版本管理和访问控制，而各领域团队则通过企业记忆机制，将特定企业的策略扩展至系统中，确保上下文层在业务演进过程中始终保持准确。

业务上下文层的成本

业务上下文层并非即插即用。供应商提供框架和工具，但客户仍需自行构建大部分内容。真正的成本并不在于向量数据库、知识图谱许可证或初始建设，而在于随之而来的持续累积负担：随着业务发展，需要持续投入工程资源以保持流程图的时效性；当新系统或并购引入时，需要专家人才来扩展和维护知识图谱；不同业务部门之间流程定义冲突时，还需进行协调对齐工作；同时，随着上下文资产不断扩展，版本管理、沿袭追踪和访问控制等治理开销也日益增加。当智能体部署规模扩大到数百个时，这些成本将呈指数级叠加。一旦生产环境中的智能体产生错误答案，企业将面临成倍增长的补救工作。正因如此，对于业务上下文层而言，自建与采用的选择比语义层更具决定性意义——其持续成本曲线更为陡峭。

SAP BDC 提供了一条不同的路径。其治理数据产品架构将语义层直接嵌入到各个领域的数据产品中，SAP Knowledge Graph 预先加载了 SAP 的流程专业知识，SAP Company Memory 捕获组织的程序性知识，而 SAP HANA Cloud 向量引擎则提供托管的 RAG 基础设施——所有这些都在同一治理边界内。它们共同使 IT 团队能够专注于真正体现组织差异的关键要素：企业特定规则、机构知识以及非 SAP 数据的集成。

上下文中的治理与合规维度

没有业务上下文，就无法做出可辩护的 AI 决策。欧盟《人工智能法案》要求自主 AI 系统必须证明其决策是在明确且可审计的业务约束范围内做出的，且回答必须引用具体指导该决策的业务规则、审批政策或流程限制。只有当业务上下文被明确编码、版本化，并在决策生成时与代理的决策相链接，这样的回答才可能实现。在高风险系统中，要符合欧盟《人工智能法案》的要求，既需要提供数据沿袭的语义层，也需要提供决策约束可追溯性的业务上下文层；仅靠其中任何一层都不够。

对于设计 AI 治理框架的企业架构师而言，业务上下文层并非可有可无的补充，而是构建监管合规性的技术基础。

结论：了解业务运作方式的智能体将赢得胜利

在智能体时代脱颖而出的企业，将是那些其智能体真正理解业务运行机制——包括流程、政策、实体关系以及将数据转化为决策的组织知识——的企业。那些已经建立起语义基础，并正在思考如何让智能体实现可靠运营的组织，其实早已知道答案。业务上下文层正是这个方程缺失的一半，没有它，AI 投资积累的将是风险而非价值。

关键问题在于：你是选择在智能体投入生产前就构建它，还是等到它们大规模输出错误结果后，再付出更高代价进行重构？