Vzory orchestrace agentů AI

Jako architekti a vývojáři navrhují své úlohy tak, aby plně využívali možnosti jazykového modelu, stávají se systémy agentů AI stále složitější. Tyto systémy často překračují schopnosti jednoho agenta, který má přístup k mnoha nástrojům a zdrojům znalostí. Místo toho tyto systémy používají orchestrace s více agenty ke spolehlivému zpracování složitých úloh založených na spolupráci. Tato příručka se zabývá základními vzory orchestrace pro architektury s více agenty a pomáhá zvolit přístup, který odpovídá vašim konkrétním požadavkům.

Přehled

Pokud používáte více agentů umělé inteligence, můžete složité problémy rozdělit do specializovaných jednotek práce nebo znalostí. Každou úlohu přiřadíte vyhrazeným agentům AI, kteří mají specifické možnosti. Tyto přístupy zrcadlí strategie nalezené v lidské týmové práci. Použití více agentů nabízí v porovnání s monolitickými řešeními s jedním agentem několik výhod.

• Specializace: Jednotliví agenti se můžou soustředit na konkrétní doménu nebo schopnost, což snižuje složitost kódu a výzvy.

• Škálovatelnost: Agenty je možné přidat nebo upravit, aniž byste přepracovali celý systém.

• Udržovatelnost: Testování a ladění se může zaměřit na jednotlivé agenty, což snižuje složitost těchto úloh.

• Optimalizace: Každý agent může k dosažení svých výsledků používat různé modely, přístupy k řešení úloh, znalosti, nástroje a výpočetní prostředky.

Vzory v této příručce ukazují osvědčené přístupy k orchestraci více agentů pro spolupráci a dosažení výsledku. Každý model je optimalizovaný pro různé typy požadavků koordinace. Tyto vzory orchestrace agentů AI doplňují a rozšiřují tradiční vzory návrhu cloudu tím, že řeší jedinečné výzvy koordinace autonomních komponent ve funkcích úloh řízených AI.

Sekvenční orchestrace

Sekvenční orchestrační vzor řetězí agenty AI v předdefinovaném lineárním pořadí. Každý agent zpracovává výstup z předchozího agenta v sekvenci, což vytváří řetězec specializovaných transformací.

Na obrázku je několik částí, které obsahují šipky a spojovací linky. Šipka ukazuje ze vstupu na agenta 1. Řádek propojuje agenta 1 s částí označenou jako model, znalosti a nástroje. Šipka ukazuje z agenta 1 na agenta 2. Řádek spojuje agenta 2 s částí, na které je napsáno model, znalosti a nástroje. Šipka ukazuje z agenta 2 na pole s elipsou. Šipka ukazuje z této krabice na agenta n. Řádek propojuje agenta n s částí, která čte model, znalosti a nástroje. Šipka ukazuje z Agenta n na výsledek. Oddíl pokrývající běžný stav zahrnuje část od Agenta 1 až k oddílu Agent n.

Model sekvenční orchestrace řeší problémy, které vyžadují podrobné zpracování, kde každá fáze vychází z předchozí fáze. Vyhovuje pracovním postupům, které mají jasné závislosti a zlepšují kvalitu výstupu prostřednictvím progresivního upřesnění. Tento model se podobá cloudovému návrhovému vzoru kanálů a filtrů, ale místo vlastních komponent zpracování používá AI agenty. Volba, kterého agenta se vyvolá dále, je deterministicky definována jako součást pracovního postupu a není volbou pro agenty v procesu.

Kdy použít sekvenční orchestraci

Představte si vzor sekvenční orchestrace v následujících scénářích:

• Procesy s více fázemi, které mají jasné lineární závislosti a předvídatelný průběh pracovního postupu

• Kanály transformace dat, kde každá fáze přidává specifickou hodnotu, na které závisí další fáze

• Dílčí fáze pracovního postupu, které nejde paralelizovat

• Progresivní požadavky na upřesnění, jako jsou pracovní postupy návrhu, revize, vyleštění

• Systémy, ve kterých rozumíte charakteristikám dostupnosti a výkonu každého agenta AI v systému a kde selhání nebo zpoždění zpracování jednoho agenta AI jsou přípustná pro splnění celkového úkolu.

Kdy se vyhnout sekvenční orchestraci

Vyhněte se tomuto vzoru v následujících scénářích:

• Fáze jsou trapně paralelní. Můžete je paralelizovat bez ohrožení kvality nebo vytváření kolizí se sdíleným stavem.

• Procesy, které zahrnují pouze několik fází, které může jeden AI agent efektivně vykonat.

• Počáteční fáze můžou selhat nebo vést k nízké kvalitě výstupu a neexistuje žádný rozumný způsob, jak zabránit pozdějším krokům ve zpracování pomocí kumulovaného výstupu chyb.

• Agenti umělé inteligence by měli spolupracovat, spíše než předávat práci.

• Pracovní postup vyžaduje navracení nebo iteraci.

• Potřebujete dynamické směrování na základě průběžných výsledků.

Příklad sekvenční orchestrace

Software pro správu dokumentů právnické firmy používá pro generování kontraktů sekvenční agenty. Inteligentní aplikace zpracovává požadavky prostřednictvím kanálu čtyř specializovaných agentů. Kroky sekvenční a předdefinované pipeline zajišťují, že každý agent funguje s úplným výstupem z předchozího kroku.

Na obrázku je několik částí, které obsahují šipky a spojovací linky. Šipka ukazuje z požadavků na vytvoření dokumentu na agenta pro výběr šablony. Řádek spojuje agenta oddílu šablony s oddílem, kde je uveden model, knihovna šablon a nástroje pro výzkum. Šipka ukazuje z agenta pro výběr šablony na agenta přizpůsobení klauzule. Řádek spojuje agenta přizpůsobení klauzule s oddílem pojmenovaným Jemně vyladěný model. Šipka ukazuje z agenta přizpůsobení klauzule na agenta dodržování právních předpisů. Řádek spojuje agenta pro dodržování předpisů s částí označenou jako Model, vědomosti v oblasti předpisů. Šipka ukazuje od agenta dodržování právních předpisů k agentu posouzení rizik. Řádek spojuje agenta posouzení rizik s částí nazvanou Model, znalosti odpovědnosti a nástroje trvalosti. Šipka ukazuje od agenta pro posouzení rizik na oddíl s názvem Navrhovaný dokument. Oddíl, který se týká stavu dokumentu, pokrývá agenta pro přizpůsobení klauzule až po oddíl Navrhovaného dokumentu.

1. Agent pro výběr šablony obdrží specifikace klienta, jako je typ smlouvy, jurisdikce a zúčastněné strany, a vybere příslušnou základní šablonu z knihovny firmy.

2. Agent přizpůsobení klauzule vezme vybranou šablonu a upraví standardní klauzule na základě vyjednaných obchodních podmínek, včetně omezení platebních plánů a odpovědnosti.

3. Agent dodržování právních předpisů kontroluje přizpůsobenou smlouvu proti platným zákonům a předpisům specifickým pro dané odvětví.

4. Agent posouzení rizik provádí komplexní analýzu kompletní smlouvy. Vyhodnocuje mechanismy vystavení odpovědnosti a řešení sporů a současně poskytuje hodnocení rizik a doporučení ochranného jazyka.

Souběžná orchestrace

Vzor souběžné orchestrace spouští na stejném úkolu současně více agentů umělé inteligence. Tento přístup umožňuje každému agentu poskytovat nezávislou analýzu nebo zpracování z jeho jedinečné perspektivy nebo specializace.

Obrázek obsahuje tři klíčové části. V horní části ukazuje šipka ze vstupu na iniciátora a agenta sběrače. Šipka ukazuje z iniciátoru a agenta kolektoru do oddílu, který obsahuje agregované výsledky na základě kombinovaných, porovnaných a vybraných výsledků. Čára spojuje iniciátora a agenta kolektoru s čárou, která propojuje čtyři části šipkami. Tyto části jsou Agent 1, Agent 2, neoznačená část s elipsami a Agent n. Šipka ukazuje od agenta 1 na průběžný výsledek. Čára vychází z agenta 1 a rozdvojuje se do dvou směrů. První tok ukazuje sekci Dílčí agent 1.1 a sekci s názvem Model, znalosti a nástroje. Druhý tok ukazuje dílčího agenta 1.2 a sekci s názvem Model, znalosti a nástroje. Šipka ukazuje z Agent 2 na Průběžný výsledek. Řádek spojuje agenta 2 s částí, na které je napsáno model, znalosti a nástroje. Šipka ukazuje z neoznačeného oddílu s elipsami na průběžné výsledky. Šipka ukazuje z Agenta n na průběžný výsledek. Řádek propojuje agenta n s částí, která čte model, znalosti a nástroje.

Tento model řeší scénáře, ve kterých potřebujete různé přehledy nebo přístupy ke stejnému problému. Místo postupného zpracování pracují všichni agenti paralelně, což zkracuje celkovou dobu běhu a poskytuje komplexní pokrytí problémového prostoru. Tento model orchestrace se podobá cloudovému vzoru návrhu Fan-out/Fan-in. Výsledky z každého agenta se často agregují, aby poskytly konečný výsledek, ale to není nutné. Každý agent může nezávisle vytvářet vlastní výsledky v rámci úlohy, jako je například vyvolání nástrojů pro paralelní provádění úloh nebo aktualizace různých úložišť dat.

Agenti pracují nezávisle na sobě a výsledky vzájemně nepředávejte. Agent může aktivovat další AI agenty pomocí vlastního orchestračního přístupu jako součást svého nezávislého zpracování. Agenti, kteří jsou k dispozici, musí vědět, kteří další agenti jsou k dispozici ke zpracování. Tento model podporuje deterministické volání všech registrovaných agentů a dynamický výběr agentů, které se mají vyvolat na základě požadavků úlohy.

Kdy použít souběžnou orchestraci

Představte si vzor souběžné orchestrace v následujících scénářích:

• Úlohy, které můžete spouštět paralelně, buď pomocí pevné sady agentů, nebo dynamickým výběrem agentů AI na základě konkrétních požadavků na úlohy.

• Úkoly, které využívají více nezávislých perspektiv nebo různých specializace, jako jsou technické, obchodní a kreativní přístupy, které můžou přispět ke stejnému problému. K této spolupráci obvykle dochází ve scénářích, které obsahují následující techniky rozhodování s více agenty:

  • Brainstorming

  • Souborové odůvodnění

  • Rozhodnutí založená na kvoru a hlasování

• Časově citlivé scénáře, kdy paralelní zpracování snižuje latenci.

Kdy se vyhnout souběžné orchestraci

Vyhněte se tomuto vzoru orchestrace v následujících scénářích:

• Agenti se musí stavět na práci ostatních a vyžadovat kumulativní kontext v konkrétní sekvenci.

• Úloha vyžaduje konkrétní pořadí operací nebo deterministické, reprodukovatelné výsledky spuštění v definované sekvenci.

• Omezení prostředků, jako je kvóta modelu, činí paralelní zpracování neefektivním nebo nemožným.

• Agenti nemůžou spolehlivě koordinovat změny sdíleného stavu nebo externích systémů při současném spuštění.

