Агент, у которого есть доступ к CRM, почте или учётной системе, отчитывается текстом: «Черновик заказа создан». По этой фразе нельзя понять, создан ли черновик на самом деле, с теми ли позициями и не задел ли агент что-то по дороге. Ниже — формат записи приёмки для одной операции. Его заполняют до первого прогона и повторяют после каждого изменения модели, инструкции, инструментов или прав.
Тестирование ИИ-агента начинается с одной операции. Зафиксируйте вход и результат, который считаете допустимым. Сохраните трассу: какие инструменты агент вызвал и что они вернули. Конечное состояние системы проверяйте отдельно от агента, а не по его отчёту. Вердикт выносите по этому состоянию и по списку запретов. После смены модели, инструкции, коннектора или прав прогоняйте тот же случай заново, каждый раз в чистой тестовой среде.
Что проверять: состояние системы, а не ответ агента
В инженерной статье Anthropic об оценке агентов (январь 2026 года) есть три определения, которыми удобно пользоваться. Попытка (trial) — один прогон агента на заранее заданном входе. Трасса (trace) — запись прогона: вызовы инструментов, промежуточные результаты, ответы. Итог (outcome) — состояние внешней среды в конце прогона. Пример авторов: агент сообщает, что рейс забронирован, а итогом считается то, есть ли бронь в базе данных. Ещё они пишут, что ответы модели различаются от запуска к запуску, поэтому один и тот же случай прогоняют несколько раз и смотрят на стабильность.
Это методика поставщика моделей, а не независимое исследование, и я беру из неё только термины. Дальше — моя рекомендация, как превратить их в рабочий документ.
Из чего состоит запись приёмки
Возьмём простой случай. Менеджер пересылает агенту письмо клиента с просьбой о поставке. Агент должен найти клиента в CRM и создать черновик заказа. Подтверждать заказ, менять карточку клиента и писать клиенту ему нельзя. Пример условный: это образец заполнения, а не история клиента.
| Поле | Что записать | Пример для черновика заказа |
|---|---|---|
| Случай и вход | Текст задачи и входные данные. Между прогонами их не меняют | Письмо от тестового клиента ООО «Пример»: «Нужно 20 пачек бумаги А4 по 500 листов, доставка на следующей неделе» |
| Допустимый результат | Что должно появиться в системе и чего там быть не должно | Один новый черновик у ООО «Пример»: позиция «Бумага А4, 500 листов», количество 20, статус «черновик». Заказ не подтверждён, карточка клиента не изменена, писем клиенту нет |
| Версии | Модель, версия инструкции, список инструментов и права на момент прогона | Инструменты: поиск клиента, поиск товара, создание черновика. Права: чтение справочников, запись только черновиков |
| Трасса | Фактические вызовы инструментов, их параметры и ответы | Поиск клиента → найден один. Поиск товара → найдена одна позиция «Бумага А4, 500 листов». Создание черновика → успех, номер черновика |
| Независимая проверка | Кто и как проверяет конечное состояние, не спрашивая агента | Сотрудник или скрипт под отдельной учётной записью только на чтение сверяет черновики, карточку клиента и исходящие письма |
| Вердикт | «Принято», «не принято» или «разобрать» — с причиной | Принято: состояние совпало с допустимым, запреты не нарушены |
Главное поле здесь — независимая проверка. Проверяющий не читает финальное сообщение агента, он сам идёт в систему. Трасса нужна для другого: объяснить, почему состояние получилось именно таким.
Как выносить вердикт, когда сигналы расходятся
Простые случаи решаются сами. Состояние совпало, трасса полная, запреты целы — принято. Агент отчитался об успехе, а черновика нет — не принято. Сложнее, когда трасса и состояние говорят разное.
| Что видим | Вердикт | Что делать |
|---|---|---|
| Черновик правильный, но трассы нет или она обрывается | Разобрать | Выяснить, почему журнал не записался. Без трассы следующий сбой будет труднее объяснить |
| Черновик правильный, но один из вызовов вернул ошибку | Разобрать | Проверить, не повторил ли агент вызов и не создал ли второй черновик. Найти, где сломался инструмент |
| Нарушен запрет: заказ подтверждён, карточка изменена или клиенту ушло письмо | Не принято | Даже при правильном черновике. Сначала пересмотреть права и инструкцию, потом повторить прогон |
| Черновик есть, но с другой позицией или количеством | Не принято | Сравнить трассу с допустимым результатом и найти шаг, на котором агент ошибся |
«Разобрать» — не вежливая форма отказа. Это честный статус: результат на месте, но вы не понимаете, как он получился. Засчитывать такой прогон автоматически я бы не стал.
Отдельно ищите побочные эффекты, о которых при описании допустимого результата никто не подумал: второй черновик у соседнего клиента, задачу менеджеру, исправленный контакт. Проще всего сравнить снимок тестовой среды до прогона и после него.
Какие случаи взять
Универсального числа случаев нет, и я его не предлагаю. Набор зависит от того, во что обойдётся ошибка агента в этой операции. Начните с трёх типов.
- Обычный случай: клиент и товар в письме однозначны. Если агент проваливает его, остальное проверять рано.
- Пограничный: две похожие позиции в каталоге, количество прописью, у клиента два юрлица. Здесь видно, уточняет агент или угадывает.
- Ошибка на входе или в системе: клиента нет в CRM, CRM не отвечает, товар снят с продажи. Допустимый результат тут — отсутствие черновика и понятное сообщение менеджеру, а не придуманный заказ.
Хорошие случаи берутся из живой работы: письма, на которых ошибались люди, ситуации, о которых спорили в отделе. Перед тестом их обезличивают. На каждый случай заводится своя запись приёмки.
Повтор после изменений
Главная польза записи появляется на втором прогоне. Тот же вход, тот же допустимый результат, та же проверка. Меняется только то, что вы поменяли в агенте. Сравниваете две записи: трассу с трассой, состояние с состоянием.
Перед каждым повтором верните тестовую среду в исходное состояние: удалите созданный черновик или поднимите чистую копию. Иначе агент увидит черновик от прошлого прогона и либо создаст дубль, либо решит, что работа уже сделана. Сравнение в обоих случаях испорчено.
| Что изменилось | Чем рискуете | На что смотреть при повторе |
|---|---|---|
| Модель: вышла новая версия или вы переключились на другую | Агент иначе понимает тот же вход | Все случаи, особенно пограничные: выбор позиции, уточняющие вопросы |
| Инструкция агента | Правка одного правила задевает соседнее | Случаи, которых правка не касалась |
| Инструмент или коннектор: другие поля CRM, другой формат ответа | Вызов падает или пишет не в то поле | Трасса вызовов и случаи с ошибкой в системе |
| Права агента | Агент получает лишний доступ или теряет нужный | Запреты: может ли он теперь подтвердить заказ или изменить карточку |
В поле «Версии» записывайте, что именно поменялось. Если вы обновили модель и права одновременно, а после этого сломались две вещи, причину найти труднее. Меняйте по одному.
Один и тот же случай прогоняйте больше одного раза. Сколько именно, решает цена ошибки, но одна удачная попытка ещё не говорит о стабильном поведении.
Как мы принимали публикацию на своём сайте
Похожую приёмку мы провели для собственной публикации. 13 октября 2026 года на сайт выходила статья о внедрении ИИ на производстве в ФАЗА. Запись о развёртывании в GitHub была, но приёмка на ней не закончилась. Мы сделали 17 проверок: страница и её файлы отвечали кодом 200, а опубликованные версии совпадали с локальными по контрольной сумме. Вёрстку проверили на ширине 1440 и 390 пикселей. Публикацию приняли после ревью этих результатов.
19 октября, готовя этот текст, мы перепроверили только страницу статьи: она отвечает кодом 200 и совпадает с принятой версией. Остальные файлы и вёрстку в этот раз не смотрели.
Это приёмка нашей публикации, а не тест агента. Надёжность какой-либо системы она не доказывает и серию прогонов не заменяет. Она показывает сам ход: заранее решить, что считается правильным, и проверить это снаружи.
Чего запись приёмки не даёт
Одна запись — один случай. Процента надёжности она не даёт, и по набору записей его тоже не стоит выводить: случаи вы подбирали сами. Записи помогают решить, пускать ли агента в работу, но решение принимает человек, который отвечает за процесс.
Если агент отвечает по документам и ничего не меняет в системах, удобнее матрица приёмки ответов. Права, ручную проверку и окупаемость агента, который работает с действиями, я разбирал на примере с входящими счетами. Здесь только один вопрос: сделал ли агент то, что надо, и ничего сверх этого.
Начните с операции, которую агент будет выполнять первой. Заполните запись до первого прогона, пока допустимый результат не подогнан под то, что агент уже выдал.
Источники и методика
Определения попытки, трассы и итога, а также тезис о повторных прогонах взяты из статьи Anthropic Demystifying evals for AI agents от 9 января 2026 года. Это методика поставщика моделей. Показатели и цифры из неё в статью не включены.
Формат записи приёмки, правила вердикта и таблица изменений — рекомендации автора, а не результаты замеров. Пример с черновиком заказа в CRM вымышлен и как тест не выполнялся.
Сведения о публикации на dffring.com — внутренние записи приёмки от 13 октября 2026 года и повторная проверка страницы 19 октября 2026 года.