Лестница выбора ИИ-агента начинается со скрипта и поднимается к модели, циклу ReAct, RAG и работе с инструментами только по необходимости. Надёжная система использует минимальную автономность, достаточную для задачи. Сначала компания описывает должность, затем выбирает технологию.
Интерес к агентам уже высок. Исследование Capgemini о внедрении генеративного ИИ сообщало, что 82% организаций планировали интегрировать агентов в течение 1-3 лет, а в исходном материале 10% уже использовали их. Эти цифры показывают намерение, но не подтверждают готовность данных, процессов и контроля.
Скрипт должен получить работу раньше агента
Если входные данные структурированы, решение определяется правилами, а результат всегда одинаков, нужен скрипт, интеграция или RPA. Языковая модель в таком процессе увеличивает стоимость и добавляет непредсказуемость. Фиксированную автоматизацию проще тестировать, объяснять и восстанавливать после сбоя.
Начать стоит с инвентаризации операции. Какие поля поступают на вход, какие проверки выполняет сотрудник, где записывается результат и какие исключения встречаются? Часто такой разбор показывает, что большая часть работы детерминирована, а модель нужна только для одного узкого участка с неструктурированным текстом.
Ограниченная модель полезна там, где формулировки меняются, но границы решения известны. Это может быть классификация обращения, извлечение полей, маршрутизация или первичный разбор запроса. Модель понимает текст, а правила определяют допустимое действие и момент передачи человеку.
До внедрения полезно пройти три теста готовности команды к ИИ. Нужно определить работу, доверенный источник контекста и способ проверки результата. Если эти элементы не описаны, более мощная модель лишь быстрее создаст неоднозначность.
Вводить автоматизацию безопаснее поэтапно. Сначала система работает в теневом режиме и не меняет данные. Затем специалист сравнивает её решение со своим. После стабилизации можно разрешить низкорисковые действия, сохранив подтверждение для исключений. Такой путь создаёт фактическую историю качества до выдачи более широких прав.
ReAct и RAG нужны для изменяющегося процесса
Цикл ReAct подходит для задач, где следующий шаг зависит от нового наблюдения. Агент рассуждает, выполняет действие, получает результат и корректирует план. Такой подход может быть полезен для диагностики, исследования и многоэтапной обработки. Для одношагового ответа он создаёт лишние вызовы и точки отказа.
Классификация агентов Galileo разделяет ограниченные модели, ReAct, связку ReAct с RAG и системы с инструментами. Это не терминологическая тонкость. Каждый новый слой требует отдельной проверки. Поиск может выбрать нерелевантный документ. Инструмент может получить неверный параметр. Цикл может продолжиться после достижения цели.
RAG добавляют, когда ответ должен опираться на внешние или закрытые знания. При этом необходимо проверять источник, актуальность и соответствие найденного фрагмента вопросу. В задачах с высокой ценой ошибки нужен независимый контроль. Материал о правилах против выдуманных фактов ИИ-агентов показывает, почему уверенный ответ нельзя принимать без подтверждения.
Оценка должна охватывать весь путь, а не только финальный текст. Отдельно проверяют выбор документа, соблюдение прав доступа, корректность вызова инструмента, остановку цикла и передачу человеку. Хороший ответ при неверном источнике остаётся опасным, потому что следующая формулировка может скрыть ошибку хуже.
Доступ к инструментам требует технического контракта
Агент с инструментами уже не только отвечает. Он вызывает API, меняет записи и проводит действия в нескольких системах. Поэтому права, журнал, безопасный повтор и восстановление становятся частью его должностной инструкции.
- Триггер: какое событие запускает работу.
- Результат: какое состояние считается завершением.
- Права: какие системы и операции действительно нужны.
- Доказательство: какие источники и вызовы сохраняются.
- Эскалация: когда решение возвращается специалисту.
- Повтор: как исключить двойное изменение при сбое.
Для связи нескольких сервисов нужен понятный интерфейс. Разбор единого протокола интеграции MCP объясняет, как инструменты становятся доступными модели. Но сам протокол не выдаёт безопасные права и не определяет бизнес-правила. Это остаётся задачей архитектуры.
Нужно учитывать и эксплуатацию. Кто получает сигнал об ошибке, где хранится трассировка, как отключить действие и как обработать незавершённую операцию? Без этих ответов пилот может выглядеть успешным, а команда поддержки получит непрозрачный сервис, который сложно восстановить.
Выбор следует формулировать не как агент или человек, а как минимальный уровень автономности, который заслужила подготовленная работа.
Частые вопросы
Это последовательность от фиксированной автоматизации до модели, ReAct, RAG и инструментов, которая помогает выбрать минимально достаточную автономность.
Скрипт подходит, когда входные данные, правила решения и результат структурированы. Он дешевле, предсказуемее и проще для тестирования.
RAG нужен, когда решение зависит от внешних, закрытых или изменяющихся знаний. Качество поиска, актуальность и источники необходимо проверять отдельно.
Нужны минимальные права, журнал действий, критерий завершения, безопасные повторы, проверка результата и правила передачи задачи специалисту.
Чтобы определить подходящие процессы и недостающие ограничения, пройдите бесплатный технический аудит инфраструктуры.
