Почему Muse Code не убивает своих агентов до конца сессии
Тихое архитектурное решение, на котором держится скорость Muse Code: фоновые агенты живут всю сессию, вместо того чтобы создаваться под задачу и выбрасываться.
Проблема «создал — выбросил»
Большинство мультиагентных инструментов для кодинга работают по одному рецепту: пришла задача — поднимаем агента-помощника, отдаём ему кусок работы, забираем результат, гасим. Абстракция чистая, но цена у неё некрасивая. Каждый свежесозданный агент стартует с нуля: заново читает структуру репозитория, заново разбирается в системе сборки, заново выучивает соглашения вашей кодовой базы. В сессии из десяти задач этот налог на сбор контекста платится десять раз.
И налог этот — не только токены. Это латентность: каждый холодный старт откладывает саму работу. И это ваши усилия на рулёжку, потому что агент, забывший всё, что выяснил час назад, задаёт вам одни и те же вопросы дважды.
Ответ Muse Code: персистентность
Muse Code устроен как простой основной цикл агента плюс набор асинхронных фоновых агентов — и эти фоновые агенты остаются активными всю сессию. Их не создают под отдельные задачи. Каждый специализирован, накапливает контекст по ходу сессии и сам решает, когда что-то стоит доложить основному агенту.
Последняя деталь важнее, чем кажется. Фоновые агенты не блокируют основной цикл в ожидании инструкций — но и не заваливают его статус-апдейтами. Они самостоятельно делают следующие шаги и выходят на связь, когда это действительно нужно. Заявленная мотивация Meta — ровно те два налога, о которых шла речь выше: персистентность снижает латентность и уменьшает потребность в ручной рулёжке на сложных многошаговых задачах.
Воркеры параллельно, ревьюеры в фоне
На практике это ощущается как команда с постоянными ролями, а не очередь временщиков. Воркеры выполняют изменения параллельно; ревьюеры непрерывно критикуют результат в фоне, ещё до того, как он дойдёт до вас. Формулировка с запуска — «multi-agent by default» — точна: координация — это не режим, который вы включаете, а то, как выполняется каждая задача. Вы двигаетесь быстрее не потому, что какой-то отдельный агент быстрее, а потому, что контроль качества идёт параллельно, а не задним числом.
Вшито в модель, а не прикручено сверху
Есть причина, по которой такой дизайн харнесса работает с Muse Spark 1.2 лучше, чем работала бы обёртка над произвольной моделью. Модель обучалась вместе с харнессом Muse Code: её рецепт тренировки явно оптимизировал поведение субагентов — наряду с работой по целям и компакцией контекста. Разделение труда между основным циклом и постоянными специалистами — не трюк промпт-инжиниринга, наклеенный сверху; модель видела его во время обучения. Отсюда и заявления про «меньше повторных попыток, лучше работа с инструментами» — подробно об этом в посте о том, как обучали Muse Spark 1.2.
Чего персистентность не решает
Долгоживущие агенты, одновременно правящие один репозиторий, были бы рецептом мердж-катастрофы — если бы делили одну рабочую копию. Но они её не делят. Когда работа разветвляется, каждый дочерний агент с правом записи получает собственный изолированный git worktree, так что параллельная работа никогда не сталкивается на файлах. Этот механизм изоляции заслуживает отдельного разбора: fan-out агентов и git worktree. А когда захотите узнать, что именно любой из этих агентов делал, пока вы не смотрели, — полный ответ лежит в append-only журнале событий.