Хотел поручить AI целый проект. Уперся в изоляцию, память и восстановление после сбоев

Что пришлось проверить, прежде чем доверять системе самостоятельную работу над программным проектом.

С чего все началось

Последние несколько месяцев я активно использую AI‑инструменты в разработке. Coding agent может изучить репозиторий, написать код, запустить тесты и предложить изменения. Но после завершения задачи кто‑то должен оценить результат, поставить следующую задачу, передать контекст и разобраться с ошибками. Обычно этот кто‑то — человек.

Мне стало интересно, можно ли передать системе больше работы: описать идею продукта обычным языком, уточнить требования, а затем последовательно получать работающие версии без ручного управления каждой AI‑сессией. Для исполнения я хотел использовать существующие CLI‑агенты, в том числе Codex CLI и Claude Code.

На схеме идея выглядела просто:

Идея пользователя
      ↓
Уточнение требований и план
      ↓
Задачи → AI-исполнители → проверка результата
      ↓
Работающая версия продукта

Проблемы начались, когда я попытался перейти от схемы к проверяемым гарантиям. Что агенту разрешено видеть? Как остановить все запущенные им процессы? Что делать, если система упала после выполнения внешнего действия, но до сохранения результата?

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

1. Запретить чтение файла недостаточно, чтобы защитить данные

Первым делом я проверял изоляцию исполнения на macOS. Агенту нужен доступ к файлам проекта, но не к другим репозиториям, пользовательским документам и данным работающих приложений. В первоначальном прототипе для этого использовался App Sandbox.

Тестовый development‑процесс не смог напрямую прочитать закрытый файл с синтетическими пользовательскими данными. Файловое ограничение сработало. Но после разрешения сетевого доступа тот же процесс получил эти данные через тестовый HTTP‑интерфейс работающего продукта.

Условно ситуация выглядела так:

Прямое чтение закрытого файла → отказ
Получение тех же данных через HTTP → успех

Сервис, адреса и данные были частью тестового стенда. Реальные документы никуда не утекли, да и неожиданным нарушением правил macOS это назвать нельзя, процессу явно предоставили сетевые возможности.

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

В том же прототипе обнаружилась проблема остановки процессов. Дочерний процесс отделился от группы родителя через setsid и продолжил запись после остановки этой группы. Координатор мог считать задачу завершённой и запускать следующую, пока предыдущий процесс продолжал работать.

Всего получил 97 наблюдений: 40 разрешённых операций и 57 отклонённых. Проверенная архитектура не выполнила обязательные требования.

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

2. Изоляция в VM помогла, но не решила все проблемы

Следующим кандидатом стали отдельные Linux VM на Mac. Одна для исполнения агентных задач, вторая для создаваемого продукта, третья для доверенной проверки. У недоверенной нагрузки нет прямого сетевого доступа и общих директорий с хостом. Разрешённые операции проходят через broker, который проверяет их тип, контекст и полномочия.

                   Mac
                    │
            Управляющий процесс
                    │
          Broker разрешенных операций
             ╱      │      ╲
            ╱       │       ╲
       Execution  Product  Verification
          VM        VM        VM

В исследованном сценарии процесс внутри execution VM мог работать со своим проектом, но не получал доступ к тестовым файлам хоста, соседнего проекта и пользовательским данным. Проверенные прямые сетевые пути также были недоступны. Настоящие Codex CLI и Claude Code выполнили сценарии с инструментами и MCP через синтетического провайдера.

Эксперимент подтвердил часть механики запуска и передачи запросов. VM также не решила вопрос доступа пользователя к созданному приложению. Если сервер работает внутри изолированной VM, а пользователь открывает приложение в обычном браузере, полученный JavaScript исполняется уже на хосте. Следовательно, нельзя считать весь продукт изолированным только потому, что его сервер находится внутри виртуальной машины.

В результате VM с broker стала рабочим архитектурным кандидатом, а безопасный доступ к продукту, реальные AI‑каналы и полноценный сетевой broker остались отдельными задачами. Для меня это стало важным архитектурным выводом: границы доверия необходимо определять через потоки данных и выполняемые действия, а не только через изоляцию конкретного процесса.

3. Два гигабайта памяти VM не означают два гигабайта памяти Mac

