Azure SRE Agent подключили к MCP: как один бэкенд работает и для людей, и для ИИ-агентов — VogueTech

Что нового

Microsoft развивает Azure SRE Agent сразу в трёх направлениях, но первым до продакшена доехало не то, что ожидаешь от классического SRE-инструмента.

Появляется новый интерфейс:

MCP‑сервер для Azure SRE Agent — сервер по протоколу Model Context Protocol, который:
- подключается к клиентам вроде GitHub Copilot CLI, VS Code Copilot, Claude Desktop, Cursor;
- доступен удалённым агентам в других экосистемах (например, DevOps‑агенту в AWS или SRE‑агенту в PagerDuty);
- отдаёт один и тот же формализованный ответ и людям внутри ассистентов, и другим агентам.

Параллельно Microsoft делает ещё два интерфейса (они пока не релизнаны, но важно понимать общую картину):

Interactive CLI — интерактивная консоль для людей:
- командная строка, заточенная под инциденты;
- минимум шума, быстрые ответы, прогрессивное раскрытие деталей.
Agent Mode — режим для код‑агентов:
- SRE Agent запускается как подпроцесс (subprocess);
- без протокольного слоя MCP между агентом и SRE‑функциями.

Сейчас в продакшене именно MCP‑сервер. CLI и Agent Mode — в работе и выйдут позже отдельными релизами.

Как это работает

Три интерфейса — один бэкенд

Azure SRE Agent внутри — единый набор возможностей для работы с инфраструктурой и инцидентами в Azure. Снаружи — три разных входа с разными сценариями вызова:

Interactive CLI
- пользователь сидит в терминале;
- вызывает SRE Agent вручную командой;
- интерфейс короткий, без лишнего текста, заточен под «2 часа ночи, всё горит».
Agent Mode
- код‑агент (например, Copilot CLI) запускает SRE Agent как подпроцесс;
- общается через стандартные потоки ввода/вывода;
- нет отдельного протокола, всё происходит локально в рамках одного окружения.
MCP‑сервер
- SRE Agent поднимает сервер по протоколу MCP;
- любой MCP‑совместимый клиент видит его как набор инструментов (tools);
- модель сама решает, когда вызывать какой инструмент.

Почему первым вышел MCP‑сервер

CLI и Agent Mode требуют осознанного вызова:

человек должен знать про Azure SRE Agent, открыть терминал и ввести команду;
код‑агент должен явно решить: «запускаю подпроцесс с этим бинарём».

MCP работает иначе:

SRE‑инструменты появляются прямо в том окружении, где уже работает человек или агент;
SRE в GitHub Copilot CLI или VS Code Copilot не открывает новый терминал — он просто спрашивает: «что не так с моим API‑шлюзом?»;
ассистент видит инструменты MCP‑сервера и сам решает, когда их дернуть.

Для удалённых агентов история похожая:

DevOps‑агент в AWS или SRE‑агент в PagerDuty не запускают подпроцессы;
они говорят по протоколу MCP и получают JSON‑ответы.

По сути, MCP‑сервер подстраивается под уже существующий контекст — IDE, ассистент, пайплайн. Поэтому его и отгрузили первым.

Два типа клиентов — один протокол

У MCP‑интерфейса Azure SRE Agent два основных типа «звонящих»:

Люди внутри код‑ассистентов
Примеры окружений:
- VS Code Copilot;
- GitHub Copilot CLI;
- Claude Desktop;
- Cursor.
Контекст: человек уже в сессии — пишет деплой‑скрипт, правит ранбук, разбирается с падением сервиса. Ему не хочется переключаться в другую консоль. Он хочет, чтобы SRE‑возможности были под рукой, в том же диалоге.
Удалённые агенты в других экосистемах
Примеры сценариев:
- DevOps‑агент в AWS разбирает кросс‑облачный инцидент и проверяет здоровье ресурсов в Azure;
- SRE‑агент в PagerDuty собирает сводку инцидента в своём триаж‑цикле;
- один экземпляр Azure SRE Agent делегирует подзадачу другому.

Обе группы используют один и тот же протокол MCP. Им не нужно знать внутреннее устройство друг друга — достаточно общего контракта.

Дизайн MCP‑инструментов: описания важнее схем

