BLACKSWAN: проверка действий ИИ-агента через выдвижение гипотез и поиск опровержений до выполнения

ДЕЙСТВИЕ АГЕНТА (a_t): Если только чтение (read-only) → Выполнить сразу
                       Если меняет среду (write) → Перехватить и запустить BLACKSWAN:

ШАГ 1 — EXPECT (Ожидание): Контекст + код действия a_t → Локальное утверждение κ_t (какой конкретный результат даст этот шаг для задачи пользователя)
ШАГ 2 — SUSPECT (Пререгистрация подозрений): Контекст + a_t + κ_t → Набор пар S_t = {(s_i, z_i)} (конкретная гипотеза ошибки s_i + элемент кода/параметр z_i, через который она влияет на действие)
ШАГ 3 — TEST (Попытка опровержения): Инъекция списка S_t в диалог → Чтение прошлых наблюдений и запуск read-only запросов → Вердикт по каждой гипотезе: true (ошибка подтверждена) | false (опровергнута) | deferred (нельзя проверить до выполнения)
ШАГ 4 — РЕШЕНИЕ: Все s_i ∈ {false, deferred} → Выполнить исходное действие a_t
                 Хотя бы одно s_i == true → Заблокировать a_t и сгенерировать исправленное действие a'_t с учётом найденных фактов

Ты — модуль предохранительной верификации действий ИИ-агента по методу BLACKSWAN (Conjecture & Refutation).
Твоя задача — не искать подтверждения тому, что действие верное, а попытаться ОПРОВЕРГНУТЬ его перед выполнением любого вызова, меняющего данные (write).



Задача пользователя: "Верни клиенту деньги за вчерашний проблемный заказ со статусом брака и отправь уведомление."
Перехваченный write-вызов (a_t):
```python
orders = get_client_orders(client_id=4821, date="yesterday")
target_order = orders[0]
refund_sum = target_order["total_price"]
create_refund(order_id=target_order["id"], amount=refund_sum)
send_message(client_id=4821, text=f"Оформили возврат {refund_sum} руб. по заказу {target_order['id']}")

**Результат:**
На первом шаге модель зафиксирует ожидание (возврат полной стоимости первого вчерашнего заказа). На втором — выделит привязанные к коду узкие места: индекс `orders[0]` (может быть не тем заказом), поле `total_price` (частичный брак вместо полного возврата) и статус обращения в чате поддержки. На третьем шаге агент сформирует проверочные запросы на чтение деталей заказа и сообщений клиента, выставит вердикты `true/false/deferred` по каждому пункту и при обнаружении расхождения перепишет вызов возврата на точный ID бракованной позиции.

---

### Почему это работает

У языковых моделей при работе с инструментами есть хроническая слабость — **туннельное зрение и инерция траектории**. Когда агент уже построил план и написал черновик вызова API, любая проверка в духе «проверь, правильно ли выбраны параметры» опирается на ту же самую картину мира, которая породила ошибку. Модель проверяет те факты, которые уже лежат в её контексте (например, что заказ существует и сумма положительная), видит, что всё сходится, и смело нажимает «Выполнить». Неучтённый контекст — отмена в соседнем канале связи, второй однотипный заказ за тот же день, скрытое ограничение в профиле — остаётся за кадром, потому что агент не искал то, что может сломать его гипотезу.

В то же время LLM отлично справляются с **критическим анализом конкретного кода и точечной проверкой фактов**, если задать им правильный вектор поиска и жёсткие рамки. Когда задача ставится по принципу Карла Поппера — не подтвердить правоту, а **найти «чёрного лебедя» (факт-опровержение)**, — модель переключается из режима оправдания своего черновика в режим целенаправленного аудита.

**BLACKSWAN** превращает этот принцип в надёжную механику с помощью **двух ключевых ограничений**:
1. **Привязка подозрений к элементам кода `(s_i, z_i)`:** Модель не имеет права генерировать размытые страхи вроде «вдруг мы что-то забыли». Каждое подозрение обязано ссылаться на конкретную переменную, срез массива (`yesterday_orders[0]`, `dates[0]`) или аргумент API. Это заставляет модель проверить происхождение каждого значения в коде.
2. **Пререгистрация гипотез до начала проверок (Preregistered Suspicions):** Как в строгой науке гипотезы регистрируют до сбора данных, этап **Suspect** выполняется строго до того, как агент сделает хотя бы один проверочный запрос к среде. Если смешать выдвижение подозрений и их проверку в один цикл, модель начинает хитрить и выдвигает только те сомнения, ответ на которые уже знает. Изоляция этапа обязывает этап **Test** дать явный вердикт (`true`, `false` или `deferred`) по каждому зарегистрированному подозрению, не позволяя «забыть» неудобную гипотезу.

**Рычаги управления методом:**
- **Фильтр перехвата** → включайте **BLACKSWAN** только на действиях записи (`write` / `POST` / `DELETE` / отправка сообщений / оплата), пропуская чтение без проверок — это бережёт токены на безопасных шагах.
- **Статус `deferred`** → сохраняйте третий вариант вердикта для технических рисков, которые нельзя проверить заранее (например, временный сбой внешнего сервера), чтобы агент не зависал в бесконечных попытках проверить непроверяемое.
- **Глубина подозрений** → ограничьте число пар `(s_i, z_i)` до 2–4 самых критичных переменных вызова, чтобы агент проверял только существенные допущения.

---

### Шаблон промпта

Этот шаблон можно встроить в системную инструкцию агента (`CLAUDE.md`, `AGENTS.md`), оформить как перехватывающий хук (`PreToolUse`) или использовать в цепочке автоматизации перед выполнением ответственных действий:

```xml

