回到主页

企业级场景工程:从场景图谱到生产级人工智能

Enterprise-Class Context Engineering: From Context Graphs to Production AI

· 场景工程,场景图谱,AI

作者:Arindam Banerji

原文:https://www.dakshineshwari.net/post/enterprise-class-context-engineering-from-context-graphs-to-production-ai

场景图谱是必不可少的,统一场景层(UCL)能让场景图谱真正发挥作用——构建能够消费、学习和行动的系统。这才是智能体真正实现自主的方式。

Section image

问题与解决方案,尽在一图。 供应商延误,风险评分飙升,截止日期临近。没有UCL时:数据孤立,纠纷持续 2-3 天,流程不受监管,没有审计追踪。有了 UCL:四个数据源融合为一个统一的平台,情境分析对信号进行评分和路由,三个协作方接收受监管的上下文信息包,证据账本记录每一个决策——从 08:15 检测到信号到第 4 天准时交付。

执行摘要

企业级人工智能正在大规模失败。标普全球市场情报公司的数据显示,到2025年,42%的公司将放弃大部分人工智能项目,高于一年前的17%。对财富2000强企业部署情况的行业分析表明,87%的企业级人工智能实施未能达到投资回报率目标。智能体会造成上下文信息碎片化,并且在没有合约的情况下将数据写回运营系统。

问题不在于模型能力。基础模型已经发展得非常完善。问题在于环境——支离破碎、缺乏管控,并且被视为副产品而非精心设计的基础设施。

场景图谱已成为一个引人注目的理论——它以结构化的方式表示企业知识,使人工智能能够进行推理,而不仅仅是检索。但上下文图作为一种数据结构是必要的,而非充分的。一些难题仍然悬而未决:

  • 智能体决策: 智能体必须分析情境并做出决策,而不是遵循脚本。这需要系统能够“消费”图:遍历图、推理、评估选项并确定响应。否则,智能体就无法真正自主。
  • 代理生产化: 部署必须在运行时不断演进。这需要基于图进行操作的系统:创建、合并、修改、连接——每次执行都积累智能。否则,代理在发布后就会停滞不前,并在生产环境中逐渐失效。
  • 企业集成: 企业在ERP、EDW、流程挖掘和IT服务管理(ITSM)等领域投入了数十年时间。这些系统蕴含着企业所需的信号和机构知识。任何解决方案都必须整合这些投资,而不是忽略它们。

将元数据直接导入 Neo4j 并不能让智能体正常工作。你需要消费结构 (读取系统的机制)、变更操作(写回系统的机制)以及受控激活 (安全运行的机制)。这才是真正自主智能体与脚本辅助驾驶系统之间的区别。

本报告将统一场景层 (UCL)视为企业级上下文工程的领先架构——该架构实现了上下文图的运行,并使真正自主的代理能够在企业治理中运行。

1. 场景工程:一门正式学科

1.1 定义和范围

上下文工程是对大型语言模型在推理时所接收的所有信息进行系统化的设计、优化和管理。这一定义源于对超过1400篇研究论文的调查(arXiv 2507.13334),并将上下文工程确立为一门超越简单提示设计的正式学科。

  • 范围包括:系统指令和提示、对话历史和记忆、检索信息、工具定义和模式、结构化输出约束以及治理机制。
  • 关键洞见:LLM 的功能类似于一种新型操作系统。模型充当处理器;上下文窗口充当工作内存。上下文工程负责管理每个推理步骤中占据该窗口的内容。
Section image

图1:上下文工程分类——三层堆栈,分别展示上下文管理、上下文处理、上下文检索和生成

1.2 理解-生成不对称性

一项关键发现:模型在理解复杂语境方面表现出卓越的能力,但在生成同样复杂的输出方面却举步维艰。在 GAIA 基准测试中,人类受试者的成功率高达 92%,而配备插件的 GPT-4 的成功率仅为 15% 左右(arXiv 2311.12983)。这是合成失败,而非检索失败。

这意味着:仅仅提供更多背景信息是不够的。背景信息的结构、顺序和呈现方式决定了模型能否将理解转化为有效的自主行动。

2. 行业中的建筑方法

目前已涌现出四种架构框架。每种框架都针对不同的方面,但也都存在特定的局限性,阻碍了智能体真正自主运行。

2.1 模型上下文协议 (MCP):集成标准

