如果你最近关注企业级 AI，一定绕不开一个词：Context Graph（上下文图谱）。

它正在迅速成为这个领域讨论最密集的概念之一。甚至已经有投资人直言，这是一个万亿美元级别的机会。

原因并不复杂。

虽然今天的 AI 已经可以调用工具、执行任务，但它仍然不真正理解“工作是如何完成的”。

系统记录了结果，却看不到过程。

AI 最大的盲区：真正的工作不在系统里

在企业中，我们通常把 CRM、工单系统、数据库称为 “系统记录（Systems of Record）”。

但现实是：

决策发生在会议里

协作发生在聊天中

推进发生在邮件、文档、评论和临时讨论中

真正的工作流程，几乎从来不完整地存在于某一个系统里。

如果 AI 只看到“状态”，而看不到“路径”，那它就无法可靠地自动化工作。

这也是为什么，尽管关于 Agent、自动化的讨论铺天盖地，但真正能跑完整流程、跨数周甚至数月任务的系统，仍然非常少。

所以，什么是 Context Graph？

Context Graph，本质上是一个“工作过程模型”。

它不是只描述“有哪些东西”，而是试图回答：

工作，究竟是如何一步步发生的？

更具体地说：

Context Graph 会把企业中的各种实体——

人、文档、工单、系统、项目——

和它们之间真实发生过的行为与时间序列连接起来。

然后，从这些行为轨迹中，提炼出可被 AI 理解和复用的“工作模式”。

它能帮助 AI 回答一些以前几乎无法回答的问题，比如：

我们这里的 P1 事故，通常是怎么解决的？

产品 X 的升级，最常见的卡点在哪里？

从“创建试点”到“成交”，中间一般会发生什么？

“Onboarding 完成”对不同团队意味着什么？

为什么有些部署要花两倍的时间？

从“有什么”，到“怎么发生”

传统的数据系统，擅长描述 “What”：

有哪些客户

有哪些工单

有哪些文档

有哪些系统

Context Graph 关注的是 “How”：

谁

在什么工具里

按什么顺序

做了什么

产生了什么影响

为了做到这一点，它把“行为”本身，变成了一等公民。

在 Context Graph 中：

节点（Nodes）

不是静态对象，而是行为本身：

创建、查看、评论、升级、批准、解决……

每一个行为都带有时间戳和上下文元数据。

边（Edges）

表示因果和相关性：

某条消息，很可能触发了后续的某个更新；

某个审批，导致了流程的推进。

这样做的关键价值在于：

系统不需要硬编码流程，而是学会“什么路径更可能发生”。

最终得到的，不是一条死板的流程图，而是一组概率分布的路径集合。

不只知道“怎么做”，还开始理解“为什么这么做”

更进一步，Context Graph 还会在这些路径之上，叠加推导出来的洞察：

为什么 A 路径比 B 路径更快

为什么某些团队总是绕远路

哪些偏差是合理的，哪些是低效的

这让系统不只掌握“怎么做”，而是具备了某种程度上的因果理解。

而当 Agent 开始执行任务后，它们的行为本身，又会反过来成为新的轨迹数据。

系统通过强化学习，不断评估：

这个路径是不是最优？

有没有更好的替代方案？

Context Graph是怎么建出来的

Context Graph 是怎么“建”出来的？

这不是一个轻量工程。

第一步：深度连接 + 可观测性

如果你看不到工作是怎么发生的，就不可能建模。

这意味着必须深入到真正发生工作的地方：

文档

聊天

邮件

日历

工单系统

代码仓库

内部工具

而且不是只抓结果，而是抓所有变更事件。

比如：

Jira 评论的生命周期很短

但 Jira 描述里的链接，往往是权威文档

这些“使用方式”，本身就是重要的结构信号。

第二步：构建知识图谱（Knowledge Graph）

在收集数据之后，需要一个更高层的结构，把碎片连起来。

系统通过机器学习，推断出：

项目

客户

产品

团队

人员

并判断哪些文档、会议、工单、代码，属于同一个实体。

这一步非常关键，因为单纯的行为信号是噪声极高的。

只有在知识图谱的约束下，行为才有意义。

第三步：个人图谱（Personal Graph）

在组织层面之外，系统还会为每个人构建一个个人工作图谱：

跨工具的行为时间线

行为背后的上下文

所参与的任务和项目

但现实工作是极其混乱的：

人会频繁切换上下文

同一个文档可能服务于多个任务

任务会被中断、重启、合并

为了解决这个问题，系统会结合：

简单信号（标题、链接、时间窗口）

大模型，对行为序列进行语义归因

最终目标是，把混乱的事件流，切分成可理解的任务单元。

第四步：从个人图谱，到 Context Graph

当我们把个人图谱匿名化、抽象化、聚合之后，Context Graph 才真正形成。

每一条轨迹，会被转换成类似这样的“步骤序列”：

行为类型

工具类型

涉及的业务实体

推断出的流程标签

轻量级时间和结果特征

系统只保留模式，不保留隐私。

只有当某种模式，在足够多用户、足够多样本中重复出现时，才会被视为有效流程。

最终形成的是一张概率化的流程地图：

什么通常会发生？

按什么顺序？

哪些路径更高效？

这，就是 Agent 可以依赖的“操作手册”。

Agent建设图谱

最后一步：让 Agent 也成为图谱的一部分

如果 Agent 的执行不被记录，Context Graph 就无法进化。

所以，Agent 的每一次运行，都会被当成一条新的轨迹：

调用了哪些工具

顺序如何

效果怎么样

用户是否满意

系统会离线回放这些轨迹，评估不同路径的优劣。

久而久之，Context Graph 会变成一个人类行为 + Agent 行为的联合模型。

它不只是记录“过去怎么做”，

而是在实时反映：工作正在如何演化。

为什么 Context Graph 和执行层不能分开？

如果上下文模型和 Agent 执行系统分离，就会出现一个问题：

图谱在演化

Agent 在漂移

两个世界逐渐失真

真正高价值的企业流程（事故响应、销售推进、产品开发），

必须同时具备：

一个持续更新的上下文层

一个能执行、能试错、能反馈的执行层

只有在同一个系统中，它们才能互相校准。

写在最后

Context Graph 的目标，并不是生成一批“写死的自动化 Agent”。

而是构建一个会随着组织变化而不断学习的工作模型。

流程会变、工具会换、角色会流动。

只有当 AI 理解“工作是如何真实发生的”，

它才可能成为真正长期、自主运行的系统。

而这，才是 Context Graph 真正的价值所在。