Startseite / Artikel / Das Erlernen des Agenten-basierten KI-Engineerings in der Reihenfolge, wie Ausfälle es lehren.

Das Erlernen des Agenten-basierten KI-Engineerings in der Reihenfolge, wie Ausfälle es lehren.

Ein strukturierter Einstieg in das Agenten-Engineering: Die Ausfallmuster, die Agenten aufweisen, der Kernstapel, fünf geordnete Projekte sowie die Zustands-, Überprüfungs- und Sicherheitsmuster, die ihre Sicherheit gewährleisten.

4569 Wörter

Entwickler, die sich dem Agentenengineering zuwenden, versuchen oft, alle Frameworks auf einmal zu erlernen – sie wechseln innerhalb einer Woche zwischen LangChain, CrewAI, AutoGen und LangGraph, ohne etwas fertigzustellen. Das Problem liegt in der Reihenfolge: Sie studieren die Tools, bevor sie verstehen, welche Fehler diese Tools verhindern sollen. Dieser Leitfaden zeigt einen vierzehn Schritte umfassenden Weg in der Reihenfolge auf, in der die Fähigkeiten tatsächlich voneinander abhängen – von Grundkenntnissen in Python bis hin zum Veröffentlichen eines unüberwachten Agenten. Unterwegs lernen Sie die drei Fehlermuster kennen, die jede Designentscheidung prägen, den kleinen Tool-Stack, der den größten Teil der Produktivitätsarbeit abdeckt, sowie die strukturellen Muster (Zustandsdateien, Überprüfung durch Maker-Checker, schichtweise Bewertung und Berechtigungsmanagement), die einen Demo-Code von einem System unterscheiden, dem man über Nacht vertrauen kann.

Teil 1: Das mentale Modell

1. Agentenengineering ist kein Prompt-Engineering mit neuem Namen

Prompt-Engineering befasst sich damit, zu formulieren, was man an ein Modell richtet. Agent-Engineering befasst sich damit, das System zu entwickeln, das entscheidet, woran das Modell arbeiten soll, wann es aufhören muss und wie es reagieren soll, wenn seine Antwort falsch ist.

Die praktische Definition ist konkret: Man entwickelt Software, in der ein LLM die nächste Aktion wählt, ein Tool aufruft, um sie auszuführen, das Ergebnis prüft und diesen Vorgang so lange wiederholt, bis die Aufgabe abgeschlossen ist – ohne dass ein Mensch bei jedem Schritt eingreift. Ein Chatbot antwortet auf eine Nachricht. Ein Agent wählt Aktionen aus, führt sie aus, überprüft die Ergebnisse und iteriert. Dieser Unterschied ist das ganze Konzept.

Das bringt drei Verantwortlichkeiten mit sich, die Prompt-Engineering nie erfordert hat:

Fehler als zentrales Problem betrachten. Agenten versagen ständig: APIs laufen ab, JSON-Dateien sind fehlerhaft, das Modell erfindet falsche Tool-Aufrufe und die Ausgaben der Tools entsprechen nicht den vorgegebenen Schemata. Code, der von einem erfolgreichen Ablauf ausgeht, bricht in dem schlimmstmöglichen Moment zusammen – meist während einer Demo.
Zustandsverwaltung. Ein einzelner LLM-Aufruf speichert nichts. Ein Agent, der zehn Schritte mit Tool-Aufrufen, Wiederholungen und Unteragenten durchführt, benötigt einen strukturierten, dauerhaften Zustand, der über ein einzelnes Kontextfenster hinaus bestehen bleibt.
Evaluierung in die Infrastruktur integrieren. Es gibt keine Intuition, die anzeigt, ob ein Agent richtig handelt. Man benötigt automatisierte Prüfmechanismen wie Tests, Bewertungskriterien oder ein Urteilsmodell, die fehlerhafte Ausgaben ablehnen, ohne dass jede Ausführung von einem Menschen überprüft werden muss.

Die Stellenbeschreibungen für diese Rollen lesen sich oft wie ein Katalog. Orchestrierungsframeworks (LangGraph, LangChain, LlamaIndex), Protokolle (MCP, A2A), Modellfunktionen (Funktionsaufrufe, strukturierte Ausgaben, Prompt-Caching), Suchmethoden (RAG, RAGAS, hybride Suche, Neubewertung, Embedding-Modelle, Vektor- und Graph-Datenbanken) sowie operative Fähigkeiten (Ausführung in Sandbox-Umgebungen, Überwachbarkeit, Bewertung) kommen alle vor – meist gefolgt von der Anforderung, mit schnellen Iterationen umgehen zu können. Die Liste wirkt überwältigend, doch die meisten Einträge basieren auf wenigen grundlegenden Konzepten unter unterschiedlichen Namen. Wenn man diese Konzepte versteht, fällt es leicht, die Produktbezeichnungen einzuordnen.

2. Drei Fehlermuster erklären den größten Teil der Arbeit

Vor dem Schreiben von Code sollte man verstehen, warum agierende Systeme versagen. Fast jedes Werkzeug und jedes Muster in diesem Bereich dient dazu, eines von drei Verhaltensmustern zu bekämpfen.

