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