Fünf Schichten eines KI-Agenten: vom Prompt zum funktionierenden System

Ein funktionierender KI-Agent erhält eine Aufgabe, ruft Informationen ab, verwendet Werkzeuge und passt seine nächsten Schritte an die Ergebnisse an. Das Sprachmodell interpretiert die Anfrage und wählt eine Aktion aus. Um die Aufgabe zu erledigen, benötigt es eine Softwareumgebung, die Informationen bereitstellt, Operationen ausführt und das Ergebnis prüft.

Die Architektur eines KI-Agenten lässt sich anhand von fünf technischen Aufgaben betrachten: Kontext vorbereiten, den Aktionszyklus steuern, Anfragen zuordnen, eine Ausführungsumgebung bereitstellen und Qualität bewerten. Diese Aufteilung hilft zu verstehen, woraus das System besteht und welcher Teil bei einem konkreten Problem verbessert werden sollte.

Die Schichten arbeiten zusammen. Die Nummerierung legt die Reihenfolge der Erläuterung fest; die konkrete Umsetzung hängt von der Aufgabe ab. Jev bezeichnet ein bestimmtes Produkt von TypeSafe. In der allgemeinen Architektur steht dieser Abschnitt für die Klassifikation und Weiterleitung von Anfragen.

Schicht	Aufgabe
Context	Welche Informationen das Modell vor der nächsten Aktion erhält
Loop	Wie der nächste Schritt gewählt wird und wann die Arbeit endet
Jev / Routing	Welche Entscheidungen getrennt vom Hauptagenten bearbeitet werden können
Harness	In welcher Umgebung der Agent arbeitet und welche Befugnisse er hat
Evals	Wie Qualität gemessen wird und Verschlechterungen erkannt werden

1. Context Engineering: Informationen für das Modell vorbereiten

Zum Kontext gehören Anweisungen, der bisherige Dialog, gefundene Dokumente, Werkzeugbeschreibungen und Ergebnisse vorheriger Operationen. Seine Zusammensetzung bestimmt, auf welche Informationen sich das Modell bei der nächsten Aktion stützen kann.

Die Größe des Kontextfensters allein entscheidet nicht über die Qualität einer Antwort. In einem langen Verlauf können relevante Informationen neben überholten Schlussfolgerungen, wiederholten Nachrichten und umfangreichen technischen Ausgaben stehen. Context Engineering bedeutet deshalb, die Informationen für jeden Schritt gezielt auszuwählen.

In der Praxis sind dafür mehrere Entscheidungen erforderlich:

• Dauerhafte Anweisungen definieren die Rolle, die Grenzen und die Anforderungen an das Ergebnis.
• Dokumente und umfangreiche Berechnungsergebnisse bleiben in externen Quellen. Das Modell ruft den benötigten Ausschnitt über ein verfügbares Werkzeug ab.
• Der Verlauf bewahrt wichtige Entscheidungen, das aktuelle Ziel und offene Fragen.
• Die Werkzeuge werden passend zur Aufgabe ausgewählt. Bei einem großen Katalog kann eine Werkzeugsuche die gleichzeitige Bereitstellung aller Beschreibungen ersetzen.

Ein Dokumentenlink ist nur hilfreich, wenn der Agent ihn tatsächlich öffnen kann. Ebenso muss eine Zusammenfassung des bisherigen Verlaufs die Einschränkungen und offenen Fragen erhalten, die später noch gebraucht werden.

Eine weitere Aufgabe ist die Wiederverwendung unveränderter Anfragebestandteile durch Prompt Caching. In der Claude API setzt ein Cache-Treffer beispielsweise voraus, dass das betreffende Präfix exakt übereinstimmt. Dauerhafte Anweisungen und wechselnde Daten sollten daher getrennt werden. Die Einsparung richtet sich nach den Konditionen des Anbieters und dem tatsächlichen Anteil der Cache-Treffer.

Für einen Entwicklungsagenten besteht ein hilfreicher Kontext aus der Fehlerbeschreibung, den relevanten Dateien, den Projektregeln und den Testergebnissen. Die gesamte Historie des Repositorys ist normalerweise nicht für jeden Modellaufruf erforderlich.

2. Loop Engineering: die Abfolge der Aktionen steuern

In einem festgelegten Workflow bestimmt das Programm die Reihenfolge der Schritte. In einem Agentenzyklus wählt das Modell den nächsten Schritt, nachdem das Ergebnis des vorherigen vorliegt. Die Architekturempfehlungen von Anthropic erläutern diesen Unterschied genauer.

Bei einer Fehlerbehebung kann der Agent Tests ausführen, die Fehlermeldung untersuchen, die passende Datei öffnen, eine Änderung vornehmen und erneut prüfen. Die Abfolge hängt von der gefundenen Ursache ab. Die Bedingungen, unter denen die Fehlerbehebung als abgeschlossen gilt, werden vorab festgelegt.

