Самопроверка AI-агентов: как система отзывает PASS

Самопроверка AI-агентов — это контур, где система проверяет не только входные данные, но и собственное решение до внешнего действия. 14 июля 2026 в Solar OS такой контур снял статус успеха с финансового импорта, публикаций и камер: 156 тестов прошли, 7 публикаций сверялись отдельно, 9 камер подтверждались двумя циклами. Главный результат дня — не новая функция, а право системы отозвать свой PASS.

Для бизнеса это скучная, но дорогая часть автоматизации. Красивый AI-агент умеет ответить клиенту, собрать отчёт или нажать кнопку. Рабочий AI-агент умеет остановиться, когда доказательств недостаточно. В Solar OS я всё чаще смотрю не на скорость действия, а на качество отказа: где система не поверила себе, где потребовала второй источник, где оставила цель открытой до следующего естественного цикла.

Почему PASS без самопроверки опасен

Обычная автоматизация любит бинарный мир: задача выполнена, тест зелёный, отчёт готов, публикация ушла. Для внутреннего скрипта этого хватает до первой сделки, первой живой CRM и первого финансового отчёта, где ошибка стоит не строчки в логе, а доверия владельца. В таких системах PASS должен быть не финальной надписью, а временным статусом, который можно снять свежим фактом.

В Solar OS 14 июля это проявилось сразу в нескольких контурах. Финансовый импорт проходил через серии тестов: сначала 143 из 143, затем 150 из 150, затем 156 из 156. На бумаге каждый этап выглядел законченным. Независимая проверка каждый раз находила новую дырку: лишнее право на колонку, скрытую колонку, слишком широкую обёртку вокруг доступа. Если бы система принимала первый зелёный прогон как истину, живой финансовый слой получил бы лишнюю поверхность риска.

Здесь полезно разделить два вида контроля. Тест проверяет заявленное поведение: функция получила данные, вернула ожидаемый результат, не упала. Самопроверка проверяет рамку, в которой этот тест имеет смысл: кто имеет доступ, какие поля видит агент, где лежит скрытая колонка, можно ли повторить запуск в другом порядке. Первый слой отвечает за корректность кода. Второй слой отвечает за доверие к решению.

Проблема малого бизнеса в том, что автоматизация часто внедряется по принципу «работает на демо, отдаём людям». В демо нет конфликтов прав, старых таблиц, ночных запусков, повторных публикаций, устаревших снимков и внешних подрядчиков. На живом контуре эти детали появляются через 3-7 дней, когда владелец уже поверил, что робот всё держит. Поэтому я закладываю право системы забрать назад собственный успех ещё на уровне архитектуры.

PASS должен иметь срок годности. Для финансового импорта это может быть один запуск с перемешанным порядком тестов. Для камер — второй естественный цикл после восстановления. Для публикаций — проверка записи в ledger до и после canonical publisher. Для CRM — несколько десятков реальных событий в теневом режиме. Если срок годности не задан, зелёная галочка превращается в декоративную наклейку на панели управления.

Как устроен контур самоотзыва

Контур самоотзыва начинается с простого правила: агент не закрывает задачу только потому, что сам сделал действие. Он должен доказать действие внешним следом. В публикациях это URL, запись canonical publisher, строка в аналитическом реестре и повторное чтение обеих записей. В финансах это сверка прав, структуры таблиц, порядка запуска и результатов независимого набора тестов. В камерах это свежий снимок, код ответа, время последнего кадра и повтор цикла.

Внутри Solar OS такие проверки не собраны в одну волшебную панель. Они лежат в разных местах: pytest для кода, SQL-аудит для данных, cron healthcheck для сервисов, content dedup для публикаций, отдельные watchdog-скрипты для инфраструктуры. Общий принцип один: статус задачи считается предварительным, пока другой процесс не подтвердил результат через свой канал.

14 июля финансовый импорт хорошо показал эту механику. Сначала тесты подтвердили базовый сценарий. Потом независимая проверка стала смотреть на то, что тесты не обещали проверять: скрытые колонки, лишние права, ширину обёртки. После каждой находки основной набор расширялся. Число тестов выросло до 156, но важнее было другое: порядок запуска перемешивали, чтобы убрать зависимость от счастливой последовательности. Живая система при этом осталась нетронутой.

