阿里云与 Qoder 探索让 Agent 直接使用云，把部署、运维、数据分析等任务从人工操作转为自动编排。
原文标题：用云新范式：Qoder Cloud Agents × Alibaba Cloud Skills
原文作者：阿里云开发者
冷月清谈：
文中重点介绍了 Alibaba Cloud Skills 与 Qoder Cloud Agents 的组合。前者将阿里云 300 多款产品、2 万多个 API 封装为带语义、权限、前置条件和可复跑剧本的 Skills；后者提供可常驻、可被事件触发、具备身份和记忆的 Agent 承载环境。
文章用几个场景说明这种模式的潜力：一句话部署高可用应用、告警触发后的自动排障与受控止血、专家经验沉淀为可复用 Skill、数据报表自动运行并按业务需求继续下钻。核心思路是把过去依赖人工操作、脚本和 Runbook 的云上任务，逐步变成可审计、可确认、可复跑的 Agent 工作流。
本文部分链接为合作推广
怜星夜思：
2、Agent 时代，运维和云工程师的工作会被替代，还是会变成另一种形态？
3、把专家经验封装成 Skill，真的能复制资深工程师的判断吗？
4、你愿意把哪些云上任务先交给 Agent？哪些任务必须坚持人工确认？
原文内容
阿里妹导读
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
凌晨两点，一份数据报告在没有任何人值守的情况下，自己跑完了。
中途它遇到一个问题——计算资源组被冻结。要是换成一段脚本来跑这个任务，这时就该红着脸报错，然后把值班的人从床上薅起来了。
但这次没有。它自己申请了一个新的按量资源组，绕过去，把报告跑完，安静地躺进早晨的收件箱。
写这份报告的，不是人，是一个 Agent。
我们越来越确信，云计算的下一个十年，会从这样一件“小事”开始——云的使用者，可以不是人，而是 AI。
云的第四代界面
先问一个简单的问题：今天要在云上部署一个高可用 Web 应用，要做哪些事？
开 ECS 选规格、进 VPC 配安全组、去 SLB 建负载均衡、申请 HTTPS 证书、配 ESS 自动扩缩容、再到域名服务绑解析——六个控制台，几十个配置项，每一步都可能出错。资深工程师半天，新手一周。
这不是技术问题，是界面问题。
云计算的每一代界面，都在回答同一个问题：怎么让人用更少的脑子，办更多的事。
-
Web 控制台（2006）：让你不用再买服务器、租机房；
-
CLI / SDK（2010）：让操作可编程、可批量、可版本控制；
-
Terraform / IaC（2014）：让你只声明“要什么”，工具负责收敛；
-
Agent（2026）：让你只说“为什么”，剩下的它自己搞定。
每一代都把上一代变成自己的工具，而不是淘汰它：CLI 调 SDK，Terraform 调 CLI，Agent 内部照样在调 CLI、写 Terraform——只是你不再需要知道这些。就像今天写网页不用懂 TCP 三次握手，Agent 时代用云，你不用知道 SLB 和 ESS 是什么。
货架已经搭好，缺一个“人以外的使用者”
过去十年，云从一台 ECS 长到几百款产品、上万个 OpenAPI——云上的每一个动作，都有了一个可被调用的接口。这是一份完整、规整、可信赖的能力底座。
今年，阿里云又往前推了一大步：把 300+ 款产品、2w+ API 的能力，从“裸 API”进一步封装成 Skills 并开源给用户（skills.aliyun.com）。一份 Skill 带语义、带前置条件、带副作用声明、带最小权限模板、带可复跑剧本——它的预设使用者，从一开始就是 Agent。
Alibaba Cloud Skills 把这些能力按场景架成一个货架：应急的、数据的、成本的、研发的……专门为 Agent 准备。
货架搭好了，下一步是让这些 Skills 真在云上被用起来。这需要一个承载体：一个有机器身份、有长期记忆、能在云上常驻、能被 API 和事件触发的 Agent。
这正是 Qoder Cloud Agents 在做的事。
我们其实一直在解同一道题
云计算从第一天起就在解一个问题：让基础设施变成水和电。
为此，过去十年云行业做了很多事：把硬件抽象成虚拟资源，让人不用管机房；把资源抽象成代码，让人不用点控制台；把代码抽象成模板和编排，让人不用反复写。每一步，都在减少“人作为云的使用者”必须付出的工作量。
“做事”这一侧，已经被抽象得足够完整。下一段路要解的，是“用云”这件事本身——那张越来越富集的云能力地图，不该再靠一个人的脑子去装。
我们也做过很多“让机器替人干活”的尝试：脚本、Runbook、ChatOps、自动化平台。但它们有个共同点——另一头，都还站着一个人。 脚本跑在某个人的电脑上，Runbook 用某个人的账号，ChatOps 在某个人在场的会话里。人，在每一步都必须在场。
Agent 用云，就是把这个“必须在场的人”挪走。
Agent 到底怎么用云
场景一 · 一句话部署
过去：把一个 Node.js 项目部署到生产，要开 6 个控制台、配几十项参数，资深工程师半天。
现在：
“帮我把这个项目部署上线，要高可用、HTTPS、自动扩缩容，预算每月 2000 元以内。”
Agent 在独立沙箱里自己干完：分析依赖、按预算选规格、建 VPC 和安全组、配 SLB 和证书、写并执行部署脚本、配好扩缩容、验证结果，最后交给你一份部署报告、访问地址和架构图。
你说了一句话，Agent 编排了六个云产品。你甚至不用知道 SLB、ESS 是什么。
用云门槛，从“需要专家”降到“能说人话”。
场景二 · 睡后运维
凌晨 3 点 07 分，一条告警弹出来。
换成过去，这时候该有个人被闹钟薅起来：登 Grafana、翻 SLS、SSH 上服务器、查 RDS 慢查询……然后用一颗打了折的凌晨大脑做判断。
这次没人起床。告警响的同一秒，Agent 接住了：顺着调用链定位根因——一条慢查询把连接池吃满了；按预设安全策略止血（只调参、只临时扩容，不删不缩）；验证服务恢复，写好诊断报告，然后停在那儿，等一个人。
早上 9 点，值班同学到岗，看完回了俩字母：approve。
从摸黑排障，变成等一个 confirm。
它敢放手，不是因为 Agent 有多聪明，而是因为验收口设计得够严。一个真实的漏斗数据：634 个 issue 进去，系统筛出 190 个有效缺陷、自动提交 25 个 CR，人工 review 后合入 12 个。634 进，12 出——漏斗的价值不在生成了多少，在挡住了多少。
场景三 · Skill 即服务
过去：新人学用云，文档散在几十个产品站，问老员工各说各话，踩个坑排查一天，三个月才勉强上手。
现在：一位资深架构师，把“数据库选型”这项专家能力打磨成一个 Skill，发布为服务。之后任何人都能一句话调用：
“我们有个电商项目，日活预计 50 万，要扛秒杀，预算不超过 5 万/月。”
Agent 跑这个 Skill，输出：推荐 PolarDB-X 分布式 + Redis 缓存，附分库分表策略、缓存预热方案、QPS 承载估算和月度成本明细。
资深 SRE 的故障诊断、安全专家的漏洞扫描、架构师的 API review——都能这样服务化给整个团队。
个人经验，不再锁在某个人的电脑里，而变成组织级的可复用能力。
场景四 · 数据自己生长
开头那份凌晨自己绕开冻结资源、跑完的报告，就是这个场景。
更妙的是它会长。决策者看完想再下钻一层，“帮我拆一下华东区 top5 门店的时段分布”。一句话，Agent 下一轮就把新维度加进分析，不用开发介入改代码。
能力，会随着业务需求自然生长。
它带来的连锁反应
云的使用者不必是人——我们想让这成为一组非常具体的产品事实。它的连锁反应，可能比我们想的还远：
-
对运维：on-call 不再是 7×24 人肉值班——告警触发，Agent 直接接住，拉日志、定位根因、受控止血、产出修复 PR，人只在高危那一步确认。
-
对数据分析：取数、问数不用再排队提工单——每个业务同学都有一个“会用云的分析师”，一句话提问，它自己探 schema、写 SQL、出图、给归因。
-
对数据工程：清洗、转换、回流这些跑批脏活不用人盯——按规则幂等执行、可调度复跑，把脏数据稳定变成可用的数据集。
-
对成本：账单不再是月底才看一眼的报告——每天一份带“预计月省 + 一行修复动作”的可执行清单，省钱动作经确认即可落地。
更多的想象，不止于此。
Agent，是云的最后一个界面
Web 控制台让你不用买服务器，CLI 让操作可编程，Terraform 让你只说“要什么”，Agent 让你只说“为什么”。
再往后，当 Agent 成为主界面，控制台、CLI、Terraform 都会变成它的工具——它们仍然在，只是你不用再直接面对它们。
Agent是云的最后一个界面。因为它之后，界面本身就不需要了。
如果你是开发者、运维、数据、业务，或者只是一个想让 on call 消息少一点的人。来开一个 Agent，给它派一次活试试看。
👉 快速开始：
https://qoder.com/cloud/quickstart
👉 文档：
https://docs.qoder.com/zh/cloud-agents/best-practices/cloud-use
千问云-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问云体验
点击阅读原文即可体验！