Effektive AI-Agenten entwickeln

• Teams, die LLM-basierte Agenten erfolgreich implementiert haben, neigen dazu, einfache, kombinierbare Muster statt komplexer Frameworks zu verwenden
• Man sollte die strukturellen Unterschiede zwischen Workflows und Agenten verstehen, und für eine optimale Lösung wird empfohlen, stets nur die minimale notwendige Komplexität einzuführen
• Verschiedene Agentenmuster (Prompt Chaining, Routing, Parallelisierung, Orchestrator-Workers, Evaluator-Optimizer-Loop usw.) werden in realen Produktionsumgebungen eingesetzt, und jedes Muster hat passende Anwendungsfälle sowie Vor- und Nachteile
• Bei der Implementierung von Agenten sind Einfachheit, Transparenz und Interface-Design die zentralen Prinzipien; auch Tool-Design und Prompt Engineering verdienen besondere Aufmerksamkeit
• In Kundenservice- oder Softwareentwicklungsumgebungen gibt es zunehmend Fälle, in denen Agenten tatsächlich Mehrwert liefern

---

Überblick

Im vergangenen Jahr hat Anthropic gemeinsam mit Teams aus verschiedenen Branchen Agenten auf Basis großer Sprachmodelle (LLMs) aufgebaut. In der Praxis zeigten erfolgreiche Einführungen von Agenten die Tendenz, eher auf einfache, kombinierbare Muster als auf komplexe Frameworks oder spezialisierte Bibliotheken zu setzen. Dieser Beitrag teilt Erkenntnisse aus der Zusammenarbeit mit Kunden und aus eigener Entwicklungserfahrung sowie konkrete Ratschläge für den Aufbau effektiver Agenten.

Was ist ein Agent?

Agenten können auf unterschiedliche Weise definiert werden.

• Manche definieren sie als vollständig autonome Systeme, die mithilfe externer Tools komplexe Aufgaben selbstständig erledigen
• Andere verstehen darunter präskriptive Implementierungen, die begrenzten Workflows oder vordefinierten Prozessen folgen

Anthropic ordnet beide Formen als agentische Systeme ein, unterscheidet jedoch architektonisch klar zwischen Workflows und Agenten.

• Workflow: eine Struktur, in der LLMs und Tools über vorab definierte Codepfade orchestriert werden
• Agent: ein System, in dem das LLM den Einsatz von Tools und den Ablauf selbst dynamisch entscheidet und Kontrolle darüber hat, wie die Aufgabe erfüllt wird

Dieser Beitrag erläutert beide Systemformen im Detail; praktische Einsatzbeispiele werden in Anhang 1 behandelt.

Wann man Agenten einsetzen sollte – und wann nicht

Bei der Entwicklung von Anwendungen ist es sinnvoll, dem Prinzip der minimalen Komplexität zu folgen und nur bei Bedarf schrittweise mehr Komplexität hinzuzufügen.

• Agentische Systeme können die Aufgabenleistung verbessern, auch wenn dafür teilweise Latenz/Kosten in Kauf genommen werden müssen
• Falls Komplexität nicht zwingend nötig ist, reichen oft ein einzelner LLM-Aufruf, Few-shot-Beispiele oder Retrieval-Anbindung aus
• Workflows eignen sich dort, wo Vorhersagbarkeit und Konsistenz wichtig sind; Agenten dort, wo Flexibilität und Skalierung erforderlich sind

Wann und wie Frameworks eingesetzt werden sollten

Es gibt verschiedene Frameworks, die die Implementierung agentischer Systeme vereinfachen.

• LangGraph (LangChain)
• Amazon Bedrock AI Agent framework
• Rivet, Vellum usw.

Diese Frameworks vereinfachen Low-Level-Aufgaben wie LLM-Aufrufe, Tool-Definition/-Parsing oder den Aufbau von Aufrufketten. Zu viel Abstraktion birgt jedoch das Risiko, dass der tatsächliche Fluss von Prompts und Antworten intransparent wird oder unnötig zusätzliche Komplexität entsteht.

