Prompt-, Kontext-, Loop- und Graph-Engineering entpuppten sich jeweils als ein Teil derselben Maschine. Das Harness ist der Ort, an dem sie endlich zusammenleben.
Jede Phase des Buildens mit KI erhielt ihren eigenen Jobtitel. Prompt Engineering kam zuerst, damals, als die gesamte Kunst darin bestand, den richtigen Satz zu finden.
Context Engineering folgte, sobald klar wurde, dass der Satz weniger wichtig war als alles, was darum herum geladen wurde. Diesen Sommer waren es Loops, und ein paar Wochen später Graphs.
Der Name, der sich jetzt verbreitet, ist Harness Engineering, und er ist der erste, der alle anderen erklärt.
Ein Harness ist alles um das Modell herum: die Tools, die es aufrufen kann, die Dateien, die es vor allem anderen liest, die Verzeichnisse, in die es schreiben darf, die Prüfung, die seine Ausgabe bestehen muss, der Zeitplan, der es aufweckt, und die Regel, die den Lauf beendet.
Jede Disziplin vor dieser stellt sich als eine einzelne Komponente dieses Rahmens heraus, getrennt aufgebaut und mit einem eigenen Namen versehen.
Ich begann aus praktischen Gründen darauf zu achten. Das darunterliegende Modell ändert sich ständig, manchmal um siebzehn Plätze im Leaderboard in einem einzigen Update, und das Harness ist der einzige Teil des Systems, der dir gehört.
1/ Sieben Engineerings, eine Maschine
Disziplin
Die Frage, die sie beantwortet
Wo sie im Harness lebt
Prompt Engineering
Was genau frage ich?
SKILL.md, die zuerst geladene Aufgabenspezifikation
Context Engineering
Was sieht das Modell bei jedem Schritt?
Der Context Assembler: Constraints, Schemas, abgerufene Seiten
Tool Engineering
Worauf kann es zugreifen, und in welcher Form?
Tool-Definitionen mit typisierten Eingaben und Ausgaben
Loop Engineering
Was startet einen Lauf und was beendet ihn?
Der Runner: Trigger, Stopp-Bedingungen, Budgets
Graph Engineering
An was erinnert es sich und wie sind die Dinge verbunden?
Die Memory-Schicht: Knoten, typisierte Kanten, Aliase
Eval Engineering
Wie wird ein Ergebnis verworfen?
Der Verifier, außerhalb der Kontrolle des Agenten
Harness Engineering
Was hält all das oben Genannte zusammen?
Der Rahmen, die Berechtigungen und die Hooks
Lies die Tabelle von oben nach unten, und es ist eine Geschichte. Lies sie von unten nach oben, und es ist eine Architektur: Harness Engineering ist die Aufgabe, festzulegen, wo jede der anderen sechs lebt, damit keine davon in einem Prompt versteckt endet.
Dieser letzte Punkt trägt das meiste Gewicht.
Ein Prompt ist der einfachste Ort, um irgendetwas abzulegen, also driftet alles hinein: das Ausgabeformat, die Stopp-Regel, die Korrekturen von letzter Woche, die Liste der Dinge, die der Agent niemals anfassen darf. Es funktioniert wunderbar auf dem Modell, für das du es geschrieben hast, und dann liest das nächste Modell denselben Absatz anders.
2/ Anatomie eines Harness
Die nützlichste Gewohnheit, die ich mir angeeignet habe, ist, das gesamte Harness als eine einzige Konfigurationsdatei aufzuschreiben, damit nichts Wichtiges implizit bleibt:
1# harness.yaml2model: kimi-k3 # one line. everything below survives a swap3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # nightly, while you sleep12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Drei Zeilen in dieser Datei erledigen die meiste Arbeit.
model: ist absichtlich eine Zeile. Alles andere ist so geschrieben, dass es egal ist, was diese Zeile sagt. Das ist die ganze Portabilitätsgeschichte.
permissions: ist wichtiger als tools:, obwohl es weiter unten in der Datei steht. Aufzuschreiben, was der Agent ändern darf und wonach er erst fragen muss, unterscheidet ein System, das du über Nacht laufen lässt, von einem, bei dem du danebensitzt und zuschaust.
verify: hat aus gutem Grund zwei Einträge. Das Skript kostet nichts und fängt alles Mechanische. Der Reviewer ist ein zweiter Agent, der nie gesehen hat, wie der erste gearbeitet hat, denn ein Agent, der seine eigene Ausgabe bewertet, findet jeden Grund zur Genehmigung.
Auf der Festplatte ist das Harness ein Ordner, und jedes Engineering aus der Tabelle erhält darin seine eigene Adresse.
3/ Warum Kimi K3 die Engine ist, die ich hineinsetzen würde
Was das Harness braucht
Was Kimi K3 mitbringt
Einen Runner, der ausfächern kann
Agent Swarm: bis zu 300 Agents gleichzeitig auf einem Problem, ohne einen Orchestrator zu schreiben
Code stark genug, um eigene Checks zu schreiben
#1 in der Frontend Code Arena mit 1.679, vor Fable 5 (1.631) und GPT-5.6 Sol (1.618), führt in 6 von 7 Domänen
Eine Engine, die unter dir besser wird
Von #18 auf #1 in einem einzigen Juli-Update
Die erste Zeile ist wichtiger, als sie aussieht. Fast jedes selbstgebaute Harness entwickelt irgendwann einen handgebauten Orchestrator, und das ist normalerweise die fragilste Datei im Ordner. Mit dem Swarm wird das Ausfächern zu einer Budgetzeile, agents: 300, und das Harness muss nur noch das verarbeiten, was zurückkommt.
Die zweite Zeile ist wichtig, weil ein Harness hauptsächlich Code ist, den das Modell für dich schreibt: Hook-Skripte, Schema-Checks, das kleine Dashboard, das 40-runs liest. Eine Engine, die die Frontend-Arena anführt, bekommt diese beim ersten Durchlauf viel häufiger richtig.
Die dritte Zeile ist der Fall für Harness Engineering in einem Datenpunkt. Wenn ein Modell über Nacht siebzehn Plätze klettert, macht ein Harness diesen Aufstieg am selben Tag nutzbar, weil die einzige Zeile, die geändert werden muss, model ist.
4/ Hooks: Die Reflexe
Ein Hook ist ein kurzes Skript, das das Harness zu einem festen Zeitpunkt ausführt, unabhängig davon, was das Modell beschließt. Hooks sind der Ort, an dem ein Harness aufhört, eine Ordnerstruktur zu sein, und anfängt, sich wie ein Sicherheitssystem zu verhalten.
Hook
Wann er feuert
Was er tut
pre_tool
Vor jedem Tool-Aufruf
Blockiert Schreibvorgänge außerhalb der Berechtigungsliste
post_tool
Nach jeder Rückgabe
Führt den Schema-Check durch und verwirft fehlerhafte Ausgaben sofort
pre_send
Bevor etwas die Maschine verlässt
Hält es in einer Warteschlange, bis du es freigibst
on_fail
Nach einem verworfenen Ergebnis
Hängt den Fehlergrund an den Retry an
post_run
Wenn die Stopp-Bedingung erreicht wird
Fügt den Laufdatensatz zu 40-runs hinzu und diffed den Graphen
Der pre_tool-Hook aus der ersten Zeile passt in fünf Zeilen:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
Allein der on_fail-Hook verändert die Ökonomie eines Loops. Ein Retry, der den Grund für das Scheitern des letzten Versuchs enthält, ist eine Korrektur. Ohne diesen Grund bezahlt der Loop zweimal für denselben Fehler.
5/ Wie eine Nacht aussieht
Setzt man alle Teile zusammen, verhält sich das Harness wie eine Nachtschicht, die Regeln befolgt. Um 02:00 Uhr feuert der Trigger, und die Startabfrage wählt jeden Knoten aus, der Arbeit benötigt. Der Swarm fächert aus, ein Agent pro Knoten.
Rückgaben, die das Schema verfehlen, werden von post_tool verworfen, bevor sie den Graphen erreichen, und jeder verworfene Knoten wiederholt einmal mit angehängtem Fehlergrund. Wenn ein Agent versucht, außerhalb seines Ordners zu schreiben, stoppt pre_tool ihn, ohne jemanden aufzuwecken.
Zusammengeführte Knoten und typisierte Kanten landen in 20-graph. Ein Entwurf einer E-Mail erreicht pre_send und wartet. post_run fügt den Datensatz hinzu, und der Loop stoppt aufgrund seiner eigenen Bedingung, weit innerhalb des 45-Minuten-Budgets aus der Konfiguration.
Um 07:30 Uhr liest du eine Datei und triffst zwei Entscheidungen. Das sind die gesamten Kosten des Morgens für das Betreiben von Loop-Engineering und Graph-Engineering auf diese Weise, und das ist der ganze Sinn des Harness: Alles, was ohne dich laufen konnte, lief, und die wenigen Dinge, die dich brauchten, warten an einem Ort.
6/ Der Swap-Test
Das schnellste Audit für jedes Agent-Setup: Ändere die Modellzeile und führe es erneut aus. Was auch immer kaputtgeht, war ein Harness, das am falschen Ort lebte.
Was nach dem Swap kaputtgeht
Wo es sich versteckte
Wo es hingehört
Das Ausgabeformat driftet
„always answer as JSON“ im Prompt
Ein Return-Schema plus ein Skript, das alles andere verwirft
Läufe hören nicht mehr von selbst auf
„keep going until it's thorough“
Eine Stopp-Bedingung aus Zählungen
Die Korrekturen von letzter Woche sind weg
Der Chat-Verlauf
CONSTRAINTS.md, bei jedem Lauf geladen
Dasselbe Unternehmen taucht dreimal auf
Das Urteil des Modells
aliases.csv, vor dem Merge geprüft
Es schreibt irgendwohin, wo es nicht sollte
Ein höflicher Satz im Prompt
Eine Berechtigungsliste und ein pre_tool-Hook
Ein Setup, das den Swap-Test besteht, ist portabel, und portabel ist, was es wertvoll macht.
Was es kostet und was es bringt
Unternehmen investieren ganze Quartale in interne Agent-Plattformen. Ein funktionierendes Harness ist ein Ordner, eine Konfigurationsdatei und fünf kurze Skripte, und es läuft auf einem Kimi-Abo. Diese Lücke ist die Chance.
Kanal
Was es bringt
Was du zuerst brauchst
Harness-Setup für ein kleines Team
Eine einmalige Gebühr im vierstelligen Bereich für das Config, Hooks und Verifier rund um ihren Workflow
Ein eigenes Harness, das auf einem Zeitplan läuft
Release-Day-Retainer
Eine monatliche Gebühr, um den Swap-Test bei jedem großen Modell-Release durchzuführen und das Team zum führenden Modell zu bewegen
Ein Kunde, dessen Läufe bereits in 40-runs protokolliert werden
Ein Nischen-Harness-Template
Der Ordner und die yaml, verpackt für eine Branche: Forschung, Recruiting, Compliance
Dasselbe Harness, bewiesen in zwei verschiedenen Märkten
Den zweiten Kanal würde ich zuerst aufbauen. Jedes große Release würfelt das Leaderboard neu, allein K3 bewegte sich siebzehn Plätze in einem Update, und jedes Team mit einem Harness braucht jemanden, dessen Job es ist, den Swap-Test am Release-Tag durchzuführen.
Die Kurzfassung
Prompt-, Context-, Tool-, Loop-, Graph- und Eval-Engineering stellen sich alle als Komponenten einer einzigen Maschine heraus, und Harness Engineering ist die Entscheidung darüber, wo jede von ihnen lebt.
Setze das Modell hinter eine Zeile, Berechtigungen vor Tools und den Verifier außerhalb des Agenten. Dann ist der nächste Sprung im Leaderboard eine Konfigurationsänderung statt eines Neuaufbaus.
Und wenn du das hier nützlich findest:
- Lesezeichen setzen. Die Links ändern sich und neue Repos tauchen wöchentlich auf, du wirst das als Referenz brauchen
- Für wöchentliche Deep Dives in KI-Architektur, Quant Trading und die Agent Economy, folge mir: @polydao
- Tritt dem TG Channel bei: Buzzoni Notes – hier teile ich meine rohen Prompts, benutzerdefinierten Skills und Alpha, das zu früh für X ist