Для AI-агента это критично. Модель может уверенно объяснить своё решение, но уверенность не является доказательством. Доказательством становится независимый факт: запись в базе, ответ API, контрольная сумма, повторное чтение, свежий timestamp, совпадение суммы после пересчёта. Если агент умеет только красиво отчитаться, он годится для черновика. Если агент умеет принести проверяемый след, его можно подпускать к рабочему процессу.

Я использую 4 слоя самоотзыва. Первый — локальная валидация: формат, обязательные поля, права, лимиты. Второй — независимый аудит: другой скрипт или другой агент смотрит на результат не тем же кодом, который его создал. Третий — временной повтор: система ждёт следующий цикл, чтобы отличить восстановление от случайной удачи. Четвёртый — человеческий gate для решений с деньгами, удалением данных, прод-деплоем и внешней коммуникацией.

Такой контур выглядит медленнее, чем прямой запуск. На практике он экономит время владельца, потому что снимает десятки спорных ручных проверок. Человек видит не общий текст «всё готово», а конкретный статус: что проверено, какой источник подтвердил, где PASS снят, какое решение осталось за владельцем. Машина перестаёт просить доверия и начинает приносить доказательства.

Публикации: почему один канал важнее скорости

Отдельная линия дня — 7 публикаций. Счётчик дошёл до 6 из 7, но аудит нашёл 3 поста во «ВКонтакте» без полного следа проверки. Один пост появился из команды для чтения: старая программа приняла её за текст публикации. Это неприятный класс ошибок, потому что внешний мир уже видит результат, а внутренняя система ещё считает себя аккуратной.

Решение здесь не в том, чтобы ругать агента за один странный текст. Правильная правка — убрать множественные пути, через которые текст может попасть наружу. В Solar OS после такого случая остаётся один канал публикации: canonical publisher. Он проверяет дубли, фиксирует DAY-GUARD, пишет в ledger, возвращает canonical URL и даёт возможность повторно прочитать запись. Всё остальное должно быть источником черновика, а не внешним действием.

Публикации особенно хорошо показывают разницу между действием и доказательством. «Пост отправлен» — слабое утверждение. Сильное утверждение выглядит так: publisher принял текст, dedup не нашёл повтор за 30 дней, DAY-GUARD не заблокировал второй пост за сутки, сообщение опубликовано, canonical URL получен, запись в ledger прочитана после публикации, marketing_publications обновлён idempotent-запросом, повторное чтение совпало. Звучит занудно. Зато меньше шансов, что команда для чтения станет публичным постом.

Для малого бизнеса логика такая же. Если менеджер может отправить клиенту счёт из CRM, из таблицы, из мессенджера и из старого шаблона в папке, рано или поздно клиент получит не ту версию. Автоматизация должна сокращать число внешних путей. Пусть внутри будет много черновиков, подсказок и проверок, но наружу действие выходит через один контролируемый шлюз.

В моём контуре посты, письма, счета, уведомления и финансовые записи имеют разные уровни риска. Чем выше риск, тем меньше прямых путей. У клубного поста один набор проверок. У внешней публикации другой. У платежа и удаления данных появляется approval-gate. У клиентского прод-деплоя — отдельное решение человека. Это не бюрократия ради красивой схемы, а способ не превращать AI-агентов в группу быстрых стажёров с доступом ко всем кнопкам.

Камеры и временной повтор: один удачный цикл не считается

Камеры дали короткий пример того, почему время должно быть частью проверки. В 18:46 система имела свежий успешный цикл 9 из 9. В 20:00 одна камера ответила ошибкой, снимок устарел, и общий счёт за день упал с 1 успеха из 8 целей до 0 из 8. В 20:20 все 9 камер вернулись. Статус успеха всё равно остался снятым до второго естественного цикла.

Это правило полезно для любых интеграций, где внешний сервис может моргнуть. Если WhatsApp API ответил один раз, это ещё не стабильная линия. Если банк отдал выписку один раз, это ещё не корректный импорт. Если камера вернулась через 20 минут, это ещё не доказательство, что мониторинг снова здоров. Один успешный кадр после ошибки показывает восстановление момента, а не устойчивость процесса.

Временной повтор особенно важен для AI-агентов, которые работают в фоне. Пользователь не сидит рядом с ними весь день. Он видит итоговую карточку: зелёный, жёлтый или красный статус. Если зелёный выставляется сразу после одного удачного события, панель начинает врать владельцу. Если зелёный требует второго цикла, статус становится менее эффектным, но ближе к реальности.

