Hört auf, AI-Agenten zu bauen, und nutzt intelligentere LLM-Workflows

• Die meisten Teams, die LLM-basierte Systeme entwickeln, versuchen zuerst Agenten zu bauen, scheitern aber oft schnell an Komplexität, mangelnder Steuerbarkeit und schwieriger Fehlersuche
• Echte Agentenmuster, die Memory, RAG, Tool-Nutzung und Workflow-Steuerung zugleich benötigen, sind in der Praxis selten; die meisten Probleme lassen sich mit einfachen Workflows (Chaining, Parallelisierung, Routing usw.) effektiver lösen
• Es wird empfohlen, zuerst fünf in der Praxis nützliche LLM-Workflow-Muster anzuwenden und Agenten nur dann vorsichtig einzusetzen, wenn sie wirklich nötig sind
  • Prompt Chaining, Parallelisierung, Routing, Orchestrator-Worker, Evaluator-Optimizer
• Selbst wenn Agenten nötig sind, bleiben menschliche Mitwirkung, klare Kontrolle und Observability der Schlüssel

---

Sind AI-Agenten wirklich nötig?

• Einblicke von Hugo Bowne-Anderson, der verschiedenen Engineers und Teams wie Netflix, Meta und der US Air Force Beratung und Schulungen zum Aufbau von LLM-Systemen bietet
  • Er betreibt den Kurs Building LLM Applications for Data Scientists and Software Engineers

Der falsche Start: Warum alle von Agenten besessen sind

• Viele Teams führen zu Beginn von LLM-Projekten zuerst komplexe Strukturen wie Agenten, Memory, Routing, Tool-Nutzung und Persönlichkeitsdesign ein
• In der Praxis treten jedoch in vielen Bereichen wie Zusammenarbeit zwischen Agenten, Tool-Auswahl und Langzeitgedächtnis fortlaufend Fehlverhalten und Ausfälle auf
• Als Beispiel wird ein auf CrewAI basiertes Forschungsagenten-Projekt genannt, in dem die einzelnen Rollen (Researcher, Zusammenfasser, Koordinator) nicht wie erwartet zusammenarbeiteten und das System hilflos zusammenbrach

Was ist ein Agent?

• Vier Eigenschaften von LLM-Systemen: Memory, Information Retrieval (RAG), Tool-Nutzung und Workflow-Steuerung
• Die letzte Eigenschaft, die Workflow-Steuerung (wenn das LLM selbst den nächsten Schritt oder den Einsatz von Tools entscheidet), wird als agentische Eigenschaft bezeichnet
• Für die meisten realen Aufgaben zeigen einfache Workflows (Chaining, Routing usw.) tatsächlich eine höhere Stabilität

Welche in der Praxis nützlichen LLM-Workflow-Muster man statt Agenten verwenden sollte

1. Prompt Chaining

• Beschreibung: Mehrere Aufgaben werden in eine Reihe von Schritten (eine Kette) aufgeteilt, sodass das LLM jeden Schritt nacheinander verarbeitet
• Beispiel: Aus einem LinkedIn-Profil Name, Titel und Firmeninformationen extrahieren → zusätzliche Informationen über die Firma ergänzen (Mission, Hiring usw.) → auf Basis von Profil- und Firmeninformationen eine personalisierte E-Mail schreiben
• Vorteile: Jeder Schritt ist klar getrennt, wodurch sich Ursachen bei Bugs leicht nachverfolgen und beheben lassen; das erleichtert Debugging und Wartung
• Leitlinien:
  • Geeignet für sequenziell verbundene Tasks
  • Fällt auch nur ein Schritt aus, kann die gesamte Kette scheitern
  • Die Aufteilung in kleine Arbeitseinheiten ermöglicht vorhersehbare Ergebnisse und einfaches Debugging

2. Parallelisierung

