Effektive AI-Agenten entwickeln

 (anthropic.com)
8 Punkte von GN⁺ 2025-06-18 | 1 Kommentare | Auf WhatsApp teilen
  • Nach den Praxiserfahrungen von Anthropic beginnen erfolgreiche LLM-Agenten oft mit einfachen, kombinierbaren Mustern statt mit komplexen Frameworks
  • Agentische Systeme lassen sich in Workflows unterteilen, die festgelegten Codepfaden folgen, und Agenten, bei denen das LLM Verfahren und Tool-Nutzung dynamisch entscheidet
  • Für viele LLM-Anwendungen reicht ein einzelner LLM-Aufruf mit Retrieval und In-Context-Beispielen aus; die Komplexität sollte nur dann erhöht werden, wenn Evaluierungen einen Nutzen belegen
  • Frameworks beschleunigen den Start, können aber durch eine Abstraktionsschicht, die Prompts und Antworten verdeckt, das Debugging erschweren
  • Autonome Agenten sind stark bei offenen Problemen, bringen aber höhere Kosten und das Risiko kumulierter Fehler mit sich; daher sind Sandbox-Tests, Guardrails und klarer Tool-Entwurf nötig

Grundlegende Unterscheidung agentischer Systeme

  • Agentische Systeme ist ein weit gefasster Begriff, der von vollständig autonomen Systemen reicht, die lange Zeit unabhängig arbeiten, bis hin zu Implementierungen, die vordefinierten Workflows folgen
  • Anthropic betrachtet all diese Varianten als agentische Systeme, teilt sie architektonisch aber in zwei Kategorien ein
    • Workflows: LLMs und Tools werden entlang eines vordefinierten Codepfads orchestriert
    • Agenten: Das LLM weist dynamisch an und steuert, wie eine Aufgabe ausgeführt wird, welches Verfahren verwendet wird und welche Tools zum Einsatz kommen

Kriterien für die Entscheidung, wann Agenten sinnvoll sind

  • Für LLM-Anwendungen wird empfohlen, mit der einfachstmöglichen Lösung zu starten und die Komplexität nur bei Bedarf zu erhöhen
  • Agentische Systeme erkaufen sich bessere Aufgabenleistung mit Latenz und Kosten; deshalb sollte zuerst geklärt werden, ob dieser Trade-off tatsächlich nötig ist
  • Selbst wenn Komplexität erforderlich ist, unterscheiden sich die Auswahlkriterien
    • Für klar definierte Aufgaben bieten Workflows Vorhersagbarkeit und Konsistenz
    • Für Aufgaben, die große Flexibilität und modellgesteuerte Entscheidungen erfordern, sind Agenten besser geeignet
  • Viele Anwendungen lassen sich bereits ausreichend optimieren, indem ein einzelner LLM-Aufruf mit Retrieval und In-Context-Beispielen verbessert wird

Kriterien für den Einsatz von Frameworks

  • Als Tools zur Implementierung agentischer Systeme werden Claude Agent SDK, Strands Agents SDK by AWS, Rivet und Vellum vorgestellt
  • Solche Frameworks vereinfachen Standardaufgaben auf niedriger Ebene wie LLM-Aufrufe, Tool-Definition und -Parsing sowie die Verknüpfung von Aufrufen und ermöglichen so einen schnelleren Start
  • Allerdings kann eine zusätzliche Abstraktionsschicht die tatsächlichen Prompts und Antworten verbergen und das Debugging erschweren
    • Sie kann selbst dann zu unnötiger Komplexität verleiten, wenn eine einfache Konfiguration ausreichen würde
  • Für Entwickler ist es meist besser, zunächst direkt mit der LLM-API zu arbeiten
    • Viele Muster lassen sich mit nur wenigen Zeilen Code umsetzen
    • Auch beim Einsatz eines Frameworks sollte man verstehen, wie der interne Code funktioniert
    • Falsche Annahmen über das Innenleben sind eine häufige Ursache für Kundenfehler
  • Beispielimplementierungen finden sich im Cookbook

