Вызов функций (в англоязычной документации — function calling или tool calling) — это механизм, которым языковая модель запускает действия в ваших системах: создаёт сделку в CRM, резервирует товар, отправляет счёт. Работает он не так, как звучит: модель ничего не выполняет сама. Она возвращает заполненный бланк — имя действия и значения параметров, — а решение выполнять его принимает ваш код.
Для владельца бизнеса из этого следует одна практическая вещь. Когда подрядчик говорит «агент оформляет заявки», спрашивать надо не про модель, а про окошко: кто проверяет бланк, какие действия вообще есть в списке разрешённых, что происходит при повторной подаче того же бланка и на какой сумме требуется подпись человека. Ответственность и лимиты живут в этом слое, и он пишется руками — его нельзя получить, выбрав модель подороже.
Дальше — механизм по шагам на одном обращении клиента; четыре ошибки, которые модель делает регулярно, и что ловит каждую; расчёт убытка без ограничителей и цены контура; порог объёма, ниже которого контур не окупается; и связь всего этого с протоколом MCP.
Модель заполняет бланк, а не открывает склад
Способ дать модели список доступных действий и получить от неё структурированный ответ вида «вызвать действие получить_статус_заказа с параметром номер = 4417» вместо обычного текста. Список действий уходит в модель вместе с вопросом; выбор действия делает модель, а выполнение — программа-посредник между моделью и вашей учётной системой.
Полезная аналогия — склад с окошком выдачи. Новый сотрудник не заходит в помещение и не берёт коробку сам: он заполняет бланк заявки и подаёт в окошко. Кладовщик сверяет бланк со списком того, что этому сотруднику разрешено, проверяет, нет ли такой же заявки за последние пять минут, и только потом идёт к стеллажу. Сотрудник может ошибиться в бланке — написать несуществующий артикул или чужую фамилию, — но на склад эта ошибка не попадёт: её остановит кладовщик.
Модель здесь — сотрудник, а кладовщик — ваш код. Самая частая ошибка проектирования выглядит так: окошко есть, кладовщика нет. Бланк уходит прямо в 1С, потому что «модель ведь умная». Умная — да, но она генератор предложений, а не исполнитель: она не знает, что этому клиенту скидка больше 10 % не согласована. Список необратимых действий стоит составить до запуска, а не после.
Пять шагов одного вызова
Возьмём живое обращение: клиент оптовой компании пишет в чат «добрый день, что там с моим заказом от вторника». За полторы секунды происходит пять шагов, и увидеть их можно только в журнале.
- 1Список функций уходит в модель вместе с вопросом
К вопросу добавляется перечень доступных действий: имя, назначение словами, параметры, что возвращается. Это часть запроса и тарифицируется как обычный текст — описание пяти-девяти функций весит 300–500 токенов на каждом запросе.
- 2Модель выбирает функцию и заполняет параметры
Ответ приходит не текстом для клиента, а структурой: «получить_статус_заказа, номер = 4417». Номер модель берёт из истории диалога или из карточки клиента, если её подставили в запрос. Если номера нет нигде, правильное поведение — не угадать, а вернуть уточняющий вопрос.
- 3Ваш код проверяет бланк
Здесь и стоит весь контроль: есть ли такая функция в белом списке, соответствуют ли параметры объявленным типам, принадлежит ли заказ 4417 именно этому клиенту, не было ли такого же вызова минуту назад, не превышен ли лимит вызовов на диалог. Любая непройденная проверка — это отказ с понятной причиной, а не молчаливое выполнение.
- 4Система выполняет действие от имени служебной учётной записи
Запрос уходит в 1С или CRM под отдельной записью агента с правами ровно под выписанные действия. Не под администратором и не под учёткой менеджера — иначе в журнале системы вы не отличите агента от человека.
- 5Результат возвращается в модель, и она формулирует ответ
Модель получает четыре поля — статус, плановая дата, склад, признак предоплаты — и превращает их в человеческую фразу. Если система не ответила, в модель уходит явная отметка об ошибке, и агент обязан сказать «не смог посмотреть», а не придумать статус.
Горизонтальная схема потока данных из шести блоков со стрелками. 1) «Вопрос клиента: что там с заказом от вторника». 2) «Модель» — исходящая стрелка подписана «предложение вызова: получить_статус_заказа, номер = 4417». 3) Крупный блок «Ваш код: проверки» с четырьмя подписанными строками внутри: «функция в белом списке», «типы параметров», «заказ принадлежит этому клиенту», «не повтор за минуту». От этого блока вниз отходит красная стрелка «отказ с причиной», а вправо — «выполнить». 4) «Учётная система 1С:УТ», доступ подписан «служебная учётная запись, только чтение». 5) Обратная стрелка в блок «Модель» подписана «четыре поля: статус, дата, склад, предоплата». 6) «Ответ клиенту». Под блоком проверок отдельная ветка вниз к фигуре человека с подписью «необратимое действие — подтверждение, 40 секунд». Чертёжный стиль, все подписи по-русски.
Не между «агент умный» и «агент глупый», а между тем, какие функции лежат в белом списке. Агент только с функциями чтения физически не может испортить данные, что бы ни было написано в промте. Добавление первой функции записи — это смена уровня риска, а не расширение возможностей, и обсуждать её стоит вместе с уровнями автономности агента, а не в переписке между делом.
Четыре ошибки модели и что ловит каждую
Ошибки в бланке — не сбой и не признак плохого подрядчика: они встроены в природу механизма, потому что модель заполняет поля по смыслу, а не по справочнику. Задача проектирования — не убрать их, а сделать так, чтобы каждая упиралась в проверку и стоила 0 ₽.
| Что делает модель | Как выглядит для бизнеса | Что ловит | Где стоит проверка |
|---|---|---|---|
| Придумывает параметр, которого нет | Агент «зависает» или отвечает не по делу, в журнале — отказ системы | Сверка со схемой параметров: типы, обязательность, допустимые значения | До обращения к системе, в коде-посреднике |
| Вызывает одну функцию дважды | Два одинаковых резерва, две заявки, задвоенный документ в учёте | Ключ идемпотентности: повторный вызов с тем же ключом возвращает прежний результат | В коде-посреднике, ключ формируется из диалога и параметров |
| Подставляет данные не того клиента | Клиенту сообщают чужой статус заказа или чужую сумму долга | Идентификатор клиента берётся из сессии, а не из текста диалога | В коде-посреднике, до вызова, жёстким сравнением |
| Выполняет необратимое действие | Отгрузка, списание, скидка или возврат, сделанные без ведома человека | Список необратимых функций, потолок суммы и обязательное подтверждение | В коде-посреднике плюс интерфейс подтверждения у менеджера |
Если агент назвал клиенту чужой номер заказа с фамилией и суммой, вы передали персональные данные третьему лицу. Единственная надёжная защита — брать идентификатор клиента из авторизованной сессии канала и никогда из текста диалога, даже если клиент сам назвал номер. Смежные требования к правам служебных учётных записей разобраны в материале про принцип минимальных прав доступа.
Сколько стоит контур ограничителей и когда он окупается
Модельный пример: оптовая компания, агент в клиентском чате, 6 000 обращений в месяц, в 2 100 из них вызывается функция. Ставки сквозные для наших расчётов: час подрядчика 3 000 ₽, полный час менеджера заказчика 700 ₽, предметного специалиста 900 ₽. Доли ошибок — модельное допущение; свои надо взять из журнала вызовов за месяц, и это первое, что стоит потребовать от подрядчика.
Обратите внимание на распределение. Самая частая ошибка — неверный параметр — не стоит почти ничего, потому что её ловит проверка типов, которая пишется за час. Самая редкая — необратимое действие — даёт три четверти убытка. Это типичная картина: деньги теряются не там, где чаще ошибаются, а там, где ошибку нельзя отменить.
Теперь цена контура. Шесть ограничителей — это около 40 часов инженера: схема параметров с отказом при несовпадении (6 часов), ключ идемпотентности на каждый вызов (8), жёсткая привязка клиента к сессии (6), потолок суммы и лимит вызовов на диалог (5), интерфейс подтверждения необратимых действий (9), журнал вызовов с параметрами и результатом (6). По ставке 3 000 ₽/час это 120 000 ₽ разово.
Две параллельные горизонтальные шкалы одинаковой длины для одного и того же месяца на 2 100 вызовов. Верхняя «Как часто» разбита по долям: «неверный параметр — 63 случая», «двойной вызов — 25», «чужой клиент — 8», «необратимое действие — 4». Нижняя «Сколько стоит» разбита по рублям: «59 ₽», «5 825 ₽», «14 400 ₽», «48 000 ₽», причём последний сегмент занимает 70 % полосы и выделен тоном. Между шкалами перекрещивающиеся тонкие линии, связывающие одинаковые категории, — они наглядно расходятся. Внизу подпись «итого 68 284 ₽ в месяц; контур ограничителей — 120 000 ₽ разово, возврат за 1,8 месяца». Чертёжный стиль, подписи по-русски.
Порог объёма считается так же. При 400 вызовах в месяц те же доли дают около 4 000 ₽ ущерба от дублей и чужого клиента, и полный контур возвращается больше двух лет. Это честный повод его не строить: берутся три базовых ограничителя — схема параметров, ключ идемпотентности, привязка к сессии — на 60 000 ₽ с окупаемостью около 15 месяцев, а необратимые действия агенту просто не отдаются. Ни одной функции записи в белом списке — и четвёртая строка расчёта обнуляется бесплатно.
Как это связано с MCP и что спросить у подрядчика
MCP решает соседнюю задачу: он стандартизирует, как описать функцию, чтобы описание подошло любой поддерживающей модели. Проверки вызовов он не выполняет и выполнять не должен — это разные слои. Мы разбирали протокол подробно в материале про MCP простыми словами, а его применение к учётной системе — в разборе подключения агента к 1С через MCP. Практический вывод: ответ «у нас MCP» на вопрос про лимиты означает, что вам ответили не на тот вопрос.
- 1Покажите белый список функций. Сколько их, какие из них меняют данные и какие необратимы. Нормальная цифра — 5–9 функций на систему; тридцать означает, что список не проектировали.
- 2Где стоит проверка параметров и что происходит при отказе. Ответ «модель не ошибается» — стоп-сигнал. Правильный ответ описывает отказ с причиной и запись в журнал.
- 3Как формируется ключ идемпотентности. Если понятия нет, спросите, что произойдёт при двойном вызове функции создания заказа. Ответ покажет, думали об этом или нет.
- 4Откуда берётся идентификатор клиента. Единственный приемлемый ответ — из авторизованной сессии канала. Вариант «модель извлекает из диалога» означает риск выдачи чужих данных.
- 5Что пишется в журнал на каждый вызов. Минимум: время, диалог, имя функции, параметры, результат проверки, кто подтвердил. Без журнала вы не сможете ни посчитать доли ошибок, ни разобрать спор с клиентом.
Нарисованный абстрактный экран журнала вызовов: шапка таблицы и три строки-примера. Колонки подписаны: «Время», «Диалог», «Функция», «Параметры», «Проверки», «Результат», «Подтвердил». Первая строка — успешный вызов «получить_статус_заказа», проверки «4 из 4», результат «выполнено», подтверждение «не требуется». Вторая строка — «создать_возврат», проверки «4 из 4», результат «ожидает подтверждения», подтвердил «менеджер, 38 сек». Третья строка выделена контуром — «оформить_скидку», проверки «3 из 4: превышен потолок суммы», результат «отказ с причиной», подтвердил «—». Справа сбоку выноска: «эти три колонки и дают доли ошибок за месяц». Чертёжный стиль, подписи по-русски.
Когда вызов функций подключать не надо
Механизм полезен ровно там, где действие в системе действительно должно происходить по ходу разговора. Во всех остальных случаях он добавляет слой, который надо строить, проверять и обслуживать.
- Агенту достаточно чтения. Если задача — отвечать по регламентам и документам, никаких функций записи не нужно, и весь контур сводится к одному ограничителю. Это случай обычного поиска по базе знаний, а не действий в системах.
- Действие происходит реже пары раз в день. Менеджер сделает его быстрее, чем вы опишете функцию, напишете проверки и объясните агенту границу применения.
- У системы нет пригодного интерфейса. Если единственный способ создать документ — руками в толстом клиенте, сначала считается стоимость этого интерфейса, и она может оказаться больше всей автоматизации.
- Цена ошибки не измерена. Пока никто не может назвать, во что обходится один неверно оформленный документ, спорить о ограничителях бессмысленно: непонятно, какой из них окупается. С этого измерения и стоит начинать — как его провести, разобрано в материале про измерение процесса до внедрения.
- Подтверждать необратимые действия некому. Если нет человека, который смотрит очередь подтверждений в рабочее время, такие функции в белый список не попадают ни при каких обещаниях подрядчика.
Вопрос «а что агент может сделать?» имеет ровно один правильный ответ — список функций на одном листе. Если список не показывают, значит его нет.
