Dapatkan AX Code · GratisDokumentasi

Halaman ini diterjemahkan dari dokumentasi bahasa Inggris. Perintah, pengenal, dan contoh tidak diubah. Runtime 7.24.4 · SDK 2.6.7. Sumber bahasa Inggris

Mode operasi cloud

Status: Aktif Cakupan: keadaan saat ini Terakhir ditinjau: 2026-09-04 Pemilik: ax-code runtime

Mode operasi cloud adalah postur siap pakai untuk mengelola infrastruktur — penyedia cloud (AWS, GCP, Cloudflare, OVHcloud, DigitalOcean, RunPod) dan perangkat jaringan (VyOS, Juniper Junos) — di mana kesalahan memengaruhi sistem yang hidup dan rollback git tidak dapat memulihkan keadaan. Ia dikirim sebagai agen cloudops bawaan: prompt sistem plus postur izin yang Anda aktifkan dengan satu pilihan, bukan menulis aturan sendiri.

Apa yang diberikan mode ini

  • Agen yang mengutamakan hanya-baca. Agen cloudops memulai setiap tugas dengan inventaris dan dry-run, dan promptnya melarang mutasi sebelum ada rencana, diff, dan resep rollback.
  • Shell tanya-sebelum-jalan. bash diatur ke ask, jadi setiap perintah shell dikonfirmasi. Kata kerja mutasi cloud atau jaringan (keluarga hapus aws/gcloud/az/doctl, kubectl delete/apply --prune, terraform apply tanpa berkas rencana, komit jarak jauh ssh tanpa konfirmasi komit, mutasi curl terhadap API bidang kendali) diklasifikasikan bash_destructive dan membawa gerbang interaktif terpisah yang tidak dapat dilewati.
  • Alat operasi kelas satu. ops_plan, ops_diff, ops_verify, dan ops_journal sudah diizinkan terlebih dahulu; ops_approve dan ops_apply tetap pada jalur interaktif mereka (di bawah).

Alur kerja: rencana → diff → setujui → terapkan → verifikasi → jurnal

  1. ops_plan — buka OperationPlan: target (penyedia/akun/wilayah atau perangkat), maksud, perintah terapkan yang persis dan konteks perintah, serta langkah dengan efek, reversibilitas (reversible | hard | irreversible), dan radius dampak (low | med | high). Menghasilkan hash rencana kanonik.
  2. ops_diff — hasilkan dan tinjau artefak yang dapat diperiksa mesin (terraform plan -out, show | compare, keluaran dry-run CLI) lalu lampirkan. Tanpa diff, tanpa persetujuan.
  3. ops_approve — manusia menyetujui rencana yang hash-nya disematkan. Gerbang ini hanya interaktif: tidak ada aturan wildcard dan tidak ada mode otonom yang dapat menyetujuinya lebih dulu, dan tidak ada pemberian “selalu izinkan” yang tahan lama.
  4. ops_apply — eksekusi mutasi rencana yang disetujui dengan token persetujuan. Ini satu-satunya jalur mutasi yang sah; token ditebus sebelum apa pun berjalan.
  5. ops_verify — jalankan asersi hanya-baca deklaratif rencana dan catat bukti lulus atau gagal.
  6. ops_journal — kueri jurnal operasi yang hanya-tambah dan bersakupan proyek menurut proyek, rencana, atau status.

Mengaktifkan mode

Di TUI, pilih Cloud Ops dari pemilih agen (atau sebut cloudops untuk tugas yang dibatasi). Untuk menjadikannya bawaan proyek, tambahkan ke ax-code.json:

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

workspace-write membatasi perubahan berkas pada workspace; network: true menjaga webfetch, websearch, dan CLI penyedia tetap terjangkau (jaringan selain itu mati pada mode sandbox — lihat Mode Sandbox). Keduanya pengaturan isolasi sesi, independen dari agen, jadi dikonfigurasi di sini, bukan di dalam preset agen.

Anda dapat memperketat atau memperluas postur per proyek di bawah agent.cloudops.permission, misalnya menolak alat tertentu. Konfigurasi yang dikomit repositori hanya dapat menambah aturan tolak; melonggarkan ask menjadi allow harus berasal dari konfigurasi pengguna atau terkelola yang Anda percayai, bukan dari repositori. Untuk menghapus agen sepenuhnya, atur "agent": { "cloudops": { "disable": true } }.

Contoh yang dikerjakan

Menerapkan perubahan firewall pada router VyOS:

  1. Anda meminta: “izinkan tcp/8443 dari 10.0.0.0/8 pada firewall tepi”.
  2. Agen memuat skill vyos-firewall, menangkap konfigurasi saat ini melalui SSH (show configuration commands disimpan ke berkas bertanggal), dan membuka rencana dengan ops_plan: satu langkah, efek add firewall rule, reversibilitas reversible (penghapusan aturan memulihkan keadaan), radius dampak med.
  3. Ia menempatkan perubahan dalam mode konfigurasi dan melampirkan diff perangkat dengan ops_diff.
  4. ops_approve menunjukkan hash rencana dan perubahan yang ditempatkan secara persis; Anda menyetujui, dan token 10 menit diterbitkan.
  5. ops_apply menebus token dan menjalankan urutan commit-confirm; timer rollback otomatis tetap bersiaga sampai verifikasi.
  6. ops_verify memeriksa keterjangkauan dan bahwa aturan cocok dengan lalu lintas yang dimaksud; baik persetujuan maupun hasil dicatat di jurnal, jadi kueri ops_journal kemudian merekonstruksi seluruh perubahan.

