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 Loop dan tugas terjadwal

Status: Aktif Cakupan: keadaan saat ini Terakhir ditinjau: 2026-08-27 Pemilik: ax-code runtime

AX Code memiliki tiga primitif otomasi yang dapat disusun:

/loop — prompt berulang

/loop <interval> <prompt>   start (interval like 30s, 5m, 1h)
/loop status                show runs, busy-skips, and the prompt
/loop stop                  stop the loop

Contoh:

/loop 5m check CI for new failures and fix any you find
/loop 30m drain the review queue

Aturan:

• Batas interval: 30 detik sampai 24 jam. Satu loop per sesi — memulai yang baru menggantikan yang lama.
• Detak yang terpicu saat sesi sibuk dilewati dan dihitung, tidak pernah diantre — loop tidak dapat menumpuk giliran.
• Setiap detak adalah giliran prompt biasa: izin, pertanyaan, batas otonom, dan gerbang penyelesaian semuanya berlaku. Dengan otonom mati, detak hanya berhenti di prompt izin pertama.
• Batas keras 500 eksekusi per loop, lalu loop berhenti sendiri dengan pemberitahuan.
• Loop hanya hidup di proses backend: mereka tidak bertahan melewati mulai ulang. Untuk jadwal yang tahan lama, gunakan tugas terjadwal di bawah.

Memasangkan /goal dengan /loop

/goal memiliki tujuan (“semua tes hijau, tidak ada temuan tinjauan yang terbuka”); /loop menyediakan detak yang terus memeriksa. Membuat tujuan terlebih dahulu menjalankan penulis rencana khusus yang menyimpan kontrak yang dapat ditinjau di bawah .ax-code/goals/ (atau direktori data AX ketika proyek bukan worktree git). Jika perencanaan gagal, tujuan tetap dijeda — /goal resume mencoba ulang. Pemeriksaan rentang Git yang mengukur diff tujuan ini memakai HEAD saat rencana ({BASELINE}), bukan origin/main, kecuali tujuan menyebut remote itu. Penyelesaian tujuan tetap digerbangi verifikasi: agen tidak dapat menandai tujuan selesai setelah suntingan tanpa eksekusi verifikasi yang lulus, dan ketika rencana ada ia juga harus menyediakan bukti untuk setiap kriteria penerimaan.

/goal keep main green: fix any CI failure the loop finds
/loop 10m check CI status and act on failures

Jaminan tujuan bersifat ikut serta

/goal <objective> mulai segera: ia tidak melampirkan kontrak penerimaan yang dibekukan, jadi penyelesaian dinilai dari rencana kerja yang dijaga agen (todo yang tertunda) plus verifikasi yang lulus setelah perubahan terakhirnya. /goal view (dan “Lihat rincian tujuan” pada dialog tujuan) menyatakannya secara eksplisit — “Tidak ada kontrak jaminan” — jadi keadaan tidak pernah harus Anda simpulkan sendiri.

/goal --assure <objective> menjalankan penulis rencana terlebih dahulu, yang membekukan kriteria penerimaan, rujukan sumber, dan pemeriksaan yang dapat dieksekusi; penyelesaian kemudian juga memerlukan tanda terima berhasil yang mutakhir untuk setiap pemeriksaan wajib (verify_project dengan id goalCheck). Pakai ini ketika “selesai” suatu tujuan harus dapat dibuktikan, bukan hanya diuraikan.

--assure digabung dengan bendera anggaran dalam urutan mana pun (/goal --assure --budget 500000 <objective>). /goal replace <objective> mempertahankan jaminan ketika tujuan yang diganti memiliki kontrak yang valid, jadi penggantian tidak pernah diam-diam melemahkan tujuan yang sudah dijamin.

Anggaran dan langit-langit tujuan

Tujuan yang aktif menaikkan batas kelanjutan otomatis per eksekusi (session.max_continuations) — eksekusi terus berjalan sampai tujuan selesai, terblokir, dijeda, atau terbatas anggaran. Yang membatasinya sebagai gantinya:

• Anggaran token (/goal --budget N …): ketika habis, agen mendapat satu giliran penutup, lalu tujuan menjadi budget_limited.
• Anggaran waktu (/goal --time-budget 30m …): batas waktu dinding dalam detik, menit (m), atau jam (h), dapat digabung dengan anggaran token dalam urutan mana pun. Ia membatasi kerja yang berlalu yang tidak terlihat anggaran token — pekerjaan pelatihan jarak jauh, panggilan alat yang panjang, kemacetan penyedia. Giliran penutup yang sama dan transisi budget_limited berlaku ketika batas itu terpicu.
• Langit-langit langkah kumulatif: eksekusi tujuan aktif berbagi penahan Super-Long sebesar max_steps × 40 langkah total (20,000 secara bawaan) alih-alih langit-langit otonom biasa sebesar max_steps × (max_continuations + 1). Timpa dengan session.max_total_steps.
• Deteksi doom-loop, batas radius dampak, dan pemutus giliran hanya-alat tetap berlaku sepanjang waktu.

CLI tujuan (tanpa antarmuka)

Kendali tujuan yang sama tersedia di luar TUI di bawah ax-code goal:

• ax-code goal status [--json] — tampilkan tujuan saat ini (-s/--session untuk memilih sesi; bawaan ke satu tujuan proyek yang dapat dilanjutkan dan kesalahan ketika pilihan akan ambigu).
• ax-code goal pause / ax-code goal clear — jeda atau bersihkan.
• ax-code goal resume — lanjutkan tujuan dan jalankan tanpa antarmuka sampai menetap. Tanpa --attach ia memulai proyek di dalam proses; dengan --attach http://localhost:4111 ia mengendalikan server yang sedang berjalan. Kode keluar mengikuti kontrak tujuan tanpa antarmuka: 0 selesai, 3 terblokir, 4 terbatas anggaran, 6 dijeda atau belum terminal, 1 kesalahan sesi, 124 batas waktu menganggur (--idle-timeout-ms, bawaan 10 menit). Peristiwa mengalir ke stdout sebagai JSONL (--event-log PATH juga merekamnya), dan baris akhir Goal <status>: <objective> pergi ke stderr.

Saat eksekusi tujuan mendekati langit-langit langkah, agen menerima peringatan konvergensi satu kali yang menyuruhnya memverifikasi dan menyelesaikan tujuan atau meninggalkan serah terima yang bersih. Jika langit-langit tetap tercapai, tujuan dijeda — bukan gagal — dan dapat dilanjutkan lagi dengan /goal resume (naikkan session.max_total_steps terlebih dahulu jika perlu ruang lebih).

Tugas terjadwal — tahan lama, percakapan

Minta agen secara langsung; ia memakai alat schedule_task, list_scheduled_tasks, dan manage_scheduled_task:

• “Ingatkan saya pukul 14:30 untuk memeriksa penerapan.”
• “Setiap hari kerja pukul 9 pagi, ringkas kegagalan CI yang baru.”
• “Daftar tugas terjadwal saya.” / “Jeda tugas ringkasan CI.”

Perubahan jadwal yang dibuat dan dikelola agen meminta izin schedule. Eksekusi hanya-baca tidak dapat mengubah atau memicu jadwal. Untuk pembuatan tanpa pengawasan tanpa antarmuka, gunakan perintah eksplisit ax-code schedule atau konfigurasikan pemberian izin schedule yang eksplisit untuk agen; pemberian wildcard yang luas tidak mengotorisasi perubahan jadwal.

Tugas yang sama dapat dikelola dari shell tanpa membuka TUI:

ax-code schedule list                 # status, next run, schedule, id, title
ax-code schedule show <id>            # details plus the five most recent runs
ax-code schedule runs <id>            # run history: fired, failed, skipped and why
ax-code schedule pause|resume <id>
ax-code schedule delete <id>
ax-code schedule run <id>             # trigger now; requires a live runtime

pause/resume/delete melewati runtime terkelola proyek ketika ada yang berjalan (efek segera, pembaruan TUI langsung) dan jika tidak menulis basis data proyek secara langsung. run memerlukan backend yang hidup — mulai dengan ax-code runtime start — karena proses CLI sekali jalan tidak boleh mengklaim kerja yang tidak dapat diselesaikannya. Semua subperintah baca menerima --json.

Jadwal mendukung eksekusi sekali, waktu harian atau mingguan, dan ekspresi cron 5 bidang, masing-masing dengan zona waktu IANA opsional. Tugas bertahan di basis data proyek dan terpicu selama backend AX Code untuk proyek itu berjalan (sapuan penjadwal 60 detik, klaim atomik — tugas terpicu sekali bahkan jika beberapa backend terbuka). Kemajuan jadwal dan penyisipan antrean yang tahan lama berbagi satu transaksi basis data, jadi mogok tidak dapat memajukan kejadian tanpa meninggalkan kerja untuk dipulihkan. Perintah sekali jalan seperti ax-code run dan ax-code stats tidak mengklaim tugas yang jatuh tempo. Mulai backend yang menetap dengan ax-code runtime start untuk mengirim mereka.

Kejadian yang terlewat secara bawaan memakai catchUpPolicy: "run_once": setelah waktu henti, AX Code menggabungkan tumpukan apa pun menjadi satu eksekusi. Gunakan "skip" ketika kerja yang basi harus dimajukan tanpa dijalankan. Tugas juga dapat mengatur maxRunDurationMs dari satu detik sampai 72 jam; eksekusi yang habis waktu dibatalkan dan dicatat sebagai gagal.

Untuk operasi yang melewati mulai ulang proses dan host, jalankan backend di bawah pengawas. Lihat Operasi berjalan lama untuk contoh systemd, launchd, dan PM2 plus semantik pemulihan yang persis.

Eksekusi panjang tanpa pengawasan

Untuk sesi otonom berjam-jam, mode Super-Long menambah tenggat eksekusi (sampai 72 jam), pengaturan laju permintaan, dan penyetelan pemadatan. Ia aktif otomatis untuk model yang kapabilitas terdeklarasinya mendukung kerja agen panjang (model penalaran konteks 1M seperti Qwen 3.7+ Max/Plus pada rute Alibaba dan GLM 5.x pada rute z.ai) dan dapat dipaksa per sesi, per proyek, atau lewat AX_CODE_SUPER_LONG. Keterlibatan eksekusi dicatat (super-long run engaged), dan pengaturan laju penyedia hanya mulai setelah jendela tenggang dari awal eksekusi (bawaan 2 jam, super_long.pacing_grace_minutes) agar fase awal yang produktif dari eksekusi agentik mempertahankan throughput panggilan alat penuh; ekor maraton diatur lajunya sesuai tingkat batas laju yang dideklarasikan model.