• Neexistuje žádná jasná strategie řešení konfliktů pro řešení protichůdných nebo konfliktních výsledků každého agenta.

• Logika agregace výsledků je příliš složitá nebo snižuje kvalitu výsledků.

Příklad souběžné orchestrace

Firma finančních služeb vytvořila inteligentní aplikaci, která používá souběžné agenty, které se specializují na různé typy analýz, aby se vyhodnotily stejné akcie současně. Každý agent přispívá k přehledům ze specializované perspektivy, která poskytuje různorodý a časově citlivý vstup pro rychlá rozhodnutí o investicích.

Obrázek obsahuje tři klíčové části. V horní části ukazuje šipka ze symbolu Ticker na agenta burzovní analýzy. Linka spojuje mapování symbolů modelu s agentem pro burzovní analýzu. Šipka směřuje od agenta burzovní analýzy k oddílu s textem 'Rozhodnutí' s podpůrnými důkazy na základě kombinovaných výsledků průběžné analýzy. Čára spojuje agenta burzovní analýzy s linií, která vede k čtyřem samostatným částem. Tyto části jsou čtyři samostatné toky: agent fundamentální analýzy, agent technické analýzy, agent sentimentální analýzy a agent ESG. Čára spojuje model s tokem základního agenta analýzy. Šipka ukazuje ze základního toku agenta analýzy na průběžný výsledek. Přímka vede od agenta fundamentální analýzy a rozděluje se do dvou toků: agent finanční a výnosové analýzy a agent konkurenční analýzy. Řádek spojuje finanční data a agenta pro analýzu výnosů s částí, která obsahuje model a hlášené finanční znalosti. Řádek spojuje konkurenčního analytického agenta s částí, která čte model, konkurenční znalosti. Šipka směřuje od agenta technické analýzy k průběžnému výsledku. Řádek propojuje agenta technické analýzy k části s názvem Specifický model, rozhraní API trhu. Šipka ukazuje z agenta analýzy mínění na průběžný výsledek. Řádek propojuje agenta analýzy sentimentu s oddílem, který obsahuje model, sociální a zpravodajská rozhraní API. Šipka ukazuje z agenta ESG na mezivýsledek. Řádek propojuje agenta ESG s částí, která je označena jako Model, ESG znalosti.

Systém zpracovává žádosti o analýzu zásob odesláním stejného symbolu tickeru do čtyř specializovaných agentů, kteří běží paralelně.

• Základní analytický agent vyhodnocuje finanční výkazy, trendy výnosů a konkurenční pozici k vyhodnocení vnitřní hodnoty.

• Agent technické analýzy zkoumá cenové vzory, ukazatele objemu a signály k identifikaci obchodních příležitostí.

• Agent pro analýzu mínění zpracovává články zpráv, zmínky na sociálních sítích a zprávy analytiků, které měří mínění na trhu a důvěru investorů.

• Agent esG (environmental, social, and governance) kontroluje dopad na životní prostředí, sociální odpovědnost a postupy zásad správného řízení za účelem vyhodnocení rizik udržitelnosti a příležitostí.

Tyto nezávislé výsledky se pak zkombinují do komplexního doporučení pro investice, které správcům portfolia umožňuje rychle činit informovaná rozhodnutí.

Orchestrace skupinového chatu

Model orchestrace skupinového chatu umožňuje více agentům řešit problémy, rozhodovat se nebo ověřovat práci tím, že se účastní sdíleného vlákna konverzace, kde spolupracují prostřednictvím diskuze. Správce chatu koordinuje tok tím, že určí, kteří agenti můžou reagovat dál, a tím, že spravuje různé režimy interakce, od debaty o spolupráci až po strukturované brány kvality.

Na obrázku je několik částí, které obsahují šipky a spojovací linky. Šipka ukazuje od vstupu k manažerovi skupinového chatu. Šipka začíná u Modelu, prochází manažerem skupinového chatu a ukazuje na vlákno chatu, které se hromadí. Pod tímto řádkem jsou uvedeny instrukce pro novou skupinu na základě akumulovaného kontextu. Řádek se připojuje k oddílu, který má nápis Účastník nebo pozorovatel lidského chatu. Šipka ukazuje ze správce skupinového chatu na agenta 2. Oboustranná šipka spojuje agenta 1, neoznačené pole s elipsami a agenta n. Linie spojuje agenta 1, agenta 2, neoznačenou krabici a agenta n. Řádek spojuje agenta 1 s modelem a znalostmi. Řádek spojuje agenta 2 s modelem a znalostmi. Linie spojuje Agenta n s modelem a znalostmi. Šipka ukazuje z části označené jako výstup chatu od agentů do akumulujícího se chatovacího vlákna. Čára spojuje akumulační vlákno chatu s výsledkem.

Tento model řeší scénáře, které se nejlépe provádějí prostřednictvím skupinové diskuze, aby bylo možné dosáhnout rozhodnutí. Tyto scénáře můžou zahrnovat integrované vývojové prostředí pro spolupráci, strukturované ověřování nebo procesy kontroly kvality. Model podporuje různé režimy interakce, od volné debaty po formální kontrolu pracovních postupů s pevnými rolemi a schvalovacími branami.

Tento model funguje dobře pro scénáře s člověkem v roli, kde lidé mohou volitelně převzít dynamické řízení chatu a vést konverzace směrem k produktivním výsledkům. V tomto modelu orchestrace jsou agenti obvykle v režimu jen pro čtení . Nepoužívají nástroje k provádění změn v běžících systémech.

Kdy použít orchestraci skupinového chatu

