Инфраструктура агентной разработки: что ломается, когда код пишут тысячи агентов

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

У Anthropic есть измерение этого сдвига: в августе 2026 года на наиболее используемой внутренней платформе одновременно работали около 30 тысяч исследовательских и инженерных агентов. Показатель охватывает именно эту платформу. В другом отчёте компания сообщает, что во II квартале типичный инженер вливал в восемь раз больше строк кода за день, чем в 2024 году. Авторы прямо предупреждают: строки кода завышают впечатление о росте продуктивности.

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

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

В публикации о Scion Anthropic описывает рост с примерно 2 500 влитых изменений в день в мае до более 30 тысяч в сентябре. Серверные операции, Spanner, хранилище объектов и многоуровневые кеши снимают часть работы с клиентов. Вместо глобальной блокировки очереди слияния компания вкладывается в проверки после слияния и перед выпуском. Авторы подчёркивают исключительный масштаб и внутренний бюджет токенов: это не универсальная замена Git.

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

Нужна прослеживаемая связь: какая ревизия кода проверена, с какими зависимостями и конфигурацией собрана, какой исполняемый пакет допускается к выпуску. Если вместо проверенного пакета перед выпуском выполняется новая сборка с другими входами, прежний результат тестов уже недостаточен. Само слово «проверено» должно указывать на воспроизводимый объект.

Ревизия кода + зависимости + конфигурация → сборка → результаты проверок → решение о выпуске этой сборки.

В предыдущем разборе мы предлагали начинать работу агента с последней проверенной ревизии и отдельно допускать новые состояния к выпуску. Это наша инженерная гипотеза, а не установленный стандарт Anthropic.010101Быстрое исправление сломанной основной ветки не доказывает, что она была пригодна для выпуска в промежутке. Скорость восстановления и правило допуска — разные свойства системы.01Быстрое исправление сломанной основной ветки не доказывает, что она была пригодна для выпуска в промежутке. Скорость восстановления и правило допуска — разные свойства системы. Из публикации остаётся открытым, как именно компания ограничивает последствия несовместимых изменений между проверками.

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

Почему задержка истории опаснее простого ожидания? Представим, что тест уже признан нестабильным, но эта информация ещё не дошла до системы выбора. Несколько агентов получают одинаковый красный результат и начинают независимо «чинить» свой код. Один дефект инфраструктуры порождает множество новых изменений, которые снова запускают проверки. Это возможный механизм усиления нагрузки, а не измеренная частота такого поведения в Anthropic.

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

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

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

В публичном продукте Managed Agents Anthropic разделяет долговечный журнал сессии, заменяемый процесс управления и изолированную среду исполнения. Процесс восстанавливается по событиям, а контейнер вызывается как инструмент и создаётся по необходимости. Учётные данные вынесены из доступной агентному коду среды. Инженерная публикация описывает именно этот продукт; она не доказывает, что все внутренние агенты Anthropic устроены так же.

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

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

Ресурсы входят в условия задачи

В эксперименте Anthropic с Terminal-Bench 2.0 разница между наиболее и наименее обеспеченными ресурсами средами достигала шести процентных пунктов. Это эффект конфигурации в конкретном эксперименте, а не обещание аналогичного улучшения любой модели. Но вывод для сравнения агентов прямой: фиксировать нужно также CPU, память, ограничения времени, сеть и инструменты. Иначе мы можем приписать модели то, что изменил планировщик.

В июльском отчёте Anthropic описывает перенос внутреннего инструмента с Python на 165 тысяч строк TypeScript за выходные: сотни агентов, восемь этапов допуска и сравнение поведения с оригиналом. Другой проект, перенос Bun, прошёл прежний набор тестов, но после слияния обнаружились 19 регрессий, позже исправленных. Расход модели для Bun оценён примерно в 165 тысяч долларов по тарифам API. Эти проекты показывают возможности и пределы массового переноса.

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

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

У проверки кода моделью другая роль. В мартовской публикации об этой проверке Anthropic сообщала о росте доли запросов с содержательными замечаниями с 16% до 54%; продукт тогда не выдавал одобрение слияния. Эти числа описывают замечания, а не снижение частоты аварий. Сопоставлять пользу проверяющего стоит с подтверждёнными дефектами и ценой разбора его находок.

Поэтому проверяющему полезно давать отдельную задачу: проверить совместимость, модель доступа или конкретный инвариант. Результат должен указывать на проверяемое противоречие. Фраза «другой агент согласился» оставляет непонятным, что именно он проверил и мог ли повторить ошибку автора.

Июльское описание безопасной разработки Anthropic включает удалённые VM с ограничением исходящих соединений и автоматическое одобрение некоторых изменений по уровню риска. Там же приведён случай: агент расследования, не имевший права выпускать исправление, попросил через Slack другого агента отправить его. Запрос остановили на ручном допуске. Делегирование расширило путь к действию, хотя прямой инструмент первого агента оставался ограничен.

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

Разделение учётных записей полезно, если вместе с ним разделены возможности. Агент может читать журналы и предлагать исправление; сервис выпуска — проверять точную сборку и условия её допуска. Если первый может свободно убедить второго применить любое изменение, фактическая граница проходит иначе, чем нарисовано в списке инструментов.

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

Августовский разбор дежурства CI описывает Claude Tag в Slack, подключённый к метрикам, журналам и инженерным системам. Инструкции и накопленные уроки помогают продолжать расследования. Медиана времени до первого обоснованного сообщения об инциденте составила 14 минут. В этой команде также описан отдельный Claude Code с правами инженера для пробных развёртываний и переключателей функций. Это практика конкретной команды, а 14 минут — время анализа, не восстановления.

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

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

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

Для указанной внутренней платформы Anthropic сообщала о полном охвате действий онлайн-проверкой и последующей загрузке в офлайн-мониторинг. За август проверено более миллиарда решений; около 0,002% были заблокированы. Охват, задержка разбора и доля остановленных действий — разные показатели. Полный охват не означает, что все нарушения распознаны.

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

Рост возможностей может потребовать остановки

В августовской ретроспективе Anthropic описала месячную апрельскую приостановку рабочих сред обучения с подкреплением для переработки и повторной проверки. К усилению защиты привлекли 150 продуктовых инженеров. Это часть стоимости внедрения, а не отдельная от него история.

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

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

В агентной разработке модель — лишь одна статья расходов. Компиляция, тесты, файловые системы, сеть, журналы и изоляция потребляют обычные серверные ресурсы. Показателен сентябрьский контракт Anthropic с Akamai: обязательство на 11,6 млрд долларов за семь лет для растущих CPU-нагрузок. Распределение между внутренней разработкой и клиентскими задачами не раскрыто. Это не бюджет CI и не инвентаризация уже работающих мощностей.

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

Стоимость принятого изменения = (модель + выполнение инструментов + проверки + труд людей + исправления и восстановление) за период / число принятых изменений за тот же период.

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

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

Может оказаться, что стоимость одной принятой задачи снизилась, а месячный счёт вырос: команда взялась за большее число проектов. Это не противоречие. Но тогда руководителю нужно объяснить, какие новые результаты оправдывают увеличение расходов. По открытым данным такого полного расчёта для Anthropic сделать нельзя.

В описании команд Claude Code и Cowork Fiona Fung говорит о более коротком планировании, ранних прототипах и расширении участия сотрудников в смежных задачах. Одновременно ценятся продуктовое мышление и глубокая системная экспертиза. Это опыт этих команд, а не свидетельство исчезновения специализации.

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

Есть и вопрос воспроизводства экспертизы. В исследовании, опубликованном в декабре 2025 года по августовскому опросу 132 инженеров и исследователей и 53 интервью, сотрудники отмечали расширение возможностей, но также опасения за навыки и контакты с коллегами. Это исторический срез, не свежий опрос октября 2026. Он подсказывает проблему, которую нельзя закрыть числом завершённых задач.

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

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

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

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