• Entwicklern wird empfohlen, zunächst möglichst direkt mit der LLM-API zu arbeiten
• Auch bei Nutzung eines Frameworks sollte man dessen interne Funktionsweise genau verstehen

Beispielimplementierungen finden sich im anthropic-cookbook.

Bausteine, Workflows und Agentenmuster

Anthropic stellt Muster agentischer Systeme vor, die in realen Betriebsumgebungen häufig genutzt werden.

Baustein: erweitertes LLM

Der Kern agentischer Systeme ist ein LLM, das um Funktionen wie Retrieval, Tools und Memory erweitert wurde.

• Das Modell kann selbstständig Suchanfragen erzeugen, geeignete Tools auswählen und Informationen speichern
• Ein zentraler Implementierungsaspekt ist, die Funktionen an den jeweiligen Anwendungsfall anzupassen und dem LLM klare, dokumentierte Interfaces bereitzustellen

Über das kürzlich veröffentlichte Model Context Protocol ist eine einfache Integration verschiedener Third-Party-Tools möglich.

Erklärung nach Workflow-Typ

Prompt Chaining

• Eine Aufgabe wird in eine Reihe von Schritten zerlegt; jeder LLM-Aufruf verarbeitet das Ergebnis des vorigen Schritts weiter
• Durch programmatische Prüfungen (Gates) in jedem Schritt lässt sich der Prozess steuern
• Beispieleinsatz: Erstellen von Marketingtexten mit anschließender Übersetzung, Strukturentwurf eines Dokuments → Validierung → Ausformulierung des Inhalts

Routing

• Eingaben werden klassifiziert und in passende nachgelagerte Aufgaben verzweigt
• Für jede Kategorie können spezialisierte Prompts und Tools genutzt werden
• Beispieleinsatz: Weiterleitung von Kundenanfragen (Rückerstattung, technischer Support usw.), Modellauswahl je nach Schwierigkeitsgrad

Parallelisierung

• Eine Aufgabe wird in kleinere Einheiten aufgeteilt, parallel verarbeitet und anschließend zusammengeführt
• Sectioning: Jeder Teil wird unabhängig bearbeitet
• Voting: Dieselbe Aufgabe wird mit mehreren Perspektiven oder Prompts wiederholt, anschließend z. B. per Mehrheitsentscheid ausgewertet
• Beispieleinsatz: Trennung von Filterung und Beantwortung von Nutzerfragen, automatische Bewertung, Code-Review

Orchestrator-Workers

• Ein zentrales LLM zerlegt und verteilt Aufgaben dynamisch; mehrere Worker-LLMs bearbeiten Teilaufgaben und kombinieren anschließend die Ergebnisse
• Geeignet für nicht vorab definierte, von der Eingabe abhängige variable Teilaufgaben
• Beispieleinsatz: Coding mit Änderungen über mehrere Dateien hinweg, komplexe Informationssuche

Evaluator-Optimizer-Loop

• Ein Antwort-LLM und ein Bewertungs-LLM werden in einer wiederholten Schleife eingesetzt
• Geeignet für Situationen, in denen klare Bewertungskriterien und Verbesserungen auf Basis von Feedback wertvoll sind
• Beispieleinsatz: Bewertung feiner Nuancen bei literarischer Übersetzung, Informationssuche über mehrere Runden hinweg

Agenten

• Mit dem Fortschritt der LLMs entstehen in realen Diensten Agenten, die komplexe Eingaben, Schlussfolgern und Planung, Tool-Nutzung sowie Fehlerbehebung bewältigen können

• Beginn mit einer Benutzeranweisung/einem Dialog → Klärung der Aufgabe → autonome Ausführung → Feedback an Zwischen-Checkpoints möglich → Ende bei Abschluss- oder Abbruchbedingung

• In der realen Implementierung arbeitet das LLM iterativ unter Berücksichtigung von Umgebungsfeedback (Tool-Ergebnisse, Code-Ausführung); Toolset und Dokumentation sind dabei zentral

