Debugging von KI-Agenten Schicht für Schicht: Prompt, Kontext, Harness oder Loop
Ein schichtbasiertes Modell für Fehler bei KI-Agenten: Wie Prompting, Kontext, Harnessing und Loop-Engineering voneinander abweichen, sowie ein auf Spuren basierender Ansatz zur Ermittlung der fehlerhaften Schicht.
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, wieder 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, wobei jede auf ihre eigene, erkennbare Weise versagt. 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.
Kurzfassung
- Prompt-Engineering prägt die Anweisungen, die dem Modell gegeben werden.
- Kontext-Engineering bestimmt, was das Modell vor der Antwort sehen darf.
- Infrastruktur-Engineering erstellt die Umgebung, in der das Modell agiert: Tools, Speicher, Dateien, Berechtigungen und Wiederherstellungsmöglichkeiten.
Die teuersten Probleme mit den Agenten entstehen durch die Behebung des falschen Elements in diesen Schichten.
Wenn die Demo funktioniert, aber nicht die Produktion
Das Muster ist bekannt: Ein Agent wirkt in einer Demo fehlerfrei. Ein paar Tage nach dem Start beginnt er, im Kreis zu laufen und Token zu verbrauchen, vergisst etwas, was ihm erst vor einer Stunde mitgeteilt wurde, oder stürzt ab, sobald ein Tool eine unerwartete Ausgabe liefert.
Das Team teilt sich in verschiedene Lager auf. Jemand schlägt vor, den Prompt umzuschreiben, ein anderer bezeichnet das Problem als Kontextproblem, und wieder ein Dritter vermutet einen Fehler im Framework. Ohne eine gemeinsame Methode, den Fehler zu lokalisieren, verwandelt sich eine zwei Tage dauernde Behebung in einen zweiwöchigen Umschreibungsprozess, weil jeder Patch auf einer Schicht angewendet wird, die zuvor einwandfrei funktionierte.
Das ist der praktische Grund, warum die vier Begriffe getrennt gehalten werden. Jeder bezeichnet einen bestimmten Punkt, an dem etwas schiefgeht, und sobald man sie voneinander unterscheiden kann, wird das Debuggen durch einen Agenten zu einem Prozess statt zu einem Ratespiel.
PACT: Eine Mnemotechnik für die vier Ebenen
Eine kompakte Methode, sich während eines Incidents die Ebenen 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?
- Control: Kann die Laufzeitumgebung das von dem Modell Geforderte sicher und zuverlässig ausführen?
- Trajectory: Bewegt sich der wiederholte Prozess auf ein überprüfbares Ende zu?
Ziel ist es nicht, eine weitere Schicht an Fachjargon hinzuzufügen. Es geht darum, die Unterschiede zwischen den Versagertypen so leicht zugänglich zu machen, dass man sie tatsächlich anwendet, wenn etwas in Flammen steht.
Wie die Ebenen entstanden und warum die Reihenfolge wichtig ist
Die Begriffe kamen in etwa in dieser Reihenfolge auf, je nachdem, welche neuen Fähigkeiten die Systeme erlangten:
- Prompt-Engineering (ungefähr 2022 bis 2024) war die erste Fähigkeit: Formulierungen, Beispiele, Einschränkungen sowie Few-Shot-Muster, die auf einen einzigen Modellaufruf abzielten.
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 Entwicklung. Wichtig ist zu beachten, dass nichts ersetzt wurde. Jede Schicht wurde auf die vorherige aufgebaut, da jede Erhöhung der Autonomie ihre eigene Steuerungsstruktur erforderte.
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, unbestimmte Ausgabeformate sowie ein Modell, das raten muss, was man gemeint hat.
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 (Eingangsdifferenz, Ausgangsliste der Probleme), legt die Struktur der Ausgabe bis hin zu den Feldnamen und zulässigen Schweregradwerten fest und definiert sogar den Fall ohne Daten, sodass das anschließende Parsen niemals mit Prosa oder fehlenden Schlüsseln umgehen muss.
Eine gängige Behauptung ist, dass Prompt Engineering überholt sei. Das stimmt nicht; es handelt sich dabei um die grundlegendste Schicht. Jeder Kontextprozess übermittelt letztendlich dem Modell eine Anweisung, und eine schwache Anweisung innerhalb einer hervorragenden Struktur liefert weiterhin schwache Ergebnisse – nur jetzt in beeindruckender Infrastruktur verpackt.
Kontextengineering: Auswahl unter Budgetbeschränkungen
Kontextengineering bedeutet, für jeden Aufruf zu entscheiden, welche Dokumente, Historie, Tool-Definitionen und Erinnerungen in den Kontext aufgenommen werden sollen – und genauso bewusst, welche nicht. Wenn dieses Konzept vernachlässigt wird, antwortet das Modell auf veraltete Informationen, lässt sich durch irrelevante extrahierte Passagen ablenken oder verliert den Fokus, weil der Kontext mit Material überfüllt ist, das nur zur Sicherheit hinzugefügt wurde.
Ein Kontextbuilder für einen Programmieragenten könnte Kandidaten extrahieren, neu rangieren 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 aus 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 anstelle von Rohdaten. 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 die Protokolle früherer Aktionen müssen alle in einer nutzbaren Form zum Modell gelangen.
Harness Engineering: Die Grenze zwischen Absicht und Wirkung
Der Harness ist der nicht-modellbasierte Teil des Systems: die Werkzeuge und Dateizugriffe, 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 handelt, aber keine zuverlässige Methode hat, sich nach einem Fehler bei einer Werkzeugaufrufung zu erholen.
Ein Wrapper für Werkzeugaufrufe veranschaulicht dieses Konzept:
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 definiert die Grenze zwischen dem, was das Modell anfordert, und dem, was das reale System tut. Jeder Versuch wird zusammen mit seinen Argumenten, dem Ergebnis und dem Status erfasst. Ein Fehler löst einen begrenzten Neversuch mit korrigierten Argumenten aus, und sobald alle Versuche erschöpft sind, wird ein als nicht wiederherstellbar gekennzeichneter strukturierter Fehler zurückgegeben, sodass der Aufrufer Daten erhält, über die er nachdenken kann, anstatt einer Ausnahme, die den Ablauf beendet.
Es ist verlockend, den Harness mit dem jeweiligen Agentenframework zu gleichsetzen, das man installiert hat. Ein Framework bietet eine Struktur; der Harness hingegen umfasst die konkreten Entscheidungen, die man darauf trifft: Was wird protokolliert, was passiert bei einem fehlgeschlagenen Aufruf, 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
Loop Engineering definiert die Aufgaben jeder Iteration, die Art und Weise, wie der Agent feststellt, ob er Fortschritte macht, sowie – was am wichtigsten ist – die Bedingungen für das Beenden. Der typische Fehlerfall dabei ist der unendliche Loop: 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"
Hier sind mehrere Beschränkungen übereinander angeordnet. max_iters begrenzt die Gesamtanzahl der Ausführungen, is_goal_met ermöglicht einen erfolgreichen Austritt, und ein Stauzähler verfolgt aufeinanderfolgende Iterationen ohne Fortschritt und wird jedes Mal zurückgesetzt, wenn wieder Fortschritte erzielt werden. Nach stall_limit gestoppten Schritten gibt der Loop einen speziellen Status zurück, der eine Eskalation fordert anstelle eines stillen Weiterlaufs. Jeder Austrittspfad gibt einen expliziten Grund an, wodurch die Ausführungen später leicht klassifiziert werden können.
Die zentrale Idee ist der Abschlussvertrag: ein klares Ziel, messbare Fortschrittsanzeichen, begrenzte Wiederholungsversuche, Budgets für Zeit und Tokens, 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.
Schleifen und Harnessing werden oft miteinander verwechselt. Das Harness definiert, was der Agent berühren darf und wie Fehler auf der Ebene einzelner Tools behandelt werden. Die Schleife steht darüber und bestimmt das Verhalten Schritt für Schritt, einschließlich des Zeitpunkts, an dem der gesamte Ablauf enden sollte.
Die vier Schichten nebeneinander
- Prompt (P): ist für die Anweisung verantwortlich. Typischer Fehler: Das Modell interpretiert die Absicht falsch oder gibt das falsche Format zurück. Erster Ort zum Überprüfen: die Ausgabe selbst.
- Context (A): ist für den modellbereiten Zustand verantwortlich. Typischer Fehler: Das Modell handelt aufgrund von veralteten, fehlenden oder störenden Informationen. Erster Ort zum Überprüfen: die Kontextschnappschüsse pro Runde.
- Harness (C): ist für die Ausführung und Wiederherstellung verantwortlich. Typischer Fehler: Fehlerrufe der Tools, blinder Neversuch oder Unmöglichkeit zur Wiederherstellung. Erster Ort zum Überprüfen: fehlgeschlagene Einträge im Tool-Trace.
- Loop (T): ist für den Fortschritt und das Stoppen verantwortlich. Typischer Fehler: Der Agent konvergiert nie oder hört niemals auf. Erster Ort zum Überprüfen: wiederholte erfolgreiche Aufrufe mit nahezu identischen Argumenten.
Einen Harness-Fehler von einem Loop-Fehler unterscheiden
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 Werkzeugverwaltung blockiert ist, weisen beide dasselbe Symptom auf: Er läuft weiter, die Rechnung wächst ständig an, und niemand weiß den Grund. Eine kurze Checkliste hilft, sie von anderen Problembereichen zu unterscheiden.
1. Überprüfen Sie die Werkzeugaufruf-Protokolle
Aufrufe, die alle mit plausiblen Ergebnissen erfolgreich sind, während der Agent fast unveränderte Argumente für ein und dasselbe Werkzeug verwendet, deuten auf eine Schleife hin.
2. Achten Sie auf wiederholte Werkzeugfehler
Falls ein Werkzeug immer wieder versagt und der Agent ohne Anpassung seines Vorgehens erneut versucht, es zu nutzen, vermuten Sie ein Problem mit dem Verbindungsmechanismus.
3. Prüfen Sie, was das Modell sehen konnte
Falls das Modell während eines Laufs scheinbar einen Fakt vergisst, prüfen Sie die Kontexterstellung: Abschneidung, Ersetzung, Komprimierung oder die Art und Weise, wie der Zustand zwischen den Schritten übertragen wird.
4. Überprüfen Sie zuerst die Ausgabe
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.
Eine Faustregel
Loop-Bugs liegen in der Entscheidung darüber, was als Nächstes passieren soll. Harness-Bugs liegen darin, was geschieht, wenn etwas schiefgeht. Kontext-Bugs liegen darin, was das Modell sehen kann. Prompt-Bugs liegen in dem, was Sie gefragt haben.
Beantworten Sie zunächst, welche der vier Fragen zutrifft, bevor Sie etwas ändern.
Fallstudie: Ein Reviewer für Pull-Requests, der nicht aufhören will
Stellen Sie sich ein Team vor, das einen Programmieragenten einsetzt, der Pull Requests überprüft. Die Tests verlaufen reibungslos. In der Produktion dauern einige Überprüfungen für einen 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 deuten jedoch etwas anderes an: 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 durch unzusammenhängende Codeänderungen und erneutes Ausführen 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 werden kann.
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 einen Fortschrittsindikator 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 solchen 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 Fehlerart 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 bei einem unbehebbaren Testfehler reine Zeitverschwendung sind. Die eigentliche Lösung besteht darin, das Modell nicht sturer zu machen, sondern dem Controller eine klare Definition von Stagnation zu geben.
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 einer Beeinträchtigung 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 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 hören Sie auf, die rohe Historie als einzige Quelle der Wahrheit zu betrachten.
„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.
In Worten nach PACT:
- Anweisung: Definition der Anforderung.
Dann muss die Korrektur dem Fehler zugeordnet 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
Ist Harness Engineering nur ein anderer Name für ein Agentenframework?
Nicht unbedingt. 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 an das Modell zurückgegeben werden.
Braucht ein Assistent mit einer einzigen Frage eine Schleifenarchitektur?
Nicht wirklich. Eine Schleifenarchitektur 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 zu entwerfende Schleife.
Welchen Layer sollten Sie zuerst erlernen?
Fangen Sie mit der Gestaltung von Prompten und Kontexten an, danach wechseln Sie zum „Harness“ und zu den Schleifen. Bevor Sie Runtime-Probleme sowie 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.
Wichtigste Erkenntnisse
- Die vier Begriffe beschreiben Steuermechanismen, nicht konkurrierende Trends: die Anweisung, der für das Modell bereite Zustand, Ausführung und Wiederherstellung sowie wiederholter Fortschritt mit einer Stoppsregel.
- Beginnen Sie jede Untersuchung mit der Protokollierung, nicht mit der Eingabeanfrage: Fragen Sie nach dem, was das Modell gesehen hat, was die Laufzeit gemacht hat, was sich zwischen den Iterationen geändert hat und warum der Steuermechanismus fortfahren wollte.
- Erfolgreiche Tool-Aufrufe, die mit nahezu identischen Argumenten wiederholt werden, deuten auf den Loop hin; wiederholte Fehler bei blinden Neuanläufen deuten auf das Steuerframework.
- Geben Sie Loops eine explizite Definition dessen, was als Blockade gilt – idealerweise je nach Fehlermuster – sowie einen Eskalationsweg.
Verwandte Artikel
- 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 einen Abhängigkeitsgraphen gesteuertes System zur Kontextabrufung KI-Programmier-Agenten dabei hilft, sowohl einen Kontextmangel als auch eine Kontextüberlastung in großen Codebasen zu vermeiden.
- Von Kotlin schreiben bis Agenten leiten: Die neue Rolle des Mobile Engineers — Wie kodierte Agenten die Arbeit eines Android-Engineers in Richtung Spezifikationen, Kontexte, Architekturbeschränkungen und Überprüfungen lenken und welche Grundlagen wichtiger sind als je zuvor.