• Beschreibung: Mehrere unabhängige Aufgaben werden gleichzeitig ausgeführt, um den gesamten Prozess zu beschleunigen
• Beispiel: Aus den Profilen mehrerer Personen parallel verschiedene Merkmale wie Ausbildung, Berufserfahrung und Skills extrahieren, um die gesamte Verarbeitungszeit zu verkürzen
• Vorteile: Effizient auch bei großen Datenmengen, etwa bei unabhängiger Datenextraktion oder -verarbeitung; passt gut zu verteilten Umgebungen
• Leitlinien:
  • Geeignet, wenn die einzelnen Tasks voneinander unabhängig sind und parallele Ausführung die Gesamtgeschwindigkeit deutlich erhöht
  • Auf Ausnahmefälle wie Race Conditions und Timeouts bei paralleler Ausführung achten
  • Passend für die Verarbeitung großer Datenmengen und die gleichzeitige Analyse mehrerer Quellen

3. Routing

• Beschreibung: Das LLM klassifiziert Eingabedaten und verzweigt sie automatisch in den jeweils passenden Workflow
• Beispiel: In einem Kundensupport-Tool wird klassifiziert, ob es sich um eine Produktanfrage, ein Zahlungsproblem oder eine Rückerstattungsanfrage handelt; danach erfolgt die automatische Weiterleitung in den passenden Workflow, bei unklaren Typen an einen Standard-Handler
• Vorteile: Saubere Trennung verschiedener Fälle durch spezialisierte Verarbeitungslogik je Eingabetyp
• Leitlinien:
  • Sinnvoll, wenn unterschiedliche Eingabetypen oder Situationen getrennt behandelt werden müssen
  • Bei Grenzfällen oder Ausnahmen kann das Routing scheitern oder Fälle übersehen
  • Ein Catch-all-Handler für nicht klassifizierte oder Ausnahmefälle muss unbedingt vorgesehen werden

4. Orchestrator-Worker

• Beschreibung: Ein LLM in der Rolle des Orchestrators zerlegt Aufgaben und trifft Entscheidungen, delegiert Teilaufgaben an Worker (ausführende LLMs) und steuert Ablauf und Reihenfolge direkt
• Beispiel: Ein Zielprofil wird in Tech oder Non-Tech klassifiziert → bei Tech wird die Erstellung der E-Mail an einen spezialisierten Worker delegiert, bei Non-Tech an einen anderen Worker
• Vorteile: Trennung von Entscheidungsfindung (Klassifikation/Bewertung) und Ausführung (Einzelverarbeitung); vorteilhaft für dynamische Flow-Kontrolle und Skalierung
• Leitlinien:
  • Geeignet, wenn Tasks jeweils spezialisierte Behandlung benötigen und komplexe Verzweigungen oder stufenweise Koordination erforderlich sind
  • Wenn der Orchestrator Tasks falsch zerlegt oder falsch delegiert, entstehen Fehler im gesamten Flow
  • Die Logik sollte explizit und einfach bleiben; Delegation, Reihenfolge und Abbruchbedingungen müssen klar entworfen werden

5. Evaluator-Optimizer

• Beschreibung: Das LLM bewertet ein Ergebnis (Score/Feedback) und überarbeitet bzw. verbessert es wiederholt, wenn es den Kriterien nicht genügt
• Beispiel: E-Mail-Entwurf erstellen → Evaluator vergibt Qualitätsbewertung/Feedback → wenn ein definierter Schwellenwert erreicht ist oder die maximale Zahl an Iterationen überschritten wurde, endet der Prozess; andernfalls wird erneut überarbeitet
• Vorteile: Die Qualität des finalen Outputs kann iterativ bis zu einem Zielniveau verbessert werden; gut geeignet für den Einsatz quantitativer Kriterien
• Leitlinien:
  • Geeignet für Situationen, in denen Qualität wichtiger ist als Geschwindigkeit und iterative Optimierung nötig ist
  • Ohne Abbruchbedingung kann das System in eine Endlosschleife geraten
  • Klare Qualitätskriterien und Iterationslimits sind zwingend erforderlich

Wann Agenten wirklich nötig sind

• Agenten entfalten ihren Wert besonders in Umgebungen, in denen Human-in-the-loop in Echtzeit garantiert ist
  • Beispiel 1: Unterstützung in Data Science – bei SQL-Queries, Visualisierung und Empfehlungen zur Datenanalyse probiert das LLM kreativ Dinge aus, während Menschen die Ergebnisse beurteilen und korrigieren
  • Beispiel 2: Kreativer Partner – bei Ideen für Werbetexte, Headline-Vorschlägen oder Empfehlungen zur Textstruktur sind menschliche Richtungsanpassung und Qualitätsprüfung zentral
  • Beispiel 3: Helfer beim Code-Refactoring – bei Vorschlägen zu Design Patterns, Erkennung von Edge Cases oder Code-Optimierung geben Entwickler ihre Freigabe oder ergänzen nach
• Merkmal: Agenten funktionieren am besten nicht dann, wenn sie „alles selbst“ erledigen, sondern in Umgebungen, in denen Menschen Fehler und Richtung in Echtzeit steuern

Wann Agenten nicht geeignet sind

• Enterprise- und mission-critical Systeme (Finanzen, Medizin, Recht usw.):
  • Weil Zuverlässigkeit der Automatisierung und deterministisches Verhalten wichtig sind, ist eine Struktur riskant, in der LLM-Agenten Entscheidungen treffen
  • Stattdessen sollten klare Kontrollmuster wie Orchestrator und Routing eingesetzt werden
• Alle Situationen, in denen Stabilität und Vorhersehbarkeit wichtig sind
  • Typische Fehlfälle: Agenten wählen ohne Kontext oder Memory wiederholt die falschen Tools oder die Arbeitsteilung/Koordination scheitert, sodass der gesamte Flow zusammenbricht
• Häufige Ursachen für das Scheitern von Agentensystemen in der Praxis
  • Kein explizites Memory-System entworfen, wodurch Kontext verloren geht
  • Zu wenige Beschränkungen bei der Tool-Auswahl (unnötige/falsche Tool-Nutzung)
  • Verlass auf freie Delegationsstrukturen, was zur gescheiterten Koordination der Zusammenarbeit führt

Lehren für das Design in der Praxis

• Selbst bei der Einführung von Agenten sind Design, Observability und Kontrollmechanismen auf dem Niveau eines hochwertigen Softwaresystems zwingend erforderlich
• Statt komplexer Agenten-Frameworks ist ein Design mit Observability, klaren Evaluationsschleifen und direkt kontrollierbarer Struktur schneller und sicherer

Fazit (TL;DR)

• Agenten werden oft überschätzt und übermäßig eingesetzt
• Für die meisten realen Aufgaben sind einfache Workflow-Muster besser geeignet
• Agenten entfalten ihren Wert in Umgebungen, in denen Menschen direkt eingreifen
• In stabilen Systemen sind sie eher ein Risikofaktor
• Systeme sollten mit Observability, expliziter Kontrolle und iterativen Evaluationsstrukturen entworfen werden

• Statt komplexer Agenten-Frameworks ist ein Design mit Observability, klaren Evaluationsschleifen und direkt kontrollierbarer Struktur in der Praxis der Schlüssel zu einer schnelleren und sichereren Entwicklung LLM-basierter Services

[samdo103]

Vor einem Monat habe ich mit CURSOR begonnen, um zu lernen, was AI Coding ist, und habe mich an die Entwicklung eines Entwicklungs-Frameworks gemacht.

Etwa drei Wochen lang wiederholte sich, dass Quellcode, der erfolgreich war und von einem AI Agent validiert worden war, wieder kaputtging. Ich versuchte mit allen möglichen Methoden, den AI Agent zu kontrollieren, aber ich scheiterte.

Dann wurde mir klar, dass es Vorrang hat, vor der Entwicklung des Entwicklungs-Frameworks zunächst den Quellcode zu entwickeln, der den AI Agent kontrolliert.

Schließlich habe ich genau einen Monat nach dem Start, bei dem ich zunächst verstehen wollte, was AI überhaupt ist, das Ergebnis erreicht, Software fertigzustellen, die zu 100 % durch AI implementiert und zu 100 % betrieben werden kann, wobei ich den AI Agent vollständig kontrolliere (genauer gesagt: ohne dass externe LLMs oder AI Agents nötig sind).

Derzeit bin ich am 14. Tag dabei, diese META AI für zusätzliche Weiterentwicklung weiter zu trainieren und dabei Betriebsregeln zu erstellen und durchsetzen zu lassen. Gleichzeitig migriere, verbessere und standardisiere ich drei MES-Systeme, die zuvor von Menschen unvollständig erstellt worden waren, und befinde mich dabei in der Abschlussphase.

