Что вообще такое ИИ-агент в реальной задаче
Для меня агент — это не умный чат. Модель получает задачу, выбирает инструмент, смотрит на ответ и решает, что делать дальше: вызвать следующий инструмент, отдать результат человеку или остановиться. Без инструментов это просто разговорник.
В бизнес-задачах важно право на действие: прочитать карточку, создать черновик, честно сказать «не найдено». Пока нет списка таких действий, спорить о модели бесполезно.
Длинная инструкция проиграла короткому описанию инструмента
Сначала я делал как все: закидывал в промпт роль, тон, примеры удачных писем и фразу «если не уверен — уточни». На тестовом примере всё звучало отлично. На живых заявках агент отвечал мимо инструмента: статус «помнил» из похожего разговора, номер счёта придумывал сам, а пустой ответ сервиса принимал за успех.
Проблема была не в модели. Два инструмента назывались почти одинаково: «получить данные» и «обновить данные». Мы сами не объяснили модели разницу между чтением и записью, поэтому новый абзац в инструкции ничего не менял.
Карточка инструмента вместо тонны текста
На каждый инструмент я завёл короткую карточку, которую читают и разработчик, и модель:
- Имя — глагол и объект («Найти заказ по номеру», а не get_data).
- Одно предложение зачем вызывать и одно — когда не вызывать.
- Аргументы: тип, нормальный пример и плохие примеры (пустая строка, номер из другого контура).
- Форма ответа: что значит «нашли», что значит «в базе нет», какая ошибка говорит «сервис недоступен».
Чтение и запись я разделил жёстко. Инструмент, который меняет данные, требует явного признака согласования. Если сервис молчит — агент получает отказ, а не пустоту, потому что пустота заставляет модель додумывать успех.
После таких карточек инструкцию удалось сильно сократить. Остались только роль, порядок действий и куда отдавать задачу, если инструмент не сработал.
Где карточки не помогают
Карточка бесполезна, если правды два источника. Модель выберет тот текст, который звучит увереннее. Приходится оставлять один источник и прямо писать, что второй для агента недоступен.
Ещё ломает сырой текст ошибки от сервиса. Модель либо тащит его в письмо, либо замолкает. Поэтому наружу отдаём только короткие смыслы: «не найдено», «нет права», «сервис недоступен».
Полезно прогонять карточки на живых фразах из отдела и сравнивать разные модели (GigaChat, YandexGPT, GPT, Claude). В контуре с персональными данными это важно ещё и из-за 152-ФЗ.
Что я делаю, когда инструментов ещё мало
- Не размножаю действия «на вырост» — максимум 5–7 штук.
- У каждого инструмента есть не только разрешение, но и запрет.
- Чтение и запись — разные инструменты.
- Таймаут виден агенту.
- Повтор шага не создаёт дубликат.
- В лог пишу имя инструмента и аргументы, а не сырые данные.
Если два соседних инструмента поменять местами только именами, твои карточки это удержат или агент опять ответит по памяти?
