Agent Ops: зачем компаниям новая роль для присмотра за ИИ-агентами

За последний год компании массово начали ставить в продакшн не просто чат-ботов, а ИИ-агентов — системы, которые сами вызывают инструменты, ходят по API, читают базы и выполняют цепочки действий без пошагового участия человека. И почти сразу выяснилось: агент, который блестяще проходит демо, в реальной эксплуатации зависает, вызывает не тот инструмент, застревает в цикле или за ночь съедает на токенах бюджет небольшого отдела. Присматривать за этим руками разработчика невозможно — так формируется отдельная инженерная роль, которую всё чаще называют Agent Ops.

Это не официальная должность из справочника профессий и не продукт конкретного вендора. Это набор задач, который откололся от MLOps и DevOps, потому что старые инструменты плохо подходят к недетерминированной штуке, принимающей решения на лету.

Что вообще такое Agent Ops

Agent Ops — эксплуатация и надзор за автономными или полуавтономными ИИ-агентами¹ в продакшене. Если DevOps отвечает за то, чтобы код доехал до сервера и не упал, а MLOps — за жизненный цикл модели от обучения до деплоя, то Agent Ops закрывает промежуток между ними: поведение работающего агента, его решения, стоимость и предсказуемость.

Ключевое отличие от классического бэкенда — недетерминированность. Один и тот же запрос может дать два разных плана действий. Обычный сервис вы покрываете юнит-тестами и радуетесь зелёной сборке. Агента так не поймать: он проходит тест сегодня и проваливает завтра, потому что модель обновили или пользователь сформулировал задачу чуть иначе.

Из чего состоит работа

• Наблюдаемость. Трейсинг каждого шага: какой инструмент вызван, с какими аргументами, что вернулось, сколько токенов ушло. Без этого разбор инцидента превращается в гадание.
• Оценка качества. Наборы эталонных сценариев (evals), прогон агента по ним при каждом изменении промпта, модели или инструмента.
• Контроль стоимости. Лимиты на токены и число шагов, алерты на аномальный расход, выбор дешёвой модели там, где дорогая не нужна.
• Безопасность и границы. Ограничение прав агента, защита от prompt injection, ручное подтверждение опасных действий вроде удаления данных или платежа.
• Реакция на инциденты. Откат на предыдущую версию промпта или модели, kill switch, дежурство по агенту так же, как по обычному сервису.

Агент в продакшене — это не программа, которую вы написали и забыли. Это сотрудник, за которым нужно следить: он ошибается, устаёт от контекста и иногда делает то, о чём его не просили.

Почему это не влезло в MLOps и DevOps

MLOps выстроен вокруг модели как артефакта: версии весов, датасеты, метрики точности. Но в мире агентов вы часто вообще не обучаете модель — берёте готовую по API и строите вокруг неё логику из промптов, инструментов и памяти. Меняется не модель, а промпт или список доступных функций, и этот слой в классическом MLOps-пайплайне никак не версионируется.

DevOps, в свою очередь, отлично разворачивает и мониторит стабильные сервисы, но его метрики — время ответа, коды ошибок, загрузка CPU. Агент может отвечать за 200 миллисекунд кодом 200 и при этом выдавать полную чушь или выполнить не ту операцию. Технически всё зелёное, по сути — сбой. Нужен слой оценки смысла, а не только доступности.

Сравнение ролей

Инструменты, которые уже используют

Отдельного стандарта пока нет, стек собирается из нескольких категорий. Для трейсинга и оценки популярны LangSmith (от команды LangChain), LangFuse (открытый), Arize Phoenix, Braintrust. Многие пишут собственные evals-наборы поверх этих платформ, потому что качество агента зависит от конкретной задачи, а универсальных метрик мало.

Часть логики берут на себя фреймворки для сборки агентов — LangGraph, OpenAI Agents SDK, CrewAI, — но они отвечают за построение агента, а не за надзор за ним в бою. Наблюдаемость и контроль стоимости приходится достраивать. Проверяйте актуальные возможности и цены этих инструментов на их официальных страницах: они обновляются часто.

Кому это пригодится, а кому нет

Роль оправдана, если:

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

Роль избыточна, если:

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

На практике Agent Ops редко становится отдельной ставкой на старте. Чаще это часть обязанностей ML- или платформенного инженера, которая разрастается по мере того, как агентов становится больше и цена их ошибок растёт. Выделять человека целиком имеет смысл, когда ручной присмотр начинает съедать рабочее время команды.

¹ ИИ-агент — система на основе языковой модели, которая не просто отвечает текстом, а сама выбирает и вызывает инструменты (поиск, API, код) в несколько шагов для достижения цели, принимая промежуточные решения без участия человека.