Что внутри этого модуля
1. Зачем LLM инструменты: проблема «текстового пузыря»
LLM — мощная технология, но у неё есть фундаментальное ограничение: модель живёт внутри «текстового пузыря». Она может рассуждать и генерировать текст, но не может выполнить ни одного действия в реальном мире: проверить почту, отправить сообщение, записать файл, сделать запрос к API, найти актуальную информацию в интернете.
Инструменты (tools) — это механизм, который ломает этот пузырь. LLM получает возможность «попросить» программу-хост выполнить действие, получить результат и продолжить рассуждение уже с реальными данными.
Tool (инструмент)
Функция или сервис, доступный LLM через программный интерфейс. Модель не вызывает инструмент напрямую — она генерирует специальный структурированный запрос, который перехватывается хост-приложением, выполняет действие и возвращает результат обратно в контекст модели.
Без инструментов vs с инструментами
| Задача | Без инструментов | С инструментами |
|---|---|---|
| Какая погода в Москве? | Придумает правдоподобный, но возможно неверный ответ (галлюцинация) | Вызовет weather API, получит реальные данные, ответит точно |
| Отправь письмо клиенту | Сгенерирует текст письма, но не отправит | Сгенерирует письмо и вызовет send_email(), который реально отправит |
| Сколько у нас заказов за сегодня? | Не знает (это приватные данные) | Сделает SQL-запрос к базе данных и вернёт точную цифру |
| Найди последние новости о Tesla | Расскажет то, что знало на момент обучения | Вызовет поисковый API и прочитает свежие новости |
Ключевая идея: Инструменты превращают LLM из «говорящей головы» в «исполнителя». Модель становится не просто генератором текста, а оркестратором действий.
2. Function Calling: LLM вызывает ваш код
Function Calling (вызов функций) — это встроенная возможность большинства современных LLM API (OpenAI, Anthropic, Google). Вы описываете функции в специальном формате (JSON Schema), а модель, когда понимает, что ей нужна функция для ответа, возвращает структурированный запрос вместо обычного текста.
Function Calling (вызов функций)
Механизм LLM API, при котором модель получает описание доступных функций (название, параметры, описание) и может вернуть структурированный запрос на вызов конкретной функции с конкретными параметрами. Хост-приложение выполняет функцию и возвращает результат модели.
Как это работает: пошагово
- Вы описываете функции. Например:
get_weather(city: string, date?: string)— «Получить погоду в городе на дату». - Отправляете описание вместе с запросом. Модель получает и вопрос пользователя, и список доступных инструментов.
- Модель решает, нужна ли функция. Если для ответа нужны внешние данные — модель возвращает не текст, а запрос на вызов:
{ "function": "get_weather", "arguments": { "city": "Москва" } }. - Ваш код выполняет функцию. Вы получаете реальные данные от API погоды.
- Результат возвращается модели. Модель получает данные и генерирует финальный человеческий ответ.
Пример описания функции для OpenAI API
Вот как выглядит описание функции в коде:
{
"name": "get_weather",
"description": "Получить текущую погоду в указанном городе",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "Название города, например 'Москва'"
},
"units": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "Единицы измерения температуры"
}
},
"required": ["city"]
}
}
Важно: Модель НЕ выполняет функцию сама. Она только говорит «вызови такую-то функцию с такими-то параметрами». Выполнение — всегда на стороне вашего приложения. Это ключевой момент безопасности.
3. MCP (Model Context Protocol): единый стандарт интеграции
MCP — это открытый протокол, предложенный компанией Anthropic в конце 2024 года. Его задача — решить проблему «зоопарка интеграций». Без MCP каждый разработчик пишет свой велосипед для подключения LLM к каждому сервису. MCP предлагает универсальный стандарт.
MCP (Model Context Protocol)
Открытый протокол для стандартизированного подключения LLM к внешним источникам данных и инструментам. Работает по принципу клиент-сервер: MCP-сервер предоставляет ресурсы, инструменты и промпты, а MCP-клиент (приложение с LLM) подключается к ним. Аналог USB-C, но для AI-интеграций.
Архитектура MCP
MCP построен на трёх примитивах:
| Примитив | Назначение | Пример |
|---|---|---|
| Resources (Ресурсы) | Данные, к которым LLM нужен доступ | Файлы, записи БД, содержимое веб-страниц, логи приложения |
| Tools (Инструменты) | Действия, которые LLM может инициировать | Отправить email, создать задачу в Jira, выполнить SQL-запрос, вызвать API |
| Prompts (Промпты) | Готовые шаблоны для стандартных сценариев | «Проведи code review», «Составь отчёт за неделю» |
Почему MCP важен
- Единый стандарт. Вместо того чтобы писать интеграцию под каждого провайдера LLM и каждый сервис отдельно, вы пишете один MCP-сервер и подключаете его к любому MCP-совместимому клиенту.
- Переиспользование. Сообщество создаёт открытые MCP-серверы для популярных сервисов (GitHub, Slack, Google Drive, PostgreSQL, Filesystem). Вы просто подключаете готовый сервер, не написав ни строчки кода.
- Безопасность. Чёткое разделение: MCP-сервер работает в своей песочнице, LLM не имеет прямого доступа к системе. Все вызовы проходят через контролируемый протокол.
- Динамическое обнаружение. Клиент может спросить у сервера: «Какие инструменты и ресурсы ты предоставляешь?» — и автоматически сделать их доступными для LLM.
Примеры существующих MCP-серверов
| Сервер | Что даёт |
|---|---|
| @anthropic/mcp-server-filesystem | Чтение/запись файлов, навигация по директориям |
| @anthropic/mcp-server-github | Управление репозиториями, issues, PR, поиск кода |
| @anthropic/mcp-server-postgres | SQL-запросы к базе данных |
| @anthropic/mcp-server-slack | Отправка/чтение сообщений, управление каналами |
| @anthropic/mcp-server-puppeteer | Браузерная автоматизация: навигация, скриншоты, клики |
| @anthropic/mcp-server-google-drive | Доступ к документам Google Drive |
4. MCP vs Function Calling: что выбрать
Это два разных уровня решения одной задачи — дать LLM доступ к внешнему миру. Они не конкурируют, а дополняют друг друга.
| Критерий | Function Calling | MCP |
|---|---|---|
| Уровень | Возможность API конкретной LLM | Протокол/стандарт интеграции |
| Где работает | OpenAI, Anthropic, Google и другие — у каждого свой формат | Любой MCP-клиент, независимо от модели |
| Что нужно писать | Описание функции в JSON Schema + код для её выполнения | MCP-сервер (или использовать готовый) |
| Сложность | Низкая для 1-3 функций; высокая при масштабировании | Средняя для одного сервера; низкая для подключения готовых |
| Когда использовать | Прототипы, простые проекты, кастомная логика | Продакшен, много инструментов, работа с разными сервисами |
Правило большого пальца: Если вам нужно 1-3 простых функции в рамках одного проекта — используйте Function Calling. Если вы строите систему с десятком разных интеграций, работаете с несколькими LLM-провайдерами или хотите переиспользовать инструменты между проектами — смотрите в сторону MCP.
5. Архитектура: как всё соединяется
Давайте соберём полную картину: как LLM, инструменты, MCP и RAG (из модуля 2) работают вместе в реальном приложении.
Типичная архитектура AI-приложения
- Пользователь пишет запрос в интерфейсе (чат, веб, мобильное приложение).
- Оркестратор (ваш код) получает запрос и решает, что с ним делать. Это может быть фреймворк вроде LangChain, LlamaIndex или самописный код.
- RAG-слой (если нужен) ищет релевантные документы через векторную базу и добавляет их в контекст.
- MCP-клиент общается с MCP-серверами, предоставляя модели список доступных инструментов, ресурсов и промптов.
- LLM получает: запрос пользователя + найденные документы (RAG) + описание инструментов (MCP/Function Calling).
- Модель либо сразу отвечает, либо запрашивает вызов инструмента.
- Оркестратор выполняет инструмент (через MCP или напрямую) и возвращает результат модели.
- Цикл повторяется, пока модель не сгенерирует финальный ответ.
Внимание: Каждый вызов LLM стоит денег и занимает время. Если ваше приложение делает 5-10 вызовов на один запрос пользователя, задержка может стать заметной. Проектируйте с учётом этого.
6. Best practices интеграции инструментов
Правила дизайна инструментов
- Одна функция — одна задача. Не делайте функцию
do_everything(). Модели лучше работают с узкими, специализированными инструментами. - Понятные названия и описания. Модель «читает» описание функции так же, как промпт. Пишите описания понятным языком, с примерами входных данных.
- Валидация на входе. Никогда не доверяйте параметрам, которые модель передала в функцию. Модель может ошибиться в формате числа или строки — всегда проверяйте.
- Тайм-ауты. Внешние API могут тормозить или падать. Всегда ставьте разумный тайм-аут (10-30 секунд в зависимости от типа операции) и возвращайте понятную ошибку.
- Ограничение прав. Инструмент должен иметь минимум необходимых прав. Функция поиска не должна иметь доступ на удаление записей в базе данных.
Чего избегать
- Слишком много инструментов. Если у модели 50 доступных функций, она может запутаться. Группируйте инструменты и предоставляйте только те, что нужны в текущем контексте.
- Бесконечные циклы вызовов. Модель может зациклиться: вызвать функцию, не удовлетвориться результатом, вызвать другую, вернуться к первой. Всегда ставьте лимит на количество вызовов (обычно 3-10 за один запрос пользователя, в зависимости от сложности задачи).
- Передача секретов в параметрах. API-ключи, токены и пароли не должны передаваться через параметры функций. Храните их в переменных окружения на стороне сервера.
Практический совет: Начните с одной функции. Убедитесь, что цикл «запрос → вызов → результат → ответ» работает стабильно. Потом добавляйте следующую. Интеграция инструментов — это процесс, а не разовое действие.
7. Итоги модуля 3
- Инструменты ломают «текстовый пузырь» LLM и позволяют взаимодействовать с реальным миром
- Function Calling — встроенная возможность LLM API для вызова ваших функций
- MCP — открытый стандарт интеграции, позволяющий переиспользовать инструменты между проектами и моделями
- MCP и Function Calling не заменяют, а дополняют друг друга
- Дизайн инструментов требует дисциплины: одна задача, понятные описания, валидация, тайм-ауты, минимум прав
Что дальше? В последнем модуле мы соберём всё вместе и разберём агентов, мультиагентные системы, архитектурные паттерны loop и chunky — как строить системы, которые не просто отвечают, а автономно решают сложные задачи.