StartseiteArtikel

Einen Artikel, um Harness Engineering zu verstehen: In 14 Artikel über das Engineering das Gehäuse zu finden, das künstliche Intelligenz davon abhält, abwegig zu werden.

36氪的朋友们2026-04-02 18:06
Zerschlage die schwarze Kiste endgültig, folge den 15-monatigen Dokumenten voller Blut und Tränen und erkenne jede echte Zeichnung dieses "Harness Engineering" klar.

Im ersten Quartal 2026 war das dominierendste Schlagwort auf der Anwendungsseite von Large Language Models (LLMs) definitiv „Harness“.

Im März dieses Jahres veröffentlichte LangChain eine empirische Studie mit dem Titel „The Anatomy of an Agent Harness“, die die Angst und die Euphorie aller entfacht hat. In diesem Bericht zitieren sie einen Vergleich von Experimentdaten. Indem man einem LLM einfach eine raffiniertere Harness - Architektur verpasst, stieg seine Passrate auf der Terminal Bench 2.0 (einer autoritativen Liste zur Messung der Programmierfähigkeiten von KI) von 52,8 % auf 66,5 %.

In diesem Experiment wurde nicht ein einziger Byte der Gewichte des zugrunde liegenden Modells geändert, und der Rechenleistungsmotor blieb unverändert. Nur durch das Anbringen einer raffinierten „Hülle“ sprang die Platzierung von Platz 30+ in die Top 5.

Seitdem haben zahlreiche Start - up - Unternehmen angefangen, ihre eigenen Hüllen zu verpacken. Harness scheint die Zauberei geworden zu sein, die alles in Gold verwandelt, und das beste Argument und Schutzschild für Anwendungsunternehmen, wenn sie sich an Investoren wenden.

Aber in dieser Euphorie wurden die Grenzen des Konzepts immer weiter gezogen und verschwommen.

Was genau ist die echte Hülle, und was liegt außerhalb? Viele externe Artikel versuchen, alles abzudecken und packen die Entstehung von CLI - Tools (Befehlszeilentools), die Popularität von Markdown - Dateien und sogar die neuesten Skill - Pakete in den Harness - Korb. In gewisser Weise ist das richtig, denn alle sind technische Optionen und Innovationen, die den Agenten im Rahmen der Agent - Infrastruktur besser funktionieren lassen.

Aber wenn wir die technologische Entwicklung von Harness verstehen möchten, müssen wir die Entstehungsgeschichte dieses Konzepts nachverfolgen.

Heute, wenn man sich die Anthropic - Gruppe ansieht, die Harness zuerst systematisierte, wird man feststellen, dass sie, während die gesamte Branche hektisch Bauwerke errichtet, stillschweigend Wände abbaut.

Mit der neuen Version von Opus haben sie beschlossen, die Kontrollkomponenten, die sie mit viel Mühe aufgebaut hatten, zu entfernen.

Während die eine Seite hektisch baut, bricht die andere Seite entschlossen ab. Diese widersprüchliche Branchen - Euphorie rührt daher, dass die meisten Menschen die in den letzten 15 Monaten entstandenen technischen Artikel nicht richtig verstanden haben.

Die Leute sehen nur den doppelten Gewinn bei den Endtests, aber sie verstehen nicht, welche verzweifelten Bugs die komplexen Mechanismen ursprünglich verursacht haben.

Heute wollen wir diese schwarze Kiste aufbrechen. Anhand der 15 - monatigen Literatur wollen wir die echten Pläne dieser „Harness - Engineering“ verstehen.

01 Die erste Schicht von Harness: Vom Notizbuch zur Management - Regelung

Es ist nicht schwer, Harness zu erklären. Stellen Sie sich einfach vor, dass ein Agent ein Auto ist.

Das Modell ist der Motor, leistungsstark und schnell, und es reagiert sofort auf Gas. Das Interaktionsprogramm, das es trägt, sind die Räder, das Lenkrad ist Ihr Prompt, und wenn Sie lenken, bringt der Motor Sie vorwärts. Aber der Motor, das Lenkrad und die Räder alleine sind kein Auto. Sie können nicht mit einem Motor auf die Straße fahren. Sie brauchen ein Getriebe und Bremsen, um die Räder zu lenken, ein Tacho, um zu wissen, wie weit Sie gefahren sind, und eine Bremse, um zu stoppen. All diese Dinge zusammen, wie man Aufgaben aufteilt, wie man den Fortschritt misst und wie man die Fertigstellung feststellt, das ist Harness, die Hülle.

