Инженерия AI-агентов, которые создают и выкатывают софт: архитектура Jobbit

Большинство «AI-агентов» останавливаются на диалоге. Они отвечают — а дальше работу делает человек. По-настоящему интересная и по-настоящему сложная инженерная задача — построить агентов, которые делают работу: пишут полноценное приложение, запускают его, исправляют собственные ошибки и выкатывают в продакшен. Именно над этой задачей каждый день работает инженерная команда Jobbit и её R&D-подразделение Jobbit Labs (jobbitlabs.com).

Эта статья — инженерный разбор паттернов, которые стоят за AI-агентами, создающими и выкатывающими софт: архитектура, типичные сбои и извлечённые уроки. Материал намеренно практичный и не привязан к конкретному провайдеру: строите ли вы на больших языковых моделях (LLM), мультиагентной оркестрации, вызове инструментов (tool calling) или RAG — эти принципы переносятся.

Чат-боты отвечают; агенты действуют

Переход от чат-бота к агенту — это переход от генерации текста к действиям в реальном мире. Агент должен спланировать многошаговую задачу, вызвать инструменты, прочитать результаты и решить, что делать дальше — и повторять это, пока цель не достигнута. Этот цикл, который часто называют агентным циклом (или циклом «рассуждение — действие»), и есть сердце системы.

Инженерная сложность в том, что сбоить может каждый шаг. Модель может выдумать несуществующую функцию, написать код, который не компилируется, неправильно прочитать вывод инструмента или тихо уйти от задачи. Ошибившийся чат-бот выдаёт плохое предложение; ошибившийся агент выдаёт сломанный деплой. Настоящая инженерная работа — это надёжность, а не «сырая» мощность модели.

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

Надёжная платформа для агентов разделяет планирование и исполнение. Слой планирования раскладывает цель («собрать приложение для бронирования с оплатой») на конкретные шаги; слой исполнения выполняет каждый шаг с помощью инструментов. Когда эти задачи разделены, систему проще отлаживать: план можно проверять отдельно от того, как отработал каждый шаг.

Использование инструментов (tool use) — это то, чем агент «берётся за работу». Инструменты — это чётко описанные функции, которые модель может вызвать: прочитать файл, написать код, запустить сборку, обратиться к базе данных, выкатить деплой. Инженерная дисциплина здесь — проектирование интерфейсов: каждому инструменту нужна строгая, однозначная схема, валидируемые входные данные и структурированный вывод, который модель умеет надёжно разбирать. Размытые интерфейсы инструментов — один из главных источников сбоев у агентов; строгие интерфейсы — самый дешёвый прирост надёжности из доступных.

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

Запуск и развёртывание реального кода — безопасно

Агент, который пишет софт, должен этот софт запускать — а запуск кода, сгенерированного моделью, прежде всего проблема безопасности. Ответ — исполнение кода в песочнице (sandboxed code execution): ненадёжный код выполняется в изолированной среде с ограниченными ресурсами, без доступа к секретам и с жёсткими сетевыми границами. Именно песочница позволяет агенту итерировать — скомпилировать, протестировать, прочитать ошибку, исправить — не подвергая риску платформу и других пользователей.

Развёртывание — это шаг, который превращает сгенерированное приложение в продукт. Настоящий конструктор приложений на AI (AI app builder) владеет всем путём от кода до живого URL: сборка, выделение хостинга, привязка домена, терминирование TLS. Хорошая инженерия здесь означает делать деплои повторяемыми и обратимыми — одни и те же входные данные дают один и тот же результат, а плохой деплой можно откатить. Идемпотентность и чистый откат не эффектны, но именно они делают автономное развёртывание заслуживающим доверия.

Контекст, память и извлечение данных

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

Здесь и проявляют свою ценность RAG (генерация с дополнением из поиска, retrieval-augmented generation) и векторные базы данных. Вместо того чтобы сваливать в контекст всю кодовую базу, система извлекает те несколько файлов, символов или документов, которые относятся к текущему шагу. В сочетании со структурированной памятью — записью принятых решений, эволюционирующей спецификации и того, что уже пробовали, — извлечение удерживает агента в рамках задачи на протяжении долгой работы, не раздувая окно контекста. Хорошее извлечение часто влияет на качество сильнее, чем модель побольше.

Надёжность: оценки (evals), верификация и ограничители

