Tool calling: как языковая модель решает, чем воспользоваться

Спросите ChatGPT, GPT-5 или Claude о погоде в Казани, и модель не станет угадывать. Она вернёт JSON вида {"name": "get_weather", "arguments": {"city": "Казань"}} — заявку на вызов функции. Дальше ваш код выполняет запрос к сервису погоды и отдаёт результат обратно модели, чтобы та сформулировала ответ человеку. Это и есть tool calling: механизм, на котором держатся все современные ИИ-агенты, от плагинов до автономных сценариев с десятками шагов.

Формат появился у OpenAI в 2023 году под названием function calling, позже был переименован в tool calling и подхвачен почти всеми: Anthropic, Google, Mistral, а также локальными моделями через форматы вроде тех, что поддерживает Ollama. Идея одна на всех, а вот детали реализации и надёжность различаются заметно.

Что происходит под капотом

Модель не имеет доступа ни к интернету, ни к вашей базе данных, ни к файловой системе. Всё, что она умеет, — генерировать текст. Tool calling надстраивает над этим протокол: вы заранее описываете модели набор инструментов, а она в нужный момент выдаёт не прозу, а структурированный вызов.

Схема из четырёх шагов повторяется на каждом обращении к инструменту:

1. Описание инструментов. Вы передаёте в запросе список функций: имя, человекочитаемое описание и JSON Schema аргументов. Именно описание — то, по чему модель решает, подходит инструмент или нет.
2. Решение модели. Получив запрос пользователя, модель либо отвечает текстом, либо возвращает один или несколько вызовов инструментов с заполненными аргументами.
3. Исполнение на вашей стороне. Ваш код принимает вызов, выполняет реальное действие — запрос к API, чтение из БД, отправку письма — и получает результат.
4. Финальный ответ. Результат возвращается модели отдельным сообщением, и та формулирует ответ пользователю или запрашивает следующий инструмент.

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

Как модель выбирает инструмент

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

Описание важнее имени

Функция fn_23 с описанием «возвращает баланс счёта клиента по его ID» будет выбираться надёжнее, чем функция get_balance вообще без описания. Модель читает не код, а метаданные. Пишите описания так, будто объясняете задачу новому сотруднику: когда применять инструмент, а когда — нет.

Аргументы модель тоже придумывает

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

Больше инструментов — хуже выбор

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

Агент настолько хорош, насколько понятны описания его инструментов. Плохое описание — это не баг модели, это баг вашего промпта.

Чем различаются реализации

Протокол похож у всех, но поведение, лимиты и удобство отличаются. Данные ниже — на конец 2024 — начало 2025 года; форматы API вендоры меняют, поэтому актуальные детали и лимиты сверяйте в документации.

Отдельная история — Model Context Protocol (MCP), открытый стандарт от Anthropic конца 2024 года. Он не заменяет tool calling, а стандартизирует то, как приложение публикует инструменты для модели: один MCP-сервер можно подключить к разным клиентам, не переписывая описания под каждый.

Где это ломается на практике

• Модель выбирает не тот инструмент. Обычно причина — размытые или пересекающиеся описания. Две функции «найти заказ» и «найти доставку» будут путаться, пока вы не разведёте их по формулировкам.
• Галлюцинация аргументов. Модель подставляет значение, которого не было в диалоге. Лечится обязательными полями, enum и валидацией на вашей стороне до исполнения.
• Зацикливание. Агент вызывает инструмент, получает ошибку, вызывает снова с тем же аргументом. Нужен лимит на число шагов и понятные сообщения об ошибках, которые модель сможет прочитать.
• Безопасность. Модель может предложить вызвать delete_all, если такой инструмент ей дать. Никогда не исполняйте деструктивные вызовы без подтверждения — модель не отвечает за последствия, отвечает ваш код.

Кому это пригодится и кому нет

Tool calling нужен, если вы строите продукт поверх LLM, а не просто пишете промпты в чате.

• Пригодится. Вы делаете ассистента, который должен читать данные из вашей CRM, оформлять заявки, искать по внутренней базе или запускать сценарии. Пример: бот поддержки, который по номеру заказа тянет статус из вашего API, а не выдумывает его.
• Пригодится. Вы собираете агента с несколькими шагами: найти данные, посчитать, отправить отчёт. Без tool calling это пришлось бы парсить из свободного текста регулярками.
• Скорее нет. Задача — суммаризация, перевод, генерация текста. Здесь модели нечего вызывать, а лишние инструменты только сбивают выбор.
• Нет. Вам нужен один разовый ответ без внешних данных. Тогда tool calling — это лишний слой сложности и лишние токены на описания инструментов.

Агент^* — программа, которая в цикле обращается к языковой модели, выполняет предложенные ею вызовы инструментов и передаёт результаты обратно, пока задача не решена или не исчерпан лимит шагов. Tool calling — механизм, на котором этот цикл держится.