Kapitel 13 — Frameworks und Cloud-Integration
Dreizehnter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Darin: niemand baut produktives MCP aus rohem Protokoll, die ehrliche Frage von 2025–2026 wird, auf welches Framework man sich festlegt, und die Antwort hängt weniger von Features ab als davon, in welcher Cloud der Rest des Systems lebt.
Warum dieses Kapitel existiert
Bis ein Team Authentifizierung, Transport, Sessionzustand, Error-Retry, strukturiertes Logging und das Dutzend kleinerer Details verdrahtet hat, die eine Demo von einem operierbaren Dienst trennen, ist aus „wir sprechen einfach MCP über HTTP" ein kleines Framework geworden — meist ein schlechteres als die bestehenden öffentlichen. Die Engineering-Frage ist, auf welches öffentliche Framework man sich festlegt, was jedes gut macht und wie sie mit den Cloud-Diensten verbinden, die den Zustand halten. Dieses Kapitel geht die Landschaft methodisch durch: Strands mit Amazon Bedrock; die AWS-Dienste, die es für Zustand und Retrieval umgeben; Microsofts Agent Framework, LangChain und Semantic Kernel als die anderen produktiven Optionen; und die Integrationsmuster, auf die die Referenzarchitekturen konvergiert sind. Ziel ist nicht, einen Sieger zu krönen, sondern zu beschreiben, wofür jedes Framework tatsächlich da ist.
13.1 Strands Agents und Amazon Bedrock
Strands ist das Open-Source-Agenten-Framework, das AWS 2025 veröffentlichte und das nun in Amazon Q, AWS Support und dem AWS-Glue-Assistenten läuft. Der Rahmen ist bewusst: Strands ist modellgetrieben, was heißt, dass die Schleife, die entscheidet, was als Nächstes zu tun ist, die eigene Tool-Calling-Schleife des Modells ist, kein Planner-Graph, den das Framework darüberlegt. Aufgabe des Frameworks ist es, diese Schleife produktionstauglich zu machen — Tool-Aufrufe abzuwickeln, Sessionzustand zu verwalten, MCP-Server als erstklassige Toolquellen über MCPClient einzubinden und alles über Bedrocks gehosteten Modellkatalog zu routen. Die Modellebene ist steckbar — Anthropics API, OpenAI, Ollama, LiteLLM — aber Bedrock ist der Default und die Audit-Story.
Die Multi-Agent-Geschichte ist, wo Strands seinen produktiven Ruf verdient. Drei Kompositionsmuster mappen sauber auf die Orchestrierungsformen früherer Kapitel: Agents-as-Tools (die einfachste Form, ein Agent als Tool gewrappt, das ein anderer Agent rufen kann); Swarm (peer-to-peer mit geteiltem Arbeitsspeicher); und Graph (deterministische Topologie, in der das Modell jeden Knoten füllt). Die Muster verschachteln in Produktion. Die operative Steuer wird in Observability gezahlt, und Strands zahlt sie, indem es OpenTelemetry-Spans für jede Agenten-Anrufung, jeden Tool-Aufruf, jeden Modellaufruf emittiert — sodass eine vierstufige Komposition aus den Logs rekonstruiert, ohne dass jede Ebene eigene Instrumentierung braucht. Bedrock fügt die Access-Grenze-Story hinzu: IAM kontrolliert, welche Modelle ein gegebener Agent aufrufen darf; CloudTrail loggt die Nutzung. Bedrock Guardrails übernehmen Inhaltsfilterung am Gateway, Knowledge Bases geben gemanagtes Retrieval, und AgentCore — AWS' 2025er Primitivmenge — formalisiert Memory-, Identity- und Runtime-Themen für Teams, die eine vollständig gemanagte Laufzeit statt einer selbstgehosteten wollen.
13.2 AWS als State-Schicht
Ein Agent, der Stunden läuft und sich an gestern erinnert, braucht Speicher, der den Prozess überlebt. Das in Produktion eingesetzte Muster: Laufzeitzustand (aktuelle Session, Aufgaben-Ledger, in-flight Tool-Calls) in DynamoDB für schnellen Schlüsselzugriff; Artefaktzustand (erzeugte Dokumente, Zwischenarbeit) in S3 mit einer session-prefixed Schlüsselstruktur, die zugleich natürliche IAM-Grenzen und kostenlose Versionierung gibt; semantischer Zustand (Langzeit-Gedächtnis, frühere Konversationen) in einem Vektorspeicher — OpenSearch Service für heißes Arbeitsgedächtnis, das neuere S3 Vectors für kaltes oder archivisches Gedächtnis. Die Zweiebenen-Trennung zwischen S3 und DynamoDB ist keine verfrühte Optimierung. Sie hält das DynamoDB-Item unter 400 KB, vermeidet Lese-Amplifikation bei jedem Schritt und lässt jede Schicht unabhängig skalieren.
Die Wahl der State-Schicht bestimmt den Fehlermodus des gesamten Systems. Ein Agent, dessen Zustand nur im Prozessgedächtnis lebt, verliert alles beim Neustart. Ein Agent, dessen Gedächtnis dauerhaft ist, aber dessen Index nicht synchron, ruft Referenzen auf Dokumente ab, die er nicht mehr finden kann. Produktive Deployments behandeln das als getrennte Konsistenzverträge: DynamoDB-Transaktionen für Zustandsatomarität, S3 Strong-Read-after-Write für den Artefaktvertrag, eine Indexierungspipeline, die Dokumente nach S3 publiziert, bevor sie deren Vektoren upserten, damit Retrieval nicht auf etwas zeigt, das es noch nicht gibt. Die Sicherheitsgrenze verdient dieselbe Sorgfalt. AWS' eigene Strands-Anleitung empfiehlt per-Session-Credentials via STS statt der Wiederverwendung der Laufzeit-Rolle für End-User-Daten-Tool-Calls — AgentCore Identity automatisiert das — damit die AWS-Identität hinter einer destruktiven Aktion die tatsächliche Endnutzerin ist und nicht eine geteilte Agentenrolle. In regulierten Umgebungen ist das die einzige akzeptable Antwort.
13.3 Microsoft Agent Framework, LangChain und Semantic Kernel
Die Microsoft- und Open-Source-Seite der Landschaft hat sich anders gesetzt. Das Microsoft Agent Framework kam Ende 2025 als explizite Fusion von Semantic Kernel und AutoGen — SKs Plugin-Modell und .NET-Integration mit AutoGens Multi-Agent-Mustern und Python-first-DX. MCP-Integration ist eingebaut über MCPStdioTool und MCPStreamableHTTPTool; Azure AI Foundry ist die gehostete Heimat, das Äquivalent zu Bedrock in der AWS-Welt. Das unterscheidende Merkmal gegenüber Strands ist, dass der Konversationsgraph zwischen Agenten ein explizites, replaybares Objekt ist — was enorm für die Evaluation zählt, weil eine fehlgeschlagene Konversation mit modifiziertem Prompt erneut gefahren und Turn für Turn verglichen werden kann. Der Preis ist mehr Struktur, als Strands aufzwingt; der richtige Tausch in reifen Deployments, der falsche in explorativer Arbeit.
LangChain in 2026 ist ein anderes Tier als LangChain in 2023. Die ursprüngliche Chains-Abstraktion ist sekundär geworden; die primäre Oberfläche ist LangGraph für Orchestrierung und LangSmith für Observability und Evaluation. Die Stärken sind Breite — jedes Modell, jede Datenbank, jedes Tool hat einen Adapter — und LangSmiths Evaluations-Reife. Die Schwäche, die Praktiker ehrlich benennen, ist Oberfläche: die High-Level-Abstraktionen des Frameworks sind exzellent für die ersten neunzig Prozent der Arbeit, und die letzten zehn Prozent werden meist erledigt, indem man Schichten abzieht, bis das Team versteht, was jede tut. Teams, die diesen Übergang einplanen, shippen schneller als Teams, die mit den Abstraktionen kämpfen. Semantic Kernel bleibt das Framework für .NET-Teams; das [KernelFunction]-Plugin-Modell passt sauber in .NET-Service-Hosts. Ein Muster, das sich über alle drei abzeichnet: dünner Agent, dicker MCP — Fähigkeiten leben hinter der Protokollgrenze, Frameworks werden zu dünnen Proxies, und derselbe MCP-Server wird von Strands auf AWS, Microsoft Agent Framework auf Azure und LangChain auf einem Entwicklerlaptop konsumiert, ohne Portierungsarbeit. Das ist die Trajektorie, die das Protokoll ermöglichen sollte.
13.4 Die produktiven Integrationsmuster
Drei Muster haben sich in den 2025–2026er Referenzarchitekturen gesetzt. Das Gateway-und-State-Layer-Muster setzt ein gemanagtes Modell-Gateway (Bedrock, AI Foundry, LiteLLM) vor die Modellschicht und eine separate dauerhafte State-Schicht dahinter. Das Gateway ist, wo Auth, Rate-Limiting, Inhaltsfilterung und Audit leben; die State-Schicht ist, wo Dauerhaftigkeit lebt. Dieses Muster ist der produktive Default; neue Deployments sollten es übernehmen, sofern sie keinen spezifischen Grund dagegen haben, weil Teams, die das Gateway überspringen und den Modellanbieter direkt rufen, das innerhalb eines Quartals bereuen. Das MCP-Service-Mesh-Muster behandelt MCP-Server als Microservices und exponiert sie durch ein Mesh, das mTLS, Retries und Circuit-Breaking erledigt — die Kosten lohnen sich nur im Maßstab (mehr als zehn Server) oder in regulierten Umgebungen, die Network-Layer-Attestation verlangen. Das Managed-Everything-Muster übergibt Runtime, Memory, Identity und Tool-Registry an einen cloud-gemanagten Agentendienst (Bedrock AgentCore, Azure AI Foundry Agent Service, Vertex AI Agent Builder); es gewinnt für interne Automatisierung und Copilots, in denen der Agent nicht das primäre Produkt ist, und verliert für Teams, in denen der Agent das Produkt ist und die operativen Hebel zählen. Zwei Muster, die nicht gewonnen haben und es wert sind, als Negativbeispiele benannt zu werden: alles-im-LLM-Kontext (Agenten, deren Gedächtnis ein ständig wachsender System-Prompt ist) und Framework-als-Orchestrator (ein starrer DAG, in dem das Modell Knotenparameter füllt). Beide sterben in Produktion aus den Gründen, die Kapitel 9 durchging, und die Lehre, die das Feld aufgesogen hat, lautet, dass die richtige Balance zwischen Framework-Struktur und Modellfreiheit sich weiter zum Modell verschiebt, je fähiger das Modell wird.
Was Kapitel 13 vorbereitet
Die Frameworks und Cloud-Dienste lassen Teams MCP-basierte Agenten shippen, ohne den Protokollstack jedes Mal neu zu schreiben. Was sie an sich nicht sagen, ist, ob das resultierende System tatsächlich funktioniert — ob der Agent die Aufgaben löst, für die er gebaut wurde, wie er sich unter Last verhält, wo die Performance-Klippen liegen und wie man zwei konkurrierende Architekturen ehrlich vergleicht. Kapitel 14 nimmt diese Frage frontal: es geht den MCP-Universe-Benchmark, die zwei systemischen Fehlermodi, die der Benchmark aufdeckte (Long-Context-Degradation und Unknown-Tool-Exploration), und die Durchsatz-Seite durch, in der die Lücke zwischen einem geteilten Session-Pool und dem naiven Session-per-Request-Muster grob eine Größenordnung beträgt.
Als Nächstes — Kapitel 14: Benchmarking, Testen und Performance. MCP-Universe auf echten Servern, die Long-Context- und Unknown-Tools-Minderungen, die funktionieren, die Zehnfach-Durchsatzlücke zwischen Session-per-Request und geteilten Session-Pools und wohin die Reihe als Nächstes geht.
