如果说趋势一是关于数据架构底层范式的转变，那么趋势二的核心命题是——数据架构的设计主体从“人“切换为“Agent”。面向Agent而非人设计数据架构，是AI时代企业数据架构转型的根本原则。这一原则将重塑数据的分布形态、组织模型、基础设施以及运维方式。

1. 根本原则：面向Agent而非人设计

在趋势一中，我们提出了“数据架构分析数据集上移及其与本体论转向“的核心洞察——AI时代的数据架构正在从面向流程的事务记录与分析数据集分离，走向面向语义实体的一体化智能建模。但这只是技术层面的变化，还有一个更根本的问题尚未充分展开：

数据架构的服务对象正在发生根本性迁移——从为人服务，转向为Agent服务。

传统企业数据架构的设计哲学，几十年来一以贯之：人为最主要的数据消费者。数据的组织、存储、访问、权限、安全、审计，一切都是围绕人的认知能力、协作方式和操作习惯来构建的。我们设计数据模型时，考虑的是人能否理解；设计数据门户时，考虑的是人能否检索；设计数据权限时，考虑的是人是否该看到。

这一哲学在以人为主体的信息化时代完全正确。然而，当AI Agent开始成为数据的主要消费者和处理者时，这套哲学遇到了根本性的挑战：

•Agent不疲倦、不遗忘、不误解，Agent的访问模式是高频、并发、跨源的

•Agent不依赖图形界面，Agent之间需要可机读的互操作协议

•Agent需要自主决策哪些数据需要“记住“（持久化），哪些只需要“用过即弃“

如果继续沿用面向人的思路设计数据架构，Agent将被迫“削足适履“，将AI的能力锁死在数据架构的枷锁之中。

面向Agent设计数据架构，意味着从一开始就将可机读性、语义连通性、动态可发现性、自我描述能力作为数据架构的核心设计目标，而非事后的补救优化。这一原则贯穿以下所有技术方向的变化。

1.1 行业拐点：2026年4月——Agent Workpace的集体觉醒

值得注意的是，2026年4月成为Agent数据基础设施的标志性月份。短短两周内，三家主流技术厂商密集发布了各自的Agent Workspace产品：

•OpenAI于4月23日发布Workspace Agents，基于Codex云执行底座，为每个Agent提供独立的文件、代码、工具和记忆工作空间，支持跨多步骤的长期自主运行。企业团队可在ChatGPT和Slack中共用Agent，通过“Agents目录“实现组织级的Agent资产复用。

•Google Cloud Next ’26（4月22-24日）推出Gemini Enterprise Agent Platform和Agentic Data Cloud，提出“让数据为Agent重新组织“的全新理念。其Knowledge Catalog利用Gemini自主标注和关联企业知识，Agent Studio提供低代码Agent构建能力，Cross-Cloud Lakehouse让数据留在原地即可被Agent实时查询。

•Microsoft同期发布Windows Agent Platform，将Agent Workspace与MCP（Model Context Protocol）深度集成，通过On Device Registry和Intune策略实现企业级Agent管控。

这不只是产品发布节奏的巧合，而是行业对同一趋势的集体确认：Agent专属的数据空间已经成为AI基础设施的新战场。当三个最大的云和AI平台同时押注同一个方向，这个方向就不再是推测，而是正在发生的历史。

2. 逻辑数据分布架构：Agent专属数据空间——AI时代新兴的数据集形态

2.1 从“三大数据集“到“第四极“

在传统企业数据架构中，逻辑数据分布长期稳定为三种形态：

•交易型数据集（OLTP）：支撑业务系统运行，ACID事务保障，面向流程

•操作型数据集（ODS/操作数据存储）：近实时的业务状态快照，面向运营监控

•分析型数据集（OLAP/数据仓库/数据湖）：历史数据聚合，面向决策分析

这三种数据集的分立，本质是基于“人为消费者“的假设：人通过业务系统操作交易数据，通过报表和分析平台消费分析数据，通过运营平台查看操作数据。三者的访问频率、数据结构、查询模式截然不同，分立设计是合理的。

AI Agent的崛起，催生了第四种逻辑数据集——Agent专属数据集。

这不是对前三种的替代，而是一个新的互补形态。在相当长的一段时间内，Agent专属数据空间将与交易、操作、分析三类数据集并存共生，成为企业数据版图中的“第四极“，如同当年数据仓库补充了交易数据库，数据湖补充了数据仓库，Agent数据空间将进一步补充和完善企业的数据资产体系。

