Das Kernproblem: Modelle können denken, aber nicht handeln
Viele Teams testen Agenten zuerst wie einen Chatbot: Prompt hinein, Antwort hinaus. Für echte Arbeit reicht das nicht. Ein Agent muss Kontext sicher beziehen, Befehle ausführen, Zwischenergebnisse prüfen und bei Abweichungen zurückrollen können. Ohne Harness fehlt genau diese operative Schicht.
- Grenze 1: Kein verlässlicher Zustand. Das Modell erinnert sich an Text, aber nicht automatisch an Dateisystem, Git-Status, CI-Artefakte oder laufende Prozesse.
- Grenze 2: Keine kontrollierte Ausführung. Shell, Browser, Paketmanager und Tests brauchen Timeouts, Logs, Berechtigungen und Abbruchregeln.
- Grenze 3: Keine Audit-Spur. Ohne Protokoll bleibt unklar, warum ein Agent eine Datei geändert, einen Test übersprungen oder eine externe Ressource genutzt hat.
Anatomie eines Agent Harness
Ein belastbares Harness besteht aus klar getrennten Schichten. Die Modellschicht plant und formuliert. Die Tool-Schicht gibt Zugriff auf Dateien, Suche, Terminal, Browser und Tests. Die Policy-Schicht entscheidet, welche Aktion erlaubt ist. Die Beobachtungsschicht sammelt Ausgaben, Exit-Codes, Screenshots und Diffs. Die Persistenzschicht hält Aufgaben, Artefakte und Verlauf fest.
| Schicht | Aufgabe | Technischer Kontrollpunkt |
|---|---|---|
| Context Loader | Repo, Tickets, Logs und Spezifikationen selektiv laden | Pfadfilter, Größenlimit, Quellennachweis |
| Tool Router | Shell, Dateieditor, Browser, Test Runner aufrufen | Timeout, Ausgabeprotokoll, Exit-Code |
| Policy Guard | Riskante Aktionen blockieren oder bestätigen lassen | Allowlist, Secret-Filter, Git-Schutz |
| Verifier | Tests, Lint, Screenshots und Diffs bewerten | Reproduzierbare Kommandos, Artefakt-ID |
| State Store | Plan, Zwischenergebnisse und offene Risiken halten | Run-ID, Task-Status, Änderungsverlauf |
Entscheidungsmatrix: Chat, Agent Harness oder dedizierte Runtime?
Die Wahl hängt nicht von Modellgröße allein ab. Entscheidend ist, ob die Aufgabe Nebenwirkungen erzeugt. Sobald Code geändert, ein Simulator gestartet oder ein Deployment vorbereitet wird, braucht der Agent eine messbare Umgebung.
| Szenario | Einfacher Chat | Agent Harness | Mac mini M4 Runtime |
|---|---|---|---|
| Architekturfrage | Ausreichend | Hilfreich für Repo-Kontext | Nicht zwingend |
| Codeänderung mit Tests | Zu riskant | Notwendig | Stabil für lange Läufe |
| iOS Build oder UI-Prüfung | Nicht ausführbar | Koordiniert Schritte | Xcode, Simulator, VNC |
| Mehrstündige Refactorings | Kein Zustand | Plan und Verifikation | Dedizierte Ressourcen |
Sicherheits- und Stabilitätsdaten, die ein Harness liefern muss
Deutsche Engineering-Teams fragen zu Recht nach Nachvollziehbarkeit. Ein Agent Harness sollte jede Aktion als Ereignis behandeln: Eingabe, Tool-Aufruf, Ausgabe, Entscheidung, Diff und Verifikation. Dadurch wird aus KI-Unterstützung ein auditierbarer Arbeitsprozess.
Ebenso wichtig ist die Kapazitätsplanung der Runtime. Ein einzelner Agent, der nur Dokumentation prüft, benötigt kaum lokale Reserven. Ein Agent, der parallel Xcode, Simulator, Paketmanager, Browser-Automation und lokale Inferenz startet, braucht dagegen planbare CPU-Zeit, ausreichend Unified Memory und SSD-Spielraum für DerivedData, Cache-Verzeichnisse und Testartefakte. Genau hier trennt sich ein Demo-Harness von einer produktiven Umgebung.
| Messpunkt | Zielwert | Warum es zählt |
|---|---|---|
| Shell-Timeout | 30 bis 600 Sekunden je Task | Verhindert hängende Prozesse und doppelte Jobs |
| Diff-Grenze | Nur relevante Dateien im Review | Reduziert unbeabsichtigte Änderungen |
| Secret-Schutz | .env und Schlüssel nie automatisch committen | Erfüllt Grundanforderungen an Datenschutz |
| Runtime-Isolation | Dedizierter Benutzer, reproduzierbare Tools | Trennt Kundenprojekte und CI-Zustände |
Rollout in sechs Schritten
Ein praxistauglicher Start ist bewusst nüchtern. Erst wird der Arbeitsrahmen definiert, dann werden Tools freigegeben, danach wird gemessen.
- 1. Aufgabenklassen trennen: Recherche, Codeänderung, Testlauf, Release-Vorbereitung und Incident-Analyse erhalten unterschiedliche Rechte.
- 2. Repo-Kontext begrenzen: Nur relevante Pfade, aktuelle Diffs und bekannte Runbooks laden; große Artefakte bleiben außerhalb des Prompts.
- 3. Tool-Grenzen setzen: Shell-Kommandos mit Timeout, Dateiedits über Patch, Browserzugriff nur für dokumentierte Quellen.
- 4. Verifikation erzwingen: Lint, Unit-Test, Build oder Screenshot werden als Abschlusskriterium pro Task festgelegt.
- 5. Audit speichern: Run-ID, Befehle, Ausgaben und Diffs bleiben für Review und Compliance verfügbar.
- 6. Runtime dimensionieren: Für Xcode, Simulator, lokale Modelle oder CI-Agenten eine dedizierte Mac mini M4 Instanz mit genügend RAM und SSD wählen.
Zitierfähige Leitplanken
Bereit, Ihr Agent Harness auf einem Mac mini M4 produktiv zu betreiben?
Mieten Sie eine dedizierte clustervps Instanz für Shell, Xcode, Tests und VNC-Prüfung. Monatliche Abrechnung, globale Standorte und klare Ressourcen ohne Virtualisierungs-Overhead.