Und jetzt bereite ich bereits die nächste Evolution vor.

[spilist2]

Ist es bei Prompt Chaining dann aber nicht auch vertretbar, die LLM, die einzelne Prompts ausführt, den Ausführungs-Worker, den Orchestrator-Worker, die Evaluator-LLM usw. jeweils als Agenten zu bezeichnen?

[spilist2]

Ah, es gibt also die Aussage: „Die letzte Workflow-Steuerung (dass das LLM selbst entscheidet, ob der nächste Schritt erfolgt oder ein Tool verwendet wird) wird als agentische Eigenschaft bezeichnet.“ Verstanden. Dann ist das also ein Text, der auf autonome Agenten abzielt. Ich kenne mich mit Agenten noch nicht so gut aus, deshalb ...

[GN⁺]

Hacker-News-Kommentare

• Die Entwicklung von Agenten hat wirklich Spaß gemacht, aber es ist klar, dass es beim „Context Engineering“ ernsthafte Probleme gibt. Egal, wie groß man das Kontextfenster macht, man muss trotzdem kuratieren, was der Agent zu sehen bekommt, und es fehlt an effektiven Filtern, die nur die wirklich wichtigen Informationen auswählen. Deshalb muss man mit überall verstreuten *.md-Dateien nachhelfen, und auch die Zuweisung von Rollen ist wichtig. Dieses *.md-System ist eine Art primitives Gedächtnissystem und könnte deutlich robuster weiterentwickelt werden. Ich denke auch, dass es möglich ist, auf Basis der Nutzerinteraktionen in Echtzeit Programme oder Modelle auf natürlicher Sprachbasis zu erzeugen. Bei der Nutzung von Claude Code habe ich gemerkt, dass es ein sehr mächtiger Reinforcement-Learning-Mechanismus ist, den Agenten mit einer Testsuite zu „steuern“, und ich hoffe, dass dieser Loop in den meisten Fällen erfolgreich weiterläuft und neue Ideen hervorbringt, wie Agenten zu intelligenteren Kollaborationspartnern werden können
  • Es fühlt sich an, als würde man mehr Zeit damit verbringen, mit den Tools zu kämpfen als mit der eigentlichen Arbeit
  • Ich frage mich, ob es eine empfohlene Methode gibt, .md-Dateien in solchen Systemen zu strukturieren. Ich habe Sorge, dass zu viel Markup für Menschen zwar gut lesbar ist, aber für LLMs problematisch werden könnte. Mich würde interessieren, ob .md-Dateien, die für Menschen gedacht sind, die Nutzung durch LLMs stören
  • Meiner Erfahrung nach ist Kontextverwaltung der Kern fast aller Probleme. Zum Beispiel den richtigen Kontext für parallele/rekursive Aufgaben zu schaffen, bestimmte Schritte auszulassen (z. B. das Bearbeiten vorheriger Antworten) und nur das überarbeitete Ergebnis zu zeigen, oder dafür zu sorgen, dass der Agent bei meinen Kommentaren seine eigene Ausgabe in diesem Kommentar wiedererkennt — es gibt in der Praxis viele verschiedene Situationen
  • Der Teil über das Verstärken des Agenten mit einer Testsuite ist interessant; ich würde gern mehr darüber hören, wie dieser Ablauf konkret aussieht
