Agent nesmí být černá skříňka v kódu

TL;DR:

• Agentský proces začíná být důležitější než samotný model: musíš vědět, kdo rozhoduje, kdy se větev mění a kde vstupuje člověk.
• Deklarativní workflow, tedy pracovní tok popsaný pravidly mimo hlavní kód aplikace, pomáhá ukázat proces i lidem, kteří nečtou kód.
• Pro malé týmy je praktická hodnota hlavně v tom, že pravidla předání, schvalování a větvení nejsou zamčená u vývojáře.
• Čitelný konfigurační zápis typu YAML může být provozní dokument, ne jen technický detail.
• Deklarativní popis sám o sobě nezaručí dobrý proces; pořád potřebuje jasné vstupy, odpovědnost a lidskou kontrolu.

Představ si, že máš agenta pro příchozí poptávky. Jeden dotaz má poslat obchodníkovi, druhý účetní, třetí technické podpoře a čtvrtý má zastavit, protože obsahuje nejasný závazek. Dokud jde o jednoduchou ukázku, stačí pár podmínek v kódu. Jakmile na tom začne stát reálná práce, objeví se nepříjemná otázka: kdo vlastně vidí pravidla, podle kterých agent rozhoduje?

Tohle je důležitější než výběr konkrétního modelu. V běžné práci není agentský systém jen chatbot. Je to řízený proces: kroky, větvení, předání práce odpovědné osobě nebo dalšímu nástroji, čekání na schválení a reakce na výjimky. Pokud je celé řízení kroků procesu schované v kódu aplikace, umí ho měnit jen úzká skupina lidí. A často ani ostatní nevidí, co přesně agent smí udělat sám.

Proces musí jít přečíst dřív, než ho pustíš do práce

Nová verze Microsoft Agent Framework Declarative Workflows 1.0 staví na jednoduché myšlence: orchestraci, tedy řízení kroků procesu, můžeš popsat deklarativně mimo běžný kód aplikace. Zdroj popisuje definice, které se dají číst, verzovat a spouštět jako běžné workflow v rámci pro stavbu agentů.

Pro praxi je podstatný posun v odpovědnosti. Když je proces popsán jako pravidla, může ho zkontrolovat vlastník procesu, konzultant, architekt řešení i vývojář. Ne každý musí rozumět frameworku, třídám a volání funkcí. Stačí vidět pořadí kroků, podmínky větvení a místa, kde se práce předává dál.

To neznamená, že netechnický člověk má nasazovat produkční změny sám. Znamená to, že se diskuse o agentovi přesune z věty „věř mi, je to v kódu“ do věty „tady jsou pravidla, pojďme je projít“.

Malý tým potřebuje měnit pravidla bez velké operace

U freelancera, konzultanta nebo malého týmu bývá největší brzda prostá: proces se vyvíjí rychleji než aplikace. Dnes chceš, aby agent předával velké zakázky ke schválení od 50 tisíc korun. Za měsíc zjistíš, že hranice má být jiná podle typu klienta. Později přidáš výjimku pro citlivá data nebo nové schvalování před odesláním nabídky.

Když je každá změna zadrátovaná v kódu, začneš agentský proces spravovat jako technický projekt. Vznikají drobné úpravy, které nikdo nechce otevírat, protože jsou malé na plnohodnotný vývoj, ale příliš důležité na improvizaci. Deklarativní popis z toho dělá pravidlo, které můžeš porovnat s předchozí verzí, schválit a teprve potom spustit.

Praktický scénář: konzultant navrhuje klientovi agenta pro třídění požadavků. Místo abstraktní prezentace ukáže čitelný popis kroků: nejdřív roztřiď požadavek, potom rozhodni podle kategorie, při nejasnosti předej člověku, po schválení pokračuj dalším krokem. Klient nemusí číst kód, aby našel chybějící výjimku nebo špatně nastavené schválení.

Předání člověku není doplněk, ale součást návrhu

U agentů se často mluví o samostatnosti. V provozu je ale stejně důležité vědět, kde samostatnost končí. Předání práce odpovědné osobě nebo dalšímu kroku není selhání automatizace. Je to návrhové rozhodnutí.

Dobrý agentský proces má jasně popsané okamžiky, kdy má agent zastavit: vysoké finanční riziko, právně citlivý text, neúplná data, konflikt mezi pravidly nebo požadavek mimo běžný rozsah. Pokud jsou tyto hranice viditelné v popisu workflow, dá se o nich vést konkrétní debata. Pokud jsou rozptýlené v kódu, snadno zůstanou jako tichý předpoklad jednoho vývojáře.

Tady je deklarativní přístup silný hlavně redakčně a provozně. Nutí tě pojmenovat rozhodovací body. Nestačí říct „agent to vyřeší“. Musíš napsat, po jakém kroku, podle jaké podmínky a komu se práce předá, když si agent nemá být jistý.

Čitelný zápis nevyřeší špatně navrženou práci

Je lákavé brát deklarativní workflow jako zkratku k lepším agentům. Tou ale není. Pokud nevíš, co má proces dělat, kdo za výsledek ručí a jak poznáš chybné rozhodnutí, nepomůže ani nejpřehlednější YAML, tedy čitelný konfigurační zápis.

Riziko je v tom, že se z přehledného souboru stane nová vrstva chaosu. Pravidla se budou přidávat bez vlastníka, výjimky bez popisu důvodu a schvalování bez jasné odpovědnosti. Výsledkem nebude kontrolovatelný agent, ale jen proces, který vypadá čitelněji než dřív.

Proto se ptej dřív, než začneš řešit nástroj: které rozhodnutí má agent dělat sám, které má jen připravit a které nesmí udělat bez člověka? Kde potřebuješ historii změn pravidel? Kdo má právo změnit větvení? A podle čeho poznáš, že nová verze procesu zlepšila práci místo toho, aby jen přidala další automatizaci?

Začni mapou rozhodnutí, ne výběrem platformy

Pokud teď porovnáváš agentské nástroje, nezačínej otázkou, který má nejhezčí ukázku. Začni mapou rozhodnutí. Vezmi jeden skutečný proces, třeba třídění poptávek, přípravu podkladů pro klienta nebo zpracování interních požadavků, a napiš jeho kroky ve čtyřech vrstvách: vstup, rozhodnutí, předání, kontrola.

Pak si u každého kroku označ, jestli ho má dělat agent, člověk nebo oba. U větvení napiš podmínku běžným jazykem. U schválení napiš, kdo ho dává a co se stane po zamítnutí. Teprve potom řeš, jestli zvolený rámec umí takový proces popsat, verzovat a upravovat mimo hlavní kód aplikace.

Tím získáš praktičtější měřítko než seznam funkcí. Dobrý agentský systém není ten, který umí všechno automatizovat. Je to ten, u kterého dokážeš vysvětlit, co přesně automatizuje, kde se zastaví a kdo může změnit pravidla bez toho, aby se z provozního rozhodnutí stal nečitelný technický zásah.

Zdroj

Semantic Kernel / Microsoft Agent Framework: https://devblogs.microsoft.com/agent-framework/?p=5678