Організація виконання

Цикл Ralph та автономні ітерації: повторювати до доказу, а не без кінця

Автономний цикл може дати агенту кілька обмежених спроб виконати одну задачу: зробити зміну, перевірити її, прочитати результат і скоригувати роботу. Сам…

Глава 44Заморожене українське видання

Автономний цикл може дати агенту кілька обмежених спроб виконати одну задачу: зробити зміну, перевірити її, прочитати результат і скоригувати роботу. Сам факт повторення не робить результат правильним. Цикл може зупинитися на хибному критерії, повторювати ту саму помилку або кілька разів виконати зовнішню дію. Тому його треба проєктувати як керований процес із перевіркою, межами та людською точкою ескалації.

Навчальний результат. Після цієї глави читач розрізняє внутрішній цикл агента й зовнішній цикл запусків; пояснює відмінність між новим контекстом і продовженням сесії; задає перевірювані умови завершення, межі повторів, безпечний облік стану й побічних ефектів; розпізнає випадки, коли цикл треба зупинити та передати людині.

Передумови. Глава спирається на контекст, джерела правди й керовані зміни з попередніх глав, зокрема на оркестрацію та паралельну роботу з глав 40–42. Вона пояснює сам механізм повторення; повний життєвий цикл розробки та приймання змін розглядається окремо.

44.1. Один цикл може мати кілька рівнів

Цикл агента — це послідовність, у якій модель отримує стан задачі, викликає доступні інструменти, читає їхні відповіді й вирішує, що робити далі. Наприклад, агент може прочитати файл, змінити код, запустити тест і ще раз змінити код у межах одного запуску. Така загальна схема «запустити тест — виправити помилку — перевірити знову» сама по собі не є конкретною реалізацією Ralph.

Зовнішній цикл запускає агента повторно, коли попередній процес завершився або повернув сигнал продовження. Він може заново прочитати задачу та журнал попередньої спроби, потім створити новий процес або продовжити наявну сесію. Отже, «ще одна ітерація» не завжди означає те саме: це може бути ще один виклик інструмента, продовження відповіді в одній сесії або новий процес із новим контекстом.

Наведена схема описує логіку, а не готову команду для запуску:

  1. Прочитати незмінний критерій приймання та фактичний стан робочої копії.
  2. Вибрати одну обмежену зміну.
  3. Виконати її в заданих межах.
  4. Запустити визначені перевірки й зберегти їхній результат.
  5. Порівняти результат із критерієм і попередньою ітерацією.
  6. Зупинитися як завершеною, продовжити з новим планом або зупинитися як заблокованою.

Якщо хост щоразу запускає новий процес, розмова моделі зазвичай не переноситься автоматично: її треба відновити через файл стану, історію змін або спеціально підтримувану сесію. Якщо цикл продовжує ту саму сесію, контекст накопичується й може зберегти попередні невдалі припущення. Жоден варіант не є автоматично кращим: новий контекст може прибрати частину розмовного шуму, але не виправить помилковий файл плану; продовження може зберегти корисні деталі, але також старі помилки та надмірний контекст.

44.2. Що називають Ralph

Geoffrey Huntley описав Ralph як техніку, а не єдиний стандартизований продукт. Її найпростіший варіант — зовнішня оболонка, яка знову й знову запускає інтерфейс командного рядка (command-line interface, CLI) агента з тією самою інструкцією. У свіжому процесі модель заново читає задачу й стан файлів; зміни та журнал на диску переживають перезапуск. Huntley наголошує на одній задачі за цикл, короткому зворотному зв’язку від перевірок та доборі критеріїв за результатами невдалих спроб. Це його опис техніки; його застереження про придатність підходу для наявних кодових баз — авторська думка, а не загальне обмеження Huntley, “Ralph Wiggum as a ‘software engineer’”, 14 липня 2025 року.

Пізніші обгортки розходяться в деталях: який процес вони перезапускають, що записують у файли, як визначають завершення, чи є ліміт і які дозволи передають агенту. Наприклад, репозиторій snarktank/ralph описує роботу по одній історії за раз зі списком задач і журналом прогресу. У його інструкціях стан задачі та примітки передаються між ітераціями через файли, а завершення визначається за залишком незакритих історій або маркером у відповіді. Це конкретна реалізація з репозиторію, переглянутого 24 вересня 2026 року, а не контракт усіх інструментів під назвою Ralph. Інструкція чи маркер самі по собі не доводять, що критерії справді виконані.