Grundbaustein: das erweiterte LLM

  • Der grundlegende Baustein agentischer Systeme ist ein erweitertes LLM, das durch Funktionen wie Retrieval, Tools und Memory ergänzt wird
  • Aktuelle Modelle können diese Fähigkeiten aktiv nutzen, indem sie selbst Retrieval-Abfragen erzeugen, passende Tools auswählen und entscheiden, welche Informationen behalten werden sollen
  • Bei der Implementierung sollte man sich auf zwei Punkte konzentrieren
    • Die Fähigkeiten auf den jeweiligen Use Case abstimmen
    • Dokumentierte Schnittstellen bereitstellen, die für ein LLM leicht nutzbar sind
  • Als eine Implementierungsform wird das Model Context Protocol vorgestellt

Workflow-Muster

  • Prompt Chaining

    • Prompt Chaining teilt eine Aufgabe in aufeinanderfolgende Schritte auf, wobei jeder LLM-Aufruf die Ausgabe des vorherigen verarbeitet
    • Zwischenstufen können durch programmatische Prüfungen kontrolliert werden, um sicherzustellen, dass der Prozess auf dem richtigen Pfad bleibt
    • Es eignet sich, wenn sich eine Aufgabe sauber in feste Teilaufgaben zerlegen lässt
    • Der wichtigste Trade-off besteht darin, mehr Latenz in Kauf zu nehmen, um die Schwierigkeit jedes einzelnen LLM-Aufrufs zu senken und so die Genauigkeit zu erhöhen
    • Beispiele
      • Marketingtexte erzeugen und anschließend in eine andere Sprache übersetzen
      • Eine Dokumentgliederung erstellen, prüfen, ob sie Kriterien erfüllt, und darauf basierend das Dokument schreiben

  • Routing

    • Routing klassifiziert Eingaben und leitet sie dann an spezialisierte Folgeprozesse weiter
    • Es trennt Zuständigkeiten und ermöglicht spezialisiertere Prompts
    • Ohne diese Struktur kann die Optimierung für eine Eingabeart die Leistung bei anderen Eingaben verschlechtern
    • Es passt gut, wenn verschiedene Kategorien eine getrennte Verarbeitung erfordern und ein LLM oder ein klassisches Klassifikationsmodell bzw. ein Algorithmus sie zuverlässig unterscheiden kann
    • Beispiele
      • Kundenservice-Anfragen wie allgemeine Fragen, Erstattungsanträge oder technischer Support werden an unterschiedliche Prozesse, Prompts und Tools weitergeleitet
      • Einfache und allgemeine Fragen werden an kleinere, kosteneffiziente Modelle wie Claude Haiku 4.5 geroutet, schwierige oder ungewöhnliche Fragen an leistungsstärkere Modelle wie Claude Sonnet 4.5

  • Parallelisierung

    • Parallelisierung bedeutet, dass ein LLM eine Aufgabe gleichzeitig in mehreren Pfaden bearbeitet und die Ausgaben anschließend programmatisch zusammengeführt werden
    • Es gibt zwei Hauptvarianten
      • Sectioning: Eine Aufgabe wird in unabhängige Teilaufgaben zerlegt und parallel ausgeführt
      • Voting: Dieselbe Aufgabe wird mehrfach ausgeführt, um unterschiedliche Ausgaben zu erhalten
    • Sie ist effektiv, wenn sich Teilaufgaben zur Beschleunigung aufteilen lassen oder wenn für höhere Zuverlässigkeit mehrere Perspektiven oder Versuche benötigt werden
    • Bei komplexen Aufgaben kann jeder Aspekt von einem separaten LLM-Aufruf bearbeitet werden, sodass sich dieser stärker auf einen bestimmten Punkt konzentriert
    • Beispiele
      • Ein Modell verarbeitet die Nutzeranfrage, während ein anderes als Guardrail ungeeignete Inhalte oder Anfragen prüft
      • Bei der Bewertung von LLM-Leistung beurteilt jeder Aufruf einen anderen Aspekt der Modellleistung
      • Mehrere Prompts prüfen Code auf Schwachstellen und markieren ihn bei gefundenen Problemen
      • Bei der Bewertung problematischer Inhalte werden mehrere Prompts und ein Voting-Schwellenwert genutzt, um das Verhältnis von False Positives und False Negatives auszubalancieren

  • Orchestrator-Worker

    • Orchestrator-Worker beschreibt ein Muster, bei dem ein zentrales LLM eine Aufgabe dynamisch zerlegt, sie an Worker-LLMs delegiert und die Ergebnisse anschließend zusammenführt
    • Es eignet sich für komplexe Aufgaben, bei denen sich die benötigten Teilaufgaben nicht im Voraus vorhersagen lassen
    • Es wirkt ähnlich wie Parallelisierung, der entscheidende Unterschied ist jedoch die Flexibilität
      • Bei der Parallelisierung sind die Teilaufgaben vordefiniert
      • Beim Orchestrator-Worker entscheidet der Orchestrator abhängig von der Eingabe, welche Teilaufgaben nötig sind
    • Beispiele
      • Coding-Produkte, die bei jedem Durchlauf komplexe Änderungen über mehrere Dateien hinweg durchführen
      • Rechercheaufgaben, die potenziell relevante Informationen aus mehreren Quellen sammeln und analysieren

  • Evaluator-Optimizer

    • Evaluator-Optimizer ist eine Schleifenstruktur, bei der ein LLM eine Antwort erzeugt und ein anderes LLM Bewertung und Feedback liefert
    • Es ist besonders wirksam, wenn es klare Bewertungskriterien gibt und iterative Verbesserungen messbaren Wert schaffen
    • Zwei Signale sprechen für eine gute Eignung
      • Wenn Menschen Feedback klar formulieren, verbessert sich die LLM-Antwort tatsächlich
      • Das LLM ist in der Lage, solches Feedback zu geben
    • Das ähnelt dem iterativen Schreibprozess, den menschliche Autoren durchlaufen, wenn sie einen Text verfeinern
    • Beispiele
      • Literarische Übersetzungen, bei denen ein Evaluator-LLM Nuancen kritisiert, die das Übersetzungs-LLM zunächst übersehen hat
      • Komplexe Rechercheaufgaben, bei denen der Evaluator entscheidet, ob zusätzliche Recherche nötig ist

