Ein Agent Harness ist die Software um einen KI-Agenten, die ihn in einem realen System nutzbar macht. Das Modell kann entscheiden, was als Nächstes zu tun ist. Der Harness entscheidet jedoch, was es sehen darf, welche Aktionen es anfordern kann, wo diese Aktionen laufen, wie lange Arbeit erhalten bleibt und was bei einem Fehler geschieht.

Diese Unterscheidung lässt sich immer schwerer ignorieren. Am 3. September erhielten Cursor Cloud Agents die Möglichkeit, in Vercel Sandbox statt auf von Cursor gehosteten Maschinen zu laufen. In dem angekündigten Design übernehmen Vercel Functions und Workflow Warteschlangen, Bereitstellung, Monitoring und Cleanup, während Vercel Sandbox für jede Agent-Anfrage eine isolierte Firecracker-MicroVM bereitstellt. Vercels Ankündigung ist ein anschauliches Beispiel für einen allgemeineren Architekturpunkt: Ein produktiver Agent ist nicht bloß ein Model Call mit einigen Tools. Er ist ein Steuerungssystem plus eine oder mehrere Ausführungsumgebungen.

Das Modell ist nicht das System

Ein Modell ist die Komponente, die aus bereitgestellten Eingaben generierte Ausgaben macht: Text, einen vorgeschlagenen Plan, einen Tool Call oder Code. In einer Agent-Schleife erhält es Context, schlägt eine Aktion vor, beobachtet das Ergebnis und wiederholt den Vorgang. Es kann gut zwischen Möglichkeiten wählen, ist aber kein verlässlicher Ort für Sicherheitsgrenzen, Retry-Semantik, Secret-Handling oder Betriebsregeln.

Der Harness ist die vertrauenswürdige Schicht um diese Schleife. Er nimmt eine Aufgabe an, stellt den relevanten Context zusammen, ruft das Modell auf, prüft und leitet angeforderte Aktionen weiter, protokolliert Ergebnisse und entscheidet, ob ein weiterer Schritt zulässig ist. Außerdem verbindet er den Agenten mit Tools: abgegrenzten Schnittstellen für Aktionen wie das Lesen eines Repositorys, das Öffnen eines Tickets, das Ausführen von Tests oder das Abfragen eines Dienstes.

Vercel beschreibt einen Harness als Orchestrierungssoftware mit Tools und Verbindungen zu externen Diensten, die vom modellgetriebenen Agenten getrennt ist. Die Architekturhinweise empfehlen zudem, den Harness und seine Secrets in einem anderen Sicherheitskontext zu halten als die Ausführung generierten Codes. Das ist weniger eine Frage der Bezeichnung als eine hilfreiche Verantwortungsgrenze.

Einfach gesagt: Das Modell kann eine Aktion vorschlagen. Der Harness entscheidet, ob sie möglich, erlaubt, protokolliert und sicher ausführbar ist.

Der Begriff „Agent“ macht das unübersichtlich, weil er entweder das modellgetriebene Verhalten oder die gesamte zusammengesetzte Anwendung meinen kann. Wenn du den Agent Harness als eigene Architekturkomponente behandelst, wird die Aufteilung klarer. In einem Design Review kannst du dann fragen: Was ist Agent-Policy, was gehört in den Harness, und was läuft außerhalb beider Komponenten in einer isolierten Umgebung?

Warum diese Grenze jetzt wichtig ist

Frühe Agent-Prototypen lassen oft alles in einem Prozess laufen: Prompt, Model Call, Shell-Zugriff, Credentials, Arbeitsverzeichnis und Retry-Logik. Das ist schnell gebaut. Für einen Agenten, der nicht vertrauenswürdige Repository-Inhalte verarbeitet, generierten Code ausführt, Drittanbieter-Dienste aufruft oder lange genug arbeitet, um auf vorübergehende Fehler zu treffen, passt es schlecht.

Die Cursor-Vercel-Integration macht die Trennung sichtbar. Dauerhafte Aufgaben der Control Plane – Anfragen einreihen, Worker erzeugen, überwachen und aufräumen – müssen nicht auf derselben Maschine stattfinden, die vom Agenten generierten Code ausführt. Jede Anfrage kann eine isolierte MicroVM erhalten. Die Ankündigung nennt außerdem Scale-to-Zero-Worker, kurzlebige nutzerbezogene Credentials und dauerhafte Retries. Das sind Eigenschaften der umgebenden Architektur, keine Eigenschaften, die das Modell von selbst entwickelt.

