Споры вокруг понятия "Ralph loop" всё чаще напоминают сцену из Spider-Verse: все говорят об одном и том же, но каждый уверен, что именно его версия — настоящая. На деле под этим термином скрываются разные архитектуры, а иногда и противоположные подходы. Пора разобраться, что есть что.

Что общего у всех Ralph-подобных циклов?

На первый взгляд все реализации похожи: есть цикл, борьба с "протуханием" контекста (context rot), критерии успеха и верификатор — "погонщик" цикла. Но при ближайшем рассмотрении различия становятся критичными.

Ключевые различия:

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

Верификатор и оракул: в чём разница?

Верификатор — технический механизм проверки: запуск тестов, линтеров, API. Он отвечает за сигнал "приблизились ли мы к цели?" Без него итерационный цикл превращается в самообман.

Оракул — источник истины о том, решена ли задача. Это может быть человек, бенчмарк, платформа или среда. Верификатор — лишь способ получить доступ к оракулу.

Например: запуск тестов — верификатор, интерпретация их результатов — оракул. Бенчмарк — оракул, а evaluation pipeline — способ его вычисления.

Системный промпт и артефакты

Системный промпт задаёт роль агента, его ограничения, приоритеты и формат сигнала о завершении. Он может быть зашит в код, собираться программно или комбинироваться с внешними артефактами.

Артефакты — внешние объекты, сохраняемые между итерациями: сжатые логи, правила, знания, извлечённые из анализа предыдущих шагов.

1. Same-prompt Ralph

Один и тот же промпт перезапускается, пока модель не скажет "готово", а внешняя проверка не подтвердит ожидаемый токен. Управление циклом формально внешнее, но решение о завершении — внутри модели.

Пример: плагин Ralph у Anthropic. Claude работает над задачей, хук перехватывает выход и перезапускает промпт до появления "DONE" или лимита итераций.

Проблемы:

1. Зависимость проверки от качества промта: если тесты не описаны детально, проверка номинальна.
2. Проверка и построение в одном контексте: модель подгоняет тесты под задачу, снижая когнитивные навыки.
3. Работа в одной сессии: контекст накапливается, растёт стоимость и риск галлюцинаций.
4. Оракул внутри цикла: решение о завершении принимает перегруженная модель, что ухудшает качество.

2. External verifier Ralph

Агент перезапускается, пока внешний верификатор не скажет "готово". Проверка вынесена в отдельный блок, что даёт больше контроля.

Пример: Ralph у Vercel. Внешний цикл с verifyCompletion проверяет результат после каждой итерации и при неудаче передаёт фидбек. Внутренний цикл использует инструменты (tools) до лимита или до "семантической готовности".

Проблемы:

1. Вся задача может решаться во внутреннем цикле с накоплением контекста.
2. Качество зависит от реализации верификатора: слабый — не гарантирует корректного решения.
3. Оракул остаётся внутри: модель сама решает, что задача решена, что часто ложно.

3. Artifact-evolving Ralph

Между итерациями меняются части инструкций. Цикл аналогичен предыдущим, но артефакты эволюционируют.

Пример 1. Оригинальный Ralph loop (Geoffrey Huntley)

Инструкции меняются от итерации к итерации на основе взаимодействия с реальностью. Промт включает:

• AGENTS.md — команды проверки (build/test/lint).
• IMPLEMENTATION_PLAN.md — задачи, статус, баги, открытия.
• PROMPT.md — дисциплина: работать над одной задачей, тесты должны проходить, обновить план, выйти.

Агент может эволюционировать:

• План — помечает задачи, добавляет проблемы.
• Слой валидации — дополняет правила проверки.
• Критерии успеха — при несоответствии спецификациям, после ручной проверки оператором.

Проблемы:

1. Мутабельность критериев — риск дрейфа, особенно в безопасности и качестве кода.
2. Извлечение артефактов во внутреннем цикле — контекст засорён, выводы некачественные.
3. Мутабельность воркфлоу — небезопасно.
4. Воркфлоу размыт по файлам — минус для безопасности.
5. Верификатор во внутреннем цикле — зависит от промта, риск подмены.
6. Человек как оракул — агент не автономен.

Пример 2 и 3. Плагин Cursor и реализация Snarktank

Более формализованные версии. Не меняют критерии успеха, но позволяют переписывать файлы с ними — уязвимо.

Оракул пытается стать внешним: проверяет сигнал "COMPLETE" или количество чекбоксов. Валидация через среду — по промтам, но воркфлоу размыт.

