Если отбросить маркетинговый флёр вокруг «агентных систем», реальность довольно прозаична: как только вы собираете цепочку из нескольких LLM‑агентов, ваш счёт за токены и latency улетает в стратосферу. Судя по экспериментам в LatentMAS, классический текстовый multi‑agent‑пайплайн для олимпиадных задач уровня AIME‑24/25 легко выжигает десятки тысяч выходных токенов на одну единственную задачу, нередко переваливая за планку в 20к токенов для одного решения. И это не абстрактная проблема академиков: любой, кто пытался склеить ReAct/AutoGen/CAMEL‑подобный конвейер для продакшена, очень быстро натыкался на те же грабли — растущий контекст, медленные ответы и ощущение, что модель занята не столько рассуждением, сколько переливанием текста из промпта в промпт.

Если развернуть эту картинку, типичный сценарий выглядит довольно однообразно. У нас есть последовательный MAS: planner, critic, refiner, solver. Ровно такой chain‑of‑agents используют авторы LatentMAS как текстовый базовый сценарий в своих экспериментах. Planner выписывает план решения в стиле CoT, critic поверх него дописывает своё «ревью», refiner переписывает всё ещё раз, а solver пытается собрать из этой россыпи токенов финальный ответ. Каждый шаг — это новый кусок текста, который аккуратно приписывается к промпту следующего агента. В результате длина диалога растёт как снежный ком, а токен‑счётчик выглядит как лог запросов к LLM, который за ночь забыли остановить.

f2-min.png
Рис. 1. Две базовые архитектуры MAS из статьи LatentMAS: последовательная цепочка planner → critic → refiner → solver и иерархия доменных экспертов с summarizer’ом.

Проблема в том, что такая архитектура бьёт сразу по трём фронтам. Во‑первых, линейно растущий т��кстовый контекст оборачивается квадратичной ценой внимания по длине последовательности (порядка O(n^2) для стандартного self‑attention): чем больше агентов «поговорили», тем дороже становится каждый следующий шаг рассуждения. Во‑вторых, каждый агент вынужден перекодировать всё предыдущее обсуждение обратно в скрытое пространство, заново прогоняя через свои слои то, что предыдущий уже когда‑то посчитал. В‑третьих, текстовые CoT‑цепочки склонны к многословию: на сложных математических задачах вроде AIME и GPQA текстовый MAS генерирует от нескольких тысяч до десятков тысяч токенов, тогда как LatentMAS добивается сопоставимой или лучшей точности, используя меньше пятидесяти «шагов мысли» (latent reasoning steps) в латентном пространстве. Даже если ускорить текстовых агентов через vLLM, LatentMAS в экспериментах остаётся быстрее в 2.6–7 раз по end‑to‑end времени.

Интуитивно это похоже на команду инженеров, которая обсуждает сложный проект только длинными голосовыми и перепиской, игнорируя тот факт, что у них есть общий репозиторий и shared docs. Каждый раз, когда вам нужно подключить ещё одного человека, вы пересылаете ему всю историю чата и ждёте, пока он её проглотит, вместо того чтобы дать доступ к уже собранным артефактам — диаграммам, схемам, промежуточным расчётам. LatentMAS как раз исходит из противоположной идеи: если модель всё равно хранит полную историю внутренних состояний в своём KV‑кэше, почему бы не использовать его как интерфейс между агентами, а не бесконечно гонять через них один и тот же текст?

Отсюда появляется радикальный ход: в LatentMAS агенты перестают говорить друг с другом текстом. Каждый агент генерирует авто‑регрессию не в пространстве токенов, а в пространстве последних скрытых состояний — так называемых latent thoughts, — а затем выкладывает весь накопленный KV‑кэш в общую «латентную рабочую память», доступную следующему агенту. Только самый последний участник цепочки декодирует финальный ответ в естественный язык. На девяти бенчмарках — от GSM8K и AIME‑24/25 до GPQA‑Diamond, MedQA, ARC и HumanEval‑Plus — такая чисто латентная коллаборация даёт двузначный прирост точности, радикальную экономию по токенам и ускорение инференса в несколько раз по сравнению с текстовыми MAS при тех же базовых моделях Qwen3‑4B/8B/14B, причём без какого‑либо дополнительного обучения. Это уже не про «немного поджать CoT», а про другой режим существования агентной системы, где текст становится лишь тонким интерфейсом на выходе, а не основным носителем мысли.

