3,583 papers
arXiv:2610.31789 77 22 окт. 2026 г. FREE

Phronix: агент превращает своё решение в готовые инструменты и правила, чтобы не изобретать его заново

КЛЮЧЕВАЯ СУТЬ
Агент выполнил 39 команд, и повторить их нельзя: все привязаны к временным папкам. При втором запуске он заново сожжёт те же 2,84 млн токенов. Phronix позволяет агенту копить опыт между запусками: каждый новый запуск дешевле и надёжнее предыдущего. Всё, где при тех же данных ответ один (установка, сборка, формулы), агент оформляет в скрипт-инструмент. Всё, где нужно суждение, он записывает в файл правил. Результат проверяет не сама модель, а отдельный проверяющий скрипт.
Адаптировать под запрос
⚡

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

📋 Дайджест исследования

Ключевая суть

Агент выполнил 39 команд, и повторить их нельзя: все привязаны к временным папкам. При втором запуске он заново сожжёт те же 2,84 млн токенов. Phronix позволяет агенту копить опыт между запусками: каждый новый запуск дешевле и надёжнее предыдущего. Всё, где при тех же данных ответ один (установка, сборка, формулы), агент оформляет в скрипт-инструмент. Всё, где нужно суждение, он записывает в файл правил. Результат проверяет не сама модель, а отдельный проверяющий скрипт.

Принцип работы

Правило одно: разделяй код и суждение. Шаг с одним верным ответом при одинаковых входных данных — в скрипт. Шаг, где надо решать по обстановке, — в файл правил с условиями применения. Не пересказывай словами то, что можно запустить. Слова каждый раз читаются по-разному, а скрипт выполняется одинаково. Это как рецепт с граммовкой и пометки шефа на полях. Граммовку не обсуждают, её взвешивают. А пометки нужны там, где решает вкус. Цикл такой: предложил решение → проверяющий скрипт выдал вердикт со списком ошибок → агент чинит сам скрипт или правило, а не обходит ошибку разовой заплаткой. Каждое действие агент записывает в журнал: что пробовал, сработало ли, почему. Группировать записи нужно по типу операции, а не по задаче.

Почему работает

Модель не помнит прошлые сессии и каждый раз решает всё с нуля. Решение, записанное словами, при следующем чтении поймут по-другому. Если просить модель оценить свой результат, она уверена и в верных, и в неверных ответах. Жесть — в разобранном запуске 6 из 11 решений оказались неверными, а агент этого не заметил. Простые повторные попытки не помогают: это та же модель с теми же слепыми зонами. Модель хорошо пишет код и разбирает текст ошибки, но плохо судит о собственной правоте. Поэтому метод отдаёт ей то, что она умеет: писать скрипты и чинить их. Оценку забирает детерминированная проверка. Остановку решает не уверенность модели, а измеримый прогресс. Дошёл до более позднего шага — ещё попытка (до двух). Та же ошибка дважды или тот же патч — стоп.

Когда применять

Повторяющиеся задачи с проверяемым результатом → еженедельные отчёты из выгрузок, сборка и установка окружения, регулярная обработка файлов, особенно когда агент каждый раз заново чинит одну и ту же ошибку. Нужна команда, чей вывод однозначно говорит «ок» или «не ок». НЕ подходит для разовых задач: первый запуск стоит как обычно, выгода начинается со второго. НЕ подходит для текстов, креатива и стратегии: там проверяющий скрипт не написать. Следи за размером файла навыков. В оригинале на 1150 накопленных инструментах только описания занимали около 95 тысяч токенов на каждый запрос.

Мини-рецепт

1. Выбери задачу, которая повторяется: отчёт, сборка, разбор выгрузки. Для разового дела метод не окупится.
2. Найди проверку: скрипт или команда, чей вывод говорит «ок» или «не ок». Без неё метод скатывается к самооценке модели.
3. Заведи три места: папка /tools для скриптов, файл навыка для правил, файл LESSONS.md для уроков.
4. Вставь блок в CLAUDE.md или AGENTS.md: роль, правило разделения, проверка, исправление, журнал, правила остановки.
5. Задай стоп: максимум 2 попытки при прогрессе; та же ошибка дважды — остановись и опиши блокер.
6. Не знаешь, как заполнить: дай шаблон модели и попроси задавать вопросы по твоей задаче. Главный вопрос там — чем проверять результат.
7. Раз в пару недель чисти файл навыка: дубли и устаревшие правила выкидывай, иначе он превратится в свалку.

Примеры

[ПЛОХО]: `Собери отчёт по остаткам и оборачиваемости из выгрузки Wildberries` [ХОРОШО]: `Прочитай /tools и /skills/otchet.md перед работой. Шаги с одним верным ответом (чтение CSV в cp1251, склейка колонок, формула оборачиваемости) оформи скриптом в /tools. Что считать неликвидом — запиши правилом в /skills/otchet.md с условиями. После отчёта запусти /tools/check_report.py и опирайся только на его вывод. Нашёл ошибку — чини скрипт, а не пересчитывай вручную. Запиши урок в /skills/LESSONS.md.` [ПЛОХО]: `Отчёт не сошёлся, попробуй ещё раз` [ХОРОШО]: `Если проверка упала на том же шаге дважды или патч повторяется — остановись и опиши блокер. Если дошёл до более позднего шага — одна попытка ещё, максимум две.`
Источник: Phronix: The Capability-Centric Learning Paradigm for Agents
ArXiv ID: 2610.31789 | Сгенерировано: 2026-10-26 13:10

