Sprawa przeciw magicznej orkiestracji
The graph that looked intelligent
The orchestration diagram was beautiful in the way dangerous diagrams often are. Rounded boxes, graceful arrows, a planner, a researcher, a verifier, a tool executor, a memory layer, a human approval node, and a final response. The demo moved with theatrical confidence. A user asked for an analysis, the planner decomposed the task, tools were called, intermediate notes appeared, and the final answer arrived with the calm of a system that had never met production traffic.
Then the first real exceptions arrived. A tool returned partial data. The planner retried with a different query and lost the earlier reason. The verifier checked style but not the source conflict. Memory brought back an old assumption because it looked relevant. A human approval step approved the final text without seeing the failed branch. The trace existed, but reading it felt like inspecting a suitcase packed by a committee during a fire drill. The graph had not failed dramatically. It had hidden the shape of responsibility.
This is the case against magical orchestration. Not against orchestration itself. Complex AI systems need coordination. They need to call tools, route tasks, manage context, ask humans, recover from failure, split work, and combine evidence. The argument is against the style of orchestration that treats a clever graph or agent loop as a substitute for explicit state, contracts, ownership, limits, and records. Magic is impressive in a demo because it hides the mechanism. Engineering is useful in production because it exposes the mechanism enough to repair it.
AI orchestration is where probability meets workflow. That junction is unforgiving. A model may choose a plan. A tool may return a result. A policy may allow an action. A retry may change context. A human may approve. A downstream system may act. If those transitions are not named, bounded, and recorded, the organisation gets an intelligent-looking system whose behaviour is difficult to reproduce and harder to govern. It is not autonomous. It is just evasive with better branding.
Orchestration is not intelligence dust
The word orchestration can make ordinary engineering sound newly enchanted. A sequence becomes a chain. A conditional becomes a router. A function call becomes a tool. A while loop becomes an agent. A queue becomes memory if the lighting is right. Some of this vocabulary is useful because AI systems do introduce new coordination problems. Some of it is packaging. Packaging is not evil. It becomes expensive when teams forget what is inside the box.
At its core, orchestration is the management of state, decisions, resources, and transitions. What is the task. What is the current state. Which inputs are allowed. Which tool may be called. Which output shape is expected. What happens on failure. Which retries are permitted. Which actions require approval. What evidence must be kept. Which step can be replayed. Which step is irreversible. These questions existed before generative AI. Models make them more important, not obsolete.
Magiczna orkiestracja omija te pytania, pozwalając modelowi lub frameworkowi zbyt wiele wnioskować w czasie działania. Planista decyduje o dekompozycji. Model wybiera narzędzia. Wynik działania narzędzia staje się kontekstem. Następny krok go interpretuje. Pamięć dodaje historię. Weryfikator kiwa głową. Pojawia się ostateczna odpowiedź. To może działać w przypadku zadań eksploracyjnych o niskiej stawce. Jest to kruche, gdy przepływ pracy dotyka rejestrów, pieniędzy, bezpieczeństwa, zgodności, zobowiązań wobec klientów, infrastruktury lub innych systemów, które nie doceniają teatru improwizacji.
Zdyscyplinowany projekt orkiestracji nie usuwa elastyczności. Umieszcza elastyczność w ramach. Model może zaproponować plan, ale wynik planisty ma schemat. System może wywoływać narzędzia, ale narzędzia mają zakresy i budżety. Przepływ pracy może ponawiać próby, ale przyczyny ponowień są klasyfikowane. Pamięć może pomagać, ale autorytatywny stan żyje gdzie indziej. Człowiek może zatwierdzić, ale zatwierdzenie widzi istotne gałęzie i dowody. Elastyczność przetrwa. Tajemnica nie może przejąć steru.
Problem ukrytego stanu
Najczęstszą awarią orkiestracji jest ukryty stan. Stan pojawia się w promptach, notatnikach roboczych, magazynach pamięci, wynikach narzędzi, komunikatach pośrednich, podsumowaniach modelu, buforowanych wynikach, komentarzach ludzi i wewnętrznych mechanizmach frameworka. Każda warstwa zawiera część prawdy. Żadna nie jest trwałym zapisem. Gdy coś pójdzie nie tak, zespół pyta, co system myślał na siódmym kroku. Odpowiedź to kolaż.
Ukryty stan sprawia, że debugowanie jest koszmarem. Model wybrał inne narzędzie, ponieważ wcześniejsze podsumowanie użyło mocniejszego czasownika. Ponowienie pominęło ograniczenie. Element pamięci z poprzedniego zadania wpłynął na plan. Wynik narzędzia został ucięty. Weryfikator widział ostateczną odpowiedź, ale nie odrzuconą gałąź. System zachowywał się wiarygodnie, a wiarygodne zachowanie jest najbardziej irytującym rodzajem do zbadania, ponieważ nie wygląda na zepsute, dopóki nie poznasz brakującego faktu.
Trwały stan zadania powinien być jawny. Powinien obejmować intencję zadania, dozwolony zakres, zbiór źródeł, wersję planu, wywołania narzędzi, wyniki narzędzi, przyczyny ponowień, decyzje ludzi, kontrolę zasad, koszty, limity czasu i zastosowane działania. Nie każda interakcja o niskiej stawce potrzebuje ciężkiego rejestru, ale każda orkiestracja, która może wpłynąć na prawdziwą pracę, potrzebuje modelu stanu wykraczającego poza transkrypt. Transkrypt to użyteczna narracja. To nie jest system operacyjny.
Jawny stan poprawia również projekt produktu. Użytkownicy mogą zobaczyć, czy system planuje, czeka na narzędzie, jest zablokowany przez zasady, prosi o przegląd, ponawia po przejściowym błędzie lub jest gotowy do wprowadzenia zmian. Operatorzy mogą wstrzymać lub wznowić. Deweloperzy mogą testować przejścia. Audytorzy mogą odtworzyć. System staje się mniej magiczny, a bardziej użyteczny, co jest kompromisem, któremu niektóre dema się opierają, a większość zespołów operacyjnych głęboko docenia.
Wywołania narzędzi nie są niewinne
Korzystanie z narzędzi daje systemom AI ręce. To jest użyteczne i niebezpieczne. Czytanie kalendarza, przeszukiwanie dokumentów, odpytywanie bazy danych, wysyłanie wiadomości e-mail, otwieranie zgłoszenia, zmienianie rekordu, wdrażanie kodu lub przekazywanie pieniędzy to nie są równoważne działania. Magiczny orkiestrator może traktować je jak narzędzia na liście. Poważny system traktuje je jako możliwości z zakresami, efektami ubocznymi, uprawnieniami, budżetami i wymogami dowodowymi.
Każde wywołanie narzędzia potrzebuje kontraktu. Dane wejściowe muszą być typowane i walidowane. Dane wyjściowe muszą być sprawdzane. Błędy muszą być klasyfikowane. Efekty uboczne muszą być deklarowane. Idempotencja musi być zrozumiała. Limity czasu muszą być określone. Ponowne próby muszą być bezpieczne. Uprawnienia muszą wynikać z użytkownika, zadania i polityki, a nie z entuzjazmu modelu. System powinien wiedzieć, czy narzędzie tylko odczytuje dane, zapisuje szkic, zmienia rekord, powiadamia osobę czy wyzwala zewnętrzne zobowiązanie. Młotek i przelew bankowy nie powinny mieć tego samego charakteru.
Wynik działania narzędzia również musi być traktowany jako dane wejściowe. Może być częściowy, nieaktualny, nieautoryzowany, niejednoznaczny lub wrogi. Wynik wyszukiwania nie jest dowodem, dopóki system nie zna źródła, świeżości i uprawnień. Wynik z bazy danych może pomijać wiersze ze względu na kontrolę dostępu. Błąd API może zwrócić komunikat, który nie powinien stać się instrukcją. Narzędzie może zawieść grzecznie i nadal zawieść. Orkiestrator nie powinien podawać każdej odpowiedzi narzędzia z powrotem do modelu, jakby zwrócenie tekstu było tym samym co przekazanie prawdy.
Efekty uboczne zasługują na szczególną ostrożność. Plan wygenerowany przez model można wyrzucić. Wysłanego e-maila nie można cofnąć z równą pewnością. Zmieniony rekord może uruchomić systemy zależne. Wdrożenie może wpłynąć na użytkowników. Zwrot może przesunąć środki. Orkiestracja powinna oddzielać propozycję od działania i wymagać wyraźnych bramek dla kroków nieodwracalnych lub o poważnych konsekwencjach. Jeśli system może robić realne rzeczy, potrzebuje czegoś więcej niż pętli agenta. Potrzebuje hamulców, kluczy i kogoś, kto wie, gdzie jest zapasowy.
Ponowne próby to polityka w przebraniu
Ponowne próby wyglądają jak klej inżynieryjny, dopóki orkiestrator AI nie zacznie podejmować decyzji. Jeśli narzędzie zawiedzie, spróbuj ponownie. Jeśli wynik modelu jest źle sformułowany, zapytaj ponownie. Jeśli weryfikator odrzuci odpowiedź, popraw ją. Jeśli plan utknie, zaplanuj go od nowa. To może być rozsądne. Może też zmienić wynik, ukryć niepewność, zwiększyć koszty lub zatrzeć dowody tego, dlaczego pierwsza ścieżka zawiodła. Ponowna próba to nie tylko drugie podejście. To decyzja o tym, jaki rodzaj awarii system może wygładzić.
Polityka ponownych prób powinna być jawna. Przejściowe błędy infrastruktury można ponawiać inaczej niż konflikty polityk. Źle sformułowany JSON można naprawić inaczej niż brakujące dowody. Niska pewność może wywołać przegląd, a nie kolejną próbkę. Konfliktu źródeł nie należy rozwiązywać, prosząc model o bardziej stanowcze brzmienie. Przekroczenie limitu czasu narzędzia nie powinno stać się pozwoleniem na użycie słabszego źródła bez oznaczenia zmiany. System musi wiedzieć, dlaczego ponawia, co jest zachowywane, co się zmienia i kiedy przestać.
Bez tej dyscypliny orkiestracja tworzy grzeczne pętle. System próbuje dalej, bo próbowanie w kodzie jest tanie. Może spalić budżet, zapełnić logi, zdezorientować użytkowników i w końcu wyprodukować odpowiedź, która wygląda lepiej głównie dlatego, że wcześniejsze dowody niestabilności są ukryte. W produkcji pętla, która ukrywa własne nieudane próby, to nie wytrwałość. To amnezja z paskiem postępu.
Ponowne próby powinny tworzyć zapisy. Liczba prób, powód, zmienione dane wejściowe, zmieniony plan, zachowane dowody, koszt, opóźnienie i ostateczne rozstrzygnięcie. To daje operatorom możliwość sprawdzenia, czy przepływ pracy jest zdrowy, czy tylko uporczywy. Pomaga też zdecydować, czy naprawić jakość danych wejściowych, niezawodność narzędzi, formatowanie modelu, jasność polityki czy oczekiwania użytkowników. Ponowna próba bez klasyfikacji to wzruszenie ramion w formie wykonywalnej.
Weryfikacja to nie ozdobny węzeł
Wiele diagramów orkiestracji zawiera weryfikator. Dobrze. Następnie weryfikator ma sprawdzić, czy odpowiedź jest prawdopodobna, poprawnie sformułowana lub zgodna z instrukcjami. Mniej dobrze. Weryfikator, który czyta tylko końcową odpowiedź, może przeoczyć błędy, które mają znaczenie: słabe źródło, zabronione dane wejściowe, nieudane narzędzie, konflikt zasad, niebezpieczne działanie lub plan zmieniony bez zgody. Może wypolerować frontowe drzwi, podczas gdy kuchnia płonie.
Weryfikacja powinna być powiązana z kontraktami i konsekwencjami. Jeśli zadaniem jest ekstrakcja, weryfikuj na podstawie fragmentów źródła. Jeśli zadaniem jest klasyfikacja, weryfikuj dozwolone etykiety i dowody. Jeśli zadaniem jest wykonanie narzędzia, weryfikuj uprawnienia, argumenty, skutki uboczne i wycofanie. Jeśli zadaniem jest wsparcie decyzyjne, weryfikuj zasady, aktualność źródła, niepewność i wymagania dotyczące przeglądu. Jeśli zadaniem jest komunikacja, weryfikuj odbiorców, twierdzenia, ton i ujawnienia. Ogólny weryfikator jest lepszy niż żaden. Weryfikator specyficzny dla zadania jest lepszy niż teatr.
Część weryfikacji powinna być deterministyczna. Schematy, dozwolone wartości, uprawnienia, budżety, progi, aktualność źródła i wymagane pola nie potrzebują poetyckiego osądu modelu. Używaj reguł tam, gdzie reguły są precyzyjne. Używaj modeli tam, gdzie niejednoznaczność jest realna. Używaj ludzi tam, gdzie konsekwencje i sporne znaczenie wymagają odpowiedzialności. Magiczna orkiestracja często prosi model o weryfikację innego modelu, ponieważ wydaje się to symetryczne. Symetria jest przyjemna na diagramach architektury. Nie jest automatycznie kontrolą.
Weryfikator powinien widzieć potrzebny ślad. Sam końcowy tekst rzadko wystarcza. Potrzebuje danych wejściowych, zestawu źródeł, wyników narzędzi, nieudanych prób, transformacji, kontroli zasad i planowanego działania. Powinien też mieć uprawnienia do blokowania, żądania większej liczby dowodów, kierowania do przeglądu przez człowieka lub oznaczania ograniczeń. Weryfikator, który nie może zatrzymać przepływu pracy, jest recenzentem w przebraniu.
Pamięć nie powinna udawać autorytetu
Pamięć agenta jest przydatna, gdy przenosi preferencje, wcześniejszy kontekst i wiedzę o powtarzających się zadaniach. Jest niebezpieczna, gdy udaje autorytatywny stan. Zapamiętana preferencja to nie zasada. Wcześniejsza odpowiedź to nie zapis. Podsumowanie sprawy to nie sprawa. Udany wcześniejszy plan nie dowodzi, że następne zadanie pozwala na te same narzędzia. Pamięć pomaga w ciągłości. Nie powinna pozwalać na przemycanie wczorajszego autorytetu do dzisiaj.
Pamięć potrzebuje typów. Preferencja osobista, stan zadania, zasady organizacyjne, dowody źródłowe, wyuczony wzorzec, zapisany wynik narzędzia i decyzja historyczna to różne rzeczy. Potrzebują różnych zakresów, terminów ważności, uprawnień i sposobów wyświetlania. Jeśli orkiestrator po prostu pobiera istotne wspomnienia i dodaje je do kontekstu, trafność staje się jedyną bramą. Trafność to nie uprawnienie. Prywatna notatka może być istotna. Nadal może być zabroniona.
Pamięć potrzebuje również usuwania i korygowania. Błędne założenie nie powinno przetrwać tylko dlatego, że kiedyś było przydatne. Tymczasowy stan projektu powinien wygasnąć. Poprawka użytkownika powinna obowiązywać w określonym zakresie. Zmiana zasad powinna unieważnić starą pamięć. Podsumowanie wygenerowane przez model nie powinno stać się skrótem zastępującym źródło pierwotne. System powinien pokazywać, jaka pamięć wpłynęła na plan, i pozwalać użytkownikom ją kwestionować. W przeciwnym razie pamięć staje się uprzejmym nawiedzeniem.
Zasada jest prosta: autorytatywny stan żyje w zarządzanych magazynach. Pamięć może wspierać planowanie, ale nie powinna po cichu decydować. Jeśli orkiestrator używa pamięci, zapisz, która pamięć, dlaczego była dozwolona i jak wpłynęła na plan. Wydaje się to ciężkie tylko wtedy, gdy pamięć wykonuje pracę o konsekwencjach. Jeśli pamięć wykonuje pracę o konsekwencjach, ciężar jest właśnie o to chodzi.
Prostota bije magię częściej, niż zespoły się spodziewają
Nie każdy przepływ pracy z AI potrzebuje agentów. Niektóre potrzebują deterministycznego potoku z jednym krokiem modelu. Niektóre potrzebują wyszukiwania, klasyfikatora i kolejki przeglądu przez człowieka. Niektóre potrzebują formularza, który wywołuje model w celu przygotowania szkicu. Niektóre potrzebują oceny wsadowej. Niektóre potrzebują planisty. Niektóre potrzebują użycia narzędzi w wielu krokach. Architektura powinna wynikać z zadania, a nie z obecnego entuzjazmu dla diagramów z agentami.
Nudna alternatywa często wygrywa. Stałą sekwencję łatwiej przetestować niż otwartą pętlę. Typowana brama narzędzi jest bezpieczniejsza niż swobodny wybór narzędzi. Kolejka z jawnymi stanami jest łatwiejsza w obsłudze niż rekurencyjny agent. Regułowa ochrona jest tańsza niż modelowy sędzia, gdy reguła jest jasna. Ścieżka eskalacji do człowieka jest lepsza niż kolejna ponowna próba, gdy konsekwencje są wysokie. To nie są stanowiska przeciw AI. To stanowiska za systemem.
Istnieje kompromis. Bardziej elastyczna orkiestracja może poradzić sobie z niejednoznacznością i nieoczekiwanymi ścieżkami. Zwiększa też wariancję, ciężar dowodów, koszt i złożoność debugowania. Bardziej jawna orkiestracja może wydawać się sztywna. Poprawia też powtarzalność, odpowiedzialność i odzyskiwanie po błędach. Właściwy punkt zależy od niejednoznaczności zadania, konsekwencji, wolumenu i tolerancji na błędy. Magiczne myślenie udaje, że elastyczny koniec daje wszystko za darmo. Produkcja wysyła rachunek później, z pozycjami.
Przydatne pytanie projektowe brzmi: co nigdy nie powinno być wybierane przez model. Autorytet źródła. Uprawnienia użytkownika. Limity budżetu. Nieodwracalne działania. Obowiązki przechowywania. Podstawa prawna. Progi bezpieczeństwa. Część z nich może być proponowana lub wyjaśniana przez modele. Nie powinny być przez nie po cichu ustalane. Model może pomóc w nawigacji po przepływie pracy. Nie powinien stać się konstytucją tylko dlatego, że wygodnie było umieścić wszystko w kontekście.
Projektuj orkiestrację jako model operacyjny
Poważna orkiestracja zaczyna się od kontraktu zadania. Jaki jest cel. Jakie dane są dozwolone. Jakie wyniki są akceptowalne. Które narzędzia mogą być używane. Które działania są zabronione. Jaki budżet obowiązuje. Jakie opóźnienie jest tolerowane. Jakie dowody muszą być zachowane. Jakie role ludzkie istnieją. Jakie stany awarii są możliwe. Jakie ścieżki odzyskiwania istnieją. Jeśli zespół nie potrafi odpowiedzieć na te pytania, nie potrzebuje bardziej magicznego grafu. Potrzebuje jaśniejszego zadania.
Następnie zdefiniuj przejścia stanów. Zaplanowano, oczekiwanie na dane wejściowe, pobieranie, oczekiwanie na narzędzie, błąd narzędzia, konflikt dowodów, zablokowano przez politykę, przegląd przez człowieka, zatwierdzono, zastosowano, skompensowano, anulowano. Te stany mogą brzmieć przyziemnie, bo takie są. Pozwalają na obsługę systemu. Pozwalają człowiekowi wiedzieć, czy czekać, interweniować, zatwierdzać czy naprawiać. Pozwalają testom potwierdzać zachowanie. Pozwalają incydentom zaczynać się od faktów, a nie od wrażeń.
Następnie zdefiniuj granice. Modele przygotowują plany. Bramy wykonują narzędzia. Reguły egzekwują precyzyjne ograniczenia. Weryfikatory sprawdzają kontrakty. Ludzie decydują o spornych konsekwencjach. Logi zachowują dowody. Kolejki obsługują opóźnienia. Pamięć masowa przechowuje trwały stan. Każda granica powinna być na tyle nudna, aby można ją było wyjaśnić. Jeśli model robi kilka z tych rzeczy, bo tak było łatwiej, nazwij ryzyko i zdecyduj, czy zadanie ma na tyle niską stawkę, aby to tolerować. Czasami tak jest. Wiele wewnętrznych asystentów może być lekkich. Problem polega na udawaniu, że lekki projekt jest fundamentem automatyzacji o wysokich konsekwencjach.
Wreszcie awaria testu. Narzędzie zwraca częściowe dane. Źródła są sprzeczne. Model generuje nieprawidłowe dane wyjściowe. Pamięć jest nieaktualna. Użytkownik nie ma uprawnień. Osiągnięto limit kosztów. Recenzja człowieka jest niedostępna. Sieć jest wolna. Plan zmienia się po zatwierdzeniu. Działanie częściowo się udaje. Jeśli orkiestrator nie potrafi powiedzieć, co dzieje się w tych przypadkach, graf jest tylko dekoracją. Może to być nadal piękny graf. Postaw go przy roślinie, nie przy produkcji.
Lekcja
Argument przeciwko magicznej orkiestracji jest argumentem za dyscypliną inżynierską. Systemy AI potrzebują koordynacji, a modele mogą uczynić koordynację bardziej adaptacyjną. Ale adaptacja bez jawnego stanu, kontraktów narzędzi, polityki ponawiania, weryfikacji, granic pamięci, bramek działań i ścieżek odzyskiwania nie jest inteligencją. To system, który wymaga od przyszłych operatorów odkrycia jego projektu poprzez czytanie śladów po tym, jak wydarzyło się coś kosztownego.
Dobra orkiestracja jest mniej mistyczna, a bardziej użyteczna. Nazywa stany. Ogranicza narzędzia. Rejestruje dowody. Oddziela propozycję od działania. Klasyfikuje ponowienia. Weryfikuje zgodność z kontraktami zadań. Traktuje pamięć jako pomocniczą, nie autorytatywną. Daje ludziom stany podlegające przeglądowi zamiast nieprzejrzystych transkryptów. Wybiera proste potoki, gdy proste potoki wystarczą. Dodaje agentów tam, gdzie niejednoznaczność uzasadnia koszt operacyjny.
Magia ukrywa mechanizm. Poważna AI potrzebuje mechanizmów, które można kontrolować, wstrzymywać, poprawiać i ulepszać. Celem nie jest usunięcie zachwytu z oprogramowania. Celem jest trzymanie zachwytu z dala od raportu o incydencie.