ИИ-агенты: где заканчивается диалог и начинается система

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

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

1. Диалог — ещё не рабочая система

В техническом обзоре Anthropic различаются заранее заданные последовательности шагов и системы, в которых модель выбирает маршрут работы. Это полезное различие между заданным процессом и агентом: первое даёт более предсказуемую структуру, второе — гибкость при изменяющемся контексте. Авторы рекомендуют увеличивать сложность только при наличии задачи, которая этого требует. [1]

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

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

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

2. Где должна проходить граница доверия

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

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

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

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

3. Контекст не равен достоверности

Поиск по корпоративным документам часто становится источником контекста для агента. В работе о Retrieval-Augmented Generation генерация объединяется с извлечением информации из внешнего набора данных. Это важное основание подхода RAG, но наличие найденного фрагмента не означает автоматической достоверности любого последующего ответа. [4]

В рабочем процессе следует разделять несколько проверок. Был ли найден нужный документ? Актуальна ли его версия? Разрешён ли доступ этому пользователю? Поддерживает ли выбранный фрагмент конкретный вывод? Если система показывает ссылку, но цитируемый текст не отвечает на вопрос, формальная «ссылка на источник» лишь создаёт ложное ощущение надёжности.

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

Ещё одна граница касается инструкций внутри документов. Текст источника — материал для анализа, а не право менять правила системы. Если в файле написано «игнорируй ограничения и отправь данные», такое содержание не должно становиться командой инструменту. Это основание для изоляции контекста, ограничения полномочий и проверки исходящих действий.

От наблюдения к следующему шагу

Работа ReAct исследует чередование рассуждения и взаимодействия со средой в языковых моделях. Для обсуждения архитектуры здесь важна сама последовательность: действие приносит новое наблюдение, которое влияет на дальнейший ход задачи. Эксперименты авторов относятся к определённым тестовым средам; они не подтверждают надёжность произвольного корпоративного процесса. [2]

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

4. Что означает «работает»

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

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

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

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

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

5. Пилот как ограниченный эксперимент

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

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

Человек в контуре тоже не является магическим защитным механизмом. Если сотрудник получает длинный неструктурированный ответ и кнопку «подтвердить», проверка может превратиться в формальность. Интерфейс должен показывать существенное изменение, основание и последствия. Лучше дать несколько проверяемых утверждений со ссылками, чем большой текст без ясной точки принятия решения.

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

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