Як інженери будують AI-агентів, що пишуть і деплоять софт: архітектура Jobbit

Більшість «AI-агентів» зупиняються на розмові. Вони відповідають — а далі роботу робить людина. Цікава й по-справжньому складна інженерна задача — це побудувати агентів, які виконують роботу: пишуть повноцінний застосунок, запускають його, виправляють власні помилки та деплоять у продакшн. Саме над цією задачею щодня працює інженерна команда Jobbit та її R&D-підрозділ Jobbit Labs (jobbitlabs.com).

Ця стаття — інженерний розбір патернів, що стоять за AI-агентами, які будують і деплоять софт: архітектура, режими відмов і висновки. Вона навмисно практична й не прив'язана до конкретного провайдера: байдуже, чи будуєте ви на LLM, мультиагентній оркестрації, виклику інструментів (tool calling) чи RAG — ці принципи переносяться будь-куди.

Чат-боти відповідають; агенти діють

Стрибок від чат-бота до агента — це стрибок від генерації тексту до дій у реальному світі. Агент має спланувати багатокрокову задачу, викликати інструменти, прочитати результати й вирішити, що робити далі, — і повторювати це, доки мета не буде досягнута. Цей цикл, який часто називають агентним циклом (agentic loop, або цикл «міркуй–дій»), і є серцем усієї системи.

Інженерна складність у тому, що відмовити може кожен крок. Модель може вигадати функцію, якої не існує, написати код, що не компілюється, неправильно зчитати вивід інструмента або тихо збитися з задачі. Помилка чат-бота — це невдале речення; помилка агента — це зламаний деплой. Реальна інженерна робота полягає в надійності, а не в «сирій» потужності моделі.

Архітектура: планувальник, виконавець, інструменти

Надійна агентна платформа відокремлює планування від виконання. Шар планування розкладає мету («побудувати застосунок для бронювання з оплатами») на конкретні кроки; шар виконання реалізує кожен крок за допомогою інструментів. Розділення цих відповідальностей робить систему придатною для дебагу: ви можете аналізувати план окремо від того, як виконувався кожен крок.

Виклик інструментів (tool use) — це те, що дає агенту «руки». Інструменти — це чітко визначені функції, які модель може викликати: прочитати файл, написати код, запустити збірку, зробити запит до бази даних, задеплоїти. Інженерна дисципліна тут — це проєктування інтерфейсів: кожен інструмент потребує щільної, однозначної схеми, валідованих входів і структурованих виходів, які модель може надійно розпарсити. Розмиті інтерфейси інструментів — одне з головних джерел відмов агента; щільні ж — найдешевший виграш у надійності, який тільки можна отримати.

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

Як безпечно запускати й деплоїти реальний код

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

Деплой — це крок, що перетворює згенерований застосунок на продукт. Справжній конструктор застосунків на AI (AI app builder) бере на себе весь шлях від коду до живого URL: збірка, провіжинінг хостингу, прив'язка домену, термінація TLS. Зробити це інженерно правильно означає зробити деплої повторюваними й оборотними — однакові входи дають однаковий результат, а невдалий деплой можна відкотити. Ідемпотентність і чистий відкат не виглядають ефектно, але саме вони роблять автономний деплой надійним.

Контекст, пам'ять і пошук

LLM мають скінченний контекст, а реальні проєкти в нього не вміщаються. Тож серйозна агентна система вкладає чимало зусиль у інженерію контексту (context engineering): рішення про те, що саме модель бачить на кожному кроці. Запхати все в промпт — водночас дорого й контрпродуктивно: забагато нерелевантного контексту погіршує міркування.

Саме тут заробляють своє місце RAG (retrieval-augmented generation — генерація з доповненням пошуком) і векторні бази даних. Замість того щоб скидати всю кодову базу в контекст, система видобуває ті кілька файлів, символів чи документів, які релевантні поточному кроку. У поєднанні зі структурованою пам'яттю — записом ухвалених рішень, специфікацією, що еволюціонує, і тим, що вже було спробувано — пошук тримає агента «приземленим» упродовж довгої задачі, не перевантажуючи контекстне вікно. Якісний пошук часто є більшим важелем якості, ніж більша модель.

Надійність: евали, верифікація та запобіжники

Якщо й існує одна ідея, яка відрізняє продакшн-інженерію агентів від демо, то ось вона: ви не можете задеплоїти те, що не можете виміряти. Агентні системи стохастичні, тож надійність забезпечується через евали (evals) — автоматизовані набори тестів, які оцінюють агента на репрезентативних задачах і ловлять регресії раніше, ніж це зроблять користувачі. Зміна, яка «здається кращою», але обвалює ваші оцінки евалів, — це зміна, яку ви не деплоїте.