Каждый инструмент MCP внутри Azure SRE Agent — это отдельная возможность SRE‑бэкенда. У инструмента есть:

имя;
описание на естественном языке;
JSON‑схема входных параметров.

Ключевой момент — описание. Модель читает именно его, чтобы понять, когда инструмент стоит вызвать.

Пример разницы:

«Возвращает статус здоровья Azure‑ресурса» — сухо и абстрактно.
«Проверяет, здоров ли Azure‑ресурс (VM, шлюз, база данных, контейнер), в деградированном состоянии или недоступен. Используйте при диагностике активного сбоя или для проверки состояния после деплоя» — даёт явный сигнал, когда инструмент уместен.

Microsoft прогоняет описания через связку PM + разработка + контент‑дизайн. Когда вызов инструмента в тестах шёл не туда, почти всегда помогала правка описания, а не схемы.

По сути, описания MCP‑инструментов работают как системные промпты: от их формулировки зависит, поймёт ли модель, что именно сейчас нужно сделать.

Один формат ответа для людей и агентов

Главная дилемма: человек и автоматический агент хотят разного от ответа одного и того же инструмента.

Человек ждёт читаемое резюме без JSON‑шумов.
Агент ждёт строгий, легко парсимый объект без лишнего текста.

Интуитивное решение — сделать разные форматы ответов. Microsoft пошла другим путём: одна форма ответа для всех.

Каждый инструмент MCP в Azure SRE Agent возвращает:

фиксированный набор полей с определённой семантикой;
стабильный контракт без преамбул и «внутренних размышлений»;
одно поле summary (название условное) с коротким описанием на естественном языке.

Как это используется:

человек видит summary и, при необходимости, заглядывает в структуру ниже;
агент игнорирует summary и парсит только структурированные поля.

Это даёт минимум накладных расходов и не плодит разветвления по типу клиента.

Microsoft рассматривала вариант с флагом «тип вызывающего» в заголовке запроса и разными ответами, но отказалась: это добавляло поверхность для ошибок и усложняло поддержку.

Статус‑less инструменты и проблема контекста

MCP‑инструменты в Azure SRE Agent стейтлесс: каждый вызов независим. Для автоматических агентов это удобно — им не нужно тянуть за собой сессию.

Для человека, работающего через ассистента, наоборот, хочется, чтобы контекст тянулся цепочкой запросов.

Microsoft решает это так:

каждый ответ инструмента содержит достаточно контекста, чтобы ассистент мог собрать следующий вызов без повторного объяснения всей истории;
сам инструмент ничего не помнит, но даёт достаточно данных, чтобы память держал тот, кто ведёт диалог (Copilot, Claude 4 и т.п.).

Тестирование: люди и агенты — разные задачи

Проверить сценарий с человеком просто:

подключаем MCP‑сервер к Copilot CLI;
задаём вопрос;
смотрим, какие инструменты вызываются и что возвращается.

С агентами сложнее:

DevOps‑агент в AWS или SRE‑агент в PagerDuty может впервые увидеть инструменты Azure SRE Agent;
у него нет «общего словаря» или заранее заданного воркфлоу.

Поэтому описания и схемы MCP‑инструментов Microsoft проектирует так, чтобы модель могла с нуля понять, что это за функции и как их связать в свою логику, не опираясь на скрытые договорённости.

Что это значит для вас

Если вы SRE или разработчик, работающий с Azure

Основной плюс MCP‑сервера Azure SRE Agent — вы можете не менять привычный рабочий инструмент.

Где это полезно:

Вы сидите в VS Code Copilot или Cursor, пишете деплой, и что‑то падает.
- Вместо того чтобы переключаться в отдельный CLI, вы спрашиваете ассистента.
- Ассистент сам вызывает нужный MCP‑инструмент SRE Agent и приносит сводку.
Вы пользуетесь GitHub Copilot CLI.
- Подключаете MCP‑сервер один раз.
- Дальше SRE‑команды появляются как «способ действия» внутри привычного cli‑диалога.

Кому это особенно зайдёт:

дежурным SRE, которые хотят меньше ручных переключений во время инцидента;
разработчикам, которые сами сопровождают сервисы и не хотят лезть в отдельные консоли для базовой диагностики.

Где есть ограничения:

MCP‑сервер сам по себе не заменяет глубокий ручной анализ — он даёт быстрый доступ к данным и операциям, но не снимает ответственность за решения;
для тяжёлых сценариев расследования инцидентов всё равно пригодится полноценный CLI, который Microsoft ещё не выкатил.

Если вы строите своих ИИ‑агентов

Azure SRE Agent через MCP — удобный вариант, если вы:

пишете DevOps‑агента, который должен сам ходить в Azure и проверять состояние ресурсов;
автоматизируете триаж в PagerDuty‑подобной системе;
строите комплексную систему, где один агент делегирует задачи другому.

Что вы получаете:

единый протокол MCP без кастомных интеграций с обеих сторон;
стабильные JSON‑ответы, которые удобно парсить и класть в свои пайплайны;
человекочитаемый summary, который можно логировать или отдавать оператору.

Что важно учитывать:

инструменты стейтлесс, так что логику сессий и цепочек вызовов нужно держать на своей стороне;
если вы хотите особые форматы или дополнительные поля, придётся работать в рамках контракта MCP‑инструментов или ждать расширений от Microsoft.

Доступность и юридические нюансы

Azure SRE Agent — часть экосистемы Azure и MCP. Для работы вам понадобится:

доступ к Azure;
MCP‑совместимый клиент (VS Code Copilot, GitHub Copilot CLI, Claude Desktop, Cursor или свой агент).

Если доступ к Azure или отдельным сервисам в вашем регионе ограничен и вы используете VPN, SRE‑сценарии будут зависеть от того, насколько стабильно вы выходите в облако Microsoft.

Место на рынке

Прямых публичных цифр по скорости, цене или сравнению с другими SRE‑инструментами Microsoft не приводит. Но по архитектуре можно понять, куда Azure SRE Agent с MCP‑сервером ложится в текущий ландшафт.

По типу интеграции

Azure SRE Agent (MCP)
- фокус: SRE‑операции в Azure через единый протокол MCP;
- сценарии: люди в код‑ассистентах + ИИ‑агенты в других облаках и инструментах;
- формат: один JSON‑контракт для всех, плюс текстовое резюме.
Классические SRE‑CLI и SDK (например, Azure CLI, AWS CLI, SDK для Python/Go):
- фокус: ручное управление и скрипты;
- сценарии: человек в терминале, CI/CD;
- формат: разные команды, разные форматы вывода, нет единого «агентского» протокола.
Встроенные ассистенты в облаках (например, Copilot в GitHub / Azure, аналоги у других провайдеров):
- фокус: помощь в IDE и порталах;
- сценарии: разработка, настройка инфраструктуры;
- формат: часто нет открытого протокола для внешних агентов.

Azure SRE Agent через MCP даёт именно протокольный уровень доступа к SRE‑функциям Azure, который удобно использовать и людям через ассистентов, и внешним агентам. Это не замена Azure CLI или портала, а ещё один слой поверх них.

По целевой аудитории

Для SRE‑команд в Azure MCP‑сервер — способ встроить диагностику и операции в существующие ассистенты и IDE.
Для команд, работающих с несколькими облаками, это способ дать своим DevOps‑агентам доступ к Azure без ручной интеграции с каждым API.

Пока нет открытых метрик скорости, стоимости вызовов или сравнения с альтернативами в AWS и GCP, поэтому сравнивать по производительности и экономике рано. Но по дизайну интерфейсов видно: Microsoft делает ставку на то, что SRE‑функции Azure будут вызываться не только людьми, но и всё большим количеством ИИ‑агентов — и MCP‑сервер как раз под это заточен.

Что дальше

В планах у Microsoft — довести до релиза ещё два интерфейса:

Interactive CLI — для людей в терминале, с короткими ответами и логикой, заточенной под инциденты;
Agent Mode — для код‑агентов, которые хотят вызывать SRE‑функции напрямую через подпроцесс, без протокола MCP.

Оба будут использовать тот же трёхузловой подход: один бэкенд Azure SRE Agent, разные интерфейсы и разные типы вызывающих.

Пока они в разработке, основной рабочий путь — подключить Azure SRE Agent как MCP‑сервер к вашему клиенту и дать SRE‑возможностям появиться прямо там, где вы уже работаете — в IDE, ассистенте или своём DevOps‑агенте.