Tool calling: как модель вызывает инструменты

Сама по себе LLM умеет ровно одно — генерировать текст. Tool calling (вызов инструментов) даёт ей «руки»: возможность попросить внешний код сходить в API, базу данных или файловую систему. Это фундамент всех агентов, и на собеседовании AI-инженера про него спрашивают почти всегда.

Интуиция

Представь очень эрудированного консультанта, запертого в комнате без окон. Он блестяще рассуждает, но не знает, какая погода на улице, и не может нажать ни одной кнопки. Всё, что он может, — писать записки. Tool calling — это договорённость: если консультант напишет записку строго определённого формата («вызови get_weather для Москвы»), то ассистент за дверью — ваш код — исполнит просьбу и просунет обратно листок с результатом. Консультант так и остаётся генератором текста; изменился только протокол общения.

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

Цикл tool calling состоит из четырёх шагов:

• Разработчик описывает инструменты (tools). Для каждого — имя, человекочитаемое описание и JSON-схема параметров (JSON Schema): какие аргументы, каких типов, какие обязательны. Эти описания уходят в запрос вместе с сообщениями.
• Модель отвечает структурированным вызовом (tool call). Вместо обычного текста она генерирует JSON: имя инструмента + аргументы. Важно: модель ничего не исполняет — она лишь выдала текст в оговорённом формате.
• Ваш код исполняет вызов. Парсит JSON, валидирует аргументы, дергает реальное API и кладёт результат обратно в контекст как сообщение с ролью tool.
• Модель продолжает генерацию — теперь уже видя результаты, и отвечает пользователю словами (или просит ещё один инструмент).

Современные модели умеют параллельные вызовы (parallel tool calls): в одном ответе — сразу несколько tool call, и ваш код может исполнить их одновременно. Классический пример — «погода в Москве и Питере»: один ответ модели, два вызова, два результата.

Качество описаний = качество вызовов

Модель выбирает инструмент и заполняет аргументы, глядя только на имя, описание и схему. Описание тула — это промпт-инжиниринг: «get_data» с пустым описанием почти гарантирует мусорные вызовы, а «возвращает текущую погоду по названию города; используй для любых вопросов о погоде» — осмысленные. Хорошая практика: описывать не только «что делает», но и «когда использовать», приводить формат аргументов и типовые значения.

Родственная механика — structured output / JSON mode: модель принуждают выдавать строго валидный JSON по заданной схеме, но без последующего исполнения. По сути tool calling — это structured output, к которому договорились приделать исполнение: обе механики опираются на одну способность модели генерировать текст по схеме (часто с constrained decoding — маскированием токенов, нарушающих грамматику).

Типичные ошибки и MCP

• Тул-простыня. 40 инструментов с однострочными описаниями: модель путает похожие тулы, дёргает не то. Лечится сокращением набора, внятными описаниями, группировкой.
• Невалидные аргументы. Модель может выдать JSON, не проходящий схему (не тот тип, лишнее поле). Правильная реакция кода — провалидировать и вернуть модели текст ошибки: она почти всегда исправляется со второй попытки.
• Галлюцинация тулов. Модель зовёт инструмент, которого нет в списке. Код должен ответить «нет такого тула, доступны: …», а не падать и не исполнять «похожий».

MCP (Model Context Protocol) — открытый стандарт подключения инструментов и источников данных к моделям. Вместо того чтобы писать интеграцию под каждую пару «приложение × тул», сервер один раз описывает свои инструменты по протоколу, и любой MCP-совместимый клиент может их использовать. Это стандартизация транспорта и описаний, сама механика вызова остаётся той же.