Agent Harness, Loop und Graph: Drei Ebenen hinter zuverlässigen KI-Agenten
Warum zuverlässige Agenten in der Regel eine Schicht vermissen: der Harness um das Modell, ein evidenzbasiertes Schleifenkonzept sowie ein expliziter Graph, zusammen mit Codemustern und einer Fehlerbehebungs-Checkliste.
Quellen: Harness, Loop, and Graph: What I Learned Building the Same AI Agent Three Different Ways
Namen, die vertraut erscheinen, aber nicht verstanden werden
Die Begriffe „Agent Harness Engineering“ und „Loop Engineering“ tauchen so häufig in Social-Media-Beiträgen und Blogartikeln auf, dass man den Eindruck gewinnt, sie würden verstanden. Vertrautheit ist trügerisch – ein kleiner Fehler macht das in der Regel deutlich.
Stellen Sie sich einen Forschungsagenten vor, dessen Aufgabe es ist, arXiv-Papiere abzurufen, sie zusammenzufassen und wöchentliche Zusammenfassungen zu erstellen. Drei Testläufe verlaufen reibungslos. Dann versagt ein auf Bandbreite beschränkter API-Aufruf ohne jegliches Anzeichen; der Code bemerkt nichts, und der Agent beginnt, Zusammenfassungen von Papieren zu erfinden, die er nie geöffnet hat. Weder das Modell noch die Anweisung sind schuld. Was fehlt, ist eine Möglichkeit für den umgebenden Code, ein tatsächlich gelesenes Papier von einer plausibel erscheinenden Fälschung zu unterscheiden. Diese Lücke existiert tatsächlich, sie hat einen Namen – und Anpassungen der Anweisungen beeinflussen sie nicht.
Das Dreifache Erstellen desselben Agenten macht die Unterschiede konkret: Eine Anpassung für die Umgebung, eine weitere für Rückkopplungsschleifen und eine dritte für die explizite Steuerung des Workflows. Das Feld existiert in seiner heutigen Form erst seit etwa achtzehn Monaten, weshalb die Benennung noch umstritten ist. Die zugrundeliegenden Unterschiede sind jedoch real und entsprechen tatsächlichen Ingenieurentscheidungen. Danach sollte ein fehlerhafter Agent anzeigen, welcher der drei Schichten zuerst repariert werden muss.
Ein Sprachmodell allein übersetzt lediglich Text in Text. Eine Speicherung zwischen Aufrufen existiert nur, wenn man sie bereitstellt. Dateizugriff, Shell-Befehle und API-Aufrufe erfordern alle Infrastruktur, die jemand erstellen muss, und das Modell kann seine eigenen Antworten ohne externe Überprüfung nicht validieren. Diejenigen, die 2024 Agenten entwickelten, stellten dies fest, als eine reibungslose Demo bei der ersten unerwarteten Benutzeraktion zusammenbrach.
Die Branche hat darauf reagiert, indem sie „den Agenten“ nicht mehr als ein einziges Objekt betrachtet. Es handelt sich um drei voneinander getrennte Ingenieurprobleme, die auf dem Modell aufgetürmt sind.
LAYER QUESTION IT ANSWERS FAILS AS
----------------------------------------------------------------------
Harness What can the agent see and touch? Missing tools,
(environment, tools, memory, lost state, blown
permissions, execution limits) budgets, leaks
----------------------------------------------------------------------
Loop How does one attempt turn into a Confident wrong
correct one? (retry, verify, stop) answers, infinite
spinning, silent
failure
----------------------------------------------------------------------
Graph What is the actual shape of the work? Wrong step order,
(sequence, branches, parallel paths, no recovery path,
human checkpoints) no visibility
----------------------------------------------------------------------
Jede Schicht lässt sich am leichtesten verstehen, indem man die kleinste Version erstellt, sie zerstört und anschließend die Forschungs- sowie Framework-Dokumente durchliest, um herauszufinden, warum sie versagt hat.
Das Harness: Was der Agent sehen und berühren kann
Die klarste Definition findet sich in einer Engineering-Notiz von LangChain, die die Idee auf eine Gleichung reduziert: Agent gleich Modell plus Harness. Das Modell liefert das Denken. Das Harness stellt alles bereit, was das Denken benötigt, um in die reale Welt vorzudringen – also Tools, Speicher, Kontext, Berechtigungen sowie Schutzmechanismen, die verhindern, dass der Agent etwas Kostenintensives oder Gefährliches tut.
Ein gängiges frühes mentales Modell für „das Bereitstellen von Werkzeugen an einen Agenten“ besteht darin, einige Python-Funktionen zu schreiben und diese im Systemprompt zu beschreiben. Das eignet sich gut für eine Demonstration. Doch es hält einer Aufgabe, die länger als ein Kontextfenster dauert, oder einem fehlgeschlagenen Werkzeugaufruf um 2 Uhr morgens ohne Aufsicht nicht stand. In der Praxis erweist sich das Framework als sechs Aufgaben übernehmen zu müssen.
- Durch die Kontexteinjection wird bestimmt, was das Modell vor jedem Schlussfolgerungs Schritt sieht: die Nachricht des Benutzers, aber auch heruntergeladene Dokumente, frühere Gespräche, der Projektzustand sowie die Unternehmensrichtlinien. Zu starke Korrekturen sind leicht möglich. Das Hineinwerfen ganzer Dateistrukturen sowie von git-Logs in jeden Aufruf verschlechtert die Genauigkeit, da das Modell in irrelevanten Tokenn untergeht – ein kleinerer, sorgfältig ausgewählter Kontext ist dabei konsequent besser als ein größerer, unverarbeiteter Kontext.
- Aktionsflächen wandeln eine Entscheidung in eine Aktion in der Welt um – sei es eine API-Anfrage, ein Shell-Befehl, eine Schreiboperation in einer Datenbank oder ein Klick im Browser. Das Model Context Protocol spielt dabei eine zentrale Rolle und hat sich in diesem Jahr stark weiterentwickelt. Es entstand Ende 2024 als Standardmethode dafür, dass Agenten Tools finden und aufrufen können, wodurch Teams keine individuelle Integration für jede API mehr benötigen. In der Spezifikation von Juli 2026 verfügte es über einen zustandslosen Kern, der hinter herkömmlichen Load Balancern ohne Sticky Sessions funktioniert, eine Tasks-Erweiterung von AWS für Aufgaben, die länger andauern als eine einzelne Anfrage, sowie strengere Autorisierungsmechanismen auf Basis von OAuth und OpenID Connect. Laut Quellen gibt es über zehntausend öffentliche Produktivserver sowie monatlich mehr als 97 Millionen Downloads der SDKs. Der Aufbau einer solchen Infrastruktur auf einer Tool-Schicht, die weder MCP noch ähnliche Standards verwendet, erfordert eine gute Begründung.
- Unter Persistenz versteht man alles, was auch nach einem Neustart, einem Absturz oder dem Schließen des gesamten Kontextfensters weiterhin erhalten bleiben muss – beispielsweise Checkpoints, Sitzungszustände, Vektormerkmale und Git-Historien. Der erste Forschungsagent speicherte keines dieser Elemente, wodurch bereits ein unterbrochener Verbindungsaufbau zu einem Verlust von vierzig Minuten an Fortschritt führte. Das Schreiben eines kleinen JSON-Checkpoints nach jeder abgeschlossenen Teilaufgabe trug mehr zur Zuverlässigkeit bei als jede Änderung der Anweisungen.
- Der Ausführungskontrollmechanismus umfasst Regeln für Wiederholungsversuche, Zeitlimits, Token- und Ausgabebudgets, die Routenverwaltung der Modelle, Beschränkungen für generierte Unteragenten sowie Schritte, bei denen eine menschliche Bestätigung erforderlich ist. Ohne ihn kann ein Agent, der über Nacht in einem Zyklus aus Anfragen und Fehlern stecken bleibt, eine Aufgabe unkontrolliert verlängern.
- Sicherheit und Governance umfassen den Zugriff auf Tools mit dem Prinzip des geringsten Privilegs, die Handhabung von Geheimnissen, Sandboxing, Audit-Logs sowie Allowlists. Code, der vom Modell erstellt wird, sollte stets in einem Sandboxing ausgeführt werden. Ein Programmieragent wurde dabei erwischt, wie er versuchte, mit
rm -rfauf einen Ordner zuzugreifen, den er fälschlicherweise für ein Build-Artefakt hielt. Es lag keine Böswilligkeit vor, sondern lediglich ein Fehler in Kombination mit der Berechtigung, Schaden anzurichten. - Observability bezieht sich auf Spuren, Logs zu Tool-Aufrufen, Token-Nutzung, Latenzzeiten sowie Bewertungsergebnisse. Das klingt langweilig, bis ein Agent in der Produktion seltsam zu handeln beginnt und es keine Aufzeichnungen darüber gibt, was er tatsächlich getan hat, im Gegensatz zu dem, was angenommen wurde.
Unten finden Sie ein minimales, aber funktionsfähiges Framework in Python. Es wird von einem lokalen Ollama-Modell angetrieben, sodass kein API-Schlüssel erforderlich ist, und der Wechsel auf ein gehostetes Modell erfordert nur eine Zeile Code.
import json
import subprocess
import requests
from datetime import datetime
OLLAMA_URL = "http://localhost:11434/api/chat"
MODEL = "llama3.1"
# --- Action surface: the only two things this agent is allowed to do ---
def read_file(path: str) -> str:
with open(path, "r") as f:
return f.read()[:4000] # cap it, don't blow the context window
def run_tests() -> str:
result = subprocess.run(
["pytest", "-q"], capture_output=True, text=True, timeout=60
)
return result.stdout[-2000:] + result.stderr[-2000:]
TOOLS = {"read_file": read_file, "run_tests": run_tests}
TOOL_SCHEMA = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read a file from the project",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_tests",
"description": "Run the project's pytest suite",
"parameters": {"type": "object", "properties": {}},
},
},
]
# --- Persistence: cheap but real ---
def checkpoint(state: dict, path: str = "checkpoint.json"):
with open(path, "w") as f:
json.dump({**state, "saved_at": datetime.utcnow().isoformat()}, f)
# --- Execution control: hard ceilings, not suggestions ---
MAX_TOOL_CALLS = 8
def harness_run(user_task: str):
messages = [{"role": "user", "content": user_task}]
calls_made = 0
while calls_made < MAX_TOOL_CALLS:
response = requests.post(
OLLAMA_URL,
json={"model": MODEL, "messages": messages, "tools": TOOL_SCHEMA, "stream": False},
).json()
msg = response["message"]
messages.append(msg)
if not msg.get("tool_calls"):
return msg["content"] # model is done, no more tools needed
for call in msg["tool_calls"]:
name = call["function"]["name"]
args = call["function"].get("arguments", {})
if name not in TOOLS:
result = f"error: tool {name} is not permitted"
else:
result = TOOLS[name](**args)
messages.append({"role": "tool", "content": str(result)})
calls_made += 1
checkpoint({"messages": messages, "calls_made": calls_made})
return "stopped: hit the tool call ceiling before finishing"
Hier gibt es nichts Besonderes – das ist die Lektion: Ein Harness stellt eine sorgfältige Verwaltung um ein Modell her, das keine Buchhaltung betreibt. Bei einem gehosteten Modell sollte der requests.post-Block durch einen Aufruf des OpenAI- oder Anthropic-SDK ersetzt werden. Das Tool-Schema sowie das Checkpointing bleiben unverändert, da sie nicht davon abhängen, wer antwortet.
Klagen darüber, dass das Modell dümmer geworden ist, lassen sich fast immer auf den Harness zurückführen. Ein Tool könnte veraltete Daten zurückgegeben haben, der Kontext könnte mit irrelevanten Informationen überladen sein, oder eine Berechtigung könnte zu weit oder zu eng gefasst sein, wodurch der Agent weiterhin versucht, etwas zu tun, was ihm nie erlaubt war. Schauen Sie sich den Harness an, bevor Sie Prompts bearbeiten oder Modelle wechseln – dort liegt in der Regel der Fehler.
Der Kreislauf: Wie aus einem Versuch ein guter wird
Falls der Harness entscheidet, was der Agent berühren darf, bestimmt der Loop, wie es vom ersten Versuch zu einem guten Ergebnis kommt. Es handelt sich um die Schicht, die am häufigsten unterschätzt wird, denn der Satz „Lass es einfach erneut versuchen“ klingt trivial, bis der Agent tatsächlich erneut versucht.
Der klassische Fehler besteht in einem selbstkorrigierenden Loop, der das Modell nach seiner Antwort fragt, ob es sicher ist, dass die Antwort richtig ist. Die Antwort ist stets ja. Ein Modell, das seine eigene Arbeit ohne jegliches externe Signal bewertet, besticht sich fast immer selbst, da es nichts gibt, gegen das es scheitern könnte. Dies ist ein gut dokumentiertes Problem und kein einmaliger Fehler: Ein Loop ohne Anhaltspunkte zum Scheitern wird immer glauben, erfolgreich gewesen zu sein.
Der Ausweg besteht darin, aufzuhören, das Modell zu bitten, sich selbst zu bewerten, und einem solchen Schleifenprozess einen externen Überprüfer zu geben: einen Testsuite mit Bestanden- oder Nichtbestanden-Status, einen Schema-Validierer, einen Compiler, eine Lint-Regel oder eine zweite unabhängige Abfrage, die die erste Antwort unterstützt oder widerlegt. evidenzbasierte Schleifen beobachten den Zustand der Welt, während konfidenzbasierte Schleifen darauf achten, wie sich das Modell fühlt.
Die Ralph Wiggum-Technik und warum eine einfache Schleife funktioniert
Ein Muster namens „Ralph Wiggum“ wurde nach seiner Beschreibung durch den Ingenieur Geoffrey Huntley im Jahr 2025 beliebt. Im Grunde genommen ist es äußerst einfach: Eine Bash-Schleife gibt denselben Prompt immer wieder an einen Programmieragenten weiter, bis die Aufgabe erledigt ist, wobei der Fortschritt in Dateien und Git-Commits gespeichert wird statt in der Erinnerung des Modells an das Gespräch.
#!/bin/bash
# ralph.sh - crude but surprisingly effective
while true; do
claude -p "$(cat PROMPT.md)" --dangerously-skip-permissions
if git diff --quiet HEAD~1 HEAD -- STATUS.md && grep -q "DONE" STATUS.md; then
echo "Task complete."
break
fi
sleep 5
done
Es scheint, als sollte es nicht funktionieren, und bei einer kleinen Überarbeitung stellt sich heraus, dass gerade diese Rohheit ein Vorteil ist. Durch das Wegwerfen des konversationellen Kontexts bei jeder Durchführung und das Erzwingen von Fortschritten in den Git-Historie- und Statusdateien wird ein Kontextverfall vermieden, und der Agent kann sich nicht mehr einreden, bereits etwas erledigt zu haben, was er nicht getan hat. Es ist nicht elegant – doch es basiert zufällig auf Beweisen, da Git und das Dateisystem nicht lügen, um das Modell zu schmeicheln.
Hier ist eine kleine, beweisbasierte Schleife derselben Art, die erneut lokal gegen Ollama ausgeführt werden kann und bei der ein fehlgeschlagener Test als die einzige akzeptable Bedeutung von „noch nicht fertig“ gilt.
def evidence_loop(task_description: str, max_attempts: int = 5):
attempt = 0
history = []
while attempt < max_attempts:
attempt += 1
code = generate_patch(task_description, history) # calls the model
apply_patch(code)
test_output = run_tests() # external evidence
passed = "failed" not in test_output.lower()
history.append({
"attempt": attempt,
"patch": code,
"test_output": test_output,
"passed": passed,
})
if passed:
return {"status": "success", "attempts": attempt}
# feed the *actual failure*, not a vague "try again"
task_description = (
f"{task_description}\n\nPrevious attempt failed with:\n{test_output}\n"
"Fix the specific failure above."
)
return {"status": "gave_up", "attempts": attempt, "history": history}
Betrachten Sie die letzte Zeile vor dem Rückgang, denn sie enthält die entscheidende Idee. Die Schleife sagt nicht „versuchen Sie intensiver“. Sie liefert dem Modell den tatsächlichen Testfehler, denn konkrete externe Belege sind es, die den zweiten Versuch besser als den ersten machen – und nicht ein zufälliger Neversuch. Bei den meisten Agenten ergibt sich der größte Zuverlässigkeitszuwachs durch den Ersatz von „Sieht das richtig aus?“ durch eine echte externe Überprüfung, die zum jeweiligen Auftrag passt.
Auch zu wissen, wann man aufhören muss, ist unerlässlich. Eine Schleife ohne feste Obergrenzen für Anzahl der Versuche, Kosten oder verstrichene Zeit ist kein zuverlässiger Agent – sie ist eher ein Fehler, der nur auf eine Rechnung wartet.
Das Diagramm: Wenn die Aufgabe echte Verzweigungen aufweist
Ein Gurt hält den Körper des Agenten fest und ein Schleifenmechanismus ermöglicht es ihm, Versuch für Versuch zu verbessern, doch keines davon beschreibt eine Aufgabe in Form eines Baums: Erst wird diese Aufgabe ausgeführt, anschließend wird je nach Ergebnis eine von drei Aktionen gewählt, auf die Zustimmung eines Menschen gewartet, danach werden zwei Überprüfungen parallel durchgeführt und miteinander kombiniert.
Das ist Graph-Engineering. Es ist in der Regel die Schicht, gegen die Widerstand geleistet wird, denn Schleifen scheinen lange Zeit auszureichen, werden aber unzureichend, wenn die Arbeit nicht in einem geraden Ablauf zu einem einzigen Bestehungstest führt. Schleifen sind nur bei einer Sache gut: Sie versuchen, überprüfen und ändern, bis eine Bedingung erfüllt ist. Sie sind unpraktisch, wenn der nächste Schritt davon abhängt, welches von mehreren Ergebnissen eingetreten ist, wenn zwei Teilaufgaben gleichzeitig fortgesetzt werden können oder wenn eine Person zustimmen muss, bevor weitergemacht werden kann. Das Hineinpacken all dessen in einen einzigen Prompt und die Hoffnung, dass das Modell den Überblick behält, hat bei einigen Teams funktioniert – doch es ist anfällig. Sobald echte Verzweigungen vorhanden sind, gehört der Kontrollfluss in eine explizite Struktur, nicht in das, was das Modell bei jeder Runde improvisiert.
Das Graphen-Engineering macht den Arbeitsablauf explizit. Knoten stellen Schritte dar, wie beispielsweise einen Aufruf eines Agents, einen Aufruf eines Tools, einen Validierer oder einen menschlichen Überprüfungspunkt, während Kanten die Bedingungen sind, die die Ausführung von einem Knoten zum nächsten führen. Ein Blick auf das Graph zeigt genau, welchen Weg eine Ausführung genommen hat – was bei einem Produktionsvorfall mitten in der Nacht von großer Bedeutung ist, da man wissen muss, was tatsächlich passiert ist, und nicht nur, was man annimmt.
LangGraph ist hier die übliche Wahl. Es repräsentiert einen Arbeitsablauf als gerichtetes Graphen, überträgt typisierte Zustände von Knoten zu Knoten, verwendet bedingte Kanten für die Verzweigung und verfügt über integrierte Überprüfungspunkte, sodass eine Ausführung gestoppt, neu gestartet oder auf einen früheren Zustand zurückgesetzt werden kann.
from langgraph.graph import StateGraph, END
from typing import TypedDict
class AgentState(TypedDict):
task: str
draft: str
review_passed: bool
attempts: int
def draft_node(state: AgentState) -> AgentState:
state["draft"] = generate_draft(state["task"])
return state
def review_node(state: AgentState) -> AgentState:
state["review_passed"] = run_validator(state["draft"])
state["attempts"] += 1
return state
def needs_human(state: AgentState) -> str:
if state["review_passed"]:
return "approved"
if state["attempts"] >= 3:
return "escalate" # branch: give up automating, ask a human
return "retry"
graph = StateGraph(AgentState)
graph.add_node("draft", draft_node)
graph.add_node("review", review_node)
graph.set_entry_point("draft")
graph.add_edge("draft", "review")
graph.add_conditional_edges(
"review",
needs_human,
{"approved": END, "retry": "draft", "escalate": "human_approval"},
)
Eine einfache Schleife hat Schwierigkeiten, klar darzustellen, was hier geschieht: Eine Überprüfung mit drei Ergebnissen (abgeschlossen, erneuter Versuch, Stoppen und Anfrage an einen Menschen), wobei jedes Ergebnis zu einer anderen Handlung führt. Der Eskalationsweg ist entscheidend – er macht den Unterschied zwischen einem Agenten, der nach dem dritten Misserfolg still aufgibt, und einem, der dem Menschen die gesamte Historie der unternommenen Versuche zur Verfügung stellt.
Auch Microsofts AutoGen fügte in diesem Jahr etwas Ähnliches hinzu, genannt GraphFlow, aus demselben Grund. Mehrere Agenten oder verzweigte Workflows erschweren es, eine implizite Schleife nachzuvollziehen, während ein Graph direkt überprüft werden kann.
Um zu beurteilen, in welchen Bereichen jedes Framework tatsächlich hervorsticht, anstatt sich auf Marketingseiten zu verlassen, wurden vier Frameworks an einem kleinen Projekt getestet: ein Dokumenten-Prüfungsprozess mit einer Validierungsstufe und einer menschlichen Freigabestufe.
FRAMEWORK ORCHESTRATION MODEL STRONGEST AT STATE / PERSISTENCE
--------------------------------------------------------------------------------------------
LangGraph Directed graph, typed Complex branching, Built-in checkpointing,
state, conditional edges long-running workflows, time-travel debugging
human-in-the-loop
--------------------------------------------------------------------------------------------
CrewAI Role-based "crew" of Fast prototyping, Sequential task output
agents, sequential or multi-agent brainstorm passing, lighter state
hierarchical process style collaboration model
--------------------------------------------------------------------------------------------
OpenAI Agents SDK Explicit agent handoffs Minimal-friction start Ephemeral context
inside the OpenAI variables by default
ecosystem
--------------------------------------------------------------------------------------------
AutoGen / GraphFlow Multi-agent conversation Agent-to-agent Conversation history
plus optional graph layer negotiation, graph- plus graph state
for explicit control based orchestration
--------------------------------------------------------------------------------------------
Die Schlussfolgerung ist praktisch. Wenn der Workflow auf einer Seite als einfache Liste von Schritten darstellbar ist, ist ein Graphenframework nicht notwendig – ein gut strukturierter Schleifencode innerhalb eines soliden Frameworks erledigt die Aufgabe mit weniger Code, der gewartet werden muss. Sobald der Workflow eine Gabelung aufweist, beginnt sich das Graphenframework bereits sofort zu lohnen, hauptsächlich durch eingesparte Zeit beim Debuggen und nicht durch Leistungen während der Ausführung.
Wie sich die drei Schichten überschneiden
Es handelt sich dabei nicht um konkurrierende Ansätze. Sie sind vertikal übereinander angeordnet, und so sieht die Struktur aus, nachdem man mit allen drei Ansätzen gearbeitet hat.
+--------------------------------------------------------------+
| GRAPH - decides which node runs next, where branches |
| are, where a human has to approve |
+--------------------------------------------------------------+
| LOOP - inside a given node, drives attempt -> verify -> |
| revise until the evidence says stop |
+--------------------------------------------------------------+
| HARNESS - underneath both, provides the tools, memory, |
| permissions, and limits that make any of it |
| possible to execute safely |
+--------------------------------------------------------------+
| MODEL - the reasoning engine none of the above exists |
| without |
+--------------------------------------------------------------+
In einem LangGraph-Ablauf kann ein Entwurfnode mehrere versuchsweise, evidenzbasierte Schleifen ausführen, bevor er die Kontrolle wieder an das Graph zurückgibt. Diese innere Schleife funktioniert nur, weil die darunterliegende Infrastruktur es dem Modell ermöglicht, Tests durchzuführen, Dateien zu lesen und an frühere Versuche anzuknüpfen. Entfernt man eine Schicht, bricht der gesamte Ablauf zusammen, weshalb die Erstellung eines monolithischen „Agents“ stets an Grenzen stoßen würde.
Durch Denken in drei Schichten wird das Debuggen deutlich schneller. Dies ist die Checkliste, die in dieser Reihenfolge durchgegangen werden sollte, bevor man an einen Prompt herangeht.
SYMPTOM LIKELY LAYER TO CHECK FIRST
----------------------------------------------------------------------
Agent doesn't know something it should Harness -> context injection
Agent "can't" do something it should be Harness -> action surface /
able to do permissions
Agent forgets earlier progress after a Harness -> persistence
restart or long run
Costs or run time spiral unexpectedly Harness -> execution control
Agent confidently reports success on Loop -> swap confidence checks
work that's actually wrong for external evidence
Agent retries the same mistake Loop -> is it seeing the actual
repeatedly without improving failure, or just "try again"?
Agent takes the wrong path when a task Graph -> is the branching logic
has more than one possible outcome explicit, or implicit in a
single prompt?
No human ever gets a chance to catch a Graph -> is there an approval
bad decision before it ships node, or is it all automatic?
Eine solche Tabelle hätte ein ganzes Wochenende voller Schuldzuweisungen an die Anfrage erspart – obwohl es eigentlich um fehlende Kontrollpunkte ging.
Offene Fragen
Einige Dinge sind noch unklar, und es wäre falsch, mit größerer Sicherheit zu sprechen, als die Beweise zulassen.
Zunächst entwickelt sich das Vokabular weiter. „Harness Engineering“ existierte vor diesem Jahr kaum in großem Umfang, und in einem Jahr könnte es in den umfassenderen Begriff „Agent Engineering“ aufgegangen sein, wobei Begriffe wie „Harness“, „Loop“ und „Graph“ zu Unterkapiteln werden und keine Fachgebiete mehr darstellen, in denen Menschen spezialisieren.
Zweitens wirkt der Ansatz von Ralph Wiggum selbst dann etwas unpassend, wenn er erfolgreich ist. Dem Modell einen Prompt in einer einfachen Schleife zu geben und sich auf die Git-Historie als einzige „Erinnerung“ zu verlassen, gleicht einem Pflaster auf einem Gurt ohne echte Persistenz. Er eignet sich für kleine, eng abgegrenzte Anpassungen, doch bei Projekten mit echten Branches oder Konsequenzen sollte man ihm noch nicht vertrauen.
Drittens können Graph-Frameworks sich weiterhin weiterentwickeln. LangGraphs Checkpointing ist hervorragend, doch Teams wählen manchmal ein ganzes Graph-Framework für einen dreistufigen Ablauf, der niemals verzweigt, nur weil es im Trend liegt. Ein Workflow, der eine gerade Linie ist, kann auch weiterhin eine bleiben.
Eine Behauptung bleibt trotz all dem bestehen: Ein unzuverlässiger Agent wird fast nie durch einen besseren Prompt behoben. Das Problem liegt fast immer in einem der drei Schichten, und die oben gestellten Fragen zeigen an, welche es ist.
Wenn man den Forschungsagenten ab heute startet, bedeutet das, zunächst die notwendige Infrastruktur zu entwickeln und diese als langweilige, tragende Struktur zu betrachten – und nicht als etwas, das erst später hinzukommt. Von Anfang an sollte ein evidenzbasiertes Verfahren zum Einsatz kommen, anstelle darauf zu vertrauen, dass das Modell sich selbst bewertet, denn allein diese Änderung behebt mehr Fehler als alles andere. Ein Graphenframework sollte erst dann eingesetzt werden, wenn der Arbeitsablauf auf Papier mit sichtbaren Verzweigungen dargestellt werden kann.
Das Modell hat seit drei Jahren die Aufmerksamkeit auf sich gezogen, doch die Zuverlässigkeit in der Praxis ergibt sich aus der darum herum entwickelten Ingenieursarbeit. Diese Arbeit ist weitaus weniger spektakulär und viel handhabbarer als die Behauptung, das Modell sei nicht intelligent genug. Meistens ist es das bereits. Es wurde einfach noch nicht mit der erforderlichen Umgebung, den Rückmeldungen oder der Karte versorgt, um dies zu zeigen.
Verwandte Artikel
- LangGraph-Konzepte in einfachen Worten: Zustand, Speicher und Orchestrierung — Bevor man Code schreibt: Was Orchestrierung, Laufzeitumgebung, zustandsbasierte Agenten, kurzfristiger und langfristiger Speicher sowie mehrere Agenten und menschliche Einflussnahme in LangGraph bedeuten.
- Erstellung eines DeepAgents Harness: Berechtigungen, Unteragenten und menschliche Genehmigung — Eine praktische Umsetzung eines System-Design-Planers mit DeepAgents: Dateibackends, Berechtigungsregeln, Unteragenten, Genehmigungsmechanismen, Fähigkeiten und MCP – sowie die Bereiche, in denen das Urteilsvermögen der Modelle weiterhin versagt.