Siklus hidup pengiriman agen

Apa itu pengiriman

Pengiriman adalah satu run dari satu agen, dalam satu percakapan, pada satu adapter. Semuanya terjadi di cc_server: klien mengirim pesan lalu menyaksikan peristiwa mengalir kembali. Tidak ada jalur pengiriman di klien mana pun.

Agen dibangkitkan karena enam alasan, yang dibawa run sebagai konteks kebangkitan-nya agar agen tahu mengapa ia bangun:

Alasan kebangkitan	Pemicu
userMessage	Seseorang mengirim pesan di sebuah space, atau menyebut agen
assignment	Sebuah tiket ditugaskan ke agen
pipelineStep	Sebuah langkah pipeline mengirimnya
childCompleted	Tiket anak selesai
followUp	Detak tindak lanjut yang terjadwal
recovery	Jalur pemulihan mengirim ulang setelah kegagalan

Konteks kebangkitan membawa id yang menyertai alasan tersebut — tiket, space, pesan, eksekusi pipeline — dan semuanya disuntikkan ke lingkungan dan prompt agen.

Perakitan prompt

Prompt dibangun berlapis-lapis, masing-masing merupakan bagian berlabel:

• Identitas — id, nama, dan id ruang kerja agen itu sendiri, dengan instruksi eksplisit untuk meneruskan UUID persis tersebut ke alat yang berskop ruang kerja. Ruang kerja melekat pada agen, jadi selalu ada.
• Katalog alat dan protokol sumber daya, lalu tata letak ruang kerja.
• Penimpaan prompt sistem, jika agen memilikinya, lalu persona (diparameterkan berdasarkan peran) dan ringkasan tim.
• Skill — nama-nama yang terpasang pada agen.
• Kontrak dan prosedur eksekusi untuk mode saat ini.
• Konteks kebangkitan dan konteks penyebutan: siapa yang memanggil agen dan daftar kehadiran di sekitarnya.
• Blok mode — dihasilkan dari profil kemampuan mode beserta daftar alatnya yang diwujudkan, sehingga prompt tidak akan pernah menyebut alat yang sebenarnya tidak dimiliki run tersebut.
• Konteks memori — fakta yang diambil untuk tugas tersebut.
• Konteks percakapan — riwayat space terbaru, dibatasi pada jendela verbatim 50.000 karakter, berapa pun ukuran konteks yang dikonfigurasi agen. Riwayat yang lebih lama tidak dipotong: agen mengambilnya sesuai kebutuhan dengan get_messages, dan pesan lama yang relevan secara semantik tetap muncul.

Perintah slash diurai dari teks mentah pengguna

Prompt berlapis diawali dengan blok konteks, jadi tidak dimulai dengan slash. Perintah diurai verbatim dari pesan pengguna lalu dikeluarkan dari ekor prompt berlapis agar setiap lapisan konteks tetap bertahan.

Perintah terbagi di dua tempat. /todo dan /compact dicegat di penyusun pesan dan sengaja tidak pernah disimpan sebagai pesan atau dikirim ke agen — menyimpan /compact akan memundurkan batas pemadatan satu giliran dan mengotori transkrip. /plan ditangani di keduanya: penyusun pesan membalik mode space, dan itulah yang membuat permukaan alat, preset pagar pengaman, serta prompt selaras untuk giliran ini dan setiap giliran sesudahnya. /goal, /loop, dan /skill:<name> ditangani di dalam run itu sendiri dan hanya pada harness bawaan — /goal dan /loop memulai pekerjaan otonom dengan anggaran biaya, dan nama berawalan skill: dicari sebagai skill yang isi SKILL.md-nya menjadi direktif giliran tersebut. Namespace inilah yang memisahkan kedua kosakata itu: menyelesaikan nama tanpa awalan terhadap skill berarti skill bernama plan atau compact selamanya tertutup oleh bawaan. Nama tanpa awalan yang bukan bawaan tetap dapat diselesaikan, untuk pesan yang ditulis sebelum namespace ada. Nama yang tidak dikenali akan langsung diteruskan sebagai teks biasa.

Penyediaan worktree

Sebelum apa pun berjalan, percakapan mendapatkan akar kerjanya sendiri, dengan worktree copy-on-write terisolasi per repo di bawahnya. Secara default, itu mencakup setiap repo yang ditautkan ke ruang kerja; space PR — atau space yang dibuat dengan pilihan eksplisit — hanya menyediakan repo yang masuk daftar izin, dan percakapan tinjauan PR memakukan satu repo miliknya ke head ref pull request sementara repo lainnya berada di branch default-nya. Checkout sumber tidak pernah diubah, dan seluruh direktori percakapan dibebaskan kembali saat space dihapus.

