OpenAI-Anthropic-Harness-Debatte: Stärkere Modelle, gegensätzliche Engineering-Wetten
OpenAI-Ingenieure haben einen folgenreichen Streit mit Anthropic neu entfacht: Stärkere KI-Modelle sollten leichtere Harnesses benötigen, doch anspruchsvolle Aufgaben profitieren weiterhin von intensiverer Aufsicht.
Diese OpenAI-Anthropic-Harness-Debatte dreht sich nicht bloß um Prompts oder Interface-Präferenzen. Es geht um die Software, die ein Modell umgibt, darunter Tools, Speicher, Berechtigungen, Planung, Evaluierung und menschliche Freigaben.
OpenAI argumentiert, dass übermäßiges Scaffolding Einschränkungen festschreiben kann, die das nächste Modell nicht mehr hat. Die jüngsten Experimente von Anthropic kamen zu einem differenzierteren Schluss. Bessere Modelle machten einen Teil der Orchestrierung überflüssig, doch Planer und unabhängige Evaluatoren blieben wertvoll, wenn Aufgaben an die Grenzen des Modells stießen.
Die Meinungsverschiedenheit betrifft mehr als Codex und Claude Code. Unternehmen verwandeln allgemeine Modelle in Agenten, die Repositories bearbeiten, Browser bedienen, Dokumente analysieren und umfangreiche Projekte koordinieren. Jede zusätzliche Kontrolle kann die Zuverlässigkeit steigern, erhöht aber auch Latenz, Komplexität und die Zahl der Annahmen, die veralten können.
Die zentrale Frage lautet daher nicht, ob Harnesses wichtig sind. Die Engineering-Arbeit beider Unternehmen zeigt, dass sie es sind. Entscheidend ist, ob Fortschritt den Wert ins Modell verlagert, nach außen in den Harness verschiebt oder fortlaufend zwischen beiden Ebenen pendelt.
Was OpenAI und Anthropic tatsächlich verändert haben
Beide Unternehmen behandeln den Agent Harness inzwischen als produktdefinierende Ebene, unterscheiden sich jedoch darin, wie viel Intelligenz diese Ebene enthalten sollte.
Ein Agent Harness ist die Laufzeitumgebung, die ein Modell mit Tools, Kontext, Speicher, Feedbackschleifen und Nutzerkontrollen verbindet. Das Modell erzeugt Entscheidungen. Der Harness bestimmt, welche Informationen es sieht, welche Aktionen es ausführen kann und wie Fehler abgefangen werden.
Die Position von OpenAI wurde in Berichten vom August über seine Bemühungen deutlich, Agenten über die Softwareentwicklung hinaus auszuweiten. Die Ingenieure beschrieben gutes Harness Engineering als die Bereitstellung genau der Tools und Informationen, die ein Modell benötigt, ohne es mit unnötigen Regeln zu umgeben.
Ingenieur Nick Gershenson sagte TechCrunch, dass ausgefeilte Sammlungen aus bedingter Logik und Tools kurzfristige Gewinne erzielen können. Allerdings argumentierte er, dass ein neues Modell diese Ergänzungen innerhalb weniger Monate obsolet machen könne. Seine bevorzugte Richtung ist ein zurückhaltendes Interface, das einem leistungsfähigen Modell erlaubt, mehr vom Problem selbst zu lösen.
Dieses Prinzip erinnert an die bittere Lektion, Rich Suttons einflussreiches Argument, wonach allgemeine Rechenleistung Systeme übertrifft, die auf umfangreichem menschlichem Wissen aufbauen. Auf Agenten angewandt, spricht die Lektion für breit leistungsfähige Modelle statt für handentworfene Workflows für jeden erwarteten Fehler.
OpenAI hat Harness Engineering nicht aufgegeben. Der eigene Bericht über Codex engineering beschreibt Repositories, Dokumentation, Tests, Feedbackschleifen und maschinenlesbare Pläne als essenzielle Infrastruktur. Das Unternehmen meldete bei einem internen Projekt durchschnittlich 3,5 Pull Requests pro Ingenieur und Tag.
Der Unterschied liegt darin, wo OpenAI die Komplexität ansiedeln möchte. Seine Ingenieure bevorzugen verständliche Umgebungen und klares Feedback statt immer komplexerer Verzweigungen, die vorschreiben, wie das Modell denken muss.
Die Forschung von Anthropic vom 24. März präsentierte einen anderen Stresstest. Der Forscher Prithvi Rajasekaran nutzte einen Planer, Generator und Evaluator, um vollständige Anwendungen über längere autonome Sitzungen hinweg zu erstellen.
Der Planer übersetzte eine kurze Anfrage in eine strukturierte Spezifikation. Der Generator setzte diesen Plan um. Der Evaluator bediente die Anwendung, prüfte vereinbarte Kriterien und meldete Fehler zur Korrektur zurück.
Der erste Vergleich von Anthropic ergab, dass ein Single-Agent-Durchlauf eine Anwendung produzierte, deren zentrales Gameplay-Feature nicht funktionierte. Der Multi-Agent-Harness lieferte ein umfassenderes, funktionierendes Ergebnis, auch wenn Mängel blieben.
Dies war kein Beleg dafür, dass mehr Gewicht immer gewinnt. Anthropic entfernte später die Zerlegung auf Sprint-Ebene, als Claude Opus 4.6 längere Arbeit kohärenter bewältigte. Planer und Evaluator fanden jedoch weiterhin fehlende oder oberflächlich umgesetzte Features.
Das Ereignis ist daher zugleich Annäherung und Meinungsverschiedenheit. OpenAI und Anthropic vereinfachen beide ihre Harnesses, wenn Modelle frühere Verantwortlichkeiten übernehmen. Sie unterscheiden sich darin, wie schnell Entwickler diesem Übergang vertrauen sollten.
Warum die OpenAI-Anthropic-Harness-Debatte jetzt wichtig ist
Der Druck entsteht, weil Agenten über klar abgegrenzte Coding-Aufgaben hinaus in Arbeit vordringen, bei der Erfolg schwerer zu definieren und Fehler schwerer rückgängig zu machen sind.
Coding bot das erste günstige Umfeld für Agenten. Repositories enthalten strukturierte Dateien, Compiler legen Fehler offen, und Tests erzeugen oft eindeutige Bestanden-oder-nicht-bestanden-Signale. Ein Harness kann diese Signale in einen weiteren Modellversuch umwandeln.
Allgemeine Wissensarbeit bietet weniger verlässliche Prüfungen. Ein Strategiememo kann schlüssig wirken, obwohl es auf schwachen Annahmen beruht. Eine Tabellenkalkulation kann korrekt rechnen und dennoch die falsche Geschäftsfrage beantworten. Ein Agent kann eine professionell gestaltete Präsentation fertigstellen, ohne zu bemerken, dass seine Belege veraltet sind.
OpenAI erweitert seinen Agentenansatz auf diese weniger strukturierten Umgebungen. Dieser Schritt setzt das Unternehmen unter Druck, die mit stärkeren Modellen verbundene Einfachheit zu bewahren und zugleich die von gewöhnlichen Nutzern verlangten Kontrollen hinzuzufügen.
Anthropic steht unter dem gegenteiligen Druck. Claude Code verdankt einen großen Teil seiner Attraktivität sichtbaren Fortschritten, häufiger Interaktion und der Einbindung der Nutzer. Das kann sich sicherer anfühlen, doch wiederholte Fragen und Freigaben erhöhen den Arbeitsaufwand der Bedienenden.
Die Rivalität spiegelt zwei Produktinstinkte wider. OpenAI hat häufig das Erlebnis verfolgt, ein Ziel zuzuweisen und ein fertiges Ergebnis zu erhalten. Anthropic hat im Allgemeinen mehr vom zwischengelagerten Denkprozess durch Pläne, Alternativen und Berechtigungsanfragen offengelegt.
Keiner dieser Instinkte ist universell besser. Autonomie wird attraktiv, wenn das Ziel klar und die Überprüfung günstig ist. Zusammenarbeit wird wertvoll, wenn Präferenzen unausgesprochen bleiben oder Folgen schwer zu messen sind.
Das erklärt, warum ein Interface die wahrgenommene Qualität eines identischen Modells verändern kann. Ein Harness steuert die Kontextauswahl, Tool-Beschreibungen, Wiederholungsverhalten, Dateizugriff und den Zeitpunkt der Nutzerintervention. Diese Entscheidungen prägen jede Aktion, die das Modell ausführt.
Unabhängige Framework-Entwickler haben dieselbe Abhängigkeit beobachtet. LangChain berichtete, dass modellspezifische Harness-Profile auf einem Teil von tau2-bench im Vergleich zur Standardkonfiguration Verbesserungen um 10 bis 20 Punkte erzielten. Seine Harness Profiles passen Prompts, Tools und Middleware an unterschiedliche Modellverhalten an.
Dieses Ergebnis stellt eine einfache Version von OpenAIs These infrage. Wäre der Harness nur eine vorübergehende Krücke, sollte seine Veränderung keine großen Leistungsunterschiede erzeugen, während das zugrunde liegende Modell unverändert bleibt.
Es stützt jedoch auch OpenAIs Kritik an unnötiger Abstraktion. LangChain fand keine einzelne, immer komplexere Architektur, die jedes Modell verbesserte. Stattdessen stellte es fest, dass unterschiedliche Modelle auf unterschiedliche Konfigurationen reagierten.
Der praktische Druck trifft Produktteams. Sie müssen entscheiden, ob sie eng für einen Anbieter optimieren oder eine portable Ebene über mehrere Modelle hinweg pflegen.
Eine enge Optimierung kann unmittelbar bessere Ergebnisse liefern. Sie kann jedoch auch Abhängigkeiten von anbieterspezifischen Tools, Prompts und Kontextverhalten schaffen. Portabilität begrenzt diese Abhängigkeit, doch ein generischer Harness kann Modellfähigkeiten ungenutzt lassen.
Diese Entscheidungen werden folgenreicher, sobald Agenten weitergehende Berechtigungen erhalten. Ein Coding-Assistent, der einen Patch vorschlägt, hat eine begrenzte Rolle. Ein Agent, der Kommunikation liest, geteilte Dokumente bearbeitet und Geschäftssysteme auslöst, überschreitet mehrere Vertrauensgrenzen.
Teams, die diese Produkte bewerten, sollten daher über Modell-Benchmarks hinausblicken. Sie benötigen Belege für die vollständige Kombination aus Modell und Harness unter realistischen Berechtigungen, Daten und Fehlerbedingungen.
OpenAI will das Modell führen lassen
OpenAIs Argument für leichtere Harnesses besagt, dass Entwickler die Umgebung klar offenlegen und das Modell dann den Großteil des adaptiven Verhaltens liefern lassen sollten.
Diese Position bedeutet nicht, Tests, Berechtigungen oder Kontextmanagement abzuschaffen. Sie bedeutet, sich gegen handgebaute Denkverfahren zu wehren, die erwartete Einschränkungen kompensieren sollen, welche bald verschwinden könnten.
OpenAIs Erfahrungen mit der ersten Codex-Webanwendung helfen, diese Überzeugung zu erklären. Das Unternehmen setzte zunächst darauf, dass ein Modell Aufgaben mit minimaler Nutzerbeteiligung erledigt. Der interaktivere Claude Code-Ansatz von Anthropic erwies sich als besser darauf abgestimmt, was Modelle zu diesem Zeitpunkt zuverlässig leisten konnten.
OpenAI fügte später mehr Möglichkeiten hinzu, damit Nutzer Codex anleiten können. Ein Ingenieur räumte ein, dass das frühere Produkt dem voraus gewesen sei, was Modell und Harness unterstützen konnten.
Diese Geschichte ist wichtig, weil sie die Gefahr auf beiden Seiten zeigt. Ein Harness kann zu viel starre Logik enthalten. Er kann auch mehr Modellkompetenz voraussetzen, als Nutzer tatsächlich erhalten.
OpenAIs aktueller Ansatz versucht, eine weitere Fehlanpassung durch klarere Umgebungen und stärkeres Feedback zu vermeiden. Der interne Engineering-Bericht betont strukturierte Dokumentation, Repository-Regeln, Pläne und automatisierte Prüfungen.
Diese Elemente sind leichter als ein Workflow, der jeden Denkschritt vorschreibt. Dennoch stellen sie weiterhin umfangreiches Engineering dar. Der Harness delegiert Urteilsvermögen und erleichtert zugleich die Überprüfung von Erfolg.
Der Ansatz passt auch zu OpenAIs Produktambitionen. Ein allgemeiner Arbeitsplatzagent kann sich nicht darauf verlassen, dass Designer jede Aufgabenfolge vorhersehen, die ein Nutzer anfordern könnte. Der Raum möglicher Aufgaben ist zu groß.
Ein modellgeführtes System kann Tools auswählen und Pläne überarbeiten, wenn sich Bedingungen ändern. Diese Flexibilität ist attraktiv, wenn Nutzer innerhalb einer Aufgabe zwischen Recherche, Tabellenkalkulationen, Nachrichten, Code und Präsentationen wechseln.
Ein minimaler Harness verlagert jedoch mehr Verantwortung in das Modell. Das Modell muss Mehrdeutigkeiten erkennen, fehlende Informationen anfordern und feststellen, wann eine Aktion eine Bestätigung verdient.
Diese Verhaltensweisen werden nicht allein durch allgemeine Leistungsfähigkeit garantiert. Ein Modell kann besser darin werden, Anweisungen auszuführen, ohne im gleichen Maß besser darin zu werden, ein fehlerhaftes Ziel zu erkennen.
Die Nutzererfahrung verstärkt dieses Risiko. Ethan Mollick, ein Wharton-Professor, der KI am Arbeitsplatz erforscht, hat Systeme, die versuchen, die Arbeit sofort zu erledigen, mit solchen verglichen, die Vergleiche zeigen und Feedback anfordern.
Das autonomere Design reduziert Reibung, wenn der Agent das Ziel richtig interpretiert. Tut er es nicht, können Nutzer den Fehler erst nach einer langen Kette schlüssiger, aber fehlgeleiteter Arbeit entdecken.
Damit wird die Qualität des Kontexts zentral. Ein leichter Harness funktioniert am besten, wenn er präzise, relevante und aktuelle Informationen bereitstellt. Großer, ungefilterter Kontext kann Prioritäten verschütten, selbst wenn das Modell ein langes Kontextfenster unterstützt.
Für Wissensarbeiter bleibt die Organisation dieser Belege ein eigenes Engineering-Problem. Eine durchsuchbare Wissensdatenbank kann Abrufrauschen reduzieren, bevor ein Agent zu handeln beginnt.
OpenAIs These ist am stärksten bei Aufgaben mit dichtem maschinellem Feedback. Compiler, Test-Suites, Linter und Browser-Prüfungen ermöglichen es einem Agenten, Fortschritt ohne fortlaufendes menschliches Urteil zu bewerten.
Es wird schwächer, wenn die Fertigstellung von Geschmack, der Geschichte einer Organisation oder nicht dokumentierten Erwartungen abhängt. Ein Modell kann keine Belege ableiten, die nie in seinen Kontext gelangen.
OpenAI geht daher eine kalkulierte Wette ein. Mit besseren Modellen werden diese intern mehr Planung und Fehlerbehebung übernehmen. Entwickler von Harnesses sollten Allgemeingültigkeit bewahren, statt die Beschränkungen heutiger Modelle im Produkt von morgen festzuschreiben.
Anthropic: Anspruchsvollere Arbeit braucht weiterhin mehr Struktur
Die Evidenz von Anthropic zu umfangreicheren Harnesses zeigt, dass stärkere Modelle Orchestrierung nicht überflüssig machen; sie verschieben lediglich deren sinnvolle Grenze zu schwierigeren Aufgaben.
Der Langzeit-Harness von Anthropic ging von zwei wiederkehrenden Schwächen aus. Modelle verloren bei längerer Arbeit die Kohärenz und bewerteten ihre eigenen Ergebnisse zu wohlwollend.
Das erste Problem betraf den Kontext. Lange Aufgaben sammeln Entscheidungen, Tool-Ergebnisse, Fehler und Teilimplementierungen an. Selbst wenn ein Kontextfenster dieses Material aufnehmen kann, beeinflusst seine Organisation, was das Modell wahrnimmt.
Anthropic verwendete Kontext-Resets mit strukturierten Übergabedateien. Ein Reset gab einer neuen Agentensitzung einen sauberen Arbeitsstand und bewahrte zugleich wesentliche Fortschritte und nächste Schritte.
Das zweite Problem war die Selbstbewertung. Dasselbe Modell, das eine Anwendung erstellt hatte, akzeptierte häufig schwache Ergebnisse – insbesondere dann, wenn Qualität von Designurteilen abhing.
Anthropic trennte Erstellung und Überprüfung. Der Evaluator nutzte explizite Kriterien und Browserautomatisierung, um die Funktionalität zu testen. Der Generator erhielt konkrete Befunde und versuchte, Korrekturen vorzunehmen.
Der erste vollständige Harness erweiterte eine einzeilige Spielanfrage über zehn Sprints auf 16 Funktionen. Sein Evaluator wandte auf jeden Sprint detaillierte Verträge an, darunter 27 Kriterien für eine Phase des Level-Editors.
Anthropic berichtete, dass das Multi-Agenten-Ergebnis funktionierende Kernfunktionen bot, die dem Single-Agenten-Versuch fehlten. Es erforderte jedoch deutlich mehr Laufzeit, Orchestrierung und Modellnutzung.
Dieser Kompromiss macht das Experiment nützlicher als einen bloßen Benchmark-Sieg. Er zeigt, was zusätzliche Struktur leisten kann, und legt zugleich offen, warum Teams Evaluatoren nicht wahllos hinzufügen können.
Anschließend wiederholte Anthropic den Prozess mit einem stärkeren Modell. Opus 4.6 hielt den Haupt-Build mehr als zwei Stunden lang ohne die frühere Sprint-Zerlegung aufrecht.
Das stützte OpenAIs zentrale Beobachtung. Eine Fähigkeit, die zuvor vom Harness bereitgestellt wurde, war in das Modell gewandert und machte einen Teil des Gerüsts überflüssig.
Der Evaluator fand weiterhin folgenreiche Lücken. Er identifizierte zentrale Audiofunktionen, die nur als oberflächliche Interface-Elemente oder Platzhalter existierten. Der Generator behob daraufhin mehrere dieser Auslassungen.
Anthropics Schlussfolgerung lautete nicht, dass jede Aufgabe drei Agenten benötigt. Der Evaluator stiftete den größten Wert, wenn die Arbeit an der Grenze dessen lag, was der Generator zuverlässig abschließen konnte.
Diese Grenze ist dynamisch. Ein neues Modell verschiebt sie nach außen. Eine anspruchsvollere Aufgabe verschiebt sie wiederum nach innen.
Daraus ergibt sich eine andere Interpretation der bitter lesson. Allgemeine Modelle ersetzen maßgeschneiderte Lösungen für die Probleme von gestern, machen aber zugleich zuvor unpraktische Ziele erreichbar.
Sobald Teams diese Ziele verfolgen, treten neue Fehlermodi auf. Der Harness verschwindet nicht. Er folgt der Leistungsgrenze.
Anthropics Position erkennt außerdem an, dass Evaluierung Teil des Produkts ist. Ein System, das mehr Output erzeugt, ist nicht automatisch nützlicher. Jemand oder etwas muss bestimmen, ob dieser Output die tatsächliche Anforderung erfüllt.
Für Entwickler können Test-Suites einen großen Teil dieser Beurteilung liefern. Bei Design-, Forschungs- und Managementarbeit müssen die Kriterien jedoch oft formuliert werden, bevor der Agent handelt.
Eine Planer-Evaluator-Architektur macht diese Erwartungen explizit. Sie kann aber auch schlechte Kriterien verstärken. Ein Evaluator wird den messbaren Proxy durchsetzen, den er erhält – selbst wenn dieser Proxy verfehlt, was Nutzer schätzen.
Umfangreichere Harnesses schaffen daher ein eigenes Governance-Problem. Mehr Komponenten bedeuten mehr Prompts, Berechtigungen, Logs, Übergaben und Fehlerpfade, die gepflegt werden müssen.
Die Evidenz von Anthropic spricht für selektive Struktur, nicht für dauerhafte Komplexität. Entfernen Sie, was ein stärkeres Modell inzwischen bewältigen kann, und investieren Sie den Engineering-Aufwand dort neu, wo Verifizierung weiterhin einen bedeutenden Gewinn bringt.
Der Test Modell gegen Harness ist weiterhin offen
Keine Seite hat gezeigt, dass ihre bevorzugte Architektur über Modelle, Aufgaben, Budgets und Risikoniveaus hinweg gewinnt.
Die Debatte über OpenAI- und Anthropic-Harnesses stützt sich stark auf interne Experimente und Produktbeobachtungen. Diese Quellen zeigen Engineering-Entscheidungen, liefern jedoch keinen kontrollierten Vergleich zwischen Codex und Claude Code.
OpenAIs Darstellung spiegelt die eigenen Modelle, Repositories und Teampraktiken wider. Anthropics Beispiele verwenden Claude-Modelle für ausgewählte Aufgaben zur Anwendungserstellung. Jedes Unternehmen wählte Umgebung und Erfolgskriterien selbst.
Sogar Anthropics detaillierter Vergleich veränderte mehrere Variablen zugleich. Das vollständige System ergänzte Planung, Evaluierung, Zerlegung, längere Ausführung und mehr Modellaufrufe. Das Ergebnis kann nicht isolieren, welche Komponente welche Verbesserung erzeugte.
Das Unternehmen nutzte später die Entfernung einzelner Komponenten, um diese Frage besser zu verstehen. Dennoch stammten seine Schlussfolgerungen aus einer kleinen Sammlung von Demonstrationen und nicht aus einer breiten unabhängigen Replikation.
Benchmarks von Drittanbietern helfen, bringen jedoch zusätzliche Komplikationen mit sich. Ein Harness kann gut abschneiden, weil der Benchmark seinem bevorzugten Workflow ähnelt. Eine andere Konfiguration kann stattdessen Token-Nutzung, Erfolgsquote, Latenz oder Wiederherstellbarkeit optimieren.
Dieselbe Punktzahl kann auch unterschiedliche operative Risiken verbergen. Ein Agent könnte sichtbar scheitern und stoppen. Ein anderer könnte ein plausibles, aber falsches Ergebnis erzeugen, das automatisierte Prüfungen übersteht.
Die Forschung zu Coding-Systemen für die Produktion betrachtet Modell und Harness zunehmend als kombinierte Einheit. Eine aktuelle Quellcode-Studie untersuchte 11 Coding-Harnesses, darunter Claude Code, Codex CLI, Gemini CLI, Pi, OpenCode und OpenHands.
Diese Vielfalt schwächt die Vorstellung eines einzigen optimalen Harnesses. Die Systeme unterscheiden sich bei Kontextmanagement, Erweiterungspunkten, Planung, Isolierung und Tool-Ausführung, weil ihre Entwickler unterschiedliche Nutzer adressieren.
Die Portabilität stellt ein weiteres ungelöstes Problem dar. Berichte verwiesen auf einen Vergleich, in dem der Open-Source-Harness Pi Codex übertraf, obwohl dasselbe OpenAI-Modell verwendet wurde.
Ein solches Ergebnis legt nahe, dass ein Modellanbieter nicht automatisch die beste Umgebung für jede Aufgabe baut. Es beweist nicht, dass Pi generell gewinnt, da Benchmark-Aufbau und Konfiguration weiterhin entscheidend sind.
Offene Harnesses können Traces, Token-Nutzung und Konfigurationsdetails offenlegen, die proprietäre Produkte verbergen. Diese Transparenz hilft Teams, Fehler zu diagnostizieren und Anbieter zu wechseln.
Anbieter-kontrollierte Harnesses erhalten früheren Zugang zu modellspezifischen Fähigkeiten. Ihre Entwickler können auf nicht dokumentiertes Verhalten abstimmen und koordinierte Updates ausrollen.
Die geschäftlichen Anreize sind relevant. OpenAI und Anthropic profitieren beide, wenn Kunden ihre Modelle über die eigenen Schnittstellen nutzen. Der Besitz des Harnesses stärkt den Vertrieb und kann durch gespeicherten Kontext, Integrationen und erlernte Workflows die Wechselkosten erhöhen.
Das macht ihre Engineering-Behauptungen nicht falsch. Es bedeutet, dass Kunden technische Evidenz von Plattformstrategie trennen sollten.
Kosten sind eine weitere Unsicherheit, auch ohne öffentliche Preisangaben zu vergleichen. Multi-Agenten-Planung und -Evaluierung verbrauchen zusätzliche Tokens und Zeit. Eine höhere Abschlussrate kann diesen Aufwand rechtfertigen, wenn Fehler teuer sind.
Für routinemäßige, reversible Arbeit gilt das Gegenteil. Einen Evaluator über jede kleine Änderung laufen zu lassen, kann mehr Ressourcen verbrauchen als die gelegentliche Korrektur eines Fehlers.
Sicherheit verkompliziert die These des leichteren Harnesses zusätzlich. Bessere Modelle können längere Handlungssequenzen ausführen und Tools effektiver nutzen. Diese Verbesserungen erhöhen die Folgen missverstandener Anweisungen.
Berechtigungsgrenzen, Audit-Logs, Sandboxing und Bestätigungen sind Funktionen eines Harnesses. Stärkere Fähigkeiten können ihre Bedeutung erhöhen, selbst wenn sie den Bedarf an Planungsgerüsten verringern.
Teams sollten daher eindimensionale Tests ablehnen. Eine nützliche Evaluierung muss Aufgabenerfüllung, verdeckte Fehler, menschliche Prüfzeit, Ressourcenverbrauch und Wiederherstellung nach Fehlern messen.
Sie sollte außerdem Konfigurationen unter demselben Modell vergleichen. Andernfalls kauft ein Team möglicherweise ein leistungsfähigeres Modell, obwohl eine Kontext- oder Tool-Änderung das Problem gelöst hätte.
Die aktuelle Evidenz stützt eine bedingte Regel: Nutzen Sie den leichtesten Harness, der eine definierte Zuverlässigkeitsschwelle erfüllt, und fügen Sie Struktur dort hinzu, wo beobachtete Fehler sie rechtfertigen.
Diese Regel klingt nach einem Kompromiss, schafft aber anspruchsvolle operative Arbeit. Teams benötigen wiederholbare Evaluierungen, Trace-Inspektion und versionierte Konfigurationen, um zu wissen, wann eine Komponente weiterhin nützlich ist.
Ohne diese Evidenz wird „leichter“ zum Glauben an das nächste Modell. „Schwerer“ wird zu angesammelter Folklore, die in Prompts und Workflow-Verzweigungen kodiert ist.
Drei Signale werden entscheiden, welcher Ansatz gewinnt
Die nächste Phase wird durch vergleichende Evidenz entschieden, nicht durch die bevorzugte Beschreibung ihrer Architektur durch eines der Unternehmen.
Das erste Signal ist die Leistung beim Austausch von Harnesses. Forschende und Framework-Entwickler benötigen kontrollierte Tests, die Modell, Aufgabe, Tool-Zugriff und Ressourcenlimits konstant halten.
Wenn Harnesses von Drittanbietern bei Verwendung desselben Modells wiederholt die Anbieter-Schnittstellen übertreffen, verschiebt sich der Wert in Richtung Orchestrierung. Dieses Ergebnis würde die Annahme schwächen, dass Modellfortschritt den Großteil der Produktdifferenzierung auf natürliche Weise absorbiert.
Wenn sich Leistungsunterschiede zwischen gut konzipierten Harnesses verringern, gewinnt OpenAIs These an Unterstützung. Das würde nahelegen, dass stärkere Modelle weniger spezialisierte Eingriffe benötigen und über einfachere, standardisierte Umgebungen arbeiten können.
Das zweite Signal ist, wie Anthropic und OpenAI ihre eigenen Systeme nach jeder Modellveröffentlichung vereinfachen. Anthropic hat bereits eine Version dieses Tests gezeigt, indem es die Sprint-Zerlegung aus Opus-4.6-Workflows entfernte.
Beobachten Sie, welche Komponenten als Nächstes verschwinden. Planung, Kontext-Resets, unabhängige Evaluierung und häufige Freigaben repräsentieren jeweils eine andere Annahme über Modellgrenzen.
Das Entfernen einer Komponente ohne Verringerung der Aufgabenqualität stärkt den Fall für leichtere Harnesses. Die Verlagerung dieser Komponente auf eine schwierigere Aufgabenklasse stützt Anthropics Interpretation einer sich verschiebenden Grenze.
Das dritte Signal ist die Einführung außerhalb des Software-Engineerings. Coding-Agenten profitieren von Repositories, Tests und digitalisiertem Feedback. Wissensarbeit enthält schwächere Signale und mehr implizite Präferenzen.
Ein modellgesteuerter Agent wirkt überzeugend, wenn Menschen abgeschlossene Arbeit ohne umfangreiche Korrekturen akzeptieren. Ein kollaborativer Harness wirkt stärker, wenn Nutzer konsequent Vorschauen, Vergleiche und Freigabepunkte benötigen.
Die nützlichste Akzeptanzkennzahl wird nicht die Zahl gestarteter Aufgaben sein. Sie wird der Anteil sein, der nach Berücksichtigung menschlicher Prüfung und Nacharbeit korrekt abgeschlossen wird.
Entwickler sollten auch die Schwere von Fehlern erfassen. Ein Harness, der weniger Aufgaben abschließt, aber sicher stoppt, kann einem vorzuziehen sein, der mehr fertigstellt und dabei schwer erkennbare Fehler macht.
Unternehmenskäufer sollten Evaluierungen mit ihren eigenen Dokumenten, Berechtigungen und Workflows verlangen. Öffentliche Bestenlisten können organisationsspezifische Definitionen von Korrektheit nicht abbilden.
Wissensarbeiter können eine einfachere Version dieses Prozesses durchführen. Beginnen Sie mit einer vertrauten, reversiblen Aufgabe und vergleichen Sie das Ergebnis des Agenten mit einer etablierten menschlichen Referenz.
Halten Sie fest, wo dem Modell Kontext fehlte, es das falsche Tool wählte oder subjektive Anleitung benötigte. Diese Beobachtungen zeigen, ob die nächste Intervention in Anweisungen, Retrieval, Freigaberegeln oder unabhängige Überprüfung gehört.
Die Debatte über die Harnesses von OpenAI und Anthropic wird nicht damit enden, dass ein Unternehmen sich für eine dünne Schicht entscheidet und das andere eine dicke baut. Beide fügen bereits Komponenten hinzu und entfernen sie wieder, wenn sich Modelle und Aufgaben ändern.
Der nachhaltige Vorteil wird bei Teams liegen, die diese Veränderungen schnell messen können. Sie werden erkennen, welche Beschränkungen weiterhin Fehler verhindern und welche lediglich Annahmen eines älteren Modells bewahren.
Für alle, die Agenten einsetzen, ist die unmittelbare Maßnahme klar: Modell und Harness gemeinsam testen, reale Traces prüfen und Erfolg definieren, bevor umfassendere Autonomie gewährt wird. Leistungsfähigere Modelle verschieben die technische Grenze, doch sie beseitigen nicht die Notwendigkeit, sie zu bestimmen.
