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í multiagent orchestrace 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 multiagent architektury a pomáhá zvolit přístup, který vyhovuje vašim konkrétním požadavkům.

Začněte správnou úrovní složitosti.

Než začnete využívat model orchestrace s více agenty, vyhodnoťte, jestli váš scénář vyžaduje jeden. Architektury agentů existují ve spektru složitosti a každá úroveň představuje koordinaci režie, latenci a náklady. Používejte nejnižší úroveň složitosti, která spolehlivě splňuje vaše požadavky.

Úroveň	Description	Kdy používat	Úvahy
Přímé volání modelu	Volání jednoho jazykového modelu s dobře vytvořenou výzvou. Žádná logika agenta, žádný přístup k nástrojům.	Model může dokončit klasifikaci, souhrn, překlad a další úkoly najednou.	Nejsložitější možnost. Pokud může prompt engineering vyřešit problém, nepotřebujete zprostředkovatele.
Jeden agent s nástroji	Jeden agent, který zdůvodní a vybere si z dostupných nástrojů, zdrojů znalostí a rozhraní API. Agent může procházet více volání modelu a vyvolání nástrojů za účelem upřesnění výsledků.	Agent může zpracovávat různé dotazy v rámci jedné domény, ve kterých některé požadavky vyžadují dynamické použití nástroje, například vyhledávání stavu objednávky nebo databázové dotazy.	Pro podnikové případy použití jsou často správné výchozí hodnoty. Jednodušší ladění a testování než nastavení s více agenty, ale stále podporuje dynamickou logiku. Pokud chcete chránit před nekonečnými smyčkami volání nástrojů, nastavte limity iterací.
Orchestrace multiagentů	Několik specializovaných agentů, kteří koordinuje řešení problémů. Orchestrátor nebo protokol založený na partnerském vztahu spravuje distribuci práce, sdílení kontextu a agregaci výsledků.	Agenti můžou zpracovávat problémy s různými funkcemi nebo mezi doménami, scénáře, které vyžadují jedinečné hranice zabezpečení pro každého agenta, a úlohy, které využívají paralelní specializace.	Zvyšuje zatížení koordinace, latenci a režimy selhání. Přidanou složitost můžete ospravedlnit, protože jeden agent nemůže spolehlivě zpracovat určité úlohy kvůli složitosti výzvy, přetížení nástrojů nebo požadavkům na zabezpečení.

Tato příručka se zaměřuje na vzory orchestrace na multiagentní úrovni, kde jsou nejdůležitější problémy koordinace.

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í.

Vzor sekvenční orchestrace se také označuje jako pipeline, řetězení výzev nebo lineární delegování.

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.

Souběžná orchestrace se také označuje jako paralelní, fan-out/fan-in, scatter-gather nebo map-reduce.

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. V případě potřeby agregace zvolte strategii, která odpovídá úkolu. Můžete například hlasovat nebo použít pravidlo většiny pro klasifikaci, využít vážené slučování pro skóre doporučení, nebo použít jazykem syntetizovaný model k sloučení výsledků do koherentního vyprávění.

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í. Orchestrátor musí vědět, kteří agenti jsou zaregistrovaní a k dispozici. 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.

Orchestrace skupinového chatu se také označuje jako kruhová tabulka, spolupráce, multiagent debata nebo rada.

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. Tento model podporuje různé režimy interakce, od volné debaty až po formální kontroly pracovních postupů, které používají pevné role a schvalovací brány.

Tento vzor funguje dobře pro scénáře HITL (human-in-the-loop), kde lidé mohou volitelně převzít odpovědnosti dynamického správce 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čí základní delegování úkolů nebo lineární zpracování kanálu.

• 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

Smyčka kontroly tvůrce je konkrétní typ orchestrace skupinového chatu, v němž agent tvůrce vytvoří nebo navrhne něco, a jiný agent, kontrolor, vyhodnotí výsledek podle definovaných kritérií. Pokud kontrola identifikuje mezery nebo problémy s kvalitou, odešle konverzaci zpět tvůrci s konkrétní zpětnou vazbou. Tvůrce reviduje svůj výstup a znovu odešle výsledek. Tento cyklus se opakuje, dokud kontrola neschválí výsledek nebo orchestrace dosáhne maximálního limitu iterace. 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.

