作者：沈林
本文整理自第 10 届 AI + 研发数字峰会（AiDD）北京站 TOP10 最佳演讲议题之一《Agent 开发范式演进：简化多源实时上下文构建》
过去一两年，Agent 开发的变化速度，可能超过了很多团队的预期。
不少团队可能都有类似经历：一开始自己写 Agent Loop，后来接入 LangChain、LangGraph 等框架，再后来又开始关注模型公司提供的 Agent SDK 和 Harness Runtime。每一次模型能力升级，似乎都伴随着一次架构调整。
这不一定说明之前的方案选错了。很多时候，只是因为底层能力变化得太快了。以前需要业务团队自己实现的 Planner、Memory、Router、重试和状态管理，正在逐渐变成模型或平台的通用能力。于是，一个现实问题摆在面前：如果模型、框架和 Runtime 还会继续变化，今天投入建设的 Agent，什么部分能够真正留下来？
我们的判断是：正交生长------通用智能要跟进，但企业更应该把长期投入放在自己的业务上下文。
留下业务上下文，而不是重复建设通用智能
1.1 两条增长轴：通用智能向前，业务深度向上
可以把 Agent 的建设拆成两条增长轴：
横向是通用智能，包括 Memory、Planner、Managed Runtime、Agent 协作等能力。这些能力是模型公司和平台持续投入的方向，企业应该跟进，也应该尽量复用，避免重复制造已经逐渐成为公共能力的东西。但这条轴上的能力，未必适合作为企业长期资产。今天由业务团队自己实现的能力，明天可能就会成为模型或平台的默认配置。
另一条是与它正交的纵向增长轴，也就是业务深度。它包括：
- 企业持续产生的业务事实；
- 业务对象之间的关系；
- 企业内部统一的业务语义；
- 具体流程和规则；
- 行业知识与业务经验。
这些内容不会因为模型升级而自动出现，也不是模型公司可以替企业完成的。模型可以帮助整理、推断和生成候选，但企业自己的业务口径、数据关系和流程边界，仍然需要在业务侧沉淀。
这就是"正交生长"的含义：模型公司沿着通用智能的方向不断向前，企业沿着业务深度的方向持续向上。两条增长轴越是垂直，获得的"智能面积"也就越大。
判断一项投入是否值得长期做，可以问一个问题：下一次模型升级之后，这项投入是会被替代，还是会被放大？
1.2 业务上下文必须来自持续运行的数据
明确了业务深度的重要性，接下来还要回答一个问题：这些业务上下文从哪里来？
答案不是一份一次性整理好的静态文档，而是企业每天持续运行、持续产生的数据。订单和交易会不断发生，客户行为会持续变化，设备会产生新的事件和告警，工单会不断流转，应用和日志会继续增长，外部 SaaS 和 API 也会持续返回新的信息。
业务事实有三个特点：
1. 它们来自系统的实际运行，而不是事后凭空整理出来的材料。 每一次订单推进、客户跟进、设备告警和流程流转，都会产生新的事实。
2. 一个答案通常需要多个系统共同参与。 一个看似简单的问题，背后可能同时涉及客户、订单、库存、履约、客服和售后。只看单一系统，信息往往是不完整的。
3. 业务状态始终在变化。 一次导出的表格只能代表导出时刻的状态，业务继续运行之后，它就会逐渐偏离现场。即使是文档知识，也需要持续维护和更新。
因此，Agent 要进入业务深处，必须看到企业此刻真正发生的事情。
真正需要建设的是一条持续的数据供给"管道"：持续接入、多源汇流、增量更新、跨系统组合，并且随着业务状态变化而更新。一次导入不等于持续的业务上下文。
消息服务：企业实时数据集成的天然底座
2.1 消息服务为什么天然适合做数据集成
讲到"管道"，大家最容易想到的是 Linux 的管道文件。在 Linux 中，一个进程可以把输出接到另一个进程的输入。前一个进程不需要了解后一个进程，后一个进程也不需要关心数据具体如何产生，双方通过管道协同工作。
消息服务把这个模型从单机扩展到分布式环境：管道的一端可以是业务应用、数据库、SaaS、日志系统或 IoT 设备，另一端可以是业务系统、数据平台、分析工具或 Agent。
它之所以适合承接持续的数据集成，主要有三个原因。
1. 追加写入，传输快，上下游解耦
消息服务通常采用 Append-only Log，数据持续追加，写入路径短，理论上最接近硬件性能上限，适合承接高吞吐的数据流。生产者只负责写入，消费者按照自己的位点和处理速度读取，双方不需要相互等待。上游不必知道下游有多少消费者，下游也不必和上游的处理节奏绑定在一起。
2. 接入方式灵活，适合连接异构系统
上游可以通过 Put 主动写入，消息服务也可以通过 Pull 主动采集；下游可以通过 Pull 主动读取，也可以由管道 Push 主动投递。这让消息服务能够连接数据库、SaaS、日志、IoT、业务应用和外部 API 等不同系统。无论数据源是主动提供数据，还是只能通过接口被调用，都可以找到合适的接入方式。
3. 数据可以缓存、订阅和回放
消息并不一定要被瞬时转发。管道可以保留一段时间的数据，用来吸收流量峰值，缓冲上下游处理速度的差异。同一份数据也可以被多个下游订阅，实现一次接入、多路使用。出现失败时，还可以从历史位点回放，用于失败重试、历史补数或新系统追赶。
所以，消息服务的"集成能力"并不是后来附加上去的功能，而是它本身的天然属性。
2.2 消息服务：正在为 Agent 集成数据
今天，以 RocketMQ、Kafka、EventBridge 等为代表的消息服务，已经拥有非常丰富的连接器生态。
上游可以连接业务应用、ERP、CRM、交易系统、数据库、文件、对象存储、微服务、API、日志系统，以及 IoT 和边缘设备。
下游则可以连接业务消费、数据湖、实时数仓、ETL、BI、风控、推荐、AI、监控、审计和安全治理系统。
每增加一种数据源，就可以复用已有的下游；每增加一个消费场景，也可以复用已经接入的上游。上游不必为每个下游重复建设链路，下游也不必分别对接所有数据源。在消息流动过程中，还可以完成过滤清洗、格式转换、关联补全和路由分流。
因此，消息服务正在从单纯的传输组件，升级为企业实时数据集成的基础设施。它把原本彼此独立的产品组织成一张实时流动的数据网络，而 Agent 也可以成为这张网络中的一类重要消费者。但这条链路，目前通常比较"间接"：
1. 我们从左向右看： 业务与交易数据、文档和日志、设备与事件，以及外部服务的数据，首先进入消息服务。
2. 消息服务充当"数据供给中枢"： 根据不同场景完成过滤、清洗、转换和路由------按需同步。
3. Agent 通常不会直接读取原始数据流， 它需要的是围绕具体任务可以"查询和理解"的数据，所以消息中的数据会继续进入不同的数据服务：
- 业务状态和精确记录，进入到关系型数据库；
- 文档与日志，进入搜索或文档库；
- 语义检索和 RAG ，使用向量数据库；
- 指标和趋势，则进入分析型数据库。
随后，这些数据服务通过 MCP Server，以标准化的方式提供给不同的 Agent。这样无论是 Qoder、ChatGPT、Claude，还是企业自研 Agent，都可以在需要时查询相应的数据。
但是，数据可访问，是否就等价于数据对 Agent 可用？
数据已经接通，为什么 Agent 还是用不好？
3.1 可访问 ≠ 可用：Agent 用好数据还差什么？
数据可访问不等于数据对 Agent 可用。
数据经过消息加工、过滤、转换、同步和分散存储之后，Schema、语义、血缘和实时性都可能出现新的断点。Agent 需要的不只是一个数据值，它还需要知道：这个值代表什么、从哪里来、经过了什么变换、什么时候更新、是否可信、是否允许当前任务使用。
如果这些上下文没有一起到达，就会出现几种情况：
- 数据分散在不同数据库里，Agent 找不到；
- 字段结构、命名和业务口径不一致，Agent 看不懂；
- 数据经过过滤、转换和同步后，来源与加工过程难以追溯，Agent 不敢用；
- 实时数据和离线数据难以对齐，新鲜度与一致性无法保证，Agent 用不准。
也就是说，传统集成链路解决了"数据有没有接通"，但还没有完全解决"Agent 能不能找到、理解、关联并信任这些数据"。
围绕这个问题，我们有三个如下判断。
3.2 三个判断：语义传递、认知统一与链路收拢
判断一：源头的数据语义，需要一直传递和演进
一条数据链路通常要经过多个环节：源系统、消息接入、加工转换、同步存储，最后通过 MCP 或其他接口交给 Agent。
源系统负责定义业务实体和最初的 Schema；进入消息系统后，需要识别事件含义，完成 Schema 注册、版本管理和兼容校验；经过加工转换时，字段会被映射、转换和补全，同时产生新的结果与变换记录；同步到存储时，还要设计场景化的表和字段；到了 MCP 和 Agent 侧，则要把数据变成可查询、可理解的业务语义。
每一段交接都可能丢失信息。
因此，每个环节交付的都不应该只有数据，还应包括数据定义、版本、变换过程和可信解释。每一次交接都要确认三件事：含义是否一致，Schema 是否兼容，变化是否可追溯。
这不是一次性的工作。源头字段发生变化之后，语义、映射、存储和访问契约都需要能够沿链路继续演进。
判断二：数据存储可以分散，但语义和检索需要提前统一
数据分散存储是企业的客观状态。
实时事件适合留在流系统，交易数据留在业务数据库，历史数据进入湖仓，文档和日志进入搜索系统，向量数据进入向量数据库，一些数据还由外部 SaaS 或 API 管理。不同系统有自己的时效、成本、性能、权限和责任边界。把所有数据复制到一个地方，既不现实，也未必必要。
但数据物理上分散，不代表对数据的理解也可以分散。平台需要在 Agent 调用之前，持续构建统一的数据认知：
- 通过 Catalog 让数据找得到；
- 通过 Schema 和 Semantic 让数据看得懂；
- 通过 Entity 和 Lineage 把跨源实体与关系关联起来；
- 通过 Freshness、Quality 和 Policy 判断数据是否新鲜、可信，以及谁有权使用。
这不是把数据集中复制，而是把目录、结构、语义、关系和可信上下文提前统一。为什么要提前做，而不是等 Agent 收到问题之后临时理解？因为 Agent 响应用户时，时间和上下文窗口都有限。它不可能每次都遍历所有系统，重新猜字段含义、核对业务口径、追溯血缘，再判断权限。
临时理解不仅慢，而且同一个问题可能得到不同解释，风险也更难控制。更合理的方式，是把"调用时临时理解"变成"调用前持续沉淀认知"，调用时再通过统一的 MCP 接口按需获取可信上下文。
判断三：整条集成链路会不断收拢
前两个判断叠加之后，第三个判断自然出现：整条集成链路会不断收拢。
这不是因为企业一定要把所有系统合并，而是因为多段拼接的代价会越来越高。因为：
1. 上下文容易断。 每交接一次，语义、口径和访问契约都可能需要重新翻译，任何遗漏都会把理解偏差放大。
2. 统一管理困难。 Catalog、Schema 和业务语义分散在多个系统中，同一份数据容易形成多套解释。
3. 复制和对齐越来越多。 每个环节都产生新的数据副本，实时与离线不断同步，新鲜度与一致性反而更难保证。
4. 责任边界破碎。 问题可能出在消息、加工、存储、查询或 Agent，但排查需要跨多个系统，没有一个服务对最终结果负责。
所以，链路收拢的重点不是把数据强制搬到一个地方，而是让一个服务能够对数据从进入、被理解到被使用的全过程负责。
EventHouse：一站式 Agent 实时数据服务
4.1 架构：消息底座 + 统一元数据层
基于以上判断，EventHouse 的产品思路是：以消息集成为数据底座，以统一元数据层贯穿加工、存储、查询和 Agentic 检索四大模块，持续为主流 Agent 提供数据。
从下往上看，底层是消息集成服务。上游既可以 Put 写入，也可以由平台 Pull 采集；下游既可以 Pull 读取，也可以由平台 Push 投递。Kafka、RocketMQ、MQTT、RabbitMQ、EventBridge 等既有生态都可以继续接入。
数据进入之后，关键不是简单地再复制一份，而是让 Catalog、Schema、Semantic 和 Lineage 在统一元数据层持续沉淀。这样，数据每经过一次加工或存储，后续环节都不必从零解释它的含义。
四大模块共享这套元数据：
- 加工： 可以使用 EventHouse，也可以流向其他组件； - 存储： 可以使用内置存储，也可以使用开放湖格式并留在客户侧； - 查询： 可以查询 EventHouse 数据，也可以通过 Trino 联合查询外部数据源； - Agentic 检索： 可以通过 API、CLI、MCP 或 IM 提供给不同 Agent。
这套"一站式"体验并不等于封闭替换。加工结果可以流向外部组件，数据可以留在客户自己的对象存储中，查询可以联查现有数据库，统一元数据也可以独立开放给外部系统和 Agent。
4.2 语义层：让业务口径变成可执行定义
真正连接数据与 Agent，不只是接口，而是语义层。
语义层不是一份简单的字段说明书。它需要把业务理解沉淀成可以辅助匹配、关联和执行的定义。
EventHouse 将其分为五类。
1. 对象语义： 表列描述、业务名称、同义词；
2. 范围语义： 当前场景选择哪些数据源，隐藏哪些无关或有歧义的字段；
3. 关系语义： Join 条件、左右表、关系基数；
4. 计算语义： Measure、Filter 以及可执行的 Field SQL；
5. 值语义： 格式辅助和实体匹配。
以"看北京地区本季度已支付订单的净收入"为例，Agent 至少需要明确几件事：
- "净收入"对应哪个指标或字段；
- "北京"对应哪个地区编码；
- "已支付"对应什么过滤条件；
- 净收入采用什么计算公式；
- 订单表和客户表如何关联，关系基数是什么。
例如，"北京"可以匹配为 region_code = 'BJ'，"已支付"可以对应 payment_status = 'PAID'，净收入则使用经过确认的 SUM(order_amount - discount_amount)。这些定义越明确，模型越不需要依赖临场猜测。
名称负责匹配，SQL 负责精确执行，关系和代表值则负责补齐上下文。
4.3 平衡语义的建设和使用成本
EventHouse 没有使用 Semantic Web Ontology 或者 Knowledge Graph Schema 等方案，核心判断是对客户来讲，这类方案的建设和维护成本较高，没有专门的 FDE 支持，很多时候都跑不起来。Palantir 公司建设的 Ontology，也是极度依赖现场工程师的贴身服务。很多时候，不是那些客户选择了 Palantir，而是 Palantir 选择了合适他业务场景的客户。
EventHouse 选择了一条平衡的方案。 我们简化了语义的建设：除了结构化的语义定义方式，也支持客户使用 wiki 等弱语义的方式来定义语义，这种方式类似 Skill，更加灵活自由。同时，我们把对语义的理解和对齐放在了使用环节，相信 LLM 的能力和上下文窗口会不断增长，同时借助 LLM 侧缓存的优势不断降低使用成本。
语义使用环节，EventHouse 的做法是先注入与当前场景关联的可信语义，一般只选择相关的一组表（一般不超过 15 张），而不是把整个数据库都交给模型。随后，通过 ReAct 闭环让 SQL 在真实执行反馈中逐步修正。
这个闭环包括四步：
- Reason： 基于业务口径和元数据推理；
- Act： 生成 SQL 并真实执行；
- Observe： 读取返回的 rows 或 errorReason；
- Reflect： 根据观察结果修正，进入下一轮。
这里不是让模型机械地多试几次，而是让每次修正都基于可信知识和真实执行反馈。语义层负责让第一步尽量走对，ReAct 负责在走偏之后有依据地纠正。
4.4 语义初始化：先继承事实，再让 AI 提候选
新接入一份数据时，语义建设不应该从空白开始，也不应该让 AI 直接宣布业务口径。EventHouse 的初始化思路可以概括为四步：
第一步： 继承上游 Schema、表列描述、字段类型和数据访问范围。这些是确定性信息，应尽量原样继承，而不是再让模型重新猜一遍。
第二步： 采样代表值。通过数据格式和分布，补充 Format Assistance 与 Entity Matching，让系统知道名称、编码和值模式可能怎样对应。
第三步： 发现确定关系。优先使用 Schema 中已有的主键、外键和关系基数，保存有证据支持的 Join。
第四步： 再由 AI 推荐候选语义，例如可复用的 SQL Expression，或者元数据中没有直接声明、但值得专家核验的补充 Join。
最终输出的是 Semantic Draft v0，状态是待专家认证。AI 的作用，是缩短从空白到可评审草案的距离，而不是跳过业务判断。
4.5 语义认证：模型提供证据，专家承担责任
语义认证也不是让专家逐字校对模型生成的描述，而是要明确哪些业务责任不能交给模型。
- 第一是定义责任：一个指标到底怎么算，统计口径是什么；
- 第二是关系责任：哪些表应该 Join，关系基数是多少，是否会产生重复计数；
- 第三是边界责任：实体怎样映射，语义适用于哪些数据、时间和业务范围；
- 第四是发布责任：谁是 Owner，版本处于 Draft 还是 Certified，出了问题由谁决定回滚。
机器可以提供来源元数据、代表值、PK/FK、候选 SQL 和历史查询模式。领域专家根据这些证据，接受、修改或拒绝候选，并明确适用范围和生命周期。所以，一份认证后的语义资产，不只有一段描述，还应该留下决策、责任人、版本状态和 Benchmark 回归结果。只有内容、责任和验证都齐备，语义才真正具备进入生产的资格。
4.6 Benchmark：衡量业务答案，不只是 SQL 字符串
SQL 能执行，不等于业务答案就正确。平台自身需要 Benchmark 来衡量通用能力，客户也需要围绕自己的真实问题、数据口径和业务风险建立专属 Benchmark。两者缺一不可。
客户侧用例可以分为三层：
探索层：扩大问题覆盖面
这一层主要验证问题是否真实、是否可问，以及Agent 能不能生成一条可执行的 SQL。它不一定一开始就有标准答案。AI 可以批量生成候选问题和 SQL，再由人工抽样确认。即使只有问题和候选 SQL，没有 Gold SQL，这个用例也有价值，因为它可以帮助发现 Agent 能否理解用户表达。
正确性层：验证业务结果
这是客户 Benchmark 的主体。每个用例需要有 Gold SQL、预期结果和必要的业务规则。
重点不是生成的 SQL 字符串是否和 Gold SQL 完全一样，因为同一个问题可能有多种等价写法。真正需要验证的是执行结果是否正确，过滤、聚合、Join、排序和指标口径是否符合业务定义。
生产可靠性层：验证上线风险
这一层关注 Agent 在真实环境中是否稳定，例如换一种说法能不能理解，问题有歧义时会不会主动澄清，查不到数据时会不会如实返回，生成的 SQL 是否满足权限、性能和安全要求。
这一层不需要数量最多，但应重点覆盖高频、高风险场景。具体的权限规则、安全要求和验收标准，仍然需要由客户自己定义。
层级越高不等于价值越高。实际建设时，正确性层通常是主体，再根据业务风险补充生产可靠性用例。
4.7 把语义变更当作一次受控的 Pull Request
语义不是一次写完的 Prompt。
业务定义会变化，指标口径会调整，表和字段会新增，用户也会提出新的问法。每次语义变化，都可能影响已有查询和业务答案，因此需要像代码一样治理。
一次语义变更，至少应包含以下内容：变更内容与业务原因，涉及的表、指标和问题，必须回归的用例与同义问法，以及预期收益和潜在风险。
变更进入可评审状态之后，还需要设置发布门槛：核心 KPI 零回归，总体准确率不下降，延迟、错误率和成本达标，并由 Owner 批准。 如果条件不满足，就继续修改或回滚。
完整流程可以概括为：Draft → Review → Benchmark → Merge / Rollback。 把语义当作代码治理，才能获得版本、差异、审批、回归和回滚能力。
4.8 从真实问答出发，形成持续升级闭环
最有价值的 Benchmark，往往来自真实用户问题。
系统不应该只保存最终答案，还需要记录完整 Trace：原始问题、生成过的 SQL、工具调用、查询结果和最终回答。
结合用户反馈与 LLM Judge，再由领域专家确认错误归因。回答出错，可能是业务定义错了，也可能是字段或表选错、Join/过滤/聚合逻辑错误、同义表达没有覆盖，或者多轮上下文没有接完整。
先分清错误类型，修复才不会停留在"再试一次"。
归因之后，可以形成两类产出：
- 语义修复：补充业务定义，修正字段和 Join 关系，增加可信数据资产和示例 SQL，形成新的语义版本；
- Benchmark 样本：把真实失败样本加入测试集，补充多种问法、边界条件以及正确 SQL 或预期结果。
随后进行离线回归，确认总体准确率没有下降，延迟、错误率和成本达到要求；人工确认后再灰度上线，继续收集线上反馈。
这样，失败会话也能变成下一轮可复用、可验证的资产，语义则可以持续演进、评测和回滚。
两个场景：既统一，又保持开放
5.1 场景一：退单客户投诉溯源与流失预警
客服或运营负责人问："刚刚申请退单的客户中，谁在退单前 90 天内投诉过？投诉了什么？"
这句话同时跨越了时间、系统和数据类型：实时退单消息告诉我们谁刚刚申请退单；MySQL 在线库里有客户、订单和售后工单；搜索系统中则保存客服对话、投诉文本和通话摘要。
EventHouse 可以围绕 customer_id 和时间窗口，把三类数据关联成一条客户时间轴：12 天前首次投诉，8 天前多次催促，4天前工单升级，今天发生退单。
它还可以把实时退单、MySQL 结构化数据和搜索文本进行多源混合检索，不再需要人工分别查询后再手工拼接。
统一元数据同样重要。例如，要提前定义"投诉"是否包括平台工单和电话，并把 Catalog、Schema、血缘、新鲜度和权限带进查询。这样 Agent 不只是找到记录，也知道记录能否关联、是否可信、是否允许使用。
最终输出不只是退单名单，还包括投诉主题、投诉到退单的路径，以及需要优先挽留的高风险客户。业务也从"谁退单了"的事后统计，进一步走向"为什么退单"和"如何提前预警"。
5.2 场景二：制造数据一次接入，开放流出与复用
生产和质量负责人提出："某条产线的电芯温度异常，之前出过问题，希望下次发生时实时告警、同步质量库、长期归档，并让维修 Agent 使用这些数据。"
数据来自 IoT/PLC 消息、MES/ERP，以及维修和质量系统。传统做法往往是围绕不同目标各自搭建链路，最后形成多套副本和多套口径。
EventHouse 保留一条完整的一站式主链路，但四个环节都可以按需开放：加工可以使用 EventHouse，也可以交给外部流处理组件；存储可以使用内置存储，也可以使用 Iceberg、Parquet 等开放湖格式，把数据留在企业自己的对象存储中；查询可以通过 Trino 联合查询 PG、MySQL 等现有数据库；统一元数据则可以通过 API、CLI、MCP 或 IM 开放给 Copilot、ChatGPT、Claude、Gemini、Dify 和企业自研 Agent。
企业不需要一次性替换所有现有系统，也不需要为了每个目标重复搭链路。加工可以外接，存储可以开放，查询可以联查，语义也可以直接复用。
结语：跟进智能，沉淀上下文；底座可换，资产不丢
回到开头的问题：当模型、框架和 Runtime 还会继续变化，Agent 建设究竟应该留下什么？
第一，通用智能要持续跟进，但真正值得长期沉淀的是企业自己的业务上下文。模型越强，这些上下文的价值越大。
第二，消息服务已经是一条成熟的实时数据管道。下一步不只是把数据接通，而是让 Schema、语义、血缘和实时性随数据一起到达。
第三，链路需要收拢，能力必须开放。企业需要一站式的服务为全链路负责，减少交接和重复建设，同时保留对外加工、开放存储、联合查询和对接多种 Agent 接入能力。
Agent 的长期竞争力，不只取决于模型和 Agent Infra 有多强，也取决于它能不能持续看见真实业务，理解企业口径，信任数据，并基于这些信息采取行动。
EventHouse 钉钉交流群：44552972