AX Code’u edinin · ÜcretsizBelgeler

Bu sayfa İngilizce belgenin çevirisidir. Komutlar, tanımlayıcılar ve örnekler aynıdır. Çalışma zamanı 7.24.4 · SDK 2.6.7. İngilizce kaynak

Bulut İşlemleri Modu

Durum: Etkin Kapsam: güncel durum Son inceleme: 2026-09-04 Sahip: ax-code runtime

Bulut İşlemleri Modu, altyapı yönetmek için hazır bir duruştur — bulut sağlayıcıları (AWS, GCP, Cloudflare, OVHcloud, DigitalOcean, RunPod) ve ağ aygıtları (VyOS, Juniper Junos) — bir hata canlı sistemleri etkiler ve git geri alması durumu geri getiremez. Yerleşik cloudops ajanı olarak gelir: kuralları elle yazmak yerine tek seçimle açtığınız bir sistem istemi artı bir izin duruşu.

Modun size verdikleri

  • Önce salt okunur ajan. cloudops ajanı her göreve envanter ve kuru çalıştırmalarla başlar ve istemi, bir plan, bir fark ve geri alma tarifleri oluşmadan değişikliği yasaklar.
  • Çalıştırmadan önce soran kabuk. bash değeri ask olarak ayarlıdır, bu yüzden her kabuk komutu onaylanır. Bulut ve ağ değiştiren eylemler (aws/gcloud/az/doctl silme ailesi, kubectl delete/apply --prune, plan dosyası olmayan terraform apply, commit-confirm olmadan ssh uzaktan commit, denetim düzlemi API’lerine karşı curl değişiklikleri) bash_destructive olarak sınıflandırılır ve ayrı, atlanamayan etkileşimli bir kapı taşır.
  • Birinci sınıf işlem araçları. ops_plan, ops_diff, ops_verify ve ops_journal önceden izinlidir; ops_approve ve ops_apply etkileşimli yollarında kalır (aşağıda).

İş akışı: plan → fark → onay → uygulama → doğrulama → günlük

  1. ops_plan — bir OperationPlan açın: hedef (sağlayıcı, hesap, bölge veya aygıt), niyet, tam uygulama komutu ve komut bağlamı ile etki, geri alınabilirlik (reversible | hard | irreversible) ve etki yarıçapı (low | med | high) içeren adımlar. Kurallı bir plan özeti üretir.
  2. ops_diff — makinece denetlenebilir yapıtı (terraform plan -out, show | compare, CLI kuru çalıştırma çıktısı) üretin, inceleyin ve ekleyin. Fark yoksa onay da yoktur.
  3. ops_approve — insan, özeti sabitlenmiş planı onaylar. Bu kapı yalnızca etkileşimlidir: hiçbir joker kural ve hiçbir otonom mod onu önceden onaylayamaz ve kalıcı bir «her zaman izin ver» bağışı sunulmaz.
  4. ops_apply — onaylanan planın değişikliğini onay belirteciyle yürütün. Bu, yaptırımı olan tek değişiklik yoludur; belirteç bir şey çalışmadan önce kullanılır.
  5. ops_verify — planın bildirimsel salt okunur doğrulamalarını çalıştırın ve geçme veya kalma kanıtını kaydedin.
  6. ops_journal — yalnızca eklenen, projeye kapsamlı işlem günlüğünü proje, plan veya duruma göre sorgulayın.

Modu açma

TUI içinde ajan seçiciden Cloud Ops seçin (veya kapsamı belirlenmiş bir görev için cloudops adresinden söz edin). Bir proje için varsayılan yapmak üzere ax-code.json dosyasına ekleyin:

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

workspace-write dosya değişikliklerini çalışma alanına kapatır; network: true webfetch, websearch ve sağlayıcı CLI araçlarını erişilebilir tutar (ağ, sanal alanlı modlarda aksi halde kapalıdır — bkz. Sandbox modu). İkisi de ajandan bağımsız oturum yalıtım ayarlarıdır, bu yüzden ajan hazır ayarının içinde değil burada yapılandırılır.

Duruşu proje başına agent.cloudops.permission altında sıkılaştırabilir veya genişletebilirsiniz; örneğin belirli araçları reddedin. Depoya işlenen yapılandırma yalnızca ret kuralları ekleyebilir; bir ask değerini allow değerine gevşetmek güvenilen kullanıcı veya yönetilen yapılandırmanızdan gelmelidir, asla depodan değil. Ajanı tamamen kaldırmak için "agent": { "cloudops": { "disable": true } } ayarlayın.

İşlenmiş bir örnek

Bir VyOS yönlendiricisine güvenlik duvarı değişikliği uygulama:

  1. Şunu sorarsınız: «uç güvenlik duvarında 10.0.0.0/8 ağından tcp/8443 izin ver».
  2. Ajan vyos-firewall becerisini yükler, güncel yapılandırmayı SSH üzerinden yakalar (show configuration commands tarihli bir dosyaya kaydedilir) ve ops_plan ile bir plan açar: bir adım, etki add firewall rule, geri alınabilirlik reversible (kural silme durumu geri getirir), etki yarıçapı med.
  3. Değişikliği yapılandırma modunda hazırlar ve aygıt farkını ops_diff ile ekler.
  4. ops_approve size plan özetini ve tam hazırlanmış değişikliği gösterir; onaylarsınız ve 10 dakikalık bir belirteç verilir.
  5. ops_apply belirteci kullanır ve commit-confirm dizisini çalıştırır; otomatik geri alma zamanlayıcısı doğrulamaya kadar kurulu kalır.
  6. ops_verify erişilebilirliği ve kuralın amaçlanan trafikle eşleştiğini denetler; hem onay hem sonuç günlüğe yazılır, böylece sonraki bir ops_journal sorgusu değişikliğin tamamını yeniden kurar.