Smyčky pro kontrolu maker se také označují jako vyhodnocovač- optimalizátor, generátor-ověřovatel, smyčky kritiky nebo smyčky reflexe.

Tento vzor vyžaduje jasná kritéria pro přijetí kontrolním agentem, aby mohl činit konzistentní rozhodnutí o úspěchu nebo neúspěchu. Nastavte omezení iterace, aby se zabránilo nekonečným smyčkám upřesňování. Definujte záložní chování pro případ dosažení tohoto omezení. Chování převzetí služeb při selhání může zahrnovat eskalaci na lidského recenzenta nebo upozornění na problémy s kvalitou spolu s nejlepším možným výsledkem.

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ů.

Orchestrace předání se také označuje jako směrování, třídění, přenos, odesílání nebo delegování.

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 vzor řeší scénáře, ve kterých optimální agent pro úlohu není předem známý nebo se požadavky úlohy během zpracování vyjasní. Umožňuje inteligentní delegování a zajišťuje, že úkoly dosáhnou nejschopnějšího agenta. 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:

• Vhodný agent nebo posloupnost agentů je identifikovatelný z počátečního vstupu. V takovém případě použijte deterministické směrování nebo jednodušší dispečer, který při zpracování nebere aktivní roli. Tento dispečer nejprve klasifikuje vstup a pak ho odešle příslušnému agentu.

• Směrování úkolů je deterministické a založené na pravidlech. Není založená na dynamických kontextových oknech ani dynamické interpretaci.

• 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 svých limitů, předá problémy jiným agentům. Například předá problémy se sítí agentu technické infrastruktury a předá fakturační spory agentům finančního řešení. 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 úspěch zákazníka je dosažen 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 pomůžou 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.

Magentická orchestrace se také označuje jako dynamická orchestrace, orchestrace založená na úlohách nebo adaptivní plánování.

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řeba k vytvoření kompletního plánu, který může úspěšně provést. Manažerský agent pravidelně kontroluje, jestli je původní požadavek splněný nebo pozastavený, a aktualizuje hlavní knihu, aby plány upravil.

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. Tento model se zaměřuje na vytváření a debatování realizovatelných plánů, ne na optimalizaci rychlosti.

• 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ů.

Zvolte vzor

Následující tabulka porovnává vzory orchestrace, které vám pomůžou identifikovat přístup, který odpovídá vašim požadavkům na koordinaci.

Vzor	Koordinace	Směrování	Nejvhodnější pro	Dávejte pozor na
Sekvenční	Lineární kanál. Každý agent zpracovává výstup předchozího agenta.	Deterministické, předdefinované pořadí	Podrobné upřesnění s jasnými závislostmi fází	Selhání v počátečních fázích se šíří. Žádný paralelismus.
Souběžný	Paralelní kanál Agenti pracují na stejném vstupu nezávisle.	Deterministický nebo dynamický výběr agenta	Nezávislá analýza z různých perspektiv. Scénáře citlivé na latenci	Vyžaduje řešení konfliktů, když jsou výsledky v rozporu. Náročné na prostředky.
Skupinové chaty	Konverzační kanál Agenti přispívají ke sdílenému vláknu.	Pořadí střídání kontroluje správce chatu.	Vytváření konsensu, brainstorming a iterativní ověřování kontrolorem.	Konverzační smyčky Obtížné ovládání s více agenty.
Předání	Model dynamického delegování Jeden aktivní agent najednou.	Agenti se rozhodnou, kdy převést řízení.	Úkoly, ve kterých se během zpracování objeví správný specialista.	Nekonečné smyčky předání. Nepředvídatelné cesty směrování
Magentický	Model plánování, stavba, realizace Agent manažerského systému vytváří a upravuje úkolový rejstřík.	Agent manažera dynamicky přiřazuje a mění pořadí úloh.	Otevřené problémy, které nemají předem stanovenou cestu řešení	Pomalu konverguje. Zastaví se na nejednoznačných cílech.

