Команда разработчиков выбрала архитектуру, где управляющий агент работает вне изоляционного контейнера-песочницы, поскольку этот подход лучше решает задачи для мультипользовательских систем, где работают десятки инженеров в одной организации. В такой модели цикл агента не живёт внутри песочницы, а запускает инструменты через внешний API, отправляя код в изолированный контейнер только тогда, когда нужно выполнить конкретную команду. Если циклом управления работать внутри песочницы, то она становится неотделимой от сессии: её сбой означает потерю всей работы, а хранилище данных превращается в сложную файловую систему, которая не масштабируется. Напротив, размещение агента снаружи позволяет выносить ключи доступа, токены пользователей и права на работу с базами данных из опасной зоны песочницы. Кроме того, контейнер можно подвесить в режиме ожидания и перезапускать при необходимости, экономя ресурсы, так как многие операции вроде анализа текста или ожидания завершения сборки требуют лишь доступа к базе данных, а не выполнения команд в песочнице. Однако у этого подхода есть проблемы. Агенты полагаются на файловую систему: навыки хранятся в файлах, а память тоже структурирована как каталоги. При работе вне песочницы эти данные не должны исчезать при перезапуске контейнера, а несколько инженеров не должны видеть устаревшие данные при параллельной работе над инцидентом. Простое синхронизирование файлов в базу данных создаёт проблемы распределённой файловой системы, которые сложно решить. Команда решила встроить виртуализацию доступа к файловой системе прямо в интерфейс агента. Инструменты чтения, записи и редактирования остаются одними и теми же для пользователя, но на бэкенде запросы к путям с префиксами навыков или памяти маршрутизируются прямо в базу данных, а не в файлы контейнера. Это позволяет агенту думать о файловой системе как раньше, сохраняя при этом целостность данных в базе Postgres. При этом виртуализация критически важна: обучение моделей на интерфейсах с множеством специфичных инструментов снижает их эффективность. Если добавить отдельный инструмент для чтения памяти, модель будет путаться, выбирая неправильное действие, так как не была обучена на такой разметке API. Команда предпочла сохранить единый интерфейс, имитирующий файловую систему, даже если часть файлов фактически хранится в другой базе. Остаётся одна незакрытая проблема безопасности. Агент имеет доступ к оболочке bash, которая может обходить виртуализацию и напрямую обращаться к файловой системе песочницы, игнорируя логику базы данных. Сейчас команды используют два метода защиты: промпт, запрещающий использовать bash для работы с виртуализованными пространствами, и парсер на базе tree-sitter, который анализирует команды bash на наличие попыток обратиться к чувствительным путям. Оба метода работают не идеально, но пока справляются. Также вопрос последовательного выполнения обновлений памяти остаётся открытым: команда использует стратегию «последний писатель выигрывает», так как строгая изоляция сессий создаёт паттерны блокировок, которые трудно контролировать. Быстрая эволюция инструментов в популярных фреймворках тоже создаёт риски, так как новый функционал может предполагать локальную файловую систему, которую виртуализация не всегда успевает перенять.
Anthropic добавила защиту файловой системы в агенты
02.05.2026 21:21 · hackernews