KI-Agenten, MCP und die moderne Framework-Landschaft

Wie KI-Agenten funktionieren

Ein KI-Agent ist ein LLM-gesteuertes System, das in einer Schleife arbeitet:

1. Planen: ein Ziel in Teilaufgaben zerlegen.
2. Handeln: ein oder mehrere Tools auswählen und aufrufen.
3. Beobachten: Tool-Ergebnisse lesen und den internen Zustand aktualisieren.
4. Iterieren: wiederholen, bis das Ziel erreicht ist oder eine Abbruchbedingung eintritt.

Das grundlegendste Beispiel für diese Schleife ist ReAct (Reasoning + Acting). 2022 von Yao et al. vorgestellt, verschränkt ReAct Reasoning-Spuren im Sinne einer Gedankenkette mit Action-Schritten. Der Agent denkt laut darüber nach, was zu tun ist, ruft ein Tool auf, beobachtet das Ergebnis und überlegt erneut. Es ist faktisch das "Hello World" der Agentenarchitekturen: Nahezu jedes moderne Framework (LangChain, Semantic Kernel, ADK, Agents SDK) liefert eine Schleife im ReAct-Stil als Standard-Agentenmodus mit. ReAct zu verstehen ist die Voraussetzung, um alles Weitere in diesem Artikel zu verstehen.

Optional binden Agenten Memory (Kurz- und Langzeitkontext) und Human-in-the-Loop-Checkpoints für sicherheitskritische Entscheidungen ein.

NVIDIAs kanonische Zerlegung bleibt ein nützliches mentales Modell:

Agenten vs. Workflows (Anthropics Unterscheidung)

Beide gehören zur selben Familie der agentischen Systeme. Produktionssysteme kombinieren häufig deterministische Workflow-Schritte mit agentengesteuerten Teilaufgaben, wo Flexibilität nötig ist.

Tools sind semantische Verträge

Tools sind semantische Verträge. Ein Agent liest Name, Beschreibung und Schema eines Tools, um zu entscheiden, ob und wie er es aufruft. Sind eines dieser Signale unklar, kann der Agent:

• das falsche Tool aufrufen.
• fehlerhafte Eingaben übergeben.
• Ausgaben falsch interpretieren und nachgelagert halluzinieren.

Anthropics Forschung zum Schreiben von Tools für Agenten zeigt, dass es die Abschlussraten messbar verbessert und Token-Verschwendung reduziert, wenn man Tools wie an Entwickler gerichtete Produkte behandelt:

Muster: Von Workflows zur vollen Autonomie

Diese Muster bewegen sich auf einem Spektrum von vollständig deterministisch bis vollständig autonom. Wählen Sie nach dem Maß an Kontrolle und Varianz, das Ihr Anwendungsfall verlangt:

Faustregel (Anthropic): Beginnen Sie mit dem einfachsten Muster, das das Problem löst. Steigen Sie nur dann zu vollen Agentenschleifen auf, wenn die Aufgabe wirklich dynamische Entscheidungen verlangt.

Praxisbeispiel: GitHub Copilot in VS Code

Der Coding-Agent von GitHub Copilot in VS Code veranschaulicht gut, wie diese Muster in einem ausgelieferten Produkt zusammenspielen:

1. Routing. Wenn Sie eine Nachricht eingeben, klassifiziert Copilot die Absicht: Ist das eine Inline-Vervollständigung, eine Chat-Frage oder eine Bearbeitung über mehrere Dateien? Jede führt zu einer anderen Pipeline.
2. Orchestrator-Workers. Im Agentenmodus erhält Copilot eine übergeordnete Aufgabe (z. B. "Eingabevalidierung zum Anmeldeformular hinzufügen"), zerlegt sie in Teilaufgaben und delegiert jede an spezialisierte Tool-Aufrufe: Dateien lesen, nach Symbolen grep-en, Terminalbefehle ausführen, Änderungen anwenden, Tests laufen lassen.
3. Evaluator-Optimizer. Nach Änderungen führt der Agent Linter, Tests oder Typechecker aus. Schlägt etwas fehl, liest er die Fehlerausgabe, überlegt sich die Korrektur und iteriert in einer Schleife aus Generieren, Bewerten, Verfeinern.
4. Prompt Chaining mit Schranken. Die Ausgabe jedes Schritts schränkt den nächsten ein. Liefert ein Dateizugriff unerwarteten Inhalt, plant der Agent neu, statt blind weiterzumachen.

Im Inneren ist dies eine ReAct-Schleife, gestützt auf eine Tool-Integration im MCP-Stil: Copilot entdeckt verfügbare Tools (Dateisystem, Terminal, Suche, Editor-APIs), ruft sie über strukturierte Schemata auf, beobachtet Ergebnisse und überlegt die nächsten Schritte. Es ist ein konkretes Beispiel für ein Produktionssystem, das deterministische Workflows mit agentengesteuerter Flexibilität verbindet.

Copilot lässt Sie außerdem zwei zentrale Stellschrauben austauschen, die das Verhalten direkt beeinflussen:

• Modell. Der Wechsel etwa von GPT-4o zu Claude Sonnet oder Gemini ändert die Reasoning-Engine. Verschiedene Modelle haben unterschiedliche Stärken: Manche planen mehrstufige Änderungen besser, andere folgen Anweisungen präziser, wieder andere minimieren Halluzinationen. Dieselben Tools und derselbe Prompt können je nach Modell merklich unterschiedliche Ergebnisse liefern, weshalb Evals (Phase 4 im Umsetzungsplan weiter unten) wichtig sind.

• Modus. Copilot bietet drei eingebaute Modi, die an unterschiedlichen Punkten des Autonomiespektrums sitzen:

  • Ask: eine Frage-Antwort-Pipeline (Prompt Chaining). Keine Dateibearbeitungen, keine Tool-Aufrufe, nur Reasoning über den von Ihnen bereitgestellten Kontext.
  • Agent: die volle Orchestrator-Workers-Schleife. Er kann Ihre Codebasis lesen, Terminalbefehle ausführen, Abhängigkeiten installieren, Dateien anlegen und bei Fehlern eigenständig iterieren. Das ist die ReAct-Schleife in Aktion.
  • Plan: ein Mittelweg. Der Agent durchdenkt die Aufgabe und erstellt einen Schritt-für-Schritt-Plan, wartet aber auf Ihre Freigabe, bevor er Änderungen ausführt. Das entspricht im Wesentlichen dem zuvor beschriebenen Muster des "Human-in-the-Loop-Checkpoints".

  Der Übergang von Ask über Plan zu Agent erhöht die Flexibilität, steigert aber auch Varianz, Kosten und die Bedeutung guter Tool-Schemata. Sie können außerdem Custom Agents mit maßgeschneiderten Anweisungen und Tool-Sets definieren und so faktisch eine spezialisierte Routing-Ebene für Ihre eigenen Workflows schaffen.

• Sessions. Copilot unterstützt mehrere parallel laufende Agenten-Sitzungen, jede mit eigenem Modell, eigenem Modus und eigenem Kontext. Das verwandelt das Einzelagentenmodell in ein praktisches Parallelization-Muster: Eine Sitzung kann Unit-Tests für eine Komponente schreiben, eine andere ein neues Feature umsetzen, eine weitere Dokumentation generieren, alle gleichzeitig gegen dieselbe Codebasis. Das funktioniert besonders gut in Architekturen mit klaren Modulgrenzen. In einem Django-Projekt etwa ist jede App (Authentifizierung, Abrechnung, Benachrichtigungen) weitgehend eigenständig, mit eigenen Models, Views, URLs und Tests. Sie können gefahrlos parallele Sitzungen aufsetzen, die auf verschiedene Apps zugeschnitten sind, mit minimalem Risiko von Merge-Konflikten, weil sich die Dateiflächen kaum überschneiden. Dasselbe Prinzip gilt für jede Codebasis mit klar definierten Paket- oder Servicegrenzen (Microservices, Monorepo-Pakete, Go-Module usw.). In der Praxis erlauben Ihnen parallele Sitzungen, Wanduhrzeit gegen Durchsatz zu tauschen und das, was sequenzielle Arbeit wäre, zu nebenläufiger Arbeit zu verdichten, solange die Aufgaben hinreichend isoliert sind.

Das Framework-Ökosystem

Das Ökosystem teilt sich in drei Schichten. Agenten-Frameworks sind der Ort, an dem Sie Agenten bauen. MCP ist das Protokoll, das sie mit externen Tools verbindet. Governance-Schichten verwalten Flotten von Agenten im Unternehmensmaßstab. Sie ergänzen sich, sie sind keine Alternativen.

Agenten-Frameworks

Microsoft Agent Framework

• Derzeit in der Public Preview (GitHub).
• Vereint Semantic Kernel (SK) und AutoGen unter einem einzigen Programmiermodell.
• Ergänzt typisierte, graphbasierte Workflows mit starker Beobachtbarkeit (eingebautes OpenTelemetry).
• Native Integration von MCP und dem A2A-Protokoll.
• Multi-Provider-Unterstützung: Azure OpenAI, OpenAI, Anthropic, Ollama und mehr.
• Wird mit einer Entwickler-UI (DevUI) zum Inspizieren von Agenten-Traces ausgeliefert.

OpenAI

Der Agenten-Stack von OpenAI verteilt sich über mehrere Produkte:

Die Agent-Platform-Seite ist OpenAIs Marketing-Dach für all das oben Genannte.

Google Agent Development Kit (ADK)

• Quelloffenes, modulares Framework, optimiert für Gemini, aber modellagnostisch.
• Unterstützt Topologien mit einem oder mehreren Agenten.
• Deployment-Ziele:
  • Vertex AI Agent Engine: vollständig verwaltet, automatisch skalierend.
  • Cloud Run: containerisiert, mit eigener Infrastruktur.
  • GKE: Kubernetes-basiertes Deployment.

Interoperabilitätsprotokoll

MCP (Model Context Protocol)

• Offener Standard, ursprünglich von Anthropic geschaffen, inzwischen von der Linux Foundation verwaltet und offen für Beiträge der Community (Protokoll & SDKs, Server-Registry).
• Clients (Claude, ChatGPT, VS Code, JetBrains-IDEs, Cursor usw.) verbinden sich mit MCP-Servern, die Tool-Schemata bereitstellen.
• Wird rasch zur De-facto-Interoperabilitätsschicht für agentische Systeme.
• Wachsende Registry an Community- und Anbieter-Servern (GitHub, Azure DevOps, Notion, Playwright, Slack, Datenbanken usw.).
• Zentraler Nutzen: Schreiben Sie Ihre Tools einmal und stellen Sie sie jedem MCP-kompatiblen Client bereit, ohne Integrationsaufwand je Client.
• Alle drei oben genannten Frameworks unterstützen MCP nativ oder über Plugins.

Governance-Schichten

MuleSoft Agent Fabric (Salesforce)

• Unternehmens-Governance-Schicht für Agentenflotten:
  • Registry: Katalog verfügbarer Agenten und Tools.
  • Broker: leitet Anfragen an den richtigen Agenten.
  • Policies: Zugriffskontrolle, Rate Limiting, Schutz vor Datenverlust.
  • Observability: zentrales Logging und Tracing.
• Unterstützt MCP als Konnektivitätsstandard.
• Konzipiert für Organisationen, die Dutzende bis Hunderte Agenten im großen Maßstab betreiben.

Multi-Agenten-Teams

Ein wachsendes Muster sind containerisierte Agenten-Teams: Gruppen domänenspezialisierter Agenten, die unter einer gemeinsamen Governance-Hülle zusammenarbeiten:

• AgentCatalog auf Docker Hub ist ein frühes Beispiel: vorgefertigte Agenten-Images für gängige Aufgaben.
• Teams lassen sich dynamisch zusammenstellen (z. B. ein Team zur "Vertragsprüfung" mit einem Agenten zur Klauselextraktion, einem zur Risikobewertung und einem zur Zusammenfassung).
• Container-Orchestrierung (Kubernetes, Docker Compose) ermöglicht Skalierung, Versionierung und Rollback auf Agentenebene.
• Interne Governance- und Zugriffsregeln können pro Container durchgesetzt werden.

Referenzarchitekturen

Alle vier laufen auf MCP als Standard für die Tool-Konnektivität zusammen. Die Wahl richtet sich nach dem bestehenden Cloud-Fußabdruck, den Anbieterbeziehungen und den Governance-Anforderungen.

Von null bis zur Produktion: Ein Umsetzungsplan

Jede Phase hat ein klares Ergebnis und Ausstiegskriterien, damit Sie wissen, wann es weitergeht (oder eine Schleife zurück nötig ist).

Phase 1: Definieren Sie Ihre Tool-Oberfläche

Ziel: Entscheiden, was bereitgestellt wird, bevor Code geschrieben wird.

1. Prüfen Sie die bestehenden APIs und Workflows Ihres Systems. Bestimmen Sie 3 bis 5 hochwertige Operationen, die Agenten realistischerweise aufrufen würden, z. B. Dokumente suchen, Entitäten extrahieren, einen Fallstatus prüfen, eine Zusammenfassung erstellen.
2. Beantworten Sie für jede Operation:
   • Was sind die Pflicht- und was die optionalen Eingaben? (Typisieren Sie sie streng.)
   • Wie sieht die Ausgabe im Erfolgsfall aus? Und wie die Fehlerausgabe?
   • Ist die Operation schreibgeschützt oder hat sie Nebenwirkungen?
3. Schreiben Sie Tool-Schemata (JSON Schema oder Äquivalent) mit:
   • Einer klaren, agentenlesbaren description. Das sieht das LLM, um zu entscheiden, ob es das Tool aufruft.
   • Einem mode-Parameter ("concise" | "detailed"), um die Ausführlichkeit der Ausgabe zu steuern.
   • Cursor-basierter Pagination (cursor + limit) für Listen-Endpunkte.
   • Einem truncated: true-Flag in den Antworten, damit der Agent weiß, dass er mehr abrufen muss.
   • Lehrenden Fehlern: Fehlermeldungen, die dem Agenten sagen, wie er den Aufruf korrigiert, nicht nur, dass er fehlschlug.

Ergebnis: Ein Schema-Dokument (OpenAPI oder MCP-Tool-Definitionen), geprüft von mindestens einer Person, die es nicht geschrieben hat.

Ausstiegskriterium: Ein Teammitglied kann die Schemata ohne Vorwissen lesen und korrekt vorhersagen, was jedes Tool tut, welche Eingaben es braucht und wie die Ausgabe aussieht.

Phase 2: Bauen Sie den MCP-Server

Ziel: Die Schemata in einen laufenden Server verwandeln, mit dem sich jeder MCP-Client verbinden kann.

1. Implementieren Sie jedes Tool hinter einem MCP-konformen Server (TypeScript- oder Python-SDK).
2. Wählen Sie den Transport nach Anwendungsfall:

3. Bauen Sie Sicherheit von Tag eins an ein:
   • Tools mit Nebenwirkungen müssen einen dry_run-Modus (gibt zurück, was passieren würde) und einen commit-Modus (führt die Aktion aus) unterstützen.
   • Destruktive Operationen erfordern einen Schritt zur menschlichen Bestätigung, bevor commit fortfährt.
4. Validieren Sie die Interoperabilität mit mindestens zwei MCP-Clients (z. B. Claude Desktop + VS Code Copilot). Wenn beide jedes Tool entdecken und korrekt aufrufen können, ist der Server bereit.

Ergebnis: Ein bereitgestellter (oder lokal lauffähiger) MCP-Server mit bestandenen Integrationstests gegen zwei Clients.

Ausstiegskriterium: Beide Clients können eine realistische, mehrstufige Aufgabe durchgängig erledigen, allein mit den bereitgestellten Tools.

Phase 3: Schließen Sie ein Agenten-Framework an

Ziel: Beweisen, dass der MCP-Server mit einem echten Agenten funktioniert. Wählen Sie zu Beginn ein Framework.

Wählen Sie das Framework, das zum Stack Ihres Teams passt:

Bauen Sie zwei Dinge:

1. Einen deterministischen Workflow: eine feste Folge von Tool-Aufrufen (z. B. "suchen, extrahieren, zusammenfassen"). Das validiert, dass die Tools korrekt zusammenspielen.
2. Einen freien Agenten: dieselben Tools, aber das LLM entscheidet den Plan zur Laufzeit. Das prüft Ihre Schemata unter Belastung: Wählt der Agent das falsche Tool oder übergibt schlechte Eingaben, müssen Sie an Ihren Beschreibungen oder Fehlermeldungen arbeiten.

Optional wiederholen Sie es mit einem zweiten Framework, um zu bestätigen, dass der MCP-Server wirklich framework-agnostisch ist.

Ergebnis: Ein funktionierender Agent (Workflow + frei), der mit dem MCP-Server echte Aufgaben erledigt.

Ausstiegskriterium: Der Agent erledigt mindestens 80% der Testaufgaben ohne menschliches Eingreifen.

Phase 4: Bewerten und iterieren

Ziel: Messen, wie gut Agenten Ihre Tools nutzen, und beheben, was kaputt ist.

1. Erstellen Sie 10 bis 20 realistische Aufgaben mit erwarteten Ground-Truth-Ausgaben (z. B. "Finde alle in Q2 auslaufenden Verträge und fasse die wichtigsten Pflichten zusammen").
2. Lassen Sie jede Aufgabe sowohl durch den Workflow als auch durch den freien Agenten laufen. Erfassen Sie bei jedem Durchlauf:

3. Triagieren Sie Fehlschläge:
   • Falsches Tool gewählt: verbessern Sie die description des Tools.
   • Falsche Parameter: verschärfen Sie das Schema, fügen Sie enum-Beschränkungen hinzu, verbessern Sie die Fehlerhinweise.
   • Korrekter Aufruf, falsche Interpretation des Ergebnisses: vereinfachen Sie das Ausgabeformat oder fügen Sie ein summary-Feld hinzu.
4. Lassen Sie die Eval-Suite nach jeder Korrektur erneut laufen. Verfolgen Sie die Verbesserung über die Iterationen.

Ergebnis: Eine Eval-Suite (automatisiert, wiederholbar) und ein Protokoll der Schema-Änderungen mit Erfolgsraten vor und nach.

Ausstiegskriterium: Mindestens 90% Erfolgsrate auf der Eval-Suite mit beiden Agentenmodi.

Phase 5: Härten und skalieren

Ziel: Auf Produktionslast und organisationsweiten Rollout vorbereiten.

1. Observability. Instrumentieren Sie den MCP-Server mit verteiltem Tracing (OpenTelemetry) und strukturiertem Logging. Jeder Tool-Aufruf sollte von der Client-Anfrage bis zum Backend-System nachvollziehbar sein.
2. Rate Limiting und Zugriffskontrolle. Entscheiden Sie, wer (welche Agenten, welche Nutzer) welche Tools aufrufen darf und mit welchem Durchsatz.
3. Governance im großen Maßstab. Wenn Sie mehrere MCP-Server oder Agenten-Teams erwarten, führen Sie eine Broker-/Fabric-Schicht ein (z. B. MuleSoft Agent Fabric) für:
   • Zentrale Durchsetzung von Policies.
   • Audit-Logging (wer rief was, wann, mit welchen Eingaben).
   • Überwachung auf Flottenebene und Not-Aus-Schalter.
4. Dokumentation. Veröffentlichen Sie einen Tool-Katalog (menschenlesbare Beschreibungen, Beispielaufrufe, bekannte Einschränkungen), damit andere Teams Agenten gegen Ihren MCP-Server bauen können, ohne ihn rückentwickeln zu müssen.

Ergebnis: Ein produktionsreifer MCP-Server mit Monitoring-Dashboards, Zugriffsregeln und einem veröffentlichten Tool-Katalog.

Ausstiegskriterium: Ein Team, das nicht am Bau des Servers beteiligt war, kann allein anhand des Katalogs und der öffentlichen Schemata einen neuen Agenten dagegen aufsetzen.