Если есть одна идея, которая отличает продакшен-инженерию агентов от демок, то вот она: нельзя выкатывать то, что нельзя измерить. Агентные системы стохастичны, поэтому надёжность достигается через оценки (evals) — автоматические наборы тестов, которые оценивают агента на репрезентативных задачах и ловят регрессии раньше, чем это сделают пользователи. Изменение, которое «ощущается лучше», но валит ваши eval-метрики, — это изменение, которое вы не выкатываете.

Поверх оценок располагаются runtime-ограничители (guardrails) и верификация. Самый эффективный паттерн — состязательная самопроверка (adversarial self-checking): после того как агент выдал результат — код, план, исправление, — отдельный проход верификации пытается его опровергнуть. Код компилируется? Тесты проходят? Вывод соответствует схеме? Если относиться к верификации как к отдельному, скептичному шагу, ловится большая доля сбоев, которые один уверенный проход пропустил бы. Повторы с экспоненциальной задержкой, предохранители (circuit breakers) и эскалация к человеку закрывают остальное.

Наблюдаемость, которую можно отлаживать

Когда автономная система принимает десятки решений на задачу, эти решения нужно видеть. Наблюдаемость (observability) — структурированная трассировка каждого промпта, вызова инструмента и результата — не обсуждается. Когда агент ошибается, именно трассировка позволяет найти точный шаг, где он ушёл в сторону, воспроизвести его и устранить первопричину. Команды, относящиеся к трассировкам агентов как к телеметрии первого класса, отлаживаются за минуты; те, кто этого не делает, — за дни.

Edge и эластичное масштабирование

Нагрузка агентов всплесковая и чувствительная к задержкам, что делает периферийные вычисления (edge computing) естественным выбором. Запуск близко к пользователям — на платформах вроде Cloudflare Workers и периферийных хранилищ — снижает задержку «туда-обратно» и эластично масштабируется под спрос. Jobbit Labs опирается на этот edge-first-подход в части своей продуктовой и дата-инфраструктуры: глобально распределённо, с автомасштабированием и оплатой по факту использования, так что мощность следует за нагрузкой, а не простаивает.

Слой «человек в контуре»

Финальный элемент архитектуры — тот, которого не хватает большинству агентных платформ: путь «человек в контуре» (human-in-the-loop). AI берёт на себя объём и скорость, но некоторые решения — чувствительная к безопасности логика, юридические формулировки, дизайнерское суждение — принадлежат человеку. Инженерия здесь означает построение чистых точек передачи, где проверенный эксперт-человек может вмешаться, а сделку защищает эскроу. Агент и человеческая сеть — не конкурирующие слои; это спроектированный заранее запасной механизм, который делает всю систему безопасной для использования.

Уроки для инженеров, создающих агентов

Если вы строите агентные системы, несколько принципов окупятся многократно.

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

Проверяйте состязательно. Не доверяйте уверенному первому проходу. Добавьте отдельный шаг, задача которого — опровергнуть результат.

Измеряйте через оценки (evals). Постройте eval-стенд раньше, чем начнёте масштабировать агента. Нельзя улучшить то, что нельзя оценить.

Инженерьте контекст, а не сваливайте его. Извлекайте релевантное; запоминайте важное. Промпт побольше — не значит промпт получше.

Изолируйте всё ненадёжное в песочнице. Если агент запускает код, изоляция — это предусловие, а не фича.

Оставляйте путь к человеку. Самая безопасная автономная система — та, что знает, когда спросить человека.

Часто задаваемые вопросы

Чем AI-агент отличается от чат-бота?

Чат-бот генерирует текст; AI-агент планирует и совершает действия — вызывает инструменты, запускает код и итерирует к цели. Инженерная сложность — в надёжности на протяжении множества шагов, где любая единичная ошибка может сломать результат.

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

С помощью исполнения кода в песочнице: ненадёжный код выполняется в изолированной среде с ограниченными ресурсами, без доступа к секретам и с ограниченной сетью, так что агент может компилировать, тестировать и исправлять без риска для платформы.

Почему оценки (evals) так важны для агентных систем?

Потому что агенты стохастичны, и нужны автоматические оценки (evals), чтобы измерять качество на репрезентативных задачах и ловить регрессии до выката. Без них «улучшения» — это догадки.

Чем занимается Jobbit Labs?

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

Интересно, какая инженерия стоит за агентами, которые выкатывают софт? Изучите jobbit.uk и jobbitlabs.com.