Agentische Trägheit. Wenn ein langfristiges, mehrteiliges Aufgabenprofil vorliegt, stoppt das Modell frühzeitig und gibt nach teilweiser Erledigung an, erfolgreich gewesen zu sein. Es bearbeitet 20 von 50 ausstehenden Aufgaben und beschreibt die restlichen als erledigt. Gegenmaßnahme ist eine explizite Stoppbedingung, die von etwas anderem als dem arbeitenden Modell überprüft wird.

Selbstbezogener Bias. Wenn ein Modell aufgefordert wird, seine eigene Ausgabe zu überprüfen, genehmigt es diese zuverlässig. Ein Prüfer, der in das Ergebnis investiert ist, kann dieses nicht objektiv beurteilen. Die Gegenmaßnahme ist strukturell: Das Modul, das die Arbeit erzeugt, darf nicht dasselbe sein, das sie überprüft.

Zielverfehlung. Über viele Schritte hinweg, insbesondere nachdem der Kontext zusammengefasst oder komprimiert wurde, verliert das System allmählich den Überblick über das ursprüngliche Ziel. Eine Einschränkung wie „den Zahlungsmodul unberührt lassen“ kann bereits im 47. Schritt stillschweigend verschwinden. Gegenmaßnahme ist eine dauerhafte Spezifikationsdatei, die bei jedem Ausführungsvorgang erneut gelesen wird und die Einschränkungen enthält, die das Modell sonst verlieren würde.

Falls das Ökosystem überwältigend wirkt, fragen Sie bei jedem neuen Tool oder Muster, welches dieser drei Probleme es adressiert. Diese Frage beseitigt den größten Teil des „Rauschens“.

3. Eine kleine Kernstack-Struktur und vier Dinge, die aufgeschoben werden sollten

Die Anforderungslisten sind lang, doch der Großteil der Arbeit mit Produktionsagenten basiert auf vier Schichten, die am besten in dieser Reihenfolge erlernt werden:

Core stack (learn these, in this order):
1. Python + async    : the bedrock; everything else builds on it
2. LLM APIs          : Anthropic, OpenAI; understand tokens, context, costs
3. Tool use / MCP    : function calling; how models act on the world
4. LangGraph         : stateful orchestration for multi-step, multi-agent work

Schieben Sie Folgendes auf, bis Sie mindestens einen echten Agenten veröffentlicht haben:

Fine-Tuning. Frühe Projekte benötigen es fast nie. Ein leistungsstarkes Grundmodell mit gut gestalteten Anweisungen ist in der Regel besser als ein fein abgestimmtes Modell mit schlechten Anweisungen.
Sich den Kopf über Vektordatenbanken zerbrechen. Tools wie Chroma eignen sich gut für den lokalen Einsatz, während verwaltete Dienste wie Pinecone in der Produktion geeignet sind. Warten Sie mit der Auswahl, bis das Abrufen von Daten tatsächlich zu einem Engpass in Ihrem Projekt wird.
Wechsel der Frameworks. Wählen Sie ein Orchestrierungsframework (LangGraph ist eine gute Standardwahl), beenden Sie ein Projekt und erkunden Sie erst danach weitere Optionen. Jede Woche die Tools zu wechseln, weil jedes als einfacher angepriesen wird, garantiert nicht, dass etwas fertiggestellt wird.
Stimmen- und Browser-Agenten. Das sind Spezialisierungen, die auf denselben Grundlagen basieren. Beherrschen Sie zunächst Text-Agenten – die Muster lassen sich darauf übertragen.

Teil 2: Die Bausteine

4. Python und asynchrone Code

Es ist nicht notwendig, sich in Python perfekt auszukennen, aber man sollte genug Kenntnisse haben, um Fehler zu debuggen – schließlich versagen Agenten häufig. Konzentrieren Sie sich auf:

Klassen und Datenmodelle. Agenten übergeben strukturierte Daten von Schritt zu Schritt, daher muss man diese modellieren. Ein Pydantic-Schema dient als Vertrag zwischen den Tool-Aufrufen und der Agentenlogik; betrachten Sie es als erforderlich und nicht als optional.
Asynchronität mit asyncio. Agenten verbringen viel Zeit damit, auf Tools zu warten: eine Datenbankabfrage, einen HTTP-Aufruf oder einen Unterprozess. Synchroner Code blockiert während jedes Wartens, während asynchrone Code andere Aufgaben erledigen kann. Langsamer Agentencode ist in den meisten Fällen synchroner Code, der nacheinander wartet.

HTTP und REST. Ohne APIs kann ein Agent nur denken, aber nicht handeln. Lernen Sie, API-Dokumentationen zu lesen, Rate Limits einzuhalten, Fehlerantworten zu interpretieren und sinnvoll erneut zu versuchen. Ein Tool, das bei HTTP 429 abstürzt, ist ein Tool, dem sich der Agent nicht anvertrauen kann.

Fehlerbehandlung. Umhüllen Sie jede Tool-Aufrufung mit try/except. Agenten laufen ohne Überwachung, und eine unverarbeitete Ausnahme, die einen Stack Trace ausgibt und beendet wird, hilft mitten in der Nacht niemandem.

