Вызов функций (Function Calling) / Tool Use

Вызов функций (function calling) / использование инструментов (tool use) — это способ, при котором модель возвращает не только обычный текст, а структурированный запрос на вызов внешнего инструмента. Дальше уже ваше приложение выполняет этот инструмент, передаёт результат обратно модели и получает продолжение ответа.

Важно: это не единый индустриальный стандарт, а семейство похожих, но несовместимых между собой протоколов у разных провайдеров. По состоянию на 2026-08-16 OpenAI, Gemini, Anthropic, Azure OpenAI и AWS Bedrock поддерживают свои варианты с разными формами событий, правилами схем и режимами выбора инструмента.

Английские термины: function calling, tool use; также встречается близкое tool calling. Практический вывод: если вам нужно, чтобы модель инициировала действие во внешней системе, нужен tool use; если нужен только валидный структурированный вывод без исполнения внешнего кода, это уже ближе к Structured Outputs, а не к полному циклу вызова инструмента.

Простыми словами

Можно представить это как диспетчера. Пользователь говорит: «сделай действие», модель не идёт во внешний сервис сама, а выписывает аккуратную заявку: какой инструмент нужен и с какими параметрами.

Потом ваш код читает эту заявку, проверяет её, реально вызывает внешний API или внутреннюю функцию и приносит результат обратно модели. Поэтому function calling — это не «умение модели нажимать кнопки», а договор между моделью и приложением о том, как описывать действие машинно читаемым способом.

Как это работает

Общая схема у провайдеров одна и та же, но названия событий различаются. OpenAI описывает function calling как механизм подключения моделей к внешним инструментам и системам; Gemini использует шаги function_call; Anthropic — блоки tool_use и tool_result; Azure OpenAI возвращает вызовы в tool_calls; AWS Bedrock разделяет client-side и server-side tool use.

1) Вы отправляете в модель сообщение пользователя + описание доступных tools
2) Модель решает: ответить текстом или вернуть запрос на tool call
3) Приложение валидирует аргументы и выполняет внешний инструмент
4) Результат возвращается в модель как tool_result или аналогичный блок
5) Модель строит финальный ответ с учётом результата

Для внедрения важны не только сами шаги, но и то, как именно провайдер оформляет этот цикл.

Из этого следует главное инженерное правило: переносить необработанные сообщения между SDK «как есть» нельзя. Даже если смысл один и тот же, форма ответа, режимы выбора инструмента и ограничения схем отличаются.

Где применяется

• OpenAI-native workflows: когда вы строите агентный сценарий в Responses API и хотите связать модель с собственными инструментами.
• Gemini-приложения: когда нужен built-in или custom tool invocation и важен streaming, включая частичную выдачу аргументов.
• Claude workflows: когда нужен явный контроль над тем, можно ли модели говорить обычным текстом или она должна сначала перейти к tool_use.
• Enterprise-развёртывания: Azure OpenAI для OpenAI-совместимых интеграций и AWS Bedrock, если вы выбираете между client-side и server-side исполнением.

Если вы собираете orchestration-слой сами, полезно держать отдельный адаптер под каждого провайдера. Для пошагового разбора клиентского потока можно посмотреть Как использовать function calling в API, а для организации цепочек и инструментов — LangChain: фреймворк для RAG, tool calling и LLM-приложений.

Практический пример

Ниже — провайдер-независимый сценарий. Названия полей у вас будут разными, но логика останется той же.

Инструмент:
get_weather(city, date)

Запрос пользователя:
Нужен прогноз для Казани на завтра

Ожидаемое поведение модели:
tool call
  name: get_weather
  arguments:
    city: Казань
    date: завтра

Что делает приложение:
- проверяет, что city и date соответствуют схеме
- вызывает внешний сервис погоды
- возвращает результат модели как tool_result

Финальный шаг модели:
строит обычный ответ на естественном языке

