Agent 正成为云平台的新用户：阿里云重构 300+ 产品，为 AI 调用铺路

当 AI Agent 从概念走向企业落地，云平台正在经历一次前所未有的用户身份转换。 一项调查显示，79% 的企业已在内部采用或正规划采用 AI Agent，近 74% 的企业预计两年内会用上 Agentic AI。Agent 不再只出现在客服、运营、研发等业务系统中，也开始嵌入云运维、架构设计与资源治理的工作流。 这些加速落地的 Agent，几乎都离不开云——大模型推理、向量检索、任务调度、复杂业务编排与集成，背后都需要云端的算力、存储、网络与安全。 但问题也随之浮现：当云资源被越来越多的 Agent 调用，云平台本身是否需要改变？Agent 自主规划、高批量、长任务的特性，让答案不言而喻——不仅需要改变，甚至需要重构。 阿里云正围绕这一需求加快演进。在一系列 Agentic Cloud 布局之后，阿里云发布云 Skills 门户，通过 Skills 化、MCP 化、CLI 化三条路径实现标准化的工具调用，以 Agentic Skills 为核心，把 300+ 云产品、20000+ API 升级为更适合 AI 使用的 Agent-Ready 能力。 这是国内云厂商首次系统性将云能力 Agent 化。它想改变的，是云产品被调用、被发现、被组合、被治理的方式，也让云厂商第一次有机会定义——Agent 该怎么使用云。

云计算的每一次关键演进，背后都源于操作云的主体变了。 控制台时代，云的用户是人。人通过页面理解资源，通过点击完成操作。云平台要解决的，是让复杂的基础设施变得可见、可管、可操作。 API 时代，云的用户变成了程序。工程师用脚本、SDK、CLI、Terraform 完成自动化，程序通过接口批量调度资源。云平台要解决的，是让基础设施稳定地被代码调用。 这两个阶段都有一个共同点：调用方是相对确定的。人知道自己为什么操作，程序按照预设逻辑运行。即便出错，也大多可以归因到配置、权限、代码 bug 或操作失误。 现在，新的主体出现了：Agent。 Agent 不只是调用 API。它要理解目标、拆解任务、选择工具、组合能力，把一句自然语言变成一连串云上动作。云操作的基本单元，也因此从“点击”“调用”变成了“意图”。 但问题也随之出现：Agent 是不确定的。它的每一步动作，都来自模型推理、上下文理解和路径规划。它可能理解错意图，选错工具，漏掉前置条件，也可能在失败后反复重试。对云平台来说，这是第一次面对一个会“思考”、也会“误判”的调用方。 更关键的是，传统 API 一开始就不是为 Agent 设计的。过去的 API，主要服务人和程序。文档写得不够清楚，参数缺一块，错误码不够友好，工程师往往也能靠经验补上。遇到问题，可以查文档、搜案例、提工单、反复试。人的容错能力，掩盖了不少接口本身的粗糙。 Agent 没有这种容错力。它不能像工程师一样理解含混的文档，也很难凭经验补齐缺失的上下文。过去被人消化掉的接口缺陷，到了 Agent 这里，会被直接放大。 所以，把 API 交给 Agent 之前，云平台必须先重新整理自己的能力。不能把旧接口原样抛给 Agent，而要把接口、文档、参数、边界、风险和后续动作，重新写成 AI 能理解的形式。 从技术上看，传统 API 留下的空白主要集中在四个问题：场景适不适合用、出错后怎么办、风险到底有多大、到底是谁在操作。 当 Agent 没有人类经验兜底，场景、风险、前置条件和失败处置等规则，就必须写进能力本身。因此，Agent“调云”需要一种新的接口表达，让 Agent 清楚地知道：这个能力什么时候用，能不能用，怎么用，出错后怎么办，是否需要人工确认，过程能否被追溯。

