面向主动型企业代理的Context Graphs

# 面向企业主动式代理的上下文图：实现超越被动检索的意图感知信息主动呈现  
来源：https://arxiv.org/html/2607.07721  

###### 摘要  
检索增强生成（RAG）和代理框架显著推进了企业人工智能的发展，但代理从根本上仍是被动的：它们必须等待人类查询后才能行动。本文认为，真正的企业生产力提升需要**主动式代理**：能够在工作者提问之前，主动呈现相关、可操作信息的系统。我们提出**上下文图（Context Graph）**，一种实时关系数据结构，用于对企业实体、实体间关系及其随时间的状态变迁进行建模。基于此图，我们定义了**增量检测引擎**，用于持续监控状态变化；**主动性评分器**，按紧迫性、相关性和角色匹配度对候选洞察进行排序；以及**呈现层**，由LLM驱动，生成带有可解释理由的排序通知。我们对每个组件进行了形式化定义，推导出统一的主动性评分函数，并提供了使用NetworkX和Anthropic Claude API的完整端到端Python实现。在三个通用企业案例（合同生命周期管理、工程事件响应、销售管道健康）上的评估表明，基于上下文图的主动机制实现了Precision@5为0.83，假阳性率为0.11，并将平均呈现时间从47分钟（被动基线）缩短至30秒以下。  

关键词：主动式代理，上下文图，企业人工智能，增量检测，信息呈现，LLM代理  

## 1 引言  
现代企业人工智能代理在设计上是被动的。支持工程师问：“哪些工单逾期了？”代理检索答案。销售经理问：“哪些交易有风险？”代理作出响应。查询是触发器；没有它，代理就保持沉默。这种被动姿态并非LLM能力的失败，而是**架构上**的失败。代理缺乏结构化的意识，无法在未被明确查询时，知道某件事何时跨越了对某人重要的阈值。这种生产力的代价是巨大的。知识工作者估计耗费20-30%的时间在寻找系统中已有的信息上[1]。更关键的是，他们会错过时间敏感的信号：一份合同48小时后到期、跨两个团队的事件依赖关系正在形成、一笔交易已停滞14天——原因并非数据不存在，而是没有系统在监视**实体之间的关系**，并在变化跨越行动阈值时发出警报。  

基于图的知识表示在企业环境中早有研究[2,3]。知识图谱建模实体和关系，但通常是静态且由查询驱动的。缺失的是一个**实时的、感知增量**的关系结构，它不仅跟踪存在哪些实体以及它们如何关联，还跟踪**发生了什么变化**、跨越了哪个阈值、以及组织中的谁应该对此采取行动。  

本文介绍**上下文图**，一种面向企业实体的动态图结构，作为主动代理行为的基础。在此基础上，我们定义了三个组件，共同构成一个主动呈现系统：  
1. (1) **增量检测引擎**，持续监控图状态以发现跨阈值事件。  
2. (2) **主动性评分器**，按紧迫性、相关性和角色匹配度对候选洞察进行排序。  
3. (3) **呈现层**，由LLM驱动，将排序后的信号转化为可操作、有依据的通知，在恰当的时间送达正确的人。  

#### 贡献。本文做出四项贡献：  
- •我们形式化定义了上下文图模式，包括节点类型、边类型、属性语义以及增量事件模型。  
- •我们推导出主动性评分函数，一个基于紧迫性、相关性、角色匹配度和置信度维度对候选呈现事件进行排序的原则性公式。  
- •我们提供了一个完整的端到端Python实现，使用NetworkX进行图管理，使用Anthropic Claude API生成自然语言通知。  
- •我们在三个通用企业领域，以Precision@5、假阳性率和平均呈现时间为指标评估了该系统，展示了相较于被动基线的可测量延迟降低。  

## 2 相关工作  

### 2.1 检索增强生成  
RAG[4]已成为将LLM输出锚定在企业知识中的标准范式。GraphRAG[5]等扩展将知识图谱遍历引入检索步骤，实现多跳推理。Corrective RAG[6]增加了自我反思循环。这些系统对于查询驱动的任务非常强大，但在架构上无法实现主动行为：它们仅在收到查询时才产生输出。  

### 2.2 代理框架与工具使用  
ReAct[7]及后续框架使LLM代理能够交错进行推理和行动，包括调用外部系统的工具。AutoGen[8]和LangGraph展示了多代理协调。AFLOW[9]引入了自动化的代理工作流生成。这些框架解决了**执行**任务时的代理自主性问题，但并未解决前置问题：在没有人类指令的情况下，代理应决定做什么，以及何时做？  