Ein steuerbarer Zyklus braucht vier Elemente: ein konkretes Ziel, eine Ergebnisprüfung, Abbruchbedingungen und ein Budget. Als Prüfung können ein Test, ein erfolgreicher Build, ein Datenabgleich oder ein bestätigter Zustand in einem externen System dienen. Die Aussage des Modells „fertig“ reicht dafür allein nicht aus.

Abbruchbedingungen umfassen den erfolgreichen Abschluss, fehlenden Fortschritt und das Erreichen eines Limits. Das Budget begrenzt die Zahl der Aktionen, die Dauer und die Kosten. Für eine unerledigte Aufgabe ist ein weiterer Weg vorgesehen: eine Rückfrage, ein festgelegter Ablauf oder die Übergabe an einen Mitarbeiter.

Ein Agentenzyklus ist sinnvoll, wenn der Arbeitsablauf von Zwischenergebnissen abhängt. Für eine bekannte Folge von Operationen bietet sich weiterhin ein herkömmlicher programmierter Ablauf an. Beide Ansätze können in einem System zusammenwirken: Standardfälle folgen festen Regeln, während der Agent Ausnahmen untersucht.

3. Jev Engineering: Klassifikation und Routing

Ein Teil der Systemarbeit besteht aus eng umrissenen Entscheidungen: eine Anfrage einordnen, die passende Verarbeitung auswählen oder eine Nachricht nach einem festgelegten Kriterium bewerten. Solche Operationen lassen sich in einer eigenen Schicht vor dem Start des Hauptagenten ausführen.

Ein Werkzeug dafür ist Jev von TypeSafe. Laut Dokumentation erhält das Modell Daten und Fragen mit einem vorgegebenen Antwortformat. Es unterstützt die Auswahl aus einer Liste, Bewertungen auf einer Skala und eine numerische Einschätzung des Wahrheitsgehalts einer Aussage. Das Ergebnis wird als strukturierte Werte zurückgegeben, die das Programm weiterverarbeitet.

Eingehende Anfragen lassen sich beispielsweise an die Dokumentation, die Bearbeitung typischer Fragen oder eine technische Untersuchung weiterleiten. Nur der letzte Weg benötigt einen Agenten, der das Problem schrittweise untersucht und Aktionen auswählt.

Ein korrektes Antwortformat garantiert dabei keine richtige Klassifikation. Eine gewählte Kategorie kann dem Schema entsprechen und trotzdem falsch sein. In der Produktankündigung von Jev bezieht der Entwickler die Aussage über ausbleibende Formatfehler ausdrücklich auf die Einhaltung des Schemas.

Auch der Confidence-Wert muss mit eigenen Daten geprüft werden. Jev berechnet ihn für Choice und Score aus der Wahrscheinlichkeitsverteilung; für Noul gibt es keinen separaten Confidence-Wert. Schwellenwerte für das Routing werden anhand der gemessenen Qualität und der Folgen einer Fehlentscheidung festgelegt.

Vor der Einführung wird diese Schicht mit einfachen Regeln oder einem herkömmlichen Klassifikator verglichen. Unsichere und ungewöhnliche Anfragen werden genauer untersucht. Jev ist eine mögliche Umsetzung; die Wahl des Werkzeugs sollte durch Ergebnisse mit den Aufgaben des Unternehmens begründet sein. Die Möglichkeiten des Produkts behandelt ein eigener Journal-Artikel.

4. Harness Engineering: Ausführungsumgebung und Zugriffskontrolle

Der Harness ist die Softwareumgebung, in der das Modell arbeitet: Werkzeuge, Dateisystem, Projektregeln, Isolation, Zugriffsrechte und Prüfungen von Operationen. Er bestimmt, welche Aktionen der Agent tatsächlich ausführen kann.

Diese Umgebung hat vier wesentliche Aufgaben.

Isolation. Der Agent arbeitet in einer eigenen Umgebung mit begrenztem Zugriff auf Dateien, Netzwerk und Daten. In der Entwicklung kann das ein Container mit einer separaten Arbeitskopie des Projekts und Zugriff ausschließlich auf eine Testdatenbank sein.

Anweisungen. Projektregeln, Werkzeugbeschreibungen und Beispiele für das erwartete Ergebnis unterstützen die Auswahl von Aktionen. In einem Repository lassen sich solche Regeln in einer AGENTS.md-Datei hinterlegen.

Prüfungen. Builds, Tests, Typprüfungen und andere automatisierte Kontrollen liefern Rückmeldung zur ausgeführten Arbeit. Ein Ablaufprotokoll hilft festzustellen, was vor einem Fehler geschehen ist.

