Harness: Wenn das Modell kein Engpass mehr ist, hat das Problem von KI erst begonnen.

In letzter Zeit hat ein Wort, das ursprünglich hauptsächlich im Ingenieurkontext vorkam, in der chinesischen Technologiebranche immer häufiger Erwähnung gefunden: Harness.

Ähnlich wie viele technische Konzepte verbreitet sich dieses Wort oft schneller, als es verstanden wird.

In verschiedenen Kontexten haben Menschen unterschiedliche Vorstellungen von ihm: Manche sehen es als eine ingenieurtechnische Umsetzung eines Agents, andere verstehen es als eine Art AI-Runtime, und wieder andere sind der Meinung, es sei lediglich eine Erweiterung der Prompt-Engineering.

Eine noch unklar geklärte Frage: AI kann es, aber nicht zuverlässig

In den letzten zwei Jahren wurde der Fortschritt in der Künstlichen Intelligenz fast ausschließlich von den Fähigkeiten der Modelle getrieben.

Stärkere logische Fähigkeiten, längere Kontextverarbeitung und komplexere Fähigkeiten zur mehrstufigen Ausführung haben es den Agents ermöglicht, sich in Bezug auf ihre Fähigkeiten schnell dem Punkt der "Anwendbarkeit" zu nähern. Doch in einigen Praxisen, die in echte Systeme integriert wurden, taucht immer wieder ein Problem auf: Diese Aufgaben können einmal erfolgreich durchgeführt werden, aber es ist schwierig, sie zuverlässig zu wiederholen; die Ergebnisse können nahe an der richtigen Lösung liegen, aber bei Randbedingungen weichen sie ab; auch wenn die Fähigkeiten der KI zunehmen, bleibt die Ausführung unvorhersehbar...

In diesen Fällen liegt das Problem oft nicht im Modell selbst, sondern darin, dass das System nicht ausreichend eingeschränkt ist. So beginnt ein neues Konsens zu entstehen: Das Modell bestimmt die obere Grenze der Fähigkeiten, während das System nun entscheidet, ob die Ergebnisse reproduzierbar sind.

Genau in diesem Kontext wird ein Wort, das ursprünglich im Ingenieurkontext vorkam, immer wieder erwähnt:

Harness.

Bevor die Diskussion begann, hatten einige bereits Erfolg

Vor der Benennung von "Harness" gab es keine einheitliche Bezeichnung für diese Ebene der Fähigkeiten. Stattdessen traten sie in unterschiedlicher Form auf: Coding Agent, Deep Research Agent und Multi-Agent Orchestrator. In der Ingenieurspraxis funktionieren diese Fähigkeiten unabhängig voneinander. Doch sobald es um komplexe Aufgaben kommt, treten Probleme zutage: Die Ausführungswege sind nicht kontrollierbar, die Ergebnisse schwer reproduzierbar und das System hat Schwierigkeiten, zu konvergieren.

Eher als eine Einschränkung der Modellfähigkeiten ist dies das Ergebnis eines Mangels an Systemeinschränkungen.

Laut 36 Kr ist ein internationales KI-Systemteam, das sich seit langem damit beschäftigt, die Fähigkeiten von Modellen in stabil ausführbare Systeme umzuwandeln, eine interessante Entstehungshistorie. Die Kernmitglieder des Teams stammen aus MIT, CMU und dem Meta-Großmodell-Team. Der Gründer Luke Wang hat an der MIT Media Lab NLP-Forschung betrieben, unter der Leitung des damaligen Chief Data Scientists von Twitter. Seine Forschung konzentrierte sich auf die Integration von Sprachmodellen und Systemausführungsebenen. Die MIT Media Lab ist eines der weltweit einflussreichsten interdisziplinären Labs und steht an der Spitze der Erforschung neuer Rechenparadigmen. Hier wurden unter anderem das Scratch-Programmierbildungstool, die "Emotionscomputing"-Forschungsrichtung und die Entwicklungspfade von tragbaren Geräten geboren. Im Laufe kontinuierlicher Ingenieurspraxis kam der Teamgründer Luke Wang zu einem Schluss:

Das Problem der KI liegt nicht mehr in ihrer Fähigkeit, sondern in ihrer Konvergenz.

Genau auf dieser Einschätzung basierend hat sich die Herangehensweise des Teams geändert - anstatt weiterhin das Modell oder die Prompts zu optimieren, setzen sie nun von der Systemebene aus an:

Wie kann das Verhalten der KI strukturell eingeschränkt werden?

