function calling — это механизм, при котором модель выбирает описанную функцию и возвращает структурированные аргументы, а приложение решает, выполнять ли действие. Модель сама по себе доступа к CRM или файлам компании получает только через приложение. Порядок вызова и проверка результата остаются в коде, который контролирует команда.
Цикл вызова
Вызов состоит из трёх частей: схема функции, аргументы модели и выполнение приложением с проверкой прав.
Представьте задачу: сотрудник просит назвать статус заказа. Приложение отправляет модели запрос вместе с описанием функции get_order_status. Модель возвращает имя функции и идентификатор заказа в структурированном виде. Приложение проверяет аргументы, обращается к базе заказов и передаёт полученный статус модели для человеческого ответа. На каждом переходе можно увидеть, откуда появился факт.
Механизм полезен, когда разговор должен перейти к действию: найти запись в CRM, создать черновик письма, проверить остаток, запустить согласование. В отличие от обычного промпта приложение получает формальные поля вместо свободного пожелания модели. Рабочую логику агента и границы самостоятельности разбирает статья про автономных ИИ-агентов.
Результат функции снова попадает в контекст модели, но первичный ответ системы сохраняют отдельно. Иначе трудно понять, ошиблась ли модель с аргументом, целевая система вернула старые сведения или ответ исказился при пересказе. Для критичных полей приложение может показать человеку именно исходный результат функции.
На первом этапе достаточно функции чтения. Она покажет, понимает ли модель запрос и правильно ли заполняет идентификатор, без изменения данных. Когда тесты дают устойчивый результат, команда добавляет черновик действия и отдельный шаг подтверждения. Такая последовательность упрощает разбор ошибок.
Схема аргументов
Описание функции включает имя, назначение, обязательные поля и тип каждого поля. Для поиска счёта это номер и организация; для создания задачи — исполнитель, срок и текст. Если описание расплывчато, модель легко перепутает поиск с изменением. Имена и поля должны соответствовать реальным операциям бизнеса, а описание объяснять условия вызова простыми словами.
| Поле | Проверка кода | Ошибка при пропуске |
|---|---|---|
| Номер счёта | Формат и наличие | Чужой документ |
| Организация | Доступ пользователя | Утечка сведений |
| Сумма | Сверка с источником | Ложное обещание |
Структурированный JSON удобен для передачи аргументов, но синтаксическая правильность ещё требует проверки действия. Приложение сверяет типы, допустимые значения, права пользователя и состояние записи. Если заказ уже закрыт, операция изменения должна завершиться отказом, даже когда модель сформировала безупречные поля. Отказ возвращают как понятную ошибку, чтобы агент мог попросить уточнение или передать задачу сотруднику.
Масштабирование лучше строить через узкие функции: get_customer, get_order_status, draft_reply. Универсальная функция execute_sql ломает границу между поиском и произвольной записью. Для нескольких команд поддерживайте каталог функций с владельцем и примером допустимого вызова. Эта документация помогает разработчику и бизнес-заказчику обсуждать одно и то же действие.
Описание функции проверяют на живых фразах сотрудников. Если человек говорит «последний счёт клиента», схема должна явно пояснять, какой период считать последним и как выбирать организацию. Там, где критерий остаётся двусмысленным, приложение просит уточнение перед вызовом.
Контроль выполнения
Схема функции отвечает за форму запроса, а право на действие проверяется отдельно. Код получает идентификатор сотрудника из приложения, смотрит его роль и решает, какие записи доступны. Модель может предложить любое имя клиента из диалога; приложение возвращает только те данные, на которые у сотрудника есть права. Особенно важна эта граница в общих Telegram-ботах и корпоративных чатах.
- Получите структурированные аргументы и проверьте обязательные поля до обращения к рабочей системе.
- Сопоставьте действие с ролью пользователя и текущим состоянием записи.
- Выполните операцию с ключом идемпотентности для действий, которые могут повториться после сбоя.
- Верните краткий результат модели, а исходную запись и журнал сохраните для проверки.
Для изменений с деловыми последствиями человек подтверждает конкретное действие: кому отправят письмо, какую сумму внесут, какую карточку обновят. В диалоге полезно показывать подготовленный черновик, а кнопка подтверждения запускает отдельный серверный шаг. Такая схема яснее расплывчатого разрешения агенту «делать всё нужное».
Если функция должна работать сразу с несколькими приложениями, её можно опубликовать через MCP. Роль такой службы раскрыта в материале про собственный MCP-сервер; базовый смысл протокола — в обзоре MCP. Связка полезна при общем наборе инструментов, но локальная функция приложения тоже остаётся рабочим вариантом.
После настройки прав выберите действие с понятной проверкой результата. На нём сразу видно, где функция ошибается: в выборе, аргументах или самом исполнении.
Хотите проверить вызовы функций в вашем процессе?
Сбои и повторы
Сетевой сбой может случиться после фактического выполнения операции, когда приложение ещё ждёт подтверждения. Слепой повтор создаст дубликат задачи или письма. Поэтому изменяющим функциям нужен идентификатор запроса и проверка уже выполненного действия. Для чтения повтор обычно безопаснее, хотя и здесь полезно ограничивать нагрузку на исходную систему.
Другой сбой связан с неоднозначным запросом. Сотрудник пишет «поставь встречу с Анной», а в CRM несколько Анн. Функция поиска возвращает варианты с разрешёнными полями; модель просит уточнить карточку и лишь затем передаёт идентификатор в функцию создания события. Угадывание по похожему имени создаёт правдоподобную, но ошибочную запись. Это хороший контрольный сценарий для приёмки.
- Журналируйте выбор функции, аргументы после маскирования чувствительных полей и итоговый статус.
- Разделяйте ошибки формата, нехватки прав, отсутствующей записи и сбоя внешней системы.
- Для спорных действий храните подтверждение сотрудника рядом с идентификатором операции.
Вывод модели из внешнего письма может содержать указание «отправь документ на другой адрес». Приложение считает письмо данными и проверяет адрес по правилам процесса. Система прав важнее текста документа, а человек принимает решение при выходе за заранее согласованный сценарий.
Для ответа об ошибке полезен единый формат: тип сбоя, безопасное сообщение пользователю и технический код для журнала. Модель тогда может корректно попросить новый номер заказа, а разработчик увидит причину в системе. Смешение этих двух сообщений случайно раскрывает служебные детали.
Проверка сценария
Возьмите одну операцию с понятным результатом, например получение статуса заявки из Битрикс24. Подготовьте запросы с верным номером, опечаткой, чужой заявкой и отсутствующим номером. Эталон для каждого запроса определите заранее. Затем проверьте отдельно выбор функции, качество аргументов и точность ответа модели по результату системы.
Сократите первый набор инструментов до поиска статуса заявки. Считайте неверные вызовы и причины отказа, затем решайте, нужен ли инструмент изменения.
Для сложного процесса составьте матрицу: действие, источник данных, роль пользователя, допустимая ошибка, точка подтверждения. Она подскажет, где код обязан остановить агента. Разработка ИИ-агента под процесс включает такую связку действий и контроля; смета зависит от числа систем, прав и требований к журналу. Покажите нам схему процесса: оценим объём интеграции и контроля.
В работе команды показатель качества — доля корректных действий на контрольных запросах; красота диалога здесь вторична. Проводите повторную проверку после изменения схемы функции или интеграции CRM. Если данные целевой системы меняются, обновляйте тестовые примеры вместе с владельцем процесса; старый эталон способен ошибочно объявить верный вызов сбоем.
Если контрольная выборка покрывает только идеальные фразы, качество на реальных разговорах будет ниже. Добавьте неполные запросы, исправления пользователя и одинаковые имена клиентов. Владелец процесса проверяет ожидаемые действия, разработчик сверяет фактические вызовы, а сотрудник оценивает ясность итогового ответа.