从 Google Agentic Data Cloud 看：个人 Agent 能干活了，企业 Agent 卡在哪了？

开发者用 Claude Code、Codex、Qoder 直接生成生产级代码；产品经理用 QoderWorker 、OpenClaw、Hermes完成竞品调研、撰写 PRD；运营人员用 Agent 自动化处理客户工单、生成周报。个人 Agent 已经在真实的工作场景里干活了，“从问答到干活”不再是口号，而是每天的日常。

但当企业试图把 Agent 部署到真实业务环境里干活时，问题就来了。上面这些个人 Agent 干的活——写代码、做调研、处理工单——都是基于公开知识或用户自己提供的上下文完成的。但企业 Agent 要干的活完全不同：它需要基于企业内部数据做决策、执行操作、完成业务流程。

举个例子：你想让一个 Agent 预判库存断货风险并自动补货。这个 Agent 首先要知道你们的库存周转逻辑、各SKU的安全库存线怎么定义，然后要能同时安全的访问ERP、仓储系统和供应商数据，最后还要能自动生成采购订单并提交审批，而不是只发个"库存不足"的告警。这三层，每一层都是一道坎。

2026年4 月下旬，谷歌在 Google Cloud Next 大会上发布了 Agentic Data Cloud，专门尝试回答这个问题。我们仔细研究了谷歌的思路，发现它指向的方向和我们已经在做的事情非常一致。这篇文章，我们想和大家分享的不是具体发布的产品功能，而是一个更本质的问题：

企业 Agent 从“能问”到“能干活”，到底需要过哪几道关？

企业 Agent 落地的三道坎

从“能问”到“能干活”，企业 Agent 需要过三关，这三关是递进的——前一关没过，后面的就别想：

第一关：读懂数据（问答的前提）

个人 Agent 干活时，你会自然地提供背景。但企业数据的业务含义嵌在组织记忆里——“orders”表和“users”表是什么关系，“gmv”字段算不算退款，“月活”的统计口径是什么。这些知识散落在数据库注释、开发文档、甚至老员工的脑子里，从来没被系统化过。没有这些语义，Agent 连问答都做不对，更别说干活。

第二关：安全访问（干活的前提）

即使 Agent 读懂了数据，企业也不会让它直接操作生产库。几十个 Agent 同时访问数据，谁能看什么、谁能改什么、敏感数据怎么脱敏、误操作怎么回溯？没有安全边界，CTO 不会允许 Agent 碰生产环境——别说干活，连查都查不了。

第三关：真正干活（从问答到行动）

这是最大的跳跃。大多数方案做到“让 Agent 能查数据”就停了，但企业真正需要的不是一个“能回答问题的 Agent”，而是一个“能完成任务的 Agent”。能自动预判库存风险并自动发起补货——这才是企业想要的“干活”。

谷歌的答案：Agentic Data Cloud

谷歌在 Google Cloud Next 大会上给出了他们的解法。仔细看本次发布的产品能力主要围绕读懂和使用数据展开：

解决数据分散：跨云湖仓。基于 Apache Iceberg 标准，BigQuery 可以直接查询 AWS、Azure 上的数据，不需要迁移。“数据不用搬，就能被 AI 用起来”。

解决读不懂：Knowledge Catalog。自动从各个数据源抓取元数据，用 AI 分析查询日志、推断业务逻辑、生成语义标签，让 Agent 不仅知道数据在哪，还知道数据代表什么。谷歌称这是“整个数据战略里技术含量最高的一块”。

解决怎么用：Data Agent Kit + MCP。发布数据库 Managed MCP Server，让 AI 直接连接运营数据；发布 Data Agent Kit，支持在 VS Code、Gemini CLI、Claude Code 等开发环境里直接使用。数据工程师的角色从“写管道”变成了“审核 Agent 输出”。

谷歌的方向判断是准确的。但如果仔细看，会发现这套方案本质上解决的是“问答”问题——让 Agent 能查到数据、读懂数据、用自然语言操作数据。但企业的真实需求是“干活”——不只是回答“磁盘快满了”，而是自动扩容并通知相关人；不只是告诉你“有慢 SQL”，而是自动分析并执行索引优化。另外，这套方案以 BigQuery 为中心，安全管控也未被重点展开。对于已有复杂数据架构的企业，这些都是待解问题。

企业 Agent 从“能问”到“能干活”的全流程

阿里云瑶池数据库在企业级Agent落地上已经实践了一年多，趟过了不少坑。接下来想分享的，是一个企业 Agent 从“能问”到“能干活”的完整链路。我们认为，这个链路至少需要三步。

第一步：先让 Agent 理解你的数据