Если вам нужна именно жёсткая привязка аргументов к схеме, в документации OpenAI описан режим Structured Outputs с strict: true для поддерживаемых моделей и конфигураций запроса. Но даже в этом случае безопаснее считать, что валидация, права доступа и фактическое исполнение остаются обязанностью приложения.

Чем отличается от…

Не путайте tool use с Chain-of-Thought (CoT): CoT описывает ход рассуждения, а не вызов внешнего инструмента. И не каждый reasoning model автоматически лучше интегрируется с tools: поддержка function calling задаётся ещё и API-провайдером.

Ограничения и заблуждения

• Заблуждение: «модель сама выполняет функцию». Обычно она только формирует вызов. Исполнение остаётся на стороне приложения; у AWS Bedrock есть и server-side вариант, но он доступен не для всех моделей.
• Заблуждение: «если есть схема, всё гарантировано». У OpenAI строгая привязка через strict: true работает только на поддерживаемых моделях и конфигурациях запроса; неподдерживаемые схемы отклоняются. У других провайдеров правила другие.
• Заблуждение: «код переносится между OpenAI, Gemini, Claude и Azure без изменений». Нельзя. Документы прямо расходятся по формам событий: function_call, tool_calls, tool_use, tool_result.
• Заблуждение: «принудительный выбор инструмента всегда улучшает результат». Anthropic отдельно отмечает, что forcing tool use может подавлять естественный текст до вызова, а manual extended thinking несовместим с частью принудительных режимов.
• Практическое ограничение: поддержка зависит от модели, API-версии, региона и быстро меняется. В исходном пакете нет исчерпывающей межпровайдерной матрицы, поэтому перед внедрением нужно перепроверять документацию именно под ваш SDK и целевую модель.

Редакционный вывод: относитесь к function calling как к протоколу оркестрации, а не как к переносимому стандарту. Самый безопасный путь — нормализовать provider-specific события в своём приложении и отдельно валидировать аргументы, права доступа и результаты инструмента.

Связанные термины и инструменты

• Chain-of-Thought (CoT) — чем рассуждение отличается от действия.
• Reasoning model (модель рассуждений) — когда модель лучше планирует шаги, но это ещё не равно поддержке tools.
• LangChain — слой оркестрации поверх разных провайдеров.
• Как использовать function calling в API — практический разбор клиентского потока.

Источники

• Function Calling in the OpenAI API | OpenAI Help Center
• Function calling and other API updates | OpenAI
• Function calling with the Gemini API | Google AI for Developers
• Release notes | Gemini API | Google AI for Developers
• 도구 정의 – Claude Platform Docs
• How to use function calling with Azure OpenAI in Microsoft Foundry Models | Microsoft Learn
• Client-side tool use – Amazon Bedrock
• Server-side tool use – Amazon Bedrock
• Toolformer: Language Models Can Teach Themselves to Use Tools
• REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS
• Gorilla: Large Language Model Connected with Massive APIs

Вопросы и ответы

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

Почти всегда эти термины используют как близкие. Но в деталях это provider-specific реализации: один провайдер говорит function_call, другой — tool_use, третий — tool_calls.

Выполняет ли модель функцию сама?

Обычно нет. В типичном client-side сценарии модель только формирует вызов, а исполнение делает ваше приложение. Исключения вроде server-side tool use есть, но они ограничены конкретными моделями и платформами.

Чем это отличается от простого JSON-ответа?

JSON сам по себе — это просто форма данных. Function calling добавляет протокол: модель явно сообщает, что хочет вызвать инструмент, приложение исполняет его и возвращает результат для продолжения ответа.

Можно ли сделать один универсальный обработчик для всех провайдеров?

На уровне внутреннего адаптера — да. На уровне «сырых» событий — нет: формы сообщений, режимы выбора инструмента и ограничения схем отличаются, поэтому нужен слой нормализации.

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

Зависит от провайдера. В документации Azure OpenAI указано, что несколько параллельных вызовов возвращаются в tool_calls; для остальных платформ такой режим нужно проверять по актуальным документам и SDK.