Model agen

Apa itu agen?

Agen adalah aktor bernama dengan persona, sekumpulan skill dan adapter untuk menjalankannya. Agen adalah prinsipal dalam pengertian yang sama seperti manusia: agen menulis pesan, memiliki tiket, meninggalkan tinjauan dan muncul di daftar yang sama. Agenlah yang mengerjakan pekerjaan.

Setiap agen hanya milik satu ruang kerja. Ini adalah invarian keras — agent.workspaceId tidak boleh null, ruang kerja milik agen itu sendiri yang menentukan file basis data tempat barisnya disimpan dan pembuatan agen tanpa ruang kerja akan ditolak.

Agen juga merupakan sebuah direktori. Definisinya berada di agents/<slug>/AGENTS.md di bawah direktori data ruang kerja, dengan skill yang dimilikinya ditautkan secara simbolik ke agents/<slug>/.agents/skills. Baris basis data dan filenya ditulis bersamaan. Proses seeding bersifat idempoten: jika baris agen sudah ada, file di disk dan tautan skillnya tetap ditulis ulang. Pemanggil di produksi adalah pembuatan ruang kerja, bukan setiap kali server dijalankan.

Apa yang dibawa agen

Atribut	Fungsinya
`name`	Pengenal pendek mirip slug (`architect`, `qa`). Juga menjadi acuan penyelesaian `@mentions`
`title`	Judul pekerjaan yang terbaca manusia
`persona`	Instruksi kepribadian dan perilaku berupa teks bebas, disuntikkan sebagai bagian prompt
`systemPrompt`	Instruksi tambahan opsional, disuntikkan sebagai bagian “Agent instructions” — tidak menggantikan bagian lain dari prompt yang dirakit
`skills`	Kumpulan nama skill yang tidak peka huruf besar/kecil, dicerminkan sebagai tautan skill di disk
`adapterId`	Runner tujuan pengiriman agen. Null akan jatuh kembali ke loop bawaan
`modelId`	Model mana di dalam adapter tersebut
`effort`	Tingkat penalaran, diambil dari kosakata model yang dipilih
`contextSize`	Penimpaan jendela konteks
`silenceTimeoutMinutes`	Penimpaan per agen (1–240) untuk pengawas waktu diam
`reportsTo`	ID agen induk — rantai pelaporan yang digambar bagan organisasi

Semua ini Anda ubah di Pengaturan → Ruang kerja → Agen. Agen baru membuat agen tanpa nama yang kemudian Anda isi.

Skill

Skill adalah nama-nama pada entitas agen yang tidak peka huruf besar/kecil. Ada dua hal terpisah yang terjadi dengannya:

Nama-namanya dicantumkan di prompt yang dirakit dengan judul “Skills”. Hanya itu yang dilakukan kumpulan milik entitas itu dengan sendirinya — tidak ada pustaka prompt per skill yang mengacu padanya.
Direktori setiap skill yang bernama (skills/<slug>/SKILL.md di ruang kerja) ditautkan ke folder agen itu sendiri. Pada harness bawaan, frontmatter skill yang ditautkan dimuat otomatis ke prompt sistem dan agen membaca isinya sesuai kebutuhan; mengetik /skill:<name> dalam percakapan memuat isi itu sebagai direktif untuk giliran tersebut.

Skill yang diambil dari luar melewati pemindaian rantai pasok yang menolak secara default antara pengambilan dan penulisan — tidak ada konten skill yang mencapai disk atau prompt tanpa putusan. Yang dimaksud “luar” adalah repositori GitHub yang Anda daftarkan sendiri sebagai sumber skill: tidak ada toko terkurasi, jadi metadata repositori itu sendiri (deskripsinya, bintangnya, nama skillnya) adalah data tampilan yang tidak tepercaya dan putusan pemindaian adalah satu-satunya sinyal keamanan. Sebuah instalasi mengambil seluruh direktori skill, menyematkannya ke commit asalnya di skills-lock.json, dan pembaruan berikutnya melewati gerbang itu lagi sebelum mengganti apa pun. Panduan caranya ada di instal dan kelola skill.

Skill dengan cakupan repo

