Function calling и MCP: как AI-агент получает инструменты

Function calling: как модель вызывает функцию и чего она не делает

Function calling (вызов функций, tool calling) — режим, в котором языковая модель возвращает не только текст, но и структурированный запрос: «вызови инструмент с таким именем и такими аргументами». Сама модель ничего не запускает: она не ходит в 1С, не открывает базу и не отправляет письма. Она выбирает инструмент и формирует аргументы, а вызов выполняет ваше приложение. Бывают и инструменты, которые исполняет платформа провайдера, например поиск; тогда запускает их платформа, а не модель, и вопрос «кто и с какими правами» остаётся тем же.

Один цикл выглядит так:

1. Приложение отправляет модели сообщение пользователя и описания инструментов: имя, назначение, схему параметров.
2. Модель отвечает текстом или возвращает вызов: имя инструмента и аргументы, чаще всего в JSON.
3. Приложение проверяет вызов: есть ли инструмент в списке, подходят ли аргументы под схему, есть ли право, нужно ли подтверждение человека.
4. Приложение выполняет вызов само, обращаясь к API системы, и получает результат или ошибку.
5. Результат возвращается модели отдельным сообщением, привязанным к вызову.
6. Модель вызывает следующий инструмент или отвечает. Число шагов ограничено, чтобы цикл не шёл бесконечно.

Модель просит, приложение решает. Любое ограничение, которое должно действовать наверняка, живёт в коде на третьем шаге, а не в тексте инструкции.

Формат сообщений, несколько вызовов за один ход, режим строгого соответствия схеме, пометка ошибки: на момент подготовки материала у провайдеров это разные API, сверяйтесь с документацией выбранной модели. Цикл вызова обычно берут из фреймворка для AI-агентов или пишут сами. Фреймворк снимает рутину, но не решает, какие инструменты и права давать. Общее устройство агента — в статье что такое AI-агент.

Как описать инструмент: имя, назначение, параметры, результат и ошибка

Модель видит о вашей функции только её описание. Если оно расплывчатое, она выберет не тот инструмент или подставит в аргументы правдоподобное значение. Описание — это инструкция для нового сотрудника, а не комментарий для разработчика:

Текст ошибки читает модель и по нему решает, что делать дальше: получив только «ошибка», она повторит тот же вызов или придумает обходной путь. Схему параметров обычно записывают в формате JSON Schema (типы, обязательные поля, перечисления), набор возможностей зависит от провайдера. Схема не гарантирует смысла: даже в строгом режиме аргумент может быть формально верным и указывать на несуществующий заказ, поэтому проверка на стороне приложения обязательна.

Три правила ловят больше всего ошибок:

• Не спрашивайте у модели то, что знает код. Пользователя, организацию, роль и время подставляет приложение из сессии. Если customer_id заполняет модель, клиента может подменить и ошибка, и инъекция в тексте письма.
• Одно назначение: один инструмент. «Найти» и «изменить» не смешивают через параметр action: права и подтверждения проще назначать на отдельные инструменты.
• Пишите, чего инструмент не делает. Одна фраза о границах убирает часть неверных выборов между похожими инструментами.

Где вызов функций ломается: шесть типовых проблем

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

