Агентный ИИ в облаке: от function calling до MCP и GPU-инференса

Классический чат-бот отвечает на вопрос текстом и на этом останавливается. ИИ-агент получает задачу, сам выбирает следующий шаг, вызывает внешний инструмент, читает результат и решает, что делать дальше. Разбираем, как устроен агентный ИИ, чем Model Context Protocol отличается от function calling, какая инфраструктура нужна для запуска агентов в облаке и где у такой системы слабые места. Материал для разработчиков, DevOps-инженеров и архитекторов, которые планируют подключать LLM к внутренним системам.

Что такое агентный ИИ и почему облако — естественная среда для него

Агентным ИИ называют LLM-систему, которая сама планирует шаги для достижения цели, вызывает внешние инструменты и корректирует план по их результатам.

Работа агента строится циклом. Модель получает задачу и контекст, решает, какой инструмент вызвать и с какими параметрами, получает результат и снова решает: задача выполнена или нужен следующий шаг. Цикл повторяется, пока агент не придёт к ответу или не упрётся в лимит шагов.

Из этого следует главное инфраструктурное отличие. Обычный LLM-сервис обрабатывает один запрос и возвращает один ответ. Агент на одну задачу порождает цепочку из пяти, десяти или нескольких десятков обращений к модели и инструментам, и каждое добавляет задержку и стоимость.

Где применяются ИИ-агенты

Разбор инцидентов. Агент получает алерт из мониторинга, запрашивает логи и метрики сервиса, сопоставляет их с последними релизами и предлагает дежурному инженеру гипотезу и план действий. Техподдержка. Агент ищет ответ в базе знаний и документации, проверяет статус заявки клиента в тикет-системе и готовит ответ оператору. Аналитика. Агент переводит вопрос бизнеса в SQL-запрос к хранилищу, выполняет его, проверяет результат на аномалии и строит сводку. Разработка. Агент читает репозиторий, запускает тесты в CI, анализирует упавшие проверки и предлагает исправление в виде merge request. Работа с документами. Агент извлекает данные из входящих договоров и счетов, сверяет их с учётной системой и помечает расхождения для сотрудника.

Агент, чат-бот и RAG-ассистент: в чём разница

Почему облако подходит для агентных систем

Агенту нужна инфраструктура, которая уже стала стандартом в cloud native: контейнеры, оркестрация, сервисы с API. По данным отчёта CNCF и SlashData State of Cloud Native Development Q1 2026, 71% backend-разработчиков используют хотя бы одну cloud native технологию или практику, а 52% применяют три и более.

Для агентных систем это значит, что внутренние сервисы компании чаще всего уже доступны по API и развёрнуты в Kubernetes. Подключить к ним LLM можно без перестройки инфраструктуры: достаточно обернуть нужные API в инструменты, которые агент умеет вызывать.

От function calling к единому протоколу

Идею чередовать рассуждение и действие формализовала работа ReAct (Yao et al., 2022): модель пишет шаг рассуждения, вызывает инструмент, анализирует результат и переходит к следующему шагу. Этот цикл лежит в основе большинства современных агентных архитектур.

В июне 2023 года OpenAI добавила в API function calling: модель возвращает структурированный вызов функции с параметрами вместо текста. Похожие механизмы появились у других провайдеров, но форматы описания инструментов различались. Интеграцию, написанную под одну модель, приходилось переписывать под другую.

Получалась задача N×M: каждый инструмент требовал отдельного адаптера под каждую модель и каждое приложение. Это и создало спрос на единый протокол.

Как устроен Model Context Protocol

В ноябре 2024 года Anthropic представила Model Context Protocol (MCP), открытый протокол для подключения LLM-приложений к внешним данным и инструментам. В декабре 2025 года Anthropic передала MCP в Agentic AI Foundation под управлением Linux Foundation. Протокол развивается как нейтральный стандарт, актуальная ревизия спецификации 2026-07-28.

MCP строится по схеме «хост, клиент, сервер»:

• Хост: приложение со встроенной LLM, например IDE, чат-интерфейс или собственный агент.
• Клиент: компонент внутри хоста, который держит соединение с одним MCP-сервером.
• Сервер: отдельный процесс, который даёт доступ к конкретной системе: базе данных, хранилищу, Kubernetes API, тикет-системе.

