Как работает ИИ‑агент: цикл, инструменты и контроль действий

Как работает ИИ‑агент, проще понять по одному проходу заявки. Пришло сообщение, система определила задачу, запросила нужные данные, подготовила ответ или создала задачу человеку, затем сохранила результат. Модель отвечает за выбор и формулировку. Доступ к CRM, календарю или отправке сообщения дают отдельные инструменты с явными входами и правами. Разделение важно: текст модели сам по себе ничего не меняет в бизнесе.

Из каких частей состоит цикл агента

На входе нужен объект события: текст, источник, идентификатор диалога, время и уже известный контекст. Далее приходит инструкция о допустимых действиях. Агент может запросить сведения из базы знаний, вызвать расчёт, создать черновик ответа. Когда инструмент вернул результат, модель решает, достаточно ли данных. Завершение цикла означает либо конкретное допустимое действие, либо остановку и передачу человеку.

Для простого прототипа полезно нарисовать все стрелки до кода. Где текст становится структурированной заявкой? Где хранится действующий прайс? Что происходит, если запрос к базе не удался? Кто увидит задачу, если модель не может ответить? В уже готовой статье о создании ИИ‑агента подробнее разобрана сборка сервиса; здесь нас интересует именно работа одного цикла.

Попробуйте проследить один запрос без модели:

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

Почему инструменту нужен узкий контракт

Модель может предложить действие в свободном тексте, но программе нужен проверяемый формат. Функция get_price принимает конкретный код услуги и возвращает цену с датой изменения. Функция create_task принимает сделку, ответственного и срок. Нельзя давать одной универсальной функции «сделай что угодно» право менять все данные CRM. Чем уже контракт, тем проще проверить неожиданный запрос.

Для каждой функции запишите:

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

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

В своём проекте Radomir CRM я вижу ту же схему на заявке с Авито: помощник начинает диалог, а для индивидуальной сметы подключается менеджер. В одном из диалогов клиент трижды просил цену. Робот намеренно оставил индивидуальный расчёт до замера менеджеру. Позже менеджер отправил смету на 80 000 ₽. Так видна граница между началом разговора и решением сотрудника. Этот пример относится к облачному помощнику; схему цикла можно реализовать и с другой моделью.

Как увидеть цикл на маленькой программе

До подключения модели проверьте маршрутизацию обычным кодом. Следующий пример не общается с клиентом: он только показывает, как разные входы ведут к разным действиям. Сохраните его в route.py и запустите локально. Такая заготовка помогает обсудить правила с владельцем процесса до расходов на модель и доступы.

from dataclasses import dataclass

@dataclass
class Event:
    text: str
    dialog_id: str

def route(event: Event) -> str:
    text = event.text.lower()
    if "человек" in text or "жалоба" in text:
        return "handoff"
    if "цена" in text:
        return "get_verified_price"
    return "ask_one_clarifying_question"

for message in ("Какая цена?", "Позовите человека", "Нужна стяжка"):
    print(message, route(Event(message, "test-dialog")))

python3 route.py

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

Есть полезное различие между планом модели и завершённым действием. Модель может предложить вызвать create_task, но приложение ещё проверяет права, обязательные поля и состояние CRM. В ответ пользователю нельзя писать «задача создана» до подтверждения от CRM с идентификатором записи. Если вызов завершился неопределённо, журнал хранит это состояние для проверки человеком. Такое разделение помогает не принимать намерение агента за факт работы системы.

Клиент

Позовите менеджера, у меня нестандартный вопрос.

Агент

Передам разговор менеджеру и сохраню ваш вопрос в заявке.

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

Что сохранять в журнале

Для разбора ошибки нужны исходное событие, версия инструкции, выбранный инструмент, параметры без секретов, ответ источника и окончательное действие. Личные данные в журнале ограничивают и защищают. Не пишите туда API‑ключи и полные медицинские истории. Идентификатор диалога помогает найти цепочку, когда клиент спрашивает, почему получил определённый ответ.

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

Где человек проверяет работу агента

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

Проверьте результат контроля:

• Откройте исходную запись, на которую опирался ответ.
• Сравните действие с записью в журнале.
• Повторите сложный диалог после исправления правила.

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

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

Когда достаточно чата, а когда нужен агент

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

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

Частые вопросы

Чем агент отличается от одного запроса к модели?

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

Должен ли агент сам вызывать внешние сервисы?

Только через разрешённые функции приложения. Приложение проверяет параметры, права, повтор события и результат вызова.

Откуда агент знает актуальную цену?

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

Что делать, если инструмент не отвечает?

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

Когда цикл заканчивается?

При достигнутой цели, передаче человеку, запрете действия, ошибке или установленном пределе времени и числа шагов.