Hey zusammen, Leo hier von agntdev.com! Heute möchte ich über etwas sprechen, das still und leise meine Herangehensweise beim Erstellen von Agenten verändert hat: der Aufstieg spezialisierter SDKs. Nicht einfach irgendwelche SDKs, sondern die, die dafür entwickelt wurden, die Orchestrierung komplexer Agentenverhaltensweisen weniger kopflastig und mehr zu einem fließenden Prozess zu machen.
Mein Agenten-Entwicklungsworkflow fühlte sich lange Zeit so an, als würde ich ständig das Rad neu erfinden. Ich hatte eine brillante Idee für einen Agenten, der mit ein paar APIs kommunizieren, Entscheidungen treffen und vielleicht sogar aus seinen Interaktionen lernen musste. Dann verbrachte ich Tage, manchmal Wochen, nur damit, das grundlegende Gerüst aufzubauen: Zustandsverwaltung, Toolaufrufe, Speicher, gleichzeitige Ausführungen. Es war erschöpfend. Es fühlte sich an, als würde ich 80 % meiner Zeit mit der Infrastruktur verbringen und 20 % mit der eigentlichen Intelligenz, die ich aufbauen wollte.
Das änderte sich für mich vor etwa anderthalb Jahren, als die ersten wirklich soliden agentenspezifischen SDKs ihren Durchbruch hatten. Ich spreche nicht nur von Wrappers um LLMs; ich meine Werkzeuge, die grundlegend verändern, wie du intelligente Agenten entwirfst, baust und einsetzt. Und heute möchte ich mich auf einen bestimmten Aspekt davon konzentrieren: wie moderne Agenten-SDKs komplexe Multi-Agenten-Interaktionen und gemeinsamen Zustand vereinfachen und das, was früher ein Albtraum war, in ein handhabbares Entwurfsmuster verwandeln.
Der alte Weg: Spaghetti-Code und verteilte Kopfschmerzen
Spulen wir ein wenig zurück. Bevor diese SDKs ausgereift waren, wenn du wolltest, dass Agenten zusammenarbeiten, sahst du dich mit ein paar gängigen Mustern konfrontiert, von denen keines besonders spaßig war. Du hättest einen zentralen „Koordinator“-Agenten, der als Verkehrspolizist fungiert und Nachrichten zwischen anderen weiterleitet. Oder du hättest ein Pub/Sub-System, das großartig zur Entkopplung ist, aber das Verwalten von gemeinsamem Zustand oder sequentiellen Abhängigkeiten wurde zu einem ganz anderen Untier.
Ich erinnere mich an ein Projekt, bei dem ich ein Kundenservice-Agentensystem aufbaute. Wir hatten einen Agenten, um eingehende Tickets zu triagieren, einen anderen, um die Wissensdatenbank zu durchsuchen, und einen dritten, um gegebenenfalls an einen Menschen weiterzuleiten. Klingt einfach, oder? Die Realität war, dass der „Triagieren“-Agent wissen musste, was der „Such“-Agent kann, und der „Such“-Agent musste wissen, wie er Ergebnisse an den „Triagieren“-Agenten zurückgeben kann, der dann entschied, ob er den „Eskalieren“-Agenten aktivieren wollte. Jeder Agent hatte seine eigene kleine Zustandsmaschine, und das Synchronisieren war ein Albtraum. Debugging war, als würde man versuchen, eine bestimmte Nudel in einer Schüssel Spaghetti zu finden – jede Änderung bei einem Agenten schien sich auf unerwartete Weise auf die anderen auszuwirken.
Gemeinsamer Speicher? Vergiss es. Wir gaben JSON-Blobs weiter, in der Hoffnung, dass alle bezüglich des Schemas auf dem gleichen Stand waren. Versionierung war ein ständiger Kampf. Es war irgendwann funktional, aber es war zerbrechlich. Und das ist das Schlüsselwort: zerbrechlich. In dem Moment, in dem du einen vierten Agenten hinzufügen oder den Ablauf ändern wolltest, sahst du dich mit erheblichen Refactorings konfrontiert.
Der neue Weg: Orchestrierung als erster Bürger
Moderne Agenten-SDKs verschieben dieses Paradigma grundlegend, indem sie Orchestrierung und gemeinsamen Kontext als Kernfunktionen betrachten und nicht als nachträgliche Überlegungen. Sie bieten Abstraktionen, die es dir ermöglichen, Agentenrollen, ihre Fähigkeiten (Tools) und entscheidend, wie sie in einer gemeinsamen Umgebung oder einem „Thread“ der Ausführung interagieren, zu definieren. Es geht nicht nur um das Weiterleiten von Nachrichten; es geht darum, einen gemeinsamen Arbeitsbereich, ein gemeinsames Verständnis der Aufgabe und strukturierte Möglichkeiten zu definieren, wie Agenten zu einem kollektiven Ziel beitragen können.
Für mich kam der größte „Aha!“-Moment, als ich begann SDKs zu verwenden, die ein Konzept von einem „Graphen“ oder „Workflow“ für Agenten anboten. Anstatt nur Nachrichten zu senden, konnten Agenten innerhalb eines vordefinierten Flusses arbeiten, und das SDK verwaltete die Zustandsübergänge, Toolaufrufe und sogar die Fehlerbehandlung zwischen ihnen. Es fühlte sich an, als würde ich von der Assemblersprache zu einem hochgradigen Framework wechseln.
Beispiel 1: Kollaborative Forschung mit gemeinsamem Kontext
Lass uns ein praktisches Beispiel nehmen. Stell dir vor, du möchtest einen Forschungsassistenten erstellen. Nicht nur einen Agenten, der sucht, sondern einen, der eine komplexe Anfrage aufschlüsseln, Teile davon delegieren, Ergebnisse synthetisieren und dann eine Zusammenfassung entwerfen kann. So könntest du es mit einem modernen SDK angehen (ich werde eine konzeptionelle, pythonähnliche Syntax verwenden, da spezifische SDKs variieren, aber die Prinzipien sind allgemein anwendbar):
from agent_sdk import Agent, Workflow, Tool, SharedState
# Werkzeuge definieren
def search_web(query: str):
# Simuliere Websuche
return f"Suchergebnisse für '{query}': ..."
def summarize_text(text: str):
# Simuliere Zusammenfassung
return f"Zusammenfassung von: {text[:50]}..."
# Werkzeuge registrieren
search_tool = Tool("web_search", search_web, "Durchsucht das Internet nach Informationen.")
summarize_tool = Tool("text_summarizer", summarize_text, "Fasst gegebenen Text zusammen.")
# Agenten definieren
research_planner = Agent(
name="Planner",
description="Bricht komplexe Forschungsanfragen in Teilaufgaben auf.",
tools=[] # Planner verwendet keine Tools direkt, er delegiert
)
information_gatherer = Agent(
name="Gatherer",
description="Führt Websuchen basierend auf Teilaufgaben aus.",
tools=[search_tool]
)
synthesizer = Agent(
name="Synthesizer",
description="Synthesisiert gesammelte Informationen in kohärente Punkte.",
tools=[summarize_tool]
)
# Den Workflow definieren
research_workflow = Workflow(
name="Komplexe Forschungsaufgabe",
initial_state={"query": "", "sub_tasks": [], "raw_data": [], "synthesized_data": "", "final_report": ""},
agents=[research_planner, information_gatherer, synthesizer]
)
@research_workflow.step(agent=research_planner)
def plan_research(state: SharedState):
# LLM-Aufruf oder regelbasierte Logik, um Anfrage aufzuschlüsseln
state["sub_tasks"] = ["suche nach X", "suche nach Y", "suche nach Z"]
print(f"Planner: Hat '{state['query']}' in {state['sub_tasks']} aufgeschlüsselt.")
return "gather_information" # Übergang zum nächsten Schritt
@research_workflow.step(agent=information_gatherer, loop_over="sub_tasks")
def gather_information(state: SharedState, sub_task: str):
result = state.call_tool("web_search", query=sub_task)
state["raw_data"].append({"task": sub_task, "result": result})
print(f"Gatherer: Hat '{sub_task}' abgeschlossen, erhielt {len(result)} Zeichen.")
return "synthesize_results" # Nach Abschluss aller Teilaufgaben weitermachen
@research_workflow.step(agent=synthesizer)
def synthesize_results(state: SharedState):
all_raw_text = "\n".join([d["result"] for d in state["raw_data"]])
summary = state.call_tool("text_summarizer", text=all_raw_text)
state["synthesized_data"] = summary
print(f"Synthesizer: Hat eine Zusammenfassung von {len(state['raw_data'])} Elementen erstellt.")
return "draft_report" # Letzter Schritt
@research_workflow.step(name="draft_report")
def draft_report(state: SharedState):
# LLM-Aufruf, um den Abschlussbericht basierend auf synthesized_data zu entwerfen
state["final_report"] = f"Abschlussbericht über '{state['query']}':\n{state['synthesized_data']}"
print(f"Abschlussbericht:\n{state['final_report']}")
return "finished"
# Ausführen des Workflows
initial_query = "Die Auswirkungen von Quantencomputing auf die Kryptographie im nächsten Jahrzehnt."
result_state = research_workflow.run(query=initial_query)
print(f"\nWorkflow abgeschlossen. Abschlussbericht erstellt: {result_state['final_report'] != ''}")
Was passiert hier? Der `Workflow` verwaltet den `SharedState`. Agenten kommunizieren nicht direkt miteinander; sie lesen aus und schreiben in diesen gemeinsamen Zustand. Der `research_workflow.step`-Dekorator bestimmt, welcher Agent zu welchem Zeitpunkt aktiv ist und welche Übergänge stattfinden. Das SDK kümmert sich um das Weitergeben des `SharedState`-Objekts und sorgt für Konsistenz. Wenn `gather_information` bei einer Teilaufgabe fehlschlägt, kann das SDK so konfiguriert werden, dass es erneut versucht oder alarmiert, ohne die gesamte Kette zu brechen.
Das ist eine enorme Verbesserung gegenüber der manuellen Nachrichtenweitergabe. Die Struktur ist eindeutig. Der Zustand ist zentralisiert und dennoch zugänglich. Und entscheidend ist, dass das SDK das Framework für diese Koordination bereitstellt, was Boilerplate reduziert.
Gemeinsamer Speicher und dynamische Zustandsverwaltung
Über explizite Workflow-Diagramme hinaus bieten viele SDKs ausgeklügelte Modelle für gemeinsamen Speicher. Es geht nicht nur um ein Wörterbuch von Werten; es geht um Kontext, der von jedem Agenten, der an einer Sitzung beteiligt ist, abgerufen und aktualisiert werden kann. Dieser gemeinsame Kontext kann Folgendes umfassen:
- Unterhaltungshistorie: Das vollständige Transkript der Interaktionen, das für LLM-gestützte Agenten entscheidend ist.
- Ergebnisse von Toolaufrufen: Ausgaben von vorherigen Toolausführungen, die nachfolgende Agenten möglicherweise benötigen.
- Benutzervorlieben/Profil: Persistente Informationen über den Endbenutzer.
- Fachspezifisches Wissen: Fakten oder Regeln, die für die aktuelle Aufgabe relevant sind.
Die Schönheit dieser Modelle für gemeinsamen Speicher liegt oft in ihrer Fähigkeit, automatisch zu serialisieren und zu deserialisieren, über Sitzungen hinweg persistent zu sein und manchmal auch gleichzeitige Aktualisierungen elegant zu handhaben. Das ist der Punkt, an dem das SDK seinen Wert zeigt – es verwaltet die Komplexität des verteilten Zustands, ohne dass du jeden Lock und jedes Mutex selbst schreiben musst.
Beispiel 2: Dynamische Tool-Ketten mit gemeinsamem Kontext
Betrachten wir einen Agenten, der bei der Planung einer Reise hilft. Es könnte einen „Flight Booker“-Agenten und einen „Hotel Booker“-Agenten geben. Sie arbeiten beide an einem gemeinsamen `TripPlan`-Objekt im Speicher.
from agent_sdk import Agent, Session, Tool, SharedContext
# Vereinfachte Tool-Definitionen
def find_flights(origin: str, destination: str, date: str):
return {"flight_id": "FL123", "price": 350, "departure_time": "10:00"}
def find_hotels(city: str, check_in: str, check_out: str):
return {"hotel_id": "H456", "name": "Grand Hotel", "price_per_night": 120}
flight_tool = Tool("find_flights", find_flights, "Findet Flüge zwischen Städten.")
hotel_tool = Tool("find_hotels", find_hotels, "Findet Hotels in einer Stadt.")
# Agenten
flight_agent = Agent(name="FlightAgent", description="Bearbeitet Flugbuchungen.", tools=[flight_tool])
hotel_agent = Agent(name="HotelAgent", description="Bearbeitet Hotelbuchungen.", tools=[hotel_tool])
coordinator_agent = Agent(name="Coordinator", description="Orchestriert die Reiseplanung.", tools=[]) # LLM könnte hier sein
# Geteilter Kontext für die Sitzung
class TripPlan(SharedContext):
origin: str = ""
destination: str = ""
travel_date: str = ""
check_in_date: str = ""
check_out_date: str = ""
booked_flight: dict = {}
booked_hotel: dict = {}
status: str = "planen"
# Eine Sitzung zur Verwaltung der Interaktion
trip_session = Session(
agents=[flight_agent, hotel_agent, coordinator_agent],
context_model=TripPlan
)
# Simulation einer Benutzerinteraktion und Agentenantworten
# In einem realen Szenario würde der coordinator_agent (LLM) dies steuern
# basierend auf Benutzeranfragen und eigener Logik.
# Erste Benutzeranfrage
trip_session.context.origin = "NYC"
trip_session.context.destination = "LAX"
trip_session.context.travel_date = "2026-06-15"
trip_session.context.check_in_date = "2026-06-15"
trip_session.context.check_out_date = "2026-06-18"
print(f"Erster Plan: {trip_session.context.dict()}")
# Koordinator entscheidet sich, den Flugagenten anzufragen
# In einer realen Einrichtung wäre dies der Toolaufruf eines LLM
print("\nKoordinator: Frag den FlightAgent, um Flüge zu finden...")
flight_result = flight_agent.call_tool(
"find_flights",
origin=trip_session.context.origin,
destination=trip_session.context.destination,
date=trip_session.context.travel_date
)
trip_session.context.booked_flight = flight_result
print(f"FlightAgent gefunden: {trip_session.context.booked_flight}")
# Koordinator entscheidet sich, den Hotelagenten anzufragen, unter Verwendung des aktualisierten Kontexts
print("\nKoordinator: Frag den HotelAgent, um Hotels zu finden...")
hotel_result = hotel_agent.call_tool(
"find_hotels",
city=trip_session.context.destination, # Verwendung des Ziels aus dem Kontext
check_in=trip_session.context.check_in_date,
check_out=trip_session.context.check_out_date
)
trip_session.context.booked_hotel = hotel_result
trip_session.context.status = "gebucht"
print(f"HotelAgent gefunden: {trip_session.context.booked_hotel}")
print(f"\nEndstatus des Reiseplans: {trip_session.context.status}")
print(f"Voller Kontext: {trip_session.context.dict()}")
Hier fungiert das `TripPlan`-Objekt als einzige Informationsquelle für die Sitzung. Agenten können darauf zugreifen und davon schreiben. Die `Session` orchestriert, welcher Agent aktiviert wird, möglicherweise basierend auf dem LLM-Ausgang des `Coordinator`-Agenten. Wenn der `flight_agent` `booked_flight` aktualisiert, kann der `hotel_agent` diese Änderung sofort sehen und seine Aktionen anpassen. Dies ist hilfreich für den Aufbau reaktiver, kontextbewusster Multi-Agenten-Systeme.
Handlungsrelevante Erkenntnisse für Ihr nächstes Agentenprojekt
- Bewerten Sie SDKs für Orchestrierungsfähigkeiten: Suchen Sie nicht nur nach LLM-Wrappers. Priorisieren Sie SDKs, die explizit Multi-Agenten-Workflows, gemeinsamen Zustand und strukturierte Kommunikationsmuster unterstützen. Achten Sie auf Features wie `Workflow`-Grafiken, `SharedContext`-Modelle und solide Tool-Integration.
- Gestalten Sie Ihren gemeinsamen Zustand zuerst: Bevor Sie überhaupt Agentenlogik schreiben, denken Sie über die Informationen nach, die *alle* relevanten Agenten benötigen, um darauf zuzugreifen oder sie zu ändern. Definieren Sie ein klares Schema für Ihren gemeinsamen Kontext. Dies wird Ihre Agentendesigns informieren und Dateninkonsistenzen verhindern.
- Übernehmen Sie ein „Koordinator“- oder „Router“-Agentmuster: Selbst mit fortschrittlichen SDKs kann es hilfreich sein, einen bestimmten Agenten (oft einen powered LLM) zu haben, der entscheidet, *welcher* andere Agent als nächstes handeln soll oder *welches* Tool aufgerufen werden soll. Das SDK übernimmt die Mechanik; Ihr Koordinator kümmert sich um die Intelligenz.
- Verfolgen Sie eine Tool-First-Denkweise: Agenten interagieren hauptsächlich über Tools mit der Welt (und miteinander). Definieren Sie Ihre Tools klar und stellen Sie sicher, dass sie auf Daten wirken oder diese erzeugen, die gut in Ihren gemeinsamen Kontext passen.
- Beginnen Sie einfach, iterieren Sie: Versuchen Sie nicht, von Anfang an ein monolithisches Multi-Agenten-System zu erstellen. Beginnen Sie mit zwei Agenten, die an einer einfachen Aufgabe mit gemeinsamem Zustand zusammenarbeiten, und führen Sie schrittweise mehr Komplexität und Agenten ein.
Die Zeiten, in denen man manuell Nachrichtenwarteschlangen und benutzerdefinierte Zustandsmaschinen für jede Multi-Agenten-Interaktion verkabeln musste, scheinen glücklicherweise zu Ende zu gehen. Moderne Agenten-SDKs bieten die notwendigen Abstraktionen, um anspruchsvolle, kollaborative Agentensysteme zu entwickeln, die nicht nur funktional, sondern auch wartbar und skalierbar sind. Wenn Sie immer noch mit zerbrechlichen, spaghetti-code Agentarchitekturen kämpfen, ist es an der Zeit, sich ernsthaft anzusehen, was diese neuen SDKs zu bieten haben. Sie haben mein Leben auf jeden Fall erheblich einfacher gemacht, und ich glaube, sie können dasselbe für Sie tun.
Das war’s für dieses Mal! Lassen Sie mich in den Kommentaren wissen, welche SDKs Sie für die Multi-Agenten-Orchestrierung verwenden und mit welchen Herausforderungen Sie noch konfrontiert sind. Viel Spaß beim Bauen!
🕒 Published: