Orkestrasi

Satu ejen bagus untuk satu perkara. Sesetengah permintaan lebih besar daripada itu: “kaji pasaran untuk X dan tulis dokumen kedudukan”, “hantar ciri ini dari hujung ke hujung”, “audit modul ini dan perbaiki apa yang anda temui”. Satu orkestrasi ialah cara Control Center mengendalikan permintaan sebegitu: seorang orkestrator (biasanya ejen CEO anda) mencadangkan rancangan seluruh pasukan, anda meluluskannya sekali dan satu pematerialan deterministik mengubahnya menjadi pipeline yang melakukan kerja itu.

Ia berada di antara dua cara sedia ada untuk menyiapkan kerja:

Apabila anda mahu…	Gunakan
Serahkan satu tugas kepada satu ejen	Mesej dalam ruang
Kodkan proses yang anda sudah tahu, secara manual	Templat pipeline
Sebut matlamatnya dan biarkan pasukan merangka rancangannya	Satu orkestrasi

Bentuk sesuatu cadangan

Apabila anda memberikan orkestrator satu matlamat, ia mengembalikan satu OrchestrationProposal berstruktur: rancangan bertipe yang boleh disahkan dan dilaksanakan oleh aplikasi, bukan prosa bebas. Sesuatu cadangan mempunyai:

Matlamat: permintaan aras tinggi anda, dinyatakan semula.
Peranan: siapa yang melakukan kerja itu. Setiap peranan sama ada ejen sedia ada yang anda pilih, atau pengambilan baharu yang dicipta oleh orkestrasi semasa kelulusan.
Sub-tiket: kerja itu, dipecahkan kepada DAG tiket.
Kajian (pilihan): fasa kajian yang berjalan dahulu dan menyuap selebihnya.
Perbincangan (pilihan): pusingan terbatas di mana setiap peranan menyiarkan pendirian berstruktur sebelum kerja bermula.
Sintesis: langkah akhir yang menghasilkan dapatan.
Bajet: siling kos yang diisytiharkan.

Di mana anda menyemaknya

Dua permukaan menunjukkan orkestrasi yang sama.

Kad cadangan berada dalam perbualan yang menghasilkan rancangan itu. Ia ialah satu mesej yang dijana semula sepanjang kitaran hayatnya — dicadangkan, melaksanakan, selesai — dengan tindakan luluskan dan batal padanya.

Plan Studio ialah editornya: kanvas DAG, pemeriksa nod, laci semakan dan diff, serta bar kelulusan yang membawa anggaran itu. Ia terbuka sebagai tab editor terus daripada kad itu. Tiada item “Plans” dalam bar sisi secara sengaja; /plans dan /plans/:kind/:id wujud sebagai pautan dalam untuk perkongsian.

Meluluskan adalah khusus pengendali. Tiada alat MCP untuknya: ejen boleh mencadangkan (propose_orchestration), menghantar rancangan (submit_plan), atau mencontohkan playbook (run_playbook), tetapi hanya manusia yang meluluskan. Semakan yang dimulakan oleh ejen juga dihadkan kadarnya oleh tempoh menunggu dua minit, jadi gelung perancangan semula bergabung dan tidak membanjiri suapan anda.

Apa yang boleh anda ubah sebelum meluluskan ialah apa yang didedahkan oleh pemeriksa nod: tukar tajuk atau tulis semula sesuatu sub-tiket, tukar peranan yang memilikinya, ubah suai kebergantungannya, sunting skema outputnya, atau padamkan nod itu terus. Nod struktur (kajian, perbincangan, sintesis) dan nod yang sudah dilaksanakan adalah baca sahaja. Anda tidak boleh menyematkan peranan kepada ejen bernama tertentu, dan anda tidak boleh menyunting bajet, daripada editor itu.

Dua editor pada satu rancangan diselesaikan melalui konkurensi optimistik, bukan penggabungan. Setiap suntingan membawa base_revision yang menjadi asasnya; suntingan yang berdasarkan semakan basi ditolak dengan “the plan moved on” dan bukannya memadam hasil kerja orang lain secara senyap. Memundurkan juga bukan pemadaman — ia menambahkan cadangan lama sebagai semakan baharu, jadi garis masa semakan hanya berkembang.

Anggaran jujur, atau tidak ada langsung

