Смерть субагентов в Claude Code и Codex: нужно ли переписывать агентный пайплайн

Короткий ответ: нет, весь пайплайн переписывать не надо. Но если у тебя, как и у меня, скиллы Claude Code годами дергали классических субагентов на каждый чих - самое время сесть и посчитать, кто из них реально нужен, а кто просто жрет токены по привычке. Повод разобраться дала статья "Смерть сабагентов в Claude и Codex" - я наткнулся на нее в поиске, но к тому моменту, как я сел читать, оригинал на Хабре уже сняли модераторы "на доработку". Цифры ниже я беру по двум зеркалам, которые успели ее перепечатать, и там, где нашел независимое подтверждение у самой Anthropic - сверяю с ним отдельно.

Мой собственный конвейер статей (тот самый, что сгенерировал этот текст) построен на классических headless-вызовах - и вот тут интересно, ломает ли новая архитектура именно такую схему или только интерактивные многооконные сессии в терминале.

Что не так с классическими субагентами в Claude Code и Codex

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

По данным исследования Anthropic о собственной multi-agent research system (июнь 2025), агентные системы в среднем тратят в 4 раза больше токенов, чем обычный чат, а схема "оркестратор плюс субагенты" - уже в 15 раз больше. При этом расход токенов сам по себе объясняет 80% разброса качества на бенчмарке BrowseComp, число вызовов тулов - еще 10%, а выбор модели - оставшиеся 5%. То есть субагенты работают в основном потому, что жгут кучу токенов, а не потому, что архитектурно умнее.

В Claude Code 2.1.198+ к этому добавился баг с обрезкой: по зафиксированному в перепечатке случаю, дочерний агент сгенерировал 151 652 символа (около 75 тысяч токенов), а вызывающая сессия получила только 24 353 - то есть около 84% вывода потерялось, и статус при этом честно показывал "completed", без единого намека на обрезку. Представь, что ты попросил стажера написать отчет на 150 страниц, а тебе принесли последнюю страницу и сказали "готово, все по плану".

В Codex дела не лучше: функция wait_agent по умолчанию опрашивает субагента каждые 30 секунд и на каждый опрос генерирует новый оборот модели с раздутым контекстом, а параметр fork_turns в режиме FullHistory заставляет каждого потомка тащить за собой полную историю родителя. В одном из тестов из перепечатки это дало расход в 2,6 раза выше, чем у чистой сессии без гидратации истории.

Отдельно досталось экспериментальным Agent Teams: координация там идет через JSON-файлы в инбоксах команды с файловыми блокировками. Ведущий агент в разобранном кейсе сделал 42 226 вызовов readMailbox и словил 4 296 ошибок отсутствия файла; через 2 часа 24 минуты автор эксперимента плюнул, отключил командную координацию и доделал задачу в одиночку за 18 минут. Я такое уже проходил на своем - когда субагенты, которые плодят субагентов, сожгли 20% недельного лимита за одну неудачную фразу в промпте, и с тех пор отдельно слежу, кому и зачем я раздаю работу между дорогим оркестратором и дешевыми исполнителями.

Есть и более тихие статьи расходов, которые не сразу видны в логе. Тяжелый префикс - системный промпт плюс схемы тулов - весит около 30 тысяч токенов на каждого нового субагента, и это платится заново при каждом холодном старте. В разобранном кейсе первый ход проверки на Haiku занял 20 993 токена, из которых 7 133 (34%) ушли на одну только подгрузку MEMORY.md, хотя субагенту для задачи нужна была едва ли десятая часть этого файла. А на выборке из 95 сессий и 1 777 субагентов кэш промпта сбрасывался в 96% случаев - просто потому, что медианный простой между вызовами (около 9 минут) превышал дефолтный TTL кэша в 5 минут, и каждый следующий вызов снова прогревал контекст с нуля.

Как теперь агенты общаются без родителя-диспетчера

Прямой ответ: вместо иерархии "родитель раздает задачи - дети отчитываются summary" сессии Claude Code и Codex получили способ говорить друг с другом напрямую, как равноправные процессы, каждый со своей полной памятью.

