2026-07-22 · Aktualisiert 2026-07-22

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Harness Engineering für AI Agents: Gestaltung des Schleifenlaufs um den Model

Teil 6 der Serie „Engineering des Agentic-Stacks“

Der Reasoning Loop eines Agent wählt die nächste Aktion aus. Sein Harness stellt den Kontext bereit, prüft sowie autorisiert die vorgeschlagenen Tool Calls, leitet die angenommenen Aufrufe an den Runtime weiter, protokolliert die Ergebnisse und entscheidet darüber, ob die Aufgabe abgeschlossen ist.

Der Models kann Änderungen vorschlagen und Aufgaben als abgeschlossen markieren, während der Harness die Berechtigungen durchsetzt sowie die Annahmekontrollen auswertet, die entscheiden, ob der Schleifenlauf beendet werden darf. Teil 5 Es wurde der Runtime behandelt, der den Prozess am Laufen hält. Dieser Artikel konzentriert sich auf den Steuercode innerhalb dieses Runtime: wie man feststellt, ob jede Ergänzung einen Nutzen bringt, und wie man sicherstellt, dass die entstehenden Steuermechanismen auch bei Veränderungen des Harness weiterhin auffindbar bleiben.

Neben der ersten expliziten Akzeptanzprüfung stellt jeder zusätzliche Versuch, jede Weiterleitung oder Evaluator eine Hypothese bezüglich eines festgestellten Fehlers dar. Er erhält erst dann Bedeutung, wenn ein kontrollierter Vergleich zeigt, dass er tatsächlich hilft.

Um diesen Steuerungspfad konkret zu machen, werde ich ein kleines fiktives Store-Repository verwenden. Die Programmieraufgabe besteht darin, die Schwellenwert für einen automatischen Rabatt von 10 % von 100 $auf 75$ zu senken. src/checkout.py. Der Repository enthält zwei erforderliche Überprüfungen:

• pytest tests/test_checkout.py überprüft die Berechnung des Rabatts. pnpm playwright test tests/checkout_discount.spec.ts Fügt ein Element im Wert von 80 $in einen lokalen Test-Shop hinzu und überprüft, ob auf der Bezahloberfläche ein Rabatt von 8$ angezeigt wird.

Das Beispiel dient lediglich als Lehrmittel und stellt weder eine echte Anwendung noch Benchmark dar. Jeder Versuch beginnt mit demselben Commit sowie den initialisierten Testdaten. Der Harness kann die Änderung erst dann akzeptieren, wenn beide Befehle erfolgreich ausgeführt werden und der Trace diese Ergebnisse mit dem getesteten Commit verknüpft.

In den folgenden Abschnitten wechseln wir bewusst zu zwei weiteren Beispielen. Eine Reihenfolge der Ausführung API veranschaulicht, warum aufrufe, die den Zustand ändern, eine Wiederholungsschutzfunktion benötigen, während eine Migration eines Zahlungsadapters zeigt, was ein neuer Model Session tun muss, um unvollendete Aufgaben fortzusetzen. Das begleitende Labor am Ende ist erneut getrennt: Es lässt sich ausführen, enthält jedoch allgemeine simulierte Aufgaben anstelle dieses Repositorys.

Zusammenfassung: Beginnen Sie mit einem. Modeleinige spezialisierte Werkzeuge sowie eine explizite Zustimmungskontrolle. Fügen Sie nach dem Vorgang Wiederholungsversuche hinzu. Traces Zeigen Sie vorübergehende Aufruffehler an. Fügen Sie bei Wiederaufnahme einen Fortschrittsbericht hinzu. Sessions die gleiche Arbeit wiederholen. Wenn Sie eine Änderung testen, achten Sie darauf, die Model Die Version, die Aufgaben, der Bewertungsalgorithmus sowie das Gesamtbudget sind festgelegt. Entfernen Sie den jeweiligen Komponenten, sobald dieser keine Verbesserung des gemessenen Ergebnisses bewirkt.

Das Diagramm verfolgt die Veränderung des Diskonts von der Vorschlagsphase bis zur Evidenzphase. Der Harness stellt die Aufgaben sowie die Dateien bereit und überprüft den vorgeschlagenen edit_file Argumente sowie Berechtigungen prüfen und den akzeptierten Aufruf weiterleiten. Nachdem der Runtime die Änderung angewendet hat, führt der Harness die definierten Unit-Tests sowie die Browser-Acceptanztests aus. Ein fehlgeschlagener Befehl wird als Nachweis für einen weiteren Versuch an den Model zurückgesendet; zwei erfolgreiche Befehle machen die Änderung für die Freigabe bereit.

Was der Harness besitzt

