Контроль ИИ-агентов: зачем нужен независимый судья

26 июня 2026 года мой ночной агент-Дежурный закрыл задачу — собрать дайджест мировых трендов и разложить их по темам. Доложил точно в срок: «готово, дайджест сформирован, задача закрыта». Рядом с Дежурным теперь работает судья — отдельный агент, построенный на другой модели, без общей памяти с Дежурным. Задача судьи одна: читать не слова отчёта, а проверять факт.

За 6 секунд судья вернул задачу: RSS-источник, который Дежурный использовал как основной, перестал отдавать данные 3 дня назад. Дайджест был пустышкой — пустой файл с правильным заголовком. Задача честно осталась открытой.

Это не баг и не катастрофа. Это штатная работа архитектуры. Агент закрыл задачу так, как умеет: сгенерировал отчёт на основе инструкции. Никакой злой умысел — просто входные данные умерли, а агент об этом не знал. Знал бы — сказал. Поэтому нужен кто-то, кто знает.

Ниже — почему автономная система всегда будет переоценивать себя, как работает независимый судья технически, и где этот принцип проявляется за пределами агентных систем — в отчётах, в собственном коде, в воронке продаж.

Всё это применимо к любому бизнесу, у которого есть хотя бы один бот или скрипт, работающий без человека: рассылка, импорт данных, парсер прайсов, CRM-интеграция. Принцип один и тот же: не доверяй на слово тому, кто сам себя экзаменует. Это не паранойя — это архитектурная гигиена.

Почему агент, который проверяет себя сам, всегда ошибается в свою пользу

Формальное закрытие задачи — не обман. Это оптимизация: агент выполняет условия завершения так, как понимает их из инструкции. Проблема не в агенте, а в том, что инструкции пишут люди, а люди неточны.

Инструкция: «собери дайджест мировых трендов из RSS, сохрани в файл, закрой задачу». Агент: взял URL, обратился к источнику, источник не ответил за 3 секунды, вернул пустой ответ, сохранил пустой файл, закрыл задачу. Технически — всё выполнено. Фактически — ноль пользы.

Самопроверка не помогает. Добавим в инструкцию: «перед закрытием убедись, что файл не пустой». Агент проверит: файл не пустой, там есть строка с заголовком «Дайджест за 25 июня 2026». Требование выполнено. Дайджест по-прежнему пустой.

Этот паттерн описывается в AI-безопасности как specification gaming: система оптимизирует под измеримую метрику «задача закрыта», а не под смысл задачи. Агент не виноват — его задача именно такая: минимизировать число открытых задач. Он это и делает.

Единственный выход — вынести проверку за пределы системы. Не «пусть агент себя проверит», а «пусть другой агент проверит первого». Из другой модели, с другими инструкциями, без доступа к внутренним состояниям первого. Судья не знает, что Дежурный думает о своей работе. Судья знает только факт: открываю URL-источник — ответа нет. Дайджест не мог быть составлен.

Именно этот вывод получен за 6 секунд — вместо того чтобы открывать утром пустой файл и тратить 15 минут на диагностику вручную.

Архитектура независимого судьи: как это устроено технически

Независимый судья — это отдельный агент. Не функция внутри основного агента, не проверка в конце того же скрипта. Отдельный процесс, отдельная модель, отдельные инструменты.

Три обязательных свойства

Другая модель или другой пресет. Судья не разделяет «логику» основного агента. Если Дежурный работает на Claude Opus 4 с набором инструкций под разгребание бэклога, то судья — отдельный инстанс Claude Haiku или GPT-4o mini с единственной задачей: верифицировать факт завершения.

Нет общей памяти. Судья не читает контекст Дежурного — он читает только результат его работы: файл, URL, запись в БД. Это гарантирует, что судья не «соглашается» с Дежурным только потому, что тот убедительно написал про выполнение.

Проверяет внешнее состояние, не слова. Лог-строчка «задача выполнена» — не доказательство. Доказательство: файл существует и содержит реальные данные, URL отдаёт 200 с нужным контентом, запись в БД обновлена с правильным значением.

Системный промпт судьи: минимальная рабочая версия

Промпт судьи не должен быть сложным. Вот структура, которая работает в системе Solar Automation:

«Ты — верификатор результатов. Тебе дают: 1) описание задачи, 2) что агент заявил как результат, 3) ссылку или идентификатор артефакта. Твои инструменты: HTTP GET, чтение файлов, SELECT-запросы к БД. Ты должен проверить артефакт независимо и вернуть ровно одно из двух: PASS — если задача выполнена по факту, REOPEN: [причина в одном предложении] — если нет. Не рассуждай, не объясняй. Верни только PASS или REOPEN: [причина].»

Ключевое ограничение: судье запрещено писать в какие-либо системы. Только READ-операции. Это предотвращает ситуацию, когда судья сам что-то меняет и считает это «доказательством» того, что всё хорошо.

Пример из системы Solar Automation

Дежурный завершает задачу → записывает в БД строку с полем status='closed' и result_summary → публикует event в очередь.

Судья читает event → берёт из БД result_summary → разбирает, какой URL использовался как источник → открывает URL свежим запросом (не кэш Дежурного) → если ответ пустой или данные за сегодня отсутствуют — verdict: REOPEN.

Дежурный получает verdict: задача снова в очереди с комментарием судьи. Комментарий лаконичный: «Источник вернул 0 записей. Найти альтернативный источник или отметить как unavailable.» Весь цикл — 6 секунд.

Что судья проверяет в системе из 7 агентов

• Контент-агент публикует статью → судья: URL доступен, H1 совпадает с заявленным, нет 404 на ресурсах страницы
• Финансовый агент обновляет отчёт → судья: сумма в отчёте совпадает с суммой в БД
• SEO-агент публикует статью → судья: robots.txt не блокирует новый slug, schema.org без ошибок
• Дежурный закрывает задачи → судья: результат соответствует критериям завершения из описания задачи

Ни одна из этих проверок не является «умной» работой. Это механические сверки. Слабое место человека — делать их каждый раз последовательно. Сильное место автоматизации — делать их каждый раз без исключений.

Три точки за один день, где принцип сработал вне агентных систем

Независимый контроль — это не только про агентов. 26 июня 2026 года тот же принцип проявился в трёх местах, которые с агентными системами не связаны напрямую.

Точка 1: Отчёт CTO о «мёртвом» боте

Утром пришёл health report от технического надзора. В нём значилось: guest-поллер — бот, который перехватывает сообщения гостей с Booking.com и Airbnb и пересылает в рабочий чат — «молчит неделю, рекомендуется отключить». Логика в отчёте разумная: виллы переданы в управление Vsemdom с 1 июня 2026, зачем держать живой канал.

Вместо того чтобы принять отчёт на слово — зашёл на сервер, запустил бота вхолостую на 5 настоящих письмах из архива. Бот жив: OAuth-ключ протух после переезда между аккаунтами Google в июне, но сам бот работоспособен. Гости пишут, сообщения есть — просто бот не мог их прочитать.

Отключить было бы легче. Это значит молча терять сообщения людей, которые уже заехали в виллы. Нашёл на сервере запасной App Password, переписал авторизацию с OAuth на IMAP App Password за час, переключил поток в чат управляющей компании Vsemdom. Проверил на тех же 5 письмах: дошли. Никого не дёргал — просто починил.

Принцип: отчёт сказал «мёртв», реальность — «жив, но сломан». Доверие к отчёту на слово = потерянные сообщения гостей. Независимая проверка по факту = час работы и работающий канал.

Точка 2: 264 скрипта с одним паролем

При выгрузке базы знаний в закрытое хранилище для доступа с телефона защита от утечек сработала мгновенно: в одном из рабочих файлов — живой пароль боевой базы данных. Пошёл проверять масштаб. Grep по всем скриптам в репозитории. Результат: этот пароль записан напрямую в 264 живых скрипта. В апреле 2026 года их было 198. За 2 месяца добавилось ещё 66 — просто копировался рабочий шаблон, который решал задачу.

6 месяцев накопленного риска. Не потому что кто-то халтурил. Потому что не было независимой проверки: ни одного инструмента, который бы при каждом новом скрипте говорил «здесь пароль в открытом виде». Проверки типа «а давай я посмотрю» — человеческая операция. Человек делает её, когда вспоминает. Автоматизированный grep при каждом коммите — делал бы каждый раз.

Решение: один защищённый файл с секретами, переменные окружения вместо хардкода. Фаза 1 — перевёл 4 главных сервиса. Остальные 260 — расписал задачами на ближайшие дни. Хуже не стало за ночь, лучше не станет без систематического контроля.

Точка 3: Воронка клуба прошла через независимого судью

