Коли AI ламається: retry, repair чи stop

ai · 2026-10-11

Агент, який отримав помилку інструмента, не має автоматично «спробувати ще раз». Повторний виклик може бути правильним для тимчасового збою мережі, небезпечним для частково виконаної оплати і безглуздим для неправильного аргументу. Практична дисципліна тут проста: кожну помилку класифікуємо як retry, repair або stop, а результат перевіряємо окремо від того, що стверджує модель.

Що відрізняється у Claude, Codex та OpenCode

У Claude межа відповідальності явно проходить між моделлю та застосунком: клієнтський інструмент повертає tool_use, застосунок виконує операцію, а потім надсилає tool_result. Документація Claude про tool use описує також обробку викликів і помилок. Отже, помилка виконання — це дані для наступного ходу, а не доказ, що дія відбулася.

У Codex app-server протокол має відповіді JSON-RPC з result або error, а для перевантаженого WebSocket-сервера офіційна документація радить повторення з експоненційною затримкою та випадковим розкидом. Опис Codex app-server також розділяє транспорт, потік подій і підтвердження. Це корисна модель для будь-якого агента: повторювати можна запит, але не припускати, що попередня спроба була повністю безпечною.

У контролях OpenAI для автономної роботи дозвіл має межі: прохання підготувати відповідь не дає права її відправити, а зупинка задачі не скасовує вже виконані дії. Це саме правило для власного агента: «зупинено» — не означає «відкотилося».

У OpenCode дозвіл — не те саме, що успіх. Його поточна модель також відділяє доступ до інструментів і зовнішніх серверів від результату їх виконання. Для практики це означає те саме розділення: політика доступу вирішує, чи можна почати дію, а перевірка — чи дія завершилася правильно.

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

Три рішення після помилки

Retry — повторити той самий виклик. Застосовуйте лише коли збій, імовірно, тимчасовий: тайм-аут читання, 429, короткий збій сервісу, перевантаження. Обмежте кількість спроб, додайте backoff і збережіть ідентифікатор операції, щоб повтор був ідемпотентним.

Repair — спочатку змінити умови, потім спробувати знову. Приклади: виправити JSON за схемою, зменшити обсяг запиту, оновити прострочений курсор, запросити відсутній параметр. Repair не повинен непомітно перетворювати deny на allow: якщо бракує дозволу, потрібне підтвердження або інший агент.

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

Корисний мінімальний контракт для кожного інструмента:

{
  "status": "retryable | repairable | terminal | succeeded",
  "operation_id": "stable-id-for-this-operation",
  "side_effect": "none | prepared | committed | unknown",
  "retry_after_ms": 2000,
  "next_action": "retry | repair | stop | verify"
}

Поле side_effect: unknown важливіше за красиве повідомлення про помилку. Якщо мережа обірвалася після відправлення запиту, повторювати запис без ідемпотентного ключа не можна: спочатку потрібна перевірка стану.

Як перенести це в OpenClaw

1. Розділіть підготовку і коміт

Для Telegram-бота корисно мати два класи інструментів: prepare_* лише формує diff, лист або план; commit_* змінює зовнішній стан. Агент може самостійно повторити підготовку, але commit_* мусить вимагати явного підтвердження або пройти вузьке правило дозволу.

tools:
  prepare_reply:
    side_effect: none
  commit_send_message:
    side_effect: committed
    approval: required
  commit_publish_post:
    side_effect: committed
    approval: required

Це не просто UX. Якщо Telegram API повернув тайм-аут, невідомо, чи повідомлення вже доставлене. Після помилки бот спочатку шукає operation_id у журналі або перевіряє стан, і лише тоді вирішує між retry та stop.

2. Зробіть окремий read-only контур перевірки

Для щоденних статей, змін у репозиторії чи відповідей з бази знань головний агент може створити результат, але не вважати його готовим. Підлеглий verifier читає результат, перевіряє схему, посилання, дублікати і вимогу задачі, після чого повертає тільки pass, repair або stop.

У OpenClaw це природно оформити як read-only агент із вузьким набором інструментів, а не як ще одну велику інструкцію головного агента. Для OpenCode аналогічна ідея є в обмеженому Plan та read-only підлеглих агентах. Перевага — менший радіус помилки; недолік — ще один хід і витрата токенів.

3. Зберігайте «конверт невідомого результату» у сховищі знань

Нестандартний, але практичний шаблон: після кожної небезпечної помилки записуйте короткий Markdown-конверт у vault, а не весь журнал моделі.

---
operation_id: telegram-2026-10-11-001
action: send_message
status: unknown
last_confirmed: prepared
next_action: verify-before-retry
---

- Запит створено: так
- Відповідь сервісу: тайм-аут
- Повтор без перевірки: заборонений
- Перевірити: журнал доставки та ідентифікатор операції

Наступна сесія або інший агент може продовжити роботу без роздування контексту. Компроміс очевидний: vault стає частиною контуру надійності, тому потрібні TTL, маскування персональних даних і регулярне прибирання невирішених конвертів. Не записуйте туди секрети чи повний текст приватного листування.

4. Введіть ліміт циклу відновлення

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

retry_budget: 2
repair_budget: 1
if same_tool_call_repeats: stop("possible doom loop")
if side_effect == unknown: verify_before_retry
if verification == fail: stop

Для Telegram-бота це означає, що невдале надсилання не породить десять однакових повідомлень. Для CI — що агент не буде нескінченно перевстановлювати залежність, коли справжня причина в мережевій політиці.

Операційна схема

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

Стан	Автоматична дія
тимчасовий збій, `side_effect=none`	retry з backoff
неправильний аргумент	repair за схемою, один раз
результат невідомий	verify, не повторювати
заборона або провал перевірки	stop і передати людині
успіх	записати доказ і завершити

Доказом успіху є не фраза «готово», а спостережуваний факт: API повернув ідентифікатор, файл пройшов перевірку, повідомлення з’явилося в цільовому чаті, збірка завершилася з кодом 0. Саме так варто будувати OpenClaw-плейбуки: підготувати → виконати → перевірити → зафіксувати, а не «попросити агента бути уважнішим».

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