MiMo Code от Xiaomi: coding-agent для длинных задач, памяти и сотен шагов разработки

Что такое MiMo Code

MiMo Code — это терминальный programming agent от команды Xiaomi MiMo. Он построен на базе OpenCode, распространяется под MIT-лицензией и предназначен для длинных автоматизированных задач, где агенту нужно работать не 5–10 шагов, а десятки или даже сотни шагов подряд.

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

Почему короткие и длинные задачи требуют разной архитектуры

Базовая схема coding-agent довольно проста: языковая модель запускается внутри runtime loop. Модель рассуждает и принимает решения, а runtime управляет инструментами, состоянием и сборкой входа для каждого нового шага. Проблема в том, что сама модель остаётся stateless: каждый вызов начинается заново, а непрерывность обеспечивает только среда исполнения.

Для коротких задач этого достаточно. Если задача укладывается примерно в 10 раундов, можно просто передавать модели всю историю диалога. Но в длинных задачах появляются две системные проблемы: контекстное окно заполняется логами, кодом и выводом инструментов, а качество следования инструкциям падает по мере роста входа. В результате важные ограничения и исходный intent пользователя начинают теряться внутри длинной истории.

Xiaomi формулирует три разных временных масштаба проблемы. Качество одного решения внутри сессии упирается в вычисления, непрерывность длинной сессии — в управление состоянием, а улучшение между сессиями — в извлечение опыта. Поэтому MiMo Code строится вокруг трёх слоёв: compute, memory, evolution.

Вычисление: больше compute на один шаг

Для длинных задач даже небольшая вероятность ошибки на каждом шаге начинает накапливаться. Если агент должен пройти 100–200 действий, одиночная неудачная развилка может испортить весь дальнейший процесс. Поэтому MiMo Code добавляет дополнительные вычисления на разных уровнях.

Max Mode: параллельные варианты и выбор лучшего

Max Mode генерирует несколько кандидатов для одного шага. По умолчанию используется N=5: каждый кандидат независимо строит рассуждение и план вызова инструментов, но не выполняет действие. Затем та же модель выступает судьёй и выбирает лучший вариант для исполнения.

Команда пишет, что при temperature=1 пять независимых выборок почти не дают одинаковый результат. Если кандидаты сходятся, это само по себе говорит о высокой уверенности направления. Если различаются, low-temperature judge выбирает более устойчивый план. На SWE-Bench Pro Max Mode даёт прирост 10–20% относительно одиночной выборки, но стоит примерно в 4–5 раз больше токенов. Сейчас это экспериментальная функция, которую нужно включать вручную.

Goal: независимая проверка завершения

Max Mode отвечает за “сделать правильно”, а Goal — за “действительно закончить”. В длинных задачах агент может преждевременно объявить работу завершённой, особенно если видит частичный прогресс в истории. В автоматическом режиме это опасно: рядом нет человека, который остановит ошибочное завершение.

Механика Goal устроена так: пользователь задаёт естественным языком условие остановки, например “все тесты проходят и код закоммичен”. Когда агент пытается завершить работу, система запускает отдельный модельный вызов, который проверяет всю историю и решает, выполнено ли условие. Если нет — агент получает конкретный список недостающих шагов и продолжает работу. Если задача признана невозможной, система может завершить её как невыполнимую.

Xiaomi пишет, что ложные блокировки встречаются чаще, чем ошибочные пропуски: например, когда тесты падают из-за проблем окружения. При этом вероятность dead loop в их наблюдениях меньше 0,5%, а по достижении лимита система может выйти автоматически.

Tool calling: не JSON, а ограниченный shell-like синтаксис

Команда отдельно разбирает формат вызова инструментов. По их наблюдению, некоторые модели, включая GPT-5.5 series, чаще ошибаются при генерации структурированного JSON. XML показывает себя немного лучше, но в итоге команда пришла к ограниченному command-line синтаксису.

Идея в том, что модели хорошо обучены на shell-подобных данных, а такой формат требует меньше токенов для выражения того же намерения. При этом синтаксис намеренно ограничен: без pipe, redirection и variable expansion. Цель — взять компактность shell, но не дать модели неконтролируемую среду исполнения. Xiaomi уточняет, что MiMo Code ещё не полностью перешёл на этот формат, но может постепенно мигрировать в следующих версиях.

Dynamic Workflow: когда prompt уже не справляется

Для задач уровня миграции целого проекта с одного языка на другой одного агента и последовательных tool calls уже недостаточно. Нужно координировать десятки или сотни параллельных рабочих единиц.

Xiaomi критикует подход, при котором workflow описывается в SKILL.md естественным языком: модель может забыть шаги после сжатия контекста, пропустить ветку, неправильно обработать retry или выполнить один и тот же процесс разными путями. Проблема в том, что orchestration logic находится в prompt, а естественный язык неоднозначен и плохо проверяем.

Dynamic Workflow переносит orchestration из prompt в код. Главный агент генерирует JavaScript-сценарий, который выполняется в изолированной песочнице. Скрипт может запускать дочерних агентов через agent(), управлять параллелизмом через parallel() и строить цепочки через pipeline(). По логике Xiaomi, ветвления, циклы и barriers должны гарантироваться кодом, а не памятью модели.

Реализация совместима с core semantics Anthropic Dynamic Workflow, но расширяет их: workflow() позволяет одному скрипту вызывать другие, результаты каждого agent() синхронно пишутся на диск, а после сбоя процесс можно восстановить из логов. В песочнице также можно напрямую читать и писать файлы.

Память: как растянуть одну логическую сессию на много окон

Дополнительное вычисление снижает шанс ошибки на отдельном шаге, но не решает главную проблему длинных задач: контекст всё равно закончится. MiMo Code решает это через cycle, checkpoint writer и rebuild.

Cycle: единица бесконечной логической сессии

Сессия состоит из последовательности turn. Пока история растёт, окно постепенно заполняется. До достижения лимита runtime создаёт checkpoints: в фиксированных местах запускается отдельный writer subagent, который читает текущую историю и пишет структурированное состояние на диск. Основной агент при этом продолжает работать, а writer выполняется параллельно.

Когда окно подходит к реальному лимиту, runtime делает rebuild: старое окно обрезается, новое окно создаётся на базе сохранённых файлов. С точки зрения модели разговор как будто продолжается, но физически начинается новое контекстное окно. Последовательность turns, прошедшая через checkpoints и rebuild, называется cycle. Количество cycle не ограничено, поэтому логическая сессия может быть длиннее любого одного окна.

Почему checkpoint делается заранее

Интуитивно кажется, что сжимать историю лучше ближе к переполнению окна. Xiaomi пишет, что это ошибка. При высокой заполненности контекста качество модели падает, а структурированное извлечение становится менее надёжным. Кроме того, самому writer тоже нужно место, чтобы прочитать историю, удержать её смысл и записать структуру.

Поэтому checkpoints запускаются заранее — примерно на 20%, 45% и 70% от настроенного бюджета. Каждая итерация обновляет предыдущую, а финальный rebuild использует уже подготовленные структурированные записи, а не пытается в последний момент сжать огромный хвост истории.

Writer: отдельный агент для памяти

MiMo Code не заставляет основного агента самому вести структурированные заметки. Xiaomi пишет, что в длинных задачах это плохо работает: модель, которая чинит сложный баг, не должна одновременно поддерживать качественный журнал состояния.

Вместо этого память вынесена в отдельный writer subagent. Он пишет checkpoint-файл фиксированной структуры из 11 полей: текущий intent, следующий шаг, рабочие ограничения, дерево задач, текущая работа, задействованные файлы, межзадачные находки, ошибки и исправления, runtime state, design decisions и miscellaneous notes. Для каждого структурированного файла есть только один writer — single-writer invariant нужен, чтобы избежать конфликтов записи.

Четыре уровня памяти

MiMo Code использует четыре слоя памяти:

Логика такая: верхние уровни более сжатые, устойчивые и маленькие; нижние — полнее, больше и медленнее. Writer поднимает полезные знания вверх, а history остаётся fallback-слоем для случаев, когда в структурированной памяти не хватает деталей.

Основной агент имеет только read access к структурированным файлам. Исключение — notes.md, session-level scratchpad, куда основной агент может append-ить промежуточные находки. Writer читает эти заметки на checkpoint, раскладывает их по структурированным полям и очищает файл.

Rebuild injection

Во время rebuild runtime собирает сохранённые файлы в иерархический prompt для нового окна. Порядок примерно такой: task list, session checkpoint, дословные фрагменты последних пользовательских сообщений, project memory, global memory, notes, индекс memory-файлов и tail reminder с указанием следующего действия.

Даже если каждый блок достигает своего лимита, общий объём injection удерживается примерно в пределах 65K tokens. После восстановления состояния агент продолжает работу без повторного подтверждения цели и без перечитывания уже обработанных файлов.

Эволюция: как агент учится между сессиями

Третий слой MiMo Code — эволюция. Xiaomi пишет, что в реальной разработке пользователь взаимодействует с одним проектом десятки или сотни раз. Если опыт каждой сессии исчезает, агент каждый раз заново обнаруживает одни и те же ограничения и повторяет старые ошибки.

Project memory хранит проектный контекст, явные правила пользователя, архитектурные решения и проверенные технические факты. Команда выбрала Markdown-файл вместо чистой vector database из-за auditability: если память влияет на поведение агента, пользователь должен видеть, что именно система запомнила, удалять ошибки и исправлять устаревшие знания.

Dream и Distill

Со временем project memory растёт, накапливает дубли, устаревшие записи и битые ссылки. Для обслуживания памяти MiMo Code использует два фоновых процесса: Dream и Distill.

Dream запускается автоматически каждые 7 дней. Отдельный агент читает историю сессий и текущую память, объединяет записи, удаляет дубли, проверяет пути и сжимает знания до актуального состояния. Он также обновляет global memory.

Distill запускается каждые 30 дней. Он анализирует не знания, а повторяющиеся рабочие паттерны: какие процессы часто возникают в проекте, что можно превратить в reusable skill, CLI-команду, кастомного агента или SOP-документ.

Оценка: benchmark и реальные AB-тесты

В офлайн-бенчмарках MiMo Code + MiMo-V2.5-Pro, по данным Xiaomi, опережает Claude Code + Claude Sonnet 4.6 на трёх основных benchmark. При этом команда отдельно уточняет, что такие benchmark всё ещё в основном измеряют способность решить одиночную задачу по одному репозиторию, а большинство преимуществ MiMo Code проявляется именно в долгих реальных сценариях.

Чтобы проверить это, Xiaomi провела внутреннее двойное слепое AB-тестирование. В нём участвовали 576 разработчиков, 474 реальных приватных репозитория и 1 213 пар с однозначным победителем. Для одной и той же задачи запускались два анонимных coding-agent, а разработчик оценивал результат; дополнительно использовались автоматическая оценка трасс и количественный анализ diff.

Ключевой вывод: преимущество MiMo Code растёт вместе со сложностью задачи. При выполнении до 200 шагов win rate был близок к 50%, но после 200 шагов, включая многораундовое взаимодействие с пользователем, win rate MiMo Code поднимался выше 65%.

Как установить MiMo Code

В статье приведены два варианта установки:

# Установка одной командой или через npmcurl -fsSL https://mimo.xiaomi.com/install | bashnpm install -g @mimo-ai/cli

При первом запуске MiMo Code предлагает выбрать способ подключения модели: MiMo Auto с бесплатным месяцем на базе MiMo-V2.5 и контекстом 1 млн токенов, вход через Xiaomi MiMo platform, импорт конфигурации Claude Code или кастомная модель.

Почему этот релиз важен

MiMo Code интересен не как ещё один терминальный агент, а как попытка инженерно закрыть проблему long-horizon coding. Большинство coding-agent хорошо выглядят на коротких задачах: поправить файл, написать функцию, найти баг. Но реальные задачи часто требуют долгой цепочки действий, промежуточных решений, проверки гипотез, возврата к старым выводам и устойчивой памяти между сессиями.

Xiaomi делает ставку именно на этот слой: не просто “модель умнее”, а runtime вокруг модели умнее. Max Mode снижает шанс ошибки на шаге, Goal борется с преждевременным завершением, checkpoint/rebuild растягивает логическую сессию, project memory сохраняет опыт, а Dream и Distill превращают историю работы в долгосрочные знания и процессы.

Фактически MiMo Code показывает тот же общий тренд, который сейчас виден у всех сильных coding-agent: конкуренция смещается от качества одиночного ответа к качеству агентной среды. Выигрывать будут не только модели, которые лучше пишут код, а системы, которые дольше держат цель, лучше помнят контекст и меньше ломаются на сотом шаге.