Die Hülle ist nicht aus dem Nichts entstanden. Sie hat eine Vorgeschichte.

LLMs haben von Natur aus nur ein Gedächtnis, das Kontextfenster. Wenn das Fenster voll ist, wird der frühere Inhalt herausgedrängt.

Das ist für kurze Aufgaben kein Problem. Im Dezember 2024 veröffentlichte Anthropic einen technischen Blogbeitrag mit dem Titel „Building effective agents“. Der Kern des Vorschlags war: „Beginne mit dem einfachsten Ansatz und füge Komplexität nur wenn nötig hinzu.“ Damals waren die Agent - Aufgaben meist kurze Strecken, die in wenigen Minuten abgeschlossen wurden. Die Kurzzeitgedächtnis - Kapazität des Modells reichte aus, und ein gut formuliertes System - Prompt (die „Rollenbeschreibung“ für das Modell) war ausreichend, um es zum Arbeiten zu bringen.

Aber alle möchten, dass Agenten größere Aufgaben erledigen.

Im ersten Halbjahr 2025 hat sich die Inferenzfähigkeit der Modelle verbessert, und theoretisch können sie längere Aufgaben ausführen. Aber hier traten Probleme mit dem Kontext auf. Obwohl die Modelle jetzt relativ lange Kontexte haben (z. B. 1 Million Tokens), ist ihre effektive Aufmerksamkeitsspanne nicht so groß, und selbst wenn es so wäre, können sie nicht alle Details einer langen Aufgabe aufnehmen. Menschen wählen beim Merken die wichtigen Dinge aus, aber Modelle können das nicht. In komplexen Aufgaben hat es fast so ein Gedächtnis wie ein Goldfisch.

Um das Problem zu lösen, dass der effektive Kontext zu klein war und die Aufgaben nicht abgeschlossen werden konnten, war einer der ersten Ansätze die externe Speicherung des Gedächtnisses. Im März 2023 gab AutoGPT dem Modell ein leeres Notizbuch, d. h. die Berechtigung, Dateien zu schreiben und zu lesen, und ließ es dann sein eigenes Gedächtnis verwalten. Das Medium war eine reine .txt - Datei ohne strukturelle Einschränkungen. Das Modell konnte schreiben und löschen, was es wollte.

Aber ohne Verwaltung schrieb das Modell natürlich chaotisch. Im März 2024 hat Devin das Notizbuch in ein strukturiertes Panel umgewandelt und ein strukturiertes Planner - Panel eingeführt. Die Aufgabenplanung des Modells wird in einen sichtbaren Fortschrittsbalken gezwungen, und jeder Schritt hat eine eindeutige Statusmarkierung.

Im Februar 2025 wurde Claude Code entwickelt, das alle Erfahrungen, die Anthropic im SWE - Bench gesammelt hatte, in ein Produkt umwandelte. Die Kombination von CLAUDE.md (Projekt - Befehlsdatei) und scratchpad (Entwurfspad) wurde zur am weitesten kopierten Methode in der Branche.

Aber selbst mit einem solchen externen Gedächtnissystem kann der Kontext immer noch nicht ausreichen.

Dafür veröffentlichte das Anwendungs - Team von Anthropic im September 2025 einen Artikel mit dem Titel „Effective context engineering for AI agents“. In dieser Version wurden drei Lösungsansätze für das Kontextproblem vorgeschlagen. Es gibt zwei Strategien: Effizienzsteigerung und Kompression, damit lange Aufgaben in einem Kontextschicht abgeschlossen werden können.

Die erste Strategie ist die Steigerung der Kontexteffizienz, d. h. die Änderung der Art und Weise, wie der Kontext geschrieben wird. Zuerst sollte das System - Prompt nicht einfach „ein paar Sätze schreiben“ sein, sondern wie Code verwaltet werden, mit Versionskontrolle, A/B - Tests und dynamischer Zusammenstellung verschiedener Prompt - Module nach Aufgabenart. Dies ist effizienter. Dann sollte man die Beschreibung der Tools ändern, denn unklare oder fehlerhafte Tool - Beschreibungen sind ineffizient und beanspruchen Kontext. Sie fanden heraus, dass das Modell die Tool - Beschreibungen genauso liest wie das System - Prompt. Die Benennung, die Parameterbeschreibung und das Rückgabewertformat der Tools beeinflussen direkt die Entscheidungsqualität des Agenten. Ein schlecht geschriebener Text ist wie eine chaotische Karte für einen Goldfisch. Dann sollte man externe Speicher (RAG) verwenden, um Daten nur bei Bedarf abzurufen, anstatt alles auf einmal einzuspeichern.

