ki-buch/teil-02-agenten-mcp/kapitel-06-framework-oekosystem-2026.md

Kapitel 6: Frameworks und Runtimes wählen (2026)

Teil II · Agent Harness, MCP und portable Capabilities

---

Faustregel: Orientierung, kein Ranking. Produktnamen und APIs sind volatil (Stand 2026-07). Entscheidend sind Vergleichsachsen, MCP-Grenze und Evals – nicht Leaderboard-Positionen. [E4]

Framework-Diskussionen enden oft in Feature-Bingo: wer hat Multi-Agent, wer hat das schönste Graph-UI, wer „unterstützt MCP“. Drei Monate später hat sich die Logo-Landschaft verschoben – und eure Capabilities stecken trotzdem im falschen Layer. Der eigentliche Fehler ist nicht die falsche Bibliothek, sondern die Annahme, ein Framework ersetze Architektur, Policies und portable Domänenfähigkeiten.

These: Orchestrierung darf framework-spezifisch sein; Capabilities und Policies sollten portabel bleiben (häufig über MCP). Frameworks sparen Boilerplate für Loops, State und HITL – sie sind nicht eure Trust Boundary und nicht euer Eval-Orakel.

Leitfrage: Welche Runtime-Familie passt zu euren Constraints – und was bleibt bewusst außerhalb des Frameworks?

Dieses Kapitel liefert Vergleichsachsen statt Ranking, ordnet Runtime-Familien (Graph, Crew, Multi-Agent, Enterprise, IDE-native, MCP-first) ein, verortet MCP unter der Orchestrierung und knüpft Auswahl an Evaluierung sowie Build/Buy/Compose. Es verdrahtet die Entscheidungslandkarte aus Kapitel 4.0 und bereitet die Praxis vor: SDLC, Toolchain und Hands-on (Kap. 7–10) setzen voraus, dass ihr Framework und Capability-Schicht trennen könnt.

Lernziele

Nach diesem Kapitel kannst du:

• das Agenten-Framework-Ökosystem 2026 entlang klarer Vergleichsachsen bewerten,
• typische Framework-Familien (Graph-/State-Maschinen, Crew-/Rollen, Multi-Agent-Runtime, IDE-native Hosts) einordnen,
• erklären, wo MCP im Stack sitzt (unter dem Framework, nicht als Ersatz für Orchestrierung),
• erklären, wie Frameworks MCP nutzen (nicht ersetzen),
• eine Evaluierungsstrategie für tool- und kontextbasierte Agenten entwerfen,
• Build vs. Buy vs. Compose mit Default-Architektur 2026 begründen.

---

Schicht	In diesem Kapitel	Stand
Stabil	Auswahlkriterien, MCP-first vs. Framework-Orchestrierung	Prinzipien
Mittelstabil	Eval-Scorecards, Gateway-Muster	Muster
Volatil	Framework-APIs, Produktnamen, Feature-Listen	Juli 2026

6.1 Warum Frameworks – und warum sie nicht die Architektur ersetzen

Ein Framework spart Boilerplate: Message-Loops, Retries, State, Visualisierung, Provider-Adapter. Es ersetzt nicht:

• eure Domain-Capabilities (die gehören in MCP-Server),
• eure Policies und Trust Boundaries,
• eure Definition of Done und Evals,
• eure Daten- und Compliance-Realität.

Analogie: Das Framework ist das Betriebssystem und der Scheduler. MCP-Server sind Treiber und Peripherie. Context Engineering ist die Prozess-Policy, welches Programm wann welchen Speicher sieht. Wer nur das OS wechselt, aber keine Treiber hat, starrt auf einen Desktop.

Regel 2026: Orchestrierung darf framework-spezifisch sein; Capabilities sollten portabel (MCP) sein.

---

6.2 Vergleichsachsen für die Auswahl

Framework-Vergleiche scheitern oft an Feature-Listen. Besser: Achsen, die eure Constraints abbilden (State, MCP, Eval, Lock-in). Die Tabelle ist eine Scorecard-Vorlage – füllt sie mit euren Gewichten, nicht mit Marketing-Häkchen. Jede Zeile und jedes Produkt-Beispiel in diesem Kapitel ist Orientierung, nicht Ranking [E4].

Achse	Fragen
Orchestrierungsmodell	Graph/State, Crew-Rollen, Event-Bus, freier Chat?
State	typisiert? checkpointbar? human-in-the-loop?
Tooling	native Functions, OpenAPI, MCP, Plugins?
Multi-Agent	first-class oder simuliert?
Observability	traces, token costs, replay?
Hosting	local, cloud control plane, air-gapped?
Sprachen	Python, TS, polyglot?
Reife & Governance	Lizenz, Community, Enterprise-Support
Eval-Hooks	wie testest du Agentenläufe?
Vendor-Lock-in	State-Format, proprietary tool protocol

{ width=100% } (Orientierungskarte, kein Leaderboard: Positionen und Logos sind volatil – entscheide entlang der Achsen.)

---

6.3 Runtime-Familien (Orientierungskarte)

Die Familien unten sind Denkmuster, keine Kaufempfehlung und kein Ranking. Lest die Spalten „Wann wählen“ und „Vorsicht“ zuerst – sie entscheiden mehr als der Charakter-Slogan. Illustrative Produktnamen sind volatil (Stand 2026-07); die Achsen aus 6.2 bleiben.

{ width=100% }

Familie	Charakter	Wann wählen	MCP-Rolle	Vorsicht
Graph / State-Machine	Nodes, Checkpoints, HITL	Edit→Verify-Phasen, CI-Jobs	Nodes rufen Tools/Resources	Over-Engineering für Mini-Edits
Crew / Rollen	Researcher→Writer→Reviewer	Rollen+Deliverables, schnelle Demos	Server-Subset pro Rolle; Shared Memory	Chat-Kaskaden ohne Contracts (Kap. 5.10, 8)
Multi-Agent / Konversation	Group-Chat, Debatte	Red-Team, Analyse	Blackboard als Shared Context	ungeeignet als Prod-Code-Bus
Enterprise-Plattform	Identity, Audit, Builder	reguliert, multi-team	Domänen-IP in euren Servern	Lock-in, wenn Tools nur proprietary
IDE-native Host	Produkt = Runtime	Alltag der Devs	Team-Katalog + CI reused dieselben Server	Host ≠ portable Orchestrierungslogik (Kap. 9)
MCP-first Runtime	Loop um Capabilities	Server-zentriert, wenig Graph-Magie	MCP primär	trotzdem Policies + Evals

Wann wählen (eine Zeile pro Familie): Graph bei verifizierbaren Phasen und HITL; Crew bei klaren Rollen-Deliverables; Multi-Agent-Chat bei Debatte/Analyse, nicht als Prod-Bus; Enterprise bei Identity/Audit; IDE-Host für den Dev-Alltag; MCP-first, wenn Capabilities und Policies vor Framework-Magie stehen.

Illustrative Klassen-Namen (volatil, kein Ranking): Graph z. B. LangGraph-artig; Crew z. B. CrewAI-artig; MCP-first z. B. mcp-agent-artig; Enterprise z. B. Semantic-Kernel-/Cloud-Builder-artig; Server-DX z. B. FastMCP / Official SDKs. Bewerte die Achsen in 6.2, nicht das Logo.

---

6.4 MCP im Stack und Gateway

{ width=100% }

Stabiles Prinzip: Framework orchestriert (State, Retries, HITL). MCP I/O’t (Tools, Resources, Prompts). Domänenlogik gehört in Server – nicht verstreut in Graph-Nodes.

Baustein	Rolle
Official Python/TS SDK	spezifikationsnahe Implementierung
FastMCP o. Ä.	ergonomische Server-DX (volatil)
Gateway (ab Teamgröße/Compliance)	OAuth, Allowlists, Rate Limits, Audit

{ width=100% }

Adapter-Muster (eine Zeile): Run-Start → MCP-Sessions öffnen → Context-Node liest Resources → Verify-Node ruft run_unit_tests → Cleanup bei Interrupt. Konkrete SDK-Syntax ist illustrativ und versionsabhängig – Companion / Vendor-Docs (Stand Juli 2026).

Wann MCP nicht im Framework verdrahten: siehe Kap. 4.0 und 4.7.5 (Editor-UX, Single-Host-Schuld, Agent-zu-Agent-Orchestrierung).

