Архитектура MiMo Code для долгосрочных задач: что трёхуровневая модель Xiaomi значит для политики маршрутизации оператора

Когда coding agent зависает на 40-м шаге рефакторинга продакшн-кода, причина почти никогда не в качестве модели. Настоящая проблема — в дизайне маршрутизации и оркестрации: context window заполнилось, способность следовать инструкциям деградировала под нагрузкой, или логика workflow была записана на естественном языке и потерялась при сжатии контекста.

10 июня 2026 года команда MiMo из Xiaomi выпустила MiMo Code — терминальный coding agent, построенный на базе OpenCode и открытый под лицензией MIT. Сопроводительный технический блог на mimo.xiaomi.com/blog/mimo-code-long-horizon содержит необычно честное описание архитектуры, организованное вокруг трёх классов отказов: вычислительные узкие места на уровне одного шага, разрывы непрерывности состояния в многошаговых задачах и невозможность накапливать опыт между сессиями. Каждый класс соответствует своему слою: вычисление (computation), память (memory) и эволюция (evolution).

Для AI-инженерных команд, работающих с Claude Code, Cursor, Kimi Code или собственными agent-стеками, архитектурный документ MiMo Code — наиболее детальное публичное описание того, что в действительности требуется для routing долгосрочных agent-задач.

Что произошло

MiMo Code запустился 11 июня 2026 года как терминальный coding agent, спроектированный Xiaomi для «десятков или даже сотен шагов выполнения». Технический блог вышел на день раньше и является основным operator-ориентированным справочником по архитектуре.

Agent построен на OpenCode, лицензия MIT, GitHub-репозиторий обновлялся два дня назад. По умолчанию использует модели MiMo-V2.5 и MiMo-V2.5-Pro от Xiaomi, но благодаря OpenCode-основе совместим с Claude Code, Cursor и Cline-workflow.

Три ключевых слоя архитектуры:

1. Computation — поддержание качества решений на каждом шаге при росте длины задачи
2. Memory — сохранение непрерывности многошагового состояния за пределами одного context window
3. Evolution — накопление опыта agent'а между независимыми сессиями

Почему это важно для AI-инженерных команд

Центральный тезис дизайна MiMo Code — то, что любой operator, запускающий долгосрочные автоматизированные задачи, должен немедленно распознать: stateless вызов модели — это единица; runtime — источник непрерывности. Каждый отказ в многошаговом agent-выполнении восходит к тому, как runtime управляет состоянием, а не к тому, как модель рассуждает.

Это переосмысление имеет прямые последствия для того, как команды планируют вычисления и проектируют routing:

Компромисс стоимости параллельного сэмплирования. Max Mode в MiMo Code генерирует N параллельных кандидатов за шаг (по умолчанию N=5), и отдельная judge-модель выбирает лучший вариант до выполнения. На SWE-Bench Pro Max Mode даёт прирост производительности 10–20% ценой 4–5× роста потребления токенов. Для операторов AI gateway это решение на уровне routing: Max Mode маршрутизирует несколько конкурентных вызовов к одной модели на каждый шаг agent'а. Команды, тарифицирующие routing по количеству запросов или бюджету токенов, должны явно моделировать это расширение стоимости.

Верификация завершения как отдельный маршрут модели. Механизм Goal — независимый верификатор, срабатывающий каждый раз, когда agent пытается завершить работу — это отдельный API-вызов, который можно маршрутизировать к той же или другой модели. Это создаёт наблюдаемую ветвящуюся паттерн в использовании API: вызов верификатора — сигнал риска зацикливания agent'а, а его отказы (ложные блокировки из-за нестабильных тестов) проявляются как неожиданные пики стоимости.

Checkpoint writers как sub-agent routing события. Слой памяти запускает независимые sub-agent-writer на 20%, 45% и 70% настроенного контекстного бюджета. Каждый writer-вызов — полностью независимый API-маршрут со своим бюджетом токенов и выбором модели. Команды, работающие через AI gateway, могут маршрутизировать эти вызовы к более дешёвым или меньшим моделям, не снижая качество основного agent'а.

Оркестрация как код — поверхность управления routing. Dynamic Workflow превращает оркестрационную логику из SKILL.md на естественном языке в детерминированный JavaScript, выполняемый в изолированной sandbox, с диспетчеризацией sub-agent'ов через agent() и управлением параллелизмом через parallel() / pipeline(). С точки зрения операторского routing это означает, что пики конкурентности становятся предсказуемыми: код workflow можно статически проанализировать, чтобы определить, сколько параллельных agent-вызовов генерирует задача. Это принципиально отличается от prompt-based оркестрации, где конкурентность возникает неожиданно.

Угол router/operator

Схема computation–memory–evolution соответствует трём вопросам политики routing:

1. Как планировать бюджет параллельного сэмплирования? Max Mode — опциональная экспериментальная функция, но она представляет реальную закономерность: coding agent платформы с параллелизмом сэмплирования переносят вычисления с глубины инференса на ширину. Операторы AI gateway нуждаются в лимитах стоимости на запрос и на сессию, способных обрабатывать N×-всплески без неожиданных счетов. Документ MiMo явно раскрывает множитель стоимости (4–5×) — что прозрачнее большинства платформ.

2. Как моделировать sub-agent routing? MiMo Code использует независимые sub-agent'ы для двух разных ролей: верификации завершения (Goal) и извлечения памяти (checkpoint writers). Это разные профили запросов — верификаторные вызовы представляют собой краткие суммарные оценки; writer-вызовы — задачи структурированного извлечения. AI gateway, маршрутизирующий все sub-agent-вызовы через одну модель и приоритетный уровень, упускает оптимизацию стоимость/качество, доступную при дифференциации этих путей.

3. Какова ваша политика routing на границах сессии? Абстракция Cycle — checkpoint, перестройка, продолжение — означает, что одна логическая задача может охватывать несколько API-«сессий» с точки зрения провайдера модели. Счётчики rate limit и атрибуция стоимости по сессиям должны быть session-aware на уровне gateway, а не только на уровне отдельного запроса. Команды, достигающие provider rate limit в середине задачи, нуждаются в fallback-политиках, сохраняющих состояние checkpoint, а не перезапускающих задачу с нуля.

Что должны отслеживать пользователи TheRouter

MiMo Code сегодня — open-source продукт, доступный на github.com/XiaomiMiMo/MiMo-Code. Он не предоставляется как hosted API route. Командам, использующим модели MiMo через gateway, следует обратиться к предыдущему материалу о запуске провайдера MiMo V2.5 для контекста по доступу к модели.

Архитектурные паттерны, задокументированные в MiMo Code — бюджеты параллельного сэмплирования, sub-agent routing для checkpoint writers, предсказуемая конкурентность workflow-как-кода — применимы к любой coding agent платформе, включая Claude Code, Kimi Code или пользовательские OpenCode-стеки. Командам, оценивающим конфигурацию AI gateway для продакшн-деплойментов coding agent'ов, следует проверить политику routing по трём измерениям:

• Поддерживает ли ваш gateway бюджеты токенов на сессию (а не только на запрос)?
• Можете ли вы маршрутизировать sub-agent-вызовы к другим уровням моделей, нежели вызовы основного agent'а?
• Есть ли у вас observability-хуки, позволяющие разделить верификаторные вызовы и вызовы основного agent'а в атрибуции стоимости?

Для модели работы с параллельной оркестрацией см. также материал об операторском routing ZCode coding agent по аналогичной схеме на базе Zhipu GLM-5.2.

Документацию по конфигурации провайдеров и политике routing смотрите на /docs/.