В Claude Code это ListAgents и SendMessage - локальные сессии находят друг друга и обмениваются текстом через unix-сокет на одной машине, я разбирал этот механизм подробно в статье про cross-session messaging между агентами. Здесь важнее контраст: сообщение не сжимается в summary, адресат сам решает, что с ним делать, и хук additionalContext на событии UserPromptSubmit может добавить контекст вообще без дополнительного платного хода модели.

В Codex взяли другой путь - фоновый демон codex app-server, который говорит по JSON-RPC и оперирует не сообщениями, а тредами: thread/read читает историю чужого треда, thread/queue/* и turn/steer управляют очередью и текущим ходом, а thread/inject_items вписывает факты в тред без запуска платного model turn. По сути и Anthropic, и OpenAI независимо пришли к одному выводу: дешевле дать сессиям читать друг друга напрямую, чем гонять данные через сжатие в summary и обратно.

Когда субагент все еще нужен, а когда - нет

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

Три сценария, где холодная изоляция субагента все еще окупается:

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

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

Как устроен мой конвейер и почему его не придется переписывать

У меня в конвейере статей нет ни одного места, где родительская сессия дожидается субагента и получает от него сжатый summary. Каждый шаг - это отдельный headless-процесс, которого будит крон: claude -p "/blog-draft $TOPIC_ID" --permission-mode acceptEdits берет тему из SQLite, пишет черновик и завершается сам, никого не дожидаясь. Следующий шаг конвейера - /blog-check, /blog-edits, публикация - тоже отдельные headless-вызовы, а не дети текущей сессии. Обмен состоянием идет не через живую переписку и не через summary дочернего процесса, а через строки в базе: тема получила статус in_work, через несколько минут в базе появился черновик с id.

Формально это тоже "субагентная" схема - один процесс запускает другой ради узкой задачи. Но она не наступает ни на одну из граблей выше: wait_agent с тридцатисекундным поллингом тут просто не нужен, никто не ждет живьем; полную историю родителя таскать некуда, потому что каждый вызов стартует с нуля из своего промпта и берет контекст из БД, а не из чужой сессии; обрезка вывода дочернего агента тоже не страшна, потому что результат - это файл и запись в SQLite, а не summary, который можно обрубить на середине. Критерий, который я для себя вывел: субагент безопасен, если то, что он должен вернуть, дешевле и надежнее хранить в БД, чем в чужой памяти диалога.

Живой пиринг через ListAgents/SendMessage мне пока в этой схеме просто негде применить: у меня нет двух сессий, которые одновременно держат в голове один и тот же черновик и должны согласовывать правки на лету. Единственное место, где я бы стал его пробовать - это ручная правка черновика в интерактивном терминале, когда параллельно крутится headless-проверка того же черновика в /blog-check, и было бы удобно, если бы вторая сессия сама написала "нашла косяк в факт-листе", а не ждала, пока я зайду в базу и прочитаю комментарий руками. Но это уже про интерактивную работу, а не про то, как устроен сам конвейер генерации.

Нужно ли переписывать свой агентный пайплайн

Если твой пайплайн, как и мой, гоняет отдельные headless-вызовы через очередь задач в базе - трогать нечего, это уже не тот субагент, который ест токены на холодном старте и теряет 84% вывода. А вот если у тебя интерактивная сессия в терминале дергает Task-тулом кучу дочерних агентов ради вещей, которые сессия вполне может сделать сама или спросить напрямую у соседнего окна - вот это и есть тот самый лишний слой, который новые ListAgents/SendMessage и Codex-овский app-server делают ненужным. Разница не в модном названии архитектуры, а в одном вопросе: тебе правда нужно похоронить контекст дочернего процесса, или ты просто по привычке зовешь субагента там, где сгодилась бы вторая открытая вкладка терминала. Проверить это дешево - на следующем прогоне пайплайна просто посчитай, сколько раз субагент вернул тебе ровно то, что ты и сам мог бы написать без холодного старта.