Eine Control Plane ist der Teil eines Systems, der Arbeit steuert und beobachtet: Er plant, konfiguriert, autorisiert, überwacht und beendet Ausführung. Der Code, der tatsächlich Tests oder Skripte ausführt, gehört in dieser vereinfachten Sicht zur Data Plane. Ein Harness sitzt häufig an dieser Grenze. Er übersetzt den fortlaufenden Plan eines Agenten in kontrollierte Arbeitsaufträge und bringt Ergebnisse wieder als Context in den nächsten Model Call.

Das ist besonders bei Coding Agents wichtig. Ein generierter Testbefehl kann viel CPU verbrauchen, eine Datenbank verändern, eine Umgebungsvariable über Logs preisgeben oder unbegrenzt hängen. Der Agent kann in guter Absicht handeln und dennoch eine schlechte Wahl treffen. Eine begrenzte Schnittstelle und eine wegwerfbare Runtime verkleinern den Schadenradius. Das macht die Ausgabe nicht korrekt, aber es begrenzt die Orte, an denen eine fehlerhafte Ausgabe Schaden anrichten kann.

So arbeitet ein Agent Harness

Die konkrete Implementierung unterscheidet sich je nach Produkt und Team, und der Begriff „Harness“ ist nicht vollständig standardisiert. Die Abfolge ist dennoch recht stabil.

Zuerst erhält der Harness eine Aufgabe und legt eine Session an. Er wählt das Modell und baut Context aus Aufgabe, Repository-Zustand, relevanter bisheriger Arbeit und Policy-Nachrichten auf. Context Engineering ist die bewusste Arbeit, diese Informationen auszuwählen, zu strukturieren und zu begrenzen, damit das Modell das Notwendige erhält, ohne von irrelevanten oder unsicheren Inhalten überflutet zu werden.

Zweitens stellt der Harness eine kleine Menge von Tools bereit. Ein Tool sollte eine definierte Eingabe, erwartete Ausgabe, Autorisierungsregel, ein Timeout und einen Audit Trail haben. „Führe beliebige Shell-Befehle in Produktion aus“ ist kein gut begrenztes Tool. „Führe dieses Testziel in einem isolierten Workspace mit festem Zeitlimit aus“ kommt dem deutlich näher.

Drittens wendet der Harness Policy an, bevor das Modell eine angeforderte Aktion ausführt. Er kann die Anfrage ablehnen, eine Freigabe verlangen, Parameter einschränken oder kurzlebige Credentials ausstellen, die nur für diese Aktion gelten. Das Modell sollte keine langlebigen Infrastructure Secrets erhalten, nur weil es einen Dienst einmal verwenden muss.

Viertens schickt der Harness riskante oder fehleranfällige Arbeit in eine Sandbox. Eine Sandbox ist eine isolierte Ausführungsumgebung, die den Zugriff von Code begrenzen soll. Im Cursor-Vercel-Design übernimmt eine Firecracker-MicroVM pro Anfrage diese Rolle. Vercel beschreibt diese MicroVM-Isolation hier. Der Harness bleibt außerhalb der Sandbox, hält seine Secrets getrennt und übergibt nur die für die Aufgabe erforderlichen Dateien, Netzwerkzugriffe und Credentials.

Fünftens sammelt der Harness Ergebnisse, zeichnet Telemetry auf und beendet oder setzt die Schleife fort. Telemetry sind Betriebssignale wie Tool-Eingaben und -Ausgaben, Laufzeiten, Fehler, Ressourcenverbrauch, Freigabeentscheidungen und Metadaten zu Model Calls. Damit kann ein Engineering-Team nachvollziehen, warum ein Agent eine Datei geändert, eine Aufgabe wiederholt oder an einer Grenze versagt hat.

Schließlich braucht lang laufende Arbeit dauerhafte Orchestrierung. Ein Workflow ist eine verwaltete Folge von Schritten, die Fortschritt über Unterbrechungen und Retries hinweg festhalten kann. Eine Workflow Engine kann die dauerhaften Zustandsübergänge liefern; der Harness ergänzt Agent-spezifische Aufgaben wie Modellinteraktion, Zusammenstellung des Context, Tool-Policy und Freigaben. Vercels Leitfaden für Coding Agents nennt dauerhafte Orchestrierung, isolierte Ausführung und Infrastruktur für den Modellzugriff als getrennte Verantwortlichkeiten. Diese Zerlegung lohnt sich auch ohne Vercel.

