AI Agent Harness: einen zuverlässigen Runtime entwerfen

Ein AI Agent Harness ist der Software-Kontrollkreislauf, der das Modell wiederholt aufruft, Kontext zusammenstellt, Tool Calls routet, Zustand dauerhaft speichert und entscheidet, wann ein Run fortgesetzt, beendet, wiederhergestellt oder an einen Menschen übergeben wird. Das Modell schlägt den nächsten Schritt vor, aber der Harness besitzt Execution Loop und Umgebung. Deadlines, Schrittlimits, Berechtigungen, Sandbox, Retries, Checkpoints, Tracing und die Prüfung des terminalen Ergebnisses gehören hierhin.

Der Begriff sollte nicht als modische Bezeichnung für einen einzelnen System Prompt oder SDK Wrapper dienen. Prompt Engineering optimiert Instruktionen; Context Engineering wählt Informationen für einen konkreten Model Call; ein Planner schlägt einen Pfad vor; ein Framework stellt Abstraktionen bereit; der Harness bindet diese Teile an einen realen Runtime Contract. Ein Produkt kann einen fertigen Harness liefern, ein anderes nur Primitives für einen eigenen. Die Marke des Modells bestimmt jedoch nicht die Zuverlässigkeit des Gesamtsystems.

• Model → schlägt innerhalb des sichtbaren Kontexts eine Antwort oder einen Tool Call vor.
• Harness → steuert Loop, State, Tools, Budgets, Isolation und Recovery.
• Application Policy → definiert Authority, Approvals und zulässige Outcomes.
• Environment → führt Befehle aus und speichert autoritative Artefakte.

Ein Production Baseline benötigt fünf getrennte Verträge. Die Session ist ein append-only Event Log mit Correlation ID. Der Loop baut Input zusammen, ruft das Modell auf, validiert die Response und wendet die Stop Policy an. Das Tool Gateway veröffentlicht eine enge Allowlist und prüft Argumente sowie Rechte erneut. Die Sandbox isoliert Filesystem, Prozesse und Network Destinations. Der State Store hält Task Status, Artifact References, Approvals und Postconditions unabhängig vom Chat Transcript.

Diese Trennung macht Komponenten austauschbar. Modell oder Prompt lassen sich aktualisieren, ohne den autoritativen Task State zu migrieren; die Sandbox kann verschärft werden, ohne den Planner neu zu schreiben; eine Tool-Implementierung lässt sich zurückrollen, während der Trace erhalten bleibt. Anthropic beschreibt Session, Harness und Sandbox als getrennte Bestandteile von Managed-Agent-Systemen, OpenAI einen model-native Harness zusammen mit Sandbox Execution. Das sind First-Party-Architekturbeschreibungen, kein Beleg für eine universelle Überlegenheit eines Anbieters.

• Session Log: Model Calls, Tool Requests, Ergebnisse, Approvals und terminaler Grund.
• Task State: planned, running, blocked, awaiting-approval, completed oder failed.
• Artifact Store: versionierte Outputs, Checksums, Provenance und Owner.
• Sandbox Policy: Mounts, Secrets, Network Egress, Resource Limits und Cleanup.
• Control Plane: Budgets, Kill Switch, Concurrency, Resume und Reconciliation.

Ein Long-running Agent durchläuft Context Windows, Restarts und Approval Waits. Compaction hilft, Historie in den Kontext zu bekommen, ersetzt aber keinen dauerhaften State. Ein Checkpoint sollte Task Version, erledigte Acceptance Criteria, geprüfte Artefakte, offene Risiken, ausstehende Approvals, die letzten autoritativen Postconditions und genau einen nächsten Schritt enthalten. Eine neue Session beginnt mit der Prüfung von Environment und State statt mit blindem Vertrauen in eine optimistische Zusammenfassung des vorherigen Modells.

Anthropic nutzte in seiner Forschung zu Long-running Harnesses eine Feature List, ein Progress Artifact, Version Control und eine grundlegende End-to-End-Prüfung vor der nächsten Änderung. Der übertragbare Grundsatz ist nicht der Dateiname, sondern das Handoff Protocol: Arbeit wird in abschließbare Slices geteilt, der Status per Test bestätigt und der nächste Worker erhält ein kurzes prüfbares Paket. Für Support oder Research kann dieses Paket aus Case State, Evidence Ledger und einer offenen Aktion bestehen statt aus einem Git Commit.