Die zweite Strategie ist die Kompression und das Entfernen des Kontexts. Wenn die Unterhaltung zu lang wird, wird eine Zusammenfassung erstellt, um Token - Platz für die nachfolgenden Tool - Ergebnisse freizumachen. Um einen Kontext - Überlauf zu vermeiden, hat Anthropic eine Schiebefenster - Strategie festgelegt, die nur die letzten N Runden der Unterhaltung beibehält und frühere Runden durch Zusammenfassungen ersetzt. Gleichzeitig lässt es den Agenten einen strukturierten Arbeitsnotizbereich im Kontext verwalten, um die Informationen in langen Unterhaltungen nicht zu verlieren. Dann werden auch die nutzlosen Teile der Tool - Rückgabedaten direkt gelöscht, um sie nicht als unnötige Last im Kontext zu haben.

Dies ist das Context Engineering, das sich um die Information kümmert. Es ist hauptsächlich verantwortlich für die Speicherung, den Zugriff und die Auswahl der Informationen. Es kümmert sich nicht um den Prozess. Ob der Goldfisch - Modell das Notizbuch überhaupt öffnet, ob es danach handelt und ob jemand die Arbeit überprüft, wird nicht berücksichtigt.

Diesen Unterschied hat damals noch niemand klar erkannt. Denn auch Anthropic ist in die gleiche Falle geraten.

Im November 2025 haben sie in „Effective harnesses for long - running agents“ diese Erfahrung offenbart. Im Mai 2025 wollte Anthropic, dass Claude eine vollständige Web - Anwendung von Grund auf schreibt. Es ging nicht um das Beheben eines Bugs, sondern um das Bauen eines ganzen Produkts. Solche Aufgaben dauern mehrere Stunden, und selbst mit externem Gedächtnis reicht das Kontextfenster nicht aus, um die gesamte Aufgabe aufzunehmen. Bei jedem neuen Lauf wird das Gedächtnis der vorherigen Runde gelöscht. Es ist wie bei Ingenieuren, die Schichten übernehmen, aber es gibt keine Übergabedokumente.

Anfangs haben sie nach dem Konzept des Context Engineering einen ersten Arbeitsrahmen aufgebaut. Die Vorgehensweise besteht aus zwei Schritten. Zuerst wird ein Agent eingesetzt, um die Anforderungen zu analysieren, über 200 Funktionspunkte auszuarbeiten und eine strukturierte Liste zu erstellen. Dann wird ein anderer Agent eingesetzt, um den Code zu schreiben. Er arbeitet bei jedem Lauf nur an einer Funktion, gibt sie ab und aktualisiert die Fortschrittsdatei für die nächste Runde.

Das Notizbuch wurde verteilt, das externe Gedächtnis wurde eingerichtet, und die besten Praktiken des Context Engineering wurden befolgt. Es klingt vernünftig.

Aber in der Praxis war es ein totaler Fiasko.

Sie haben festgestellt, dass es vier Fehlermuster gibt.

Erstens: Vorzeitiges Abgeben. Der Agent hat drei Funktionen implementiert und erklärt dann, dass das Projekt abgeschlossen sei. Er sah die vorhandene Code - Menge und dachte, die Arbeit sei erledigt.

Zweitens: Umweltblindheit. Der Agent schreibt tatsächlich Code, aber es gibt Bugs in der Umgebung, und er weiß nicht, dass der Code nicht funktioniert.

Drittens: Falsche Markierung der Fertigstellung. In der Funktionsliste ist eine Funktion als „erledigt“ markiert, aber die Funktion ist fehlerhaft. Der Agent hat die Unit - Tests durchgeführt und dachte, alles sei in Ordnung, aber die End - to - End - Tests funktionieren nicht.

