Tool calling: базовые и расширенные инструменты AI-агента

Качество агента редко упирается в саму модель - чаще в то, какие инструменты ей дали и насколько предсказуемо они вызываются. Плохо спроектированный tool calling ломает даже сильную модель: она либо не понимает, когда вызывать инструмент, либо получает от него неструктурированный ответ, который не может использовать дальше.

Базовые инструменты: web search, web fetch, browser

Для большинства задач хватает связки web search -> web fetch -> browser с эскалацией только при необходимости. Подробный разбор каждого инструмента, порядок вызова и метрики - в статье Web fetch, web search, browser: базовый стек инструментов AI-агента.

Расширенные инструменты агента

Помимо базовой тройки, в продуктовых сценариях агенту обычно нужны:

• Code execution / интерпретатор кода - для расчетов, парсинга данных и генерации файлов, которые ненадежно делать текстом.
• Работа с файлами - чтение и запись документов, экспорт отчетов, обработка вложений.
• Retrieval / RAG-инструмент - поиск по внутренней базе знаний вместо общего web search, когда источник истины - ваши данные, а не интернет.
• Коннекторы к внутренним системам (MCP и аналоги) - CRM, PMS, биллинг, тикет-система: агент читает или меняет реальные бизнес-данные.
• Computer use - прямое управление интерфейсом ОС или приложения; крайний случай, когда нет API и не хватает browser-автоматизации.
• Delegation / handoff - вызов другого агента или sub-workflow под конкретную подзадачу вместо расширения одного универсального промпта.
• Memory / state tools - чтение и запись состояния между сессиями, если агенту нужно помнить контекст дольше одного диалога.

Расширенные инструменты почти всегда меняют что-то в реальной системе - это отдельный класс риска по сравнению с read-only поиском.

Как проектировать инструмент, а не просто функцию

• Явная схема входа: типы, обязательные поля, ограничения (enum, min/max) - модель должна понимать границы до вызова, а не по факту ошибки.
• Явная схема выхода - чтобы модель могла проверить результат по структуре, а не парсить произвольный текст.
• Одна ответственность на инструмент: не смешивать “найти и обновить” в одном вызове - это усложняет и логирование, и откат.
• Структурированные ошибки (код + сообщение), а не сырое исключение - модель должна уметь отличить “не найдено” от “сервис недоступен”.
• Идемпотентность для операций записи, чтобы повторный вызов при таймауте не задвоил действие.
• Таймаут и retry-политика на каждый инструмент отдельно, а не одна общая на весь агент.

Параллельные и последовательные вызовы

• Параллельные вызовы разрешать только для read-only инструментов без побочных эффектов.
• Action-инструменты вызывать последовательно, с проверкой результата предыдущего шага перед следующим.
• Дедуплицировать вызовы с идентичными аргументами в рамках одной сессии - типичный источник лишних затрат и дублей.

Чеклист перед продакшеном

• У каждого инструмента есть версия схемы и changelog изменений контракта.
• Ошибка инструмента возвращается модели как данные, а не роняет всю сессию.
• Логируется каждый вызов: имя инструмента, аргументы, результат, latency.
• Есть явное разделение read-only и action-инструментов.

Где заканчивается tool calling и начинается guardrails

Все перечисленное выше - про то, чтобы инструмент вызывался корректно и предсказуемо. Отдельный вопрос - можно ли вообще разрешать модели этот вызов в конкретной ситуации: это уже уровень политики доступа и защиты, а не механики вызова. Разбор этого слоя - в статье Guardrails для AI-агентов: input, output и защита действий.