Cloud Use：当 Agent 开始真正使用云

本文作者：泮圣伟

前言

Qoder Cloud Agents 工程实践系列：如果 Agent 的边界是工具调用，那么 Cloud Use 的边界则是云原生执行。前者让 AI 帮人操作软件，后者让 Agent 成为云上的新型工作负载。读完这篇文章，我们会看到 Cloud Use 和普通 Tool Use 的差别其实不在「能不能调 API」，在于 Agent 是否能以受治理的身份、凭证、环境、生命周期和审计轨迹，真正进入云的生产体系。

凌晨 2 点，一个跨境商家的新品突然爆单。人还没醒，Agent 已经开始工作。它创建临时沙盒，拉取库存和支付数据，检查异常订单，模拟不同物流方案，计算关税影响，生成客服话术，调整投放建议，并把高风险订单交给人工确认。它没有打开控制台，也没有登录一台服务器，但它确实在使用云。

问题也在这一刻变得尖锐：这个 Agent 用谁的身份访问库存系统？它看到的支付数据是否经过脱敏？它调用云 API 的凭证在哪里？如果它调整了资源规格，谁授权的？如果任务跑了 40 分钟 后失败，状态能不能恢复？每一步操作能不能被审计？让 Agent 调一次云 API 并不难。难的是，让它每天调、半夜调、跨系统调、带着权限边界调，并且每一次调用都知道是谁授权的、用了什么凭证、做了哪些动作、是否触发了风险控制、结果能不能被复现。

这就是 Cloud Use 要回答的问题。

01云迎来了第二类使用者

过去二十多年，云计算的主要交互模型围绕两类对象展开：人类操作者，以及确定性自动化程序。人登录控制台，人创建 ECS，人配置数据库，人看日志，人处理告警；CI/CD、Terraform、Kubernetes Controller 和各类定时脚本，则按预先定义好的规则执行。

后来有了 CLI、SDK、IaC 和更多自动化平台，人的操作成本下降了很多，但系统背后的假设仍然清晰：要么是人在操作，要么是确定性程序在执行。这个模型很稳定。云平台围绕它设计了账号体系、权限模型、审计日志、控制台交互和工单流程。一个 RAM 用户、一个 AccessKey、一条操作记录，背后通常都能映射到某个具体的人、团队或系统。

Agent 出现后，中间地带也随之产生。它不再只是回答「这个云产品怎么用」，也不只是生成一段脚本。它开始读取日志、分析账单、诊断 CI、检查数据任务、调用 OpenAPI、提交 MR、触发流水线。换句话说，它正在从“懂云的助手”变成“使用云的执行者”。

云计算过去主要围绕人类操作者和确定性自动化程序设计。Agent 带来的新变量，是一种会推理、会调用工具、会跨系统行动的机器执行体。

这件事的影响比「多一个 AI 助手」大得多。如果使用者还是人，那么控制台、CLI、SDK、IaC 都是在降低人的操作成本；如果执行者是确定性程序，云平台要管理的是服务账号、角色、策略和日志。

可 Agent 介于两者之间：它有人的目标理解能力，又有程序的执行速度和调用规模，不需要控制台、鼠标和桌面，却需要身份、权限、工具、数据、运行环境、状态管理、成本记录、失败恢复和审计链路。如下图所示，我把这三类使用者放在一起，他们之间的边界会更清楚。

在这张图里，人类和确定性程序都是云已经熟悉的使用者，账号体系与审计链路已经打磨了二十年。Agent 则是介于两者之间的新变量：它既不像人一样一次点几下鼠标，也不像脚本一样只走确定路径，而是会推理、会跨系统串联行动。云平台要接纳它，就得在同一套治理层里为它开一条通路；可现实是，很多仅具备 Tool Use 能力、却缺少云平台原生治理的 Agent，在 Demo 阶段看起来能跑，真正进入生产却会遭遇卡住的情况。它们能调用工具，但还没有被云平台当成一个可管理的执行主体来接纳。

02为什么 Agent 很难成为云上工作负载

我们都意识到，并不是模型不够强，而是当下的 Agent 从来没有被云真正「接纳」过——Demo 里跑得漂亮，落到生产就现原形。

