Agenten zu entwerfen ist immer noch schwierig

 (lucumr.pocoo.org)
20 Punkte von GN⁺ 2025-11-23 | 1 Kommentare | Auf WhatsApp teilen
  • Der Aufbau von Agenten ist weiterhin komplex, und SDK-Abstraktionen brechen in der Phase der tatsächlichen Tool-Nutzung häufig auseinander
  • Cache-Management unterscheidet sich je nach Plattform; manuelle Verwaltung ist vorhersehbarer und effizienter, wobei der Ansatz mit expliziten Cache-Punkten im Anthropic SDK bevorzugt wird
  • Reinforcement-Loops spielen eine Schlüsselrolle bei der Nachverfolgung des Aufgabenstatus und der Wiederherstellung nach Fehlern; Fehler sollten separat isoliert werden, damit der Loop nicht kollabiert
  • Für das Management von gemeinsamem Zustand ist eine dateisystemähnliche Hierarchie wichtig, die als grundlegende Struktur für den Datenaustausch zwischen Code-Ausführung und Inferenz-Tools dient
  • Output-Tools und Modellauswahl bleiben schwierig; Modelle wie Haiku, Sonnet und Gemini bleiben zentrale Optionen, was die anhaltende Komplexität des Agenten-Designs zeigt

Auswahl des Agenten-SDK

  • Beim Aufbau eines Agenten muss entschieden werden, ob die Basis-SDKs von OpenAI, Anthropic usw. direkt verwendet werden oder höherstufige Abstraktionsschichten wie das Vercel AI SDK oder Pydantic
    • Der Autor erwähnt, dass er in der Vergangenheit nur die Provider-Abstraktion des Vercel AI SDK genutzt hat, diese Entscheidung heute aber nicht noch einmal treffen würde
  • Da die Unterschiede zwischen den Modellen groß sind, muss man selbst eine Abstraktionsschicht für Agenten bauen; die vorhandenen Abstraktionen der bestehenden SDKs sind dafür nicht geeignet
    • Es gibt feine Unterschiede bei Cache-Steuerung, Reinforcement-Anforderungen, Tool-Prompts usw.
  • Das Vercel SDK verursacht Probleme bei der providerseitigen Tool-Verarbeitung
    • Es gibt Fälle, in denen das Web-Such-Tool von Anthropic den Nachrichtenverlauf beschädigt
    • Bei direkter Nutzung des Anthropic SDK sind Cache-Management und Fehlermeldungen klarer
  • Das Fazit lautet, dass derzeit ein Ansatz mit direkter SDK-Nutzung ohne Abstraktionsschicht vorteilhafter ist

Erkenntnisse zum Cache-Management

  • Die Caching-Ansätze unterscheiden sich je nach Plattform; Anthropic verlangt für Caching Gebühren und erfordert explizite Verwaltung
    • Manuelle Verwaltung wird bevorzugt, weil sie Kosten und Cache-Auslastung besser vorhersehbar macht
  • Explizites Caching ermöglicht die Ausführung verzweigter Dialoge oder Context Editing
    • Es werden mehrere Cache-Punkte gesetzt, etwa nach dem System-Prompt oder im frühen Teil des Gesprächs
  • Um den Cache zu erhalten, bleiben System-Prompt und Tool-Auswahl statisch; dynamische Informationen wie die Uhrzeit werden in späteren Nachrichten übermittelt
  • Reinforcement-Loops werden zusammen mit dem Cache aktiv genutzt, um Kostenvorhersagbarkeit und Kontrolle zu verbessern

Reinforcement innerhalb des Agenten-Loops

  • Bei der Tool-Ausführung können neben reinen Ergebnissen auch Informationen wie Ziel, Aufgabenstatus und Fehlerursachen wieder in den Loop eingespeist werden
  • Tools zur Selbstverstärkung (self-reinforcement) wie das Todo-Write-Tool in Claude Code helfen dem Fortschritt des Loops
  • Bei Umgebungsänderungen oder der Wiederherstellung nach Fehlern wird Information über Zustandsänderungen eingespeist, um die Stabilität des Loops zu sichern
    • Beispiel: Wenn auf Basis beschädigter Daten erneut versucht wird, wird eine Nachricht eingefügt, die zur Rückkehr zu einem früheren Schritt auffordert

Fehler isolieren (Isolate Failures)

  • Aufgaben, bei denen wiederholte Fehlschläge zu erwarten sind, werden in einen Subagenten (subagent) ausgelagert; nur erfolgreiche Ergebnisse werden an den übergeordneten Loop gemeldet
    • Zusammenfassungen fehlgeschlagener Versuche dienen als Lernmaterial für die nächste Aufgabe
  • Im Anthropic SDK können Fehlerprotokolle mit der Funktion Context Editing entfernt werden
    • Dabei bleibt nicht die gesamte Fehlerinformation erhalten, sondern nur die notwendigen Teile
    • Allerdings kann Context Editing den Cache ungültig machen und so die Kosten erhöhen

