艾体宝洞察 | 什么才是真正的上下文？为什么我们需要它

2025 年之后，几乎所有企业的 AI 项目都在加速进入 Agent 时代。

大家不再满足于一个只会问答的聊天机器人。

企业真正想要的是能够自主行动的智能体：

• 自动诊断并修复系统故障
• 自动处理工单并分派工程师
• 自动完成客户跟进并预测成单概率
• 自动执行跨部门业务流程
• 基于实时业务状态做出运营决策

然而，从 Demo 走向生产，几乎每一步都踩在坑上。很多团队发现，Agent 在演示环境中表现得聪明、丝滑，可一旦接入真实的企业系统，就会开始出现各种“失智”行为：

• 回答看似正确，却完全脱离实际业务价值
• 推理过程漏洞百出，关键因果链条缺失
• 多步骤任务执行到一半突然“失忆”
• 给出违背公司经营常识的业务建议
• 不同 Agent 同时得出相互矛盾的结论，令业务侧完全丧失信任

面对这些问题，最常见的反应是把锅甩给模型：

“GPT 还是不够强。”

“Claude 的推理能力太弱。”

“DeepSeek 的幻觉太严重了。”

但在 Arango 的观察中，问题核心根本不在于模型。核心在于——企业从未真正给过 Agent 可用的上下文。

一个真实的企业级错误：500 错误与消失的上下文

假设你是一家大型电商公司的技术负责人。

凌晨两点，报警电话响起：用户支付失败率突然飙升。你被紧急拉进线上会议，所有人都在等结论。你打开运维助手，输入了一行字：

为什么订单支付失败率突然上升？

Agent 快速检索了最近 15 分钟的日志，给出了答案：

支付服务出现大量 500 错误，建议检查支付服务代码，特别是近期发布是否有变更。

从语言层面看，这个回答无可挑剔。它准确提取了日志中的异常信号，表达了正确的技术判断。

但从业务层面看，这个回答几乎没有价值——甚至可能是危险的误导。

因为真正发生的是这样一条因果链：

22:03  Redis 集群发生节点重启
        ↓
       连接池瞬间耗尽
        ↓
       大量订单服务调用超时
        ↓
       支付服务调用失败
        ↓
       支付网关出现 500 错误
        ↓
       用户端订单支付失败

500 错误只是整条链路的末端结果，而 Redis 节点重启才是真正的根因。如果不恢复 Redis 容量或迁移连接池配置，就算重启支付服务一百次，故障依旧。

那为什么 Agent 没有发现根因？因为它看到的，是孤立、扁平的日志片段，而不是被还原出来的业务上下文。它不知道支付服务依赖于 Redis，不知道 Redis 集群的变更历史，也不知道当晚发生的所有关联事件之间的因果网络。

这就是问题的本质：Agent 有数据，但没有上下文。

RAG 的局限：当“找文档”不再够用

过去两年，行业里最主流的解法是 RAG（检索增强生成），其架构简单直接：

用户提问
   ↓
Embedding 向量化
   ↓
向量库语义检索
   ↓
找到最相关的文档片段
   ↓
交给 LLM 生成回答

这种模式对于知识问答型场景非常有效。比如：

• “公司最新的报销流程是什么？”
• “OAuth2 授权码模式是如何工作的？”
• “产品 A 和产品 B 的功能差异在哪里？”

这些问题的答案，天然封装在现有的文档、手册和规范之中。它们本质上是在找知识。

但企业环境里最关键的决策问题，极少是知识问答，绝大多数是关系分析与因果推理问题。例如：

• “为什么支付突然失败？”（这是事件与组件之间的因果链问题）
• “哪些客户最有可能在 30 天内续约？”（这是客户行为与产品使用之间的关联问题）
• “这次发布的风险究竟在哪里？”（这是变更、依赖和业务影响之间的影响面问题）
• “哪个供应商是我们的单点风险？”（这是供应链节点与依赖度的网络问题）

回答这些问题，需要理解的不只是某一篇文档，而是：

• 实体与实体之间的关系（客户、产品、合同、团队、系统）
• 事件与事件之间的时序与因果（发布、变更、告警、工单）
• 组织与组织之间的影响域（部门、权限、流程、SLA）

而这些关系，往往从不完整地存在于任何一份单一的文档、表格或日志里。它们是跨系统、跨模态、跨时间的碎片。

企业数据的原罪：上下文碎片化（Fragmented Enterprise Data）

Arango 在其 Contextual Data Platform 中反复指向一个无法回避的现实：企业数据天然是高度碎片化的。

一个所谓的“客户 360 视图”，背后可能是这样的散落结构：

• CRM：客户联系人、阶段、最后沟通时间
• ERP：应收账款、历史订单、信用额度
• 邮件系统：最近三周的报价沟通
• 客服系统：正在处理的投诉与工单
• 工单系统：关联的 P1 故障及其处理人
• 合同系统：即将到期的合同与续约条款
• 知识库：该客户所在行业的最佳实践案例

对于经验丰富的人类员工，他们天然会进行“上下文拼接”：接到客户电话时，脑子里自动把投诉历史、付款状态、合同条款和最近接触记录融合在一起，然后做出判断。

但 Agent 不具备这种跨越系统边界的“自动拼接”能力。绝大部分时候，它只能被限定在某个系统、某类数据切片内，看到的永远是局部真相。

这也就是为什么，销售 Agent 可能会根据“客户上周反复打开报价单”这一信号，果断建议：

立即推动签约，给出限时折扣。

从销售漏斗数据来看，这个判断没有任何毛病。但从企业全局来看，可能完全错误。因为同一时刻，财务系统已经标记该客户有严重逾期未付，客服系统显示多个产品缺陷投诉未被处理，法务系统显示该客户存在合同违约风险。

销售 Agent 是正确的，但业务结论是灾难性的。

缺失上下文，就是缺失判断力。

什么才是真正的“上下文”？

一个普遍的误解是：上下文 = 更多文档。

似乎只要把 PDF、Wiki 和邮件都向量化，Agent 就自然获得了上下文。

但这恰恰是 RAG 思维的最大盲区。

Arango 对“上下文”的定义，其实更接近于一个本质概念：业务上下文（Business Context），即业务运行过程中自然产生的、所有有关联的、活的信息集合。

它既包括传统的非结构化知识：

• 文档、PDF、Wiki 页面、邮件正文

更包括结构化的、动态的、彼此勾连的业务要素：

• 用户、客户、供应商
• 产品、SKU、订单
• 服务、微服务、基础设施组件
• 事件、告警、变更、发布
• 流程、审批、工单流转
• 权限、角色、组织架构
• 实时状态（库存、在线、健康度）

但仅仅是要素本身还不够。真正的上下文是这些要素之间的关联及其动态演化，例如：

客户 A
 └─ 签订 → 合同 B
        └─ 关联 → 产品订阅 C
                └─ 部署在 → 环境 D
                        └─ 产生 → 工单 E
                                └─ 分配给 → 运维工程师 F
                                        └─ 隶属 → 支持团队 G

当这些关联被完整地连接起来，Agent 从“客户 A 投诉”这一事件中获得的就不再是孤立的投诉记录，而是可以沿着图游走的丰富上下文：合同等级、产品依赖、环境健康度、工单历史、责任人忙闲度。

上下文不是信息堆叠，而是信息之间的连接与意义。

Arango 将其核心目标概括为三个词：Unified（统一的）、Current（实时的）、Trusted（可信的）Business Context。

• 统一：跨系统打破孤岛，以同一个语义层表达；
• 实时：不依赖离线批处理，而是持续捕获变化并更新关联；
• 可信：来源清晰、血缘完整、权限受控，每一步推理都可追溯。

为什么 Agent 天生依赖上下文层？

Agent 与 ChatBot 的本质区别，不在于模型强弱，而在于行动还是回答。

ChatBot 的输出是信息。Agent 的输出是决策和行动。而任何一个负责任的行动，都必须建立在完整、新鲜、可信的上下文基础之上。

举个例子，用户对智能助理说：

“帮我安排下周去纽约见客户。”

这句话本身的语义很清晰，但信息量严重不足。要真正完成这个动作，Agent 至少还需要掌握：

• 这个用户是谁？当前职位和权限？
• 下周哪几天有空？是否有不可动移的日程？
• 纽约要见的客户是什么级别？最近三次沟通的内容和情绪？
• 公司差旅政策是什么？预算上限、舱位标准、审批流程？
• 用户本人的出行偏好（航司、时间段、酒店品牌）？
• 该客户是否存在未解决的严重问题，此时拜访是否合适？

这些信息分散在日历系统、CRM、邮件记录、HR 系统、差旅平台和业务沟通工具中。任何一条缺失，都可能让执行结果尴尬甚至带来商业损失。

传统做法是，Agent 每接到一个任务，便临时到各系统去检索、提取、拼装上下文。Arango 把这种现象称为 “Inference-time Context Reconstruction”——推理时上下文重建。

这种方法有三个根本性缺陷：

1. 慢

每次推理都需要跨多个异构系统进行数据检索与聚合，涉及 API 调用、权限检查、数据格式转换，延迟极高，在需要快速响应的生产环境中完全不现实。

2. 不一致

不同的 Agent、同一 Agent 的不同调用，因为时序不同、数据更新滞后或查询路径不同，可能拿到完全不同的上下文视图。这直接导致开头所说的“不同 Agent 得出相互矛盾结论”的混乱局面。

3. 不可解释

当 Agent 做出一个错误决策，团队回溯时发现，它使用的上下文是“临时拼凑”出来的，没有完整的血缘和版本，根本无法确定是模型错、数据错还是拼装逻辑错。

