企业级上下文工程：从Context Graph到生产级AI

前文：AI的万亿美元机遇：上下文图谱（Context graphs）

上下文图谱（Context Graphs）是必要的。UCL（ Unified Context Layer：统一上下文层）让它们真正发挥作用——通过能够消费、学习和行动的系统。这就是智能体实现真正自主的方式。

一张图说明问题与解决方案。 供应商延迟交货，风险评分飙升，截止日期逼近。

• 没有UCL：数据孤岛，2-3天的争议处理，缺乏治理的流水线，没有审计追踪。
• 有UCL：四个数据源融合为统一基座，情境分析对信号进行评分和路由，三个Copilot接收受管控的上下文包，证据账本捕获每一个决策——从08:15的信号检测到第4天的准时交付。

我们为何获胜：复合护城河 — UCL馈送结构，智能体工程馈送智能，两个循环从累积语义图谱读取并回写

执行摘要

企业级AI正在大规模失败。据S&P Global Market Intelligence数据，2025年有42%的企业放弃了大部分AI项目——较一年前的17%大幅上升。对财富2000强企业部署的行业分析显示，87%的企业RAG实现未能达到ROI目标。智能体碎片化地处理上下文，并在没有契约的情况下回写到业务系统。

失败点不在于模型能力。基础模型已达到显著的复杂程度。失败点在于上下文——碎片化、缺乏治理，被视为副产品而非工程化基础设施。

上下文图谱（Context Graphs） 已成为一个引人注目的理论方向——企业知识的结构化表示，使AI能够推理而非仅仅检索。但上下文图谱作为数据结构是必要的，而非充分的。真正的难题仍未解决：

• 智能体决策：智能体必须分析情境并做出决策——而非遵循脚本。这需要能够消费图谱的系统：遍历、推理、评估选项、确定响应。没有这一点，智能体无法真正自主。

• 智能体生产化：部署必须在运行时演进。这需要能够操作图谱的系统：创建、合并、修改、连接——在每次执行中积累智能。没有这一点，智能体在发布后就会僵化，在生产中性能衰减。

• 企业集成：企业在ERP、EDW、流程挖掘、ITSM等领域已投资数十年。这些系统包含智能体需要的信号和机构知识。任何解决方案都必须集成这些投资，而非忽视它们。

将元数据导入Neo4j并不能让智能体工作。你需要消费结构（读取的系统）、变异操作（回写的系统）和受控激活（安全行动的系统）。这就是真正自主的智能体与脚本化Copilot的区别。

本报告提出统一上下文层（UCL）作为企业级上下文工程的领先架构——该架构将上下文图谱 operationalize（可操作化），并使真正自主的智能体能够在企业治理框架内运行。

1. 上下文工程：正式学科

1.1 定义与范围

[图1：上下文工程分类法 — 三层架构，展示上下文管理、上下文处理、上下文检索与生成]

上下文工程是对推理时提供给大语言模型的所有信息进行系统性设计、优化和治理的学科。这一定义来自对1400多篇研究论文的综述（arXiv 2507.13334），将上下文工程确立为超越简单提示设计的正式学科。

范围涵盖：系统指令和提示、对话历史和记忆、检索到的信息、工具定义和模式、结构化输出约束，以及治理机制。

关键洞察：LLM的功能类似于一类新的操作系统。模型充当处理器；上下文窗口充当工作内存。上下文工程管理在每个推理步骤中占据该窗口的内容。

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：上下文作为编译视图

[图2：ADK架构 — 源 → 编译器流水线 → 编译视图]

Google的智能体开发工具包将上下文框架为编译视图——源 → 编译器流水线 → 编译视图。它解决三个压力：成本/延迟螺旋上升、信号衰减和推理漂移。

局限性： ADK提供编译规范，但不解决流程-技术融合、多消费支持或受控激活。智能体获得更好的上下文，但仍遵循预定路径。

2.3 智能体上下文工程（ACE）：自改进的Playbook

[图3：ACE架构 — 围绕演进Playbook的生成器 → 反射器 → 策展人循环]

ACE框架（arXiv 2510.04618）将上下文视为演进的Playbook——生成器 → 反射器 → 策展人。它在智能体基准测试中实现+10.6%的改进，并将适应延迟降低82-91%。

局限性： ACE实现自改进，但需要企业基座作为改进对象。没有来自企业系统的受控上下文，Playbook从什么中学习？智能体孤立地改进，与企业现实脱节。

2.4 上下文图谱：必要但不充分

[图4：上下文图谱：为什么结构胜过字符串 — 从"存在什么？"到"需要什么行动？" — 由UCL可操作化]

Foundation Capital的"上下文图谱"理论识别了一个万亿美元的机会：不仅捕获状态而且捕获决策痕迹的图谱——为什么做出决策、批准了哪些例外、存在哪些先例。

这是引人注目的——但上下文图谱作为数据结构并不能解决真正的难题：

智能体决策问题： 智能体必须分析情境并做出决策——而非遵循脚本。Neo4j中的数据做不到这一点。你需要一个情境分析器——一个消费图谱并产生决策的系统。没有这一点，智能体无法处理新情况；它们会升级给人类。人类仍然是瓶颈。

智能体生产化问题： 部署必须在运行时改进。图数据库存储数据。你需要运行时演进系统来回写学习——CREATE新模式、MERGE实体、ALTER关系、CONNECT决策痕迹。没有这一点，智能体在部署后就会僵化，性能衰减。

