00:00:00Vielen Dank an HubSpot für das Sponsoring dieses Videos.
00:00:03Im Dezember 2025 ist tatsächlich etwas wirklich Großes passiert.
00:00:07Und die meisten Leute haben es nicht einmal bemerkt.
00:00:09Andrew Cupsey hat letzte Woche darüber getwittert.
00:00:10„Es ist schwer zu vermitteln, wie sehr sich das Programmieren durch KI in den letzten zwei Monaten verändert hat,
00:00:15insbesondere seit letztem Dezember."
00:00:17Und auch Greg von OpenAI hat darüber gesprochen.
00:00:20Seit Dezember gibt es sprunghafte Verbesserungen bei den Fähigkeiten des Modells und der Tools.
00:00:24Einige Ingenieure erzählten ihm, dass sich ihr Job seit Dezember 2025
00:00:28grundlegend verändert hat.
00:00:29Was ist also im Dezember 2025 eigentlich passiert?
00:00:32Kurz gesagt: Das neueste Modell, das damals eingeführt wurde, ist endlich bereit für vollautonome,
00:00:37lang laufende Aufgaben.
00:00:38Bei KI war der ultimative Traum schon immer, dass die KI vollautonom rund um die Uhr arbeiten kann,
00:00:43während wir schlafen.
00:00:46Sogar im Jahr 2023 hieß das bekannteste Projekt, falls Sie sich erinnern, AutoGPT.
00:00:50Damals wurden diese vollautonomen Agentensysteme zum ersten Mal vorgestellt.
00:00:54Sie hatten eine recht einfache Architektur, die GPT-4 als Modell nutzte, um Aufgaben basierend auf dem Nutzerziel
00:00:59selbstständig zu zerlegen, und einen einfachen Speicher besaß,
00:01:03um die Ergebnisse zu sichern.
00:01:04Die Leute haben ziemlich verrückte Dinge ausprobiert, wie zum Beispiel das Ziel vorzugeben, 100.000 Dollar zu verdienen,
00:01:08und die KI die Aufgaben endlos wiederholen zu lassen, bis das Ziel erreicht ist.
00:01:11Damals scheiterte das System kläglich, weil das Modell einfach noch nicht bereit war.
00:01:15Aber seit letztem Dezember hat sich das wirklich geändert.
00:01:18Die Modelle haben eine deutlich höhere Qualität, langfristige Kohärenz und können
00:01:22viel größere und längere Aufgaben bewältigen.
00:01:24Und wir haben alle möglichen Experimente aus der Branche gesehen.
00:01:28Zuerst gab es ab Januar dieses brandheiße Konzept namens „Rough Loop“ – eine sehr einfache
00:01:33Agenten-Iterationsschleife, um das Modell zu zwingen, länger zu arbeiten,
00:01:37damit es komplexere Aufgaben bewältigen kann.
00:01:38Wir haben das Modell einfach mit ein paar einfachen Bedingungsprüfungen in eine Schleife geschickt, aber wir sahen bereits
00:01:42den Unterschied.
00:01:43Und eine Woche später veröffentlichte Cursor ein Experiment, bei dem sie GPT-5.2 nutzten,
00:01:49um autonom einen Browser mit 3 Millionen Zeilen Code von Grund auf zu erstellen.
00:01:52Anthropic veröffentlichte ebenfalls ein Experiment, bei dem ein Team von „Cloud Codes“
00:01:57zwei Wochen lang autonom an einem C-Compiler von Grund auf arbeitete.
00:02:01Am Ende lieferten sie eine funktionale Version ohne jegliche manuelle Codierung ab.
00:02:05Man kann darin sogar das Spiel Doom ausführen.
00:02:08Gleichzeitig begann OpenClaw Aufmerksamkeit zu erregen und erlebte ein explosives Wachstum,
00:02:13wie wir es noch nie zuvor gesehen hatten.
00:02:14Es war schwer zu verstehen, was bei OpenClaw vorging, denn von außen betrachtet
00:02:18könnte man es leicht als ein weiteres Programm abstempeln, das auf dem Computer lebt
00:02:23und auf das man auch über Telegram zugreifen kann.
00:02:27Warum also ist das so populär?
00:02:29Erst nachdem ich es intensiv genutzt habe, wurde mir klar, dass der wahre Unterschied darin liegt, dass OpenClaw
00:02:35diesen Typ von immer aktiven, lang laufenden und vollautonomen Agenten repräsentiert.
00:02:40Das unterscheidet sich stark von früheren Systemen, bei denen der Mensch der Haupttreiber war,
00:02:45der den nächsten Schritt anstoßen musste.
00:02:46OpenClaw ist immer an und agiert proaktiv.
00:02:49Dieses autonome Gefühl entsteht durch eine recht einfache Architektur mit einer
00:02:53Speicher-Kontext-Ebene, Triggern und Cron-Jobs, um automatisch Aktionen auszuführen,
00:02:58und vollem Computerzugriff – eine mächtige Umgebung.
00:03:02Ich glaube, OpenClaw ist das erste Projekt, das den großen Paradigmenwechsel im Jahr 2026 eingeleitet hat,
00:03:06weg von einfachen Copilot-Systemen hin zu diesen lang laufenden,
00:03:13vollautonomen Agenten.
00:03:15Etwas, das immer aktiv ist und selbstständig hochkomplexe, koordinierte Arbeit liefert.
00:03:20Das ist ein entscheidender Wandel, den man verstehen muss.
00:03:22Die heutigen Modelle sind viel leistungsfähiger als man denkt, solange man das richtige
00:03:27System entwirft, um dieses Potenzial freizusetzen.
00:03:28Und das ist der Kern dessen, worüber ich heute sprechen möchte.
00:03:30Das „Harness Engineering“, um lang laufende autonome Systeme zu ermöglichen.
00:03:34Falls Sie den Begriff „Harness Engineering“ zum ersten Mal hören: Es ist die Weiterentwicklung
00:03:38von dem, was wir bisher Context Engineering oder Prompt Engineering genannt haben.
00:03:41Bisher haben wir uns darauf konzentriert, die Prompts innerhalb des Kontextfensters zu optimieren,
00:03:46um die beste Leistung für eine einzelne Sitzung zu erzielen.
00:03:49Beim Harness Engineering geht es jedoch um lang laufende Aufgaben, also darum,
00:03:53ein System zu entwerfen, das über verschiedene Sitzungen und mehrere Agenten hinweg funktioniert.
00:03:57Wie gestaltet man den Workflow so, dass für jede Sitzung der relevante Kontext abgerufen wird
00:04:01und die richtigen Werkzeuge bereitstehen, um das Maximum aus den Modellen herauszuholen?
00:04:05Das ist ein recht neues Konzept, aber das Gute ist, dass sich die Branche bereits
00:04:09auf einige Best Practices von Anthropic, Vercel, LangChain und vielen anderen geeinigt hat.
00:04:14Wir werden diese nacheinander durchgehen, damit Sie die Muster erkennen können.
00:04:16Doch bevor wir eintauchen: Mit diesem Wechsel zu autonomen Agenten liegt eine der größten
00:04:21Chancen der nächsten 6 bis 12 Monate darin, ein „OpenClaw“ für eine bestimmte Branche zu bauen.
00:04:25Das bedeutet, den End-to-End-Workflow eines bestimmten Sektors tiefgreifend zu verstehen
00:04:29und einen autonomen Agenten mit der passenden Umgebung zu entwickeln, der den Prozess komplett übernimmt.
00:04:34Deshalb möchte ich Ihnen diese großartige Studie von HubSpot über die
00:04:39KI-Adoption im E-Mail-Marketing vorstellen.
00:04:40Es ist ein faszinierender Bericht, um zu verstehen, wo Menschen in einer Branche wie dem E-Mail-Marketing
00:04:44heute tatsächlich KI einsetzen und wo noch Lücken klaffen.
00:04:47Dieser Bericht zeigt klare Workflows und Möglichkeiten im E-Mail-Marketing auf,
00:04:51die man potenziell automatisieren kann.
00:04:52Es wurden Hunderte von E-Mail-Marketern aus Top-Unternehmen befragt, um genau zu verstehen, wie KI
00:04:57ihre Arbeitsabläufe verändert.
00:04:58Es wird thematisiert, warum Marketer immer noch viel manuell nachbearbeiten,
00:05:03woran das liegt und welches die größten Herausforderungen bei der Implementierung von KI
00:05:06im E-Mail-Marketing sind.
00:05:07Jede dieser Herausforderungen ist eine Chance für Sie, einen vollautonomen Agenten zu bauen.
00:05:11Der Bericht geht sogar auf spezifische KPIs ein, die besonders wichtig sind und bei denen KI
00:05:15nachweislich Ergebnisse geliefert hat.
00:05:16Sowie darauf, was genau E-Mail-Marketer sich wirklich von der KI wünschen.
00:05:20Wenn Sie also ein Entwickler sind, der über das nächste große Agenten-Produkt nachdenkt,
00:05:24kann ich Ihnen diese Ressource nur wärmstens empfehlen.
00:05:27Ich habe den Link zum kostenlosen Download in die Beschreibung gepackt.
00:05:30Und danke an HubSpot für das Sponsoring dieses Videos.
00:05:32Kommen wir zurück zum Harness Engineering für lang laufende Agentensysteme.
00:05:36Es gibt im Wesentlichen drei Erkenntnisse, die ich daraus mitgenommen habe.
00:05:39Erstens: Für lang laufende Agenten ist der entscheidende Teil des Systemdesigns die Schaffung
00:05:44einer „lesbaren Umgebung“, in der jeder Sub-Agent oder jede Sitzung genau versteht,
00:05:49wie der aktuelle Stand ist.
00:05:50Es gibt wahrscheinlich Workflows, die man nutzen kann, um die Lesbarkeit der Umgebung zu erzwingen.
00:05:54Das werde ich gleich noch näher erläutern.
00:05:56Zweitens ist die Verifizierung entscheidend.
00:05:58Sie können die Systemausgabe erheblich verbessern, indem Sie dem System ermöglichen,
00:06:03seine Arbeit durch schnellere Feedbackschleifen effektiv zu überprüfen.
00:06:04Und drittens müssen wir dem Modell mehr vertrauen, anstatt spezialisierte Werkzeuge zu bauen,
00:06:08die zu viel Logik und Reasoning vorzeitig vorwegnehmen.
00:06:11Wir sollten dem Modell maximalen Kontext mit generischen Werkzeugen geben, die es nativ versteht,
00:06:16und es wie einen Menschen explorieren lassen.
00:06:17Ich werde diese drei Punkte nun einzeln aufschlüsseln.
00:06:20Zuerst Anthropics Blogbeitrag über effektive Strukturen für lang laufende Agenten.
00:06:24Sie haben mit dem Cloud Code SDK experimentiert, um einen spezialisierten Agenten für extrem
00:06:29lang laufende Aufgaben zu bauen, wie zum Beispiel den Klon der Website cloud.ai.
00:06:32Die ersten Misserfolge, die sie beobachteten, waren erstens: Agenten neigen dazu, zu viel auf einmal zu wollen.
00:06:37Im Grunde versuchen sie immer, die gesamte App in einem Rutsch zu erledigen.
00:06:40Das führte dazu, dass dem Modell mitten in der Implementierung der Kontext ausging
00:06:45und die nächste Sitzung mit einer halb fertigen oder schlecht dokumentierten Funktion beginnen musste.
00:06:49Der Agent musste dann raten, was eigentlich passiert war, und verbrachte viel Zeit damit,
00:06:52die Basis-App überhaupt wieder zum Laufen zu bringen.
00:06:55Der zweite Fehler war, dass Agenten dazu neigen, Aufgaben vorzeitig als erledigt zu markieren.
00:07:00Das haben Sie wahrscheinlich selbst auch schon erlebt.
00:07:02Das Tool behauptet dann einfach, das Projekt oder die Funktion sei fertig.
00:07:05Aber sobald man es testet, merkt man, dass es gar nicht funktioniert.
00:07:07Ihre Lösung für dieses Standard-Fehlverhalten des Modells war erstens, eine initiale
00:07:12Umgebung aufzubauen, die das Fundament für alle geforderten Funktionen legt.
00:07:16Das bringt den Agenten dazu, Schritt für Schritt und Funktion für Funktion vorzugehen.
00:07:20Das ähnelt dem Planungs- oder PRD-Ansatz, den wir normalerweise verfolgen.
00:07:23Zweitens begannen sie, jeden Agenten so zu instruieren, dass er inkrementelle Fortschritte macht
00:07:27und die Umgebung am Ende jeder Sitzung in einem sauberen Zustand hinterlässt.
00:07:32Dafür entwickelten sie eine zweiteilige Lösung.
00:07:35Sie nutzen einen „Initializer Agent“, der das Modell über einen speziellen Prompt auffordert,
00:07:40die Startumgebung mit einem „init.sh“-Skript einzurichten, das zum Beispiel den Dev-Server startet,
00:07:45damit sich das nächste Modell nicht mehr darum kümmern muss.
00:07:48Außerdem gibt es eine Datei namens „cloud progress.txt“, die protokolliert, was der Agent getan hat,
00:07:53sowie einen initialen Git-Commit, der zeigt, welche Dateien hinzugefügt wurden.
00:07:55Danach wird für jede weitere Sitzung ein „Coding Agent“ eingesetzt, der inkrementelle Fortschritte macht
00:08:01und strukturierte Updates hinterlässt.
00:08:02All diese Bemühungen dienen dem Zweck, eine Umgebung zu definieren,
00:08:07in der Agenten den Arbeitsstand sofort verstehen können, wenn sie mit einem frischen
00:08:11Kontextfenster starten.
00:08:13Der Workflow sieht so aus: Der Initializer Agent versucht zuerst, eine Umgebung oder
00:08:17ein Dokumentationssystem einzurichten, um den Gesamtplan zu verfolgen.
00:08:21Dazu gehört erstens ein Dokument mit einer Liste aller Funktionen, um zu verhindern,
00:08:25dass der Agent alles auf einmal probiert oder das Projekt voreilig als beendet ansieht.
00:08:30Der Initializer Agent bricht das Projekt in über 200 Einzelfunktionen auf
00:08:34und protokolliert diese in einer lokalen JSON-Datei, die etwa so aussieht, wobei jede Aufgabe
00:08:39eine detaillierte Spezifikation sowie einen Status (bestanden/fehlgeschlagen) hat.
00:08:41Standardmäßig sind alle Aufgaben als fehlgeschlagen markiert.
00:08:43Das zwingt das Modell, immer auf das Gesamtziel und den Fortschritt zu schauen,
00:08:49die wichtigste Aufgabe auszuwählen und den nächsten Schritt zu machen.
00:08:50Damit dieser Workflow funktioniert, müssen sie das Modell auch dazu bringen, die Umgebung
00:08:55nach Codeänderungen sauber zu hinterlassen. In ihren Experimenten fanden sie heraus,
00:08:59dass der beste Weg darin besteht, das Modell aufzufordern, Fortschritte mit einer aussagekräftigen
00:09:05Commit-Nachricht in Git zu speichern und eine Zusammenfassung in der Progress-Datei zu schreiben.
00:09:08Aber Dokumentation und Kontext allein reichen nicht aus, da Modelle dazu neigen,
00:09:13Dinge ohne richtige Tests als erledigt zu markieren. Anfangs haben sie den Code
00:09:17einfach dazu aufgefordert, nach Änderungen Unit-Tests oder API-Tests
00:09:22für den Dev-Server durchzuführen.
00:09:23Das reichte oft nicht aus, um zu erkennen, ob eine Funktion wirklich durchgängig funktioniert.
00:09:27Die Dinge änderte sich erst grundlegend, als sie dem Modell die richtigen Werkzeuge gaben,
00:09:30um End-to-End-Tests selbst durchzuführen – etwa Puppeteer oder Chrome DevTools.
00:09:35Damit konnte der Agent Fehler finden und beheben, die im Code allein nicht offensichtlich waren.
00:09:39Im Grunde bauen sie also eine Struktur auf, in der der Initializer Agent das Nutzerziel
00:09:43in eine Liste von Funktionen zerlegt, ergänzt durch „init.sh“ zum Starten des Dev-Servers
00:09:47und Progress-Dateien.
00:09:49Der nächste Coding Agent kann dann einfach die Feature-Liste lesen, um den Gesamtplan zu verstehen,
00:09:53die wichtigste Aufgabe auswählen und in der Progress-Datei nachsehen,
00:09:57wie der Stand der Dinge ist.
00:09:59Dann startet er „init.sh“, um sofort den Dev-Server zu haben, und führt End-to-End-Tests durch,
00:10:04um sicherzustellen, dass die Umgebung sauber ist. Das ermöglicht ein klares Bild
00:10:09und schnelle Feedbackschleifen trotz neuer Sitzungen und Kontextfenster.
00:10:10Im Blog von OpenAI liest man über sehr ähnliche Ansätze.
00:10:13Man muss sicherstellen, dass die Anwendungsumgebung lesbar ist.
00:10:16Sie machen das gesamte Repository zum Wissensspeicher oder System.
00:10:19Zuerst versuchten sie es mit einer riesigen „agents.md“-Datei, was erwartungsgemäß scheiterte,
00:10:23da es einfach zu viel Kontext für einen Agenten war.
00:10:27Also entwarfen sie eine richtige Dokumentationsstruktur und nutzten „agents.md“ nur als
00:10:32Inhaltsverzeichnis.
00:10:33Sie bauten ein System auf, das von Architektur und Design-Docs bis hin zu Ausführungsplänen,
00:10:37DB-Schemas, Produktspezifikationen, Frontend-Plänen und Sicherheit alles abdeckte,
00:10:42und verknüpften dies in der „agents.md“, sodass der Agent bei Bedarf gezielt Informationen
00:10:47abrufen konnte.
00:10:49Das ermöglicht eine schrittweise Offenlegung von Informationen, und OpenAI geht sogar noch weiter.
00:10:53Sie versuchen, nicht nur das Codewissen, sondern auch Google Docs, Slack-Nachrichten und andere
00:10:58fragmentierte Informationen in das Repository einzuspielen,
00:11:03als lokale Artefakte.
00:11:04So kann der Agent auch darauf zugreifen. Denn aus der Sicht des Agenten existiert nichts,
00:11:09auf das er in seiner Umgebung nicht zugreifen kann.
00:11:11Aber Dokumentation allein hält eine von Agenten generierte Codebasis nicht konsistent.
00:11:16Sie führten auch bestimmte programmatische Workflows ein, um Regeln zu erzwingen.
00:11:20Zum Beispiel unterteilten sie die Architektur in Domänen mit klaren Grenzen,
00:11:25was es ihnen ermöglichte, Regeln durch Custom-Checks, Linter und Struktur-Tests zu erzwingen,
00:11:29die automatisch bei jedem Git-Pre-Commit ausgelöst werden.
00:11:33Solch eine Architektur führt man in klassischen Firmen normalerweise erst ein, wenn man Hunderte Ingenieure hat,
00:11:37aber für Coding-Agenten ist das eine frühe Voraussetzung.
00:11:41Innerhalb dieser Grenzen gewährt man den Teams und Agenten große Freiheit bei der Lösungssuche,
00:11:46ohne sie mikrozumanagen oder Angst vor einer abweichenden Architektur haben zu müssen.
00:11:49Gleichzeitig verbesserten sie die Codebasis erheblich.
00:11:52Sie machten die App zum Beispiel pro Git-Worktree startfähig, sodass der Agent einfach
00:11:55viele verschiedene Instanzen starten konnte.
00:11:57Zudem binden sie das Chrome-Dev-Protokoll in die Laufzeit des Agenten ein, damit dieser
00:12:01Fehler reproduzieren und Korrekturen via DOM-Snapshots und Screenshots validieren kann.
00:12:05Mit diesem Setup erreichte das Repository schließlich die Schwelle,
00:12:09an der Agenten eine neue Funktion komplett eigenständig umsetzen konnten.
00:12:13Jedes Mal, wenn der Agent einen Prompt erhält, validiert er den aktuellen Stand des Codes,
00:12:17reproduziert einen gemeldeten Fehler und nimmt ein Video auf, um das Scheitern zu zeigen.
00:12:21Dann implementiert er den Fix, validiert ihn durch die App, nimmt ein zweites Video zur Bestätigung
00:12:25der Lösung auf und mergt schließlich die Änderung.
00:12:29Diese beiden Beispiele zeigen wertvolle Erkenntnisse und die notwendigen Strukturen,
00:12:32die man für ein vollautonomes System schaffen muss.
00:12:34Es gibt jedoch noch weitere Lehren.
00:12:36Oft neigen wir dazu, beim Bau von Agenten – besonders für Nischen –
00:12:40hochspezialisierte Werkzeuge für domänenspezifische Aufgaben zu entwickeln.
00:12:43Die Erfahrung zeigt jedoch: Große Sprachmodelle funktionieren fast immer besser mit generischen Tools,
00:12:47die sie nativ verstehen.
00:12:49Vercel veröffentlichte einen Artikel darüber, wie sie ihre „Text-to-SQL“-Agenten umgestaltet haben.
00:12:53Sie verbrachten Monate damit, ein komplexes System mit speziellen Tools,
00:12:58aufwendigem Prompt-Engineering und Kontextmanagement zu bauen.
00:13:02Wie viele von uns schon erfahren haben, funktionierte das zwar irgendwie, war aber instabil,
00:13:06langsam und wartungsintensiv.
00:13:09Bei jedem neuen Sonderfall musste man dem Agenten einen neuen Prompt hinzufügen.
00:13:12Dann probierten sie etwas aus, das alles änderte.
00:13:15Sie löschten fast alle Spezialwerkzeuge und ließen nur noch ein einziges Batch-Befehls-Tool übrig.
00:13:20Mit dieser viel einfacheren Architektur arbeitete der Agent 3,5-mal schneller,
00:13:25verbrauchte 37 % weniger Token und die Erfolgsquote stieg von 80 % auf 100 %.
00:13:30Ähnliche Erfahrungen teilte das Team von Anthropic. Sie sprachen davon,
00:13:34dass sie statt spezialisierter Such- und Ausführungswerkzeuge nur noch ein Batch-Tool nutzen,
00:13:38mit dem sie grep, tail oder npm run lint ausführen können.
00:13:41Im Grunde liegt das wohl daran, dass große Sprachmodelle viel vertrauter mit diesen
00:13:45Code-nativen Tools sind, für die es Milliarden von Trainings-Token gibt, im Vergleich zu
00:13:49maßgeschneiderten JSON-Tool-Aufrufen.
00:13:51Darüber habe ich bereits in meinem Video über programmatische Tool-Aufrufe letzte Woche gesprochen.
00:13:55Ich glaube, hier gelten ähnliche Prinzipien. Die Basis für diese einfache Architektur
00:13:59ist wieder eine gute Kontext- und Dokumentationsumgebung, in der das Modell generische Werkzeuge nutzen kann,
00:14:05um Kontext schrittweise abzurufen.
00:14:06Das ist auch bei OpenClaw der Fall.
00:14:09Ein Grund, warum OpenClaw so interessant ist, ist ihre überraschend einfache, aber effektive
00:14:13Kontext-Umgebung.
00:14:15Sie haben eine Liste von Dokumenten, um Kerninformationen zu speichern.
00:14:18Damit nutzen sie nur grundlegende Tools wie Dateien lesen, schreiben, bearbeiten, Batch-Befehle ausführen
00:14:23und Nachrichten senden.
00:14:24Der Rest kommt daher, dass dem Agenten eine Umgebung gegeben wird, um relevanten Kontext abzurufen,
00:14:29plus eine große Bibliothek an Skills, um die Fähigkeiten zu erweitern.
00:14:31Das sind also drei praktische Erkenntnisse über „Harness Engineering“ für lang laufende,
00:14:35komplexe Agenten.
00:14:36Indem man eine lesbare Kontextumgebung schafft, in der jede Sitzung effektiv Informationen abgreifen kann,
00:14:41die richtigen Workflows und Tools zur Verifizierung etabliert, schnellere Feedbackschleifen nutzt
00:14:46und dem Agenten mit generischen, nativ verständlichen Tools vertraut.
00:14:50Wenn Sie interessiert sind, werde ich noch genauer zeigen, wie ich diese Erkenntnisse
00:14:54in einen Entwicklungsprozess umsetze.
00:14:58Im AI Builder Club haben wir Kurse zu „Vibe Coding“ und dem Bau von produktionsreifen
00:15:02Agenten.
00:15:03Jede Woche teilen ich und Branchenexperten die neuesten praktischen Erfahrungen.
00:15:08Wenn Sie also lernen möchten, was ich jeden Tag lerne, klicken Sie auf den Link
00:15:12unten, um der Community beizutreten.
00:15:13Ich hoffe, Ihnen hat dieses Video gefallen.
00:15:14Vielen Dank und bis zum nächsten Mal.