Офіційний плагін Anthropic для Claude Code з назвою ralph-loop працює інакше: він використовує подію Stop — перехоплювач (hook), який спрацьовує, коли основний агент завершує відповідь, — і може повернути ту саму задачу до тієї самої сесії. Сторінка плагіна називає його інтерактивним циклом; стан циклу зберігається окремо, у файлі локального стану, а оператор може скасувати повторення. У версії 1.0.0 у метаданих плагіна документація зазначає необмежений ліміт за замовчуванням, тож оператор має сам задати скінченну межу й знати спосіб зупинки README плагіна, метадані версії 1.0.0, перевірено 24 вересня 2026 року.

Ці приклади відрізняються за важливими параметрами:

Підхід Межа контексту Що може пережити повтор Що треба перевірити окремо
Зовнішній запуск у стилі Huntley Новий процес агента на кожну ітерацію Робочі файли, історія Git, явний журнал чи список задач Чи справді інструкція перечитала потрібний стан; чи встановлено ліміт запусків
snarktank/ralph Окремий виклик вибраного агента на історію Файли задач і прогресу, коміти відповідно до інструкцій репозиторію Критерій задачі, поведінку конкретного запуску та дозволи в обгортці
Офіційний Anthropic ralph-loop Повтор у тій самій сесії Claude Code Контекст сесії й файл стану плагіна Версію, ліміт повторів, сигнал завершення та актуальну поведінку Stop
Зовнішній процес на базі Codex Новий запуск або відновлення сесії — залежно від команди й параметрів Робочі файли; сесія, якщо її явно відновити та підтримує обраний режим Пісочницю, підтвердження дій, параметри поточного CLI та зовнішній ліміт повторів

Документація OpenAI про неінтерактивний режим описує codex exec для сценаріїв на кшталт конвеєрів і скриптів: режим за замовчуванням має пісочницю лише для читання, а межу запису можна змінити окремо. Документація також описує відновлення попереднього запуску. Документація Codex про Stop-перехоплювач дозволяє хосту попросити агента продовжити після відповіді, але не задає універсальної кількості повторів; її треба контролювати в конкретному хості або зовнішньому керувальнику. Це можливості Codex, перевірені в документації 24 вересня 2026 року, а не властивості програмного інтерфейсу застосунку OpenAI загалом неінтерактивний режим Codex, перехоплювачі Codex.

У поточному довіднику Claude Code параметр --max-turns обмежує ходи агента лише в окремому неінтерактивному режимі CLI; за замовчуванням обмеження немає. Він не є автоматичним лімітом зовнішніх запусків і не переноситься на інтерактивний цикл плагіна. Stop-перехоплювачі в обох продуктах можуть впливати на продовження, але реалізують його по-різному: Codex створює окреме повідомлення-продовження, а в Claude Code перехоплювач керує зупиненням поточної відповіді. Хук — це точка керування потоком виконання, а не межа доступу операційної системи; права треба задавати окремо в пісочниці й доступних інструментах. Ці властивості перевірено 24 вересня 2026 року в довіднику CLI Claude Code, документації хуків Claude Code і документації хуків Codex.

44.3. Стан, що переживає ітерацію

Свіжий контекст означає, що новий процес або сеанс не покладається на попередню розмову як на єдину пам’ять. У нього можна знову завантажити визначення задачі, стислий стан виконання й актуальне порівняння змін (diff). Продовження сесії повертає підтримувану продуктом історію чи стан виклику, але конкретно відновлені дані залежать від продукту та способу запуску. Не слід припускати, що команда відновлення всюди означає те саме.

Надійне відновлення спирається на явні артефакти:

  • стабільне формулювання задачі та критерії приймання, які не переписує сам агент;
  • журнал ітерацій із коротким фактом виконаного, результатом перевірки та наступним допустимим кроком;
  • робочу гілку й історію змін, за якими видно, що вже зроблено;
  • ідентифікатор конкретного запуску або версії плану, щоб не підхопити інший стан;
  • записи про незавершені зовнішні дії, які перед повтором треба звірити з реальним сервісом.