Мне удобнее всего думать об этом так: классический TextMAS — это чат агентов, а LatentMAS — это общий «рабочий стол памяти», куда каждый агент выкладывает свои мысли в виде векторов, а не абзацев. В первом случае вы бесконечно пересказываете друг другу суть проекта словами, во втором — просто открываете один и тот же многослойный рабочий файл и продолжаете править его там, где остановился коллега. Авторы формализуют эту идею как shared latent working memory поверх KV‑кэша и дальше показывают, что при такой схеме не теряется информация по сравнению с текстовыми обменами, а вычислительная сложность для той же «семантической мощности» оказывается ни��е. И тут неизбежно возникает следующий вопрос, который будет пронизывать оставшуюся часть статьи: если агентам больше не нужен текст, чтобы понимать друг друга, как вообще выглядит их память изнутри и чем являются эти самые латентные мысли?

2-min(1).png

Базовая интуиция: что такое KV‑кэш и латентные мысли

Чтобы понять, как именно агенты могут «разговаривать мыслями», нужно опуститься на уровень ниже текстовых токенов и посмотреть, что происходит внутри decoder‑only Transformer во время генерации. У модели уже есть встроенная оперативная память, которая хранит всю историю внутренних вычислений, — это KV‑кэш. Обычно о нём вспоминают только как об инженерном трюке для ускорения: модель не пересчитывает всё внимание заново на каждом шаге, а сохраняет ключи и значения из предыдущих токенов и переиспользует их. Но если посмотреть шире, KV‑кэш — это динамическая рабочая память, куда на каждом шаге дописываются новые фрагменты внутренних представлений модели, слой за слоем и токен за токеном. Фактически он хранит то, что модель уже «увидела» и «обработала» в ходе генерации.

На каждом шаге генерации модель берёт эмбеддинг нового токена, вычисляет для него очередные ключи и значения и просто дописывает их в уже существующий кэш. Эта аккумулятивная природа делает KV‑кэш естественным кандидатом на роль носителя коллективной памяти: в нём уже собрана вся история входа и рассуждений текущего агента. Авторы LatentMAS используют это наблюдение как отправную точку: если вся нужная для внимания информация уже живёт в KV‑кэше, нет необходимости заставлять агентов пересказывать друг другу одни и те же мысли в текстовом виде. Гораздо логичнее научиться передавать сам кэш от одного агента к другому, чтобы следующий сразу получил доступ к внутренней «кухне мысли» предыдущего, без повторного кодирования и декодирования текста.

Отказавшись от обмена текстом, нужно ответить на следующий вопрос: как модель может продолжать «думать» внутри себя, если промежуточные шаги рассуждения ничем не заканчиваются в виде токенов? В LatentMAS это решается через механизм auto‑regressive latent thoughts. Вместо классической схемы, где скрытое состояние последнего слоя преобразуется в распределение по словарю и порождает следующий токен, модель использует эти же скрытые состояния как строительный материал для дальнейшего мышления. Каждое новое состояние приводится к формату, совместимому с входными эмбеддингами, и подаётся обратно на вход как следующий «шаг мысли». Так получается последовательность не из дискретных токенов, а из непрерывных, плотных векторов, которые авторы и называют latent thoughts.

f5-min.png
Рис. 2. Семантическое пространство latent thoughts: новые латентные векторы лежат в той же области, что и эмбеддинги текстовых токенов, но дают более плотное покрытие пространства.

Здесь возникает важная техническая тонкость — input‑output alignment. Скрытые состояния верхнего слоя по распределению и геометрии отличаются от обычных входных эмбеддингов: если просто начать кормить их обратно на вход, модель быстро выйдет за пределы того пространства, в котором её обучали. Это приводит к дрейфу активаций и деградации качества. Чтобы этого избежать, авторы строят линейный оператор выравнивания, который переводит выходные векторы в зону, где они «выглядят» как валидные входные эмбеддинги. Практически это реализуется как одна небольшая матрица, вычисляемая заранее на основе слоёв входных и выходных эмбеддингов. Её считают один раз и потом переиспользуют на всех латентных шагах, так что накладные расходы минимальны, а устойчивость модели заметно повышается.

f6-min.png
Рис. 3. Как работает input‑output alignment: без выравнивания новые скрытые векторы уезжают из области входных эмбеддингов, после применения матрицы выравнивания выровненные векторы возвращаются в то же распределение, что видно по плотностям и расположению точек в embedding‑пространстве.

Эксперименты подтверждают, что это не косметическая деталь, а критический элемент. Визуальный анализ распределений показывает, что без выравнивания новые выходные векторы заметно уезжают от области, где живут нормальные входные эмбеддинги, тогда как после применения оператора выравнивания их геометрия и плотность снова совпадают с исходным пространством. На уровне метрик это даёт дополнительные 2.3–5.3 процентных пункта точности на разных бенчмарках при включённом выравнивании. Отдельно авторы исследуют, сколько латентных шагов вообще имеет смысл делать: качество стабильно растёт примерно до 40–80 шагов, после чего либо выходит на плато, либо слегка падает, что хорошо согласуется с идеей «нескольких десятков осмысленных шагов мысли» вместо десятков тысяч токенов классического CoT.

f78-min.png
Рис. 5. Влияние выравнивания на downstream‑точность: на MedQA, ARC‑Easy/Challenge и GSM8K применение матрицы выравнивания даёт дополнительные 2.3–5.3 процентных пункта accuracy по сравнению с LatentMAS без выравнивания. Рис. 6. Как число латентных шагов влияет на качество: на задачах ARC‑Challenge, ARC‑Easy и GSM8K точность растёт по мере увеличения глубины латентного рассуждения и стабилизируется в диапазоне примерно 40–80 шагов, после чего начинает выходить на плато или слегка снижаться.

Интуитивно всё это можно понять через аналогию. Текстовые рассуждения — это как если бы вы проговаривали свою мысль вслух, по одному слову из ограниченного словаря. Латентные мысли — это ваш внутренний векторный язык, где каждый шаг — это богатый многомерный вектор, способный унести гораздо больше семантики, чем одиночный токен. Линейный оператор выравнивания в этой картинке — «переводчик» между голосом внутренней мысли и внутренней «клавиатурой» модели, который следит за тем, чтобы она продолжала думать в корректном формате. Теоретический анализ в LatentMAS формализует эту интуицию: при определённых предположениях один шаг латентного рассуждения может быть эффективнее текстового примерно во столько раз, сколько даёт логарифм размера словаря, что для моделей Qwen3, использованных в статье, приводит к выигрышам порядка сотен раз по потенциальной выразительности на шаг. И как только оказывается, что отдельный агент умеет так рассуждать и хранит всю историю этих рассуждений в своём KV‑кэше, естественный следующий вопрос звучит так: как превратить эту индивидуальную память в общее рабочее пространство для всей системы агентов? Именно на него LatentMAS отвечает концепцией shared latent working memory, к которой мы сейчас и перейдём.

3-min.png

Латентная рабочая память: как агенты реально обмениваются мыслями

К этому моменту картина внутри одного агента уже достаточно понятна: он может продолжать рассуждать в латентном пространстве, генерируя последовательность скрытых состояний вместо потока токенов, а KV‑кэш выступает в роли оперативной памяти для этих мыслей. Следующий логичный шаг — превратить эту индивидуальную KV‑память в коллективный рабочий стол, на котором агенты оставляют друг другу не текстовые конспекты, а сырые векторные следы своих рассуждений. Именно это LatentMAS формализует под названием latent working memory.

f3-min.png
Рис. 7. Схема LatentMAS: агенты генерируют latent thoughts, сохраняют их в KV‑кэше и передают общий слепок рабочей памяти следующим агентам вместо текстового CoT.

Авторы аккуратно определяют, что именно считается «рабочей памятью» агента A₁. Представим, что он прочитал исходный контекст (вопрос плюс инструкции своей роли) и сделал несколько десятков латентных шагов мысли. На каждом слое у него накопились матрицы ключей и значений в KV‑кэше: по строкам — разные временные шаги, по столбцам — компоненты скрытого состояния. Latent working memory этого агента — это просто собрание всех этих пар матриц по слоям. По‑человеческ��, это полный слепок того, что агент видел и над чем думал: от исходных токенов вопроса до всех сгенерированных латентных мыслей, аккуратно разложенный по слоям модели.

Теперь в игру вступает агент A₂. В классическом текстовом MAS он получил бы на вход длинный CoT‑ответ A₁, заново прогнал бы этот текст через свои эмбеддинги и слои, ещё раз собрал KV‑кэш и только после этого начал бы собственные рассуждения. В LatentMAS этого второго прохода не требуется: вместо текста A₂ получает готовый KV‑кэш из latent working memory A₁. Перед тем как начать свои latent thoughts, он берёт свой текущий кэш и просто добавляет к нему блоки из памяти первого агента. На каждом слое временная ось расширяется: его внимание сможет смотреть и на собственный локальный контекст, и на полную историю внутренних состояний A₁. Это как если бы вы не пересказывали коллеге ход мысли словами, а просто переслали ему весь рабочий блокнот со схемами и пометками, и он продолжил бы дописывать новые страницы прямо в нём.

Важно, что LatentMAS передаёт именно KV‑кэш, а не сырые скрытые состояния последнего слоя. Это даёт два практических выигрыша. Во‑первых, не нужно заново пропускать пришедшие вектора через self‑attention — они уже находятся в том виде, в котором механизм внимания их ожидает. Во‑вторых, в KV‑кэше одновременно закодированы и исходный текстовый контекст, и вся последовательность латентных мыслей, а не только «стартовый префикс» входа. В отличие от простого совместного использования префилла, где разные модели делятся кэшем только для исходных токенов, здесь речь именно о полной истории размышлений предыдущего агента, доступной следующему без перекодирования.

Естественный вопрос: не теряется ли при таком обмене что‑то важное по сравнению с классической схемой «сгенерировали текст — отдали текст следующему»? На него отвечает теоретический результат, который в статье формулируется как Theorem 3.3 (Information Preservation via Latent Working Memory). По сути, эта теорема говорит, что при идеальной передаче латентной рабочей памяти следующий агент может прийти к тем же выходам, что и в текстовом MAS, где ему явно подают на вход ответы предшественников и он сам их перекодирует. Интуитивно это выглядит так: текст — это квантизованная, сжатая проекция скрытых состояний в пространство словаря, а KV‑кэш содержит эти состояния до стадии сжатия в токены. Если бы вы всё же сгенерировали текст и отдали его второму агенту, он прогнал бы его через свои эмбеддинги и слои и в итоге оказался бы примерно в том же регионе скрытого пространства, который LatentMAS передаёт напрямую через кэш.

Здесь очень хорошо работает визуальная аналогия: передавать мысли через текст — это как делиться JPEG вместо оригинального многослойного PSD‑файла. В текстовом MAS вы отдаёте следующему агенту уже сплющенную картинку рассуждения — финальный рендер CoT, где большинство промежуточных слоёв и деталей потеряны. В LatentMAS вы пересылаете именно «PSD»: все слои внимания, все промежуточные активации, все черновики мысли лежат в KV‑кэше. Второй агент может поверх них дорисовывать свои слои, не начиная с чистого холста и не пытаясь восстановить недостающие детали по сжатому JPEG.

Формальный бонус этой схемы не только в сохранности информации, но и в вычислительной цене. Ранее в статье вводится теорема, показывающая, что для той же семантической мощи текстовой последовательности ей требуется в несколько раз больше шагов за счёт ограничения словарём: один шаг латентного рассуждения может нести семантику, сопоставимую с сотнями токенов. На этом основании авторы анализируют сложность LatentMAS и приходят к выводу, что при фиксированной «глубине» рассуждения его стоимость по вычислениям заметно ниже, чем у текстового MAS с тем же уровнем экспрессивности. Особенно это заметно в сценариях вроде AIME или GPQA, где текстовый CoT может занимать десятки тысяч токенов, а LatentMAS достигает сопоставимой или лучшей точности за несколько десятков латентных шагов.

Если вернуться к интуитивной картинке multi‑agent‑системы, разница между TextMAS и LatentMAS становится почти карикатурной. В первом случае агенты выстраиваются в очередь к микрофону и по очереди произносят длинные речи. Каждый следующий сначала вынужден прослушать всё предыдущее, а затем перевести это обратно в свои внутренние схемы. Во втором случае у них на столе лежит общий «блокнот памяти» — тот самый послойный KV‑кэш — и каждый просто дописывает туда свои схемы и формулы, видя полный контекст. Теоретические результаты в LatentMAS говорят: по содержанию эти два процесса могут быть эквивалентны, но работа с общим блокнотом существенно дешевле, чем бесконечные пересказы вслух. В следующем акте как раз будет видно, как эта, казалось бы, чисто архитектурная идея превращается в очень приземлённые выигрыши по точности, токенам и latency на реальных бенчмарках.

4-min.png

Экспериментальный взгляд: цифры, которые меняют архитектуру

После трёх актов про устройство латентной памяти легко списать всё на красивую теорию: «ну да, латентные мысли, KV‑кэш, теоремы… а в проде‑то это работает?». Авторы LatentMAS отвечают на это очень агрессивно и делают это не абстрактными картинками, а плотной таблицей из девяти бенчмарков, трёх размеров моделей и двух типов MAS‑архитектур. За счёт одной только замены текстового общения агентов на латентную рабочую память система получает прирост до 14.6 п.п. точности, 70.8–83.7% уменьшения числа выходных токенов и в среднем 4–4.3x ускорение инференса по сравнению с текстовыми MAS, причём без дополнительного обучения и на тех же Qwen3‑4B/8B/14B.

f1-min.png
Рис. 8. Сводный выигрыш LatentMAS по точности, скорости инференса и числу токенов на девяти бенчмарках в иерархическом MAS‑режиме.

Структура экспериментов довольно честная. С одной стороны — сильный single‑model baseline, который просто генерирует ответ токен за токеном без каких‑либо агентов. С другой — два варианта текстового MAS: sequential (planner → critic → refiner → solver) и hierarchical (math/code/science‑агенты + summarizer), оба построены на тех же моделях и промптах, что и LatentMAS, но общаются текстом. С третьей — LatentMAS в двух тех же конфигурациях, где единственное принципиальное отличие в том, что CoT‑диалоги между агентами заменены на latent thoughts плюс передачу KV‑кэша. Все три лагеря гоняют по одному и тому же набору из девяти датасетов: GSM8K, AIME‑24/25, GPQA‑Diamond, MedQA, ARC‑Easy/Challenge, MBPP‑Plus и HumanEval‑Plus.

Если смотреть на «общие» задачи — школьную математику, commonsense и код, — картина получается вполне системной. На GSM8K, ARC‑Easy/Challenge, MedQA, MBPP и HumanEval LatentMAS практически всегда превосходит single‑model по точности (в среднем около 14 процентных пунктов выигрыша в sequential‑настройке) и к этому ещё добавляет несколько пунктов по сравнению с текстовым MAS. При этом по токенам разрыв выглядит особенно неприлично: sequential‑вариант LatentMAS тратит на ответы примерно в 3–5 раз меньше токенов, чем TextMAS, а hierarchical‑версия местами выбивает до 80% экономии, что хорошо видно в сводных таблицах и Рис. 8. По latency всё в том же духе: средний 4x speedup относительно текстовых MAS плюс бонус против single‑модели за счёт того, что финальный агент в LatentMAS декодирует уже на очень коротком хвосте.

f4-min.png
Рис. 9. LatentMAS против single‑модели и текстового sequential MAS: ускорение end‑to‑end инференса и сокращение системных токенов при одинаковых базовых моделях.
t1-min.png
Рис. 10. Результаты LatentMAS на шести «общих» задачах в sequential MAS: прирост точности, сокращение токенов и ускорение инференса относительно single‑модели и текстового MAS.
t2-min.png
Рис. 11. LatentMAS в иерархическом MAS‑режиме: выигрыши по точности, токенам и скорости на тех же шести задачах при переходе от текстовой коллаборации к латентной.

Но настоящая проверка концепции — это, конечно, «жёсткие» reasoning‑бенчмарки: AIME‑24/25 и GPQA‑Diamond. Именно там классические CoT‑цепочки особенно любят раздуваться до неприличных размеров — в таблице видно, что текстовый MAS легко уходит за 20к выходных токенов на одну задачу AIME и десятки тысяч токенов на GPQA. На этом фоне LatentMAS выглядит как система из другого мира: в sequential‑режиме для Qwen3‑8B и 14B он достигает тех же или лучших показателей по accuracy на AIME‑24/25 и GPQA‑Diamond, используя заметно меньше токенов (порядка 9–11 тысяч вместо 30–45 тысяч) и всего несколько десятков латентных шагов, а не тысячи CoT‑токенов. По времени инференса разрыв ещё ярче: даже если подложить обоим лагерям vLLM как ускоритель, LatentMAS остаётся быстрее текстового MAS в 2.6–7x на тех же задачах, просто потому что почти не декодирует текст внутри системы.

t3-min.png
Рис. 12. Результаты на сложных reasoning‑бенчмарках AIME‑24/25 и GPQA‑Diamond: LatentMAS достигает схожей или лучшей точности при радикальном уменьшении числа токенов и времени инференса.

Хорошо видно, как теоретическое log |V|-преимущество латентных шагов материализуется в инженерные числа. Там, где TextMAS вынужден шагать по дискретному словарю, порождая длинную последовательность токенов, LatentMAS делает несколько десятков плотных векторных шагов и затем один короткий выход в текст. Рис. 9. подчёркивает это визуально: слева — бары по времени, где LatentMAS стабильно быстрее и single‑модели, и TextMAS (даже при использовании vLLM), справа — бары по токенам, где латентный подход экономит от 60 до почти 90% по сравнению с текстовым взаимодействием агентов. При этом возникает интересный побочный эффект: система на латентной памяти часто тратит меньше токенов, чем одиночная модель, потому что финальный агент декодирует очень короткий вывод, опираясь на богатую KV‑память предыдущих.

Отдельно стоит остановиться на анализе латентного пространства, потому что он закрывает важный скепсис: «а вдруг все эти latent thoughts — просто красивый шум». На MedQA авторы берут 300 вопросов и сравнивают распределения эмбеддингов токенов, которые генерирует TextMAS в процессе CoT, с эмбеддингами латентных мыслей LatentMAS. Выясняется, что латентные векторы заполняют практически ту же область пространства, что и текстовые ответы, но при этом шире покрывают её, демонстрируя большую разнообразность и выразительность. После применения матрицы выравнивания новые эмбеддинги возвращаются в «правильное» подпространство входа, что наглядно видно в визуализациях, а на downstream‑метриках это даёт те самые +2.3–5.3 п.п. точности. Там же в анализе числа латентных шагов видно, как рост их количества до диапазона 40–80 стабильно улучшает качество, после чего кривая выравнивается — лишние шаги уже почти не добавляют пользы и могут даже слегка шуметь.

Вся эта экспериментальная часть вместе производит довольно сильный эффект: LatentMAS выглядит не как «ещё один трюк над CoT», а как полноценная альтернатива текстовым MAS‑пайплайнам с убедительным профилем accuracy / tokens / latency. Это очень похоже на переход команды с бесконечной переписки по почте к работе в общем Notion: меньше писем, больше дела. И вот здесь становится особенно уместным вопрос к практикам: готовы ли вы и дальше платить за десятки тысяч токенов рассуждений, если те же агенты могут договориться за несколько десятков латентных шагов, опираясь на общую рабочую память?

5-min.png

Практическая ценность и риски: взгляд инженера

После всех теорем и красивых картинок самое интересное начинается там, где LatentMAS сталкивается с вашими уже существующими пайплайнами. Если у вас сегодня крутится sequential MAS в стиле planner/critic/refiner/solver, LatentMAS показывает довольно прямолинейный путь его «перепрошивки» в латентный режим: вы оставляете ту же логику ролей, те же промпты и ту же модель Qwen3‑4B/8B/14B, но вместо длинных CoT‑ответов между агентами организуете передачу latent working memory через KV‑кэш и просите только финальный агент декодировать текст. В статье именно такая четырёхагентная цепочка используется как базовая архитектура и для текстового MAS, и для LatentMAS, и одна только замена текстовой коммуникации на латентную даёт те самые выигрыши по точности, токенам и latency, о которых шла речь выше. По сути, это первый design prompt: взять свой текущий sequential MAS и задать вопрос не «какие ещё агенты добавить?», а «где можно выкинуть текст из уравнения и оставить только обмен памятью?».

Второй естественный шаблон — latent‑версия hierarchical MAS. В оригинальной работе это доменные эксперты (math, code, science) плюс summarizer, который получает их ответы и собирает итог. В текстовом варианте каждый эксперт возвращает свой длинный текстовый разбор, summarizer вынужден читать весь этот CoT‑поток, и именно поэтому и токены, и время так легко раздуваются. В LatentMAS эксперты выдают не токены, а последовательности латентных мыслей, их KV‑кэши по слоям попадают в общую latent working memory, и summarizer смотрит сразу на этот «многослойный PSD» вместо кучи JPEG‑резюме, декодируя только финальный ответ. Практическая опция для инженера выглядит так: оставить summarizer текстовым (для объяснимости), но максимально сдвинуть в latent‑пространство всё, что происходит до него — доменные рассуждения, проверки, внутренние дебаты между экспертами. В экспериментах такая конфигурация LatentMAS обгоняет и single‑модель, и текстовый hierarchical MAS по качеству, одновременно сокращая токены более чем на 80% и ускоряя инференс примерно в четыре раза.