Autonome Agenten

  • Agenten kommen inzwischen in der Produktion zum Einsatz, weil LLMs komplexe Eingaben verstehen, schlussfolgern und planen, Tools zuverlässig nutzen und sich von Fehlern erholen können
  • Die Aufgabe beginnt mit einer menschlichen Anweisung oder einem Gespräch
    • Sobald die Aufgabe klar ist, erstellt der Agent einen Plan und arbeitet eigenständig weiter
    • Wenn zusätzliche Informationen oder Urteile nötig sind, kann er zum Menschen zurückkehren
  • Während der Ausführung ist es wichtig, in jedem Schritt reale Validierungssignale aus der Umgebung zu erhalten
    • Zum Beispiel Ergebnisse von Tool-Aufrufen oder Ergebnisse der Codeausführung
    • Darüber wird der Fortschritt bewertet
  • Agenten können an Checkpoints oder bei Blockaden anhalten, um menschliches Feedback einzuholen
  • Aufgaben enden häufig mit dem Abschluss, üblich sind aber auch Stop-Bedingungen wie eine maximale Zahl an Iterationen, um die Kontrolle zu behalten
  • Die Implementierung selbst ist oft einfach
    • Ein Agent ist meist ein LLM, das in einer Schleife auf Basis von Umgebungsfeedback Tools verwendet
    • Daher sollten Toolset und Dokumentation klar und sorgfältig entworfen werden
  • Einsatzbedingungen
    • Offene Probleme, bei denen sich die nötige Zahl von Schritten schwer oder gar nicht vorhersagen lässt
    • Aufgaben, bei denen kein fester Pfad hart kodiert werden kann
    • Situationen, in denen das LLM über mehrere Turns hinweg arbeiten kann und ein gewisses Vertrauen in seine Entscheidungen nötig ist
  • Einschränkungen
    • Mehr Autonomie geht mit höheren Kosten und der Möglichkeit kumulierter Fehler einher
    • Umfassende Tests in Sandbox-Umgebungen und geeignete Guardrails werden empfohlen
  • Beispiele