一个云上 Agent Demo 很容易搭出来：给它一组 AK/SK，包几个 OpenAPI 工具，写一段 Prompt，告诉它“帮我查一下昨天的账单异常”。如果模型足够强，工具封装得也不错，它确实能跑出一个像样的结果。第一天看起来很顺，第二天问题就来了：这组 AK/SK 是谁的？权限是不是太大？密钥有没有进入模型上下文？工具调用日志在哪里？它如果误删资源算谁的？用户关掉电脑后任务还跑不跑？换一个团队成员，凭证和上下文怎么复用？安全团队怎么审计？这些问题不是边角料。它们决定了 Agent 能不能从 Demo 进入生产。

仅具备 Tool Use 能力的 Agent，典型形态是一次对话、几个工具、一个结果。它常常站在人的影子里：借人的电脑运行，借人的账号登录，借人的 AK/SK 调接口，借人的在线状态维持任务。短任务没问题，探索性分析也没问题。可如果没有身份、凭证、运行时和审计体系，它就很难成为稳定的云上工作负载。Cloud Use 要解决的不是「Agent 会不会调用工具」。这个问题已经被 Tool Use、Function Calling、MCP 解决了一部分。Cloud Use 要解决的是另一个问题：云如何接纳 Agent，让它以可识别、可授权、可审计、可托管的方式运行。

仅有 Tool Use 的 Agent 解决的是“模型如何调用工具”；Cloud Use 解决的是“云如何接纳 Agent 成为受治理的使用主体”。

这句话揭示了其中的分水岭。它把讨论的核心从「Agent 能碰到什么工具」，推到「Agent 在哪里运行、以什么身份运行、凭证如何使用、任务能持续多久、失败后能不能恢复、谁能审计它」。

仅靠 Tool Use 的 Agent 像一个临时助手，坐在你旁边帮你操作；Cloud Use 更像给 Agent 发了一张工牌，让它进入云上的工作现场，但每一道门禁、每一次取证、每一个动作都留下记录。

03Cloud Use 的价值要从场景前后对比里看

概念说到这里已经足够，接下来把它按场景拆开看，才能看出 Cloud Use 到底在生产里补上了哪些洞。只讲「Agent 能查日志、跑报表、调 API」，很难和普通 Agent 拉开差距，因为这些事普通 Agent 也能做。真正的差异要从工作方式的变化里看：任务是否脱离人的在线状态，Agent 是否能自己进入云上现场收集证据，执行动作是否有身份、凭证和审计边界。

1. 周期性任务：从「有人每天打开系统」到「任务自己醒来」

很多云上任务并不复杂，却一直依赖人的操作。回到开头那个跨境商家的场景，爆单之后团队第二天要看的东西很多：库存是不是被打穿，支付失败率有没有异常，物流成本有没有突然上升，客服工单是不是集中在某个地区。放在今天，这通常意味着有人打开 BI 系统、云账单、数据平台和日志平台，一项项跑查询，再把结果整理到群里。流程高度重复，规则也相对清晰。它的问题不是难，而是必须有人在场。

普通 Agent 可以缓解一部分工作。它能帮人写 SQL、解释异常、润色报告。但多数情况下，人仍然要发起任务、提供上下文、确认凭证、把结果复制到目标系统里。Agent 只是把某一步做快了，整条链路仍然系在人身上。Cloud Use 的变化在于，任务可以自己醒来。

一个 Cloud Agent 可以在云端按 cron 触发，可以被各种突发的事件触发，它能够使用任务级身份访问数据源和云工具，通过 Vault 使用受控凭证，通过 MCP 调用 BI、日志、存储、计算等能力。它完成查询、识别异常、生成报告，再把结果推回 IM、文档、Webhook 或业务系统。人不需要每天在固定时间打开页面。

周期性任务的变化，是“任务不再依赖某个人在线”，而非“报告写得更快”。

节省的是责任结构。过去是“某个人每天记得做”；现在是“一个受托任务按时运行，人只处理异常和决策”。在我们讨论过的样例任务里，一次 BI 分析包含 111 次 工具调用，持续约 21.5 分钟（21 分 32 秒），中间 0 人工干预；一次 ETL 任务产生 116 个 事件，运行 13 分钟，由 cron 触发完成。这些数字来自具体样例任务，不代表所有场景的稳定 SLA。它们的意义不在于炫耀调用次数，而在于说明 Agent 已经不只是聊天窗口里的回答者，它能承担一段有生命周期的云上任务。

2. 诊断任务：从「人喂材料」到「Agent 进入现场取证」