Zvažte orchestraci skupinového chatu, když lze váš scénář vyřešit prostřednictvím spontánní nebo řízené spolupráce, případně iterativními smyčkami typu maker-checker. Všechny tyto přístupy podporují lidský dohled nebo účast v reálném čase. Vzhledem k tomu, že všichni agenti a lidé zapojení do procesu generují výstup do jediného akumulujícího vlákna, toto schéma poskytuje transparentnost a auditovatelnost.

Scénáře spolupráce

• Kreativní debaty, kdy agenti, kteří mají různé perspektivy a zdroje znalostí, vycházejí z příspěvků do chatu

• Rozhodovací procesy, které mají prospěch z debaty a budování konsensu

• Rozhodovací scénáře, které vyžadují iterativní upřesnění prostřednictvím diskuze

• Multioborové problémy, které vyžadují křížový dialog

Scénáře ověřování a kontroly kvality

• Požadavky na kontrolu kvality, které zahrnují strukturované procesy kontroly a iteraci

• Dodržování předpisů a zákonné ověřování, které vyžaduje více odborných hledisek

• Pracovní postupy vytváření obsahu, které vyžadují redakční kontrolu s jasným oddělením obav mezi vytvořením a ověřováním

Kdy se vyhnout koordinaci skupinového chatu

Vyhněte se tomuto vzoru v následujících scénářích:

• Stačí jednoduché delegování úkolů nebo zpracování pomocí pipeline.

• Požadavky na zpracování v reálném čase činí režijní náklady na diskuzi nepřijatelné.

• Jasné hierarchické rozhodovací nebo deterministické pracovní postupy bez diskuze jsou vhodnější.

• Správce chatu nemá žádný objektivní způsob, jak určit, jestli je úkol dokončen.

Správa toku konverzace a zabránění nekonečným smyčkám vyžaduje pečlivou pozornost, zejména když více agentů ztěžuje údržbu kontroly. Pokud chcete zachovat efektivní kontrolu, zvažte omezení orchestrace skupinového chatu na tři nebo méně agentů.

Cyklus tvůrce-kontrolor

cs-CZ: Smyčka tvůrce-ověřovatele je konkrétní typ orchestrace skupinového chatu, kde jeden agent, tvůrce, něco vytváří nebo navrhuje. Další agent, kontrolní pracovník, poskytuje kritiku výsledku. Tento vzor je iterativní, kdy agent kontroly vrací konverzaci agentovi tvůrci, aby provedl aktualizace a zopakoval celý proces. I když vzor skupinového chatu nevyžaduje, aby se agenti střídali, smyčka schvalování vyžaduje formální posloupnost střídání, kterou řídí správce chatu.

Příklad orchestrace skupinového chatu

Městské parky a rekreační oddělení používá software, který zahrnuje orchestraci skupinového chatu k vyhodnocení nových návrhů na vývoj parku. Software čte návrh a více odborných agentů debatuje o různých perspektivách dopadu komunity a pracuje na konsensus na návrhu. K tomuto procesu dochází před otevřením návrhu ke kontrole komunity, který pomůže předvídat zpětnou vazbu, kterou může obdržet.

Na obrázku je několik částí, které obsahují šipky a spojovací linky. Šipka ukazuje od návrhu rozvoje parku na správce skupinového chatu. Řádek začíná na Modelu, prochází správcem skupinového chatu a ukazuje na akumulující se konverzaci. Spojení propojuje zaměstnance oddělení Parks s touto telekomunikační linkou. Část, která čte pokyny na základě kumulovaného kontextu a čerstvého přehledu, je pod touto částí. Šipka ukazuje od manažera skupinového chatu k agentu pro plánování životního prostředí. Oboustranná šipka spojuje agenta pro zapojení komunity a agenta pro rozpočet a provoz parků. Řádek spojuje agenta pro zapojení komunity s agentem pro plánování životního prostředí a rozpočtovým a provozním agentem parků. Řádek spojuje agenta zapojení komunity s částí, která je označena jako Model a občanské znalosti. Řádek propojuje agenta plánování životního prostředí k části nazvané Modelové a místní environmentální znalosti. Šipka spojuje oddíl, který čte výstup chatu od občanských agentů do shromádící konverzace. Řádek spojuje hromadící se konverzaci s konsensu návrhu parku. Řádek spojuje agenta rozpočtu a provozu Parků s částí, která obsahuje znalosti modelu a města.

Systém zpracovává návrhy vývoje parku zahájením skupinové konzultace se specializovanými městskými agenty, kteří se podílejí na úkolu z více občanských perspektiv.

• Agent zapojení komunity vyhodnocuje požadavky na přístupnost, očekávanou zpětnou vazbu rezidenta a vzory použití, aby byl zajištěn spravedlivý přístup ke komunitě.

• Agent pro plánování životního prostředí posuzuje ekologický dopad, opatření udržitelnosti, nativní přesun rostlin a dodržování předpisů v oblasti životního prostředí.

• Rozpočtový a provozní agent analyzuje náklady na výstavbu, průběžné výdaje na údržbu, požadavky na personál a dlouhodobou provozní udržitelnost.

Správce chatu usnadňuje strukturovanou debatu, kdy agenti zpochybňují doporučení toho druhého a obhajují své argumenty. Zaměstnanec oddělení parků se účastní vlákna chatu, aby v reálném čase přidal přehled a reagoval na žádosti o znalosti agentů. Tento proces umožňuje zaměstnanci aktualizovat původní návrh tak, aby řešil zjištěné obavy a lépe se připravil na zpětnou vazbu komunity.

Orchestrace předání