Einfach gesagt: Halte Entscheidungen des Agenten, die Befugnis zum Handeln und riskante Ausführung getrennt. Dann wird ein Fehler an einer Stelle seltener zu einem Fehler überall.

Was ein Harness nicht ist

Ein Harness ist nicht das Modell. Ein Modellwechsel sollte idealerweise einen Adapter oder eine Konfiguration ändern, statt eine Umschreibung der Autorisierungs- und Ausführungsregeln zu erzwingen. Er ist auch keine Sandbox: Die Sandbox schränkt Ausführung ein; der Harness erstellt, konfiguriert, begrenzt, steuert und entsorgt sie.

Er ist auch nicht nur ein Workflow Orchestrator. Ein Workflow-System ist gut bei Schritten, Zustand, Warten und Retries. Es weiß aber nicht automatisch, wie es Model Context auswählt, einen Tool Call interpretiert oder einen harmlosen Dateizugriff von einem zerstörerischen Deployment unterscheidet. Umgekehrt kann ein Tool Gateway Dienste über einen kontrollierten Endpunkt verfügbar machen, liefert aber weder die Agent-Schleife noch den Lebenszyklus einer Session oder das umfassendere Betriebsmodell.

Vercels AI SDK 7 verwendet HarnessAgent für eine gemeinsame Schnittstelle um etablierte Harnesses wie Claude Code, Codex und Pi, mit konfigurierbaren Sandboxes, Tools und Skills. Diese Abstraktion ist nützlich, zeigt aber auch eine Portabilitätsfalle. Eine gemeinsame Schnittstelle kann vereinheitlichen, wie Software Agenten aufruft, ohne deren Berechtigungsmodelle, Tool-Semantik, Context-Verhalten oder Runtime-Garantien gleich zu machen.

Ein praktisches Beispiel: ein interner Agent zur Reparatur von Pull Requests

Stell dir als hypothetisches Beispiel einen Dienst vor, der einen fehlgeschlagenen CI-Job erhält und einen Agenten um einen Reparaturvorschlag bittet. Die unsichere Version gibt dem Agenten einen Repository-Checkout, ein weitreichendes CI-Token, Shell-Zugriff und die Berechtigung, einen Branch zu pushen. Das kann funktionieren, bis eine Prompt Injection in einem Issue, ein bösartiges Dependency-Skript oder ein falscher Befehl eine Grenze überschreitet.

Eine Harness-orientierte Version trennt die Zuständigkeiten.

Der Harness legt einen Task Record an und gibt dem Modell die fehlgeschlagene Testausgabe, ausgewählte Dateien und Repository-Konventionen. Er bietet eng begrenzte Tools an: erlaubte Pfade untersuchen, einen Patch erzeugen, ein benanntes Testziel ausführen und eine menschliche Prüfung anfordern. Das Modell kann einen Fix vorschlagen, aber weder unmittelbar eine Host-Maschine auswählen noch nicht zugehörige Secrets durchsuchen oder Code pushen.

Für die Testausführung erzeugt der Harness eine kurzlebige Sandbox mit einem schreibgeschützten Source Snapshot, einem beschreibbaren temporären Workspace, einer restriktiven Netzwerk-Policy, Ressourcenlimits und – falls nötig – einem Credential, das nur auf die erforderliche Package Registry zugreifen kann. Testergebnis und Patch gehen an den Harness zurück. Möchte der Agent es erneut versuchen, setzt der Workflow aus gespeichertem Zustand fort, statt die Aufgabe vollständig neu aufzubauen.

Vor jeder unumkehrbaren Aktion, etwa dem Öffnen eines Pull Requests oder einer Änderung einer Produktionskonfiguration, liegt eine menschliche Freigabe. Der Harness protokolliert den vorgeschlagenen Diff, Tool Calls, Testergebnisse und die Freigabe. Das beweist nicht, dass der Patch gut ist. Es hält fest, wer oder was welche Aktion mit welcher Berechtigung und in welcher Umgebung ausgeführt hat.

Darin liegt der eigentliche Nutzen: nicht autonome Codegenerierung, sondern ein nachvollziehbarer Weg vom Vorschlag zur begrenzten Aktion.

Wo das Design scheitert