Anthropic 的 MCP 解决了 N×M 集成难题,建立了一个通用协议,将 AI 应用与数据源解耦。该生态系统包含 75 多个生产级连接器,并于 2025 年 12 月捐赠给了 Linux 基金会的 Agentic AI 基金会。

局限性: MCP 解决的是连接问题,而非治理问题。它支持集成,但并不强制执行语义、情境分析或受控激活。代理可以连接到数据,但无法自主地对数据进行推理。

2.2 Google ADK:场景作为编译视图

Google 的代理开发工具包将上下文信息构建为编译后的视图——源代码 → 编译器管道 → 编译后的视图。它旨在解决三个问题:成本/延迟螺旋式上升、信号劣化和推理漂移。

Section image

图 2:ADK 架构 — 源代码 → 编译器流水线 → 编译后视图

局限性: ADK 提供编译规范,但并未解决流程技术融合、多用户支持或受控激活等问题。代理程序能够获取更完善的上下文信息,但仍然遵循预设路径。

2.3 智能体场景工程(ACE):自我改进手册

ACE框架(arXiv 2510.04618)将上下文视为不断演化的剧本——生成器→反射器→策展人。它在智能体基准测试中实现了10.6%的性能提升,并将适应延迟降低了82-91%。

Section image

图3:ACE架构——生成器→反射器→策展人围绕演进的剧本循环

局限性: ACE 能够实现自我改进,但需要企业环境作为改进的基础。如果没有企业系统的规范化上下文,行动手册又能从中学习到什么呢?智能体只能在孤立的环境中改进,与企业实际情况脱节。

2.4 场景图谱:必要但不充分

Foundation Capital 的“上下文图”理论指出了一个万亿美元的机会:图不仅能捕捉状态,还能捕捉决策轨迹——决策的制定原因、批准的例外情况、存在的先例。

这很有说服力——但上下文图作为一种数据结构并不能解决难题:

智能体决策问题: 智能体必须分析情境并做出决策,而不是照搬脚本。Neo4j 中的数据无法做到这一点。你需要一个情境分析器——一个能够处理图数据并生成决策的系统。如果没有它,智能体就无法应对新情况;它们最终会求助于人类。而人类仍然是瓶颈所在。

代理生产化难题: 部署必须在运行时不断改进。图数据库存储数据。你需要运行时演化系统 来回写回学习成果——创建新模式、合并实体、修改关系、连接决策轨迹。否则,代理在部署后会停滞不前,性能下降。

企业集成难题: 忽略现有IT基础设施的上下文工程方法忽略了一个根本现实。企业在ERP、EDW、流程挖掘和IT服务管理(ITSM)方面投入了数十年。这些系统包含着企业所需的信号和机构知识。任何未能集成这些系统的架构都无法实现企业协同效应。

Section image

图4:上下文图:为什么结构胜过字符串——从“存在什么?”到“需要采取什么行动?”

3. 是什么让场景工程成为“企业级”技术?

企业级环境工程需要七个维度,缺少任何一个维度,代理都无法在生产环境中可靠或自主地运行

Section image

图表 5:企业级情境工程——生产级 AI 系统所需的七个维度

Section image

缺少任何一个维度都会破坏系统,并阻止智能体实现真正的自主性。

4. 统一场景层:企业级场景工程的领先架构

统一上下文层 (UCL) 提供了所有七个维度,解决了上下文图本身无法解决的难题,并使真正自主的代理能够在企业治理中运行。

4.1 六大范式转变

转变 1:上下文成为受管控的产品。 上下文包采用版本控制,并设有评估门槛(可回答性@k ≥90%,可引用性@k ≥95%,忠实度 ≥95%)。

转变2:异构数据源整合。 流程智能、ERP系统、网络信号通过一个共同的语义层汇聚。

转变3:元数据成为推理的基础。 元图是上下文图的运行化实现。

转变4:一种底物服务于所有消费模型。S1(BI)、S2(ML)、S3(RAG)、S4(代理)、激活。

转变5:激活完成受控流程。包括预写验证、职责分离、回滚和证据账本。

转变6:情境分析赋能自主行动。智能体能够根据上下文进行推理、分析情境并做出决策,而不是照搬脚本。这才是智能体真正自主的关键所在。

4.2 八种模式

Section image

这些模式共同构成了受控的底层结构。但底层结构本身并非最终状态。UCL 的变革性之处在于,这一底层结构如何滋养并赋能一个复合型架构——以及该架构如何催生真正自主的智能体。

Section image

图 6:UCL 底层架构:代理网关——顶部为情境分析平面(模式 8),下方依次为控制平面、元数据平面和数据/服务平面

4.3 复合架构

Section image

图表 7:我们获胜的原因:复合护城河——UCL 提供数据结构,智能体工程提供智能,两个循环都从累积语义图读取数据并向其写入数据】

整合现有企业投资

UCL 将现有企业系统视为一流的上下文数据源。ERP 提供事务真实数据。流程挖掘提供运营智能。EDW 提供历史模式。ITSM 提供系统状态。这些投资不会被替换——它们通过共享合约连接起来,使代理能够跨企业范围进行推理,并在现有基础设施上实现新的投资回报率。

累积语义图

该架构的核心是:累积的语义图,它接收来自两个方向的输入。UCL 提供结构信息——实体定义、KPI 合约、流程模式和异常分类。运行时系统提供智能信息——执行轨迹、解决模式、结果评估和学习到的行为。这些图并非静态数据存储,而是动态的底层架构,会随着每个工作流程的进行而不断成长。

两个复合循环

模式 8(情境分析器)是入口——但它在一个双环架构中运行:

  • 循环 1 — 每次运行都更加智能: 运行时演进持续优化部署。路由规则、提示模块和工具约束会根据结果进行调整。学习结果会写回图表:创建新模式、合并重复项、修改关系。
  • 循环 2 — 跨运行更智能: 情境分析基于累积的模式进行推理,以评估、分类和决策。决策轨迹会写回以供未来学习。每个工作流都会丰富下一个工作流所继承的基础。

两个循环都会从累积的语义图中读取数据并向其写入数据。上下文信息为两者提供输入。每个工作流程都会使下一个工作流程更加智能。这正是真正自主的智能体与脚本化的副驾驶之间的区别——它们能够学习、适应并处理新的情况。

受控激活闭环

仅凭推理而不采取行动是不完整的。UCL 的受控激活机制确保自主决策能够转化为安全、可审计、可逆的行动:

  • 写入前验证 确认模式权限和幂等键
  • 职责分离 确保了敏感内容写入的审批流程。
  • 回滚功能 确保任何操作都可以撤销(目标:≤5分钟)
  • 证据账本 记录了完整的链条:信号 → 背景 → 决策 → 行动 → 结果

这正是实现企业级成果的关键所在——数据处理时间缩短 11 天,准时交付率从 87% 提升至 96%,平均修复时间从数小时缩短至数分钟。这不仅仅是停留在仪表盘上的洞察,而是能够根据证据自主采取行动的智能体。

一个受控的底层系统,多个自主副驾驶

企业级情境工程的强大之处在规模化应用中显露无疑。只需构建一次底层架构,即可在其上部署多个协同平台。每个协同平台都能继承完整的情境基础设施:融合的企业信号、强制执行的合约、可用的情境分析以及随时可控的激活机制。所有协同平台都无需从零开始,而是能够受益于其他所有协同平台积累的智能。

Section image

图表 10:上下文工程:一个受控底层,多个自主副驾驶——展示了上下文工程底层,包括数据平面、控制平面和激活平面,用于支持重大事件响应、服务台分类、访问履行、财务结算和准时交付救援。

采购差异和净效应副驾驶

这就是“一次构建,多次部署”的价值主张:重大事件响应与财务结算对账共享上下文基础设施。OTIF救援继承了与采购差异监控相同的受控激活机制。底层架构不断叠加;每个组件都为下一个组件的运行提供加速。

5. 行业应用案例:UCL 与其他替代方案的比较

三个场景说明了为什么企业级环境工程需要 UCL,以及为什么其他替代方案无法实现真正​​的自主代理。

5.1 发票异常处理服务(采购到付款)

场景: 发票被冻结——三方匹配失败。需要:提取合同条款、找出根本原因、确定解决方案、执行解决方案、收集证据。

Section image

与UCL合作的结果: DPO缩短11天。释放2700万美元营运资金。自主处置——例外情况上报;其他一切照常进行。

5.2 OTIF 恢复(供应链)

场景: OTIF(准时交付率)下降。需要:将ERP系统与流程挖掘相结合,找出根本原因,制定补救措施,执行补救措施,并验证其有效性。

