Агентна інфраструктура та новий бекенд
· 9 min read · Filippo Spinella · AI, Agents, Infrastructure, Developer Tools
Ми часто говорили про агентські фреймворки. LangGraph, CrewAI, AutoGen, різні SDK, цикл, виклик інструментів, пам’ять, планувальник, критик, супервізор. Усі корисні слова, бога бога. Але чим більше я дивлюся на фактично використовувані агенти, тим більше мені здається, що найцікавіша частина перемістилася нижче рамкового рівня.
Питання більше не просто: яку бібліотеку я використовую, щоб змусити крокову модель думати?
Справжнє запитання: де живе цей агент, коли він перестане бути демонстрацією?
Тому що серйозний агент — це не функція, яка викликає модель і повертає текст. Це невелика розподілена система. Він повинен читати контекст, використовувати інструменти, виконувати код, торкатися файлів, запам’ятовувати рішення, запитувати дозволу, виходити з ладу, перезапускати, залишати журнали, не спалювати бюджет і не перетворюватися на бульдозер у сховищі виробництва.
Каркас - кермо. Інфраструктура - це дорога, гальма, гараж, страховка і людина, яка знає, де ключі.
Бо зараз про це багато говорять
У 2023 і 2024 роках розмова була дуже орієнтована на моделі. Який LLM? Скільки контексту? Скільки це коштує? Наскільки добре він програмує?
У 2025 і 2026 роках розмова змінилася. Моделі достатньо хороші, щоб виконувати реальну роботу, але саме тому стають видимими нудні біти: час виконання, безпека, з’єднувачі, ідентичність, спостережливість, виконання коду, розгортання, відкат.
Це природний перехід від магії до інженерії.
Коли агенту потрібно просто згенерувати відповідь, достатньо чату. Коли вам потрібно відкрити запит на отримання, запитати базу даних, викликати CRM, розпочати роботу, перейти на сайт, прочитати Slack, скомпілювати код і оновити документ, вам потрібна операційна система навколо цього.
Не в прямому сенсі. В організаційному плані.
Перша частина: час виконання, де агент може тривати
Агент часто працює поетапно. Подивіться на стан, виберіть дію, скористайтеся інструментом, спостерігайте за результатом, оновіть план, повторіть.
Якщо цей цикл живе в одному запиті HTTP, у вас одразу виникає проблема. Деякі дії виконуються повільно. Деякі чекають людського втручання. Деякі не вдаються, і їх потрібно спробувати ще раз. Деякі мають витримати розгортання або тайм-аут.
Саме тут у гру вступають довговічні робочі процеси, черги, фони роботи та кінцеві автомати. Вони не гламурні, але це різниця між агентом, який здається розумним на демонстрації, і тим, кого ви можете залишити працювати, а ви йдете пити каву.
Для мене середовище виконання агента має відповідати на дуже конкретні запитання:
- де я можу зберегти стан між одним кроком і іншим?
- що станеться, якщо процес загине на півдорозі?
- чи можу я зробити паузу та запитати схвалення?
- чи можу я відтворити пробіжку, щоб зрозуміти, чому він зробив такий вибір?
- чи можу я обмежити тривалість, пам'ять, інструменти та вартість?
Vercel активно наполягає на цьому фронті, створюючи SDK для штучного інтелекту, функції, робочі процеси та інструменти для створення агентів у веб-додатках. Але справа не лише у Верцелі. Справа в тому, що агенту потрібен оперативний дім, а не окрема кінцева точка.
Друга частина: пісочниця, тому що агент повинен мати можливість забруднитися, не зламавшись
Як тільки агент пише код або виконує команди, потрібна пісочниця.
Начебто технічне слово, але ідея побутова: даси йому верстак. Він може відкривати файли, встановлювати залежності, запускати тести, проводити експерименти, генерувати вихідні дані. Якщо він помиляється, ви стримали шкоду. Якщо це працює, рекламуйте результат.
Агентна пісочниця повинна мати деякі властивості:
- ізольована файлова система;
- Обмеження процесора, пам'яті та часу;
- контрольована мережа;
- секрети монтуються лише за потреби;
- комплектні журнали;
- можливість експорту артефактів;
- чисте скидання між прогонами, коли це необхідно.
Vercel Sandbox працює саме в цьому напрямку: ізольовані середовища для запуску коду, встановлення залежностей, роботи з файлами та створення артефактів без запуску всього в основному середовищі виконання програми.
Ця річ важливіша, ніж здається. Багато агентних прототипів переходять безпосередньо з моделі в реальну систему. Модель може викликати інструмент. Інструменти можуть щось робити. Усе це здається елегантним, доки не з’являється перша неправильна команда, перша залежність, встановлена не в тому місці, перший маркер, який потрапляє в журнал.
Пісочниця – це дорослий спосіб сказати: вперед, але сюди.
Третя частина: MCP і проблема роз'єму
Протокол контексту моделі став однією з найцікавіших частин екосистеми, оскільки він намагається стандартизувати те, що інакше швидко стає некерованим: як модель виявляє та використовує зовнішні інструменти.
Без стандарту кожна інтеграція є маленьким острівцем. Конектор для GitHub зроблено одним способом, один для Slack зроблено іншим, один для баз даних з різною семантикою, один для автоматизації браузера, який виглядає ні на що.
MCP пропонує спільну мову між клієнтом і сервером: інструменти, ресурси, підказки, авторизації, транспортування, виявлення. Це не магічно вирішує управління та безпеку, але дає граматику.
І граматика має значення. Коли агент може підключатися до багатьох інструментів, питання полягає не лише в тому, «чи зможе він це зробити?». Проблема в тому, «чи розуміє він, що він може робити, в яких межах, від імені кого і який слід залишити?».
Для мене MCP не є ажіотажем, тому що він "викликає інструменти". Ми вже це зробили. Це ажіотаж, тому що він зміщує центр ваги з однієї інтеграції на оперативний каталог інструментів.
У хорошій агентській архітектурі MCP стає свого роду патч-панеллю:
- GitHub для коду та проблем;
- слабкий для розмовного контексту;
- Linear або Jira для планової роботи;
- база даних тільки для читання для аналітики;
- браузер або скребок, керований зовнішніми сайтами;
- зберігання документів;
- ізольовані середовища виконання;
- відкрити внутрішні системи із суворими дозволами.
Складна частина полягає в тому, що каталог інструментів без політики — це просто більш елегантний спосіб створити хаос.
Четверта частина: ідентифікація та дозволи
Це та сфера, на яку багато демонстрацій закривають очі.
Агент діє від чийогось імені. Тому має бути зрозуміло, хто є суб’єктом дії.
Він використовує дозволи користувача? Сервісного облікового запису? Робочого простору? У вас є тимчасовий чи постійний доступ? Чи можете ви прочитати все чи лише деякі ресурси? Ви можете написати? Ви можете скасувати? Чи може він написати реальним людям?
Якщо ви погано відповісте на ці питання, рано чи пізно ви побудуєте помічника з ключами від дому і не пам’ятатимете, хто їх йому дав.
Емпіричне правило, яке мені подобається, таке: агент повинен бути здатним робити менше, ніж людина, а не більше, ніж людина. І коли йому потрібно зробити щось більш ризиковане, він повинен зупинитися і запитати.
Це означає OAuth, область дії маркера, керування секретами, журнал аудиту, політику інструменту, білий список, етап затвердження. Не дуже романтичні речі. Необхідні речі.
П'ятий шматок: пам'ять і контекст, але без накопичення сміття
Агентам потрібна пам'ять, але пам'ять небезпечна, коли стає горищем.
Існує щонайменше три види пам'яті:
- пам'ять запуску: що сталося в цьому виконанні;
- пам'ять проекту: умовності, рішення, обмеження;
- особиста або командна пам'ять: уподобання, тон, ритуали, процеси.
Розмістити все в підказці – це ярлик. Працює, поки не перестане працювати. Необхідно подбати про корисну пам'ять: проіндексувати, оновити, прострочити, перевірити, зробити доступним для цитування.
Агент, який погано пам'ятає, гірший за агента, який не пам'ятає. Тому що він говорить впевнено.
Тому інфраструктура повинна включати пошук, файли інструкцій, базу знань, вбудовування за потреби, а також очищення. Потрібна культура пам’яті: що входить, хто це затверджує, коли воно згасає, як це виправити.
Шоста частина: спостережливість, оцінка та відтворення
Якщо агент робить помилку, журналу «викликається модель» недостатньо.
Ви хочете побачити маршрут. Який контекст він отримав? Які інструменти були доступні? Який інструмент ви обрали? З якими аргументами? Яку відповідь ви отримали? Скільки це коштувало? Де застрягло? Людина щось схвалювала? Чи помилка моделі, інструменту, підказки, даних або дозволу помилка?
Тут агенти більше нагадують розподілені системи, ніж чат-боти.
Вам потрібні читабельні сліди, а не просто текстові журнали. Ви повинні вміти відтворювати пробіжку. Необхідно порівняти дві версії одного агента на відомих завданнях. Нам потрібно виміряти регресії: він не тільки «відповідає краще», але й «закриває правильний запит, не торкаючись небажаних файлів».
Агентні оцінки складніші, ніж текстові, оскільки вони включають дії. Недостатньо порівняти очікуваний рядок. Ви повинні дивитися на послідовність, побічні ефекти, якість артефакту, час, вартість, кількість людських втручань.
Найсмішніше те, що ми завжди повертаємося туди: розробка програмного забезпечення. Тести, середовища, трасування, відкати. За винятком того, що код тепер також вирішує, що робити далі.
The seventh piece: human interfaces
The agent doesn't have to just live in a chat.
Some agents need a board. Others a page with status and log. Others of an "approve" button. Більше внутрішніх коментарів. Ще інші з CLI.
Інтерфейс користувача змінює поведінку. Якщо єдиним способом керування агентом є написання довгого повідомлення, користувач дасть агенту розпливчасті інструкції. Однак якщо він бачить план, різницю, джерела, ризики та наступні дії, він може точно втрутитися.
Пристойна агентська інфраструктура включає контрольні поверхні:
- поточний стан;
- редагований план;
- виготовлені артефакти;
- диф;
- запити на погодження;
- хронологія;
- кнопка зупинки;
- кнопка повторити спробу;
- видимі дозволи.
It seems trivial, but it isn't. Різниця між «страшним штучним інтелектом» і «надійним помічником» часто полягає лише в тому, що останній показує, до чого він приклав руку.
The mental stack
Якби я намалював це сьогодні, мінімальний стек агентів був би таким:
- Модель: міркування, генерація, виклик інструменту, мультимодальний, якщо необхідно.
- Оркестровка: цикл, крок, планувальник, політика, людина в циклі.
- Надійний час виконання: робочий процес, черга, повторна спроба, пауза, відновлення.
- Пісочниця: виконання коду, ізольована файлова система, обмеження, артефакти.
- Інструментальний рівень: MCP, внутрішній API, браузер, база даних, репозиторій.
- Рівень ідентифікації: OAuth, область, секрет, аудит, політика.
- Рівень пам'яті: контекст проекту, пошук, інструкції, термін дії.
- Спостережуваність: відстеження, повторне відтворення, оцінка, показники вартості та якості.
- Поверхня продукту: чат, коли достатньо, інформаційна панель, коли потрібно, огляд, коли це важливо.
Агентна структура в основному охоплює пункти 2 і частину пункту 1. Решта — справжня робота.
What I would do in practice
Якби команда сказала мені, що «нам потрібні агенти у виробництві», я б не починав із десяти агентів.
Я б почав з невеликого, повторюваного та помітного робочого процесу. Наприклад: відкрити PR-запити на технічне обслуговування, оновити документацію із закритих проблем, підготувати щотижневий огляд, відсортувати повторювані помилки, створити тести для файлів, які зазнали впливу.
Тоді я б встановив дуже чіткі обмеження:
- жодного письма без гілок чи пісочниці;
- відсутність секретів у підказці;
- інструменти в білому списку;
- схвалення людиною зовнішніх дій;
- обов'язковий журнал і слід;
- бюджет на пробіг;
- вихід завжди перевіряється.
Тільки тоді я б розширився.
Агенти не зазнають невдачі лише тому, що моделі помиляються. Вони зазнають невдачі, тому що ми ставимо їх у невизначене середовище, із заплутаними дозволами та театральними очікуваннями.
Моє читання
Агентська інфраструктура нудна в кращому випадку.
Це не та частина, яка змушує вас плескати в демо. Це та частина, яка дозволяє вам фактично використовувати демонстрацію в понеділок вранці з реальними людьми, реальними даними та реальними наслідками.
Майбутнє агентів не буде вирішуватися лише тим, хто має найкращий приклад для наслідування. Це буде вирішено тим, хто побудує найкраще місце, де він зможе працювати: ізольований, коли він експериментує, пов’язаний, коли це необхідно, завжди спостережливий, уповноважений із критеріями та достатньо скромний, щоб зупинитися, коли він не знає.
Тут агенти перестають бути іграшками, а стають інфраструктурою.