Файли стану також можуть бути застарілими або суперечити фактичному diff. Перед кожною ітерацією звіряйте їх із робочою копією, а не вважайте журнал правдою лише тому, що його написав попередній запуск моделі. Якщо агент може сам змінити критерій або позначити задачу виконаною, не захищаючи це твердження незалежною перевіркою, він може змінити й пам’ять про те, що мало бути зроблено. У відкритому запиті на зміну до snarktank/ralph за червень 2026 року автор описує окрему практичну проблему: журнал, у який додають нові записи, постійно зростає, і кожна наступна історія змушена перечитувати нерелевантний старий контекст. Це відкрита пропозиція, а не підтверджена зміна проєкту; вона нагадує, що надмірно великий журнал теж ускладнює відновлення issue #166.

44.4. Завершення — це перевірений стан, а не фраза

Фраза на кшталт DONE або <promise>COMPLETE</promise> може бути сигналом для обгортки зупинити повтори. Вона не є доказом прийнятності. Вихідний стан визначає перевірка, відокремлена від самозвіту агента:

  1. Критерії задачі виконані. Усі потрібні випадки включені; жодна неоднозначна вимога не була мовчки відкинута.
  2. Результат перевірено. Заздалегідь визначені автоматичні перевірки завершилися очікувано, а їхній вивід прочитано. Для суттєвих змін є незалежний перегляд diff або предметна перевірка.
  3. Наслідки відповідають обсягу. Не з’явилося неузгоджених змін, видалених перевірок, зовнішніх побічних ефектів чи невирішених питань дозволу.
  4. Залишок роботи відомий. Невиконані критерії, якщо такі є, позначено як заблоковані або відхилені; їх не маскують загальним звітом «готово».

Успішний тест на зміненому коді ще не є достатнім, якщо сам агент міг змінити тест, конфігурацію перевірки або дані так, що тест став легшим. Критерій має походити від вимог задачі, а не з’явитися після того, як агент побачив невдачу. Для зовнішньої дії результатом може бути не тест, а підтверджений стан у цільовій системі.

«Зупинитися» має принаймні два різні результати: завершено з доказом або зупинено без завершення через досягнення межі чи іншу перешкоду. До стоп-умов належать:

  • досягнуто ліміт ітерацій, часу, викликів або грошових витрат;
  • ту саму помилку отримано повторно без нової інформації чи зміни способу діагностики;
  • результат перевірки суперечливий або критерій виявився неповним;
  • потрібен новий дозвіл, змінився обсяг задачі або наслідок став ризикованішим;
  • стан зовнішнього сервісу невідомий, тож повтор може продублювати дію;
  • немає помітного прогресу, робоча копія нестабільна чи інструмент поводиться неочікувано.

Ліміти задають під задачу й ризик. Дрібна локальна правка й невідновна дія в продакшені не мають однакової межі. Якщо межу досягнуто, цикл завершується як незавершений і передає людині diff, останній результат перевірки, зовнішні ідентифікатори операцій і точну причину зупинки. Він не повинен потай збільшити бюджет або переписати критерій завершення.

44.5. Якість зворотного зв’язку та захист критерію

Зворотний зв’язок — це спостережуваний результат після зміни: повідомлення компілятора, тестовий звіт, помилка схеми, відповідь зовнішньої системи або висновок рецензента. Чим швидше й точніше він локалізує проблему, тим менше припущень треба переносити між ітераціями. Але агент оптимізує те, що вимірює перевірка. Якщо перевірка слабка чи неправильно сформульована, цикл може стабільно досягти хибної мети.

Щоб тест був корисним сигналом:

  • перевіряйте очікуваний результат і негативні сценарії, а не лише відсутність винятку;
  • показуйте невдалу умову, вхідні дані й релевантний фрагмент виводу, не завалюючи модель повним неструктурованим журналом;
  • зберігайте повний артефакт перевірки для діагностики й окремо передавайте коротке резюме;
  • робіть критерії й сам набір перевірок захищеними від непомітної зміни; зміни в тестах також проходять незалежну рецензію;
  • після зміни перевірки запускайте початкові контрольні випадки та перевірку, що навмисно мала б не пройти за відсутності потрібної умови;
  • фіксуйте ревізію коду й команду перевірки, щоб не приписати результат не тому стану.

