Проєктування багатоагентних систем на A2A: вузли, пам’ять та управління
Архітектура для систем з кількома агентами, побудована на протоколі A2A, яка охоплює модулі агентів, типи пам’яті, оркестрацію, ризики для безпеки та чек-лист для проектування.
Як тільки у компанії стає більше кількох штучних інтелектуальних агентів у експлуатації, складні проблеми вже не стосуються формулювання запитів, а пов’язані з архітектурою: як агенти спілкуються між собою, де знаходиться їхній стан, хто координує їх дії та як перевіряти їхню роботу. У цій статті наведено основні принципи такої системи, де в якості основи комунікації використовується протокол Agent-to-Agent (A2A). До кінця ви зможете розуміти основні елементи окремого агента, шари пам’яті та оркестрації, які об’єднують багато агентів, механізми керування, необхідні для мережі з багатьох агентів, а також фактори, які потрібно враховувати під час планування масштабування.
Основна зміна полягає у переході від генеративних систем до агентних. Генеративний ШІ працює за принципом запиту: людина ставить запит, модель створює контент, і взаємодія закінчується. Агентний ШІ керується цілями: система отримує загальну мету, розділяє її на менші підцілі та виконує їх майже без участі людини. Практичним наслідком для архітекторів є зміна масштабу роботи. Генеративні моделі автоматизують окремі завдання, тоді як агентні системи можуть автоматизувати цілі процеси, перетворюючи ШІ з інструменту, який реагує, на представника, який діє. Саме це уможливлює масштабування операцій, які раніше вимагали постійного контролю за кожним кроком. Якщо ви хочете детальніше дізнатися про цю термінологію, перегляньте пояснення агентного ШІ від мовних моделей до автономних агентів.
Пробабілістичні двигуни та формальні міркувальники
У центрі кожного агента знаходиться модель прийняття рішень — зазвичай це велика мовна модель або велика модель зображень для візуальних завдань. Ці моделі є вероятнісними. Вони генерують плавні, переконливі результати, але можуть створювати хибну інформацію, причому плавність не є тотожною правильності. Формальні системи, такі як розумники онтологій OWL чи байєсові мережі, функціонують інакше: їхні висновки ґрунтуються на чітких правилах та ймовірностях, тому вони є математично надійними у своїй сфері. Надійний дизайн використовує кожен з цих інструментів там, де він є найсильнішим.
Той самий прагматизм стосується і глибини міркувань. Техніки на кшталт запитів у форматі „ланцюга думок“ підвищують точність, змушуючи модель працювати через проміжні кроки, але кожен додатковий крок збільшує затримку та енергоспоживання. Глибші міркування не є безкоштовними, а оптимальна глибина залежить від швидкості реакції системи. Коли у вас є багато таких агентів, кожен з власною моделлю та стилем міркувань, потрібен спільний спосіб їхнього взаємодіяння. Саме для цього існує A2A.
A2A як шар взаємодійності
A2A був запропонований у 2025 році як відкритий протокол для агентів, створених за допомогою різних фреймворків та компаніями-виробниками, щоб вони могли працювати разом. Його мета — запобігти роз’єднанню багатоагентних систем на ізольовані структури, притаманні конкретним виробникам: агенти, створені за допомогою різних фреймворків або розміщені у різних компаніях, можуть обмінюватися контекстом та координувати свою роботу через єдиний інтерфейс. Його впровадження все ще розвивається, тому перевіряйте поточну специфікацію перед тим, як приймати остаточні рішення.
П’ять принципів проектування
- Ставитися до агентів як до агентів. Протокол передбачає, що учасники можуть самостійно міркувати та діяти, а не лише відповідати на окремі запити. Це відкриває шлях до співпраці заради довгострокових цілей, а не лише до простої взаємодії запит-відповідь.
Дотримання цих принципів захищає від двох класичних способів збою: невдач у координації, коли агенти не діють синхронно, та розбіжностей між агентами, коли децентралізовані учасники поступово відхиляються від спільної мети. Ці принципи конкретизуються в кожному агенті через модульний цикл сприйняття, міркувань та дії.
Усередині окремого вузла агента
Кожен вузол працює за замкнутим циклом вхідних даних, обробки, дій та навчання. Оскільки цей цикл повертає результати назад у внутрішній стан агента, вузол залишається обізнаним про своє середовище та адаптується, замість того щоб механічно виконувати фіксований скрипт.
Чотири підсистеми
- Сприйняття. Цей шар отримує сигнали всіх типів: запити природною мовою, потоки подій API, зображення. Він використовує технологію генерації з підтримкою пошуку даних (RAG), щоб закріпити ці дані у реальних фактах перед тим, як вони потраплять до шару міркувань.
- Представлення знань та міркування (KRR). Тут наміри інтерпретуються за допомогою поєднання статистичних та символічних методів. Модель мови обробляє нюанси та неоднозначності, тоді як формальні перевірки дозволяють підтвердити, що отриманий план є логічно послідовним.
- Вибір дії та її виконання. Рішення перетворюються на конкретні результати через визначений каталог викликів API або зовнішніх повідомлень. Це межа, де міркування агента торкаються цифрового чи фізичного світу.
Основним шаблоном виконання є ReAct — скорочення від reasoning plus acting. Агент по черзі думає про наступний крок та спостерігає за результатом дії, що забезпечує його міркування на основі того, що фактично сталось. Недоліком є те, що кожен етап міркувань вимагає ще одного запиту до моделі, тож ці цикли збільшують витрати на обробку та час відповіді, що потрібно враховувати під час планування. Те, що зберігає послідовність між кроками та сеансами, — це пам’ять.
Постійна пам’ять протягом часу
Моделі мови є безстановими: кожен виклик знає лише те, що знаходиться в його контексті. Для планування на довгий період саме постійна пам’ять об’єднує окремі кроки. Без неї агенти забувають про досягнуті результати під час багатоетапних завдань або коли робота передається між сеансами, що призводить до повторної роботи та нестабільних систем.
Три види пам’яті
- Епізодична пам’ять фіксує те, що відбулося під час певного завдання, включаючи кроки міркувань та невдалі спроби, усе це протягом одного сеансу.
- Семантична пам’ять зберігає стабільні факти та структуровані організаційні знання, якими може скористатися кожне завдання.
- Пам’ять на основі векторів призначена для пошуку за схожістю, дозволяючи агентові знаходити релевантний контекст у дуже великих колекціях за допомогою RAG.
Ці елементи потрібно тримати окремо, оскільки вони мають різний термін існування та шаблони доступу. Епізодична пам’ять є короткочасною та пов’язаною з конкретним завданням, семантична пам’ять — довготривалою та систематизованою, а сховища векторів оптимізовані для нечіткого пошуку, а не для точного знаходження інформації.
Спільний контекст для передачі завдань
У масштабних системах агентам також потрібні буфери спільного контексту. Коли один агент передає підзавдання іншому, буфер містить всю необхідну інформацію про фон та поточний стан, щоб отримувач міг продовжити роботу без початку з нуля. Розподіл стану у такий спосіб, у свою чергу, вимагає наявності координаційного шару над окремими агентами.
Оркестрація та розбиття цілей
У міру зростання систем одна універсальна модель поступається місцем ансамблю спеціалістів. Призначення певних ролей — наприклад, агента, який планує як генеральний директор, агента, який пише код, та агента, який його перевіряє — зазвичай забезпечує кращу точність та глибину роботи, ніж коли одна модель має виконувати все сама.
Що робить мета-агент
Мета-агент, або оркестратор, керує цим ансамблем. Його обов’язки включають:
- Призначення кожного підзавдання агенту, який найкраще підходить для його виконання.
- Керування залежностями, щоб результати надходили у правильне місце у правильному порядку.
- Вирішення конфліктів, коли агенти дають суперечливі результати чи конкурують за одні й ті самі ресурси.
Планування за допомогою Дерева думок
Оркестрація залежить від розбиття мети на підмети. Підходи до планування, такі як «Дерево думок», досліджують кілька варіантів міркувань замість того, щоб обмежуватися однією послідовністю дій, що допомагає подолати невизначеність та зменшує крихкість та галюцинації, до яких схильні плани з одним шляхом. Однак дослідження кількох варіантів також збільшує кількість викликів моделі, тож це поглиблює проблему затримок, про яку йшлося раніше.
Існує ще один ризик — емергентна поведінка. Коли багато автономних агентів взаємодіють нелінійними способами, система може створювати результати, які ніхто не проєктував та не передбачав. Оркестрація зменшує цей ризик, але не усуває його повністю, тому керування має бути частиною архітектури, а не щось, що додається пізніше.
Безпека та керування
- Ланцюгові помилки. Галюцинація чи помилка на ранньому етапі обробки даних передається далі та спотворює кінцеве рішення. Стаття про запобігання посиленню галюцинацій у графах агентів детально розглядає цей спосіб збою.
- Атаки зловмисників. Вставка спеціальних запитів чи отруєння моделі можуть перервати діяльність агента.
- Поширення упереджень. Агенти можуть посилити спотворені закономірності в даних, що призводить до систематично несправедливих результатів.
Архітектура, з оглядом на управління
Три механізми допомагають подолати більшість цих ризиків:
- Ізоляція ролей обмежує повноваження кожного агента та API, які він може використовувати, тож агент, який потрапив під загрозу, може завдати лише обмеженої шкоди.
- Логування рішень із можливістю відстеження фіксує кожен крок міркувань, щоб збої можна було перевірити та присвоїти їм винуватця.
- Аутентифікація агентів перевіряє ідентичність кожного учасника робочого процесу.
Окрім цього, рівень формальної верифікації відокремлює те, що звучить правильно, від того, що є логічно обґрунтованим. Це архітектурна відповідь на переконливу, але ненадійну природу мовних моделей, описаних на початку.
Куди це прямує: проактивний інтелект та AZR
У міру злиття модульних агентів та оркестрованих агентських систем наступним кроком є проактивний інтелект – системи, які помічають сигнали у своєму середовищі та запускають робочі процеси ще до того, як хтось цього попросить.
Одним із напрямків досліджень, пов’язаних із цим, є парадигма абсолютного нуля (AZR). Замість навчання на прикладах, позначених людьми, вона вдосконалюється через посилене самонавчання, створюючи власні задачі та міркування без зовнішніх даних для навчання. Те, що утримує цей підхід у реальності, – це перевірна зворотна взаємодія, така як запуск створеного коду чи перевірка формальних доведень, яка замінює людську анотацію як джерело істини. Вважайте це активною галуззю досліджень, а не технологією, готовою до використання.
Чек-лист проектування
Перш ніж масштабувати багатоагентну систему, перевірте її проектування з урахуванням цих запитань:
- Формальна перевірка: Чи існує логічний шар, який відрізняє переконливий результат роботи моделі від результатів, що є справді коректними?
- Розділення пам’яті: Чи чітко розділені епізодичні, семантичні та векторні сховища даних?
- Стандарт протоколу: Чи вся комунікація між різними фреймворками та постачальниками відбувається через A2A?
- Контролі управління: Чи активовано ізоляцію ролей та облік рішень для кожного автономного вузла?
- Бюджет затримки: Чи було виміряно та налаштовано співвідношення між глибиною міркувань, наприклад за допомогою концепції „Дерево думок“, та часом відповіді?
Основні висновки
- Системи з кількома агентами переносять акцент з створення інструментів для відповідей на запитання на створення екосистем, які самостійно вирішують проблеми, і ця зміна є архітектурною.
Пов’язана література
- Agent = Model + Harness: Де насправді походить надійна поведінка ШІ — Дізнайтеся, що таке механізм harness для ШІ-агента, чому стан, авторитет та верифікація належать поза межами моделі, та які елементи стануть непотрібними з покращенням моделей.
- Проектування чотирирівневої пам’яті агента з використанням LangGraph та Amazon Bedrock — Дізнайтеся, як надати агентам LLM функціональну епізодичну, семантичну та процедурну пам’ять на платформах Bedrock та LangGraph, а також як захистити її від отруєння, витоку персональних даних та інших проблем.
- Ескалація по вузлам, а не за завданнями: шестирівнева сходинка для контролю витрат на роботу LLM — Чому вибір між DAG та агентом на кожне завдання підвищує витрати на LLM, та як схема ескалації по вузлам із контрактами, обмеженнями та бюджетами допомагає їх контролювати.
- Інтерфейс чату чи цикл агента? Як визначити, що потрібно вашій функції ШІ — Дізнайтеся, як відрізнити чат-бота для розмов від агента, орієнтованого на досягнення цілей, що додає цикл агента та як вирішити, що насправді потрібно вашій функції ШІ.
- Реєстри агентів повідомляють про те, що існує, а не про те, чи можна йому все ще довіряти — Чотири запитання для оцінки реєстрів можливостей агентів, які охоплюють наявність, придатність, статус та походження, а також простий тест останньої перевірки, який ви можете провести сьогодні.