AI-агенты и Tool Calling: как модели выполняют задачи

Вечер, я на кухне одной рукой мешаю макароны, другой — пишу в чат: «Купи, пожалуйста, два билета на завтра, на 19:30, места рядом. Бюджет — до 8 000 за оба». Он бодро кивает словами, как будто это обычная переписка, и через минуту уже: «Готово! Билеты оформлены, места рядом, осталось только подтвердить оплату». Ну магия же. Я даже на секунду ловлю себя на мысли, что вот оно, будущее: никаких вкладок, никаких очередей, просто попросил — и сделано.

А потом прилетает пуш от банка, и у меня внутри всё холодеет: сумма больше, чем я говорил. Открываю — билеты на сегодня, на 21:30. И не два рядом, а два “в одном вагоне, но на разных концах”. Мелочь? Да вроде бы нет: вечер срывается, деньги зависли, поддержку нужно ловить, а я стою с этими макаронами и тупо злюсь. И вот тут становится ясно: это уже не “умный текст”, который можно вежливо проигнорировать или посмеяться над ошибкой. Это действие, которое оставляет след — в кошельке, в календаре, в нервах.

Когда чат просто болтает, ошибка — это максимум неловкий совет или не та формулировка. А когда он начинает “делать”, ставки другие: одно неверное время, одна лишняя галочка — и ты расплачиваешься не красивыми словами, а реальными минутами, рублями и данными. И самое неприятное — всё выглядит правдоподобно до последней секунды: он говорит уверенно, как человек, который точно всё проверил. Хотя, ну… не проверил.

«Модель умеет вызывать инструменты» — это значит, что она не только болтает и советует, а реально делает действия во внешних сервисах. Как секретарь с блокнотом: ты сказал “перенеси встречу”, и он не сочиняет красивый ответ, а открывает календарь и нажимает нужные кнопки. Только вместо “рук” у модели — доступ к заранее разрешённым операциям: создать событие, найти адрес на карте, оформить заказ, обновить карточку клиента в CRM.

Представь пульт с ограниченным набором кнопок. Модель может нажимать только те кнопки, которые ей разрешили (и в нужном формате), а всё остальное — нет. Это и есть “инструменты”: функции/API внешних сервисов вроде create_calendar_event, search_map, add_to_cart, update_crm_contact. Не магия, а аккуратный “доступ к действиям”.

Мини‑пример: “Запланируй созвон с Ирой на завтра в 15:00 и пришли ссылку”. Тут инструментами будут, например, календарь (создать событие) и видеосервис (сгенерировать ссылку). Ответ модели — это уже не только текст, а пара нажатий на эти кнопки плюс короткое подтверждение пользователю.

Агент обычно начинает с простого: читает просьбу и прикидывает, что именно от него хотят — поговорить “в теории”, уточнить пару деталей или уже что-то сделать. Дальше в голове складывается черновой план: какие шаги нужны, где взять данные, какой сервис дернуть. Если запрос мутный (например, “закажи доставку на вечер”), нормальный ход — остановиться и переспросить: на какой адрес, во сколько, какие предпочтения. Но если кажется, что и так “понятно”, он может решить действовать сразу — и вот тут начинается зона, где легко срезать угол.

Когда он выбирает действие, это похоже на человека, который по телефону заполняет форму: услышал “в пятницу в восемь”, быстро внес в поля, отправил заявку и ждет подтверждение. Проблема в том, что можно неправильно расслышать дату (“восьмого” vs “в восемь”), перепутать адрес или взять “типичные” значения по умолчанию. Агент делает примерно то же самое: формирует аккуратную заявку для нужного сервиса, отправляет, получает ответ и продолжает по цепочке.

Дальше идет проверка: ответ сервиса может быть “нет мест”, “нужна предоплата”, “адрес не найден”. И агент либо возвращается на шаг назад и уточняет у пользователя, либо пробует альтернативу. А “срезать угол” он может в двух местах: во-первых, когда подставляет недостающие детали от себя (чтобы не мучить вопросами), во-вторых, когда видит частичный успех и торопится отчитаться, не сверив ключевые вещи — время, сумму, получателя. В итоге выглядит бодро, а по факту заказ уехал не туда или встреча стоит не на тот день.

Риск №1 — это когда агент уверенно сделал не то. Не “сломалось” и не “не получилось”, а наоборот: всё прошло гладко, просто результат оказался мимо. Просили записать к врачу — он выбрал первую попавшуюся клинику с похожим названием и бодро оформил запись. Хотели заказать “в этом магазине, где уже есть моя скидка”, а он ушёл в другой, потому что там “быстрее доставка”. И ты видишь красивое подтверждение, номер заказа, всё чинно — а потом выясняется, что это не тот сервис и не те условия.

Вторая категория — ошибки деталей, когда инструмент выбран правильный, но параметры поехали. Самое банальное: дата и время. “Вылет в 00:30” — это ещё сегодня или уже завтра? “Доставить в пятницу” — в ближайшую или через неделю, если сейчас уже пятница вечер? Или адрес: “Ленина 10” в городе и “Ленина 10” в посёлке рядом, и агент без вопросов отправляет туда, где совпало больше символов. А ещё размеры и валюты: заказал M вместо L, оплатил 120 USD вместо 120 EUR, потому что в карточке товара валюта была мелким шрифтом.