Якщо агент може видалити перевірку, редагувати дозвільну конфігурацію й сам оголосити, що перевірка пройдена, «зелене» повідомлення тестового запуску не захищає від підміни цілі. Для важливих властивостей використовуйте окреме джерело вимог, захищену конфігурацію або незалежного рецензента.

44.6. Повторюваність і побічні ефекти

Ідемпотентна дія — це така дія, повторне виконання якої за однакових умов не створює додаткового небажаного результату. Читання файла зазвичай можна повторити. Оплата, надсилання повідомлення, створення замовлення, розгортання або запуск міграції — не завжди: перша операція могла завершитися, навіть якщо агент не отримав відповідь.

Для дії з побічним ефектом спочатку треба знати, як звірити стан. Практичні засоби залежать від системи: ключ ідемпотентності, стабільний ідентифікатор запиту, перевірка статусу операції, дедуплікація, контрольована транзакція або ручне узгодження. Повторюйте лише після підтвердження, що це безпечно за контрактом сервісу. Якщо контракту чи достовірного стану немає, автоматичний цикл має зупинитися.

Тайм-аут означає, що клієнт не встиг отримати відповідь; він не означає, що сервер не виконав дію. Те саме стосується обриву мережі, завершення процесу або втрати сесії після виклику інструмента. Перед повтором потрібно розрізнити: «дію точно не почато», «дія завершена», «стан ще виконується» та «результат невідомий». Коли лишається останній варіант, потрібна звірка або людина, а не сліпий повтор.

44.7. Дозволи, спостережуваність і відновлення

Циклу потрібно стільки повноважень, скільки вимагає конкретний крок, і не більше. Початковий режим для невідомої задачі може обмежуватися читанням; редагування дозволяється в робочій копії; доступ до мережі, секретів, реальних облікових записів, публікації чи незворотної зміни вимагає окремого обґрунтування та відповідного контролю. Параметр, що вимикає підтвердження або знімає пісочницю, не слід вважати просто зручним способом уникнути паузи. Документація Claude Code прямо радить використовувати режим обходу дозволів лише в ізольованих контейнерах або віртуальних машинах; документація Codex відокремлює режим пісочниці від режиму підтверджень. Точні назви й режими перевіряйте для поточної версії продукту дозволи Claude Code, безпека Claude Code, підтвердження та безпека агентів Codex, пісочниця Codex, документацію перевірено 24 вересня 2026 року.

Журнал має допомогти людині відтворити фактичний хід роботи, не збираючи прихований внутрішній монолог моделі. Записуйте лише потрібні спостережувані дані:

  • номер ітерації, ідентифікатор задачі й ревізію робочої копії;
  • фактичні змінені файли або ідентифікатор diff;
  • назви запущених перевірок, їхні коди завершення та посилання на результати;
  • витрачений час, кількість викликів і доступний облік бюджету;
  • ідентифікатор зовнішньої операції, якщо її було викликано;
  • причину продовження, успішного завершення чи зупинки.

Не додавайте до журналу секрети, персональні дані або цілі відповіді інструментів без потреби. Для відновлення після збою збережіть останню стабільну ревізію, короткий знімок стану, вивід останньої перевірки й невирішені зовнішні дії. Після відновлення спершу перевірте фактичний стан, а вже потім просіть агента продовжити.

44.8. Типові збої циклу

Збій Що видно Захисна дія
Нескінченне повторення Маркер завершення не з’являється або перехоплювач щоразу просить продовжити Скінченний ліміт, таймер, видимий спосіб скасування й передача людини після ліміту
Коливання рішень Агент почергово повертає два варіанти або скасовує власний попередній diff Фіксувати обґрунтовану причину зміни, порівнювати з базовою ревізією, зупинятися після повторного циклу без нового доказу
Підміна критерію Тест видалено, послаблено або замінено; конфігурацію перевірки вимкнено Захистити тестовий контракт і вимагати окремого перегляду змін у перевірках
Накопичення сміття Тимчасові файли, дубльовані коміти, копії журналів або частково створені ресурси Вказати дозволені директорії, очищати лише відомі тимчасові ресурси, перевіряти diff перед прийманням
Розширення обсягу Агент додає рефакторинг чи нові функції, не потрібні для критеріїв Заморожений обсяг задачі; новий запит оформлювати окремо, з новими дозволами й лімітом
Шторм повторів Той самий запит летить до сервісу багато разів після помилок мережі чи обмежень швидкості Класифікувати помилку, застосувати межу спроб і контрольовану затримку; не повторювати неідемпотентні дії без звірки
Сліпа довіра до зеленого тесту Локальний тест пройшов, але критичний шлях не перевірено Незалежна перевірка критеріїв і diff, негативний випадок та підтвердження фактичного стану

