Případ proti magické orchestraci
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.
Magická orchestrace se těmto otázkám vyhýbá tím, že nechává model nebo framework odvozovat příliš mnoho za běhu. Plánovač rozhoduje o rozkladu. Model si vybírá nástroje. Výstup nástroje se stává kontextem. Další krok jej interpretuje. Paměť přidává historii. Verifikátor přikývne. Objeví se konečná odpověď. To může fungovat u nenáročných průzkumných úloh. Je to křehké, když pracovní postup zasahuje do záznamů, peněz, bezpečnosti, compliance, závazků vůči zákazníkům, infrastruktury nebo jiných systémů, které nemají rády improvizační divadlo.
Disciplinovaný návrh orchestrace flexibilitu neodstraňuje. Uvádí ji do kolejí. Model může navrhnout plán, ale výstup plánovače má schéma. Systém může volat nástroje, ale nástroje mají rozsahy a rozpočty. Pracovní postup se může opakovat, ale důvody opakování jsou klasifikovány. Paměť může pomáhat, ale autoritativní stav žije jinde. Člověk může schvalovat, ale schválení vidí relevantní větve a důkazy. Flexibilita přežije. Záhada nesmí řídit.
Problém skrytého stavu
Nejčastějším selháním orchestrace je skrytý stav. Stav se objevuje ve výzvách, pomocných poznámkách, úložištích paměti, výstupech nástrojů, mezilehlých zprávách, shrnutích modelu, uložených výsledcích, lidských komentářích a interních částech frameworku. Každá vrstva obsahuje částečnou pravdu. Žádná není trvalým záznamem. Když se něco pokazí, tým se ptá, čemu systém věřil v kroku sedm. Odpovědí je koláž.
Skrytý stav dělá z ladění utrpení. Model si vybral jiný nástroj, protože dřívější shrnutí použilo silnější sloveso. Opakování vynechalo omezení. Položka paměti z předchozí úlohy ovlivnila plán. Výsledek nástroje byl zkrácen. Verifikátor viděl konečnou odpověď, ale ne zamítnutou větev. Systém se choval věrohodně a věrohodné chování je nejotravnější druh vyšetřování, protože odmítá vypadat rozbitě, dokud neznáte chybějící skutečnost.
Trvalý stav úlohy by měl být explicitní. Měl by zahrnovat záměr úlohy, povolený rozsah, zdrojovou sadu, verzi plánu, volání nástrojů, výstupy nástrojů, důvody opakování, lidská rozhodnutí, kontroly politik, náklady, časové limity a provedené akce. Ne každá nenáročná interakce potřebuje těžkou evidenci, ale každá orchestrace, která může ovlivnit skutečnou práci, potřebuje model stavu nad rámec přepisu. Přepis je užitečné vyprávění. Není to operační systém.
Explicitní stav také zlepšuje návrh produktu. Uživatelé vidí, zda systém plánuje, čeká na nástroj, je blokován politikou, žádá o kontrolu, opakuje po přechodné chybě nebo je připraven provést změny. Operátoři mohou pozastavit nebo obnovit. Vývojáři mohou testovat přechody. Auditoři mohou přehrávat. Systém se stává méně magickým a užitečnějším, což je kompromis, kterému některé demosystémy odolávají a který většina provozních týmů hluboce oceňuje.
Volání nástrojů není nevinné
Používání nástrojů dává systémům AI ruce. To je užitečné a nebezpečné. Čtení kalendáře, prohledávání dokumentů, dotazování do databáze, odeslání e-mailu, založení tiketu, změna záznamu, nasazení kódu nebo převod peněz nejsou rovnocenné akce. Magický orchestrátor je může považovat za nástroje v seznamu. Seriózní systém je považuje za schopnosti s rozsahy, vedlejšími účinky, oprávněními, rozpočty a požadavky na důkazy.
Každé volání nástroje potřebuje kontrakt. Vstupy musí být typované a validované. Výstupy musí být kontrolované. Chyby musí být klasifikované. Vedlejší účinky musí být deklarované. Idempotence musí být pochopená. Časové limity musí být ohraničené. Opakované pokusy musí být bezpečné. Oprávnění musí být odvozena od uživatele, úkolu a politiky, ne od nadšení modelu. Systém by měl vědět, jestli nástroj pouze čte, zapisuje návrh, mění záznam, upozorňuje osobu nebo spouští externí závazek. Kladivo a bankovní převod by neměly sdílet stejnou atmosféru.
Výstup nástroje je také třeba považovat za vstup. Může být částečný, zastaralý, neoprávněný, nejednoznačný nebo nepřátelský. Výsledek vyhledávání není důkaz, dokud systém nezná zdroj, aktuálnost a oprávnění. Výsledek databáze může vynechat řádky kvůli řízení přístupu. Chyba API může vrátit zprávu, která by se neměla stát instrukcí. Nástroj může selhat zdvořile a přesto selhat. Orchestrátor nesmí krmit každou odpověď nástroje zpět do modelu, jako by vrácení textu bylo totéž co sdělení pravdy.
Vedlejší účinky si zaslouží zvláštní opatrnost. Plán vytvořený modelem lze zahodit. Odeslaný e-mail nelze odeslat zpět se stejnou jistotou. Změněný záznam může spustit navazující systémy. Nasazení může ovlivnit uživatele. Vrácení peněz může přesunout finance. Orchestrace by měla oddělit návrh od akce a vyžadovat explicitní brány pro nevratné nebo závažné kroky. Pokud systém může dělat skutečné věci, potřebuje víc než smyčku agenta. Potřebuje brzdy, klíče a někoho, kdo ví, kde je rezerva.
Opakování je politika v přestrojení
Opakování vypadá jako technické lepidlo, dokud orchestrátor s umělou inteligencí nezačne dělat rozhodnutí. Pokud nástroj selže, opakuj. Pokud je výstup modelu chybný, zeptej se znovu. Pokud ověřovač odmítne odpověď, reviduj. Pokud se plán zasekne, naplánuj znovu. To může být rozumné. Může to také změnit výsledek, skrýt nejistotu, zvýšit náklady nebo vymazat důkazy o tom, proč první cesta selhala. Opakování není jen druhý pokus. Je to rozhodnutí o tom, jaký druh selhání smí systém zahladit.
Politika opakování by měla být explicitní. Přechodné chyby infrastruktury lze opakovat jinak než konflikty politik. Chybný JSON lze opravit jinak než chybějící důkazy. Nízká jistota může spustit revizi spíše než další vzorek. Konflikt zdrojů by se neměl řešit tím, že model požádáme, aby zněl rozhodněji. Časový limit nástroje by se neměl stát oprávněním použít slabší zdroj bez označení změny. Systém potřebuje vědět, proč opakuje, co je zachováno, co se mění a kdy přestat.
Bez této disciplíny vytváří orchestrace zdvořilé smyčky. Systém se pořád snaží, protože snažení je v kódu levné. Může spálit rozpočet, zaplnit logy, zmást uživatele a nakonec vytvořit odpověď, která vypadá lépe hlavně proto, že dřívější důkazy nestability jsou skryté. V produkci není smyčka, která skrývá vlastní neúspěšné pokusy, vytrvalost. Je to amnézie s ukazatelem průběhu.
Opakování by mělo vytvářet záznamy. Počet pokusů, důvod, změněné vstupy, změněný plán, zachované důkazy, náklady, latence a konečné vyřízení. To dává provozovatelům možnost vidět, jestli je pracovní postup zdravý nebo jen vytrvalý. Pomáhá to také rozhodnout, jestli opravit kvalitu vstupů, spolehlivost nástrojů, formátování modelu, jasnost politik nebo očekávání uživatelů. Opakování bez klasifikace je pokrčení ramen v spustitelné podobě.
Ověřování není dekorativní uzel
Mnoho diagramů orchestrace obsahuje ověřovací prvek. To je dobře. Pak je ale ověřovací prvek požádán, aby zkontroloval, zda je odpověď věrohodná, správně strukturovaná nebo v souladu s pokyny. To už je méně dobré. Ověřovací prvek, který čte pouze konečnou odpověď, může přehlédnout chyby, na kterých záleží: slabý zdroj, zakázaný vstup, selhání nástroje, konflikt pravidel, nebezpečnou akci nebo plán, který se změnil bez schválení. Může vyleštit přední dveře, zatímco v kuchyni hoří.
Ověřování by mělo být vázáno na kontrakty a důsledky. Pokud je úkolem extrakce, ověřujte proti zdrojovým částem. Pokud je úkolem klasifikace, ověřujte povolené štítky a důkazy. Pokud je úkolem spuštění nástroje, ověřujte oprávnění, argumenty, vedlejší účinky a vrácení změn. Pokud je úkolem podpora rozhodování, ověřujte pravidla, aktuálnost zdrojů, nejistotu a požadavky na přezkum. Pokud je úkolem komunikace, ověřujte publikum, tvrzení, tón a zveřejnění. Obecný ověřovací prvek je lepší než žádný. Ověřovací prvek specifický pro daný úkol je lepší než divadlo.
Část ověřování by měla být deterministická. Schémata, povolené hodnoty, oprávnění, rozpočty, prahové hodnoty, aktuálnost zdrojů a povinná pole nepotřebují básnické úsudky modelu. Používejte pravidla tam, kde jsou pravidla jasná. Používejte modely tam, kde je nejednoznačnost skutečná. Používejte lidi tam, kde důsledky a sporný význam vyžadují odpovědnost. Kouzelná orchestrace často žádá model, aby ověřoval jiný model, protože to působí symetricky. Symetrie je příjemná v architektonických diagramech. Automaticky to ale není kontrola.
Ověřovací prvek by měl vidět stopu, kterou potřebuje. Samotný konečný text obvykle nestačí. Potřebuje vstupy, sadu zdrojů, výstupy nástrojů, neúspěšné pokusy, transformace, kontroly pravidel a plánovanou akci. Měl by mít také pravomoc blokovat, vyžádat si další důkazy, postoupit k lidskému přezkumu nebo označit omezení. Ověřovací prvek, který nemůže zastavit pracovní postup, je recenzent ve slavnostním úboru.
Paměť by neměla předstírat autoritu
Paměť agenta je užitečná, když nese preference, předchozí kontext a znalosti o opakujících se úkolech. Je nebezpečná, když předstírá autoritativní stav. Zapamatovaná preference není pravidlo. Předchozí odpověď není záznam. Shrnutí případu není případ. Úspěšný minulý plán není důkaz, že další úkol povoluje stejné nástroje. Paměť pomáhá kontinuitě. Nemělo by jí být dovoleno propašovat včerejší autoritu do dneška.
Paměť potřebuje typy. Osobní preference, stav úkolu, organizační pravidla, důkazy ze zdrojů, naučený vzor, uložený výsledek nástroje a historické rozhodnutí jsou různé věci. Potřebují různé rozsahy, dobu platnosti, oprávnění a zobrazení. Pokud orchestrátor jednoduše načte relevantní vzpomínky a přidá je do kontextu, relevance se stane jedinou bránou. Relevance není oprávnění. Soukromá poznámka může být relevantní. Přesto může být zakázaná.
Paměť také potřebuje mazání a opravy. Nesprávný předpoklad by neměl přetrvávat jen proto, že byl jednou užitečný. Dočasná podmínka projektu by měla vypršet. Oprava od uživatele by se měla uplatnit v definovaném rozsahu. Změna pravidel by měla zneplatnit starou paměť. Shrnutí vytvořené modelem by se nemělo stát zkratkou, která nahrazuje primární zdroj. Systém by měl ukázat, jaká paměť ovlivnila plán, a umožnit uživatelům ji zpochybnit. Jinak se paměť stane zdvořilým strašením.
Pravidlo je jednoduché: autoritativní stav žije v řízených úložištích. Paměť může pomáhat při plánování, ale neměla by tiše rozhodovat. Pokud orchestrátor paměť používá, zaznamenejte, která paměť to byla, proč byla povolena a jak ovlivnila plán. Připadá to těžkopádné, jen pokud paměť dělá důslednou práci. Pokud paměť dělá důslednou práci, těžkopádnost je přesně to, oč jde.
Jednoduchost poráží kouzla častěji, než týmy čekají
Ne každý pracovní postup s AI potřebuje agenty. Některé potřebují deterministický pipeline s jedním krokem modelu. Některé potřebují vyhledávání, klasifikátor a frontu na lidskou kontrolu. Některé potřebují formulář, který zavolá model pro návrh textu. Některé potřebují dávkové vyhodnocení. Některé potřebují plánovač. Některé potřebují použití nástrojů ve více krocích. Architektura by měla následovat úkol, ne současné nadšení pro diagramy s agenty.
Nudná alternativa často vítězí. Pevná posloupnost se testuje snadněji než otevřená smyčka. Typově zabezpečená brána nástrojů je bezpečnější než volný výběr nástrojů. Fronta s explicitními stavy se provozuje snadněji než rekurzivní agent. Pravidlový strážce je levnější než modelový rozhodčí, když je pravidlo jasné. Cesta k lidské eskalaci je lepší než další pokus, když jsou důsledky vysoké. Toto nejsou proti-AI postoje. Jsou to postoje pro systém.
Existuje kompromis. Flexibilnější orchestrace zvládne nejednoznačnost a neočekávané cesty. Také zvyšuje variabilitu, nároky na důkazy, náklady a složitost ladění. Explicitnější orchestrace může působit rigidně. Také zlepšuje reprodukovatelnost, vlastnictví a zotavení. Správný bod závisí na nejednoznačnosti úkolu, důsledcích, objemu a toleranci k selhání. Magické myšlení předstírá, že flexibilní konec dá vše zadarmo. Produkce pošle účet později, s položkami.
Užitečná designová otázka zní: co by model nikdy neměl volit. Autorita zdroje. Oprávnění uživatelů. Rozpočtové limity. Nevratné akce. Povinnosti uchovávání. Právní základ. Bezpečnostní prahy. Některé z nich mohou modely navrhovat nebo vysvětlovat. Neměly by je však tiše nastavovat. Model může pomoci orientovat se v pracovním postupu. Neměl by se stát ústavou jen proto, že bylo pohodlné dát vše do kontextu.
Navrhněte orchestraci jako provozní model
Vážná orchestrace začíná kontraktem úkolu. Jaký je cíl. Jaká data jsou povolena. Jaké výstupy jsou přijatelné. Které nástroje lze použít. Které akce jsou zakázané. Jaký rozpočet platí. Jaká latence je tolerovatelná. Jaké důkazy musí být uchovány. Jaké lidské role existují. Jaké stavy selhání jsou možné. Jaké cesty zotavení existují. Pokud tým na tyto otázky neumí odpovědět, nepotřebuje magičtější graf. Potřebuje jasnější úkol.
Pak definujte přechody stavů. Naplánováno, čeká na vstup, vyhledává se, nástroj čeká, nástroj selhal, konflikt důkazů, politika blokuje, lidská kontrola, schváleno, aplikováno, kompenzováno, zrušeno. Tyto stavy mohou znít všedně, protože jsou. Umožňují systém provozovat. Umožňují člověku vědět, zda čekat, zasáhnout, schválit nebo opravit. Umožňují testům ověřovat chování. Umožňují incidentům začínat od faktů místo od dojmů.
Pak definujte hranice. Modely navrhují plány. Brány spouštějí nástroje. Pravidla vynucují přesná omezení. Ověřovače kontrolují kontrakty. Lidé rozhodují o sporných důsledcích. Logy uchovávají důkazy. Fronty zvládají zpoždění. Úložiště drží trvalý stav. Každá hranice by měla být dost nudná na vysvětlení. Pokud model dělá několik z těchto věcí, protože to bylo snazší, pojmenujte riziko a rozhodněte, zda je úkol dost nízko rizikový, aby to bylo tolerovatelné. Někdy je. Mnoho interních asistentů může být odlehčených. Problém je předstírat, že odlehčený design je základem pro automatizaci s vysokými důsledky.
Konečně selhání testu. Nástroj vrací částečná data. Zdrojové soubory si odporují. Model produkuje neplatný výstup. Paměť je zastaralá. Uživatel nemá oprávnění. Byl překročen nákladový limit. Lidská kontrola není k dispozici. Síť je pomalá. Plán se po schválení změní. Akce částečně uspěje. Pokud vám orchestrátor nedokáže říct, co se v těchto případech stane, je graf jen dekorativní. Může to být stále krásný graf. Dejte ho ke květině, ne do produkce.
Poučení
Argument proti magické orchestraci je argumentem pro inženýrskou disciplínu. Systémy umělé inteligence potřebují koordinaci a modely mohou koordinaci učinit adaptivnější. Ale adaptace bez explicitního stavu, kontraktů nástrojů, politiky opakování, ověřování, hranic paměti, bran akcí a cest obnovy není inteligence. Je to systém, který po budoucích operátorech chce, aby jeho návrh objevili čtením záznamů poté, co se stane něco nákladného.
Dobrá orchestrace je méně mystická a užitečnější. Pojmenovává stavy. Omezuje nástroje. Zaznamenává důkazy. Odděluje návrh od akce. Klasifikuje opakování. Ověřuje podle kontraktů úkolů. S pamětí zachází jako s pomocnou, ne autoritativní. Lidem dává přezkoumatelné stavy místo neprůhledných přepisů. Volí jednoduché pipeliny, když jednoduché pipeliny stačí. Přidává agenty tam, kde nejednoznačnost ospravedlňuje provozní náklady.
Magie skrývá mechanismus. Vážná umělá inteligence potřebuje mechanismy, které lze prohlížet, pozastavit, opravit a vylepšit. Cílem není odstranit úžas ze softwaru. Cílem je udržet úžas mimo zprávu o incidentu.