Сервер предоставляет три типа возможностей: инструменты (tools), которые модель вызывает для действий; ресурсы (resources), то есть данные для контекста; промпты (prompts), готовые шаблоны запросов. Сообщения передаются в формате JSON-RPC 2.0. Стандартных транспортов два: stdio, когда клиент запускает сервер как локальный процесс, и Streamable HTTP для удалённых серверов. Streamable HTTP в 2025 году заменил прежний транспорт HTTP+SSE.

Так выглядит описание инструмента, которое MCP-сервер возвращает клиенту: json

{

  "name": "get_pod_logs",

  "description": "Возвращает последние строки логов пода в указанном namespace",

  "inputSchema": {

    "type": "object",

    "properties": {

      "namespace": { "type": "string" },

      "pod": { "type": "string" },

      "tail": { "type": "integer", "default": 100 }

    },

    "required": ["namespace", "pod"]

  }

}

Модель видит название, описание и схему параметров. По ним она решает, когда вызвать инструмент и что передать. Детали реализации (как сервер ходит в Kubernetes API, с какими правами) от модели скрыты.

Function calling и MCP: сравнение

Эти подходы не конкурируют. Хост-приложение обычно использует function calling модели, чтобы та выбрала инструмент, а MCP отвечает за то, откуда инструменты берутся и как исполняются.

GPU для агентных пайплайнов

GPU нужен, если модель работает в вашем контуре. Это типичный выбор, когда данные нельзя передавать внешнему API: персональные данные, коммерческая тайна, требования 152-ФЗ. Если агент обращается к модели внешнего провайдера, GPU для инференса не нужен, но запросы и контекст уходят за пределы компании.

Для агентного сценария важна предсказуемая задержка. Задача из десяти шагов вызывает модель десять раз, и лишние 500 мс на каждом вызове превращаются в пять секунд ожидания для пользователя.

В Kubernetes GPU подключаются через Device Plugin Framework: узел объявляет видеокарты как расширенный ресурс nvidia.com/gpu, а под запрашивает его в спецификации: yaml

apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
spec:
  containers:
    - name: vllm
      image: vllm/vllm-openai:latest
      resources:
        limits:
          nvidia.com/gpu: 1
          ```
          

Риски: агентность расширяет поверхность атаки

Подключение LLM к инструментам добавляет к обычным рискам веб-приложений новые классы атак. В OWASP Top 10 for LLM Applications 2025 для агентов критичны три:

• Промпт-инъекция (LLM01). Вредоносная инструкция приходит не от пользователя, а из данных, которые агент читает: письма, веб-страницы, тикета. Модель может выполнить её как команду.
• Избыточная агентность (LLM06). У агента больше прав, чем требует задача. Агент, которому нужно читать логи, получает сервисный аккаунт с правом удалять поды.
• Отравленные инструменты. Описание инструмента на MCP-сервере попадает в контекст модели. Сторонний сервер со скрытыми инструкциями в описании может повлиять на поведение агента.

Что снижает риски:

• Отдельный MCP-сервер и отдельный сервисный аккаунт на каждую систему, права по принципу минимальных привилегий.
• Разделение инструментов на чтение и запись; для необратимых действий (удаление, откат, платёж) подтверждение человеком.
• Только проверенные MCP-серверы из внутреннего реестра, фиксированные версии.
• Для удалённых серверов на Streamable HTTP: аутентификация и проверка заголовка Origin, как требует спецификация MCP.
• Журнал каждого вызова инструмента: кто, что, с какими параметрами, какой результат.

Практическая архитектура в облаке

Разделение слоёв позволяет масштабировать их независимо. Рост числа параллельных агентов требует больше GPU для инференса, но не новых MCP-серверов. Подключение новой системы добавляет MCP-сервер, но не меняет инференс.

Наблюдаемость в агентной системе сложнее, чем в обычном сервисе. Трассировать нужно всю цепочку: какой инструмент вызван, с какими параметрами, что вернул и как результат повлиял на следующий шаг. Для этого подходит OpenTelemetry: в нём развиваются семантические соглашения для GenAI-систем, которые описывают вызовы моделей и инструментов.

Ограничения агентного подхода

• Стоимость. Каждый шаг цепочки тратит токены и время GPU. Задача, которую агент решает за 20 шагов, стоит в десятки раз дороже одного запроса.
• Недетерминированность. На одной и той же задаче агент может выбрать разные пути. Это усложняет тестирование и воспроизведение ошибок.
• Отладка. Без трассировки всей цепочки понять, почему агент принял решение, почти невозможно.
• Не всё требует агента. Если шаги задачи известны заранее, надёжнее и дешевле жёсткий сценарий (workflow), где LLM выполняет отдельные шаги, а порядок задаёт код.