Muster kombinieren und anpassen

  • Die vorgestellten Bausteine sind keine festen Rezepte, sondern gemeinsame Muster, die Entwickler an ihren Use Case anpassen und miteinander kombinieren können
  • Wie allgemein bei LLM-Fähigkeiten liegt der Schlüssel zum Erfolg darin, die Leistung zu messen und die Implementierung iterativ zu verbessern
  • Komplexität sollte nur hinzugefügt werden, wenn sich die Ergebnisse dadurch tatsächlich verbessern

Implementierungsprinzipien

  • Erfolg im LLM-Bereich bedeutet nicht, das ausgefeilteste System zu bauen, sondern das richtige System für die jeweilige Anforderung
  • Empfohlen wird folgende Reihenfolge
    • Mit einfachen Prompts beginnen
    • Prompts durch umfassende Evaluierung optimieren
    • Erst dann mehrstufige agentische Systeme ergänzen, wenn einfache Lösungen nicht ausreichen
  • Bei der Implementierung von Agenten sind drei Prinzipien wichtig
    • Einfachheit im Design bewahren
    • Der Planungsprozess des Agenten sollte explizit sichtbar sein, Transparenz hat Vorrang
    • Das agent-computer interface, also ACI, sollte mit gründlicher Tool-Dokumentation und Tests sorgfältig entworfen werden
  • Frameworks helfen beim schnellen Start, beim Übergang in die Produktion kann es aber nötig sein, Abstraktionsschichten zu reduzieren und mit den Grundbausteinen direkt zu arbeiten

Praktische Einsatzbereiche

  • Kundensupport

    • Kundensupport verbindet eine vertraute Chatbot-Oberfläche mit Funktionserweiterung durch Tool-Integration
    • Es gibt Gründe, warum sich dieser Bereich natürlich für offenere Agenten eignet
      • Support-Interaktionen folgen einem Gesprächsfluss und benötigen zugleich Zugriff auf externe Informationen und Aktionen
      • Tools können integriert werden, um Kundendaten, Bestellhistorie und Dokumente aus der Wissensdatenbank abzurufen
      • Aufgaben wie Erstattungen oder Ticket-Updates können programmatisch ausgeführt werden
      • Der Erfolg lässt sich klar daran messen, ob die vom Nutzer definierte Lösung erreicht wurde
    • Mehrere Unternehmen haben die Umsetzbarkeit dieses Ansatzes mit nutzungsbasierten Preismodellen gezeigt, bei denen nur erfolgreiche Lösungen berechnet werden

  • Coding-Agenten

    • Im Bereich Softwareentwicklung hat sich mit der Entwicklung von LLM-Fähigkeiten von Codevervollständigung bis zu autonomer Problemlösung großes Potenzial gezeigt
    • Es gibt Gründe, warum Agenten hier effektiv sind
      • Codelösungen lassen sich durch automatisierte Tests verifizieren
      • Agenten können Testergebnisse als Feedback nutzen, um Lösungen iterativ zu verbessern
      • Der Problemraum ist gut definiert und strukturiert
      • Die Ausgabequalität lässt sich objektiv messen
    • In der Implementierung von Anthropic können Agenten allein anhand einer Pull-Request-Beschreibung reale GitHub-Issues im Benchmark SWE-bench Verified lösen
    • Auch wenn automatisierte Tests die Funktionsprüfung unterstützen, bleibt menschliches Review wichtig, um sicherzustellen, dass die Lösung den übergeordneten Systemanforderungen entspricht