Uygulama 5. adımda başarısız olsaydı belirteç gitmiş olurdu — herhangi bir yeniden denemeden önce 4. adım yeniden çalışırdı.

Onay belirteci anlambilimi

  • Tek kullanımlık — ops_apply başlangıcında atomik olarak kullanılır; tüketilmiş, bilinmeyen veya süresi dolmuş bir belirteç hiçbir şey yürütülmeden başarısız olur.
  • TTL bağlı — varsayılan 10 dakika, en fazla 60. Sona erme tüketim anında tembel denetlenir; arka plan süpürücüsü yoktur.
  • Plana bağlı — belirteç, planın kurallı sha256 özetine karşı verilir; bu özet tam uygulama komutunu, isteğe bağlı anlık görüntü komutunu ve çalışma dizinini içerir. Bağımsız değişken kayması ve farklı bir plan için sunulan belirteçler tüketimden önce reddedilir; bu, yeniden oynatmayı, planlar arası karışıklığı ve komut değiştirmeyi önler.
  • Bir kez gösterilir — ham belirteç ops_approve sonucunda tam olarak bir kez görünür ve asla kalıcılaştırılmaz (yalnızca sha256 değeri saklanır).
  • İade yok — başarısız veya zaman aşımına uğramış bir uygulama belirteci geri vermez. Yeniden denemek ops_approve üzerinden yeniden onay gerektirir.

Güvenlik modeli

  • bash_destructive, gelişigüzel değişiklikler için kapı olarak kalır. İşlem iş akışı planlı değişikliği kapsar; tek seferlik yıkıcı komutlar hâlâ yıkıcı sınıflandırıcıya ve etkileşimli kapısına çarpar ve hiçbir izin kuralı onları otomatik onaylayamaz.
  • ops_approve yalnızca etkileşimlidir, isolation_escalation ve bash_destructive gibi: joker izin kural kümeleri altında ve başsız otonom modda bile her zaman sorar.
  • Günlük, ajanın bakış açısından yalnızca eklenir ve projeye kapsamlıdır; oturumlardan uzun yaşar ve oturum silindiğinde zincirleme silinmez.
  • Beceri paketleri sağlayıcı çalışma kitaplarını taşır. cloud-ops-aws, cloud-ops-gcp, cloud-ops-cloudflare, cloud-ops-digitalocean, cloud-ops-runpod, vyos-firewall ve junos-firewall önce salt okunur denetim listelerini, değiştirmeden önce plan adımlarını ve geri alma örüntülerini tutar; ajan bir yüzeyi işletmeden önce eşleşen paketi yükler. OVHcloud ve diğer sağlayıcılar, doğaçlama CLI zincirleri değil, yapılandırılmış MCP sunucuları ve belgeleri üzerinden kapsanır.
  • Kimlik bilgileri kayda asla ulaşmaz. Kalıcılaştırılan bash girdilerindeki satır içi kimlik bilgisi atamaları, olay günlüğüne ulaşmadan önce karartılır.

Katı mod

Varsayılan olarak yıkıcı sınıflandırılmış bir bash komutu (bash_destructive ailesi: bulut ve ağ değiştiren eylemler, rm -rf, git push --force ve sınıflandırıcı listesinin geri kalanı) atlanamayan etkileşimli bir soru alır — kullanıcı tek seferlik komutu onaylayabilir ve komut çalışır. Katı mod bu seçeneği kaldırır.

Katı mod açıkken yıkıcı sınıflandırılmış bir bash komutu, herhangi bir sorudan önce doğrudan reddedilir. Ret iletisi sınıflandırılmış komutları gerekçeleriyle listeler ve modeli yaptırımı olan iş akışına yönlendirir: ops_plan → ops_diff → ops_approve (tek kullanımlık bir onay belirteci verir) → ops_apply. Gelişigüzel yıkıcı kabuk değişiklikleri artık hiç olanaklı değildir; her değişiklik planlanmalı, farkı alınmalı, onaylanmalı ve günlük destekli yol üzerinden uygulanmalıdır.

Güvenilen yapılandırmada açın (kullanıcı yapılandırma dizininizdeki ax-code.json, yönetilen yapılandırma veya kullanıcının açıkça güvendiği bir proje yapılandırması):

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

Notlar:

  • Soruşla etkileşim: katı mod, bash_destructive sormasını sert bir ret ile değiştirir. Bayrak kapalıyken (varsayılan) davranış tam olarak yukarıdaki gibidir — etkileşimli kapı kalır.
  • Kapsam: bayrak ajan başına değil genel yapılandırmadır — oturumdaki her bash çağrısına, alt ajanlar dahil, uygulanır. cloudops ajanı bunu kendi başına açamaz; ajanlar yapılandırma değil izin ve istem taşır.
  • Güven kapsamı: güvenilmeyen, depoya işlenen proje yapılandırması katı modu açamaz; makine başına (AX_CODE_TRUST_PROJECT_CONFIG=1) katılın veya güvenilen kullanıcı ya da yönetilen yapılandırmada ayarlayın.
  • ops_apply etkilenmez: yaptırımı olan değişiklik yolunun araç içinde kendi plana bağlı belirteç kapısı vardır ve bu bayrağa hiç bakmaz.

Doğruluk kaynağı

  • packages/ax-code/src/agent/agent.ts — cloudops ajan tanımı ve izin birleştirmesi
  • packages/ax-code/src/agent/prompt/cloudops.txt — ajan sistem istemi
  • packages/ax-code/src/tool/ops_*.ts — altı işlem aracı ve açıklamaları
  • packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY (ops_approve, bash_destructive, isolation_escalation)
  • Sandbox modu — yalıtım modları, ağ denetimleri ve öncelik