正好有时间，将一些最新观察落在博客里。数据驱动，智能决策；我相信大都对此深信不疑。智能体数据的下半场，不再主要争夺更多文档，而是争夺谁能进入真实工作流。我依然毫不怀疑的认为的数据集成很可能是智能体数据下半场最确定的机会之一，但它不会只是“给智能体多接几个数据源”，而是从传统的数据搬运，升级为智能体的感知、上下文和行动基础设施。
举个例子，如果我们想要做智能体驱动决策的智慧工厂，第一件事是什么？那一定是如何把现有的机器数据通过某种方式采集上来。得益于产业工业 4.0 的升级，现在很多工厂的数据可能天然已经存在某个数仓或者数据库了。下一步，应该是将这些数据通过某些手段喂给 Agent 。讲白了就是 Agent 和 Data 的 Bridge 能力。
核心判断
传统数据集成解决：如何把数据从 A 搬到 B。
智能体时代的数据集成要解决：如何让智能体在正确时间，以正确语义和权限，看到可信状态，完成数据获取，并确认结果。
因此，未来的数据集成平台至少包含四层：
连接层：数据库、SaaS、API、文件、消息与事件
上下文层：实体、语义、规则、质量、时态与权限
行动层：查询、预览、执行、审批、验证与恢复
控制层：血缘、轨迹、评测、审计与持续学习
过去很多厂商和产品只覆盖第一层，智能体会把竞争推向后三层。这个趋势我在最近的各种报告中已经看到无数的创业团队蜂拥到这个赛道。包括我现在做的 Datyo.ai 以及业内一些很火的项目 houghtspot，getwren.ai 等，几乎所有的创业项目都是向这个方向去的。
为什么现有 ETL/ELT 不够？
ETL 和 ELT 是为报表、分析和批处理设计的，典型特征是：
1. 数据从源系统流向仓库
2. 几分钟到几小时的延迟可以接受
3. 主要面向人类分析
4. 查询多，行动少
5. 关注表是否更新，而非业务是否完成
智能体的工作循环不同：
发现事件 → 获取当前状态 → 查询历史 → 理解规则→ 作出判断 → 调用业务系统 → 验证结果 → 持续观察
它对数据集成提出四个新增要求：
时性：数据不仅要完整，还必须处于正确时态
双向性：既要读数据，也要安全写回业务系统。
语义性：不能让智能体从列名和 API 字段中猜测业务含义
状态性：需要保留跨系统、跨时间的任务状态
可验证性：工具返回“成功”不等于业务结果真的正确
Google 2026 年将这一变化描述为从被动的 “System of Record” 转向主动的 “System of Action”，并明确把数据联邦查询、实时摄取和操作型数据库放入同一个智能体闭环。这是一个很强的产业信号，尽管其中的效果案例仍属于 PPT 阶段。
传统数据集成能力会怎样重估
批处理不会消失；但不再是唯一主干。历史分析、财务结算、模型训练依然适合批处理。真正变化的是，批处理之外会出现一条“实时上下文路径”：CDC 捕获业务状态变化，流处理进行聚合、过滤和实体关联，事件触发智能体，智能体查询历史与当前状态，行动结果再次写入事件流。Confluent 已经把流处理、智能体运行和 MCP 工具调用结合进 Flink/Kafka 管道，允许智能体持续消费事件并调用外部工具。Confluent Streaming Agents 的出现意味着 CDC 和事件流的价值会从“同步数据”升级为“驱动智能体观察—行动循环”。
数据目录会升级为运行时上下文服务；传统 Catalog 主要服务数据工程师查表、看血缘。智能体需要在每次推理和行动之前动态查询：
这是什么业务对象
数据由谁负责
当前质量是否合格
是否包含敏感信息
哪个字段是权威来源
智能体是否有权访问和行动
Google 的 Knowledge Catalog 正在把第三方目录、业务逻辑、使用日志和非结构化数据自动标注汇聚为上下文层，并让搜索结果继承访问权限。因此，Catalog 的下半场不是“更好地搜数据”，而是成为智能体决策前的事实与策略查询服务。
iPaaS 会转向“智能体行动控制面”；传统 iPaaS 的 Recipe、Flow 和 API 编排拥有三个天然优势，大量现成连接器，确定性的工作流执行企业级凭证、重试和审计。但大模型不能直接取代这些能力。更合理的架构是模型负责理解意图和处理不确定性；iPaaS 负责执行确定性流程和控制风险。Workato 正把连接器和流程封装为可复用的 Enterprise Skills；MuleSoft 则把既有 API Catalog 暴露为 MCP 工具，并用图式编排把模型推理与确定性控制流分开。Workato ONE、MuleSoft Agent Fabric所以 iPaaS 的未来定位可能是，智能体的业务技能库、事务执行器与行动治理平台。
MCP 会不会取代数据集成？
这个问题确实困扰了我非常久的时间。举个例子，如果用户为每个数据源都挂载一个独立的 MCP ，数据平台的价值是否就不复存在了？经过很长时间的观察，我的回答是不会。
MCP 更像智能体时代的 USB 接口。它主要标准化：工具如何被发现，参数如何描述，智能体如何调用，资源如何返回，客户端如何授权连接问题。但 MCP 本身并不解决数据是否新鲜，多个系统中哪个数据可信，两个字段是否表达同一业务概念，写操作是否幂等，流程是否需要审批，执行失败后如何补偿，最终业务状态是否正确，工具描述是否被恶意篡改等等问题。
NSA 2026 年的 MCP 安全指南也指出，MCP 简化了能力集成，但动态工具调用、隐式信任关系和上下文共享会带来新的系统性风险。因此，我判断 MCP 降低“连接”的门槛，反而会让数据连接器上面的能力更值钱：语义、质量、权限、事务、验证和可观测性。单纯包装 API 的 MCP Server 会迅速同质化。
我认为值得探索的产品机会
Agent-ready Data Bridge；在企业数据与智能体之间建立统一入口，对外提供 MCP、API 或技能，对内连接数据库、仓库、SaaS 和事件流。关键差异不在连接数量，而在每次返回数据时附带来源，更新时间，质量分，敏感等级，业务定义，权威性，允许采取的行动等信息。相当于“带语义和治理的智能体数据 API”。
Semantic CDC：语义化变更数据捕获：普通 CDC 告诉系统：orders.status 从 2 变成了 3。语义化 CDC 应该告诉智能体：一笔高价值订单已付款，但库存仍未锁定，距离承诺发货时间还有两小时，需要检查履约风险。机会在于把底层数据变化转化为业务事件，关联实体，影响范围，紧急程度，可执行建议，对应规则与证据。这个可能是事件驱动的又一个机会。
实时数据质量防火墙：传统数据质量通常在入仓时运行。智能体需要在三个时间点检查：
读取前：数据是否足以支持决策
行动前：关键实体和字段是否完整、一致
写入后：结果是否违反业务规则
例如，智能体准备修改供应商银行账户时，即使 API 参数合法，也应该触发跨系统一致性、异常行为和审批规则检查。
跨智能体上下文交换：A2A 已进入 Linux Foundation，目标是让不同厂商和框架构建的智能体相互发现、通信与协作。但真正困难的不是消息传递，而是双方是否使用同一个实体标识，数据和任务状态如何同步，权限是否可以委托，上下文如何最小化披露，如何避免重复执行，责任如何在多个智能体间传递，这会产生“跨智能体集成总线”的机会，但市场成熟度低于前几个方向。
总结
简单来说，我有个断言智能体时代，数据集成会出现三个阶段：
Connect：让智能体接入更多系统
Contextualize：让智能体理解数据的含义、时态与可信度
Operationalize：让智能体安全行动、验证结果并从经验中学习
第一阶段正在被 MCP 和前期数据集成平台快速标准化，壁垒极低，但也不可或缺；真正的长期机会集中在第二、第三阶段。换句话说，未来数据集成最大的价值，不再是“把数据送到目的地”，而是建立一条从业务变化到智能行动，再到结果反馈的闭环。如何保证数据在真实环境的可用，可能是未来最大的发展机会。