Однако у этого «телепатического» дизайна есть нетривиальные инженерные хвосты. Во‑первых, LatentMAS требует совместимых архитектур агентов: чтобы передавать KV‑кэш без перекодирования, у всех участников цепочки должны совпадать размерности слоёв и формат кэша. В работе авторы просто берут одну и ту же Qwen3‑модель в разных ролях, что автоматически выполняет это требование. В реальных системах с гетерогенными моделями придётся либо вводить проекторы между пространствами, либо ждать дальнейших исследований по более общим схемам латентной коллаборации. Во‑вторых, нужно научиться жить с крупными и долгоживущими KV‑кэшами: когда вы не выбрасываете CoT между агентами, а таскаете всю историю внутренних состояний, объём оперативной памяти на инференсе становится новой лимитирующей константой. Здесь придётся проектировать политику жизненного цикла для кэшей: что логировать, что можно реконструировать по входу, как реплеить или частично усекать рабочую память, не ломая при этом саму идею shared latent working memory.

Самый неприятный трейд‑офф — это, конечно, интерпретируемость. В текстовом MAS любой product‑менеджер может прокрутить чат агентов и сказать: «вот здесь planner сошёл с ума, а тут critic проморгал очевидную ошибку». В LatentMAS между входом и финальным ответом скрыта только латентная многомерная динамика. Авторы прямо отмечают, что такая схема снижает прозрачность, и указывают в разделе будущих направлений на необходимость сочетать latent и текстовые режимы, а также лучше понимать и визуализировать поведение системы в латентном пространстве. С инженерной точки зрения список вопросов, которые нужно закрыть перед продом, довольно конкретный: как логировать и реплеить latent‑трассы (а не только текст), какие метрики строить поверх скрытых состояний и структуры KV‑кэша, как внедрять выборочный «проброс» некоторых шагов обратно в текст, когда нужно объяснение для пользователя или аудитора. Плюс остаются классические вопросы безопасности: при обмене скрытыми состояниями агенты потенциально видят больше внутренней информации, чем при обмене усечёнными текстовыми резюме, и это отдельное поле для red‑teaming и политик доступа.

При этом LatentMAS — не абстрактная идея из PDF, а вполне осязаемый код, который можно пощупать в ближайшие выходные. Авторы выложили полный репозиторий и данные на GitHub, с готовыми реализациями для Qwen3‑4B/8B/14B, а также конфигурациями и скриптами для sequential и hierarchical MAS на основных бенчмарках — от GSM8K и MedQA до MBPP‑Plus и HumanEval‑Plus. Минимальный чеклист для инженера выглядит так: клонировать репозиторий, поднять один из Qwen3‑бэкендов, запустить текстовый MAS и LatentMAS на одной из поддерживаемых задач (например, GSM8K или HumanEval‑Plus), собрать свои метрики accuracy/tokens/latency и только после этого решать, стоит ли переносить паттерны в свой стек. Это тот редкий случай, когда статья про то, как LLM‑система может хранить и передавать латентные «воспоминания», одновременно является инструкцией по сборке собственной «телепатической» команды агентов на продакшн‑коде. И главный эксперимент здесь даже не в том, какие цифры вы получите на бенчмарках, а в том, что вы узнаете о своих текущих агентных системах, если дадите им хоть раз «поговорить мыслями» вместо бесконечных CoT‑мемуаров.

В итоге LatentMAS предлагает смотреть на multi‑agent‑систему не как на цепочку «болтающих» LLM, а как на общую вычислительную среду, где агенты работают с одной и той же латентной памятью. Текст в такой архитектуре становится тонким интерфейсом только на границах системы, а не главным носителем смысла, что радикально меняет и экономику, и дизайн агентных пайплайнов. Осталось лишь ответить для себя на практический вопрос: хотите ли вы тратить токены на разговоры агентов или инвестировать ресурсы в их общее поле мыслей.

А как вы относитесь к такому компромиссу в своих проектах? Готовы ли вы пожертвовать прозрачностью текстовых логов ради радикального ускорения и удешевления агентных систем, или старая добрая интерпретируемость всё же важнее? Делитесь мыслями в комментариях.

Оставайтесь любопытными.

Взгляд инди-хакера на AI и разработку: глубокое погружение в языковые модели, гаджеты и self-hosting через практический опыт в моем телеграм канале.