Befugnisse. Der Zugriff wird auf die erforderlichen Operationen beschränkt. Das Vorbereiten einer Änderung, ihre Veröffentlichung und das Ändern von Produktivdaten können unterschiedliche Rechte erfordern.

Die ausführende Software setzt diese Grenzen durch. Eine Anweisung im Prompt hebt ein bereits erteiltes Schreibrecht des Benutzerkontos nicht auf. OWASP empfiehlt, Funktionen und Berechtigungen zu minimieren, die Autorisierung außerhalb des Modells durchzusetzen und für Aktionen mit erheblichen Folgen eine Bestätigung einzuholen.

Die Umgebung muss überprüft werden, wenn sich das Modell oder die Aufgaben ändern. Neue Fähigkeiten können Teile der Steuerungslogik vereinfachen. Änderungen an den Einschränkungen sollten jedoch auf geprüften Ergebnissen beruhen.

5. Evals Engineering: Qualität messen

Evals bestehen aus wiederholbaren Testaufgaben und Bewertungskriterien. Sie ermöglichen den Vergleich verschiedener Agentenversionen nach Änderungen am Modell, an Anweisungen, Werkzeugen oder Routing-Regeln.

Die Prüfungen erfassen das Ergebnis und wesentliche Aktionen. Bei einem Entwicklungsagenten wäre das Ergebnis ein behobener Fehler, während das geforderte Verhalten der Anwendung erhalten bleibt. Gesondert lässt sich prüfen, ob Zugriffsgrenzen eingehalten werden und eine Veröffentlichung wie vorgeschrieben freigegeben wird. Der genaue Lösungsweg sollte nur festgelegt werden, wenn es dafür einen Grund gibt: Unterschiedliche korrekte Lösungen können verschiedene Schrittfolgen verwenden.

Die erste Sammlung entsteht aus tatsächlichen Aufgaben und beobachteten Fehlern. Für jeden Fall werden Ausgangsdaten, das erwartete Ergebnis und eine Prüfmethode definiert. Neue Szenarien ergänzen die Sammlung im Laufe der Zeit.

Objektive Kriterien lassen sich programmatisch prüfen. Für eine inhaltliche Bewertung kann ein weiteres Modell eingesetzt werden, dessen Urteile zuvor mit denen von Fachleuten abgeglichen wurden. Dieses Vorgehen beschreibt die Methodik zur Bewertung von Agenten von Anthropic.

Die Ergebnisse werden nach Kategorien betrachtet: Ein Gesamtwert kann eine Verschlechterung in einem kritischen Szenario verdecken. Neben der Qualität werden die Bearbeitungsdauer, die Kosten pro Aufgabe und notwendige Eingriffe durch Mitarbeiter erfasst.

Wie die fünf Schichten zusammenarbeiten

Betrachten wir eine beispielhafte Aufgabe: einen Fehler in einer Webanwendung beheben. Das Routing erkennt den Anfragetyp und übergibt ihn an einen Entwicklungsagenten. Der Kontext stellt die Fehlerbeschreibung, die Projektregeln und die relevanten Dateien bereit. Der Aktionszyklus verbindet Diagnose, Änderungen und erneute Tests. Der Harness stellt die Arbeitsumgebung, Werkzeuge und Zugriffsgrenzen bereit. Evals prüfen, ob eine neue Agentenversion ihre Qualität bei einer Reihe ähnlicher Aufgaben beibehält.

Eine fertige Plattform kann einen Teil dieser Fähigkeiten bereits mitbringen. Bei der Auswahl wird geprüft, wie gut sie zu den Aufgaben des Unternehmens passt: welche Datenquellen und Integrationen sie unterstützt, wie sie die Befugnisse des Agenten begrenzt und wie sich die Ergebnisse bewerten lassen.

Diese Aufteilung hilft, Probleme einzugrenzen. Fehlende Informationen erfordern Arbeit am Kontext. Wiederholte Aktionen ohne Fortschritt sprechen für eine Überprüfung des Zyklus. Falsch zugeordnete Anfragen erfordern Routing-Prüfungen. Zu weitreichende Zugriffsrechte verlangen Anpassungen der Ausführungsumgebung. Qualitätsänderungen nach einem Update werden durch den Vergleich der Evals-Ergebnisse sichtbar.

Für ein Gespräch mit LindenTech über die Architektur eines KI-Agenten bereiten Sie eine konkrete Arbeitsaufgabe, die verwendeten Datenquellen, die erlaubten Aktionen und ein Beispiel für ein akzeptables Ergebnis vor. Damit lässt sich bestimmen, welche Teile des Systems bereits vorhanden sind und was entwickelt werden muss.