Гэта пераклад артыкула з LangChain Blog.

Арыгінал: https://blog.langchain.com/choosing-the-right-multi-agent-architecture/

У гэтым артыкуле мы разгледзім, калі мульты-агентныя архітэктуры становяцца неабходнымі, чатыры асноўныя шаблоны, якія мы назіраем, і тое, як LangChain дазваляе эфектыўна будаваць мульты-агентныя сістэмы.

Шматлікія агенцкія задачы лепш за ўсё вырашаюцца адным агентам з добра распрацаванымі інструментамі. Варта пачаць з гэтага — адзіночныя агенты прасцей у стварэнні, разуменні і адладцы. Але па меры маштабавання прыкладанняў каманды сутыкаюцца з агульнай праблемай: у іх ёсць разрозненыя магчымасці агентаў, якія яны хочуць аб'яднаць у адзіны ўзгоднены інтэрфейс. Па меры росту колькасці функцый узнікаюць два асноўныя абмежаванні:

1. Кіраванне кантэкстам: Спецыялізаваныя веды для кожнай здольнасці не могуць камфортна змясціцца ў адным прампце (падказцы). Калі б вокны кантэксту былі бясконцымі, а затрымка нулявой, вы маглі б уключыць усю адпаведную інфармацыю адразу. На практыцы патрэбныя стратэгіі для выбарачнага прадастаўлення інфармацыі па меры працы агентаў.
2. Размеркаваная распрацоўка: Розныя каманды распрацоўваюць і падтрымліваюць кожную здольнасць незалежна, з выразнымі межамі і адказнасцю. Адзіны маналітны прампт агента становіцца цяжкім для кіравання рознымі камандамі.

Гэтыя абмежаванні становяцца крытычнымі, калі вы кіруеце шырокімі даменнымі ведамі, каардынуеце працу каманд або вырашаеце сапраўды складаныя задачы. У такіх выпадках мульты-агентныя архітэктуры могуць стаць правільным выбарам.

Мульты-агентныя архітэктуры

Чатыры архітэктурныя шаблоны складаюць аснову большасці мульты-агентных прыкладанняў: Subagents, Skills, Handoffs і Routers. Кожны з іх выкарыстоўвае розны падыход да каардынацыі задач, кіравання станам і паслядоўнага адкрыцця магчымасцей.

Subagents: Цэнтралізаваная аркестроўка

У шаблоне Subagents агент-назіральнік (supervisor) каардынуе спецыялізаваных субагентаў, выклікаючы іх як інструменты. Галоўны агент захоўвае кантэкст размовы, у той час як субагенты застаюцца без стана (stateless), забяспечваючы моцную ізаляцыю кантэксту.

• Як гэта працуе: Галоўны агент вырашае, якіх субагентаў выклікаць, якія ўваходныя дадзеныя даць і як аб'яднаць вынікі. Субагенты не памятаюць мінулых узаемадзеянняў. Гэтая архітэктура забяспечвае цэнтралізаванае кіраванне, дзе ўся маршрутызацыя праходзіць праз галоўнага агента, які можа выклікаць некалькі субагентаў паралельна.
• Лепш за ўсё падыходзіць для: Прыкладанняў з некалькімі рознымі даменамі, дзе неабходны цэнтралізаваны кантроль працоўнага працэсу, і субагенты не павінны размаўляць непасрэдна з карыстальнікамі. Прыклады ўключаюць персанальных асістэнтаў, якія каардынуюць каляндар, электронную пошту і CRM-аперацыі, або даследчыя сістэмы, якія дэлегуюць задачы спецыялізаваным даменным экспертам.
• Асноўны кампраміс: Дадае адзін дадатковы выклік мадэлі на ўзаемадзеянне, таму што вынікі павінны праходзіць назад праз галоўнага агента. Гэтыя накладныя выдаткі забяспечваюць цэнтралізаваны кантроль і ізаляцыю кантэксту, але каштуюць затрымкі (latency) і токенаў.

Skills: Прагрэсіўнае раскрыццё

У шаблоне Skills агент загружае спецыялізаваныя прампты і веды па запыце. Думайце пра гэта як пра прагрэсіўнае раскрыццё магчымасцей агента.

• Як гэта працуе: Skills — гэта ў асноўным спецыялізацыі на аснове прамптоў, спакаваныя ў каталогі, якія змяшчаюць інструкцыі, скрыпты і рэсурсы. Пры запуску агент ведае толькі назвы навыкаў і апісанні. Калі навык становіцца актуальным, агент загружае яго поўны кантэкст. Дадатковыя файлы ўнутры Skills забяспечваюць трэці ўзровень дэталізацыі, які агент выяўляе толькі па меры неабходнасці.
• Лепш за ўсё падыходзіць для: Адзіночных агентаў з вялікай колькасцю магчымых спецыялізацый, сітуацый, дзе не трэба ўводзіць абмежаванні паміж магчымасцямі, або размеркавання каманд, дзе розныя каманды падтрымліваюць розныя Skills. Тыповыя прыклады ўключаюць агентаў для напісання кода або творчых асістэнтаў.
• Асноўны кампраміс: Кантэкст назапашваецца ў гісторыі размоў па меры загрузкі навыкаў, што можа прывесці да раздзімання токенаў (token bloat) пры наступных выкліках. Аднак гэты шаблон забяспечвае прастату і прамое ўзаемадзеянне з карыстальнікам на працягу ўсяго часу.