Anggaran pada bar kelulusan dibina daripada sejarah larian selesai sebenar bagi setiap peranan, sebagai julat antara kuartil (p25–p75). Jumlah kos menjumlahkan nod yang boleh dianggar; tempoh ialah laluan kritikal melalui DAG dan bukannya jumlah (cabang selari bertindih).

Sesuatu nod yang peranannya tiada sejarah larian selesai melaporkan sampleSize: 0 dan julat null. Itu dipaparkan sebagai tepat itu — tidak diketahui — dan tidak pernah sebagai nilai titik yang direka, kerana anggaran yang anda tidak boleh percayai lebih buruk daripada tiada anggaran. Apabila sesetengah nod mempunyai sejarah dan sesetengahnya tidak, jumlahnya ditanda sebahagian. Jejari letupan muncul hanya apabila sesuatu nod mengisytiharkan rujukan asal usul symbol atau file; nod tanpa itu kekal “tidak diketahui” dan bukannya menyimpulkan daripada prosa.

Satu kelulusan, kemudian pelaksanaan deterministik

Inilah idea terasnya: ejen merancang; fungsi deterministik melaksanakan. Apabila anda meluluskan, OrchestrationMaterializer, satu fungsi tulen tanpa LLM dan tanpa I/O, menukar cadangan itu menjadi pipeline sebenar. Diberikan cadangan yang sama dan peranan yang diselesaikan yang sama, ia sentiasa menghasilkan DAG yang sama. Ini penting kerana pipeline yang dijana mewarisi segala-galanya yang sudah dilakukan oleh enjin secara percuma: penggantungan dan penyambungan semula merentas mula semula, pemulihan ranap, jumlah kos dan token setiap larian, serta UI butiran larian.

Kelulusan juga mencipta perancah yang diperlukan oleh kerja itu:

mengambil mana-mana peranan yang ditanda baharu (dan merekodkan id ejen yang diambil supaya ranap di pertengahan kelulusan boleh disambung semula tanpa pengambilan berganda)
satu pasukan yang mengelompokkan peranan-peranan itu
satu projek yang memfailkan tiket induk
templat pipeline + larian yang memandu semuanya

Kitaran hayat

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

Status	Maksud
`proposed`	Rancangan sudah sedia dan menunggu satu kelulusan awal daripada anda
`approved`	Anda meluluskannya; pematerialan sedang berjalan (pengambilan, pasukan, projek, pipeline)
`executing`	Pipeline yang dijana sedang berjalan: sub-tiket, perbincangan, kerja
`synthesizing`	Sub-tiket sudah selesai; langkah sintesis sedang menghasilkan dapatan
`completed`	Selesai: tiket induk ditanda lengkap dan dapatan disiarkan dalam ruang yang dikongsi
`failed`	Pematerialan gagal, atau larian pipeline yang dijana gagal
`cancelled`	Anda membatalkannya

Nombor semakan yang monoton menjejaki cadangan itu semasa orkestrator menyemaknya semula selagi ia masih proposed; aplikasi merekodkan semakan mana yang anda luluskan. propose_orchestration menolak sesuatu semakan sebaik sahaja statusnya bukan lagi proposed.

Sesuatu orkestrasi sentiasa dibuka terhadap satu tiket induk dan berkongsi satu ruang perbincangan, jadi keseluruhan usaha boleh dijejaki kepada satu item kerja dan pasukan berbual dalam satu bilik.

Apa yang berlaku apabila ia selesai

Pendengar yang dikekalkan hidup memantau pipeline yang dijana dan memetakan keadaan akhirnya kembali kepada orkestrasi dan tiket induk, jadi penyiapan dan kegagalan muncul di tempat yang anda sudah pantau. Ciri orkestrasi tidak memerlukan enjin pelaksanaan yang tersendiri.

Anda boleh membatalkan sesuatu orkestrasi pada bila-bila masa; pembatalan itu meruntuhkan kerja yang sedang berjalan.

Lihat juga

Pipeline dan automasi: enjin yang menjalankan orkestrasi yang dimaterialkan
Tiket dan perwakilan: tiket induk tempat sesuatu orkestrasi dipautkan
Model ejen: peranan yang diisi atau diambil oleh sesuatu orkestrasi
Jalankan orkestrasi
Bekerja dalam Plan Studio