Viertens: Das Syndrom des vergesslichen Praktikanten. Bei jedem neuen Lauf (Session) verbraucht der Agent eine große Anzahl von Tokens, um die Projektstruktur neu zu erlernen, wie ein neuer Praktikant, der ständig fragt, wo der Code liegt.

Also haben sie festgestellt, dass das Notizbuch des Context Engineering nur das Problem des fehlenden Speicherns löst. Aber die Probleme des Goldfisch - Modells gehen weit über das hinaus. Manchmal öffnet es das Notizbuch nicht, und wenn es es öffnet, folgt es nicht den Anweisungen. Außerdem fehlt es an der Fähigkeit zur Selbstüberprüfung.

Das Notizbuch ist kein Problem. Das Problem ist, dass niemand das Goldfisch - Modell zwingt, es zu lesen und zu befolgen, und niemand überprüft, ob es richtig geschrieben hat.

Diese Erkenntnis hat Anthropic dazu gebracht, von der Herstellung eines besseren Notizbuchs zur Schaffung eines ganzen Management - Systems umzuschwenken, das die strikte Einhaltung des Arbeitsablaufs gewährleistet.

Um die falsche Markierung der Fertigstellung und das vorzeitige Abgeben zu verhindern, hat Anthropic erkannt, dass man nicht nur auf die externe Speicherung in Markdown - Format setzen kann, und dass der Agent nicht gleichzeitig Athlet und Manager sein darf. Zu Beginn eines Projekts erstellt ein spezieller „Initialisierungs - Agent“ eine vollständige Funktionsliste in JSON - Struktur (ein maschinenlesbares Datenformat). Es ist so konzipiert, dass der „Codierungs - Agent“, der die eigentliche Arbeit erledigt, nur ein Feld markieren kann, um anzugeben, ob die Funktion „bestanden“ oder „nicht bestanden“ ist. Man kann die Funktionen nicht löschen oder die Beschreibung ändern, sondern nur den Status markieren. Und das JSON - Format besagt, dass der Agent den Status erst auf „bestanden“ setzen darf, wenn er die Tests tatsächlich bestanden hat, und nicht einfach, weil es „ungefähr okay“ aussieht.

In dieser Einstellung wird das JSON, das der Aufgabensteller verwendet, zu einer Anti - Betrugs - Sperre. Durch die strenge Prüfung dieser Daten wird der Fortschrittsbalken festgehalten. Die Markdown - Dateien existieren weiterhin, aber sie dienen hauptsächlich als Wegweiser, nicht als strenger Arbeitsablauf. (Dies ist auch einer der Gründe, warum die Skills nicht so gut funktionieren.)

Um das Syndrom des vergesslichen Praktikanten zu bekämpfen, wird zu Beginn jeder Session ein dreistufiges Aufweckritual durchgeführt. Es wird pwd (Bestätigung des aktuellen Verzeichnisses) ausgeführt, git log (Anzeige der Code - Änderungshistorie) gelesen und progress.txt (Anzeige der nächsten Aufgabe) gelesen. Es ist wie bei der Schichtübergabe in einer Fabrik, wo der nächste Arbeiter zuerst das Übergabebuch liest. Das Gedächtnis des Agenten liegt nicht in seinem eigenen Kopf, sondern in der Git - Historie und der Fortschrittsdatei. Wenn man nicht darauf vertraut, dass der Agent sich erinnert, hilft man ihm systematischer, sein Gedächtnis extern zu speichern und ihn zu zwingen, zuerst anzumelden, das Übergabebuch zu lesen und seinen Arbeitsplatz zu bestätigen.

Der Effekt war unmittelbar. Der Agent konnte nun mehrere Stunden lang laufen. Bei jedem Lauf wurde nur eine Aufgabe erledigt, und der Status wurde in die Fortschrittsdatei geschrieben. Bei der nächsten Runde liest er die neueste progress.txt und weiß, was er tun muss.

Anthropic hat noch eine zusätzliche Sicherung eingeführt. Jede Code - Änderung wird über Git archiviert. Wenn das Modell in eine Sackgasse gerät, wird der Code - Repository mit git revert auf den letzten funktionierenden Zustand zurückgesetzt, und das Modell wird neu gestartet. Man erwartet nicht, dass das Goldfisch - Modell seine Fehler rückgängig macht. Man gibt ihm einfach eine Zeitmaschine.