Как компании разрабатывают автономные ИИ-агенты: контур контроля в проде

Автономные ИИ-агенты отличаются от прототипа не моделью и не промптом, а контуром, который держит их в рамках: подтверждением опасных действий, урезанным списком инструментов, эвалами перед выкаткой, трассировкой каждого шага и правом откатить прогон. Прототип оценивают по одному удачному ответу, прод-агента по тому, что он делает в худшем из своих сценариев. Ниже разобрано, чем компании удерживают агента, которому разрешили действовать самому.

Что меняется при выходе агента из прототипа в прод

Первое: цена прогона. Anthropic формулирует компромисс прямо, агентные системы обменивают задержку и стоимость на качество решения задачи. Их замер: агент расходует примерно в 4 раза больше токенов, чем обычный чат, мультиагентная схема примерно в 15 раз больше, и расход токенов объясняет около 80% разброса в качестве работы.

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

Третье: организация. Gartner в пресс-релизе от 25 июня 2025 года прогнозирует, что более 40% агентных ИИ-проектов будут закрыты до конца 2027 года, называя причинами рост издержек, размытую ценность и недостаточный контроль рисков. Страница релиза отдаёт код 403 на машинный запрос, формулировка сверяется вручную по тексту на сайте Gartner.

Подтверждение опасных действий: пауза, одобрение, возобновление

Штатный механизм описан в разделе Guardrails and human review документации OpenAI Agents SDK. Инструмент помечается флагом needsApproval: true в JS/TS или needs_approval=True в Python. Такой инструмент не выполняется сразу: прогон останавливается, и вместо результата вызова записывается interruption. Приложение получает объект результата с полями interruptions и state, вызывает state.approve(interruption) либо отклоняет запрос и возобновляет работу тем же состоянием через run(agent, state) в JS/TS или Runner.run(agent, state) в Python.

Важная деталь оттуда же: если проверка занимает время, состояние сериализуют, кладут в хранилище и возобновляют позже, и это остаётся тем же прогоном, а не новым запуском. Именно это позволяет поставить между шагом агента и его исполнением человека с обычным рабочим графиком.

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

Ограничение прав и набора инструментов

Второй рубеж: агент физически не может вызвать то, чего у него нет. В Claude Agent SDK права проверяются в шести шагах строго по порядку: хуки, deny-правила, ask-правила, режим прав, allow-правила, колбэк canUseTool. Порядок здесь и есть содержание: deny-правило блокирует вызов даже в режиме bypassPermissions, а хук PreToolUse отрабатывает раньше всех остальных проверок, поэтому проверку, обязательную на каждом вызове, кладут в хук, а не в колбэк.

Режимов шесть: default, dontAsk, acceptEdits, bypassPermissions, plan, auto. Для жёстко ограниченного фонового агента документация предлагает связку: перечислить инструменты в allowedTools и поставить permissionMode: «dontAsk», тогда всё не перечисленное отклоняется, а не превращается в вопрос. Там же зафиксирована ловушка: allowed_tools не ограничивает bypassPermissions, в нём одобряется каждый инструмент, включая Bash и Write, и урезать его можно только через disallowed_tools.

Форма правила меняет поведение. Запись disallowed_tools=[«Bash»] убирает описание инструмента из запроса, агент его не видит. Запись disallowed_tools=[«Bash(rm *)»] оставляет Bash доступным, но блокирует совпадающие вызовы во всех режимах. Разница видна при разборе инцидента: в первом случае в трассе не будет даже попытки, во втором попытка зафиксируется.

Тот же принцип закреплён в разделе Scope Minimization документа Security Best Practices протокола Model Context Protocol: начинать с минимального набора скоупов и повышать привилегии точечно через scope-челлендж в заголовке WWW-Authenticate. Омнибус-скоупы вида all и full-access названы прямой ошибкой: украденный токен открывает всё сразу.

Guardrails: три рубежа проверки вокруг вызова

Документация OpenAI Agents SDK различает три типа guardrails. Input guardrails валидируют запрос до запуска основной модели. Output guardrails проверяют и правят финальный ответ. Tool guardrails проверяют аргументы вызова функции и его результат. Срабатывание оформлено как tripwire: прогон прерывается исключением, например InputGuardrailTripwireTriggered, и приложение решает, что показать пользователю.

