Multi-tool AI агенты: как они вызывают инструменты и зачем

Чистая LLM умеет одно — генерировать текст в ответ на текст. Это всё. Чтобы превратить её в полезный агент, ей нужно дать набор инструментов: поиск в интернете, выполнение кода, чтение файлов, отправка email, что угодно ещё. Этот механизм называется tool use или function calling, и он лежит в основе любого современного AI-агента.

Tool use часто воспринимается как «чёрная магия» — как будто модель сама понимает что когда вызвать. Реальность скучнее и инженернее. Разбираем как именно это работает, почему правильный набор инструментов важнее самой модели, и какие подводные камни возникают в production.

Что такое tool в контексте AI-агента

Tool — это любая функция, которую модель может вызвать вместо «обычного ответа текстом». У каждого tool'а есть:

• Имя — например web_search или run_python.
• Описание — на естественном языке: «Поиск в интернете. Используй когда нужна свежая или фактологическая информация».
• JSON-схема параметров — какие аргументы принимает: query (строка), max_results (число), и т.д.
• Реальная реализация на стороне сервера — Python-функция, HTTP-запрос, что угодно.

При каждом запросе пользователя модели передаётся не только сам запрос, но и список доступных tools с их описаниями. Модель решает: ответить текстом или вызвать tool. Если вызвать — пишет в специальном формате имя tool'а и параметры. Сервер парсит, реально выполняет tool, возвращает результат модели — и она продолжает рассуждать с этим новым контекстом.

Как модель решает «вызывать или нет»

Самый частый вопрос: «как модель понимает, что пора звать инструмент?». Ответ — никакой магии. Модель видит описания tools, видит запрос пользователя, и оценивает: «может ли я ответить из своих знаний или мне нужны внешние данные/действия?».

На «сколько будет 12 × 47?» — Sonnet ответит «564» без tool'а (умеет считать). На «сколько сейчас идёт фильм X?» — вызовет web_search (не знает что показывают сейчас). На «прочитай PDF из моих файлов» — вызовет read_document.

Эта оценка не идеальна. Бывают ошибки:

• Модель отвечает текстом, когда лучше было бы вызвать tool (галлюцинирует факт, не желая искать).
• Модель вызывает tool, когда могла бы ответить и так (теряя время и токены).

Хорошие описания tools уменьшают ошибки. Плохо описанный tool («поиск») игнорируется или вызывается невпопад. Хорошо описанный («Поиск в интернете. Используй когда нужна свежая информация (новости, цены, события), факты которых нет в твоих знаниях, или подтверждение из независимых источников») — вызывается правильно.

Цикл: tool → результат → следующий шаг

Один запрос пользователя может породить несколько tool-вызовов в цикле. Типовая схема:

1. Пользователь: «Найди мне три похожих наушника на эти, по цене до 5000 рублей».
2. Модель: вызывает web_search с описанием наушников.
3. Сервер: возвращает 10 результатов.
4. Модель: смотрит на результаты, решает что нужно больше деталей. Вызывает browse_page на первые три ссылки.
5. Сервер: возвращает контент страниц.
6. Модель: теперь имеет полную картину, вызывает marketplace_search чтобы найти ещё похожие на маркетплейсах.
7. Сервер: возвращает товары с ценами.
8. Модель: складывает всё в финальный ответ пользователю.

4-5 tool-вызовов в одном «turn'е» — обычное дело для сложного запроса. Каждый вызов добавляет токены в контекст, увеличивает время ответа и стоимость. Поэтому хорошие агенты заботятся о минимизации лишних tool-вызовов.

Откуда берётся набор tools

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

В EPIHEN (на май 2026) набор inluding ~40 tools, в т.ч.:

• Поиск и чтение: web_search, browse_page, deep_read, academic_search.
• Файлы и документы: file_read, file_write, read_document, list_uploads.
• Создание контента: create_pdf, create_docx, create_xlsx, create_pptx, generate_image, generate_video.
• Исполнение: run_python, install_package, ssh_exec.
• Память: add_knowledge, notepad_read, notepad_write.
• Делегирование: run_subagent, run_agent (см. статью).
• Маркетплейсы: marketplace_search (Wildberries, Ozon).
• Аудио: analyze_audio_pro.
• Расписания и напоминания: create_schedule, set_reminder.
• Wordpress / CMS: wp_list_pages, wp_update_page, etc.

Набор curated — не все возможные tools одновременно доступны модели. Слишком много (50+) — модель путается, выбирает плохо. Слишком мало — упускает возможности.

Подводные камни и как с ними бороться

1. Циклы