2.2 Agent专属数据集的独特性

Agent专属数据集与前三种有本质区别：

维度	交易数据集	分析数据集	Agent专属数据集
服务对象	业务操作人员	分析人员/管理者	AI Agent
数据来源	业务录入	ETL汇聚	Agent运行时产生+外部集成
访问模式	单条CRUD	批量聚合查询	高频并发跨模态
生命周期	长期持久化	长期持久化	任务生命周期驱动
数据形态	结构化为主	结构化+半结构	结构化+向量+文件+会话
所有权	企业/部门	企业/部门	Agent（及背后的用户）
接口形态	SQL/REST	SQL/OLAP	语义接口+自然语言

Agent专属数据集的核心特征在于：它是以Agent的任务上下文为组织单元，而非以业务域或数据域为组织单元。一个Agent在执行“季度销售报告生成“任务时，其专属数据空间中同时包含该季度结构化的销售指标、非结构化的客户反馈邮件、语义向量化的竞品分析结果、以及Agent自我改进的操作经验——这些数据在传统架构中分属CRM、邮箱、文档库和运维日志四个系统，而Agent需要它们在同一个上下文中被统一访问。

2.3 Agent专属数据空间的普适性：从企业到通用领域

Agent专属数据空间的概念不仅适用于企业场景。在通用AI应用中，同样的趋势正在发生：

•个人AI助手：每个用户的AI助手需要独立的记忆空间，存储偏好、历史交互、个性化上下文。飞书aily率先实现了“每个用户、每个群组独立记忆空间，物理隔离不互串“的设计——100人共用同一个Agent，每人只能看到自己的数据。

•垂直行业Agent：金融风控Agent、医疗诊断Agent、法律咨询Agent，各自需要专属领域的知识空间和案例库。

•开源Agent框架：数据鲸社区的Hello-Agents项目、Spring AI Alibaba的DataAgent等，都在探索Agent专属数据管理的标准化方案。

Agent专属数据空间正在成为AI时代的通用数据基础设施概念，其普适性不亚于关系数据库在信息化时代的地位。

3. 数据物理架构：All in One与Scale to Zero——Agent数据空间的技术双核

如果说逻辑分布架构回答了“Agent数据放在哪“的问题，那么物理架构回答的是“Agent数据怎么存、怎么管“的问题。Agent专属数据空间的物理实现，需要同时满足两个看似矛盾的要求：数据形态的高度统一（All in One）和资源消耗的极致弹性（Scale to Zero）。

3.1 All in One：Agent数据集的多模态一体化

传统数据架构中，结构化数据（数据库）、非结构化数据（文件存储）、向量数据（向量数据库）通常是三分立的——各有各的存储引擎，各有各的访问接口，之间通过ETL或数据链路来维持一致性和关联性。这种分立设计在面向人的场景下是合理的：人不会同时高频访问三种形态的数据。

然而，Agent的工作模式完全颠覆了这一假设。Agent需要在一个统一的上下文中同时处理结构化事实、非结构化文档和语义向量：

•结构化数据提供精确的事实依据：订单状态、指标数值、实体关系

•非结构化数据提供上下文和背景：合同文本、会议记录、业务规则描述

•向量数据提供语义检索和记忆关联：基于相似性的召回、跨域知识的关联发现

Agent不能在接受任务时分别去三个系统查数据、然后手动合并——这种割裂会使Agent的推理效率大打折扣。2026年4月腾讯云开发者社区发布的《Agent Memory：从概念到架构的完整解析》一文指出，Agent记忆系统的最优设计是“Raw Ledger（权威记录）+ Derived Views（派生视图）+ Policy（控制层）“的三层架构，而非简单地拼接多种存储引擎。

All in One不是大一统的单一引擎，而是三个层次的一体化：

第一层：统一的数据抽象。 Agent通过统一的语义接口访问Workspace内的所有数据资产，无需关心底层是对象存储、向量索引还是关系表。数据的物理形态对Agent透明。这正是Google Agentic Data Cloud中Knowledge Catalog的设计思路——用Gemini自主标注和关联企业内的多源异构数据，为Agent提供一个语义统一的“企业地图“。