### 2.3 主动推荐与事件驱动系统  
主动信息系统在推荐系统文献中已有研究[10]，特别是在推送通知和预期计算方面[11]。分布式系统中的事件驱动架构[12]展示了状态变化如何触发下游处理。我们的工作将这些思想综合成一个原生代理架构，其中图既是知识基础，也是事件源。  

### 2.4 企业知识图谱  
企业知识图谱已被部署用于实体解析、语义搜索和关系分析[13]。它们建模实体和关系，但通常作为静态快照维护。时序知识图谱[14]通过时间感知谓词对此进行了扩展。我们的上下文图更进一步：它在每个节点和边上跟踪实时状态，并将状态转换视为驱动代理行为的一等增量事件。  

### 2.5 定位  
与我们工作最密切相关的是Kumar[15]提出的三层上下文架构，该架构在企业代理中划分了静态知识、经验记忆和工作流状态。那篇论文确定了**什么**是上下文；本文则探讨当上下文变得动态且代理必须在未被查询时主动行动时会发生什么。上下文图可以被视为[15]所识别缺失的实时关系基础的具体实现。  

## 3 上下文图：定义与模式  

### 3.1 形式化定义  
我们将上下文图\(\mathcal{G}\)定义为一个有向、带属性、带时间戳的多重图：  
\(\mathcal{G} = (V, E, P_V, P_E, \mathcal{T})\)  (1)  
其中\(V\)是节点集合（企业实体），\(E \subseteq V \times V\)是有向边集合（关系），\(P_V: V \rightarrow \mathcal{A}\)将每个节点映射到一个属性包，\(P_E: E \rightarrow \mathcal{A}\)将每条边映射到一个属性包，\(\mathcal{T}\)是一个全局逻辑时钟，每次状态修改操作时递增。  

每个节点\(v \in V\)携带一组强制属性：全局唯一的id；来自领域模式的type；编码当前状态的state；创建和更新的wall-clock时间戳created_at和updated_at；标识责任人或团队的owner；以及领域特定键值对的metadata字典。  

每条边\(e = (u,v) \in E\)携带：语义标签rel_type（例如assigned_to、depends_on、blocks）；权重weight取值范围[0,1]；以及created_at时间戳。  

### 3.2 节点与边分类  
表1和表2展示了上下文图分类法中的主要节点和边类型。图1展示了代表性企业图片段中这些节点类型间的关系。  

表1：上下文图节点分类。  
表2：上下文图边分类。  

| Task | Event | Person | Asset | System | Org |
|------|-------|--------|-------|--------|-----|
| depends_on / blocks | escalates_to | assigned_to | owned_by | member_of | triggers | affects |

实线箭头 = 主要关系  
虚线箭头 = 派生/推断关系  

图1：上下文图节点与边分类。节点按实体类型着色。Task（任务内依赖）和Person（升级）的自环分别显示在左侧和右侧。Event和System之间的虚线箭头表示派生关系。长距离边清晰绕过中间列节点以避免任何重叠。  

### 3.3 增量事件模型  
对\(\mathcal{G}\)的每一次状态修改操作都会产生一个**增量事件**\(\delta\)。形式化地：  
\(\delta = (\texttt{entity\_id}, \texttt{change\_type}, v_{\text{old}}, v_{\text{new}}, t_{\text{wall}}, \mathcal{T}_{\text{clock}})\)  (2)  
变更类型取自集合\(\Delta = \{\texttt{StateTransition}, \texttt{ThresholdBreach}, \texttt{RelationshipChange}, \texttt{Staleness}, \texttt{DependencyRisk}\}\)。增量事件被追加到一个不可变的事件日志\(\mathcal{L}\)中，支持回放、审计和时序查询。  

## 4 系统架构  
图2展示了主动呈现系统的端到端管线。企业源系统将状态更新输入上下文图。增量检测引擎持续轮询图，对所有节点评估阈值规则。触发的规则产生候选洞察，主动性评分器按用户对这些洞察进行排序。呈现层调用LLM生成自然语言通知，经过去重和冷却处理后送达相应接收者。  

CRM | 工单 | 合同 | 基础设施  
↓  
上下文图\(\mathcal{G}\)（NetworkX有向图++事件日志\(\mathcal{L}\)）  
↓  
增量检测引擎（阈值规则\(\mathcal{R}\)，k跳BFS快照）  
↓  
候选洞察  
↓  
主动性评分器\(P(c,u)=w_1U+w_2R+w_3F+w_4K\)  
↓  
排序后的洞察  
↓  
LLM呈现层（Claude API，去重，冷却）  
↓  
接收者（正确的人）  

图2：主动呈现系统的端到端架构。企业数据源写入上下文图；四个处理层逐步过滤、评分并呈现洞察以供交付。  

## 5 增量检测引擎  