• Ich bin noch nicht sicher, ob AI-Agenten sich wirklich so breit durchsetzen werden, wie die Leute auf LinkedIn behaupten, aber ich halte die Möglichkeit offen. Im Moment nutze ich AI stark unter Kontrolle, etwa mit Claude Code oder Cursor. Das liegt nicht daran, dass die Modelle zu schwach wären, sondern daran, dass ich selbst häufig Taste und Richtung vorgeben will. Der AI mehr Autonomie zu geben, ist für mich eher nicht attraktiv, weil ich nur durch mein Eingreifen ein Gefühl von Identität und Verbundenheit habe. Vielleicht ändere ich meine Meinung, wenn sich die Arbeitsweise verändert oder neue UX entsteht, aber derzeit möchte ich nicht, dass AI zu agentisch wird
  • Glaubst du, dass man mit der Zeit das Verhalten der Modelle besser versteht und mit mehr/besserem Kontext und Anweisungen die Anforderungen an den Geschmack und die Richtung des Nutzers bis zu einem gewissen Grad erfüllen kann? Meiner Erfahrung nach lässt sich AI in vielen Workflows schon mit gut gemachtem Prompt Engineering ziemlich stark in die gewünschte Richtung lenken, sodass man oft nicht häufig eingreifen muss
  • Dem stimme ich genau zu. Ich habe anderswo schon ähnliche Kommentare hinterlassen, aber ich denke, das alte Sprichwort „There’s no free lunch“ stimmt immer noch. Wenn ein LLM Probleme ganz ohne Menschen lösen könnte, würde das bedeuten, dass alle mit ein paar Zeilen Prompt dasselbe ausgefeilte System bauen könnten — und dann verschwänden die Unterschiede und der Wert zwischen den Systemen. Wenn Prompts eine neue Abstraktionsebene sind und man Claude zum Beispiel einfach sagt: „Bau mir eine Notiz-App“, dann geben Millionen Menschen denselben günstigen Prompt ein, und man fragt sich, was genau der Prompter überhaupt noch an Bedeutung hinzufügt
  • Ich denke, dass sich mit der Zeit auch diese einzelnen Elemente von Taste zunehmend als Prompts systematisieren lassen. Zum Beispiel ein Prompt, der bei Codeänderungen keine unnötige Mutabilität erzeugt und dazu anhält, vorhandene Dinge möglichst immutable zu halten. Ein anderer Prompt legt Standards fest, um nutzlose Logs zu vermeiden (auf die von mir konkret definierte Weise) usw. Wenn ich Codeänderungen reviewe, führe ich all diese Prompts einzeln aus und sammle sie als strukturierten MCP-Output. Solche Dinge wende ich auf Code-Agenten an, um automatisierte Review-Iterationen zu realisieren. Wenn eine Situation entsteht, in der ich manuell Kontext hinzufügen muss, erstelle ich einen neuen Prompt oder erweitere einen bestehenden zur Verstärkung
• Es ist interessant, dass in einem Bereich, der gefühlt erst 1–2 Jahre Berufserfahrung alt ist, schon „Autoritäten“ auftauchen. Das wirkt wie die umgekehrte Version des Memes „10 Jahre Erfahrung in einer 2 Jahre alten Sprache“
  • Ich baue sogenannte „ai agent“-Systeme seit dem Erscheinen von GPT-3, und viele andere haben ähnliche Erfahrungen gemacht. Das sind inzwischen schon 5 Jahre, und wenn in 5 Jahren noch keine Experten entstanden sind, dann gibt es vielleicht einfach keine Experten. Natürlich wird das Wort „Agent“ heutzutage immer mehr zum Buzzword, wodurch seine Bedeutung verwässert
  • Wenn man dann Aussagen liest wie „Ich habe mit Dutzenden Teams gearbeitet ...“, wirkt das schon etwas dramatisch
• Kurzfassung: Wenn es bereits eine vordefinierte Lösung gibt, braucht man keinen Agenten zu verwenden (z. B. die im Artikel erwähnten „Patterns“). Normalerweise empfehlen Programmierer für Probleme, die sich als Programm lösen lassen, eine einfachere und zuverlässigere Lösung. In Zukunft wird AI vielleicht wirklich so schlau sein, dass sie jedes Problem per Brute Force löst, aber im Moment erhöht das nur die Komplexität. Ich denke, ein Grund, warum Menschen so begeistert von Agenten sind, ist, dass die meisten mit LLMs über Chat-Assistenten in Berührung gekommen sind. Bei solchen Chat-Assistenten gibt es oft keine feste Lösung und die Interaktionen sind komplex, sodass Agenten hier eher ihre Stärken ausspielen. Beispiel: „Finde den nächsten Freitagabend und schreib Bob per SMS, ob er sich treffen kann“ — dafür alle Fälle im Voraus zu programmieren, hat Grenzen. Weil die Interaktionsmöglichkeiten mit einem Assistenten nahezu unendlich sind, passen Agenten hier gut
  • Es funktioniert sehr gut, wenn die Verifizierungsgeschwindigkeit höher ist, als es selbst direkt zu machen. Allerdings fällt es mir schwer, AI ohne Verifikation zu vertrauen
