Мультиагентные демо сейчас повсюду.
Проблема в том, что многие из них останавливаются прямо перед той частью, которая по-настоящему болит в реальной жизни: форма развёртывания, подключение сервисов, здоровье, телеметрия, границы времени выполнения и обычный хаос распределённых систем.
Именно поэтому стоит обратить внимание на новый пример Aspire + Microsoft Agent Framework.
Нет, интересна здесь не сама сценка с консьержем горнолыжного курорта.
Интересно то, что пример показывает намного более реалистичный паттерн построения распределённой агентной системы с:
- кастомными размещёнными (hosted) агентами
- prompt-агентами
- несколькими рантаймами
- ссылками на сервисы
- живыми источниками данных
- структурой наблюдаемости и развёртывания
Вот в чём реальная история.
Это больше, чем «агент, использующий инструменты»
Архитектура в этом примере выходит за пределы привычной модели агента с одним циклом.
У вас есть:
- специализированные агенты с узкими зонами ответственности
- агенты-советники, которые их оркестрируют
- ресурсы, управляемые Foundry
- сервисы на .NET, Python и Go в одном графе
- точки входа для голоса и чата
Это намного ближе к тому, как серьёзные агентные системы будут выглядеть на практике.
И именно здесь Aspire внезапно становится очень важным.
Aspire делает трудную часть работы, которую люди обычно держат в голове
Больше всего мне здесь нравится даже не логика агентов. А то, что граф приложения явен.
Aspire используется для описания:
- каких сервисов существует
- от чего они зависят
- какие развёртывания моделей им нужны
- какой рантайм использует каждый сервис
- какие отношения здоровья и развёртывания существуют
Это важно, потому что распределённые агентные системы быстро становятся запутанными. Если топология существует только в головах людей и разрозненных документах по настройке, ваша система немедленно становится хрупкой.
Помещение этой топологии в AppHost — огромный шаг к чему-то воспроизводимому.
Специализированные агенты как инструменты — по-прежнему паттерн, за которым стоит следить
Одна из моих любимых частей архитектуры — то, как специализированные агенты представлены как вызываемые возможности для оркестратора.
Этот паттерн появляется снова и снова не просто так. Он даёт вам:
- разделение ответственностей
- более чёткие границы домена
- более ясную наблюдаемость
- более лёгкую замену одного специалиста без переписывания всего остального
Для .NET-команд это намного более здоровая ментальная модель, чем строить одного гигантского всезнающего агента и надеяться, что инструкции промпта удержат его стабильным.
Моё мнение
Важная вещь, которую доказывает этот пример, — не то, что мультиагентные приложения возможны. Мы это уже знали.
Он доказывает, что стек Microsoft начинает предлагать связный ответ на следующий вопрос:
как строить мультиагентные системы, которые всё ещё ощущаются управляемыми?
Aspire — для графа. Agent Framework — для абстракций времени выполнения. Foundry — для управляемых ИИ-ресурсов и хостинга. Это сочетание начинает ощущаться менее экспериментальным и больше похожим на настоящую платформенную историю.
Вот за чем я бы здесь следил.
Оригинальный пост: Distributed multi-agent systems with Aspire and Microsoft Agent Framework