Tool guardrails на практике самые полезные, потому что ловят не формулировку, а действие: сумму перевода выше порога, получателя вне белого списка, SQL с оператором DELETE без условия WHERE, путь за пределами рабочего каталога. Такая проверка детерминирована и не требует второго вызова модели. Anthropic описывает и модельный вариант: один экземпляр модели обрабатывает запрос, второй параллельно проверяет его на недопустимое содержимое.

Изоляция среды и сетевой периметр

Если агент выполняет команды и правит файлы, ограничивают саму среду: в OpenAI Agents SDK под это выделен раздел Sandbox agents, контейнерное окружение с файлами, командами, пакетами и снимками.

Сетевой периметр в проде выглядит как список разрешённых хостов. В GitHub Copilot coding agent межсетевой экран включён по умолчанию вместе с рекомендованным allowlist: репозитории пакетов ОС (Debian, Ubuntu, Red Hat), реестры контейнеров (Docker Hub, Azure Container Registry), реестры пакетов популярных языков, центры сертификации для проверки TLS и хосты загрузки браузеров. Заблокированный запрос не молчаливый: предупреждение с заблокированным адресом и командой, которая пыталась сделать запрос, добавляется в тело нового pull request или комментарием к уже открытому. Отключить экран можно на уровне организации или репозитория, и, по документации GitHub, это повышает риск вывода кода на произвольный хост.

Отдельный слой: инструменты по MCP. Документ Security Best Practices протокола делит требования на обязательные и рекомендованные, и разницу стоит держать в голове. Через MUST записаны три вещи: сервер не принимает токены, выпущенные не для него (запрет token passthrough); сессии не используются как средство аутентификации; идентификаторы сессий недетерминированные. Через SHOULD записаны привязка идентификатора сессии к идентификатору пользователя и блокировка запросов в диапазоны 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, fc00::/7 и fe80::/10, где по адресу 169.254.169.254 отдаются облачные учётные данные. Обязательное требование к клиенту при запуске локального сервера в один клик: показать пользователю точную команду без усечения и дождаться явного согласия.

Эвалы и регрессионные прогоны

Агента нельзя принимать по одному удачному диалогу: та же задача при следующем запуске пойдёт другим маршрутом. В документации OpenAI Agents SDK под это выделен раздел Evaluate agent workflows: оценивают рабочий процесс целиком, а не отдельный ответ модели, а трассы советуют использовать сначала для отладки и только потом заводить цикл оценки.

Порог входа ниже, чем принято думать. Anthropic указывает, что для ранней проверки хватает примерно 20 запросов из реальных сценариев. Оценивают их через LLM-as-judge по рубрике из пяти критериев: фактическая точность, корректность цитирования, полнота, качество источников, эффективность использования инструментов. Шкала от 0.0 до 1.0 плюс отметка pass или fail, чтобы можно было и сравнивать версии, и ставить порог приёмки.

Регрессионный прогон гоняет тот же набор кейсов перед каждым изменением промпта, модели, набора инструментов или правил доступа, а пополняют набор из трасс реальных инцидентов. Проверяют не только ответ, но и путь: сколько шагов сделал агент, какие инструменты вызвал, сколько токенов потратил.

Трассировка и разбор инцидентов

Без трассы автономный агент не расследуется. Трассировка в OpenAI Agents SDK включена по умолчанию, и в неё попадает прогон целиком, каждый вызов модели, вызовы инструментов вместе с их результатами, хендоффы и срабатывания guardrails, плюс пользовательские спаны. Смотрят это в разделе Traces на платформе, а документация советует не выключать наблюдаемость полностью, а пользоваться настройками уровня SDK или отдельного прогона.

Anthropic описывает свой прод-контур так: полная трассировка решений агента, но без мониторинга содержимого разговоров. Для российских компаний это рабочий компромисс, потому что в трассу почти всегда попадают персональные данные: пишем последовательность вызовов и параметры, а не сырой текст.

Откат, лимиты и постепенная выкатка

