1. Zusammenfassung

Die Evolution von isolierten generativen Modellen hin zu "Agentic AI" markiert einen fundamentalen Paradigmenwechsel in der künstlichen Intelligenz. Nicht mehr die statistische Token-Vorhersage, sondern die Architektur autonomer Systeme als kognitives Betriebssystem steht im Zentrum. Agentische Systeme unterscheiden sich von reiner generativer KI durch autonome Orchestrierung, persistente Zustandsverwaltung und zielgerichtete Werkzeugnutzung über ausgedehnte Planungshorizonte. Dies erzwingt eine Transformation der Softwareentwicklung von linearen Pipelines hin zu komplexen, zyklischen Regelkreisen ("Reasoning Loops").

Bei der Implementierung konkurrieren "Pure Python"-Architekturen mit maximaler Kontrolle gegen spezialisierte Framework-Lösungen. Während der Verzicht auf Frameworks Transparenz für kritische Infrastrukturen sichert, aber hohen Wartungsaufwand bedeutet, haben sich Lösungen wie LangGraph für komplexe Anforderungen durchgesetzt. Durch graphenbasierte Zustandsmaschinen ("State Machines") ermöglichen sie zyklische Workflows, Selbstreflexion und stabile "Human-in-the-Loop"-Interaktionen, die mit linearen Ansätzen wie LangChain nicht realisierbar sind. Ergänzend bieten Frameworks wie CrewAI Abstraktionen für rollenbasierte Team-Dynamiken.

Für die Skalierbarkeit von "Long-Running Systems" sind robuste Persistenzmechanismen wie Checkpointing zwingend erforderlich, um Ausfallsicherheit und zeitliche Kontinuität zu gewährleisten. Das entscheidende Nadelöhr für ein vernetztes KI-Ökosystem bleibt jedoch die Interoperabilität. Die Durchsetzung offener Standards - spezifisch das Model Context Protocol (MCP) für die Werkzeuganbindung und das Agent-to-Agent (A2A) Protokoll für die Kollaboration - bildet die notwendige Basis für modulare Systeme. Die künftige KI-Architektur basiert somit auf standardisierter, autonomer Kooperation statt auf monolithischen Silos.

2. Der Paradigmenwechsel zur agentischen Orchestrierung

Die Landschaft der künstlichen Intelligenz durchläuft im Jahr 2026 eine fundamentale Metamorphose, die weit über die iterative Verbesserung von Modellparametern oder Kontextfenstern hinausgeht. Wir beobachten eine historische Abkehr von isolierten, stochastischen "Prompt-Response"-Interaktionen hin zu komplexen, agentischen Systemen, die durch Autonomie, persistente Zustandsverwaltung und kollaborative Problemlösung gekennzeichnet sind. Während die generative KI (GenAI) primär auf die Erstellung von Inhalten fokussiert war, zielt die "Agentic AI" auf die autonome Erreichung komplexer Ziele durch mehrstufige Handlungsstränge ab [1].

Die Kernherausforderung der modernen Softwarearchitektur liegt in diesem Kontext nicht mehr allein in der Qualität des zugrundeliegenden Large Language Models (LLM), sondern in der Orchestrierung. Ein KI-Modell, so leistungsfähig es auch sein mag, gleicht einem hochintelligenten Berater, der in einem isolierten Raum ohne Werkzeuge, Gedächtnis oder Verfahrensanweisungen operiert. Ohne eine definierte Architektur fehlt diesem Berater die Fähigkeit zur zeitlichen Kontinuität, zur Nutzung externer Hilfsmittel und zur strukturierten Zerlegung abstrakter Ambitionen in exekutierbare Schritte. Die KI-Architektur fungiert hierbei als das kognitive Betriebssystem, das dem Modell diktiert, wann externe Informationen eingeholt, wo Zwischenergebnisse persistiert und wie Fehler durch reflexive Schleifen korrigiert werden sollen.

In der akademischen Taxonomie wird dieser Sprung deutlich unterschieden. Während klassische "AI Agents" oft als modulare Systeme mit hoher Autonomie innerhalb spezifischer Aufgaben definiert werden, beschreibt "Agentic AI" ein System, das durch Zielzerlegung (Goal Decomposition), inter-agentische Kommunikation und kontextuelle Adaption über weite Planungshorizonte hinweg operiert.

Dieser Bericht bietet eine erschöpfende Analyse der dominierenden Architekturmuster, die dieses neue Ökosystem definieren. Wir untersuchen das Spektrum von "Pure Python"-Implementierungen, die maximale Kontrolle bei höchstem manuellem Aufwand bieten, bis hin zu hochgradig abstrahierten Frameworks wie LangChain, LangGraph, CrewAI und LlamaIndex Workflows. Ein besonderer Fokus liegt dabei auf der technologischen Differenzierung zwischen transienten Systemen und "Long-running AI Agentic Systems", die eine persistente Zustandsverwaltung über Tage oder Wochen erfordern. Abschließend analysieren wir die kritische Infrastruktur für Interoperabilität, namentlich das Model Context Protocol (MCP) und das Agent-to-Agent (A2A) Protocol, welche die Standardisierung der Kommunikation zwischen Modellen, Datenquellen und autonomen Agenten vorantreiben.

3. Pure Python: Die Architektur der totalen Kontrolle

Der "Pure Python"-Ansatz, oft auch als "No-Framework" oder "Vendor-Agnostic Architecture" klassifiziert, stellt das Fundament dar, auf dem alle abstrakteren Systeme aufbauen. Er repräsentiert die Architektur der totalen Kontrolle und Transparenz und bildet oft die "Escape Hatch" für Senior Engineers, die sich von den Einschränkungen und Abstraktionsschichten moderner Frameworks befreien müssen.

3.1 Konzeptuelle Philosophie und der "Reasoning Loop"

Die Philosophie hinter Pure Python ist die Reduktion von Komplexität durch den Verzicht auf unnötige Middleware. In einer Zeit, in der Frameworks oft unter dem Problem der "Leaky Abstractions" leiden - wobei die interne Komplexität des Frameworks die Fehlerbehebung erschwert und Stack Traces unleserlich macht -, ist der direkte Zugriff auf die API des Modellanbieters (z.B. OpenAI, Anthropic) oft der robusteste Weg.

Ein LLM wie GPT-4 ist per Definition zustandslos. Es besitzt kein inhärentes Gedächtnis an vorherige Interaktionen zwischen zwei API-Aufrufen. Wenn wir also eine Unterhaltung oder einen agentischen Prozess führen wollen, müssen wir als Architekten die kognitive Kontinuität künstlich erzeugen. Dies geschieht durch die manuelle Verwaltung einer Listenstruktur (List/Array), in der alle bisherigen Nachrichten (SystemMessage, UserMessage, AssistantMessage) gespeichert und bei jedem neuen Inferenzschritt erneut an das Modell gesendet werden.

Der Kernmechanismus dieses Ansatzes ist die Endlosschleife (While-Loop), die den sogenannten "Reasoning-Loop" (Nachdenk-Zyklus) abbildet [2]. Der Algorithmus folgt dabei einem strikten deterministischen Muster:

1. Initialisierung: Eine Liste wird erstellt, die als Kontextspeicher fungiert.
2. Modell-Inferenz: In jedem Durchlauf der Schleife wird die gesamte Historie an das Modell gesendet. Das Modell entscheidet basierend auf diesem Kontext über den nächsten Schritt ("Next Token Prediction" auf Makroebene).
3. Entscheidungsbaum: Das Modell liefert entweder eine textuelle Antwort oder fordert die Ausführung eines Werkzeugs (Tool Call) an. Dies ist der kritische Verzweigungspunkt im Code.
4. Exekution: Wenn ein Werkzeugaufruf signalisiert wird (z.B. durch ein spezielles JSON-Schema oder tool_calls im API-Response), unterbricht der Python-Code den Fluss. Er extrahiert den Funktionsnamen und die Argumente, führt die entsprechende Python-Funktion lokal aus und injiziert das Ergebnis (Observation) zurück in die Nachrichtenliste.
5. Rekursion: Der Prozess wiederholt sich mit dem nun angereicherten Kontext, bis das Modell eine finale Antwort generiert oder eine Abbruchbedingung erreicht wird.

Dieser Code implementiert den beschriebenen Ansatz. Wir nutzen hier beispielhaft das OpenAI-SDK, da es der Industriestandard für diese Art von API-Interaktion ist, verzichten aber komplett auf abstrakte Frameworks wie LangChain oder CrewAI.

1import openai
2import json
3
4# 1. Initialisierung: Werkzeuge definieren (Lokale Funktionen)
5def get_weather(location):
6    """Simuliert einen API-Aufruf für Wetterdaten."""
7    print(f"--- [System] Führe Tool 'get_weather' für {location} aus ---")
8    return {"temp": "22°C", "condition": "Sonnig"}
9
10# Mapping für die Exekution
11available_tools = {
12    "get_weather": get_weather
13}
14
15def run_pure_python_agent(user_prompt):
16    client = openai.OpenAI() # Benötigt API-Key in Umgebungsvariable
17    
18    # 2.1 Kognitive Kontinuität: Die manuelle Listenstruktur
19    messages = [
20        {"role": "system", "content": "Du bist ein hilfreicher Assistent. Nutze Tools, falls nötig."},
21        {"role": "user", "content": user_prompt}
22    ]
23
24    # 2.2 Der Reasoning-Loop (Endlosschleife mit Abbruchbedingung)
25    while True:
26        # Schritt: Modell-Inferenz
27        response = client.chat.completions.create(
28            model="gpt-4o",
29            messages=messages,
30            functions=[{ # Definition des Tools für das Modell
31                "name": "get_weather",
32                "parameters": {
33                    "type": "object",
34                    "properties": {"location": {"type": "string"}}
35                }
36            }]
37        )
38        
39        response_message = response.choices[0].message
40        
41        # 2.3 Entscheidungsbaum: Tool Call oder Antwort?
42        if response_message.function_call:
43            # Exekution & Rekursion
44            function_name = response_message.function_call.name
45            function_args = json.loads(response_message.function_call.arguments)
46            
47            # Tool lokal ausführen
48            function_response = available_tools[function_name](**function_args)
49            
50            # Ergebnis in History injizieren (Wichtig für kognitive Kontinuität)
51            messages.append(response_message) # Die Anfrage des Modells speichern
52            messages.append({
53                "role": "function",
54                "name": function_name,
55                "content": json.dumps(function_response)
56            })
57            # Loop geht weiter -> Nächster Inferenzschritt
58        else:
59            # Finale Antwort erhalten
60            return response_message.content
61
62# Beispielaufruf
63if __name__ == "__main__":
64    result = run_pure_python_agent("Wie ist das Wetter in Berlin?")
65    print(f"\nFinale Antwort: {result}")
66

3.2 Technische Analyse: Transparenz vs. Verantwortung

Die Entscheidung für Pure Python ist eine Entscheidung für radikale Transparenz. Der Entwickler versteht jede Zeile Code. Es gibt keine versteckten Prompts, die das Framework im Hintergrund injiziert ("System Prompts"), und keine undurchsichtigen Token-Kosten. Dies ist besonders kritisch beim Debugging: Wenn ein Agent halluziniert oder in einer Schleife gefangen ist, erlaubt dieser Ansatz eine direkte Inspektion der Raw-Messages und des State-Objekts. Standard-Debugger und Logging-Mechanismen greifen unmittelbar.

Allerdings verschiebt dieser Ansatz die gesamte Verantwortung auf den Entwickler. Themen wie das Parsen der oft inkonsistenten LLM-Antworten, das Abfangen von API-Fehlern (Rate Limits, Timeouts), das Management der Retries und vor allem das Formatieren der Daten für verschiedene Modell-Provider müssen manuell implementiert werden. Dies führt bei wachsender Komplexität schnell zu einem hohen Wartungsaufwand, da Features, die in Frameworks "gratis" sind (z.B. Streaming, Caching), hier selbst gebaut werden müssen.

3.3 Einsatzszenario: Kritische Infrastruktur

Dieser Architekturstil ist ideal für hochkritische Produktionssysteme, bei denen Vorhersehbarkeit, Sicherheit und Auditierbarkeit wichtiger sind als eine schnelle Entwicklungszeit ("Time-to-Market"). Er eignet sich hervorragend für Microservices, die eine sehr spezifische, enge Aufgabe erfüllen müssen (z.B. Klassifizierung von Finanzdaten), ohne den Overhead einer großen Library mitzuschleppen. Zudem ist er die bevorzugte Wahl, wenn absolut keine Abhängigkeiten zu Drittanbieter-Code (außer dem SDK des Modellproviders) bestehen dürfen.

4. LangChain: Das Baukasten-Prinzip (Pipeline Architecture)

LangChain markierte historisch den ersten großen Schritt zur Demokratisierung der Entwicklung von LLM-Anwendungen und etablierte das fundamentale Konzept der "Chain" (Kette). Es fungierte als das "Klebeband", das die fragmentierte Welt der frühen LLM-APIs zusammenhielt und standardisierte Schnittstellen schuf [3].

4.1 Die LangChain Expression Language (LCEL) und DAGs

Die Architektur von LangChain basiert auf der Komposition und dem Fließband-Prinzip. Anstatt monolithische Skripte zu schreiben, bietet das Framework vorgefertigte Module: "Prompts" (Anweisungsschablonen), "Modelle" (Interfaces zu verschiedenen LLMs) und "Output-Parser" (die unstrukturierten Text in strukturierte Daten wandeln). Diese Bausteine werden mittels der LangChain Expression Language (LCEL) verbunden. LCEL nutzt eine deklarative Syntax, die stark an UNIX-Pipes (|) angelehnt ist, um den Datenfluss zu definieren. Die Daten fließen wie in einem industriellen Prozess von links nach rechts: Input | Prompt | Modell | Parser.