Copy-on-write adalah satu-satunya implementasi di mana pun rift disertakan, dengan dukungan native yang dibundel. Sistem berkas yang tidak dapat melakukan reflink — atau dir data yang berada di volume berbeda dari repo — membuat penyediaan gagal alih-alih memakai fallback. git worktree adalah backend-nya di Windows, yang tidak punya backend copy-on-write untuk dibangun, dan itu bukan degradasi senyap di host lain. rift yang hilang di platform yang seharusnya menyertakannya berarti instalasi rusak — server menolak untuk boot alih-alih diam-diam memakai fallback, karena fallback senyap akan menyembunyikan kerusakan di balik jalur yang lebih lambat selamanya.

Identitas dan kredensial

Dua identitas diselesaikan per run, sebelum proses apa pun diluncurkan.

Kepengarangan Git. Commit yang dibuat agen dikarang sebagai agen — <Name> (agent) <agentId@agents.control-center.local> di GIT_AUTHOR_* maupun GIT_COMMITTER_* — tidak pernah menyamar sebagai manusia. Bagian lokalnya adalah UUID agen, bukan slug namanya. Manusia yang meminta dicantumkan lewat trailer Co-Authored-By:, yang dibawa di lingkungan dan diinstruksikan di prompt sistem. Identitas eksplisit yang ditetapkan pemanggil selalu menang atas keduanya.

Identitas forge. Kredensial GitHub dalam run selalu hanya milik broker — token instalasi App yang berskop repo, atau fallback PAT dari lingkungannya — tidak pernah token tersimpan milik anggota yang meminta. actingUserId membatasi fallback PAT agar anggota yang bukan pemilik server tidak mewarisi jangkauan server; ini tidak menimpakan token pribadi ke lingkungan agen.

Kredensial penyedia model diselesaikan dalam urutan tetap, dan urutannya penting:

1. penimpaan lingkungan per adapter,
2. lingkungan pemanggil,
3. penyimpanan kredensial server (menyegarkan token OAuth jika hampir kedaluwarsa),
4. lingkungan proses.

Karena penimpaan per adapter didahulukan, ia diam-diam mengalahkan akun penyedia yang terhubung di aplikasi. Jika sebuah run menagih ke akun yang salah, penimpaan itulah tempat pertama yang perlu diperiksa. Kredensial penyedia bersifat global per host — dibagi ke seluruh ruang kerja pada instalasi tersebut.

Token GitHub milik run berasal dari broker kredensial: token hanya-baca yang bercakupan repo milik worktree. Push melewati gateway run agen, yang menanyakan aturan Push ke remote sebelum meneruskannya, dan tidak ada kunci tiket yang disuntikkan. Lihat Sandbox dan keamanan.

Peluncuran

Run dijalankan dengan worktree-nya sebagai direktori kerja dan — untuk Claude Code — konfigurasi MCP yang dihasilkan agar agen dapat menjangkau permukaan alat Control Center. ACP dan bash di harness mendapat lingkungan yang disanitasi; Claude Code melalui NoSandboxAdapter mewarisi lingkungan host.

Sandbox OS hanya membungkus run di host yang punya backend

cc_server memeriksa host sekali saat boot dan, bila backend tersedia, membungkus proses agen dengannya — Seatbelt di macOS, bubblewrap di Linux dan WSL2. Kedua sambungan pengiriman dibungkus, karena keduanya tidak memakai satu jalur yang sama: CLI Claude Code melewati port sandbox; adapter ACP dan alat bash milik harness bawaan melewati manajer sandbox. Itu juga yang menerapkan jalur terlindungi milik run: checkout repo yang Anda daftarkan bersifat tolak-tulis di dalam sandbox, di setiap mode.

Bila tidak ada backend, run tidak di-sandbox dan tidak ada hal lain yang berubah sebagai kompensasi. Artinya Windows selalu demikian (tanpa pembungkusan native — microvm adalah jalur terpisah yang digerbangi pemeriksaan, untuk terminal dan rig) serta Linux atau WSL2 tanpa bwrap dan socat di PATH. Server menyebutkan status mana yang berlaku di baris log saat startup, dan --sandbox off untuk keluar secara sengaja.

