Prompt Engineering oder Context, Harness, Loop? Fehlersuche bei KI-Agenten Schicht für Schicht
Prompt Engineering, Context Engineering, Harness Engineering und Loop Engineering versagen jeweils auf ihre eigene Weise. Eine trace-first-Routine ermittelt die Stelle, an der es zu einem Fehler kam.
Wenn ein KI-Agent in der Produktion falsch handelt, neigen Teams dazu, statt über Beweise über das Vokabular zu streiten: Ein Ingenieur wünscht sich einen besseren Prompt, ein anderer macht den Kontext dafür verantwortlich, ein Dritter weist auf die Infrastruktur hin. Prompt-Engineering, Kontext-Engineering, Infrastruktur-Engineering und Schleifen-Engineering sind keine konkurrierenden Denkschulen; es handelt sich um vier übereinanderliegende Schichten, und jede versagt auf ihre eigene, erkennbare Weise. Diese Anleitung definiert jede Schicht anhand eines kleinen Beispiels mit einem Code-Agenten und gibt anschließend eine schrittweise Vorgehensweise an, um herauszufinden, welche Schicht tatsächlich versagt hat, bevor man Code ändert.
Vier Schichten eines KI-Agenten im Überblick
- Prompt-Engineering prägt die Anweisung, die dem Modell gegeben wird.
- Kontext-Engineering bestimmt, was das Modell vor der Antwort sehen darf.
- Engineering der Steuerungssysteme erstellt die Umgebung, in der das Modell agiert: Werkzeuge, Speicher, Dateien, Berechtigungen und Wiederherstellungsmöglichkeiten.
- Engineering der Schleifen entwirft den Zyklus, der das System am Laufen hält, überprüft seinen eigenen Fortschritt und entscheidet, wann er gestoppt werden soll.
Die teuersten Probleme mit Agenten entstehen durch die Behebung eines Fehlers in einem dieser Schichten.
Wenn die Demo funktioniert, die Produktion aber nicht
Das Muster ist bekannt: Ein Agent wirkt in einer Demo fehlerfrei. Ein paar Tage nach dem Start beginnt er, in Schleifen zu geraten und Token zu verbrauchen, vergisst etwas, was ihm erst vor einer Stunde mitgeteilt wurde, oder stürzt ab, sobald ein Werkzeug eine unerwartete Ausgabe liefert.
Das Team teilt sich in Gruppen auf. Jemand schlägt vor, die Anweisung neu zu formulieren, ein anderer bezeichnet das als Kontextproblem, und eine dritte Person vermutet ein Problem mit dem Harness. Ohne eine gemeinsame Methode, den Fehler zu lokalisieren, verwandelt sich eine zwei Tage dauernde Behebung in eine zwei wöchige Neufassung, weil jede Korrektur auf einer Schicht vorgenommen wird, die zuvor einwandfrei funktionierte.
Das ist der praktische Grund, die vier Begriffe voneinander zu trennen. Jeder bezeichnet einen bestimmten Punkt, an dem etwas schiefgehen kann, und sobald man sie voneinander unterscheiden kann, wird das Debuggen zu einem strukturierten Prozess statt zu einem Ratespiel.
PACT: Ein Mnemonikum für die vier Schichten
Eine kompakte Methode, sich während eines Incidents die Schichten im Gedächtnis zu merken, ist PACT: Prompt, Awareness, Control, Trajectory. Jedes Wort steht für eine Frage:
- Prompt: Wurde die Aufgabe klar definiert?
- Awareness: Erhielt das Modell die für diesen Schritt benötigten Informationen?
- Kontrolle: Kann die Laufzeitumgebung das von dem Modell Geforderte sicher und zuverlässig ausführen?
- Verlauf: Bewegt sich der wiederholte Prozess auf ein überprüfbares Ende zu?
Das Ziel ist nicht wieder ein weiterer Schicht von Fachjargon. Es geht darum, die Grenzen zwischen Versagertypen so klar zu gestalten, dass man sich daran erinnern kann, sie tatsächlich anzuwenden, wenn etwas schiefgeht.
Wie die Schichten entstanden sind und warum die Reihenfolge wichtig ist
Die Begriffe kamen mehr oder weniger in dieser Reihenfolge auf, je nachdem, welche neuen Fähigkeiten die Agenten erwarben:
- Prompt-Engineering (ungefähr 2022 bis 2024) war die erste Fähigkeit: Formulierungen, Beispiele, Einschränkungen sowie Muster für wenige Beispiele, die auf einen einzigen Modellaufruf abzielten.
- Context Engineering (ungefähr 2024 bis 2025) rückte in den Vordergrund, als Agenten gleichzeitig abgerufene Dokumente, Konversationen und Tool-Definitionen verarbeiten mussten. Die Fragestellung wandelte sich von der Formulierung einer Anfrage hin zu dem, was das Modell tatsächlich wahrnimmt. Anthropic, LangChain und Chroma trugen dazu bei, dieses Konzept bei Praktikern populär zu machen, und Andrej Karpathys Kommentare halfen dabei, es in breitere ingenieurwissenschaftliche Diskussionen einzubringen.
- Harness Engineering (Anfang 2026) wurde zum Schwerpunkt, sobald Agenten Zugriff auf Dateisysteme, Shell-Befehle sowie mehrstündige Ausführungen hatten. Der Fokus verlagerte sich auf die Reichweite der Agenten sowie auf ihr Verhalten nach fehlgeschlagenen Tool-Aufrufen. OpenAIs Arbeiten am Codex machten dies zu einer wichtigen Fragestellung für Coding-Agenten; deren Dokumentation zum Harness Engineering mit Codex ist eine nützliche Primärreferenz.
- Loop Engineering (Mitte 2026) ist die neueste Bezeichnung. Selbst mit einem Steuergerät muss noch entschieden werden, was bei jeder Iteration geschieht und wann gestoppt werden soll: beobachten, handeln, überprüfen, wiederholen oder aufhören. IBM bietet eine Erklärung zu Loop Engineering, falls Sie eine andere Darstellung wünschen.
Diese Daten bezeichnen den Zeitpunkt, an dem die Begriffe an Bedeutung gewannen – nicht formelle Meilensteine – und das Vokabular befindet sich zum Zeitpunkt der Niederschrift noch in der Entstehung. Wichtig ist zu beachten, dass nichts ersetzt wurde. Jede Schicht wurde auf die vorherige aufgebaut, da jede Erhöhung der Autonomie ihre eigene Steuerungsstruktur benötigte.
Prompt Engineering: der lokale Vertrag
Prompt-Engineering ist die Kunst, eine Anweisung so zu formulieren, zu strukturieren und zu veranschaulichen, dass die Antwort vorhersehbarer wird. Ohne dieses Verfahren erhält man vage Anweisungen, unbeständige Ausgabeformate sowie ein Modell, das gezwungen ist, zu erraten, was man meint.
In einem Programmier-Agenten könnte ein Prompt für die Code-Überprüfung wie folgt aussehen:
SYSTEM: You are a code reviewer.
Given a diff, output ONLY valid JSON:
{"issues": [{"line": int,
"severity": "low|medium|high", "note": str}]}
No prose. No markdown fences.
If there are no issues, return {"issues": []}.
Dieser Prompt legt einen lokalen Vertrag fest. Er weist eine Rolle zu, beschreibt die Transformation (Unterschiede ein, Liste der Probleme aus), bestimmt die Ausgabestruktur bis hin zu den Feldnamen und zulässigen Schweregradwerten und definiert sogar den Fall ohne Daten, sodass das nachfolgende Parsen niemals mit Prosa oder fehlenden Schlüsseln umgehen muss.
Eine gängige Behauptung ist, dass Prompt Engineering überholt sei. Das ist nicht der Fall; es handelt sich dabei um die grundlegendste Schicht. Jeder Kontextpipeline gibt dem Modell letztendlich eine Anweisung, und eine schwache Anweisung innerhalb einer hervorragenden Struktur liefert weiterhin schwache Ergebnisse – nur jetzt in einer beeindruckenden Infrastruktur verpackt.
Kontextengineering: Kuratierung unter Budget
Context Engineering bedeutet, für jeden Aufruf zu entscheiden, welche Dokumente, Historie, Tool-Definitionen und Erinnerungen in das Ansichtsfenster aufgenommen werden sollen – und genauso bewusst, welche nicht. Wenn dieses Konzept vernachlässigt wird, antwortet das Modell auf veraltete Informationen, wird durch irrelevante abgerufene Passagen abgelenkt oder verliert den Fokus, weil das Fenster mit Material überfüllt ist, das nur zur Sicherheit hinzugefügt wurde.
Ein Context-Builder für einen Programmier-Agenten könnte Kandidaten abrufen, diese neu ranken und die Historie komprimieren:
def build_context(query, full_history, kb):
relevant = retrieve(query, kb, top_k=8)
reranked = rerank(relevant, query)[:3]
summary = summarize_if_long(
full_history, max_tokens=800
)
return {
"docs": reranked,
"history": summary,
"query": query,
}
Man sollte es wie einen Trichter betrachten. Die Abfrage wirft ein breites Netz mit acht Kandidaten aus, die Neubewertung behält die drei relevantesten bei, und die Konversationsgeschichte wird nur dann auf etwa 800 Token zusammengefasst, wenn sie zu lang wird. Die Funktion gibt einen kleinen, strukturierten Datensatz zurück und nicht Rohmaterial. Die geforderten Fähigkeiten sind Auswahl, Ranking und Kompression – nicht Menge.
Deshalb ist das häufigste Missverständnis, dass Kontextengineering bedeutet, dem Modell mehr Informationen zu geben, in der Regel falsch. Ein größerer Kontext enthält tendenziell mehr Störgeräusche: veraltete Anweisungen, wiederholte Fakten und widersprüchliche Beweise. Der größte Teil der Arbeit besteht darin, zu entscheiden, was weggelassen werden soll.
Kontextengineering ist umfassender als RAG
Retrieval-augmented Generation ist eine Technik innerhalb des Context-Engineerings, die den Datenerfassungsschritt umfasst. Ein RAG-Pipeline kann acht Datenblöcke abrufen und diese wie oben beschrieben auf drei herunterranken. Das Context-Engineering beinhaltet außerdem das Komprimieren von Historiedaten, das Formatieren von Tool-Definitionen, das Aufrechterhalten des Zustands kritischer Aufgaben, das Zurückgeben von Überprüfungsergebnissen an das Modell sowie die Entscheidung darüber, was weggelassen werden soll.
Ein Programmieragent ohne Vektorlager hat dennoch ein echtes Problem mit dem Kontext, das gelöst werden muss. Git-Status, offene Dateien, Compilerfehler, Testergebnisse, der aktuelle Plan sowie der Protokoll der vorherigen Aktionen müssen alle in einer nutzbaren Form zum Modell gelangen.
Engineering der Nutzung: Die Grenze zwischen Absicht und Wirkung
Der Harness ist der nicht-modellbasierte Teil des Systems: die Werkzeuge und der Zugriff auf Dateien, das persistent gespeicherte Memory, die Berechtigungsregeln, Sandboxes, das Tracking sowie alles, was bei Fehlern geschieht. Ohne einen guten Harness erhält man einen Agenten, der zwar gut logisch denken kann, aber nicht darauf handeln kann, oder einen Agenten, der zwar handeln kann, aber keine zuverlässige Methode hat, sich nach Fehlern bei Werkzeugaufrufen zu erholen.
Ein Wrapper für Werkzeugaufrufe veranschaulicht diese Idee:
def call_tool(tool_name, args, retries=2):
for attempt in range(retries + 1):
try:
result = TOOLS[tool_name](**args)
log_trace(tool_name, args, result, status="ok")
return result
except ToolError as e:
log_trace(tool_name, args, str(e), status="failed")
if attempt == retries:
return {"error": str(e), "recoverable": False}
args = repair_args(args, e)
Der Wrapper unternimmt keinen Versuch, die Aufgabe zu lösen. Er bestimmt die Grenze zwischen dem, was das Modell anfordert, und dem, was das reale System tut. Jeder Versuch wird mit seinen Argumenten, dem Ergebnis und dem Status erfasst. Ein Fehler löst einen begrenzten Neversuch mit korrigierten Argumenten aus, und sobald die Neversuche erschöpft sind, wird ein als nicht wiederherstellbar gekennzeichneter, strukturierter Fehler zurückgegeben, sodass der Aufrufer Daten erhält, mit denen er arbeiten kann, anstatt einer Ausnahme, die die Ausführung beendet.
Es ist verlockend, den Harness mit dem von Ihnen installierten Agentenframework gleichzusetzen. Ein Framework bietet eine Grundstruktur; der Harness hingegen umfasst die konkreten Entscheidungen, die Sie darauf treffen: Was protokolliert wird, was bei einem fehlgeschlagenen Aufruf als Nächstes geschieht, welcher Zustand nach einem Absturz erhalten bleibt, welche Befehle erlaubt sind und wie die Ausführungsergebnisse dem Modell zurückgegeben werden.
Loop-Engineering: Der Beendigungsvertrag
Die Schleifenarchitektur definiert die Arbeit bei jeder Iteration, die Art und Weise, wie der Agent feststellt, ob er Fortschritte macht, und vor allem die Bedingungen für das Beenden. Der typische Fehler ist die unbegrenzte Schleife: Ein Agent, der weiterhin Tools aufruft und Token verbraucht, weil ihm niemals mitgeteilt wird, dass er fertig ist oder in einer Sackgasse steckt.
Ein minimaler Controller sieht so aus:
def run_loop(task, harness, max_iters=15, stall_limit=3):
state = init_state(task)
stalls = 0
for i in range(max_iters):
action = plan_next_step(state)
result = harness.call_tool(action.tool, action.args)
state = update_state(state, result)
if is_goal_met(state):
return state, "success"
if made_no_progress(state):
stalls += 1
if stalls >= stall_limit:
return state, "stalled — escalate"
else:
stalls = 0
return state, "max iterations reached"
Mehrere Beschränkungen sind hier übereinander angeordnet. max_iters begrenzt die Gesamtarbeit, is_goal_met ermöglicht einen erfolgreichen Austritt, und ein Stauzähler verfolgt aufeinanderfolgende Iterationen ohne Fortschritt und wird jedes Mal zurückgesetzt, wenn der Fortschritt wieder einsetzt. Nach stall_limit gestoppten Schritten gibt der Loop einen spezifischen Status zurück, der eine Eskalation fordert, anstatt stillschweigend weiterzumachen. Jeder Austrittspfad gibt einen expliziten Grund an, wodurch die Ausführungen später leicht klassifiziert werden können.
Die zentrale Idee ist der Terminierungsvertrag: ein klares Ziel, messbare Fortschrittsanzeichen, begrenzte Wiederholungen, Budgets für Zeit und Token, ein Überprüfungsschritt sowie eine festgelegte Richtlinie dafür, was zu tun ist, wenn der Fortschritt stockt. Für TypeScript-Implementierungen derselben Konzepte siehe begrenzte agenteische Schleifen für die Nutzung von LLM-Tools.
Loop- und Harness-Engineering werden oft miteinander verwechselt. Das Harness legt fest, was der Agent berühren darf und wie Fehler auf der Ebene der einzelnen Tools behandelt werden. Der Loop steht darüber und bestimmt das schrittweise Verhalten, einschließlich des Zeitpunkts, an dem die gesamte Ausführung enden sollte.
Die vier Schichten nebeneinander
- Prompt (P): enthält die Anweisung. Typischer Fehler: Das Modell missversteht die Absicht oder gibt das falsche Format zurück. Erster Ort zur Überprüfung: die Ausgabe selbst.
- Context (A): enthält den für das Modell bereitgestellten Zustand. Typischer Fehler: Das Modell handelt aufgrund veralteter, fehlender oder störender Informationen. Erster Ort zur Überprüfung: die Kontext-Snapshots pro Schritt.
- Harness (C): ist für die Ausführung und Wiederherstellung zuständig. Typischer Fehler: Die Tool-Aufrufe fehlen, es werden blind erneute Versuche unternommen oder eine Wiederherstellung ist nicht möglich. Erster Ort zur Überprüfung: fehlgeschlagene Einträge im Tool-Trace.
Unterscheidung zwischen Harness-Fehler und Loop-Fehler
Die zeiteffizienteste Beobachtung ist, dass zwei verschiedene Fehler von außen identisch aussehen. Ein Agent, der aufgrund eines fehlerhaften Controllers in einer Schleife steckt, sowie ein Agent, der aufgrund fehlerhafter Tool-Verarbeitung blockiert ist, weisen beide dasselbe Symptom auf: Er läuft weiter, die Rechnung wächst ständig, und niemand weiß den Grund. Eine kurze Checkliste hilft, sie von anderen Problemen zu unterscheiden.
1. Überprüfen Sie die Tool-Aufruf-Protokolle
Aufrufe, die alle mit plausiblen Ergebnissen erfolgreich sind, während der Agent fast unveränderte Argumente für ein Tool verwendet, deuten auf einen Loop hin.
2. Suchen Sie nach wiederholten Tool-Fehlern
Falls ein Tool immer wieder versagt und der Agent ohne Änderung seines Ansatzes erneut versucht, sollte man an das Harness denken.
3. Überprüfen, was das Modell sehen konnte
Falls das Modell scheinbar einen Fakt während einer Ausführung vergisst, prüfen Sie die Kontexterstellung: Abschneiden, Ersetzen, Komprimieren oder die Art und Weise, wie der Zustand zwischen den Schritten übertragen wird.
4. Zuletzt die Ausgabe überprüfen
Falls die Tools funktioniert haben, der Kontext korrekt war und der Loop sauber endete, aber die Antwort dennoch falsch ist, schauen Sie sich den Prompt an.
Ein Faustregel
Loop-Bugs liegen in der Entscheidung darüber, was als Nächstes passiert. Harness-Bugs liegen darin, was passiert, wenn etwas schiefgeht. Kontext-Bugs liegen darin, was das Modell sehen kann. Prompt-Bugs liegen darin, was Sie gefragt haben.
Beantworten Sie zuerst, welche der vier Fragen zutrifft, bevor Sie etwas ändern.
Fallstudie: Ein Pull-Request-Prüfer, der nicht aufhören will
Stellen Sie sich ein Team vor, das einen Programmieragenten einsetzt, der Pull-Requests prüft. Die Tests verlaufen reibungslos. In der Produktion dauern einige Prüfungen bei einem einzelnen Pull-Request länger als 40 Minuten und führen zu unerwarteten Rechnungen.
Die erste Theorie besagt, dass die Anweisung zu vage ist und der Agent zu viel nachdenkt. Die Anweisung wird umgeschrieben – doch nichts ändert sich. Die zweite Theorie bezieht sich auf den Kontext: Vielleicht liest der Agent bei jedem Schritt das gesamte Repository erneut durch. Die Protokolle zeigen jedoch etwas anderes: Die Abfrage ist ordnungsgemäß begrenzt, und nur die relevanten Dateien werden heruntergeladen.
Dann liest jemand den Tool-Call-Trace sorgfältig durch. Der Agent ruft sein Test-Runner-Tool wiederholt auf, und jede Aufrufung verläuft fehlerfrei. Die Testsuite versagt tatsächlich aufgrund eines unzuverlässigen Integrationstests, der nichts mit dem Pull Request zu tun hat. Der Agent versucht weiterhin, diesen Fehler mit nicht relevanten Codeänderungen sowie dem Neustart der Tests zu beheben, da ihm nichts mitteilt, dass er bereits genügend Versuche für dieses Teilziel unternommen hat und aufhören sowie die Angelegenheit weiterleiten sollte.
Es handelt sich weder um ein Prompt-Problem, noch um ein Kontextproblem oder um ein Harness-Problem; die Tools haben sich genau wie vorgesehen verhalten. Es ist rein ein Loop-Fehler. Wenn man den Ablauf Schritt für Schritt durchgeht, wird deutlich, wie zu diesem Schluss gelangt wird.
Schritt 1: Überprüfung der Funktionsfähigkeit der Tools
Erfolgreiche Ausführungen im Trace schließen die einfachsten Harness-Fehler aus, wie beispielsweise Befehle, die nie ausgeführt werden, oder Adapter, die ständig Fehler werfen.
Schritt 2: Vergleich des Zustands zwischen Iterationen
Die Testausgabe ist im Kontext des Agents enthalten, und die Abfrage erfolgt korrekt eingegrenzt, sodass dem Modell keine Beweise fehlen.
Schritt 3: Überprüfung auf Konvergenz
Der Repository ändert sich bei jeder Iteration, doch das wichtige Überprüfungssignal verbessert sich nie. Es gibt weder einen Stoppdetektor noch eine Obergrenze für Versuche bezüglich desselben Teilziels.
Schritt 4: Der Controller wird darauf trainiert, Stillstand zu erkennen
Die Lösung besteht aus einem kleinen Teil der Controller-Logik, der eine Fortschrittssignatur zwischen den Schritten vergleicht:
if progress_signature == previous_signature:
stagnant_steps += 1
else:
stagnant_steps = 0
if stagnant_steps >= 3:
escalate("no measurable progress")
stop()
progress_signature kann alles sein, was einen sinnvollen Fortschritt darstellt – beispielsweise die Liste der fehlgeschlagenen Tests zusammen mit ihren Fehlermeldungen. Wenn sich dieser Wert nicht ändert, steigt die Stagnationszählung; nach drei stagnierenden Schritten leitet der Controller mit einer Begründung ein Eingreifen ein und stoppt den Prozess. Jede tatsächliche Veränderung setzt die Zählung zurück.
Man kann noch weiter gehen und eine Obergrenze für die Anzahl der Versuche pro fehlerhafter Signatur festlegen, nicht nur für die Gesamtanzahl der Iterationen. Der Unterschied ist wichtig: Fünfzehn erfolgreiche Iterationen können völlig in Ordnung sein, während fünfzehn Versuche gegen einen nicht behebbaren Testfehler reine Verschwendung sind. Die eigentliche Lösung besteht darin, dem Controller eine klare Definition von Stagnation zu geben, anstatt das Modell weniger stur zu gestalten.
Fallstudie: Eine Einschränkung, die aus dem Kontext verschwindet
Stellen Sie sich nun einen Agenten vor, der zu Beginn einer Migration feststellt, dass keine bestehenden Clients beeinträchtigt werden dürfen. Vierzig Schritte später wird das Gespräch komprimiert und die Einschränkung geht im Zusammenfassung verloren. Der Agent schlägt anschließend eine Änderung des Schemas vor, die zu Beeinträchtigungen führt.
Es sieht wie fehlerhaftes Denken aus, doch die Ursache liegt woanders. Vergleichen Sie den Kontext, den das Modell in verschiedenen Schritten tatsächlich erhalten hat. Wenn die Einschränkung im fünften Schritt vorhanden war und im vierzigsten Schritt fehlte, liegt die Lösung in der Kontextgestaltung: Speichern Sie kritische Invarianten getrennt vom Gespräch, sorgen Sie dafür, dass Zusammenfassungen explizite Einschränkungen weitergeben, und betrachten Sie die rohe Historie nicht länger als einzige Quelle der Wahrheit.
„Das Modell hat es vergessen“ ist niemals eine vollständige Diagnose. Die wichtige Frage ist, was dem Modell tatsächlich gegeben wurde.
Schichten, keine Ersetzungen
Jede neuere Disziplin baut auf den älteren auf, anstatt sie zu ersetzen. Ein Produktionssystem umhüllt eine klare Anweisung mit sorgfältig ausgewähltem Kontext, führt sie innerhalb eines zuverlässigen Umfelds aus und steuert den gesamten Ablauf mithilfe einer gezielten Schleife. Die Abfolge der Komponenten spiegelt wider, was Teams im Laufe der Zeit hinzufügen mussten: zunächst klarere Anweisungen, dann besser ausgewählte Informationen, anschließend eine Ausführungsumgebung für das Modell und schließlich ein Controller, der diese Umgebung ununterbrochen am Laufen hält. Wenn Sie entscheiden müssen, ob Ihr eigenes Laufzeitumfeld oder ein Framework diese äußere Schleife übernehmen soll, behandelt der Vergleich von Laufzeitumgebungen und zusammengesetzten Frameworks die damit verbundenen Abwägungen.
Umgerechtet durch PACT:
- Anweisung: Definition der Anweisung.
- Bewusstsein: Schaffung des Zustands, über den das Modell reasoningen wird.
- Kontrolle: Sicherstellung, dass die Ausführung beobachtbar, begrenzt und wiederherstellbar ist.
- Trajektorie: Umwandlung von Wiederholungen in messbaren Fortschritt, der mit einer überprüfbaren Abschlussphase endet.
Dann muss die Korrektur dem Fehler angepasst werden. Ein Modell, das eine klar definierte Aufgabe falsch interpretiert, benötigt umgehende Anpassungen. Ein Modell, dem die für seine Arbeit notwendigen Fakten fehlen, braucht zusätzlichen Kontext. Vernünftige Entscheidungen, die nicht in zuverlässige Handlungen umgesetzt werden, erfordern Optimierungsarbeiten. Handlungen, die erfolgreich sind, während der gesamte Ablauf nie konvergiert, erfordern Schleifenoptimierungen.
Häufige Fragen zu Agentenschichten
Ist Harness Engineering nur ein anderer Name für ein Agentenframework?
Nein. Ein Framework liefert Bausteine. Das „Harness“ setzt sich aus den Entscheidungen zusammen, die man bei der Verwendung dieser Bausteine trifft: Verhalten bei Tool-Fehlern, persistierter Zustand, Protokollierung, Berechtigungen sowie die Art und Weise, wie Ergebnisse zum Modell zurückgegeben werden.
Braucht ein Assistent mit einer einzigen Frage eine Schleifenverarbeitung?
Nicht unbedingt. Eine Schleifenverarbeitung wird relevant, wenn ein Agent pro Aufgabe mehrere Aktionen ausführt und selbst oder über Controller-Code entscheiden muss, ob die Arbeit abgeschlossen ist. Ein Bot für Fragen und Antworten in einem einzigen Schritt benötigt kaum oder gar keine Schleifen zum Entwerfen.
Welchen Layer sollten Sie zuerst lernen?
Beginnen Sie mit der Gestaltung von Prompten und Kontexten, anschließend wenden Sie sich dem „Harness“ und den Schleifen zu. Bevor Sie den Laufzeitbetrieb und den Controller darum herum debuggen können, müssen Sie schlechte Anweisungen von fehlendem Zustand unterscheiden.
Kann ein Fehler mehrere Layer betreffen?
Ja, und das sind oft die schwierigsten Fälle. Ein Kontextfehler kann ein Fortschrittsignal vor dem Loop verbergen, wodurch es wie ein Loop-Fehler aussieht. Verfolgen Sie den Fehler durch die verschiedenen Ebenen, anstatt nur das erste sichtbare Symptom zu beheben.
Checkliste für das nächste Agent-Vorfall
- Die vier Begriffe beschreiben Steuermechanismen, nicht konkurrierende Trends: die Anweisung, der modellbereite Zustand, die Ausführung und Wiederherstellung sowie der wiederholte Fortschritt unter Berücksichtigung einer Stopps Regel.
- Beginnen Sie jede Untersuchung mit den Protokollen und nicht mit der Eingabeanfrage: Fragen Sie nach dem, was das Modell gesehen hat, was der Laufzeitumgebung getan hat, was sich zwischen den Iterationen geändert hat und warum der Steuermechanismus fortfahren hat.
- Erfolgreiche Tool-Aufrufe, die mit nahezu identischen Argumenten wiederholt werden, deuten auf einen Loop hin; wiederholte Fehler bei blinden Neuanläufen deuten auf Probleme im Steuerframework hin.
- Geben Sie Schleifen eine explizite Definition für den Stillstand – idealerweise je nach Fehlermuster – sowie einen Eskalationsweg.
- Halten Sie dauerhafte Einschränkungen außerhalb der komprimierbaren Historie, damit eine Komprimierung sie nicht löschen kann.
Verwandte Literatur
- Wie das Model Context Protocol es KI-Agenten ermöglicht, Tools zu entdecken und aufzurufen: Eine klare Erklärung von MCP: Wie Hosts, Clients und Server es einer KI-Anwendung ermöglichen, Tools zu entdecken, diese mit strukturierten Eingaben aufzurufen, sowie wo ihre Grenzen liegen.
- CodeBuddy: Intelligentere Kontextabrufung für KI-Programmier-Agenten: Erklärt, wie ein durch ein Abhängigkeitsgraph gesteuertes Kontextabrufungssystem KI-Programmier-Agenten dabei hilft, sowohl einen Kontextmangel als auch eine Kontextüberlastung in großen Codebasen zu vermeiden.