Orchestráció

Egyetlen ügynök egyetlen dologban jó. Vannak azonban ennél nagyobb kérések: „kutassa fel az X piacát, és írjon pozicionálási dokumentumot”, „szállítsa le ezt a funkciót elejétől a végéig”, „vizsgálja át ezt a modult, és javítsa, amit talál”. Az orchestráció az, ahogy a Control Center ezeket kezeli: egy orchestrátor (rendszerint az Ön CEO-ügynöke) egy egész csapatot érintő tervet javasol, amelyet egyszer hagy jóvá, és amelyből egy determinisztikus materializáló olyan pipeline-t készít, amely elvégzi a munkát.

A munka elvégzésének két meglévő módja közé ékelődik:

Amikor ezt szeretné…	Használja
Egy feladatot adna át egyetlen ügynöknek	Egy üzenetet egy térben
Kézzel kódolná azt a folyamatot, amelyet már ismer	Egy pipeline-sablont
Megmondaná a célt, és a csapatra bízná a tervet	Egy orchestrációt

A javaslat felépítése

Amikor megad egy célt az orchestrátornak, az egy strukturált OrchestrationProposal-t ad vissza: egy típusos tervet, amelyet az alkalmazás validálni és végrehajtani tud, nem szabad szöveges leírást. Egy javaslat a következőket tartalmazza:

Cél: a magas szintű kérése, újrafogalmazva.
Szerepek: kik végzik a munkát. Minden szerep vagy egy Ön által kiválasztott meglévő ügynök, vagy egy új felvétel, amelyet az orchestráció a jóváhagyáskor hoz létre.
Aljegyek: a munka, jegyek DAG-jára bontva.
Kutatás (opcionális): egy kutatási fázis, amely elsőként fut le, és táplálja a többit.
Megbeszélés (opcionális): egy körülhatárolt kör, amelyben minden szerep strukturált álláspontot tesz közzé, mielőtt a munka elkezdődik.
Összegzés: a záró lépés, amely előállítja a szállítandót.
Költségvetés: egy megadott költségplafon.

Hol nézheti át

Két felület mutatja ugyanazt az orchestrációt.

A javaslatkártya abban a beszélgetésben él, amely a tervet létrehozta. Egyetlen üzenet, amely az egész életcikluson át újrarenderelődik — javasolt, végrehajtás, befejezve —, rajta a jóváhagyás és a megszakítás műveletével.

A Plan Studio maga a szerkesztő: DAG-vászon, csomópontvizsgáló, revízió- és diff-fiók, valamint a becslést hordozó jóváhagyási sáv. Közvetlenül abból a kártyából nyílik meg szerkesztőfülként. Az oldalsávban szándékosan nincs „Tervek” elem; a /plans és a /plans/:kind/:id megosztási célú mélyhivatkozásként létezik.

A jóváhagyás kizárólag operátori művelet. Erre nincs MCP-eszköz: egy ügynök javasolhat (propose_orchestration), tervet nyújthat be (submit_plan) vagy playbookot példányosíthat (run_playbook), de jóváhagyni csak ember tud. Az ügynök által kezdeményezett revíziókat emellett egy kétperces várakozási idő is korlátozza, így az újraütemező ciklus összeolvad, ahelyett hogy elárasztaná a hírfolyamát.

A jóváhagyás előtt annyit módosíthat, amennyit a csomópontvizsgáló felfed: átcímezheti vagy átírhatja az aljegyet, megváltoztathatja, melyik szerep birtokolja, átkötözheti a függőségeit, szerkesztheti a kimeneti sémáját, vagy egyenesen törölheti a csomópontot. A strukturális csomópontok (kutatás, megbeszélés, összegzés) és a már végrehajtott csomópontok csak olvashatók. A szerkesztőből nem rendelhet egy szerepet konkrét, névvel ellátott ügynökhöz, és a költségvetést sem szerkesztheti.

Ha két szerkesztő dolgozik egy terven, azt optimalista párhuzamosság-kezelés oldja fel, nem összefésülés. Minden szerkesztés magával hozza a base_revision értéket, amelyre készült; az elavult revízióra épülő szerkesztést a rendszer „a terv közben továbbhaladt” üzenettel utasítja el, ahelyett hogy csendben felülírná valaki másét. A visszatekerés sem törlés — a régebbi javaslatot új revízióként fűzi hozzá, így a revíziók idővonala csak növekszik.