Ein Harness ist Eindämmung, kein Sicherheitsbeweis. Das Modell kann eine Aufgabe weiterhin missverstehen, durch feindlichen Text beeinflusst werden, ein ungeeignetes Tool wählen oder subtil falschen Code erzeugen. Auch Tool-Ausgaben können nicht vertrauenswürdig sein; eine bösartige Webseite, Log-Zeile oder Repository-Datei kann spätere Modellentscheidungen zu beeinflussen versuchen. Jedes Tool-Ergebnis als vertrauenswürdigen Context zu behandeln, ist ein vermeidbarer Fehler.

Auch Sandboxing hat Grenzen. Isolation hängt von der tatsächlichen Konfiguration von Mounts, Netzwerk, Egress-Regeln, Interprozess-Kanälen und Credentials ab. Eine MicroVM mit einem mächtigen Produktionstoken oder uneingeschränktem Netzwerkzugang kann vom Host isoliert sein und trotzdem an anderer Stelle nicht akzeptable Aktionen ausführen.

Zuverlässigkeit schafft eine eigene Fehlerklasse. Ein fehlgeschlagener Dateilesevorgang lässt sich meist gefahrlos wiederholen; bei „Rechnung erstellen“ oder „Änderung deployen“ kann ein Retry eine Nebenwirkung wiederholen. Entwirf nach außen wirkende Tools für Idempotency, also so, dass eine Wiederholung derselben Anfrage den beabsichtigten Effekt einmal und nicht mehrfach hat, oder biete eine kompensierende Aktion an, wenn das nicht möglich ist. Dauerhafte Retries sind wertvoll, müssen aber mit dauerhafter Semantik verbunden werden.

Schließlich bringt die Trennung zusätzliche Komponenten mit: Session State, Queues, Trace-Korrelation, Timeouts, Cleanup und Debugging über Sicherheitskontexte hinweg. Ein Harness kann zu einer undurchsichtigen Plattform werden, wenn seine Policies und Traces nicht verständlich sind. Die richtige Antwort ist nicht, die Schichten wieder zusammenzulegen. Sie besteht darin, ihre Verträge explizit zu machen und zu testen.

Einfach gesagt: Ein Harness senkt Risiken und erleichtert die Untersuchung von Fehlern. Er macht aus einem fehleranfälligen Modell keinen perfekt sicheren Operator.

Was du diese Woche tun kannst

Zeichne zuerst den aktuellen Pfad deines Agenten. Markiere, wo Model Calls stattfinden, woher Context kommt, welche Tools existieren, wo Secrets liegen, wo generierter Code läuft und wer folgenreiche Aktionen freigeben kann. Wenn alle Markierungen in einem Prozess oder auf einer langlebigen Maschine landen, hast du eine Designannahme gefunden, die du prüfen solltest.

Definiere als Nächstes Tool Contracts, bevor du Prompts verbesserst. Gib jedem Tool einen engen Zweck, explizite Input Validation, ein Timeout, eine Authorization Policy und ein beobachtbares Ergebnis. Trenne schreibgeschützte Erkundung von zustandsverändernden Aktionen. Verlange Bestätigung oder Review für Aktionen, die veröffentlichen, Geld ausgeben, Produktion verändern oder Daten offenlegen.

Verschiebe dann die Ausführung generierten Codes in eine kurzlebige Umgebung mit minimalen Berechtigungen. Beginne mit einem riskanten Schritt – Tests, Installation von Dependencies oder Repository-Analyse –, statt das ganze System neu zu bauen. Prüfe die Details: gemountete Pfade, ausgehendes Netzwerk, Credential Scope, Cleanup und Ressourcenlimits.

Mache schließlich Fehler zu einem primären Testfall. Unterbrich eine Aufgabe auf halbem Weg. Erzeuge einen Tool Timeout. Wiederhole einen Retry. Gib dem Agenten irreführenden Text in einem Fixture. Stelle sicher, dass der Harness genug Telemetry aufzeichnet, um das Ergebnis zu erklären, und dass keine Nebenwirkung wiederholt wird. Das Vercel-Material behandelt Tool Loops, Tool Design, Context Management, Sandbox-Lebenszyklus, menschliche Kontrollmechanismen, Planung und Verifikation als getrennte Engineering-Themen. Das ist eine starke Checkliste für deine eigene Architektur.

Die entscheidende Frage ist nicht, ob dein Produkt „einen Agenten hat“. Sie lautet, ob das System um diesen Agenten seine Fähigkeit zu handeln sicher gewähren, begrenzen, beobachten und widerrufen kann.