Was eine 10-minütige Erstellung eines Agenten über die wahre Architektur verrät

Was die Arbeit mit LangGraph, Deep Agents und TrueForge über Abstraktion, Steuerung sowie das tatsächliche Verhalten von Agenten aufgezeigt hat.

Beim Aufbau von DEVIN ging ein großer Teil der Anstrengungen in Arbeiten, die nicht sichtbar werden, wenn jemand einfach einen KI-Agenten verwendet.

Die Verkabelung von Deep Agents.

Die Konfiguration von Daytona als Sandbox-Umgebung.

Die Verwendung von Ingest zur Handhabung von Streaming und Hintergrundausführungen.

Das Zusammenbringen all dieser Komponenten, damit sie zusammenarbeiten.

Der Fortschritt war langsam.

Aber irgendwann im Zuge dieser Arbeit zeichnete sich ein klareres Bild davon ab, was eigentlich einen Agentensystem ausmacht.

Nicht nur das Modell selbst.

Alles, was es umgibt.

Die Laufzeitumgebung.

Die Tools.

Die Sandbox.

Die Orchestrierungsschicht.

Die Art und Weise, wie die Agenten miteinander kommunizieren und Aufgaben weitergeben.

Dann kam ein Hackathon, und damit auch TrueForge.

Bereits fast sofort wurde deutlich, wie viel von der Infrastruktur, die mühsam von Hand aufgebaut worden war, stattdessen an eine Plattform übertragen werden konnte.

Es dauerte nicht länger als etwa zehn Minuten, einen funktionsfähigen Agenten zusammenzustellen: Die relevanten MCPs anzuschließen, die notwendigen Tools hinzuzufügen, eine SKILL.md-Datei zu erstellen, in der das Verhalten beschrieben wird, und ihn anschließend einfach auszuführen.

Nach all der Zeit, die mit dem Aufbau von Infrastruktur von Grund auf verbracht worden war, erschien das fast zu einfach.

Ehrlich gesagt war es beeindruckend.

Genau so sollte sich gute Abstraktion anfühlen.

Doch der Kompromiss, der hinter dieser Einfachheit steckte, war noch nicht offensichtlich.

Der 10-minütige Agent

Die erste Reaktion war reine Bewunderung dafür, wie mühelos der Prozess ablief.

TrueForge kümmerte sich um die zugrundeliegende Infrastruktur und überließ die Hauptaufgabe, zu beschreiben, was der Agent tatsächlich tun sollte, der Definition der Fähigkeit.

Das ist eine wirklich starke Abstraktion.

Die hinzugefügten MCPs waren sichtbar.

Die Tools waren sichtbar.

Die Datei SKILL.md war sichtbar.

Alles wirkte verständlich und leicht zu durchdenken.

Deshalb blieb die Gewohnheit, darauf zurückzugreifen, bestehen.

Nur durch kontinuierliche Nutzung tauchte ein subtileres Problem auf, eines, das während des Hackathons selbst nicht bemerkt worden war.

Die Sorge galt nicht dem Was überprüft werden kann.

Die Sorge galt dem Wo die eigentliche Architektur liegt.

Eine Fähigkeit für sich allein ist keine Architektur

Der Root-Agent liest die Fähigkeitsdatei und verwendet sie, um zu entscheiden, wie er die ihm übergebenen Fähigkeiten anwenden soll – einschließlich der Art und des Zeitpunkts, zu dem Sub-Agenten erstellt werden.

Das bedeutet, dass eine einzige SKILL.md-Datei stillschweigend einen großen Teil der Verhaltensstruktur des Agents definieren kann.

Stellen Sie sich vor, Sie möchten etwas Ähnliches erstellen:

                    Root Agent
                   /          \
                  /            \
            Researcher        Coder
                /                \
               /                  \
          Searcher              Tester

Einfach dem Root-Agenten mitzuteilen: „Hier sind Ihre Werkzeuge – erstellen Sie die benötigten Sub-Agenten und kümmern Sie sich darum“, ist nicht dasselbe wie das Entwerfen des Systems.

Wichtig ist vielmehr die direkte Definition der Architektur:

• welche Agenten vorhanden sind
• für was jeder einzelne zuständig ist
• welche Werkzeuge an welchen Agenten gehen
• welchen Kontext jeder Agent erhält
• wann Delegation stattfinden sollte
• wie der Wiederherstellungsprozess nach einem Fehler aussieht

Das ist der Unterschied, der zunehmend auffiel.