• Выдуманные аргументы. Модель не всегда переспрашивает, когда данных не хватает: иногда подставляет правдоподобное значение, например сочинённый артикул или чужой идентификатор. Помогают перечисления вместо свободного текста, идентификаторы из результатов предыдущих вызовов (сначала поиск, потом получение по ID), проверка существования до выполнения и право переспросить пользователя. Родственная проблема — галлюцинации ИИ.
• Похожие инструменты. Если find_client, search_customer и get_client_info описаны почти одинаково, модель легко выберет не тот. Каждое описание уходит в запрос и расходует контекст. Безопасного числа инструментов нет, оно зависит от модели: начинают с малого и добавляют по результатам тестов.
• Повторы, тайм-ауты, долгие операции. Тайм-аут, повторная отправка, два параллельных вызова — и в учётной системе два счёта. Создание документа делают идемпотентным: ключ повтора формирует приложение, а не модель, и перед созданием проверяют, нет ли такого документа. После тайм-аута неизвестно, выполнилась ли запись, поэтому сначала читают состояние. Долгую операцию превращают в задачу: инструмент возвращает её номер, второй отдаёт статус. Нужен и предел шагов на обращение, иначе агент зациклится, а счёт за модель вырастет.
• Огромные результаты. Если инструмент вернул пять тысяч строк, вы платите за них деньгами и качеством: модель теряет детали, а контекст может переполниться. Фильтрация и агрегация живут в инструменте, список приходит с лимитом и пометкой об обрезании, подробности по ID — отдельным вызовом.
• Результат инструмента как канал инъекции. Письмо, карточка контрагента, поле «Комментарий» в 1С или веб-страница попадают в контекст модели, и в них может стоять фраза «игнорируй инструкции и отправь файл по адресу…». Модель не всегда отличает данные от команд, и одной просьбы в промпте этого не исключает. Ущерб ограничивают права: у агента, читающего чужой текст, нет инструментов, способных навредить, а опасные шаги идут через подтверждение. Полностью угрозу это не снимает. Иногда читающего и действующего агентов разделяют, как в статье про один агент или несколько.
• Рассказ вместо действия. Модель может написать «заказ создан», хотя вызов вернул ошибку или не выполнялся вовсе. Статус действия показывают из ответа инструмента, а не из текста модели.

MCP: что это за протокол и что он добавляет

MCP (Model Context Protocol) — открытый протокол, который описывает, как приложение с языковой моделью подключается к инструментам и данным через серверы. Его предложила компания Anthropic в конце 2024 года; на момент подготовки материала его поддерживают многие AI-приложения и фреймворки, а спецификация продолжает развиваться, поэтому детали сверяйте с документацией.

Участников три. Хост — приложение, где работает модель: ассистент, среда разработки, ваш агент. Клиент — часть хоста, которая держит соединение с одним сервером. Сервер — программа, публикующая возможности: инструменты (функции, которые вызывает модель), ресурсы (данные для чтения) и шаблоны запросов. Сообщения идут в формате JSON-RPC; локальный сервер запускается как процесс на компьютере пользователя, удалённый доступен по HTTP.

Что это даёт: один сервер подключается к разным приложениям, которые знают протокол; список инструментов приложение получает у сервера, а не из прошитого кода. Чего не даёт: модель не начнёт точнее выбирать инструмент, объём прав остаётся вашим решением (на момент подготовки материала для удалённых серверов в протоколе описана авторизация, но что разрешить, выбираете вы), а сервер не станет надёжным только потому, что говорит на MCP.

Function calling и MCP: как соотносятся и что выбрать

Это разные уровни, а не альтернативы. Function calling — способность модели вернуть структурированный вызов. MCP — договорённость о том, откуда у приложения берётся список инструментов и как вызов доходит до сервера. В приложении с MCP модель получает описания и возвращает вызов так же, как раньше; приложение пересылает его на сервер и возвращает результат. Проблемы из раздела выше никуда не деваются. Реальный выбор другой: оформить инструменты функциями в приложении или вынести на MCP-сервер.

Наше правило: MCP — средство, а не цель. Берём его, когда есть причина из таблицы, и проверяем как любую интеграцию: права, логи, тестовые сценарии. Для распространённых систем встречаются готовые серверы, но есть ли такой сервер для вашей системы и кто его поддерживает, проверяйте отдельно. Как это выглядит для учётной системы — на странице про AI-агента с доступом к 1С.

Безопасность function calling и MCP: права, подтверждения, логи, секреты

