Inhalt: Risikoachsen · Architekturmatrix · Spezifikation · Rollout · Kennzahlen · Kaufentscheidung
Drei Risikoachsen ohne Harness
1. Unbegrenzte Wirkung: Ein Modell darf niemals direkt Shell, Netzwerk oder Repository steuern. Ohne Harness fehlt die klare Grenze zwischen Vorschlag, Freigabe und Ausführung. 2. Unscharfer Zustand: Chat-Verlauf, Arbeitsverzeichnis, Cache und Secrets vermischen sich; Wiederaufnahme nach Fehlern wird Zufall. 3. Nicht messbare Stabilität: Wenn Tool-Timeouts, Token-Budget, Retry-Anzahl und Exit-Codes nicht als Felder erfasst werden, bleibt jeder Agent-Lauf eine Anekdote statt ein reproduzierbarer Prozess.
Architekturmatrix: Modell versus Harness
Die folgende Matrix trennt Verantwortlichkeiten präzise. Deutsche Plattformteams bevorzugen diese harte Trennung, weil sie Audit, Datenschutz und Kostenkontrolle gleichzeitig bedient.
| Schicht | Aufgabe des Modells | Aufgabe des Harness | Abnahmekriterium |
|---|---|---|---|
| Planung | Ziel zerlegen, Hypothese formulieren | Scope, Rollen und Stop-Regeln setzen | Plan ohne Tool-Ausführung prüfbar |
| Tooling | Tool mit Argumenten vorschlagen | Schema, Timeout, Working Directory validieren | 100 % strukturierte Tool-Ergebnisse |
| Speicher | Relevante Fakten referenzieren | Session, Vektorindex, Artefakte versionieren | Resume nach Abbruch identisch |
| Ausführung | Zwischenergebnis interpretieren | Sandbox, Retry, Circuit Breaker steuern | p95-Laufzeit und Fehlerklasse sichtbar |
Technische Spezifikation für produktive Agenten
Ein belastbarer Harness ist kleiner als viele Frameworks versprechen, aber strenger in seinen Verträgen. Er braucht mindestens ein Tool-Manifest, einen Ausführungs-Adapter, einen Speicher-Adapter und ein Telemetrie-Schema.
| Komponente | Startwert 2026 | Sicherheitsnotiz |
|---|---|---|
| Tool-Timeout | 30-120 Sekunden je Toolklasse | Keine unendlichen Shell-Prozesse; Kill-Pfad testen |
| Parallelität | 2-4 Slots pro Agent-Lane | Schreibende Tools serialisieren |
| Speicher | Session-Log plus Artefakt-Hash | Secrets nie in Prompt oder Trace speichern |
| Observability | Trace-ID, Tool, Exit-Code, Token, Dauer | Prompts redigieren, Metadaten behalten |
Rollout in sechs Schritten
Schritt 1: Definieren Sie pro Agent einen engen Auftrag, etwa "Pull Request prüfen" statt "Repository verbessern". Schritt 2: Schreiben Sie ein Tool-Manifest mit JSON-Schema, erlaubten Pfaden und Timeouts. Schritt 3: Trennen Sie lesende und schreibende Werkzeuge, damit Reviews ohne Seiteneffekte laufen können. Schritt 4: Persistieren Sie Session-ID, Arbeitsverzeichnis, Modell-Fingerprint und Artefakt-Hashes. Schritt 5: Führen Sie Nachtläufe auf einem dedizierten Mac mini M4 aus und messen Sie p50/p95, Abbruchrate und Retry-Dichte. Schritt 6: Erst wenn drei identische Testläufe dieselben Dateien, dieselben Fehlerklassen und vergleichbare Laufzeiten erzeugen, schalten Sie Kunden-Repositories frei.
Betriebsmodell: Freigabe, Fehler-Envelope und Eigentümer
Der Harness braucht außerdem ein klares Betriebsmodell. In frühen Demos sitzt der Entwickler neben dem Agenten und korrigiert jeden Schritt. In der Produktion muss diese Rolle als Policy beschrieben sein: Wer darf einen Lauf starten, wer sieht Artefakte, wer kann ein schreibendes Tool freigeben, und wann wird ein Lauf automatisch beendet? Ohne diese Zuständigkeiten wandert Verantwortung in Prompt-Text, der weder revisionssicher noch ausreichend präzise ist.
| Kontrollpunkt | Empfohlene Umsetzung | Stabilitätswirkung |
|---|---|---|
| Human Gate | Freigabe vor Dateiänderung, Deployment oder Ticket-Kommentar | Verhindert stille Seiteneffekte |
| Fehler-Envelope | code, phase, retryable, summary und artifact_uri | Erlaubt automatische Wiederaufnahme |
| Owner Map | Agent-Lane, Repo, Budget und Eskalationskontakt koppeln | Verkürzt Analyse nach Nachtläufen |
Besonders wichtig ist der Fehler-Envelope. Ein Agent darf nicht nur melden, dass "etwas schiefging". Er muss die Phase, den letzten sicheren Zustand, Wiederholbarkeit und betroffene Artefakte zurückgeben. So kann ein Scheduler entscheiden, ob ein Timeout erneut versucht, ein Schreibkonflikt an Menschen übergeben oder ein Secret-Leak hart gestoppt wird. Diese disziplinierte Fehlerform unterscheidet einen belastbaren Harness von einem Chatbot mit Shell-Zugriff.
Zitierbare Stabilitäts- und Kostendaten
Für eine erste Abnahme reichen drei harte Zahlen: p95 Tool-Laufzeit unter 120 Sekunden, weniger als 3 % Tool-Retries pro Nachtlauf und 0 Klartext-Secrets in Trace-Samples. Ergänzend sollte die Wall-Clock-Laufzeit pro Aufgabe dokumentiert werden, weil Agenten-Kosten nicht nur aus Modell-Tokens, sondern auch aus belegter Mac-Zeit, SSD-I/O und blockierten Parallel-Slots entstehen.
Der praktische Schwellenwert lautet: Wenn ein Agent mehr als 20 Minuten dauerhafte Mac-Ressourcen bindet, sollte er auf einem eigenen Remote-Knoten laufen. Ein Mac mini M4 mit 24 GB Unified Memory genügt für viele Review-, Build- und leichte LLM-Harness-Läufe; für parallele Evaluierungen oder lokale Modelle ist eine höhere RAM-Stufe planbarer als spätere Fehlersuche unter Speicherdruck.
Kauf- oder Mietentscheidung für Agent Harnesses
Ein Agent Harness ist kein Demo-Notebook, sondern Betriebsinfrastruktur. Kaufen lohnt sich erst, wenn Auslastung, Speicherbedarf und Fehlerprofil über mehrere Wochen stabil sind. Für Prototyping, Kundentests und CI-Nachtläufe ist ein gemieteter LlmMac Mac mini M4 sauberer: Teams erhalten SSH/VNC-Zugriff, reproduzierbare Apple-Silicon-Hardware und können RAM-Stufen nach Sprint-Risiko wählen. Prüfen Sie Ihren Harness zuerst auf LlmMac, messen Sie reale Laufzeiten und buchen Sie danach den passenden Knoten statt Hardware auf Verdacht zu kaufen. So bleiben Experimente isoliert, Budgets monatlich steuerbar und spätere Kaufentscheidungen durch Messwerte statt durch Marketingversprechen begründet. Dokumentieren Sie zusätzlich jeden Abnahmelauf mit Datum, Modellversion, macOS-Version und Konfiguration, damit spätere Regressionen schnell auf Hardware, Prompt oder Tool-Vertrag zurückgeführt werden können.