Section image

与伦敦大学学院合作的结果: 当日完成​​根本原因分析。准时交付率从 87% 提高到 96%。在政策框架内进行自主补救。

5.3 重大事件拦截(IT运维)

场景: 服务器在凌晨 2 点出现延迟峰值。需要:关联变更、评估影响范围、决定补救措施、执行补救措施、收集证据。

Section image

5.4 能力差距

上述用例揭示了一个一致的模式:不同的方法各自提供部分功能,但没有一种方法能够提供真正自主代理所需的完整系统。第三节中的七个企业级维度为评估提供了一个客观的框架。

Section image

图表 9:企业上下文工程能力矩阵——架构方法在生产级 AI 能力方面的现状,展示了 MCP、ADK、ACE、上下文图和 UCL 在所有七个维度上的评估结果】

矩阵使差距显现出来:

  • MCP提供连接,但仅此而已——代理可以访问数据,但不能对其进行推理、做出决定或安全地采取行动。
  • ADK增加了编译规范和部分治理,但缺乏流程融合、情况分析和受控激活——代理会提出建议,但不会采取行动。
  • ACE能够进行学习,但没有企业底层环境可供学习——智能体在孤立状态下改进,与企业现实脱节。
  • 上下文图 提供了数据结构,但没有消费、变异或激活系统——数据存在,但代理无法使用它。
  • UCL提供了所有七个维度——这是唯一能够让智能体进行推理、决策、行动和学习的架构。

关键在于:每个人都只有零散的组件。只有伦敦大学学院(UCL)拥有能够相互连接、不断完善的系统。这并非是逐步添加功能的问题——而是架构上的缺陷。局部解决方案无法拼凑成完整的方案,因为它们缺乏基础架构。

Section image

这些用例和能力矩阵证明了核心论点:企业级上下文工程不仅仅是更好的上下文,而是使代理能够在企业治理中真正自主运行。

6. 为什么这件事现在很重要

投入:

这些数字令人触目惊心:

  • 2025年, 42%的公司将放弃大部分人工智能项目(标普全球市场情报,2025年3月)——高于一年前的17%。
  • 87%的企业 RAG 部署未能达到预期的投资回报率(Fini Labs 对 50 多个财富 2000 强企业部署案例的分析,2025 年 7 月)
  • 68%的已部署智能体在需要人工干预之前执行 ≤10 个步骤(加州大学伯克利分校,arXiv:2512.04123,2025 年 12 月)
  • 63%的企业认为输出不准确是其面临的最大人工智能风险(麦肯锡全球调查,2024 年 5 月)。

诊断

这些是上下文问题,而非模型问题。基础模型已经发展到相当强大的程度,并且很大程度上实现了商品化。差异化优势已从模型选择转移到上下文架构。

那些在人工智能领域失败的企业并非选择了错误的模型,而是将上下文视为事后才考虑的因素:上下文分散在各个系统中,缺乏管理,并且是针对每个用例临时拼凑的。每个新的“副驾驶”都从零开始,没有任何累积效应。智能体无法自主运行,因为它们缺乏推理的基础。

时机

构建上下文基础设施的窗口期现在是:

  • Gartner预测, 到2028年,33%的企业软件将包含智能体人工智能,而2024年这一比例还不到1%。
  • 但报告警告称 ,由于成本不断攀升、商业价值不明朗或风险控制不足,到2027年底,超过40%的智能体人工智能项目将被取消。
  • 这种复利效应 意味着先行者能够积累优势,而后入者则无法弥补。

语义图谱的累积形成一道不断增强的护城河。每个工作流程都会丰富底层架构。每个解析模式都会为未来的决策提供信息。每个自主行动都会提升智能。现在构建这种基础设施的企业将拥有真正自主的代理,而竞争对手还在编写辅助驾驶脚本。

选择

企业面临非此即彼的选择:

  • 将上下文视为事后考虑 ——信号碎片化、临时拼凑、无序激活。智能体将所有问题都上报给人类。加入放弃人工智能项目的42%行列吧。
  • 将上下文视为受控基础设施 ——企业信号统一,代理进行推理和决策,激活过程利用证据形成闭环。真正自主的代理在企业治理框架内运行。随着上下文的累积,获取不成比例的价值。

架构已经存在。问题是谁先构建底层结构。

