Model ejen

Apakah itu ejen?

Ejen ialah pelaku bernama yang mempunyai persona, satu set kemahiran dan penyesuai untuk dijalankan. Ejen ialah prinsipal dalam erti kata yang sama seperti manusia: mereka menulis mesej, memiliki tiket, meninggalkan semakan dan muncul dalam senarai yang sama. Merekalah yang melakukan kerja.

Setiap ejen tergolong dalam tepat satu ruang kerja. Ini invarian yang tegas — agent.workspaceId tidak boleh nol, ruang kerja ejen sendiri yang memilih fail pangkalan data tempat barisnya disimpan, dan penciptaan ejen tanpa ruang kerja ditolak.

Ejen juga ialah direktori. Definisinya terletak di agents/<slug>/AGENTS.md di bawah direktori data ruang kerja, dengan kemahiran yang dimilikinya dipautkan secara pautan simbolik ke dalam agents/<slug>/.agents/skills. Baris pangkalan data dan fail tersebut ditulis bersama. Pembenihan adalah idempoten: jika baris ejen sudah wujud, fail pada cakera dan pautan kemahiran tetap ditulis semula. Pemanggil dalam pengeluaran ialah penciptaan ruang kerja, bukan setiap pelancaran pelayan.

Apa yang dibawa oleh ejen

Atribut	Apa fungsinya
`name`	Pengecam pendek seperti slug (`architect`, `qa`). Juga yang menjadi asas penyelesaian `@mentions`
`title`	Jawatan yang boleh dibaca manusia
`persona`	Arahan personaliti dan tingkah laku dalam bentuk teks bebas, disuntik sebagai bahagian prompt
`systemPrompt`	Arahan tambahan pilihan, disuntik sebagai bahagian “Agent instructions” — ia tidak menggantikan bahagian lain prompt yang dipasang
`skills`	Set nama kemahiran yang tidak sensitif huruf besar/kecil, dicerminkan sebagai pautan kemahiran pada cakera
`adapterId`	Pelari yang dituju oleh ejen. Nilai nol jatuh kembali kepada gelung terbina
`modelId`	Model mana dalam penyesuai itu
`effort`	Tahap penaakulan, diambil daripada perbendaharaan kata model yang dipilih itu sendiri
`contextSize`	Penggantian tetingkap konteks
`silenceTimeoutMinutes`	Penggantian setiap ejen (1–240) untuk pemantau senyap
`reportsTo`	Id ejen induk — rantaian pelaporan yang dilukis oleh carta organisasi

Anda mengedit semua ini di Tetapan → Ruang kerja → Ejen. Ejen baharu mencipta ejen tanpa nama yang kemudian anda isi.

Kemahiran

Kemahiran ialah nama yang tidak sensitif huruf besar/kecil pada entiti ejen. Dua perkara berasingan berlaku dengannya:

Nama-nama tersebut disenaraikan dalam prompt yang dipasang di bawah tajuk “Skills”. Itu sahaja yang dilakukan oleh set entiti itu dengan sendirinya — tiada pustaka prompt mengikut kemahiran yang berasaskan padanya.
Direktori setiap kemahiran yang dinamakan (skills/<slug>/SKILL.md dalam ruang kerja) dipautkan ke dalam folder ejen sendiri. Pada harness terbina, frontmatter kemahiran yang dipautkan dimuatkan secara automatik ke dalam prompt sistem dan ejen membaca isi kandungannya atas permintaan; menaip /skill:<name> dalam perbualan memuatkan isi tersebut sebagai arahan untuk giliran itu.

Kemahiran yang diambil dari luar melalui imbasan rantaian bekalan yang menolak secara lalai antara pengambilan dan penulisan — tiada kandungan kemahiran mencapai cakera atau prompt tanpa keputusan. Yang dimaksudkan dengan luar ialah repositori GitHub yang anda daftarkan sendiri sebagai sumber kemahiran: tiada kedai yang dikurasi, jadi metadata repositori itu sendiri (penerangannya, bintangnya, nama kemahiran itu) ialah data paparan yang tidak dipercayai dan keputusan imbasan ialah satu-satunya isyarat keselamatan. Satu pemasangan mengambil keseluruhan direktori kemahiran itu, menyematkannya pada commit asalnya dalam skills-lock.json, dan kemas kini kemudian akan melalui pintu itu semula sebelum menggantikan apa-apa. Cara melakukannya ada dalam Pasang dan urus kemahiran.

Kemahiran berskop repositori

