本頁譯自英文文件。指令、識別名稱與範例保持原樣。執行環境 7.24.4 · SDK 2.6.7。英文原文

雲端維運模式

狀態：有效範圍：現行狀態上次審閱：2026-09-04 負責人：ax-code runtime

雲端維運模式是一套現成的態勢，用來管理基礎設施——雲端供應商（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 選擇器挑選 Cloud Ops（或對範圍限定的任務提及 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 之下依專案收緊或擴充這個態勢，例如拒絕特定工具。提交到儲存庫的設定只能新增 deny 規則；把 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）
沙盒模式 — 隔離模式、網路控制與優先順序