Agent Infra - Cloud Agents V7
Cloud Use（用云）
- Cloud Use 让云上运行的 Agent 以受治理的身份操作你的阿里云资源，在云上闭环完成任务
- 接入分两步：控制台用 OAuth 授权阿里云 OpenAPI MCP + 按需从技能中心导入阿里云官方 Skill
- Agent 以平台注入的机器身份通过 MCP 调用阿里云 OpenAPI - 云端长期运行、按事件实时触发、云操作全程服务端留痕
Cloud Use = V4/V5/V6 三篇机制的官方样板间：OAuth 凭证进（Vault）、事件驱（Webhooks / Schedules）、双层账单（Credits + 阿里云）——文末机制剖析逐一对应
心智模型
一句话：OAuth 授权一次，Agent 7×24 在云上替你管云 - 读永远 allow、变更必须 ask、破坏永远 deny。
全景：接入与运行
flowchart TB
subgraph SETUP["🔌 接入（控制台，一次性）"]
direction TB
A["① 阿里云 RAM<br/>安装官方应用<br/>OpenAPI MCP Server"] --> B["② Cloud Agents 控制台<br/>Vault 建 MCP OAuth 凭证<br/>（置顶「阿里云 Cloud Use」）"]
B -->|"③ OAuth 跳转授权"| B2["凭证状态：已授权"]
C["④ 技能中心导入<br/>Cloud Use 分类 Skill"]
end
subgraph RUN["🏃 运行（每个会话）"]
direction TB
D["⑤ Agent 绑定 MCP<br/>+ 选用 Skill"] --> E["⑥ 创建会话，关联 Vault"]
E -->|"自动注入 OAuth Token"| F["Agent 以授权的阿里云<br/>机器身份调 OpenAPI"]
end
B2 -.-> D
C -.-> D
classDef setup fill:#e8f0fe,stroke:#4285f4
classDef run fill:#e6f4ea,stroke:#34a853
class A,B,B2,C setup
class D,E,F run
接入五步（控制台 OAuth）
| 步骤 | 操作 | 要点 |
|---|---|---|
| ① 获取专属 MCP URL | 阿里云 OpenAPI 门户 MCP 接入页：中国站 api.aliyun.com/mcp，国际站 api.alibabacloud.com/mcp |
选 Streamable HTTP Endpoint，按账号站点选域名 |
| ② RAM 安装官方应用 | RAM 控制台 →「第三方应用」→「安装官方应用」→ OpenAPI MCP Server | OAuth 前置：未安装时授权页直接报「应用未被授权安装」 |
| ③ 创建 Vault 凭证 | Cloud Agents 控制台 →「密钥」→「添加」：类型 MCP OAuth，服务器选置顶 「阿里云 Cloud Use」（或自定义 URL 填 ① 的地址） | 保存后完成一次 OAuth 跳转，凭证状态变「已授权」 |
| ④ Agent 绑定 MCP | Agent 的 MCP Servers 配置中勾选该凭证 | 推荐从「密钥」勾选，无需重复填 URL |
| ⑤ 会话关联 Vault | 发起会话时选择该 Agent 并关联 Vault | 平台自动把 OAuth Token 注入 MCP 调用链路 |
前置：拥有阿里云账号 + 在 RAM 中安装第三方应用的权限。
这正是 V4「Vaults 认证」详讲的
mcp_oauth凭证类型 + CAS OAuth 流程——下拉置顶的「阿里云 Cloud Use」就是平台预注册的 MCP 服务器条目，OAuth 全程与 V4 时序图一致（token 不经过用户之手）。
导入用云 Skill
控制台「技能 → 创建 → 从技能中心导入」：
- 选 「Cloud Use」分类（置顶）查看平台精选的用云 Skill
- 可搜索阿里云官方 Skill（RAM 权限诊断、DataWorks 数据开发、Quick BI 智能问数等）
- 导入后进入「技能」列表，可在 Agent 配置中立即选用
四大典型场景
| 场景 | 闭环产出 | 权限分级（allow / ask / deny） | 推荐 Skill | 触发 |
|---|---|---|---|---|
| 应急处理 | 告警触发 → 定位根因 → 受控止血 → 修复 PR | 日志/监控只读 allow；重启/扩容/切流 ask；删除/释放 deny |
RAM 权限诊断、云监控 2.0、ES 集群诊断修复 | 告警 Webhook 实时 |
| 数据分析 | 自然语言提问 → 探 schema → 生成并执行 SQL → 出图 → 归因解读 | 取数/跑 SQL（只读）allow；写操作 deny |
Quick BI 智能小 Q、DMS 智能问数（60+ 数据源） | 实时问答 / 08:00 大盘 |
| 数据处理 | 读源 → 清洗/转换/聚合 → 写入目标数据集 → 校验行数与 schema（幂等可复跑） | 读源 allow；写回结果表/OSS ask；删除源数据 deny |
DataWorks、ClickHouse 迁移、MaxCompute 元数据 | 每日 02:00 跑批（cron） |
| 成本治理 FinOps | 拉账单与利用率 → Top 成本项 +「预计月省 + 一行修复动作」可执行清单 | 账单/利用率只读 allow；停闲置/降配/生命周期 ask |
EMR 生命周期（成本标签）、MaxCompute 费用追踪、DAS | 每日 09:00（cron） |
权限设计的共同模式：读永远
allow、变更必须ask、破坏永远deny—— 把”最小权限”做成了产品化的三级开关。
触发与执行链路
flowchart LR
subgraph SRC["⚡ 触发源"]
W["告警 Webhook<br/>（实时）"]
CR["Schedule cron<br/>（02:00 跑批 · 09:00 成本）"]
Q["实时问答"]
end
SRC --> SESS["Session（云端 7×24）"]
SESS --> AG["Agent + 用云 Skill"]
V[("Vault<br/>MCP OAuth 凭证")] -->|"注入 OAuth Token"| AG
AG -->|"MCP 调用"| ALI["阿里云 OpenAPI"]
ALI --> G{"权限门<br/>allow / ask / deny"}
G -->|"读 allow"| R1["日志 · 监控 · 账单 · 取数"]
G -->|"变更 ask"| R2["重启 · 扩容 · 写回 · 降配<br/>（需确认）"]
G -->|"破坏 deny"| R3["删除 · 释放<br/>（永远禁止）"]
R1 --> OUT["产出 + 服务端留痕"]
R2 --> OUT
classDef src fill:#fef7e0,stroke:#f9ab00
classDef gate fill:#fce8e6,stroke:#ea4335
classDef out fill:#e6f4ea,stroke:#34a853
class W,CR,Q src
class G gate
class OUT,R1,R2 out
机制剖析：V4/V5/V6 的官方样板间
| Cloud Use 机制 | 对应本系列 | 闭环了什么 |
|---|---|---|
| Vault 建 MCP OAuth 凭证 | V4「Vaults 认证」的 mcp_oauth + CAS 时序 |
那套 OAuth 流程的官方首用场景 |
| 会话关联 Vault → 自动注入 Token | V4「token 全程不经过用户之手」 | 机器身份的具体形态 |
| 告警 Webhook 实时触发 | V5「Webhooks」 | 事件驱动入口 |
| 每日 02:00 / 09:00 cron | V5「Schedule」 | 定时驱动入口 |
| Agent 云端 7×24 长驻 | V6「计费」：idle 免费、只罚 running | 长驻的经济性基础 |
| 阿里云资源消费计入被授权的阿里云账号 | V6「计费」：Credits 只覆盖模型+沙箱 | 双层账单：Qoder 收 Credits（脑），阿里云收资源费（云）——BYO Cloud Account |
| 授权集中在 Vault，多处复用 | V4：Vault 与 Session 解耦 | 配一次，处处挂 |
| allow / ask / deny 三级权限 | - | 本篇新概念：最小权限的产品化 |
常见问题
Q：这和「本地 Coding Agent + 阿里云 MCP」有什么区别？
A：Agent 运行在云端，7×24 长期运行、按事件实时触发，不依赖你的机器在线；用云通过授权的机器身份进行，凭证由平台托管注入、不落到本地；每一步云操作都在服务端留痕、可审计。
Q：授权时提示「应用未被授权安装」？
A：回到第②步，确认已在阿里云 RAM「第三方应用」中安装 OpenAPI MCP Server 官方应用，再重新发起 OAuth。
Q：使用阿里云产生的费用账单在哪里？
A：双层账单 - 用云消费计入完成 OAuth 授权的那个阿里云账号（账单在其费用中心）；Agent/模型消耗走 Qoder Credits。
Q：Agent 多个会话能复用同一个授权吗？
A：可以。授权与连接集中在「密钥（Vault）」，Agent 只做挂载引用 - 配一次，多处可挂。
小结
| 问题 | 答案 |
|---|---|
| 定位 | 云端 Agent 以受治理的机器身份操作阿里云，云上闭环 |
| 接入两件事 | ① RAM 装官方应用 + Vault 建 MCP OAuth（一次）② 技能中心导入 Skill |
| 运行三特征 | 云端长驻 7×24 · 事件/定时触发 · 服务端留痕 |
| 权限模式 | 读 allow / 变更 ask / 破坏 deny |
| 四大场景 | 应急处理（Webhook）、数据分析（问答）、数据处理（cron）、成本治理（cron） |
| 账单结构 | Qoder Credits（模型+沙箱）+ 阿里云账号（资源消费） |
一图流记忆：OAuth 进、事件驱、身份治理、双层账单 - Cloud Use 是前六篇机制拼图的官方样板间。
附：SSE 初始连接行为调整公告（2026-08-24 生效）
| 项 | 值 |
|---|---|
| 公告日期 | 2026-08-10 |
| 生效时间 | 2026-08-24 00:00（UTC+8） |
| 影响范围 | Cloud Agents（SSE 接口） |
本篇收录时距生效还有 2 天 - 依赖”新连接回放历史”的客户端请抓紧适配。
调整内容：一句话
未携带 Last-Event-ID 的新建 SSE 连接：从建连时刻的事件流末尾开始，只推送后续新增事件；不再回放历史事件（包括最新一条历史）。携带 Last-Event-ID 的断线续传不变；历史事件走 List Events 分页查询。
接口影响范围
| 接口 / 能力 | 是否调整 | 说明 |
|---|---|---|
GET /sessions/{id}/events/stream |
✅ 是 | 无 Last-Event-ID 时，从建连时事件流末尾开始，仅下发新增 |
GET /sessions/{id}/threads/{thread_id}/stream |
✅ 是 | 同上，仅限该 Thread 的新增事件 |
两个 List Events 接口以 Accept: text/event-stream 作为 SSE 使用 |
✅ 是 | 行为与对应 Stream 接口一致 |
Last-Event-ID 断线续传 |
❌ 否 | 携带有效游标则从该事件之后下发，规则不变 |
| List Events 的 JSON 分页查询 | ❌ 否 | 仍可分页查询已保存的公开事件 |
POST /sessions/{id}/events |
❌ 否 | 请求与响应契约不变 |
行为对比（时序图）
以某 Session 为例：建连前已有 4 条事件，建连后新产生 4 条（事件 ID 已缩短）：
sequenceDiagram
autonumber
participant C as 客户端
participant S as SSE 服务端
participant E as 事件流
Note over E: 建连前已有 4 条<br/>（status_running · user.message · agent.message · status_idle）
rect rgb(252, 232, 230)
Note over C,S: 调整前（2026-08-24 前）
C->>S: GET /events/stream（无 Last-Event-ID）
S-->>C: 回放 4 条历史 + 4 条新增 = 共 8 条
Note over C: 客户端需自行解析、去重，<br/>难以区分回放与实时
end
rect rgb(230, 244, 234)
Note over C,S: 调整后（2026-08-24 起）
C->>S: GET /events/stream（无 Last-Event-ID）
S-->>C: 仅推建连后新增 4 条<br/>不补发任何历史（含最新一条）
Note over C: 历史请走 List Events 分页
end
rect rgb(232, 240, 254)
Note over C,S: 断线续传（不变）
C->>S: GET /events/stream<br/>Last-Event-ID: evt_00l83045n…
S-->>C: 从该事件之后继续下发
end
细节坑：先发消息、后建连 ≠ 能收到之前那条 - 服务端不补发任何历史，包括最新一条。要完整接收某次操作的实时事件，必须先建连、再触发。
三个职责的边界（调整后的设计）
flowchart LR
NEED["客户端需要…"] --> H["📜 历史事件<br/>List Events 分页查询"]
NEED --> RT["⚡ 实时事件<br/>SSE 新连接（从末尾开始）"]
NEED --> RS["🔁 断线补收<br/>Last-Event-ID 游标续传"]
RT -->|"处理成功后<br/>记录最新事件 ID"| RS
classDef need fill:#e8f0fe,stroke:#4285f4
classDef way fill:#e6f4ea,stroke:#34a853
class NEED need
class H,RT,RS way
| 洞察 | 解读 |
|---|---|
| 老行为 = 每次建连全量回放 | 事件多时重复传输大量已处理数据，客户端去重负担重 - 本质是隐式 at-least-once |
| 新行为 = 显式游标语义 | 实时（SSE）/ 历史（List）/ 断点（Last-Event-ID）三类场景职责边界清晰 |
| 与 V5「Webhooks」互补 | Webhook 是 at-least-once + 指数退避重试 → 按 event id 幂等；SSE 是游标续传 → 同样按 id 幂等 |
| 共同底座 | 事件 ID 是唯一真相源，消费端必须幂等 |
| 存量连接不受影响 | 新行为仅适用于生效时间后新建或重建的连接 |
适配指引
以下三类客户端需在生效前完成适配：
- 通过新建 SSE 连接获取历史事件
- 先发送消息/触发执行，再建连，依赖历史回放补收事件
- 断线后未携带
Last-Event-ID直接重连，依赖回放补收断线期间事件
推荐接入方式（四步）：
- 历史：List Events 分页获取
- 实时：SSE 接收；处理成功后记录最新事件 ID
- 断线：将该 ID 置于
Last-Event-ID重连，并按事件 ID 做幂等处理 - 顺序：要完整接收某次操作的实时事件，先确认连接已建立，再触发操作
仅用 SSE 接收实时事件、不依赖历史回放的客户端无需调整。
小结
| 问题 | 答案 |
|---|---|
| 生效时间 | 2026-08-24 00:00（UTC+8），仅影响此后新建/重建的连接 |
| 核心变化 | 无 Last-Event-ID 的新连接不回放历史，从建连时刻的末尾开始 |
| 不变 | Last-Event-ID 续传、List Events 分页、事件格式、POST events 契约 |
| 三职责边界 | 实时走 SSE · 历史走 List · 断点走游标 |
| 客户端铁律 | 事件 ID 幂等 + 先建连再触发 |
一图流记忆：SSE 只管实时，历史找 List，断点找游标 - 全量回放的”老好人”时代结束了。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-08-21
Agent Infra - Cloud Agents V6
文件上传与挂载 上传文件为 Agent 提供上下文，并下载 Agent 产出的文件 文件 API 让你向 Session 提供文件上下文 - 代码仓库、配置文件、参考文档等 Agent 可以读取这些文件来理解任务背景 Files / Resources 属于 Managed Mode 资源（base URL /api/v1/cloud），系列分界线见 V5 全景：一张图看懂 flowchart TB subgraph CTRL["🎛️ 控制面（记账）"] API["Files API"] OSS[("对象存储<br/>file 正文")] DB[("元数据库<br/>scope · 引用计数")] SPEC["Session 资源表<br/>sesr_: file_id → mount_path"] W[("工作队...
2026-08-21
Agent Infra - Cloud Agents V5
Schedule 在 Forward Session 中使用自然语言创建、查询和删除 Schedule 除了调用 Schedule API，终端用户也可以在 Web 或 IM Channel 会话中描述任务内容和执行时间，由 Agent 创建 Schedule 创建后，任务会按约定时间自动运行，无需保持当前会话在线 使用前提当前会话使用的 Template 必须启用对应的 Schedule 托管工具： 能力 托管工具 创建 Schedule create_forward_schedule 查询 Schedule list_forward_schedules 删除 Schedule delete_forward_schedule Template 默认不启用这些工具。managed_tool_config 是 Template 请求体的顶层字段，可通过以下接口配置： 场景 接口 创建 Template 时启用 POST /api/v1/forward/templates 为已有 Template 启用或调整 POST /api/v1/forward/templ...
2026-08-20
Agent Infra - Cloud Agents V3
启动 Session 创建、运行、查看和归档 Cloud Agent Sessions Session 是 Agent 的运行工作区 它把 Agent 快照、Environment、可选资源和可选 Vault 凭证绑定在一起 新 Session 初始为 idle，发送事件后开始执行 Session 状态生命周期Session 是一个状态机。Session 资源上的 status 字段取以下值之一： 状态 说明 可流转到 idle Session 空闲，可以发送消息 running、rescheduling、terminated running Agent 正在处理 turn idle、rescheduling、terminated rescheduling 底层运行时正在重新调度，期间 Session 不可用，恢复后回到 idle idle、terminated terminated Session 已终止（终态） — stateDiagram-v2 [*] --> idle: 创建 Session idle --> ru...
2026-08-20
Agent Infra - Cloud Agents V4
使用 Vaults 认证 安全地存储凭据并注入到 Agent Session Agent 经常需要访问第三方服务 - GitHub、Jira、数据库、自建 MCP 服务器等 Vaults 提供安全的凭证托管，让你把 Token 交给我们保管，Session 运行时按需注入，无需硬编码在代码里 核心概念 概念 说明 Vault 凭证容器，可包含多个 Credential Credential 单条凭证记录，绑定到具体 MCP 服务器 URL auth.type 凭证鉴权类型：static_bearer 或 mcp_oauth vault_ids Session 创建时引用的 Vault ID 列表 安全性 access_token永远不会在 API 响应中返回 token、refresh_token、client_secret 等其他密文也永远不会返回 凭证在服务端加密存储 仅关联的 Session 可在运行时访问凭证内容 完整流程整体流程图： flowchart TB subgraph S1["① 配置阶段：准备 Vault"] ...
2026-08-18
Agent Infra - Cloud Agents V1
概述 Qoder Cloud Agents 是一个全托管的 AI Agent 运行平台 通过 API 定义 Agent、启动 Session，即可在云端运行复杂任务并实时接收结果 为软件装上不断进化的大脑 通过 API 将持续进化的 Agent 能力嵌入你的应用 一次接入 - 智能能力随平台升级自动成长，无需修改任何代码 特性 一次调用即生产，长程执行，全程可观测 10000+ - 秒级并发实例弹性调度，按需扩缩 26 小时 - 单 Session 最长持续运行时长 1 天 - 从零到生产级 Agent 的交付时间 特点 一次调用，端到端交付 Agent 自主完成理解、规划、工具调用、代码生成、测试验证的完整链路，直接交付可用结果 长程执行，断点恢复 Session 基于事件流持久化，不绑定单一进程 支持数小时乃至数天的长时运行任务：批量审查、跨仓库重构、多轮迭代修复 中断自动恢复，进度永不丢失 安全可信，全程可观测 每个 Agent 运行在独立 Sandbox 中，租户间零数据渗透 所有行为通过 SSE 实时可观测 每一步思考、每一次工具调用、每一个输出，精确可追溯可审计 接入...
2026-08-22
Agent Infra - Cloud Agents V8
API 全景：从端点反推业务布局 本篇素材是官方 API 文档全量 238 篇（213 个端点 + 25 篇 Schema/概念页）——不再按指南页逐篇读，而是把端点当作”业务布局的化石记录”来反推 两个数字定全局：Managed Mode（/api/v1/cloud）105 个端点，Forward Mode（/api/v1/forward）114 个——交付层端点数已反超原语层，平台重心在”让别人把 Agent 嵌进自己的产品“ 方法分布 GET 103 / POST 93 / DELETE 22 / PUT 2（均已弃用），全 API 无 PATCH——更新一律 POST /{id}，文档明说为对齐 Anthropic CMA 规范 一句话：V1–V7 是”用户指南视角“（概念 → 功能），本篇补上”API 视角”（资源 → 端点）——四块拼图 V1–V7 完全没讲：Deployments（定时运行）、Forward Mode 深层、Work API（BYOC 工人协议）、事件溯源架构观。 心智模型 一句话：API 是业务的骨架—...