这是整个链路的起点，也是最容易被跳过的一步。

很多团队一上来就想让 Agent 查数据库，结果发现 Agent 写出的 SQL 经常“语法对但业务错”。根本原因是：Agent 不理解你的数据资产。它不知道哪张表存的是订单、哪个字段是金额、两张表之间的关联关系是什么。

我们的做法是构建了 Meta Agent，它是企业的“知识大脑”。 Meta Agent 做的第一件事是“资产盘点”：自动扫描和解析所有数据源的元数据，为每个资产生成业务描述、关联实体、血缘、使用说明、场景化最佳实践（Skills）。这个能力已经上线。

如果说谷歌的 Knowledge Catalog 是“给数据建索引”，那 Meta Agent 做的是“给企业建知识”。它不仅标注元数据业务语义知识，还会自动拆解业务口径、构建Ontology、生成Skills、甚至引入行业知识，并且能够根据使用和反馈来实现知识进化。

Meta Agent 的核心价值：它不是一次性的“数据标注工具”，而是一个持续积累、不断进化的企业知识大脑。它生成的知识、口径和 Skill，会被所有 Agent 共享和复用。Agent 用得越多，Meta Agent 就越懂你的业务。

第二步：打通安全的数据通道

有了知识大脑之后，Agent 知道该查什么、怎么查了。但企业不会允许 Agent 直接连数据库——这就像不会允许一个新员工第一天就拿到生产环境的密码。

Agent DataGateway 就是我们为之建设的安全通道。 Agent 借助 Meta Agent 自动生成的知识和 Skill 去访问数据，而 Agent DataGateway 确保这个过程是安全、可控、可审计的。具体来说：

Agent身份认证：每个 Agent 有独立身份，可以和企业现有的身份体系无缝打通；

数据权限管控：精确到库、表、字段、行级别的访问控制；

数据脱敏：识别敏感数据，敏感数据自动脱敏后再返回给 Agent；

安全规范拦截：不符合安全规范的操作自动拦截或触发审批，避免 Agent 误操作；

操作审计日志：所有 Agent 的数据访问行为可追溯、可回溯。

同时，网关支持 100+ 跨云多模数据源的统一接入。不管数据在哪、是什么形态，Agent 都通过同一个网关访问——数据不用搬，引擎也不用换。可通过搜索文章《别让 AI Agent 按下数据库的”核按钮”》了解更多。

第三步：让 Agent 真正能干活

谷歌的 Agentic Data Cloud 解决的是“让 Agent 能查数据”，为此提供了Data Agent Kit + 数据库 MCP，但在企业场景里，"能查"只是起点。企业真正需要的是 Agent 能基于数据执行动作——发现问题并修复它，而不是只报告问题。

这中间有一道真正的鸿沟：从"查到数据"到"完成任务"，Agent 需要具备真正的企业认知。

让 Agent 干活的前提：企业认知从哪里来

个人 Agent 之所以能干活，是因为它依赖的是公开知识——编程语言的规范、互联网上的信息、用户提供的上下文。但企业 Agent 要干的每一件事，都依赖一种完全不同的知识：企业自己的业务常识。

什么是"安全库存线"？"月活"的统计口径是什么？库存周转逻辑里哪些 SKU 是例外？这些知识从来没有被系统化过，散落在文档、注释、甚至老员工的经验里。Agent 没有这些认知，就算查到了数据，也不知道该怎么用它做决策和处理。

我们的解法分三层，自上而下建立认知、自下而上持续演化：

第一层：构建初始本体给 Agent 装上企业常识

人构建初始本体，通过Meta Agent盘点+业务专家定义构建企业最核心、最稳定的业务概念、关系和规则——"订单"是什么、"用户"和"订单"之间是什么关系、"GMV"的计算口径是什么、哪些情况会触发库存变更，可以轻量但必须正确。之后通过Meta Agent进一步拓展盘点范围，生成企业最初始的业务语义知识。

这不是简单的元数据标注，而是业务语义的结构化表达。它是 Agent 理解业务的"第一性原理"——有了它，Agent 才知道查到的数据意味着什么，才能做出符合业务逻辑的判断。

第二层：人机协同，在行动中反哺知识

第一层定义的是静态的业务常识，但企业的业务是动态的。新的业务规则、新的数据口径、特殊场景下的例外处理——这些知识不可能一次性穷举完。

我们的做法是让企业内每一个 Agent 共享同一份知识底座（DataWiki），同时在每次执行任务的过程中，通过人机协同不断反哺和丰富这份知识，越用越懂，持续积累。Agent 执行了一次补货操作，人工审核时发现某个 SKU 的安全库存线需要调整——这个修正不只是修改一次参数，而是更新了整个知识体系里关于这类 SKU 的业务规则，下一个 Agent 再遇到同类情况时，就已经知道该怎么处理了。