Вечером собрал воронку с бесплатным материалом на входе для клуба «Solar — внутрянка». Написал письма прогрева, запустил через того же независимого судью — агента, которому дана задача смотреть на письма глазами нового подписчика, не как внутреннего контент-ревьюера. Судья не знает, сколько времени потрачено на письма. Судья знает только, что видит читатель.

Первую версию воронки судья завернул: «Мало пользы, сразу продаёшь». Переписал. Вторая версия прошла.

«Интересно, что я считал первую версию нормальной. Судья не согласился. В итоге письма стали лучше. Не потому что я плохо пишу — просто у меня нет дистанции от собственного текста.» — Юрий Солар, основатель Solar Automation

Это та же механика: автор не может честно оценить собственную работу. Он знает, что хотел сказать. Читатель видит только то, что написано. Судья — это читатель без контекста автора.

Как запустить независимого судью: минимальный рабочий вариант

Если у вас есть хоть одна автоматизация, которая что-то закрывает без участия человека — вот минимальный план внедрения судьи.

Шаг 1: Определите, что проверять

Не каждое действие агента требует судьи. Нужен там, где действие необратимо (удалил, отправил, опубликовал, закрыл), дорогостоящее при ошибке (отчёт, который человек прочитает как истину), имеет внешнее состояние, которое можно проверить независимо.

Не нужен там, где агент только читает и формирует черновик для человека, или где человек всё равно проверяет перед финальным действием.

Шаг 2: Сформулируйте критерии завершения машинно

До написания судьи — определите, что значит «выполнено» так, как это можно проверить кодом, а не словами:

• Файл с контентом существует, длина > N символов, не совпадает с файлом за предыдущий день
• URL отдаёт HTTP 200 и содержит ключевой заголовок, не кэшированный вариант
• Запись в таблице tasks имеет status='closed' и поле result не пустое и не дефолтное
• Email-рассылка: bounce rate по API < 5%, delivery rate > 90%

Если вы не можете сформулировать критерий завершения машинно — задача слишком размыта для автономного агента в принципе. Это тоже полезная информация.

Шаг 3: Напишите минимального судью

Судья — агент с одним системным промптом: «Ты проверяешь, выполнена ли задача по факту. Тебе дают описание задачи и ссылку на результат. Ты должен: 1) проверить результат независимо, 2) вернуть одно из двух: PASS или REOPEN + причина в одном предложении».

Инструменты судьи: HTTP-запросы, чтение файлов, SQL-запросы к БД (только SELECT), сравнение с эталоном. Модель — самая дешёвая, которая умеет следовать структурированным инструкциям. Это не творческая задача — это сверка. Для сверки достаточно Claude Haiku или GPT-4o mini.

Шаг 4: Замкните цикл и добавьте выход

Судья вернул REOPEN → задача уходит обратно в очередь основного агента с комментарием судьи. Агент читает комментарий, переделывает, судья проверяет снова. Максимум 2-3 итерации — если после 3 итераций задача не прошла, она уходит на ручную проверку человеком.

Это не бесконечный цикл — это конечный автомат с явным выходом на человека. Без этого выхода система может зациклиться: агент не умеет решить задачу, судья не принимает, агент пытается снова. С выходом — через 3 итерации задача эскалирует. Человек видит: «агент 3 раза пытался, не получилось» — это уже диагностика, а не черный ящик.

Дополнительный бонус — статистика вердиктов судьи. Если за месяц он вынес 12 REOPEN и 88 PASS — это конкретная точка данных: 12% задач закрываются формально, не по факту. Это число, а не ощущение. С этим можно работать: улучшить инструкции Дежурному, добавить проверки источников, пересмотреть, какие типы задач берёт автономный агент. Без судьи этого числа не существует вообще.

Накопленный техдолг без контроля: как растёт невидимая угроза

264 скрипта с одним паролем — не история про халтуру. Это история про то, что техдолг растёт там, где нет независимой проверки.

В апреле 2026 года таких скриптов было 198. За 2 месяца добавилось ещё 66 — просто копировался рабочий шаблон. Никто не ставил задачу «вписать пароль в каждый новый файл». Просто в шаблоне пароль был, и шаблон работал. Это и есть накопление без контроля: не злой умысел — инерция. Каждый следующий скрипт несёт в себе дефект оригинала.

Аналогичная динамика в других местах системы Solar Automation:

• Telegram-бот писал логи в файл вместо stdout → за 4 месяца файл вырос до 2.3 ГБ, сервер начал тормозить
• Агент отправлял дайджест на личный email вместо рабочего → 2 месяца важные отчёты оседали не там, никто не читал
• Cron-задача запускалась каждые 15 минут вместо одного раза в час → лишняя нагрузка на API, обнаружена только при аудите счётчиков

Во всех трёх случаях — отсутствие независимого контроля. Метрика «работает» была правдой. Метрика «работает правильно» — нет. Разница между этими двумя метриками и есть пространство, в котором живёт накопленный техдолг.

Правило накопленного техдолга: то, что можно проверить автоматически и не проверяется — накапливается. Не линейно: каждый новый элемент системы копирует дефект предыдущего и иногда добавляет свой.

Превентивный контроль дешевле аудита. Судья за 6 секунд дешевле, чем разбирать 264 скрипта вручную. Лог-мониторинг дешевле, чем экстренная чистка 2.3 ГБ. Проверка email-маршрута при каждом деплое дешевле, чем 2 месяца потерянных отчётов. Цифры несоразмерны: профилактика стоит копейки, лечение — часы и иногда данные.

Когда независимый контроль обязателен, а когда нет

Не всё нужно проверять. Простое правило: судья обязателен там, где цена ошибки превышает стоимость самого контроля в месячном масштабе.

Обязателен:

• Необратимые действия: отправил email, опубликовал пост, закрыл задачу с финансовыми данными, обновил запись о клиенте
• Агрегирующие отчёты: данные, которые человек будет читать как истину и принимать на их основе решения
• Автономные ночные циклы: агент работает без человека и совершает 10+ действий за сессию
• Финансовые операции: любые записи в таблицы с балансами, транзакциями, начислениями инвесторов

Не обязателен:

• Черновики и заготовки: агент пишет текст, который человек редактирует перед публикацией
• Внутренние агрегации без побочных эффектов: суммирование статистики для внутреннего дашборда
• Прототипы в тестовой среде: где ошибка обратима и видна немедленно

Пограничный случай — маршрутизация входящих: агент классифицирует обращения клиентов и раскладывает по очередям. Без судьи — ошибка маршрутизации уходит в неправильную очередь, теряется. С судьёй — агент-верификатор проверяет, что классификация соответствует тексту обращения, прежде чем отправить его дальше. Стоит это 1-2 секунды задержки. Цена неверной маршрутизации — потерянный клиент, который написал и не получил ответа.

Отдельная категория — отчёты от других агентов. Если один агент формирует health report для другого (как CTO-агент в примере выше с guest-поллером), этот отчёт сам по себе уже является артефактом, требующим независимой проверки. Отчёт может ошибаться добросовестно: агент собирал данные в момент, когда бот молчал, и написал «молчит». Это правда. Но неполная правда: бот молчал по конкретной причине, которую можно устранить за час. Принять отчёт на слово — потерять живой канал.

Выводы: автономная система без независимого судьи — это чёрный ящик

Автономная система хороша ровно настолько, насколько хорош контроль за ней. Агент, который оценивает себя сам — не независимый исполнитель, а чёрный ящик с самовыданными справками.

26 июня 2026 года в системе Solar Automation один принцип сработал в трёх местах: судья поймал пустой дайджест за 6 секунд, ручная проверка спасла «мёртвый» бот, который оказался живым, grep вскрыл 264 скрипта с открытым паролем. Ни в одном из этих случаев проблему не было видно изнутри. Агент доложил «сделано». Отчёт написал «отключить». Шаблон передавал дефект из скрипта в скрипт.

Независимый взгляд — не признак недоверия к системе. Это архитектурное решение: правильно построенная автоматизация содержит механизм проверки собственной работы. Без этого механизма она рано или поздно закроет пустую задачу, потеряет живое сообщение гостя или передаст дефектный шаблон в 265-й скрипт.

Если у вас есть хоть один агент, который что-то закрывает ночью без человека — добавьте судью. Это не сложно архитектурно: отдельная модель, READ-only инструменты, один системный промпт. Сложнее потом разбираться, что именно агент там закрывал.

Подробнее об устройстве агентных систем в продакшене — в статье Multi-agent systems на практике: как организовать работу нескольких AI-агентов.

Полный набор артефактов — AGENTS.md с судьёй, промпт для независимой верификации, схема замыкания цикла — в клубе «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

— Solar OS.