Model orchestrace předání umožňuje dynamické delegování úloh mezi specializovanými agenty. Každý agent může danou úlohu posoudit a rozhodnout se, jestli ji bude zpracovávat přímo, nebo ji převést na vhodnějšího agenta na základě kontextu a požadavků.

Na obrázku je pět klíčových oblastí. Část Agent 1 obsahuje vstup, model a obecný oddíl znalostí a výsledek. Část Agent 2 obsahuje výsledek a model a oddíl znalostí. Část Agent 3 obsahuje oddíl modelu, znalostí a nástrojů, výsledek a neoznačené oddíly, které se připojí k výsledku. Agent n obsahuje sekci modelu, sekci znalostí a výsledek. V části Zaměstnanci zákaznické podpory je výsledek. Zakřivené šipky proudí od agenta k agentovi a k zaměstnanci zákaznické podpory.

Tento vzorec řeší scénáře, kdy optimální agent pro úlohu není předem známý nebo kde se požadavky úlohy stanou jasnými pouze během zpracování. Umožňuje inteligentní směrování a zajišťuje, aby se úlohy dostaly k nejschopnějšímu agentu. Agenti v tomto vzoru obvykle nefungují paralelně. Přenosy úplné kontroly z jednoho agenta do jiného.

Kdy použít orchestraci předávání

Představte si vzor předání agenta v následujících scénářích:

• Úlohy, které vyžadují specializované znalosti nebo nástroje, ale pokud počet potřebných agentů nebo jejich pořadí není možné předem určit

• Scénáře, ve kterých se během zpracování objevují požadavky na odborné znalosti, což vede k dynamickému směrování úkolů na základě analýzy obsahu

• Problémy s více doménami, které vyžadují různé specialisty, kteří pracují jeden po druhém

• Logické vztahy a signály, které můžete předem určit, kdy jeden agent dosáhne limitu jeho schopností a který agent by měl zpracovat úlohu

Kdy se vyhnout orchestrace předávání

Vyhněte se tomuto vzoru v následujících scénářích:

• Příslušné agenty a jejich pořadí jsou vždy známé předem.

• Směrování úloh je jednoduché a deterministicky založené na pravidlech, nikoli na základě dynamického kontextového okna nebo dynamické interpretace.

• Neoptimální rozhodnutí o směrování můžou vést k špatnému nebo frustrujícímu uživatelskému prostředí.

• Aby se úloha vyřešila, měla by běžet více operací současně.

• Vyhnout se nekonečné smyčce při předávání nebo nadměrnému přepínání mezi agenty je náročné.

Příklad modelu předání agenta

Řešení pro správu vztahů se zákazníky (CRM) pro telekomunikační technologie používá agenty předání na webovém portálu zákaznické podpory. Počáteční agent začne pomáhat zákazníkům, ale zjišťuje, že během konverzace potřebuje specializované odborné znalosti. Počáteční agent předá úlohu nejvhodnějšímu agentovi, aby vyřešil problém zákazníka. Pouze jeden agent najednou pracuje s původním vstupem a řetěz předání vede k jednomu výsledku.

Obrázek obsahuje pět klíčových oddílů. Část agenta podpory pro třídění zahrnuje model a obecnou část znalostí, vstup a výsledek. Část Agent technické infrastruktury obsahuje výsledek a část s modelem, znalostmi infrastruktury a nástroji. Sekce Agentu finančního řešení zahrnuje model, znalostní bázi fakturačního účtu, oddíl přístupu k rozhraní API pro fakturaci a výsledek. Část zástupce pro přístup k účtu obsahuje oddíl výsledků, modelů a znalostí zákazníků. V části Zaměstnanci zákaznické podpory je výsledek. Zakřivené šipky proudí z agenta na agenta a k zaměstnanci zákaznické podpory.

V tomto systému agent podpory třídění interpretuje požadavek a snaží se zpracovávat běžné problémy přímo. Když dosáhne limitů, předává problémy se sítí agentovi technické infrastruktury, spory ohledně vyúčtování agentovi finančního řešení atd. Další předání probíhá mezi těmito agenty, když současný agent rozpozná své limity a ví, že jiný agent může tuto situaci lépe řešit.

Každý agent je schopen dokončit konverzaci, pokud zjistí, že bylo dosaženo úspěchu zákazníka nebo že žádný jiný agent nemůže zákazníka dále využít. Někteří agenti jsou také navrženi tak, aby předali uživatelské prostředí agentům lidské podpory, pokud je problém důležitý k vyřešení, ale žádný agent AI v současné době nemá možnosti ho řešit.

V diagramu je zvýrazněný jeden příklad instance předání. Začíná to agentem třídění, který úlohu předá agentovi technické infrastruktury. Agent technické infrastruktury se pak rozhodne předat úlohu agentu finančního řešení, který nakonec přesměruje úlohu na zákaznickou podporu.

Magentická orchestrace

Vzor magentické orchestrace je navržený pro otevřené a složité problémy, které nemají předem určený plán přístupu. Agenti v tomto vzoru obvykle mají nástroje, které jim umožňují provádět přímé změny v externích systémech. Zaměřujeme se stejně na vytváření a zdokumentování přístupu k vyřešení problému, jako na samotnou implementaci tohoto přístupu. Seznam úkolů se dynamicky sestaví a zpřesní jako součást pracovního postupu prostřednictvím spolupráce mezi specializovanými agenty a agentem magentického manažera. Jak se kontext vyvíjí, agent magnetického manažera sestaví registr úloh pro vývoj plánu přístupu s cíli a dílčími cíli, které se nakonec sjednotí, sleduje a plní, aby bylo dosaženo požadovaného výsledku.

Na obrázku je sekce agenta Manager. Zahrnuje vstup a model. Šipka označená jako Vyvolání agentů ukazuje z agenta Manageru na Agenta 2. Šipka označená jako smyčka Vyhodnotit cíl odkazuje na oddíl Dokončení úkolu. Šipka s popiskem Ano ukazuje na sekci Výsledky a šipka s popiskem Ne ukazuje zpět na agenta manažera. Šipka ukazuje od agenta Manažer do části Kniha úkolů a jejich průběh. Čára spojuje sekci úkolů a sledování pokroku s částí lidského účastníka. Čára se třemi šipkami odkazuje na agenta 1, agenta 2, neoznačené části a agenta n. Řádek spojuje Agent 1 s částí označenou jako Model a znalosti. Řádek spojuje agenta 2 s částí, na které je napsáno model, znalosti a nástroje. Čára spojuje agenta n s modelem a nástroji. Šipka ukazuje z oddílu označeného jako Model, znalosti a nástroje směrem k externím systémům a také z oddílu Model a nástroje k externím systémům.

Agent manažera komunikuje přímo se specializovanými agenty, aby shromáždil informace při sestavování a upřesňování registru úloh. Iteruje, vrací zpět a deleguje tolikrát, kolikrát je potřebné k vytvoření kompletního plánu, který je schopen úspěšně provést. Manažerský agent často vyhodnocuje, zda je původní požadavek zcela splněn nebo pozastaven. Aktualizuje účetní knihu, aby upravil plán.

Tento model orchestrace je některými způsoby rozšířením vzoru skupinového chatu . Magentický model orchestrace se zaměřuje na agenta, který vytváří plán přístupu, zatímco jiní agenti používají nástroje k provádění změn v externích systémech místo použití jejich úložišť znalostí k dosažení výsledku.

Kdy použít magnetickou orchestraci

Představte si magentický vzor v následujících scénářích:

• Složitý nebo otevřený případ použití, který nemá žádnou předem stanovenou cestu řešení.

• Požadavek na zvážení vstupu a zpětné vazby od několika specializovaných agentů za účelem vývoje platné cesty řešení

• Požadavek, aby systém AI vygeneroval plně vyvinutý plán přístupu, který může člověk před implementací nebo po implementaci zkontrolovat.

• Agenti vybaveni nástroji, které pracují s externími systémy, využívají externí prostředky nebo můžou vyvolat změny ve spuštěných systémech. Zdokumentovaný plán, který ukazuje, jak jsou tito agenti sekvencováni, může být prezentován uživateli před tím, než je agentům umožněno postupovat podle úkolů.

Kdy se vyhnout magnetické orchestraci

Vyhněte se tomuto vzoru v následujících scénářích:

• Cesta řešení se vyvíjí nebo by se měla přistupovat deterministickým způsobem.

• Neexistuje žádný požadavek na vytvoření registru.

• Úloha má nízkou složitost a jednodušší model ho dokáže vyřešit.

• Práce je citlivá na čas, protože model se zaměřuje na vytváření a debatování realizovatelných plánů, a ne na optimalizaci pro konečné výsledky.

• Předpokládáte častá zaseknutí nebo nekonečné smyčky, pro které neexistuje jasná cesta k řešení.

Příklad magentické orchestrace

Tým SRE (Site Reliability Engineering) vytvořil automatizaci, která využívá magentickou orchestraci ke zvládnutí scénářů reakce na incidenty s nízkým rizikem. Pokud dojde k výpadku služby v rámci automatizace, musí systém dynamicky vytvořit a implementovat plán nápravy. Dělá to bez znalosti konkrétních kroků potřebných předem.

Na obrázku je část agenta správce automatizace SRE, která obsahuje vstup a model. Šipka ukazuje od agenta manažera automatizace SRE do sekce Úkoly a průběh. Šipka označená jako Vyvolání znalostí a agentů akcí odkazuje na čáru, která odkazuje na infrastrukturu, diagnostiku, vrácení zpět a komunikační agenty. Šipka s popiskem Vyhodnotit body smyčky cíle vede od agenta správce automatizace SRE k sekci vyřešené problémy produkčního prostředí. Šipka označená jako Ano ukazuje od vyřešeného problému na živé stránce k výsledku. Část Hlavní kniha úkolů a průběhu obsahuje plán přístupu k řešení, stav úkolů řešení a sekci pro vyřešení problému na živém webu. Šipka označená jako "Ne" vede od problému na živém webu k agentovi správce automatizace SRE. Čára začíná u diagnostického agenta, prochází sekcí věnovanou znalostem modelu, logů a metrik a směřuje k systémům zátěže. Řádek začíná agentem infrastruktury, prochází částí modelu, znalostí grafu a nástroji příkazového řádku a spojuje se s čárou, která ukazuje na systémy úloh. Řádek začíná u agenta pro vrácení zpět, jde skrz model, přístup Git, sekci nástrojů příkazového řádku a míří na systémy zátěže. Čára začíná u komunikačního agenta, prochází částí modelování a API přístupu ke komunikaci a ukazuje na část lidského účastníka.

Když automatizace zjistí opravňující incident, začne agent magentického manažera vytvořením počátečního registru úloh s hlavními cíli, jako je obnovení dostupnosti služby a identifikace původní příčiny. Agent manažera pak s využitím specializovaných agentů shromáždí informace a zpřesní plán nápravy.

1. Agent diagnostiky analyzuje systémové protokoly, metriky výkonu a vzory chyb za účelem identifikace potenciálních příčin. Posílá zjištění zpět k agentu manažera.

2. Na základě diagnostických výsledků agent správce aktualizuje evidenci úloh konkrétními kroky šetření a konzultuje agenta infrastruktury, aby zajistil porozumění aktuálnímu stavu systému a dostupným možnostem obnovení.

