Термин «ИИ-агент» в разговоре чаще всего рисует образ автономного сотрудника, который берет задачу и сам доводит ее до конца. Такая картинка годится для презентации и слабо годится для проектирования системы. Инженеру полезнее другой образ: узел с ограниченным набором инструментов, четкими границами данных и понятной точкой ответственности. При таком взгляде разговор смещается с ожиданий на устройство: какие входы у этого узла, какие выходы, где обрыв связи, кто отвечает за результат. Дальше разбираю рабочий контур такого узла: какие данные он видит, какие действия выполняет, где хранятся журналы его работы, как ему выдаются права и в какой момент задача уходит человеку.
Что агент видит
Область данных, доступная агенту, задается явно: конкретные ящики почты, конкретные папки в хранилище документов, конкретные таблицы или базы. Все остальное для агента подобно оборудованию за пределами цеха: оно существует физически, но соединения к нему отсутствуют, и агент обходится без него в работе.
Широкий доступ «на всякий случай» — частая ошибка проектирования. Логика здесь понятная: шире доступ, больше доступных действий, меньше шанс упереться в стену на новой задаче. Цена ошибки раскрывается при разборе инцидента. Чем больше лишних источников читал агент, тем труднее восстановить наблюдаемую цепочку от входа до действия: журнал фиксирует обращения к источникам, а полезные события теряются среди лишних данных.
Правильная последовательность обратная: сначала описывается задача агента, затем под задачу выделяется минимальный набор источников, и только при явном расширении задачи список источников растет. Тот же принцип знаком инженерам по датчикам на линии: сенсор занимает место, продиктованное технологическим процессом, а удобство прокладки кабеля остается вторичным критерием. Граница данных определяет и границу ответственности: список источников агента становится частью технической документации системы, наравне со схемой подключения датчиков.
Что агент делает
Набор действий агента описывается конкретным списком инструментов с проверяемыми параметрами: прочитать обращение, извлечь поля, создать карточку в системе, отправить уведомление, задать уточняющий вопрос отправителю. Общая формулировка «работает с обращениями клиентов» скрывает границы и мешает понять, что происходит на каждом шаге.
У каждого инструмента свои ограничения: допустимый диапазон значений на входе, реакция на пустой результат, лимит повторов при сбое связи. Действия, которые меняют состояние систем компании, — создание записи, отправка письма, изменение статуса заявки, — отделяются от действий, которые только читают данные. Такое разделение знакомо инженерам по контурам управления: датчик снимает показание и передает его дальше, привод меняет положение механизма, и смешивание этих ролей в одном блоке считается плохой практикой. У агента работает та же логика: инструмент чтения обращения устроен и протестирован иначе, чем инструмент, который создает запись в учетной системе и запускает цепочку дальнейших действий.
Журналы
По каждому шагу журнал фиксирует разрешенные политикой сведения о входе, выбранный инструмент, параметры вызова, результат, время выполнения и версию правил. Персональные данные маскируют или исключают из журнала по правилам конкретного контура. Формат близок журналу событий в промышленной автоматике: строка на событие, метка времени, идентификатор источника, значение.
Такой журнал закрывает несколько задач. При разборе ошибки инженер восстанавливает наблюдаемую цепочку от входного сообщения до итогового действия и находит шаг, где результат разошелся с ожидаемым сценарием. При сверке с регламентом специалист проверяет действие по версии правил, которая была подключена в момент обращения. Для оценки качества журнал дает статистику по инструментам, типам обращений и причинам передачи дежурному. Он показывает, какие данные, правила и инструменты участвовали в цепочке. Внутреннюю причинность вывода модели журнал объяснить неспособен. Журнал входит в базовые требования к системе вместе со способностью агента выполнять действия.
Права доступа
Агент получает собственную учетную запись, отдельную от учетных записей людей, с минимальным набором прав под конкретный список инструментов. Каждое право привязывается к конкретному инструменту и пересматривается при изменении задачи: агент, которого расширили с чтения почты до создания карточек в учетной системе, получает права на новый инструмент отдельным шагом, а прежний набор прав отзывается, когда инструмент выходит из эксплуатации. Модель знакома инженерам по промышленным сетям: контроллер получает доступ к конкретной шине и конкретному диапазону регистров, и расширение этого доступа проходит через отдельное согласование при каждом изменении конфигурации.
Отдельная тема — доступ к персональным данным. Когда агент отвечает на вопрос о записи конкретного человека, система сверяет идентификатор пользователя и его права на эту запись. Журнал таких обращений хранится и открывается сотрудникам по политике компании и применимым требованиям. Срок хранения, состав событий и круг доступа задаются для конкретного контура до запуска.
Момент передачи человеку
Передачу человеку запускают явные правила для конкретной задачи. Агент останавливается, когда отсутствуют обязательные данные, документы противоречат друг другу, запрос выходит за рамки разрешенных инструментов или действие относится к категории с обязательным подтверждением сотрудника.
Проектирование отказа — отдельная инженерная задача, и решают ее до запуска системы. Для каждого правила команда задает причину остановки, получателя задачи, состав передаваемого контекста и следующий разрешенный шаг.
Здесь уместен подтвержденный пример из практики: агент разбирает входящий поток заявок в лизинговой компании, которая занимается лизингом контейнеров, определяет тему обращения и адресата. Решение о дальнейшей обработке принимает сотрудник компании.
Что ломает такие системы после запуска
После запуска система зависит от того, кто отвечает за актуальность ее правил. Первая причина отказа — отсутствие роли, которая ведет базу знаний и обновляет правила: регламент компании меняется, а агент продолжает работать по версии, подключенной на момент запуска. Роль владельца правил — такая же обязательная часть системы, как дежурная смена у промышленной линии.
Вторая причина — попытка охватить агентом все задачи сразу. Список инструментов быстро разрастается за пределы проверенного и покрытого журналом объема, а для новых зон отсутствуют явные правила остановки и передачи человеку.
Третья причина — оценка агента по демонстрации на этапе презентации системы. Демонстрация показывает подготовленный сценарий. Рабочую картину дает журнал за выбранный компанией период: он показывает распределение успешных и ошибочных сценариев, передачи человеку и сбои инструментов.
Как оценивать
Работу агента измеряют по нескольким показателям. Доля задач, закрытых агентом без участия человека. Доля задач, переданных дежурному по явным правилам, и распределение причин передачи. Среднее время обработки обращения от получения до закрытия. Количество случаев, где журнал позволил восстановить наблюдаемую цепочку ошибки, и случаев, где данных журнала для этого оказалось мало. Отдельно считают повторные сбои после исправления: этот показатель показывает, сохраняется ли исправленное поведение после обновления правил.
Эти показатели считают на собственных данных за выбранный период. Общая цифра экономии здесь лишена смысла: ответ берется из журнала конкретной компании и сравнения с ее исходным процессом.
Узкая область данных, явный набор инструментов, журнал на каждом шаге и правила передачи человеку создают контролируемую основу рабочего контура. Гарантия безошибочной работы здесь отсутствует, зато команда может ограничить последствия сбоя, восстановить наблюдаемую цепочку и решить, какой сценарий требует исправления. Агент «на все сразу», собранный ради впечатляющей демонстрации, лишает команду такой управляемости.