Prompt Engineering für Tools

  • In jedem agentischen System sind Tools mit hoher Wahrscheinlichkeit ein zentraler Bestandteil
  • Tools ermöglichen es Claude, mit externen Services und APIs zu interagieren
    • In der API werden die genaue Struktur und Definition festgelegt
    • Wenn Claude einen Tool-Aufruf plant, enthält die API-Antwort einen Tool-Use-Block
  • Tool-Definitionen und Spezifikationen verdienen genauso viel Aufmerksamkeit im Prompt Engineering wie der Gesamtprompt

  • Wahl des Tool-Formats

    • Dieselbe Aufgabe kann auf verschiedene Weise spezifiziert werden
      • Dateibearbeitung kann als Diff oder als vollständiges Umschreiben einer Datei angegeben werden
      • Strukturierte Ausgaben können als Code in Markdown oder als Code in JSON zurückgegeben werden
    • Aus Sicht des Software Engineering mag das nur ein Formatunterschied sein, der sich verlustfrei konvertieren lässt; für ein LLM sind manche Formate jedoch deutlich schwerer zu erzeugen
      • Beim Schreiben von Diffs muss vor dem neuen Code bekannt sein, wie viele Zeilen sich in den Chunk-Headern ändern
      • Wenn Code in JSON geschrieben wird, kommen zusätzliche Zeilenumbrüche und das Escaping von Anführungszeichen hinzu
    • Bei der Wahl des Tool-Formats sollte verhindert werden, dass das Modell in unnötige Formatzwänge gerät
      • Vor dem Einstieg in ein restriktives Format genügend Thinking Tokens bereitstellen
      • Bei Formaten bleiben, die dem ähneln, was das Modell natürlich aus Internettext kennt
      • Format-Overhead wie das exakte Zählen von Zeilen in Tausenden Zeilen Code oder das Escaping von Code-Strings vermeiden

  • ACI-Design

    • In das Design des agent-computer interface (ACI) sollte ähnlich viel Aufwand fließen wie in Human-Computer Interaction (HCI)
    • Gute Tool-Definitionen enthalten oft Beispielnutzung, Edge Cases, Anforderungen an Eingabeformate und eine klare Abgrenzung zu anderen Tools
    • Parameternamen und Beschreibungen sollten so angepasst werden, dass das Modell sie leichter versteht
      • Das ähnelt dem Schreiben eines hervorragenden Docstrings für einen Junior-Entwickler im Team
      • Besonders wichtig ist das, wenn es viele ähnliche Tools gibt
    • Die Tool-Nutzung des Modells sollte getestet werden
      • In der Workbench können viele Beispielinputs ausgeführt werden, um Fehler des Modells zu erkennen und die Implementierung iterativ zu verbessern
      • Es wird empfohlen, Tools nach dem Poka-yoke-Prinzip so zu entwerfen, dass Fehler möglichst schwer passieren
    • Beim Bau eines Agenten für SWE-bench wurde mehr Zeit in die Tool-Optimierung investiert als in den Gesamtprompt
      • Ein Problem war, dass der Agent Fehler bei Tools machte, die relative Dateipfade nutzten, nachdem er das Root-Verzeichnis verlassen hatte
      • Nachdem das Tool so geändert wurde, dass es immer absolute Dateipfade verlangt, nutzte das Modell diesen Ansatz fehlerfrei

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-18
Meinungen auf Hacker News

  • Ich halte diesen Beitrag weiterhin für einen der guten Texte zu diesem Thema. Besonders gut fand ich, dass gleich zu Beginn klar definiert wird, was hier mit AI Agents gemeint ist
    Definiert wird es hier als „ein System, in dem ein LLM seinen eigenen Verarbeitungsprozess und die Nutzung von Tools dynamisch steuert und die Kontrolle darüber behält, wie eine Aufgabe erreicht wird“
    Außerdem fand ich gut, wie zwischen „Agents“ und „Workflows“ unterschieden wird und wie mehrere nützliche Workflow-Muster beschrieben werden
    Als der Beitrag zuerst erschien, habe ich mir dazu Notizen gemacht: https://simonwillison.net/2024/Dec/20/building-effective-age...
    Ein neuerer Beitrag von Anthropic ist https://www.anthropic.com/engineering/built-multi-agent-rese... — „How we built our multi-agent research system“, der ebenfalls sehr interessant ist; dazu habe ich auch Notizen zusammengestellt: https://simonwillison.net/2025/Jun/14/multi-agent-research-s...

    • Einer der Autoren von Building Effective Agents kam zu AIE und hielt auf Grundlage dieses Beitrags einen Vortrag, der gut ankam: https://www.youtube.com/watch?v=D7_ipDqhtwk
    • Der Beitrag über das Multi-Agent-Research-System ist hervorragend. Allerdings stimme ich der Aussage im Beitrag Building Effective AI Agents nicht zu, dass man frühe Systeme ohne Framework bauen sollte
      Für Lernzwecke klingt das sinnvoll, aber der erste Vorteil eines guten Frameworks besteht darin, LLMs verschiedener Anbieter leicht ausprobieren zu können
    • Ich halte die Workflow-Definition in diesem Beitrag für ungenau. Moderne Workflow-Engines folgen nicht nur vorab festgelegten Codepfaden; in solchen Fällen sind sie praktisch dasselbe wie Agents
      Es wirkt wie ein Versuch, Workflows neu zu definieren, um sie abzugrenzen, aber die meisten Agents sind letztlich nur iterative Workflows, die abhängig von LLM-Antworten dynamisch etwas aufrufen. Moderne Workflow-Engines sind sehr dynamisch
    • Weiß jemand, welches AI-Agent-Framework Anthropic verwendet? Es scheint nicht so, als hätten sie ein eigenes Framework veröffentlicht

  • Der Rat „Sie erleichtern den Einstieg, indem sie Standardaufgaben auf niedriger Ebene wie LLM-Aufrufe, Tool-Definition und -Parsing sowie das Verketten von Aufrufen vereinfachen, schaffen aber oft zusätzliche Abstraktionsschichten, die die zugrunde liegenden Prompts und Antworten verdecken und das Debugging erschweren. Sie verleiten dazu, Komplexität hinzuzufügen, obwohl einfachere Konstruktionen ausreichen würden. Entwicklern wird empfohlen, damit zu beginnen, die LLM-API direkt zu verwenden“ ist für mich mit Abstand der beste im ganzen Artikel
    Im Grunde ergibt es keinen Sinn, ein riesiges Framework zu verwenden, nur um im Wesentlichen ein Array von Strings an einen Webservice zu schicken
    Auch in einem Firmenprojekt haben wir LangChain und LangGraph entfernt; in der Praxis brachten sie keinen Mehrwert und erhöhten nur die Komplexität. Weil man den Boilerplate-Code des Frameworks behandeln musste, schrieb man am Ende sogar mehr Code als ohne Framework

    • langflow dürfte wohl auch in diese Kategorie fallen. Trotzdem sehe ich durchaus einen Zweck darin, mehrere Flows in ein gemeinsames Format zu bringen
      Man kann auch alle Schritte zur Bilderzeugung mit Stable Diffusion selbst ausführen oder Shader-Code direkt schreiben, aber wenn es mehr als einen Flow oder eine Aufgabe gibt und man experimentiert, ist comfy-UI oder ein Shader-Graph deutlich aufgeräumter

  • Ein halbes Jahr ist vergangen, und im AI-Bereich fühlt sich das nach einer ziemlich langen Zeit an. Vor ein paar Monaten habe ich diesen Beitrag mehrfach gelesen, aber inzwischen scheint die Agent-Entwicklung klar an einen Engpass geraten zu sein
    Sogar das neueste Gemini wirkt wie ein Rückschritt

    • Wenn man mehrere Agents laufen lässt, werden die Kosten hoch und der Return on Investment sinkt. Ein DeepSearch-Agent für Aktien nutzt sechs Agents und kostet etwa 2 Dollar pro Anfrage
      Multi-Agent-Orchestrierung ist schwer zu kontrollieren, und je besser die Modellleistung wird, desto geringer wird der Bedarf an Multi-Agent-Systemen. Umgekehrt gilt: Je schwächer die Modellleistung, desto eher sind eng begrenzte AIs geschäftlich sinnvoll
    • Was genau führt zu diesem Rückschritt? Ich frage mich, warum es nicht möglich sein sollte, sich selbst massiv zu forken, 24 Stunden parallel zu arbeiten, die Ergebnisse zu verifizieren und sich kontinuierlich weiterzuentwickeln
    • Man hat Schwierigkeiten, das Problem der Prompt Injection zu lösen, und das ist einer der Engpässe

  • Gibt es Beispiele für Agenten, die in realen Produktionsumgebungen Firmen Geld sparen und wirklich wertvolle Arbeit leisten? Also nicht so etwas wie Texte schreiben, um den leeren Platz auf einer Chipstüte zu füllen

    • ChatIPT war gut. Es löst echte Probleme mit Biodiversitätsdaten. Der Ausdruck „agentisch“ wird nicht verwendet, aber es schreibt und führt eindeutig Python-Code aus
      https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys...
      Ist noch in der Beta
      Laut Pressemitteilung bietet der Chatbot von Rukaya Johaadien Studierenden und Forschenden interaktive Unterstützung, die zwar Biodiversitätsdaten haben, Daten aber zum ersten Mal oder nur selten veröffentlichen. Er bereinigt und standardisiert Tabellen, erstellt grundlegende Metadaten und leitet sie an, gut strukturierte Datensätze als Darwin Core Archive auf GBIF.org zu veröffentlichen
      Bisher war es schwierig, hochwertige Daten aus Promotions- und Masterarbeiten oder kleineren Biodiversitätsstudien in großem Maßstab zu veröffentlichen. Denn für die Datenstandardisierung waren in der Regel Kenntnisse in Programmiersprachen, Datenmanagementmethoden und Spezialsoftware nötig
      Auch der Zugriff auf das Integrated Publishing Toolkit (IPT), die zentrale Anwendung zum Teilen von Daten im GBIF-Netzwerk, ist für Einsteiger anspruchsvoll. Da Zeit und Ressourcen der Node-Verantwortlichen begrenzt sind und Gelegenheitsnutzer sich jedes Jahr leicht an die genauen Abläufe und Details nicht mehr erinnern, lassen sich logistische und sprachliche Hürden mit Schulungen allein nur schwer überwinden
      „Datenstandardisierung ist schwierig, und Biologen sind nicht Biologen geworden, weil sie gerne programmieren oder Excel mögen; daher werden viele potenziell wertvolle Daten verworfen. Als ich sah, dass große Sprachmodelle sehr gut beim Generieren von Code und bei Datenaufgaben geworden sind, habe ich ein Tool gebaut, das nichttechnische Nutzer mit alltäglichen Fragen anleitet, unordentliche Daten so weit wie möglich verarbeitet und sie dann schnell und automatisch bei GBIF veröffentlicht“, erklärte sie
    • Bei louie.ai werden Agenten und agentisches Reasoning genutzt, um Rechercheaufgaben zu automatisieren, die Nutzer täglich erledigen
      Für jede eingehende Benachrichtigung oder jedes Ticket führt ein Agent eine Vorabrecherche in relevanten APIs, Datenbanken usw. durch, identifiziert False Positives und liefert mehr Kontext zu echten Problemen. Das spart menschliche Arbeitszeit und erhöht die Bearbeitungsgeschwindigkeit
      Dasselbe agentische Reasoning wird auch für Exploration verwendet: Über simples Text-to-SQL hinaus recherchiert ein LLM 2 bis 10 Minuten lang stellvertretend in Splunk, Databricks usw.
      Intern gibt es Werkzeuge wie eine semantische Schicht über Datenbanken sowie Analyzer für große Logs, Texte und Dataframes

  • Ich habe einen selbstgebauten n8n-Workflow ausprobiert, der fast genauso aufgebaut war wie im Artikel. Eine Antwort auf eine einfache Frage zu bekommen, kostete 3 Dollar und mindestens 3 Minuten
    Vorerst bleibe ich bei normaler Suche

  • Der Artikel erinnert gut daran, mit dem einfachsten funktionierenden Ansatz zu beginnen und Komplexität nur dann hinzuzufügen, wenn sie wirklich nötig ist
    Ein paar klar definierte LLM-Aufrufe und etwas leichte Glue-Logik ergeben meist ein System, das stabiler, leichter zu debuggen und deutlich billiger auszuführen ist. Auffällige, funktionsreiche Agenten erzeugen oft mehr Probleme, als sie lösen

  • Als jemand, der in einem Unternehmen arbeitet, das in der Produktion echte Agenten und keine Workflows hat, kann ich dem ersten Satz hier, „nutzt ein Agenten-Framework wie LangGraph“, überhaupt nicht zustimmen
    Wir haben genau das gemacht und mussten nach einem Monat alles wegwerfen; danach haben wir von Grund auf neu gebaut, und inzwischen skaliert das System ziemlich gut
    Fairerweise muss man sagen, dass es Raum für Agenten-Frameworks geben kann. Aber der Agentenbereich ist noch viel zu jung, als dass es schon ausreichend gute Frameworks geben könnte
    Bis zu einem gewissen Grad denke ich sogar das Gegenteil: Der Agentenbereich bewegt sich so schnell, dass es vielleicht überhaupt nie ein ausreichend gutes Framework geben wird

    • Das klingt eher so, als würdest du dem Artikel zustimmen. Im Original heißt es ebenfalls, dass man im vergangenen Jahr mit LLM-Agenten-Teams aus mehreren Branchen gearbeitet habe und die erfolgreichsten Implementierungen nicht mit komplexen Frameworks oder spezialisierten Bibliotheken gebaut wurden, sondern mit einfachen, kombinierbaren Mustern
      Frameworks erleichtern den Einstieg, können aber durch zusätzliche Abstraktionsschichten Prompts und Antworten verdecken und das Debugging erschweren; außerdem können sie Komplexität hinzufügen, auch wenn ein einfacherer Aufbau ausreichen würde. Deshalb wird empfohlen, direkt mit der LLM-API zu beginnen, da viele Muster mit wenigen Zeilen Code umsetzbar sind
    • Ich migriere gerade von einem Prototyp, der mit den Agenten-Tools von N8N gebaut wurde, zu einem selbst hostbaren echten System
      Ich habe viele Kommentare gesehen, dass die meisten pragmatischen Teams Dinge wie LangChain, LangGraph, Haystack oder Crew aufgegeben und durch einfacheren internen Code ersetzt haben, aber ich habe noch kein gutes Gefühl dafür, wie Teile wie Tool Calls in der Praxis tatsächlich implementiert werden
      Kannst du Links oder Dokumente teilen, auf die du deine Arbeit stützt?
    • Welche Aufgaben übernimmt dieser Agent?

  • Der Artikel ist von Dezember 2024, aber seltsamerweise fühlt er sich an, als wäre er schon sehr lange her

    • Trotzdem finde ich persönlich, dass er sich auch heute noch sehr gut gehalten hat. Ich nutze ihn weiterhin als Referenz und habe nicht das Gefühl, dass er veraltet ist
      Das war der Artikel, der mich Anthropic bei der Entwicklung von AI-Tools wieder als „pragmatischen Partner“ sehen ließ
    • „Oh nein, ich muss wieder meinen Kopf benutzen und 100 % des Codes selbst schreiben wie ein Höhlenmensch aus Dezember 2024“
      https://news.ycombinator.com/item?id=44260988

  • Der Agenten-Hype scheint sich inzwischen etwas gelegt zu haben

  • Die Aussage, man solle einfache, kombinierbare Muster verwenden, ist auf seltsame Weise beruhigend
    Mir gefällt, dass die Maxime „Mach eine Sache gut“ auch nach Jahrzehnten immer noch gültig ist. Kombinierbarkeit ist das Beste