Code as Agent Harness — Eine 102-seitige Survey, die Code als Ausführungsgrundlage für Agenten betrachtet

UIUC × Meta × Stanford als Gemeinschaftsarbeit. Es handelt sich um ein Survey-Paper, das im Mai auf arXiv erschienen ist, und die Perspektive ist ziemlich interessant.

Zentrale These

"Code ist nicht länger nur ein Ergebnis, das von LLMs erzeugt wird. Er ist das operational substrate, auf dem Agenten schlussfolgern, handeln, Zustand speichern und Feedback verifizieren."

Mit anderen Worten: Code ist nicht einfach nur eine .py-Datei, sondern die Welt selbst, in der Agenten leben. Diese Sichtweise nennt das Paper code as agent harness.

3-Schichten-Struktur

Das Paper analysiert Agentensysteme, indem es sie in drei Layer unterteilt:

① Harness Interface — Wie Code den Agenten mit der Umgebung verbindet

• Schlussfolgerungen werden wie bei Program-of-Thoughts in Code externalisiert und dann ausgeführt/verifiziert
• Bei GUI- oder Robotersteuerung arbeitet das generierte Programm als Policy
• Codebases, Traces und Simulatoren repräsentieren die Umgebung selbst

② Harness Mechanisms — Das Kontrollsystem, das langfristige Ausführung aufrechterhält

• Planning: entwickelt sich über einfache Decomposition hinaus zu dateisystembasierten, fortlaufenden Plänen wie PLAN.md. Meta-Harness behandelt sogar das Harness-Design selbst als Search Space
• Memory: analysiert nach working/semantic/experiential/long-term/multi-agent plus context compaction. Kernaussage: "Memory ist keine einzelne Vektor-DB, sondern eine integrierte Schicht für Zustandsverwaltung"
• PEV Loop: Der Zyklus Plan → Execute → Verify wird als cybernetic governor neu definiert. Die Ausführung folgt einem dreistufigen Berechtigungsmodell: read-only → sandbox-edit → full-access (HITL)
• AHE: eine Meta-Schicht, die das Harness selbst misst und optimiert

③ Scaling the Harness — Wie Multi-Agenten auf dem gemeinsamen Medium Code zusammenarbeiten

• Interessante Beobachtung: "Topologische Komplexität ist eine Steuer, die durch unausgereifte Repräsentationen gemeinsamen Zustands entsteht" — Systeme mit gut gestaltetem Zustand funktionieren auch mit einfachen Strukturen gut, während Systeme, die auf implizitem Zustand beruhen, dieses Defizit mit komplexerer Topologie kompensieren

Bemerkenswerte Punkte

• Context Compaction + State Offloading: Nicht alles in das Context Window packen, sondern nur die für Entscheidungen nötige Zusammenfassung im active context halten und die Gesamtdaten über MCP-style-Protokolle auslagern — ein wirklich praktischer Tipp
• Verifikation als deterministischer Sensor: Deterministisches Feedback wie Linter, Type Checker, Tests und Fuzzer ist ein verlässlicheres Kontrollsignal als LLM-Kritik
• Die Ursache von Fehlern liegt nicht im Modell, sondern im Harness: "Die meisten Agentenfehler kommen von unzureichendem Repository-Kontext, fragilen Tool-Interfaces, schwachen Verifikatoren, überhöhten Token-Kosten und schlechten Retry-Policies"

Open Problems

Unter den sieben offenen Problemen, die das Paper hinterlässt:

• Bewertung jenseits des Enderfolgs: Auch Zwischen-Traces, Wiederherstellungsversuche und Sicherheitschecks sollten erstklassige Metriken sein
• Harness-Verbesserungen ohne Regressionen: Wie man aus Fehlern lernt, ohne bestehendes Verhalten zu verschlechtern
• Transaktional geteilter Zustand zwischen Multi-Agenten: Konfliktlösung, wenn mehrere Agenten gleichzeitig Code ändern

Referenzen

• Paper: https://arxiv.org/abs/2605.18747
• Saubere Zusammenfassungsseite: https://code-as-harness.github.io/code-as-harness-webpage/
• Sammlung verwandter Paper: https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers