Чому автономні агенти Fetch.ai втрачають зв'язок із блокчейном
Автономні агенти Fetch.ai ухвалюють рішення на своєму боці: тримають модель стану, обчислюють умови спрацювання й підписують операцію самостійно, без людини в циклі.
Мережа при цьому живе за власними правилами — фінальність настає не миттєво, частина подій відкочується, а порядок операцій задає консенсус, а не агент.
Поки ці дві картини світу збігаються, інтеграція AI-агентів виглядає робочою; розходження стану проявляється пізніше й не там, де його чекають.
Типовий збій починається з оракулів даних: зріз стану приходить агенту із затримкою, а всередині агента ще й кешується на кілька циклів. Рішення ухвалюється на застарілих даних — ціна, доступний обсяг або право доступу на момент виконання вже інші. Агент діє формально коректно, але на неправильній картині, і за його логами цього не видно.
Друга половина проблеми — повторні операції. Не дочекавшись підтвердження, агент не знає, чи дійшла перша спроба, і надсилає другу. Реєстр отримує два однакові записи, позиції розходяться з обліковими, а розбір займає більше часу, ніж сама угода. Якщо операція необоротна, відкотити її в мережі не можна — лише компенсувати.
Корінь один: логіка автономного агента живе окремо від стану мережі, а межа між ними ніяк не контролюється. Розбираємо, як це закривається — звіркою стану перед підписом, ключами повторюваності й журналом намірів агента.
Що дає інтеграція агентів: швидкість, відмови, ручні операції
Агент у Fetch.ai — це сервіс, який сам відстежує події в мережі та поза нею, застосовує правила й запускає наступну дію. Набір uAgents утворює виконавчий шар між вашими системами: він не чекає, поки оператор відкриє інтерфейс, а реагує на зміну стану.
Ефект тут рахується за чотирма напрямами — час операції, усунений клас відмов, частка ручних звірок і повнота аудиту.
Час операції скорочується завдяки тому, що між подією та виконанням немає людини. Агент перевіряє умову, збирає підтвердження й надсилає транзакцію за один прохід — медіана часу від події до виконання падає з годин до секунд.
Різниця видна не на демо, а в потоці: чим більше операцій за одиницю часу, тим сильніше розходяться стара й нова схема.
Окремий клас відмов — повторне виконання й розходження станів — знімається на рівні логіки агента. Ідемпотентні обробники, дедуплікація за ідентифікатором операції й повтор із обмеженням спроб прибирають подвійні списання й завислі заявки. Помилки, які раніше спливали через добу під час звірки, відсікаються в момент обробки.
Частка ручних звірок падає, бо звіряти стає нічого: стан агента й стан системи сходяться за однією й тією самою подією. Оператор підключається лише до винятків, які агент позначив як спірні, — черга розбору скорочується в рази, а не на відсотки.
Аудит будується з журналу рішень агента: вхідні дані, спрацьоване правило, результат і підпис виконавця. За таким записом дія відтворюється крок за кроком, тому спір розбирається за одним ланцюжком, а не за логами в різних системах. Саме повнота цього журналу визначає, чи можна віддати агенту операції без ручного підтвердження.
Варіанти інтеграції Fetch.ai: хмара, гібрид, власний контур
Логіка агента та його приватні ключі — дві різні сутності, і розміщувати їх можна по-різному. Ключове питання варіанта інтеграції: де фізично лежать ключі й хто ініціює підпис транзакції.
Від цього залежить і схема зберігання ключів, і те, чи потрапляють ваші дані до зовнішнього периметра.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарна інфраструктура | Швидкий запуск агентів, ізоляція не критична | Ключі поза вашим периметром, залежність від провайдера, потрібен окремий аудит доступів |
| Гібридна схема | Потрібен контроль над ключами при зовнішньому обчислювальному навантаженні | Складніша маршрутизація, розсинхрон стану між частинами |
| Закритий контур | Регуляторні вимоги, чутливі дані | Зовнішні сервіси недоступні, весь супровід реєстрів на вашому боці |
Як це працює на практиці
У хмарній інфраструктурі агенти uAgents розгортаються в контейнерах, масштабуються за навантаженням і одразу бачать зовнішні сервіси.
Гібридна схема забирає компроміс: розрахункова частина живе зовні, а підпис і зберігання ключів залишаються на вашому вузлі — агент працює із зовнішніми даними, не віддаючи керування активами.
Закритий контур обирають, коли зовнішні підключення недопустимі: обмін іде всередині периметра, точки входу закриті, а зв'язок із зовнішніми реєстрами — через контрольовані шлюзи. Плата за це — ручна синхронізація й більше супроводу. Опишіть задачу — повернемося з оцінкою та планом під ваш периметр.
Порядок робіт: від аудиту сценаріїв до передачі контуру
Порядок робіт однаковий і для першого запуску, і для продуктивного контуру: спочатку фіксуємо, які рішення ухвалює агент і на яких даних, потім проєктуємо схему й лише після цього переходимо до реалізації.
Такий порядок знімає основний ризик — коли інтеграція вже зібрана, а сценарій на реальних даних не сходиться й частину роботи доводиться переробляти.
- Аудит сценаріїв і даних — розбираємо задачі, які закривають агенти Fetch.ai, описуємо джерела, умови спрацювання й те, як рішення ухвалюється зараз.
- Проєктування схеми взаємодії — хто з ким обмінюється повідомленнями, що відбувається при недоступності джерела, де потрібен ручний підтверджувальний крок.
- Налаштування агентів — логіка обробки, підключення джерел даних, правила поведінки при помилках, обмеження за частотою звернень до зовнішніх сервісів.
- Тестовий прогін — проганяємо сценарії на історичних даних і в закритому контурі, звіряємо відповіді агентів з очікуваними.
- Перевірка під навантаженням — пікові запити, черга повідомлень, час відгуку й коректність відмов.
- Передача рішення й навчання команди — передаємо схему, конфігурації, журнали й регламент експлуатації, розбираємо з вашою командою спірні випадки.
Кожен етап закривається перевірюваним артефактом: картою сценаріїв, схемою, наборами тестових даних, звітом про навантаження, документацією. Проміжні результати погоджуємо по ходу — ви бачите рух за етапами, а не фінальну демонстрацію.
Що залишається у вас: схеми, політики, регламенти, документація
Інтеграція агентів — це не лише робочий код у мережі. Через пів року вже ніхто не згадає, чому в агента саме такі ліміти на виклики, як він отримує доступ до гаманця й що робити при відмові вузла.
Тому проєкт ми здаємо так, щоб його можна було розвивати й експлуатувати без нас: будь-який артефакт відкривається, читається й застосовується на практиці. Нижче — типовий комплект за підсумками робіт із Fetch.ai та uAgents.
- Схеми взаємодії — які агенти обмінюються повідомленнями, за якими темами, хто ініціатор запиту, де зовнішні сервіси й точки відмови.
- Конфігурації агентів — параметри запуску, ліміти, прив'язка до мереж, змінні середовища, правила оновлення адрес і ключів.
- Схема потоків даних — від вхідної події до запису в мережу: що де зберігається, що логується, що йде в зовнішні системи.
- Політики доступів і ролей — хто підписує операції, хто змінює конфігурацію, хто читає журнали; порядок видачі й відкликання ключів.
- Регламенти експлуатації — планове оновлення агентів, відкат до попередньої версії, реакція на падіння й на розходження балансів.
- Спостережуваність — набір метрик, порогові значення, куди надходять оповіщення й хто на них реагує в першу чергу.
- Документація проєкту — опис архітектури, ухвалені рішення та їхні причини, відомі обмеження поточної гілки.
- Передача знань команді — розбір стенда з вашими інженерами, відповіді на запитання, спільне виправлення першого оновлення.
Кейс: маркетплейс даних скоротив ручні звірки втричі
Маркетплейс даних зводить постачальників наборів даних і покупців: розрахунок проходить в ончейні, а права доступу видаються на боці сервісу. Звірку між журналом угод і записами про доступ команда вела вручну — аналітик зіставляв ідентифікатори угод, умови й строки.
На це йшло до третини робочого часу підтримки, а розходження спливали через дні: покупець уже працював із набором даних, хоча підтвердження оплати не пройшло.
Що змінили в агентній логіці
Зібрали агентний шар на uAgents із Fetch.ai: агент-постачальник публікує умови угоди, агент-покупець їх перевіряє й ініціює розрахунок, агент-аудитор слухає події та збирає докази за кожною операцією.
Правила звірки винесли в декларативні умови — доступ, строки, ліміти, порядок розбору розходжень — і перестали правити код під кожну нову вимогу. Обробники зробили ідемпотентними з ключем за ідентифікатором угоди: повторна доставка події не створює дубль і не псує журнал.
Після запуску частка операцій, що йдуть на ручну звірку, впала з 34% до 11%, час реакції на подію — з 40–90 хвилин до одиниць секунд, кількість спірних операцій скоротилася вчетверо.
Ручний розбір залишився лише там, де розходяться зовнішні джерела, і це вже виняток, а не щоденна робота. Агентна логіка дала не «магію ШІ», а передбачуваний контур: кожна дія залишає слід, а будь-яке розходження відтворюється за журналом.
Чим автономний агент відрізняється від звичайного скрипта в мережі?
Скрипт у мережі — це заздалегідь описана послідовність: перевірити умову, викликати метод контракту, записати результат. Рішення ухвалено автором коду, а виконання йде строго за закладеною гілкою.
Автономний агент отримує мету й правила, а конкретну дію обирає сам на кожному кроці — що викликати, коли зачекати, коли відмовитися від угоди.
Різниця підходів найяскравіше видна на непередбаченій ситуації. Скрипт, отримавши не ту відповідь або впершись у ліміт, падає чи йде в цикл очікування, транзакція відкочується — і до втручання людини система стоїть.
Агент бачить, що маршрут не спрацював, і перебудовує план: бере альтернативне джерело даних, переносить дію на наступний крок, знижує обсяг до допустимого.
Межі автономності не з'являються самі — їх задають у правилах: що агент читає, до яких контрактів звертається, які дії обов'язково йдуть на підтвердження. Чим вужчі ці межі, тим ближча поведінка до скрипта: передбачуваніша й надійніша, але менш корисна там, де потрібна гнучкість.
Змінюється й клас ризику. У скрипта він бінарний: спрацював чи ні. В агента з'являється третій стан — дія формально допустима, але не та, яка малася на увазі.
Тому в контур закладають жорсткі ліміти на дію, журнал рішень з обґрунтуванням і точку зупинки, що закриває агента без втрати стану.
У Fetch.ai агент — це сервіс із власною логікою й адресою, який обмінюється повідомленнями з іншими агентами.
Практичний висновок простий: скрипт автоматизує відомий сценарій, а агент береться за той, який не можна описати заздалегідь повністю, — і це закладається в проєктування з першого дня.
Технічні сумніви: ключі, навантаження, безпека, відкат
Перед стартом інтеграції агентів на Fetch.ai замовники ставлять п'ять питань: ключі, збій джерела, навантаження, відкат змін, сумісність із продуктом. Нижче — короткі відповіді, за якими зручно звірити рішення з вимогами.
Де зберігаються ключі підпису?
Ключ агента лежить у менеджері секретів і видається на час операції — у код і репозиторій не потрапляє. Ротація йде за розкладом, права розділені: агент підписує лише свої транзакції.
Що буде при збої джерела?
Агент не надсилає транзакцію за застарілими даними: запит повторюється з наростаючою паузою, подія йде в чергу. Якщо джерело мовчить довше за поріг, спрацьовує запобіжник і повідомлення черговому.
Як це вплине на навантаження?
Агент реагує лише на підтверджені зміни, тому звернення до мережі — частка від загального потоку подій. Чергу розбирають воркери з обмеженням паралелізму — пік не перетворюється в лавину запитів.
Чи можна відкотити зміни?
Так, при ідемпотентному проєктуванні. Контракт веде журнал операцій, повтор із тим самим ідентифікатором не створює дубль, а спірні операції розбираються вручну після зупинки агента.
Чи сумісно з поточним продуктом?
Агент підключається окремим сервісом і працює через наявні інтерфейси. Сценарії спочатку перевіряються в тіньовому контурі й вмикаються поступово — переписувати продукт не потрібно.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Оцінка проєкту виходить правдивою лише з вашої картини задачі, а не із загальних слів. Для першого кроку достатньо опису: які сценарії закривають агенти, з якими сервісами й даними вони працюють, хто володіє ключами й куди йдуть результати їхніх дій.
На першій розмові уточнюємо межі автоматизації та режими роботи агентів на Fetch.ai: що агент виконує сам, що підтверджує людина, які ліміти ставимо на дії й як відкочуємо помилкове спрацювання. Після цього фіксуємо план робіт і повертаємося з оцінкою.
З чим ми повернемося після обговорення задачі:
- карту сценаріїв: які агенти, які задачі, де починається й закінчується автоматизація;
- схему інтеграції з вашими сервісами, гаманцями та зовнішніми джерелами даних;
- модель доступів: хто тримає ключі, які ліміти й підтвердження стоять на діях агента;
- склад етапів із точками приймання — що вважається готовим на кожному кроці;
- строки впровадження за етапами й порядок виведення агентів у робочий режим;
- перелік ризиків і способів їх зняти, включно з умовами відкату на попередній стан.
Перший крок — лист або короткий дзвінок з описом задачі: цього достатньо, щоб побачити склад робіт. Оцінку, план робіт і строки впровадження за етапами надсилаємо одним документом, щоб їх можна було звірити з вашими пріоритетами.
