Почему tool calling в LLM‑агентах нельзя воспринимать как обычный API‑вызов
При разработке агентных систем на базе LLM команды часто упираются в одну и ту же ситуацию. Модель вызывает инструмент, что‑то ломается, а понять причину трудно. Автор материала в Towards AI объясняет, откуда это берется. Распространенная ошибка инженеров в том, что tool calling воспринимают как работу с REST‑клиентом: описали схему, указали endpoint, отправили корректный payload. На практике такой подход быстро дает сбой. Модель, которая инициирует вызов, не детерминирована. Она не обязана выдавать идеально структурированные аргументы, может не распознать момент, когда инструмент вызывать не нужно, и часто плохо реагирует на неожиданный ответ со стороны инструмента.
Еще одна типичная проблема связана со схемами инструментов. Их нередко пишут так, будто текст читает человек. Но решение о вызове принимает сама LLM, опираясь на описание в схеме, поэтому любая двусмысленность превращается в догадку. Если назначения инструментов пересекаются, модель может выбрать любой из них. В статье приводится пример: агент вызывал get_record вместо search_records, потому что в обоих описаниях фигурировала формулировка "retrieving data". Исправлять пришлось не логику маршрутизации. Достаточно было переписать описания и четко обозначить границы поведения: что именно делает инструмент, чего он не делает и в каких условиях его следует использовать.
Есть и другая распространенная ошибка, отсутствие проверки аргументов перед выполнением инструмента. Во многих ранних реализациях вызов, сформированный моделью, сразу передают функции без валидации, проверки типов и ограничений. При этом LLM нередко генерируют некорректные аргументы. Строковое поле может оказаться числом, обязательный параметр может прийти как null, значение enum иногда выходит за пределы допустимого набора. Такие ошибки не всегда приводят к явному сбою. Они способны тихо просачиваться в базы данных, внутренние сервисы и журналы. Поэтому автор советует проверять схему на уровне MCP или на границе функции, еще до фактического выполнения инструмента.
Ключевые факты
Автор описывает опыт построения tool‑driven агентных систем в MasTec, где LLM‑агенты оркестрируют enterprise API, операционные базы данных и внутренние сервисы в production‑среде.
В материале выделены пять повторяющихся ошибок при внедрении tool calling в агентных системах.
Одна из ошибок, схемы инструментов пишутся как документация для разработчиков, а не для модели, из‑за чего агент может выбрать, например, get_record вместо search_records, если описания пересекаются.
В примере «production‑grade» схемы инструмент get_customer_by_id требует точный customer_id формата 'cust_XXXXXXXXXX' и явно указывает использовать его только при наличии подтверждённого идентификатора.