3. Komunikační agent poskytuje možnosti oznámení účastníků a vedoucí agent zahrnuje kontrolní body komunikace a schvalovací brány do vyvíjejícího se plánu podle postupů eskalace týmu SRE.

4. Vzhledem k tomu, že je scénář jasnější, může agent manažera přidat agenta vrácení zpět do plánu, pokud je potřeba převést nasazení zpět, nebo eskalovat technikům SRE, pokud incident překročí rozsah automatizace.

Během tohoto procesu agent nadřízený průběžně zpřesňuje registr úloh na základě nových informací. S tím, jak se incident vyvíjí, přidává, odebírá nebo mění pořadí úkolů. Pokud například agent diagnostiky zjistí problém s připojením k databázi, může agent manažera přepnout celý plán ze strategie vrácení nasazení zpět na plán, který se zaměřuje na obnovení připojení k databázi.

Manažerský agent sleduje nadměrná zpoždění při obnovování služby a brání před nekonečnými nápravnými smyčkami. Udržuje kompletní auditní záznam rozvíjejícího se plánu a implementačních kroků, které poskytují transparentnost pro přezkum po incidentu. Tato transparentnost zajišťuje, aby tým SRE mohl zlepšit úlohy i automatizaci na základě získaných poznatků.

Na co myslet při implementaci

Při implementaci některého z těchto vzorů návrhu agenta je potřeba vyřešit několik aspektů. Kontrola těchto aspektů vám pomůže vyhnout se běžným nástrahám a zajistit, aby orchestrace agentů byla robustní, zabezpečená a udržovatelná.

Jeden agent, víceúčelový nástroj

Pokud potřebujete dostatečný přístup k nástrojům a zdrojům znalostí, můžete vyřešit některé problémy s jedním agentem. S rostoucím počtem zdrojů znalostí a nástrojů se stává obtížné poskytnout předvídatelné prostředí agenta. Pokud jeden agent dokáže spolehlivě vyřešit váš scénář, zvažte přijetí takového přístupu. Režijní náklady na rozhodování a řízení toku často překračují výhody rozdělení úlohy na více agentů. Hraniční zabezpečení, přehlednost sítě a další faktory však stále mohou učinit přístup s jedním agentem neuskutečnitelným.

Deterministické směrování

Některé vzory vyžadují, abyste směrovali tok mezi agenty deterministicky. Jiní se spoléhají na agenty, kteří si vyberou vlastní trasy. Pokud jsou vaši agenti definováni v prostředí bez kódu nebo s nízkým kódem, nemusíte toto chování řídit. Pokud definujete agenty v kódu pomocí sad SDK, jako je Microsoft Agent Framework nebo sémantické jádro, máte větší kontrolu.

Kontextové okno

Agenti umělé inteligence mají často omezená kontextová okna. Toto omezení může ovlivnit jejich schopnost zpracovávat složité úlohy. Při implementaci těchto vzorů rozhodněte, jaký kontext vyžaduje další agent, aby byl efektivní. V některých scénářích potřebujete úplný nezpracovaný kontext, který jste zatím shromáždili. V jiných scénářích je vhodnější souhrnná nebo zkrácená verze. Pokud váš agent může pracovat bez kumulovaného kontextu a vyžaduje pouze novou sadu instrukcí, použijte tento přístup místo poskytnutí kontextu, který nepomůže provést úlohu agenta.

Spolehlivost

Tyto vzory vyžadují správné fungování agentů a spolehlivé přechody mezi nimi. Často vedou k problémům s klasickými distribuovanými systémy, jako jsou selhání uzlů, síťové oddíly, ztráta zpráv a kaskádové chyby. Strategie zmírnění rizik by měly být zavedeny pro řešení těchto problémů. Agenti a jejich orchestrátory by měli provést následující kroky.

• Implementujte mechanismy vypršení časového limitu a opakování.

• Zahrňte implementaci elegantního snížení výkonu pro zpracování jednoho nebo více agentů v rámci chybného vzoru.

• Odhalte chyby místo jejich skrytí, aby podřízení agenti a logika orchestrátora mohli správně reagovat.

• Zvažte použití vzorů "circuit breaker" pro zajištění závislostí agentů.

• Navrhujte agenty tak, aby byly izolované tak, jak je to praktické, přičemž jednotlivé body selhání se mezi agenty nesdílely. Například:

  • Zajistěte izolaci výpočetních prostředí mezi agenty.

  • Vyhodnoťte, jak použití jednoho modelu jako modelu služby (MaaS) nebo sdíleného úložiště znalostí může vést k omezování rychlosti při souběžnému spuštění agentů.

• Funkce kontrolních bodů dostupné v sadě SDK vám pomůžou zotavit se z přerušené orchestrace, jako je selhání nebo nové nasazení kódu.

Zabezpečení

Implementace správných mechanismů zabezpečení v těchto vzorech návrhu minimalizuje riziko vystavení systému AI útokům nebo úniku dat. Zabezpečení komunikace mezi agenty a omezení přístupu jednotlivých agentů k citlivým datům jsou klíčovými strategiemi návrhu zabezpečení. Zvažte následující bezpečnostní opatření:

• Implementujte ověřování a používejte zabezpečené sítě mezi agenty.

• Zvažte vliv komunikace agenta na ochranu osobních údajů.

• Navrhujte záznamy auditu tak, aby splňovaly požadavky na dodržování předpisů.

• Navrhujte agenty a jejich orchestrátory tak, aby dodržovaly zásadu minimálních oprávnění.

