企业上下文层图解

我见过每一个失败的企业AI项目根本原因都一样。不是模型。不是提示词。甚至不是智能体框架。而是缺少地基。团队启动一个智能体来处理采购审批它会毫不犹豫地批准一份200万美元的供应商合同因为没人告诉它三个月前已经更改的政策。或者一个销售智能体使用定价团队在第二季度就已经废弃的企业级定义来回答客户关于定价的问题。智能体没有出错。它运行得很完美只是基于过时的、断连的、不受治理的上下文。这个地基有一个名字。它叫做企业上下文层。如果你在部署AI智能体时没有考虑到这一点你就是在沙子上建房。1、智能体在真实业务中运作实际需要什么想想在一家500人公司入职新员工需要什么。你不会只是给他们一台笔记本电脑然后指向Jira。你让他们访问CRM并简要介绍关键客户是谁。你带他们了解销售流程实际上是如何运作的不是手册中的版本。你解释哪些事情他们可以单独做哪些需要经理签字。这种入职过程大致就是企业上下文层为AI智能体所做的事情。它编码了三类知识业务是什么数据模型、实体、指标。在这里流失率意味着什么如果客户30天或90天没有登录算不算活跃客户哪些账户归入哪些收入线工作实际上是如何完成的流程、例外、判断。不是这是我们的支持升级流程图而是当一个客户距续约还有60天并且有一个未解决的P1工单时我们最好的支持代表实际会做什么。什么是被允许的政策、审批链、合规规则。这个智能体可以起草折扣提案但不能承诺。那个智能体可以读取合同数据但不能发送到第三方系统。没有这三者你的智能体就像在风暴中仅靠仪表飞行。2、架构不讲空话上下文层位于底部的数据和系统与顶部的智能体之间。它有两部分一个底层基质和一组产生、更新和交付该基质的能力。底层基质是三个相互关联的东西。第一AI就绪的知识图谱你的结构化数据通过连接路径、自然语言描述以及人们通常如何查询它的机构理解来丰富。第二语义层你业务的共享词汇表让销售智能体和财务智能体在就如何处理MRR产生分歧之前先就MRR的含义达成一致的术语表。第三技能可重用的、有版本号的程序性知识单元。不是提示词。不是Notion文档。可以进行测试、审批和更新的正式资产当业务变化时也能相应更新。下面的图表展示了这三个底层基质组件如何为该层的五个能力提供支撑以及这些能力如何服务于顶部的智能体。3、没人谈论的问题上下文大部分是未成文的构建企业AI有一个令人不适的现实。最能提升智能体表现的知识不在任何数据库中。它在那些在公司待了三年的人的脑袋里。问你最优秀的销售工程师他们如何评估潜在客户他们会给你一个流程。看他们实际评估潜在客户你会看到不同的东西。他们注意到没人写下来的信号。他们跳过技术上要求但实际上没用的步骤。他们上报那些行动手册说没问题的事情。这就是上下文挖掘的用途。现在我们来讨论这个。一种方法是在人类手动完成工作后观察智能体会话轨迹。如果一个智能体尝试运行月度对账但失败或被纠正了六次那些纠正就是金子。每一个都是一个关于这家公司实际如何结账的未记录假设。另一种方法是结构化访谈领域专家让他们在做决策时同步叙述。你是在逆向工程机构知识而不是从头开始构建。挑战在于这些都不产生成品的上下文。它们产生候选内容。需要经过审核和批准流程才能成为规范的原始材料。这就把我们带到了生命周期问题。4、上下文需要开发生命周期而不是提示词文件夹每个软件团队现在都理所当然地认为代码需要版本控制、测试、审查和部署管道。大多数企业中今天的上下文管理方式就像1992年的软件管理在系统之间复制半记忆状态在每个运行的地方都有微妙的不同。想想一个更新了理想客户画像的公司。销售领导批准了新的ICP文档并通过Slack发送给团队。三个月后SDR外联智能体仍然按照旧定义评估潜在客户。内容营销智能体在写关于新ICP的案例研究。分析智能体在报告两者的混合数据。没人撒谎。只是上下文没有被当作基础设施来管理。实践中上下文开发生命周期的样子新的上下文经过提案阶段由AI完成草拟和初始测试。人类负责人审查并决定它是否成为规范。一旦部署系统追踪哪些东西依赖它。当它变化时下游负责人收到通知必须确认其上下文仍然有效或进行更新。治理部分不是可选的。它是区分上下文层和有野心的数据湖的关键。5、复利循环才是全部意义上下文层之所以值得架构投资原因在于每次智能体运行时它都会变得更好。想象一个采购智能体帮助买家评估新的软件供应商。在对话过程中买家提到他们公司有政策不支持不符合SOC 2 Type II的供应商。这个事实在对话期间存在于工作记忆中。但一旦上下文层接收、验证并将其提升为规范约束每个未来接触供应商评估的智能体都知道这一点。买家再也不需要说一遍了。第十个智能体比第一个更聪明因为第一个已经做了这项工作。大多数团队在部署智能体时并没有在思考这个循环。他们在思考的是单个任务。但上下文层的复利价值来自于系统随时间积累的东西而不是任何单次交互。这也是记忆分类法重要的地方。工作记忆智能体当前正在处理的内容和情景记忆本次会话中发生的内容属于靠近智能体运行时的地方。语义记忆关于业务及其客户的持久事实和程序性记忆工作如何完成属于上下文层内部因为这些是组织想要治理的而不仅仅是存储的东西。6、它不是什么因为这个概念吸引了大量模糊的标签几个对比值得明确说明。语义层是上下文层的一个组件不是它的同义词。语义层是为BI分析师构建的它们在这方面做得很好建模指标、定义维度、驱动仪表板。它们不包括技能。它们不挖掘程序性知识。它们没有部署生命周期。它们是语义底层基质不是整个系统。数据目录是人类的发现工具。它帮助分析师找到正确的查询表。企业上下文层是构建来服务AI作为其主要消费者的。接口不同MCP、向量搜索、图遍历不只是搜索栏治理要求不同内容也更丰富。长期记忆如大多数智能体框架所实现的是一个能力的一个输入。它存储会话历史和用户偏好。这很有用。但它不等同于一个受治理的、有版本的、组织范围的上下文系统——这个系统知道某个客户上周二说了什么与构成公司官方政策之间的区别。7、什么时候值得构建不是每个AI项目都需要上下文层。如果你在构建一个具有窄领域、硬编码检索、没有计划扩展到更多智能体的单一用途智能体其开销不值得。当三个条件为真时计算方式会改变你在部署多个需要共享对同一业务理解的智能体底层知识变化足够频繁使得硬编码的上下文会腐烂智能体基于错误上下文错误的政策、过时的定价、废弃的流程行动的成本高于构建基础设施的成本。在实践中门槛比大多数人预期的要低。到了第三个或第四个智能体缺少共享上下文层就开始产生可见的协调失败。销售和支持智能体在客户应得什么上产生分歧。财务和运营智能体基于同一指标的不同定义运行。这些失败有真实的成本即使很难归因于缺失的架构。地基很重要。在你有四个智能体运行在四个从未互相认识的地板上之前先把它建好。8、你需要正式的上下文层吗你可能需要如果你有三个或更多共享领域知识的智能体你的业务定义至少每季度变化一次智能体基于过时上下文行动会产生合规、财务或客户风险你需要智能体决策的审计跟踪。你可能可以跳过正式构建如果你有一两个窄领域智能体领域稳定且小共享提示词文件和有版本号的文档存储以10%的成本获得90%的价值。从底层基质开始特别是语义。一个防止你的智能体互相说不到一块去的共享术语表其回报速度会比AI技术栈中几乎任何其他东西都快。原文链接企业上下文层图解 - 汇智网