Lewati ke konten

Delegasikan pekerjaan ke agen

Panduan ini membahas cara memindahkan pekerjaan dari piring Anda ke agen, dan apa yang terjadi ketika para agen saling mengoper pekerjaan.

  1. Buat tiketnya dengan judul dan deskripsi yang cukup tepat untuk dijadikan dasar bekerja.
  2. Tetapkan Penerima tugas-nya ke agen tersebut, agar kepemilikannya tercatat.
  3. Buka (atau buat) sebuah space dan @-mention agen tersebut.
  4. Rujuk tiket itu dengan mention # di pesan Anda — penyusun pesan melengkapi tiket ruang kerja secara otomatis — dan sebutkan apa yang ingin Anda kerjakan.

Agen mengambil pekerjaan itu dari percakapan. Kemajuannya dialirkan ke space tersebut.

  • Pesan Anda, termasuk rujukan tiket yang Anda tandai.
  • Space untuk bekerja dan melapor.
  • Worktree terisolasi dari repo yang tertaut ke ruang kerja.
  • Mode space tersebut, yang mengatur permukaan alat run itu.

Mode adalah properti space, bukan properti tiket — tiket tidak punya mode. Karena itu, satu agen dapat berada dalam mode chat di satu space dan plan di space lain. Pilih mode dari dropdown mode di penyusun pesan (Agent, Plan, atau Orchestrate); review ditetapkan oleh space tinjauan PR dan tidak dapat dipilih. Lihat Mode.

Kontrak keluaran dideklarasikan pada pengiriman, bukan pada tiket: expected_output_schema plus output_contract_mode (secara default strict). Agen memenuhinya dengan memanggil submit_output, yang memvalidasi payload terhadap skema dan menolak payload yang tidak sesuai.

Baik keluaran yang diterima maupun setiap penolakan tercatat di log eksekusi agen. Status tiket itu sendiri tidak tersentuh oleh hal ini — kontrak yang gagal tidak menggagalkan tiketnya.

  • Space — aktivitas agen secara langsung, tampilan utama.
  • Tiket — statusnya, sesuai yang ditetapkan oleh siapa pun yang memindahkannya.
  • Observabilitas → Langsung (/workspaces/<workspace-id>/observability) — daftar agen secara langsung.
  • Observabilitas → Wawasan — log eksekusi, beserta biaya dan durasinya.

Tidak ada layar dasbor; URL ruang kerja tanpa apa pun akan mengalihkan ke Kotak masuk.

Agen yang menemui sub-masalah akan mendelegasikan dengan alat MCP delegate_task. Alat itu membuat tiket anak yang ditetapkan ke agen lain dan — ketika Anda memberikan parent_ticket_id — mencatat rantainya agar pagar pengaman dapat melihatnya.

Dua pagar struktural selalu berjalan di titik penyempitan tiket, tidak pernah melalui instruksi prompt:

  • Batas kedalaman — rantai yang lebih dalam dari 3 hop ditolak.
  • Deteksi siklus — hop kembali ke agen yang sudah ada di rantai ditolak.

Ketika Anda memberikan from_agent_id, dua pagar lagi berjalan (produksi selalu menyediakan port resolver):

  • Plafon otonomi — tingkat efektif penerima delegasi di space tidak boleh melebihi tingkat pemberi delegasi.
  • Amplop anggaran — delegasi membebankan sisa anggaran hard-stop milik pemberi delegasi dan tidak dapat mencetak anggaran baru. Tanpa kebijakan, atau dengan kebijakan tanpa batas, akan lolos.

Penolakan bersifat terang-terangan: alat mengembalikan alasan pagar tersebut apa adanya, sehingga agen yang mendelegasikan melihat persis alasannya. Kolom delegatedByAgentId mencatat siapa yang mendelegasikan, membentuk pohon delegasi.

Batas kedalaman delegasi sebesar 3 ini adalah batas yang berbeda dari batas penyarangan subagen sebesar 2 pada harness bawaan — yang satu membatasi tiket antaragensi, yang lain membatasi subagen di dalam satu run.

Tambahkan mereka sebagai kolaborator pada tiket (peran: penerima tugas, kolaborator, peninjau). Itu hanyalah daftar nama — catatan siapa saja yang terlibat — dan tidak memberi kuasa apa pun dengan sendirinya.

Untuk benar-benar menempatkan para agen dalam percakapan yang sama, tambahkan mereka sebagai peserta dari header space. Mereka kemudian dapat saling @-mention di sana. Lihat Space.

Tidak ada node di palet pipeline yang membuat tiket, sehingga pipeline tidak dapat menyebarkan pekerjaan sebagai tiket yang ditetapkan.

Jalur yang ada adalah orkestrasi: menyetujui proposal akan membuat proyek dan tim, mengompilasi DAG sub-tiket proposal menjadi templat pipeline (satu langkah promptAgent per sub-tiket, bukan satu baris Ticket untuk masing-masing) lalu menjalankan run tersebut. Lihat Jalankan orkestrasi.