把一句自然语言翻译成一次 API 调用，只解决了最表层的问题。对企业来说，更重要的问题在调用之后才开始：这个 Agent 是谁？它凭什么有权操作这台机器？它为什么选择这个接口？这次操作会不会影响生产环境？失败后应该继续重试，还是立刻停下？整个过程能不能审计、能不能复盘？ 这些问题，靠一个“自然语言转 API 调用”的翻译层回答不了。阿里云这次要做的，正是围绕 Agent 重新整理云开放平台的底层链路。更准确地说，它是在给 Agent 操作云资源加上一套工程化的“安全带”。 这套体系背后的基本判断很清楚：Agent 可以自动化，但不能无边界地自动化；Agent 可以自主执行，但必须被身份、权限、工具、风险和审计约束住。 按主链路看，这套体系可以拆成三层，每一层处理的都是一种不确定性。 第一层，是 Agent Gateway，处理行为意图的不确定性。 Agent 的行为模式不同于人，也不同于传统程序。人不会在一秒内发起大量操作；程序通常有明确的重试、限流和异常处理逻辑；Agent 却可能在一次任务中连续拆解、并发调用、失败重试，甚至把任务继续交给另一个 Agent。 因此，Gateway 不能只被看作普通的流量入口。它更像是 Agent 行为的第一道边界，负责入口管理、流量控制、异常拦截、多 Agent 协作，以及高危操作识别。在协议层，阿里云接入 MCP、A2A 等开放协议。MCP 让 Agent 可以用标准方式调用工具，A2A 让多个 Agent 可以用标准方式协作。阿里云没有另起一套封闭体系，而是把云能力接入更大的 Agent 生态。 第二层，是 Agent 3A，处理身份的不确定性。 3A 指的是可认证、可授权、可审计。它要回答一个最基本的问题：这个 Agent 到底可不可信？ 过去，云的身份体系主要服务两类主体。人对应的是人员身份、账号、RAM 角色；程序对应程序身份、访问密钥 AK、临时凭证 STS。Agent 介于二者之间。它不是传统意义上的人，也不是一段固定逻辑的程序。它会理解上下文，会选择工具，也会在执行过程中调整路径。 因此，Agent 不能简单借用人的账号，也不能长期混用程序密钥。它需要自己的 Agent Identity，并且要和发起任务的人建立绑定关系。 这背后，是阿里云 RAM、STS 等身份能力面向 Agent 场景的升级：让 Agent 可以被独立识别，让权限按最小范围授予，让凭证短期受控下发，让每一次调用都可以被记录、追踪和审计。当“人的身份”和“Agent 的身份”同时进入调用链路，企业才能回答三件事：谁发起了操作？哪个 Agent 执行了操作？出了问题应该追到哪里？ 第三层，是 Agentic Skills 与 Agent Toolkit，处理能力使用的不确定性。 Agentic Skills 的作用，是把 300 多个云产品、2 万多个 API，重新组织成 Agent 能理解、能选择、能组合、能安全调用的 Skills。Agent Toolkit 则负责工程接入，让阿里云 CLI、SDK、Terraform、MCP Server 等工具以插件化方式协同。 这里的关键在于，阿里云没有让 Agent 绕过既有工程体系，直接裸调 API。相反，它让 Agent 沿着成熟工具链进入云：CLI 负责命令执行，SDK 负责程序化接入，Terraform 承接 IaC 编排和状态管理，MCP Server 提供标准协议支持。

阿里云的这一系列动作，标志着云厂商正式进入 Agent 化竞争阶段。当 Agent 成为新的核心云用户，云平台的传统设计逻辑——以人和程序为中心——正在被颠覆。 对于企业而言，这意味着在选择云平台时，不仅要考虑其传统能力，还要评估其对 Agent 的友好程度。Agent-Ready 的云平台，将能更高效地支持 AI 应用的落地，降低集成成本，提升安全性。 从行业视角看，阿里云此次的布局也提供了一个参考范式：如何在不破坏现有工程体系的前提下，让云能力无缝融入 Agent 生态。这对于整个云计算行业的发展，都具有启示意义。 AI大狗（AIdadog.com）作为一站式 AI 导航与资讯平台，将持续关注云厂商在 Agent 化方面的最新进展，帮助用户发现、收藏与追踪 AI 领域的关键动态。 随着更多企业将 Agent 引入生产环境，云厂商的 Agent 化能力将成为核心竞争力之一。这场由 Agent 引发的“用云范式”变革，才刚刚开始。