OpenAI’s Durchgang durch den Codex-Loop Es wird der grundlegende Ablauf beschrieben. Der Harness erstellt einen Prompt, fragt den Model nach der nächsten Aktion, sendet eine akzeptierte Tool Call an den Runtime, fügt das Ergebnis hinzu und fragt erneut nach, bis entweder der Harness das Ergebnis akzeptiert oder die Steuerung an den Benutzer zurückgegeben wird.

Implementierungen können mehrere Verantwortungsbereiche in einen einzigen Prozess zusammenfassen. Die Fehlergrenzen bleiben dennoch unterschiedlich:

Wenn ein Fehler auftritt, muss zunächst die Grenze diagnostiziert werden, die eigentlich reagieren sollte. Ein unzureichender Plan kann bessere Anweisungen oder Model Reasoning erfordern. Wenn edit_file zielt auf einen Pfad außerhalb ab src/Der Harness sollte diesen Vorgang ablehnen, während ein Sandbox-Prozess, der vor Ausführung der Änderung abstirbt, zur Kategorie Runtime gehört; dieser muss entweder den Worker neu starten oder den Absturz melden.

OpenAIs eigene Harness – Fallstudie zur Ingenieurpraxis Es wird eine startbare Anwendungsinstanz für jeden Worktree beschrieben. Das Team integrierte außerdem die Browserautomatisierung in die Agent-Umgebung und stellte Logs, Metriken sowie Traces zur Verfügung.

Eine Aufgabe wie „Kein Span in diesen vier kritischen Benutzerpfaden darf länger als zwei Sekunden dauern“ wurde testbar, da der Agent die Anwendung ausführen sowie dieselben Leistungsindikatoren abfragen konnte, die ein Ingenieur normalerweise überprüft. Die Fallstudie ist produktspezifisch. Was übertragen wird, ist die Bedingung hinter dem Ergebnis: Die Anwendung sowie ihre Leistungsindikatoren mussten innerhalb der Agent-Umgebung verfügbar sein.

Lopopolo, der Autor dieser Fallstudie, führt ein Feldhandbuch für Harness-Entwicklung Dadurch werden die beiden Schlüsselfaktoren benannt, auf die sich dieser Artikel konzentriert: das Festhalten von Model sowie der Programmierung Agent als Black Box und die gezielte Gestaltung des Kontexts sowie der Werkzeuge rund um diese Elemente. Seine Darstellung macht zudem klar, warum ein Großteil der Harness letztendlich als gewöhnlicher Code endet.

Die Qualitätsstandards, Verfahren, Historie von Ausnahmen sowie die Autorisierungsbeziehungen einer Organisation bleiben unterhalb des Wissenshorizonts eines herkömmlichen Model. Der Harness macht sie durch Repository-Anweisungen, Berechtigungsregeln und Acceptanzprüfungen sichtbar. Jeder erfolgreich abgeschlossene Ausführungsvorgang kann seine Erkenntnisse wieder in diese Artefakte einbringen, anstatt darauf angewiesen zu sein, dass ein folgender Session sie erneut herausfindet.

Verfolgen Sie die Änderung des Rabatts vom Entwurf bis zur Freigabe

Für die oben definierte Rabattaufgabe schlägt der Model vor, dies zu ändern calculate_discount in src/checkout.py. Mehrere Dinge geschehen vorher, wobei jede Änderung bereits als Fortschritt gilt:

1. Der Kontextbuilder stellt die Aufgabe, die Anweisungen zum Repository, die relevanten Dateien, die vorherigen Tool Results sowie den aktuellen Plan bereit.
2. Der Model schlägt einen Vorschlag vor. edit_file aufrufen mit einem Pfad und Ersatztext.
3. Die Tool-Grenze (der Harness-Code zwischen Vorschlag und Ausführung) prüft die Argumente, überprüft den Pfad hinsichtlich des zulässigen Umfangs und beantragt bei Bedarf Genehmigung.
4. Der Runtime führt die Änderung im Sandbox durch und gibt ein strukturiertes Ergebnis zurück.
5. Der Harness wird ausgeführt. pytest tests/test_checkout.py, gefolgt von pnpm playwright test tests/checkout_discount.spec.tsund liest beide Abbruchcodes aus. Der Browser-Test überprüft den sichtbaren Rabatt von 8 $im mit 80$ initialisierten Warenkorb.
6. Der Harness bestimmt, was die Ergebnisse bedeuten. Eine fehlgeschlagene Überprüfung wird zum neuen Kontext für den nächsten Model‑Schritt, während ein erfolgreicher Test die Aufgabe zu einem Kandidaten für die Abschlussprüfung macht.
7. Ein erfolgreiches Ergebnis gilt erst nachdem der Harness Befehl, Abbruchcode sowie Version des getesteten Artefakts im Trace aufgezeichnet hat, als Nachweis für die Abschlussprüfung.

