当 Agent 成为新的核心云用户：阿里云重新定义“用云范式”

引言 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 多