Orkiestracja

Pojedynczy agent jest dobry w jednej rzeczy. Niektóre prośby są większe: „zbadaj rynek produktu X i napisz dokument pozycjonujący”, „dowieź tę funkcję od początku do końca”, „przeaudytuj ten moduł i napraw, co znajdziesz”. Orkiestracja to sposób, w jaki Control Center radzi sobie z takimi zadaniami: orkiestrator (zwykle Twój agent CEO) proponuje plan całego zespołu, zatwierdzasz go raz, a deterministyczny materializator zamienia go w potok, który wykonuje pracę.

Znajduje się między dwoma istniejącymi sposobami wykonywania pracy:

Jeśli chcesz…	Użyj
Przekazać jedno zadanie jednemu agentowi	Wiadomości w przestrzeni
Zapisać ręcznie proces, który już znasz	Szablonu potoku
Podać cel i pozwolić zespołowi ustalić plan	Orkiestracji

Kształt propozycji

Gdy przekażesz orkiestratorowi cel, zwraca on ustrukturyzowaną OrchestrationProposal: typowany plan, który aplikacja może zwalidować i wykonać, a nie swobodny tekst. Propozycja zawiera:

Cel: Twoja ogólna prośba, przeformułowana.
Role: kto wykonuje pracę. Każda rola to albo istniejący agent, którego wybierasz, albo nowe zatrudnienie, które orkiestracja tworzy po zatwierdzeniu.
Zgłoszenia podrzędne: praca podzielona na graf DAG zgłoszeń.
Badanie (opcjonalne): faza badania, która uruchamia się pierwsza i zasila resztę.
Dyskusja (opcjonalna): ograniczona runda, w której każda rola publikuje ustrukturyzowane stanowisko, zanim rozpocznie się praca.
Synteza: krok końcowy, w którym powstaje rezultat.
Budżet: zadeklarowany pułap kosztów.

Gdzie ją przeglądasz

Dwie powierzchnie pokazują tę samą orkiestrację.

Karta propozycji znajduje się w rozmowie, w której powstał plan. To jedna wiadomość, która renderuje się ponownie przez cały cykl życia — zaproponowana, wykonywana, ukończona — z akcjami zatwierdzenia i anulowania.

Plan Studio to edytor: kanwa DAG, inspektor węzłów, szuflada wersji i diffów oraz pasek zatwierdzania z szacowanym kosztem. Otwiera się jako karta edytora bezpośrednio z tej karty. W panelu bocznym celowo nie ma pozycji „Plany”; /plans i /plans/:kind/:id istnieją jako linki bezpośrednie do udostępniania.

Zatwierdzanie jest dostępne tylko dla operatora. Nie ma do tego narzędzia MCP: agent może zaproponować orkiestrację (propose_orchestration), przesłać plan (submit_plan) lub utworzyć instancję playbooka (run_playbook), ale tylko człowiek zatwierdza. Wersje inicjowane przez agenta są dodatkowo ograniczane dwuminutowym odstępem, dzięki czemu pętla replanowania scala się, zamiast zalewać Twój kanał.

To, co możesz zmienić przed zatwierdzeniem, odpowiada temu, co udostępnia inspektor węzłów: zmienić tytuł lub treść zgłoszenia podrzędnego, zmienić rolę, do której należy, przepiąć jego zależności, edytować jego schemat wyjścia lub całkowicie usunąć węzeł. Węzły strukturalne (badanie, dyskusja, synteza) oraz węzły, które już się wykonały, są tylko do odczytu. W edytorze nie możesz przypiąć roli do konkretnego nazwanego agenta ani edytować budżetu.

Dwie osoby edytujące jeden plan rozwiązuje optymistyczna współbieżność, a nie scalanie. Każda edycja niesie ze sobą base_revision, względem którego została wykonana; edycja oparta na nieaktualnej wersji jest odrzucana z komunikatem „plan się zmienił”, zamiast po cichu nadpisywać cudzą pracę. Cofnięcie również nie jest usunięciem — dołącza starszą propozycję jako nową wersję, więc os czasu wersji tylko rośnie.

Uczciwe szacunki albo żadne