---

6.5 Evaluierung von MCP-basierten Agenten

Klassische LLM-Benchmarks (MMLU & Co.) sagen wenig darüber, ob euer Coding Agent mit euren Tools und eurem Kontext zuverlässig arbeitet.

6.5.1 Was du messen solltest

Dimension	Metriken / Signale
Task Success	% Aufgaben erfüllt nach Definition of Done
Tool Correctness	richtige Tools, korrekte Args, wenige Retries
Grounding	Behauptungen durch Observations gedeckt
Context Quality	nötige Resources geladen? Rauschen-Anteil?
Efficiency	Tokens, Steps, Wall-Clock, Kosten
Safety	Policy-Violations, Secret-Touch, path escapes
Stability	Varianz über Seeds / Model-Updates
Human Effort	Edit-Rate, Review-Zeit, Revert-Rate

6.5.2 Eval-Set bauen (praktisch)

1. 30–100 reale Tasks (anonymisiert) aus Issues/PRs
2. Fixtures: Repo-Snapshot, Fake-CI, Fake-Issues als MCP-Testserver
3. Orakel: Tests grün, Datei-Inhalte, JSON-Felder, verbotene Pfade
4. Runner: Host/Framework headless, fester Seed wo möglich
5. Reports: Trace pro Step + Scorecard

Illustratives Snippet – API-Namen und Runner-Hooks je Framework-/SDK-Version; kein Copy-Paste-Vertrag (Stand 2026-07).

from dataclasses import dataclass


@dataclass
class EvalCase:
    id: str
    goal: str
    # MCP fixture servers wired in test harness
    must_call_tools: tuple[str, ...]
    forbid_tools: tuple[str, ...]
    success_check: str  # z.B. "tests_passed && file_contains:x"


def score_trace(case: EvalCase, called: list[str], success: bool) -> dict:
    missing = [t for t in case.must_call_tools if t not in called]
    forbidden = [t for t in case.forbid_tools if t in called]
    return {
        "id": case.id,
        "success": success and not missing and not forbidden,
        "missing_tools": missing,
        "forbidden_tools": forbidden,
    }

6.5.3 Context-Qualität messen

Zusätzliche Logger im Host:

• welche Resource-URIs geladen wurden,
• Token-Anteile pro Kategorie,
• Context Hit: goldene Datei/URI war enthalten?
• Context Waste: Anteil Chunks mit Similarity/Score unter Schwelle

{ width=100% }

6.5.4 MCP-spezifische Testpyramide

Ebene	Was	Wie
Unit	Server-Tools/Resources	pytest/jest ohne LLM
Contract	JSON-Schema, URI-Formate	schema tests
Loop	Agent mit Fake-MCP	deterministic fixtures
Staging	echte Server, non-prod Daten	canary tasks
Prod Analytics	Erfolg, Kosten, Incidents	continuous eval sample

Pitfall: Nur Golden-Answer-String-Matching auf freie Modelltexte. Besser strukturelle und ausführbare Orakel.

6.5.5 Regression bei Model- oder Server-Updates

Jedes Update von:

• Foundation Model,
• Systemprompt/Policy,
• MCP-Server-Version,

sollte die Eval-Suite triggern. Semantic Versioning für Server: Breaking Tool-Rename = Major.

6.5.6 Öffentliche Benchmarks vs. interne Suite

Klassische Benches (MMLU, HumanEval) und selbst SWE-bench / SWE-bench Verified beantworten: „Wie gut löst dieses Scaffold öffentliche GitHub-Issues?“ Sie beantworten nicht: „Darf Server X mit Policy Y bei uns auf L2?“

MCP-spezifisch relevant (Stand 2026-07, Details Anhang F.3):

Bench	Fokus	Stufe
MCP-Bench (Wang et al., 2025, arXiv:2508.20453)	multi-step Tool-Use über MCP-Server	[E3]
MCP-AgentBench (Guo et al., AAAI 2026)	MCP-mediated Tasks, outcome-Eval	[E3]
MCPSecBench (Yang et al., arXiv:2508.13220)	Angriffsflächen / Security	[E3]
Eure Suite (Anhang C)	Success + Safety + Context Hit in eurer Welt	Freigabe ([E3*] / intern)