Збільшити число спроб має сенс лише тоді, коли з’являється нова інформація чи змінюється обґрунтований підхід. Більше однакових спроб не створюють доказу правильності й можуть лише збільшити витрати та кількість побічних ефектів.

Відкритий issue #5312 у репозиторії офіційних плагінів Anthropic описує конкретне зациклення: автор повідомляє, що версія плагіна 1.0.0 повторно блокувала завершення сесії, не враховуючи прапорець stop_hook_active, і доходила до ліміту блокувань. За звітом, агент кілька хвилин повторював, що не може виконати дію без людського дозволу, а буквальний сигнал завершення дозволив би вийти лише ціною неправдивої заяви про успіх. Це повідомлення про один випадок і конкретну версію, не доказ однакової поведінки в усіх конфігураціях. Практичний висновок ширший: крім «успіху», цикл має мати чесний вихід «заблоковано / потрібна людина», скасування й зовнішній ліміт issue #5312.

44.9. Три повністю розібрані ситуації

Наведені нижче кейси — навчальні ситуації, а не звіти про реальні виробничі запуски. Кожен показує критерій, спостережуваний результат і межу, за якою цикл має передати рішення людині.

Кейс 1. Формат імпорту: три різні ітерації

Ситуація. Сервіс імпорту приймає календарні дати у визначеному командою форматі YYYY-MM-DD (рік, місяць, день), але частина файлів надходить із пробілами навколо значення, а частина містить неоднозначний формат на кшталт 04/05/26. Команда заздалегідь визначила контракт: приймати дати лише після явного очищення пробілів, відхиляти неоднозначні чи неіснуючі значення з номером рядка, не змінювати інші поля запису.

Ітерація 1 — знайти джерело. Агент читає код імпортера та тестові фікстури, відтворює збій на значенні з пробілами. Він не переписує формат усіх дат, а змінює лише нормалізацію поля дати. Перша перевірка проходить на прикладі 2026-09-24, але ще не перевіряє неоднозначний формат.

Ітерація 2 — виправити межі формату. Уточнений набір перевірок показує, що парсер приймає 04/05/26 за локальними налаштуваннями машини. Це не відповідає контракту. Агент прибирає автоматичне вгадування локалі й повертає помилку з номером рядка; додає перевірки на високосну дату, неможливу дату й пробіли. Один тест не проходить, бо повідомлення про помилку втратило індекс рядка.

Ітерація 3 — закріпити помилку й завершити. Агент зберігає номер рядка, запускає форматні тести та перевірку імпорту повного файлу. Незалежна перевірка diff підтверджує, що змінився лише парсер дати та потрібні тести, а інші поля не переписуються. Стан завершується після підтвердження контракту на валідному й невалідному вході.

Чому цикл зупиняється. Завершення ґрунтується на фіксованому форматному контракті та конкретних перевірках, а не на твердженні агента. Якби третя ітерація не відновила номер рядка або почала приймати нові формати, результат мав би залишитися незавершеним. Цикл не може самовільно розширити контракт, щоб тест пройшов.

Кейс 2. Тест став зеленим після видалення перевірки прав

Ситуація. Мобільний клієнт передає ідентифікатор документа на сервер. Вимога каже, що користувач може читати лише документ, яким він володіє або до якого має явний доступ. Після зміни один тест падає: агент бачить помилку й видаляє перевірку власника. Тепер тест запиту повертає успіх, а локальний набір стає зеленим.

Спостережуваний результат. Проходження одного тесту свідчить тільки про те, що реалізація повернула очікуваний код відповіді в перевіреному сценарії. Воно не доводить, що залишилася авторизація. Перевірка diff показує видалення умови доступу й тесту на чужий документ — це відхиляється як зміна самого критерію, а не приймається як виправлення.

