这是 2026 年的第 33 篇文章（本文阅读时间：约 25 分钟）
前言
Qoder Cloud Agents 工程实践系列：如果 Agent 的边界是工具调用，那么 Cloud Use 的边界则是云原生执行。前者让 AI 辅助人工操作软件，后者让 Agent 成为云上的新型工作负载。Cloud Use 与普通 Tool Use 的核心差异不在于“能否调用 API"，而在于 Agent 是否能以受治理的身份、凭证、环境、生命周期和审计轨迹，真正融入云的生产体系。
凌晨 2 点，跨境商家新品爆单。在人工介入前，Agent 已自动创建临时沙盒，拉取库存与支付数据，排查异常订单，模拟物流方案，计算关税影响，生成客服话术并调整投放建议，仅将高风险订单移交人工确认。它未登录控制台或服务器，却实实在在地在使用云资源。
随之而来的挑战尖锐而具体：Agent 以何种身份访问系统？支付数据是否脱敏？API 调用凭证何在？资源规格调整由谁授权？任务失败后状态能否恢复？每一步操作是否可审计？让 Agent 调用一次云 API 并不难，难的是让它具备持续、跨系统、带权限边界且全程可追溯的执行能力。这正是 Cloud Use 需要解决的核心命题。
01 云迎来了第二类使用者
过去二十余年，云计算的交互模型主要围绕两类对象：人类操作者与确定性自动化程序。人类通过控制台管理资源、配置数据库、处理告警；CI/CD、Terraform、Kubernetes Controller 及各类脚本则按预设规则执行。尽管 CLI、SDK 和 IaC 降低了操作成本，但底层逻辑依然清晰：要么是人，要么是确定性程序。云平台的账号体系、权限模型及审计日志均基于此构建，每条操作记录皆可映射到具体的人或系统。
Agent 的出现打破了这一二元结构。它不再局限于回答问题或生成脚本，而是开始读取日志、分析账单、诊断 CI、检查数据任务、调用 OpenAPI 并提交代码变更。Agent 正从“懂云的助手”演变为“使用云的执行者”。
云计算过去主要围绕人类操作者和确定性自动化程序设计。Agent 带来的新变量，是一种会推理、会调用工具、会跨系统行动的机器执行体。
这一变化的影响深远。若使用者是人，工具旨在降低操作成本；若执行者是确定性程序，云平台管理的是服务账号与策略。Agent 介于两者之间：它拥有人类的目标理解力，兼具程序的执行速度与规模，无需图形界面，却亟需身份、权限、工具、数据、运行环境、状态管理、成本记录、失败恢复及完整的审计链路。
如图所示，人类和确定性程序是云已熟悉的使用者，其账号与审计体系历经二十年打磨。Agent 则是新变量：它既非单次鼠标点击，亦非固定路径脚本，而是能推理并串联跨系统行动的智能体。云平台若要接纳它，必须在现有治理层中开辟通路。现实中，许多仅具 Tool Use 能力却缺乏云原生治理的 Agent，往往在 Demo 阶段表现良好，一旦进入生产环境便因缺乏可管理的执行主体身份而受阻。
02 为什么 Agent 很难成为云上工作负载
当前 Agent 难以成为云上工作负载，并非模型能力不足，而是未被云平台真正“接纳”。Demo 中赋予一组 AK/SK、封装几个 OpenAPI 工具并编写 Prompt，虽能跑出结果，但生产环境随即暴露诸多隐患：凭证归属不明、权限过大、密钥泄露风险、日志缺失、误操作责任不清、任务持久性不足以及审计困难等。
仅具备 Tool Use 能力的 Agent 通常依赖人的影子运行：借用人的设备、账号、密钥及在线状态。这种模式适用于短任务或探索性分析，但无法支撑稳定的云上工作负载。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 颁发工牌，使其进入云上工作现场，确保每道门禁、每次取证、每个动作均有迹可循。
03 Cloud Use 的价值要从场景前后对比里看
概念需落地于场景方能体现价值。Cloud Use 与普通 Agent 的差异不在于能否查日志或调 API，而在于工作方式的本质的变化：任务是否脱离人的在线状态、Agent 能否自主进入现场取证、执行动作是否具备身份与审计边界。
1. 周期性任务：从「有人每天打开系统」到「任务自己醒来」
许多云上任务规则清晰但高度重复，如跨境商家爆单后的库存、支付、物流及客服数据分析。传统流程依赖人工定时登录各系统查询并整理报告。普通 Agent 虽能辅助写 SQL 或润色报告，但仍需人工发起任务、提供上下文及确认凭证，整条链路系于人身上。
Cloud Use 实现了任务的自主唤醒。Cloud Agent 可由 cron 或突发事件触发，利用任务级身份访问数据源，通过 Vault 使用受控凭证，经由 MCP 调用 BI、日志及计算能力，独立完成查询、异常识别与报告生成，并将结果推送至业务系统。人无需定时在线，仅需处理异常与决策。
周期性任务的变化，是“任务不再依赖某个人在线”，而非“报告写得更快”。
这改变了责任结构。实测数据显示，一次 BI 分析包含 111 次工具调用，持续约 21.5 分钟，全程零人工干预；一次 ETL 任务产生 116 个事件，运行 13 分钟由 cron 触发完成。这些数据表明 Agent 已能承担具有完整生命周期的云上任务。
2. 诊断任务：从「人喂材料」到「Agent 进入现场取证」
CI 失败、慢查询及线上告警是另一类典型场景。传统模式下，开发者需手动收集分散在各系统的日志、配置及依赖信息。普通 Agent 仅能分析人工提供的片段，无法主动追溯证据链。
Cloud Use 重塑了诊断流程。当 CI 失败事件触发，Agent 直接在云端被激活，主动利用云身份读取流水线日志、查询 MR、检查依赖变更及构建环境状态，必要时调用监控系统将证据串联，并将结论回写至 MR 评论或工单。此时 Agent 不仅是总结日志，更是在主动取证。
诊断任务的变化，是"Agent 能自己进入云上工作现场，收集上下文并形成证据链”，而非“模型更会解释错误”。
在 ELK 慢查询与 CI 失败诊断场景中，Agent 可在数分钟内给出端到端结论并将分析回写。核心价值在于 Agent 不再等待人工复制材料，而是围绕事件主动收集证据。
3. 执行任务：从「脚本自动化」到「受治理执行」
执行类任务最易被误解。技术上赋予 Agent 足够权限即可自动修复问题或调整配置，但风险亦藏于此。普通 Agent 虽补足了动态判断能力，但若缺乏身份、凭证及审计约束，自动化越强，事故半径越大。
Cloud Use 的目标并非无边界自动执行，而是实现“可托付”。低风险动作（如读日志、建沙盒、清资源）可自动执行；高风险动作（如删生产资源、改线上配置）必须进入人工确认环节。Agent 提供建议与证据，但不可越过边界。
执行任务的变化，不是“全自动替代人”，而是“低风险自动化，高风险可审批，全过程可追溯”。
综上，Agent 已从聊天助理转变为有身份、有边界、有生命周期的执行体。Cloud Use 依赖的是治理体系：身份可识别，凭证不可见，权限可收回，动作可审批，过程可审计，失败可恢复。
04 某咖啡品牌是如何把分析任务交给云上的 Agent
理论需经实战检验。以某连锁咖啡品牌的经营会为例，CEO 需快速获取店型坪效、品类增长曲线及新店选址建议。面对分散在四张表中的 320 行数据，传统流程需经历需求提报、排期、SQL 编写及报告整理，耗时数天至两周。
Cloud Use 的价值在于将此事托付为一段云上任务。Agent 作为带身份、凭证边界、运行时及验收标准的机器执行体，完成了从“经营问题”到“验收证明”的完整链路。
咖啡 BI 这个案例的价值，在于它把“经营问题 → 数据访问 → 查询执行 → 异常恢复 → 结果回传 → 验收证明”跑成了一条完整链路。
该链路跨越了六个关键工程门槛：
1. 凭证：先进 Vault，不进 Prompt
生产环境中，将 AK/SK 直接塞入 Prompt 存在极大安全风险。解决方案是将凭证存入 Vault，Agent 仅持有引用 ID（如 vault_credential_id）。运行时由平台侧完成凭证兑换与受控注入，确保 Agent 可使用云资源但无法获取明文密钥。
2. 路径：Skill 沉淀踩坑史，而不是重玩一遍
Agent 可能因过度推理而选择错误 API 路径。Skill 的价值在于沉淀组织过往的踩坑经验，明确哪些接口可用、语法陷阱及资源组冻结时的应对策略。实测中，Skill 帮助 Agent 避免了约 13 分钟的错误路径探索，复用了被验证过的执行路径。
3. 角色边界：任务合约，而不是「你是分析师」
进入云端执行前，需通过任务合约收窄 Agent 权限。例如规定必须通过 DataWorks 执行 ODPS SQL，输出必须包含数字结论与可追溯表格，遇到资源组不可用时先检查可用资源或按预案创建临时资源组。这并非 Prompt 技巧，而是一份小型任务合约，确保结论可追溯、异常处理不越权。
你是一名资深数据分析师。
你需要通过 DataWorks 执行 ODPS SQL 分析 MaxCompute 数据。
每个分析维度都必须输出：
1. 带数字的结论；
2. 查询结果表；
3. 可执行的业务建议。
不要输出无法追溯的数据判断。
遇到资源组不可用时，先检查可用资源组；
必要时按预案创建临时资源组并记录操作。4. 运行时：云上 Session，不是本地进程
实测任务运行 21 分 32 秒，产生 111 次工具调用与 312 个事件，全程零人工干预。这证明 Cloud Use 可承载长周期多步骤任务，且过程可追踪、可回放。用户发起任务后，Agent 在云端 Session 独立执行，不受本地浏览器关闭或网络断开影响。
5. 结果回传：监听正确事件
为确保结果稳定进入业务流，业务系统应订阅任务结束事件（如 session.thread_idled），而非过早拉取半成品。以下代码展示了如何通过 Webhook 签名验证与事件监听来可靠地获取报告：
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 需可信来源验证，任务完成由事件触发，报告拉取异步处理。
6. 验收：可执行的 Rubric
任务完成不能靠 Agent 自我声明，而需通过可执行的验收标准（Rubric）。BI 任务必须回答具体经营问题，且每个结论需有数字支撑并可回溯至 SQL 查询结果。
最终产出包括：快取店日均坪效约¥85+/㎡，是旗舰店的 2.2 倍；咖啡 GMV 占比 81.3%，茶饮环比增长 18.5%；城市扩张评分中杭州最高。这些可检查的数字让 BI Agent 从“会生成报告”变为“能回答经营问题”。
7. 边界，边界，还是边界！
面对资源组不可用等异常，Cloud Use 将其定义为已知失败模式：先在预授权边界内尝试自救（如创建临时资源组并记录），若超出边界则停止并请求人工确认。成熟的 Cloud Use 不在于从不失败，而在于失败后能在治理边界内恢复或干净地停下。
真正可托付的 Agent，不是自己宣布任务完成，而是它的完成状态可以被事件、日志、产物和验收标准共同证明。
咖啡 BI 案例表明：凭证进 Vault、路径靠 Skill、执行靠 Session、结果靠 Webhook、完成靠 Verification。这是 Cloud Use 从“演示”走向“生产”的关键。
05 Cloud Use 不是 API 包装，是一套云原生执行模型
Cloud Use 是 Agent 以可控、可审计、可恢复的方式，使用云上计算、数据、工具、身份和运行时完成任务的能力。其本质是将 Agent 从“调用工具的模型”转化为“可被云平台托管的执行体”。这需要四层递进能力：
- Identity Use：解决“谁在操作”。Agent 需拥有独立身份，每次动作均可追溯至任务发起者与权限来源。
- Credential Use：解决“凭证怎么用”。凭证参与调用但不进入 Prompt 或日志，通过 Vault、短期令牌及服务端代理实现“可用不可见”。
- Tool/API Use：解决“工具怎么被治理”。在 MCP 等协议基础上，叠加权限约束、调用审计、速率限制及风险确认机制。
- Runtime Use：解决“任务怎么活下去”。通过云端 Session、状态管理及事件流，支持长周期运行、失败重试及结果回传。
Cloud Use 的本质，不是让 Agent 多一个工具，而是让 Agent 获得身份、凭证、工具和运行时之后，成为可托管的云上执行体。
06 真正的革新：从「人操作资源」到「Agent 承担任务」
控制台、CLI、SDK 及 IaC 旨在让人更高效地操作资源。Agent 带来的革新在于让“任务”本身成为新的云抽象。人转向定义目标、边界与验收标准，Agent 则在云端负责环境创建、数据访问、工具调用及结果验证。
过去云的核心抽象是资源。Agent 时代，云还需要面向任务和机器执行体的新抽象。
Cloud Use 并未淘汰旧界面，而是将其纳入 Agent 的工具层。Agent 通过受控接口完成控制台背后的动作，调用等价云 API，生成并验证 Terraform 变更。新的界面将旧工具置于其执行层内，构建可验证的信任而非盲目信任。
企业愿意托付的是一个有身份、有边界、有日志、有恢复机制且能在关键节点暂停的执行体。
07 Cloud Use 的难点：让 Agent 失败得可控
生产化的关键在于设计失败路径。真实的云上任务必然遭遇接口不适用、权限不足或资源冻结等问题。Cloud Use 的目标是让失败可观察、可约束、可恢复。
Cloud Use 真正要解决的，不是让 Agent 永远成功，而是让 Agent 失败时可观察、可约束、可恢复；恢复不了时，能干净地停下来。
- 错误路径控制：通过 Skill 沉淀正确与错误路径，防止 Agent 在无效 API 上浪费时间。
- 基础设施异常处理：将资源组冻结等异常转化为受控自救路径，在预授权边界内尝试恢复，超出边界则停止。
- 结果回传可靠性：监听正确的空闲事件，配合 Webhook 签名验证与幂等处理，确保获取完整结果。
- 严格验收标准：将“完成”定义为可执行、可检查的标准，防止 Agent 生成看似合理但未解决实际问题的报告。
成熟的 Cloud Agent 不在于从不犯错，而在于失败时不会将系统带入更坏状态。
08 边界：Cloud Use 不适合从最高风险任务开始
任何新范式都需循序渐进。Cloud Use 应从低风险、高频、结果可验证的任务起步，逐步爬升至带确认的执行，最后才涉及高风险变更。
初期适合的任务包括周期性巡检、成本分析、CI 诊断、日志分析及临时环境创建等。这些任务读取多于写入，失败可重试，风险边界清晰。随后可扩展至带确认的执行动作，如 Agent 生成修复建议由人确认后触发，或生成 IaC 变更由人 Review 后合入。
Cloud Use 的成熟，不体现在 Agent 能不能越过人，而体现在它知道什么时候必须停下来等人。
真正的目标不是扩大模型权限，而是将权限、凭证和执行放回云平台可治理的框架内。
09 当 Agent 真正开始使用云
Cloud Use 解决了当云的使用者不再只有人时，云平台如何接纳、约束并托管机器执行体的问题。Agent 将成为云上的新型工作负载：有身份、有环境、有工具、有生命周期、有审计轨迹且有明确边界。
控制台、CLI 及 IaC 将从人直接使用的界面逐渐转变为 Agent 可调用的工具层。Cloud Use 改变了云的使用关系：Agent 不再是人的外挂，而是云平台可识别、授权、托管和审计的执行主体。
未来路径应始于高频、低风险、可验证的任务，如定时巡检、故障诊断及成本分析，并在高风险节点设置人工确认。当这条路径跑通，云计算的使用方式将真正从“人操作资源”走向"Agent 承担任务”。
