Tool use: как Claude вызывает твои функции

Ты подключил Claude к своему приложению через API, и всё шло отлично — пока пользователь не спросил: «А какая сейчас погода в Казани?» Модель честно ответила, что не знает: её обучили давно, окна за сервером у неё нет, текущую погоду взять неоткуда. То же самое с курсом валют, с балансом на счёте, с тем, что лежит в твоей базе данных прямо сейчас.

Дело не в том, что Claude глупый, — он просто заперт внутри текста. Рассуждать умеет, а вот сам сходить в интернет, заглянуть в базу или отправить письмо — нет. Тут и появляется tool use: механизм, который даёт модели руки. Ты описываешь доступные функции, а она решает, когда их позвать.

Кто что делает: разделение ролей

Самое важное и при этом самое неочевидное в tool use: Claude не выполняет твои функции сам. Он только просит их выполнить. Код запускаешь ты — в своём приложении, на своём сервере. Звучит странно? Разложим по ролям.

Представь, что ты диспетчер, а Claude — толковый, но безрукий консультант на телефоне. Соображает отлично, но встать со стула не может. Поэтому диалог идёт так:

• Ты (в коде) говоришь Claude: «Вот список того, что ты умеешь попросить: узнать погоду, найти заказ по номеру, отправить письмо. У каждого инструмента такое-то имя и такие-то параметры».
• Claude думает и отвечает: «Чтобы ответить пользователю, мне нужна погода в Казани. Позови, пожалуйста, инструмент get_weather с городом Казань».
• Ты выполняешь свою настоящую функцию get_weather("Казань") — обычный код, который пишешь сам, — и получаешь, скажем, +18, дождь.
• Ты возвращаешь результат Claude: «Вот что вернул инструмент: +18, дождь».
• Claude формулирует человеческий ответ: «Сейчас в Казани +18 и дождь, захвати зонт».

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

Как ты описываешь инструмент

Чтобы у Claude появились руки, ты при запросе передаёшь список инструментов. Каждый инструмент — это, по сути, три вещи: имя, описание словами (зачем он нужен) и список параметров. Вот как это выглядит для погоды:

{
  "name": "get_weather",
  "description": "Узнать текущую погоду в указанном городе",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "Название города" }
    },
    "required": ["city"]
  }
}

input_schema пусть не пугает — это просто формальное описание: какие поля бывают и какие из них обязательны. А вот description важнее, чем кажется: именно по нему Claude решает, когда инструмент уместен. Чем понятнее объяснишь словами, тем точнее модель будет его звать — и тем реже дёрнет не вовремя.

Зачем это нужно на практике

Tool use превращает Claude из умного собеседника в деятельного помощника. Сводится всё к двум классам задач.

Свежие и приватные данные. Модель знает только то, что было до обучения, и понятия не имеет о твоей базе. Через инструменты ты открываешь ей доступ к актуальному: курс валют на сегодня, статус доставки конкретного заказа, остаток на складе, профиль пользователя. Claude перестаёт фантазировать и начинает отвечать фактами — потому что факты приносишь ему ты.

Действия, а не только слова. Инструмент может не просто что-то возвращать, а делать: создать запись в календаре, отправить письмо, завести задачу в трекере, оформить возврат. Тогда из твоего приложения вырастает настоящий ассистент: пользователь пишет «перенеси встречу на завтра», Claude зовёт инструмент move_meeting, а твой код реально двигает событие.

И весь фокус в том, что ты решаешь, насколько отпустить поводок. Хочешь — выполняешь вызов автоматически. Хочешь — показываешь пользователю «Claude собирается отправить письмо, подтвердить?» и ждёшь нажатия. Раз код выполняешь ты, последнее слово на каждом шаге тоже за тобой.

Главное в трёх строчках

Если убрать все детали, tool use держится на одной идее:

• Ты описываешь функции словами — имя, зачем, какие параметры.
• Claude решает, какую и когда позвать, и называет аргументы.
• Ты выполняешь свой код и возвращаешь результат — а он превращает его в ответ.

Модель остаётся мозгом, который рассуждает, а руками всё делает твой код. Похоже на магию, но под капотом — обычный обмен сообщениями. Тот же запрос по API, с которым ты уже знаком, просто с добавленным списком инструментов.

Хочешь потрогать это руками — от первого запроса до полноценного tool use? Мы разбираем API по шагам и без воды.