У такого подхода есть цена: часть целей остаётся открытой дольше. 14 июля я сознательно оставил общий успех снятым, хотя все 9 камер уже ответили. Машина получила право сказать: «сейчас лучше подождать». Для владельца бизнеса это непривычно, потому что автоматизация обычно продаётся как ускоритель. На рабочем контуре иногда ценнее замедление на 20-40 минут, чем быстрый зелёный статус с плохой памятью.

То же правило применимо к лидам и CRM. Если AI-агент верно классифицировал одну заявку, его нельзя сразу выпускать на всех клиентов. Если он 50 раз подряд верно определил тип обращения в теневом режиме, можно обсуждать следующий уровень доступа. Если после запуска он снова ошибся на новом классе заявки, статус должен откатиться: агент остаётся в системе, но внешнее действие забирается до правки сценария.

Факты вместо красивой классификации

В тот же день Hawaiian Designs показал другую сторону самопроверки: система должна уметь оставить часть данных без красивой этикетки. Каталог прошёл сверку 383 товаров с 38 страницами. Из них 240 товаров удалось точно разложить по семействам, а 141 оставили без выдуманной классификации. Живой магазин не меняли: имена и адреса ждали одобрения владельца.

Для AI это болезненная дисциплина. Модель умеет достроить недостающий смысл, придумать категорию, сгладить пропуск и сделать таблицу визуально полной. В SEO, каталоге, финансах и клиентских отчётах такая полнота часто вреднее пустого поля. Пустое поле честно показывает, что факта нет. Выдуманная категория создаёт долг: кто-то потом примет её за правду и начнёт строить на ней следующую автоматизацию.

В Solar OS я предпочитаю таблицу с дырками, если дырки подписаны. 240 подтверждённых товаров ценнее, чем 383 «примерно понятных». 25 подтверждённых строк ДДС ценнее, чем полный отчёт, где часть строк натянута ради завершённости. 37 121 337 IDR к доплате УК имеет смысл только тогда, когда источник каждой строки известен. Деньги плохо переносят художественные догадки, какая жалость для любителей красивых презентаций.

Самопроверка здесь сводится к маркировке происхождения данных. У каждого поля должен быть источник: страница каталога, выписка, бронь, сообщение клиента, ручное подтверждение владельца. Если источника нет, поле получает статус unknown, pending или needs_approval. Такой статус раздражает только до первого спора. Когда спор появляется, он спасает часы переписки и показывает, где заканчиваются факты.

Эта дисциплина напрямую связана с SEO и GEO. Поисковые системы и генеративные ответы любят конкретику, но не прощают фальшивую конкретику. Можно указать дату, число товаров, сумму, количество броней, если источник есть. Нельзя превращать пустые места в уверенные обещания. Контент, CRM и финансы должны жить по одному правилу: лучше меньше фактов, но каждый с паспортом.

Как внедрить самопроверку в малом бизнесе

Начинать стоит не с большой платформы, а с карты внешних действий. Выпишите 10-20 операций, после которых ошибку увидит клиент, банк, подрядчик, поисковик или владелец: отправка счёта, публикация поста, изменение цены, запись расхода, звонок клиенту, пересчёт остатка, удаление строки, запуск рассылки, обновление карточки товара. Для каждой операции нужен ответ на 3 вопроса: что считается доказательством, кто имеет право снять PASS, когда требуется человек.

Затем добавьте журнал решений. Не общий лог на 100 тысяч строк, а понятный след: время, агент, действие, входные данные, источник факта, результат проверки, ссылка на объект. Для публикации это URL и id сообщения. Для финансов — id строки, сумма, валюта, источник. Для камеры — endpoint, код ответа, возраст снимка. Для CRM — id лида, классификация, следующий шаг, причина отказа от действия.

Третий шаг — разделить проверки на pre-flight и post-flight. Pre-flight смотрит до действия: права, лимиты, обязательные поля, свежесть данных, дубли. Post-flight проверяет, что действие случилось именно там, где нужно: запись появилась, URL доступен, сумма совпала, счётчик обновился, второй источник прочитал то же состояние. Многие внедрения ломаются потому, что имеют только pre-flight. Скрипт уверенно ушёл наружу, а потом никто не проверил, что внешний мир принял правильный результат.

Четвёртый шаг — ввести статусы, которые не притворяются финалом. Например: draft, ready_for_check, published_pending_ledger, tracking, pass_revoked, waiting_second_cycle, needs_human. Эти слова скучные, но они дают системе язык для честного отчёта. Владелец видит, что задача не потерялась, а ждёт конкретного подтверждения. Агент видит, что у него нет права перескочить через проверку ради красивого done.