In Schritt 2 hat sich keine Datei geändert. Der Harness kann dies ablehnen. ../../secrets.env, erfordert die Genehmigung für einen zerstörerischen Befehl oder stoppt eine Ausführung, die ihr Budget bereits aufgebraucht hat. Nach Abschluss der Tests liest der Harness die entsprechenden Exit-Codes selbst aus. Der Model kann seine eigene Änderung nicht als erfolgreich markieren.

Der Trace sollte den vorgeschlagenen Pfad sowie den Ersatztext, die Berechtigungsentscheidung, die geänderten Dateien, den getesteten Commit und die Ergebnisse beider Befehle anzeigen. Eine abschließende done Eine Nachricht ohne diese Aufzeichnungen beweist nicht, dass diese Änderung die erforderlichen Überprüfungen bestanden hat.

Bestimmen, wo jede Regel durchgesetzt wird

platzieren tests/checkout_discount.spec.ts Innerhalb der normalen Programmlogik leitet der Harness den Playwright-Befehl an den Runtime weiter, liest dessen Abbruchcode aus und weigert sich, die Ausführung zu beenden, solange dieser fehlschlägt. Ein Prompt kann den Model daran erinnern, den Test auszuführen. Er kann jedoch nicht verhindern, dass der Model ohne entsprechende Belege einen Erfolg meldet.

Andere Regeln gelten für unterschiedliche Schichten:

Toolverträge trennen Vorschlag von Genehmigung

Die Rabattaufgabe erfordert lediglich Dateiänderungen sowie Testbefehle. Ein Zustandswechsel von API weist einen anderen Fehlermodus auf, weshalb die Beispiele für diesen Abschnitt ausgetauscht werden müssen. Angenommen, der Agent kann aufrufen create_test_order gegenüber einem Staging-Order-Dienst beim Erstellen von Testdaten. Dieses Werkzeug gehört nicht zu den Akzeptanzprüfungen der Rabattaufgabe. Es ist hier nützlich, da ein Timeout verbergen kann, ob der Dienst eine Bestellung erstellt hat.

Die Grenzen des Tools erfordern mehr als nur eine Beschreibung in natürlicher Sprache. Für create_test_order, der Harness benötigt einen Vertrag mit:

• Validierte Argumente, sodass fehlerhafte Eingaben vor der Ausführung abgelehnt werden
• ein strukturiertes Ergebnis wie { "order_id": "123", "created": true }, sodass spätere Überprüfungen keinen freien Text analysieren müssen.
• Eine Effektkategorie, die festhält, ob der Aufruf lediglich Informationen abruft oder eine Datei, einen Datenbankeintrag oder einen externen Dienst ändert. Zudem wird darin erfasst, ob ein erneuter Aufruf sicher ist. Diese Kennzeichnung teilt dem Harness mit, ob ein automatischer Neversuch Arbeit doppelt erledigen könnte: Er kann dann erneut versuchen. get_order_status wenn der Service diese Abfrage als nur zum Lesen definiert, darf er jedoch nicht blind wiederholt versuchen, sie auszuführen. create_test_order denn der erste Aufruf hat möglicherweise bereits die Bestellung erstellt – eine Timeout- und Wiederholungspolitik, sodass ein verloren gegangenes Antwortsignal keine unbeschränkte Abfolge von Aufrufen auslöst – eine Berechtigungsregel, die angibt, welche Genehmigung erforderlich ist. Das Abrufen des Bestellstatus kann automatisch erfolgen, während die Erstellung einer Bestellung eine Bestätigung erfordern kann

Die natursprachliche Beschreibung ist der Text, der dem Model angezeigt wird. Dort kann stehen beispielsweise: „Erstellen Sie eine Testbestellung zur Überprüfung des Checkout-Prozesses.“ Dieser Satz unterstützt den Model dabei, zu entscheiden, wann ein Vorschlag eingereicht werden soll. create_test_order. Es autorisiert den Aufruf nicht. In diesem Beispiel überprüft der MCP-Client des Harness die Argumente, wendet eigene Regeln an und prüft vor dem Versand jeglicher Daten den Server-Zugriff, die Genehmigungsanforderungen sowie die Sicherheit bei erneuten Versuchen.

Ein MCP-Server stellt dem Client Beschreibungen von Tools sowie optionalen Anmerkungen zu deren Verhalten zur Verfügung. Ein fehlerhafter oder bösartiger Server könnte ein Zustandsänderndes Tool als unbedenklich darstellen. Wenn der Client diese Angabe automatisch akzeptiert, könnte er es ausführen oder erneut versuchen. create_test_order ohne Genehmigung eine Kopie erstellen zu können, weshalb die MCP-Spezifikation von den Kunden verlangt, dass sie Tool-Annotierungen als unzuverlässig einzustufen es sei denn, dem Server selbst wird Vertrauen entgegengebracht.