Ein praktischer Richtwert: Wenn Sie eine Aufgabe an einen Junior-Entwickler mit einer Checkliste weitergeben und darauf vertrauen können, dass ein Testumfeld seine Fehler aufspürt, dann kennen Sie genug Python, um anzufangen. Mehr kann später hinzukommen.

5. Grundlagen von LLMs: Tokens, Kontext und Kosten

Modelle wie Claude, GPT und Gemini sind leistungsstark, benötigen aber Anleitung – und man kann nicht das steuern, was man nicht versteht.

Tokenisierung. Modelle lesen Token statt Wörter, und ein einziger Begriff kann je nach Tokenisierer in mehrere Token aufgeteilt werden. Als grobe Regel für Englisch enthält ein Kontext mit 100.000 Token etwa 75.000 Wörter. Alles, was außerhalb dieses Rahmens liegt – sei es das Gespräch von letzter Woche oder eine Datei, die man vergessen hat einzubeziehen – existiert für das Modell einfach nicht. Wenn etwas wichtig ist, muss es im Kontext enthalten sein.

Kontextgrenzen und Abruf. Modelle erinnern sich nicht; jede Sitzung beginnt leer. Alles in die Anfrage aufzunehmen ist ressourcenintensiv und verschlechtert die Qualität, je größer der Umfang wird. Retrieval-augmented Generation dient dazu, nur das Relevante abzurufen.

Inferenz, nicht Training. Sie werden fast nie ein Modell trainieren. Sie rufen die Inferenz bei einem fremden Modell auf und zahlen pro Token. Die Kosten bestehen aus den Eingabetoken multipliziert mit dem Eingabepreis plus den Ausgabetoken multipliziert mit dem Ausgabepreis; daher entsteht bei einer Schleife, die 50 Aufrufe mit einem Kontext von 20.000 Token durchführt, eine erhebliche Rechnung.

Anweisungen für Agenten. Anweisungen für Agenten unterscheiden sich von Chat-Anweisungen. Drei Muster sind am wichtigsten: Chain-of-Thought, bei dem das Modell vor der Ausführung explizit nachdenkt; ReAct, ein Zyklus aus Nachdenken, Handeln und Beobachten; sowie Reflection, bei dem das Modell seinen eigenen Entwurf kritisiert, bevor es ihn zurückgibt. Die meisten anderen Anweisungstechniken sind Variationen dieser Ansätze. Für eine detailliertere Betrachtung des ReAct-Zyklus siehe wie ReAct-Agenten Nachdenken mit Handlungen in der realen Welt verbinden.

6. Werkzeugnutzung und MCP verwandeln einen Chatbot in einen Agenten

Ein Modell, das nur auf Textgenerierung beschränkt ist, ist ein Chatbot. Ein Modell, das eine Funktion aufrufen, das Ergebnis prüfen und entscheiden kann, was als Nächstes zu tun ist, ist ein Agent – wobei die Werkzeugnutzung der Mechanismus ist, der dies ermöglicht.

Mechanisch gesehen beschreiben Sie jede Funktion mit einem Namen, einer Beschreibung in natürlicher Sprache sowie einem JSON-Schema für ihre Parameter und senden diese Definitionen zusammen mit der Nachricht des Benutzers. Das Modell entscheidet, ob ein Werkzeug benötigt wird; falls ja, gibt es einen strukturierten Werkzeugaufruf mit Argumenten anstelle von reinem Text zurück. Ihr Code führt die Funktion aus, sendet das Ergebnis zurück und das Modell setzt von dort aus fort. Die Beschreibung ist genauso wichtig wie das Schema, denn sie dient dem Modell dazu, zu entscheiden, wann ein Werkzeug anwendbar ist.

Die meisten praktischen Agentenwerkzeuge lassen sich in vier Kategorien einteilen. Die untenstehenden Beispiele veranschaulichen sie: Werkzeuge zum Lesen (Beobachtung der Welt), Werkzeuge zum Schreiben (Änderung des Zustands), Werkzeuge zur Ausführung von Code sowie Werkzeuge zur Überprüfung der Arbeit:

# Category 1: Read  (agent observes the world)
def search_codebase(query: str, path: str) -> list[str]: ...
def fetch_url(url: str) -> str: ...
def read_file(path: str) -> str: ...

# Category 2: Write (agent changes state)
def create_file(path: str, content: str) -> None: ...
def open_pull_request(title: str, body: str, branch: str) -> str: ...
def send_slack_message(channel: str, text: str) -> None: ...

# Category 3: Execute (agent runs code)
def run_tests(test_path: str) -> dict: ...
def execute_sql(query: str, db: str) -> list[dict]: ...

# Category 4: Verify (agent checks its own work)
def lint_code(file_path: str) -> list[str]: ...
def run_type_checker(path: str) -> bool: ...

Die Kategorien bilden außerdem ein nützliches Instrument zur Bewertung von Risiken. Les- und Überprüfungswerkzeuge können in der Regel ungehindert aufgerufen werden, während Schreib- und Ausführungswerkzeuge Veränderungen vornehmen und strengere Berechtigungen erfordern – ein Thema, das auch im Sicherheitsschritt eine Rolle spielt.