Eher als dass sie "Harness" forschen, wurden sie durch wiederholte Misserfolge zu dieser Frage gezwungen.

Ein internes Projekt brachte überraschende Ergebnisse

Vor etwa einem Jahr begann dieses Team mit einem internen Projekt (Mynora.ai) und stand damit vor einem immer wieder auftretenden Problem: Die Ausführung von Agents in komplexen Aufgaben kann nicht zuverlässig konvergieren.

Sie entwickelten einen intelligenten Coding Agent, der Code-Sicherheit und Systemstabilität betont, und testeten das Problem in den schwierigsten Szenarien: komplexe Aufgaben, langfristige Ausführungsketten und hochrisikoreiche Umgebungen. Das Ziel war eindeutig: Zu überprüfen, ob das System die KI "einschränken" kann, anstatt sie "anzuleiten".

Weniger als einen Monat nach dem Start verbreitete sich dieses Projekt in der nordamerikanischen Entwicklergemeinschaft rasch und "eroberte" eine sehr spezifische Nische: Bei der ETHGlobal New York Hackathon wählten fast 50 % der Teams es zur Entwicklung von Smart Contracts aus.

Zur gleichen Zeit erreichte es die Spitze der Product Hunt-Wochenliste im Oktober 2025 und belegte den zweiten Platz in der Monatsliste der Entwicklertools. In Bezug auf die Stabilität bei der Ausführung von Low-Level-Code (insbesondere in systemnahen Sprachen wie Rust) war es bereits besser als vergleichbare Produkte wie Cursor.

Dies zeigt, dass es in hoch eingeschränkten Szenarien als Standardtool eingesetzt wird.

Stabilität "wächst"

Bei solchen Systemen ist "etwas getan zu haben" und "etwas verstanden zu haben" oft völlig unterschiedliche Dinge.

Während fast einem Jahr an kontinuierlicher Praxis hat das Luke-Team im Laufe ständiger Iterationen eine umfassende Menge an Ingenieurwissen über die stabile Konvergenz des Agentenverhaltens gesammelt. Dies ist jedoch keine Fähigkeit, die einfach entworfen werden kann. Sie entsteht vielmehr aus wiederholten Fehlern, Korrekturen und langfristiger Beobachtung des Systemverhaltens.

In diesem Prozess hat sich auch der Schwerpunkt der Arbeit des Teams verlagert. Anstatt nur eine bestimmte Art von Aufgaben zu optimieren, testen sie ständig die Stabilitätsgrenzen des Systems in verschiedenen Szenarien. Von der Softwareausführung bis hin zu komplexeren Interaktionen und Geräteumgebungen werden die Formen der Einschränkung, die Ausführungswege und die Rückmeldemechanismen Schritt für Schritt neu definiert. In diesem Prozess des ständigen Ausprobierens und Lernens wird ein Konsens immer deutlicher:

Stabilität wird nicht entworfen, sondern "wächst" im Laufe des ständigen Ausprobierens.

Solche Fähigkeiten lassen sich schwer durch eine einzige Entwurfsphase umsetzen. Sie sind eher eine sich allmählich entwickelnde Systemfähigkeit. Aus diesem Grund zeigt die Harness-Engineering ein sehr einzigartiges Bild: Einerseits ist der Fortschritt sehr schnell, andererseits ist es immer mit Unsicherheiten verbunden.

Wie Luke es sagt: Dieser Weg macht Angst, aber er ist auch fesselnd.

Warum scheitern Regeln?

Viele Teams versuchen es zunächst, indem sie die Regeln erweitern: Durch System-Prompts, Anweisungen oder Einschränkungsdokumente versuchen sie, das Verhalten des Agents in die gewünschte Richtung zu lenken.

Aber bald stellt man fest, dass die Regeln systematisch verletzt werden. Der Grund dafür ist, dass die Regeln eher "verstanden" werden, als "befolgt".

In einem probabilistischen System kann der Agent die Regeln verstehen, wiederholen und sogar wissen, "was er tun sollte", aber das bedeutet nicht, dass er dies zuverlässig umsetzt.

Das bedeutet auch: Die Regeln allein können keine wirklichen Einschränkungen darstellen.

Von "Regeln" zu "Umgebung"

Der entscheidende Wandel bei Harness besteht darin: Anstatt die KI die Regeln zu merken zu lassen, wird verhindert, dass fehlerhafte Pfade überhaupt auftreten können.

