Как мы отучили ИИ-агентов угадывать: событийная спецификация вместо «умного агента»

Знакомая картина: ИИ-агенту дали доступ к данным, хороший промпт и десяток инструментов. Первую неделю он удивляет. Потом начинаются странности: заявка ушла не тому согласующему, у договора появился статус, которого нет в регламенте, а один и тот же шаг агент сделал дважды, потому что «забыл», что уже его сделал.

Первая реакция — взять модель посильнее и дописать промпт. Мы прошли этот путь и свернули с него. Сейчас мы работаем по-другому: не делаем агента умнее, а убираем у него поводы угадывать. Получилось точнее, на порядок дешевле и легко переносится с процесса на процесс.

Почему агент ошибается

Если разобрать ошибки агентов в реальных процессах, почти все сводятся к трём причинам:

1. Агент держит процесс в голове. Регламент описан в промпте, и следующий шаг агент выводит сам. Где описание неполное — додумывает.
2. Агент угадывает модель данных. Что такое «клиент», чем он отличается от «контрагента», какие статусы бывают у заявки — всё это он восстанавливает из контекста. Каждый раз немного по-разному.
3. Агент теряет состояние. На длинной задаче история переписки разрастается, и то, что было сделано час назад, тонет в ней.

Ни одна из причин не про «глупость» модели. Агент угадывает там, где правила живут только в его контексте. Значит, правила надо оттуда вынести.

Онтология: понятия бизнеса — это данные

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

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

Процесс — таблица событий, а не схема и не промпт

Второе — сам процесс. Мы описываем его не блок-схемой и не текстом, а таблицей: одна строка — одно событие. В строке записано:

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

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

Что делать, когда в таблице нет ответа

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

У нас неопределённость не повод для импровизации, а событие. Регулярная проверка ищет три случая:

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

Каждая находка записывается в журнал. Пройти мимо неё незаметно нельзя.

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

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

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

Главное правило: агент никогда не решает молча и по-своему. Либо решает внутри проверок спецификации, и это видно в журнале, либо отдаёт вопрос людям.

Почему это удобно не только агенту

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

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

Где подход не работает

Честно о границах. Процесс всё равно придётся описать, и первые недели неопределённостей будет много — это нормально, спецификация так и растёт. Перекрёстные проверки ловят только то, что в них записано: забытое правило агент не соблюдёт. И подход рассчитан на повторяющиеся процессы с объектами и статусами — заявки, проекты, согласования, производство. Для открытых творческих задач таблица событий почти ничего не даёт.

Итог

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

Подробный разбор механики, сравнение с BPMN и автономными агентами и ограничения — в статье базы знаний.