Агент LangChain — это программный контур, где нейросеть выбирает инструменты сама: запрашивает данные из таблицы, создаёт черновик, сверяет статус и отчитывается о каждом шаге. В отличие от поиска по документам, агент действует, поэтому для него критичны права доступа и журнал вызовов. Браться за сборку имеет смысл, когда процесс повторяется регулярно, результат каждого шага проверяется человеком, а ошибка в действии заметно дороже ошибки в ответе.
Где агент уместен
Начните с одной повторяемой задачи и небольшого набора инструментов. Измеряйте полный цикл: вызовы модели, проверку человеком, исправление ошибок и время до принятого результата.
Разница с RAG-контуром проста: поиск отвечает на вопрос, агент доводит задачу до результата. Агент может собрать сведения о заявке и подготовить письмо, если для каждого действия есть инструмент и понятная граница полномочий. Проверка оплаты и отправка письма требуют отдельной проверки прав и результата. Перед пилотом запишите, сколько времени команда тратит на перенос данных между таблицей, почтой и CRM. Сравнивайте с агентом одинаковые задачи: засеките время ручного варианта в течение нескольких рабочих дней и сопоставьте с полным циклом агента, включая подтверждения. Только так видна реальная польза. Где заканчивается поиск и начинается действие, разобрано в материале про RAG-агента с цитатами, а выбор момента для такого контура — в статье о LangChain для компаний. Граница ответственности при этом остаётся прежней: модель предлагает, человек подтверждает, журнал фиксирует.
Инструменты и права
Инструмент — оформленная функция с описанием для модели: какие данные принимает, что возвращает, какие побочные действия совершает. Набор держится коротким: оставьте лишь функции, нужные для выбранного сценария; расширение набора проверяйте тестами и правами доступа. Описание для модели пишите глазами исполнителя: какие поля обязательны, в каком формате ждать ответ, что считать ошибкой. Права режутся на уровне учётной записи сервиса, с которым говорит агент: токен читает заявки, а смену статусов оставляет за человеком — запись идёт после его подтверждения. Проектирование таких вызовов подробно разобрана в статье про function calling.
| Инструмент | Доступ агента | Подтверждение человека |
|---|---|---|
| Чтение заявок | Просмотр списка и карточек | Без подтверждения |
| Черновик письма | Создание текста в папке drafts | Перед отправкой |
| Смена статуса | Запись нового значения | Обязательно |
| Отчёт за день | Сводка по выполненным шагам | Без подтверждения |
Таблица прав — рабочий документ: её читают перед каждым расширением контура и сверяют с журналом. Расхождение между таблицей и журналом — сигнал пересмотреть токены и роли до того, как агент применит лишнее право на практике.
Журнал вызовов
Для аудита настройте трассировку вызовов: имя инструмента, время, результат и безопасный набор аргументов. LangChain задаёт контур агента; запись трасс зависит от вашей конфигурации, например LangSmith или собственного журнала. По журналу отвечают на три вопроса: что агент собирался сделать, что сделал на самом деле и где остановился. Храните журнал отдельно от промптов — он понадобится при разборе инцидента и при доработке инструкций. Метки времени и идентификатор задачи помогают восстановить порядок действий. Причину ошибки выясняют по трассе и данным целевой системы, вместо одного ответа модели. Практика защиты прав и секретов в таких контурах описана в материале про безопасность ИИ-агентов.
- Время и имя инструмента в каждой записи.
- Только нужные для разбора аргументы после маскирования персональных данных и секретов.
- Код результата и нужный фрагмент ответа без токенов и лишних персональных данных.
- Имя сотрудника, подтвердившего шаг.
- Метка версии инструкций, по которой работал агент.
Отдельной строкой в журнале живёт версия инструкций: как только меняете промпт, журнал начинает метить записи новой версией. Без этой метки разбор старого инцидента превращается в угадайку, какая формулировка действовала в тот день. Срок хранения, доступ к журналу и маскирование данных закрепите по правилам компании. Логи полезны для аудита лишь тогда, когда сами защищены от лишнего доступа.
Если сразу выдать агенту право менять статусы в CRM, ошибочный вызов может пройти без подтверждения. Начните с чтения и черновиков, а для записи добавьте паузу на решение человека и проверку прав на стороне CRM. Раздавайте права по одному инструменту и следите за журналом в первые недели работы.
Контроль результата
Тестовые задачи берите из реальной работы отдела: типовые ситуации плюс сложные исключения, где агент может выбрать неверный инструмент. Для каждой ситуации зафиксируйте верный исход: какие данные прочитаны, какой статус выставлен, какое письмо ушло. Набор работает как регрессионный тест: любая правка инструкций прогоняется через него до выкатки. После каждого прогона сверяйте итоги и открывайте журнал даже там, где результат сошёлся с ожиданием лишь отчасти. Считайте три показателя: долю верно выполненных задач, время проверки человеком и число нарушений прав. Для действий с записью ошибка в полномочиях — причина остановить пилот и исправить настройки, даже если итог верный: сегодня агент прочитал лишнее, завтра запишет. Деньги и внешние отправки всегда идут через паузу на подтверждение. Сценарии и откат разобраны в материале про тестирование ИИ-агентов. Когда набор проходит чисто, самое время выбрать рутину для первого контура: какая из них мешает вашей команде сильнее остальных?
Какую рутину отдали бы агенту в первую очередь?
Первый контур
- Выберите процесс из пяти-семи повторяющихся шагов.
- Опишите три-четыре инструмента с правами доступа.
- Соберите тестовые задачи с верными исходами и опасными исключениями.
- Включите журнал и прогоните контур в режиме наблюдения.
- Разрешите действия по одному, начиная с чтения данных.
Порядок шагов важен: тестовый набор подготовьте до подключения агента к рабочим системам. Набор, собранный задним числом по памяти, пропускает те самые ситуации, которые ломали процесс.
В режиме наблюдения агент предлагает действия, а сотрудник выполняет их сам. Длительность такого пилота определяют по числу реальных случаев, охваченных тестом. Список предложений покажет, где инструкции расплывчаты, а журнал — где права избыточны. После успешных тестов откройте чтение, затем создание черновиков и только после отдельной проверки — действия с записью. Каждый следующий уровень открывается после чистого прогона тестового набора. Если наблюдение показывает, что значительная часть предложений уходит мимо, — сужайте процесс: выберите один филиал, один тип заявок, один канал. Узкий контур с высокой точностью полезнее широкого, где ошибки разбросаны по всем процессам. Состав такого проекта и порядок работ собраны на странице про ИИ-агентов для бизнеса: стоимость обсуждается на созвоне под ваш процесс и данные.