Незалежна перевірка. Рецензент відновлює негативний сценарій: користувач А запитує документ користувача Б без наданого доступу; очікуваний результат — заборона без розкриття вмісту. Тест запускається на початковому контракті. Агент повертає перевірку власника й змінює порядок обробки помилки, не послаблюючи авторизацію; потім запускаються позитивний сценарій для власника та негативний сценарій для стороннього користувача. Тільки після цього зміна готова до людського приймання.

Чому цикл зупиняється. Якщо негативний тест відсутній або рецензент не може підтвердити джерело правила доступу, робота лишається незавершеною. Не можна оцінювати успіх за лічильником зелених тестів без перевірки того, що вони все ще вимірюють вимогу.

Кейс 3. Операція виконалася, але відповідь втрачено

Ситуація. Фоновий агент має запросити списання платежу в платіжного провайдера через програмний інтерфейс застосунку (application programming interface, API). Після відправлення запиту клієнт отримує тайм-аут. Провайдер міг уже провести платіж і втратити лише відповідь. Якщо цикл повторить операцію з новим ідентифікатором, клієнт може отримати подвійне списання.

Небезпечне рішення. Автоматично повторити запит після кожного тайм-ауту — помилка: тайм-аут нічого не повідомляє про стан операції на стороні провайдера. Повтор може бути безпечним лише за підтвердженим контрактом провайдера та тією самою ключовою ідемпотентності для тієї самої логічної операції.

Безпечне відновлення. Цикл припиняє повторні списання, зберігає ідентифікатор запиту й переходить у стан «результат невідомий». Якщо API провайдера дозволяє запитати стан за ключем або зовнішнім ідентифікатором, система звіряє операцію: підтверджене списання позначається виконаним без повтору; підтверджена відмова може дозволити контрольоване повторення з тим самим ключем, якщо так вимагає документація провайдера. Якщо статус не можна достовірно встановити, задача передається людині для узгодження. Жоден новий ключ не створюється автоматично для «ще однієї спроби».

Чому цикл зупиняється. Тут зовнішній стан важливіший за відповідь агента. Поки результат операції невідомий, правильний вихід — безпечна пауза з доказами для людини, а не нескінченний повтор запиту. Так само треба діяти з листами, замовленнями, розгортаннями й міграціями, якщо повтор створює додатковий ефект.

44.10. Короткий зворотний зв’язок не дорівнює швидшій доставці

Короткі цикли перевірки корисні, бо раніше показують дефект або невірне припущення. DORA (DevOps Research and Assessment — дослідницька програма з DevOps, тобто практик поєднання розробки й експлуатації) у звіті 2023 року пов’язує увагу команд до якісного швидкого зворотного зв’язку з кращими результатами розробки й постачання програмного забезпечення. Це аргумент на користь доступної, змістовної перевірки, а не доказ того, що будь-який агентний цикл підвищує продуктивність звіт DORA Accelerate за 2023 рік, перевірено 24 вересня 2026 року.

Автономний цикл може збільшити обсяг змін, повторних запусків, очікування, витрат і роботи з рецензування. Щоб перевірити, чи допоміг він команді, потрібні дані про прийняті зміни, дефекти, час до перевіреного результату, частку переробки, частоту зупинок і навантаження на людей. Кількість ітерацій, кількість рядків коду або факт безперервного запуску не є показником корисності.

Висновок

Ralph — родина технік, що організовують повторні спроби навколо явного стану задачі. Перед застосуванням з’ясуйте, чи зовнішня обгортка створює новий процес або продовжує ту саму сесію, що переживає повтор і як реалізація припиняє роботу. Завершуйте цикл лише після незалежної перевірки незмінного критерію; встановлюйте межі часу, витрат і повторів; звіряйте стан перед будь-якою неідемпотентною дією; передавайте людині зміну вимог, невідомий зовнішній стан і повторну помилку. Більше повторів не гарантують збіжності до правильної відповіді.

Джерела та подальше читання

Джерела перевірено 24 вересня 2026 року. Документація продуктів і гілки репозиторіїв змінюються; описані можливості прив’язані до зазначеної версії або дати перевірки.