引言

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 留下的空白，主要集中在四个问题上。

第一，场景适不适合用。API 能告诉参数是什么，却很少说明这个操作适合什么场景。

第二，出错后怎么办。API 能返回错误码，却很少告诉 Agent 下一步该重试、改参、停止，还是上报。

第三，风险到底有多大。API 允许删除、修改、释放资源，却不天然标注风险等级。

第四，到底是谁在操作。API 能验证人或程序的身份，却很难说明一次操作究竟是人发起、程序执行，还是 Agent 自主决策。

现在，当 Agent 没有人类经验兜底，场景、风险、前置条件和失败处置等规则，就必须写进能力本身。

因此，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（AccessKey）、临时凭证 STS（Security Token Service）。

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 的能力不再悬浮在自然语言上，而是落进一条可校验、可审计、可回滚的工程链路里。

把这三层合在一起，Agentic Cloud 的基本逻辑就清楚了：Gateway 管入口和行为，3A 管身份和权限，Skills 管能力表达，Toolkit 管工具消费，HITL 管高危介入，可观测体系管全程追踪。

它真正解决的，不只是让 Agent 更容易调云，而是让企业敢把一部分云操作交给 Agent。

先可管，再可信；先可信，再可用；最后才谈自动化。

三、从意图到执行，Spec 是 Agent 调云的“稳定器”

在 Agent 调云的链路里，最容易失控的一步，是从自然语言直接跳到执行。

用户说一句“帮我搭一个网站”，Agent 如果立刻开 ECS、配网络、放端口，看似很智能，实则风险很高。因为自然语言是模糊的，云操作却是精确的。中间如果没有一个可确认、可校验的方案，模型的推理结果就会直接变成基础设施变更。

企业很难接受这种路径。

所以，阿里云在这里引入了 SDD，也就是 Spec-Driven Development，规格驱动开发。它的核心约束很简单：Agent 不能从自然语言直接进入执行，必须先从意图进入规格。

Spec 是意图与执行之间的稳定器。

还是以“帮我搭一个网站”为例。Agent 不应该立刻动手，而应该先生成一份可确认的方案：部署在哪类资源上？实例规格是什么？磁盘多大？网络如何隔离？安全组开放哪些端口？预计费用是多少？有没有更低成本的版本？是否符合最佳实践？

这份 Spec，把一句模糊的需求，变成了一个可以讨论、可以修改、可以校验的工程对象。

用户确认后，Agent 再把 Spec 转成 Terraform 等 IaC 配置。这里的关键在于：Agent 不是绕开现有工程体系，而是进入 IaC 路径。

因为云上变更天然需要工程化承接。创建一台 ECS，和批量创建一万台 ECS，不是同一件事。前者可以是一次操作，后者必须是可声明、可复用、可审计、可回滚的基础设施管理。IaC 的价值正在这里：它让云资源的变化有记录、有版本、有边界，也有恢复路径。

接下来是验证。

变更真正落地前，系统需要做校验和预检，判断操作是否符合预期，是否触碰高危红线，是否会影响生产环境。

报错机制也要随之改变。过去的报错主要给人看。到了 Agent 时代，报错还要成为下一轮修复的 Prompt。它不能只说“失败了”，还要尽量说明为什么失败、下一步可以怎么修。

最后才是 Execute，也就是受控执行。

只有规划、生成、验证都通过，变更才真正下发。高危动作在这一步触发 HITL 人工审批，由静态规则兜底，由风控引擎补强，确保关键时刻人能介入。

这条链路可以概括为四步：Plan、Code、Validate、Execute。

Plan，是把自然语言变成 Spec。

Code，是把 Spec 变成 IaC。

Validate，是在执行前校验风险与正确性。

Execute，是在受控条件下真正落地。

这四步合起来，指向一件比“接口好不好用”更深的事：所有工具和能力，无论是 CLI、SDK、Terraform、MCP Server，还是网关、身份、权限和可观测，最终都是为了让云真正可靠地运转起来。

阿里云给出的，正是这样一套面向 Agent 调云的工程框架。至于关键动作该在哪里停下来，哪些场景可以全自动，哪些场景必须人工介入，仍然需要在真实生产环境里不断打磨和沉淀。

但方向已经清楚：Agent 调云，不是把"人点按钮"换成"AI 点按钮"，而是把云操作重新纳入一套可规划、可校验、可追溯的工程秩序之中。这不是给智能套上枷锁，而是给智能划定一条能够被信任的边界——唯有可控，自动化才谈得上真正可用。、

四、真正的战场，是谁来定义 Agent 时代的云开放标准

事实上，Skills 改变的不只是接口体系，还有“云能力”的流通方式。

过去，云能力是“重”的。它们散落在 API 文档、SDK、脚本和工程师经验里。开发者要先读文档，再写代码；企业要自己补权限、审计和风控；平台每做一次集成，也要重复大量基础工作。

到了 Agent 时代，这种“重”会被进一步放大。

一方面，很多云 API 过去并没有被打磨成足够精简、稳定、可组合的接口。在人和程序操作云的时代，这些问题还能靠工程师经验消化；但 Agent 没有这样的经验，它只能依赖结构化、明确、稳定的能力描述。

另一方面，真实的云操作也很少只是调用一个 API。它通常是一串动作：先做什么、再做什么，失败后怎么办，哪些步骤需要确认。这些都需要沉淀成 SOP。

Skills 平台的价值就在这里。

它不是简单把 API 包一层，而是把稳定的 API、场景化 SOP、权限边界和调用规则，打包成一个 Agent 能理解、能调用、能组合的能力单元。

云 Skills 门户也不是传统产品目录，而是面向 Agent 的云能力入口。对外，阿里云通过 Skill Forge 计划邀请伙伴共建场景和标准；对内，企业已有的脚本、Workflow 和 Agent 能力，也可以被重新抽象成标准 Skill，变成可复用的资产。

阿里云之所以强调开放，是因为它判断：Agentic Cloud 不可能由一家云厂商独自完成。

未来的 Agent 必然跨平台、跨工具、跨云运行。如果每家厂商都有一套自己的接口和 Skill 规范，开发者很快会重新掉进碎片化里。Agent 越复杂，碎片化的成本越高。

所以，下一代云入口之争，最后可能是“标准”之争。目前，“Skill 应该如何描述”，行业还没有统一答案。谁的描述方式被生态接受，谁就更有机会成为 Agent 时代的云入口。

这也回到全文最初的问题：当 Agent 成为云的新用户，云平台该如何把能力交到它手里？

阿里云的答案是：不能只是把旧 API 翻译给 Agent，而要把能力、规则和边界一起交出去。

这个答案最终能不能立住，还要等生态投票。但至少，在很多人还急着让 Agent “能调云”的时候，阿里云先问了一个更难的问题：Agent 究竟该怎样调云？

问对问题的人，未必一定会赢。但能定义问题的人，往往已经先一步站到了入口上。