TL;DR
Phronix — архитектура самообучающегося агента, которая делит всё, что агент узнал за задачу, на две части. Всё, где при тех же входных данных правильный ответ один (установка, сборка, флаги), превращается в готовый инструмент-скрипт. Всё, что требует суждения (что именно размечать, какой вариант выбрать), записывается в файл правил (SKILL.md, LESSONS.md). Каждое действие агента фиксируется автоматически, без просьбы пользователя. Результат проверяет детерминированный проверяющий инструмент, а не сама модель.
Главная находка: проблема не в модели, а в обвязке вокруг неё. Агент решает задачу, но решение остаётся в виде одноразовых команд. В разборе одного запуска Claude Code с gpt-5.5 агент выполнил 39 команд, и почти все были привязаны к временным папкам и состоянию конкретной сессии. Повторить их нельзя. Ничего не сохранилось, и при втором запуске он заново тратит те же 2,84 млн токенов. Ещё агент сам не заметил ошибки: 6 из 11 решений в итоговой работе оказались неверными.
Метод работает как цикл «предсказал → проверил → исправил». Агент предлагает решение, проверяющий инструмент выносит вердикт с точным перечнем ошибок, агент чинит сам навык, а не обходит проблему разовой заплаткой. Если задача падает, цикл не просто повторяет попытки. Он идёт на исследование проблемы, но останавливается, когда прогресса нет: та же ошибка дважды или тот же патч снова.
Схема метода
ШАГ 1 (Capability Builder): перед задачей подгружает из хранилища нужные
навыки и инструменты → агент стартует не с нуля
ШАГ 2 (Агент): решает задачу, вызывая накопленные инструменты
ШАГ 3 (Tracker): каждое действие (что пробовал, сработало ли, кратко почему)
пишется в журнал автоматически → группировка по ТИПУ операции, не по задаче
ШАГ 4 (Validator): детерминированная проверка (компилируется? дубликат?
сработало на отложенных примерах?) → вердикт с перечнем ошибок
ШАГ 5 (Corrector): агент правит сам навык/инструмент, а не обходит ошибку
ШАГ 6 (Researcher): при провале — смотрит, есть ли ответ в хранилище;
если нет — планирует подход, даёт попытки по прогрессу
ШАГ 7 (Promotion): после КАЖДОЙ задачи проверенное уходит в постоянное хранилище
Правило остановки: прогресс = дошёл до более позднего шага → ещё попытка (до двух);
та же ошибка дважды или тот же патч → стоп
Это система на коде. В одном чате она не воспроизводится. Её принципы можно перенести в файл инструкций агента (см. шаблон ниже).
Пример применения
Задача: аналитик селлера на Wildberries каждую неделю просит агента в Claude Code собрать отчёт по остаткам и оборачиваемости из выгрузки кабинета. Каждый раз агент заново разбирается: какая кодировка у CSV, какие колонки склеивать, как считать оборачиваемость. На четвёртой неделе он снова ошибается в формуле, которую уже чинили.
Промпт (блок в CLAUDE.md проекта — ручная версия принципов Phronix):
Ты ведёшь еженедельный отчёт по остаткам и оборачиваемости для магазина на Wildberries.
Каждое решение должно сделать следующий запуск дешевле и надёжнее.
Если у шага один правильный ответ при одинаковых входных данных (чтение CSV в cp1251,
склейка колонок, формула оборачиваемости) — оформи скриптом в папке /tools.
Не пересказывай такие шаги в тексте.
Если шаг требует суждения (какие артикулы считать неликвидом, как трактовать
аномальный остаток) — запиши правило в /skills/otchet.md с условиями применения.
Перед работой прочитай /tools и /skills/otchet.md. Решай задачу, вызывая готовые скрипты.
После отчёта запусти /tools/check_report.py: суммы остатков совпадают с выгрузкой,
нет пустых артикулов, оборачиваемость не отрицательна. Не оценивай результат сам —
опирайся только на вывод проверки.
Если проверка нашла ошибку — исправь скрипт или правило, а не пересчитывай вручную
в обход. Запиши в /skills/LESSONS.md: что сломалось, почему, как исправлено.
Записывай в /skills/LESSONS.md каждую неудачную и каждую удачную попытку:
что пробовал, сработало ли, одна строка почему. Группируй по типу операции
(чтение файла, расчёт, выгрузка), не по названию отчёта.
Попытка считается прогрессом, если агент дошёл до более позднего шага, чем раньше.
Прогресс — ещё попытка (максимум две). Та же ошибка дважды или тот же патч снова —
остановись и опиши блокер.
Результат: на первой неделе агент пройдёт задачу как обычно, но оставит после себя скрипты в /tools и записи в LESSONS.md. На второй неделе начнёт с чтения накопленного и вызовет готовые скрипты. Проверка запустится отдельным скриптом. Если отчёт не сходится, агент починит инструмент и запишет урок. Если упрётся в ту же ошибку дважды, остановится и опишет, что мешает.
Почему это работает
Слабость: модель не помнит прошлые сессии и каждый раз решает задачу заново. Если решение записано словами, при следующем чтении его поймут по-другому. Если проверять результат собственной оценкой модели, она уверена и в верных, и в неверных ответах. Поэтому простой повтор попыток только пересэмплирует ту же модель.
Сильная сторона: модель хорошо пишет код, разбирает текст ошибки и принимает локальные решения. Скрипт выполняется одинаково каждый раз. Проверка скриптом выдаёт один и тот же вердикт и называет конкретные дефекты.
Как метод это использует: повторяемое уходит в код, а в тексте остаётся только суждение. Модель никогда не оценивает свой результат, этим занимается детерминированная проверка. Остановку решает измеримый прогресс, а не уверенность модели.
Рычаги управления: - Граница «код / проза» → чем больше шагов вынесено в скрипты, тем меньше разброс между запусками. - Лимит попыток (в оригинале прогресс даёт до двух попыток, смена вида ошибки — ещё одну) → уменьши для дешёвых задач. - Критерий остановки → «та же ошибка дважды» можно заменить на свой порог. - Группировка уроков → по типу операции, а не по задаче: урок про сборку пригодится в другом проекте. - Структурные проверки (файл читается, ссылки живы) → дают базу даже до первых собственных проверок.
Шаблон промпта
В статье нет готового промпта: Phronix устроен как код. Шаблон ниже — ручная версия принципов для файла инструкций агента (CLAUDE.md, AGENTS.md). Автоматики оригинала (фоновый обучатель, граф знаний, дедупликация) в нём нет.
Ты — агент, который решает повторяющиеся задачи: {тип_задач}.
Каждое решение должно сделать следующий запуск дешевле и надёжнее.
Шаг с одним правильным ответом при тех же входных данных → скрипт в {папка_скриптов}.
Шаг, требующий суждения → правило с условиями в {файл_навыка}.
Не пересказывай детерминированные шаги словами.
Перед работой прочитай {папка_скриптов} и {файл_навыка}.
Решай задачу, вызывая готовые инструменты. Не придумывай то, что уже записано.
После результата запусти {команда_проверки}.
Опирайся только на её вывод, не оценивай результат сам.
Если проверка нашла ошибку — исправь скрипт или правило, а не обходи ошибку.
Запиши в {файл_уроков}: что сломалось, почему, как исправлено.
По ходу работы записывай в {файл_уроков} каждую попытку: что пробовал,
сработало ли, одна строка почему. Группируй по типу операции, а не по задаче.
Прогресс = дошёл до более позднего шага, чем раньше → ещё попытка (максимум {число_попыток}).
Та же ошибка дважды или тот же патч снова → стоп, опиши блокер.
Подставь: {тип_задач} — что агент делает регулярно. {папка_скриптов} и {файл_навыка} — где хранить инструменты и правила. {команда_проверки} — любая команда, чей вывод однозначно говорит «ок» или «не ок». {файл_уроков} — отдельный файл для уроков. {число_попыток} — обычно 2.
🚀 Быстрый старт — вставь в чат:
Вот шаблон самообучающегося агента (по принципам Phronix). Адаптируй под мою задачу: [твоя повторяющаяся задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая задача повторяется, чем проверить результат и где хранить файлы. Без команды проверки блок не работает: модель вернётся к оценке самой себя, а метод строится на том, чтобы этого не делать.
Ограничения
⚠️ Нужен код: оригинал — набор Python-модулей, MCP-инструментов, фонового обучателя и графа знаний. Читатель без разработки воспроизведёт только принципы в виде инструкций. Автоматический сбор опыта без просьбы пользователя в ручной версии недоступен.
⚠️ Нужна проверяемая задача: метод опирается на детерминированный проверяющий инструмент. Для задач без однозначного критерия (тексты, креатив, стратегия) валидатор написать нельзя.
⚠️ Разовые задачи не выигрывают: выгода появляется только на повторяющихся задачах. Первый запуск стоит не дешевле обычного. Накопленное хранилище окупается со второго раза.
⚠️ Раздувание инструментов: на примерно 1150 накопленных инструментах схемы занимали около 95 тысяч токенов на каждый запрос. Авторы ввели «диспетчер» после 64 возможностей. В ручной версии следи, чтобы файл навыка не превратился в свалку.
⚠️ Вклад частей не разделён: в доступной части текста нет проверки «что будет, если убрать один компонент». Нельзя сказать, какое из правил даёт основной эффект. Основной практический кейс один (инструментирование HPC-приложения), плюс SWE-bench. Результаты получены самими авторами. Часть про Researcher и полные результаты в тексте обрезаны.
Как исследовали
Авторы начали с одного разбора. Они дали Claude Code с gpt-5.5 задачу: разметить научный конвейер 1000 Genomes трассировщиком ввода-вывода. Агент справился, но все три проблемы вылезли сразу: решение не повторить, ничего не записано, при втором запуске он повторит те же 50 вызовов. Отсюда выросли три механизма Phronix.
Дальше они проверяли систему на двух видах задач: на SWE-bench (исправление ошибок в репозиториях) и на этом конвейере. Сравнивали с базовой обвязкой без накопления опыта. Измеряли долю задач, решённых с первой попытки, число накопленных возможностей, токены на задачу и количество пройденных проверок корректности.
Результаты: решение повторяющейся задачи с первой попытки в 93–95% случаев на всех моделях. На конвейере проходят все 11 проверок против 6 у базовой обвязки. Две дешёвые модели поднялись с 29% и 27% до 91% и 87% решённых задач SWE-bench, то есть до уровня самой дорогой. Токены тоже интересны: запуск с готовым хранилищем тратит 0,38–0,40 млн токенов на задачу, это в три-четыре раза меньше одной базовой попытки. Холодный старт стоит не больше базы. Новые возможности создаются в среднем 7,6–30,8 на задачу, но когда нужная уже есть, падают ниже двух.
Инсайт для практики: слабая модель с хорошей обвязкой догоняет дорогую. Вкладывать усилия стоит в то, что агент сохраняет и проверяет, а не только в выбор модели.
Адаптации и экстраполяции
🔧 Техника: убрать «агент записывает уроки» → «ты записываешь после каждой сессии»
Если агент забывает вести журнал, замени на разбор в конце сессии:
В конце сессии просмотри историю своих команд. Выдели: (1) что можно превратить в скрипт,
(2) какие ошибки были и как исправлены, (3) какие решения потребовали суждения.
Предложи изменения в /tools и LESSONS.md, но не вноси их, пока я не подтвержу.
Эффект: ты контролируешь, что попадёт в постоянную память. Это дешевле автоматики, но возвращает человека в цикл. Автоматика была задумана ровно для того, чтобы человека оттуда убрать.
Ресурсы
- Phronix: The Capability-Centric Learning Paradigm for Agents — Hariharan Devarajan, Neeraj Rajesh, Aniruddha Marathe, Nikoli Dryden, Kin Ng, Michela Taufer
- Lawrence Livermore National Laboratory; Illinois Institute of Technology; University of Tennessee, Knoxville
- Упомянутые в статье: Model Context Protocol (MCP), Claude Code, Codex, OpenCode, DFTracer, 1000 Genome Pegasus workflow, SWE-bench
