本页译自英文文档。命令、标识符和示例保持原样。运行时 7.24.4 · SDK 2.6.7。英文原文

云操作模式

状态：生效范围：当前状态最近审阅：2026-09-04 负责人：ax-code 运行时

云操作模式是一套现成的运维姿态，用于管理基础设施——云提供商（AWS、GCP、Cloudflare、OVHcloud、DigitalOcean、RunPod）和网络设备（VyOS、Juniper Junos）。在这类环境里，一次失误会影响在线系统，而且 git 回滚无法恢复状态。它以内置的 cloudops agent 交付：一份系统提示词加上一套权限姿态，一次选择即可启用，不必手写规则。

该模式提供什么

先只读的 agent。 cloudops agent 在每项任务开始时先做清单盘点与空跑，其提示词禁止在计划、差异和回滚配方就绪之前进行变更。
运行前询问的 shell。 bash 设为 ask，因此每条 shell 命令都需确认。云与网络的变更类动词（aws/gcloud/az/doctl 删除族、kubectl delete/apply --prune、没有计划文件的 terraform apply、未经 commit-confirm 的 ssh 远程提交、针对控制平面 API 的 curl 变更）被归类为 bash_destructive，并带有一道不可绕过的独立交互门。
一等运维工具。 ops_plan、ops_diff、ops_verify 和 ops_journal 预先允许；ops_approve 和 ops_apply 仍走各自的交互路径（见下文）。

工作流：计划 → 差异 → 批准 → 应用 → 验证 → 日志

ops_plan — 打开一份 OperationPlan：目标（提供商/账户/区域或设备）、意图、精确的应用命令与命令上下文，以及带有效果、可逆性（reversible | hard | irreversible）和爆炸半径（low | med | high）的步骤。产出规范计划哈希。
ops_diff — 生成并审阅可机器检查的产物（terraform plan -out、show | compare、CLI 空跑输出）并附上。没有差异，就没有批准。
ops_approve — 由人批准钉住哈希的计划。此门仅限交互：通配规则和自主模式都不能预先批准，也不会提供持久的“始终允许”授权。
ops_apply — 用批准令牌执行已批准计划中的变更。这是唯一被认可的变更路径；令牌在任何内容运行之前就被兑现。
ops_verify — 运行计划中的声明式只读断言，并记录通过或失败的证据。
ops_journal — 按项目、计划或状态查询仅追加、限定于项目的操作日志。

启用该模式

在 TUI 中，从 agent 选择器选取 云操作（或用 @ 提及 cloudops 以限定单次任务）。若要把它设为项目默认，添加到 ax-code.json：

{
  "default_agent": "cloudops",
  "isolation": {
    "mode": "workspace-write",
    "network": true
  }
}

workspace-write 把文件变更限制在工作区内；network: true 保持 webfetch、websearch 和提供商 CLI 可达（沙盒模式中网络默认关闭——参见沙盒模式）。二者都是会话隔离设置，独立于 agent，因此在这里配置，而不是写进 agent 预设。

你可以在 agent.cloudops.permission 下按项目收紧或扩展姿态，例如拒绝特定工具。随仓库提交的配置只能追加拒绝规则；把 ask 放宽为 allow 必须来自你信任的用户配置或托管配置，绝不能来自仓库。要彻底移除该 agent，设置 "agent": { "cloudops": { "disable": true } }。

一个完整示例

对 VyOS 路由器应用防火墙变更：

你提出：“允许来自 10.0.0.0/8 的 tcp/8443 访问边缘防火墙”。
agent 加载 vyos-firewall 技能，通过 SSH 捕获当前配置（show configuration commands 保存到带日期的文件），并用 ops_plan 打开计划：一步，效果为 add firewall rule，可逆性为 reversible（删除规则即可恢复状态），爆炸半径为 med。
它在配置模式中暂存变更，并用 ops_diff 附上设备差异。
ops_approve 向你展示计划哈希和精确的暂存变更；你批准后，签发一个 10 分钟令牌。
ops_apply 兑现令牌并运行 commit-confirm 序列；自动回滚计时器在验证完成前保持武装。
ops_verify 检查可达性，以及规则是否匹配预期流量；批准与结果都记入日志，因此稍后的 ops_journal 查询可以重建整次变更。

