zufälliger Ausbruch darüber, wo wir mit KI-Agenten stehen:

Einige nennen sie nicht Agenten, sondern "Workflow-Agenten", die mit deterministischen Abläufen überall vorhanden sind und funktionieren. Jeder kann einfache Workflow-Agenten erstellen, sogar ohne Programmierkenntnisse mit Tools wie Zapier und n8n. Komplexe Workflow-Agenten erfordern viel mehr Überlegung, um zuverlässig und effizient gebaut zu werden. Ein komplexer Workflow für einen gängigen und wertvollen Anwendungsfall, mit relevanten Integrationen, kann als eigenständiges Geschäft fungieren und auch eine großartige GTM sein, um später in andere Workflows oder autonomere Arbeiten zu expandieren.

Immer mehr dynamische/autonome Agenten beginnen zu arbeiten und sind hilfreich für die Forschung (insbesondere wenn sie webbasiert sind) und beim Programmieren. Sie sind weniger zuverlässig, sobald man mehr Datenquellen hinzufügt (z. B. APIs). Nur-Lese-Agenten fühlen sich sicher und einfach zu testen, aber es ist beängstigend, autonomen Agenten zu erlauben, Maßnahmen zu ergreifen (zu schreiben). (Eine zufällige Idee dazu: Es wäre cool, wenn Tools wie ein CRM es dir ermöglichen würden, ein Entwicklungs-Mirror zu „forken“ und Automatisierungsexperimente durchzuführen, die du zurückrollen oder wieder zusammenführen kannst.)

Dynamische Agenten arbeiten gut, wenn sie (1) einen guten Plan erstellen und verfolgen können und (2) Aufgaben korrekt ausführen, während sie (3) den richtigen Kontext finden, um ihn in jeden Schritt (sowohl Planung als auch jede Aufgabe) einzuspeisen. Schließlich muss es (4) unterwegs reflektieren (entweder mit oder ohne menschliche Eingabe), damit es den Plan entsprechend anpassen und auch die Art und Weise verbessern kann, wie es fehlgeschlagene oder schlecht abschneidende Aufgaben ausführt.

Aufgabenplanung: Die Denkfähigkeiten von LLMs funktionieren gut für einfache Aufgabenlisten, die keinen privaten Kontext erfordern (wie tiefgehende Recherchen, nur eine Reihe von Websuchen während der Zusammenfassung). Wenn Sie viele Entitäten recherchieren möchten, funktioniert die tiefgehende Recherche nicht so gut, da das Aufgabenlistenmanagement relativ einfach ist. Tabellenkalkulationsbasierte KI-Tools funktionieren besser für die Recherche vieler Entitäten, da Sie das Aufgabenmanagement effektiv an die Tabelle auslagern, da das Übergeben langer Aufgabenlisten zwischen den Eingabeaufforderungen hier nicht funktioniert. Das Aufgabenmanagement in Codierungsagenten funktioniert bei einfachen Problemen, einfachem Code oder wenn Sie von Grund auf neu beginnen. Sobald Sie in komplexere, bereits bestehende Projekte eintauchen, sind sie weniger zuverlässig - und Entwickler erhöhen die Zuverlässigkeit, indem sie dokumentieren, wie ihr Code funktioniert und organisiert ist (.md-Dateien), was es dem Agenten ermöglicht, besser informierte Aufgabenlisten zu erstellen. Komplexer Code erfordert mehr Dokumente und schließlich das dynamische Abrufen nur relevanter Kontexte aus diesen Dokumenten. Viele Menschen/Geschäfte haben starke undokumentierte Meinungen über die richtige Reihenfolge/Herangehensweise/Tools, um ein Projekt anzugehen, und wir benötigen mehr Ansätze, um dies im Voraus und spontan zu dokumentieren. Ein weiterer Grund, warum Codierungs- und webbasierte Forschungsagenten gut funktionieren, ist, dass sie alle dasselbe Set von Tools verwenden, sodass es nicht notwendig ist, zu „lernen“, wie man diese Tools verwendet (mehr dazu im nächsten Abschnitt).

Aufgabenbearbeitung: Aufgaben sind normalerweise API-Aufrufe (die Authentifizierung erfordern und ein Verständnis dafür, wie man die API und die zugrunde liegende Datenstruktur verwendet - die einzigartig sein kann, wie in einem CRM oder einer DB mit benutzerdefinierten Tabellen/Spalten), LLM-Argumentation (z. B. Zusammenfassen), eine Kombination und sogar Workflow-Agenten*. Ein Forschungsagent ist im Grunde genommen nur eine Websuche und Zusammenfassung in einer Schleife. Programmieragenten führen CRUD-Operationen auf Ihrem Code-Bestand durch und möglicherweise Websuche, um APIs zu lernen. Authentifizierung und grundlegender API-Zugriff scheinen gelöst zu sein (MCPs passen hier), aber ich würde gerne mehr über kontextspezifische Werkzeuge sehen (den Benutzer fragen, aber auch bei der ersten Verbindung analysieren, in vorhandene Daten eintauchen, um zu verstehen, wie das Werkzeug verwendet wird, wie die Daten strukturiert sind, für welche Szenarien/Projekte wir das Werkzeug verwenden). Fehler/Reflexion/Feedback müssen in organisierte Lernprozesse umgewandelt werden, die als Kontext zurückgeführt werden, wenn es relevant ist. Dieselben Werkzeuge können für unterschiedliche Zwecke und auf unterschiedliche Weise zwischen Organisationen verwendet werden, und wir müssen dies irgendwie erfassen/dokumentieren, um Aufgaben gut auszuführen.

