Чому агенти не домовляються: де ламається Agent-to-Agent Protocol
Поки агентів два, зв'язка тримається на домовленостях усередині інструкцій. Щойно в ланцюжку п’ять-сім учасників, ламається не модель, а обмін: кожен упевнений, що передав завдання коректно, а наступний бачить уже інше формулювання.
Частина умов — обмеження, терміни, ідентифікатори сутностей — губиться під час переказу, і помилка випливає через два-три кроки.
Друге вузьке місце — неузгоджений обмін завданнями. Якщо відповідь не надійшла вчасно, агент-ініціатор надсилає завдання повторно, а виконавець не відрізняє повтор від нової роботи й виконує її двічі.
Так з’являються дублі: два записи, два листи, подвійне підтвердження — за повної впевненості обох сторін, що вони зробили саме те, про що просили.
Третє — втрата контексту між агентами. Результат повертається в гілку діалогу, яка вже закрита або перевикористана під інше завдання, і відповідь осідає «в нікуди».
Сторона-ініціатор не отримує ні результату, ні помилки: агент просто чекає, а збій у ланцюжку агентів виявляється за непрямими ознаками — завислою чергою або порожнім звітом.
Звідси завислі ланцюжки: без явних підтверджень і граничного часу очікування ніхто не знає, працює виконавець чи вже впав. Чим довша зв’язка, тим дорожча діагностика — стани завдань живуть у різних журналах, і відновити причину постфактум майже неможливо.
Agent-to-Agent Protocol закриває саме цей шар: у кожного агента з’являється оголошена роль і контракт повідомлення, завдання отримує ідентифікатор і стан, відповідь — підтвердження доставки. Розбираємо, з чого складається інтеграція AI-агентів, яка не розсипається на третьому кроці.
Що дає керована взаємодія агентів у робочому контурі
У керованому контурі агент не викликає іншого агента напряму — він реєструє в реєстрі агентів картку з описом умінь, форматів входу й виходу та меж відповідальності.
Диспетчеризація завдань зіставляє картку з конкретним запитом і маршрутизує виклик, тому зв’язки між учасниками стають даними, а не жорстко зашитим кодом.
Практичний ефект видно на підключенні нового агента: реєстрація картки й прогін за контрольним набором завдань займають години замість тижнів переписування інтеграцій, а на кожній стиковці вивільняються дні роботи інженерів.
Частка завдань, що доходять до кінця без ручного втручання, зростає з ~70% до 95% — завдяки повторенням зі збереженням проміжного стану та явним перевіркам результату на кожному кроці.
Окремо закривається відновлення після збою агента: незавершений крок повертається в чергу разом із контекстом і повторюється на резервному виконавці, а не починається з нуля.
Диспетчер при цьому сам є єдиною точкою відмови, тому його розгортають у кількох екземплярах, а стан завдання тримають у спільному журналі, доступному кожному вузлу.
Такий контур описує відкрита специфікація Agent-to-Agent, розвиток якої курирує Linux Foundation: замовник не прив’язується до одного постачальника агентів і змінює виконавця, не перебудовуючи оркестрацію цілком.
Режими роботи Agent-to-Agent Protocol та їхні обмеження
Режим обміну в Agent-to-Agent Protocol — не смаковий вибір, а рішення про те, які відмови ви отримаєте першими і наскільки дешево їх діагностувати. Прямий виклик агента дає мінімальну затримку, але жорстко зв’язує учасників: недоступність одного зупиняє весь ланцюжок.
Асинхронні схеми знімають зв’язність, зате переносять складність в інше місце. Шина подій потребує ідемпотентних обробників і дедуплікації — інакше повтори й загублені завдання.
Централізований оркестратор тримає маршрути в одному вузлі: налагодження простіше, але це й єдина точка відмови. У федерації немає посередника, зате узгодження схем і прав доступу розходиться по командах.
Чотири режими обміну
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Прямий виклик агента | Синхронний сценарій, 2-3 учасники | Жорстка зв’язність, немає історії обміну |
| Шина подій | Багато незалежних агентів, довгі завдання | Потрібні дедуплікація та підтвердження, порядок не гарантовано |
| Централізований оркестратор | Регламент, аудит, права за кроками | Єдина точка відмови, стеля за навантаженням |
| Федерація агентів | Крос-доменні сценарії, різні власники | Узгодження схем і довіри, розподілена діагностика |
На практиці режими комбінують: федерація на периметрі, оркестратор усередині контуру, шина — для довгих завдань. Ми починаємо з матриці сумісності: які агенти вже є, які версії а2а-протоколу та формати описів вони підтримують, що відбувається за недоступності сусіда. Опишіть завдання — повернемося з оцінкою та планом.
Етапи впровадження: від аудиту схеми до передачі в експлуатацію
Порядок робіт фіксуємо до старту: кожен етап закінчується артефактом, який замовник бачить і може перевірити. Це прибирає головну причину зривів — інтеграцію, яку збирають одразу в робочому контурі й потім місяцями налагоджують.
- Аудит агентної схеми. Розбираємо наявних агентів, їхні зони відповідальності та поточні способи обміну. На виході — карта: хто до кого звертається, які дані передає і де зараз губиться контекст.
- Проєктування обміну. Фіксуємо структури повідомлень, правила ідентифікації завдань і поведінку за недоступності сусіда. Обмін будуємо на Agent-to-Agent Protocol — відкритому стандарті, тому схему не доведеться переписувати у разі зміни моделей або постачальників.
- Налаштування маршрутизації та прав. Визначаємо, хто кому може делегувати завдання, які виклики заборонені та на яких лімітах агент зупиняється сам, не витягуючи ресурси з інших.
- Складання в тестовому контурі. З’єднуємо агентів на копії реальних даних і прогоняємо штатні та аварійні сценарії: обриви зв’язку, дублі, повторну доставку.
- Приймання інтеграції під навантаженням. Дивимося, як схема тримається на піковому потоці та що відбувається за відмови одного вузла. Критерії вимірювані: частка успішних обмінів, час відповіді, частка завдань, що дійшли до результату.
- Передача в експлуатацію. Віддаємо регламенти, схеми маршрутів, панелі моніторингу та порядок розбору інцидентів. Команда замовника змінює маршрути й додає агентів без нас.
Артефакти проєкту: реєстр агентів, схеми та політики доступу
Проєкт з інтеграції агентів закінчується не показом сценарію, а набором артефактів у вашому репозиторії.
Ми передаємо не «працюючий сервіс як є», а конфігурації, схеми та регламенти, за якими ваша команда сама змінює зв’язки між агентами й права доступу — без нас і без повторного складання інтеграції за Agent-to-Agent Protocol. Нижче — перелік того, що фізично залишається в замовника.
- Реєстр агентів: призначення, власник, вхідні та вихідні формати повідомлень, обмеження за навантаженням, версія картки.
- Схема взаємодії агентів: хто з ким спілкується, які виклики синхронні, де стоять черги, таймаути й точки відмови.
- Політики доступу агентів: матриця «агент — ресурс — дія», термін життя облікових даних, порядок відкликання прав під час виведення агента.
- Регламент ескалації: які класи завдань агент не бере, кому передає діалог і за якою ознакою розуміє, що потрібна людина.
- Конфігурації: параметри запуску, ліміти, повторні спроби, правила маршрутизації запитів між моделями.
- Документація з агентів: як підключити нового агента, змінити політику й прогнати контрольні приклади перед випуском.
- Передача знань: пакет онбордингу для команди, розбір спірних сценаріїв, спільне редагування регламентів.
Усе це версіонується разом із кодом: за наступної зміни видно, яка політика або схема до неї привела. Якщо хочете звірити склад таких артефактів зі своїм завданням — опишіть його, повернемося з оцінкою та планом.
Кейс: ланцюжок із семи агентів — метрики до і після
Ланцюжок із семи агентів — збір, нормалізація, вилучення, валідація, збагачення, маршрутизація, звітність — працював на самописних зв’язках, де вихід одного етапу передавався наступному прямим викликом.
Обрив у середині руйнував весь контур: контекст губився, частина даних оброблялася повторно, інженер вручну перезапускав етапи й звіряв стан.
Перевели взаємодію на Agent2Agent — відкриту специфікацію обміну, де кожен агент публікує картку своїх можливостей, а завдання живе як об’єкт з ідентифікатором і статусом.
Що змінили
Кожен перехід отримав ідемпотентність і обмежену кількість повторів, стан завдання фіксується на кожному кроці, а трасування за ідентифікатором показує, де саме зупинився ланцюжок. Агент, що вийшов з ладу, замінюється резервним без зупинки решти шести — черга продовжує рухатися.
| Метрика | До | Після |
|---|---|---|
| Час відновлення ланцюжка | 40–60 хвилин ручного повторного складання | 3–5 хвилин автоматичного повтору |
| Частка успішних завдань | 71% | 96% |
| Ручні доопрацювання | близько 15 на тиждень | 2 на тиждень |
| Клас відмов | втрата контексту під час обриву в середині | усунуто |
Через місяць експлуатації ланцюжок перестав потребувати постійного нагляду: сім агентів стали керованим контуром із спостережуваним станом, а не набором викликів, де будь-який збій означає ручний розбір.
Що робити, якщо агенти вже розгорнуті в різних контурах
Якщо агенти вже працюють у різних контурах, переписувати їх не потрібно. З’єднання робиться ззовні — через посередника між контурами, який тримає вихідне з’єднання із закритим середовищем.
Внутрішня логіка агента залишається недоторканою: змінюється лише те, як він отримує завдання й віддає результат.
Підключення наявного агента починається з опису його можливостей: які завдання розв’язує, що приймає на вхід, що повертає і коли відмовляє. Опис потрапляє до каталогу — за ним посередник розуміє, кому адресувати виклик.
Сам агент отримує легку обв’язку-адаптер, яка переводить його внутрішній формат у загальний формат Agent-to-Agent обміну й назад.
Закритий контур назовні не відкривається: з’єднання завжди ініціює внутрішня сторона, вхідні порти залишаються закритими, а посередник лише маршрутизує вже встановлений потік.
Кожен виклик підписаний і прив’язаний до конкретного агента й навички, права видаються не на контур цілком, а на окремі операції. Журнал обміну фіксує, хто запросив дію, що повернулося й скільки це зайняло.
Якщо контур недоступний, посередник ставить виклики в чергу й повторює їх, а сторона-ініціатор отримує зрозумілу відмову замість зависання — деградує окрема навичка, а не весь ланцюжок.
Так агенти з різних середовищ починають обмінюватися завданнями без переписування й без розширення периметра.
Часті технічні сумніви перед інтеграцією агентів
Агенти вже працюють окремо, і перед об’єднанням у спільний ланцюжок в інженерних команд виникають ті самі питання: хто чим керує, що відбувається за відмови вузла та як відновити хід завдання.
Обмін і картки агентів задає відкрита специфікація Agent2Agent — нижче короткі відповіді з експлуатації.
Як розмежовуються права агентів?
Кожен агент публікує картку з оголошеними навичками, а викликає інших не від свого імені, а від окремого сервісного облікового запису з вузьким набором областей доступу. Прав ініціатора запиту агент не успадковує: компрометація одного вузла не відкриває доступ до всього ланцюжка.
Що буде, якщо агент у ланцюжку недоступний?
Виклик іде з таймаутом і повторними спробами з наростаючою паузою, при цьому завдання не губиться — воно залишається в черзі зі збереженим станом. Далі ланцюжок переходить на резервний маршрут або зупиняється на останньому успішному кроці.
Як зрозуміти, на якому кроці зламався ланцюжок?
Кожен виклик отримує ідентифікатор завдання, а журнал фіксує, хто викликав агента, яка навичка спрацювала і який артефакт повернувся.
За ідентифікатором піднімається вся історія, включно з проміжними повідомленнями, — збій локалізується за хвилини, без ручного звіряння логів різних сервісів.
Чи можна залишити обмін у закритому контурі й перевикористати наявних агентів?
Так: обмін розгортаємо в межах периметра, назовні трафік не йде, доступи видаються всередині вашої служби каталогів. Уже впроваджені агенти підключаються через адаптер і публікують картку — далі їх використовують нові сценарії без переписування.
Обговоримо завдання та повернемося з оцінкою й планом робіт
Щоб повернутися з оцінкою інтеграції та планом етапів, нам достатньо кількох вступних від вас. Чим точніше описаний сценарій, тим менше припущень в оцінці й тим раніше ми називаємо термін і склад робіт. Надсилати готове технічне завдання не потрібно — достатньо опису процесу та обмежень.
- Які системи та сервіси мають обмінюватися даними і хто в них відповідає за зміни.
- Ролі агентів: що кожен вирішує самостійно, а що потребує підтвердження людини.
- Формат обміну між сторонами й вимоги сумісності з уже працюючими інтеграціями.
- Обмеження щодо доступів: які дані не можна виводити за периметр, які журнали обов’язкові.
- Нештатні ситуації: поведінка за недоступності агента, конфлікту відповідей, повторної доставки запиту.
- Режим навантаження: пікові періоди, частка ручних операцій, допустима затримка відповіді.
- Хто з боку замовника приймає результат і за якими критеріями вважає завдання закритим.
На дзвінку ми уточнюємо межі відповідальності агентів, схему узгодження дій, вимоги до журналювання та відкату. Потім збираємо тестовий контур на ваших сценаріях: кілька агентів і заміна одного з них без зупинки решти.
За результатами даємо оцінку термінів, поетапний план і точки приймання — ви бачите, що і в якому порядку перевіряєте.
Опишіть завдання у вільній формі — повернемося з оцінкою та планом робіт.