LangChain ist architektonisch primär auf DAGs (Directed Acyclic Graphs) ausgelegt - also gerichtete, zyklenfreie Graphen. Das bedeutet, der Informationsfluss ist linear und kennt keine Rücksprünge. Dies macht das Framework extrem effizient für Aufgaben, die eine klare Start- und Endsequenz haben, limitiert es jedoch in seiner Fähigkeit zur komplexen Problemlösung, die oft Iteration erfordert.

Dieses Diagramm visualisiert das "Fließband-Prinzip" (Pipeline-Architektur), bei dem Daten linear von einer Komponente zur nächsten fließen, ohne Rückschleifen (Directed Acyclic Graph).

Das folgende Beispiel zeigt, wie die im Text erwähnte Pipe-Syntax (|) in der Praxis aussieht. Wir erstellen eine Kette, die eine einfache Frage verarbeitet und das Ergebnis direkt in ein strukturiertes Format (JSON-ähnlich) parst.

1# Voraussetzungen: pip install langchain langchain-openai
2from langchain_openai import ChatOpenAI
3from langchain_core.prompts import ChatPromptTemplate
4from langchain_core.output_parsers import StrOutputParser
5
6# 1. Modell-Interface (Interface zu LLMs)
7model = ChatOpenAI(model="gpt-4o-mini")
8
9# 2. Prompt (Anweisungsschablone)
10prompt = ChatPromptTemplate.from_template(
11    "Du bist ein technischer Experte. Erkläre das Konzept von {thema} in einem kurzen Satz."
12)
13
14# 3. Output-Parser (Wandelt unstrukturierten Text in String um)
15parser = StrOutputParser()
16
17# 4. Die "Chain" - Das Herzstück (Baukasten-Prinzip via LCEL)
18# Hier sieht man die UNIX-Pipes | , die den DAG definieren
19chain = prompt | model | parser
20
21# Ausführung der Pipeline
22if __name__ == "__main__":
23    result = chain.invoke({"thema": "Directed Acyclic Graphs (DAG)"})
24    print(f"Ergebnis der Chain:\n{result}")
25

4.2 Die Dominanz im RAG-Sektor

Die größte Stärke von LangChain liegt in seiner enormen Integrationsdichte. Es existieren hunderte fertige Anbindungen ("Loaders") an Datenbanken, Dateisysteme (PDF, Notion, Slack), Suchmaschinen und Vektorspeicher. Dies hat LangChain zum De-facto-Standard für Retrieval Augmented Generation (RAG)gemacht [4]. In einem RAG-Szenario ist der Ablauf meist linear: "Lade Dokument, teile es in Chunks, erstelle Embeddings, suche relevante Stellen zur User-Frage, generiere Antwort". Für diese Pipeline-Architektur ist LangChain optimiert und unschlagbar effizient in der Implementierung.

4.3 Kritik und Limitationen

Die Kehrseite der Medaille ist die Debugging-Komplexität. Wenn eine Kette fehlschlägt, ist es aufgrund der tiefen Verschachtelung der "Runnables" oft schwer herauszufinden, in welchem Baustein der Fehler liegt. Das "Black-Box"-Problem wird hier im Tausch gegen Entwicklungsgeschwindigkeit in Kauf genommen. Kritiker bemängeln oft, dass einfache Aufgaben durch die Abstraktion unnötig kompliziert werden und Stack Traces schwer lesbar sind. Sobald bedingte Logik (Loops, komplexe If/Else-Verzweigungen) notwendig wird, wird die LCEL-Syntax oft sperrig und schwer verständlich, was den Übergang zu graphenbasierten Ansätzen notwendig macht.

5. LangGraph: Der intelligente Kreislauf (State Machine Architecture)

In der realen Welt sind Problemlösungsprozesse selten strikt linear. Ein menschlicher Experte schreibt einen Bericht nicht in einem Zug von A bis Z. Er erstellt einen Entwurf, prüft ihn, korrigiert Fehler, recherchiert fehlende Fakten nach und überarbeitet den Text. LangGraph erweitert das Konzept von LangChain, um genau diese zyklischen Arbeitsweisen abzubilden und markiert den Übergang von Pipelines zu Zustandsautomaten [5].

5.1 Graphentheorie als architektonisches Fundament

LangGraph modelliert KI-Anwendungen als Zustandsautomaten (Finite State Machines). Die Architektur betrachtet den Agenten als einen Graphen, bestehend aus drei Kernkomponenten:

1. Knoten (Nodes): Diese repräsentieren Arbeitsschritte oder Funktionen (z.B. "Recherchieren", "Schreiben", "Code ausführen"). Jeder Knoten führt eine spezifische Aufgabe aus und gibt ein Update für den Zustand zurück.
2. Kanten (Edges): Diese definieren den Kontrollfluss zwischen den Knoten.
3. Zustand (State): Ein zentrales Datenobjekt (oft ein TypedDict oder Pydantic Model), das den aktuellen Status der Anwendung hält. Jeder Knoten liest diesen Zustand und schreibt Änderungen hinein.

Der entscheidende architektonische Durchbruch ist die Einführung von Zyklen (Loops). Der Graph kann an Kreuzungen ("Conditional Edges") basierend auf dem aktuellen Zustand entscheiden, zu einem vorherigen Knoten zurückzukehren. Dies war in der DAG-Architektur von LangChain nicht möglich.

Dieses Beispiel implementiert einen minimalen "Writer-Reviewer"-Graphen. Ein Agent erstellt einen Text, und ein "Kritiker"-Knoten entscheidet, ob er gut genug ist oder überarbeitet werden muss.

1from typing import TypedDict, Annotated, List
2from langgraph.graph import StateGraph, END
3
4# 1. Definition des Zustands (State)
5class AgentState(TypedDict):
6    content: str
7    feedback: str
8    iterations: int
9
10# 2. Definition der Knoten (Nodes)
11def designer_node(state: AgentState):
12    print("--- DESIGNER: Erstelle Entwurf ---")
13    content = state.get("content", "")
14    if not content:
15        content = "Das ist ein erster Entwurf über KI-Systeme."
16    else:
17        content += " (Überarbeitet basierend auf Feedback)"
18    
19    return {"content": content, "iterations": state.get("iterations", 0) + 1}
20
21def reviewer_node(state: AgentState):
22    print("--- REVIEWER: Prüfe Qualität ---")
23    if state["iterations"] < 2:
24        return {"feedback": "Bitte mehr Details hinzufügen."}
25    return {"feedback": "Gut genug."}
26
27# 3. Logik für bedingte Kanten (Conditional Edges)
28def should_continue(state: AgentState):
29    if state["feedback"] == "Gut genug.":
30        return "end"
31    return "continue"
32
33# 4. Den Graphen zusammenbauen
34workflow = StateGraph(AgentState)
35
36# Knoten hinzufügen
37workflow.add_node("designer", designer_node)
38workflow.add_node("reviewer", reviewer_node)
39
40# Kanten definieren
41workflow.set_entry_point("designer")
42workflow.add_edge("designer", "reviewer")
43
44# Bedingte Kante: Reviewer -> Designer ODER Ende
45workflow.add_conditional_edges(
46    "reviewer",
47    should_continue,
48    {
49        "continue": "designer",
50        "end": END
51    }
52)
53
54# Graph kompilieren
55app = workflow.compile()
56
57# Testlauf
58inputs = {"content": "", "iterations": 0}
59for output in app.stream(inputs):
60    print(output)
61

