Die auf Large Language Models basierende Systemtechnik hat in produktiven Arbeitsumgebungen einen radikalen Wandel durchlaufen – weg von bloßen Texten und zufälligen Prompts, die mit einfachen Verkettungsskripten verbunden sind, hin zu strukturierten Ausführungsframeworks, die als Agentic Harnesses bekannt sind. Diese Entwicklung zielt darauf ab, probabilistische Modelle mit der notwendigen Softwareunterstützung zu umgeben, um Verlässlichkeit, Zuverlässigkeit und Beobachtbarkeit in realen Arbeitsumgebungen zu gewährleisten.
Phase eins: Chains und einfache lineare Abläufe
Frühe Systeme basierten auf einem vereinfachten linearen Arbeitsablauf, der als Chains bezeichnet wird. Dieser Ansatz zeichnet sich durch eine schnelle Ausführung und geringe Rechenkosten bei eng umrissenen Aufgaben wie einer einfachen Zusammenfassung aus. Die Idee beruht darauf, die Ausgabe des ersten Schritts als Eingabe für den zweiten Schritt zu verwenden und so weiter, wobei die Modelle als Black Boxes fungieren, die Texte empfangen und ausgeben.
Beispielsweise nutzte LinkedIn in seinen frühen Phasen feste Chains, die Klassifizierung und Routing, gefolgt von Datenabfragen über Suchwerkzeuge zur Anreicherung der Antwort, sowie schließlich Generierung und Filterung umfassten. Trotz der schnellen Entwicklung litten diese Systeme strukturell unter Anfälligkeit; denn jeder Fehler in einem frühen Schritt führte zum Ausbruch des gesamten Arbeitsablaufs, da Mechanismen zur automatischen Reaktion und Korrektur fehlten.
Phase zwei: Graphen zur Stärkung von Struktur und Kontrolle
Mit der wachsenden Komplexität der Anwendungsfälle verlagerten sich die Entwickler auf die Verwendung von Graphen (Graphs), um bedingte Verzweigungen, Parallelisierung, Wiederholungen und die Verwaltung des Zustands (State Management) einzuführen. Die Knoten in diesen Strukturen repräsentieren die verschiedenen Aufgaben, während Kanten den Kontrollfluss steuern.
Diese Strukturen ermöglichten den Entwurf von Multi-Agenten-Systemen (Multi-Agent Systems) mit einem Hauptkoordinator, der den Aufgabenfluss und die asynchrone Nachrichtenübermittlung verwaltet, um Reihenfolge und Kontinuität zu gewährleisten. Diese Architekturen wurden beim Start des Recruiting-Assistenten (Hiring Assistant) eingesetzt, um Personalverantwortlichen die Automatisierung von Routineaufgaben zu ermöglichen. Dennoch blieben diese Frameworks an vom Menschen festgelegte Arbeitsabläufe gebunden, was ihre Wartung bei der Ausweitung von Ausnahmefällen komplex machen kann.
Phase dritte: Programmierung als wesentliches Werkzeug für das Schließen
Die neueste Entwicklung besteht in der Verwendung von Programmcode anstelle visueller sprachlicher Prompts als Hauptmittel für das Schlussfolgern. Anstatt Probleme nur textuell zu interpretieren, generieren und führen diese Architekturen Code in isolierten, getesteten Umgebungen aus.
Programmcode zeichnet sich im Vergleich zu den ungarantierten probabilistischen Ausgaben von Sprachmodellen durch seine deterministische, verifizierbare Natur aus. Diese Architektur basiert auf einer isolierten Ausführungsumgebung, Protokollierungs- und Überwachungswerkzeugen, automatischen Verifizierungsstrukturen sowie iterativen Debugging-Schleifen, die Fehler korrigieren und Codes so lange neu ausführen, bis die erforderlichen Standards erreicht sind. LinkedIn hat diesen Ansatz intern angewendet, um Mitarbeitern Datenabfragen über strukturierte Abfragesprachen und Python im Rahmen von Datenschutz- und Governance-Frameworks zu ermöglichen.
Best Practices für das Engineering agentischer Systeme
- Umgang mit Ausgaben als nicht vertrauenswürdige Daten: Die Notwendigkeit, die Validität von Modell-Ausgaben zu überprüfen, bevor sie an eine nachfolgende Programmlogik übergeben werden.
- Trennung von Planung und Ausführung: Dem Modell erlauben, Pläne vorzuschlagen, während ein strenges Software-Framework die Ausführung übernimmt.
- Investition in die Überwachung: Genaue Verfolgung von Ausführungssituationen, um Fehler und Zustandsprotokolle zu überprüfen, ohne sensible Daten zu gefährden.
- Kontinuierliche Entwicklung: Aufbau analytischer Feedbackschleifen, um die Systemleistung im Laufe der Zeit zu verbessern.
Auswahl der geeigneten technischen Abstraktion
Nicht jedes technische Problem erfordert die betriebliche Komplexität von Graphen oder fortgeschrittenen Programmiercodes. Einfache Chains bleiben bei direkten Aufgaben wie der Zusammenfassung und Inhaltsverarbeitung die am besten geeignete und kostengünstigste Option hinsichtlich Zeit und Rechenleistung. Graphen hingegen werden notwendig, wenn Verzweigungen und Zustandssteuerung erforderlich sind, während Programmier-Frameworks in kritischen Bereichen eingesetzt werden, die strenge Genauigkeit und Verifikation erfordern, wie etwa im Software Engineering und bei der komplexen Datenanalyse.