Die Spezifikation legt keine einheitliche Einstellung für das Vertrauensniveau fest. Der Client benötigt daher eine explizite Vertrauensrichtlinie für seinen Deployment; ein Server kann seine eigenen Anmerkungen nicht automatisch als vertrauenswürdig betrachten. Diese Richtlinie bestimmt, welche Metadaten Einfluss auf Entscheidungen bezüglich Berechtigungen oder Wiederholungsversuchen haben dürfen und welche Anmerkungen lediglich als Empfehlungen gelten.

Das Wiederholen einer aufrüstbaren Anfrage erfordert Replay-Schutz

Ein schwierigereres Problem bei der Wiederholung versucht sich dann zu zeigen, wenn create_test_order Es wird eine Bestellung erstellt, doch die dazugehörige HTTP-Antwort geht verloren. Der Harness erkennt einen Zeitüberschreitung und kann nicht feststellen, ob der Server die Anfrage abgeschlossen hat. Durch Wiederholung des Aufrufs könnte eine zweite Bestellung entstehen.

Eine Statusabfrage kann erneut durchgeführt werden, wenn der Service diese als nur für Lesezugriff definiert hat. Ein Erstellungsaufruf hingegen benötigt Schutzmechanismen wie eine Idempotenzschlüssel: Der Client fügt einen eindeutigen Anfragenidentifikator hinzu, und der Service gibt bei Wiedererkennung dieses Identifikators das erste Ergebnis zurück, anstatt eine weitere Bestellung zu erstellen. Ohne diesen Schutz muss der Harness prüfen, ob die Bestellung bereits existiert, oder vor einem weiteren Versuch eine menschliche Entscheidung einholen. AWS dokumentiert dieses Vorgehen in seinen Leitlinien für idempotente Operationen API.

Die Akzeptanz erfordert unabhängige Nachweise.

ein erfolgreiches create_test_order Die Antwort besagt lediglich, dass das Tool Daten zurückgegeben hat. Sie beweist jedoch nicht, dass eine Programmieraufgabe ihre Tests bestanden hat. Falls ein späterer Browsertest von der festgelegten Abfolge abhängt, muss der Harness das Antwort-Schema überprüfen und den Test dennoch ausführen, bevor er die Codeänderung akzeptiert.

Einige Kriterien lassen sich nicht auf einen Abbruchcode reduzieren. Für eine separate Aufgabe im Bereich visuelles Design kann ein neuer Evaluator eine dargestellte Seite oder ein Diagramm mit einer schriftlichen Bewertungskriterienliste vergleichen. Die Teams sollten vor der Verwendung als Abschlussprüfung sicherstellen, dass Evaluator mit menschlichen Überprüfungen abgeglichen wurde.

Eine Migration des Zahlungs-Adapters erfordert eine Übergabeprozessierung

Wechseln Sie erneut zu den Aufgaben, bleiben Sie jedoch im fiktiven Store-Repository. Der Agent muss nun den Zahlungsvorgang vom Payment-Adapter v1 auf v2 migrieren. Dabei fallen Arbeiten an dem Spans für den Checkout-Handler, den Payment-Client, die Konfiguration sowie die Tests an, damit dieser länger als ein Model Session erhalten bleibt.

Bevor der erste Session seine Kontextgrenze erreicht, hat er bereits mehrere Dateien geändert, eine lokale Zahlung Sandbox gestartet und ist anschließend gegangen. tests/payment_migration.spec.ts Es fehlt. Der Browser-Acceptanztest führt eine Zahlung über den Adapter v2 durch und überprüft die gespeicherte Anbieter-ID. Eine Gesprächsübersicht kann die nächste Model Session orientieren, doch sie kann weder den Sandbox neu starten noch nachweisen, welche Dateien derzeit geändert wurden.

Der nächste Session muss drei Dinge wiederherstellen:

Durch Komprimierung werden ältere Nachrichten durch eine kürzere Zusammenfassung ersetzt, damit der aktuelle Session fortgesetzt werden kann. Eine Fortschrittsübergabe dokumentiert, was der nächste Session benötigt: die aktuelle Branch, die geänderten Dateien, den letzten Testbefehl samt Ausgabe sowie den nächsten ungelösten Schritt. Falls die alte Konversation veraltete Annahmen enthält, kann der Harness mit dieser Übergabe sowie dem aktuellen Arbeitsbereich einen neuen Model Session starten. Das Ersetzen eines abstürzenden Workers und das Wiederherstellen seiner Prozesse stellt hingegen eine separate Runtime-Wiederherstellungsaktion dar.