5.2 Reflexion, Selbstkorrektur und Human-in-the-Loop

Diese zyklische Struktur ermöglicht kognitive Muster wie "Self-Reflection". Ein Agent kann eine Antwort generieren, diese in einem nachfolgenden Schritt selbst bewerten (z.B. "Ist der generierte Code syntaktisch korrekt?" oder "Ist die Antwort faktisch belegt?") und bei negativem Ergebnis den Prozessschritt wiederholen. Dies führt zu einer signifikant höheren Robustheit gegenüber Fehlern.

Ein weiteres Alleinstellungsmerkmal ist die Persistenzschicht ("Checkpointer"). LangGraph speichert den Zustand nach jedem Schritt. Dies ermöglicht nicht nur Fehlertoleranz (Wiederaufnahme nach Absturz), sondern auch Human-in-the-Loop-Workflows. Der Graph kann an einem bestimmten Punkt pausieren ("Breakpoint"), auf eine menschliche Genehmigung warten (z.B. vor dem Senden einer E-Mail oder einer Finanztransaktion) und dann mit dem genehmigten oder korrigierten Zustand fortfahren.

5.3 Einsatzszenario: Komplexe Agenten

LangGraph ist der Industriestandard für komplexe Enterprise-Agenten, Coding-Assistenten und Kundensupport-Bots, die autonom Probleme lösen müssen. Es wird überall dort eingesetzt, wo die Logik nicht linear ist und der Agent "nachdenken" und seine Strategie während der Laufzeit anpassen muss.

6. AI Agentic Systems: Rollenbasierte Teams und Orchestrierung

Während LangGraph die technische Ebene der Zustandsverwaltung adressiert, fokussieren sich Ansätze wie "AI Agentic Systems" auf die semantische Ebene der Zusammenarbeit. Anstatt einen einzelnen monolithischen Agenten zu programmieren, wird ein Team von spezialisierten Agenten erstellt. Dies reflektiert die menschliche Arbeitsorganisation, in der komplexe Projekte selten von Einzelpersonen, sondern von Teams mit diversifizierten Fähigkeiten gelöst werden.

6.1 CrewAI: Das rollenbasierte Framework

CrewAI abstrahiert die Teamdynamik durch ein starkes Metaphernsystem [6]. Agenten werden wie Mitarbeiter definiert: Sie erhalten eine Rolle (z.B. "Senior Research Analyst"), ein Ziel (Goal) und eine Backstory(Persönlichkeit/Lebenslauf).

• Architektur: Das Framework fungiert als Orchestrator. Es teilt Aufgaben (Tasks) zu und managt die Kommunikation. Wenn ein "Researcher"-Agent Ergebnisse liefert, werden diese automatisch als Kontext an den "Writer"-Agenten weitergegeben. Prozesse können sequenziell oder hierarchisch organisiert werden.
• Stärken: Die Definition über natürliche Sprache und Rollen ist extrem intuitiv und senkt die Einstiegshürde massiv. Agenten können autonom Aufgaben delegieren und kollaborieren.
• Schwächen: Der hohe Token-Verbrauch ist kritisch. Die umfangreichen "Backstories" und System-Prompts, die bei jedem Schritt mitgeschickt werden, erhöhen die Kosten und Latenz. Zudem neigen solche Systeme in unstrukturierten Chats zu Instabilität und "Black-Box"-Verhalten, da schwer nachzuvollziehen ist, warum ein Agent eine bestimmte Entscheidung getroffen hat.

Das folgende Diagramm verdeutlicht, wie der Orchestrator die Rollen, Ziele und Backstories nutzt, um Aufgaben in einer sequentiellen Kette abzuarbeiten.

Dieses Beispiel zeigt die Implementierung der im Text beschriebenen Konzepte (Rolle, Ziel, Backstory) unter Verwendung des crewai Frameworks.

1import os
2from crewai import Agent, Task, Crew, Process
3
4# 1. Definition der Agenten mit spezifischen Rollen und Persönlichkeiten
5researcher = Agent(
6    role='Senior Research Analyst',
7    goal='Finde die neuesten Trends im Bereich KI-Agenten 2024',
8    backstory="""Du bist ein erfahrener Analyst mit einem Auge für 
9    disruptive Technologien. Dein Schreibstil ist präzise und faktenorientiert.""",
10    verbose=True,
11    allow_delegation=False
12)
13
14writer = Agent(
15    role='Content Strategist',
16    goal='Erstelle einen leicht verständlichen Blogpost basierend auf der Recherche',
17    backstory="""Du bist darauf spezialisiert, komplexe technische Themen 
18    für ein breites Publikum aufzubereiten, ohne dabei an Tiefe zu verlieren.""",
19    verbose=True,
20    allow_delegation=False
21)
22
23# 2. Definition der Aufgaben (Tasks)
24task_research = Task(
25    description='Analysiere die Top 3 Frameworks für Multi-Agenten-Systeme.',
26    expected_output='Ein detaillierter Bericht zu CrewAI, LangGraph und AutoGPT.',
27    agent=researcher
28)
29
30task_write = Task(
31    description='Schreibe einen Blogartikel über die Vorteile von rollenbasierten KIs.',
32    expected_output='Ein Blogpost mit 500 Wörtern im Markdown-Format.',
33    agent=writer,
34    context=[task_research] # Hier wird das Ergebnis von Task 1 als Kontext übergeben
35)
36
37# 3. Die Crew orchestriert die Zusammenarbeit
38my_crew = Crew(
39    agents=[researcher, writer],
40    tasks=[task_research, task_write],
41    process=Process.sequential, # Sequenzieller Ablauf wie im Text beschrieben
42    full_output=True,
43    verbose=True
44)
45
46# Start des Prozesses
47result = my_crew.start()
48
49print("######################")
50print("ERGEBNIS DES TEAMS:")
51print(result)
52

6.2 LangGraph Supervisor-Modell

Eine strukturierte Alternative zum oft freieren Chat von CrewAI ist das Supervisor-Modell innerhalb von LangGraph. Hier wird ein zentraler Router-Agent (der Supervisor) eingesetzt, der als Manager fungiert [7].

• Funktionsweise: Der Supervisor erhält die Anfrage, analysiert sie und entscheidet, welcher Spezialist (Knoten im Graphen) zuständig ist. Er delegiert die Arbeit, und nach Abschluss kehrt der Kontrollfluss zum Supervisor zurück. Dieser prüft das Ergebnis und entscheidet, ob die Aufgabe erledigt ist oder ein weiterer Spezialist (z.B. für Lektorat) benötigt wird.
• Vorteile:
  • Determinismus: Der Entwickler legt im Graphen genau fest, wer mit wem kommunizieren darf.
  • Zustandskontrolle: Der globale "State" enthält den gesamten Verlauf, was Auditierbarkeit gewährleistet.
  • Modularität: Neue Spezialisten können einfach als Knoten hinzugefügt werden, ohne die Gesamtlogik neu schreiben zu müssen.