CI 失败、慢查询、线上告警，是另一类典型任务。过去一个 MR 挂了，开发者要打开流水线日志，看测试失败原因，查最近依赖变更，确认构建镜像，再去云上看构建机、缓存、网络、权限配置。很多时候问题并不深，只是上下文散在太多系统里。普通 Agent 在这里也有用，你把日志贴给它，它能总结错误；你把配置贴给它，它能判断可能原因。但这仍然是“你把材料拿给 Agent”。Agent 不能自己进入现场，不能自己追溯证据链，只能分析你喂给它的片段。

Cloud Use 让诊断任务换了一种方式。当 CI 失败事件发生，Agent API 在云端直接被触发。它会主动使用云的身份去读取流水线日志，查询相关 MR，检查依赖变更，访问构建环境状态，必要时调用日志和监控系统，把证据串起来，再把结论写回 MR 评论、IM 群或工单。这时 Agent 做的不只是“总结日志”，它在主动做取证。

诊断任务的变化，是“Agent 能自己进入云上工作现场，收集上下文并形成证据链”，而非“模型更会解释错误”。

ELK 慢查询、CI 失败诊断这类场景尤其能体现差异。在我们讨论过的样例里，慢查询诊断可以在 2–5 分钟 内给出端到端结论，CI 诊断可以在 3–8 分钟 内把分析写回 MR。具体耗时会受系统规模、工具响应和上下文复杂度影响；有价值的不是几分钟这个数字，而是 Agent 不再等人复制材料，它开始围绕事件主动收集证据。

3. 执行任务：从「脚本自动化」到「受治理执行」

最容易被误解的，是执行类任务。如果 Agent 能诊断问题，能不能让它直接修？能不能让它创建预览环境、触发流水线、清理临时资源、调整配置？跨境商家的例子里，Agent 可以自动生成补货建议、模拟物流方案，但真要调整投放预算、改变履约策略或处理高风险订单，就必须停下来等人确认。技术上，给它足够权限就能做，但恰巧真正的风险也藏在这里。

过去很多团队已经有脚本自动化。脚本有密钥，有权限，有定时任务，也有日志。但脚本通常缺少动态判断，缺少跨系统上下文，也不擅长解释结果。普通 Agent 补上了判断能力，却可能把风险放大：它能根据上下文采取行动，但如果身份、凭证、权限、审计没有跟上，自动化越强，事故半径越大。

Cloud Use 的目标不是让 Agent 无边界地自动执行。恰恰相反，它要把执行变得可托付。低风险动作可以自动执行，比如读取日志、生成报告、创建临时沙盒、清理过期资源。高风险动作必须进入确认，比如删除生产资源、扩大权限、修改线上配置、触发影响用户的发布。Agent 可以给出建议和证据，但不能越过边界。

执行任务的变化，不是“全自动替代人”，而是“低风险自动化，高风险可审批，全过程可追溯”。

到这里，周期性、诊断、执行三类任务已经画出了轮廓：Agent 不再是聊天窗口里的助理，而是一个有身份、有边界、有生命周期的执行体。普通 Agent 的自动化常常依赖信任：相信 Prompt，信任模型，信任工具封装。Cloud Use 依赖的是治理：身份可识别，凭证不可见，权限可收回，动作可审批，过程可审计，失败可恢复。

04某咖啡品牌是如何把分析任务交给云上的 Agent

理论说清楚之后，就得压到一个真实场景里看它是不是真的能跑。下面这一节，就是我们把上面的模型丢进一杯咖啡的经营会。

周一早上九点，连锁咖啡品牌的经营会要开始了。CEO 不想听一份“整体表现良好”的周报。他要三个答案：哪种店型坪效最高，哪个品类正在长出第二曲线，下季度新店应该优先去哪座城市。杭州、深圳、成都、广州，15 家 门店，数据散在 4 张 表里，事实数据 320 行。问题不大，但足够烦。传统流程大家都熟：业务方提需求，数据分析师排期，确认口径，写 SQL，查 MaxCompute 或数仓，整理表格，再写成经营报告，快的时候几天，慢的时候一两周。不是分析师不努力，而是这类任务总要在人的日程里排队。

Cloud Use 的性感之处，不是让 Agent “也会写 SQL”——那太普通了。真正的变化在于：这件事可以被托付成一段云上任务，Agent 是一个带身份、带凭证边界、带运行时、带事件回传、带验收标准的机器执行体，不再只是聊天窗口里的问答对象。