Eine kleine Anpassung der Dokumentation erfordert möglicherweise keines dieser Mechanismen. Bei der Migration der Zahlungen ist ein Übergabeprozess erforderlich, sobald die Arbeiten Sessions überschreiten, da der nächste Model Session sowohl den Arbeitsraum als auch den Status der Aufgabe neu erstellen muss.

Anthropics Experimente mit langlaufende Programmierung Agents zwischen Sessions wurden die Git-Historie sowie eine Fortschrittsdatei genutzt, während später Harness-Designbericht es trennt die Komprimierung von der Übertragung in einen neuen Kontext und gibt den zusätzlichen Orchestration-, Token-Verbrauch sowie die für die Übertragungen erforderliche Laufzeit an.

Verwenden Sie Traces, um drei verschiedene Fehlerarten voneinander zu unterscheiden

Die nächsten drei Zeilen sind exemplarische Trace Skizzen und keine gemessenen Ausführungen bzw. Ergebnisse aus dem dazugehörigen Labor. Jede Zeile zeigt einen anderen Fehler und somit eine andere Harness Reaktion.

Diese Unterscheidung ist von Bedeutung, da ein 503 Es macht nicht jeden Aufruf sicher für eine erneute Ausführung. Die erste Zeile dient lediglich als lesbarer Lookup. Die zweite Zeile ist eine Anfrage, die den Zustand ändert; daher entscheiden der Idempotenzschlüssel sowie der Status auf Serverseite darüber, ob ein weiterer Erstellungsversuch zulässig ist. Die dritte Zeile stellt keineswegs einen Tool-Fehler dar – der Harness hat noch keine notwendigen Belege gesammelt, um die Preissenkung anzunehmen.

Ein Chat-Transkript dokumentiert, was der Model wahrnahm. Es kann jedoch nicht nachweisen, ob der Bestelldienst die Anfrage bereits vor dem Verschwinden der Antwort abgesetzt hat. Der Trace muss die Client-Anfrage, die Freigabebeschluss, die Idempotenzschlüssel, das Server-Ergebnis oder den Statusabgleich, die getestete Commit-Aktion sowie das Ergebnis des Akzeptanztests enthalten. Diese Felder geben dem Harness an, auf welchem der drei möglichen Pfade er sich befindet.

Bevor Sie ein Komponente hinzufügen, geben Sie an, welchen wiederkehrenden Fehler sie reduzieren soll sowie welche Kennzahl Sie überwachen werden. Entfernen Sie die Komponente, wenn ein kontrolliertes Vergleichsverfahren diese Kennzahl nicht ausreichend senkt, um deren Kosten zu rechtfertigen.

Messen Sie eine Änderung nach der anderen

Durch eine Ablation wird überprüft, ob ein Harness-Komponente den erwarteten Effekt hervorruft, indem diese Komponente entweder geändert oder entfernt wird, während der Rest des Experiments unverändert bleibt. Zum Beispiel: Hilft die Linting-Funktion des Editors dabei, dieses Model in diesem Aufgabensatz zu verbessern?

Verwenden Sie das folgende Protokoll:

1. Einfrieren Sie die Version von Model, die Task-Instanzen, die Umgebung, den Bewertungsmechanismus sowie Prompts außerhalb des getesteten Komponentenmoduls.
2. Weisen Sie beiden Varianten denselben Gesamtbudgetwert für Token, Zeit und Kosten zu.
3. Wählen Sie vor dem Durchführen des Vergleichs die Anzahl der Versuche oder die Regel zur Beendigung des Laufs aus.
4. Führen Sie in beiden Varianten dieselben Task-Instanzen aus. Da die Ausgaben von Model variieren, wiederholen Sie jede Aufgabe mehrfach.
5. Geben Sie den Mittelwert zusammen mit der Streuung oder dem Konfidenzintervall an.
6. Zählen Sie jeden gestarteten Versuch mit – einschließlich Timeout-Fällen, Beendigungen aufgrund von Strategiebeschränkungen, Harness-Abstürzen sowie Evaluator-Fehlern.

Allein die Erfolgsrate kann einen kostspieligen Faktor verbergen. Mindestens sollten Sie fehlerhafte Aufgaben verfolgen, die als abgeschlossen markiert wurden, sowie die Kosten und die Bearbeitungszeit pro abgeschlossener Aufgabe, Tool-Fehler, doppelte Bestellungen, die Dauer der Überprüfungen sowie manuelle Freigabeanpassungen. Wählen Sie den Kennwert, der den tatsächlichen Kostenfaktor für das Produkt darstellt. Ein Anstieg um zwei Punkte bei den abgeschlossenen Aufgaben ist nur dann sinnvoll, wenn dadurch nicht die Warteschlange der Überprüfungen verdoppelt wird.

Ein Paarungsversuch zur Migration von Zahlungen macht die Übertragung des Fortschritts messbar. Jedes Kontroll-/Behandlungs-Paar startet mit derselben Repository-Commit-Version und wird mit demselben Checkpoint, der gleichen Model-Aufgabe, dem gleichen Bewertungstool sowie dem gleichen Gesamtbudget initialisiert. Die Übertragung stellt dabei den einzigen Wechselpunkt dar. Die primäre Metrik zählt doppelte Tool-Aktionen nach der Wiederaufnahme: Eine Aktion gilt als doppelt, wenn ihre Operation und das erzeugte Ergebnis mit einem Schritt übereinstimmen, den der vorherige Session bereits abgeschlossen hat.

Der SWE-Paper zu Agent behebt Probleme bei GPT-4 Turbo im 300-Aufgaben-SWE-bench Lite-Teil und weist einen Lösungsgrad von 18,0 % mit der vollständigen Benutzeroberfläche auf, im Vergleich zu 11,0 % bei der reinen Shell-Version Agent. Zudem wurden im Paper einzelne Funktionen der Benutzeroberfläche geändert:

Diese Zahlen beziehen sich auf die Obergrenzen von Model, Benchmark sowie auf eine Gebühr von 4 Dollar pro Aufgabe. without linting, full file, und full history Die Zeilen stellen die nützlichen Einzellösungs-Tests dar: Jeder dieser Tests änderte eine bestimmte Schnittstellenfunktion, während der Model sowie die Bewertungsumgebung unverändert blieben.

LangChain hat eine erweiterte Version veröffentlicht. fixierte Model-Vergleich für deepagents-cli. Es weist einen Anstieg im Rahmen von Terminal-Bench 2.0 von 52,8 % auf 66,5 % auf. gpt-5.2-codex Während sein Team den System Prompt, die verwendeten Tools sowie das Middleware umgestellt hat, wurde dies behoben. Der entsprechende Post enthält mehrere Änderungen, lässt jedoch einen Konfidenzintervall, einen Vergleich zum festgelegten Gesamtbudget sowie eine Ablations-Tabelle pro Änderung aus. Aufgrund dessen ist es nicht möglich, die wirklich nützliche Änderung zu identifizieren.

Anthropics Bericht über eine langlaufende Anwendung Es handelt sich um eine qualitative, produktbezogene Fallstudie und nicht um ein kontrolliertes Benchmark-Experiment. Dabei wurden im Sprint 3 insgesamt 27 Kriterien des Level-Editors von Evaluator überprüft. Das Team berichtet, dass die durch Evaluator ausgelösten Aufrufe zu einer Belastung für Aufgaben wurden, die Opus 4.6 allein zuverlässig bewältigen konnte; dennoch trugen sie bei, besonders an den Grenzen der Model. Deshalb entfernte das Team nach dem Upgrade von Model die Harness-Komponenten nacheinander. Dieses Beispiel liefert einen Grund, alte Strukturen bei Änderungen von Model erneut zu überprüfen – es liefert jedoch keine Schätzung bezüglich der allgemeinen Effektstärke.

Stellen Sie sicher, dass der Harness nach seiner Einbindung weiterhin editierbar bleibt

Ablation dient dazu, einen bestimmten Bestandteil zu isolieren und seine Auswirkung auf das Gesamtsystem zu bewerten. Harness klein, doch sein Code kann dennoch länger bestehen als Model es wurde für … abgestimmt. Eine Anfrage wie „Verschleiere Geheimnisse in jedem Erfassungspfad“ bezeichnet ein Verhalten und nicht eine Datei. In der Produktion Harness, dieses Verhalten kann Span Ausführungsphasen sowie gemeinsamer Zustand. Ein Mensch oder die Programmierung Agent Man muss vor dem sicheren Ändern jede Implementierungsstelle finden.

ein Preprint von Wang et al. aus dem Jahr 2026, Harness Handbuch, Dieser Schritt wird als Behavioralisierung bezeichnet. Das Handbuch erstellt auf der Grundlage des Harness-Codebases eine auf Verhalten ausgerichtete Karte. Die statische Analyse extrahiert einen Programmgraphen ohne Model-Aufrufe, wobei anschließend ein LLM die einzelnen Komponenten in Ausführungsphasen strukturiert.

Der Wartungskraft oder der Programmierer von Agent beginnt mit einem Systemüberblick, öffnet anschließend die entsprechende Ausführungsstufe und geht schrittweise zu den quellbasierten Einträgen einer Funktion oder Datei über. Ein Registeransicht zeigt an, an welchen Stellen der gemeinsame Zustand zwischen den Stufen geschrieben und gelesen wird. Diese Hierarchie sorgt dafür, dass der Überblick übersichtlich bleibt, während gleichzeitig ein Pfad zum Quellcode aufrechterhalten wird.