Dieses Diagramm verdeutlicht den zyklischen Prozess, bei dem die Kontrolle nach jedem Arbeitsschritt zum Supervisor zurückkehrt, bis das Ziel erreicht ist.

Dieses Beispiel skizziert, wie ein Supervisor-Modell strukturell mit langgraph und langchain aufgebaut wird. Es zeigt die Orchestrierung zwischen einem "Researcher" und einem "Writer".

1import operator
2from typing import Annotated, List, TypedDict, Union
3
4from langchain_openai import ChatOpenAI
5from langgraph.graph import StateGraph, END
6from langchain_core.messages import BaseMessage, HumanMessage
7
8# 1. Definition des Zustands (State)
9class AgentState(TypedDict):
10    # Der Verlauf der gesamten Kommunikation
11    messages: Annotated[List[BaseMessage], operator.add]
12    # Wer ist als nächstes dran?
13    next: str
14
15# 2. Die Worker-Knoten (Spezialisten)
16def researcher_node(state: AgentState):
17    # Simuliert eine Recherche
18    last_message = state['messages'][-1].content
19    return {"messages": [HumanMessage(content=f"Recherche-Ergebnis zu: {last_message}", name="Researcher")]}
20
21def writer_node(state: AgentState):
22    # Simuliert das Schreiben eines Textes
23    return {"messages": [HumanMessage(content="Hier ist der ausformulierte Artikel basierend auf der Recherche.", name="Writer")]}
24
25# 3. Der Supervisor-Knoten (Entscheidungslogik)
26def supervisor_node(state: AgentState):
27    llm = ChatOpenAI(model="gpt-4o")
28    # In der Realität würde hier ein LLM entscheiden, wer als nächstes dran ist
29    # Für dieses Beispiel nutzen wir eine einfache Logik:
30    if len(state['messages']) < 2:
31        return {"next": "Researcher"}
32    elif "Researcher" in state['messages'][-1].name:
33        return {"next": "Writer"}
34    else:
35        return {"next": "FINISH"}
36
37# 4. Graph-Erstellung
38workflow = StateGraph(AgentState)
39
40# Knoten hinzufügen
41workflow.add_node("Supervisor", supervisor_node)
42workflow.add_node("Researcher", researcher_node)
43workflow.add_node("Writer", writer_node)
44
45# Kanten definieren (Das Herzstück der Orchestrierung)
46workflow.add_edge("Researcher", "Supervisor")
47workflow.add_edge("Writer", "Supervisor")
48
49# Bedingte Kanten vom Supervisor aus
50workflow.add_conditional_edges(
51    "Supervisor",
52    lambda x: x["next"],
53    {
54        "Researcher": "Researcher",
55        "Writer": "Writer",
56        "FINISH": END
57    }
58)
59
60# Startpunkt setzen
61workflow.set_entry_point("Supervisor")
62
63# Graph kompilieren
64app = workflow.compile()
65
66# Testlauf
67inputs = {"messages": [HumanMessage(content="Schreibe einen Blogpost über Quantencomputer.")]}
68for output in app.stream(inputs):
69    print(output)
70

6.3 Flexible Graph-Topologien: Dezentrale und Custom-Orchestrierung

Während der Supervisor eine hierarchische Struktur erzwingt, liegt die eigentliche Stärke von LangGraph in seiner Unvoreingenommenheit gegenüber der Topologie. Entwickler sind nicht auf das Manager-Modell beschränkt, sondern können dezentrale Netzwerke oder spezifische Pipelines entwerfen.

Funktionsweise: In diesem Modus existiert kein zentraler Entscheider. Stattdessen wird die Logik der Aufgabenübergabe direkt in die „Edges“ (Kanten) des Graphen programmiert. Ein Agent kann das Ergebnis seiner Arbeit direkt an den nächsten Spezialisten weiterreichen (Chaining) oder basierend auf einer Bedingung entscheiden, welcher Pfad als Nächstes eingeschlagen wird.

Vorteile:

• Geringere Latenz & Kosten: Da kein Supervisor-LLM bei jedem Zwischenschritt analysieren muss, wer als Nächstes dran ist, spart man Token und Zeit.
• Explizite Workflows: Für Prozesse mit einer klaren Abfolge (z. B. Extraktion → Validierung → Archivierung) ist eine direkte Verkettung effizienter und weniger fehleranfällig als eine dynamische Zuweisung.
• Zustandsgesteuerte Zyklen: Man kann präzise definieren, dass ein Agent seine Aufgabe so lange wiederholt (Self-Correction), bis eine technische Bedingung erfüllt ist, ohne dass ein menschlicher oder KI-Manager eingreifen muss.

Vergleich der Ansätze: In LangGraph kann ein System somit wie ein Uhrwerk (fest definierte Pfade), ein Team (Supervisor) oder ein freies Netzwerk (Peer-to-Peer) fungieren. Dies macht es zum präzisesten Werkzeug für komplexe Enterprise-Anwendungen, bei denen Vorhersehbarkeit wichtiger ist als die rein intuitive Aufgabenverteilung von Frameworks wie CrewAI.

In diesem Diagramm siehst du, dass der Datenfluss linear startet, aber bei Qualitätsmängeln eine direkte Feedback-Schleife zwischen Editor und Writer entsteht - ohne Umweg über einen Supervisor.

In diesem Code nutzen wir add_edge für feste Übergänge und add_conditional_edges für die Qualitätskontrolle des Editors.

1import operator
2from typing import Annotated, TypedDict, Literal
3from langgraph.graph import StateGraph, END
4
5# 1. State Definition
6class GraphState(TypedDict):
7    # Das Dokument, an dem gearbeitet wird
8    content: str
9    # Recherche-Notizen
10    research_notes: str
11    # Anzahl der bisherigen Überarbeitungen (um Endlosschleifen zu vermeiden)
12    revision_count: int
13
14# 2. Knoten-Funktionen (Nodes)
15def researcher(state: GraphState):
16    print("--- RESEARCHER ARBEITET ---")
17    return {
18        "research_notes": "KI-Trends 2026: Agentic Workflows und LangGraph Flexibilität.",
19        "revision_count": 0
20    }
21
22def writer(state: GraphState):
23    print("--- WRITER ARBEITET ---")
24    notes = state["research_notes"]
25    count = state["revision_count"]
26    return {
27        "content": f"Blogpost (Version {count+1}): Basierend auf {notes}...",
28        "revision_count": count + 1
29    }
30
31def editor(state: GraphState):
32    print("--- EDITOR PRÜFT ---")
33    # Simulierte Logik: Erst nach der 2. Überarbeitung ist es 'perfekt'
34    if state["revision_count"] < 2:
35        return "re-write"
36    return "accept"
37
38# 3. Graph-Konstruktion
39workflow = StateGraph(GraphState)
40
41# Knoten hinzufügen
42workflow.add_node("researcher", researcher)
43workflow.add_node("writer", writer)
44
45# Kanten definieren
46workflow.set_entry_point("researcher")
47
48# Direkter Übergang: Researcher schickt Daten IMMER sofort zum Writer
49workflow.add_edge("researcher", "writer")
50
51# Bedingter Übergang: Der Editor-Check entscheidet über den Pfad
52workflow.add_conditional_edges(
53    "writer",
54    editor, # Die Funktion 'editor' entscheidet über den nächsten Schritt
55    {
56        "re-write": "writer", # Zurück zum Writer (Loop)
57        "accept": END         # Prozess beenden
58    }
59)
60
61# Kompilieren
62app = workflow.compile()
63
64# Testlauf
65for output in app.stream({"content": "", "research_notes": "", "revision_count": 0}):
66    print(output)
67

