Scion: как меняется хранение кода для агентов

Исходная проблема Anthropic — рост нагрузки на инфраструктуру разработки. Ведущий пересказывает показатели инженерной статьи: примерно 2500 ежедневных слияний в мае, свыше 30 тысяч в сентябре и порядка 25 миллионов получений кода в день только для CI. Речь идёт об операциях репозитория, а не о доказанном росте полезного результата разработки. Масштабирование прежней системы требовало всё больше усилий, поэтому команда пересмотрела исходные требования.

Ключевое допущение Scion состоит в том, что клиенты постоянно подключены к сети. Агенту всё равно нужен доступ к модели; возможность автономно работать с полной историей репозитория для этой нагрузки не обязательна. Отсюда возникает асимметричная архитектура: сервер выполняет сложные операции, а клиент хранит ограниченный набор необходимых данных. Цена такого решения — зависимость от сети, которую Git позволяет избежать в ряде сценариев.

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

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

Основная единица хранения — changeset, описание изменений относительно первого родителя. Метаданные размещаются в Google Spanner, содержимое файлов — в объектном хранилище. В отличие от указателя на готовое дерево в Git-коммите, нужные структуры могут вычисляться сервером из изменений. Поломодов объясняет подход через знакомую модель базы данных: сначала зафиксировать запись в журнале, затем подготовить представления для чтения.

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

Указатель на ветку или релиз не входит в сам changeset. Чтобы передвинуть ссылку, используется отдельная операция сравнения и замены значения в строке Spanner. Это разделение позволяет сохранять объекты изменений неизменяемыми: движение main не требует переписывать уже сохранённое содержимое. Регистрация изменений и выбор версии, на которую указывает ссылка, становятся разными действиями с разными последствиями.

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

Формулировка о доступности данных везде и мгновенно вызывает у ведущего вопросы. Гарантии Spanner относятся к этой базе, тогда как система также использует объектное хранилище и вычисляемые представления. Из статьи неясно, что именно становится доступно после подтверждения записи: метаданные, содержимое или все ответы API. Сильная согласованность не означает нулевой сетевой задержки, поэтому красивую фразу нельзя принимать за полный контракт системы.

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

По описанию Anthropic, семь инженеров создали Scion, Antique и связанные системы и провели переход за пять месяцев. Работу разделили между интерфейсами, клиентом и хранением. Ведущий считает скорость миграции существенным результатом, особенно когда инфраструктура уже ограничивает работу компании. Однако расход токенов не раскрыт, поэтому из срока и размера команды нельзя вывести стоимость такого проекта для другой организации.

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

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

При этом без текстового конфликта всё ещё могут разойтись контракты или поведение приложения. Ведущий упоминает свои размышления о локальных проверках и временной среде интеграции, но не развивает их в эфире: исходная статья этих деталей не раскрывает. Схему из дополнительных слайдов нельзя приписывать реализации Scion. Открытым остаётся вопрос, как устроен полный путь от принятого changeset до проверенного артефакта и безопасного релиза.

У Anthropic необычные условия: большой репозиторий, интенсивная работа онлайн-агентов, доступ к собственным передовым моделям и возможность проверять пределы их применения. Команда с другой нагрузкой, потребностью в автономной работе или оплатой токенов по внешним тарифам получит другую экономику. В статье названы источники вдохновения — Piper и Sapling; само наличие Scion не означает, что каждой компании нужна собственная система контроля версий.

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