第二层：统一的基础设施承载。同一个Workspace内的结构化、向量化、文件类数据，共用同一套基础设施（计算、存储、访问控制），而非各自独立建一套“烟囱系统“。OpenAI的Workspace Agents通过Codex云底座实现了这一点——Agent的任务空间统一承载代码执行、工具调用、文件操作和记忆持久化。

第三层：统一的生命周期管理。 Workspace的创建、备份、迁移、销毁，一次操作搞定全部数据资产。这是传统分立架构无法做到的——你不可能用一个命令同时管理PostgreSQL、Elasticsearch和S3。

3.2 为什么用链接拼接行不通

也许有人会说：为什么不能继续用传统思路——各系统独立存在，Agent通过链接来关联它们？这是互联网时代最常见的数据集成模式。

答案在于延迟和一致性问题在Agent场景下被极度放大：

当Agent在执行一个复杂任务时，可能需要跨数百次数据访问——读取一个实体，然后找到它的相关文档，然后基于文档内容找到相似的历史案例，然后提取其中的数值指标。如果每一次跨越系统边界的访问都引入额外的网络延迟和状态同步问题，Agent的响应速度和推理质量都将受到严重影响。

更关键的是，Agent的信任模型不允许数据间的语义歧义。当一个实体ID在不同系统中指向不同的值时，人可以判断哪个更可信，但Agent的自动化决策需要一个唯一的、可信的数据源。用链接拼接的数据拼图，无法保证这种一致性。

因此，All in One不是技术退步，恰恰是对Agent需求的精准匹配——牺牲了系统间的物理解耦，换取了Agent使用数据时的语义内聚和访问效率。

3.3 Scale to Zero：面向Agent的数据基础设施新范式

传统企业数据基础设施的设计，隐含了一系列面向人（运维人员）的假设：

•创建过程复杂：需要申请资源、配置网络、设置权限、连接数据源，一个新数据库的创建周期通常以天甚至周计

•配置成本高：数据源连接、ETL任务、数据质量规则、监控告警，都需要人工配置

•连接即存在：资源一旦创建，就会持续运行，即使无人使用也在消耗成本

•销毁有流程：数据的删除和销毁有严格的审批流程，以防误操作导致数据丢失

这些假设对于服务人类的运维团队来说是合理的——人需要时间学习和理解系统，系统需要稳定性来支持人的工作，变更需要审批来控制风险。

然而，当数据基础设施的服务对象变成Agent时，上述假设全部失效：

•Agent可以自己完成创建过程，但如果创建需要几天时间，Agent的工作流就会被卡在“等待数据就绪“上，根本无法发挥并行和实时的优势

•Agent的负载模式是高度弹性的——一个Agent可能同时活跃数千个Workspace，也可能同时处于静默状态，按峰值预留资源成本将无法承受

•很多Agent任务只需要一个临时数据环境来存储中间结果，任务完成后这个环境就无需存在，如果需要人工审批销毁，Agent的自主性完全丧失

因此，面向Agent的数据基础设施必须实现Scale to Zero：

•即用即起（Instant On）：Agent请求一个Workspace，数据基础设施在秒级甚至毫秒级完成创建和初始化

•即放即毁（Auto Cleanup）：Workspace的生命周期由任务生命周期决定，任务完成即自动释放

•弹性伸缩（Elastic）：根据Agent的实际负载动态扩缩容，空闲时收缩到零

•零接触运维（Zero Ops）：Agent自主管理Workspace的全生命周期

3.4 Scale to Zero对架构的深层影响

Scale to Zero不只是性能指标的变化，它对整个数据架构产生了深刻影响：

存储与计算分离成为必选项。如果存储和计算强耦合，Scale to Zero就无法实现——无法在不卸载数据的情况下释放计算资源。对象存储（如S3）加无状态计算层（如Lambda）的组合，正是Scale to Zero在云原生日渐普及的技术基础。

无服务器架构（Serverless）成为首选。传统的“购买服务器→部署数据库→配置连接“模式，根本无法满足“秒级创建Workspace”的需求。Serverless数据库和Serverless向量存储，将“创建一个数据库“的成本从小时级配置降低到秒级API调用。

成本模型从“资源预留“转向“实际使用“。传统模式下，企业为数据基础设施支付的是“最大容量“费用，即使实际使用量远低于此。Scale to Zero的模式下，成本与Agent实际发起的数据操作量直接挂钩。

3.5 当前局限与演进方向

需要承认的是，当前的数据基础设施生态距离真正的Scale to Zero仍有距离：