Subagenten und gemeinsames Dateisystem

  • Die meisten Agenten basieren auf Code-Ausführung und -Generierung und benötigen daher einen gemeinsamen Datenspeicher
    • Dafür wird ein virtuelles Dateisystem (VFS) verwendet
  • Verschiedene Tools für Bildgenerierung, Komprimierung oder Inferenz müssen denselben Dateipfad gemeinsam nutzen
    • Die Tools ExecuteCode und RunInference müssen auf dasselbe Dateisystem zugreifen können
  • Diese Struktur ist wesentlich, um Engpässe beim Datenaustausch zu beseitigen und zusammenhängende Arbeitsschritte innerhalb des Loops zu verarbeiten

Output-Tool

  • Agenten arbeiten nicht in einer Chat-Sitzung, sondern in einem internen privaten Nachrichten-Loop; die Kommunikation nach außen erfolgt über ein Output-Tool
    • Das Output-Tool übernimmt externe Kommunikation wie das Versenden von E-Mails
  • Die Steuerung von Ton und Stil des Output-Tools ist schwierig; bei Nutzung eines unterstützenden LLMs (Gemini 2.5 Flash) kommt es zu Qualitätsverlust und Verzögerungen
    • Untergeordnete Tools verfügen nicht über ausreichend Kontext und erzeugen daher ungenaue Ergebnisse
  • Wenn beim Ende des Loops kein Output-Tool aufgerufen wird, wird durch das Einfügen einer Reinforcement-Nachricht ein Aufruf ausgelöst

Modellauswahl

  • Haiku und Sonnet liefern starke Leistung bei Tool-Calls und werden deshalb als Hauptmodelle im Loop verwendet
  • Gemini 2.5 eignet sich für die Zusammenfassung großer Dokumente, PDF-Verarbeitung und die Extraktion von Bildinformationen
    • Das Sonnet-Modell hat den Nachteil, häufig an Sicherheitsfiltern zu scheitern
  • Modelle der GPT-Reihe zeigen im Haupt-Loop keine großen Erfolge
  • Anhand der Token-Kosten allein lassen sich die Gesamtkosten nicht beurteilen
    • Ein besseres Modell für Tool-Calls kann dieselbe Aufgabe mit weniger Tokens erledigen

Tests und Evaluierungen (Evals)

  • Die Automatisierung von Tests und Evaluierungen für Agenten wird als das schwierigste Problem bezeichnet
    • Anders als bei Prompts ist eine einfache Bewertung in externen Systemen nicht möglich
    • Benötigt werden Observability oder Instrumentation auf Basis echter Ausführungsdaten
  • Es wird erwähnt, dass bisher noch keine zufriedenstellende Evaluierungsmethode gefunden wurde

Update zu Coding-Agenten

  • Bei Coding-Agenten gibt es keine großen Veränderungen
    • Kürzlich wird der Agent Amp getestet, und die Interaktionsstruktur zwischen Oracle-Subagent und Haupt-Loop wird hoch bewertet
  • Amp und Claude Code vermitteln den Eindruck eines entwicklerzentrierten Designs, das die eigenen Tools tatsächlich verwendet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-11-23