Sebuah repo dapat menyertakan skill-nya sendiri, di tempat konvensional mana pun (.agents/skills/, .claude/skills/, .opencode/skills/). Sebuah space melakukan checkout pada setiap repo yang ditautkan secara berdampingan di bawah repos/<name>/, tetapi agen bekerja di satu repo pada satu waktu — jadi agen hanya membawa skill repo itu, dan skill tersebut berganti saat agen berpindah.

Repo mana yang aktif disimpulkan dari file yang disentuh agen: menulis file di bawah repos/<name>/ menjadikannya repo aktif, sedangkan sekadar membaca lintas repo tidak, sehingga menelusuri simbol ke layanan saudara tidak pernah mengganti kumpulan skill di tengah tugas. Pada space dengan satu repo, jawabannya sudah diketahui sebelum giliran pertama.

Pembatasan cakupan ini adalah keputusan anggaran konteks. Indeks skill berada di prompt pada setiap giliran sementara isinya tidak, jadi mendaftarkan skill semua repo sekaligus memakan token terus-menerus — dan skill testing dari satu layanan justru menyesatkan saat pekerjaannya ada di layanan lain. Alasan yang sama juga menjelaskan mengapa indeks agen hanya membawa satu repo tetapi composer tidak dibatasi begitu: menamai skill sendiri adalah satu tindakan eksplisit, sehingga /skill:<repo>:<name> menjangkau repo mana pun di space.

Skill repo dimuat untuk setiap adapter, bukan hanya harness bawaan. Skill repo aktif diwujudkan ke direktori kerja agen, yaitu path yang sudah dipindai Claude Code; indeks yang sama disusun ke dalam AGENTS.md yang dibaca harness bawaan. Skill sebuah repo melewati pemindaian yang menolak secara default yang sama dengan skill yang diinstal sebelum semua itu terjadi — repo yang di-checkout adalah konten hasil klon, dan frontmatter-nya mencapai prompt.

Izin

Agen tidak membawa flag izin sendiri. Apakah agen boleh membuat commit, melakukan push, membuka pull request, menulis ke pelacak, atau menjangkau jaringan ditentukan oleh pagar pengaman aksi — izinkan, tanyakan dulu, atau tolak, pada cakupan ruang kerja, agen, atau space — dan aturan yang sama berlaku adapter mana pun yang menjalankannya.

Apa yang diberikan ke sebuah run tidak berubah karena aturan-aturan itu. Run di worktree GitHub selalu mendapat token GitHub hanya-baca, dan push ditanyakan saat push itu terjadi: konfigurasi git agen mengirim setiap push GitHub melalui Control Center, yang menerapkan aturan Push ke remote sebelum meneruskannya.

Lihat Sandbox dan keamanan untuk cara kerjanya, termasuk apa yang ditegakkan dan tidak ditegakkan di tingkat sistem file.

Adapter menentukan apa yang bisa ditegakkan

Bidang yang paling berpengaruh pada agen adalah adapter-nya, karena transport adapter menentukan seberapa banyak kebijakan Control Center yang benar-benar dapat ditegakkan.

Transport	Adapter	Apa yang ditegakkan Control Center
Harness bawaan	Control Center (built-in)	Semuanya. Permukaan alatnya dibangun dari mode, jadi alat yang tidak diizinkan menjadi tidak terlihat, bukan sekadar ditolak; setiap panggilan melewati gerbang persetujuan dan pagar pengaman tindakan; kontrak penyelesaian dapat menegur lalu menggagalkan run yang berakhir tanpa hasil kerjanya
Claude CLI	Claude Code	Alat `mcp__*` yang disediakan untuknya, ditambah perintah `Bash`-nya, yang dikirim sebuah hook ke kebijakan aksi sebelum dijalankan. Alat baca, tulis, dan edit milik Claude sendiri berjalan di dalam prosesnya dan berjalan tanpa terlihat — dan CLI-nya diluncurkan dengan `--dangerously-skip-permissions`, karena `claude -p` yang non-interaktif jika tidak akan terblokir selamanya pada prompt-nya sendiri

