a* (autostar)

Если можно измерить — можно улучшить.

Soft RLVR для всех. a* превращает любую измеримую цель в структурированный цикл оптимизации. Вы определяете, что значит «хорошо». a* запускает эксперименты, оценивает результаты, учится на каждой попытке и сходится к лучшей версии в рамках вашего бюджета.

Никакой reward-модели для обучения. Никакой среды для построения. Никакого GPU-кластера для развёртывания. Только цель, оценщик и агент, умеющий искать.

Быстрый старт

Если вы просто хотите установить скилл и попробовать его в Claude Code:

npx skills add chrisvoncsefalvay/autostar

Затем вызовите его в Claude Code:

/skill autostar

Скилл проведёт онбординг, согласует с вами задачу и запустит эксперименты в рамках утверждённого бюджета.

Что это такое

Большинство артефактов существуют там, где качество реально, но сложно поддаётся полной верификации. Код можно проверить типами, но не красотой. Текст можно проверить орфографией, но не тоном.

Традиционный RLVR (обучение с подкреплением на верифицируемых наградах) требует наград, которые можно вычислить с уверенностью: математические доказательства, юнит-тесты, формальные верификации. Это покрывает лишь узкий срез того, что люди хотят улучшить.

a* использует верифицируемые-приблизительно награды. Он сочетает жёсткие сигналы (тайп-чекеры, линтеры, тест-сьюты) с мягкими (LLM-судьи, человеческие проверки). У каждого трека свой верификатор. Система выполняет достаточно шагов за итерацию, чтобы набрать статистическую уверенность.

Результат: цикл оптимизации для всего, что можно разбить на измеримые измерения. Качество кода, документация, prompt-инжиниринг, стиль письма, дизайн API, доступность.

Демонстрация

Исправление этой самой документации

Как это работает

a* работает в пяти фазах:

1. Онбординг

Интерактивный диалог — никогда не пропускается, никогда не выводится автоматически. Система разбивает вашу цель на треки (измеримые измерения), настраивает верификаторы, устанавливает ограничения, согласовывает бюджет и получает ваше одобрение перед запуском.

2. Подготовка к запуску

Базовое измерение, проверка инструментов, запрос к библиотеке диспозиций и финальное подтверждение задачи.

3. Цикл выполнения

Основной цикл:

Шаг   → мутировать артефакт, оценить все треки, применить ratchet (сохранить/откатить)
Лэп   → N шагов с одним семейством параметров → статистический вердикт
Раунд → набор лэпов → обязательная рефлексия (стоит продолжать? спросить пользователя? сменить курс?)

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

Встроенный визуализатор отображает прогресс в реальном времени в виде inline HTML-дашборда.

4. Память и обучение

Каноническим источником истины является один локальный персистентный бэкенд для всей системы. Краткосрочные логи запуска хранятся только в режиме добавления внутри запуска, а долгосрочная память хранится в этом бэкенде и экспортируется в виде человекочитаемых JSON/JSONL-зеркал.

Внутри запуска:

step_log.jsonl и reflections.jsonl — источники истины только для добавления
hypothesis_stack.json, track_trajectories.json и momentum.json — производные снимки
если производный файл расходится с логом, лог имеет приоритет

Между запусками:

эпизоды и сводки запусков сохраняются в бэкенде и зеркалируются в JSONL
диспозиции версионируются в бэкенде и зеркалируются в JSON
резервные сессии Claude.ai используют text-first пакет памяти проекта, экспортированный из бэкенда

Режимы доступа к памяти:

Режим	Значение
`direct_backend`	Runtime может напрямую использовать канонический локальный бэкенд
`connector_backed`	Runtime обращается к памяти через коннектор
`project_pack`	Runtime использует text-first пакет проекта с ручной синхронизацией
`none`	Только краткосрочная память

Диспозиции — это долгосрочная база знаний. Они формируют будущие действия на основе того, что сработало, а что нет. Встроенная память Claude полезна для непрерывности чата, но не является системой учёта для обучения a*.

5. Отчёт после запуска

Базовые vs. финальные оценки, графики траекторий, лог рефлексий, что сработало, что нет, и учёт бюджета.

Таксономия верификации

Каждый трек объявляет один из пяти типов верификаторов:

Тип	Сигнал	Когда использовать
Детерминированный	Формула / regex / правило	Количество слов, соответствие формату, валидация схемы
Внешний инструмент	CLI-подпроцесс	`pyright`, `pytest`, `eslint`, `lighthouse`, `vale`, `bandit`
LLM-судья	Структурированный LLM-вызов с фиксированными критериями оценки	Читаемость, тон, качество документации
Гибридный	Инструмент + LLM-судья, агрегированные	Фактическая точность (проверка сущностей блокирует оценку качества)
Человеческий шлюз	Пауза и вопрос пользователю	Согласование бренда, юридическое одобрение, эстетика

Верификаторы неизменны во время запуска. Изменение оценщика в середине запуска — главный режим отказа автономной оптимизации; a* предотвращает это по дизайну.

Внешние судьи

LLM-судья треки работают в режиме self (хост-агент судит inline) или external (отдельная модель через подпроцесс). Внешний режим сохраняет независимость мутатора и судьи и обрабатывает конфликты safety-фильтров: чувствительные домены могут использовать судью, который не откажется оценивать легитимный контент.

Контракт: a* записывает JSON-запрос, вызывает вашу команду и читает JSON-ответ (оценка + обоснование) из stdout. Подключите любую модель с CLI-обёрткой.

Устойчивость к safety-фильтрам

Когда safety-фильтр отклоняет LLM-вызов, a* перефразирует и повторяет попытку до двух раз. Если повторные попытки не удались, он предлагает пользователю конкретные варианты: переключиться на внешнего судью, скорректировать критерии, пропустить трек или прервать выполнение. Все отказы логируются.

Форма прогресса

(Раздел обрезан в оригинале)

autostar

Установка

README