Szacunek na pasku zatwierdzania powstaje na podstawie rzeczywistej historii ukończonych uruchomień dla każdej roli, jako pasmo międzykwartylowe (p25–p75). Koszt całkowity sumuje węzły, które da się oszacować; czas trwania to ścieżka krytyczna przez graf DAG, a nie suma (równoległe gałęzie nakładają się na siebie).

Węzeł, którego rola nie ma historii ukończonych uruchomień, zgłasza sampleSize: 0 i puste zakresy. Jest to renderowane dokładnie jako to — nieznane — nigdy jako wymyślona wartość punktowa, bo szacunek, któremu nie możesz zaufać, jest gorszy niż brak szacunku. Gdy część węzłów ma historię, a część nie, suma jest oznaczana jako częściowa. Zasięg zmian pojawia się tylko wtedy, gdy węzeł zadeklarował odwołania pochodzenia symbol lub file; węzeł bez nich pozostaje „nieznany”, zamiast być wnioskowany z tekstu.

Jedno zatwierdzenie, a potem deterministyczne wykonanie

To jest sedno: agent planuje; deterministyczna funkcja wykonuje. Gdy zatwierdzasz, OrchestrationMaterializer — czysta funkcja bez LLM i bez wejścia/wyjścia — zamienia propozycję w prawdziwy potok. Dla tej samej propozycji i tych samych obsadzonych ról zawsze tworzy ten sam graf DAG. Ma to znaczenie, bo wygenerowany potok dziedziczy wszystko, co silnik już robi za darmo: wstrzymywanie i wznawianie po restartach, odzyskiwanie po awarii, zbiorcze podsumowania kosztów i tokenów na uruchomienie oraz interfejs szczegółów uruchomienia.

Zatwierdzenie tworzy też rusztowanie, którego potrzebuje praca:

zatrudnia role oznaczone jako nowe (i zapisuje identyfikatory zatrudnionych agentów, aby awaria w trakcie zatwierdzania mogła zostać wznowiona bez duplikowania zatrudnień)
zespół grupujący role
projekt, w którym składane jest zgłoszenie nadrzędne
szablon potoku i uruchomienie, które napędzają całość

Cykl życia

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

Status	Znaczenie
`proposed`	Plan jest gotowy i czeka na Twoje jednorazowe zatwierdzenie
`approved`	Zatwierdzono go; trwa materializacja (zatrudnienia, zespół, projekt, potok)
`executing`	Wygenerowany potok działa: zgłoszenia podrzędne, dyskusja, praca
`synthesizing`	Zgłoszenia podrzędne są gotowe; krok syntezy tworzy rezultat
`completed`	Gotowe: zgłoszenie nadrzędne jest oznaczone jako ukończone, a rezultat opublikowany we wspólnej przestrzeni
`failed`	Materializacja nie powiodła się albo uruchomienie wygenerowanego potoku nie powiodło się
`cancelled`	Anulowano

Monotoniczny numer wersji śledzi propozycję, gdy orkiestrator ją zmienia, dopóki jej status to wciąż proposed; aplikacja zapisuje, którą wersję zatwierdzono. propose_orchestration odrzuca zmianę wersji, gdy status nie jest już równy proposed.

Orkiestracja zawsze otwiera się względem zgłoszenia nadrzędnego i korzysta z jednej przestrzeni dyskusji, dzięki czemu cały wysiłek można prześledzić do jednego elementu pracy, a zespół rozmawia w jednym miejscu.

Co się dzieje, gdy się zakończy

Utrzymywany przy życiu nasłuch obserwuje wygenerowany potok i odwzorowuje jego stan końcowy z powrotem na orkiestrację i zgłoszenie nadrzędne, dzięki czemu ukończenie i niepowodzenie pojawiają się w miejscach, które już obserwujesz. Funkcja orkiestracji nie potrzebuje własnego silnika wykonawczego.

Orkiestrację możesz anulować w dowolnym momencie; anulowanie usuwa wykonywaną w danym momencie pracę.

Zobacz też

Potoki i automatyzacja: silnik, na którym działa zmaterializowana orkiestracja
Zgłoszenia i delegowanie: zgłoszenie nadrzędne, do którego zakotwiczona jest orkiestracja
Model agentów: role, które orkiestracja obsadza lub zatrudnia
Uruchom orkiestrację
Pracuj w Plan Studio