Secara konkret, hanya harness bawaan yang mendukung subagen, pengarahan di tengah run, jeda dan lanjutkan (dan karena itu ambil alih) serta penegakan mode secara struktural. Claude Code tidak mendapat satu pun dari itu.

Matriks di atas berbicara tentang apa yang dapat dilihat dan dibatasi oleh Control Center. Di bawahnya, cc_server membungkus CLI Claude Code dalam sandbox OS milik host jika ada — Seatbelt di macOS, bubblewrap di Linux dan WSL2 — sehingga rm yang tak terlihat atau penulisan yang tak terlihat tetap dibatasi oleh OS. Di Windows tidak ada backend sama sekali dan di Linux atau WSL2 tanpa bwrap dan socat probe melaporkan tidak ada, jadi di sana run tersebut jatuh kembali ke sanitasi lingkungan, kredensial via broker, pagar pengaman pada panggilan yang bisa dilihat Control Center dan worktree percakapan itu sendiri (copy-on-write di tempat rift dikirim; git worktree di Windows).

Apa yang bukan sandbox adalah sebuah gerbang. Sandbox membatasi di mana sebuah proses boleh membaca, menulis dan terhubung — mode hanya-baca memang menjangkaunya, sebagai bind mount hanya-baca — tetapi sandbox tidak dapat mencegat panggilan, memunculkan persetujuan, atau memberi tahu Anda setelahnya apa yang dicoba CLI. Itu, ditambah keempat kemampuan yang disebut di atas, tetap yang dimiliki harness bawaan dan tidak dimiliki yang lain. Lihat Sandbox dan keamanan.

Agen tanpa adapter jatuh kembali ke Control Center (built-in) — loop di dalam server, jadi tidak ada CLI yang perlu diinstal — dan log run-nya mencatat cc-harness. Setiap agen hasil seeding dibuat tanpa adapter atau model, jadi kelima agen di ruang kerja baru semuanya berjalan di sana, pada model default Anthropic, sampai Anda menetapkan adapter dan model untuk tiap agen. Pilihan “adapter default” saat onboarding adalah preferensi sisi klien yang tidak pernah dibaca server dan tidak berlaku surut ke agen yang sudah dibuat.

Dari mana agen berasal

Diseed bersama ruang kerja. Setiap ruang kerja — bukan hanya yang pertama — mendapat seorang CEO plus empat spesialis (qa, architect, engineer, librarian) yang melapor kepadanya, dibuat secara idempoten di latar belakang saat ruang kerja dibuat. Lihat Ruang kerja dan isolasi.
Ditambahkan secara manual di Pengaturan → Ruang kerja → Agen. Meminta agen merekrut kolega tidak membuat baris; gunakan layar itu.

Status langsung

Agen tidak memiliki kolom status yang tersimpan. Status langsungnya diturunkan dari log run terbarunya setiap kali dibaca:

Status	Arti
`neverRun`	Tidak ada log run
`running`	Setidaknya ada satu run yang sedang berlangsung
`failed`	Run terbaru mengalami error, atau liveness-nya failed atau dead
`blocked`	Liveness run terbaru blocked, stalled, atau looping
`idle`	Segala hal lainnya — agen sudah pernah berjalan dan tidak ada yang sedang diproses

Dua status lain, queued dan succeeded, ada untuk run individual di pohon run percakapan; daftar agen tidak pernah menghasilkannya, karena run yang selesai berwarna hijau adalah fakta tentang run itu, bukan tentang agennya.

Daftar kehadiran menampilkan gambaran paralel yang lebih kasar yang disintesis di sisi server dari peristiwa run langsung — berpikir, berjalan, terblokir menunggu persetujuan, selesai — dan itulah yang membuat agen muncul di samping manusia. Lihat Multiplayer.

Konsep terkait

Siklus hidup pengiriman agen: apa yang terjadi saat agen benar-benar dijalankan
Mode: pengaturan per percakapan yang membentuk permukaan alat agen
Multiplayer: agen sebagai prinsipal, kehadiran dan tombol otonomi
Sandbox dan keamanan: apa yang membatasi sebuah run saat ini
Referensi konfigurasi agen: daftar bidang lengkapnya