Как создать ИИ-агента, который вызывает нужный инструмент, а не соседний

Закупщик спрашивал статус поставки, а модель отвечала из памяти диалога. Инструмент "найти заказ" лежал рядом, но в длинной инструкции важнее были тон и вежливость. Мы перестали наращивать текст и стали описывать каждый инструмент как контракт: когда звать, когда не звать, что считать ошибкой. Создание ИИ-агента после этого перестало быть спором о формулировках. Раньше руководитель вылавливал чужие цифры уже в переписке, теперь первый вопрос другой: инструмент вызывали или модель ответила сама.

Что такое ИИ-агент, если смотреть на действия

В рабочей системе это не чат с удачным названием. Модель читает задачу, выбирает инструмент, смотрит ответ и либо делает следующий шаг, либо отдаёт результат человеку, либо останавливается. Чат без инструментов умеет только говорить.

ИИ-агенты для бизнеса отличаются правом на конкретное действие: прочитать карточку, положить черновик, честно вернуть "не найдено". Пока списка действий нет, спорить о модели рано. Сначала действия, потом выбор модели под них.

Инструкция на две страницы проиграла одной строке

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

Дело было не в "слабой модели". Два инструмента назывались почти одинаково: "получить данные" и "обновить данные". У каждого описание в одну строку. Чтение и запись для модели не различались, потому что мы сами этого не написали. Новый абзац в инструкции ничего не менял. Текст рос, путаница оставалась.

Карточка, которую стыдно оставлять общей

На каждый инструмент мы завели короткую карточку. Её читает и разработчик, и модель.

Имя - глагол и объект. "Найти заказ по номеру", а не внутренний код вроде get_data. Одно предложение - зачем вызывать. Второе - когда не вызывать: нет номера, вопрос про договор, а не про поставку, человека просят "просто прикинуть".

Дальше аргументы. Тип, пример нормального значения и пример плохого: пустая строка, номер из другого контура, пачка заказов разом. Потом форма ответа. Что значит "нашли", что значит "в базе нет", какая ошибка значит "сервис недоступен, не выдумывай".

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

Инструкцию после этого ужали. Роль, порядок "сначала прочитай, потом предлагай запись" и куда сдавать задачу, если карточка инструмента не выполнена. Характер агента стал короче списка его действий.

Где карточка не спасает

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

Ломает и слишком откровенный ответ сервиса. Сырой текст ошибки, внутренние номера, кусок чужой карточки. Модель либо тащит это в письмо, либо замолкает. Наружу ей отдаём короткие смыслы: не найдено, нет права, сервис недоступен, повторите позже.

И ещё проверка на одном удачном диалоге. Фраза закупщика и фраза из рекламаций похожи, инструменты разные. Мы прогоняем пачку живых формулировок из отдела. Где инструмент обязателен, где его звать нельзя, где надо остановиться и отдать человеку. Не чужой рейтинг, а эти фразы.

Те же карточки гоняем на GigaChat Pro и YandexGPT: кто устойчивее держит границу чтения и записи. На обезличенных примерах полезно глянуть, как тот же контракт ведут GPT, Claude или Qwen. В контур с договорами и персональными данными это не переносится само. Здесь раньше бенчмарка решает 152-ФЗ и то, где вообще можно хранить карточку.

Что настроить, пока инструментов ещё мало

Не размножайте действия "на вырост". Пять-семь штук, у каждого запрет, не только разрешение. Чтение и запись - разные инструменты и разные права. Таймаут виден агенту, иначе он додумает. Повтор того же шага не плодит второй документ. В журнал пишите имя инструмента и аргументы, а не простыню персональных данных внутри инструкции.

Начните создание ИИ-агента с этого списка, даже если модель уже выбрана. Польза появляется, когда сотрудник верит: "не найдено" значит не найдено, а черновик сам никуда не ушёл. До этого вы настраиваете собеседника, а не исполнителя.

Если два соседних инструмента поменять местами только именами, ваши карточки это удержат или агент опять ответит по памяти?