6.4 Holarchien vs. Hierarchien: Ein theoretischer Exkurs

In der fortgeschrittenen Betrachtung agentischer Systeme zeichnet sich eine Debatte zwischen hierarchischen und holarchischen Strukturen ab. Während Hierarchien (wie das Supervisor-Modell) klare Befehlsketten bieten, argumentieren Forscher, dass Holarchien - in denen jede Einheit (Holon) sowohl ein Ganzes als auch ein Teil ist - besser für adaptive Systeme geeignet sind [8]. In einer Holarchie adaptiert sich jeder Agent (Holon) autonom an Kontextänderungen, ohne auf zentrale Befehle zu warten. Dies ermöglicht eine höhere Flexibilität in dynamischen Umgebungen, in denen sich die Problemstruktur während der Laufzeit ändert ("Contextual Fluidity"). Dies steht im Gegensatz zu starren Hierarchien, die oft zum Flaschenhals werden, wenn der zentrale Manager überlastet ist oder den lokalen Kontext nicht vollständig erfassen kann.[9]

In diesem Modell fließen Befehle von oben nach unten. Der Zentrale Manager ist der Flaschenhals: Alle Informationen müssen über ihn laufen, und Agenten handeln nur auf Anweisung.

Hier ist jeder Agent ein Holon - also gleichzeitig ein eigenständiges Ganzes und Teil eines größeren Systems. Es gibt keine starre Top-Down-Kontrolle; stattdessen kommunizieren Holons autonom und passen sich dem Kontext an.

6.4.1 Zusammenfassung der Unterschiede

6.5 Pure Python Hand-off Architektur

Für maximale Performance kann das Team-Konzept auch ohne Frameworks über eine Hand-off-Logik realisiert werden. Jeder Agent ist hierbei eine Klasse oder Funktion. Das Ergebnis einer Funktion dient als Input für die nächste. Dies eliminiert Abhängigkeiten und maximiert die Ausführungsgeschwindigkeit, erfordert jedoch das manuelle Schreiben der gesamten Orchestrierungslogik. Dies ist oft der Weg für Hochleistungsanwendungen, bei denen jede Millisekunde Latenz zählt.

7. Event-Driven & Declarative Architectures

Parallel zu den graphenbasierten und linearen Ansätzen etablieren sich Paradigmen, die den Fokus auf Ereignisse (Events) und Deklaration legen, um spezifische Probleme der Skalierbarkeit und Optimierung zu lösen.

7.1 LlamaIndex Workflows: Event-Driven Architecture

LlamaIndex, ursprünglich bekannt als Bibliothek für Daten-Ingestion und RAG, hat mit "Workflows" ein ereignisgesteuertes Modell eingeführt [10]. Anstatt imperativ "Schritt A dann Schritt B" zu programmieren, definiert man: "Wenn Ereignis X eintritt, führe Schritt Y aus".

• Mechanismus: Komponenten emittieren Events (z.B. RetrievalEvent oder ReasoningEvent), auf die andere Komponenten asynchron reagieren (Listener-Pattern).
• Vorteil: Dies entkoppelt die Komponenten maximal und ermöglicht hochflexible, asynchrone Systeme. Es ist ideal für komplexe RAG-Szenarien, bei denen z.B. mehrere Dokumente parallel verarbeitet werden müssen und der nächste Schritt erst startet, wenn alle Events eingetroffen sind. Es erlaubt eine natürliche Modellierung von Parallelität, die in starren Graphen oft schwerfällig wirkt.

1from llama_index.core.workflow import Workflow, step, StartEvent, StopEvent, Event
2
3class RechercheEvent(Event):
4    inhalt: str
5
6class MeinWorkflow(Workflow):
7    @step
8    async def schritt_1(self, ev: StartEvent) -> RechercheEvent:
9        # Reagiert auf den Start und "feuert" ein RechercheEvent
10        return RechercheEvent(inhalt="KI-Daten gefunden")
11
12    @step
13    async def schritt_2(self, ev: RechercheEvent) -> StopEvent:
14        # Wartet auf ein RechercheEvent
15        return StopEvent(result=f"Bericht über: {ev.inhalt}")
16

7.2 DSPy: Declarative Self-Improving Python

DSPy (entwickelt an der Stanford University) verfolgt einen radikal anderen Ansatz [11]: Programmieren statt Prompten. Die zentrale These ist, dass manuelle Prompt-Optimierung ("Prompt Engineering") fragil, nicht skalierbar und fehleranfällig ist.

• Architektur: Entwickler definieren Signaturen (Input/Output-Typen, z.B. Frage → Antwort) und Module. Ein "Optimizer" (Teleprompter) kompiliert diesen Code dann in optimale Prompts.
• Mechanismus: Der Optimizer führt Testläufe durch, wählt automatisch die besten Few-Shot-Beispiele aus und passt die Instruktionen an, um eine definierte Metrik (z.B. Genauigkeit) zu maximieren.
• Implikation: Das System optimiert sich selbst. Wenn sich das zugrundeliegende LLM ändert (z.B. Wechsel von GPT-4 auf Llama-3), muss der Prompt nicht manuell umgeschrieben werden; der Compiler wird einfach neu ausgeführt ("Re-Compile"). Dies verspricht höchste Präzision und Robustheit und verschiebt den Fokus von der "Kunst" des Promptens zur "Ingenieurskunst" der Systemdefinition.

1import dspy
2
3class BeantworteFrage(dspy.Signature):
4    """Beantworte Fragen kurz und präzise."""
5    frage = dspy.InputField()
6    antwort = dspy.OutputField()
7
8# DSPy findet im Hintergrund den optimalen Prompt für dieses Ziel
9rechner = dspy.ChainOfThought(BeantworteFrage)
10print(rechner(frage="Warum ist der Himmel blau?").antwort)
11

8. Long-Running AI Agentic Systems: Persistenz und Gedächtnis

Ein fundamentaler Unterschied zwischen einem Chatbot und einem echten agentischen System ist die Lebensdauer des Prozesses. Transiente Agenten existieren nur für die Dauer eines Requests. Langlebige Agenten ("Long-Running Systems") müssen über Tage oder Wochen an einer Aufgabe arbeiten, "schlafen" können und nach einem Neustart exakt wissen, wo sie waren. Sie müssen robust gegenüber Infrastrukturausfällen sein.

8.1 State-Based Persistence (LangGraph)

Die Architektur für Langlebigkeit in LangGraph basiert auf Checkpoints. Nach jedem einzelnen atomaren Schritt im Graphen wird der gesamte Zustand (State) serialisiert und in einer Datenbank (z.B. SQLite, Postgres) gespeichert.