• Beispieleinsatz: Coding-Agenten zur Lösung von SWE-bench-Aufgaben, computer-use-Automatisierung auf Basis von Claude

• Einsatzbereich: offene Probleme, bei denen sich feste Pfade oder Schritte nicht vorhersagen lassen, sowie Situationen, in denen verlässliche Entscheidungsfindung nötig ist

• Wegen der zunehmenden Autonomie müssen Kosten und das Risiko komplexer Fehler berücksichtigt werden; Sandbox-Tests und Guardrails sind essenziell

Kombination und Anpassung von Mustern

• Die vorgestellten Bausteine sind keine starren Regeln, sondern können je nach Situation kombiniert werden
• Entscheidend sind die Messung der Ergebnisse und iterative Verbesserung, um die optimale Struktur zu wählen und schrittweise Komplexität hinzuzufügen

Zusammenfassung und empfohlene Prinzipien

Der Erfolg von LLM-Systemen hängt nicht von Komplexität oder neuen Technologien ab, sondern davon, den passenden Ansatz für das Ziel zu finden.

• Mit einfachen Prompts beginnen, Ergebnisse bewerten, iterativ optimieren und die Komplexität stufenweise erweitern

• Drei Grundprinzipien für das Agenten-Design

  1. Einfachheit bewahren
  2. Transparenz priorisieren (Klarheit schon in der Planungsphase)
  3. Dokumentation und Tests von Tools/Interfaces ernst nehmen

• Frameworks ermöglichen einen schnellen Start, doch in der Praxis entscheiden minimale Abstraktionsschichten und die Fähigkeit zur direkten Implementierung über Zuverlässigkeit und Wartbarkeit

Anhang 1: Einsatzbeispiele von Agenten in der Praxis

Kundenservice

Der Kundenservice eignet sich durch die Kombination aus Chatbot-Interface und Tool-Integration auf natürliche Weise für den Einsatz von Agenten.

• Dialogbasierte Interfaces und die Notwendigkeit externer Daten- und Prozessanbindung treten gleichzeitig auf
• Über Tools lassen sich Kundeninformationen, Bestellhistorien, Wissensdatenbanken usw. anbinden
• Aufgaben wie Rückerstattungen oder Ticketbearbeitung können automatisiert werden
• Erfolgskriterien lassen sich klar definieren

Erfolgreiche Anwendungsfälle validieren die Wirksamkeit von Agenten durch nutzungsbasierte Abrechnungsmodelle auf Basis erfolgreicher Lösungsfälle.

Coding-Agenten

Auch in Softwareentwicklungsumgebungen steigt der praktische Nutzen von Agenten deutlich, etwa bei der automatischen Problemlösung.

• Code-Ergebnisse lassen sich durch automatisierte Tests verifizieren
• Auf Basis von Testergebnissen sind iterative Verbesserungen möglich
• Problemdefinitionen sind klar, und die Qualität der Ergebnisse lässt sich objektiv messen

Beispiel aus der internen Implementierung von Anthropic: Im Benchmark SWE-bench Verified wurden reale GitHub-Issues allein anhand von Pull-Request-Beschreibungen gelöst. Neben automatisierten Tests bleibt menschliche Prüfung weiterhin wichtig, um zu kontrollieren, ob das Gesamtsystem den Anforderungen entspricht.

Anhang 2: Methoden des Tool Prompt Engineering

In allen agentischen Systemen sind Tools ein Kernelement.

• LLMs wie Claude können über APIs präzise gemäß Struktur und Definition mit externen Services interagieren
• Antworten können einen tool use block enthalten
• Auch Tool-Definitionen und -Spezifikationen müssen ebenso sorgfältig wie Prompt Engineering entworfen werden

Tipps zum Design von Tool-Formaten

• Genügend Tokens bereitstellen, damit das Modell nicht in typische Schreib-„Fallen“ gerät

• Es wird empfohlen, natürliche Formate zu verwenden, denen das Modell im Internet häufig begegnet ist

• Unnötigen Formatierungs-Overhead (z. B. Zählen von Codezeilen, String-Escaping usw.) minimieren

• So wie man in das Design von Human-Computer-Interfaces (HCI) investiert, sollte man auch Agent-Computer-Interfaces (ACI) sorgfältig gestalten

• Aus Sicht des Modells muss klar sein, wie ein Tool zu verstehen und zu verwenden ist; dazu gehören auch Nutzungsbeispiele, Randbedingungen und Angaben zum Eingabeformat

• Parameternamen und Beschreibungen sollten mit intuitiven Begriffen gestaltet werden – ähnlich wie beim Schreiben einer Dokumentation (Docstrings)

• Die tatsächliche Nutzung mit verschiedenen Eingabewerten testen und iterativ verbessern

• Argumente so gestalten, dass Fehler reduziert werden können (Poka-yoke)

Beim Aufbau des tatsächlichen SWE-bench-Agenten wurde mehr Zeit in die Optimierung des Tool-Designs investiert als in den Gesamtprompt. Beispiel: Um Fehler bei Dateipfaden nach dem Verlassen des Root-Ordners zu verringern, wurde das Tool so geändert, dass nur absolute Pfade akzeptiert werden – danach funktionierte es einwandfrei.

[GN⁺]

Hacker-News-Kommentare

• Besonders beeindruckend sei, dass dieser Beitrag mit einer klaren Definition von "AI agents" beginnt. Die hier verwendete Definition sei "ein System, in dem ein LLM Prozesse und den Einsatz von Tools dynamisch selbst verwaltet und die Ausführung einer Aufgabe eigenständig kontrolliert". Auch die Unterscheidung zwischen „Agent“ und „Workflow“ sowie die Vorstellung mehrerer praktischer Workflow-Muster gefalle. Als der Beitrag erstmals erschien, habe man auch selbst eine Zusammenfassung dazu geschrieben: Notiz zu building-effective-agents. Und kürzlich sei auch Anthropics Bericht über den Aufbau eines Multi-Agenten-Forschungssystems interessant gewesen, dazu gebe es ebenfalls zusätzliche Notizen: Notiz zum Multi-Agent-Research-System

  • Man halte die in diesem Beitrag verwendete Workflow-Definition für nicht präzise. Moderne Workflow-Engines folgten oft keinem vorab festgelegten Codepfad mehr und verhielten sich in vielen Fällen faktisch genauso wie Agenten. Der Autor habe den Begriff Workflow offenbar neu gefasst, um eine Unterscheidung zu schaffen, tatsächlich sei aber auch ein Agent letztlich nur ein Workflow in Schleifenform, der dynamisch anhand der LLM-Antworten Funktionen aufruft. Aktuelle Workflow-Engines seien ebenfalls sehr dynamisch

  • Einer der Co-Autoren von Building Effective Agents habe bei AIE auch einen Vortrag zu diesem Beitrag gehalten, und die Resonanz sei sehr gut gewesen: YouTube-Video

  • Der Artikel über Multi-Agent-Research sei wirklich gut, aber der Aussage aus Building Effective AI Agents, dass es aus didaktischer Sicht besser sei, ein System ohne Framework von Grund auf zu bauen, stimme man nicht zu. Der erste Vorteil eines guten Frameworks sei, dass man damit verschiedenste LLMs – und zwar herstellerunabhängig – leicht ausprobieren könne

  • Frage, welches AI-Agent-Framework Anthropic verwendet. Es wirke so, als hätten sie ihr internes Framework nie veröffentlicht

  • Dank für die zusätzlichen Notizen, und die Reaktion, dass dieses Thema in letzter Zeit auch für einen selbst sehr wichtig sei