Őszinte becslések — vagy egy sem

A jóváhagyási sávon látható becslés szerepenként a valós, befejezett futások előzményeiből épül fel, interkvartilis (p25–p75) sávként. A költségösszegek az egyes becsülhető csomópontokat összegzik; az időtartam a DAG-on át vezető kritikus út, nem pedig az összeg (a párhuzamos ágak átfedésben vannak).

Az a csomópont, amelynek szerepéhez nincs befejezett futási előzmény, sampleSize: 0 értéket és null tartományokat jelent. Ez pontosan így is jelenik meg — ismeretlenként —, soha nem kitalált pontértékként, mert egy megbízhatatlan becslés rosszabb, mint a becslés hiánya. Ha egyes csomópontoknak van előzményük, másoknak nincs, az összesítés részlegesnek jelölődik. A hatósugár csak akkor jelenik meg, ha egy csomópont symbol vagy file származási hivatkozásokat deklarált; az ilyenekkel nem rendelkező csomópont „ismeretlen” marad, ahelyett hogy a szövegből következtetne.

Egy jóváhagyás, majd determinisztikus végrehajtás

Ez a lényegi gondolat: az ügynök tervez, egy determinisztikus függvény hajt végre. Amikor jóváhagyja, az OrchestrationMaterializer, egy LLM és I/O nélküli tiszta függvény, valódi pipeline-ná alakítja a javaslatot. Ugyanabból a javaslatból és ugyanazokból a feloldott szerepekből mindig ugyanazt a DAG-ot állítja elő. Ez azért fontos, mert a generált pipeline mindent örököl, amit a motor már ingyen nyújt: felfüggesztés és folytatás újraindítások között, összeomlás utáni helyreállítás, futásonkénti költség- és token-összesítések, valamint a futásrészletek felülete.

A jóváhagyás emellett létrehozza a munkához szükséges állványzatot:

felveszi az újként megjelölt szerepeket (és rögzíti a felvett ügynökök azonosítóit, hogy egy jóváhagyás közbeni összeomlás ismétlődő felvételek nélkül folytatódhasson)
egy csapat, amely a szerepeket csoportosítja
egy projekt, amely a szülőjegyet iktatja
a pipeline-sablon + futtatás, amely mindezt vezérli

Az életciklus

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

Állapot	Jelentés
`proposed`	A terv készen áll, és az egyszeri, előzetes jóváhagyására vár
`approved`	Jóváhagyta; a materializálás folyamatban van (felvételek, csapat, projekt, pipeline)
`executing`	A generált pipeline fut: aljegyek, megbeszélés, munka
`synthesizing`	Az aljegyek elkészültek; az összegzés lépése állítja elő a szállítandót
`completed`	Kész: a szülőjegy befejezettként van megjelölve, a szállítandó pedig a közös térben jelenik meg
`failed`	A materializálás sikertelen, vagy a generált pipeline futtatása bukott meg
`cancelled`	Ön megszakította

Egy monoton revíziószám követi a javaslatot, ahogy az orchestrátor módosítja, amíg az még proposed állapotban van; az alkalmazás rögzíti, melyik revíziót hagyta jóvá. A propose_orchestration elutasítja a további revíziókat, amint az állapot már nem proposed.

Az orchestráció mindig egy szülőjegyre horgonyozva nyílik meg, és egyetlen beszélgetési téren osztozik, így a teljes erőfeszítés egyetlen munkaelemig visszakövethető, a csapat pedig egy szobában beszél.

Mi történik, amikor befejeződik

Egy életben tartott figyelő kíséri a generált pipeline-t, és annak végállapotát visszavezeti az orchestrációra és a szülőjegyre, így a befejezés és a hiba ott jelenik meg, ahol egyébként is nézi a dolgokat. Az orchestráció funkciónak nincs szüksége saját végrehajtómotorra.

Az orchestrációt bármikor megszakíthatja; a megszakítás lebontja a folyamatban lévő munkát.

Lásd még

Pipeline-ok és automatizálás: a motor, amelyen a materializált orchestráció fut
Jegyek és delegálás: a szülőjegy, amelyre az orchestráció horgonyzódik
Az ügynökmodell: a szerepek, amelyeket az orchestráció betölt vagy felvesz
Orchestráció futtatása
Munka a Plan Studióban