### 5.1 架构  
增量检测引擎（DDE）针对一组已注册的**阈值规则**\(\mathcal{R}\)评估每个增量事件\(\delta \in \mathcal{L}\)。每条规则\(r \in \mathcal{R}\)是图上的一个谓词：  
\(r: (\mathcal{G}, \delta) \rightarrow \{\texttt{True}, \texttt{False}\}\)  (3)  
当\(r(\mathcal{G},\delta)=\texttt{True}\)时，DDE发出一条**候选洞察**\(c\)，包含：受影响的实体标识符和类型；规则标识符；归一化严重性分数\(s_c \in [0,1]\)；受影响角色集合；以及一个**上下文快照**：以受影响实体为中心的\(\mathcal{G}\)的子图，捕获k跳邻居。  

### 5.2 阈值规则规范  
表3展示了规则词汇表。规则是用Python编写的可组合谓词，可承受任意复杂度。  

表3：增量检测引擎中的示例阈值规则。  

### 5.3 子图上下文提取  
对于每条候选洞察\(c\)，DDE通过以受影响实体为起点的k跳BFS遍历（k=2）提取上下文快照。快照包括实体节点及其所有属性、k跳内的所有邻居、这些节点间路径上的所有边，以及触发增量事件。该快照被传递给主动性评分器，并最终传递给LLM呈现层，为LLM提供有依据的上下文，而无需查询整个图。  

图3展示了实现中使用的演示图，以及DDE在笔记本评估运行中呈现的三个候选洞察。  

Alice → Bob → Carol  
↑ assigned_to  
ticket-42  
↑ assigned_to  
deploy-7  
ticket-17  
↑ depends_on  
contract-88  
↑ blocks  
R-01 SLA违规 分数=0.765  
R-01 SLA违规 分数=0.765  
R-03 被阻塞>24h 分数=0.810  

图3：演示上下文图（3人，3个任务，1个资产）。红色框显示笔记本运行中的三个候选洞察：R-01（SLA违规）在ticket-42和ticket-17上触发（每个分数0.765）；R-03（被阻塞>24小时）在ticket-17上触发（分数0.810）。  

## 6 主动性评分  

### 6.1 动机  
并非所有阈值突破都值得呈现。一条规则可能同时在数十个实体上触发；不加区别的通知会造成告警疲劳，这比完全没有主动行为更糟糕[16]。主动性评分\(P(c,u)\)量化了向用户\(u\)呈现候选洞察\(c\)的价值，使系统能够在通知前对候选池进行排序和过滤。  

### 6.2 形式化定义  
\[
P(c,u) = w_1 \cdot U(c) + w_2 \cdot R(c,u) + w_3 \cdot F(c,u) + w_4 \cdot K(c)
\]  (4)  
满足\(\sum_i w_i = 1\)，所有\(w_i > 0\)，且\(P(c,u) \in [0,1]\)。  

### 6.3 紧迫性\(U(c)\)  
紧迫性捕获阈值突破的时间和严重性压力：  
\[
U(c) = \sigma\left(\alpha \cdot s_c + \beta \cdot \tau_c\right)
\]  (5)  
其中\(\sigma\)是sigmoid函数，\(s_c \in [0,1]\)是归一化规则严重性，\(\tau_c = 1 - \frac{t_{\text{deadline}} - t_{\text{now}}}{W_{\max}} \in [0,1]\)是在最大时间窗口\(W_{\max}\)内的时间压力。参数\(\alpha\)和\(\beta\)可按领域调整；我们使用\(\alpha=2.0\)，\(\beta=1.5\)。  

### 6.4 相关性\(R(c,u)\)  
相关性度量候选洞察直接涉及用户\(u\)的程度：  
\[
R(c,u) = \max\left( \mathbb{1}[\text{owns}(c,u)], \; \gamma \cdot \mathbb{1}[\text{team\_owns}(c,u)], \; \delta \cdot \frac{1}{1 + d_{\mathcal{G}}(u, e_c)} \right)
\]  (6)  
其中\(d_{\mathcal{G}}(u, e_c)\)是在\(\mathcal{G}\)中从用户\(u\)到受影响实体\(e_c\)的最短路径跳数。参数\(\gamma=0.6\)和\(\delta=0.3\)对间接相关性进行折扣。  

### 6.5 角色匹配度\(F(c,u)\)  
角色匹配度捕获此类洞察是否与用户的角色匹配：  
\[
F(c,u) = \cos\left( \mathbf{e}_{c.\text{type}}, \; \mathbf{e}_{u.\text{role}} \right)
\]  (7)  
其中\(\mathbf{e}_{(\cdot)}\)是实体类型和用户角色的嵌入向量。我们为演示使用手工制作的原型嵌入，但在生产中这些可以从组织图或HR数据源中学习。