Ein Harness sollte dem Modell keinen universellen Tool-Katalog geben und darauf hoffen, dass ein Prompt Grenzen einhält. Für jeden Schritt prüft das Tool Gateway Actor, Tenant, Resource, Action, Parameters, Risk Tier, Approval Version und Expiry. Read-, Draft- und Write-Operationen verwenden unterschiedliche Credentials. Eine folgenreiche Aktion erhält Idempotency Key, Preflight Preview und erwartete Postcondition; ein Timeout nach dem Aufruf führt zu Reconciliation statt zu einem blinden Retry.

Eine Sandbox reduziert den Blast Radius, schafft aber allein keine Business Authorization. Ein Prozess kann isoliert sein und trotzdem einen gefährlichen Token oder erlaubten Egress zu einer Production API besitzen. Effective Authority ist daher die Schnittmenge aus Sandbox Policy, Credential Scope, Tool Contract, Application Rules und gültigem Approval. Prompt Injection, kompromittierte Dependency oder Modellfehler dürfen diese Schnittmenge nicht durch Textinstruktionen erweitern.

• Unbekannte Permission oder veraltetes Approval → fail closed.
• Unbekanntes Ergebnis eines Write Calls → vor Retry reconciliieren.
• Neues Destination oder Scope → separate Authorization Decision.
• Kill Switch → blockiert neue Aktionen, erhält aber Forensic Evidence und Recovery Path.

Golden Tasks sollten Outcome und Trajectory prüfen. Deterministische Grader bestätigen Schema, Filesystem Diff, API Postcondition, Budget und verbotene Events. Ein Model Grader kann die Qualität eines offenen Artefakts bewerten, ersetzt aber keine Prüfung von Permissions oder des tatsächlichen Side Effects. Human Review bleibt für mehrdeutige Nützlichkeit und materielles Risiko nötig. Eine kritische Policy-Verletzung darf nicht durch guten Schreibstil weggemittelt werden.

Die Failure Suite sollte Context Exhaustion, beschädigten Checkpoint, Duplicate Delivery, verlorene Tool Response, Partial Commit, revoked Credential, stale Branch, unavailable Dependency, Prompt Injection in retrieved Content und einen Agenten enthalten, der Completion vor bestandenem Acceptance Test meldet. Vergleichen Sie nicht nur Task Success, sondern Verified Progress pro Run, unnötige Tool Calls, Recovery Success, Reviewer Minutes, Wall-Clock Time und Cost per Accepted Outcome auf demselben Corpus. Vendor-Experimente sind nicht Ihr Baseline.

Beginnen Sie mit einer bounded Read-only-Aufgabe, für die bereits ein Baseline aus einem deterministischen Workflow existiert. Ergänzen Sie einen Model Loop, zwei oder drei klar getrennte Tools, explizite Terminal States, Task State außerhalb des Transcripts und einen vollständigen Trace. Fügen Sie danach Restart Fixture, Corrupted-State Fixture und einen Canary auf einem kleinen Segment hinzu. Multi-Agent Planner-Generator-Evaluator, lange autonome Loops oder Write Authority kommen erst dazu, wenn der einfachere Harness bei dokumentierten Task Slices messbar scheitert.

Ein Harness kodiert Annahmen über Schwächen des aktuellen Modells; deshalb braucht jeder Workaround Owner, Eval und Review Date. Nach einem Model- oder Tool-Upgrade folgt eine Ablation: Brauchen Sie noch einen separaten Planner, erzwungene Context Resets, zu viele Critique Loops oder einen großen Prompt? Rollback stellt ein kompatibles Paket aus Loop Policy, Tool Versions und Checkpoint Schema wieder her; aktive Writes werden zuerst reconciled. Der beste Harness ist nicht der größte, sondern der kleinste Kontrollkreis, der Ihre Aufgaben nachweislich innerhalb definierter Grenzen abschließt.

• Define → Outcome, Authority, Environment und Terminal States.
• Instrument → Session Events, State Transitions, Budgets und Artifacts.
• Evaluate → Success, Policy, Recovery, Efficiency und Human Acceptance.
• Canary → Read-only, bounded Concurrency, Kill Switch und On-call Owner.
• Simplify → regelmäßig Scaffolding entfernen, das keinen messbaren Gain mehr liefert.