Hacker-News-Kommentare

  • Ich habe vor etwa 2 Jahren in diesem Bereich ein Unternehmen gegründet. Es läuft inzwischen gut.
    Was ich in den letzten 2 Jahren gelernt habe: Viele Techniken sind nur temporäre Optimierungen, um die aktuellen Grenzen von LLMs auszugleichen. Da sich die Technik schnell weiterentwickelt, ist das Problem von heute morgen oft schon verschwunden.
    Als es bei AWS früher noch keine Festplattenverschlüsselung gab, hat unser Team 3 Monate damit verbracht, sie selbst zu implementieren, und kurz darauf hat AWS eine Standardverschlüsselung veröffentlicht, die sich mit einem Klick aktivieren ließ. Im Endeffekt war das vergeudete Zeit.
    Deshalb habe ich gelernt, dass manchmal gar nichts zu tun die beste Entscheidung ist.

    • Ich denke, das ist die zentrale Einsicht. Kollegen in meiner Firma veranstalten derzeit AI-Workshops und behaupten, neue Muster „erfunden“ zu haben, aber die meisten davon sind nächste Woche schon veraltet.
      Die Zeit, in der man Muster als gemeinsame Sprache gelernt hat, ist vorbei; heute beträgt die Halbwertszeit von AI-Mustern etwa eine Woche. Selbst wenn man 10 Experten fragt, was ein „agent“ ist, bekommt man 10 verschiedene Antworten.
    • Beim Tempo der AI-Entwicklung könnte es, wenn man nur lange genug wartet, am Ende einfach auf die direkte Nutzung von OpenAI hinauslaufen.
    • Mich würde interessieren, ob ihr ein profitables Modell habt, bei dem der Umsatz die Betriebskosten übersteigt. Ich fand es schwer vorstellbar, mit Agenten Geld zu verdienen. Was ist euer Geheimnis?
    • Gut zu wissen, wann man „nichts tun“ sollte, hängt damit zusammen, ob ein Team einschätzen kann, ob das Problem, an dem es arbeitet, ein Kernproblem oder eher ein Randproblem ist.
    • Stimme zu. Im Moment kann Warten auch eine Strategie sein. Wenn man aber zu lange wartet, kann man in die Falle geraten, bis zum Erscheinen von AGI einfach gar nichts mehr zu tun.

  • Ich habe in den letzten 2 Jahren verschiedene agent SDKs ausprobiert, und als ich selbst eines gebaut habe, war es viel komplexer als erwartet.
    Das Claude Code SDK (jetzt Agent SDK) ist hervorragend, aber noch nicht vollständig von Claude Code entkoppelt. Zum Beispiel müssen skills direkt im Dateisystem abgelegt werden.
    Das OpenAI SDK ist dank der starken Kopplung an die Plattform praktisch, weil sich Tracking und Evaluation automatisch im Dashboard erledigen lassen, aber die Anbindung von Drittanbieter-Modellen ist schwierig.
    Das Google Agent Kit hat noch kein Typescript-SDK, und Mastra ist unpraktisch, weil man dafür einen Server starten muss.
    Im Moment teste ich das SmythOS SDK, das bei der Wahl des Modellanbieters und der Definition der Architektur viel Freiheit lässt.
    Mich würde interessieren, ob eure aktuelle Struktur Agent → SubAgents → SubSubAgents ist oder eher vom Typ Planner-Executor.

    • Die meisten SDKs werden zum Albtraum, sobald man über die Grundfunktionen hinausgeht. Deshalb habe ich es mit der OpenRouter-Client-Bibliothek selbst implementiert.
      Das ist zwar mehr Code, aber das mentale Modell ist einfacher und dadurch viel leichter zu verstehen. Ich lasse eine ReAct-Schleife laufen, die reasoning und Tool-Aufrufe wiederholt.
      Letztlich kann man agent handoff oder Workflows auch ohne SDK selbst umsetzen.
    • Ich halte den Begriff „sub-agent“ für fast nutzlos. Letztlich ist es nur eine Abstraktion von Tool-Aufrufen; außerhalb der Hauptschleife zählt nur ein einfacher Ein-/Ausgabe-Vertrag.
    • Es hieß zwar, dass Claude Code nur Anthropic-Modelle unterstützt, aber mit Claude Code Router kann man auch andere Modelle anbinden.
    • Ich nutze die Go-Version von Google ADK. Sie ist noch unreif, aber ich bin zufrieden, weil Workflow-Komposition und Vendor-Kompatibilität gut sind.
    • Ich habe auch das Strands Agents SDK von AWS ausprobiert; es unterstützt die wichtigsten Vendor-APIs auch ohne Bedrock, und das API-Design ist sehr flexibel (ich arbeite bei AWS, aber das ist meine persönliche Meinung).

  • Ich teile ein paar Prinzipien für Agent-Design, die wir gelernt haben.

    1. Wenn viel Code generiert wird, ist Claude Code / Agent SDK am effizientesten.
    2. Ein größeres Risiko als Vendor-Lock-in ist es, ein Produkt zu bauen, das schlechter ist als ChatGPT.
    3. Claude Code hat ein starkes Selbstverständnis und beantwortet Fragen über sich selbst sofort präzise.
    4. Wenn man einem agent einen echten Computer gibt, wird er viel mächtiger. Wir nutzen e2b.dev, aber Modal ist auch gut.
      Zur Einordnung: Unsere Firma Definite ist eine Datenplattform, die wie Heroku von einem AI-Dateningenieur betrieben wird.
    • Claude ist kreativ, aber in komplexen Codebasen halluziniert es und betreibt reward hacking. In solchen Fällen ist Codex stabiler.
    • Ich denke, das Problem ist, dass viele Produkte mit schlechterer Qualität als die ChatGPT-Weboberfläche veröffentlicht werden.
    • Statt zwanghaft ein eigenes agent-System zu bauen, sollte man lieber fertige Tools wie Claude Code nutzen und sich auf die echte Wertschöpfung konzentrieren.
    • Natürlich ist es riskant zu sagen: „Überlassen wir alles Big Tech.“ Der Prozess des Selbstbauens, Lernens und Teilens ist wichtig. Ich wachse gerade selbst schnell mit ADK und einer VS-Code-Erweiterung.

  • Ich baue seit einigen Jahren agenten, und das Beste, was ich gemacht habe, war, ein eigenes Framework aufzubauen.
    Mehrere Open-Source-Abstraktionsschichten werden mit Veränderungen der SDKs unmöglich wartbar und brechen am Ende zusammen.

    • Ich sehe das genauso. Der Kern eines Agenten besteht aus strukturierten Ein-/Ausgaben, Tool-Registrierung und Aufrufschleife sowie Delegation zwischen Agenten.
      Ich habe OpusAgents auf Basis von PydanticAI gebaut; es ist einfacher als ein MCP-Server und dennoch ein skalierbares Open-Source-Framework.
    • Als Autor des Artikels stimme ich zu. Ich habe verwandte Gedanken in diesem Post festgehalten.
    • Als wir einen Chatbot für den Kundensupport gebaut haben, haben wir statt der bestehenden Struktur eine chatroom-basierte Architektur eingeführt. Das Frontend schickt einfach Nachrichten hinein, und das Backend erweitert die Funktionen schrittweise.
    • Ein vollständiges Framework selbst zu bauen, ist allerdings eine große Aufgabe. Langfristig könnten Agent-Plattformen so standardisiert werden wie Game-Engines.

  • Im Moment wiederholt sich dasselbe wie in der Frühphase von LangChain/RAG: übermäßige Abstraktion und Komplexität.
    Letztlich kann man einen agent einfach als REPL-Struktur verstehen (Read, Eval, Print, Loop).
    Eine leichtgewichtige Version, die ich auf diesem Konzept selbst implementiert habe, war deutlich stabiler als schwere SDKs.

    • In wirklich komplexen Anwendungsfällen braucht man aber spezialisierte subagents und Datenfreigabestrukturen. Eine einfache Schleife stößt dort an ihre Grenzen.

  • Das schwierigste Problem bei agenten ist Testing und Evaluation (evals).
    Für die Bewertung mit externen Systemen gibt es zu viele Eingaben, und man muss Daten während der Ausführung beobachten.
    Ich bin noch nicht sicher, welcher Ansatz hier wirklich funktioniert.

    • Es macht mir Sorgen, dass die meisten AI-Agent-Deployments offenbar ohne formale Tests und nur nach Bauchgefühl erfolgen.
    • In Googles ADK-Evaluationsdokumentation steht, dass die Ergebnisse bei jedem Lauf unterschiedlich sind und es daher schwierig ist, klare Pass/Fail-Kriterien festzulegen. Am Ende bewertet dann wieder ein anderes LLM.

  • Selbst bei den Grundlagen der agent-Entwicklung fehlen klare Richtlinien.
    Zum Beispiel treten bei der Behandlung von Ein-/Ausgabetypen für Function-Tools beim Übergeben numerischer IDs Serialisierungsfehler oder Präzisionsverluste auf.
    Ich habe das letztlich gelöst, indem ich alles in Strings umgewandelt habe.
    In den OpenAI-Dokumenten (Link) und in einem Google-ADK-Issue (Link) heißt es,
    „das Ergebnis muss ein String sein“, aber die tatsächlichen Beispiele geben dicts oder Zahlen zurück. Diese Widersprüche sorgen für Verwirrung.

  • Ich nutze das Produkt einer bestimmten agentic coding company (den Namen nenne ich nicht)
    und bin zufrieden, weil sie sich um Modell-Releases, Evaluationen, Subagent-Verwaltung, Abrechnung und alles andere kümmern, sodass ich mich einfach auf die Arbeit konzentrieren kann.

    • Wahrscheinlich ist diese Firma Amp von Sourcegraph. Anfangs war es noch holprig, aber inzwischen ist es ziemlich ausgereift.

  • In den letzten zwei Monaten habe ich Agenten für verschiedene Aufgaben implementiert. Zuerst habe ich Claude Code verwendet, aber wegen Vendor-Lock-in und Nutzungsbeschränkungen habe ich eine eigene Runtime gebaut.
    Aktuell unterstützt sie nur OpenAI, ist aber so entworfen, dass sich auch Claude oder Gemini ergänzen lassen.
    Ich habe sie als Open Source veröffentlicht, falls es jemanden interessiert → agent-composer

  • Mein Tipp ist simpel: Kein SDK verwenden, sondern selbst eine while-Schleife schreiben und JSON verarbeiten.
    Nur wenn man Kontextgröße und Fehler direkt kontrolliert, kann man wirklich flexible Agenten bauen.