LLM не проникают в ваш код — они передают вам запрос, а вы запускаете функцию. Этот простой факт опровергает миф о том, что «модель магическим образом вызывает мою Python-функцию», и заставляет разработчиков переосмыслить подходы к отладке и безопасности.

Цикл диспетчеризации, шаг за шагом

Когда языковой модели (LLM) требуется инструмент, она следует детерминированной последовательности:

  1. Планирование — модель решает, что требуется действие (например, «вернуть платеж»).
  2. Генерация запроса — она выдает структурированный текст (обычно JSON), в котором указано название инструмента и переданы аргументы.
  3. Парсинг — ваше приложение или вспомогательный фреймворк считывает этот текст.
  4. Сопоставление — фреймворк ищет название в реестре функций, которые вы предоставили.
  5. Валидация — проверяется соответствие аргументов схеме функции и наличие прав у вызывающей стороны.
  6. Выполнение — найденная функция запускается в вашей среде и выполняет работу.
  7. Возврат — результат упаковывается и отправляется обратно модели для дальнейших рассуждений.

Представьте, что LLM — это планировщик, фреймворк — диспетчер, а функция — это исполнитель, который фактически перемещает данные или деньги.

Почему миф о «магии» сохраняется

Большинство разработчиков видят одну строку вывода модели, которая выглядит как вызов функции, и предполагают, что модель сама выполнила операцию. Термин «tool calling» (вызов инструментов) в документации провайдеров звучит так, будто модель напрямую вызывает код.

На самом деле модель только генерирует текст, который описывает вызов. Всю основную работу — поиск, проверку типов, контроль прав доступа и обработку ошибок — выполняет ваш процесс.

Фреймворки, скрывающие детали реализации

Библиотеки, такие как PydanticAI и LangChain, абстрагируют этот цикл, позволяя вам сосредоточиться на бизнес-логике. Они автоматически:

  • Валидируют аргументы на соответствие схеме (например, модели Pydantic).
  • Контролируют права доступа, гарантируя, что пользователь имеет право вызывать инструмент.
  • Выполняют повторные попытки при сбое, возвращаясь к модели, если инструмент возвращает ошибку.
  • Защищают от бесконечных циклов, ограничивая количество последовательных вызовов инструментов.
  • Поддерживают состояние диалога, встраивая результаты работы инструментов в контекст беседы.

Даже с этими помощниками принцип остается прежним: модель никогда не исполняет код.

Нативная поддержка вызова инструментов от провайдеров

Некоторые провайдеры предоставляют «нативный» интерфейс вызова инструментов, который стандартизирует определения инструментов и форматы запросов. Это упрощает интеграцию, но не отменяет этап диспетчеризации. Вам все равно нужно писать (или импортировать) код, который фактически выполняет запрошенную операцию.

Отладка становится проще, если правильно называть проблему

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

  • Нет вызова инструмента — модель ответила напрямую или не смогла сгенерировать запрос в правильном формате.
  • Некорректный запрос — JSON синтаксически неверен или в нем отсутствуют обязательные поля, поэтому диспетчер отклоняет его.
  • Ошибка валидации — аргументы не соответствуют схеме, что вызывает ошибку еще до выполнения.

Классификация сбоев позволяет логировать каждый этап цикла и точно определять, где именно что-то пошло не так.

Практические советы для создания надежного конвейера

  • Относитесь к выводу модели как к недоверенным входным данным. Пропускайте каждый запрос через детерминированную валидацию перед вызовом любого кода, вызывающего побочные эффекты.
  • Логируйте исходный запрос и результат каждого этапа валидации. Это создаст возможность воспроизведения цепочки событий, если что-то пойдет не так.
  • Устанавливайте явные лимиты на количество последовательных вызовов инструментов; бесконечный цикл может исчерпать ресурсы или привести к превышению лимитов запросов (rate limits).
  • Оборачивайте каждую функцию в блок try/except, который возвращает структурированный объект ошибки, понятный модели, что позволит инициировать повторную попытку или корректный откат.
  • Отделяйте проверку прав от бизнес-логики. Проверяйте полномочия вызывающей стороны перед запуском функции, особенно для привилегированных действий, таких как «удалить пользователя».
  • Используйте определения на основе схем (например, модели Pydantic), чтобы фреймворк мог автоматически генерировать JSON-схему, которой должна следовать модель.

На что обратить внимание в будущем

По мере совершенствования нативных API для вызова инструментов от провайдеров, ожидайте более строгих контрактов в форматах запросов и более информативных кодов ошибок. Эти изменения упростят валидацию и позволят разработчикам выстраивать более строгие барьеры безопасности. Следите за обновлениями библиотек — многие из них уже добавляют встроенную поддержку новейших функций провайдеров.

Итог

LLM — это сложный генератор текста, а не исполнитель. Ваш код остается единственным источником полномочий, выполняющим действия, а созданный (или импортированный) вами диспетчер выступает в роли контролера, который проверяет, авторизует и запускает эти действия. Переосмысление рабочего процесса устраняет миф о «магии», упрощает отладку и внедряет дисциплину безопасности, необходимую любой продакшн-системе.