Преимущества:

• Нет дрейфа критериев при нормальной работе.
• Работает над одной задачей за итерацию, не в бесконечной сессии.

Недостатки:

1. Нет защиты от несанкционированного переписывания критериев.
2. Воркфлоу мутабелен.
3. Оракл — модель, как у Anthropic: автономно, но небезопасно.

4. Artifact-evolving Ralph with external verifier

Эволюция артефактов, но право на успех — у внешнего валидатора. Валидация отделена от внутреннего цикла, повышая безопасность.

Чёткое разделение:

• Критерии успеха (specs) — что считается правильным.
• Исполнение (runtime) — попытка реализовать задачу.
• Проверка (verification) — внешняя команда решает, соответствует ли результат.

Пример. Codex плагин (JH427)

Системный промт собирается программно, включая обновлённые артефакты. Оркестрация защищена от переписывания агентом.

Ключевое отличие — внешний проверяющий контур. Решение о успехе — не по отчёту модели, а по результату проверки: компиляция, тесты и др.

Безопасность: валидатор проверяет, не нарушен ли режим "только добавления", корректно ли изменён статус задачи. При несовпадении — откат через git.

Оракул — один из самых чистых: модель не может сама объявить задачу завершённой. Условие остановки двухуровневое:

• Итерация: обновление артефактов + прохождение проверки.
• Цикл: внешний контур подтверждает выполнение критериев.

Недостатки:

1. Агент подстраивается под валидатор — дрифт критериев.
2. Нет физической защиты от мутации валидатора — риск "побега из песочницы".
3. Риск переписывания системного промта через артефакты — решается инструкциями игнорировать инъекции.

Извлечение артефактов: сравнение

Почему Huntley назвал его Ральфом? По аналогии с героем из Симпсонов: Ральф падает с горки, ставит табличку "съезжать", и в следующий раз не падает. Он извлекает знание и оставляет его на будущее.

У разных реализаций разная глубина извлечения:

• Huntley: знание распределяется по артефактам — задачи, проверки, спецификации.
• Cursor: парсер распознаёт инфраструктурные паттерны, но глубокий анализ — на агенте или человеке.
• Snarktank: агент дописывает знания, паттерны, подводные камни, выносит переиспользуемое в артефакты верификации.
• Codex: сохраняется только узкое наблюдение, без анализа причин — деградация в части эволюции.

Верификатор формирует результат даже сильнее, чем вербальные критерии.

5. Self-evolving agent

Агент может переписывать системный промт, план, инструменты, критерии — во внешнем цикле. Это уже не просто Ralph loop, а отдельный родственник.

Для безопасности нужна связка из четырёх агентов:

• Решатель — выполняет задачу.
• Верификатор — пишет и запускает тесты.
• Анализатор — глубоко анализирует ошибки.
• Модификатор — меняет решателя для лучшей адаптации.

Система неустойчива, но становится рабочей, если верификатор неизменяем: бенчмарк, реальность, платформа с 0/1.

Пример. Claude's sequential evolution

Победитель Enterprise RAG Challenge: Main Agent решает задачи, Analyzer разбирает провалы, Versioner выпускает новую версию промта. Верификатор — платформа, возвращающая 0 или 1.

Риски:

1. Переобучение: агент запоминает ответы, а не обобщает.
2. Оптимизация под бенчмарк, а не под суть задачи.
3. Высокий риск безопасности при самопереписывании.
4. Деградация интерпретируемости из-за накопления патчей.

Итог: как строить Ralph-like архитектуру?

Прежде чем говорить "давайте сделаем Ralph loop", задайте себе вопросы:

1. Кто оракул?
2. Где живут критерии завершения — в промте, коде, бенчмарке, тестах или человеке?
3. Что переносится между итерациями — логи, фидбек, правила, план, анализ причин?
4. Что может мутировать — ничего, промт, инструменты, план, всё?
5. Это execution loop или evolution loop?
6. Подходит ли схема без дешёвого машино-проверяемого фидбека?

И главное: какие trade-off и уязвимости вы хотите избежать? Только тогда разговор перестанет быть о костюме Человека-паука и начнётся о том, как он делает паутину, как движется и мутирует ли сам по ходу дела.

Ответив на эти вопросы, можно создать своего Ральфа — свою уникальную вселенную архитектуры с собственными правилами и источниками истины.

