Четыре проверки перед тем, как отдать агенту весь проект

Одну задачу coding agent решает сам: читает репозиторий, пишет код, гоняет тесты. Дальше обычно вмешивается человек — оценивает результат, ставит следующую задачу, передаёт контекст, разбирает ошибки. Если убрать человека из этого цикла и поручить оркестратору вести проект от идеи до работающей версии, генерация кода быстро перестаёт быть главной проблемой.

Схема такой системы выглядит так:

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

Сложности начинаются, когда от схемы переходишь к гарантиям, которые можно проверить. Что агенту разрешено видеть? Как остановить всё, что он запустил? Что делать, если координатор упал после внешнего действия, но до записи результата? Ниже — четыре эксперимента с прототипом такого оркестратора на macOS и выводы, которые из них получились.

Закрытый файл, открытая сеть

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

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

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

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

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

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

• доступ к данным контролируется по всем каналам сразу: файлы, сеть, работающие сервисы, вывод инструментов;
• «задача завершена» означает, что вся её нагрузка, включая отделившиеся потомки, фактически остановлена. Сигнала группе процессов для этого мало.

Три VM и broker

Следующий кандидат — отдельные Linux VM на Mac под разные роли:

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

В execution VM работают агенты, в product VM — создаваемый продукт, verification VM отвечает за доверенную проверку. У недоверенной нагрузки нет прямой сети и общих с хостом директорий. Каждая разрешённая операция идёт через broker, который проверяет её тип, контекст и полномочия.

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

Одну дыру VM не закрывает. Сервер продукта живёт в изолированной VM, а пользователь открывает приложение в обычном браузере — и полученный JavaScript выполняется уже на хосте. Сервер в виртуалке не делает изолированным весь продукт. Границы доверия приходится проводить по потокам данных и выполняемым действиям; граница процесса или машины их не задаёт.

Статус на сейчас: VM с broker — рабочий кандидат. Безопасный доступ к продукту, реальные AI-каналы и полноценный сетевой broker остаются отдельными задачами.

2 GB гостевой памяти больше 2 GB на хосте

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

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

• Лимит виртуального адресного пространства процесса ничего не говорит о физической памяти, которую потребляет вся система.
• Лимит накопленного CPU-времени не дал нужного поведения при запуске и остановке VM.
• Внешний watchdog замечает превышение по наблюдаемой метрике и останавливает нагрузку, но срабатывает с задержкой, и порог к этому моменту уже может быть пробит.

Похожая история с давлением памяти. Прототип наблюдателя прошёл 44 из 44 проверок. В следующем read-only прогоне независимый наблюдатель собрал 698 показаний, вспомогательный процесс — ещё 170, и все они были WARN: реального перехода между состояниями ни разу не случилось. Получение и обработка наблюдений проверены, цепочка «давление выросло → нагрузка вовремя остановлена → система восстановилась» — нет.

Практическое следствие — разделить требование на два:

1. Технически ограничивать параметры гостевой среды и проверять эти ограничения отдельно.
2. Следить за состоянием хоста и при опасных условиях гасить свою нагрузку за заданное время.

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

Зелёные проверки отдельных компонентов не доказывают, что система целиком выполняет требование. 37/38 и 44/44 здесь соседствуют с отрицательным итогом.

Действие выполнено, координатор не в курсе

Отдельный класс проблем — падение управляющего процесса или исполнителя:

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

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

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

Прототип восстановления прошёл 159 из 159 проверок на исследованном наборе точек сбоя, резервного копирования и восстановления. Это результат конкретного прототипа; гарантии для любого аппаратного или производственного отказа он не даёт.

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

Что ещё не проверено и какие критерии приёмки

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

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

Если вы собираете похожий оркестратор у себя, четыре вопроса из этих экспериментов стоит задать до первого автономного запуска: по каким каналам агент может достать данные помимо файловой системы; останавливаются ли процессы, которые сделали setsid; сколько памяти хоста реально съедает VM сверх гостевого лимита; и что ваш координатор сделает с операцией, результат которой после падения неизвестен.