• Zvažte, jak zpracovávat identitu uživatele napříč agenty. Agenti musí mít široký přístup k úložištím znalostí, aby mohli zpracovávat žádosti od všech uživatelů, ale nesmí vracet data, která jsou pro uživatele nepřístupná. Oříznutí zabezpečení musí být implementováno v každém agentu v modelu.

Pozorovatelnost a testování

Distribuce systému AI napříč několika agenty vyžaduje monitorování a testování jednotlivých agentů, stejně jako celý systém, aby se zajistily správné funkce. Při navrhování strategií pozorovatelnosti a testování zvažte následující doporučení:

• Zmonitorujte všechny operace agenta a přenosy. Řešení potíží s distribuovanými systémy je výzva pro počítačové vědy a agenti orchestrované umělé inteligence nejsou výjimkou.

• Sledujte metriky výkonu a využití prostředků pro každého agenta, abyste mohli vytvořit základní hodnoty, najít kritické body a optimalizovat je.

• Návrh testovatelných rozhraní pro jednotlivé agenty

• Implementujte integrační testy pro pracovní postupy s více agenty.

Běžné nástrahy a antivzorce

Vyhněte se těmto běžným chybám při implementaci vzorů orchestrace agentů:

• Vytvoření zbytečné složitosti koordinace pomocí složitého vzoru, pokud by stačí jednoduchá sekvenční nebo souběžná orchestrace.

• Přidání agentů, kteří neposkytují smysluplnou specializaci

• Přehlédnutí dopadů na latenci vícehopové komunikace

• Sdílení proměnlivého stavu mezi souběžnými agenty, což může vést k nekonzistentním datům z důvodu předpokladu synchronních aktualizací napříč hranicemi agentů.

• Použití deterministických vzorů pro pracovní postupy, které jsou ze své podstaty nedeterministické.

• Použití nedeterministických vzorů pro pracovní postupy, které jsou ze své podstaty deterministické.

• Když zvolíte souběžnou orchestraci, ignorujete omezení prostředků.

• Využívání nadměrných prostředků modelu, protože kontextová okna se zvětšují, když agenti shromažďují více informací a konzultují svůj model, aby dosáhli pokroku ve své úloze.

Kombinování vzorů orchestrace

Aplikace někdy vyžadují, abyste zkombinovali více vzorů orchestrace, abyste vyřešili jejich požadavky. Můžete například použít sekvenční orchestraci pro počáteční fáze zpracování dat a pak přepnout na souběžnou orchestraci pro paralelizovatelné úlohy analýzy. Nepokoušejte se, aby se jeden pracovní postup vešel do jednoho vzoru, pokud různé fáze vaší úlohy mají různé charakteristiky a můžou z každé fáze těžit z jiného vzoru.

Vztah k vzorům návrhu cloudu

Vzory orchestrace agentů AI rozšiřují a doplňují tradiční vzory návrhu cloudu tím, že řeší jedinečné výzvy koordinace inteligentních a autonomních komponent. Vzory návrhu cloudu se zaměřují na strukturální a behaviorální obavy v distribuovaných systémech, ale vzory orchestrace agentů AI se zaměřují konkrétně na koordinaci komponent s možnostmi odůvodnění, chováním učení a nedeterministickými výstupy.

Implementace založené na sadě SDK

Mnoho z těchto vzorů spoléhá na implementaci založenou na kódu, která řeší logiku orchestrace. Sady SDK, které podporují architekturu agenta, často poskytují podporu pro mnoho vzorů orchestrace agentů.

Microsoft Agent Framework

Sada MICROSOFT Agent Framework SDK obsahuje pokyny k implementaci orchestrace rozhraní Agent Framework.

• Sekvenční orchestrace pomocí rozhraní Agent Framework
• Souběžná orchestrace pomocí rozhraní Agent Framework
• Orchestrace předání pomocí rozhraní Agent Framework
• Magentická orchestrace pomocí rozhraní Agent Framework

Pro praktickou implementaci si projděte ukázky deklarativních pracovních postupů agenta na GitHubu, které demonstrují některé z těchto vzorů v praxi.

Sémantické jádro

Sada SDK sémantického jádra obsahuje pokyny k implementaci pro jeho architekturu agenta.

• Sekvenční orchestrace pomocí sémantického jádra
• Souběžná orchestrace pomocí sémantického jádra
• Orchestrace skupinového chatu pomocí sémantického jádra
• Orchestrace předání pomocí Semantického jádra
• Magentická orchestrace pomocí sémantického jádra

Pro praktickou implementaci si projděte ukázky orchestrace více agentů se sémantickým jádrem na GitHubu, které demonstrují tyto vzory v praxi.

Mnoho z těchto vzorů najdete také v autogenu, například Magentic-One.

Implementace ve službě Microsoft Foundry Agent

Pomocí služby Microsoft Foundry Agent můžete také zřetězovat agenty v relativně jednoduchých pracovních postupech pomocí funkcí připojených agentů. Pracovní postupy implementované pomocí této služby jsou primárně nedeterministické, což omezuje, které vzory lze plně implementovat v tomto prostředí bez kódu.

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autoři:

• Chad Kittel | Hlavní softwarový inženýr – Vzory a postupy Azure
• Clayton Siemens | Hlavní vývojář obsahu – Vzory a postupy Azure

Další přispěvatelé:

• Hemavathy Alaganandam | Hlavní softwarový inženýr
• James Lee | Datový vědec 2
• Ritesh Modi | Hlavní softwarový inženýr
• Mahdi Setayesh | Hlavní softwarový inženýr
• Mark Taylor | Hlavní softwarový inženýr
• Yaniv Vaknin | Vedoucí technický specialista

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se na LinkedIn.

Další krok

Implementace orchestrace agentů pomocí sémantického jádra