Sesuatu repositori boleh menyertakan kemahirannya sendiri, di mana-mana tempat konvensional (.agents/skills/, .claude/skills/, .opencode/skills/). Sesuatu ruang membuat checkout setiap repositori yang dipautkan secara bersebelahan di bawah repos/<name>/, tetapi ejen bekerja dalam satu repositori pada satu masa — jadi ia membawa kemahiran repositori itu sahaja, dan kemahiran tersebut bertukar apabila ia berpindah.

Repositori mana yang aktif disimpulkan daripada fail yang disentuh oleh ejen: menulis fail di bawah repos/<name>/ menjadikan repositori itu aktif, manakala sekadar membaca merentas repositori tidak, jadi menjejaki simbol ke dalam perkhidmatan bersaudara tidak pernah menukar set tersebut di tengah-tengah sesuatu tugas. Dalam ruang satu repositori, jawapannya sudah diketahui sebelum giliran pertama.

Penskopan ini ialah keputusan bajet konteks. Indeks kemahiran berada dalam prompt pada setiap giliran manakala isi kandungannya tidak, jadi menyenaraikan kemahiran semua repositori sekali gus menelan token secara berterusan — dan kemahiran testing daripada satu perkhidmatan secara aktif mengelirukan apabila kerja itu berada dalam perkhidmatan lain. Alasan yang sama menjelaskan mengapa indeks ejen membawa satu repositori tetapi penggubah mesej tidak diskop begitu: menamakan kemahiran sendiri ialah satu tindakan eksplisit, jadi /skill:<repo>:<name> boleh mencapai mana-mana repositori dalam ruang itu.

Kemahiran repositori dimuatkan untuk setiap penyesuai, bukan hanya harness terbina. Kemahiran repositori aktif diwujudkan ke dalam direktori kerja ejen, iaitu laluan yang sudah diimbas oleh Claude Code; indeks yang sama disusun ke dalam AGENTS.md yang dibaca oleh harness terbina. Kemahiran sesuatu repositori melalui imbasan menolak secara lalai yang sama seperti kemahiran yang dipasang sebelum semua itu berlaku — repositori yang telah di-checkout ialah kandungan klon, dan frontmatter-nya mencapai prompt.

Kebenaran

Ejen tidak membawa bendera kebenaran sendiri. Sama ada ia boleh mencipta commit, push, membuka pull request, menulis ke penjejak atau mencapai rangkaian ditentukan oleh guardrail tindakan — benarkan, tanya dahulu atau tolak, pada skop ruang kerja, ejen atau ruang — dan peraturan yang sama terpakai tanpa mengira penyesuai yang menjalankannya.

Apa yang diberikan kepada sesuatu larian tidak berubah dengan peraturan itu. Larian dalam worktree GitHub sentiasa mendapat token GitHub baca sahaja, dan push ditanya pada saat ia berlaku: konfigurasi git ejen menghantar setiap push GitHub melalui Control Center, yang menggunakan peraturan Push ke remote sebelum memajukannya.

Lihat Kotak pasir dan keselamatan untuk cara ia berfungsi, termasuk apa yang dikuatkuasakan dan tidak dikuatkuasakan pada peringkat sistem fail.

Penyesuai menentukan apa yang boleh dikuatkuasakan

Medan yang paling besar kesannya pada sesuatu ejen ialah penyesuainya, kerana pengangkutan penyesuai itu menentukan berapa banyak polisi Control Center yang benar-benar boleh dikuatkuasakan.

Pengangkutan	Penyesuai	Apa yang dikuatkuasakan oleh Control Center
Harness terbina	Control Center (built-in)	Semuanya. Permukaan alat dibina daripada modus, jadi alat yang tidak dibenarkan adalah tidak kelihatan dan bukan sekadar ditolak; setiap panggilan melalui pintu kelulusan dan guardrail tindakan; kontrak penyiapan boleh menyentil dan kemudian menggagalkan larian yang tamat tanpa hasil serahannya
Claude CLI	Claude Code	Alat `mcp__*` yang disajikan kepadanya, serta perintah `Bash`-nya, yang dihantar oleh hook kepada polisi tindakan sebelum dijalankan. Alat baca, tulis dan edit Claude sendiri berada dalam prosesnya dan berjalan tanpa dilihat — dan ia dilancarkan dengan `--dangerously-skip-permissions`, kerana `claude -p` yang tidak interaktif jika tidak akan tergantung selama-lamanya pada promptnya sendiri