• Ich frage mich, warum so viele Beispiele am Ende darauf hinauslaufen, „Spam schneller und besser zu verschicken“
  • War das nicht tatsächlich das Beispiel? Leute über LinkedIn crawlen, sie finden und mit „personalisierten“ E-Mails zuspammen
  • Das lässt sich mit dem Bild vergleichen, dass sich das Rad am Ende doch nicht ohne Schmiermittel dreht
• Ende 2023 bis Anfang 2024 stimmte das vielleicht, aber inzwischen, also etwa mid 2025, trifft das meiner Meinung nach für viele Aufgaben nicht mehr zu, wenn man SOTA-LLMs verwendet. Früher hat man LLMs oft einfach wie Funktionen aufgerufen, aber das lag auch an der Wahl des falschen Werkzeugs. Heutige Spitzen-LLMs (Gemini 2.5 Pro, Claude 4 usw.) sind wirklich intelligent und sehr gut bei Instruction Following und Tool-Auswahl. Checklist-Tools, Delegate-Befehle, Aufgabenteilung usw. sind weiterhin nötig. Aber ein Ansatz, bei dem man Anweisungen formuliert und Kommandos festlegt — besonders wenn sich Tool-Kommandos in einer UI leicht definieren lassen — ist flexibler und eine Ebene höher abstrahiert als Workflows. Auch visuelle Workflows sind letztlich fragiles, schwer feinzujustierendes Programmieren. Vor 6–12 Monaten war so etwas noch nicht möglich, aber wenn das LLM nicht gut genug ist, gilt das weiterhin nicht. Im Großen und Ganzen lohnt es sich, Agenten auf die wenigen Modelle anzuwenden, die gut in Instruction Following und Tool-Integration sind. In den nächsten 1–2 Jahren wird es einen großen Trend zu Browser-/Computer-Use-Agenten geben. Diese werden außerdem gute Memory-Systeme und einen „Demonstration/Observation Mode“ integrieren, damit sie lernen (aufzeichnen), wie Nutzer mit UIs arbeiten, und auch optimierte Prozeduren aus menschlichen mündlichen oder schriftlichen Anweisungen lernen
  • Mit dem Auftauchen der zuletzt besonders starken Agentenmodelle (Claude Opus 4 usw.) hat sich die Lage komplett verändert. Guter Kontext ist zwar immer noch nötig, aber die präzise Auswahl von Tools ist wirklich hervorragend
  • Die Techniken im Originalpost laufen größtenteils darauf hinaus, Probleme als „Dataflow-Graphen“ zu modellieren und diese dann einfach abzuarbeiten. Wenn man über die Modellierung hinaus einfach nach dem Motto „wird schon irgendwie klappen“ vorgeht, dann ist das keine Ingenieursarbeit, sondern Glaube
