В Claude Code мне попалась подсказка, которую я описал в исходной заметке: размер агентного процесса можно ограничить прямо в запросе. Например, попросить небольшую команду, разрешить максимум пять агентов или задать размер по умолчанию через /config.
Я смотрел на неё с двойственным чувством. Последние месяцы я решал ту же задачу в своём инструменте, который проводит агентную работу от плана до готового изменения в репозитории. Но ограничить число одновременно работающих агентов оказалось лишь одной частью проблемы.
Как агентная задача разрастается
Я хотел, чтобы агент мог получить инженерную задачу, прочитать репозиторий, внести правку, проверить результат и передать изменение дальше. Самая трудная часть обнаружилась не в генерации кода. Трудно было предсказать, сколько работы агент создаст себе по дороге.
Одна задача превращается в несколько подзадач. Для них запускаются отдельные сессии, иногда в собственных git worktree. Проверки повторяются. Растут расход контекста, время и счёт за вычисления. Снаружи это выглядит как параллельная работа, но часть усилий уходит на обслуживание самой параллельности.
У меня накопились вполне материальные последствия таких запусков. В одном случае параллельные сессии за три недели заполнили диск. В другом тесты в нескольких worktree оставили во временной папке около 1,4 млн файлов; после этого Mac перестал загружаться, хотя свободное место ещё было. В разборе этого сбоя я привёл точный подсчёт: 1 378 905 файлов и 30 182 папки. В одном сравнении самый тщательный режим обходился примерно в 12 раз дороже дешёвого на задаче того же типа. Каждый дополнительный поток стоил примерно как ещё одна интерактивная сессия.
Эти цифры не означают, что любой запуск будет вести себя так же. Они показывают, почему мне понадобились ограничения, которые действуют на протяжении всей задачи, а не только в момент старта.
Пять агентов — понятный предел. Что происходит дальше?
Подсказка Claude Code описывает простой рычаг: зафиксировать размер команды. Я и сам пришёл к необходимости такого предела. Когда система может порождать новые работы и тратить реальные ресурсы, ограничение масштаба быстро становится обязательным.
Но сама задача проходит больше этапов:
-
Принять запрос и понять, что именно нужно сделать.
-
Решить, можно ли запускать работу при текущем бюджете и условиях.
-
Выполнить изменение.
-
Получить доказательства, что оно работает: тесты, проверки, просмотр diff.
-
Принять решение о слиянии.
-
Выполнить слияние и закрыть задачу.
Лимит в пять агентов отвечает лишь на вопрос о количестве параллельной работы. Он не определяет, кто допускает задачу к исполнению, сколько раз можно повторить неудачную проверку, какие доказательства достаточны для слияния и когда зависший запуск следует остановить.
Поэтому в своей системе я ограничиваю не только число потоков. У цикла проверки есть предел повторений; исчерпанный лимит не превращается в молчаливое разрешение на merge. Для изменения выбирается самый дешёвый маршрут, который всё ещё даёт нужную проверку. За человеком остаются выпуск и публикация. Остальное агенты могут делать самостоятельно в пределах заранее заданных условий.
Снаружи два инструмента могут одинаково показывать «не больше пяти агентов». Разница становится видна, когда одна из проверок не прошла или задача застряла на полпути.
Мог ли Claude Code взять эту идею из моих запусков?
Я строю свой инструмент с помощью Claude Code, поэтому после появления подсказки у меня возник неприятный вопрос: могла ли команда платформы увидеть мои решения? У меня нет фактов, которые позволяли бы так утверждать.
Здесь полезно различать несколько потоков данных. Запросы и ответы отправляются модели для работы сервиса. Отдельно существует операционная телеметрия: метрики использования и сообщения об ошибках. Согласно документации Anthropic, метрики не содержат код, запросы и пути к файлам; для них и для сообщений об ошибках предусмотрены отдельные настройки. Возможность использовать разговоры для обучения будущих моделей на пользовательских тарифах задаётся другой настройкой аккаунта. Команды /feedback, /bug и /share могут передать историю разговора, включая код, если пользователь сам отправляет такой отчёт.
Сам факт работы через платформу не доказывает, что кто‑то изучил мою архитектуру и повторил её. Для такого вывода понадобились бы датированные материалы, конкретные совпадения и понятная связь между ними. Пока у меня есть только совпадение по времени и по инженерной проблеме.
Какие ограничения пришлось добавить
Мне нужен процесс, который умеет остановиться, когда исчерпан бюджет или не получены доказательства готовности. Он должен понимать, какое решение можно принять автоматически, а где нужно передать его человеку. Простая настройка числа агентов этого не решает.
Появление похожей подсказки у Claude Code не отменяет работу, которую я уже сделал. Оно показывает, что вопрос контроля масштаба возникает и у других пользователей агентных систем. Для себя я сформулировал более строгий критерий: инструмент полезен тогда, когда изменение можно довести до проверенного результата, не оставив человеку разбирать последствия бесконтрольного запуска.
Источники
-
Исходная статья на английском — The tip described our problem. История подсказки Claude Code, замеры затрат и устройство агентного процесса.
-
Разбор сбоя Mac — Two hundred and sixty‑four gigabytes free. Точный подсчёт временных файлов и разбор сбоя загрузки Mac.
-
Документация Anthropic — Data usage. Передача запросов, телеметрия, обучение моделей и команды обратной связи.
Источник: habr.com