При проверке ресурсов обнаружилась следующая проблема. Если виртуальной машине выделено 2 GB памяти гостевой системы, это не означает, что вся связанная с ней нагрузка на хосте будет занимать не больше 2 GB. Есть память процесса виртуализации, вспомогательных компонентов и дополнительные накладные расходы. Причём не все из них можно надёжно приписать отдельному процессу.

Для проверки механизмов ограничений я провёл эксперимент с QEMU/HVF. Это было отдельное исследование ресурсного подхода, а не замена VM‑кандидата из предыдущего раздела. В одном из прогонов 37 из 38 проверок получили PASS, но общий результат остался отрицательным. Причина достаточно простая: необходимую совокупную гарантию для хоста доказать не удалось.

В частности:

• Ограничение виртуального адресного пространства процесса не доказывало предел физической памяти, потребляемой всей системой.

• Ограничение накопленного CPU‑времени не обеспечивало необходимое поведение запуска и остановки VM.

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

В итоге пришлось разделить два требования. Первое — технически ограничивать параметры гостевой среды и проверять их отдельно. Второе — наблюдать за состоянием хоста и при опасных условиях прекращать собственную нагрузку за установленное время. Абсолютный жёсткий предел совокупного потребления RAM и CPU всего Mac я теперь не заявляю.

Для мониторинговой защиты ещё необходимо определить допустимые превышения, доказать полноту учёта процессов и проверить время обнаружения и фактической остановки. Причём просто отправить сигнал завершения недостаточно. Нужно убедиться, что процесс действительно прекратил выполнение, а его ресурсы можно освободить.

С наблюдением давления памяти возникла похожая ситуация. Один из прототипов прошёл 44 из 44 проверок, но общий профиль так и остался непроверенным. В последующем read‑only прогоне независимый наблюдатель собрал 698 показаний, вспомогательный процесс — ещё 170. Все показывали WARN; реального перехода между состояниями не произошло.

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

4. Действие выполнено, а координатор об этом не знает

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

Здесь возникает достаточно неприятный сценарий:

Координатор отправил команду
           ↓
Действие могло выполниться
           ↓
Координатор упал до записи результата
           ↓
После перезапуска результат неизвестен

Если команда читала файл, повторное выполнение может быть допустимо. Если она изменила данные, создала внешний ресурс, отправила сообщение или использовала однократное разрешение, слепой повтор уже может привести к проблемам. При этом история AI‑сессии не устраняет неопределённость. В ней может просто не оказаться информации о фактическом результате последней операции.

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

В прототипе восстановления 159 из 159 проверок прошли для исследованного набора точек сбоя, резервного копирования и восстановления. Но это результат конкретного прототипа, а не гарантия корректной работы при любом аппаратном или производственном отказе. Полная квалификация жизненного цикла пока остаётся открытой.

Рядом обнаружилась ещё одна интересная проблема, уже при перезапуске сетевого relay. Позднее закрытие старого соединения могло затронуть новое, поскольку оба получали идентификатор conn-1. После добавления поколения к идентификатору сценарии рестарта прошли повторную проверку.

Причина заключалась в том, что имя ресурса само по себе не гарантирует его идентичность. После перезапуска за тем же именем может находиться уже другой экземпляр. Именно поэтому восстановление нельзя сводить к обычному продолжению AI‑сессии. Необходимо согласовывать сохранённое состояние с фактическими последствиями уже выполненных действий.

Что пока остается открытым

Все описанные эксперименты не отменяют первоначальные вопросы о декомпозиции задач, передаче контекста, выборе моделей и проверке качества кода. Они добавили целый набор требований, без выполнения которых я не готов запускать полностью автономную работу над долгоживущим проектом. Сейчас предстоит проверить полноценный сетевой broker, реальные механизмы авторизации двух CLI, безопасный доступ пользователя к приложениям внутри VM, защиту ресурсов Mac при изменении давления памяти, восстановление после сбоев и независимую проверку результатов работы агентов.

Для будущей версии я зафиксировал достаточно строгие критерии приёмки. Один и тот же релиз должен пройти автоматические проверки, 48-часовой прогон, семидневное длительное испытание и реальный цикл исчерпания и восстановления квоты хотя бы одного CLI. Не исключаю, что текущая архитектура ещё неоднократно изменится.

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

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