咖啡 BI 这个案例的价值，在于它把“经营问题 → 数据访问 → 查询执行 → 异常恢复 → 结果回传 → 验收证明”跑成了一条完整链路。

这条链路可以划成六个工程问题，这是一次真实任务往前推进时绕不开的六道门槛：

1.凭证：先进 Vault，不进 Prompt

任务刚开始，最先撞上的不是 SQL，是凭证。Agent 要查数仓，最粗暴的办法是把 AK/SK 塞进 Prompt。快，但也很危险。密钥会进入模型上下文，可能出现在工具日志里，也可能被某个中间结果带到 Webhook payload。真实生产里，这一步过不了安全评审。

所以凭证先进入 Vault。Agent 拿到的不是明文密钥，而是 vault_credential_id 这样的引用。运行时访问 DataWorks、MaxCompute 或其他云服务时，由平台侧或工具侧完成凭证兑换和受控注入。这个判断很关键：Agent 可以使用云，但不能拥有一把能被复制走的万能钥匙。

2.路径：Skill 沉淀踩坑史，而不是重玩一遍

凭证问题解决后，第二个麻烦马上出现：它该走哪条路？Agent 知道要分析 MaxCompute 数据，不代表它知道真实企业环境里应该通过 DataWorks 提交 ODPS SQL；它可能寻找一个看似更直接的接口，也可能在不适用的 API 上反复试错。模型越“聪明”，越会给自己编出一条看起来合理的路。Skill 的价值在这里才显出来，它不是提示词模板，是组织踩坑史：哪些接口不要用，ODPS SQL 有哪些语法坑，资源组冻结时先查什么，报告输出必须有哪些字段。在这个样例里，Skill 避免了约 13 分钟 的错误路径探索。这个数字来自这次样例任务，不作为通用承诺；它说明的是：Cloud Use 要复用的不是一次 Prompt，而是一条被验证过的执行路径。

路径收敛之后，问题转向角色边界。“你是数据分析师”这句话太宽了，宽到 Agent 可以写一份很漂亮、但无法追溯的报告。进入云端执行前，Agent 必须被收窄：能用什么工具，按什么口径输出，遇到什么异常可以自救，什么动作必须停下来。

3.角色边界：任务合约，而不是「你是分析师」

一个简化的任务合约可以长这样：

你是一名资深数据分析师。
你需要通过 DataWorks 执行 ODPS SQL 分析 MaxCompute 数据。
每个分析维度都必须输出：
1.带数字的结论；
2.查询结果表；
3.可执行的业务建议。
不要输出无法追溯的数据判断。
遇到资源组不可用时，先检查可用资源组；
必要时按预案创建临时资源组并记录操作。

这不是 Prompt 技巧展示。它更像一份小型任务合约：结论必须带数字，数字必须能回到查询结果，异常处理不能越权。

4.运行时：云上 Session，不是本地进程

任务真正跑起来后，考验的是运行时。这次样例运行持续 21 分 32 秒，产生 111 次 工具调用、312 个 事件，中间 0 人工干预。这里的数字不是平台 SLA，也不是所有 BI 任务的性能承诺。它们证明的是另一件事：Cloud Use 可以承载一段长于普通聊天回合的多步骤任务，而且过程可追踪、可回放、可接入业务系统。这一步是“本地跑一下 Agent”和“云上托付一段任务”的分岔口。用户发起任务后，Agent 在云端 Session 里继续执行；浏览器关闭、电脑休眠、聊天窗口断开，都不应该影响任务生命周期。

5.结果回传：监听正确事件

报告生成之后，还有一个经常被低估的问题：它怎么回到业务系统？如果最后只是在聊天窗口里输出一段文字，BI 数字员工还是没有进入业务流。更可靠的方式，是业务系统订阅任务结束事件，比如在 session.thread_idled 之后拉取完整结果。监听太早，拿到的是半成品；等线程进入 idle，再取报告，结果才稳定。

这里放一段实践代码，反而比继续解释概念更直观：

import hmac
import hashlib
import time

def verify_webhook(secret: bytes, raw_body: bytes, header: str, tolerance: int = 600) -> bool:
    parts = dict(item.split("=", 1) for item in header.split(","))
    timestamp = int(parts["t"])

        if abs(time.time() - timestamp) > tolerance:
            return False

    payload = f"{timestamp}.".encode() + raw_body
    expected = hmac.new(secret, payload, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, parts["v1"])

def handle_event(event):
    if event["data"]["type"] == "session.thread_idled":
        session_id = event["data"]["id"]
        enqueue_report_pull(session_id)

代码不长，但边界很清楚：Webhook 要能证明来自可信来源；任务完成要由事件触发；报告拉取要异步处理。否则 Agent 跑完了，结果却丢在半路，这条链路仍然不算完成。

6.验收：可执行的 Rubric

最后，任务不能靠 Agent 自己宣布完成。一个 BI 任务是否完成，不看最后有没有一段像报告的文字，要看它是否回答了经营问题：哪种店型坪效最高？哪个品类增长最快？哪个城市应该优先扩张？每个结论有没有数字？数字能不能回到 SQL 查询结果？

最后产出的是可检查的经营判断：快取店日均坪效约 ¥85+/㎡，是旗舰店约 ¥38/㎡ 的约 2.2 倍；咖啡 GMV 占比 81.3%，茶饮环比增长 18.5%，周边环比增长 45.0%；城市扩张评分里，杭州 0.92，深圳 0.85，成都 0.78，广州 0.70。这些数字才让 BI Agent从“会生成报告”变成“能回答经营问题”。

7.边界，边界，还是边界！

样例中还出现过资源组不可用的问题。普通脚本通常会失败退出，普通 Agent 可能会继续尝试错误路径，直到人介入。Cloud Use 更合理的处理方式，是把「资源组不可用」写成 Skill 里的已知失败模式：先检查可用资源组，必要时在预授权边界内创建临时资源组，记录操作，再继续执行后续 SQL。超出成本、权限或资源范围的动作，仍然进入人工确认。这类自救能力不能被理解成「Agent 可以随意改云资源」。相反，它说明 Cloud Use 的成熟度在于失败发生后，Agent 是否能在治理边界内恢复；不能恢复时，是否知道干净地停下来。

真正可托付的 Agent，不是自己宣布任务完成，而是它的完成状态可以被事件、日志、产物和验收标准共同证明。

回过头看，咖啡 BI 这条链路并不只是一个案例。它把 Cloud Use 的理论落到了一个具体现场里：凭证不能裸奔，所以有 Vault；路径不能靠猜，所以有 Skill；执行不能依赖人的在线状态，所以有 Session；结果不能停在聊天窗口，所以有 Webhook；完成不能靠自我声明，所以有 Verification。这也是 Cloud Use 从“看起来自动化”走向“可以进生产”的关键一步。

05Cloud Use 不是 API 包装，是一套云原生执行模型

从咖啡 BI 的现场退回来，我们可以给 Cloud Use 一个更抽象的定义了：Cloud Use 是 Agent 以可控、可审计、可恢复的方式，使用云上的计算、数据、工具、身份和运行时来完成任务的能力。它不是把云 API 包一层自然语言，也不是给控制台加一个聊天框。那只是入口变化。真正的变化，是 Agent 从「调用工具的模型」变成「可以被云平台托管的执行体」。

这件事至少需要四层能力。它们是一条依赖链：没有身份就谈不上凭证，没有凭证就谈不上工具，没有工具就谈不上运行时。

1.Identity Use 解决的是「谁在操作」。Agent 不能长期冒用人的账号，也不应该持有人类 AK/SK。一个云上执行体的每次动作，都应该能回答：任务是谁发起的，Agent 以什么身份执行，权限来自哪里，什么时候过期。

2.Credential Use 解决的是「凭证怎么用」。凭证可以参与调用，但不应该进入 Prompt、工具日志、错误栈或 Agent 可以自由读取的临时文件。Vault、短期令牌、受控注入和服务端代理，本质上都是为了让 Agent 能用凭证，但看不到凭证。

3.Tool/API Use 解决的是「工具怎么被治理」。MCP 或类似协议可以让云 API、内部系统、CI、监控、数据库进入 Agent 世界，但协议本身不等于治理。权限、参数约束、调用审计、速率限制、风险确认和错误恢复，仍然需要平台层、网关层和企业 IAM 一起承接。

