Автономний агент із необмеженим доступом до коштів — це не інструмент, а збиток, який ще не стався. Обмеження бюджету перетворює AI-агента з неконтрольованого споживача ресурсів на передбачуваний бізнес-процес із чіткими фінансовими межами. Нижче — покрокова механіка, як це реалізується на Solana.

Чому обмеження бюджету — критичне для автономних агентів

Автономний агент виконує дії безпосередньо в блокчейні: сплачує за обчислення, купує дані, здійснює мікротранзакції, взаємодіє зі смарт-контрактами. На відміну від людини, він не втомлюється, не сумнівається й не зупиняється, якщо логіка дозволяє продовжити.

Без бюджетних обмежень виникають три класи проблем:

  • Циклічні витрати. Агент потрапляє в логічний цикл: запитує дані, отримує помилку, повторює запит — і так доти, доки не вичерпає баланс. У мережі з мікрокомісіями це може відбутися за секунди.
  • Зовнішня маніпуляція. Провайдер даних або смарт-контракт може навмисно повертати невірні відповіді, змушуючи агента повторювати платні виклики.
  • Неконтрольоване розширення scope. Агент отримує завдання «знайти найкращу ціну» і починає опитувати десятки DEX-агрегаторів, кожен виклик — окрема комісія.

Бюджетний ліміт — це не просто цифра. Це механізм, який перетворює відкриту транзакційну можливість на замкнену фінансову процедуру з точними межами.

Механіка бюджетних лімітів

На Solana бюджетні обмеження реалізуються на рівні програмної логіки, а не лише на рівні гаманця. Гаманець містить баланс, але рішення про те, чи дозволити транзакцію, приймає логіка, яка контролює доступ агента до підпису.

Щоденні, тижневі, місячні ліміти

Часові вікна — базовий інструмент. Ліміт визначає максимальну суму в SOL або SPL-токенах, яку агент може витратити за певний період. Реалізація зазвичай базується на PDA (Program Derived Address) — програмно керованому акаунті, який веде облік витрат агента.

Механіка працює так:

  1. Перед кожною транзакцією програма перевіряє поточне споживання у вікні.
  2. Якщо сума транзакції + вже витрачене перевищує ліміт — транзакція відхиляється на рівні програми, комісія за невиконану транзакцію не стягується (крім мінімальної комісії за невдалу інструкцію).
  3. При переході до нового часового вікна лічильник скидається.

Практичний нюанс: часові вікни на блокчейні прив'язані до слоту (slot), а не до календарного часу. Щоб уникнути розбіжностей, програма має використовувати Clock (системний акаунт Solana, що фіксує час) або зовнішній оракул для точної прив'язки до UTC.

Ліміти на одного провайдера

Глобальний ліміт не захищає від ситуації, коли один провайдер споживає 90% бюджету. Тому паралельно вводяться пер-провайдерні ліміти: кожному API-контракту або оракулу виділяється окрема частка бюджету.

Реалізація передбачає картку (mapping) від адреси провайдера до витраченої суми. Коли агент ініціює виклик, програма:

  • Ідентифікує цільовий контракт за інструкцією транзакції.
  • Перевіряє ліміт саме для цього контракту.
  • Перевіряє загальний ліміт.

Транзакція проходить лише за умови виконання обох перевірок.

Багаторівневе схвалення

Для високих сум або нетипових операцій застосовується механізм ескалації. Агент не блокується повністю, а переводить транзакцію в стан очікування людського схвалення.

Типова конфігурація рівнів:

  • Рівень 1 — автоматичне схвалення: транзакції нижче порогу (наприклад, до 0,1 SOL за раз і до 1 SOL на добу) проходять без участі людини.
  • Рівень 2 — відкладене схвалення: транзакції в межах 0,1–1 SOL за раз або такі, що виводять добовий бюджет на 80%+, створюють pending-запис, який людина-оператор підтверджує через окрему інструкцію.
  • Рівень 3 — жорстка блокада: будь-які транзакції, що виходять за межі місячного ліміту, відхиляються незалежно від схвалення.

Технічно це реалізується через стан акаунта агента (enum: Active, PendingApproval, Blocked) і окрему інструкцію approve_transaction, яку може викликати лише авторизований підписант.

Передумови для впровадження

Перш ніж налаштовувати ліміти, переконайтеся, що інфраструктура відповідає мінімальним вимогам:

  • Розділення гаманців. Агент не повинен працювати з гаманцем, де зберігаються основні кошти компанії. Використовується окремий гаманець (escrow), на який перераховується лише виділений бюджет.
  • Програмний контроль підпису. Ключі від гаманця агента не передаються самій AI-моделі. Підпис транзакцій здійснюється через програму (Anchor-програму або інший on-chain механізм), яка виконує перевірки перед підписом.
  • Визначена одиниця ліміту. Чітко зафіксуйте, в чому вимірюється бюджет: SOL, USDC, інший SPL-токен чи комбінація. Змішані ліміти значно ускладнюють логіку.
  • Фіксований перелік дозволених контрактів. Агент не повинен мати можливості взаємодіяти з довільними адресами. Сформуйте allowlist контрактів, з якими дозволена робота.

Для перевірки готовості достатньо відповісти на питання: «Якщо агент зараз почне безперервно відправляти транзакції, яка максимальна сума буде втрачена до моменту реакції?» Якщо відповідь вас не влаштовує — передумови не виконані.

Очікуваний результат та як його перевірити

Після впровадження бюджетних лімітів ви маєте отримати такий стан:

  • Агент виконує рутинні завдання в межах виділеного бюджету без участі людини.
  • При спробі перевищити ліміт транзакція відхиляється on-chain, а не після факту витрати.
  • Усі спроби виходу за ліміт фіксуються в логах програми з вказівкою причини (перевищення добового ліміту, перевищення ліміту провайдера, необхідність схвалення).

Як перевірити:

  1. Ініціюйте серію дрібних транзакцій агента, сума яких наближається до добового ліміту, але не перевищує його. Усі мають пройти успішно.
  2. Ініціюйте транзакцію, яка виводить суму за ліміт. Очікуваний результат — невдала транзакція з конкретним кодом помилки програми (не generic-помилка Solana, а саме помилка бюджетного обмеження).
  3. Ініціюйте транзакцію в межах рівня 2 (відкладене схвалення). Перевірте, що транзакція не виконалась автоматично, а створила pending-запис.
  4. Дочекайтеся закінчення часового вікна та перевірте, що лічильник скинувся і агент знову може витрачати кошти.

Усі перевірки проводьте на devnet-або testnet-середовищі Solana. Перехід на mainnet — лише після повного проходження чек-листа.

Типові помилки при налаштуванні лімітів

  • Ліміт без урахування комісій. Бюджет у 1 SOL не означає, що агент зможе переказати 1 SOL. Відніміть оцінку комісій за очікувану кількість транзакцій у періоді. Інакше агент витратить бюджет на комісії до виконання корисних дій.
  • Занадто жорсткий ліміт, що блокує роботу. Якщо добовий ліміт становить 0,01 SOL, а одна транзакція з комісіями коштує 0,005 SOL, агент зможе виконати лише дві операції на добу. Ліміт має враховувати реальну вартість одного циклу роботи.
  • Єдиний ліміт для різних типів операцій. Запит до оракула за 0,0001 SOL і своп на DEX за 0,5 SOL — різні за масштабом дії. Єдиний ліміт або завищить ризик (дозволить великі свопи), або заблокує рутину (заблокує дешеві запити після кількох свопів).
  • Відсутність механізму екстреного блокування. Якщо ви виявили аномальну поведінку агента, ви маєте мати можливість миттєво перевести його стан у Blocked через одну транзакцію, не чекаючи закінчення часового вікна.
  • Ігнорування сліпих зон. Лічильник витрат оновлюється лише після успішного виконання транзакції. Невдалі транзакції теж коштують комісій, але можуть не фіксуватися в лічильнику. Враховуйте їх окремо або встановіть ліміт на кількість спроб.

Ризики: обхід лімітів, втрата доступу

Обхід лімітів через фрагментацію. Агент може розділити велику транзакцію на кілька дрібних, кожна з яких укладається в ліміт. Протидія: встановлюйте не лише ліміт за раз, а й ліміт на суму всіх транзакцій з однаковою метою (наприклад, на один цільовий контракт за годину).

Обхід через зміну провайдера. Якщо ліміт на одного провайдера вичерпано, агент може звернутися до іншого провайдера з тією самою послугою. Це не є помилкою логіки, але може несподівано прискорити витрачання загального бюджету. Протидія: моніторинг загального ліміту має бути пріоритетнішим за пер-провайдерний.

Втрата доступу до коштів. Якщо програма, що контролює ліміти, містить помилку, яка блокує всі транзакції, кошти на гаманці агента можуть стати недоступними. Протидія: передбачте механізм emergency-withdraw — інструкцію, яку може викликати авторизований підписант поза логікою лімітів, з таймлоком (наприклад, 24 години затримки перед виконанням).

Компрометація авторизованого підписанта. Якщо ключ, який схвалює транзакції рівня 2 або виконує emergency-withdraw, скомпрометовано, бюджетні ліміти втрачають сенс. Протидія: використовуйте multisig (наприклад, Squads Protocol) для критичних дій, розподіляючи повноваження між кількома ключами.

Наступний крок: моніторинг та аудитування

Налаштовані ліміти — це статична конфігурація. Динамічна система потребує постійного моніторингу. Наступний логічний крок — побудова системи спостереження, яка фіксує не лише фактичні витрати, а й патерни поведінки агента: частоту відхилених транзакцій, швидкість витрачання бюджету, розподіл витрат між провайдерами.

Аудитування полягає в періодичній перевірці того, чи відповідають налаштовані ліміти поточним бізнес-реаліям. Якщо ціна на послуги провайдера змінилася або агент отримав новий тип завдань, ліміти потребують перегляду. Без цієї процедури система або блокує корисну роботу, або залишає небезпечні прогалини.

Для глибшого розуміння інфраструктури, в якій працюють ці ліміти, рекомендуємо ознайомитися з тим, що таке agent wallet і як він працює.

Джерела