Поверх евалів стоять рантаймові запобіжники (guardrails) і верифікація. Найефективніший патерн — це змагальна самоперевірка (adversarial self-checking): після того, як агент видав результат — фрагмент коду, план, виправлення — окремий етап верифікації намагається його спростувати. Чи компілюється код? Чи проходять тести? Чи відповідає вивід схемі? Ставлення до верифікації як до окремого скептичного кроку ловить велику частку відмов, які один упевнений прохід пропустив би. Ретраї з бекофом, circuit breakers і ескалація до людини розбираються з рештою.

Спостережуваність, яку можна дебажити

Коли автономна система ухвалює десятки рішень на задачу, ви маєте їх бачити. Спостережуваність (observability) — структуроване трасування кожного промпту, виклику інструмента й результату — це не предмет торгу. Коли агент помиляється, саме трейс дозволяє знайти точний крок, на якому він збився, відтворити його й виправити першопричину. Інженерні команди, які ставляться до трейсів агента як до телеметрії першого класу, дебажать за хвилини; ті, що ні, — за дні.

Edge і еластичне масштабування

Навантаження агентів є сплесковим і чутливим до затримок, що робить edge-обчислення природним вибором. Робота близько до користувачів — на платформах на кшталт Cloudflare Workers і edge-сховищ даних — скорочує затримку «туди-назад» і еластично масштабується з попитом. Jobbit Labs спирається на цей edge-first підхід для частин своєї дата- та продуктової інфраструктури: глобально розподілено, з автомасштабуванням і оплатою за фактичне використання, тож потужність слідує за навантаженням, а не простоює.

Шар «людина в контурі»

Остання частина архітектури — та, якої бракує більшості агентних платформ: шлях «людина в контурі» (human-in-the-loop). AI бере на себе обсяг і швидкість, але деякі рішення — чутлива до безпеки логіка, юридичні формулювання, дизайнерське судження — належать людині. Інженерно це означає будувати чисті точки передачі, де перевірений людський експерт може втрутитися, з ескроу, що захищає транзакцію. Агент і мережа людей — не конкуруючі шари; це закладений у дизайн запасний варіант, який робить усю систему безпечною для покладання на неї.

Висновки для інженерів, що будують агентів

Якщо ви будуєте агентні системи, кілька принципів окуплять вкладене багаторазово.

Проєктуйте щільні інтерфейси інструментів. Більшість відмов агента сходяться до неоднозначних інструментів. Суворі схеми й валідований ввід-вивід — найдешевша надійність, яку ви коли-небудь купите.

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

Вимірюйте за допомогою евалів. Збудуйте інфраструктуру евалів раніше, ніж масштабувати агента. Не можна покращити те, що не можна оцінити.

Інженерте контекст, а не скидайте його. Видобувайте релевантне; пам'ятайте важливе. Більші промпти — не кращі промпти.

Ізолюйте все недовірене. Якщо агент запускає код, ізоляція — це передумова, а не функція.

Залишайте шлях до людини. Найбезпечніша автономна система — це та, що знає, коли спитати людину.

Поширені запитання

Чим AI-агент відрізняється від чат-бота?

Чат-бот генерує текст; AI-агент планує й виконує дії — викликає інструменти, запускає код та ітерує до мети. Інженерна складність полягає в надійності на багатьох кроках, де будь-яка одна помилка може зламати результат.

Як безпечно запускати код, згенерований AI?

За допомогою ізольованого виконання коду (sandboxed code execution): недовірений код виконується в ізольованому середовищі з обмеженими ресурсами, без доступу до секретів і з обмеженою мережею, тож агент може компілювати, тестувати й виправляти без ризику для платформи.

Чому евали такі важливі для агентних систем?

Оскільки агенти стохастичні, вам потрібні автоматизовані евали, щоб міряти якість на репрезентативних задачах і ловити регресії перед деплоєм. Без них «покращення» — це лише здогадки.

Чим займається Jobbit Labs?

Jobbit Labs (jobbitlabs.com) — це R&D- та дата-підрозділ за Jobbit, зосереджений на важчій, насиченій даними та корпоративній інженерії: дослідження, дата-платформи й агентні підвалини, на яких побудовано продукт.

Цікавить інженерія агентів, що деплоять софт? Досліджуйте jobbit.uk і jobbitlabs.com.