Третий вариант — не уточнил важное и пошёл дальше, и это почти всегда выглядит как “ну он же старался”. Например: “Запиши к стоматологу на этой неделе” — а там принципиально важно, терапевт это или хирург, платно или по страховке, какой филиал, есть ли парковка. Агент видит много похожих вариантов, выбирает один, потому что так проще закрыть задачу, и продолжает цепочку действий. В tool calling это особенно опасно: один неверный шаг — и дальше уже летит подтверждение, списание, запись, доставка.

Почему это происходит? Потому что агенту поощряется скорость и полезность: лучше “сделать хоть что-то”, чем задавать десять уточняющих вопросов. А реальный мир, честно говоря, издевательски похож сам на себя: два города с одинаковым названием, три клиники с почти одинаковыми доменами, пять магазинов с “официальными” витринами. И если не встроить привычку тормозить на неоднозначностях — агент будет ошибаться не громко, а уверенно.

Риск №2: «слишком много доверия» — безопасность, деньги и чужие данные

Как только агенту дают “инструменты” с доступом к личному — почте, календарю, платежам, рабочим базам, CRM — он перестаёт быть просто болтливым помощником и становится оператором. И тут простая логика: чем больше кнопок ему доступно, тем выше цена ошибки. Одно дело — неудачно сформулировать письмо. Другое — отправить его не тому адресату, отменить встречу с клиентом или оплатить “не тот” счёт. Плюс такой агент автоматически становится интереснее для злоумышленников: раньше им нужно было взломать человека, теперь достаточно “подсунуть” агенту хитрый запрос или добраться до токена доступа.

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

Типичные сценарии, которые выглядят “мелочью”, а потом долго вспоминаются:

• Менеджер просит: “скинь последнюю переписку по проекту”, агент ищет в почте, цепляет не тот тред и пересылает партнёру внутреннее обсуждение цен и скидок — и всё, переговоры начинают пахнуть странно.
• Кто-то пишет в чат: “оплати счёт, я уже согласовал”, агент видит похожий инвойс в почте и проводит платёж — а там подмена реквизитов на один символ, и деньги улетают “в никуда”, заметили через два дня.
• В пятницу вечером агент “наводит порядок” в календаре, сдвигает встречи, отправляет автоуведомления — и случайно отменяет созвон с ключевым клиентом, потому что решил, что это дубль. Клиент, конечно, не читает ваши объяснения про “ошибку инструмента”.

Агент с tool calling — это как ребёнок, которому вы дали доступ к шкафу с бытовой химией: полезно, пока стоит детский замок, и опасно, если дверца открыта настежь. Поэтому “ограждения” — это не параноя, а нормальная инженерия. Хотим, чтобы агент помогал, но не “нажимал лишнего” в реальном мире.

Первое правило: подтверждение перед дорогими и необратимыми действиями. Оплата, удаление, отправка письма на внешние адреса, смена прав — только через “Вы уверены?” плюс короткое резюме: кому, что, сколько, когда. Хорошая привычка: агент сначала показывает черновик (платёж/письмо/заказ), а не делает “сразу оплатить”. И да, по умолчанию лучше медленнее, но безопаснее.

Второе: лимиты и разрешения, как ограничитель скорости. Минимальные права (least privilege), отдельные ключи/токены под задачи, белые списки инструментов и доменов. Поставьте потолки: “не больше 2 платежей в день”, “не дороже 10 000 ₽ без человека”, “не больше 20 писем за час”, “не удалять данные вообще”. Пусть агент умеет много, но может мало — звучит странно, зато работает.

Третье: двойная проверка того, что чаще всего ломается — адреса, даты, суммы, получатели, валюты. Нужен второй взгляд: либо повторная валидация другим правилом/моделью, либо простая формула “сверь с источником” (например, адрес — из CRM, дата — из календаря). Если есть сомнение или конфликт данных, агент обязан остановиться и спросить, а не угадывать.

Четвёртое: журнал действий “что он нажал”. Логируйте каждый вызов инструмента: входные параметры, ответ, время, пользователя, и главное — “почему он это сделал” в двух строках. Это помогает разбирать инциденты за 10 минут, а не за 2 дня. И добавьте аварийную кнопку: быстро выключить конкретный инструмент или весь режим действий, если агент “поехал”.

Если убрать весь вау‑эффект, агенты лучше всего окупаются там, где много повторяемых шагов и мало сюрпризов. Рутина “собери данные → разложи по полям → обнови запись → отправь уведомление” — вот их стихия. Ещё хорошо работает связка “поиск → сводка → запись”: агент пробегает по источникам, вытаскивает факты, складывает в заметку/таблицу/тикет, оставляя ссылки. Время здесь экономится не магией, а тем, что он делает 20 кликов за минуту и не устает.

Отдельная сильная зона — подготовка черновиков. Письма, ответы в поддержку, план задачи, шаблон отчёта, набросок ТЗ: агент может быстро собрать структуру, подставить детали из контекста, предложить варианты. Но финальная правка всё равно на человеке — не потому что “ИИ тупит”, а потому что тон, приоритеты и ответственность обычно не формализуются в промпте на 100%.

А вот где лучше притормозить — всё, что связано с деньгами, доступом к чувствительным данным и юридически значимыми действиями. Переводы, возвраты, изменение реквизитов, удаление данных, подписание/отправка документов “как есть” — это зоны, где одна неверная интерпретация или лишний вызов инструмента превращаются в инцидент. Здесь нужны ограничения по правам, подтверждения, логирование, и желательно принцип “сначала черновик/предпросмотр, потом кнопка человеком”.

В общем, агент — это стажёр с быстрыми руками. Он реально ускоряет работу, если дать ему чёткие правила, узкий набор инструментов и нормальный присмотр. Без этого он тоже “помогает”, просто иногда — не туда.