Автономный агент работает долго, поэтому падение на середине не должно означать запуск с нуля. Anthropic использует чекпойнты и возобновление: система поднимается с точки отказа. При выкатке новой версии применяются rainbow deployments, трафик переключается постепенно, а уже запущенные прогоны доживают на прежней версии.

Второй ограничитель: потолок шагов. В документации OpenAI Agents SDK превышение лимита шагов отнесено к тем же runtime-сбоям, что исключения guardrails и ошибки инструментов, то есть обрабатывается приложением как штатный исход. У фоновых агентов встречается и потолок по времени: у GitHub Copilot coding agent предельная длительность одной сессии составляет 59 минут, и он работает только в одной ветке за раз, открывая ровно один pull request на задачу. Anthropic отдельно отмечает, что параллельные вызовы инструментов сократили время исследования на сложных запросах до 90%, то есть коротким прогон делают не урезанием задачи, а параллелизмом.

Работа с ИИ-агентами: регламент для сотрудника

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

1. Очередь подтверждений и срок реакции. Каждое действие с флагом needs_approval попадает в очередь с владельцем и сроком. Состояние сериализуется и возобновляется как тот же прогон, поэтому срок ставят в рабочих часах, а не в секундах.
2. Что показывают подтверждающему. Не «агент хочет выполнить действие», а имя инструмента и его аргументы: получатель, сумма, путь, идентификатор записи. Именно аргументы проверяют tool guardrails, и именно их должен видеть человек.
3. Как читают трассу. Разбор начинается с последовательности спанов: вызов модели, вызов инструмента, результат, хендофф. Сначала ищут первый шаг, где результат разошёлся с ожиданием, потом читают текст.
4. Что делать при сбое. Зафиксировать идентификатор трассы, остановить прогон, откатить действие вручную, если оно прошло, и добавить кейс в набор эвалов.

ИИ-агент помощник и распределение ответственности

ИИ-агент помощник не снимает ответственность с сотрудника, он перераспределяет её между четырьмя ролями, и границы удобно проводить по механизмам доступа.

• Владелец процесса отвечает за список разрешённых инструментов и за то, какие действия помечены как требующие подтверждения.
• Информационная безопасность ведёт deny-правила и сетевой allowlist: deny-правило срабатывает раньше режима прав и блокирует вызов даже в bypassPermissions, разработчик не перекроет его настройкой запуска.
• Инженер отвечает за хуки, guardrails, набор эвалов и трассировку. Проверки, обязательные на каждом вызове, он кладёт в PreToolUse-хук, потому что автоматически одобренные вызовы до пользовательского колбэка не доходят.
• Дежурный сотрудник подтверждает действия из очереди и разбирает трассы. Его метрика не число одобрений, а доля отклонённых действий и время реакции.

Примеры ИИ-агентов и встроенные в них ограничители

Полезнее смотреть не на список задач, а на то, чем в конкретных продуктах ограничена автономность. Ниже примеры ИИ-агентов и ограничители из документации к ним.

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

Частые вопросы

Чем автономный агент отличается от прототипа

Набором ограничителей: подтверждение необратимых действий через флаг needs_approval, явные deny-правила, три типа guardrails, трассировка всех вызовов и набор эвалов минимум из 20 реальных запросов, который прогоняется перед каждым изменением.

Какое действие обязательно подтверждать человеком

Любое необратимое: платёж, отправку внешнему получателю, удаление, изменение прав, публикацию. Технически это флаг needsApproval: true в JS/TS или needs_approval=True в Python: прогон останавливается, приложение получает interruptions и state и после state.approve(interruption) продолжает тот же прогон.

Как понять, что новая версия агента стала хуже

Регрессионным прогоном на фиксированном наборе кейсов с оценкой по рубрике из пяти критериев по шкале от 0.0 до 1.0 с отметкой pass или fail. Сравнивают и результат, и путь: число шагов, состав вызовов, расход токенов.

Что ограничивает агента, который ходит в интернет и запускает команды

Песочница плюс сетевой allowlist. У GitHub Copilot coding agent межсетевой экран включён по умолчанию, а заблокированный запрос попадает комментарием в pull request. Для инструментов по MCP документ Security Best Practices рекомендует клиенту блокировать приватные диапазоны, включая 169.254.0.0/16 с облачными учётными данными.