如果应用在第 5 步失败，令牌即已消耗——任何重试之前都要再次执行第 4 步。

批准令牌语义

单次使用 — 在 ops_apply 开始时原子兑现；已消耗、未知或过期的令牌会失败，且什么都不执行。
受 TTL 约束 — 默认 10 分钟，最长 60。过期在消费时惰性检查；没有后台清扫器。
绑定计划 — 令牌针对计划的规范 sha256 哈希签发。该哈希包含精确的应用命令、可选的快照命令和工作目录。参数漂移，以及针对另一份计划出示的令牌，会在消费前被拒绝，从而防止重放、跨计划混淆和命令替换。
只揭示一次 — 原始令牌恰好在 ops_approve 结果中出现一次，且永不持久化（只存储其 sha256）。
不退还 — 失败或超时的应用不会退回令牌。重试需要通过 ops_approve 重新批准。

安全模型

bash_destructive 仍是临时变更的门。 运维工作流覆盖有计划的变更；一次性破坏性命令仍会命中破坏性分类器及其交互门，任何权限规则都不能自动批准它们。
ops_approve 仅限交互，如同 isolation_escalation 和 bash_destructive：即使在通配允许规则集下，以及在无头自主模式中，它也始终提示。
从 agent 视角看，日志仅追加，且限定于项目；它比会话更长久，删除会话时不会级联删除。
技能包携带提供商操作手册。 cloud-ops-aws、cloud-ops-gcp、cloud-ops-cloudflare、cloud-ops-digitalocean、cloud-ops-runpod、vyos-firewall 和 junos-firewall 存放先只读检查清单、变更前先计划的步骤和回滚模式；agent 在操作某个界面之前加载匹配的包。OVHcloud 和其他提供商通过已配置的 MCP 服务器及其文档覆盖，而不是临时拼凑的 CLI 链。
凭据永不进入记录。 持久化 bash 输入中的内联凭据赋值会在到达事件日志之前被脱敏。

严格模式

默认情况下，被归类为破坏性的 bash 命令（bash_destructive 族：云与网络变更动词、rm -rf、git push --force，以及分类器列表的其余部分）会收到不可绕过的交互询问——用户可以批准这一次性命令，然后它才会运行。严格模式去掉这个选项。

启用严格模式后，被归类为破坏性的 bash 命令会直接拒绝，发生在任何询问之前。拒绝消息列出被分类的命令及其原因，并把模型导向被认可的工作流：ops_plan → ops_diff → ops_approve（签发一次性批准令牌）→ ops_apply。临时的破坏性 shell 变更不再可能；每一次变更都必须经过计划、差异、批准，并通过有日志支撑的路径应用。

在受信任配置中启用（你的用户配置目录、托管配置，或用户已明确信任的项目配置中的 ax-code.json）：

{
  "ops": {
    "strict": true
  }
}

说明：

与询问的关系： 严格模式_替换_ bash_destructive 询问，改为硬拒绝。关闭该标志时（默认），行为与上文完全一致——交互门仍然存在。
范围： 该标志是全局配置，不是按 agent。它适用于会话中的每一次 bash 调用，包括子 agent。cloudops agent 不能自行启用它；agent 携带的是权限和提示词，不是配置。
信任范围： 不受信任、随仓库提交的项目配置不能启用严格模式；按机器选择加入（AX_CODE_TRUST_PROJECT_CONFIG=1），或在受信任的用户配置与托管配置中设置。
ops_apply 不受影响： 被认可的变更路径在工具内部有自己的计划绑定令牌门，从不查阅此标志。

事实来源

packages/ax-code/src/agent/agent.ts — cloudops agent 定义与权限合并
packages/ax-code/src/agent/prompt/cloudops.txt — agent 系统提示词
packages/ax-code/src/tool/ops_*.ts — 六个运维工具及其说明
packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY（ops_approve、bash_destructive、isolation_escalation）
沙盒模式 — 隔离模式、网络控制与优先级