Aspire als KI-Orchestrator: MCP, Agents und Foundry

Aspire war bisher ein Infrastruktur-Tool: Services starten, Verbindungen verdrahten, deployen. In Aspire 13 kommt eine neue Dimension dazu – KI-Integration als Konzept, das in den AppHost, die CLI und das Dashboard eingebettet ist.

MCP: Aspire als Werkzeug für KI-Agenten

Das Model Context Protocol (MCP) definiert, wie KI-Agenten auf externe Tools und Datenquellen zugreifen. Aspire 13.1 integriert MCP auf zwei Ebenen.

Erstens als Entwicklungswerkzeug: aspire agent init richtet einen MCP-Server ein, über den KI-Assistenten direkt mit dem laufenden Aspire-Environment interagieren können – Services starten, Logs lesen, Konfigurationen abfragen, ohne den Entwickler als Mittelsmann. Ein KI-Agent kann damit eigenständig den Zustand der laufenden Anwendung verstehen und darauf reagieren.

aspire agent init   # MCP-Server für das aktuelle Projekt einrichten

Zweitens als Hosting-Konzept: Services, die selbst MCP-Server bereitstellen, lassen sich im AppHost registrieren und wie andere Ressourcen referenzieren. Aspire übernimmt die Service Discovery und stellt sicher, dass MCP-Clients die Server-Endpunkte automatisch erhalten.