Leaderboards veralten in Wochen – immer Stand-Datum pinnen. Öffentliche Benches vorselektieren; Freigabe entscheidet eure Suite [E4]. Für Produktivitäts- und Feldstudien (Copilot-RCTs, METR [E1]; DORA [E2]): Anhang F.2; Mindest-Set interner Cases: Anhang F / C (≈15 Coding + 5 Safety + 5 Context-Hit) [E4].

---

6.6 Entscheidungsleitfaden: was solltet ihr wählen?

{ width=100% }

Ergänzt die Landkarte Kap. 4.0. Kurzform:

Empfohlene Default-Architektur 2026

Orientierung (kein Branchenmittel) [E4]:

1. MCP-Server für Git/Repo, Issues, CI/Tests, Project Memory, optional Code Graph
2. IDE-Host für den Alltag der Entwickler
3. Graph-Runtime nur für schwere Automationen / CI-Agenten
4. Gateway ab Teamgröße / Compliance
5. Eval-Harness ab Tag 1 der Produktisierung

Build vs. Buy

Kaufen/Nutzen	Selbst bauen
Host/IDE, generische PoC-Server	Server mit eurer Domäne und IP
Model APIs, Observability-Backend, Auth-Provider	Policy-Logik, Memory-Ontologie, Threat Model

---

Best Practices

1. Capabilities in MCP, Orchestrierung im Framework/Host – saubere Grenze.
2. Einheitliche Server-IDs und Tool-Namespaces über alle Runtimes.
3. Pro Framework-Integration ein Adapter-Modul, nicht Business-Logik im Graph-Node verstreut.
4. Eval-Cases aus echten Incidents und PRs ableiten.
5. Kosten- und Step-Budgets im Framework konfigurieren, nicht hoffen.
6. Versioniert: prompts, policies, server, eval-set.
7. Bevorzuge deterministische Fixtures-MCP-Server in CI.

---

Pitfalls

Pitfall	Folge	Gegenmaßnahme	Kapitel-Querverweis
Framework-Hopping jedes Quartal	Rewrite-Tax	stabile MCP-Schicht	Kap. 6
Alles in LangChain/Crew-Tools ohne MCP	Lock-in	MCP-Adapter	Kap. 6
Demo-Multi-Agent ohne Evals	Prod-Chaos	Scorecards first	Kap. 6
Ein Mega-Graph für alle Use Cases	unwartbar	mehrere kleine Graphen/Skills	Kap. 6
Prod-Server in Unit-Tests	Flake, Gefahr	Fake-MCP	Kap. 6
Nur Win-Rate, keine Safety-Metriken	stille Risiken	Safety scorer	Kap. 6

---

Key Takeaways

• Frameworks orchestrieren; MCP portiert Capabilities; Context Engineering steuert Sichtbarkeit.
• Wähle nach Achsen (6.2) und Landkarte 4.0 – Orientierung, nicht Ranking; Feature-Bingo und Logo-Hopping vermeiden.
• Graph / Crew / Enterprise / IDE-Host / MCP-first sind Familien – Produktnamen veralten.
• Evaluierung muss Tool-Use, Context-Qualität, Safety und Success umfassen (6.5).
• Default: portable Capabilities + IDE-Alltag + Eval ab Tag 1; Graph und Gateway nur bei Bedarf.
• Die teuerste Entscheidung ist oft nicht das Framework – sondern nicht-portable Integrationen.

---

Was als Nächstes kommt

Teil III bringt die Praxis: Kapitel 7 verankert Agenten im Software Development Life Cycle und zeigt Context Engineering für Coding Agents mit MCP (Codebase, Git-Historie, Issues, Docs on-demand).

---

Übungsanregungen

1. Bewertet euren aktuellen Stack auf den 10 Vergleichsachsen (1–5 Punkte).
2. Listet alle Tools, die heute nur in einer IDE leben – Kandidaten für MCP-Server.
3. Schreibt 10 EvalCases inkl. must_call_tools und ausführbarem Success-Check.
4. Skizziert einen Fake-tests-MCP-Server für CI-Evals.