•大多数主流数据库（包括向量数据库）尚不支持真正的秒级Workspace创建

•跨模态数据的统一存储仍然需要组合多个服务

•Workspace级别的成本计量和精细化计费，尚未成为主流云服务的标配

然而，2026年4月的产业信号已经清晰指示了方向。Google的Agentic Data Cloud、OpenAI的Workspace Agents、Microsoft的Agent Platform都在向同一个目标演进：让Agent能够像调用一个函数一样创建和管理自己的数据空间。

4. Agent数据空间之间的交互：新的数据总线架构

Agent专属数据空间解决了单个Agent的数据自足性问题，但Agent并非孤立运行。在多Agent协作场景下——一个销售Agent、一个风控Agent、一个财务Agent协同完成客户尽调——这些分散独立的Agent数据空间之间需要高效、安全、标准化的数据交换机制。

4.1 为什么传统数据总线不够用

传统企业数据总线（ESB、Kafka、API Gateway）的设计哲学是“系统间的系统“：一个中心化的消息路由层，负责在不同应用系统之间转发数据。这套模式对于应用系统间的数据集成是有效的，但对于Agent数据空间的互联存在三个根本不适应：

•粒度不匹配：传统数据总线面向的是“系统“级别的集成，而Agent数据空间之间的交互需要“任务“级别的数据交换——Agent A在完成某个计算步骤后，Agent B需要的是该步骤的输出结果和推理上下文，而非整个数据空间的批量同步。

•语义需求：Agent之间的数据交换不只需要数据本身，还附带语义元数据（置信度、来源、推理路径、时效性）。传统消息队列只传递数据载荷，不携带语义。

•自主性需求：Agent需要自主决定何时与哪些Agent数据空间交换什么数据，传统集成模式需要预定义数据流和映射规则。

4.2 A2A与MCP：Agent数据空间交互的标准协议

2026年，两个关键的协议正在成为Agent数据空间互联的标准基础设施：

A2A（Agent-to-Agent）协议：Google于2025年底提出的A2A协议，定义了Agent之间发现、通信、协作的标准化方式。在数据空间层面，A2A使Agent能够声明自己数据空间的能力（“我能提供什么样的数据“），发现其他Agent数据空间的能力，并建立安全的点对点数据交换通道。截至Cloud Next ’26，A2A协议已在150个组织中得到应用。

MCP（Model Context Protocol）：Anthropic推出的MCP则更聚焦于Agent与数据源之间的上下文交换。Microsoft将MCP深度集成到Windows Agent Platform中，使Agent能够通过标准化的上下文协议访问本地和云端的数据资源。MCP为Agent数据空间提供了一种“标准插座“——任何遵循MCP的数据源都可以被Agent无缝接入其专属数据空间。

4.3 技术实现：Msg.io与Dropbox模式

在上述标准协议的框架下，Agent数据空间之间的数据交换可以通过两种互补的技术模式实现：

消息通道模式（Msg.io）：类似于消息队列的“发布–订阅“模型，但面向Agent数据空间的语义进行了增强。每个Agent数据空间可以发布“数据通知“（Data Notification），声明产生了什么样的数据，附带了什么样的语义元数据。其他Agent数据空间可以订阅其关心的数据通知，并通过安全通道拉取数据。这解决了Agent数据空间之间的数据发现和事件驱动协作问题。

文件投递模式（Dropbox）：类似于文件共享的“投递–接收“模型。Agent A将特定数据打包为标准化的数据包（Data Package），投递到指定的共享空间。Agent B从共享空间拉取数据包并解包使用。这种模式适合大体积数据的异步交换，以及需要审计追踪的数据传递场景。

两种模式互为补充：Msg.io适合高频、小数据量、实时性要求高的交互（如Agent间的状态同步、任务协作），Dropbox适合低频、大数据量、异步的交互（如报告输出、模型文件、数据集的共享）。

4.4 数据空间交互的治理与安全

Agent数据空间之间的数据交换带来了新的治理挑战：

•数据所有权边界：一个Agent产生的数据何时变成另一个Agent数据空间中的“居民“？谁有权修改或删除它？

•语义污染风险：如果一个Agent数据空间接收了错误或低质量的数据，它的决策质量会受到什么影响？如何追溯责任的源头？

•权限传递：Agent A有权限访问某数据，但Agent B没有。如果Agent A将数据传给了Agent B的Workspace，权限应如何传递？