Jika penerapan gagal pada langkah 5, token sudah hilang — langkah 4 harus dijalankan lagi sebelum percobaan ulang.

Semantik token persetujuan

  • Pakai sekali — ditebus secara atomik di awal ops_apply; token yang sudah terpakai, tidak dikenal, atau kedaluwarsa gagal tanpa ada yang dieksekusi.
  • Terikat TTL — bawaan 10 menit, maksimum 60. Kedaluwarsa diperiksa secara malas saat dikonsumsi; tidak ada penyapu latar belakang.
  • Terikat rencana — token diterbitkan terhadap hash sha256 kanonik rencana, yang mencakup perintah terapkan yang persis, perintah snapshot opsional, dan direktori kerja. Pergeseran argumen dan token yang diajukan untuk rencana lain ditolak sebelum konsumsi, yang mencegah pemutaran ulang, kebingungan lintas rencana, dan substitusi perintah.
  • Diungkapkan sekali — token mentah muncul tepat sekali pada hasil ops_approve dan tidak pernah disimpan (hanya sha256-nya yang disimpan).
  • Tidak ada pengembalian — penerapan yang gagal atau habis waktu tidak mengembalikan token. Mencoba ulang memerlukan persetujuan ulang melalui ops_approve.

Model keamanan

  • bash_destructive tetap menjadi gerbang untuk mutasi ad-hoc. Alur operasi mencakup perubahan yang direncanakan; perintah destruktif sekali jalan tetap mengenai pengklasifikasi destruktif dan gerbang interaktifnya, dan tidak ada aturan izin yang dapat menyetujuinya otomatis.
  • ops_approve hanya interaktif, seperti isolation_escalation dan bash_destructive: ia selalu meminta, bahkan di bawah kumpulan aturan izinkan-wildcard dan dalam mode otonom tanpa antarmuka.
  • Jurnal hanya-tambah dari sudut pandang agen dan bersakupan proyek; ia hidup lebih lama dari sesi dan tidak dihapus berantai saat sesi dihapus.
  • Paket skill membawa runbook penyedia. cloud-ops-aws, cloud-ops-gcp, cloud-ops-cloudflare, cloud-ops-digitalocean, cloud-ops-runpod, vyos-firewall, dan junos-firewall menyimpan daftar periksa yang mengutamakan hanya-baca, langkah rencana-sebelum-mutasi, dan pola rollback; agen memuat paket yang cocok sebelum mengoperasikan suatu permukaan. OVHcloud dan penyedia lain dicakup melalui server MCP yang dikonfigurasi dan dokumentasinya, bukan rantai CLI yang diimprovisasi.
  • Kredensial tidak pernah mencapai catatan. Penugasan kredensial sebaris pada masukan bash yang disimpan disunting sebelum mencapai log peristiwa.

Mode ketat

Secara bawaan, perintah bash yang diklasifikasikan destruktif (keluarga bash_destructive: kata kerja mutasi cloud atau jaringan, rm -rf, git push --force, dan sisa daftar pengklasifikasi) menerima pertanyaan interaktif yang tidak dapat dilewati — pengguna dapat menyetujui perintah sekali jalan dan ia berjalan. Mode ketat menghapus opsi itu.

Dengan mode ketat aktif, perintah bash yang diklasifikasikan destruktif ditolak langsung, sebelum pertanyaan apa pun. Pesan penolakan mencantumkan perintah yang diklasifikasikan beserta alasannya dan mengarahkan model ke alur yang sah: ops_plan → ops_diff → ops_approve (menerbitkan token persetujuan pakai-sekali) → ops_apply. Mutasi shell destruktif ad-hoc tidak lagi mungkin sama sekali; setiap mutasi harus direncanakan, di-diff, disetujui, dan diterapkan melalui jalur yang didukung jurnal.

Aktifkan di konfigurasi tepercaya (ax-code.json di direktori konfigurasi pengguna, konfigurasi terkelola, atau konfigurasi proyek yang secara eksplisit dipercaya pengguna):

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

Catatan:

  • Interaksi dengan pertanyaan: mode ketat menggantikan pertanyaan bash_destructive dengan penolakan keras. Dengan bendera mati (bawaan), perilaku persis seperti yang dijelaskan di atas — gerbang interaktif tetap ada.
  • Cakupan: bendera adalah konfigurasi global, bukan per agen — ia berlaku untuk setiap panggilan bash di sesi, termasuk subagen. Agen cloudops tidak dapat mengaktifkannya sendiri; agen membawa izin dan prompt, bukan konfigurasi.
  • Cakupan kepercayaan: konfigurasi proyek yang tidak dipercaya dan dikomit repositori tidak dapat mengaktifkan mode ketat; ikut serta per mesin (AX_CODE_TRUST_PROJECT_CONFIG=1) atau atur di konfigurasi pengguna atau terkelola yang tepercaya.
  • ops_apply tidak terpengaruh: jalur mutasi yang sah punya gerbang token terikat rencana sendiri di dalam alat dan tidak pernah berkonsultasi dengan bendera ini.

Sumber kebenaran

  • packages/ax-code/src/agent/agent.ts — definisi agen cloudops dan penggabungan izin
  • packages/ax-code/src/agent/prompt/cloudops.txt — prompt sistem agen
  • packages/ax-code/src/tool/ops_*.ts — enam alat operasi dan deskripsinya
  • packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY (ops_approve, bash_destructive, isolation_escalation)
  • Mode Sandbox — mode isolasi, kontrol jaringan, dan prioritas