• Resiliency: Wenn der Server abstürzt oder neu gestartet wird, kann der Agent anhand der thread_id den letzten validen Zustand laden und fortfahren, als wäre nichts geschehen. Es gehen keine Fortschritte verloren.
• Time Travel: Diese Architektur erlaubt es Entwicklern sogar, in der Zeit zurückzureisen. Man kann den Zustand an einem früheren Punkt laden, ihn manuell korrigieren (z.B. eine halluzinierte Antwort editieren oder einen falschen Tool-Output überschreiben) und den Agenten von dort aus neu starten ("Replay"). Dies ist ein mächtiges Werkzeug für Debugging und Human-in-the-Loop-Korrekturen.

Das Diagramm zeigt, wie LangGraph nach jedem Schritt den Zustand in einem Checkpoint-Speicher ablegt. Dies ermöglicht die Ausfallsicherheit (Resiliency) und das Zurückspringen in der Historie (Time Travel).

In diesem Beispiel nutzen wir den MemorySaver (einen In-Memory-Checkpointer). Für produktive Systeme würde man diesen einfach durch einen SqliteSaver oder PostgresSaver ersetzen.

1import uuid
2from typing import TypedDict, Annotated
3from langgraph.graph import StateGraph, START, END
4from langgraph.checkpoint.memory import MemorySaver
5
6# 1. Definition des Zustands (State)
7class AgentState(TypedDict):
8    input: str
9    steps: list[str]
10
11# 2. Definition der Knoten (Nodes)
12def research_step(state: AgentState):
13    print("--- Führe Recherche aus ---")
14    return {"steps": state["steps"] + ["Recherche abgeschlossen"]}
15
16def writing_step(state: AgentState):
17    print("--- Schreibe Bericht ---")
18    return {"steps": state["steps"] + ["Bericht erstellt"]}
19
20# 3. Graph-Konstruktion
21workflow = StateGraph(AgentState)
22workflow.add_node("research", research_step)
23workflow.add_node("writer", writing_step)
24
25workflow.add_edge(START, "research")
26workflow.add_edge("research", "writer")
27workflow.add_edge("writer", END)
28
29# 4. Persistence: Checkpointer hinzufügen
30checkpointer = MemorySaver()
31app = workflow.compile(checkpointer=checkpointer)
32
33# 5. Ausführung mit einer thread_id
34config = {"configurable": {"thread_id": "projekt-123"}}
35
36print("Start der ersten Phase...")
37initial_input = {"input": "Marktanalyse KI", "steps": []}
38app.invoke(initial_input, config)
39
40# --- Simulation: System-Neustart oder spätere Fortsetzung ---
41print("\n--- Simulation: Fortsetzung nach Pause ---")
42# Wir nutzen dieselbe thread_id, um den Zustand zu laden
43current_state = app.get_state(config)
44print(f"Letzter bekannter Zustand: {current_state.values['steps']}")
45
46# Time Travel / Manuelle Korrektur
47# Wir könnten hier den Zustand bearbeiten, bevor wir weitermachen
48# app.update_state(config, {"steps": ["Korrektur: Recherche war unvollständig"]})
49

8.2 Knowledge-Based Persistence (CrewAI)

CrewAI nähert sich dem Thema über ein hierarchisches Speichersystem, nicht primär über technische State-Serialization auf Graphen-Ebene.

• Short-Term Memory: Speichert den Kontext der aktuellen Ausführung (RAG), um während der Diskussion relevante Informationen parat zu haben.
• Long-Term Memory: = Speichert Erkenntnisse dauerhaft in einer Datenbank, sodass der Agent auch nach einem kompletten Neustart des Systems weiß, was er in früheren Sessions gelernt hat.
• Entity Memory: Speichert spezifische Informationen über Entitäten (z.B. Nutzer, Projekte), um Konsistenz zu wahren.
• Human-in-the-Loop: Durch Features wie human_input=True kann ein Agent pausieren und auf Feedback warten. Da der Prozessstatus jedoch oft im Arbeitsspeicher gehalten wird, ist die technische Robustheit gegenüber Abstürzen hier oft geringer als bei der Datenbank-basierten State-Machine von LangGraph, die jeden Schritt persistiert.

Dieses Diagramm verdeutlicht, wie CrewAI die verschiedenen Speicherebenen nutzt, um Persistenz zu simulieren und Informationen über verschiedene Ausführungen hinweg zu behalten.

In CrewAI wird die Persistenz durch das Setzen des Flags memory=True aktiviert. Um dies in einer produktiven Umgebung "Long-Running" zu machen, würden die Daten normalerweise in einer Vektordatenbank (wie ChromaDB oder Pinecone) gespeichert, die CrewAI im Hintergrund verwaltet.

1from crewai import Agent, Task, Crew, Process
2
3# Beispiel: Ein Agent, der aus vergangenen Interaktionen lernt
4# Hierfür ist die Installation von 'crewai' und 'langchain' nötig.
5
6# 1. Agenten definieren
7researcher = Agent(
8    role='Research Specialist',
9    goal='Analysiere die neuesten Trends in {topic} und behalte wichtige Fakten im Gedächtnis.',
10    backstory='Du bist ein Experte für Marktforschung und erinnerst dich an frühere Analysen.',
11    verbose=True,
12    allow_delegation=False,
13    # Aktiviert das Speichersystem (Short-Term, Long-Term, Entity)
14    memory=True
15)
16
17# 2. Task definieren
18research_task = Task(
19    description='Identifiziere 3 Kerntrends im Bereich {topic}. Frage den Nutzer nach Feedback, bevor du das Ergebnis finalisierst.',
20    expected_output='Ein detaillierter Bericht der Top 3 Trends.',
21    agent=researcher,
22    # Human-in-the-Loop: Pausiert die Ausführung für Nutzer-Input
23    human_input=True
24)
25
26# 3. Die Crew zusammenstellen
27my_crew = Crew(
28    agents=[researcher],
29    tasks=[research_task],
30    process=Process.sequential,
31    # Globale Aktivierung des Speichers für die gesamte Crew
32    memory=True,
33    verbose=True
34)
35
36# 4. Ausführung starten
37# Bei einem Neustart des Systems mit derselben Datenbank würde der Agent
38# auf das Long-Term Memory zugreifen können.
39result = my_crew.kickoff(inputs={'topic': 'Künstliche Intelligenz 2026'})
40
41print("######################")
42print("FINAL RESULT:")
43print(result)
44

8.3 Die "Memory Wall" und Herausforderungen

Eine zentrale Herausforderung für langlebige Systeme ist die "Memory Wall" - die Begrenzung des Kontextfensters und die Kosten für Token. Da nicht die gesamte Historie von Wochen in einen Prompt passt, müssen Architekturen Strategien wie Summarization (periodische Zusammenfassung alter Zustände) oder Vektor-Einbettung (Embeddings) nutzen, um relevante Erinnerungen dynamisch zu laden. Dies erfordert eine ausgeklügelte Speicher-Architektur, die über reine Datenbank-Persistenz hinausgeht und semantische Relevanz bewertet.

