Вам нужно больше, чем просто Ralph Loop
@ai_longreadsПочему долгоиграющие агенты в формате простого цикла работают плохо, и как выстроить собственный воркфлоу с планированием, мультиагентной архитектурой и межконтекстной памятью, чтобы получать по-настоящему качественные результаты.
Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.
Вам нужно больше, чем просто Ralph Loop
You Need More Than a Ralph Loop Автор: Jarrod Watts Оригинальный текст:
За последние несколько месяцев я экспериментировал с долгоиграющими агентами в рамках различных побочных проектов, включая прохождение найма в Anthropic.
Я пришёл к пониманию того, что причина, по которой «долгоиграющие агенты» работают — это буквально то, что они тратят больше токенов (токены). Или, если вы исследователь — они «масштабируют вычисления на этапе инференса (inference)».
Это может звучать глупо, но на самом деле работает — например, на бенчмарке (benchmark) BrowseComp, Sonnet 4.6, потративший в 10 раз больше токенов, показал результат примерно на 10 процентных пунктов выше.
Однако это начинает давать сбои, когда ваша задача требует значительно больше контекста, чем может вместить контекстное окно (context window) агента...
Для решения этой проблемы ранее в этом году появились такие вещи, как Ralph Wiggum Loop, который в своей первоначальной форме представляет собой просто повторный запуск одного и того же промпта в цикле.
На прошлой неделе команда Codex выпустила goals — встроенную систему для долгоиграющих агентов, способных работать днями ради достижения вашей цели.
Я был невероятно воодушевлён этим, но оказался довольно разочарован результатами, которые получил, несмотря на мою любовь к GPT 5.5!
Поскольку Codex полностью имеет открытый исходный код, мы можем точно увидеть, как он работает под капотом — я именно это и сделал, и вот что я узнал и почему считаю, что мой собственный воркфлоу для долгоиграющих агентов лучше.
Как работают Codex Goals
Если вы ещё не пробовали, функция goal пытается выполнить ваши более амбициозные задачи за один подход, работая часами или даже днями, путём ввода /goal <ваша цель> в CLI Codex.
Под капотом функция goals использует простую настройку SQLite — Codex создаёт таблицу thread_goals для хранения каждой новой цели в виде строки; каждая из которых содержит описание цели, id, статус и опциональный бюджет токенов.
Когда Codex начинает работу над достижением вашей цели, он использует новые инструменты, включая get_goal и update_goal, для учёта прогресса и обновления статуса цели в базе данных.
После этого Codex использует довольно стандартный Ralph Loop (повторяя один и тот же промпт снова и снова) с примерно таким промптом:
Continue working toward the active thread goal. <untrusted_objective> Ship the benchmark article with real Goal-mode evidence. </untrusted_objective> Budget: - Time spent pursuing goal: XX seconds - Tokens used: XX - Token budget: XX - Tokens remaining: XX Before deciding that the goal is achieved, perform a completion audit against the actual current state.
Это решает раздражающую проблему остановки Codex каждые 15 минут с вопросом, можно ли продолжать, но я не считаю это эффективным способом запуска агентов на длительные периоды времени.
Чего, на мой взгляд, не хватает /goal
Мне абсолютно нравится идея долгоиграющих агентов — это ближайшее, что у нас есть к реалистичному достижению цели заставить агентов действительно «построить B2B SaaS с MRR в 1 млн, без ошибок».
Но мой опыт использования функции /goal в Codex оказался довольно разочаровывающим — с теми же недостатками, которые я обнаружил при создании множества собственных неудачных воркфлоу для долгоиграющих агентов.
Я пришёл к такому выводу по трём основным причинам:
- Неопределённость накапливается
- Мультиагентное превосходство
- Межконтекстная память работает
Я усвоил эти уроки за последние несколько месяцев, и ниже поделюсь подробностями, а также воркфлоу, к которому пришёл и который мне действительно нравится.
Неопределённость накапливается
Запуск LLM в цикле означает, что выходные данные каждой итерации становятся входными данными следующей — и это оказывает кумулятивный эффект на каждую последующую итерацию.
Модель принимает бесчисленное количество решений, когда вы просите её построить что-то от начала до конца, и в какой-то момент она обычно принимает решение, которое вы бы не приняли — и вся последующая работа может уйти в неверном направлении.
Это ничем не отличается от реальной жизни — если вы попросите кого-то другого построить что-то с расплывчатыми требованиями, вы, скорее всего, не получите то, что себе представляли, когда нет возможности для обратной связи.
Поскольку у ИИ, похоже, пока нет вкуса, очень сложно избежать такого развития событий — если только вы не пишете чрезвычайно детальные промпты, чтобы максимально сократить пространство для ошибок.
В моей собственной стратегии долгоиграющих агентов я использую вариацию скилла «/interview» для максимального снижения неопределённости, который очень похож на скилл «grill-me» Мэтта Покока.
Я делаю это на «этапе подготовки», прежде чем позволить агентам запускать какой-либо код. Я вкладываюсь на начальном этапе, где взаимодействие с пользователем действительно происходит — до начала любого автономного цикла агента.
После этого довольно строгого процесса цель, которая теперь стала достаточно конкретной и детальной, разбивается на вехи, состоящие из отдельных задач.
По моему опыту, этот этап ОЧЕНЬ, очень, ОЧЕНЬ важен — он заставляет ВАС (не только агента) задуматься: «а что именно я на самом деле здесь хочу?».
Практически каждый раз, когда я провожу этот этап, Codex задаёт мне вопросы и поднимает допущения, о которых я даже не задумывался, но которые оказываются удивительно важными деталями, о которых стоит подумать и принять решения заранее.
Я визуализирую полезность этого шага как дерево возможных исходов, где каждая ветвь — это решение, которое нужно принять, чтобы прийти к конечному результату.
Без предварительного уточнения ваш агент сам принимает эти решения, что оставляет вас с одним результатом из почти бесконечного числа возможных, который может лишь отдалённо напоминать то, что вы запрашивали.
В то время как дополнительное время, потраченное на подготовку, даёт вам возможность скорректировать курс до начала процесса долгоиграющего агента, отсекая те ветви, которые далеки от того, что вы себе представляете.
Превосходство мультиагентности
Исследования (и мой собственный опыт) также показали, что использование нескольких агентов в связке «оркестратор — субагент» значительно превосходит использование одного хорошего агента.
Очевидно, это сжигает гораздо больше токенов, но если для вас это не проблема, результаты действительно улучшаются.
По сути, это «горизонтальный» способ масштабирования расхода токенов: вместо того чтобы один умный агент тратил больше токенов на размышления, несколько умных агентов тратят больше времени на совместные размышления.
Я реализую это в моём воркфлоу для долгоиграющих агентов следующим образом: основной долгоиграющий агент выступает в роли оркестратора, который может свободно создавать команды субагентов для каждой отдельной задачи.
Эти небольшие команды работают вместе для получения более качественного результата, чем мог бы один агент — обычно я делаю так, что один выступает в роли исполнителя, а другой — в роли ревьюера.
Это работает так: агент реализует свою задачу (которая была разбита на небольшие выполнимые части на этапе планирования) и передаёт её субагенту-ревьюеру.
Ревьюер, собственно... проводит ревью, и эти два агента обмениваются исправлениями и улучшениями до тех пор, пока оба не будут довольны качеством кода; после чего они отчитываются главному оркестратору о выполнении работы.
Борис (создатель Claude Code) элегантно выразил это:
Я обнаружил, что это чрезвычайно полезно, поскольку позволяет агентам смотреть на вещи свежим взглядом, без предвзятости. Например, агент-ревьюер видит код впервые и проводит объективный, непредвзятый обзор.
Это важно, потому что агенты, особенно Claude, часто могут обманывать себя, веря в вещи, которые просто неверны, когда их контекстные окна становятся перегруженными.
Изначально я создал Claude Delegator для этого (чтобы Codex ревьюил работу Claude), но с появлением GPT 5.5 я просто использую GPT 5.5 на xHigh для всего, что не связано с проектированием интерфейсов на фронтенде — для этого я использую Claude Design.
Межконтекстная память
Предоставление агентам места для хранения воспоминаний между контекстными окнами и принуждение их читать эти данные при каждом новом контекстном окне хорошо работает как для агентов, так и для людей, позволяя понимать текущее состояние дел.
В моём воркфлоу для долгоиграющих агентов, после этапа планирования, я прошу агентов создать, читать и поддерживать три файла:
- GOAL.md: верхнеуровневая цель, которую мы хотим достичь.
- STANDARDS.md: непреложные стандарты качества кода, которые необходимо соблюдать.
- IMPLEMENT.md: инструкции по воркфлоу (использование нескольких агентов для ревью, написание тестов, верификация работы и тому подобное).
- PROGRESS.md: непрерывно обновляемый журнал принятых решений и выполненной работы.
Я прошу новых агентов прочитать все эти файлы, чтобы мгновенно понять все решения и прогресс, достигнутый предыдущими агентами, и действовать в соответствии с этим прогрессом.
Конечно, агенты не всегда слушают, когда вы говорите им слишком много, так что это скорее ориентиры, чем вещи, которые всегда работают — но в целом они помогают процессу.
Заключительные мысли
Я невероятно воодушевлён долгоиграющими агентами. Сама идея о том, что мы однажды сможем создавать вещи одним запросом по мере улучшения моделей — это поразительно.
Я экспериментировал с их запуском на протяжении последних нескольких месяцев, документируя свои открытия по ходу дела... если вам интересна моя текущая настройка и вы хотите попробовать сами, вот ссылка: https://github.com/jarrodwatts/long-running-agent-skill/tree/main
Он оформлен как SKILL.md, который можно легко подключить к Claude/Codex, но я рекомендую использовать его с GPT 5.5 xHigh внутри приложения Codex, в котором есть отличная визуализация для субагентных воркфлоу.
Скилл также включает интересные функции, такие как параллелизация работы между небольшими командами субагентов с использованием git worktrees — я использовал его в длительных запусках для создания очень качественных базовых частей проектов, готовых к доработке.
Надеюсь, вам понравится!
Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!
Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot