Что такое tool calling и как ИИ вызывает инструменты

Короткое объяснение

Tool calling - это механизм, при котором ИИ не только пишет текст, но и выбирает внешний инструмент для выполнения действия: поиск, запрос к базе, создание задачи, проверку статуса заказа, отправку письма, расчет, вызов API или запись в CRM.

Если совсем просто:

1. пользователь задает задачу;
2. модель понимает, что одного текста недостаточно;
3. модель выбирает подходящий инструмент;
4. формирует аргументы для вызова;
5. backend выполняет инструмент;
6. результат возвращается модели;
7. модель пишет итоговый ответ пользователю.

Tool calling - одна из главных технологий, которая превращает чат-бота в AI-агента.

Зачем нужен tool calling

Обычная LLM генерирует ответ на основе контекста. Но она сама по себе не может открыть вашу CRM, проверить оплату, создать задачу, прочитать базу данных или отправить сообщение.

Tool calling нужен, чтобы модель могла работать с внешним миром через безопасные функции.

Примеры:

1. найти заказ по номеру;
2. проверить статус доставки;
3. создать лид в CRM;
4. получить свободные слоты календаря;
5. найти документ в базе знаний;
6. посчитать стоимость;
7. сгенерировать отчет;
8. создать черновик письма;
9. вызвать внутренний API;
10. передать диалог оператору.

Без инструментов ИИ может только предполагать. С инструментами он может получать актуальные данные и выполнять управляемые действия.

Простой пример

Пользователь пишет:

Проверь, оплачен ли заказ 18492.

Если у модели нет инструмента, она не знает ответ. Она может только попросить проверить вручную или, что хуже, начать выдумывать.

С tool calling сценарий выглядит так:

1. модель выбирает инструмент `get_order_status`;
2. передает аргумент `order_id = 18492`;
3. backend вызывает CRM или базу заказов;
4. CRM возвращает статус “оплачен”;
5. модель отвечает: “Заказ 18492 оплачен”.

Важный момент: модель не должна сама иметь прямой доступ к базе. Она предлагает tool call, а backend выполняет его по правилам.

Чем tool calling отличается от обычного промпта

Промпт задает инструкции. Tool calling добавляет действия.

Промпт может сказать:

1. как отвечать;
2. какой стиль использовать;
3. что нельзя делать;
4. какие данные учитывать;
5. какой формат вернуть.

Tool calling позволяет:

1. получить актуальные данные;
2. выполнить расчет;
3. вызвать API;
4. создать объект;
5. обновить запись;
6. передать задачу дальше;
7. проверить результат.

Хороший промпт без tools остается текстовой инструкцией. Tools дают системе рабочие руки, но эти руки должны быть ограничены.

Чем tool calling отличается от RAG

RAG обычно ищет знания в документах. Tool calling вызывает функцию или сервис.

RAG подходит, когда нужно:

1. найти фрагмент инструкции;
2. ответить по базе знаний;
3. показать источник;
4. объяснить правило;
5. работать с документами.

Tool calling подходит, когда нужно:

1. получить статус из системы;
2. выполнить действие;
3. создать запись;
4. обновить данные;
5. вызвать внешний API;
6. посчитать результат.

В реальном агенте они часто работают вместе: RAG находит правило, tool calling проверяет статус заказа, модель формирует ответ.

Как устроен tool calling

Внутри обычно есть несколько частей.

1. Описание инструмента.
2. Схема аргументов.
3. Правила доступа.
4. Модель, которая выбирает инструмент.
5. Backend, который выполняет вызов.
6. Лог вызова.
7. Проверка результата.
8. Ответ пользователю.

Модель не должна “сама сходить в интернет” или “сама записать в CRM”. Она возвращает структурированное намерение: какой инструмент вызвать и с какими аргументами. Исполнение остается на стороне приложения.

Что такое инструмент

Инструмент - это функция, API или действие, которое приложение разрешает модели использовать.

Инструментом может быть:

1. поиск по базе знаний;
2. чтение карточки клиента;
3. получение статуса заказа;
4. создание задачи;
5. отправка уведомления;
6. расчет цены;
7. проверка календаря;
8. генерация PDF;
9. запуск workflow в n8n;
10. обращение к внутреннему API.

Хороший инструмент должен быть маленьким, понятным и ограниченным. Инструмент “делай что угодно в CRM” опаснее, чем отдельные `get_lead`, `create_task`, `draft_email`.

Что такое schema

Schema описывает, какие аргументы принимает инструмент и в каком формате.

Например, инструмент `get_order_status` может принимать:

1. `order_id` - строка или число;
2. `customer_phone` - необязательное поле;
3. `channel` - сайт, маркетплейс или офлайн;
4. `request_id` - id запроса для логов.

Schema нужна, чтобы модель не передавала свободный текст вместо структуры.

Хорошая schema:

1. описывает обязательные поля;
2. запрещает лишние поля;
3. задает типы данных;
4. ограничивает enum-значения;
5. объясняет, когда инструмент использовать;
6. содержит понятные описания;
7. не содержит секреты и приватные API-ключи.

Что такое tool call

Tool call - это структурированная заявка модели на вызов инструмента.

Примерно:

1. инструмент: `create_support_ticket`;
2. аргументы: тема, описание, id клиента, приоритет;
3. причина: пользователь просит передать вопрос оператору.

Tool call еще не означает, что действие уже выполнено. Это только запрос на выполнение. Backend должен проверить права, аргументы, риск и только потом вызвать реальный сервис.

Что такое tool result

Tool result - это результат выполнения инструмента, который возвращается модели.

Например:

1. “заказ найден”;
2. “статус: доставляется”;
3. “задача создана, id 912”;
4. “свободные слоты: 10:00, 12:30, 15:00”;
5. “ошибка: клиент не найден”;
6. “действие требует подтверждения”.

Модель использует tool result, чтобы написать понятный ответ. Но лучше не отдавать модели лишние данные: секреты, полные персональные данные, внутренние токены, технические поля.

Кто реально выполняет действие

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

Правильное разделение:

1. модель выбирает инструмент;
2. backend валидирует аргументы;
3. backend проверяет права;
4. backend решает, нужен ли approval;
5. backend вызывает API;
6. backend логирует результат;
7. модель формирует ответ.

Это важная граница безопасности. Если модель ошиблась в выборе инструмента, backend должен остановить опасный вызов.

Read-only, draft-only и write tools

Tools лучше делить по риску.

Read-only tools только читают данные:

1. получить статус;
2. найти документ;
3. прочитать карточку;
4. посмотреть наличие товара.

Draft-only tools создают черновик:

1. подготовить письмо;
2. создать черновик задачи;
3. собрать проект ответа;
4. подготовить коммерческое предложение.

Write tools меняют внешний мир:

1. отправить письмо;
2. обновить CRM;
3. списать деньги;
4. удалить файл;
5. изменить статус заказа.

Начинать лучше с read-only и draft-only. Write tools добавляют только после тестов, логов и подтверждений.

Approval: когда нужен человек

Approval - это подтверждение действия человеком или отдельным правилом перед выполнением.

Approval нужен, если tool:

1. отправляет сообщение клиенту;
2. меняет деньги;
3. меняет статус заказа;
4. удаляет данные;
5. дает скидку;
6. раскрывает чувствительную информацию;
7. создает юридически значимый документ;
8. влияет на доступы;
9. запускает внешнюю команду;
10. работает с персональными данными.

Модель может подготовить действие, но финальное “выполнить” должен подтвердить человек или строгая бизнес-логика.

Почему tool calling опасен без ограничений

Tool calling усиливает ИИ, но также усиливает ошибки.

Риски:

1. модель выбрала не тот инструмент;
2. передала неверные аргументы;
3. вызвала tool из-за prompt injection;
4. раскрыла лишние данные;
5. выполнила действие без подтверждения;
6. создала дубли;
7. изменила чужую запись;
8. ушла в бесконечный цикл вызовов;
9. потратила деньги на лишние API-запросы;
10. поверила вредной инструкции из внешнего документа.

Поэтому tool calling нельзя строить только на доверии к промпту.

Guardrails для инструментов

Для tools нужны отдельные guardrails.

Минимальные правила:

1. allowlist инструментов;
2. запрет неизвестных tools;
3. проверка аргументов по schema;
4. проверка прав пользователя;
5. лимит количества вызовов;
6. idempotency для повторных действий;
7. approval для write tools;
8. маскирование персональных данных;
9. audit log каждого вызова;
10. понятный fallback при ошибке.

Системный промпт помогает, но настоящая защита должна жить в backend.

Что такое idempotency

Idempotency защищает от повторного выполнения одного и того же действия.

Пример проблемы:

1. агент создает задачу в CRM;
2. сеть временно падает;
3. система повторяет вызов;
4. в CRM появляются две одинаковые задачи.

Idempotency key помогает backend понять, что повторный вызов относится к тому же действию. Это особенно важно для write tools: оплаты, задач, писем, заказов и статусов.

Tool calling и structured output