Section image

图表 8:背景故障模式——为什么 95% 的 Gen-AI 试点项目失败:六种故障类型及其机制和 UCL 预防策略】

结论

上下文工程已成为区分成功企业人工智能与失败企业人工智能(占87%)的关键学科。随着基础模型的同质化,差异化不再在于选择哪个模型,而在于是否拥有足够的上下文基础设施来使任何模型都有效,并实现真正自主的智能体。

场景图谱揭示了一个关键洞见:人工智能需要企业知识的结构化表示来进行推理,而不仅仅是检索。但仅仅依靠数据结构并不能解决所有难题:

  • 智能体的决策需要消费结构 来遍历图进行分析和决策。
  • 智能体生产化需要变异操作 ,将学习成果写回复合智能。
  • 与现有的ERP、EDW、流程挖掘和ITSM投资 与现有的ERP、EDW、流程挖掘和ITSM投资企业协同效应需要 与现有的ERP、EDW、流程挖掘和ITSM投资进行整合。
  • 真正的自主性需要受控激活机制 ,使主体能够在政策约束范围内安全行动。

UCL 是将上下文图应用于企业级上下文工程的领先架构 。UCL 通过八个同等重要的模式(其中模式 8 为“门户”)提供:

  • 现有企业投资统一为受监管的背景来源
  • 由结构和智能驱动的累积语义图
  • 两个递增循环:每次运行更智能,跨运行更智能
  • 受控激活机制,通过回滚和证据形成闭环。
  • 真正自主的智能体 ,能够推理、决策、行动和学习

成果可量化:DPO 缩短 11 天,OTIF 从 87% 提升至 96%,MTTR 缩短至数分钟。这些洞察并非止步于仪表盘,也并非需要人工干预,而是能够根据证据自主采取行动的智能体。

事关存亡。时机已到。架构已就绪。

上下文图是必要的。UCL 让它们发挥作用。智能体正是通过这种方式实现真正自主的。

参考

学术研究

Mei, L. 等人 (2025)。“大型语言模型的上下文工程综述”。arXiv:2507.13334。

Zhang, Q. 等人 (2025)。“智能体上下文工程:用于自改进语言模型的演化上下文。” arXiv:2510.04618。

Pan, MZ 等人 (2025)。“生产中的代理测量”。arXiv:2512.04123。加州大学伯克利分校,2025 年 12 月。

Mialon, G. 等 (2023)。“GAIA:通用人工智能助手的基准测试。” arXiv:2311.12983。Meta AI、Hugging Face、AutoGPT。2023 年 11 月;ICLR 2024。

行业架构

Anthropic。“模型上下文协议”。2024 年 11 月;Linux 基金会 Agentic AI 基金会,2025 年 12 月。

Google开发者博客。“代理开发工具包”。2025年12月。

Foundation Capital。“上下文图:人工智能的万亿美元机遇。” 2025 年 12 月。

企业分析

标普全球市场情报。“人工智能项目失败率调查”。2025年初。调查对象为北美和欧洲1000多名受访者。来源:CIO Dive,“报告显示人工智能项目失败率正在上升”,2025年3月14日。https ://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/

麦肯锡公司。“2024年初人工智能现状:新一代人工智能应用激增并开始创造价值。”麦肯锡全球调查,1363名参与者,2024年5月30日。https ://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-2022

Fini Labs。“为什么大多数 RAG 应用过于宽泛而无用,以及为什么未来将不再需要 RAG。” 对 50 多家财富 2000 强企业 RAG 部署的分析,2025 年 7 月 28 日。https ://www.usefini.com/blog/why-most-rag-applications-are-too-broad-to-be-useful-and-why-the-future-is-ragless

Gartner公司,《Gartner预测到2027年底,超过40%的智能体人工智能项目将被取消》。新闻稿,2025年6月25日。https ://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

框架文档

Banerji, A.“统一上下文层(UCL):企业人工智能的受控上下文基础。” dakshineshwari.net,2025 年 12 月。

Banerji, A.“AI 产品化报告:衡量生产中的代理。” dakshineshwari.net,2025 年 12 月。

Banerji, A.“AI 产品化:扩展代理系统。” dakshineshwari.net,2025 年 12 月。

Banerji, A.“Gen-AI ROI in a Box.” dakshineshwari.net,2026 年 1 月。