Das Model Context Protocol (MCP) ist ein sich entwickelndes Standard, das benutzerdefinierten Integrationscode durch ein Protokoll ersetzt. Eine gängige Analogie ist USB-C für KI: Anstatt jedes Mal einen maßgeschneiderten Adapter zu schreiben, wenn der Agent auf GitHub, Slack oder eine Datenbank zugreifen muss, wird ein vorhandener MCP-Server verbunden, wodurch die Host-Anwendung die Fähigkeiten des Servers erkennt und sie ohne zusätzlichen Code nutzen kann.

Die am schnellsten lohnenden Integrationen sind GitHub für Branches, Pull Requests und Issues; Slack für Benachrichtigungen und Zusammenfassungen; Ihre Datenbank für Abfragen und kontrollierte Schreibvorgänge; sowie der Issue-Tracker des Teams. Wenn diese vier miteinander verbunden sind, kann ein Agent den größten Teil eines Engineering-Werkflows abdecken.

7. Abruf von Informationen, denn der Kontext hat eine Obergrenze

Durch retrieval-augmented Generation erhält ein Agent Wissen, das nicht in seinen Kontext passt. Dies ist eine Reaktion auf eine strenge Einschränkung und keine Modeerscheinung: Das Kontextfenster ist begrenzt, während Ihre Codebasis und Dokumentation das nicht sind.

Ein Abrufsystem besteht aus vier Hauptteilen:

Chunking – hier machen Anfänger am häufigsten Fehler. Zu große Blöcke enthalten zu viel irrelevante Informationen; zu kleine Blöcke verlieren an Bedeutung. Die richtige Größe hängt vom Inhalt ab, wobei Quellcode in der Regel andere Grenzen benötigt (zum Beispiel ganze Funktionen) als prosaische Dokumentation.
Embeddings – sie ermöglichen die Suche nach Ähnlichkeiten. Ein Embedding-Modell wandelt Text in einen numerischen Vektor um, sodass ähnliche Abschnitte nahe beieinander liegende Vektoren erzeugen.
Suche – sie findet die gespeicherten Vektoren, die dem eingegebenen Abfragedaten am nächsten sind, und gibt deren Blöcke zurück.

Bewertung, die ein funktionsfähiges System von einem, das nur so erscheint, unterscheidet. Die wichtigsten Messgrößen sind die Abrufgenauigkeit (ist das, was abgerufen wurde, tatsächlich relevant?), die Treue (bleibt die Antwort im Rahmen des abgerufenen Materials?) sowie die Relevanz der Antwort (beantwortet sie die Frage?). Werkzeuge wie RAGAS oder ein Bewertungsmodell können diese Aspekte bewerten. Ohne Messung bleibt Verbesserungen reine Spekulation.

Eine ausgereifte Informationsabrufung verläuft selten in gerader Linie von der Anfrage bis zur Antwort. Produktivsysteme schreiben die Frage in der Regel vor der Suche um, rangieren die Ergebnisse nach der Suche neu und nutzen einen Bewertungsschritt, um zu prüfen, ob das abgerufene Material tatsächlich die Frage beantwortet. Im Grunde überlegt das Modell, was abgerufen werden soll und ob der Abruf erfolgreich war.

8. Zustandsbasierte Orchestrierung mit LangGraph

Ein einziger LLM-Aufruf stellt kein Agent dar. Ein Agent führt mehrere Schritte aus, überträgt den Zustand zwischen ihnen, entscheidet je nach Beobachtung weiter und erholt sich von Fehlern. LangGraph bietet eine Struktur genau dafür.

Strukturell gesehen ist eine LangGraph-Anwendung ein gerichteter Graph, dessen Knoten einfache Funktionen sind – wie Agenten, Tools oder Verarbeitungsschritte. Kanten definieren, wie die Steuerung zwischen ihnen übertragen wird. Ein gemeinsames, typisiertes Zustandsobjekt wird von jedem Knoten gelesen und aktualisiert.

Der untenstehende Entwurf definiert einen Zustand mit einer Aufgabe, einem Plan, Ergebnissen, Fehlern sowie einem Abschlussflagge und registriert anschließend vier Knoten: einen Planer, der die Arbeit aufteilt, einen Ausführender, der einen Schritt ausführt, einen Überprüfer, der das Ergebnis prüft, sowie einen Fehlerhandler, der erneut versucht oder die Situation weiterleitet. Die bedingte Kante nach dem Überprüfer bildet das Herz des Schleifens: Die Ausführung endet, wenn der Zustand „erledigt“ anzeigt, es wird zum Handler weitergeleitet, wenn Fehler vorliegen, andernfalls wird der nächste Schritt ausgeführt. Beachten Sie, dass dies nur ein Fragment ist; ein ausführbarer Graph benötigt außerdem einen Eingangspunkt, die restlichen Kanten sowie einen Aufruf von compile().

from langgraph.graph import StateGraph, END
from typing import TypedDict

class AgentState(TypedDict):
    task: str
    plan: list[str]
    results: list[str]
    errors: list[str]
    done: bool

graph = StateGraph(AgentState)

graph.add_node("planner", plan_task)       # breaks work into steps
graph.add_node("executor", execute_step)   # runs one step
graph.add_node("verifier", verify_output)  # checks the result
graph.add_node("handler", handle_error)    # retries or escalates