8.4 Zusammenfassender Vergleich der langlebigen Architekturen

Mit dieser Umstellung auf CrewAI wird deutlich, dass "Long-Running" in der KI-Welt zwei Gesichter hat: Das technische Einfrieren eines Zustands (LangGraph) und das kontinuierliche Lernen und Warten auf den Menschen (CrewAI).

9. Standardisierte Protokolle: Die Zukunft der Interoperabilität

Damit Agenten nicht in isolierten Silos operieren, entstehen Standards für die Kommunikation. Das Jahr 2026 ist geprägt vom Kampf um diese Protokolle, die das Rückgrat eines "Internet of Agents" bilden sollen.

9.1 Model Context Protocol (MCP)

Das von Anthropic entwickelte MCP ist ein offener Standard, der die Anbindung von Datenquellen an KI-Modelle revolutioniert [12]. Die Spezifikation wurde maßgeblich von David Soria Parra und Justin Spahr-Summers verfasst.

• Problem: Bisher musste für jedes Tool (Google Drive, Slack, SQL) eine eigene Integration für jeden Agenten geschrieben werden (M x N Problem).
• Lösung: MCP definiert eine universelle Schnittstelle (basierend auf JSON-RPC). Ein "MCP Server" stellt Daten oder Tools bereit. Jeder "MCP Client" (z.B. Claude Desktop, IDEs wie Cursor, oder eigene Agenten) kann diese sofort nutzen.
• Analogie: Es ist das "USB-C für KI-Anwendungen". Einmal standardisiert, passt der Stecker überall. Dies ermöglicht es Entwicklern, einen Konnektor einmal zu schreiben und ihn über alle MCP-kompatiblen Plattformen hinweg zu nutzen.

1from fastapi import FastAPI
2
3app = FastAPI()
4
5# Ein standardisierter Endpunkt, der Tools für Agenten beschreibt
6@app.get("/tools")
7async def list_tools():
8    return {
9        "tools": [{
10            "name": "query_database",
11            "description": "Sucht in der Kundendatenbank",
12            "input_schema": {"type": "object", "properties": {"query": {"type": "string"}}}
13        }]
14    }
15
16@app.post("/call")
17async def call_tool(tool_name: str, arguments: dict):
18    # Standardisierte Ausführung
19    return {"status": "success", "data": "Ergebnis aus DB"}
20

9.2 Agent-to-Agent Protocol (A2A)

Während MCP die vertikale Verbindung (Agent zu Daten/Tools) löst, adressiert das von Google initiierte A2A-Protokoll die horizontale Kollaboration (Agent zu Agent). Es wurde im April 2025 eingeführt.

• Konzept: Wie findet ein Reise-Agent einen Kalender-Agenten, ohne dass sie explizit verknüpft wurden? A2A definiert Mechanismen zur Discovery. Jeder Agent veröffentlicht eine agent.json (ähnlich einer robots.txt oder Visitenkarte), die seine Fähigkeiten beschreibt.
• Kollaboration: Agenten können sich gegenseitig beauftragen, Aufgaben aushandeln und Ergebnisse austauschen, ohne die interne Implementierung des anderen zu kennen. Dies ermöglicht dynamische Ökosysteme, in denen Agenten ad-hoc Teams bilden können.
• Mechanismen: Das Protokoll nutzt Standard-Webtechnologien (HTTP, JSON) und unterstützt sowohl synchrone REST-Calls als auch asynchrone Webhooks für langlebige Aufgaben.

1from fastapi import FastAPI
2from pydantic import BaseModel
3
4app = FastAPI()
5
6# 1. Agent Card Definition
7@app.get("/.well-known/agent.json")
8async def get_agent_card():
9    return {
10        "name": "GlobalResearchBot",
11        "description": "Spezialist für Websuche und Zusammenfassung",
12        "endpoints": {"execute": "/api/v1/execute"},
13        "capabilities": ["web_search", "summarization"]
14    }
15
16# 2. Implementierung der Fähigkeiten
17class TaskRequest(BaseModel):
18    capability: str
19    input_data: str
20
21@app.post("/api/v1/execute")
22async def execute_task(request: TaskRequest):
23    if request.capability == "web_search":
24        # Logik für Websuche
25        return {"result": f"Suche nach {request.input_data} erfolgreich."}
26    
27    elif request.capability == "summarization":
28        # Logik für Zusammenfassung
29        return {"result": f"Zusammenfassung von {request.input_data[:20]}..."}
30    
31    return {"error": "Capability not supported"}
32

9.3 Vergleich der Protokolle MCP und A2A

10. Fazit und Strategische Empfehlungen

Die Wahl der Architektur ist keine reine Geschmacksfrage, sondern eine fundamentale strategische Entscheidung, die über Skalierbarkeit, Wartbarkeit und Erfolg eines KI-Projekts bestimmt.

10.1 Vergleichende Entscheidungsmatrix der Architekturen

10.2 Strategischer Ausblick

Für Unternehmen und Entwickler lassen sich folgende Empfehlungen ableiten:

1. Einsteiger & einfaches RAG: Nutzen Sie LangChain. Es bietet den schnellsten Weg zum Ziel für Standardaufgaben, bei denen Dokumentenverarbeitung im Vordergrund steht.
2. Prozess-Automatisierung & Enterprise: Nutzen Sie LangGraph. Die Kontrolle über Zyklen, Persistenz ("Time Travel") und Fehlerbehandlung ist für geschäftskritische Anwendungen unverzichtbar. Es ist das robusteste Framework für langlebige Prozesse.
3. Kreative Teams & Content: eignet sich hervorragend für explorative Aufgaben und Brainstorming, bei denen die Interaktion verschiedener "Persönlichkeiten" einen Mehrwert bietet und die strikte Reproduzierbarkeit sekundär ist.
4. Datenintensive Workflows: Für asynchrone, ereignisgesteuerte Prozesse ist LlamaIndex die erste Wahl.
5. Interoperabilität: Setzen Sie auf Standards. Bauen Sie keine proprietären Tool-Integrationen mehr, sondern entwickeln Sie MCP-Server. Bereiten Sie Ihre Agenten auf A2A vor, um zukunftssicher zu sein und an agentischen Netzwerken teilnehmen zu können.

Der Trend geht eindeutig weg von starren Skripten hin zu adaptiven, langlebigen Systemen. Die Architektur der Zukunft ist nicht mehr eine einzelne Pipeline, sondern ein Netzwerk aus spezialisierten, autonomen Knoten, die über standardisierte Protokolle kommunizieren und in der Lage sind, ihre eigenen Fehler durch Reflexion zu korrigieren. Die "Magie" der KI liegt nicht mehr nur im Modell, sondern in der Struktur, die wir ihm geben - dem "Reasoning Loop", dem Gedächtnis und der Orchestrierung.

Weitere Beiträge

• KI-Agenten 01 - Mehr als nur Automatisierung: Entwurf kognitiver Architekturen für KI-Agenten
• KI-Agenten 02 - Das Architekturspektrum agentischer Systeme
• KI-Agenten 03 - Selbstreflexion in Agentischen Systemen