企业智能体落地瓶颈，除知识与记忆外，还需第三类上下文——实时业务状态层

当AI智能体从演示场景走向真实企业业务，一个被广泛忽视的挑战逐渐浮现：它知道该做什么（Knowledge），记得做过什么（Memory），却难以准确判断“现在业务走到哪一步了”。

以一个典型客服场景为例：客户询问“已付款为何未发货”，智能体可以调用RAG查发货政策，通过Memory回溯此前沟通记录，甚至调用API查询订单号。但要给出可靠答复，它必须确认——支付是否真正到账？库存是否已完成预留？订单是否进入履约队列？是否存在风控拦截或物流异常？这些状态分散在支付系统、WMS仓库系统、ERP和CRM中，各自更新节奏不同、数据模型各异，仅靠单次API调用难以拼出完整图景。

这揭示了一个关键缺口：企业智能体所需的上下文，实际包含三类而非两类。

第一类是知识上下文（Knowledge），由RAG机制支撑，用于获取静态规则、产品手册、合规文档等；第二类是记忆上下文（Memory），保存用户偏好、任务进度与历史交互；第三类则是操作状态上下文（Operational State），即实时、动态、跨系统的业务实体状态流——客户账户余额、订单履约阶段、库存可用量、支付结算状态等。

这三者共同构成智能体理解“业务当下”的完整认知框架：应该知道什么？此前发生过什么？业务现在处于什么状态？

图中清晰展示了这一分层逻辑：上层为业务系统（CRM、订单、支付、库存等多源数据），中间通过CDC（变更数据捕获）接入Operational State Layer（实时业务状态层），经Capture→Transform→Serve三步处理后，输出统一、持续更新的“当前业务状态”视图，供AI Agent直接调用。

值得注意的是，Operational State并非全新概念，而是企业数据中台或实时数仓能力在AI应用侧的延伸。其核心难点在于：业务状态具有强时效性（如库存秒级变动）、高关联性（订单-支付-库存需联合判定）与一致性要求（不能出现“已付款但库存未扣”的矛盾状态）。传统RAG将数据视为静态文档，Memory侧重非结构化对话流，二者均难以满足此类需求。

那么，如何构建这一层？实践中主要有两种技术路径：

路径一：请求驱动的临时组合

Agent在收到用户请求后，同步调用多个业务系统API，由后端服务完成数据关联与状态推断。这种方式开发快、耦合低，适用于低频、简单场景。但当涉及5个以上系统、或需处理状态冲突（如支付成功但库存不足）时，链路延迟、接口超时、重试逻辑复杂度陡增，响应稳定性难以保障。

路径二：后台持续维护的状态视图

通过CDC监听各源系统数据库变更（如订单表status字段更新、库存表quantity减少），在数据管道中实时完成过滤、映射、关联与聚合，生成统一的“订单全景状态”实体（含支付状态、库存预留、物流节点等字段），并持久化为可查询的服务接口。Agent只需一次调用即可获得完整业务快照。

后者虽初期投入较高，但长期收益显著：多个智能体（如客服Agent、订单追踪Agent、风控Agent）可复用同一份状态视图；避免重复计算；支持更复杂的业务推理（例如：“该订单因库存不足卡在‘待发货’，但同SKU在邻仓有余量，可触发跨仓调拨建议”）。

现实中，部分成熟企业已悄然部署类似能力。例如，某头部电商平台在其智能客服后台构建了“订单生命线”服务，整合支付网关回调、WMS出库日志、物流轨迹API，每500毫秒刷新一次订单状态摘要。当Agent处理“为什么没发货”问题时，不再需要拼接多个异步响应，而是直接读取该摘要，结合RAG中的发货规则与Memory中的客户历史，生成精准答复。

这种架构也解释了为何许多企业智能体项目止步于POC阶段：不是模型能力不足，而是缺乏对Operational State层的系统性建设。当业务系统仍是孤岛，智能体便只能做“信息搬运工”，无法真正参与决策闭环。

进一步看，Operational State层的成熟度，正成为区分L2与L3级智能体的关键指标。参考行业常见的能力分层：

L1：单轮问答型Agent，依赖预设规则与RAG；
L2：多轮任务型Agent，具备Memory与简单工具调用；
L3：业务协同型Agent，能基于实时业务状态发起跨系统动作（如自动触发补货、协商退款、升级人工）；
L4：自主优化型Agent，可在约束下调整业务流程本身。

L3及以上能力的前提，正是稳定、一致、低延迟的Operational State供给。没有它，智能体永远停留在“辅助查询”层面，无法深入业务执行层。

值得警惕的是，部分厂商将“调用API”等同于“解决状态问题”，实则混淆了数据获取与数据理解。调用10个API不等于拥有1个业务视图——前者是动作，后者是认知。正如一位企业架构师所言：“我们不是缺接口，是缺能把接口变成故事的能力。”

当前，已有技术组件趋近成熟：Debezium等CDC工具可低成本捕获数据库变更；Flink/Kafka Streams支持实时关联处理；Delta Lake/Iceberg提供ACID保障的增量状态存储。真正的门槛在于业务语义建模——如何定义“一个订单的完整状态”？哪些字段必须强一致？状态变更的因果链如何追溯？这些问题没有标准答案，需结合具体行业流程定制。

对技术团队而言，推进智能体落地需同步启动三项工作：梳理核心业务实体的状态变迁路径（如订单从创建到签收的12个关键节点）；评估现有系统数据更新机制与延迟；设计轻量级Operational State服务作为Agent的“业务感知中枢”。

短期内，企业可优先为高频场景（如订单状态查询、退换货审核）构建专用状态视图；中长期则应将其纳入数据中台演进路线，使实时业务状态成为与主数据、指标数据并列的核心资产。

智能体的下一程，不取决于模型参数规模，而取决于它能否真正“看见”业务正在发生的每一帧变化。