Na co myslet při implementaci

Abyste se vyhnuli běžným nástrahám a zajistili, že orchestrace agentů je robustní, zabezpečená a udržovatelná, projděte si následující aspekty při implementaci některého z těchto vzorů návrhu agentů.

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. Další informace najdete v tématu Začínáme se správnou úrovní složitosti. Protokoly, jako je protokol kontextu modelu , standardizují způsob zjišťování a vyvolání nástrojů agentů. 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.

Správa kontextu a stavu

Agenti umělé inteligence mají často omezená kontextová okna. Toto omezení může ovlivnit jejich schopnost zpracovávat složité úlohy, zejména když kontext roste s každým přechodem agenta. 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ší komprimovaná verze, například souhrn předchozích výstupů agenta. 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.

V multiagent orchestracích můžou kontextová okna rychle růst, protože každý agent přidává vlastní důvody, výsledky nástrojů a mezilehlé výstupy. Monitorujte kumulovanou velikost kontextu a mezi agenty používejte techniky komprimace, jako je sumarizace nebo selektivní vyřezávání. Tyto techniky vám můžou pomoct zůstat v mezích limitů modelu a vyhnout se snížení kvality odpovědí.

V případě orchestrací, které zahrnují více interakcí uživatelů nebo dlouhotrvajících úloh, zachovají sdílený stav externě, místo aby se spoléhaly pouze na kontext v paměti. Pokud chcete agentům umožnit pokračovat v práci po přerušení, ukládat průběh úkolů, průběžné výsledky a historii konverzací v trvalém úložišti. Aby se snížila režie tokenů a rizika ochrany osobních údajů, omezte rozsah trvalého stavu na nejmenší potřebné informace.

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.

• Chyby odhalujte místo toho, abyste je skrývali, aby podřízení agenti a logika orchestrátoru mohli reagovat odpovídajícím způsobem.

• Než ho předáte dalšímu agentu, ověřte výstup agenta. Odpovědi s nízkou spolehlivostí, špatně strukturovaným nebo mimo téma se mohou kaskádovitě šířit skrz pipeline. Orchestrátor nebo přijímající agent by měli zkontrolovat kvalitu výstupu a buď opakovat, požádat o objasnění nebo zastavit pracovní postup, aby se zabránilo chybnému šíření vstupu.

• 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 může jeden model jako koncový bod služby (MaaS) nebo sdílené úložiště znalostí zavést omezování rychlosti při paralelním 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.

• Použijte bezpečnostní mantinely obsahu v několika bodech orchestrace, včetně vstupu uživatele, volání nástrojů, odpovědí nástroje a konečného výstupu. Zprostředkující agenti mohou zavést nebo rozšířit škodlivý obsah.

Optimalizace nákladů

Multiagent orchestrace násobí vyvolání modelu a každý agent využívá tokeny pro své instrukce, kontext, odůvodnění a interakce nástrojů. Model, který zvolíte, má přímý vliv na náklady. Sekvenční a předávací vzory vyvolávají agenty jednotlivě, což omezuje souběžné využití prostředků, ale shromažďuje náklady v jednotlivých krocích. Souběžné vzory zvyšují propustnost, ale můžou zvýšit spotřebu prostředků, když více agentů vyvolává modely současně. Magentické orchestrace jsou nejvíce proměnlivé, protože agent manažera pokračuje iterací, dokud nevytvoří realizovatelný plán, což znesnadňuje predikci celkových nákladů.

Pro spravování nákladů v multiagentních orchestracích:

• Přiřaďte každému agentu model, který odpovídá složitosti jeho úlohy. Ne každý agent vyžaduje nejschopnější model. Agenti, kteří provádějí klasifikaci, extrakci nebo formátování, můžou často používat menší a levnější modely bez snížení celkové kvality.