Dua celah tetap ada meski sandbox aktif. Alat berkas dalam proses milik harness (read, write, edit, apply patch, search, find, search_files) berjalan di dalam proses server, jadi tidak ada profil yang membatasinya — batasnya adalah pengurungan jalur milik alat itu sendiri ditambah pagar pengaman. Dan Claude Code diluncurkan dengan --dangerously-skip-permissions, sehingga panggilan berkasnya sendiri tidak digerbangi oleh Control Center, dan perintah shell-nya hanya oleh hook yang membaca baris perintah; sandbox OS adalah batas di sekelilingnya.

Batas lainnya berlaku di setiap host, dengan atau tanpa sandbox: worktree milik run (copy-on-write di tempat rift disertakan; git worktree di Windows), token forge hanya-baca yang dijembatani per peluncuran lalu dicabut saat pembongkaran, push yang harus lolos aturan push di gateway run agen, pagar pengaman aksi terpadu (fail-closed — keputusan prompt tanpa penyetuju yang terhubung akan ditolak), serta permukaan alat yang diizinkan mode percakapan. ACP dan bash di harness tetap menyanitasi lingkungan; Claude Code melalui NoSandboxAdapter mewarisi lingkungan host.

Aliran peristiwa

Run mengalirkan kembali urutan peristiwa bertipe, yang dipersistenkan oleh pemroses aliran sebagai delta pesan, dilipat menjadi segmen transkrip, dan diubah menjadi peristiwa perpesanan:

Peristiwa	Yang dibawanya
thinking	Keluaran penalaran, ditampilkan inline
text	Keluaran yang terlihat
toolCall	Pemanggilan alat, beserta id dan argumen terstrukturnya
toolResult	Hasil yang cocok, ditandai jika galat atau aliran parsial
usage	Jumlah token dan biaya untuk satu jendela pengukuran
error	Galat, beserta kode terstruktur milik adapter jika dilaporkan
sandboxViolation	OS menolak sebuah syscall. Hanya dipancarkan jika sandbox benar-benar membungkus proses — lihat catatan di atas
debug	Diagnostik runtime (penanda peluncuran, keputusan pagar, dorongan kontrak)
done	Run selesai

Apa yang membatasi sebuah run

Sengaja tidak ada plafon giliran di mana pun. Jumlah iterasi yang dipatok akan mematikan pekerjaan panjang yang sah (migrasi, pembersihan fan-out) dan tidak menangkap apa pun yang tidak sudah ditangkap lebih dahulu oleh penjaga di bawah ini. Sebuah run berakhir ketika:

• model berhenti sendiri;
• manusia menghentikannya, atau mengambil alih percakapan (yang menjeda harness bawaan pada batas giliran bersih berikutnya — run Claude Code, yang tidak punya batas aman, justru dihentikan);
• pengawas keheningan menyala. Tidak ada keluaran selama ambang waktu dan sesi dihentikan dengan kegagalan silentRun. Default-nya 15 menit, turun menjadi 10 menit di mode yang sebagian besar membaca (Tinjauan dan Rencana); agen dapat menimpanya antara 1 dan 240 menit. Pengawas ini diaktifkan saat proses anak melaporkan PID-nya, jadi ia mencakup CLI Claude Code — bukan harness bawaan, yang tidak menjalankan proses apa pun;
• batas biaya terpicu — tetapi hanya untuk perintah otonom.

Pagar doom-loop bukan terminator: tiga pemanggilan alat yang identik berturut-turut dan loop akan mengarahkan agen untuk mengubah pendekatannya.

Giliran biasa tidak punya batas biaya

Pagar biaya dalam sesi hanya terpasang untuk /goal dan /loop; run lainnya tidak meneruskan anggaran sama sekali. Untuk perintah tersebut, satu segmen tanpa pengawasan dapat menghabiskan 500 sen ($5,00) secara default, dengan pengarahan lunak di 80% yang meminta agen merampungkan pekerjaan dengan rapi sebelum penghentian keras dan anggaran goal yang tahan lama sebesar 5.000 sen ($50,00) lintas segmen. /goal --budget yang eksplisit tidak pernah dilampaui sebanyak satu segmen penuh.

Secara keseluruhan, giliran interaktif biasa pada harness bawaan tidak punya plafon giliran, tidak punya batas biaya, dan tidak punya pengawas keheningan. Ia berakhir saat model berhenti atau saat Anda menghentikannya. Itu adalah pertukaran yang disengaja — semua alternatifnya mematikan pekerjaan panjang yang sah — tetapi memang berarti run interaktif tanpa pengawasan hanya dibatasi oleh penilaian model itu sendiri.

Di tengah run, pesan yang dikirim ke agen yang sedang berjalan diantrekan sebagai pengarahan dan dikuras pada batas giliran berikutnya, sehingga Anda dapat mendorong run tanpa mematikannya. Pengarahan, penjedaan, subagen, dan kontrak penyelesaian adalah fitur harness bawaan; Claude Code tidak memiliki satu pun darinya.

Bagaimana run dicatat

Setiap pengiriman menulis AgentRunLog: waktu mulai dan selesai, ringkasan, jumlah token dan perkiraan biaya (termasuk biaya yang diakumulasi dari subagen), adapter dan model, id proses dan jalur log, percakapan serta tiket atau eksekusi pipeline yang menjadi induknya, plus dua bidang klasifikasi yang memuat sebagian besar kebenarannya.

• Status bersifat kasar: pending, running, completed, error.
• Keaktifan adalah bacaan yang lebih halus: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
• Keluarga galat mengelompokkan kegagalan secara berguna: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

completed tidak berarti “tersampaikan”

Ketika sebuah run berakhir tanpa hasil yang diwajibkan modenya — run mode Rencana yang tidak pernah memanggil submit_plan, run Orkestrasi yang tidak pernah mengajukan proposal — statusnya tetap completed, karena prosesnya memang keluar dengan bersih. Sinyal jujurnya bersandar pada keaktifan (empty), keluarga galat (silentRun), dan ringkasan yang menyatakan persis apa yang tidak dihasilkan. Ringkasan itu dilindungi: finalisasi tidak akan menimpanya dengan obrolan terakhir model.

Ini disengaja. Membalik statusnya akan menggerakkan mesin keadaan tiket dan pipeline yang sama sekali tidak terkait dengan artefak yang hilang. Ini juga berarti “status: completed” saja tidak pernah cukup untuk menyimpulkan sebuah run berhasil — bacalah ringkasannya.

Menutup run menerbitkan AgentRunCompleted dan banyak hal bergantung padanya: akumulasi biaya pipeline, melanjutkan langkah pipeline yang menunggu run tersebut, menyelesaikan tiket yang mendasarinya, memetakan orkestrasi ke keadaan terminal, keputusan lanjut-atau-berhenti dari pengawas goal, peran pemeriksa, dan evaluasi anggaran setelah run. Daftar kehadiran menyusul secara terpisah, dengan mengamati log run terbaru alih-alih peristiwanya. Notifikasi “agen selesai” tidak ada dalam daftar itu: peristiwa tersebut terpicu saat aliran proses berakhir, sebelum balasannya ditulis, sehingga notifikasinya adalah MessageReceived milik giliran tersebut, yang diterbitkan setelah pesannya disimpan.

Anggaran, setelah kejadian

Penegakan anggaran adalah reaksi, bukan gerbang. Saat run selesai, pengevaluasi membandingkan pengeluaran agen sejak awal bulan dengan plafon efektifnya (kebijakan anggaran yang ditautkan jika ada, jika tidak maka angka bulanan agen itu sendiri; nol berarti tanpa batas). Melewati ambang lunak mencatat insiden peringatan; menghabiskan anggaran mencatat insiden keras dan membalik status siklus hidup agen menjadi paused di bagan organisasi. Pengiriman tetap menerima pekerjaan dari agen tersebut. Pemicu pipeline BudgetThresholdCrossed dapat memulai pekerjaan tindak lanjut dari peristiwa yang sama.

Silsilah percobaan ulang

Setiap log run dapat membawa silsilah percobaan ulang — id run induk, penghitung percobaan, dan ringkasan lanjutan. Pohon run percakapan menampilkan nomor percobaan bila bukan nol. “Coba lagi” dari chat adalah pengiriman baru dengan log run yang baru.

Konsep terkait

• Model agen: apa yang dapat dan tidak dapat ditegakkan adapter
• Mode: dari mana permukaan alat dan kontrak penyelesaian berasal
• Pagar pengaman: kebijakan kelas efek yang dilalui setiap panggilan bergerbang
• Sandbox dan keamanan: kisah isolasi selengkapnya
• Multiplayer: pengarahan, pengambilalihan, dan dial otonomi
• Peristiwa domain: apa yang dipicu oleh AgentRunCompleted