Kontext: Stellen Sie sich vor, Sie sind ein neuer Mitarbeiter in einem Unternehmen. Sie lernen während der Einarbeitung viel (und je besser die Einarbeitung, desto effektiver sind Sie von Anfang an), und dann gibt es das Lernen am Arbeitsplatz, das sich in Lernen aus der Erfahrung der Organisation („so machen wir das“) und Lernen aus eigener Erfahrung unterteilt - ersteres ist in großen Organisationen stärker ausgeprägt. Kontextmanagement ist ähnlich. Es gibt verschiedene Ebenen des Kontexts wie Meta (Benutzer/Unternehmen), projekt-/abteilungsspezifisch, aufgabenbezogen, werkzeugspezifisch usw. Wir haben uns von einfachen Systemaufforderungen zu hybriden RAG-Strategien (Vektor, Schlüsselwort, Graph) weiterentwickelt, aber über das Vorhandensein der Daten/Kontexte hinaus benötigen wir Anleitung, wann und wie wir den Kontext abrufen, was wir in frühen Versionen heute sehen - aber es gibt viel Raum für Verbesserungen. Dies ist nicht nur ein technisches Problem, sondern auch ein geschäftliches Problem - da Sie im Grunde ein Einarbeitungsdokument erstellen müssen, das jedes Szenario abdeckt, das Sie erwarten. Wenn Projekte komplizierter werden, erfordert es mehr Überlegung, um den Kontext korrekt zu kürzen, sodass nur relevante Informationen in die Aufforderung aufgenommen werden, während irrelevanter Kontext minimiert wird.

Reflexion: Wir haben Überwachungstools für Agenten, die die Kosten für LLM/API abdecken, Beobachtungen, aber die Zuordnung von Erfolg/Misserfolg ist eine Herausforderung - ein Bereich, in dem codierte Agenten anderen gegenüber im Vorteil sind, ist eine deterministische Möglichkeit, Misserfolge zu bemerken (durch Testen des Codes). Für viele andere agentische Aufgaben sind wir noch dabei, den richtigen Weg zu finden, um menschliches Feedback zu sammeln, um zukünftige Ergebnisse zu verbessern. Soweit ich weiß, ist die Reflexion heute menschlich-in-der-Schleife, wobei das Feedback größtenteils an menschliche Entwickler weitergegeben wird, um den Agenten zu verbessern, aber der Durchbruch kommt, wenn wir herausfinden, wie wir Reflexion in Selbstverbesserung umwandeln - wo der Agent Erkenntnisse aus Misserfolgen bei der Generierung von Aufgabenlisten und der Ausführung von Aufgaben nutzt, um es beim nächsten Mal besser zu machen. Grundsätzlich muss die Reflexion in gut organisierte Kontexte umgewandelt werden, die nur dann in Eingabeaufforderungen gezogen werden können, wenn sie relevant sind. Dies entwickelt sich zu einer Feinabstimmung von Teilen des Agenten und dann zu agentischen RL-Umgebungen - fühlt sich hier immer noch ziemlich früh an.

*Früher habe ich erwähnt, dass Aufgaben an Workflow-Agenten übergeben werden, was sinnvoll wird, wenn Ihr Agent davon profitieren würde, keine Workflow-Agenten als Werkzeuge zu haben (im Gegensatz dazu, jedes Mal eine bekannte Aufgabenliste herauszufinden) oder wenn Ihr System kompliziert genug ist, dass spezialisierte Agenten mit spezialisiertem Kontext und Werkzeugen besser abschneiden. Oder wenn Sie Agenten nutzen, die von anderen Personen erstellt wurden (ein Muster, das ich hier begonnen habe zu sehen, sind natürliche Sprach-API-Endpunkte für eine einfachere Zusammenarbeit von Agenten).

Wenn wir die heutige Modellqualität mit einem unendlichen Inhaltsfenster (keine Qualitätsverschlechterung), unendlicher Rechenleistung, unendlichem Speicher, Browserzugang und einer Zahlungsmethode hätten, wäre eine einzige LLM-Schleife wahrscheinlich ausreichend, um viel zu erreichen. Der Punkt des sinnlosen Punktes oben (nichts ist unendlich) ist, dass die Agentenorchestrierung größtenteils darum geht, Einschränkungen zu verwalten, indem man Wege entwirft, um Arbeit vom LLM durch Struktur und Code auszulagern.

Agenten in der Produktion kommen in verschiedenen Ausführungen: als interne Werkzeuge, als eigenständiges Produkt, das verschiedene Werkzeuge kombiniert, und integriert als Funktion in ein Kernwerkzeug. Sie können allgemein oder spezialisiert sein. Chat-, Sprach- und Hintergrundagenten scheinen die häufigsten UI-Schnittstellen zu sein, um agentische Abläufe auszulösen.

Was fehlt mir noch?