Пятый шаг — убрать параллельные внешние каналы. Если публикация выходит через canonical publisher, ручной скрипт не должен иметь доступа к тому же каналу без отдельного решения. Если счёт выставляется из CRM, старый шаблон должен стать архивом. Если клиентское сообщение отправляет бот, тестовый процесс не должен иметь production-токен. Сложность системы часто растёт не от количества агентов, а от количества обходных дорожек.

Последний шаг — договориться, какие решения остаются у человека. В Solar OS это крупные расходы, удаление данных, прод-деплой нового сервиса, публикация клиента без письменного OK и любые внешние действия, где цена ошибки выше скорости. AI-агент может собрать факты, предложить решение и подготовить payload. Нажимать кнопку он получает право только после прохождения своего уровня допуска.

Для первого внедрения не надо покупать отдельный наблюдательный комплекс. Достаточно таблицы или маленькой базы, куда каждый агент пишет 8 полей: task_id, risk_level, source_object, proposed_action, proof_url, proof_status, revoke_reason и next_check_at. Через неделю в этой таблице уже видно, какие процессы чаще всего теряют доказательства. Обычно всплывают 2-3 слабых места: старый ручной скрипт, общий токен, неподписанный источник данных или слишком ранний зелёный статус.

После этого полезно назначить владельца для каждого типа отказа. Техническую ошибку читает CTO, спорный контент уходит в QA, деньги идут к Finance, внешний клиентский запуск остаётся за Product или Юрием. Если все отказы падают в один общий чат, система быстро превращается в шум. Если у каждого отказа есть адресат и срок, самоотзыв PASS становится рабочим маршрутом, а не красной лампочкой для красоты.

Ещё один практичный приём — хранить примеры снятого PASS рядом с инструкцией агента. Не абстрактное «будь аккуратен», а конкретные кейсы: 156 тестов прошли, но права оказались шире нужного; 9 камер ответили, но нужен второй цикл; 383 товара найдены, но 141 без подтверждённой категории. Такие примеры лучше длинного регламента, потому что агент видит границу на живых данных.

Раз в неделю стоит смотреть не только на успешные задачи, но и на снятые PASS. Если за 7 дней один и тот же агент 3 раза теряет proof_url, проблема не в конкретной задаче, а в инструкции или доступах. Если один сервис постоянно ждёт second_cycle, значит healthcheck слишком оптимистичен. Если один канал часто требует human_gate, его надо поднять по уровню риска. Такая статистика скучная, зато она показывает место следующей инженерной правки.

Что забрать в свою систему

Минимальный чек-лист самопроверки можно внедрить за один вечер. Для каждого AI-агента добавьте поле proof_required: что он обязан принести перед закрытием задачи. Добавьте proof_reader: какой независимый процесс перечитает результат. Добавьте revoke_condition: какое событие снимает PASS. Добавьте check_after: когда статус можно считать устойчивым. Добавьте human_gate: какие суммы, типы данных или внешние действия требуют владельца.

Для финансового импорта proof_required может включать число строк, сумму по валютам, список скрытых колонок, перечень прав и контрольный пересчёт после перемешанного порядка тестов. Для публикаций — dedup, DAY-GUARD, canonical URL, ledger readback и запись в marketing_publications. Для камер — количество устройств, возраст снимка, второй цикл после восстановления. Для каталога — список подтверждённых полей и отдельный список unknown без попытки угадать.

Хорошая формула для отчёта агента: «сделал действие, доказал таким-то источником, нашёл такой-то риск, PASS снят или оставлен до такой-то даты». Она длиннее обычного «готово», но владелец получает управляемую картину. Когда таких отчётов 10-20 в день, разница становится заметной: человек принимает решения там, где нужен контекст, а машина спокойно держит рутину.

14 июля 2026 Solar OS не стала быстрее из-за самопроверки. Она стала честнее. Финансовый импорт не получил лишних прав, публикации не ушли через старый обходной путь, камеры не вернули зелёный статус по одному кадру, каталог не получил выдуманные категории. Для системы, которая работает каждый день, это нормальная планка: не обещать без факта, не закрывать без следа, не гордиться зелёной галочкой, если свежие данные уже её сняли.

У меня это всё крутится 24/7. Кому интересно как устроено внутри — клуб «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/. По теме рядом пригодятся разборы про теневой режим автоматизации и стоп-краны в бизнес-автоматизации.

Solar OS.