企业集成问题： 忽视现有IT基础设施的上下文工程方法错过了一个基本现实。企业在ERP、EDW、流程挖掘、ITSM等领域投资了数十年。这些系统包含智能体需要的信号和机构知识。任何不集成它们的架构都无法捕获企业协同效应。

跨图谱发现问题： 即使当上下文图谱存储多个语义域时，图数据库本身也不会发现涌现的跨域关系。考虑：决策历史图谱知道"127个新加坡登录被关闭为误报（置信度：0.94）"。威胁情报图谱知道"新加坡IP范围显示凭证填充增加340%"。单独看，两个图谱都没有标记问题。但一个定期跨图谱边界搜索的系统发现了交集：鉴于当前威胁情报，误报校准是危险的错误校准。这种跨图谱发现不仅需要图数据库，还需要一个受控基座，其中所有域共享实体定义和可遍历的元图——这正是UCL提供的。

3. 什么使上下文工程成为"企业级"

企业级上下文工程需要七个维度，缺少任何一个，智能体都无法在生产中可靠或自主地运行。

[图5：企业级上下文工程 — 生产级AI系统所需的七个维度]

缺失任何维度都会破坏系统——并阻止智能体实现真正自主。

4. UCL：企业级上下文工程的领先架构

统一上下文层（UCL）交付所有七个维度，解决上下文图谱单独无法解决的难题，并使真正自主的智能体能够在企业治理内运行。

4.1 六大范式转变

转变1：上下文成为受管控的产品。 上下文包带有评估门控进行版本化（answerable@k ≥90%，cite@k ≥95%，忠实度 ≥95%）。

转变2：异构源统一。 流程智能、ERP、网络信号通过通用语义层汇聚。

转变3：元数据成为推理基座。 元图是可操作化的上下文图谱。

转变4：一个基座服务所有消费模型。 S1（BI）、S2（ML）、S3（RAG）、S4（智能体）、激活。

转变5：激活关闭受控循环。 预写入验证、职责分离、回滚、证据账本。

转变6：情境分析实现自主行动。 智能体基于上下文推理、分析情境并做出决策——而非遵循脚本。这就是使智能体真正自主的东西。

4.2 八大模式

这些模式共同创建了受控基座。但基座本身不是最终状态。使UCL具有变革性的是这个基座如何馈送和启用复合架构——以及该架构如何启用真正自主的智能体。

5. 行业用例：UCL vs. 替代方案

三个场景演示为什么企业级上下文工程需要UCL——以及为什么替代方案无法使真正自主的智能体成为可能。

5.1 发票例外礼宾（寻源到付款）

场景： 发票被冻结——三方匹配失败。需要：拉取合同条款、识别根本原因、决定解决方案、执行、捕获证据。

UCL结果： DPO ↓11天。$2700万营运资金释放。自主解决——例外升级；其他一切自动运行。

5.2 OTIF恢复（供应链）

场景： OTIF下降。需要：融合ERP与流程挖掘、识别根本原因、决定补救措施、执行、证明有效。

UCL结果： RCA当日完成。OTIF 87%→96%。政策 guardrails 内自主补救。

5.3 重大事件拦截（IT运维）

场景： 服务器延迟在凌晨2点飙升。需要：与变更关联、评分爆炸半径、决定补救措施、执行、捕获证据。

UCL结果： MTTR以分钟计，而非小时。作战室从未形成。自主事件解决。

5.4 能力差距

上述用例揭示一致模式：替代方案各交付部分能力，但无一个交付真正自主智能体所需的完整系统。第3节的七个企业级维度提供客观评估框架。

图9：企业上下文工程能力矩阵 —— 架构方法在生产级AI能力上的立场，展示MCP、ADK、ACE、上下文图谱和UCL在全部七个维度上的评估

矩阵使差距可见：

• MCP提供连接性但无其他——智能体可达数据但无法推理、决策或安全行动。
• ADK增加编译规范和部分治理，但缺乏流程融合、情境分析和受控激活——智能体推荐但不行动。
• ACE实现学习但无企业基座可对抗学习——智能体孤立改进，与企业现实脱节。
• 上下文图谱提供数据结构但无消费、变异或激活系统——数据存在但智能体无法使用。
• UCL交付全部七个维度——唯一使能推理、决策、行动和学习的智能体的架构。

关键洞察： 每个人都有碎片。只有UCL有复合的连接系统。这不是可增量添加的功能问题——差距是架构性的。部分解决方案无法修补为完整方案，因为它们缺乏基础基座。

这些用例和能力矩阵演示核心论点：企业级上下文工程不仅是关于更好的上下文——它是关于使能真正能在企业治理内自主运行的智能体。

图8：上下文失败模式 —— 为何95%的Gen-AI试点失败：六种失败类型及其机制和UCL预防策略

结论

UCL是将上下文图谱 operationalize 为企业级上下文工程的领先架构。 通过八个同等模式——以模式8为网关——UCL提供：

• 现有企业投资统一为受控上下文源
• 由结构和智能馈送的累积语义图谱
• 两个复合循环：每次运行内更智能，跨运行更智能
• 以回滚和证据关闭循环的受控激活
• 推理、决策、行动和学习的真正自主智能体

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