7.7
深览指数
科技Bestblogs·阿里技术··AI 生成
Cloud Use：当 Agent 开始真正使用云
本文提出一个新概念「Cloud Use」，区别于目前流行的 Tool Use，指出 Agent 要成为云上可信、可托管的工作负载，必须从「工具调用者」进化为「受治理的执行体」。文章从身份、凭证、工具到运行时四层能力，构建了一个完整的执行框架，并剖析了任务失败可控、生产路径演进等工程实践。作者来自阿里技术，内容从架构设计到落地步骤均有覆盖，适合云原生架构师、AI 平台开发者及对 Agent 工程化感兴趣的读者阅读。原文 ↗
核心观点
- ▍Cloud Use 的核心是让 Agent 成为受治理的云上执行体，区别于仅解决「模型如何调用工具」的 Tool Use，它关注的是「云如何接纳 Agent 成为受治理的使用主体」。
- ▍Agent 要成为真实工作负载，必须具备身份识别、受控凭证、治理工具调用和云端运行时四层能力（Identity / Credential / Tool-API / Runtime Use），缺一不可。
- 01凭证进入 Vault 后以引用形式使用，Agent 不可直接读取；Skill 沉淀已验证的执行路径，而非任意生成的 API 调用；任务合约明确工具边界、输出格式和异常处理。
- 02云端 Session 使任务脱离人在线状态，具备事件触发、线程管理等运行时特征；结果回传需要事件触发和签名验证，确保业务系统获得完整可靠产出。
- 03文章将 Cloud Use 场景分为三类：周期性任务（如每日巡检）、诊断任务（如成本异常分析）、执行任务（如 CI 失败诊断），并分析了各自的治理边界。
- 04失败可控的关键在于：错误路径需要沉淀在 Skill 中；基础设施异常应在预授权边界内自救或停止；结果回传须在线程 idle 后拉取验证；验收标准必须可执行可检查。
- 05建议从低风险高频任务起步（如周期性巡检、成本异常分析），待稳定后再逐步引入带人工确认的执行动作，实现渐进式的生产信任建立。
- 06文章以具体案例说明：一个云网络诊断 Agent 的失败路径包括尝试拉取错误的 VPC 拓扑（看似合理但 API 不存在），需要在 Skill 中明确定义正确和错误的 API 集合。
反方 / 局限
- — 文章自行指出了局限性：对于高风险场景（如直接影响生产环境的变更），人工确认仍是必要的安全阀，Agent 不能完全自主执行。
- — 作者暗示但未展开的盲点：Agent 推理质量的不稳定性（幻觉）是影响 Cloud Use 可靠性的黑箱，文章主要从控制面和治理面着手，而对模型本身的可靠性依赖未有深入讨论。
4 分钟 · 4 卡片 · 11 资料
读原文 →