4.Runtime Use 解决的是「任务怎么活下去」。真正的云上任务很少是一次问答。它可能跑 10 分钟，也可能跑 2 小时；可能等待外部系统返回，也可能中途失败重试。云端 Session、状态管理、事件流、取消机制和结果回传，决定了 Agent 能不能从一次聊天变成一段可托管的执行过程。

Cloud Use 的本质，不是让 Agent 多一个工具，而是让 Agent 获得身份、凭证、工具和运行时之后，成为可托管的云上执行体。

如果没有这些，Agent 仍然只是一次对话里的聪明助手。它可以帮忙，但很难被托付。

06真正的革新：从「人操作资源」到「Agent 承担任务」

四层能力搭起来之后，云的使用关系其实已经在悄悄变化，人不再是唯一的第一线操作者。控制台、CLI、SDK、IaC 都在解决同一个问题：人如何更高效地操作云资源。控制台把机房变成页面。CLI 和 SDK 把页面变成命令和代码。IaC 把一组资源变成可声明、可复用、可审计的配置。每一次演进，都在把底层细节往后藏，让人站在更高的抽象层上操作云。

Agent 带来的变化不只是抽象层再高一点。它让「任务」本身有机会成为新的云抽象。人不再逐项操作资源，转向定义目标、边界和验收标准。Agent 在云端创建环境、访问数据、调用工具、并行探索、验证结果、释放资源。它像一种新的工作负载，生命周期可能很短，权限应该很细，资源使用高度动态，行为必须可追踪。

过去云的核心抽象是资源。Agent 时代，云还需要面向任务和机器执行体的新抽象。

这也是 Cloud Use 让新旧界面重新排位的地方。它不是替代控制台、CLI、SDK 或 IaC。相反，这些旧界面会变成 Agent 的工具层。Agent 不需要点控制台，但可以通过受控接口完成控制台背后的动作；Agent 不需要手敲 CLI，但可以调用等价的云 API；Agent 不需要手写完整 Terraform，但可以生成、验证、提交变更，并把高风险部分交给人确认。新的界面不会消灭旧工具，它会把旧工具放到自己的执行层里。

这也是为什么「可托付」比「全自动」更重要。企业不会把云交给一个黑盒 Agent，他们愿意托付的，是一个有身份、有边界、有日志、有恢复机制、能在关键节点停下来等人确认的执行体。Cloud Use 要建立的不是盲目信任，是可验证的信任。

07

Cloud Use 的难点：

让 Agent 失败得可控

前面讲的是范式变化，听起来很完整。但真实生产不会因为一个模型完整就变得温顺。只展示成功案例，会让 Cloud Use 看起来像宣传。真正的工程分水岭，往往出现在失败发生之后。因为真实的云上任务一定会遇到失败：接口不适用、权限不够、资源组不可用、查询超时、Webhook 丢失、结果不满足业务标准。生产化的关键，不是把这些失败藏起来，也不是让模型用更长的推理把错误绕过去，而在于让失败路径本身进入设计。

Cloud Use 真正要解决的，不是让 Agent 永远成功，而是让 Agent 失败时可观察、可约束、可恢复；恢复不了时，能干净地停下来。

1.错误路径：Agent 会走向看似合理但实际不可用的 API

Agent 推理能力越强，越容易给出“看起来合理”的路径。比如它知道要查 MaxCompute 数据，于是尝试寻找一个直接执行 SQL 的接口；但在真实云产品路径里，正确方式可能是通过 DataWorks 的临时工作流或指定执行入口完成。没有 Skill 和工具边界时，Agent 会在错误路径上消耗时间，甚至反复尝试。解决方式不是让模型“更聪明一点”，而是把正确路径和错误路径都沉淀进 Skill。告诉 Agent 哪些接口可用，哪些接口不要走，遇到特定错误码如何切换路径。

2.基础设施异常：资源组冻结不应该直接变成人工中断

资源组被冻结、队列不可用、权限临时失效，这类问题在传统流程里通常会变成人工介入点。Cloud Use 可以把其中一部分变成受控自救路径：先检查可用资源组，再判断是否存在预授权的临时资源组创建策略；如果在边界内，就创建、绑定并记录操作；如果超出边界，就停止执行并请求人工确认。重点不是“Agent 自己修好了”，而是它没有越权。能自救的在边界内自救，不能自救的明确停下。

3.结果回传异常：监听错事件会拿到半成品

