Tool Calling

Tool Calling позволяет модели предложить вызов поиска, калькулятора, базы или другой функции в структурированном виде. Само действие выполняет приложение или провайдер инструмента, поэтому аргументы, права и результат нужно проверять вне модели.

Коротко

Коротко. При tool calling модель не нажимает кнопку и не обращается к базе сама. Она выбирает подходящий инструмент и формирует структурированные аргументы. Приложение проверяет предложение, выполняет разрешённое действие и возвращает результат модели.

Зачем модели инструменты

Языковая модель хорошо работает с текстом, но её собственный ответ не заменяет свежие данные, точный расчёт или действие во внешней системе. Инструменты закрывают этот разрыв.

С их помощью модель может:

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

Модель отвечает за выбор и формирование вызова. Источником истины остаётся инструмент и проверяющий его код.

Как выглядит цикл

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

{
  "name": "get_order",
  "description": "Получить заказ по идентификатору",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string" }
    },
    "required": ["order_id"]
  }
}

Дальше происходит несколько шагов:

1. Пользователь задаёт вопрос.
2. Модель решает, достаточно ли контекста или нужен инструмент.
3. Модель возвращает имя функции и аргументы.
4. Приложение проверяет схему, права и допустимость действия.
5. Код вызывает API, базу или локальную функцию.
6. Результат добавляется в диалог.
7. Модель формирует ответ или предлагает следующий вызов.

Цикл может повторяться, но приложение должно ограничивать число шагов, время и бюджет.

Модель только предлагает вызов

Структурированный JSON легко принять за команду, которая уже выполнена. На самом деле это лишь предложение модели.

Например, аргументы могут выглядеть корректно:

{
  "recipient": "client@example.com",
  "subject": "Обновление заказа",
  "body": "..."
}

Но перед отправкой приложение всё равно проверяет:

• имеет ли пользователь право писать этому адресату;
• не попали ли в письмо секреты;
• соответствует ли текст политике продукта;
• требуется ли предварительный просмотр и подтверждение;
• не выполнялся ли тот же вызов раньше.

JSON-схема подтверждает форму, а не смысл и не полномочия.

Собственные и встроенные инструменты

Собственный инструмент описывает функция приложения. Модель предлагает вызов, а ваш код решает, как его выполнить. Такой вариант удобен для внутренних данных и бизнес-логики.

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

Для устойчивой статьи важнее различие в ответственности: собственный инструмент контролирует приложение, встроенный — ещё и провайдер платформы. В обоих случаях результат может быть неполным или ошибочным.

Наглядный пример

Пользователь спрашивает: «Есть ли у заказа задержка и можно ли предупредить клиента?»

Помощник получает два инструмента:

• get_order_status(order_id) — только читает состояние заказа;
• create_email_draft(order_id, reason) — создаёт черновик, но ничего не отправляет.

Модель сначала запрашивает статус. Если данные указывают на задержку, она создаёт черновик и показывает его оператору. Отправку выполняет отдельная команда после подтверждения.

Такой дизайн лучше функции fix_order_problem, которая одновременно читает данные, меняет заказ и пишет клиенту. Узкие инструменты легче проверять, ограничивать и журналировать.

Что делает описание инструмента хорошим

Модели проще выбирать между функциями, если их назначения не пересекаются.

Полезное описание включает:

• конкретный результат вызова;
• условия, когда инструмент подходит и когда не подходит;
• единицы измерения и формат дат;
• обязательные поля и допустимые значения;
• сведения о побочном эффекте: чтение, запись, удаление или отправка.

Фраза «работает с заказами» слишком широкая. «Возвращает текущий статус заказа по внутреннему идентификатору и не меняет данные» заметно яснее.

Проверка и безопасность

Надёжный обработчик относится к аргументам модели как к недоверенному вводу.

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

Результат инструмента тоже недоверенный. Веб-страница или документ могут содержать инструкцию, которая пытается переопределить задачу модели. Данные нужно отделять от команд и фильтровать по источнику.

Tool calling и MCP

Tool calling описывает сам выбор функции и аргументов. MCP даёт стандартный канал, по которому внешние серверы объявляют такие функции и получают вызовы.

Можно использовать tool calling без MCP — просто передать модели схемы собственных функций. Можно подключить MCP-сервер, а затем представить его инструменты модели через механизм конкретного API.

В ComfyUI tool calling обычно появляется через отдельную интеграцию или внешний оркестратор. Он может передать параметры в API workflow, но это не встроенная гарантия безопасности и не свойство самого графа.

Когда прямой код проще

Если порядок операций заранее известен, модель между ними не обязательна. Для цепочки «проверить оплату → сформировать чек → отправить уведомление» обычный код предсказуемее.

Tool calling полезен, когда способ решения зависит от запроса: иногда нужно найти документ, иногда посчитать, иногда задать уточняющий вопрос. Даже тогда критическую часть процесса можно оставить детерминированной.

Частые ошибки

• Считать аргументы модели проверенными. Они могут быть неполными, выдуманными или опасными.
• Давать один инструмент на всё. Широкие полномочия сложнее контролировать.
• Полагаться на число инструментов. Важно не универсальное ограничение, а качество выбора на собственных тестах.
• Не учитывать повторы. Сетевой сбой может привести к повторной оплате или отправке.
• Скрывать опасное действие внутри чтения. Название и описание должны честно отражать побочный эффект.
• Доверять результату инструмента без проверки. API может вернуть ошибку, устаревшие данные или вредоносный текст.

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

Function calling и tool calling — одно и то же?

Термины часто используют как синонимы. Иногда function calling называют только пользовательские функции, а tool calling — более широкий механизм, включающий встроенные инструменты. Точное значение зависит от API.

Может ли локальная модель вызывать инструменты?

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

Можно ли заставить модель выбрать конкретную функцию?

Многие API поддерживают режим обязательного или фиксированного выбора, но синтаксис различается. Даже принудительно выбранный вызов нужно валидировать.

Как оценить качество?

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

Главное

Tool calling соединяет языковую модель с внешними возможностями, но не отдаёт ей полный контроль. Модель предлагает функцию и аргументы; приложение проверяет полномочия, выполняет действие и возвращает результат. Чем яснее инструменты и строже границы вокруг них, тем предсказуемее работает весь помощник.