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

> Tool calling даёт LLM «руки»: вызов API, БД и инструментов в агентном цикле. Фундамент AI-агентов и частый вопрос на собеседовании инженера.

Раздел: [Агенты и инструменты](https://ml-book.com/s/agents/) · Страница темы: https://ml-book.com/t/tool-calling/ · Обновлено: 2026-09-16 · Источник: ml-book.com, учебник делается сообществом

## Интуиция

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

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

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

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

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

> **💡 Ключевая мысль**
>
> Модель никогда ничего не исполняет — она только «просит» в формате JSON. Исполняет всегда ваш код, с вашими правами и вашей ответственностью. Поэтому и валидация, и безопасность, и обработка ошибок — на стороне разработчика.

> 🎛 Интерактивная визуализация — на странице темы: https://ml-book.com/t/tool-calling/

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

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

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

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

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

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

> **⚠️ Подводный камень**
>
> Раз исполняет ваш код — все риски тоже ваши. Тул «выполнить произвольную shell-команду» без ограничений превращает любую prompt injection (внедрённую инструкцию в данных) в удалённое выполнение кода. Права инструментов должны быть минимально необходимыми, опасные действия — за подтверждением человека.

> **🎤 На собеседовании**
>
> - «Модель сама исполняет инструменты?» — нет, она генерирует структурированный запрос; исполнение — всегда на стороне вашего кода. Это главный вопрос-ловушка.
> - «Как улучшить точность вызовов?» — меньше тулов, подробные описания «что и когда», строгие JSON-схемы, возврат ошибок валидации модели для повторной попытки.
> - «Что такое MCP и зачем он?» — стандарт описания и подключения тулов: пишем сервер один раз, используем из любого клиента.
> - «Чем tool calling отличается от JSON mode?» — обе механики про генерацию по схеме; tool calling добавляет цикл «вызов → исполнение → результат в контекст → продолжение».

## Связанные темы

- [Агентный цикл и критерий остановки](https://ml-book.com/t/agent-loop/)
- [Память, планирование и мультиагентные системы](https://ml-book.com/t/agent-memory/)
- [MCP: стандарт подключения инструментов](https://ml-book.com/t/mcp/)
- [Безопасность: guardrails и prompt injection](https://ml-book.com/t/safety-guardrails/)

---

Интерактив, тест из 12 вопросов и карточки терминов — на странице темы: https://ml-book.com/t/tool-calling/
Весь учебник в markdown: https://ml-book.com/llms-full.txt · Оглавление для агентов: https://ml-book.com/llms.txt