• Pokud chcete zjistit, které agenty nebo vzory jsou nejnáročnější, monitorujte spotřebu tokenů na agenta a provedení orchestrace. Tato data použijte k cílení na úsilí o optimalizaci.

• Pokud chcete snížit objem tokenu předaný prostřednictvím orchestrace, použijte mezi agenty komprimaci kontextu. Další informace najdete v tématu Správa kontextu a stavu.

Pozorovatelnost a testování

Distribuce systému AI napříč několika agenty vyžaduje monitorování a testování jednotlivých agentů a systém jako celek, aby se zajistila správná funkčnost. 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 víceagentní pracovní postupy. Výstupy agenta nejsou deterministické, proto místo přesných kontrolních výrazů shody používejte hodnoticí kritéria nebo vyhodnocení jazykového modelu jako rozhodčího.

Lidská účast

Několik vzorů orchestrace podporuje zapojení HITL . Mezi formy HITL patří pozorovatelé ve skupinovém chatu, kontroloři ve smyčce maker-checker a cíle pro eskalaci v předání a magnetických orchestracích. Určete, které body vyžadují lidský vstup, rozhodněte, zda je tento vstup nepovinný nebo povinný, a určete, zda lidská odpověď představuje schválení, které posouvá pracovní proces, nebo zda jde o zpětnou vazbu, která se vrátí k agentovi k dalšímu upřesnění. Povinná hradla v daném kroku zajistí synchronní orchestraci, takže zachování stavu na těchto kontrolních bodech pro obnovení operace bez přehrání předchozí práce agenta. Brány HITL můžete také vymezit na konkrétní vyvolání nástrojů, nikoli na úplné výstupy agentů, aby orchestrace mohly samostatně pokračovat v akcích s nízkým rizikem. V tomto stavu se schválení vyžaduje jenom pro citlivé operace.

Běžné nástrahy a antipatterny

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čila základní 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

Tyto vzory orchestrace jsou nezávislé na technologiích. Můžete je implementovat pomocí různých sad SDK a platforem v závislosti na vašich jazycích, infrastruktuře a požadavcích na integraci.

Agentní rámec

Agent Framework je opensourcová sada SDK, která vám může pomoct sestavovat multiagent orchestrace na platformě Microsoft. Agent Framework poskytuje integrovanou podporu pro následující orchestrace pracovních postupů:

• Sekvenční orchestrace
• Souběžná orchestrace
• Orchestrace skupinového chatu
• Orchestrace předání
• Magentická orchestrace

Návod

Tyto orchestrace podporují funkce HITL pro schvalování a zpětnou vazbu při provádění pracovních postupů.

Praktickou implementaci najdete na GitHubu s využitím declarativních pracovních postupů Agent Framework.

Sémantické jádro nadále poskytuje podporu orchestrace agentů. Pokud už máte úlohy Sémantické jádro, postupujte podle návodu migrace a přejděte na Agent Framework.

Služba agenta Foundry

Služba Foundry Agent Service poskytuje spravovaný přístup bez kódu ke řetězům agentů pomocí jeho funkce připojených agentů . Pracovní postupy v této službě jsou primárně nedeterministické, což omezuje rozsah vzorů, které můžete plně implementovat. Službu agenta použijte, když potřebujete spravované prostředí a požadavky na orchestraci jsou jednoduché.

Další rámce

Vzory orchestrace popsané v tomto článku nejsou specifické pro sady SDK Microsoft. Mezi další architektury, které podporují multiagentní orchestraci, patří LangChain, CrewAI a OpenAI Agents SDK. Každá architektura má svůj vlastní přístup k implementaci vzorů a můžete použít pokyny k architektuře v tomto článku bez ohledu na vámi zvolenou sadu SDK.

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 – Azure Vzory a Praktiky
• Clayton Siemens | Vedoucí vývojář obsahu – Azure vzorů a postupů

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 k LinkedIn.

Další krok

Implementace orchestrace agentů pomocí rozhraní Agent Framework