Achtung: Die MCP-Authentifizierung ist nicht dokumentiert. Der MCP-Server verwendet einen x-mcp-api-key-Header für die Absicherung, aber weder die Generierung noch der Wert des Keys sind in der offiziellen Dokumentation beschrieben. Die launchSettings.json enthält eine MCP-Endpoint-URL, die in der Praxis nicht direkt funktioniert (microsoft/aspire#16396). Wer den MCP-Server in einen eigenen KI-Client integrieren will, muss den Key aus dem Dashboard oder aus den Aspire-Logs extrahieren.

Weitere Einschränkung: MCP-Integration ist lokal. Die über aspire agent init konfigurierten MCP-Tools und Agenten-Registrierungen existieren nur im lokalen Entwicklungsbetrieb. aspire deploy überträgt diese Konfiguration nicht in die Zielumgebung. Für eine produktive Agenten-Architektur müssen die MCP-Server-Endpunkte manuell in die Produktionsinfrastruktur übernommen werden (microsoft/aspire#16063).

Azure AI Foundry und Microsoft Foundry

Azure AI Foundry-Integration ermöglicht lokale Modellentwicklung ohne aktive Azure-Subscription. Aspire startet das Modell lokal und stellt es über dieselbe Endpoint-Abstraktion bereit wie einen remote-gehosteten Dienst:

var model = builder.AddAzureAIFoundry("foundry")
    .AddDeployment("gpt4o", "gpt-4o", "2024-11-20");

builder.AddProject<Projects.ChatApi>("chat")
    .WithReference(model);

Der chat-Service bekommt den Endpoint als Umgebungsvariable injiziert und muss nicht unterscheiden, ob er gegen eine lokale oder eine Azure-gehostete Instanz spricht. Für das Deployment auf Azure Container Apps oder AKS wechselt Aspire automatisch auf den Azure-Endpunkt.

Ab 13.2 löste Microsoft Foundry das Azure AI Foundry Branding ab, die API-Oberfläche blieb kompatibel.

Aspire als Orchestrator für Agent-Workflows

KI-Agenten-Architekturen bestehen oft aus mehreren Komponenten: einem Orchestrator, Spezialistenagenten, einem Vektorspeicher, einem Embedding-Service und einer Datenbank. Genau das ist die Domäne, in der Aspire seinen Wert zeigt.

Ein typischer Agent-Stack im AppHost:

var vectorDb = builder.AddQdrant("vectordb");
var embeddings = builder.AddAzureAIFoundry("embeddings")
    .AddDeployment("embed", "text-embedding-3-small", "1");

var orchestrator = builder.AddProject<Projects.Orchestrator>("orchestrator")
    .WithReference(vectorDb)
    .WithReference(embeddings);

var specialist = builder.AddPythonApp("specialist", "../SpecialistAgent")
    .WithReference(orchestrator);

Aspire übernimmt die gesamte lokale Verdrahtung: Service Discovery, Verbindungsstrings, Zertifikate. Im Aspire Dashboard sind alle Komponenten des Agent-Stacks sichtbar – Logs, Traces und die Verbindungen zwischen ihnen – wie bei jeder anderen verteilten Anwendung.

AI Agents im Dashboard

Ab 13.4 hat das Aspire Dashboard einen eigenen AI Agents Dialog in der Kopfleiste. Dieser zeigt alle registrierten KI-Agenten im laufenden Environment an, ihren Status und – bei MCP-fähigen Agenten – die verfügbaren Tools.

Die Kombination aus Aspire-Dashboard und MCP-Integration erlaubt es, KI-Agenten-Workflows auf dieselbe Weise zu beobachten wie klassische Service-Interaktionen: als Traces, die zeigen, welcher Agent welche Tools mit welchen Parametern aufgerufen hat.

Lokale Entwicklung ohne Cloud-Kosten

Ein praktischer Aspekt, der oft unterschätzt wird: Aspire ermöglicht die vollständige lokale Ausführung von KI-Workflows, bevor eine einzige Azure-Ressource provisioniert wird. Modelle laufen lokal via Foundry-Integration, Vektorspeicher wie Qdrant starten als Container, und der gesamte Agent-Stack ist über das Dashboard beobachtbar.

Beispiel: Ollama und Open WebUI orchestrieren

Ein eindrucksvolles Beispiel für das lokale Setup ist die Einbindung von Open-Source-Modellen mit Ollama, gekoppelt mit einem Interface wie Open WebUI. Aspire orchestriert hierbei das Herunterladen der Container, mountet die notwendigen Laufwerke für Modelle und Start-Skripte und injiziert automatisch die URLs für die API-Kommunikation.

So sieht die Einrichtung im AppHost aus:

// Ollama Resource als Container hinzufügen und Port freigeben
var ollamaResource = builder.AddContainer("ollama", "ollama/ollama:latest")
    .WithEnvironment("OLLAMA_MODELS", "/root/.ollama/models")
    .WithEnvironment("OLLAMA_NOPRUNE", "true")
    .WithBindMount("ollama", "/root/.ollama")
    .WithBindMount("./ollamaconfig", "/usr/config")
    .WithBindMount("./ollama-startup.sh", "/usr/local/bin/startup.sh")
    .WithHttpEndpoint(11434, 11434, "ollama")
    .WithEntrypoint("/bin/bash")
    .WithArgs("-c", "chmod +x /usr/local/bin/startup.sh && /usr/local/bin/startup.sh") // Modelle automatisch beim Start laden
    .WithLifetime(ContainerLifetime.Persistent);

var ollamaEndpoint = ollamaResource.GetEndpoint("ollama");

// Open WebUI als Frontend, kommuniziert direkt mit Ollama
var openWebUiResource = builder.AddContainer("openwebui", "ghcr.io/open-webui/open-webui:main")
    .WithEnvironment("OLLAMA_BASE_URL", ollamaEndpoint)
    .WithVolume("open-webui", "/app/backend/data")
    .WithHttpEndpoint(8080, 8080)
    .WaitFor(ollamaResource);

Mit dem entsprechenden ollama-startup.sh Script wird sichergestellt, dass beim Containerstart die Modelle nicht nur heruntergeladen, sondern auch gestartet werden, und der Container aktiv bleibt. Hier zum Beispiel mit qwen3:1.7b:

#!/bin/bash
set -e

echo "=== Ollama Container Startup ==="

export OLLAMA_HOST=0.0.0.0:11434

# Check if ollama binary is available and working
echo "Checking ollama binary..."
which ollama || { echo "ERROR: ollama binary not found"; exit 1; }

# Ensure the data directory exists and has proper permissions
echo "Setting up ollama data directory..."
mkdir -p /root/.ollama
chmod 755 /root/.ollama

echo "Starting Ollama server..."
# Start ollama serve in the background
ollama serve &
OLLAMA_PID=$!

# Wait for ollama to be ready
echo "Waiting for Ollama server to be ready..."
sleep 10

# Check if model already exists
if ! ollama list | grep -q "qwen3:1.7b"; then
    echo "Pulling qwen3:1.7b model..."
    ollama pull qwen3:1.7b
    echo "Model pull completed successfully!"
else
    echo "Model qwen3:1.7b already exists, skipping pull"
fi

echo "=== Ollama setup completed successfully! ==="

# Keep the container running by waiting for the ollama process
wait $OLLAMA_PID

Mit wenigen Zeilen Code starten wir das KI-Modell und ein Chat-Frontend. Das Start-Skript für Ollama wird direkt per Mount in den Container injiziert und lädt die Modelle automatisch beim Start. Die Dependencies (WaitFor) stellen sicher, dass Open WebUI erst bootet, wenn das Modell bereit ist. Die Umgebungsvariable OLLAMA_BASE_URL wird direkt über ollamaEndpoint asynchron zum Start aufgelöst, ohne dass wir uns als Entwickler um Port-Kollisionen oder IP-Adressen sorgen müssen.

Erst beim aspire deploy wechseln die lokalen Ressourcen auf ihre Cloud-Äquivalente – mit denselben Verbindungsabstraktionen, die auch lokal verwendet wurden.