因此，想让 Agent 在真实企业环境中持续可靠地行动，必须把上下文从“临时制品”升级为持续维护的基础设施。

解法：Contextual Data Layer——提前构建的业务语义层

Arango 给出的方案非常直接：不要在推理时重建上下文，而应该提前构建上下文，并以 API 的形式持续供给。

这就是 Contextual Data Layer（上下文数据层）的核心思想。

架构对比很明显：

传统 RAG 模式：

数据源 → 向量化 → 检索片段 → LLM

上下文层模式：

各类业务数据源
      ↓
Contextual Data Layer（持续同步、实时建模）
      ↓
Agent（获取完整上下文）
      ↓
LLM（推理与行动）

Contextual Data Layer 并不取代数据源，而是在数据源之上，持续维护一个活的企业业务上下文图谱，其中包含：

• 实体：客户、产品、合同、系统、人员、事件
• 关系：依赖、所属、影响、版本、沟通、交易
• 状态：在线状态、库存量、运行健康状况、审批节点
• 事件流：变更记录、告警通知、用户行为
• 规则与权限：谁有权看到什么，什么操作受什么策略约束

这使得所有 Agent 不再各自为战地去理解企业，而是共享同一个统一、实时、可信的业务语义层。

为什么是图模型？上下文的内核是关系网络

很多人会问：用关系数据库、宽表或者更强大的向量库，能不能完成这个任务？

答案是：局部可以，整体不能。

因为上下文的本质，不是一张二维表上的属性字段，而是高度互联的关系网络。回到支付故障的例子：

支付服务
 ├─ 依赖 → Redis 集群
 │         ├─ 部署于 → 服务器 Node-42
 │         └─ 关联 → 最近变更记录 #12901
 ├─ 触发 → 告警事件 Alert-3344
 └─ 负责 → 运维团队 SRE-Payments
        └─ 成员 → 张×、李×

这个结构天然就是图（Graph）。如果强行用宽表去表达，要么产生恐怖的连接查询和性能瓶颈，要么丢失关系之间的多层依赖，最终给 Agent 的还是“变形的碎片”。

Arango 之所以选择图作为核心模型，正是因为图是表达“企业脉络”最高效、最自然的方式。与此同时，Arango 并没有抛弃文档、键值、全文检索等多模型能力，而是以图作为骨架，把不同模型的能力有机融合在一个引擎里。

更关键的是，企业现在不必再手工维护一副巨大而昂贵的企业知识图谱。Arango 推出的 AutoGraph 技术，可以直接从现有业务数据中自动构建 Context Graph：

• 自动识别实体（通过规则、模式匹配、元数据）
• 自动推断关系（外键、引用、命名规范、事件关联）
• 自动发现依赖链路和服务拓扑
• 自动注入业务语义，并保持增量更新

最终，这个图不是某个部门的一次性项目产出，而是一个持续自更新的、活的上下文网络，可随时被 Agent 查询和遍历。

举个更具业务冲击力的例子：供应链风险。当一个地区的二级供应商出现合规问题，Context Graph 可以实时沿着“部件 → 组件 → 产品 → 客户合同”的路径，一键识别出所有受影响的高价值客户合同，并触发主动响应。这种全局冲击分析，离开图几乎无法实时完成。

从 RAG 时代到 Context Engineering 时代

过去几年，整个行业的注意力被 Prompt Engineering 吸走，紧接着是 RAG Engineering 的狂热。大家反复琢磨如何写出更精妙的提示词、如何调优分块策略、如何改进向量相似度。

而 Arango 点出了下一波真正的分水岭：Context Engineering（上下文工程）。

核心问题已经发生根本迁移：

• 不再问“如何让模型更聪明？”
• 而是问“如何让模型获得正确的、完整的、可信的业务上下文？”

因为当模型能力日趋同质化，Agent 的竞争力不会来自模型参数的数量，而是来自上下文的质量。谁能够率先把散落在文档、数据库、事件流、业务规则和实时状态中的所有碎片，连接成一个统一、实时、可信的 Contextual Data Layer，谁才能真正构建出经得起生产环境考验的 Enterprise Agent。

这就是为什么 Arango 不再仅仅把自己当作一家多模型数据库公司，而开始重新定位为：

“The Context Layer for Enterprise AI”——企业 AI 的上下文层。

在这个新的时代叙事里，上下文不再是 AI 的辅助信息，不再是临时拼凑的检索片段，而是新的基础设施本身。

结语：把上下文当作第一要素

让 Agent 不再“犯蠢”，靠的从来不是等待下一版更强的模型。

靠的是，从现在开始，把上下文当作企业 AI 体系中的第一要素——提前构建、统一治理、实时演进。

当你拥有一个能够持续连接企业所有业务要素的上下文层时，Agent 看到的就不再是碎片的日志、文档或表格，而是一个活的、可以推理的商业世界。

在那之后，它才真正开始变聪明。