ТЗ на AI-агента: полномочия, инструменты и критерии приёмки

Чем ТЗ на AI-агента отличается от задания на чат

AI-агент может не только подготовить ответ, но и вызвать инструмент: создать задачу, изменить запись или отправить документ. Поэтому требования должны описывать границы действия и способ проверки результата. Хорошая формулировка «помогает менеджеру» слишком широка для оценки: нужно знать, что агент делает самостоятельно, что предлагает и что выполняет только после подтверждения.

Этот материал — практическая структура задания на ограниченный бизнес-сценарий. Учебные примеры не описывают внедрённый клиентский проект. Скачиваемый бриф помогает определить полномочия, данные, проверку и остановку системы. Точность, стоимость и скорость оцениваются на выбранной реализации, а не обещаются одинаковыми для любого агента.

Выберите одну завершённую задачу

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

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

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

Составьте реестр инструментов

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

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

OWASP рассматривает избыточные полномочия и небезопасное использование инструментов как риски агентных систем. Практический вывод для ТЗ — проверять разрешения вне модели и ограничивать область каждой операции. Это не обещает абсолютной защиты, но делает полномочия проверяемыми и доступными для аудита.

Разделите знания и инструкции

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

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

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

Опишите безопасное исполнение и повтор

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

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

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

Подготовьте набор оценки до настройки

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

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

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

Задайте формат ответа и неопределённости

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

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

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

Эксплуатация и остановка

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

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

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