Проблемы LLM

ПроблемаСутьКак обойти
Модель не замечает свои ошибки, когда сама проверяет результатПросишь проверить собственный ответ. Модель так же уверена в неверных решениях, как и в верных. Ошибки проходят дальше. Простой повтор попыток не помогает: та же модель снова даёт похожие ошибки.Вынеси проверку из модели в скрипт. Скрипт отвечает «ок» или «не ок» и называет конкретные дефекты. В запросе пиши: «Не оценивай результат сам. Опирайся только на вывод проверки». Примеры проверок: суммы совпадают с исходником, нет пустых полей, код компилируется, тесты проходят.
Решение, записанное словами, при следующем запуске выполняется по-другомуМодель не помнит прошлые сессии. Удачное решение остаётся в тексте или в одноразовых командах, привязанных к сессии. В новом запуске модель читает описание иначе или решает заново. Результат плавает, токены уходят на то же самое.Всё, где при тех же входных данных ответ один, оформи скриптом. Модель вызывает скрипт, а не пересказывает шаги. Подробности в методе «Граница код / суждение».

Методы

МетодСуть
Граница «код / суждение» — меньше разброс между запускамиРаздели шаги задачи на два типа. Один правильный ответ при тех же входных данных (чтение файла в нужной кодировке, формула, флаги сборки) → скрипт в отдельной папке. Нужно суждение (что считать аномалией, какой вариант выбрать) → правило с условиями применения в файле навыка. В запросе: «Не пересказывай детерминированные шаги словами. Перед работой прочитай папку скриптов и файл навыка». Почему работает: скрипт выполняется одинаково каждый раз. Слова каждый раз читаются заново и по-разному. Когда да: задача повторяется регулярно, есть чем проверить результат. Когда нет: разовая задача (первый запуск не дешевле обычного) или нет однозначного критерия правильности, например тексты и креатив.
Правка источника, а не заплатка — ошибка не повторяетсяПроверка нашла ошибку. Не пересчитывай вручную в обход. Исправь сам скрипт или правило. Затем запиши в файл уроков три вещи: что сломалось, почему, как исправлено. Группируй записи по типу операции (чтение файла, расчёт, сборка), а не по названию задачи. В запросе: «Исправь скрипт или правило, а не обходи ошибку. Запиши урок». Почему работает: заплатка решает один запуск. Исправленный инструмент решает все следующие. Урок про тип операции пригодится и в другой задаче.
Остановка по прогрессу, а не по уверенности моделиДай лимит попыток и измеримое правило остановки. Прогресс = агент дошёл до более позднего шага, чем в прошлый раз (например, раньше падала сборка, теперь падают тесты). Прогресс → ещё попытка (обычно максимум две). Та же ошибка дважды или тот же патч снова → стоп и описание блокера. В запросе: «Та же ошибка дважды — остановись и опиши, что мешает». Почему работает: без правила агент крутится по кругу и жжёт токены. Модель сама не отличает «почти получилось» от «топчусь на месте». Для дешёвых задач лимит можно снизить. Порог «дважды» подбирай под задачу.
📖 Простыми словами

Phronix: The Capability-Centric Learning Paradigm for Agents

arXiv: 2610.31789

AI-агенты лажают не потому, что они тупые, а потому что у них память как у золотой рыбки. Каждый новый запуск модель начинает с чистого листа, наступает на старые грабли и радостно путает формулы. Архитектура Phronix лечит этот маразм: она автоматически делит опыт задачи на железобетонный код и гибкие правила, полностью исключая самолюбование нейронки.

Это как стажёр с вечной амнезией, который каждое утро заново изобретает колесо и делает его треугольным. Вместо того чтобы в сотый раз читать ему нотации, ты один раз зашиваешь рутину в скрипт, а для нетривиальных развилок вешаешь строгий регламент на стену. И ключевое: результат оценивает не сам исполнитель — ведь он всегда собой безумно доволен, — а бездушный внешний чекер.

В Phronix реально работают три механики. Любое однозначное действие агент сам компилирует в готовый инструмент-скрипт, чтобы навсегда закрыть вопрос с кривыми кодировками и флагами. Вопросы контекста и выбора улетают в файлы правил SKILL.md и LESSONS.md. А финальный контроль отдают не болтливой LLM, а детерминированному верификатору, который моментально ловит косяки чистой логикой.

Тестировали на аналитике отчётов с маркетплейсов, но принцип универсален. Это база для любых задач в Claude Code, сложного парсинга данных или CI/CD пайплайнов — везде, где агент на четвёртой итерации внезапно ломает то, что работало вчера. Хватит скармливать контекст впустую: без разделения знаний на код и правила агент просто превращает сложную задачу в дорогой генератор случайных ошибок.

Короче: завязывай с промпт-шаманством и перестань надеяться на рефлексию модели. Превращай повторы в скрипты, фиксируй правила, проверяй жёстким кодом. Либо твой агент начнёт сам собирать себе инструменты под капотом, либо ты продолжишь бесконечно платить за токены и руками переделывать за ним очередной запоротый отчёт.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с