Самая частая проблема. Модель вызывает tool, получает «не то», вызывает похожий tool, тоже «не то», вызывает первый ещё раз, и так до бесконечности. В реальности есть жёсткие лимиты количества tool-вызовов на один turn (обычно 25-50), но даже 30 циклов — это раздутый контекст и потерянные деньги.

Защита: каждые N tool-вызовов сервер вставляет «напоминание» — «ты уже делал 10 поисков, попробуй сменить подход или скажи пользователю что не получается». Помогает.

2. Галлюцинация параметров

Модель решает вызвать tool, но придумывает несуществующие параметры. Например web_search(query="...", lang="cz") когда схема не разрешает lang. Сервер должен валидировать и возвращать корректную ошибку «такого параметра нет, доступны: query, max_results» — модель быстро поймёт.

В EPIHEN мы строго валидируем все параметры через Pydantic-схемы и возвращаем ошибку модели сразу, не пытаясь «угадать».

3. Race conditions при параллельных вызовах

Современные модели (Claude 4.7) умеют вызывать несколько tools параллельно: «поищи в интернете и одновременно прочитай этот PDF». Если эти tools независимы — параллелизм ускоряет. Если зависимы (один опирается на результат другого) — модель может ошибиться и вызвать их одновременно, получив бесполезный результат.

Защита: явные подсказки в описаниях tools («вызывай только после X», «не комбинируй с Y»).

4. Сохранение результатов между шагами

Tool вернул большой результат (например 50K токенов из PDF). Если модель потом снова вызовет тот же tool с тем же запросом — это лишний расход. Кэширование на стороне сервера помогает, но требует аккуратной инвалидации.

5. Безопасность вызовов

Tool ssh_exec или run_python позволяет модели выполнять команды на серверах. Если её обмануть промптом — может сделать что-то опасное. Защита: sandbox-исполнение (Python в изолированной среде, SSH с ограниченным sudoers), список запрещённых команд, явное подтверждение пользователем для критичных действий.

Зачем нужны разные классы tools

Не все tools равноценны. У них разная стоимость, скорость и риски.

Дешёвые и безопасные (поиск, чтение файлов, чтение БД) — можно вызывать свободно, без подтверждения.

Средние (генерация изображений, видео, документов) — стоят денег, но не опасны. Логируем стоимость, иногда показываем пользователю «это будет стоить X поинтов».

Дорогие и медленные (sub-agents с тяжёлыми моделями, длинный reasoning) — используются только когда другие классы не справились.

Опасные (SSH-команды, write-операции в БД, отправка денег, удаление файлов) — требуют explicit user approval или работают только в режиме «admin». Модель не должна автоматически их вызывать без явного указания.

Почему набор tools важнее модели

Интересное наблюдение: для большинства реальных задач разница между Claude Sonnet и Claude Opus с одним и тем же набором tools — меньше, чем разница между Opus с хорошим набором tools и Opus с плохим набором.

«Хороший набор» — это:

• Покрытие нужных способностей (поиск, файлы, исполнение, etc.).
• Чёткие описания, минимум перекрытий между tools.
• Стабильные API tools — не ломаются на edge-cases.
• Умеренный размер (10-30 tools, не 100).

Это объясняет почему стартапы, которые делают «своего ChatGPT-конкурента», часто проваливаются. Модель у всех одинаковая (Claude / GPT). Разница — в том насколько хорошо построен tool layer вокруг неё. Это инжиниринг, не AI-research.

Перспективы: куда движется tool use

Несколько направлений на 2026-2027:

Universal Tool Calling (UTC). Стандартизация форматов tool definitions между провайдерами. Anthropic и OpenAI движутся в одном направлении. Через год можно будет писать tool один раз и использовать его с разными моделями.

Browser-агенты как universal tools. Вместо отдельных tools под каждое API — агент с доступом к браузеру. Computer Use от Anthropic, Operator от OpenAI — это движение в эту сторону. Заменит часть специфических tools.

Самообучение наборов tools. Эксперименты с агентами, которые сами замечают «мне часто нужно делать X, давайте создадим для этого tool». Пока экзотика, но интересно.

Резюме

Tool use — это не магия, а инжиниринг. Хороший набор tools с хорошими описаниями превращает обычную LLM в полезного агента. EPIHEN построен вокруг этого принципа: ~40 курированных tools, каждый с подробным описанием, валидацией параметров и продуманной безопасностью.

Если хотите построить своего агента — главное вложение времени тратьте не в выбор модели (любая топ-модель справится), а в дизайн tools: какие нужны, как их описать, как защитить от ошибок.

В следующих статьях разбираем vibe-coding и подробности по конкретным моделям.