Beim Einsatz des Deep Agents-Ansatzes wird die Architektur absichtlich von einem selbst konstruiert.

Bei TrueForge ist die Infrastruktur deutlich einfacher, doch die Verhaltensarchitektur hängt davon ab, ob der Root-Agent die Fähigkeit genau so interpretiert, wie man es beabsichtigt hat.

Diese Abhängigkeit bindet das Verhalten des gesamten Systems viel enger an das zugrunde liegende Modell.

Ein leistungsstärkeres Modell könnte die Fähigkeit genau so auswerten, wie es vorgesehen ist.

Ein schwächeres Modell könnte bei denselben Anweisungen einen völlig anderen Weg einschlagen.

Dieselbe Fähigkeitsdatei.

Dieselben Tools.

Anderses Ergebnisverhalten.

Die Architektur auf dem Papier hat sich nicht geändert.

Nur die Interpretation dieser Architektur durch das Modell hat sich geändert.

Dieser Mangel machte es schwierig, diesem Ansatz vollständig zu vertrauen.

Die Arbeit an AEGIS verstärkte diese Sorge

Beim Aufbau von AEGIS stieß das Team auf ein einfaches, aber aufschlussreiches Problem.

Der Agent sollte Fälle von Blockaden im Node.js-Event-Loop untersuchen.

Dafür musste er Code prüfen, das Problem nachstellen, das Laufzeitverhalten messen, die Ursache diagnostizieren, eine Lösung vorschlagen und bestätigen, dass die Lösung tatsächlich funktionierte.

Zu Beginn bestand die Überprüfungsphase hauptsächlich aus einer Anweisung an das Modell, was es tun sollte, etwa in folgendem Sinne:

Führen Sie das Experiment durch, vergleichen Sie die erzielten Metriken und beurteilen Sie, ob die Lösung das Problem tatsächlich gelöst hat.

Doch es zählt eigentlich nicht als Überprüfung, wenn ein LLM selbst entscheiden soll, ob sein eigener Patch erfolgreich war.

Daher wurde der deterministische Teil dieser Logik in den Code statt in den Prompt-Text verlegt.

Das Modell führt die Überlegungen durch.

Das System führt die Messung durch.

Der Überprüfer trifft die Entscheidung.

Diese Erfahrung führte zu einem Prinzip, das heute weitgehend auf die Konzeption von Agenten angewandt wird:

Falls etwas nicht beobachtet werden kann, lässt es sich nicht ordnungsgemäß testen. Wenn es nicht getestet werden kann, lässt es sich nicht bewerten. Und wenn es nicht bewertet werden kann, lässt es sich nicht zuverlässig verbessern.

Deshalb ist Architektur so wichtig.

Nicht weil ein Diagramm mit mehr Kästen und Pfeilen per se überlegen ist.

Sondern weil man eine klare Erklärung dafür benötigt, was das Verhalten hervorgerufen hat, das man verbessern möchte.

„Es funktioniert“ versus „Ich verstehe, warum es funktioniert“

Zwei verschiedene Agenten können beide technisch gesehen erfolgreich sein.

Sie können beide die zugewiesene Aufgabe erledigen.

Sie können beide in einer Live-Demonstration hervorragend aussehen.

Die eigentliche Prüfung kommt dann, wenn etwas schiefgeht.

Bei einer Art von Agent ist es möglich, den genauen Ausführungspfad nachzuvollziehen:

Root Agent
    ↓
Researcher
    ↓
Search Tool
    ↓
Result
    ↓
Root Agent
    ↓
Coder
    ↓
Sandbox

Jeder Entscheidungspunkt kann untersucht und hinterfragt werden:

Warum ist dieser spezielle Schritt erfolgt?

Bei einer anderen Art von Agent gibt es nur eine Beschreibung der gewünschten Ergebnisse, während das Modell den Weg selbst herausfindet.

Wenn das funktioniert, wirkt es erstaunlich einfach.

Fällt es jedoch fehl, wird die Frage zur Fehlerbehebung viel schwieriger zu beantworten:

Wurde der Fehler durch das Modell, die Anweisung, die Delegationslogik, den bereitgestellten Kontext oder die von dem Modell selbst improvisierte Architektur verursacht?

Dieses zweite Szenario ist ein weitaus schwierigeres Problem, das zu lösen ist.

Und genau das hat TrueForge gelehrt

Vor dem Umgang mit der Plattform geht man davon aus, dass der schwierige Teil beim Erstellen von Agenten ausschließlich in der Infrastruktursschicht liegt.