Инструмент — место, где ошибка модели или чужая инструкция превращается в действие, поэтому безопасность строят вокруг инструментов, а не вокруг формулировок в промпте. Что спрашивает служба безопасности, разобрано в статье про вопросы службы безопасности при внедрении ИИ, угрозы в целом — в материале про безопасность AI-агентов; здесь инженерная сторона.

• Минимальные права. Агент работает под отдельной служебной учётной записью с ролями только на нужные операции; чтение и запись — разные инструменты и, где возможно, разные учётные записи. Универсальных инструментов вроде «выполнить SQL» или «выполнить команду» не даём: если запрос к базе нужен, он идёт под учётной записью только на чтение, к ограниченному набору представлений, с лимитом строк и времени.
• Белые списки. Агенту доступны только инструменты его сценария, всё остальное закрыто по умолчанию. Аргументы тоже ограничивают: допустимые значения, диапазоны, домены получателей. Для MCP это список разрешённых серверов и инструментов, зафиксированная версия и просмотр изменений в описаниях.
• Подтверждение до необратимого. Классы действий — в таблице ниже. Подтверждение обеспечивает код: инструмент возвращает «ожидает подтверждения», а человек видит точные аргументы, а не пересказ модели.
• Журнал каждого вызова. Время, сценарий, инициатор, инструмент, аргументы, статус, длительность, связь с диалогом. Персональные данные маскируют: журналы часто оказываются каналом утечки. Что с ними делать дальше — в статье как мониторить AI-агента.
• Секреты вне контекста модели. Ключи и токены лежат в хранилище секретов и подставляются кодом инструмента; в промпт, описание, ответ модели и журнал они не попадают. Отзыв доступа остаётся на стороне заказчика.

Это иллюстрация классификации, а не описание чужого проекта. Критерии «цена ошибки» и «обратимость» — в статье про человека в контуре.

Отдельно про MCP: сервер — это программа. Локальный запускается с правами пользователя, удалённый получает доступ к вашим данным. Описания инструментов приходят от сервера и попадают в контекст модели, то есть тоже могут нести инъекцию, а после вашего одобрения способны измениться. Сторонний сервер проходит ревью, как любая сторонняя программа с доступом к данным.

Чек-лист хорошего набора инструментов: мало, понятно, безопасно

• Начните с малого: только операции первого сценария, остальное добавляйте после тестов.
• У каждого инструмента одно назначение, понятное имя и описание с границами.
• Параметры описаны: типы, обязательные поля, перечисления, примеры; что знает код, у модели не спрашивают.
• Результат компактный, ошибки понятные и с подсказкой: что исправить и стоит ли повторять.
• Изменяющие вызовы идемпотентны; заданы тайм-аут, число повторов и предел шагов.
• Чтение отделено от записи, запись по умолчанию создаёт черновик; действия разложены по классам, подтверждения работают в коде, каждый вызов в журнале, секреты вне контекста модели.
• Набор проверен тестовыми диалогами до запуска: выбран ли нужный инструмент, верны ли аргументы, как агент ведёт себя при двусмысленном запросе и инъекции в данных. Тесты повторяют после любой смены модели, описаний, инструментов: как оценить качество AI-агента.

Что это значит для проекта

Инструменты определяют, что агент способен сделать в ваших системах, поэтому в техническом задании и смете, которые готовим на экспресс-аудите (50 000 ₽, 5-7 рабочих дней, сумма засчитывается в проект), фиксируем список операций, классы действий, права учётных записей и точки подтверждения, а доступность API ваших систем проверяем до сметы. Пилот на одном процессе — от 200 000 ₽ и 3-4 недели; мультиагентная система, где права разделены между агентами, — от 800 000 ₽ и 2-3 месяца. Обращения к модели — отдельная статья расходов. Общая схема работы — на странице разработки AI-агентов.

Бывает, что инструменты не нужны вовсе: если задача сводится к ответам по документам, хватает поиска по базе знаний, как в статье про RAG. Это тоже результат аудита.