客户订单为何延误？AI代理缺的不是数据是关系图

AI代理能写代码、能生成答案、能自动跑工作流。可一旦让它处理企业数据，问题就冒出来了：它不知道信息在不同系统之间是怎么连起来的。

设想一个提问：这位客户的订单为什么延误，他符合退款条件吗？要回答它，代理得同时摸到客户记录、订单详情、物流状态、退款政策，还有业务规则。这些散落在多个系统里。

光有访问权限不够。代理还得认出正确的关系、取到相关证据、遵守组织的访问与审批规则。AWS Context 想解决的正是这件事。

AWS 在 2026 年 6 月推出 AWS Context，定位是一项尚待上线的服务，把企业数据之间的关系映射成知识图谱，帮代理在运行时取到受治理的上下文。部署前得先查最新的 AWS 公告，确认服务可用性和支持的能力。

它到底做什么

按已公布的说法，AWS Context 通过一张共享知识图谱，把企业数据、业务概念和组织知识连起来。能力包括几块：关系发现，识别数据资产与业务实体之间的关系；知识图谱，表示数据集、实体、业务概念之间的连接；业务知识策展，让数据管理员审核关系并附上可信定义和规则；受治理检索，让代理在请求方身份既定的访问边界内取上下文；互操作性，AWS 提到会把关键上下文元数据以 Apache Iceberg 格式发布到 Amazon S3 Tables，供兼容工具使用。

目标很明确：让企业知识能被多个 AI 应用复用，而不是把同一套假设塞进每一个提示词里。

传统 RAG 差在哪

传统检索增强生成（RAG）通常按问题去匹配文档或段落。这有用，但单篇文档不一定能揭示回答业务问题所需的全部关系。

看一张简化的图：客户下单，订单有物流，物流有状态，状态指向延误；订单又要按退款政策来评估。图把客户、订单、物流、政策串了起来。代理可以顺着这些关系去查，而不是把每条记录当成孤立信息。

举个例子，找到退款政策还不够。代理得先定位相关订单、取到当前物流状态，再套用正确的政策。知识图谱帮忙组织这些关系，但底层数据本身仍要可靠，代理做决定前也得验证自己的发现。

放进架构里看

一个简化的概念流程是：用户请求进入 AI 应用，交给 AI 代理，代理访问 AWS Context，落到受治理的知识图谱，图谱连着客户数据、订单数据、政策与规则，最后产出有证据支撑的回答，行动前还要过审批。

这张图描述的是预期工作流，不是已部署的 AWS Context 配置。代理先识别任务需要哪些上下文，通过配置好的接口取到相关关系，再用这些证据准备答案。

访问控制是关键。代理不能因为某条受限记录和另一个可访问实体相连，就把它取出来。

一个客服代理的小实验

可以设计一个小型客服流程，把客户信息、订单记录、物流状态、退款政策连起来。代理要做的是：定位相关客户和订单，取最新物流状态，找到适用退款政策，用证据解释情况，执行退款前请求人工审批。

示例用虚构数据，演示的是预期工作流，不是真实的 AWS Context 部署，也不是跑过的集成测试。

先准备样本数据：客户与订单记录、物流记录，以及一条业务规则——退款资格取决于订单状态、产品类别、配送条件和适用的退货窗口，单凭物流延误并不自动等于可退款。生产环境里，这些记录应来自权威系统，退款规则应来自经批准的政策源。

再建模关系：客户 C101 拥有订单 O501，订单 O501 有物流 S801，S801 当前状态为延误，订单 O501 按退款政策评估。在支持的情况下，记录重要关系的来源、新鲜度和审核状态，有助于区分已验证事实和假设。

然后给代理一个任务提示：客户想了解延误订单的进展，识别相关订单，取最新物流状态，定位适用退款政策，解释可选方案；只用授权数据和已批准规则；信息缺失就说明缺什么；不得发起退款或修改订单。

预期流程是：解析客户与订单标识，取授权物流记录，取适用政策，评估现有证据，产出带来源引用的解释，证据不全或需人工复核时升级处理。具体检索 API 和实现步骤取决于环境里可用的接口，动手写 SDK 调用或端点前先查当前 AWS 文档。

对虚构订单 O501，代理可能产出这样的响应：订单号 O501，物流状态延误，政策检查结果为需要更多信息，解释是物流延误本身不构成退款资格，下一步是核对适用退货窗口和订单条件，退款执行状态为未执行，需要人工复核。这是示意性的响应结构，不是 AWS Context 的真实输出。

关键行为在于，代理不凭空发明退款权利。它说明已知什么、指出缺什么，并避免执行未经批准的动作。

安全与治理要放在模型外面

生产实现里，控制措施应尽量落在语言模型之外：

• 最小权限：只给代理需要的访问权。
• 身份感知检索：用户权限约束可访问的数据。
• 人工审批：退款等有后果的动作必须审批。
• 来源可追溯：保留答案背后的数据和政策引用。
• 审计日志：记录相关检索与执行活动。
• 新鲜度检查：行动前重新校验订单状态。
• 安全失败处理：记录冲突或证据不足时升级。

目标不只是让代理知道得更多，而是让它的决定更可解释、更可控。

和传统 RAG 不是替代关系

两者解决的是相关但不同的问题，可以互补。知识图谱可能负责定位正确的退款政策和订单，RAG 系统负责取回政策的具体段落。生产架构可能同时受益于结构化关系和非结构化文档检索。

能派上用场的地方包括：客服场景连接客户档案、订单、物流、工单和政策；财务运营关联交易、账户、审批规则和审计记录，同时保住访问控制；企业分析连接指标、数据资产、归属信息和定义，让代理更清楚一个指标是什么意思、从哪来；内部知识发现帮员工在团队、项目、系统和文档之间的关系里导航，而不是搜孤立文档。实际价值取决于数据质量、关系准确性和治理控制的有效性。

上生产前该问什么

数据质量：源记录是否准确、标识是否一致？关系质量：推断出的关系能否在影响重要决策前被审核？权威性：来源冲突时以哪个系统为准？权限：用户身份是否约束了代理可用的上下文？新鲜度：数据和政策的变化多快能反映出来？可追溯性：团队能否找出答案背后的来源和规则？评估：代理响应是否针对已知场景和冲突证据做过测试？失败处理：上下文不完整时，代理会不会请求澄清或升级？

知识图谱本身不保证答案正确。源质量、检索行为、访问控制和测试仍然缺一不可。

想在被管理的 AWS Context 可用之前先试知识图谱，可以看开源的 Context Ontology Accelerator。它提供了另一种建模业务实体和关系的方式，带人工审核，组件涉及 Amazon Neptune、Amazon OpenSearch Serverless 和 Amazon Bedrock。它的搭建方式与托管服务不同。

对企业代理团队来说，机会在于从孤立答案走向基于连接起来的业务信息做决定。从小工作流起步，验证关系和源数据，落实最小权限访问，对有后果的动作保留人工审批。