Handoffs: Пераходы на аснове стана

У шаблоне Handoffs актыўны агент дынамічна змяняецца ў залежнасці ад кантэксту размовы. Кожны агент мае магчымасць перадаваць кіраванне іншым праз выклік інструментаў.

• Як гэта працуе: Калі агент выклікае інструмент Handoff, ён абнаўляе стан, які вызначае наступнага агента для актывацыі. Гэта можа азначаць пераключэнне на іншага агента або змену сістэмнага прампта бягучага агента і даступных інструментаў. Стан захоўваецца паміж раўндамі размовы, што дазваляе ствараць паслядоўныя працоўныя працэсы (workflow).
• Лепш за ўсё падыходзіць для: Патокаў падтрымкі кліентаў, якія збіраюць інфармацыю паэтапна, шматступенных размоўных досведаў, або любога сцэнара, які патрабуе паслядоўных абмежаванняў, дзе магчымасці адкрываюцца толькі пасля выканання папярэдніх умоў.
• Асноўны кампраміс: Больш залежны ад стана, чым іншыя шаблоны, патрабуе ўважлівага кіравання станам. Аднак гэта дазваляе весці плыўныя шматкрокавыя (multi-turn) размовы, дзе кантэкст натуральна пераносіцца паміж этапамі.

Router: Паралельная адпраўка і сінтэз

У шаблоне Router крок маршрутызацыі класіфікуе ўваходныя дадзеныя і накіроўвае іх спецыялізаваным агентам, выконваючы запыты раўналежна і сінтэзуючы вынікі.

• Як гэта працуе: Router дэкампазіруе запыт, выклікае нуль або некалькі спецыялізаваных агентаў паралельна, і сінтэзуе вынікі ў звязны адказ. Routers звычайна не маюць стана (stateless), апрацоўваючы кожны запыт незалежна.
• Лепш за ўсё падыходзіць для: Прыкладанняў з рознымі вертыкалямі (асобныя галіны ведаў), сцэнараў, якія патрабуюць запытаў да некалькіх крыніц адначасова, або сітуацый, дзе трэба сінтэзаваць вынікі ад некалькіх агентаў. Прыклады ўключаюць карпаратыўныя базы ведаў і шматвертыкальныя асістэнты падтрымкі кліентаў.
• Асноўны кампраміс: Дызайн без стана азначае нязменную прадукцыйнасць на запыт, але паўтаральныя выдаткі на маршрутызацыю, калі вам патрэбна гісторыя размоў. Гэта можа быць змякчэна шляхам абгортвання Router як інструмента ўнутры размоўнага агента са станам.

Супастаўленне патрабаванняў з шаблонамі

Патрабаванне	Шаблон
Некалькі розных даменаў (каляндар, пошта, CRM), патрабуецца паралельнае выкананне	Subagents
Адзін агент з мноствам магчымых спецыялізацый, лёгкая кампазіцыя	Skills
Паслядоўны працоўны працэс са зменай станаў, агент размаўляе з карыстальнікам ўвесь час	Handoffs
Розныя вертыкалі, запыт да некалькіх крыніц паралельна і сінтэз вынікаў	Router

Характарыстыкі прадукцыйнасці

Выбар архітэктуры наўпрост уплывае на затрымку, кошт і карыстальніцкі досвед.

Scenario 1: One-shot request

Scenario 2: Repeat request

Scenario 3: Multi-domain query

• Аднаразовы запыт: Handoffs, Skills і Router найбольш эфектыўныя.
• Паўторны запыт: Шаблоны са станам (Handoffs, Skills) эканомяць 40-50% выклікаў на паўторных запытах, захоўваючы кантэкст.
• Шматдаменны запыт: Шаблоны з паралельным выкананнем (Subagents, Router) найбольш эфектыўныя. Skills маюць менш выклікаў, але высокае выкарыстанне токенаў з-за назапашвання кантэксту.

З чаго пачаць

У многіх выпадках простыя архітэктуры часта дастатковыя. Пачніце з аднаго агента і добрай распрацоўкі прамптоў (prompt engineering). Дадавайце інструменты перад даданнем агентаў. Пераходзьце да мульты-агентных шаблонаў толькі тады, калі вы сутыкнецеся з відавочнымі абмежаваннямі.

Крыніца: https://blog.langchain.com/choosing-the-right-multi-agent-architecture/