• Im AI-Bereich fühlten sich sechs Monate extrem lang an. Vor ein paar Monaten habe man diesen Beitrag wiederholt gelesen, inzwischen wirke es aber so, als sei die Agentenentwicklung klar an einen Engpass gestoßen. Sogar das neueste Gemini scheine eher Rückschritte gemacht zu haben

  • Mehrere Agenten gleichzeitig laufen zu lassen sei teuer und drücke den RoI. Ein DeepSearch-Agent für Aktien verwende zum Beispiel sechs Agenten und koste etwa 2 Dollar pro Anfrage. Multi-Agent-Orchestrierung sei schwer zu kontrollieren, und je stärker die Modelle würden, desto weniger brauche man Multi-Agenten. Umgekehrt steige bei schwächeren Modellen der Geschäftswert spezialisierter, enger KI-Systeme. Das sei praktische Erfahrung

  • Frage, warum es sich so anfühle, als hätten Agenten Rückschritte gemacht. Warum könnten sie nicht einfach selbst viele Instanzen von sich erzeugen und 24/7 parallel weiterarbeiten, prüfen und sich verbessern?

  • Die Lösung des Prompt-Injection-Problems sei extrem schwierig, und genau das werde zu einem ernsthaften Engpass

• Man frage sich, wie Agenten mit task queueing, race conditions und anderen Nebenläufigkeitsproblemen umgehen. In Artikeln zum Aufbau von Multi-Agent-Workflows heiße es oft, ein Orchestrator-Agent verwalte alles, aber man frage sich immer, ob in der Praxis nicht deutlich komplexeres Design und intelligenterer Glue Code nötig seien. Oder ob das alles wirklich wie „automatische Magie“ funktioniere

  • Der Standard bei Agenten sei, dass Tools sequenziell ausgeführt würden, sodass man sich um Nebenläufigkeitsprobleme nicht kümmern müsse. Inzwischen unterstützten mehrere Modelle parallele Tool-Aufrufe, sodass das Modell etwa „führe diese drei Tools aus“ anfordern könne und das Harness sie parallel oder sequenziell ausführe und die Ergebnisse an den nächsten Schritt weitergebe. Anthropic nutze Multi-Agenten-Setups deutlich aktiver, bei denen ein übergeordneter Agent Aufgaben parallel an Unteragenten delegiere. Dieser Trick werde in Claude Code eingesetzt und auch in entsprechenden Reverse-Engineering-Notizen (claude-trace) sowie in einem Beitrag zur Funktionsweise von Claude Research (multi-agent-research-system) näher erläutert. Die Phase, in der man gute Muster für LLM-Tool-Nutzung entdecke, stehe noch ganz am Anfang, und dass Modelle überhaupt wirklich gut im Tool-Use geworden seien, sei erst in den letzten sechs Monaten passiert – entsprechend groß sei das Entwicklungspotenzial

  • Daher bevorzuge man zunehmend den Ansatz, nicht alles in JSON abzubilden, sondern das LLM direkt Code erzeugen zu lassen, der Tool Calls behandelt. Die smolagents-Bibliothek von Huggingface nutze den Ansatz, dass das LLM Python-Code für Funktionsaufrufe generiert. Wenn man parallele Tool-Aufrufe wolle, könne man das im Prompt festlegen, und das LLM müsse dann auch die Synchronisation übernehmen. Natürlich gebe es das Problem, vom LLM erzeugten Code auszuführen, aber dafür existierten verschiedene Lösungen

  • Erfahrungsbericht zur Nutzung des Codex-Webinterfaces. Es habe einen Refactoring-Plan gegeben, der zu lang für eine einmalige Bearbeitung gewesen sei, daher habe man über die „ask“-Funktion den Plan in mehrere Aufgaben zerlegt und parallelisierbare Aufgaben gruppiert. Das LLM habe die Aufteilung ähnlich vorgenommen wie ein echtes Team, aber weil zwischen den Aufgaben keine Kommunikation vorausgesetzt worden sei, sei der Kontextverlust sehr groß gewesen. Obwohl es länger gedauert habe, als es selbst zu machen, habe man es ausprobiert und die Aufgaben dann sequentiell in mehreren Sessions abgearbeitet, jeweils mit detaillierten Prompts zu Ziel, Vorgehen, Verifikation und Dokumentation. Kurz gesagt: Ein Orchestrator-Agent eigne sich für sehr einfache Aufgaben, sein praktischer Einsatzbereich sei aber deutlich begrenzter als gedacht

  • Nichts funktioniere magisch automatisch. Die betrieblichen Eigenschaften, um die man sich in klassischen Systemen kümmern müsse, müsse man auch bei AI-Agenten explizit entwickeln. Wer sich nur AI-Agent-Demos ansehe und glaube, man könne den Code eines Spaghetti-Code-Teams einfach durch ein paar saubere AI-Prompts ersetzen, werde leicht in die Irre geführt. In einigen wenigen Fällen könne das funktionieren, aber letztlich habe jeder Code in einem System einen Grund, und wenn man irgendwann dabei lande, all diesen Code in ein LLM zu „übersetzen“, habe man die Richtung verloren

  • Bei Coding-Agenten zeichne sich als emerging pattern ab, Arbeit über Container zu isolieren und Ergebnisse mit Git zu reviewen und zu mergen. Ein Beispiel sei die Nutzung von Containern und MCP (container-use), was für parallele Code-Arbeit nützlich sei. Für andere Arbeitsbereiche würden Workflow-Builder wie n8n, Zapier oder CrewAI weiterhin häufig verwendet

