RAG 提供知识，Memory 保留交互历史。当 Agent 开始处理真实业务，它如何及时掌握来自不同系统的当前业务状态？
假设一个企业客服 Agent 收到这样的请求：
「我的订单已经付款了，为什么还没有发货？」
它可以检索公司的发货政策，记住客户此前的沟通记录，也可以调用订单、支付和库存系统的 API。
但要给出准确的答复，它还需要弄清楚几个问题：支付是否已经完成？库存是否已经预留？订单是否进入履约流程？有没有其他业务状态影响发货？
这些信息可能分别存在于不同的业务系统中。各系统有自己的数据模型、更新机制和业务流程。Agent 即使能够逐一查询，也仍然需要处理数据关联，并判断不同记录共同反映了怎样的业务进展。
对于一次简单查询，这项工作可能并不复杂。但当企业开始部署多个 Agent，让它们共同参与客户服务、订单处理和运营管理时，数据如何关联、更新和共享，就不再只是应用开发中的一个细节。
企业 Agent 所需要的上下文，可能还不止知识和记忆。
一、企业 Agent 需要的上下文，正在变得更加复杂
RAG 和 Memory 已经成为企业 AI 应用中常见的两类上下文机制。
RAG 通过检索企业文档、产品资料和业务规则，让 Agent 在执行任务时获取相关知识。Memory 则用于保留用户偏好、交互历史和任务过程，使 Agent 能够在后续交互中延续此前的信息。
但企业业务还有一类信息：来自业务系统、持续发生变化，并且需要跨系统关联的当前业务状态。
客户账户会发生变化，订单会进入不同处理阶段，支付会完成，库存会减少。这些信息分布在不同的业务系统中，需要结合业务关系才能形成完整的业务视图。
可以从三个维度理解企业 Agent 所需要的上下文：
| 上下文类型 | 典型内容 | Agent 需要解决的问题 |
|---|---|---|
| Knowledge | 企业知识、产品资料、业务规则 | 应该知道什么？ |
| Memory | 对话历史、用户偏好、任务记录 | 此前发生过什么？ |
| Operational State | 客户、订单、库存、支付等当前业务状态 | 业务现在处于什么状态？ |
这里的三分法是一种理解企业 Agent 数据需求的分析框架，并不意味着 RAG 和 Memory 存在绝对的技术边界。RAG 可以检索动态数据，Memory 也可以保存结构化业务信息。
我们希望单独讨论的是：当 Agent 需要执行真实业务时，如何持续获取不同业务系统中的变化，将相关数据组织起来，并提供能够反映当前业务情况的状态。
这类信息有自己的更新频率、业务关联关系和一致性要求，不能简单等同于一份知识文档或一段历史记录。
二、Agent 可以调用 API，但跨系统数据整合由谁负责？
让 Agent 直接调用业务系统 API，是一种自然且有效的实现方式。
对于单系统查询，或者业务关系简单、调用频率不高的任务，直接调用 API 通常已经足够。
但当 Agent 需要同时访问 CRM、订单、支付和库存系统时，数据获取只是第一步。不同系统返回的数据需要按照业务标识进行关联，还要考虑各自的更新时间、数据结构和状态变化。
这里实际上有两种不同的处理方式。
方式一：请求发生时临时组合数据
Agent 或后端服务在收到请求后，分别调用相关系统的 API，将返回结果组合成所需的业务视图。
这种方式不需要预先维护一份独立的跨系统状态，数据获取也可以直接依赖各源系统提供的接口。对于低频查询、简单业务关系或对读取时效要求特殊的场景，它往往是更直接的选择。
但当查询涉及多个系统和复杂关联时，每次请求都需要重新完成数据获取和组合。调用链路的延迟、部分接口失败、重试以及不同数据源的更新时间，都可能影响最终结果。
方式二：持续维护跨系统业务状态
另一种方式是在后台持续捕获源系统的变化，通过数据转换和增量处理，提前维护跨系统的业务视图。应用需要数据时，直接读取已经形成的状态。
这将数据组合工作从每次请求中移到了持续运行的数据处理链路中。多个应用可以复用同一份经过维护的业务视图，也不必分别实现相同的数据关联逻辑。
两种方式的主要区别在于数据处理发生的时间和位置：
| 对比维度 | 按需 API 组合 | 持续状态维护 |
|---|---|---|
| 数据处理时机 | 请求发生时 | 后台持续处理 |
| 数据关联 | 每次请求时组合，或由后端服务完成 | 通过增量处理提前维护 |
| 数据读取 | 调用相关 API 获取结果 | 读取已维护的业务视图 |
| 主要成本 | 请求链路、接口依赖和重复组合逻辑 | 持续运行的数据处理及状态维护 |
| 适用情况 | 低频查询、简单关联 | 多源数据、持续变化、多应用共享 |
这里还需要考虑一种常见情况：企业已经有统一的后端业务 API，负责聚合多个系统的数据。如果它能够直接提供应用需要的完整业务视图，那么 Agent 完全可以调用这个接口。
如果这个后端服务已经在后台持续维护跨系统状态，那么它实际上已经承担了我们讨论的那部分数据基础设施工作。
预先整合业务数据，也可能减少 Agent 在任务执行过程中反复检索、关联和整理数据的工作。在一项基于合成银行数据的对照测试中，同一模型查询持续维护的整合视图时，单次运行的中位总 Token 消耗从直接访问六个源系统时的 33,650 降至 17,619，减少约 48%。
测试口径： 自定义 Data Agent Benchmark；合成银行数据；同一模型；24 个问题；每条路径重复三轮。该结果反映 Agent 侧 Token 使用量的变化，并不代表整体基础设施成本或账单节省幅度。
因此，问题并不是 API 能不能解决，而是当跨系统的数据整合成为多个应用的共同需求时，是否应该把这项工作独立出来，持续处理并供不同消费者复用。
三、数据库变化不等于业务状态
以一笔订单为例——订单记录被创建，支付记录更新为成功，库存数量发生变化，履约记录进入新的处理阶段。这些变化分别发生在不同的数据表和业务系统中。
通过 CDC（Change Data Capture），系统可以捕获数据库记录的新增、更新和删除等变化。
但需要注意：CDC 捕获的是数据库层面的变化记录，并不意味着它已经理解了这些变化背后的业务含义。
例如，支付表中的一个状态字段从 Pending 更新为
Success，只说明数据库记录发生了变化。要判断这对某笔订单意味着什么，还需要知道支付记录对应哪笔订单，以及订单当前的其他业务状态。
同样，库存数量发生变化，也不能单独说明某笔订单是否可以发货。还需要结合订单明细、商品标识、库存分配和相应的业务规则进行判断。
从数据库变化到业务状态，中间还需要完成几个步骤：
- 识别不同数据记录之间的业务关联关系。
- 根据业务模型转换和组织数据。
- 将不同来源的信息组合成应用需要的业务视图。
- 随着源数据持续变化，更新受到影响的状态。
最终形成的业务状态，是对多个数据来源进行处理后的结果，而不是某一条数据库变更记录本身。
这也是为什么捕获数据库变化之后，还需要进一步的数据转换和状态维护。
四、Operational State Layer：从数据库变化到持续更新的业务状态
Operational State Layer（实时业务状态层）关注的是这条从源系统数据变化到应用可用状态的处理链路。
它位于现有业务系统与上层应用之间，负责捕获数据变化、转换和关联多源数据，并将形成的业务状态持续提供给应用和 AI Agent。
从工程实现来看，这条链路可以分为三个阶段。
1. Capture：捕获数据库变化
通过 CDC 机制，持续获取生产数据库中的新增、更新和删除等变化。
对于支持日志读取的数据库，可以通过读取事务日志等方式捕获数据变化，避免完全依赖周期性全量抽取。
初始数据如何建立也需要考虑。系统通常需要先获得一份初始数据快照，再衔接后续增量变化，确保下游状态能够从一个明确的数据基线开始持续更新。
在此过程中，源数据库仍然承担原有的系统记录职责，不需要因为上层应用需要实时数据，就首先迁移或重建原有业务系统。
2. Transform：转换并关联多源数据
捕获到的数据变化还不能直接作为完整的业务上下文使用。
系统需要根据业务模型，对数据进行过滤、字段映射、结构转换、关联、聚合和丰富等处理。
例如，订单主表、订单明细、支付记录和客户信息分别存储在不同的数据表中。通过业务标识和关联关系，可以将这些记录组织成一个包含订单进度、支付情况和客户信息的业务视图。
当相关源表发生变化时，处理链路需要识别受影响的数据关系，并增量更新对应状态。
这项工作涉及的不只是数据格式转换，还包括如何定义业务关联、如何处理多源更新，以及如何让目标状态持续反映源数据的变化。
3. Serve：提供应用可用的业务状态
完成数据转换和状态维护后，还需要将结果提供给上层消费者。
一种常见方式是将处理后的状态物化到目标数据库或数据存储中，再通过查询接口、API 等方式供应用使用。
这样，客户服务 Agent、销售应用和运营系统可以读取相应的业务视图，而不必每次都从多个底层系统重新获取和组合数据。
整条处理链路可以概括为：Capture → Transform → Serve。
三个阶段分别负责数据变化的获取、业务状态的构建，以及状态的提供。
这里的「实时」并不意味着零延迟。源端变化仍需经过捕获、转换和写入，系统应关注端到端处理延迟及状态新鲜度，确保其满足具体业务要求。
五、企业 AI 生产化，需要重新考虑业务状态的供给方式
当 Agent 从知识问答走向订单处理、客户服务、供应链协同等真实业务，企业的数据需求也随之发生变化。
它们需要的不只是能够被检索的知识和能够延续的交互历史，还包括来自不同业务系统、持续更新并能够被多个应用复用的当前业务状态。
这类状态可以通过按需 API 组合，也可以由后台持续维护。选择哪种方式，取决于业务场景和工程要求。
但对于多源数据持续变化、业务关系复杂、多个应用需要共享相同状态的场景，将数据捕获、增量转换和状态维护作为独立能力来设计，值得认真考虑。
这就是第三类上下文所指向的架构问题。
当企业开始让 Agent 参与真实业务，除了让它知道规则、记住交互，还需要让它及时了解业务系统中正在发生什么。
活动预告｜COSCon'26「Data × AI：下一代数据基础设施」
第十一届中国开源年会 COSCon'26 将于 2026 年 11 月 14–15 日 在 杭州云谷中心 举行，今年的主题是「开源下一代，Open Source：The Next Generation」。开源的下一个时代，将由下一代开源技术、人才、社区与商业共同定义。
届时，TapData 创始人兼 CEO 唐建法（TJ）将于「Data × AI：下一代数据基础设施」分论坛发表主题演讲：
被忽略的第三类上下文：企业 AI 生产化的关键
演讲将从 RAG、Memory 与实时业务状态的关系出发，探讨企业级 Agent 执行真实业务时所需要的第三类上下文，并介绍 Operational State Layer 的核心理念。
通过架构解析与现场演示，分享如何利用 CDC 捕获数据库变化，对多源业务数据进行增量转换和聚合，持续维护应用与 AI Agent 可以直接使用的当前业务状态。
彩蛋：分享过程中，TJ 还将正式官宣新的开源项目 tapstate。tapstate 围绕 Operational State Layer 构建，关注从数据库变化到实时业务状态的持续构建过程。开源发布后，开发者可以了解其技术实现，参与项目开发，并共同探索下一代实时数据基础设施。
活动信息
| 项目 | 信息 |
|---|---|
| 活动 | COSCon'26「Data × AI：下一代数据基础设施」分论坛 |
| 演讲时间 | 2026 年 11 月 15 日 14:10–14:40 |
| 演讲嘉宾 | 唐建法（TapData 创始人兼 CEO） |
| 地点 | 杭州云谷之芯负一楼（云枢） |
