Terminal-RSI-27B это терминальная агентная модель, которую проект Terminal-RSI выпустил на базе Qwen3.8-27B. Заявленные задачи: инспекция репозиториев, редактирование кода, починка зависимостей, воспроизведение научных пайплайнов и другие многошаговые сценарии, где нужен контакт с исполняемой средой и проверка итогового состояния.
С версией базовой модели есть расхождение. В теме материала указано «Qwen3-27B», в источнике - «Qwen3.8-27B». Предоставленные материалы не позволяют установить, какая запись точная, поэтому ниже используется формулировка источника, а при поиске весов стоит держать в голове оба варианта.
К анонсу приложены статья «Terminal-RSI: Recursive Self-Improving Terminal Agents via Recursive Self-Rewrite and Policy-Refine», страница проекта, код в репозитории jyyang26/Terminal-RSI и веса модели. Результатов бенчмарков в анонсе нет. Поэтому здесь не будет ни цифр, ни сравнений по качеству: оценивать пока нечего, кроме самой схемы обучения. Все факты ниже взяты из анонса в r/LocalLLaMA от 8 ноября 2026 года.
Что такое Terminal-RSI-27B и чем она отличается от обычной LLM
Обычная чат-модель отвечает текстом. Терминальный агент действует: читает файлы, запускает команды, правит код, смотрит на вывод и решает, что делать на следующем шаге. Разница практическая. Ответ «попробуйте обновить зависимость» и фактически обновлённая зависимость с проходящей сборкой это разные результаты, и второй требует цикла действий в среде.
Ключевые характеристики из анонса
Ниже весь подтверждённый набор фактов. Дальше в тексте только расшифровка этих пунктов и логические следствия из них.
| Параметр | Что сказано в источнике |
|---|---|
| Базовая модель | Qwen3.8-27B (в теме статьи указано Qwen3-27B, расхождение не разрешено) |
| Класс | терминальная агентная модель |
| Назначение | инспекция репозиториев, редактирование кода, починка зависимостей, воспроизведение научных пайплайнов, прочие многошаговые задачи |
| Условие задачи | взаимодействие с исполняемой средой и проверка итогового состояния |
| Метод обучения | чередование Recursive Self-Rewrite (RSR) по верифицированным траекториям и Recursive Policy-Refine (RPR) с наследованием критика |
| Артефакты | статья, страница проекта, код jyyang26/Terminal-RSI, веса Teriminal-RSI/Terminal-RSI-27B (написание как в источнике) |
| Бенчмарки | в анонсе не приводятся |
Число 27B в названии указывает на масштаб параметров базовой модели. Для локального запуска это серьёзная нагрузка на видеопамять, но конкретных требований к VRAM анонс не называет, поэтому любые цифры на этот счёт были бы догадкой.
Почему «терминальный агент» это отдельный класс
Разница между чатом с инструментами и терминальным агентом видна на первой же ошибке. Чат-модель с function calling может вызвать команду и получить вывод, но если сборка упала, цикл часто заканчивается советом проверить версию пакета. Терминальный агент по описанию проекта должен довести дело до состояния, которое можно проверить: тесты прошли, сборка собралась, скрипт отработал на тех же данных.
Формулировка источника: такие задачи «требуют взаимодействия с исполняемой средой и проверки итогового состояния». В этом предложении и спрятана методическая ставка проекта. Модель учат не на красивом тексте, а на траекториях, чей результат подтверждён. Отсюда и название фреймворка с приставкой RSI, recursive self-improving: агент не просто решает задачу, а переносит найденное решение в собственное поведение.
Практическое следствие для пользователя простое. Агент такого класса работает там, где есть shell, файловая система и способ проверить результат: тесты, линтер, сборка, воспроизводимый запуск. В чистом чате без доступа к среде его преимущество не проявится.
Какие задачи решает модель: инспекция репозиториев, правка кода, научные пайплайны
Список задач в источнике короткий, и каждая позиция стоит отдельного пояснения, потому что за ней стоит конкретный тип многошаговой работы.
- Инспекция репозиториев. Агент читает структуру проекта, находит точки входа, конфиги, тесты и разбирается, как код собирается и запускается. Это подготовительный этап почти для любой задачи: без карты репозитория правки делаются наугад.
- Редактирование кода. Изменения затрагивают несколько файлов, требуют согласованности импортов, сигнатур и стиля. Проверка идёт по состоянию после правки, а не по тому, насколько убедительно выглядит дифф.
- Починка зависимостей. Классический пример задачи, где текст бесполезен. Нужно не посоветовать версию пакета, а получить рабочее окружение: конфликт версий разрешён, установка прошла, сборка не сломалась.
- Воспроизведение научных пайплайнов (scientific workflow reconstruction). Собрать окружение и прогнать цепочку вычислений так, чтобы результат соответствовал описанию в статье или репозитории. Здесь мало запустить скрипт, важно получить ожидаемый итог.
- Прочие многошаговые задачи. Общий признак один: несколько действий подряд с проверкой состояния среды между ними.
Почему проверка итогового состояния - ключевое требование
Код может выглядеть правильным и не работать. Зависимость может установиться и сломать сборку. Пайплайн может отработать без ошибок и выдать не те числа, потому что версия библиотеки изменила поведение по умолчанию. Все три сценария объединяет одно: правдоподобный ответ не равен решённой задаче.
Отсюда логика обучения вокруг верифицированных траекторий. Если результат проверяется объективно, у обучения появляется надёжный сигнал. Если проверка слабая или её нет, модель закрепляет решения, которые просто хорошо звучат. Что именно проект использует в роли верификатора (тесты, сравнение состояния файловой системы, коды возврата, отдельную модель-критика), в предоставленных материалах не раскрыто.
Многошаговые сценарии с машинной проверкой на каждом этапе уже встречаются в практике локального запуска. Например, в материале о 27B-модели на двух GPU и марафоне по кодингу разобраны мелкие фазы с автоматической проверкой и файловая память агента. Схема похожая: агент получает обратную связь не от читателя, а от среды.
Как устроен фреймворк Terminal-RSI: RSR и RPR с наследованием критика
Название статьи проекта прямо перечисляет два механизма: Recursive Self-Rewrite и Policy-Refine. По описанию они чередуются, то есть цикл обучения состоит из двух фаз, которые сменяют друг друга и опираются на результаты предыдущей.
Recursive Self-Rewrite: успешное исследование становится воспроизводимым поведением
Логика такая. Агент попадает в незнакомую среду и начинает исследовать: смотрит файлы, пробует команды, ошибается, корректируется. Иногда он находит рабочее решение. Само по себе это ещё не обучение, а удачный эпизод: в следующий раз модель может пойти другим путём и не дойти до результата.
RSR работает с траекториями, которые прошли верификацию, и переписывает их так, чтобы найденное поведение воспроизводилось. Ключевое слово здесь «верифицированные»: в переработку попадает не любая цепочка действий, а только та, чей результат подтверждён проверкой состояния среды.
Аналогия из обычной разработки: инженер разобрался, почему падал CI, и не просто починил сборку, а добавил тест и правило в линтер, чтобы следующий случай ловился автоматически. Разовый успех превращается в повторяемую процедуру. Конкретный механизм перезаписи в источнике не детализирован: неизвестно, как именно формируется обучающая выборка из траектории и сколько итераций проходит цикл.
Recursive Policy-Refine и наследование критика
RPR уточняет политику модели, то есть её поведение в среде. Особенность, заявленная в анонсе, это наследование критика: оценка не начинается с нуля на каждой итерации, критик переходит из предыдущего цикла в следующий. На практике это должно снижать потерю накопленных знаний о том, какие решения уже забракованы, а какие прошли проверку.
Цель второго механизма в описании звучит так: превращать частичный прогресс в строго проверенное завершение задачи. Разница между «сделал половину и остановился» и «довёл до проверяемого состояния» для терминального агента принципиальная. Частично исправленный репозиторий с падающими тестами это не результат, а заготовка.
Как устроен критик, из чего он берёт сигнал и что именно наследует, материалы не раскрывают. Возможны разные варианты: отдельная модель, набор проверок, комбинация. Додумывать здесь нечего, можно только зафиксировать сам принцип.
Что именно улучшает подход
Схема опирается на два предположения. Первое: сигнал из среды надёжнее, чем оценка текста ответа. Второе: найденное в ходе исследования решение нужно закреплять, иначе агент каждый раз будет исследовать заново.
Концептуально это близко к обучению с подкреплением, где награда приходит из проверяемой среды, но прямое сравнение с RLHF или SFT было бы натяжкой: в анонсе нет ни данных о процедуре, ни метрик, ни базовых показателей. Корректная формулировка: подход делает ставку на верифицируемость результата и на перенос успешных исследований в поведение. Насколько эта ставка выигрышна, по доступным материалам проверить нельзя.
Код и веса: что реально приложено к анонсу
К анонсу приложены четыре артефакта. Ниже они в том виде, в каком перечислены в источнике.
| Артефакт | Что указано | Комментарий |
|---|---|---|
| Статья | Terminal-RSI: Recursive Self-Improving Terminal Agents via Recursive Self-Rewrite and Policy-Refine | название приведено как в источнике |
| Страница проекта | Terminal-RSI project page | отдельный ресурс проекта |
| Код | jyyang26/Terminal-RSI | репозиторий с кодом |
| Веса | Teriminal-RSI/Terminal-RSI-27B | написание с опечаткой в первом слове, как в источнике |
Прямых ссылок на эти артефакты здесь нет по простой причине: в предоставленных материалах есть только адрес обсуждения в r/LocalLLaMA, где они и перечислены. Искать нужно по названиям из таблицы, а не по памяти и не по догадкам о том, как «должно» выглядеть имя организации.
Что проверить перед тем, как пробовать локально
Анонс не содержит инструкций по запуску и требований к железу. Чек-лист ниже построен на логике работы с крупными агентными моделями, а не на заявлениях проекта, и каждый пункт стоит закрыть до скачивания десятков гигабайт.
- Уточнить точное написание репозитория весов. В источнике «Teriminal-RSI» с опечаткой, по этому имени поиск может не найти ничего.
- Проверить лицензию и формат весов на странице проекта. От этого зависит, можно ли использовать модель в работе и каким раннером её запускать.
- Оценить доступную видеопамять. 27B это крупная модель, а квантованные версии и выгрузка слоёв на CPU меняют и скорость, и качество. Ориентиры по локальному запуску моделей такого класса собраны в разборе локального запуска Qwen3-Flash-Next через llama.cpp, где видны различия между уверенной работой с кодом и рыхлыми общими рассуждениями.
- Подготовить изоляцию. Терминальный агент по определению получает доступ к shell и файлам, поэтому контейнер, отдельный пользователь и ограничение сети это гигиенический минимум, а не паранойя.
- Заранее собрать проверки: тесты, сборку, эталонный запуск. Без них вы не отличите работу агента от правдоподобного текста.
Ограничения подхода и чего в анонсе нет
Начнём с фактов, которых не хватает. В анонсе нет результатов бенчмарков, поэтому приписывать модели цифры на Terminal-Bench, SWE-bench или любых других наборах нельзя: таких данных просто не публиковали. Детали RSR и RPR не раскрыты: неизвестны ни процедура верификации, ни архитектура критика, ни объём обучающих траекторий. Обозначение базовой модели расходится (Qwen3-27B в теме и Qwen3.8-27B в источнике). Название весов приведено с опечаткой.
Отдельно стоит вопрос доверия к метрикам в целом. Даже когда бенчмарки появятся, их стоит читать с оглядкой на то, что именно они измеряют: разбор The Struggle Bench хорошо показывает, как сильно заявленный навык расходится с реальной проверяемой способностью агента.
Теперь концептуальные риски. Это вопросы к подходу, а не установленные недостатки конкретной модели.
- Качество верификатора задаёт потолок обучения. Если проверка неполная, агент будет закреплять решения, которые проходят тест и ломают что-то за его пределами. Классический случай: правка, из-за которой зелёный набор тестов перестал покрывать реальный сценарий.
- Перенос «успешных исследований» в поведение может консервировать хрупкие решения. Решение, найденное в одном репозитории, не всегда обобщается. Если механизм перезаписи не отсекает такие случаи, воспроизводимым станет случайное везение.
- Наследуемый критик наследует и свои слепые зоны. Оценка, которая не начинается с нуля, экономит ресурсы и одновременно рискует тянуть за собой систематическую ошибку прошлых итераций.
- Терминальный агент без песочницы опасен. Доступ к shell, сети и файлам означает, что цена ошибки измеряется не испорченным текстом, а испорченным окружением.
- Публичной информации мало для выводов о зрелости. Один анонс с четырьмя артефактами не позволяет судить, как подход ведёт себя на длинных задачах и сколько шагов агент выдерживает без деградации.
Есть и бытовое ограничение, знакомое всем, кто пробовал агентный кодинг: агент уверенно идёт по неверной ветке. Пример из практики многошаговой разработки описан в разборе сканер NTFS-потоков на Rust, где сбои на итерациях приходилось ловить проверкой кода и расхождением сред. Верификация результата там оказалась важнее скорости генерации.
Кому это интересно и как относиться к анонсу
Terminal-RSI-27B стоит читать как описание фреймворка обучения терминальных агентов, а не как готовый инструмент с подтверждёнными результатами. Ценность анонса в другом: он показывает, как команда формализует переход от исследования среды к воспроизводимому поведению.
Кому следить за проектом:
- разработчикам AI-агентов, которым интересны схемы обучения на верифицированных траекториях;
- тем, кто строит автоматизацию вокруг репозиториев, сборок и окружений;
- пользователям локальных LLM с железом под модели класса 27B;
- инженерам, которым нужен язык для описания требований к проверяемости агентных задач.
Что делать дальше, если тема зацепила. Прочитать статью проекта целиком: там должны быть процедура верификации и детали RPR, которых нет в анонсе. Посмотреть код jyyang26/Terminal-RSI, чтобы понять, как устроен раннер и что именно считается проверкой. Веса искать по точному имени из таблицы выше, с учётом возможной опечатки. И до появления публичных замеров не строить на этой модели производственные процессы: схема обучения выглядит осмысленной, но подтверждений её эффективности пока нет.