Die Aktualität ist eine eigene Regel. Jeder Locator muss auf dem aktuellen Repository abgefragt werden. Das Handbuch ignoriert veraltete Einträge anstelle von Vermutungen, und jeder nicht leere Diff synchronisiert erneut die betroffenen Einträge.

Das Diagramm veranschaulicht den Modifikationszyklus: Eine ausschließlich auf Verhalten bezogene Anfrage durchläuft die verschiedenen Ebenen des Handbuchs, jeder potenzielle Lokator wird vor der Erstellung des Plans mit dem aktuellen Repository abgeglichen, und jede angewendete Differenz synchronisiert erneut die Karte.

Der Handbuchbewertung befolgt das von diesem Artikel befürwortete Protokoll. Anhand zweier Open-Source-Plattformen (Terminus-2 mit sechs Python-Dateien sowie das Codex-Monorepo mit 2.267 Rust-Dateien) untersuchte ein ausschließlich zum Lesen berechtigtes Planner, angetrieben von DeepSeek-V4-Pro, entweder den Repository-Inhalt direkt oder über das Handbuch. Anfragen, Berechtigungen für den Repository-Zugriff und die verwendeten Tools sowie die Dekodierung verliefen in beiden Ansätzen identisch. Drei Judges-Modelle (GPT-5.5, Opus 4.8, DeepSeek-V4-Pro) bewerteten jeden Edit-Plan hinsichtlich Lokalisierbarkeit, Kontrolle des Umfangs und Reasoning:

Die mit dem Handbuch unterstützte Planner führte in beiden Repositorien häufiger und setzte dabei weniger Planner Tokens ein. Zu diesem Ergebnis gehören weiterhin folgende Bedingungen: Drei LLM Judges erzielten gute Bewertungen für die durch einen Planner Model auf zwei Plattformen erstellten Bearbeitungspläne. Die Studie bewertete lediglich die Pläne, nicht die tatsächlich ausgeführten Änderungen oder die Fehlerraten in der Produktion.

In den vorangegangenen Abschnitten wird Traces verwendet, um zu erläutern, warum eine Komponente überhaupt existiert. Diese Zuordnung beantwortet die nächste Frage: Wo befindet sich diese Komponente, wenn sie geändert werden muss?

Probieren Sie die Methode im begleitenden Labor aus

Der Harness – Demo-Projekt im Commit 517353f3 ist eine kleine, deterministische Übung mit 12 generischen synthetischen Aufgaben, die Codeänderungen wie fix-parser-edge-case, split-large-module, und wire-browser-test. Es implementiert das fiktive Store-Repository nicht.

Jedes Task-Fixture deklariert eine Schwierigkeitsstufe sowie vier boolesche Bedingungen: ein unzuverlässiges Tool, verlorene Fortschritte, einen übersehenen Implementierungsfehler und eine unklare Abschlussbedingung. Der Simulator leitet für schwierige Aufgaben, die außerdem eine Fortschrittsdatei erfordern, eine fünfte Bedingung ab: ohne context_resetDurch Komprimierung bleiben veraltete Annahmen erhalten. Ein deterministischer Bewertungsmechanismus markiert eine Aufgabe als bestanden, nur wenn die ausgewählte Konfiguration alle relevanten Bedingungen berücksichtigt. Dabei werden weder Model noch externe Dienste ausgeführt.

Die Befehle beantworten unterschiedliche Fragen:

• make check führt Ruff sowie sieben Unit-Tests aus, darunter den Validator, der jedes Ablationspaar zurückweist, das mehr als einen Komponenten ändert. make run Es wird eine kumulative Lehrmatrix ausgegeben, gefolgt von fünf gültigen Vergleichen nach dem Prinzip „einen Komponenten weglassen“. make failures gibt die unverarbeitete Bedingung für jede fehlgeschlagene Aufgabe an. Der vollständige Harness muss mit einem Punkt enden all synthetic tasks pass.

make check
make run
make failures

Der kausale Abschnitt von make run Es sieht so aus:

component                 control  treatment  delta
retry_policy              8/12     12/12       +4
progress_handoff          7/12     12/12       +5
evaluator                 8/12     12/12       +4
fail_closed_acceptance    7/12     12/12       +5
context_reset            10/12     12/12       +2

In jeder Zeile stellt die Kontrollgruppe die vollständige Konfiguration dar, aus der ein einzelnes Komponente entfernt wurde; die Behandlungsgruppe wiederum setzt lediglich diese eine Komponente wieder her. Die frühere kumulative Matrix ist zwar hilfreich zur Orientierung, doch einige ihrer benachbarten Zeilen fügen mehrere Komponenten gleichzeitig hinzu und können daher keine Ursache identifizieren.