Tool calling близок к structured output. В обоих случаях модель должна вернуть структуру, а не свободный текст.

Structured output полезен, когда нужно:

1. извлечь поля из текста;
2. вернуть JSON;
3. классифицировать обращение;
4. заполнить форму;
5. подготовить аргументы для tools.

Tool calling идет дальше: структура становится заявкой на действие. Поэтому к tool calls требования строже: валидация, права, логи и безопасность.

Tool calling и AI-агенты

AI-агент часто работает циклом:

1. понять цель;
2. выбрать следующий шаг;
3. вызвать tool;
4. получить результат;
5. оценить, достаточно ли данных;
6. вызвать следующий tool или завершить;
7. сформировать ответ.

Без tools агент остается разговорным ассистентом. С tools он может реально двигать задачу: искать, проверять, создавать, обновлять, отправлять на согласование.

Примеры инструментов для разных задач

Для поддержки:

1. `search_knowledge_base`;
2. `get_order_status`;
3. `create_support_ticket`;
4. `handoff_to_operator`.

Для продаж:

1. `find_lead`;
2. `create_crm_task`;
3. `draft_followup_email`;
4. `check_meeting_slots`.

Для документов:

1. `search_contract`;
2. `extract_fields`;
3. `create_document_summary`;
4. `send_for_review`.

Для аналитики:

1. `run_sql_query`;
2. `get_dashboard_metric`;
3. `create_report_draft`;
4. `notify_manager`.

У каждого инструмента должны быть границы: что он может, что не может и когда его нельзя использовать.

Как тестировать tool calling

Тестировать нужно отдельно от красоты ответа.

Проверяйте:

1. выбрал ли агент правильный tool;
2. передал ли правильные аргументы;
3. не вызвал ли запрещенный tool;
4. обработал ли ошибку API;
5. не сделал ли повторный write-call;
6. попросил ли approval;
7. не раскрыл ли лишние данные;
8. остановился ли после лимита;
9. корректно ли ответил пользователю;
10. записался ли audit log.

Для критичных tools нужен regression dataset: набор типовых и опасных сценариев, который прогоняется после изменения промпта, модели или backend.

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

Частые ошибки при внедрении tool calling:

1. слишком широкие инструменты;
2. нет schema validation;
3. нет проверки прав;
4. write tools включены сразу;
5. нет approval;
6. tool description содержит секреты;
7. результат tool возвращает слишком много данных;
8. нет логов;
9. модель обещает действие, которое еще не выполнено;
10. ошибки API маскируются красивым ответом;
11. нет лимита вызовов;
12. нет тестов на prompt injection.

Хорошая система делает tools маленькими, проверяемыми и обратимыми.

Мини-чеклист

Перед запуском tool calling проверьте:

1. список tools ограничен;
2. у каждого tool есть понятная задача;
3. schema валидирует аргументы;
4. секреты не попадают в prompt;
5. read-only tools отделены от write tools;
6. write tools требуют approval;
7. есть audit log;
8. есть лимит вызовов;
9. есть обработка ошибок;
10. есть тесты на опасные сценарии.

Если этого нет, лучше оставить агенту только чтение и черновики.

Что изучать дальше

После tool calling полезно изучить:

1. structured output;
2. function calling;
3. MCP;
4. guardrails;
5. human-in-the-loop;
6. AI-агенты;
7. agent memory;
8. audit log;
9. evals для agents;
10. sandbox для инструментов.

Эти темы помогают строить агента, который не просто отвечает, а безопасно работает с системами.

Частые вопросы

Tool calling и function calling - это одно и то же?

В бытовом смысле почти да. Function calling чаще звучит как вызов функции с аргументами, tool calling шире: инструментом может быть API, поиск, workflow, база данных или действие в сервисе.

Модель сама выполняет tool?

Нет. Модель обычно только предлагает, какой tool вызвать и с какими аргументами. Реальное выполнение делает backend, который должен проверить права, schema, риск и логику.

Можно ли давать ИИ доступ на запись сразу?

Лучше нет. Начинайте с read-only и draft-only tools. Запись в CRM, отправка писем, удаление данных, платежи и изменение статусов должны появляться только после тестов, approval и логов.

Почему tool calling важен для AI-агентов?

Потому что агенту нужны действия. Без инструментов он может только обсуждать задачу. С инструментами он может искать данные, проверять статусы, создавать черновики, вызывать API и двигать процесс к результату.

Что опаснее всего в tool calling?

Самое опасное - широкий tool с большими правами без approval и логов. Ошибка модели, prompt injection или неверный аргумент тогда превращаются в реальное действие во внешней системе.