Durch die Arbeit damit ändert sich diese Sichtweise. Die Infrastruktur stellt sich als nur die Hälfte der Herausforderung heraus.

Die Infrastruktur ist etwas, das man abstrahieren kann.

Das Verhalten widersteht der Abstraktion.

Eine Plattform kann einen Sandbox zur Verfügung stellen.

Sie kann MCP bereitstellen.

Sie kann Streaming bereitstellen.

Sie kann die gesamte Laufzeitumgebung bereitstellen.

Doch wenn man einen Agenten entwickelt, dessen Aktionen tatsächlich Bedeutung haben, muss man trotzdem selbst einige Fragen beantworten:

Welcher Komponente obliegen welche Entscheidungen?

Was ist wofür erlaubt?

Wo genau findet die Delegation statt?

Welche Sicht haben Sie auf den Prozess?

Was können Sie tatsächlich messen oder bewerten?

Welche Hebel gibt es, um Probleme zu beheben, wenn sie auftreten?

Das sind die Aspekte, die man nicht einfach so weitergeben sollte, ohne zweimal nachzudenken.

Wie lange dauert es, herauszufinden, warum etwas fehlgeschlagen ist?

Einen Agenten in zehn Minuten zusammenzustellen, ist tatsächlich eine beeindruckende Leistung.

Aber eine nützlichere Frage wird wichtiger als diese Geschwindigkeit:

Wie lange dauert es, herauszufinden, warum etwas fehlgeschlagen ist?

Produktionsumgebungen belohnen keine erfolgreiche erste Demonstration.

Was sie bestrafen, ist der zehnte Misserfolg.

Das Tool, das unerwartete Ergebnisse liefert.

Das schwächere zugrunde liegende Modell.

Der Agent, der die Arbeit zu früh weitergibt.

Der Agent, der die Arbeit zu spät weitergibt.

Der Agent, der „Erledigt“ ankündigt

während eigentlich nichts erreicht wurde.

Darin zeigt sich genau, wofür Architekturen nützlich sind.

Was tatsächlich gelernt wurde

Beim Rückblick auf das DEVIN-Projekt war die eigentliche Erkenntnis nicht das Beherrschen von Deep Agents, Daytona oder Ingest als eigenständige Tools.

Sondern das Verstehen der Weise, wie die Komponenten eines Agentensystems miteinander verbunden sind.

TrueForge zeigte anschließend, wie schnell diese gleichen Komponenten aus dem Blickfeld abstrahiert werden können.

Doch ihre Verwendung machte auch die andere Seite dieser Bequemlichkeit sichtbar:

Die Infrastruktur kann aus einem Workflow verschwinden, ohne dass das Verhalten gleichzeitig verschwindet.

Jemand muss trotzdem dieses Verhalten steuern.

Jemand muss es noch in Aktion beobachten.

Jemand muss noch bewerten, ob es funktioniert.

Und jemand muss noch entscheiden, was geändert wird, falls es versagt.

Diese Verantwortung ist eine, die man selbst übernehmen sollte, anstatt sie auszulagern.

Wohin die Agentenarchitektur steuert

Diese Erfahrung verändert auch die Art und Weise, wie der Entwicklungsverlauf von agilen Systemen im weiteren Sinne verstanden werden kann.

Das Feld hat verschiedene Phasen durchlaufen:

Modelle → Werkzeuge → MCP → Agenten → tiefe Agenten

Und in jeder Phase wird die zugrundeliegende Infrastruktur einfacher zu beschaffen.

Die wichtigste Schicht für die Zukunft ist aus dieser Sicht die Harness-Struktur um das Modell herum.

Nicht nur die rohen Fähigkeiten des Modells, sondern auch das System, das es mit den notwendigen Ressourcen versorgt:

Kontext, Werkzeuge, Ausführung, Berechtigungen, Orchestrierung, Speicher, Beobachtbarkeit, Bewertung und Steuerung.

Sobald sich die Modelle weiterentwickeln, wird allein die Rohqualität des Modells nicht mehr der entscheidende Faktor sein.

Die wichtige ingenieurtechnische Frage wird zunehmend lauten:

Welche Umgebung wurde um das Modell herum aufgebaut, und inwieweit lässt sich sein Verhalten steuern?

Das ist wohl die zentrale Lehre aus der Entwicklung von DEVIN sowie dem späteren Zusammenbau eines Agenten in zehn Minuten.

Je einfacher es wird, einen Agenten zu erstellen, desto wichtiger wird es, alles um ihn herum zu verstehen.