Содержание
Путеводитель по паттернам (Таблица) — обзорная таксономия Ralph-агентов.
Базовая терминология — разбор понятий Верификатор, Оракул и Артефакты.
Паттерн №1: Same-prompt Ralph — анализ подхода Anthropic.
Паттерн №2: External verifier Ralph — анализ подхода Vercel.
Паттерн №3: Artifact-evolving Ralph (Huntley) — разбор оригинальной концепции.
Паттерн №4: Artifact-evolving Ralph with external verifier — подход с внешней проверкой (Codex).
Как агент «умнеет» (Эволюция артефактов) — почему Ральф расставляет «таблички».
Паттерн №5: Self-evolving agent — высшая форма автономии.
Итоги: Дизайн-чеклист — 6 вопросов для архитектора.
Все началось с довольно прикладного спора с коллегой об одном агентном решении. Мы не могли сойтись во мнении, что именно вообще стоит называть Ralph loop, так что пришлось лезть в интернет за пруфами. А дальше случился один из тех раздражающих моментов, когда чем больше читаешь, тем больше тумана.
Постепенно стало ясно, что под "Ralph loop" уже начинают понимать очень разные, а иногда и почти противоположные вещи. И это не просто мое ощущение: вокруг Ralph довольно быстро появились публичные пересказы, упрощающие его по-разному [1] , [2], [3], а затем и публичные поправки к этим интерпретациям - [4], [5], [6], [7].
И поэтому любой разговор о нем очень быстро начинает напоминать сцену из Spider-Verse: “все вроде говорят про одного и того же Человека-паука и каждый уверен, что именно его версия и есть настоящая.”
Давайте разложим все по полочкам. А Питеров Паркеров Ральфов по их мирам.
Среди существующих реализаций встречаются следующие варианты - см. Таблицу
p.s. Хочу обратить внимание, что ниже скорее моя внутренняя рабочая таксономия, чем какие-то общеупотребимые сообществом термины.
Издалека все они могут выглядеть похоже, потому что везде есть: цикл, борьба с “протуханием” контекста (context rot), критерии успеха и некий верификатор, который проверяет достижимость критериев - погонщик цикла.
Но если начать их рассматривать поближе, то можно заметить что:
- цикл может быть внутренний и/или внешний;
- память - ослабление зависимости от “протухания” контекста (context rot) может быть за счет полного удаления логов и истории рассуждений, сделанных внутри итерации, за счет простой суммаризации этой информации или глубокого анализа и выявления причин неудач;
- критерии успеха/завершения цикла могут быть описаны вербально, реализованы в тестах или “зашиты” в среду или и то и другое;
- верификатор может быть внешним и внутренним, независимым и чисто номинальным, когда реальный оракул - источник окончательного решения “Можем ли мы принять результат и выйти из цикла?” остается внутри “решателя” задачи.
Базовая терминология
Верификатор - центральный элемент цикла, потому что без него сама идея итерационного цикла становится шаткой. Если после каждого шага система никак не проверяет результат, то непонятно, зачем ей делать следующую итерацию и что вообще считается прогрессом. Если провести аналогию с обучением моделей - на уровне обучения критически важен сигнал вознаграждения: без сигнала качества модель не знает, какое поведение усиливать. На уровне цикла агента верификатор играет сходную роль - он не обязательно совпадает с функция вознаграждения (reward function) в строгом RL-смысле, но именно должен поставляет системе оценочный сигнал о том, приблизилась ли она к цели. В простых случаях этот сигнал бинарный - pass/fail. В более сложных он может быть богаче: список ошибок, штрафы, скоры бенчмарка, фидбек для следующей итерации. Но в любом случае именно этот слой должен связывать генерацию с реальной проверкой и не давать циклу превратиться в самообман.
Оракул - этот термин шире, чем "верификатор". Оракул - это источник окончательной истины о том, выполнена задача или нет. А верификатор - конкретный технический механизм доступа к этой истине. Иногда они почти совпадают иногда нет: например, запуск тестов - верификатор, интерпретатор результатов тестов - оракул. Иногда нет: бенчмарк выступает оракулом, а evaluation pipeline - лишь способом его вычислить; человек может быть оракулом, а форма проверки - ревью; платформа может быть оракулом, а API-ответ - каналом получения сигнала. Поэтому колонка "Where is the oracle" так важна: она показывает, кому именно архитектура делегирует право сказать "достаточно, задача решена".
Системный промпт - это верхний слой инструкций, который задает роль агента, его ограничения, приоритеты, допустимые действия и формат сигнала о завершении. Он отвечает за "режим работы" агента. При этом системный промпт не обязательно существует как отдельный файл. Он может быть зашит в коде, собираться программно перед каждым запуском или комбинироваться с внешними артефактами.
Артефакты - здесь имеются в виду внешние объекты, которые сохраняются между итерациями и или вставляются в системный промт или читаются агентом перед началом работы. Это могут быть сжатые логи предыдущей работы, а могут быть накопленные правила или знания, полученные в результате глубокого анализа предыдущих шагов.
Рассмотрим существующие примеры, увидим как меняются подходы к реализации элементов их архитектуры и найдем узкие места.
1. Same-prompt Ralph
Same-prompt Ralph - один и тот же промпт перезапускается в цикле, пока модель не решит сказать "готово" (completion promise), а внешняя синтаксическая проверка подтвердит наличие ожидаемого токена и остановит работу. Управление циклом здесь как будто внешнее, но реально решение о завершении принимает сама модель.
Если разложить одну итерацию по шагам, получается так. На вход итерации агент получает неизменный системный промт с задачей, критериями успеха и требованиями к верификации: какой токен вернуть, если задача готова; плюс изменившееся состояние рабочей директории. Дальше агент сам выбирает рабочие действия внутри прохода, в зависимости от того, что указано в системном промте: написать код, написать падающие тесты, реализовать, запустить тесты, далее в цикле дебажить и исправлять, пока тесты не станут полностью зеленым.
Таким образом во внутреннем цикле решения задачи предусматривается валидация через среду (environment validation, Reality Check): тесты, линтеры, сборка, файлы, покрытие, но она не оформлена как самостоятельный reality-check модуль, это всего лишь требования, описанные в системном промте агента вместе с основным запросом: агент запускает что-то, видит реальные ошибки, исправляет их в этом же внутреннем цикле.
Из-за этого может оказаться, что весь цикл разработки (Software Development Life Cycle (SDLC)) осуществляется внутри одной сессии работы и между итерациями не происходит никакой очистки памяти, сессия разрастается, а агент просто пытается решить всю задачу сразу во внутреннем цикле.
Вместо того чтобы перезапускать агента на свежем контексте, он работает как single session, где контекст накапливается. А самое главное - он в этой же перегруженной сессии он же решает, достигнуты ли критерии завершения всей задачи.
Никаких плюсов разделения на внутренний и внешний цикл не наблюдается, так как внешний цикл тут чисто номинальный.
Пример
Плагин Ralph у Anthropic - самый чистый пример этого паттерна. Сам плагин прямо описывает цикл так: Claude работает над задачей, пытается выйти, хук перехватывает выход, подает тот же промт снова, и так повторяется до тех пор, пока модель не выведет “DONE” или по достижению лимита итераций.
Детали:
Документация Anthropic Ralph предполагает внутреннюю валидацию через среду - тесты, ошибки, исправления, повторные прогоны. Но все это поведение пользователь плагина должен сам “зашить” в свой промт. README рекомендует формулировать задачу и критерии завершения через проверяемые условия и TDD (Test-Driven Development)-формулировки, но это именно бест практис (best practices) для написания промта, а не зафиксированный кодом пайплайн.
README прямо подчеркивает, что успех зависит от того, насколько хорошо оператор написал промт, в самом плагине нет никаких специальных субагентов для написания тестов, их запуска или анализа результатов. Валидация через среду присутствует концептуально, но не оформлена как самостоятельный reality-check модуль. Среда здесь - источник сигналов, но не финальный арбитр. Формально встроенный оракл у плагина - это лексический стоп-критерий: точное совпадение с ожидаемой завершающей фразой + лимит итераций.
Значит, это не "верификация через среду управляет циклом", а "среда информирует модель, а хук удерживает цикл от преждевременной остановки”. Среда здесь - источник сигналов, но не финальный арбитр в коде агента.
Дальше опишу в чем проблема этого.
Критика
Зависимость тестов от промта - если какие-то особенности не будут учтены, если промт не будет содержать подробного и качественного описания тестов, проверка будет номинальной.
Проверяем (reality check) в том же проме, что и строим - отсутствие разделения контекстов ухудшает когнитивные навыки модели (некачественные тесты) и заставляет подгонять тесты под задачу.
Работает в одной сессии, решает всю задачу во внутреннем цикле, где контекст накапливается - дорого и увеличивает вероятность галлюцинации модели.
Оракул, который принимает решение о завершенности задачи и достижении критериев успеха фактически находится во внутреннем цикле и сливается с промтом, который решает задачу, и контекстом, забитым предыдущими неудачными попытками и логами - ухудшает качество принятия решений.
2. External verifier Ralph
External verifier Ralph - агент перезапускается, пока внешний верификатор не скажет “готово”. Здесь оценка выполненности выносится в отдельный блок архитектуры, а не прячется во внутреннем цикле. Это дает больше контроля и позволяет, к примеру, подтюнить логику проверки под конкретный домен на выбор: через внешний детерминированный код, структурированные проверки или даже эвалюатор на базе LLM, но с явными скорами. Хотя внутренняя верификация через среду может тоже присутствовать.
Пример
Ralph у Vercel - идеальный пример здесь: README рисует схему как внешний цикл вокруг цикла вызова тулов AI SDK Tool Loop (inner): LLM ↔ tools ↔ LLM ↔ tools ... until done. Но поверх этого он добавляет еще один слой: внешний цикл с verifyCompletion, который после каждой итерации проверяет завершенность задачи и при неуспехе инжектит фидбек в следующую итерацию. Главное архитектурное отличие Vercel - наличие явного внешнего верификационного контура.
Детали:
Внутренний цикл здесь просто выполняет те действия, которые модель считает нужными в рамках текущей попытки, используя доступные инструменты (tools). Если вы дали инструмент (tool) вроде readFile, writeFile, execute, модель может: читать файлы, менять код, запускать команды, в том числе и тесты, если это следует из системного промта и доступных инструментов. Как внутренний цикл "понимает", что пора выйти на внешнюю проверку? У Vercel нет отдельного "semantic done token" в стиле Anthropic. Логика такая:
модель делает цепочку вызова инструментов (tool calls), пока считает это полезным;
как только текущая попытка закончена с ее точки зрения либо срабатывает жесткий лимит на количество внутренних итераций - внутренний цикл останавливается.
А между внешними итерациями Vercel умеет не только передавать фидбек верификатора, но и сжимать историю вызова тулов и использовать ее на следующих шагах. Это происходит после завершения внутреннего цикла и только в случае достижения лимитов.
Критика
Проблемы, на самом деле остаются те же что и у Antropic, за исключением внешнего оракла.
Может также скатиться к тому, что вся задача решается во внутреннем цикле. Контекст во внутреннем цикле также накапливается, сжимается только во внешнем цикле - это дорого, увеличивает вероятность галлюцинации модели и даже использования тулов вопреки инстуркциям и прочим нарушениям правил. Пруфы [1], [2], [3].
Зависимость от реализации функции верификатора. Если верификатор слабый, внутренний цикл может "сделать много всего", но не обязательно действительно закрыть задачу корректно. И в целом автор не предлагает инструмента для создания верификатора. Эта задача ложится на плечи оператора. Ниже (в обсуждении Codex плагина) рассмотрим проблематику создания верификаторов.
Оракул остается во внутреннем цикле - модель сама судит что задача решена - такие суждения часто могут быть преждевременными и не соответствовать истине. Пруф: [1].
3. Artifact-evolving Ralph
Artifact-evolving Ralph - сам цикл здесь аналогичный, но между итерациями меняются части инструкций, по которым работает агент. Это отличается от двух паттернов выше: где в следующую попытку просто передается результат проверки от верификатора. Пусть верификатор в этом паттерне внешний чисто номинально, зато валидация через среду присутствует в более явном и контролируемом виде, хотя и во внутреннем цикле.
Дальше я рассмотрю разновидности реализаций таких агентов. Отличия будут в том как организована валидация через среду, куда вынесены инструменты для извлечения артефактов, какие части промта мутабельны и к чему это может привести.
Пример 1. Оригинальный Ralf loop
Начнем с того самого, оригинального Ralf loop агента Geoffrey Huntley. Его изначальная идея была не настолько примитивна, как ее более поздние интерпретации, описанные выше. Она впервые содержала мысль о том что инструкции, поступающие на вход агенту, должны меняться от итерации к итерации и должны формироваться в результате столкновения агента с реальным миром, при попытке реализовать поставленную задачу. При этом автор большую часть реализации посвятил попыткам организовать такой воркфлоу разработки, который принудит самого агента максимально тестировать свою работу.
За счет чего здесь происходит деление на внутренний и внешний цикл? Как тут дробятся задачи для внутреннего цикла? За счет того что промт включает в себя список задач и требование во внутреннем цикле работать только над одной самой важной сейчас задачей (Important Item) за этот цикл разработки.
Детали:
Состав промта
Критерии достижения успеха - “спецификации” по Huntley, формируются через длинный разговор с LLM в начале проекта, а затем записываются по файлам в specifications folder specs/*. А также подготоваливаются следующие промпты:
AGENTS.md- как технически правильно работать и проверять результат в этом проекте. Это слой валидации, он должен содержать build/test/typecheck/lint команды и вообще все, что нужно для немедленной самооценки в рамках того же цикла. То есть общий воркфлоу задается системным, а конкретные команды проверки и практические знания - черезAGENTS.md.IMPLEMENTATION_PLAN.md- список задач, приоритеты, статус и прогресс, найденные баги и открытия, новые элементы, которые надо потом реализовать. Мутации этого файла позволяют агенту не останавливаться никогда.А в системном промте
PROMPT.md/PROMPT_*- содержится дисциплина работы внутреннего цикла: прочитай specs/*. , прочитайAGENT.mdи действуй в соответствии сIMPLEMENTATION_PLAN.md. Выбери одну наиболее приоритетную задачу, закоммить только когда тесты прошли успешно, (т.е. исправлять ошибки нужно в рамках той же итерации, пока тесты не станут «зелеными»), обновиIMPLEMENTATION_PLAN.md, извлеки артефакты и выйди.
Уже заметно, что воркфлоу работы размыт по нескольким промтам. Что заметный минус с точки зрения безопасности, это вдобавок к тому что все делается во внутреннем цикле.
Формирование артефактов и мутабельность
Теперь еще раз - что меняется. По дизайну воркфлоу допускает эволюцию:
плана - агент после каждой итерации должен пометить задачу как выполненную, отметить обнаруженные проблемы/ошибки,
валидационного слоя (validation layer) - агент дополняет его при извлечении опыта в ходе работы,
и даже: критерии достижения успеха (source-of-truth specs) - если найдены несоответствия в спецификациях (агент “осознает” критерии как “недостижимые”), но после ручной проверки оператором-человеком.
У Huntley осмысление результатов проверки действительно может быть делегировано отдельному субагенту, но нет опубликованного самостоятельного "ролевого" промта. В статье это скорее внутренняя подзадача главного агента: основной контекст выступает как планировщик, запускает вспомогательного субагента для сжатия шумного вывода среды.)
Здесь с одной стороны мы выполняем “дорогую” работу в контексте субагента, чтобы не засорять основной контекст, а с другой - боремся с “протуханием контекста (contex rot) за счет суммаризации - извлечения неких артефактов из логов действий агента на каждом шаге внутреннего цикла. И этот процесс выделяет оригинальный Ralph Loop от предыдущих архитектур. Здесь Ральф заметно умнеет, эволюционируют его инструменты, его “понимание” задачи и путей её решения.
Но вместе с тем эволюция затрагивает и саму задачу. В оригинальном понимании сами критерии успеха дрифтуют (criteria drift ), Ральф может бесконечно придумывать новые подзадачи, фичи, которые можно реализовать чтобы еще и еще ближе приблизиться к некой генеральной цели. Так, если изучить репозиторий с его реализацией нового языка программирования и интерпретатора для него CURSED - он описал общую цель как “получить максимально звезд на гитхабе”. Амбициозно. Посмотрим как SpiderMan Ralph Wiggum c ней справится 🙂
Примечательно, что здесь существует еще и “ручная” эволюция - она совершается самим разработчиком, который наблюдает за работой агента и когда замечает “плохое поведение” - вручную его направляет, тюнингует Ralph, внося изменения в системный промпт (PROMPT.md/PROMPT_*). Например, если Ralph:
прыгает к нескольким задачам вместо одной,
делает неверные предположения,
использует неправильные технические паттерны,
строит вообще не то, что нужно. (пруф L116-L126)
При этом явных встроенных технических защит от переписывания системного промта самим агентом в опубликованных материалах не видно.
Оракул
Где происходит решение, что мы, наконец, завершили? В оригинальном Ральфе его нет. Для безопасности есть только ограничение на количество итераций, а решение о том, что мы добились желаемого принимаются оператором-человеком в процессе наблюдения за работой агента. Плюс есть неявное ограничение, что агент должен остановиться, когда закончатся задачи в плане. Но если критерии будут поставлены так, что мы все время будем дописывать задачи, то цикл становится бесконечным “улучшателем” решения.
Критика
Мутабельность критериев успеха - делает архитектуру не применимой для некоторых решений. Пусть даже с ручным контролем человека, но сама идея давать агенту “задумываться” о недостижимости критериев успеха и править их под себя, может привести к большим дрифтам как в безопасности, так и в качестве кода. Пруфы [1], [2], [3]. Более поздние реализации (примеры будут ниже) лишены этого дрейфа.
Извлечение артефактов вроде как в оригинале это выполняет отдельный суб-агент. Но если это будет делаться во внутреннем цикле системным промтом вместе с другими задачами могут быть не качественные выводы из-за засорения контекста (см. критику Vercel).
Мутабельность воркфлоу работы и валидации через среду - не безопасно. Пруф [1], [2].
Воркфлоу работы размыт по нескольким промтам - заметный минус с точки зрения безопасности. Пруфы [1], [2], [3].
Верификатор через среду во внутреннем цикле - зависит только от правильных промтов и того, что агент их сам не поменяет - риск безопасности и некачественных выводов. Пруф [1].
“Human-in-the-loop” как оракл - здесь делает агент не автономным и ограничивает применимость архитектуры.
Пример 2 и 3. Плагин Cursor и реализация Snarktank
В то же время реализация [Cursor плагина Singh (доп. описание есть в статье Gekov) и еще одна реализация Snarktank являются более формализованым вариантом того же семейства. Тут есть попытка автоматизировать контроль за счет нескольких типов проверок, но также часть ответственности за проверку остается во внутреннем цикле, потому что ожидаемый результат все также описывается человеком при постановке задачи.
Детали:
Формально обе реализации не предусматривают ручное изменение системного промта, не предусматривают изменение критериев успеха, но обе грешат тем, что позволяют переписывать файл, в котором критерии указаны. Пусть и с целью пометить выполнимость, но это, конечно же, максимально уязвимая реализация.
Оракул пытается тут стать внешним, проверяя сигнал COMPLETE в ответе агента, а у Cursor дополнительно скрипт сверяет количество чекбоксов отмеченных [x]. Валидация через среду диктуется промптами, но воркфлоу тоже сильно размыт. У Cursor в системном промте общее требование - тестировать любые изменения, сами тесты описаны в RALPH_TASK.md (изменяемый агентом), а инфраструктура только исполняет и контролирует. У Snarktank в prompt.md (системном промте) сидит более подробная рамка проверки, а конкретные проверки по задачам сидят в prd.json и acceptance criteria (изменяемые агентом).
В реальности мы пробуем валидироваться через среду во внутреннем цикле, модель решает остановиться сама, а дальше внешний номинальный верификатор подтверждает останов путем лексической проверки вывода модели. Не смотря на схожесть c Anthropic, тут мы не делаем всю работу во внутреннем цикле в одной бесконечной сессии, а работаем над одной задачей в одном внутреннем цикле.
Критика
Благодаря доработкам, отсутствует вероятность дрейфа критериев успешности в рамках нормальной работы агента, но не предусмотрены меры безопасности в случае несанкционированных попыток переписать критерии. А вероятноcть такого поведения агента высока. Пруф: [1].
Воркфлоу работы четче чем в оригинальном исполнении, но мутабелен, так же как и в оригинальном Ralph Loop.
Остальные недостатки те же, что и у оригинального агента, за исключением того, что оракл выхода из цикла здесь не человек, а сама модель как у Anthropic. Это делает агента автономным, в отличие от оригинала, но не безопасным. Т.к. сохраняются те же проблемы что и у Anthropic (см. критику)
4. Artifact-evolving Ralph with external verifier
Есть и более строгая разновидность artifact-evolving Ralph. В ней внешний слой артефактов все еще эволюционирует между итерациями, но право объявить успех уже не оставлено ни модели, ни изменяемому файлу с критериями и статусом задачи. Оно вынесено в отдельный программный валидатор и оракул. За счет этого валидация через среду отделена от внутреннего цикла и это заметно повышает безопасность архитектуры. Кроме того есть жесткое разделение между:
критериями успеха (specs) - что именно считается правильным результатом,
исполнением (runtime) - очередной попыткой агента реализовать одну задачу,
проверкой (verification)- внешней командой, которая решает, соответствует ли результат критериям.
Пример. Codex плагин
Именно так устроен Codex плагин от JH427: системный промт собирается программно перед каждой итерацией и включает в себя обновленные артефакты - за счет этого оркестрация агента защищена от несанкционированного переписывания им самим. Попытки “побега из песочницы” возможны путем внесения инъекций в изменяемые части, но это отдельный разговор. При этом сам оркестрационный шаблон промпта хранится в ralph.py, а не в маркдаун файле, и по смыслу считается human-owned, хотя технически не защищен полностью от изменения, но усилить защиту тут гораздо легче.
Детали:
Состав промта
Как и в других архитектурах, системный промт задает общую дисциплину и порядок работы внутреннего цикла: взять ровно одну нерешенную задачу, реализовать только ее, не рефакторить лишнее, при необходимости дописать справочные заметки в learnings.md, и если задача завершена, вывести ровно DONE. Но это уже не тот случай, где воркфлоу размазан по нескольким текстовым файлам и может медленно дрейфовать.
Формирование артефактов и мутабельность. Критерии успеха.
Архитектурно это интересный гибрид. От artifact-evolving Ralph здесь остается накопление знаний и артефактов, но в их число не входят “критерии успеха/качества/достижения результата”. Если в оригинальном Ральф-агенте можно дописывать новые критерии без конца, а в более формальных интерпретациях это запрещено и список конечен, но нет никакой физической защиты, кроме указаний в системном промте, то у этого Codex плагина реализована принудительная проверка модификаций. Если внешний верификатор после завершения внутреннего цикла работы агента обнаружит добавление новой задачи или изменение критериев - включается откат состояния через гит и выполнение останавливается. Таким образом, агент может двигаться только внутри фиксированного пространства задач и требований, но не имеет возможности расширять или подменять сами критерии успеха, что принципиально снижает риск дрейфа критериев и "подгонки задачи под решение".
Верификатор
Итак. Ключевое отличие этой реализации - наличие внешнего проверяющего контура в строгом смысле. Решение о том, считать ли шаг успешным, принимается не по текстовому отчету модели, а по результату отдельной проверки в среде: успешно ли прошли компиляция, тесты и другие заданные условия.
И тут изюминка безопасности: кроме прогона тестов, валидатор последовательно смотрит, не нарушен ли режим "только добавления" для накопленных наблюдений, допустимо ли изменено состояние задачи и действительно ли выбранный элемент плана переведен в состояние успеха. Только если все эти условия выполнены одновременно, результат фиксируется. В противном случае, при любом несовпадении - изменения отбрасываются, и цикл переходит к следующей попытке.
Оракул
С точки зрения устройства/дизайна оракула это одна из наиболее чистых Ralph-like реализаций. Модель здесь не может сама объявить задачу успешно завершенной. Она может лишь подать локальный сигнал, что считает работу законченной, но этого недостаточно. Условие остановки в такой схеме двухуровневое: на уровне отдельной итерации требуется корректное обновление артефактов и успешное прохождение внешней проверки; на уровне всего цикла завершение наступает только тогда, когда тем же внешним контуром подтверждено выполнение критериев успеха по задаче в целом.
Само наличие отдельного валидатора как у Vercel, тоже является неким “правИлом”, которое задает направление эволюции кода, ведь агент, сталкиваясь с фидбеком от верификатора будет пытаться подстроиться под “зашитые” в его тестах критерии. Но в основном это будет эволюция через отбор, а не через явное обучение. Верификатор не столько "объясняет" агенту, как нужно работать дальше, сколько отсекает невалидные состояния и оставляет выживать только те изменения, которые проходят внешнюю проверку. И это, к сожалению, слабая часть этой конкретной реализации. У всех реализаций artifact-evolving Ralph интерпретаторы знаний, извлекающие артефакты из фидбека более умные - подробный разбор будет ниже. Однако можно модифицировать эту конкретную реализацию более интеллектуальным субагентом, суммаризующим выход тестов, поэтому не будем здесь заострять фокус.
Критика
Зависимость от внешнего валидатора - дрифт критериев успеха, агент подстраивается под валидатор. Пруфы: [1], [2], [3], [4].
Нет физической защиты от мутабельности валидатора - не безопасно, вероятен “побег из песочницы”. Пруфы: [1], [2]. Но решается, путем добавления доп.проверки, так как валидатор выделен в отдельный объект.
Остается риск переписывания системного промта через мутирующие артефакты. Пруфы [1], [2]. Но решается инструкциями в системный промт игнорировать инъекции или противоречащие требования из артефактов.
Извлечение артефактов. Сравнение artifact-evolving агентов.
Почему последние два архитектурных паттерна названы эволюционирующими? И чем они отличаются от Anthropic плагина - и реализации Vercel? Тем, как агент “умнеет” от взаимодействия со средой.
Почему вообще Huntley назвал его Ральфом? Что общего с героем из Симпсонов? Просто процитирую автора:
Вольный перевод: Ральф приходит на детскую площадку и прыгает с горки - ударяется. В следующий раз он пытается сбежать с горки - падает. В третий раз он съезжает с горки и оставляет рядом с ней табличку: с горки надо съезжать. Когда он в другой день пойдет гулять на детскую площадку, благодаря табличке он будет только скатываться с горки и не будет повреждаться.
Примеры
У Huntley после проходки не просто сохраняется факт ошибки, а извлекается знание о том, где именно сидит проблема - в задаче, проверке, рабочем процессе или даже в самих спецификациях - и это знание перераспределяется по куче артефактов.
У Cursor плагина есть явное разделение между логами и извлеченным знанием что именно пошло не так и как не повторить ошибку. Но важно, что глубина этого "понимания" ограничена. Парсер сам распознает в основном паттерны инфраструктурного уровня: повторяющиеся ошибки, дерганье одного и того же файла, лимиты запросов. А вот более глубокий анализ причин либо делает сам агент при записи guardrail, либо человек вручную.
Да, агент может делать осмысленную интерпретацию ошибки и извлекать уроки. Но по опубликованным материалам это выглядит скорее как прагматическая интерпретация провала и суммаризация, а не как сильный, систематический анализ причин.
Snarktank тоже довольно явно делает суммаризацию: агенту предписано не просто вести журнал, а дописывать: знания для будущих итераций, обнаруженные паттерны, обнаруженные подводные камни, полезный контекст.
Дальше еще сильнее: если найден переиспользуемый паттерн, его нужно вынести в отдельную секцию; а если открылись по-настоящему переиспользуемые знания по конкретным директориям, их нужно вынести еще и в артефакты верификации и тестирования. Там же перечислены примеры: зависимости между файлами, подходы к тестированию, требования к конфигурации, неочевидные требования. Это уже явная выжимка знания после итерации, а не просто сырой лог.
Пусть знание здесь менее "диагностическое", чем у Cursor, но более похоже на сознательную операционную суммаризацию.
В ralph-codex, увы, после проходки может сохраниться только узкое фактическое наблюдение, но без полноценной архитектуры суммаризации и анализа причин. те.если по остальной части архитектуры мы видим явное развитие, то в части эволюции артефактов - явную деградацию.
Здесь мы приходим к важной философской мысли, что верификатор формирует конечный результат и иногда даже больше, чем какие-то вербально-описанные критерии.
5. Self-evolving agent
Как следует из названия, self-evolving agent - еще близкий, но уже отдельный родственник в этом семействе. Здесь мы рассмотрим вариант архитектуры, который после OpenClaw уже, конечно не может напугать своей автономностью и самостоятельностью, но близок к тому.
Почему? Как видно из таблицы 1, мы ожидаем здесь полной мутабельности: агент может переписывать системный промт, может переписывать план работы, свои инструменты, любые критерии успеха, где бы они ни были записаны. И это делается во внешнем цикле относительно основного агента. Тут нам сложно в полной мере назвать эту архитектуру Ralph loop, где в цикле живет один системный промт = главный агент.
Потому что для безопасной реализации само-развивающегося агента нам нужна связка как минимум из четырех агентов в цикле: агент-решатель, агент-верификатор, агент-анализатор, и агент-модификатор.
Первый решает задачу. Второй пишет под нее тесты и запускает их. Третий анализирует и делает глубокие выводы причин ошибок. Четвертый - модифицирует первый агент (его промт, тулзы и тп.) так, чтобы сделать его более приспособленным к выполнению задачи.
Выглядит неустойчиво? Абсолютно верно. Но по задумке максимально близко к оригинальной идее Ralph loop и еще и без тормозов-ограничений в виде человека. Теперь звучит еще хуже, однако эта система становится просто невероятно-рабочей, если неизменяемым станет верификатор. Тоесть или тесты уже будут написаны и проверены человеком, или мы будем заранее знать правильные ответы (бенчмарк) или будет некая иная петля обратной связи с реальностью. Не агент, который может лгать, прикидываться и подкучивать тесты, а нечто неизменяемое. Среда, реальность, бенчмарк. И тогда мы можем переписывать агента-решателя без помощи человека извне, без присмотра, но и без риска “уплыть” не в ту сторону. Да это сужает применимость. Но потребность в таких решениях есть. Увы, вероятно это не кодинговые агенты, если только наша цель не скопировать уже готовое решение.
Пример. Claude's sequential evolution
Agent-evolution loop на бенчмарке, решение-победитель на осеннем Enterprise RAG Challenge ( @aostrikov claude sequential evolution (описание в выпадающем поле) у которого: Main Agent получает и решает набор задач из бенчмарка, Analyzer Agent разбирает провалы, Versioner Agent выпускает новую версию системного промта, и так по кругу. Здесь верификатор - это платформа, которая возвращает 0 или 1 за правильно или не правильно решенную задачу.
Критика
Высокая автономность - высокая вероятность переобучения агента, когда он запоминает правильные ответы, вместо того чобы "осознавать" и выводить генерализованные правила или иным способом вламывает петлю обратной связи с верификатором.
Оптимизация под бенчмарк вместо устойчивого агента - система эволюционирует под score платформы и ее форматные особенности, а не только под смысл задачи. Здесь мы зависим от качества бенчмарка.
Если агент может переписывать сам себя, его уязвимость к взлому ведет к намного более высоким рискам безопасности, чем взлом не эволюционирующих агентов. Высок размера ущерба, который он может нанести до того как его измененное поведение заметят.
Длинные цепочки размышлений ведут к накоплению локальных патчей и деградации интерпретируемости.
Итог
Отсюда, собственно, и мой основной вывод.
Когда кто-то говорит “давайте заюзаем Ральф луп”, моя первая реакция теперь такая: какой именно Ralph? Обертка с хуком остановки? Баш луп с внешним верификатором, где агент продолжает переписывать артефакты, которые формируют его следующий запуск? А может вообще имеется в виду agent-evolution loop, где бенчмарк не просто оценивает задачу, а постепенно переписывает самого решателя?
Итоговый дизайн-чек лист вопросов, которые стоит задать себе до того, как начать строить Ralph-like архитектуру:
Кто оракл?
Где живут критерии завершения - в промте, в коде верификатора, в бенчмарке, в тестах или в человеке?
Что именно переносится между итерациями - сырой вывод, фидбек верификатора, дистилляция правил, плана решения или глубокий анализ причин и следствий неуспеха?
Что имеет право мутировать - почти ничего, поверхность промта, инструменты, политики, план, системный промт, все кроме критериев?
Это execution loop или evolution loop?
И подходит ли вообще эта схема для среды, в которой у вас нет дешевого машино-проверяемого (machine-checkable) фидбека?
И самое главное: какие ваши трейд-оффы (trade-off), какие слабые места и уязвимости этих архитектурных паттернов вы хотите избежать? Тогда разговор "ну это же Ralph" не заканчивается на уровне костюма Человека-паука, и мы уже начинаем смотреть: как он делает свою паутину, какая дополнительная опора используется для движения, меняется ли у него только маршрут - или сам он тоже мутирует по ходу дела?
Интересно, что ответив эти вопросы по-своему, можно создать своего Ральфа, свою уникальную вселенную архитектуру, используя свои правила и источник истины верификации.
P.S. Под кат ушел разбор деталей, чтобы не пререгружать статью.