Secara konkritnya, hanya harness terbina menyokong subejen, pemanduan pertengahan larian, jeda dan sambung semula (dan oleh itu pengambilalihan) serta penguatkuasaan modus secara struktur. Claude Code tidak mendapat satu pun daripada itu.

Matriks di atas adalah tentang apa yang boleh dilihat dan dikawal oleh Control Center. Di bawahnya, cc_server membalut CLI Claude Code dalam kotak pasir OS hos jika ada — Seatbelt pada macOS, bubblewrap pada Linux dan WSL2 — jadi rm yang tidak dilihat atau penulisan yang tidak dilihat masih dibatasi oleh OS. Pada Windows tiada bahagian belakang sama sekali dan pada Linux atau WSL2 tanpa bwrap dan socat probe melaporkan tiada, jadi di sana larian tersebut jatuh kembali kepada pensanitasi persekitaran, kelayakan yang diuruskan melalui broker, guardrail pada panggilan yang dapat dilihat oleh Control Center dan worktree perbualan itu sendiri (copy-on-write di mana rift disertakan; git worktree pada Windows).

Apa yang bukan dimiliki oleh kotak pasir ialah sifat pintu. Ia membatasi tempat sesuatu proses boleh membaca, menulis dan menyambung — modus baca sahaja memang sampai kepadanya, sebagai bind mount baca sahaja — tetapi ia tidak boleh memintas panggilan, meminta kelulusan, atau memberitahu anda selepas itu apa yang dicuba oleh CLI. Itu, ditambah dengan empat keupayaan yang disebut di atas, masih menjadi apa yang dimiliki oleh harness terbina dan tidak dimiliki oleh yang lain. Lihat Kotak pasir dan keselamatan.

Ejen yang tiada penyesuai jatuh kembali kepada Control Center (built-in) — gelung di dalam pelayan, jadi tiada CLI untuk dipasang — dan log lariannya merekodkan cc-harness. Setiap ejen yang dibenihkan dicipta tanpa penyesuai atau model, jadi lima ejen dalam ruang kerja baharu semuanya berjalan di situ, pada model lalai Anthropic, sehingga anda menetapkan penyesuai dan model bagi setiap ejen. Pilihan “penyesuai lalai” semasa pengenalan ialah keutamaan di pihak klien yang tidak pernah dibaca oleh pelayan dan ia tidak digunakan secara retroaktif kepada ejen yang sudah dicipta.

Dari mana ejen datang

Dibenihkan bersama ruang kerja. Setiap ruang kerja — bukan hanya yang pertama — mendapat seorang CEO serta empat pakar (qa, architect, engineer, librarian) yang melaporkan kepadanya, dicipta secara idempoten di latar belakang apabila ruang kerja itu dicipta. Lihat Ruang kerja dan pengasingan.
Ditambah secara manual di Tetapan → Ruang kerja → Ejen. Meminta ejen mengupah rakan sekerja tidak mencipta baris; gunakan skrin itu.

Keadaan langsung

Ejen tiada lajur status yang disimpan. Keadaan langsungnya diperoleh daripada log larian terbarunya setiap kali ia dibaca:

Keadaan	Maksud
`neverRun`	Tiada log larian wujud
`running`	Sekurang-kurangnya satu larian sedang berjalan
`failed`	Larian terbaharu mengalami ralat, atau keaktifannya gagal atau mati
`blocked`	Keaktifan larian terbaharu tersekat, terhenti atau bergelung
`idle`	Semua yang lain — ejen pernah berjalan sebelum ini dan tiada apa-apa yang sedang berjalan

Dua keadaan lagi, queued dan succeeded, wujud untuk larian individu dalam pokok larian perbualan; senarai ejen tidak pernah menghasilkannya, kerana larian yang sudah selesai berwarna hijau ialah fakta tentang larian itu, bukan tentang ejen.

Senarai kehadiran menunjukkan gambaran selari yang lebih kasar yang disintesiskan di pihak pelayan daripada peristiwa larian langsung — berfikir, berjalan, tersekat menunggu kelulusan, selesai — dan inilah yang membuat ejen muncul bersebelahan manusia. Lihat Multipemain.

Konsep berkaitan

Kitaran hayat penghantaran ejen: apa yang berlaku apabila ejen benar-benar dijalankan
Modus: tetapan setiap perbualan yang membentuk permukaan alat ejen
Multipemain: ejen sebagai prinsipal, kehadiran dan dail autonomi
Kotak pasir dan keselamatan: apa yang mengekang sesuatu larian hari ini
Rujukan konfigurasi ejen: senarai medan penuh