Подрядчик показывает экран: агент выполнил запрос, сервис ответил, в отчёте появилась зелёная отметка. Можно принимать работу? Подождите. Возможно, проверка вообще смотрела на другой объект.

При техническом аудите одной агентной системы мы воспроизвели именно такую ситуацию. Тестовое создание вернуло объект с номером 123. Следующий запрос искал номер 999 и получил пустой список. Система всё равно поставила статус «результат проверен». Она проверяла, что запрос завершился без исключения. Совпадение объекта и его полей никто не проверял.

Это был изолированный тест с подставными ответами сервисов, без клиентских данных и действий в рабочих кабинетах. Он не доказывает чьих-либо потерь. Зато показывает, как получить убедительное «готово» без доказательства работы.

В том же аудите прошли 126 штатных тестов. Противоречия здесь нет: тесты подтверждают только те условия, которые в них заложили. Можно аккуратно проверить сотню функций и не проверить, что случится после обрыва связи.

Заказчику нужно договориться с подрядчиком, что считается выполнением, и увидеть заранее выбранные проверки. Особенно если ИИ уже меняет документы, карточки товаров или настройки рабочих сервисов. Я бы включил в приёмку шесть пунктов.

Начните с скучных вещей: аккаунт, рабочий или тестовый кабинет, номер объекта, версия документа. Именно их легко потерять за красивой демонстрацией.

Условный пример: агент обновляет срок задачи №123, получает подтверждение записи, читает список задач и отчитывается об успехе. Но проверять он может старую задачу с похожим названием или первую страницу списка, где №123 вообще нет.

Нормальная проверка привязана к результату записи: открыть задачу №123 в нужном рабочем пространстве и сравнить срок с заданным. Если заодно поменялся исполнитель, это тоже должно попасть в отчёт. Для файла нужны точный путь или ссылка и проверяемая версия; для публикации на сайте — публичный адрес, а не только локальный предпросмотр.

Попросите показать пару «ожидали → получили» для одного безопасного тестового объекта. Изменяли три поля? Проверить нужно все три. Успешный вход в аккаунт их правильности не доказывает.

Затем подставьте неверный номер в тестовой среде. Ожидаемый результат — видимая ошибка верификации. Система, которая на неправильном объекте говорит «готово», проверку не прошла.

С пакетными действиями начинается арифметика. Допустим, нужно обновить десять карточек товара. Сервис обработал запрос, но два изменения отклонил: в одной карточке нет обязательного поля, к другой не хватает прав. Сам запрос при этом мог получить технически успешный HTTP-ответ.

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

В аудите подставные ответы с бизнес-ошибками проходили как обычный результат. Ошибка лежала внутри ответа, а обработчик смотрел только на внешний статус. Уверенный текст агента маскировал пробел в проверке.

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

Запросите три числа: сколько объектов входило в задачу, сколько система получила и сколько успешно обработала. Если общее количество неизвестно, пусть так и будет написано. «Всё проверено» нельзя выводить из «больше данных не загрузилось».

«Принято», «в очереди», «выполнено» и «проверено» отвечают на разные вопросы. Сервис может принять запрос и закончить работу позже. Письмо может уйти из отправляющей системы, но это ещё не подтверждение прочтения. Файл может появиться на сервере, но по публичной ссылке всё ещё отдаётся старая версия.

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

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

В аудите отложенный ответ терял сведения, необходимые для продолжения. Отсутствие данных в реальном кабинете этим не подтверждалось.

Нарисуйте цепочку: запрос подготовлен → принят сервисом → изменение применено → результат сверили. У каждого перехода своё основание. Для принятого запроса это квитанция; для проверки — чтение нужного объекта и сравнение с заданием.

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

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

Что будет после нажатия «повторить»? Если система просто выполнит создание ещё раз, появится риск дубля. Но и объявить первую попытку неудачной она пока не вправе: о её результате ничего не известно.

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

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

Так выясняется, умеет ли система остановиться, когда ей не хватает сведений.

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

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

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

Для существенной автоматизации покажите на тестовом экземпляре неудачное обновление и восстановление. Сверять нужно конфигурацию вместе с версией программы. Копия исполняемого файла не заменяет резервной копии нужных настроек.

Защиту журнала проверяют намеренно испорченной записью в отдельной копии. Перезапуск не должен превращать повреждённую историю в «всё корректно». Рабочий журнал компании для такого теста не подходит.

После демонстрации в аккаунте автора остаётся вопрос: сможет ли этим пользоваться команда заказчика?

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

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

После прогона сотрудник должен знать, где увидеть ошибку, как остановить дальнейшие действия и кому передать неизвестный исход. Если для любого отклонения нужен автор, это сопровождаемое решение. Оно может быть полезным; просто его нельзя принимать как самостоятельный продукт без участия подрядчика.

Карточка приёмки, которая помещается в задачу

Заполните шаблон до запуска: одна карточка на один сценарий.

Сценарий: какое действие выполняем и в каких границах.

Среда и объект: аккаунт, тестовая/рабочая среда, ID или точная ссылка.

Ожидаемый итог: какие поля, файлы или состояния должны измениться; что трогать нельзя.

Доказательство: как повторно прочитаем результат и с чем сравним.

Полнота: сколько объектов ожидали, получили и обработали; какие пропущены.

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

Вердикт: принято / частично выполнено / требует проверки; ответственный за продолжение.

Это не попытка превратить заказчика в тестировщика на полную ставку. Подрядчик готовит проверки и доказательства; заказчик согласует критерии и смотрит выбранные сценарии. Глубина зависит от последствий: для черновика заголовков и для массового изменения каталога она разная.

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