In der kontinuierlichen Ingenieurspraxis wird ein Wandel deutlich: Das Team versucht nicht mehr, den Agenten die Regeln zu vermitteln, sondern gestaltet das System so, dass bestimmte fehlerhafte Pfade strukturell unmöglich werden. Die Form der Einschränkung ändert sich:

· Von Text zu System

· Von Anweisungen zu Umgebung

· Von "Verbot" zu "Unmöglichkeit"

In diesem Rahmen hängt die Einschränkung nicht mehr von der Verständnisfähigkeit ab, sondern wird direkt in der Ausführungsstruktur umgesetzt. Wenn ein Prompt dem Agenten sagt, was er nicht tun soll, dann ist Harness eher eine Methode, um ihm zu verwehren, dies überhaupt zu tun.

Deshalb kann es in einigen Systemen so aussehen, als sei der Agent "klüger". Im Ingenieurkontext ist die Erklärung eher, dass die Ausführungsumgebung des Systems nun vorhersagbarer ist.

Eine neue Systemebene entsteht

Harness ist kein plötzlich auftauchendes Konzept. Es ist eher die Kombination mehrerer etablierter Ingenieurkonzepte, die nach der Entstehung von Large Language Models neu zusammengefügt wurden: Sandbox, Runtime-Kontrolle, Typsystem, verteilte Einschränkungen, Tool-API-Design...

Diese Fähigkeiten existierten schon immer, aber waren in verschiedenen Bereichen verteilt. Erst mit der Entstehung von Agents richten sich diese Fähigkeiten auf dasselbe Problem. In herkömmlichen Software-Systemen ist das Verhalten vorhersagbar; in Agent-Systemen ist es probabilistisch.

Wenn das Verhalten einer Wahrscheinlichkeitsverteilung folgt, wird in der Ingenieurspraxis ein Trend deutlich: Die Einschränkungen müssen in die Strukturebene integriert werden.

Harness ist im Wesentlichen diese Strukturebene.

Warum jetzt?

Die intensive Diskussion über Harness ist kein Zufall. Sie ist eher ein Signal für eine neue Phase: Die Engpässe in der KI verschieben sich von den Modellen hin zum System. Früher ging es darum, ob das Modell etwas tun kann, jetzt geht es darum, ob das System es immer wieder zuverlässig tun lässt. In diesem Prozess verschiebt sich auch der Wert:

· Von der Modellschicht zur Systemschicht

· Von der Fähigkeitskonkurrenz zur Stabilitätskonkurrenz

Die Fähigkeiten der Modelle werden immer ähnlicher, während die Systemfähigkeiten sich unterscheiden. Harness wird daher als der entscheidende Wendepunkt in diesem Wandel angesehen.

Ein aus Fehlern gewachsenes System

Diese Erkenntnisse stammen nicht aus theoretischen Überlegungen, sondern aus wiederholter Ingenieurspraxis.

Ein typisches Beispiel: Selbst wenn explizit festgelegt ist, dass Python mit "uv run" ausgeführt werden muss, kann der Agent dennoch über "python3", "subprocess" oder Pfadmechanismen die Einschränkung umgehen.

In diesem Prozess wurde dem Team klar: Die festgelegten Regeln entsprechen nicht den wirklichen Einschränkungen im System. Deshalb werden die Einschränkungen Schritt für Schritt "verfestigt". Vom Textprompt über die Ausführungsunterbrechung bis zur Runtime-Kontrolle wandelt sich das System von einer "Empfehlung" zu einer "Struktur". Bis zu einem gewissen Punkt können Fehler nicht mehr verhindert, sondern werden einfach unmöglich.

Von "kann es" zu "kann es immer"

Mit der Einbindung von Agents in realistischere Anwendungsumgebungen ändert sich das Problem. Der Fokus liegt nicht mehr darauf, "was noch möglich ist", sondern darauf, "ob es immer möglich ist". Wenn die Aufgabenketten länger werden, die Umgebung komplexer wird und die Laufzeit verlängert sich, ist das Modell nicht mehr der Engpass, sondern das System.

Die echte Herausforderung besteht nun darin, die korrekte Ausführung ohne Unterbrechung aufrechtzuerhalten.

Fazit: Der Wendepunkt ist erreicht

Wenn die KI in den letzten zwei Jahren von ihrer Fähigkeit bestimmt wurde, wird der kommende Wendepunkt nicht mehr von den Modellen bestimmt. Der entscheidende Faktor wird sein, wer in der Lage ist, ein System aufzubauen, das die KI zuverlässig ausführt.

Und Harness wird immer mehr zum Namen für diese Ebene.