Контроль автономных AI-агентов
Проектирование и прототипирование в Codex: как команды запускают, отслеживают и контролируют автономных агентов в реальных рабочих процессах.
Идея
AI-агенты уже умеют писать код, но им по-прежнему не хватает контекста, на который опираются разработчики. Большая часть этого контекста остается неявной: он не структурирован и недоступен системе.
Из-за этого агенты выдают результат без полного понимания цели, разработчики тратят время на правки, а доверие к процессу снижается. AI ускоряет генерацию кода, но сам по себе не создает общего понимания задачи.
От промптов к контексту
Чтобы давать осмысленный результат, агентам нужен доступ к тому же контексту, с которым работают разработчики: откуда появилась задача, какие есть продуктовые ограничения, как выглядит хороший результат и какие решения уже были приняты в процессе.
Сейчас этот контекст разбросан по документации, чатам, тикетам и другим инструментам и редко складывается в цельную картину. Поэтому разработчикам приходится вручную собирать его в промптах, тратя время и все равно рискуя что-то упустить.
Агентам нужен прямой доступ к этой экосистеме: не через промпты, а через структурированный контекст. Подходы вроде MCP позволяют подключать агентов к тем же инструментам, которыми уже пользуются разработчики.
Если система работает для инженеров в масштабе, она должна работать и для агентов.
Главный челлендж
Исследование и инсайты
Миньоны от Stripe
Я начал с изучения подхода Stripe к облачным агентам, известным как Minions.
Таких агентов можно запускать из Slack или других внутренних инструментов. Они работают с доступом к контексту и выполняют задачи в фоне.
Но интерфейс показывает ограничение: он хорошо работает для отдельных запусков, но начинает разваливаться, когда параллельно выполняется несколько агентов.
В этот момент становится сложно понять, чем занимается каждый агент, как продвигаются задачи и как результаты связаны между собой.
Это показывает разрыв между выполнением задач и управлением ими. Агенты уже могут выполнять работу, но у разработчиков все еще нет понятного способа наблюдать за ними как за системой.
Интерфейс Stripe Devbox
Источники: How I AI, Stripe’s Article about Minions
Агенты - это не роли
Сначала я рассматривал структуру агентов как роли в реальной команде: Frontend Engineer, Backend Engineer, CTO. Каждый агент отвечал бы за свою область и выполнял задачи параллельно. Похожий подход использует Paperclip.
Но после обсуждений с разработчиками стало понятно, что такая модель плохо отражает реальную работу. Разработчики не мыслят жесткими ролевыми границами: одна задача часто затрагивает сразу несколько областей, от фронтенда до бэкенда и дальше.
Фиксированные роли создают лишние ограничения и снижают полезность агентов. Поэтому система должна строиться вокруг задач и контекста, позволяя агенту адаптироваться к проблеме, а не заранее заданной категории.
Первые итерации
Разделение выполнения и наблюдения
Также стало понятно, что объединять слой выполнения и слой наблюдения в одном интерфейсе не работает. Когда все выглядит одинаково важным, ничего не выделяется.
Фокус сместился к ясности: интерфейс должен сразу показывать разработчику, что требует внимания. В любой момент нужно понимать, что делают агенты, какие задачи готовы к ревью и где требуется вмешательство.
Основной единицей интерфейса стал run. Каждый run дает понятный снимок задачи: текущее состояние, связанные изменения в коде, контекст выполнения и следующее возможное действие.
Task status transitions
Иногда агенту нужно подтверждение человека, прежде чем продолжить работу. Например, если действие чувствительное или может сильно повлиять на продукт.
После подтверждения агент продолжает выполнение. В этот момент разработчику важно ясно видеть переход из одного состояния в другое.
Для этого изменения статуса оформлены как плавные переходы: так проще отследить, что произошло, и понять текущее состояние агента.
Что такое Agent Run
Внутри run
Вместо чат-интерфейса он работает с заранее заданным контекстом из Slack, поэтому задача и ожидаемый результат уже известны.
Основной экран показывает активность как структурированный лог: действия агента и изменения в коде, которые из них следуют.
Разработчик все еще может направлять процесс: добавлять инструкции в сайдбаре, смотреть исходный промпт, связанные источники и состояние репозитория.
Когда run завершен, система подсвечивает, что требует ревью, и показывает summary, чтобы разработчик мог сразу перейти к созданию pull request.
Создание pull request из завершенной задачи
После завершения run разработчик проверяет изменения, которые подготовил агент.
Если все выглядит корректно, pull request можно создать прямо из интерфейса, не выходя из рабочего процесса.
Другие кейсы
Playdex - NFT маркетплейс
Steamify - скупка скинов