云端 Agent 的执行过程会产生很多事件。如果业务系统监听得太早，比如只看到状态更新就去拉取报告，拿到的可能是半成品。更稳妥的做法，是在任务线程进入 idle 后再拉取完整结果，并对 Webhook 做签名验证、幂等处理和重试。这类细节很小，但决定了 Cloud Use 是一次演示，还是一个可以接入业务系统的生产链路。

4.验收过松：Agent 看起来完成了，但业务没有得到答案

Agent 很容易生成一份像报告的报告。标题有了，表格有了，建议也有了。但如果没有验收标准，它可能没有回答真正的问题：哪种店型坪效最高？哪个品类增长最快？哪个城市应该优先扩张？每个结论有没有数字？数字能不能回到 SQL 查询结果？

Rubric 太宽，Agent 很容易通过；Rubric 太细，任务可能反复修正。Cloud Use 的工程能力之一，就是把“什么叫完成”写成可执行、可检查的标准。这也是 Cloud Use 和普通 Agent 最容易拉开差距的地方。普通 Agent 在失败时经常给出一个看似合理的解释；Cloud Use 更关心的是：错误发生在哪一步，是否越过权限边界，是否触发重试，是否产生审计事件，是否需要人接管。

一个 Cloud Agent 的成熟，在于失败时不会把系统带到更坏的状态，而不是从不遇到错误。

08边界：Cloud Use 不适合从最高风险任务开始

失败可以被恢复，不等于任何任务都可以直接交给 Agent。第一步交给它做什么，比「它能做什么」更关键。任何新范式都容易被过度想象。

Cloud Use 也一样。如果一上来就说「让 Agent 自动管理生产云环境」，技术读者会本能地警惕。这种警惕是对的。云上的生产变更、权限扩大、数据删除、账单操作，都不应该因为 Agent 会推理就自动放开。更现实的路径，是从低风险、高频、结果可验证的任务开始，再逐步爬升到带确认的执行、最后才碰高风险变更。这条路径可以画成一条三阶段的成熟度曲线：

顺着这条曲线，具体任务可以对号入座。比如周期性巡检、成本异常分析、CI 失败诊断、日志慢查询分析、临时环境创建、过期资源清理、报表生成、数据任务状态检查。这些任务有共同特点：读取多于写入，结果容易验证，失败可重试，风险边界清晰。

等这些任务跑通，再逐步扩展到带确认的执行动作。比如 Agent 给出修复建议，人确认后触发流水线；Agent 生成 IaC 变更，人 review 后合入；Agent 创建临时资源，到期自动回收；Agent 检测到成本异常，先通知，再等待人工批准调整策略。

Cloud Use 的成熟，不体现在 Agent 能不能越过人，而体现在它知道什么时候必须停下来等人。

这条边界必须讲清楚。否则 Cloud Use 很容易被误解成“让 AI 自动操作云资源”。真正的目标不是扩大模型权限，而是把权限、凭证和执行放回云平台可以治理的地方。

09当 Agent 真正开始使用云

三阶段的路径最终指向的问题很简单：当云的使用者不再只有人，我们希望云变成什么样子。如果说控制台、CLI、SDK、IaC 解决的是人如何更高效地使用云，那么 Cloud Use 解决的是另一个问题：当云的使用者不再只有人，云平台如何接纳、约束并托管一个机器执行体，这就是它和普通 Agent 的根本区别。普通 Agent 可以帮人完成一次操作，Cloud Use 要让 Agent 成为云上的新型工作负载：它有身份，有环境，有工具，有生命周期，有审计轨迹，也有必须遵守的边界。

这种变化不会一夜之间替代现有用云方式。控制台还会存在，CLI 还会存在，IaC 还会存在，只是它们的位置会变，从人直接使用的界面，逐渐变成 Agent 可以调用、验证、提交和回放的工具层。Cloud Use 的价值，不是让 Agent 看懂云，也不是让 Agent 多调用几个云 API，它真正改变的是云的使用关系：Agent 不再只是人的外挂，而开始成为云平台可以识别、授权、托管和审计的执行主体。

下一步，真正值得做的不是把最高风险的云操作交给 Agent，而是从那些高频、低风险、可验证的任务开始：让它定时巡检、诊断失败、分析成本、生成报告、创建临时环境，再在每一个高风险节点停下来等人确认。当这条路径跑通，云计算的使用方式才真正从「人操作资源」，走向「Agent 承担任务」。