Das Labor überprüft jedes deklarierte Paar vor dem Ausführen. Zu seinen Regressionstests gehört außerdem ein absichtlich ungültiges Paar, das die Wiederholungspolitik sowie Evaluator gleichzeitig verändert; der Validator lehnt solche Einträge ab.

Das Konfigurationsschema des Labors überprüft alle fünf Komponentenfelder. Dieses ausführbare Auszug zeigt denselben Schutzmechanismus für ein gültiges Paar zur Übertragung des Fortschritts:

from dataclasses import dataclass, fields


@dataclass(frozen=True)
class Config:
    progress_handoff: bool = False
    evaluator: bool = False
    retry_policy: bool = False
    fail_closed_acceptance: bool = False
    context_reset: bool = False


def changed_components(control: Config, treatment: Config) -> tuple[str, ...]:
    return tuple(
        field.name
        for field in fields(control)
        if getattr(control, field.name) != getattr(treatment, field.name)
    )


control = Config(progress_handoff=False, evaluator=True, retry_policy=True)
treatment = Config(progress_handoff=True, evaluator=True, retry_policy=True)
assert changed_components(control, treatment) == ("progress_handoff",)

Beginnen Sie mit einer Schleife und einer Akzeptanzprüfung

Ich würde mit dem Entwickeln eines Coding-Agent Harness unter Verwendung eines leistungsfähigen Model-Repositories, entsprechender Anleitungsdokumente, einiger spezialisierter Tools, einer Sandbox sowie eines expliziten Akzeptanztests beginnen. Die dabei erzielten Tool Calls-Ergebnisse, Kosten sowie den Abschlusstest würde ich in einem Trace festhalten, damit die ersten relevanten Fehler ohne Umwege aus Terminalprotokollen oder Chat-Transkripten sichtbar sind. Es handelt sich dabei um einen vorgeschlagenen Basistandard und nicht um Daten aus einem bereits im Einsatz befindlichen System.

Fügen Sie von dort aus ausschließlich das hinzu, was ein Trace rechtfertigt. Dokumentieren Sie außerdem, wer jeden Komponenten wartet, wie viele Tokens bzw. Sekunden er hinzufügt, sowie welcher Regressionstest eine Entfernung nach einem Model-Upgrade rechtfertigen würde.

Sechs Monate später sieht jemand, der es betrachtet progress_handoff=True Es sollte in der Lage sein, den fehlgeschlagenen Traces zu identifizieren, der die Ursache dafür darstellt, sowie die Regressionsfälle, die ihn weiterhin dort belassen. Die Traces erläutern, warum das Komponente überhaupt existiert; eine aktuelle Verhaltenskarte zeigt an, wo an ihr gearbeitet werden muss.

Referenzen

• OpenAI, Das Entrollen des Codex Agent Loop.
• OpenAI, Harness Engineering: Nutzung von Codex in einer Welt, die auf Agent basiert.
• Lopopolo, Harness Engineering: Anthologie, Feldführer sowie Agent-Kontextpaket.
• Anthropic Engineering, Effektive Mechanismen für die Steuerung langlaufender Agents.
• Anthropic Engineering, Harness Entwurf für die Entwicklung langlaufender Anwendungen.
• LangChain, Verbesserung von Deep Agents mithilfe von Harness Engineering.
• Yang et al., SWE-Agent: Agent – Computer-Schnittstellen ermöglichen die automatisierte Softwareentwicklung.
• Wang et al., Harness Handbuch: Entwicklung sich wandelnder Agenten Agent Nutzt eine lesbare, navigierbare und editierbare Struktur, arXiv:2607.13285, 2026.
• AWS, Sichere Wiederholungsversuche durch idempotente Operationen gewährleisten APIs.
• Model Kontextprotokoll, Spezifikation der Tools.

Reihe: Entwicklung der Agentic-Stack-Struktur

• Teil 1: AI Agent Reasoning Schleifen im Jahr 2026: ReAct, ReWOO sowie Plan-and-Execute Teil 2: AI Agent Memory Architektur im Jahr 2026: Checkpoints, Vector Stores sowie Dokumentenmemorie Teil 3: AI Agent Tool Use im Jahr 2026: MCP, CLI, Fähigkeiten, Ausführung von Code sowie ACI
• Teil 4: AI Agent Sicherheit im Jahr 2026: Guardrails, Berechtigungen, Sandboxes, HITL sowie die Begrenzung des Zugriffsbereichs durch MCP Teil 5: Langlaufende AI Agent Runtime im Jahr 2026: Sessions, Sandboxes, Checkpoints sowie Steuermechanismen und Deployment-Formungen
• Teil 6: Harness Engineering für AI Agents (dieser Artikel)