Більша частина хостингу спроєктована довкола людини за клавіатурою: форма реєстрації, картка, панель керування, лист, коли щось зламалося. ШІ-агент, якому потрібні обчислення, не вписується в жоден із цих кроків. Він не розв'яже капчу, не відрізнить сторінку техробіт від зламаної й не помітить, що створив той самий сервер сорок разів.
Хочеться сказати «просто дайте йому API». Це перша вимога, а не остання. Нижче — сім, які ми вважаємо важливими, з досвіду створення власних MCP-сервера і REST API для агентів. Для кожної: що йде не так без неї.
1. Усе, що потрібно агентові, програмоване
Створення, перегляд, зміна розміру й видалення ресурсів мають працювати без браузера. Разом із нудними частинами: дізнатися ціну до купівлі, перевірити, чи є потужності в локації, прочитати пароль нової машини, скасувати.
Без цього: агент проходить 80% шляху й зупиняється на єдиному кроці, що потребує кліку, і людині все одно доводиться завершувати. Частковий API часто гірший за відсутність, бо провокує автоматизацію, яка не може завершитися.
2. Помилки, на які програма може реагувати
Агент читає відповідь і вирішує, що робити далі. JSON-тіло зі стабільним кодом (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded із часом скидання) — те, за чим він може розгалужуватися. HTML-сторінка помилки чи 500 із туманним повідомленням лишають його гадати — часто повторювати те, що ніколи не вдасться.
Без цього: цикли повторів. Найдорожчі збої агентів зазвичай не хибні рішення, а той самий невдалий виклик, повторений тисячі разів.
3. Оплата без людини в ланцюжку
Платежі карткою повні кроків, вигаданих, щоб підтвердити присутність людини: коди 3-D Secure, підтвердження в банківському застосунку, перевірки особи. Вони добрі проти шахрайства й неможливі для програми. Передплачений баланс, поповнений заздалегідь (у нас часто стейблкоїнами), дає агентові платити за використане без схвалення людиною кожного списання.
Без цього: або людина схвалює кожну покупку, що вбиває сенс, або хтось дає агентові картку, а цим ризиком не варто ризикувати нікому.
4. Жорсткі ліміти витрат
Передплачений баланс обмежує найгірший випадок тим, що на ньому лежить. Це все ще може бути багато. Денний і місячний ліміт у доларах, який забезпечує платформа, а не добрі наміри самого агента, перетворює зацикленого агента на невелику втрату. Ліміт має спрацьовувати гучно, з помилкою, яку агент розпізнає, і зупиняти чи ставити на паузу те, що запущено.
Без цього: про цикл ви дізнаєтеся з балансу. В оплаті пісочниць ліміти є саме тому, а розділ захист MCP підказує, яким діям узагалі потрібне схвалення людини.
5. Обчислення потрібної гранулярності
Агенти виробляють три дуже різні види роботи:
- Секунди: запустити згенерований фрагмент, перевірити відповідь, спробувати виправлення.
- Години: оцінювання, парсинг, довге збирання.
- Постійно: бот, API, воркер за розкладом.
Платформа, що пропонує лише місячні сервери, робить перший вид абсурдно дорогим; що пропонує лише короткоживучі пісочниці — робить третій крихким. Задача на 20 секунд на машині з погодинною оплатою оплачує 59 хвилин нічого. Як працює посекундна оплата показує, де кожна модель перестає мати сенс.
Без цього: агенти або переплачують за коротку роботу, або тримають довгоживучі сервіси на інфраструктурі, не розрахованій на це.
6. Ізоляція за замовчуванням
Код, написаний агентом, — код, який ніхто не перевіряв. Він має працювати там, де немає нічого цінного: не на хості самого агента, не на сервері з вашими ключами, не на машині, що надсилає вашу пошту. На практиці це окрема VM чи microVM на задачу, яку видаляють після. Рівні ізоляції для недовіреного коду порівнюють варіанти; Firecracker microVM простою мовою пояснює, чому важливе власне ядро.
Без цього: перша prompt injection, що проникла в згенерований код, отримує доступ до всього, до чого дотягується хост агента.
7. Видимість і вимикач
Людині, що відповідає за агента, треба бачити, що той зробив, і швидко його зупинити. Це означає: використання й вартість за кожним ресурсом, список усього, що агент створив, і спосіб усе це видалити. Облікові дані мають бути відкличними й досить короткоживучими, щоб токен, який витік, не діяв вічно, з можливістю оновлення без участі людини.
Без цього: прибирання перетворюється на археологію. Забуті ресурси й далі тарифікуються; токен, що витік, і далі працює.
Що агентам не потрібно
Не менш показово те, що не допомагає: панелі, збудовані під апсейл, онбординг-листи, тарифи, чиї реальні обмеження у виносці, ціни, показані лише після реєстрації. Нічого з цього програма не прочитає, а дещо активно вводить в оману модель, що розуміє текст буквально.
Що поки не розв'язано
Не все тут — розв'язана інженерна задача.
- Відповідальність. Хтось відповідає за те, що агент робить з акаунтом. Платформам потрібен спосіб пов'язати автоматичну активність із відповідальною людиною, не проганяючи цю людину крізь кожен крок.
- Зловживання. Відкрита, повністю автоматична реєстрація — саме те, чого хочуть і зловмисники. Кожна платформа, що обслуговує агентів, балансує між доступом без тертя та фермами й майнінгом, і ідеальної відповіді немає ні в кого.
- Довгі сценарії. Агенти досі частіше ламаються на процесах із десяти кроків, ніж на поодиноких викликах. Інфраструктура може допомогти, роблячи кожен крок ідемпотентним, а його стан — легко доступним для запиту, щоб повтор продовжував, а не дублював.
До чого прийшли ми
Ми намагалися будувати під ці вимоги, а не в обхід: MCP-сервер і REST API на весь життєвий цикл, машиночитні помилки, передплачений баланс, ліміти витрат, посекундні пісочниці для коду для короткої роботи й місячні сервери на кшталт тарифу AI agent для довгої. Розбір боку пісочниць — у пісочниці для ШІ-агентів. Але оцінюйте список по суті: це корисний чек-лист для будь-якої платформи, якій ви довіряєте агента.
Коментарі
Поки немає коментарів. Будьте першим.