这些问题的解答，需要结合“面向Agent而非人设计“的根本原则——治理规则也需要是可机读、可自动执行的，而非依赖人的审批流程。

5. All in One数据模型与本体Ontology的深层呼应

5.1 Ontology方法的核心思想

在趋势一中，我们详细展开了本体Ontology在数据建模维度的价值：Ontology的本质是将业务领域的概念及其关系形式化，使数据和语义融为一体。

Ontology的核心思想可以概括为：

•实体即数据：概念不是外在于数据的“元数据“，而是内嵌在数据的组织结构中

•关系即一等公民：实体间的关系和实体本身同等重要，而不是外键约束的附属品

•可推理性：基于Ontology模型，可以从已知数据推导出未知知识

5.2 All in One是Ontology在基础设施维度的投影

当我们将Ontology的哲学延伸到数据基础设施层面，会发现All in One的数据模型设计，本质上是Ontology思想在基础设施维度的投影：

从Ontology视角看，Workspace中的所有数据资产——结构化记录、非结构化文档、向量embedding——都是同一个业务本体的不同表示侧面。它们描述的是同一个Workspace所服务的业务语境中的实体和关系，只是表现形式不同。

语义内聚优于物理分布——这是Ontology方法论的核心理念在Agent数据空间设计中的自然延伸。Workspace不是简单的“把所有数据放在同一个存储桶里“，而是要确保：结构化事实与描述这些事实的上下文之间具备可追踪的语义链路；向量检索的结果能够回溯到原始的结构化实体；非结构化文档中引用的实体能够被精确解析和关联。

Google的Agentic Data Cloud正是这一理念的工程实践：Knowledge Catalog利用AI自主标注和关联企业数据，为Agent提供一张可导航的语义地图。

6. 结语：从“数据平台“到“数据空间“的范式迁移

纵览趋势一和趋势二，我们可以清晰地看到一条主线：企业数据架构正在从“平台范式“走向“空间范式“。

传统的数据平台范式中，数据是集中的、管理是中心化的、访问是通过门户的——人围着平台转。而面向Agent的数据空间范式中，数据是Agent专属的、管理是分布式的、访问是通过语义接口的——平台围着Agent转。

这一迁移的核心推动力，既是AI技术的成熟（使Agent成为主要数据消费者），也是数据本体论思想的深化（使语义内聚取代物理集中成为更高优先级的设计目标），更是产业实践的共同选择——2026年4月，当OpenAI、Google、Microsoft在同一时间窗口推出各自的Agent Workspace产品时，这个方向已经从学术讨论变成了产业共识。

6.1 核心观点回顾

本文贯穿始终的三个核心观点：

第一，从逻辑数据分布架构来看，Agent专属数据空间正在成为AI时代新兴的数据集形态——它不只是企业数据架构的增量补充，更是面向Agent的数据策略的基石。如同关系型数据库定义了信息化时代，Agent数据空间将定义智能化时代。

第二，在相当长的一段时间内，Agent专属数据空间将与原有的交易、操作与分析数据集并存共生——它不是一个“替代者“，而是一个新的“互补形态“。企业数据架构将进入“四极并存“的新阶段，如何在这四极之间建立高效、安全、语义贯通的数据交换体系，是下一阶段的架构核心挑战。

第三，从物理架构来看，Agent专属数据空间的技术特色是All in One + Scale to Zero的双核驱动——数据形态的统一抽象和资源消耗的极致弹性，是同一个硬币的两面。同时，Agent数据空间之间的交互需要新的数据总线架构——以A2A和MCP等标准协议为基础，以Msg.io消息通道和Dropbox文件投递为技术实现的新一代数据交换体系。

Scale to Zero则从运维效率和经济性的角度，为这一迁移提供了现实的技术约束和发展方向。

可以预见，未来三到五年，那些率先完成“面向Agent数据架构“转型的企业，将在AI应用效能、数据资产复用、运维成本优化等方面建立起显著的竞争优势。数据架构的竞争，将从“谁的平台更大“转向“谁的数据空间更智能、更敏捷、更Agent-Native”。

这一转型不会是平滑的渐变——它需要企业在数据思维、组织架构、技术选型和文化层面都做出深刻的调整。但方向是明确的：不是让AI适应数据架构，而是让数据架构适配AI。这是AI时代企业数据战略的核心命题。

— — —

本文为“AI时代企业数据架构转型趋势“系列的第二篇。