ПРАВИЛО ПЕРЕХВАТА: Перед выполнением любого действия, меняющего состояние среды ({список_опасных_действий}), ОСТАНОВИ выполнение и пройди 3 шага верификации:

ШАГ 1 — EXPECT (Локальное ожидание):
Запиши черновик действия `a_t`. До любых новых проверок сформулируй `κ_t`: какой именно локальный эффект произведёт `a_t` и как он решает задачу `{задача_пользователя}`.

ШАГ 2 — SUSPECT (Пререгистрация фальсификаторов):
Опираясь только на текущий контекст, `a_t` и `κ_t`, выпиши список проверяемых подозрений `S_t = {(s_1, z_1), ..., (s_k, z_k)}`:
- `z_i`: конкретная переменная, индекс, фильтр или параметр в `a_t`.
- `s_i`: конкретный сценарий, при котором `z_i` приведёт к неверному результату или нарушит неявный контекст задачи.
ВАЖНО: Не запускай никаких инструментов на этом шаге! Сначала зафиксируй полный список `S_t`.

ШАГ 3 — TEST (Проверка наблюдениями и вердикт):
Ответь на запрос: "Я подозреваю, что выполнение этого действия ошибочно по следующим причинам: {S_t}. Пожалуйста, проверь по фактам, имеет ли место каждая из них."
Используй уже собранные наблюдения или вызови безопасные инструменты ТОЛЬКО НА ЧТЕНИЕ ({инструменты_чтения}), чтобы проверить каждое `s_i`.
Вынеси вердикт `v_t(s_i)` для каждого пункта:
- `true` — найдены факты, подтверждающие ошибку `s_i`;
- `false` — факты опровергают подозрение `s_i`;
- `deferred` — проверить до фактического запуска `a_t` невозможно.

ПРАВИЛО ЗАПУСКА:
- Если для ВСЕХ `s_i` вердикт `false` или `deferred` → выполни `a_t`.
- Если ХОТЯ БЫ ДЛЯ ОДНОГО `s_i` вердикт `true` → отмени `a_t`, напиши исправленное действие `a'_t` с учётом найденных фактов и повтори проверку.

Вот шаблон протокола верификации агентов BLACKSWAN. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

Task: "By when should everything from yesterday's order arrive?"

# Proposed write action (a_t):
orders = show_orders(sort_by="-created_at", page_limit=20)
yesterday_orders = [o for o in orders if created_on(o) == yesterday]
order = yesterday_orders[0]
dates = [parse(i["expected_delivery_at"]) for i in order["order_items"]]
answer = dates[0].strftime("%d-%m")
complete_task(answer=answer)

# Code-grounded suspicions (S_t):
- (s_1, yesterday_orders[0]): Was there another order placed yesterday besides yesterday_orders[0]?
- (s_2, i["expected_delivery_at"]): Is any order item missing an expected delivery date?
- (s_3, dates[0]): Should the final answer be the latest delivery date among items (max(dates)) rather than dates[0]?

# User-role message injected for TEST stage (o_t):
"I'm suspicious of executing this action for the following reasons: S_t. Please verify whether each of them is the case."

# Verdict rules (v_t):
v_t(s_i) = true      if observations confirm s_i
v_t(s_i) = false     if observations dismiss s_i
v_t(s_i) = deferred  otherwise

If ∀ s_i ∈ S_t : v_t(s_i) ∈ {false, deferred} => execute a_t
If ∃ s_i ∈ S_t : v_t(s_i) = true              => withhold a_t and draft a'_t