Все началось с довольно прикладного спора с коллегой об одном агентном решении. Мы не могли сойтись во мнении, что именно вообще стоит называть 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 модуль. Среда здесь - источник сигналов, но не финальный арбитр. Формально встроенный оракл у плагина - это лексический стоп-критерий: точное совпадение с ожидаемой завершающей фразой + лимит итераций.

Значит, это не "верификация через среду управляет циклом", а "среда информирует модель, а хук удерживает цикл от преждевременной остановки”. Среда здесь - источник сигналов, но не финальный арбитр в коде агента.

Дальше опишу в чем проблема этого.

1. Зависимость тестов от промта - если какие-то особенности не будут учтены, если промт не будет содержать подробного и качественного описания тестов, проверка будет номинальной.
2. Проверяем (reality check) в том же проме, что и строим - отсутствие разделения контекстов ухудшает когнитивные навыки модели (некачественные тесты) и заставляет подгонять тесты под задачу.
3. Работает в одной сессии, решает всю задачу во внутреннем цикле, где контекст накапливается - дорого и увеличивает вероятность галлюцинации модели.
4. Оракул, который принимает решение о завершенности задачи и достижении критериев успеха фактически находится во внутреннем цикле и сливается с промтом, который решает задачу, и контекстом, забитым предыдущими неудачными попытками и логами - ухудшает качество принятия решений.

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. Логика такая:

1. модель делает цепочку вызова инструментов (tool calls), пока считает это полезным;
2. как только текущая попытка закончена с ее точки зрения  либо срабатывает жесткий лимит на количество внутренних итераций  - внутренний цикл останавливается.

А между внешними итерациямиVercelумеет не только передавать фидбек верификатора, но и сжимать историю вызова тулов и использовать ее на следующих шагах. Это происходит после завершения внутреннего цикла и только в случае достижения лимитов.

Проблемы, на самом деле остаются те же что и у Antropic, за исключением внешнего оракла.

