Тіньовий рев’юер: як змусити AI перевіряти власний результат

ai · 2026-10-06

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

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

Що саме порівнюємо

У Anthropic описує агента як цикл планування, дії, спостереження та повторення, а безпеку розкладає на модель, harness, інструменти та середовище. Важлива для нашої схеми частина — людський контроль: для Claude Code окремо виділено Plan Mode, де план перевіряється до виконання дій.

Codex CLI має окремий режим review: він аналізує незбережені зміни, коміт або базову гілку, повертає пріоритетні знахідки й не змінює робоче дерево. Це хороший приклад правила «рев’юер не виправляє те, що перевіряє». Тести, захист гілки та обов’язкові підтвердження залишаються жорстким бар’єром, а висновок моделі — лише сигналом.

У OpenCode CLI агент створюється з власним системним промптом і permission-конфігурацією: усе, чого явно не дозволили, для нового агента заборонено. Це близько до схеми Plan/Explore з обмеженим доступом. Отже, корисний спільний принцип для Claude, Codex і OpenCode такий: перевірка повинна бути окремою фазою з меншим набором можливостей, а не проханням до виконавця «перевір себе ще раз».

Мінімальний протокол тіньового рев’ю

Спочатку визначте контракт результату. У ньому мають бути не лише «зроби X», а й критерії приймання, заборонені дії та докази, які треба повернути:

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

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

Відповідь рев’юера краще обмежити схемою:

{
  "status": "pass | changes_requested | blocked",
  "findings": [
    {
      "severity": "high | medium | low",
      "claim": "що не виконано",
      "evidence": "де це видно",
      "fix": "яку зміну внести"
    }
  ],
  "checked": ["tests", "links", "scope"]
}

Статус pass не означає «модель права». Він означає лише, що визначені перевірки пройдено. changes_requested повертає роботу виконавцю з конкретними доказами. blocked означає відсутність потрібних даних або небезпечну дію; автоматично вгадувати продовження тут не можна.

Чотири практичні схеми для OpenClaw

1. Vault як черга артефактів. Замість пересилання довгого діалогу зберігайте в Obsidian три короткі сторінки: inbox/ із контрактом, outbox/ із результатом і reviews/ із висновком. Skill описує процедуру перевірки, а окремий агент має доступ лише на читання до цих розділів. У фіналі він додає посилання на докази, але не редагує результат. Це зручно для статей, досліджень і Terraform-планів: рев’ю можна повторити після зміни джерела або вимоги.

2. Telegram із двома маршрутами. Зробіть у власній схемі бота дві команди: /do передає запит виконавцю, /check — ідентифікатор артефакту read-only рев’юеру. Виконавець може готувати файл, але не має права відправляти зовнішні повідомлення чи пушити. Рев’юер повертає короткий звіт і змінює стан артефакту з draft на pass, changes_requested або blocked. Це схема маршрутизації, а не готовий формат конфігурації OpenClaw: конкретні назви агентів і дозволів треба прив’язати до вашого Gateway.

routes:
  /do:
    agent: builder
    artifact_state: draft
    permissions: [read, write_workspace, run_tests]
  /check:
    agent: shadow-reviewer
    input: artifact_id
    permissions: [read_workspace, read_vault]
    output: review_json
    transitions: [pass, changes_requested, blocked]

3. Розділіть роль і процедуру. В OpenClaw skill має містити сталі кроки: перевірити контракт, зібрати докази, виконати тести, повернути JSON. Агент визначає межі: чи може він писати, запускати команди або звертатися до мережі. Не давайте рев’юеру skill із правом редагування «для зручності». Для інфраструктури це особливо важливо: read-only планувальник може аналізувати Terraform plan, але не повинен мати credentials для apply.

4. Зробіть дешевий preflight до дорогого виконання. Нетиповий, але корисний варіант — запускати рев’юера першим. Він не перевіряє результат, якого ще немає, а перетворює запит на короткий список критеріїв: неоднозначності, ризикові дозволи, обов’язкові тести, заборонені файли. Потім виконавець працює за цим списком, а звичайний тіньовий рев’юер перевіряє фінальний пакет. Ціна — додаткова затримка й ризик надмірно суворого чекліста; вигода — дорогий агент не витрачає час на задачу з неясною умовою приймання.

Як не перетворити перевірку на декорацію

Не доручайте обом агентам однаковий вільний аналіз. У рев’юера мають бути інші питання: «де доказ?», «чи перевищено scope?», «що станеться при помилці?». Корисно також змінювати модель або хоча б сесію, щоб не переносити помилкове припущення з першого проходу.

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

Збережіть у vault не тільки «пройдено», а й пакет доказів: час, версію інструкції, хеш або ідентифікатор артефакту, перелік джерел та невдалі спроби. Спільний instruction-файл може містити чекліст рев’ю, але не повинен бути єдиним бар’єром. Для контролю того, які моделі або провайдери взагалі доступні, в OpenCode є окремий експериментальний рівень policies; це інший контур, ніж дозволи інструментів. Критичні умови мають виконуватися детермінованим валідатором, тестом або branch protection.

Робочий playbook

Записати контракт і межі дії.
Запустити виконавця з мінімальними дозволами та вимагати докази.
Заморозити результат у пакет артефакту.
Передати пакет read-only рев’юеру з окремим контекстом.
Автоматично пропустити далі лише pass; інші два стани повернути людині або виконавцю.
Запустити детерміновані тести після AI-рев’ю та зберегти фінальний receipt.

Головна перевага такого контуру не в тому, що «друга модель мудріша». Вона в тому, що помилка має окрему поверхню для виявлення, а агент, який створює зміну, не є єдиним свідком її якості. Для OpenClaw це перетворює Telegram-запит, vault і набір інструментів на відтворюваний процес із чітким місцем, де робота зупиняється.