AI-агент с code interpreter: где ломается на живых задачах
AI-агент с code interpreter работает иначе, чем обычный чат-бот: вместо ответа «по памяти» модель пишет код, запускает его в изолированном окружении, читает вывод и уточняет расчёт. Именно выполнение кода в агенте даёт то, ради чего всё затевается — цифры считаются по вашим файлам, а не угадываются. Поэтому такой агент первым делом ломается там, где данные перестают быть учебно-аккуратными.
Первая точка отказа — расхождение схемы. На тестовом наборе таблица с ровными колонками, в реальной выгрузке — переименованные поля, пустые значения, разные разделители, листы без заголовка. Агент генерирует код под формат, который увидел в первой итерации, и падает на первом же непохожем файле.
Вторая — цикл: сбой не читается как сбой, агент правит одну строку, получает тот же результат и повторяет до лимита шагов, сжигая время и токены. Третья — изоляция запуска: если окружение не ограничено, сгенерированный код лезет в сеть, читает переменные окружения с ключами и пишет за пределы рабочей папки. И воспроизводимость результатов: без фиксации снимка данных, набора библиотек и случайного зерна два прогона одной задачи дают разные числа, а отчёт нечем защитить перед тем, кто будет по нему принимать решение.
Дальше разбираем, как это закрывается.
Что даёт управляемое выполнение кода в агенте
Управляемое выполнение кода — это когда сгенерированный агентом код уходит не в основной процесс, а в одноразовую изолированную среду с описанной политикой: доступные модули, сеть, время жизни процесса, лимиты памяти и диска. Агент остаётся планировщиком, а исполнение — отдельным шагом с проверяемым входом и выходом.
Повторяемые прогоны держатся на закреплённом окружении, тех же входных данных и тех же лимитах, поэтому разбор инцидента сводится к повтору запроса, а не к спорам «у нас локально работает». След прогона читается человеком: код, логи, промежуточные файлы и графики складываются в блокнот на базе Jupyter, и видно, каким шагом получена каждая цифра.
Ограничение прав агента убирает целый класс отказов: сеть — по списку разрешённых адресов, запись — только в рабочую папку, секреты не попадают в окружение. Неверный код портит одноразовую среду, а не рабочий контур, и стабильность агента перестаёт зависеть от аккуратности модели.
- Одинаковый запрос и то же окружение дают тот же артефакт — результат перепроверяем перед передачей заказчику.
- Сбой в одном шаге не роняет сервис: среда пересоздаётся с чистого состояния, восстановление занимает минуты.
- Лимиты по времени, памяти и диску отсекают зацикливание до того, как оно займёт общий контур.
- Доступ в сеть по списку адресов закрывает утечку данных наружу.
Итог — предсказуемое потребление ресурсов и повторяемость вместо надежды на удачный запуск: границы прогона, его след и лимиты описаны заранее.
Режимы работы code interpreter: сравнение подходов
Прежде чем AI-агент с code interpreter выполнит первую строку кода, нужно решить, где этот код исполняется. От режима зависят три вещи: дотянется ли агент до внутренних систем, какие данные покинут периметр и кто отвечает за эксплуатацию среды.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Песочница на нашей стороне | Открытые данные, быстрый старт, разовые задачи | Нет доступа к внутренним системам, данные уходят за периметр |
| Изолированная песочница в контуре заказчика | Работа с чувствительными данными | Нужны выделенные ресурсы и их эксплуатация |
| Локальный запуск на рабочей станции | Отладка сценариев, разовые вычисления | Нет воспроизводимости и общих лимитов |
| Запуск в процессе агента без изоляции | Прототипы, доверенный код | Ошибка или зацикливание роняет весь сервис |
Локальный запуск: где он уместен
Локальный запуск нужен на этапе отладки: инженер видит вывод и повторяет сценарий на своих данных. Как постоянный режим он не годится — набор библиотек у каждого свой, состояние среды не воспроизводится, а сбой одного сценария уносит рабочий процесс. Общего журнала нет, и разобрать по нему, что именно выполнил агент, не получится.
Песочница в инфраструктуре заказчика
Изолированная песочница поднимается в вашем контуре: код идёт в отдельном контейнере с урезанными правами, файловая система — только на чтение, исходящие соединения ограничены явным списком адресов. Данные не покидают периметр, а лимиты на процессорное время и память не дают одному сценарию занять узел целиком. Плата — выделенные ресурсы и совместная эксплуатация среды.
Ограничения среды мы фиксируем до старта, а не после первого инцидента — иначе режим запуска кода выбирается по факту сбоя.
Как мы внедряем агента: этапы инженерной работы
Работы идём в порядке, при котором риски всплывают до того, как агент получит доступ к данным и внешним системам. Сначала фиксируем сценарии, затем строим изоляцию, после — настраиваем права и лимиты, и только потом запускаем приёмку на реальных задачах.
- Аудит сценариев агента — разбираем, какие задачи он решает, где выполняет код, какие данные читает и куда пишет. Результат — карта сценариев с перечнем операций и точек, где нужна проверка человеком.
- Проектирование схемы изоляции — определяем, в какой среде исполняется код, как часто она пересоздаётся и что остаётся между запусками. Схему проверяем с двух сторон: что агент может сломать и что может утечь.
- Настройка прав и лимитов — выдаём только необходимые доступы: конкретные каталоги, список разрешённых адресов, ограничения по времени исполнения и объёму записи. Всё, что выходит за рамки, просто не выполняется.
- Подключение источников данных — агент получает файлы, базу и внешние сервисы, с которыми работает. Каждое подключение проходит через тот же контроль прав.
- Прогон на реальных задачах — проверяем сценарии вместе с ожидаемыми сбоями: неверный ввод, недоступный сервис, превышение лимита. Смотрим, как агент восстанавливается и что попадает в журнал.
- Приёмка агента — вы проверяете результат на своих задачах по критериям, согласованным заранее. Отдельно фиксируем, какие сбои считаем допустимыми, а какие блокируют запуск.
- Передача схемы и регламента сопровождения — отдаём описание архитектуры, правила обновления сценариев и порядок действий при отказе.
Что передаём на руки: конфигурации, политики и регламенты
Передаём не «работающий прототип», а комплект, по которому ваша команда эксплуатации может поднять агента на своём контуре и сопровождать его без нас. Интерпретатор кода исполняет сгенерированные программы в изолированной среде — значит, всё, что касается допусков, ограничений и наблюдаемости, должно быть зафиксировано письменно. Набор артефактов выглядит так.
- Конфигурация среды выполнения: описание базового образа, зафиксированный перечень библиотек, правила сетевого доступа, точки монтирования рабочих файлов.
- Политики доступа: роли и права, срок жизни ключей, порядок ротации секретов, разграничение между тестовым и рабочим контуром.
- Лимиты ресурсов: максимальное время одного запуска, объём памяти и диска на сессию, число одновременных сессий, поведение при исчерпании квоты.
- Матрица инструментов агента: какие вызовы разрешены автоматически, какие требуют подтверждения оператора, какие закрыты полностью.
- Схема хранения артефактов: где лежат промежуточные файлы, как настроено их истечение и как удалить данные по запросу.
- Передаваемая документация: инструкция по развёртыванию, перечень зависимостей, описание переменных окружения, точки подключения журналов и метрик.
- Набор проверок: сценарии на типовые запросы, тесты на исчерпание лимитов, контроль качества итоговых ответов перед выкаткой.
- Регламент сопровождения: уровни реагирования на сбои, окна обновления образов и библиотек, порядок отката на предыдущую версию.
Документы пишем так, чтобы инженер без нашего участия мог воспроизвести среду, изменить лимит или отозвать доступ. Отдельно проговариваем, какие места конфигурации рассчитаны на самостоятельную правку, а какие связаны с логикой агента и требуют согласования.
Кейс: стабильность агента до и после изоляции кода
Аналитическая платформа заказчика отдавала расчёты AI-агенту: он писал код по запросу пользователя и выполнял его прямо в процессе API. Пока запросы были простыми, это работало; на потоке из нескольких сотен сессий в сутки один бесконечный цикл или утечка памяти в чужом скрипте уводили рабочий процесс целиком — вместе с чужими задачами и незавершёнными диалогами. Доля сорванных задач держалась на 18%, а разбор каждого падения занимал у дежурного инженера часы: по логам нельзя было отличить ошибку агента от падения общего процесса.
Перенесли исполнение в отдельную изолированную среду на Docker: своя файловая система только для чтения, временный том для артефактов, запрет сетевых вызовов и жёсткие лимиты по процессору и памяти на сессию. Образ с зафиксированным набором библиотек собирается заранее — код агента не тянет зависимости из интернета и не ломает окружение соседям.
Что изменилось в поведении агента
Срыв сессии перестал быть общим сбоем: упавший расчёт завершается по лимиту времени, а очередь продолжает работать. Доля сорванных задач снизилась с 18% до 2%, отказов вида «агент завис и не отвечает» за квартал не осталось ни одного. Повторные запуски одного и того же запроса дают идентичный результат в 96% случаев — раньше расхождения ловили вручную, потому что окружение «плыло».
Отдельно выиграла диагностика: артефакты, логи запуска и входные данные складываются в один каталог — инцидент разбирается по фактам, а не по переписке. Время восстановления после падения расчёта — секунды вместо ручного перезапуска процесса и повторного прогона диалога.
Что делать, если агент уже работает без изоляции кода?
Останавливать сценарии не нужно: исполнение переезжает в изолированный контейнер параллельно, а прежний путь остаётся рабочим до сверки результатов. Разница принципиальная — песочница процесса ограничивает вызовы внутри интерпретатора, но делит с агентом адресное пространство, а изоляция на уровне контейнера задаёт границу для файловой системы, сети и прав пользователя. Поэтому сбой в первом варианте роняет сервис целиком, а во втором гасится вместе с контейнером.
| Вариант | Что ограничивает | Когда подходит | Ограничения |
|---|---|---|---|
| Песочница процесса | Импорты, доступ к путям, время выполнения | Демонстрации и внутренние задачи на доверенных данных | Делит память с агентом, падение интерпретатора останавливает сервис |
| Изоляция контейнера | Файловую систему, сеть, пользователя, память | Пользовательский код и данные из внешних источников | Нужен прогрев среды и сбор логов, запуск дольше |
Перевод уже развёрнутого агента выглядит так: в кластере Kubernetes рядом поднимается вторая среда исполнения, маршрутизация переключается долей трафика через флаг, а ответы сверяются с прежними на одной выборке задач. Расхождения разбираются до полного переключения, откат делается тем же флагом. Контейнеры переиспользуются между вызовами, поэтому время ответа не растёт, а лимиты на память и число процессов выставляются на каждый запуск отдельно.
В результате код от пользователя перестаёт считаться доверенным по умолчанию: даже при вредоносном скрипте наружу уходят только разрешённые файлы, а остальное отсекает граница среды.
Частые технические сомнения по изоляции исполнения
Такие вопросы инженеры задают на разборе чаще всего: где границы доступа агента к файлам, что остаётся в среде после сессии и как ведёт себя система, когда сгенерированный код падает. Ниже — короткие ответы по каждому пункту, без общих слов.
Что агент видит в файловой системе?
На сессию поднимается отдельный контейнер с собственным корнем. Внутрь монтируется только рабочая директория — сначала в режиме чтения, запись открывается явным разрешением на конкретные пути. Ключи и переменные окружения хоста не пробрасываются, выход за пределы смонтированного дерева закрыт политикой доступа, а сетевой обмен по умолчанию выключен.
Как очищается среда между запусками?
Состояние живёт ровно столько, сколько идёт диалог: агенту нужно видеть промежуточные файлы и результаты прошлых шагов. После завершения сессии контейнер удаляется целиком вместе с файловой системой, кэшем пакетов и временными данными — следующий запуск стартует с чистого образа. Наружу переносятся только артефакты из явного списка, поэтому данные одного пользователя не пересекаются с другим.
Что будет, если код упал или зациклился?
На исполнение ставится лимит по времени, памяти и числу шагов на задачу. При превышении процесс снимается, а агенту возвращается лог ошибки — он переписывает код и повторяет шаг, но не уходит в бесконечный цикл: зацикливание отсекается счётчиком итераций. Один сбойный запуск не вытягивает ресурсы всей задачи, а причина падения остаётся в журнале для разбора.
Обсудим задачу: соберём схему под ваш сценарий
Чтобы оценка объёма работ опиралась на факты, а не на предположения, к первому разговору достаточно описания сценария, примера входных данных и перечня систем, с которыми агент будет обмениваться. Если есть текущие наработки — формулировки инструкций для модели, тесты, логи отказов — присылайте: они заметно сокращают разбор.
Обсуждение задачи идёт по шагам: проходим сценарий целиком, отмечаем, что агент делает сам и где подключается человек, как проверяется корректность результата и что считаем ошибкой. По итогам собираем план внедрения с очередностью этапов и точками, на которых фиксируем готовность. По итогам обсуждения заказчик получает:
- схему решения: откуда приходят данные, в каком изолированном окружении выполняется код, куда возвращается результат;
- границы окружения: доступные библиотеки, ограничения по сети и файловой системе, время жизни процесса;
- перечень проверок и тестовых сценариев, включая отказные ветки и повторные запуски;
- оценку объёма работ по этапам с порядком запуска и точками контроля;
- список рисков и решений, которые снимают их до начала разработки;
- регламент эксплуатации: логирование, отслеживание ошибок, порядок обновления правил агента.
Опишите задачу в свободной форме — вернёмся с оценкой, схемой окружения и планом первого этапа. Если сценарий ещё не устоялся, разберём варианты и предложим тот, который быстрее проверить на реальных данных.