1. Может также скатиться  к тому, что вся задача решается во внутреннем цикле. Контекст во внутреннем цикле также накапливается, сжимается только во внешнем цикле - это дорого, увеличивает вероятность галлюцинации модели и даже использования тулов вопреки инстуркциям и прочим нарушениям правил. Пруфы[1],[2],[3].
2. Зависимость от реализации функции верификатора. Если верификатор слабый, внутренний цикл может "сделать много всего", но не обязательно действительно закрыть задачу корректно. И в целом автор не предлагает инструмента для создания верификатора. Эта задача ложится на плечи оператора. Ниже (в обсуждении Codex плагина) рассмотрим проблематику создания верификаторов.
3. Оракул остается во внутреннем цикле - модель сама судит что задача решена - такие суждения часто могут быть преждевременными и не соответствовать истине. Пруф:[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- он описал общую цель как “получить максимально звезд на гитхабе”. Амбициозно. Посмотрим какSpiderManRalph Wiggum c ней справится 🙂

Примечательно, что здесь существует еще и “ручная” эволюция - она совершается самим разработчиком, который наблюдает за работой агента и когда замечает “плохое поведение” - вручную его направляет,тюнингует Ralph,внося изменения в системный промпт  (PROMPT.md/PROMPT_*).  Например, если Ralph:

• прыгает к нескольким задачам вместо одной,
• делает неверные предположения,
• использует неправильные технические паттерны,
• строит вообще не то, что нужно. (пруфL116-L126)

При этом явных встроенных технических защит от переписывания системного промта самим агентом в опубликованных материалах не видно.

Где происходит решение, что мы, наконец, завершили? В оригинальном Ральфе его нет. Для безопасности есть только ограничение на количество итераций, а решение о том, что мы добились желаемого принимаются оператором-человеком в процессе наблюдения за работой агента. Плюс есть неявное ограничение, что агент должен остановиться, когда закончатся задачи в плане. Но если критерии будут поставлены так, что мы все время будем дописывать задачи, то цикл становится бесконечным “улучшателем” решения.

1. Мутабельность критериев успеха -делает архитектуру не применимой для некоторых решений. Пусть даже с ручным контролем человека, но сама идея давать агенту “задумываться” о недостижимости критериев успеха и править их под себя, может привести к большим дрифтам как в безопасности, так и в качестве кода. Пруфы[1],[2],[3]. Более поздние реализации (примеры будут ниже) лишены этого дрейфа.
2. Извлечение артефактоввроде как в оригинале это выполняет отдельный суб-агент.Но если это будет делаться во внутреннем циклесистемным промтом вместе с другими задачами могут бытьне качественные выводы из-за засорения контекста (см. критику Vercel).
3. Мутабельность воркфлоу работы и валидации через среду -не безопасно. Пруф[1],[2].
4. Воркфлоу работы размыт по нескольким промтам- заметный минус с точки зрения безопасности. Пруфы[1],[2],[3].
5. Верификатор через среду во внутреннем цикле- зависит только от правильных промтов и того, что агент их сам не поменяет - риск безопасности и некачественных выводов. Пруф[1].
6. “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 (изменяемые агентом).

В реальности мы пробуем валидироваться через среду во внутреннем цикле, модель решает остановиться сама, а дальше внешний номинальный верификатор подтверждает останов путем лексической проверки вывода модели. Не смотря на схожесть cAnthropic, тут мы не делаем всю работу во внутреннем цикле в одной бесконечной сессии, а работаем над одной задачей в одном внутреннем цикле.

1. Благодаря доработкам, отсутствует вероятность дрейфа критериев успешности в рамках нормальной работы агента, но не предусмотрены меры безопасности в случае несанкционированных попыток переписать критерии. А вероятноcть такого поведения агента высока. Пруф:[1].
2. Воркфлоу работы четче чем в оригинальном исполнении,но мутабелен, так же как и в оригинальном Ralph Loop.
3. Остальные недостатки те же, что и у оригинального агента, за исключением того, что оракл выхода из цикла здесь не человек, а сама модель как у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. Зависимость от внешнего валидатора- дрифт критериев успеха, агент подстраивается под валидатор. Пруфы:[1],[2],[3],[4].
2. Нет физической защиты от мутабельности валидатора -не безопасно, вероятен  “побег из песочницы”. Пруфы:[1],[2]. Но решается, путем добавления доп.проверки, так как валидатор выделен в отдельный объект.
3. Остается риск переписывания системного промта через мутирующие артефакты.Пруфы[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 за правильно или не правильно решенную задачу.

1. Высокая автономность - высокая вероятность переобучения агента, когда он запоминает правильные ответы, вместо того чобы "осознавать" и выводить генерализованные правила или иным способом вламывает петлю обратной связи с верификатором.
2. Оптимизация под бенчмарк вместо устойчивого агента - система эволюционирует под score платформы и ее форматные особенности, а не только под смысл задачи. Здесь мы зависим от качества бенчмарка.
3. Если агент может переписывать сам себя, его уязвимость к взлому ведет к намного более высоким рискам безопасности, чем взлом не эволюционирующих агентов. Высок размера ущерба, который он может нанести до того как его измененное поведение заметят.
4. Длинные цепочки размышлений ведут к накоплению локальных патчей и деградации интерпретируемости.

Отсюда, собственно, и мой основной вывод.

Когда кто-то говорит “давайте заюзаем Ральф луп”, моя первая реакция теперь такая: какой именно Ralph? Обертка с хуком остановки? Баш луп с внешним верификатором, где агент продолжает переписывать артефакты, которые формируют его следующий запуск? А может вообще имеется в виду agent-evolution loop, где бенчмарк не просто оценивает задачу, а постепенно переписывает самого решателя?

Итоговый дизайн-чек лист вопросов, которые стоит задать себе до того, как начать строить Ralph-like архитектуру:

1. Кто оракл?
2. Где живут критерии завершения - в промте, в коде верификатора, в бенчмарке, в тестах или в человеке?
3. Что именно переносится между итерациями - сырой вывод, фидбек верификатора, дистилляция правил, плана решения или глубокий анализ причин и следствий неуспеха?
4. Что имеет право мутировать - почти ничего, поверхность промта, инструменты, политики, план, системный промт, все кроме критериев?
5. Это execution loop или evolution loop?
6. И подходит ли вообще эта схема для среды, в которой у вас нет дешевого машино-проверяемого (machine-checkable) фидбека?

И самое главное: какие ваши трейд-оффы (trade-off), какие слабые места и уязвимости этих архитектурных паттернов вы хотите избежать? Тогда разговор "ну это же Ralph" не заканчивается на уровне костюма Человека-паука, и мы уже начинаем смотреть: как он делает свою паутину, какая дополнительная опора используется для движения, меняется ли у него только маршрут - или сам он тоже мутирует по ходу дела?

Интересно, что ответив эти вопросы по-своему, можно создать своего Ральфа, свою уникальнуювселеннуюархитектуру, используя свои правила и источникистиныверификации.