graph.add_conditional_edges(
    "verifier",
    lambda state: END if state["done"] else
                  "handler" if state["errors"] else
                  "executor"
)

Verglichen mit einer manuell geschriebenen Python-Schleife bietet das Framework drei zusätzliche Funktionen:

Checkpointing. Wenn Sie das Graph mit einem Checkpointer kompilieren, wird der Zustand nach jedem Schritt gespeichert, sodass ein unterbrochener Ablauf (ein abgestürzter Laptop, eine neu gestartete Sitzung) dort fortgesetzt werden kann, wo er aufgehört hat, anstatt von vorne zu beginnen.
Pausen durch menschliches Eingreifen. Durch die Einstellung von interrupt_before für einen kritischen Knoten wird das Graph gestoppt, die vorgeschlagene Aktion angezeigt und auf Genehmigung gewartet, bevor es weitergeht. Dies ist ein wesentlicher Unterschied zwischen einem Demo-Agenten und einem Produktionsagenten.
Parallelisierte Zweige. Unabhängige Schritte können gleichzeitig ausgeführt werden, während das Framework dafür sorgt, dass ihre Ergebnisse in den Zustand integriert werden; dadurch müssen Sie nur die Struktur beschreiben, anstatt Synchronisierungscode zu schreiben.

Eine vernünftige Regel: Wählen Sie ein Graphen-Framework, wenn der Agent mehr als etwa drei Schritte hat, Verzweigungen in den Tool-Ausgaben vorkommen oder Schleifen bis zur Erfüllung einer Bedingung existieren. Eine einfache lineare Kette ohne Verzweigungen reicht in reinem Python aus. Die Abwägungen werden ausführlicher in der Entscheidung zwischen Ketten und zustandsbehafteten Graphen behandelt.

Teil 3: Korrekte Implementierung

9. Fünf Projekte nacheinander

Über Agenten zu lesen und sie selbst zu bauen sind unterschiedliche Fähigkeiten, und der Lernweg funktioniert nur durch praktische Projekte. Diese fünf Projekte, in dieser Reihenfolge durchgeführt, behandeln jedes Konzept, das für die Erstellung von Anwendungen erforderlich ist.

Ein Agent mit einem Werkzeug. Wählen Sie eine einzige API, wie GitHub oder einen Wetterdienst, und schreiben Sie einen Agenten, der prüft, ob die API benötigt wird, sie aufruft und ihre Antwort in die Antwort integriert. Verwenden Sie die rohe Anthropic- oder OpenAI-API ohne Framework, damit Sie den Werkzeugnutzungszyklus unverfälscht sehen können, ohne dass irgendeine Abstraktion ihn verdeckt.
Ein ReAct-Agent mit drei Werkzeugen. Fügen Sie eine Web-Suche, einen Taschenrechner und einen Code-Executor hinzu und schreiben Sie selbst den Reason-Act-Observe-Zyklus. Hier bemerkt ein Agent in der Regel erstmals seinen eigenen Fehler und korrigiert ihn.
Datenerfassung aus einer bekannten Codebasis. Indizieren Sie ein reales Repository, erstellen Sie eine Datenerfassungsmethode dafür und stellen Sie Fragen, die das Verständnis mehrerer Dateien erfordern. Messen Sie die Qualität der Datenerfassung und beheben Sie die fehlerhaften Abschnitte. Dieses Projekt zeigt, warum das Aufteilen in Abschnitte wichtiger ist als alles andere.

Ein mehrstufiger Graphen-Agent. Erledigt die Triage in CI: liest fehlerhafte Testprotokolle, klassifiziert den Fehler, durchsucht die Codebasis nach der wahrscheinlichen Ursache, entwirft eine Korrektur und führt die Tests aus, wobei der Zustand über fünf Knoten fließt. Machen Sie den Überprüfer zu einem separaten Knoten vom Korrekturagenten; andernfalls geraten Sie sofort in einen selbstbezogenen Bias.

Ein geplanter autonomer Kreislauf. Führen Sie Projekt vier nach einem Cron-Plan ohne Aufsicht aus. Geben Sie ihm eine Zustandsdatei, damit es fortsetzen statt neu starten kann, ein festes Ausgabenbudget, damit es keine hohen API-Kosten verursacht, sowie ein Audit-Log, der seine Aktionen aufzeichnet. Hier verwandelt sich „funktioniert in einer Demo“ in „funktioniert unüberwacht.“

10. Die Zustandsdatei: Agenten vergessen, Dateien nicht

Das klingt zu einfach, um von Bedeutung zu sein, doch es bildet die Grundlage jedes zuverlässigen autonomen Agenten: eine Markdown-Datei, ein JSON-Dokument oder eine Datenbankzeile, die außerhalb des Gesprächs gespeichert wird und festhält, was bereits erledigt wurde und was als Nächstes ansteht.

Modelle speichern nichts zwischen den Sitzungen. Alles, was ein Agent während eines Laufs lernt, verschwindet, es sei denn, es wird aufgeschrieben. Daher beginnt ein Loop ohne persistente Zustandsdaten jedes Mal von Null, während ein Loop mit Zustand dort weitermacht, wo er aufgehört hat. Das untenstehende Beispiel verfolgt die letzte Laufzeit, die Anzahl der verarbeiteten und noch ausstehenden Elemente, die in Bearbeitung befindlichen Aufgaben, die abgeschlossenen Arbeiten, die an einen Menschen weitergeleiteten Elemente sowie datierte Erkenntnisse wie Umgebungsbesonderheiten, die beim nächsten Mal vermieden werden sollen:

// STATE.md: what every working autonomous agent needs
{
  "last_run": "2026-07-01 03:00 UTC",
  "items_processed": 47,
  "items_remaining": 12,
  "in_progress": [
    "fix/auth-token-refresh: tests passing, awaiting CI"
  ],
  "completed": [
    "fix/null-check-in-billing: merged, CI green"
  ],
  "escalated_to_human": [
    "src/payments/refund.ts: root cause unclear after 3 theories"
  ],
  "lessons": [
    "2026-06-30: E2E tests require Stripe webhook secret in env. Skip if missing.",
    "2026-06-29: Windows runner has TLS 1.2 issue. Use bash, not PowerShell."
  ]
}

Die Liste der Lektionen verdient Aufmerksamkeit. Sie zeigt, wie eine Schleife verhindert, immer wieder denselben Fehler zu begehen, und dient gleichzeitig als nachhaltige Spezifikation, um eine Abweichung von den Zielen zu vermeiden. Es gibt zwei gängige Formate: Eine in das Repository eingetragene Markdown-Datei wird versioniert, ist leicht vergleichbar und einfach zu handhaben – was sich für Einzelpersonen und kleine Teams eignet. Für Produktions-Schleifen, die von mehreren Personen überwacht werden müssen, eignen sich externe Systeme wie Issue-Tracker wie Linear oder Datenbanken besser. Das Prinzip ist einfach: Der Agent vergisst, das Repository erinnert sich – daher sollte alles Wichtige außerhalb des Kontextfensters gespeichert werden.

11. Maker-checker: Autor und Reviewer getrennt halten

Ein Agent erzeugt die Arbeit und ein anderer Agent, der über seinen eigenen Kontext verfügt, prüft sie. Dies ist die strukturelle Lösung für den selbstpräferenziellen Bias, und seine konsequente Anwendung ist eines der deutlichsten Zeichen für ein ausgereiftes Agentendesign.

Ein Modell, das seine eigene Ausgabe bewertet, ist gegenüber sich selbst viel zu großzügig. Fragt man den Agenten, der eine Korrektur vorgenommen hat, ob diese richtig ist, wird er Gründe finden, ja zu sagen. Gibt man einem separaten Prüfer die Korrektur zusammen mit einer Bewertungskriterienliste, ohne dass er weiß, wer sie verfasst hat oder warum, findet dieser echte Mängel.

Der Unterschied im Code: Die falsche Version bittet einen einzelnen Agenten, einen Fehler zu beheben und seine eigene Korrektur zu bestätigen. Die richtige Version führt zunächst einen Korrektor auf einem Modell aus und übermittelt anschließend nur den resultierenden Code sowie eine spezifische Bewertungskriterienliste an einen Prüfer, wobei dieser angewiesen wird, Autorschaft und Absicht zu ignorieren sowie entweder mit Begründung eine Genehmigung oder mit Zeilenreferenzen eine Ablehnung zurückzugeben. Der Prüfer verwendet ein leistungsstärkeres Modell, da das Urteilsvermögen die schwierigere Aufgabe darstellt:

# Wrong: one agent does both
result = await agent("Fix the auth bug and verify your fix is correct")

# Right: maker and checker are separate agents, separate contexts
fix = await agent(
    "Fix the auth bug in src/auth/middleware.ts",
    model="sonnet"
)

review = await agent(
    f"""Review this fix against the rubric below.
    Do not consider who wrote it or their intent.

    Fix:
    {fix.code}

    Rubric:
    - Does it handle the null case on line 47?
    - Does it preserve the existing token expiry logic?
    - Does the test cover the regression case?

    Return: PASS with reasoning, or FAIL with specific line references.""",
    model="opus"   # harder model for the harder judgment task
)

Die Regel für die Kombination lautet, dass der Prüfer nur zwei Eingaben erhält – die Bewertungskriterienliste und das Ergebnis – niemals jedoch die Identität des Autors, die Begründung für die Änderung oder den Dialog, der zu ihr führte. Jede dieser Informationen könnte durch die Art der Darstellung eine eigene Präferenz wieder einführen. Auch die Bewertungskriterienliste ist wichtig; spezifische, überprüfbare Fragen wie die oben genannten funktionieren weitaus besser als die Frage, ob eine Änderung gut ist.

Dieses Prinzip der Trennung gilt weit über Code hinaus: Autoren und Rezensenten, Schreiber und Faktenprüfer, Generatoren und Urteiler. Sobald man es bemerkt, erkennt man, wie oft Standardwerkzeuge diese beiden Rollen stillschweigend miteinander verschmelzen.

12. Bewertung: das Tor, das einen Zyklus vertrauenswürdig macht

Ein Agent ohne Überprüfer ist lediglich ein wiederholt aufgerufener Chatbot. Die Bewertung entscheidet darüber, ob ein Ergebnis vertrauenswürdig genug ist, um darauf zu handeln, es zu integrieren oder freizugeben. Verwenden Sie drei Ebenen, deren Kosten sowie die Art der Urteile, die sie fällen können, zunehmen:

Deterministische Überprüfungen. Tests, Linter, Typüberprüfer und Build-Prozesse liefern ein binäres Ergebnis ohne jegliches Urteil. Sie stellen das erste und günstigste Tor dar; nutzen Sie sie immer dann, wenn eine deterministische Überprüfung fehlerhafte Ausgaben ablehnen kann.

Ein LLM-Richter. Ein zweites Modell bewertet die Ausgabe des ersten Modells anhand eines Bewertungskriteriums. Dies funktioniert, wenn das Kriterium präzise ist, scheitert jedoch bei Unklarheiten. Der Richter sollte mindestens genauso fähig sein wie das erzeugende Modell und darf niemals erfahren, wer die Ausgabe erstellt hat. Die effektive Nutzung eines Richters ist eine eigene Disziplin, die in „Managing LLM as a Judge as a Production System“ behandelt wird.

Menschliche Freigabe. Unumkehrbare Aktionen wie Produktivumsetzungen, Zahlungscodes, Force-Pushes und architektonische Änderungen benötigen die Freigabe eines Menschen, bevor der Agent fortfahren kann. In LangGraph bietet interrupt_before diese Pausefunktion. Nutzen Sie sie ausschließlich für Aktionen, deren Rückgängigmachung kostspielig ist, anstatt alles zu blockieren.

Um festzustellen, ob die Bewertung funktioniert, sollte man den Anteil der akzeptierten Änderungen verfolgen. Wenn ein zum Beheben fehlerhafter Tests konstruierter Agent 70 % seiner Probleme mit Änderungen löst, die sowohl den CI-Tests als auch der menschlichen Überprüfung standhalten, beträgt sein Anteil 70 %. Liegt dieser Wert unter etwa 50 %, verbringen Menschen ihre Zeit damit, die von dem Agenten begonnenen Arbeiten abzuschließen, wodurch der Kreislauf mehr kostet, als er einspart.

13. Sicherheit: Ein unbeaufsichtigter Agent ist eine unbeaufsichtigte Angriffsfläche

Jeder autonome Agent, der auf echte Infrastrukturen zugreift, stellt eine Sicherheitslücke dar, da er ohne Überwachung arbeitet. Das Risiko ist konkret: Durch indirekte Prompt-Injektion kann ein Agent, der eine bösartige E-Mail oder Webseite liest, manipuliert werden, um Befehle eines Angreifers auszuführen. Die Hauptbedrohungen:

Injektion über Tool-Ausgaben. Webseiten, GitHub-Issues und Support-Tickets können Anweisungen in gewöhnlichem Inhalt verbergen, beispielsweise eine Zeile, die dem Agenten mitteilt, frühere Anweisungen zu ignorieren und Testdateien zu löschen. Die Quarantäne dient als Schutzmaßnahme: Jeder Agent, der mit unzuverlässigem Inhalt in Berührung kommt, erhält nur Leserechte. Halten Sie Leser- und Handlungsagenten getrennt.
Permission Creep. Ein Agent, der mit nur Leserechten validiert wurde, erhält „aus Bequemlichkeit“ ein Schreibrecht, ohne dass dies erneut überprüft wird. Überprüfen Sie die Rechte regelmäßig (monatlich ist ein angemessener Rhythmus) und gewähren Sie nur das Minimum, was die Aufgabe erfordert.
Geheimnisse in den Logs. Ausführliches Logging in einer langlaufenden Schleife verteilt Anmeldeinformationen in Ausgaben, die niemand überwacht. Deaktivieren Sie ausführliches Logging in Produktivschleifen und reinigen Sie das Verbleibende.

Nicht überprüfter generierter Code. Agenten können Pull Requests schneller öffnen, als Menschen sie lesen können. Fehlt in der CI-Systematik eine statische Analyse, Abhängigkeitsprüfungen sowie das Scannen nach Geheimnissen, kann anfälliger Code unbemerkt in die Hauptbranche gelangen. Automatisierung macht diese Kontrollmechanismen wichtiger – nicht weniger.

Ein Berechtigungsmodell macht diese Regeln explizit. Das untenstehende Beispiel genehmigt automatisch nur solche Aktionen, die lediglich zur Beobachtung dienen, wie das Lesen von Dateien, das Ausführen von Tests sowie das Anzeigen des git-Status oder von Diffs, und erfordert eine menschliche Überprüfung für das Pushen, Bearbeiten von Umgebungsdateien, Änderungen am Zahlungskodex sowie alles, was mit einem Force-Flag versehen ist:

# Safe agent permission model
permissions = {
    "auto_approve": [
        "Read(*)",           # read anything
        "Bash(npm test)",    # run tests
        "Bash(git status)",  # observe state
        "Bash(git diff*)",   # observe diffs
    ],
    "require_human": [
        "Bash(git push*)",   # never push without approval
        "Edit(.env*)",       # never touch secrets
        "Edit(src/payments/*)",  # never touch payments code
        "Bash(*--force*)",   # never force anything
    ]
}