• Dieser Beitrag erinnere an die Botschaft, mit der „einfachsten möglichen Lösung“ zu beginnen und echte Komplexität nur dann hinzuzufügen, wenn sie wirklich gebraucht werde. Mit klar definierten LLM-Aufrufen und etwas einfacher Glue-Logik lasse sich oft ein stabileres, leichter zu debuggendes und günstigeres System bauen. Aufwendig wirkende Agentensysteme verursachten dagegen häufig eher zusätzliche Probleme

• Ausdruck der Hoffnung, dass AI für Menschen tatsächlich zu etwas Nützlichem werde

• Anthropic stelle zwar solche technischen Informationen bereit, sollte aber auch eine leicht verständliche Guide-Version für Nichtfachleute anbieten. Wenn etwa eine Marketingabteilung Agenten einführen wolle, brauche sie eine Anleitung, mit der sich Spezifikationen schon auf elementarem Niveau definieren ließen. Im Schlussabschnitt und im Anhang gebe es zwar entsprechende Inhalte, dennoch bleibe die Frage „wie baut man das?“ weiterhin stark auf die Implementierung fokussiert

• (Dezember 2024 – aus heutiger Sicht fühlt sich das an wie eine sehr lange zurückliegende Zeit)

  • Aaaah, also heißt das, wir müssen jetzt wieder unser Gehirn benutzen und wie Höhlenmenschen im Dezember 2024 wieder 100 Prozent des Codes selbst schreiben? scherzhafte Reaktion Zugehöriger Kommentar

  • Dieser Beitrag halte sich erstaunlich gut. Man nutze ihn persönlich weiterhin als Referenz und er wirke auch mit der Zeit nicht veraltet. Der Beitrag habe Anthropic als „praktischen Partner für die Entwicklung echter AI-Tools“ in einem neuen Licht erscheinen lassen

• Die überzogene Hype-Welle rund um Agenten habe inzwischen deutlich nachgelassen

  • Inzwischen interessierten sich alle eher für AI Agency

• Hinweis, dass dieser Beitrag damals bereits diskutiert worden sei: Originale HN-Diskussion

• Positives Urteil darüber, dass der Beitrag ohne Übertreibung und ohne dem Hype zu folgen realistisch an das Thema herangehe. Kritisch gesehen werde die Tendenz vieler Menschen, Agentensysteme nur deshalb zu bauen, weil sie gerade im Trend seien, ohne zu hinterfragen, ob die Aufgabe überhaupt wirklich einen Agenten brauche