这是共享知识的核心价值：不是一个 Agent 学会了，而是所有 Agent 都学会了。

第三层：自下而上，动态完善企业知识

光靠人工审核驱动的反哺还不够。随着 Agent 的大规模使用，知识的完善需要能够自主发生。

我们在实践中探索的方向是：企业Agent 在执行任务的过程中，由Meta Agent自主识别知识缺口、提出知识补充建议，再经由人工确认后沉淀进知识体系。比如 Agent 在处理一批跨境订单时，发现现有的"订单"定义里没有覆盖汇率换算的规则——Meta Agent会标记这个知识缺口，推动知识体系自我完善。

这是从"人教 Agent"到"Agent 和人一起建知识"的转变。知识体系不再是一次性交付物，而是在 Agent 的每一次行动中持续生长的活体。

遥望远方

企业 Agent 从“能问”到“能干活”的第一、二步能力阿里云瑶池数据库已经构建完成，第三步能力也在不断优化中，有几个方向是我们在实践中继续探索的：

1、从“单点任务”到“端到端的业务流”

当前企业结合阿里云瑶池数据库的能力，已经能够较好地完成单点任务——查一次数据、备份一次、优化一条慢 SQL。但企业真实的业务问题从来不是单点的，一个异常事件背后往往涉及跨系统的数据、跨角色的决策、跨环节的执行。

我们在探索的方向是：让多个 Agent 协作完成端到端的业务流。从发现异常→分析根因→执行修复→验证结果→通知相关人，每一个环节由专职 Agent 负责，全链路自动化完成，不需要人工在中间反复传递信息、协调推进。这不是单个 Agent 能力的叠加，而是多个 Agent 在同一套知识体系下的真正协同——Meta Agent 构建的业务认知是这种协同的基础，它确保每个 Agent 对业务概念的理解一致、对操作边界的判断对齐，协作才不会变成"各说各话"。

2、从能干到规模化的干

单个 Agent 能干活，不等于企业能规模化地用 Agent 干活。当前的 Skill Plan 已经解决了知识共享的问题——100+ 场景 Skill 开箱即用，所有 Agent 共享同一套能力底座。但这些 Skill 目前还是由人来定义和封装的，规模化的天花板在这里。

我们在探索的方向是：让 Skill 的生成本身也自动化。在企业 Agent 的真实使用过程中，系统自动识别哪些操作模式是高频的、哪些处理逻辑是跨场景可复用的，并将其自动转化为标准化的 Tool、MCP Server 或 Skill——不需要人工定义，不需要开发介入，Agent 用着用着，自己就长出了新工具。

3、从自进化的知识管理到知识大脑

当前 Meta Agent 已经能做知识管理——自动标注元数据、沉淀业务口径、积累 Skill，知识也在 Agent 的使用过程中持续丰富和进化。但知识管理解决的是"把已有的知识管好"，知识大脑要解决的是更进一步的问题：主动理解企业在发生什么、行业在走向哪里，并基于这种理解自动生成新知识驱动企业Agent的进化。

我们在探索的方向是：让Meta Agent能够持续感知企业经营动态——业务数据的趋势变化、跨部门的决策模式、异常事件的处理路径，并将视野延伸到行业层面，自动追踪行业趋势、竞争变化、外部政策，让知识体系不只反映企业的过去，还能预判企业需要面对的未来。

当知识体系具备这种主动感知和自动生长的能力，它就不再只是 Agent 的"参考资料"，而是成为驱动所有 Agent 高效协同和进化的"中枢"—业务在扩张，知识大脑感知到了，自动调整相关 Agent 的认知边界；行业在变化，知识大脑追踪到了，提前让 Agent 具备应对新场景的能力。企业不需要每次业务变化都重新配置 Agent，知识大脑会替它做这件事。

写在最后

个人 Agent 的时代已经到来，企业 Agent 的战争刚刚打响。

谷歌发布 Agentic Data Cloud，是一个重要的行业信号：企业 Agent 的核心矛盾不在模型，在数据。这和我们一年多前开始做的判断完全一致。不同的是，谷歌在解决“能问”，我们已经在解决“能干”。

方向对只是第一步。真正的比赛在于谁能在企业的真实环境里跑通从“能问”到“能干”的全链路——让 Agent 理解数据、安全地使用数据、基于数据真正干出活来、还能越干越好。谷歌的发布证明了方向，我们的实践正在证明它的可行性。