· · 3 минут чтения

Создаём мультиагентные UI в реальном времени, которые не выглядят как чёрный ящик

AG-UI и Microsoft Agent Framework объединяются, чтобы дать мультиагентным рабочим процессам полноценный фронтенд — с потоковой передачей в реальном времени, человеческими одобрениями и полной видимостью действий агентов.

agent-framework ai ag-ui multi-agent azure sse
Эта статья также доступна на:English, Español, Deutsch, Français, Português, Italiano, 日本語, 中文, 한국어

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Вот в чём дело с мультиагентными системами: в демо они выглядят невероятно. Три агента передают друг другу работу, решают задачи, принимают решения. А потом ты пытаешься показать это реальным пользователям и… тишина. Крутящийся индикатор. Непонятно, какой агент чем занимается и почему система встала на паузу. Это не продукт — это проблема доверия.

Команда Microsoft Agent Framework только что опубликовала отличный walkthrough о том, как связать рабочие процессы MAF с AG-UI — открытым протоколом для потоковой передачи событий выполнения агентов на фронтенд через Server-Sent Events. И честно? Это именно тот мост, которого нам не хватало.

Почему это важно для .NET-разработчиков

Если вы строите приложения с ИИ, наверняка уже упирались в эту стену. Ваша серверная оркестрация работает отлично — агенты передают задачи друг другу, инструменты запускаются, решения принимаются. Но фронтенд понятия не имеет, что происходит за кулисами. AG-UI решает это, определяя стандартный протокол для потоковой передачи событий агентов (RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) напрямую в ваш UI-слой через SSE.

Демо — это рабочий процесс клиентской поддержки с тремя агентами: агент триажа маршрутизирует запросы, агент возвратов обрабатывает денежные вопросы, и агент заказов управляет заменами. У каждого агента свои инструменты, а топология передач определена явно — никакого «разберись из промпта».

Топология передач — настоящая звезда

Что зацепило мой взгляд — как HandoffBuilder позволяет объявить направленный граф маршрутизации между агентами:

builder = HandoffBuilder(
    name="ag_ui_handoff_workflow_demo",
    participants=[triage, refund, order],
    termination_condition=termination_condition,
)

(
    builder
    .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
    .add_handoff(triage, [order], description="Replacement, exchange...")
    .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
    .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Каждый add_handoff создаёт направленное ребро с описанием на естественном языке. Фреймворк генерирует инструменты передачи для каждого агента на основе этой топологии. Решения о маршрутизации основываются на вашей структуре оркестрации, а не на том, что LLM решит сделать. Это огромное преимущество для надёжности в продакшене.

Human-in-the-loop, который действительно работает

Демо показывает два паттерна прерываний, без которых не обойтись ни одному реальному агентному приложению:

Прерывания для одобрения инструментов — когда агент вызывает инструмент с approval_mode="always_require", рабочий процесс ставится на паузу и отправляет событие. Фронтенд рендерит модальное окно одобрения с названием инструмента и аргументами. Никаких циклов повторных попыток, сжигающих токены — просто чистый поток пауза-одобрение-возобновление.

Прерывания запроса информации — когда агенту нужно больше контекста от пользователя (например, ID заказа), он ставит на паузу и спрашивает. Фронтенд показывает вопрос, пользователь отвечает, и выполнение возобновляется с того же места, где остановилось.

Оба паттерна передаются как стандартные события AG-UI, поэтому вашему фронтенду не нужна специальная логика для каждого агента — он просто отображает любое событие, приходящее через SSE-соединение.

Подключение удивительно простое

Интеграция между MAF и AG-UI — это один вызов функции:

from agent_framework.ag_ui import (
    AgentFrameworkWorkflow,
    add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
    workflow_factory=lambda _thread_id: create_handoff_workflow(),
    name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
    app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory создаёт свежий рабочий процесс для каждого потока, так что каждый диалог получает изолированное состояние. Эндпоинт автоматически обрабатывает всю SSE-обвязку. Если вы уже используете FastAPI (или можете добавить его как лёгкий слой), это практически без трения.

Моё мнение

Для нас, .NET-разработчиков, немедленный вопрос: «Можно ли сделать это на C#?» Agent Framework доступен и для .NET, и для Python, а протокол AG-UI не зависит от языка (это просто SSE). Так что хотя конкретная демка использует Python и FastAPI, паттерн переносится напрямую. Вы можете настроить минимальный API ASP.NET Core с SSE-эндпоинтами, следуя той же схеме событий AG-UI.

Более важный вывод — мультиагентные UI становятся полноценной задачей первого класса, а не чем-то придуманным постфактум. Если вы строите что-либо, где агенты взаимодействуют с людьми — клиентская поддержка, рабочие процессы утверждения, обработка документов — эта комбинация оркестрации MAF и прозрачности AG-UI является паттерном, которому стоит следовать.

Подведём итоги

AG-UI + Microsoft Agent Framework даёт вам лучшее из обоих миров: надёжную мультиагентную оркестрацию на бэкенде и видимость в реальном времени на фронтенде. Больше никаких взаимодействий агентов как чёрный ящик.

Посмотрите полный walkthrough и репозиторий протокола AG-UI, чтобы погрузиться глубже.

Поделиться:
Просмотреть исходный код этой статьи на GitHub ↗
← Та Самая Настройка Плавающих Окон в Visual Studio, О Которой Вы Не Знали (Но Должны)
Подключите ваши MCP-серверы на Azure Functions к агентам Foundry — Вот как →