🔧 Инструменты и MCP

LLM сама по себе умеет только генерировать текст. Чтобы она могла что-то сделать — найти запись в CRM, посчитать пени, отправить письмо, прочитать файл, — ей нужны инструменты. Эта статья — о том, как модель вызывает внешние системы, и о стандарте, который объединяет эти вызовы, — MCP.

Зачем это руководителю

Именно инструменты превращают LLM в систему, которая действует, а не болтает. В вакансиях AI Solution Architect прямо перечислены: Function Calling, Structured Outputs, MCP, интеграция с API. Это базовый словарь.


Function Calling — модель вызывает функцию

Function Calling (вызов функций) — это способность модели вернуть не свободный текст, а структурированный вызов инструмента с именем и аргументами. Вы описываете модели доступные функции (имя, что делает, какие параметры), и при необходимости она выбирает нужную и отдаёт готовый к исполнению вызов.

sequenceDiagram
    participant U as 👤 Пользователь
    participant A as 🧠 LLM
    participant T as ⚙ Инструмент (API)
    U->>A: «Создай задачу в CRM для Иванова на завтра»
    A->>A: Решает: нужен create_task
    A->>T: function_call: create_task({assignee:"Иванов", due:"завтра"})
    T-->>A: {status:"ok", id:12345}
    A-->>U: «Готово, задача #12345 создана»

Модель не «выполняет» функцию сама

Важно понимать разделение: модель лишь возвращает описание вызова. Само выполнение (обращение к CRM, базе, расчёт) делает ваш код. Модель — это «решатель, какой инструмент и с какими аргументами»; исполнитель — отдельный. Эта граница критична и для безопасности (15-compliance-i-bezopasnost).

Structured Outputs — ответ по схеме

Structured Output (структурированный вывод) — режим, в котором модель гарантированно отвечает в заданной JSON-схеме, а не свободным текстом. Современные модели поддерживают это на уровне самого вызова — схема соблюдается строго.

Зачем обязательно

Если результат работы LLM уходит в другую систему (запись в БД, поле в CRM, триггер процесса), свободный текст — это хрупкость. Любой «договор№5» вместо ожидаемого формата ломает интеграцию. Structured Outputs делают соединение надёжным и предсказуемым.

Без structured outputС structured output
«Договор от 12 мая, сумма около 1 млн…»{"date":"2026-05-12","amount":1000000,"currency":"RUR"}
Парсить регэкспами — больно и ломаетсяГарантированная схема — простая интеграция
Высокий риск галлюцинации форматаФормат устойчив

MCP — Model Context Protocol

MCP (Model Context Protocol) — открытый стандарт, описывающий, как единообразно подключать модели к внешним инструментам и данным: файлам, базам, API, корпоративным системам. До MCP каждая интеграция писалась заново и под каждую модель; MCP даёт общий «разъём».

flowchart LR
    subgraph Host["🧠 Хост-приложение<br/>(агент / Copilot)"]
        Client["MCP-клиент"]
    end
    Client <-->|"стандартный<br/>протокол"| S1["🔧 MCP-сервер<br/>CRM"]
    Client <-->|"стандартный<br/>протокол"| S2["📄 MCP-сервер<br/>файлы/БД"]
    Client <-->|"стандартный<br/>протокол"| S3["🌐 MCP-сервер<br/>внешние API"]

Аналогия

MCP — это как USB-C для AI. Вместо того чтобы под каждый инструмент делать свой «штекер», вы подключаете любой MCP-совместимый сервер — и модель через стандартный протокол видит его инструменты и данные. Один раз написанный MCP-сервер к CRM работает с разными моделями и хостами.

Что даёт MCP

  • Переиспользование: один MCP-сервер обслуживает разные модели и приложения.
  • Стандартизация: инструменты, ресурсы и подсказки описаны единообразно.
  • Развязка: команда, ведущая интеграцию с CRM, не зависит от команды модели.
  • Экосистема: появляются готовые MCP-серверы к популярным системам (Google Drive, Slack, базы данных и т. д.).

Вакансии подтверждают

В описании «AI Platform Architect» прямо фигурируют: Function Calling, Structured Outputs, интеграция LLM с внутренними сервисами. MCP — это современный способ делать такую интеграцию не «костыльно», а по стандарту.

Принципы проектирования инструментов

Хороший инструмент — какой он

  • Атомарный — делает одну понятную вещь (не «ведёт CRM», а «создаёт задачу»).
  • Понятно описанный — модель выбирает инструмент по описанию; плохое описание = неправильный выбор.
  • Строгий по аргументам — типы, обязательные поля, валидация.
  • Возвращает предсказуемый результат — структура, а не «как попало».
  • Идемпотентный там, где важно — повторный вызов не создаёт дубль.
  • Минимальные права — ровно те действия, что нужны (15-compliance-i-bezopasnost).

Чем больше инструментов — тем хуже

Давать агенту десятки инструментов «про запас» — частая ошибка. Модель путается, выбирает не тот инструмент, а каждый лишний — это и риск (через него можно провести промпт-инъекцию, 07-prompt-engineering), и шум в контексте. Минимум необходимых инструментов — правило №1.

Безопасность инструментов

Инструменты — это точки контакта с реальным миром, поэтому они же — главная зона риска:

  • Принцип наименьших привилегий: у инструмента только те права, что нужны.
  • Валидация аргументов: модель может передать ерунду — проверяйте.
  • Опасные действия — через подтверждение (human-in-the-loop): платёж, удаление, отправка вовне.
  • Аудит: логируйте все вызовы инструментов с аргументами и результатами (14-ocenka-kachestva).
  • Защита от инъекций: данные, возвращённые инструментом (например, текст из внешнего документа), считайте недоверенными — они могут содержать инструкции для модели (07-prompt-engineering, 15-compliance-i-bezopasnost).
flowchart TD
    Call["🔧 Вызов инструмента"] --> Val{"Валидация<br/>аргументов"}
    Val -- fail --> Reject["❌ Отклонить"]
    Val -- ok --> Perm{"Достаточно прав?"}
    Perm -- нет --> Reject
    Perm -- да --> Risk{"Опасное<br/>действие?"}
    Risk -- да --> Confirm["✋ Human approval"]
    Risk -- нет --> Exec["▶ Выполнить"]
    Confirm -- одобрено --> Exec
    Confirm -- отказ --> Reject
    Exec --> Audit["📋 Аудит-лог"]

📌 Что запомнить

  • Function Calling — модель возвращает структурированный вызов; исполняет ваш код, не сама модель.
  • Structured Outputs — гарантированная JSON-схема для интеграций; не парсите свободный текст.
  • MCP — открытый стандарт «разъёма» между моделями и инструментами/данными; переиспользование + стандартизация.
  • Хороший инструмент: атомарный, понятно описанный, строгий, минимальные права.
  • Меньше инструментов — надёжнее; лишние = риск и шум.
  • Инструменты — главная зона безопасности: валидация, принцип наименьших привилегий, human-in-the-loop, аудит, защита от инъекций.

Дальше: 🐝 Мультиагентные системы → — когда одного агента мало и как организовать команду агентов без хаоса.