Context Graphs: Powering Enterprise AI Agents

Glean 是企业 AI 搜索公司，这篇来自他们的工程博客。文章出发点是两个问题：Context Graph 到底是什么，以及怎么构建。

因为 AI 模型能调用工具了，但缺乏理解实际工作流程的知识。系统记录了决策结果，但真正的工作发生在会议、聊天、邮件和文档里。没有结构化的工作流程视图，AI 无法可靠地自动化。

文章给出精确定义：

核心转变：从描述"有什么"到描述"变化怎么发生"。

• "What" — 传统数据系统建模的是事物：客户、工单、文档、人、系统
• "How" — Context Graph 建模的是行为：谁做了什么、在哪个应用、什么顺序、什么效果

图的构成：节点 = 动作（"创建"、"查看"、"审批"、"升级"、"解决"，每个带时间戳和元数据），边 = 因果关系（"消息 A 触发更新 B，概率 P"）。

Context Graph 能回答的问题示例："P1 事件通常怎么解决的？"、"产品 X 最常见的问题升级路径是什么？"、"从'试点创建'到'交易关闭'通常经历什么？"

• Knowledge Graph（知识图谱） — 实体层。ML pipeline 推断项目、客户、产品、团队、人等高层实体及其关系。理解"CRM 里的 ACME Inc"和"工单里的 ACME"是同一个客户。知识图谱是 Context Graph 的基础——活动信号本身是噪音，需要知识图谱来赋予意义。
• Personal Graph（个人图谱） — 个人层。收集每个人的跨工具活动流，拼接成时间线，用知识图谱实体丰富元数据。然后将原始事件分组为语义任务（如"调查告警"、"起草设计方案"）。隐私隔离，数据只对本人可见。
• Context Graph（上下文图谱） — 聚合层。将 Personal Graph 匿名化：移除用户标识、保留动作类型+实体标签+流程标签+时序特征。只保留跨 N 个独立轨迹都出现的模式，稀有模式丢弃。最终产出的是概率性的流程视图——"通常发生什么"、"什么顺序"、"为什么这条路偏离了那条路"。

文章讨论了存储决策：纯图结构太僵化，原始文本太难以导航。Glean 的选择是混合模型：把自由文本分段，嵌入实体 ID。例如一个事件处理流程被切成短段，标记阶段转换——"调查中"→"缓解中"——通过标记实体 ID（如 incident_id=INC-123）让 Agent 能一步步走流程。代价是不适合同时跨数千个事件推理。

文章指出：如果 Agent 在系统外运行，Context Graph 永远不会从它们身上学习。如果 Agent 在系统内运行，每次执行都会成为一条新轨迹：调用了哪些工具、什么顺序、成功还是失败、用户是否点赞。离线时系统回放并尝试替代路径，评分标准包括正确性、完整度、指令遵循度和效率。

成功执行强化了期望的模式，失败执行标记了反模式。随着时间推移，Context Graph 成为人类和 Agent 行为的联合模型——它不只描述工作过去是怎么做的，还反映当前人类和 Agent 共同协作下工作正在怎么展开。

Glean 在实际构建之前先做了内部测试：让员工 opt-in 共享 Personal Graph 数据 → 识别高频高价值流程（如"AE 中端市场交易周期"、"on-call 事件响应"、"PM 功能发布"） → 用时间维度区分低价值和高价值流程 → 找领域专家验证 A 路径 vs D 路径的区别和偏差原因 → 把这些流程做成可工作的 Agent。

最终目标不是静态的 Agent，而是让 Agent 持续从 Context Graph 中获取新鲜流程洞察，把越来越多的逻辑推入学习层而不是依赖手动维护的指令。

• Context Graph = 上下文 Lab 的核心研究对象 — Glean 的 Context Graph 直接对应你在研究的 Context Graph。他们的三层架构（KG → Personal → Context）提供了企业级实现的参考。
• "What vs How" = Context Layer 的核心理念 — 从建模"有什么"转向建模"变化怎么发生"，和你站关于"业务上下文不是静态数据而是动态规则"的论点一致。
• 混合存储 — 分块文本 + 实体 ID 的做法，可以看作是你们 Schema Graph 实验的工程化版本——都致力于让 Agent 能结构化地理解业务上下文路径。
• 反馈闭环 — Agent 执行结果回注 Context Graph，和 Stanford ACE 的 Generator→Reflector→Curator 本质相同，都是"自改进上下文系统"的架构模式。