• Ich habe in den letzten 3 Wochen versucht, Agenten stabil zum Laufen zu bringen, bin am Ende aber auf ein deutlich einfacheres Pattern umgestiegen. Die heutigen Agenten wirken auf mich wie Hände mit sechs Fingern — ein sehr frühes Evolutionsstadium
• Wenn man Dinge liest wie „Der Koordinator gibt auf, wenn die Aufgabenstellung nicht klar definiert ist“ und daraus schließt „Dann wirf auch den Koordinator weg und geh zu imperativer Logik über“, dann könnte das in Wirklichkeit ein Problem sein, das sich lösen ließe, wenn man Prompts oder Tool-Beschreibungen konkreter formuliert und Verfahren wie Zwischenzusammenfassungen oder LLM-Kontextkomprimierung einbaut. Wenn im Artikel nicht einmal wirklich nutzbare lange Beispiele für Tool-Beschreibungen/Prompts vorkommen, ist ein Urteil schwer. Intuitiv ist die Antwort, eine zur Aufgabe passende Orchestrierung zu nutzen, aber ich glaube, dass sich in der Praxis agentische Orchestrierung bei viel mehr Aufgaben effektiv einsetzen lässt
• Ich stimme auch zu 100 % zu. Agenten machen wirklich Spaß und eignen sich gut zum Experimentieren, aber um die echte Produktivität zu steigern, kommt es vor allem darauf an, bestimmte Workflows und Prozesse gut zu orchestrieren und sich auf die Teile zu konzentrieren, die nur mit AI möglich sind. Nebenbei bemerkt empfehle ich auch den Text über AI-Workflows auf ai.intellectronica.net
• Was ich derzeit oft sehe, ist, dass bestehende Workflow-Orchestrierungs-Tools mit LLMs ergänzt werden, wodurch sich Systeme viel einfacher bauen lassen. Der Großteil der Komplexität liegt bei a) dem Modell selbst (die aktuellen Labs liefern leicht nutzbare Modelle), b) der Produktivsetzung von Workflows (was Workflow-Tools erleichtern). Da diese Workflows auf bestehender Arbeit basieren, lässt sich ihr Wert leicht erkennen und messen. Dieses Pattern tritt so häufig auf, dass sogar ein SDK speziell für Airflow (ein sehr populäres Workflow-Tool) als Paket veröffentlicht wurde.
  https://github.com/astronomer/airflow-ai-sdk

[sto1111]

Ich arbeite derzeit ebenfalls an einem Computer-Use-Agenten namens UseDesktop

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

und stimme dem größtenteils zu.

Der Beitrag behandelt eher nur einen groben Überblick als wirklich praktische Tipps. Wenn ich noch ein paar Hinweise zur Entwicklung von LLM-basierten agentischen Systemen bzw. Agenten ergänzen darf: LLMs basieren letztlich auf Transformern (d. h. probabilistischem Schlussfolgern; sie verstehen auf Basis des aktuellen Tokens/States den nächsten Token nicht wirklich kontextuell/semantisch und geben das nächste Wort nicht „bewusst“ aus, sondern erzeugen Outputs probabilistisch). Deshalb liefern sie selbst mit gutem System-Prompt oft nicht die gewünschte Antwort (z. B. wenn man eine Antwort im JSON-Format verlangt und gelegentlich eine } fehlt). Daher ist es Pflicht, immer mehrere regex-basierte Fallback-Funktionen hinzuzufügen.

Und wenn man einen System-Prompt für strukturierte Outputs schreibt, verwendet man in der Regel eher ein Non-Reasoning-Modell. Je länger der Kontext wird, desto häufiger treten Halluzinationen auf, daher ist es oft besser, mehrere System-Prompts zu erstellen und zu chainen.

Wenn man einen Service entwickelt, können verschiedene Fehler auftreten, deshalb ist es entscheidend, die Service-Architektur modular und fault-tolerant zu entwerfen (z. B. den Supervisor-Agenten asynchron und die übrigen Agenten synchron), besonders bei agentischen Systemen bzw. Agenten, bei denen häufig unerwartete Outputs auftreten.
Deshalb sollte man von Anfang an beim Schreiben des Codes möglichst das SRP einhalten und deklarativ arbeiten; ich würde sagen, dass ein funktionaler Ansatz sinnvoll ist (= keine Side Effects und ein intuitiver Flow).

Je nachdem, ob man LLMs über eine API nutzt oder die Modelle selbst serven will, sieht es etwas anders aus. Falls man jedoch ein SLM oder LLM selbst serven möchte, sollte man das Model Serving nicht auf demselben Server betreiben, auf dem auch das Backend gehostet wird. Es ist fault-toleranter und besser, IO-bound Tasks und CPU-bound Tasks (d. h. Tasks, die eine GPU benötigen, Matrixmultiplikationen usw.) auf getrennten Servern zu platzieren (z. B. CPU-bound Tasks auf Runpod hosten).

Es gibt noch viele weitere Entwicklungstipps, aber ich höre hier auf, bevor es zu lang wird.

Ich hoffe, das hilft jemandem.

[jypark]

Vielen Dank, dass Sie Ihre wertvollen Erfahrungen und Meinungen geteilt haben. Die Meinung von jemandem, der direkt vor Ort arbeitet, ist wirklich eine große Hilfe.