Der Test für jede Regel besteht aus einer einzigen Frage: Wenn sich diese Aktion als falsch erweist, wie teuer ist es, sie rückgängig zu machen? Wenn die Korrektur günstig ist, wird sie automatisch genehmigt; wenn sie kostspielig ist, muss eine Person entscheiden. Das Fall für Fall Entscheiden mitten im Prozess führt zum sogenannten Permission Creep.

14. Fähigkeiten in eine Karriere umwandeln

Ein Lernpfad sollte zu einem Ziel führen. Hier ist eine realistische Sicht darauf, wo diese Fähigkeiten Anwendung finden.

Was gezeigt werden sollte. Vermeiden Sie Tutorial-Clones. Drei echte Projekte, die tatsächliche Probleme gelöst haben, sind weitaus aussagekräftiger:

Ein geplanter Agent, dessen Ausgabe in der Praxis genutzt wird – wie der in Schritt 9 erstellte Loop.
Ein Mehr-Agenten-System, in dem mindestens zwei Agenten unterschiedliche Rollen haben, die strukturell verhindern, dass eine Modellinstanz beides ausführt – wie im Maker-Checker-Muster aus Schritt 11.
Ein Abrufsystem mit dokumentierten Bewertungskriterien, das das Ergebnis vor und nach einer Korrektur zeigt – anstatt nur zu zeigen, dass es funktioniert.

Wie lange es dauert. Als grobe Schätzung kann jemand, der bereits solides Python beherrscht und 10 bis 15 Stunden pro Woche lernt, damit rechnen, dass dieser Weg etwa acht Monate in Anspruch nimmt. Betrachten Sie das als Planungswert, nicht als Versprechen.

Wo man anfangen sollte. Die Zugänglichkeit der jeweiligen Rollen für Anfänger variiert stark:

KI-Automatisierungsingenieur in einem Unternehmen, dessen Hauptgeschäft nicht KI ist. Es wird jemand benötigt, der beispielsweise einen Loop erstellen kann, der Tests über Nacht korrigiert. LangGraph, MCP sowie grundlegende Kenntnisse in CI reichen aus; Dutzende von Frameworks sind nicht erforderlich.
KI-Engineer in einem Startup, dessen Produkt ein Agent ist. Hier sind umfassende Kenntnisse in den Bereichen Datenabruf, Bewertung, Entwurf mehrerer Agenten sowie Deployment erforderlich – mit höheren Anforderungen und größeren Möglichkeiten.

Agent-basierter Infrastrukturingenieur in einem großen Technologieunternehmen – ein Position mit hohem Anspruch, die neben allen anderen Fähigkeiten auch Expertise in verteilten Systemen erfordert und kein Einstiegsjob ist.

Der wichtigste Punkt, den die meisten Lernpläne übersehen, ist, dass man nicht alles vor Beginn wissen muss. Entscheidend sind ein eingesetzter Agent, der ein echtes Problem löst, Nachweise dafür, dass man dessen Erfolg quantifizieren kann, sowie die Fähigkeit, darzulegen, gegen welche Ausfallmöglichkeiten das Design schützt. Nur wenige Kandidaten bringen all drei Aspekte mit, und kein Zertifikat kann sie ersetzen.

Zusammenfassung

Einige Zeit lang lag der größte Hebel bei angewandter KI im Prompt: bessere Formulierungen, besserer Kontext, bessere Ergebnisse bei einmaliger Ausführung. Da die Modelle nun ausreichend leistungsfähig sind, um tatsächlich zu handeln, ist der Hebel auf eine höhere Ebene gewandert – zum System, das entscheidet, an welchen Aufgaben die Agenten arbeiten, wann ihre Ergebnisse überprüft werden, wie ihre Aktionen aufgezeichnet werden und was passiert, wenn sie versagen.

Lernen Sie zunächst Konzepte, bevor Sie Frameworks nutzen, und beurteilen Sie jedes Werkzeug danach, mit welchen Versagungsmodi es umgeht: Trägheit, Selbstpräferenz oder Abweichung.
Bewahren Sie den Zustand außerhalb des Modells in einer Datei oder Datenbank auf, die der Agent bei jeder Ausführung erneut liest.
Lassen Sie niemals den Verfasser einer Änderung gleichzeitig ihr Prüfer sein; geben Sie dem Prüfer nur das Ergebnis der Änderung sowie ein spezifisches Bewertungskriterium.
Strukturieren Sie die Bewertung von deterministischen Überprüfungen über Prüfer bis hin zur menschlichen Freigabe und messen Sie die Rate der angenommenen Änderungen.

Beschränken Sie die Berechtigungen nach Umkehrbarkeit und halten Sie Agenten, die unzuverlässigen Inhalt lesen, von Schreibzugriffen fern.

Dafür ist weder ein Forschungshintergrund noch spezielles Feintuningswissen erforderlich. Es reicht aus, über solides Wissen in Python zu verfügen, eine klare Vorstellung davon zu haben, wie LLMs Fehler machen, sowie die Gewohnheit, das Überprüfungsverfahren bereits vor dem eigentlichen Laufprozess einzubauen. Bauen Sie den ersten Agenten, lassen Sie ihn über Nacht laufen und prüfen Sie am Morgen die Ergebnisse.