Veröffentlicht am
·
20 Minuten
Harness Engineering: Von KI-Agent-Demos zur Produktion
Francisco García Sierra
Kurze Zusammenfassung
KI-Agenten sind zustandslos und systematisch überheblich. Deshalb sehen die meisten KI-Workflows im Unternehmen in Demos großartig aus und kommen in der Produktion still und leise ins Stocken. Die Lösung ist kein intelligenteres Modell, sondern Harness-Engineering: die Disziplin, die Umgebung, den Zustand, die Verifikation und die Wiederherstellungspfade zu gestalten, die das Modell umgeben. Dieser Beitrag erklärt in verständlicher Sprache, was ein Harness ist, geht acht praktische Leitplanken durch, die jedes Team anwenden kann, und zeigt die technischen Details hinter einem funktionierenden Zylon-Beispiel, bei dem KI-Agenten unsere Frontend-End-to-End-Abdeckung jeden einzelnen Tag verbessern. Deshalb betreiben wir auch unsere eigenen internen KI-Workloads auf lokalen Modellen, auf unserer eigenen Infrastruktur – sobald das Harness stimmt, wird das Modell zu einer austauschbaren Komponente statt zu einer Abhängigkeit vom Anbieter.
Vor dem Einstieg in den Code
Vor dem Code, den Büchern und den Validierungspipelines gibt es eine Idee, die Sie im Kopf behalten müssen — und sie gilt, egal ob Sie CIO, Betriebsleiter, Compliance-Beauftragter oder Produktmanager sind, der sich fragt, warum Ihre „KI-Initiative“ nach der ersten Demo ins Stocken geraten ist.
Ein KI-Agent ist kein Kollege, der lernt. Er ist ein Kollege ohne Gedächtnis.
Jede Unterhaltung mit einem KI-Agenten beginnt auf einem leeren Blatt. Er erinnert sich nicht daran, was er gestern gebaut hat. Er erinnert sich nicht an den Fehler, auf den er letzte Woche gestoßen ist. Er erinnert sich nicht an die Richtlinie, auf die Ihr CFO vor drei Monaten bestanden hat. Wenn dieses Wissen nicht irgendwo niedergeschrieben ist, damit der Agent es zu Beginn jeder Sitzung lesen kann, existiert es nicht.
Diese eine Tatsache ist der Grund, warum die meisten KI-Projekte in Woche eins wie Wunder und bis zum zweiten Quartal wie Enttäuschungen wirken. Die erste Sitzung funktioniert, weil ein Senior Engineer oder Analyst mit im Loop ist — beantwortet Fragen, korrigiert Fehler und hält den Kontext im Kopf. Die zehnte Sitzung funktioniert auf dieselbe Weise. Die hundertste Sitzung ist dieselbe Person, die dieselbe Korrektur macht, dieselben Einarbeitungskosten bezahlt und dieselbe unvollständige Antwort erhält. Der Agent wird nie besser in Ihrem Geschäft, weil zwischen den Sitzungen nichts von Ihrem Geschäft bestehen bleibt.
Die Disziplin, die das behebt, hat einen Namen: Harness Engineering. Das Modell ist nicht das Harness. Das Harness ist alles um das Modell herum — die Anweisungen, die es beim Start liest, die Umgebung, in der es arbeitet, der Zustand, den es für den nächsten Lauf hinterlässt, die Verifikation, die es bestehen muss, bevor es behaupten kann, etwas sei erledigt, und die Grenzen, die es davon abhalten, mehr zu tun, als es sollte.
Eine nützliche Analogie aus der Literatur zum Harness Engineering: Ein großartiger Koch ohne Küche wird Ihnen kein großartiges Essen zubereiten. Er braucht Rezepte (Anweisungen), Messer und Pfannen (Werkzeuge), einen Herd, der tatsächlich funktioniert (eine zuverlässige Umgebung), eine Vorbereitungsstation, die das Mise en Place von gestern hält (State), und ein Fenster, an dem jemand das Essen probiert, bevor es rausgeht (Verifikation). Nimmt man eines davon weg, serviert selbst ein Michelin-Koch am Ende ein Sandwich. Die meisten Enterprise-KI-Implementierungen sind genau das: erstklassige Zutaten, keine Küche.
Der Rest dieses Beitrags ist das, was eine Küche ausmacht.
Wir werden es zweimal durchgehen — zuerst als Prinzipien, mit denen Sie jeden KI-Workflow in Ihrer Organisation bewerten können, dann als konkretes Engineering-Beispiel, bei dem diese Disziplin uns bei Zylon bereits Nutzen bringt. Wenn Sie nicht technisch sind, reichen die Prinzipien aus. Wenn Sie Ingenieur sind, zeigt das Beispiel, wie die Prinzipien im Code aussehen.
Warum Fähige Agenten Trotzdem Versagen
Es gibt ein Phänomen, das jedes Team erlebt, das versucht hat, einen Agenten in Produktion zu bringen, und es hat einen klaren technischen Namen. Forschende nennen es die Verifikationslücke: den systematischen Abstand zwischen der Überzeugung eines Agenten, eine Aufgabe sei erledigt, und der Frage, ob die Aufgabe tatsächlich korrekt ist. Eine Kalibrierungsarbeit von Guo et al. aus dem Jahr 2017 zeigte, dass moderne neuronale Netze systematisch überkonfident sind — sie melden eine höhere Sicherheit, als ihre tatsächliche Genauigkeit rechtfertigt. Neun Jahre später gilt das Gleiche für die Agenten, die auf ihnen aufbauen. Agenten lügen nicht, wenn sie „erledigt“ sagen. Sie irren sich auf strukturierte, vorhersehbare Weise.
Das ist operativ wichtig, weil die meisten Teams ihre KI-Workflows rund um die Sicherheit des Agenten entwerfen. Der Agent sagt, er sei fertig; wir shippen es. Der Agent sagt, er habe seine Arbeit getestet; wir vertrauen ihm. Der Agent sagt, er habe die Richtlinie befolgt; wir machen weiter. Jede dieser Bewertungen ist eine Selbstbenotung, und Selbstbenotungen sind systematisch großzügig.
Anthropics Forschung zu langlebigen Agenten geht noch weiter. Wenn derselbe Agent sowohl Arbeit erzeugt als auch bewertet, ist die Bewertung verzerrt — selbst bei Aufgaben, bei denen Korrektheit objektiv messbar ist. Die Lösung ist strukturell, nicht kognitiv: Man trennt den Ausführenden vom Prüfer. Dasselbe Modell kann beide Rollen übernehmen, aber das Harness muss sie in verschiedene Sitzungen, verschiedene Kontexte und verschiedene Prompts setzen. Ein Student sollte nicht seine eigene Prüfung bewerten.
Das ist die tragende Einsicht, die Harness Engineering von „Prompt Engineering“ unterscheidet. Prompt Engineering versucht, das Modell dazu zu bringen, bessere Dinge zu sagen. Harness Engineering akzeptiert, dass die Selbstberichte des Modells unzuverlässig sind, und baut die Umgebung so, dass sie extern verifiziert werden.
Was Ein Harness Tatsächlich Ist
Ein praktisches Harness hat fünf Subsysteme. Man kann sie als die fünf Funktionsbereiche einer Küche betrachten.
Anweisungen. Eine kurze, langlebige Datei, die dem Agenten sagt, worum es bei diesem Projekt geht, auf welchem Stack es läuft, welche Konventionen nicht verhandelbar sind und wo er für mehr Details nachsehen soll. In einem Code-Repository ist das AGENTS.md oder CLAUDE.md. In einem Finance-Ops-Workflow kann es ein einseitiges Betriebsdokument sein. Die Disziplin ist dieselbe: Jede Sitzung beginnt damit, dies zu laden. Rund 100 Zeilen sind die OpenAI-Richtlinie; wenn es nicht passt, verlinken Sie weiter.
Werkzeuge. Die Menge der Dinge, die der Agent tatsächlich tun darf. Nicht zu viele — Least Privilege gilt weiterhin. Nicht zu wenige — ein Agent, der pip install nicht ausführen oder eine isolierte Datenbank nicht abfragen kann, kann keine echte Arbeit leisten. Die meisten Teams machen an einem der beiden Extreme einen Fehler. Die Lösung ist, aufzuschreiben, welche Werkzeuge für diese Art von Aufgabe benötigt werden, und genau das zu gewähren.
Umgebung. Eine sich selbst beschreibende, reproduzierbare Laufzeitumgebung. Fixierte Abhängigkeiten, festgelegte Versionen, ein bekannter Startzustand. Für Nicht-Ingenieure ist das das operative Äquivalent: bekannte Datenquellen, bekannte Zugriffsbereiche, bekannte Service-Verfügbarkeit. Der Agent sollte in der Lage sein, nachzuweisen, dass er alles hat, was er braucht, bevor er mit der Ausgabe beginnt.
State. Ein dauerhafter Nachweis darüber, was erledigt wurde, was in Arbeit ist, was blockiert ist und was als Nächstes kommt. Das ist die Datei (oder die Menge von Dateien), die einen zustandslosen Agenten in ein System verwandelt, das sich kumulativ verbessert. Ohne State ist jede Sitzung die erste Sitzung.
Feedback. Die Verifikationsschleife. Explizite Befehle, die dem Agenten — und dem Team — sagen, ob die Arbeit tatsächlich korrekt ist. Im Code sind das Tests, Lints, Typprüfungen, End-to-End-Läufe. In Wissensarbeit sind das Bewertungsraster, menschliche Stichproben, Gold-Datensätze, Regression-Suiten. Die mit Abstand höchstrangige Investition in jedes Harness ist, Feedback spezifisch, ausführbar und extern zum Agenten zu machen.
Eine Praxisgeschichte aus der Literatur zum Harness Engineering: Ein Team, das GPT-4o auf einer 20.000-Zeilen-TypeScript-App einsetzte, steigerte die Erfolgsrate bei Agent-Aufgaben von 20 % auf nahezu 100 % — ohne das Modell zu ändern. Sie fügten die Instruktionsdatei hinzu. Dann fügten sie die Verifikationsbefehle hinzu. Dann fügten sie eine Fortschrittsdatei hinzu. Vier Iterationen am Harness, kein Modell-Upgrade, fünffache Erfolgsrate. Die Küche wurde organisiert.
Die Acht Schienen
Diese acht Schienen zeigen, wie die fünf Subsysteme im Tagesgeschäft sichtbar werden. Lesen Sie sie zuerst als universelle Prinzipien; die technischen Beispiele stammen aus einem Zylon-Projekt, in dem KI-Agenten täglich unsere Frontend-End-to-End-Testabdeckung erhöhen, aber die Schienen gelten genauso gut für einen Vertragsprüfungs-Workflow, eine Regulierungs-Filing-Pipeline oder eine Kundensupport-Automatisierung. Überall dort, wo ein Agent wiederholt echte Arbeit an einem beweglichen Ziel erledigen soll, gelten diese Schienen.
Schiene 1 — Der Start Ist Eine Echte Phase, Keine Formalität
Das Prinzip: Das Erste, was ein Agent in jeder Sitzung tut, ist nicht die Arbeit. Es ist das Laden des Kontexts, der die Arbeit produktiv macht. Die meisten gescheiterten KI-Workflows überspringen das — der Agent wird in eine Aufgabe geworfen und verbrennt die Hälfte seines nützlichen Kontextbudgets damit, neu zu entdecken, was er gestern schon wusste.
Operativ bedeutet das, dass jede Sitzung mit einer strukturierten Initialisierung beginnt: die Instruktionsdatei lesen, das Startskript ausführen, die State-Dateien laden. Das Ergebnis des Starts ist nicht mehr Ausgabe — es ist eine nachgewiesene Ausgangslage. Für einen Wissensarbeits-Agenten könnte das heißen: „Ich arbeite am Q3-Abschluss. Der letzte gebuchte Journaleintrag war 4.127. In der Abstimmungswarteschlange sind 19 offene Punkte. Drei Punkte sind wegen Gegenparteibestätigung blockiert.“ Dieser Satz macht den Unterschied zwischen produktiver Arbeit und Erkundungsarbeit aus.
In unserem Testautomatisierungsbeispiel lädt der Start:
AGENTS.md— der Einstiegspunkt, jede Sitzung zuerst gelesen.progress.md— was in der aktuellen Arbeitslinie erledigt wurde.session-handoff.md— konkreter Neustartpfad für die nächste Sitzung.test_migration_list.md— das Migrations-Register.feature_list.json— abgeschlossene Arbeit mit Nachweisen.docs/e2e-test.md— aus früheren Fehlern abgeleitete Regeln.
Sobald diese geladen sind, bringt progress.md den Agenten direkt dorthin, wo die Arbeit aufgehört hat:
Das ist ein fundamental anderer Startpunkt als „das Repo lesen und herausfinden, wie es funktioniert“. Die erste Aktion des Agenten ist produktiv, nicht erkundend.
Schiene 2 — Die Umgebung Muss Nachgewiesen Werden, Nicht Angenommen
Das Prinzip: Agenten bauen fröhlich Schlösser auf Sand. Sie schreiben Logik, die auf ein System verweist, das offline ist, fragen eine Datenbank ab, die nicht bereitgestellt wurde, oder erzeugen einen Bericht aus Daten, die nicht aktualisiert wurden. Die Arbeit wirkt korrekt, weil das Modell keine Möglichkeit hat zu wissen, dass das Fundament kaputt ist.
Die Lösung besteht darin, die Verifikation der Umgebung vor jeder Produktionsarbeit als verpflichtende Phase zu machen. Zwei Fragen müssen mit Belegen beantwortet werden, bevor der Agent weitermacht: Kann das System starten, und ist es dort erreichbar, wo wir es erwarten? In einem regulierten Workflow könnten die Fragen lauten: Habe ich Zugriff auf die richtigen Datenquellen, und sind sie aktuell? In beiden Fällen werden die Antworten als Fakten in den State-Dateien festgehalten, statt in jeder Sitzung erneut abgefragt zu werden.
Im Code ist das konkret:
Zwei Prüfungen. Zwei dokumentierte Fakten. Keine Implementierung beginnt, bis diese Fakten grün sind. Wenn eine Prüfung fehlschlägt — ein fehlendes Paket, ein nicht reagierender Port — meldet der Agent das sofort, anstatt darum herumzuarbeiten und das Problem drei Ebenen später zu entdecken.
An dieser Schiene sterben die meisten Enterprise-KI-Piloten still. Die Demo wurde gegen eine saubere Umgebung gebaut, mit jemandem im Loop, der Dinge repariert. Der Pilot läuft gegen eine chaotische Umgebung ohne jemanden im Loop. Ohne nachgewiesene Umgebung als explizite Phase kann der Agent den Unterschied nicht erkennen, und das Team auch nicht.
Schiene 3 — Eine Quelle Der Wahrheit, Ein Migrationsregister Und Verfolgter State
Das Prinzip: Der Agent erfindet die Arbeit nicht. Er zieht die Arbeit aus einer autoritativen Quelle, prüft anhand eines verfolgten Registers, was bereits erledigt wurde, und erzeugt dabei Nachweise.
Für ein Softwareteam kann die Quelle der Wahrheit ein Testmanagementsystem, ein Backlog, ein Issue-Tracker oder eine Feature-Spezifikation sein. Für ein Backoffice-Team kann es eine Liste von Vorschriften sein, die eingehalten werden müssen, eine Warteschlange von Tickets, ein Portfolio von Verträgen. Das Werkzeug ist nebensächlich. Entscheidend ist, dass der Agent sich nicht frei ausdenken kann, was die Arbeit ist, denn genau dort verursacht ein verzerrtes Sicherheitsgefühl den größten Schaden.
Ein Migrationsregister erfasst dann für jeden Eintrag der Quelle der Wahrheit den aktuellen Status: queued, in-progress, blocked, automated, deferred. Das ist die zweitwichtigste Datei in jedem Agent-Workflow, gleich nach der Instruktionsdatei. Ohne sie wird der Agent Arbeit wiederholen, Arbeit überspringen oder Ausgabe erzeugen, die vom eigentlichen Ziel abdriftet.
Für unser E2E-Projekt ist Qase die Quelle der Wahrheit für manuelle Testabsichten und test_migration_list.md ist das Register:
Dieselbe Form funktioniert für einen Vertragsprüfungs-Workflow, eine KYC-Pipeline oder ein Compliance-Nachweisprotokoll. Das Artefakt ist generisch; die Disziplin trägt die Last.
Schiene 4 — Fehler Werden Zu Regeln, Nicht Nur Zu Fixes
Das Prinzip: Eine einmalige Korrektur ist für einen zustandslosen Agenten unsichtbar. Derselbe Fehler wird in der nächsten Sitzung, und der nächsten, und der nächsten wieder auftreten. Der einzige Weg, einen Fix dauerhaft zu machen, besteht darin, ihn in eine schriftliche Regel umzuwandeln, die der Agent beim Start lädt.
Das ist eine der wirksamsten Schienen im Harness Engineering und eine der am wenigsten genutzten. Jedes Team, das mit Agenten arbeitet, erlebt irgendwann den Moment, in dem es dasselbe Problem zweimal behebt. Das zweimal-fixen ist ein Signal: Es fehlt eine Regel. Schreiben Sie sie auf, legen Sie sie in der Rules-Datei ab und machen Sie weiter.
Wir sind darauf bei fragilen UI-Locators gestoßen — Selektoren, die stillschweigend brachen, wenn die Oberfläche einen String anders übersetzte. Der Patch war einfach. Die Regel machte ihn dauerhaft:
Und die Regel kam in docs/e2e-test.md:
In einem regulierten Workflow könnte das Äquivalent sein: Der Agent versuchte, PII an einen externen Dienst zu senden, wir haben es blockiert, und wir haben eine Regel darüber geschrieben, welche Datenklassifikationen das Netzwerk verlassen dürfen. Sobald die Regel im Harness ist, ist die Lektion dauerhaft. So wird aus einem reaktiven Review-Kommentar eine proaktive Richtlinie.
Schiene 5 — Umfang Hält Den Agenten Ehrlich
Das Prinzip: Je größer die Aufgabe, desto stärker verliert der Agent an Treue. Der Kontext füllt sich, frühere Entscheidungen werden zusammengefasst, das Verhalten des Agenten driftet zu dem, was zuletzt und am prominentesten ist. Das ist kein Modellfehler; es ist eine Eigenschaft davon, wie lange Kontextfenster in der Praxis funktionieren. Das Gegenmittel ist ein kleiner, begrenzter Umfang.
Operativ: Bitten Sie den Agenten nicht, „alle Tests zu automatisieren“ oder „alle Verträge zu prüfen“. Bitten Sie ihn, fünf Tests oder drei Verträge oder ein Viertel eines Workflows zu erledigen. Jede Einheit vollständig, validiert, dokumentiert. Der nächste Batch ist eine neue Sitzung mit den vorherigen Belegen bereits auf der Platte.
Unser Beispiel versucht nicht, 500 Fälle abzudecken. Es zielt auf einen Batch:
Jeder Fall ist ein einzelner, eingegrenzter, individuell validierter Test:
Kleiner Umfang macht den Agenten genauer. Aufgezeichneter State ermöglicht der nächsten Sitzung weiterzumachen. Die Kombination ist das, was Wachstum der Abdeckung inkrementell statt durch Ambition gestoppt ermöglicht.
Schiene 6 — Blocker Sind Erstklassige Ergebnisse
Das Prinzip: Nicht jede Aufgabe sollte bestehen, und ein deterministisches System muss das ausdrücken können. Wenn die einzigen Optionen „erledigt“ und „fehlgeschlagen“ sind, werden Agenten so lange ändern, bis etwas erledigt aussieht — selbst wenn die richtige Antwort lautet: „Das kann nicht erledigt werden, weil das zugrunde liegende System falsch ist.“
Hier wird die Verifikationslücke am teuersten. Ein Agent, der „blockiert“ nicht mit Belegen sagen kann, wird stattdessen „erledigt“ ohne Belege sagen. Falsches Grün ist teurer als ehrliches Rot. Falsches Grün geht weiter; ehrliches Rot legt das zugrunde liegende Problem offen und leitet es weiter.
Ein sauberer Lebenszyklus ist das Gegenmittel:
In unserem Lauf stellte BO-25 — prüfen, dass doppelte E-Mail abgelehnt wird — ein Backend fest, das Duplikate tatsächlich nicht ablehnte. Der Test konnte nicht bestehen, weil das Produkt falsch war. Die richtige Antwort des Agenten war, das zu markieren:
Und das Register hält es fest:
Blockiert mit Belegen ist Produktinformation. Ein Backlog gut dokumentierter Blocker ist ein Qualitätssignal, kein Loch. Das Gleiche gilt für jeden agentischen Workflow — eine Ausgabe nach dem Motto „Ich kann das nicht, und hier ist warum“ ist weit wertvoller als ein erfundener Erfolg.
Schiene 7 — Validierung Muss Festgelegt, Nicht Improvisiert Sein
Das Prinzip: Wenn der Agent selbst auswählt, wie er seine Arbeit validiert, wird er die Validierung wählen, die die Arbeit erledigt aussehen lässt. Das Harness muss festlegen, welche Prüfungen in welcher Reihenfolge laufen und was als bestanden gilt. Der Agent führt aus; er entscheidet nicht.
Das ist die Formalisierung der Trennung von Ausführendem und Prüfer auf Workflow-Ebene. Die Arbeit gehört dem Agenten. Das Bewertungsraster gehört dem Harness. Es sind nicht dasselbe Artefakt, und sie werden nicht zur gleichen Zeit geschrieben.
Konkret ist die Validierung in unserem Beispiel vorgeschrieben und nicht verhandelbar:
Die Befehle sind vorgeschrieben. Die Ausgaben werden dokumentiert. Die nächste Sitzung übernimmt beides. In einem Wissensarbeits-Setting wird das zu einem Raster und einem Evaluator — manchmal ist der Evaluator ein separater Agentenlauf mit einem anderen Prompt und der Anweisung „sei streng“, manchmal ist es ein menschlicher Reviewer, manchmal ein deterministischer Check gegen bekannte gute Daten. Die Form ist egal. Wichtig ist, dass die Validierung extern zu dem Agenten ist, der die Arbeit gemacht hat.
Schiene 8 — Ein Sauberer Abschluss Ist Das, Was Automatisierung Kumulativ Macht
Das Prinzip: Jede Sitzung muss den Arbeitsbereich in einem Zustand hinterlassen, in dem die nächste Sitzung sofort, mit vollem Kontext und ohne Nachfragen fortsetzen kann. Das ist keine Hausarbeit. Das ist der gesamte Mechanismus, durch den tägliche Automatisierung sich ansammelt statt zu verfallen.
Entropie ist der Standard. Ohne aktive Disziplin beim Aufräumen fügt jede Sitzung veraltete Artefakte hinzu, bricht implizite Annahmen und hinterlässt unausgesprochenen Kontext, den die nächste Sitzung neu erschließen muss. Nach ein paar Iterationen übersteigt die Entdeckungskosten die produktiven Kosten, und der Workflow wirkt, als würde er mit der Zeit langsamer, obwohl sich am Modell nichts geändert hat.
Ein sauberer Exit ist Teil der Definition von „erledigt“ — nicht davon getrennt. Eine Sitzung ist nicht abgeschlossen, wenn die Arbeit abgeschlossen ist. Sie ist abgeschlossen, wenn die Arbeit abgeschlossen ist und die Übergabedateien aktuell sind.
Für uns bedeutet das:
Und der explizite Neustartpfad für den nächsten Agenten:
Die nächste Sitzung startet nicht aus einem leeren Chat. Sie startet aus repo-eigenem State, bekannter Validierung, bekannten Blockern und bekannten Dateigrenzen.
Der Gesamtablauf
Warum Das Für Private KI Wichtig Ist
In den meisten Enterprise-KI-Gesprächen steckt eine stille Annahme, die ungefähr so lautet: Ernsthafte Arbeit braucht das neueste Frontier-Modell, ausgeliefert aus der Cloud von jemand anderem, hinter der API von jemand anderem. Alles andere sei ein Spielzeug.
Unsere Erfahrung sagt das Gegenteil. Der schwierigste Teil davon, KI in Produktion sinnvoll arbeiten zu lassen, ist nicht das Modell. Es ist alles um das Modell herum. Und sobald man das akzeptiert, verändert sich die gesamte Kosten- und Souveränitätsrechnung.
Wir bauen Zylon auf Zylon. Die Plattform, auf der unsere Kunden ihre Daten auf ihren eigenen Servern betreiben — um ihre Daten innerhalb ihrer Wände zu halten, Regulatoren zu genügen und von keinem einzelnen Modellanbieter abhängig zu sein — ist dieselbe Plattform, die wir intern nutzen, um das Produkt selbst zu bauen. Die Agenten, die täglich unsere Testabdeckung erweitern, unsere internen Tools entwerfen und uns beim Ausliefern von Features helfen, laufen gegen lokale Modelle auf unserer eigenen Infrastruktur. Nicht das neueste Modell auf dem Markt. Nicht der teuerste Endpoint. Lokale Modelle, auf Hardware, die wir kontrollieren.
Das funktioniert, weil das Harness den Großteil der Schwerarbeit übernimmt. Ein gut instruierten Agent mit einem kleinen, schnellen, lokal gehosteten Modell, der den richtigen State lädt, seine Umgebung nachweist, in abgegrenzten Aufgaben arbeitet und seine Arbeit gegen externe Befehle validiert, wird ein Frontier-Modell schlagen, das mit einem vagen Prompt in ein nacktes Repository gesetzt wurde. Jedes Mal. Das Modell ist eine Komponente. Das Harness ist das System.
Das hat zwei Konsequenzen, über die es sich lohnt nachzudenken.
Die erste ist wirtschaftlich. Frontier-Modell-APIs werden so bepreist, als sei die Modellfähigkeit die knappe Ressource. Für viele Enterprise-Aufgaben ist sie das nicht — Kontext, State und Verifikation sind es. Ein Team, das in sein Harness investiert, kann den Großteil seiner agentischen Arbeit auf kleineren, günstigeren, lokalen Modellen laufen lassen und die Frontier-Endpunkte für die engen Fälle reservieren, die sie wirklich brauchen. Die Kostenkurve von KI in Produktion sieht ganz anders aus, wenn das Harness die Arbeit übernimmt, die in weniger ausgereiften Setups die Prompts übernehmen.
Die zweite ist strategisch. Ein Workflow, der vom neuesten Modell eines einzelnen Anbieters abhängt, erbt dessen Roadmap, dessen Preisgestaltung, dessen Abschaltplan und dessen Geopolitik. Ein Workflow, der gegen lokale Modelle auf Infrastruktur läuft, die Sie kontrollieren, erbt nichts davon. Das Harness ist portabel. Der State gehört Ihnen. Die Anweisungen gehören Ihnen. Wenn im nächsten Quartal ein besseres lokales Modell erscheint, tauschen Sie es aus. Wenn ein Anbieter seine Bedingungen ändert, merken Sie es nicht. So sieht echte Modellunabhängigkeit aus, und deshalb ist dieselbe Disziplin, die unsere interne Automatisierung kumulativ wachsen lässt, die Disziplin, die eine Private-KI-Plattform für eine regulierte Bank, ein Krankenhaus oder eine Behörde überhaupt erst praktikabel macht.
Wir haben uns nicht vorgenommen, diesen Punkt zu beweisen. Wir haben nur immer wieder festgestellt, dass das Harness wichtiger ist als das Modell — und dass lokale Modelle, gut eingebettet in ein Harness, für fast alles ausreichen, was wir intern tun müssen. Die täglich wachsende Testabdeckung ist ein Beleg dafür. Das Produkt selbst, auf derselben Infrastruktur gebaut, die wir verkaufen, ist der größere Beleg.
Wenn Ihre KI-Strategie derzeit eine Wette darauf ist, welches Frontier-Modell Sie verwenden sollten, lohnt es sich vielleicht, eine andere Frage zu stellen: Wie würde Ihre Arbeit aussehen, wenn das Harness das wäre, was Sie richtig machen, und das Modell der Teil wäre, den Sie austauschen könnten?
Quellen
OpenAI, Harness Engineering: Codex in einer agenten-zentrierten Welt nutzen — https://openai.com/index/harness-engineering/
Anthropic, Wirksame Harnesses für langlebige Agenten — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Anthropic, Harness-Design für langlebige Anwendungsentwicklung — https://www.anthropic.com/engineering/harness-design-long-running-apps
Walking Labs, Harness Engineering lernen (Vorlesungsreihe) — https://walkinglabs.github.io/learn-harness-engineering/en/
Guo et al., Zur Kalibrierung moderner neuronaler Netze, ICML 2017 — https://arxiv.org/abs/1706.04599
Awesome Harness Engineering — https://github.com/walkinglabs/awesome-harness-engineering
Autor: Francisco Garcia Sierra, Full-Stack-Entwickler bei Zylon
Veröffentlicht: Mai 2026
Francisco ist Full-Stack-Entwickler bei Zylon und arbeitet über Produkt, Infrastruktur und KI-gestützte Entwickler-Workflows hinweg. Er hat Enterprise-Produkte End-to-End gebaut, von Backend-Systemen und APIs bis hin zu Frontend-Erlebnissen und Produktionsintegrationen, mit starkem Fokus auf den Aufbau zuverlässiger Systeme, die in realen Umgebungen skalieren. Sein Hintergrund umfasst außerdem Blockchain und Kryptografie, was prägt, wie er an Sicherheit, Systemdesign und Vertrauen in Software herangeht. Bei Zylon arbeitet er daran, fortgeschrittene KI-Fähigkeiten in praktische Werkzeuge zu verwandeln, die die Entwicklererfahrung verbessern, operative Reibung verringern und Teams helfen, schneller und mit mehr Kontrolle auszuliefern.
Veröffentlicht am
Geschrieben von
Francisco García Sierra
