Headline про 73,0% выглядит сильно, но в Orchard он складывается не из одной модели. В reported setup это Qwen3.5-35B-A3B MoE, recipe обучения с reinforcement learning, best-of-6 при выводе и отдельная 4B value model для выбора лучшего кандидата. Поэтому Orchard интересен не как очередная «модель Microsoft», а как демонстрация более жёсткого тезиса: у агента качество возникает на уровне системы, где веса, harness, инструменты, sandbox, reward и число попыток работают вместе.
Коротко
- Microsoft открыла препринт Orchard v3 на arXiv, публичный GitHub под MIT и dataset на Hugging Face; на 13 августа 2026 года tagged releases в GitHub нет.
- Orchard — это framework и слой среды, а не новая LLM: общий Kubernetes-native environment используется для SWE, GUI и Claw-задач.
- Ключевой объект работы — Orchard Env, который управляет жизненным циклом sandbox и даёт единый API для сбора данных, обучения и оценки.
- Headline 73,0% на SWE-bench Verified — author-reported системный результат с best-of-6 и 4B ranker, а не single-pass показатель одной модели.
- Работа показывает высокую чувствительность к harness: один и тот же checkpoint даёт 64,3% и 62,1% в двух обвязках, а в Claw разрыв между harness ещё больше.
- Security controls в репозитории полезны, но не доказывают production-ready безопасность: supply chain, credentials, tenant isolation и конфигурация остаются зоной ответственности оператора.
Что именно выпустила Microsoft
На дату среза 13 августа 2026 года Orchard состоит из нескольких открытых артефактов. Базовый источник — препринт Orchard версии v3 на arXiv от 30 июля 2026 года, объёмом 59 страниц; это не peer-reviewed публикация. Дополнительно 3 августа Microsoft Research опубликовала обзорный блог-пост, обновлённый 4 августа, а также доступны живой GitHub-репозиторий и dataset на Hugging Face.
Практически это означает следующее: Microsoft выложила не только описание идей, но и код среды, training stack и наборы данных для SWE и GUI. По состоянию на 13 августа GitHub-репозиторий microsoft/Orchard публичен и распространяется по лицензии MIT. При этом tagged releases репозиторий не показывает, а независимого воспроизведения headline-результатов на дату среза найти не удалось, поэтому все ключевые числа ниже нужно читать как author-reported.
Отдельно важно убрать типичную путаницу. Orchard не следует описывать как новую LLM от Microsoft: в работе используются открытые backbone-модели и набор recipe вокруг них. И столь же важно не повторять устаревший поисковый сниппет о том, что релиз якобы удержан: живая страница GitHub на дату среза открыта.
Почему среда для агента стала отдельной инженерной проблемой
Для обычной LLM ещё можно мысленно отделить модель от остального стека. Для агентной системы это работает хуже, потому что итог зависит от harness — обвязки, которая управляет циклом действий агента, вызовами инструментов, памятью, условиями остановки и верификацией результата. В задачах вроде SWE-bench Verified это особенно заметно: benchmark измеряет исследовательскую способность системы чинить код в sandbox, а не production-метрику бизнеса.
Проблема начинается с жизненного цикла среды. Если агент должен читать файлы, запускать тесты, изменять репозиторий или взаимодействовать с веб-интерфейсом, то нужен воспроизводимый sandbox: его надо быстро поднять, изолировать, ограничить по ресурсам, а затем убрать без утечек состояния. Когда одна и та же модель обучается в одном окружении, а работает в другом, появляется training-deployment mismatch: агент привыкает к одной обвязке, а в эксплуатации сталкивается с другой.
Именно поэтому Orchard делает сильный организационный ход: выносит environment в самостоятельный, повторно используемый Kubernetes-layer. Это сближает исследования по агентам с тем, как давно устроены data platform и compute platform. Становится важным не только то, какие веса у модели, но и то, какой API у инструментов, как устроена проверка ответа, сколько попыток допускает evaluation и как накапливается история rollout.
Этот сдвиг хорошо согласуется с более широким движением отрасли к системным тестам агентности, а не к голому сравнению моделей в чате. Контекст для такого перехода удобнее смотреть в обзоре agent benchmarks, где качество уже давно зависит от связки модели, инструментов и evaluator. Для GUI-агентов логика такая же, о чём отдельно говорит практика computer use.
Как устроен Orchard Env
Архитектурно Orchard Env описан как тонкий Kubernetes-native service с REST API и Python SDK. Его задача не в том, чтобы придумать новый тип рассуждения, а в том, чтобы стандартизовать среду исполнения: одни и те же операции должны работать для сбора данных, обучения с reinforcement learning и финальной оценки. За счёт этого environment превращается в повторно используемый слой, а не в одноразовый скрипт под конкретный benchmark.
- Task: система получает задачу, например багфикс в репозитории или GUI-цель.
- Sandbox pod: Orchard поднимает изолированный pod из task-specific image и внедряет лёгкий agent через init container.
- Harness/tools: обвязка управляет действиями агента, а инструменты выполняют команды, файловые операции и другие вызовы через единый интерфейс.
- Verifier: внешний проверяющий слой оценивает, достигнут ли нужный результат, например прошли ли тесты или выполнена ли цель.
- Trajectory store: вся траектория действий, ошибок и промежуточных состояний сохраняется как данные для следующего цикла.
- SFT/RL/value model: накопленные rollout используются в supervised fine-tuning, reinforcement learning и обучении отдельной value model для последующего reranking.
Важная деталь реализации — горячий путь не гоняется через Kubernetes API на каждом действии. Команды и файловые операции выполняются напрямую по Pod IP, а сама среда навешивает CPU, RAM и time limits, TTL cleanup и сетевые политики. Это снижает накладные расходы и одновременно делает интерфейс одинаковым для разных доменов.
На уровне roadmap среда пока линейна: rollout создаётся, исполняется и затем уничтожается. В качестве следующего шага авторы указывают pause/resume, branching и prefix sharing. Если эти функции появятся, агентные эксперименты смогут дешевле сравнивать контрфактические продолжения от одной точки, а credit assignment в длинных процессах станет точнее.
Системные показатели Orchard Env: что измерили авторы
Ниже — не универсальные метрики рынка, а measurements в конкретной конфигурации авторов. Для корректного чтения важно помнить условия: образы были заранее загружены, кластер состоял из восьми cloud VM по 32 vCPU и 128 GiB RAM, а ценовые оценки привязаны к rate cards апреля 2026 года. Особенно это касается spot-стоимости: она нестабильна и не переносится автоматически на другой cloud или workload.
| Показатель | Orchard Env (authors report) | Сравнение | Конфигурация и оговорки |
|---|---|---|---|
| Средняя задержка одной команды | 0,280 с | SkyPilot Code Sandbox — 0,284 с; E2B — 0,747 с; Modal — 2,046 с | Предзагруженные images; сравнение относится к собственной конфигурации статьи |
| Стресс-тест параллелизма | 1000 sandbox, 4 команды в каждом, 100% успешных сессий, 26 с end-to-end, около 154 команд/с | Без отдельного внешнего baseline в той же таблице | Те же восемь VM; результат не эквивалентен универсальной production SLA |
| Оценочная стоимость 128 sandbox по 2 vCPU/8 GiB на 240 часов | $3362 on-demand; $673 spot | Daytona/E2B — $7078; Modal — $10305 | Цены апреля 2026 года; spot и публичные rate cards не дают универсальный TCO |
Смысл этих цифр не в доказательстве «самой дешёвой среды», а в более узком выводе. Авторы показывают, что Kubernetes-layer в их setup не выглядит заметно медленнее Docker-подобного baseline и может обслуживать большой параллелизм без видимой деградации. Но переносить эти значения на собственную инфраструктуру без перепроверки нельзя.
Orchard-SWE: какие данные накапливает система
Наиболее содержательный фрагмент работы — Orchard-SWE, где environment используется как машина для накопления и переработки rollout history. Датасет включает 107 185 траекторий по 19 287 уникальным задачам и 2788 репозиториям. Из этих траекторий 74 649 помечены как resolved, а 32 536 — как unresolved.
| Срез Orchard-SWE | Значение | Контекст |
|---|---|---|
| Траектории | 107 185 | История agent rollout для обучения и анализа |
| Уникальные задачи | 19 287 | SWE-задачи в разных репозиториях |
| Репозитории | 2788 | Набор кодовых баз, на которых строятся сценарии |
| Resolved | 74 649 | Траектории, завершившиеся успешным решением |
| Unresolved | 32 536 | Неуспешные траектории, которые не выбрасываются полностью |
| Средняя длина | 47,5 взаимодействия и около 21 000 токенов | Длинные агентные процессы, где особенно важен правильный reward |
В качестве teacher-моделей для генерации данных использовались MiniMax-M2.5 и Qwen3.5-397B. Harness в этом контуре — mini-swe-agent и OpenHands. Для каждой задачи авторы генерировали по пять rollout и сохраняли успешные траектории, но при этом неуспешные прогоны не считались полностью бесполезными.
Это один из центральных моментов Orchard. В классическом коротком SFT неудачный пример часто просто отбрасывают. Здесь же сама история неуспеха становится сырьём: из неё можно извлечь локальный прогресс, признаки хорошей дисциплины и материал для отдельной value model.
Как Orchard извлекает сигнал из длинных агентных запусков
Основная сложность длинных агентных задач состоит в редком и грубом reward. Если финальный сигнал бинарный — задача решена или нет, — то модели трудно понять, какие промежуточные шаги были полезными. Orchard отвечает на это не одной техникой, а связкой методов, и именно поэтому нельзя приписывать весь результат одной только среде.
Credit-assignment SFT
В credit-assignment SFT система пытается выделить из неуспешной траектории участки, где агент всё же делал осмысленный прогресс. Модель обучается не только на «идеальных» историях полного успеха, но и на частично полезных шагах. Это снижает потери данных и делает обучение менее зависимым от редких полностью успешных rollout.
BAR, OPD и RPR
Balanced Adaptive Rollout регулирует, какие rollout стоит продолжать и на чём сосредотачивать sampling, когда награда редкая и бинарная. On-policy distillation добавляет более плотный сигнал от teacher distribution на тех состояниях, куда уже приходит текущая policy. Rubric-based process reward оценивает не только финал, но и дисциплину процесса: воспроизведён ли баг, запускались ли тесты, проверялось ли исправление, как агент реагировал на failure.
Historical experience distillation
Последний слой — это использование исторических rollout для обучения отдельной 4B value model. Она не решает задачу сама, а оценивает кандидатов, сгенерированных основной моделью, и помогает выбрать лучший. По сути Orchard превращает историю прошлых запусков в переиспользуемый актив, который улучшает inference-time selection.
Отсюда и главный методологический вывод. Рост качества в Orchard нельзя свести к формуле «поставили лучшую среду и получили больше процентов». Одновременно меняются данные, teacher-модели, training recipe, verifier и способ выборки кандидатов.
Результаты Orchard-SWE: как читать шкалу от 61,4% до 73,0%
На SWE-bench Verified, который подробнее разобран в отдельном материале COMRAD404, Orchard показывает цепочку улучшений на одном backbone. Для Qwen3.5-35B-A3B под mini-swe-agent авторы приводят среднее по трём запускам. Это важно: ниже показан progression внутри одного исследовательского setup, а не прямая «победа модели над всеми».
| Режим | Конфигурация | SWE-bench Verified (authors report) |
|---|---|---|
| Base | Qwen3.5-35B-A3B под mini-swe-agent | 61,4% |
| RL + BAR | Тот же backbone, добавлен Balanced Adaptive Rollout | 69,1% |
| RL + OPD | Тот же backbone, добавлена on-policy distillation | 69,3% |
| RL + RPR | Тот же backbone, добавлен rubric-based process reward | 69,7% |
| RPR + value-model reranking | Best-of-6 и отдельная 4B value model для выбора кандидата | 73,0% |
В этой таблице видно главное: Orchard продвигает не просто модель, а весь цикл получения и использования rollout history. Если смотреть только на финальную строку, теряется важная ступенчатость. Если смотреть только на среду, теряется вклад reward, teacher supervision и reranking.
Почему 73,0% — не single pass
Финальный headline не означает, что агент в одном автономном прогоне решает 73,0% задач. В reported setup система генерирует N=6 кандидатов, после чего отдельная 4B value model выбирает лучший ответ. Это пример best-of-N, то есть схемы с дополнительным inference compute, а не single-pass оценки.
Для ориентира авторы также показывают oracle на уровне 82,4%: это гипотетический селектор, который всегда выбирал бы успешного кандидата, если он есть среди шести. Такой разрыв означает, что заметная часть потенциала и заметная часть текущего результата лежат именно в механике отбора. По этой причине сравнивать 73,0% с однопроходными системами без маркировки режима нельзя; различие между single pass, pass@k и best-of-N подробнее полезно держать в голове вместе с материалом о repeated sampling.
Нюанс с параметрами: это не «3B-модель на 73%»
Qwen3.5-35B-A3B — это MoE-модель, то есть mixture-of-experts. В работе фигурируют примерно 35 млрд параметров всего и около 3 млрд активных на токен. Поэтому формулировка «3B model reaches 73%» некорректна: она скрывает полную архитектуру, дополнительный inference compute и отдельный 4B ranker.
Даже утверждение о «десятикратной компактности» относится только к активному parameter budget в моменте, а не к полной памяти, latency или стоимости всей системы. Для инженерного сравнения надо считать всю конфигурацию целиком: backbone, selector, число попыток и sandbox overhead.
Harness sensitivity: почему цифра принадлежит системе, а не только весам
Один из самых полезных результатов Orchard — демонстрация чувствительности к обвязке. Внутри статьи один и тот же SFT checkpoint показывает 64,3% с mini-swe-agent и 62,1% с OpenHands. На unseen Kimi-CLI разброс становится ещё заметнее, хотя точные значения в кратком факт-паке не приводятся.
Та же логика видна и в Orchard-Claw. На одном checkpoint авторы сообщают 59,6% pass@3 на Claw-Eval, а с более сильным ZeroClaw harness — 73,9% pass@3. Здесь важно не спутать режимы: pass@3 означает успех за срок до трёх попыток, а не вероятность успешного single-run.
Это наблюдение хорошо сочетается с тем, как постепенно стандартизуются tool interface и схемы подключения инструментов, например в обсуждении MCP. Чем агентнее задача, тем менее осмысленно говорить о «способности модели» в отрыве от интерфейсов, восстановительных механизмов и verifier logic.
Orchard-GUI: перенос идеи среды в веб и визуальные задачи
Помимо SWE, Orchard показывает ту же логику на GUI-агентах. Orchard-GUI построен вокруг Qwen3-VL-4B-Thinking, примерно 0,4K distilled trajectories и 2,2K open-ended RL tasks. В reported setup авторы приводят 74,1% на WebVoyager, 67,0% на Online-Mind2Web и 64,0% на DeepShop, что даёт среднее 68,4%.
Но интерпретировать эти проценты надо осторожно. Организаторы таких бенчмарков используют live websites, а значит итог зависит не только от модели и среды, но и от доступности страниц, UI drift, judge и механизмов восстановления состояния. Поэтому GUI-результаты стоит читать как snapshot исследовательского setup, а не как стабильную производственную гарантию; контекст таких систем полезно держать рядом с анализом computer use.
Безопасность и зрелость: что есть в репозитории, а чего нет
В репозитории и статье описан набор базовых защитных мер. Среди них Redis-backed state и distributed locks, Calico NetworkPolicy с deny-egress по умолчанию, API-key authentication, ресурсные лимиты и TTL cleanup для sandbox. Для исследовательской среды это полезный минимум, который снижает риск и помогает управлять жизненным циклом окружения.
Но из этого не следует, что Orchard доказал production-ready безопасность для hostile multi-tenant deployment. Вне статьи остаются вопросы image supply chain, управление credentials, точная настройка сетевых исключений, изоляция tenant и качество операционной конфигурации Kubernetes. Отсутствие tagged releases на 13 августа 2026 года — это прежде всего сигнал зрелости проекта, а не доказательство плохого качества или, наоборот, достаточной готовности к эксплуатации.
Что Orchard доказал, а что пока не доказал
| Поддержано экспериментами авторов | Пока не доказано независимо |
|---|---|
| Единый environment API можно использовать как минимум в трёх доменах: SWE, GUI и Claw | Headline-результаты воспроизводятся сторонней командой на дату среза |
| Повторное использование неуспешных траекторий и более плотные rewards повышают качество в выбранных setup | Стоимость и производительность сохранятся в другой облачной конфигурации и на другом workload |
| Harness заметно влияет на итоговый score даже при одном и том же checkpoint | Generalization устойчив к существенно другим репозиториям, сайтам и бизнес-процессам |
| Historical rollouts можно сжать в value model и использовать для reranking | Security controls достаточны для hostile multi-tenant production |
| Kubernetes layer в тестовой конфигурации не показал видимой деградации относительно Docker baseline | Большая часть прироста вызвана именно Orchard Env, а не данными, teacher models, verifier и sampling |
| Система обучения и оценки становится более переносимой за счёт общего слоя среды | 73,0% автоматически означает лучшую стоимость, latency или операционную эффективность, чем у frontier alternatives |
Каких последствий ждать дальше
Если вынести за скобки headline, Orchard подталкивает к смене единицы анализа. Для агентов всё меньше смысла в leaderboard, где указано только имя модели. Гораздо полезнее видеть рядом harness, tool schema, лимиты среды, verifier и число попыток, потому что именно эта композиция определяет результат.
Второе следствие — превращение rollout history в самостоятельный dataset. Неудачные прогоны больше не выглядят как шум, который нужно удалить: они нужны для credit assignment, process reward и обучения value models. Это приближает агентные исследования к более зрелому циклу, где прошлые запуски становятся капиталом для следующих итераций.
Третье направление — уменьшение training-deployment mismatch. Orchard уже строит общий интерфейс между сбором данных, RL и оценкой, а следующая логичная стадия — обучение в той же реальной обвязке, в которой агент потом работает. Показательно, что в июне и июле 2026 года в смежной экосистеме появились OpenWebRL и OpenForge RL, расширяющие эту линию на live websites и реальный deployment harness; это важный вектор, хотя и не основной предмет текущего препринта.
Наконец, roadmap со snapshot, branching и prefix sharing может изменить стоимость экспериментов с длинными процессами. Если система сможет ветвить продолжения из одной общей точки, станет дешевле оценивать ценность конкретного шага и сравнивать стратегии в контролируемом контексте. Тогда среда окончательно станет не фоном для модели, а её частью в инженерном смысле.
Вывод
Microsoft Orchard не доказывает, что появился «маленький агент», который сам по себе решил 73,0% задач на SWE-bench Verified. Работа показывает нечто более полезное и более приземлённое: агентный score принадлежит системе, в которую входят backbone-модель, harness, среда исполнения, verifier, данные, reward и механизм выбора ответа. На дату среза это остаётся author-reported результатом без найденного независимого воспроизведения, но сама постановка вопроса выглядит сильной.
Если Orchard и запомнят надолго, то не из-за одного headline. Скорее из-за того, что он формализует environment как повторно используемый слой разработки и делает накопленную историю rollout такой же важной, как рост параметров. Для инженерных команд это полезный сигнал: оптимизировать нужно не только веса, но и всю систему, в которой агент живёт и учится.
FAQ
Orchard — это модель или framework?
Это framework и слой среды, а не новая LLM. В работе используются открытые backbone-модели, а вклад Orchard — в environment, data pipeline, reward recipe и reranking.
Можно ли говорить, что «3B-модель набрала 73,0%»?
Нет. В reported setup используется Qwen3.5-35B-A3B MoE с примерно 35 млрд параметров всего и около 3 млрд активных на токен, плюс best-of-6 и отдельная 4B value model.
Почему 73,0% нельзя сравнивать с single-pass результатами?
Потому что это best-of-6 с дополнительным inference compute и отдельным селектором. Single pass, pass@k и best-of-N измеряют разные режимы работы и должны маркироваться отдельно.
Доказал ли Orchard production-ready безопасность?
Нет. В репозитории есть deny-egress, TTL cleanup, лимиты и API-key authentication, но безопасность зависит от конфигурации Kubernetes, supply chain, credentials и tenant isolation.
Зачем Orchard хранит неуспешные траектории?
Потому что в длинных агентных задачах неудачный запуск может содержать полезные локальные шаги. Их можно использовать в credit-assignment SFT, process reward и обучении value model.
Что самое важное Orchard показывает инженерам?
Что leaderboard number принадлежит не только весам модели. Harness, verifier, формат инструментов, sandbox и число попыток могут менять результат почти так же заметно, как выбор backbone.
Источники
- Orchard v3 на arXiv — основной препринт с архитектурой, данными и reported-результатами.
- Microsoft Research Blog — обзор публичного релиза среды, данных и evaluation methods.
- GitHub: microsoft/Orchard — живой кодовый репозиторий, лицензия MIT и состояние проекта на дату среза.
- Hugging Face dataset: microsoft/Orchard — опубликованные SWE и GUI subsets.
- SWE-bench paper — контекст benchmark для программных задач.
- Critical context on SWE-bench — контекст ограничений и аккуратной интерпретации benchmark-результатов.