langchain deep-agents ai-agents context-engineering agent-architecture

Warum Langzeit-Agenten ein Harness benötigen: Wie Deep Agents Zustand und Kontext verwalten.

Warum Langzeit-Agenten einen „Gurt“ benötigen: Wie LangChain Deep Agents den Kontextverfall mit vier Säulen, Middleware, Dateisystem-Backends und isolierten Subagenten bekämpft.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202612 Min. Lesezeit2727 Wörter

Quellen: The Deep Agents Architecture, Part 1: Understanding the Agent Harness

Die grundlegendste Agentenarchitektur besteht aus einer Schleife, die aus Aufrufen von Tools besteht. Das Modell liest die Anfrage, wählt ein Tool aus, führt es aus, liest die Ausgabe ein, wählt erneut aus und setzt dies so lange fort, bis es aufhört, Tools aufzurufen. LangChain ist ehrlich darüber, wo diese Architektur an ihre Grenzen stößt: Solche Agenten sind „flach“ und nicht in der Lage, langfristige, komplexe Aufgaben zu planen und auszuführen. Das ist kein Mangel, der einem bestimmten Framework eigen ist. Es ist vielmehr das Ergebnis davon, zwischen dem Modell und einem stetig wachsenden Kontext nichts zu lassen.

Das beste Zeichen dafür, dass die Struktur des Systems auf dem „Ceiling“ beruht, stammt von drei Teams, die nie miteinander koordiniert haben. Anthropic kam darauf, als es Claude Code entwickelte, OpenAI mit Deep Research, und Butterfly Effect so stark, dass Manus viermal neu aufgebaut werden musste. Alle kamen auf dieselben vier Komponenten: ein Planungstool, Delegation an Subagenten, Zugriff auf das Dateisystem und eine detaillierte Anweisung. Unabhängige Bemühungen von verschiedenen Unternehmen, zu derselben Architektur zu gelangen, deuten darauf hin, dass das Problem diese Struktur vorgab und nicht irgendjemandes Geschmack.

Context Rot ist das eigentliche Problem

Es ist verlockend zu behaupten, lange Laufzeiten der Agenten scheitern daran, dass das Kontextfenster voll wird. Das ist jedoch nicht die Ursache.

Ein Modell, das in einem langen Gespräch gefangen ist, trifft schlechtere Entscheidungen als dasselbe Modell in einem kurzen Gespräch – selbst dann, wenn noch der größte Teil seines Speicherraums frei ist. Die Aufmerksamkeit, die einem einzelnen Token zur Verfügung steht, nimmt mit zunehmender Anzahl der umliegenden Tokens ab, und das immer schlechter werdende Signal-Rausch-Verhältnis beeinträchtigt die Ausgabequalität bereits lange bevor der Speicherraum voll ist. Dieser Effekt ist belegt und nicht nur auf Anekdoten beruhend: Modelle holen Informationen aus der Mitte eines langen Kontexts zuverlässig schlechter ab und bevorzugen Tokens am Anfang und am Ende.

Dies verändert, wie eine Lösung aussehen müsste. Wäre die Kapazität das Problem, würde ein größerer Speicherraum es beheben. Das eigentliche Problem ist die Verdünnung: Das Modell ist zwar weiterhin fähig, doch das, was es benötigt, wird von allem, was zuvor kam, verdeckt. Das ist ein Hygieneproblem und kein Größenproblem – zusätzlicher Speicherraum hilft bei der Hygiene nicht.

Die Lücke, die weder LangChain noch LangGraph schließen sollen

LangGraph konzentriert sich auf eine zuverlässige Ausführung: Checkpoints, Streaming, menschliche Überprüfung sowie Persistenz über verschiedene Threads hinweg. Sein eigentlicher Vergleichsgegenstand ist Temporal, nicht andere Agenten-Frameworks. Es stellt sicher, dass ein Agent auch nach einem Absturz weiterhin funktioniert, sagt aber nichts darüber aus, ob der Agent nach vier Stunden noch klar denken kann. LangChain befindet sich auf einer höheren Ebene und bietet Abstraktionen wie den Tool-Aufruf-Loop, strukturierte Inhalte sowie Anpassungsmittelwerke. Dennoch ist der standardmäßig aus diesen Abstraktionen erstellte Loop der gerade beschriebene, oberflächliche Loop. Zuverlässigkeit und Abstraktion sind zwar real und notwendig, doch keines davon beantwortet die Frage, ob der Arbeitskontext des Modells sauber bleibt.

Dies lässt sich an der Verkabelung der Komponenten überprüfen. Die deklarierten Abhängigkeiten von Deep Agents lauten langchain, langchain-core, langchain-anthropic, langchain-google-genai und langsmith. LangGraph steht nicht auf der Liste. Es kommt nur deshalb vor, weil LangChain davon abhängt. Die Struktur ist streng verschachtelt: Deep Agents auf LangChain auf LangGraph – es handelt sich dabei nicht um drei eigenständige Komponenten, die zusammengesetzt werden. Weder im Laufzeitbetrieb noch in der Framework-Schicht wurde jemals für die Kontextpflege gesorgt, denn die Schicht, die dafür zuständig sein sollte, befindet sich oberhalb beider.

Die These: Ein Zustandsproblem, kein Schlussfolgerungsproblem

Komplexe Aufgaben gehören für eine bestimmte, klar definierte Klasse von Komplexität zu den Zustandsverwaltungsproblemen und nicht zu den Schlussfolgerungsproblemen.

Es gibt eine einfache Möglichkeit, herauszufinden, um welche Art von Problem es sich bei einer Aufgabe handelt. Stellen Sie sich einen fähigen Kollegen vor, der alle zehn Minuten sein gesamtes Gedächtnis verliert. Wenn dieser Kollege die Aufgabe nicht bewältigt, lag das Problem im Zustandsmanagement; Notizen, Delegation sowie eine Strukturierung, die auf dem Gedächtnisverlust beruht, können dies beheben. Wenn jedoch eine Person, die das gesamte Problem die ganze Zeit im Kopf behalten hat, trotzdem Schwierigkeiten hat, werden Notizen nichts nützen, da die Herausforderung von Anfang an im logischen Denken lag.

Jeder Mechanismus, den ein Harness hinzufügt – sei es ein Dateisystem zur Lastverteilung, Unteragenten zur Isolation oder ein Planungstool zur Fortschrittsverfolgung – befasst sich mit dem Amnesie-Fall. Keiner von ihnen macht einen einzelnen Schlussfolgerungs Schritt intelligenter. Zustandsverwaltung ist daher keine konkurrierende Erklärung zur Schlussfolgerung. Sie ist die Grundlage, die es der Schlussfolgerung ermöglicht, sich über viele Schritte hinweg aufzubauen, anstatt bei jedem Schritt neu zu beginnen. Ein Modell, das bei jedem Schritt korrekt schlussfolgert, kann bei einer zweihundert Schritte umfassenden Aufgabe trotzdem versagen, wenn Schritt 150 nicht erkennen kann, was in Schritt 12 entschieden wurde. Die Schlussfolgerung war nicht falsch – sie hatte einfach nie Kontinuität, auf der sie arbeiten konnte.

Diese Grundlage reicht an sich nicht aus, und so zu tun, als wäre sie ausreichend, würde die übrige Argumentation schwächen. An einer fehlerhaften Strategie festzuhalten, obwohl die korrekte, vollständige Historie offensichtlich vorliegt, ist ein reines Argumentationsversagen, und ein fehlerfreies Zustandsmanagement kann dies nicht beheben. Ebenso weist ein Modell, dessen eigene Wiedergabe der Ereignisse von dem abweicht, was tatsächlich geschehen ist, ein Argumentationsproblem auf – selbst dann, wenn die wahre Aufzeichnung intakt und auffindbar ist. Die korrekte Formulierung der Behauptung lautet wie folgt: Für die Fehler, auf die ein Harness abzielt, also Aufgaben, die durch das Überdauern eines sauberen Kontexts verschlechtern, ist das Zustandsmanagement der dominierende Hebel, während die Qualität der Argumentation der schwierigere Restaspekt ist, den das Scaffold nicht beeinflussen kann. Die folgenden Abschnitte beschreiben, was drei Teams entwickelt haben, um diesen Hebel in Bewegung zu setzen.

Vier Säulen mit vielen Komponenten

Was Deep Agents ist

Deep Agents wird als Open-Source-Python-Paket unter der MIT-Lizenz bereitgestellt, über pip installiert und befindet sich derzeit in Version 0.7.5. Dazu gehören eine TypeScript-Portierung, eine Terminal-CLI mit dem Namen deepagents-code sowie eine gehostete, verwaltete Version, die noch im privaten Beta-Stadium ist. Es handelt sich dabei nicht um einen Konkurrenten zu LangChain und LangGraph. Wie bereits erwähnt, ist es direkt von LangChain abhängig und erhält LangGraph nur über diesen Weg. Der Aufruf von create_deep_agent() führt schließlich zu LangChains create_agent(), wodurch ein LangGraph-Graph erstellt wird; somit erbt der Agent alle Eigenschaften bezüglich Langlebigkeit, die von LangChain übergeben werden.

Die vier Säulen und der Stack darunter

Laut LangChain sind vier Elemente notwendig, damit ein Agent tiefgründig ist: ein Planungstool, Delegation an Unteragenten, Zugriff auf das Dateisystem sowie eine ausführliche Anweisung. Harrison Chase schlug dieses Konzept vor, nachdem er die gleiche Struktur in Claude Code, Deep Research und Manus festgestellt hatte. Als mentales Modell funktioniert es gut, denn diese vier Kategorien markieren tatsächlich den Unterschied zwischen einem oberflächlichen Prozess und einem Agenten, der eine umfangreiche Aufgabe bewältigen kann.

Vier war eine anfängliche Beschreibung, nicht der endgültige Entwurf. create_deep_agent() setzt jede Fähigkeit aus einem größeren und weiter wachsenden Satz an Middleware zusammen, die frei miteinander kombiniert werden können. Die Liste umfasst Dateien, Subagenten, Zusammenfassung, Korrektur von Tool-Aufrufen, verschiedene Prompt-Caching-Varianten, die an bestimmte Anbieter gebunden sind, Speicher, Fähigkeiten sowie menschliche Genehmigung, plus jede benutzerdefinierte Schicht, die ein Entwickler schreibt. Die Säulen geben an, was der Agent tun kann. Der Middleware-Stack ist die Methode, mit der diese Fähigkeiten tatsächlich erzeugt werden, und er verändert sich ständig.

Nur zwei Komponenten des Stacks sind strukturell erforderlich, und das ist wichtiger als jede Anzahl. FilesystemMiddleware ist notwendig, weil es die Zugriffsrechte durchsetzt, die den Zugriff auf Dateien steuern – was in einem Quellkommentar als Sicherheitsgarantie bezeichnet wird. SubAgentMiddleware ist erforderlich, weil es von der task-Tool verwendet wird. Ohne eine dieser Komponenten tritt ein Fehler auf, und es kommt nicht zu einer stillen Funktionsbeeinträchtigung. Alles Weitere ist optional und wird nur auf Anfrage eingebunden.

Jeder, der jetzt darauf aufbaut, sollte wissen, dass zwei der ursprünglichen vier Kategorien nun optional sind. Ab Version v0.7.0 gehört das Planungstool (write_todos) nicht mehr zum Standardpaket, und der Basis-Systemprompt wird gemäß der Abschaffungsmitteilung leer ausgeliefert. Jedes davon erfordert eine Konfigurationszeile, um wiederhergestellt zu werden. Ein einfacher Aufruf von create_deep_agent() gewährt standardmäßig Zugriff auf Dateien und Delegation an Unteragenten und bietet Planung sowie einen detaillierten Prompt nur auf Anfrage.

Nutzen Sie Profile – die Anpassungsebene, die neuere Modelle nicht haben

Unter dem Middleware liegt ein separates Einstellmechanismus namens Harness Profile. Ein Profil fügt zusätzlichen System-Hinweistext hinzu und entfernt bestimmte Tools, die durch die genaue Modell-String-Angabe an den Agenten ausgewählt werden. Verwechseln Sie es nicht mit ProviderProfile, das bestimmt, wie das Modellobjekt konstruiert wird. Ein HarnessProfile prägt das Verhalten nach der Konstruktion.

Die Abfrage erfordert den exakt registrierten Schlüssel provider:model; falls dieser nicht vorhanden ist, dient eine gesamte Anbieterbezogene Eintragung als Ersatz. Aus der Box heraus gibt es Profile für die Codex-Familie von OpenAI sowie für drei Claude-Generationen: Haiku 4.5, Sonnet 4.6 und Opus 4.7. Das Sonnet 4.6-Profil enthält mehr als nur allgemeine Ratschläge zur Anleitung. Es folgt den von Anthropic veröffentlichten Richtlinien so genau, dass dies in den Kommentaren im Code ausdrücklich erwähnt wird, und es lässt absichtlich die für Opus bestimmten Warnungen bezüglich Überbegeisterung und intensiver Nutzung von Unteragenten aus, da diese für Sonnet als irrelevant eingestuft wurden.

Ein Modell, das eine Generation nach den registrierten Versionen veröffentlicht wird, erhält nichts. Bei Überprüfung mit dem Resolver liefern claude-sonnet-5, anthropic:claude-sonnet-5 sowie anthropic jeweils kein Profil. Da es keine exakte Übereinstimmung gibt und es keine branchenweite Anthropic-Einträge zum Zurückgreifen gibt (es existieren nur Profile, die an einzelne Versionen gebunden sind), passt nichts zusammen. Der Fehlschlag bleibt völlig unbemerkt. Laut der eigenen Dokumentation des Resolvers ist die einzige Protokollinformation eine Debug-Nachricht, die ausgegeben wird, wenn ein fallback auf Provider-Ebene verwendet wird. Wenn beide Abfragen fehlschlagen, wird überhaupt kein Protokoll geschrieben.

Ein Agent, der auf dem neuesten Modell einer schnell entwickelten Modellfamilie basiert, erhält daher genau die gleiche Anpassung wie ein Agent, der auf einem Modell basiert, von dem das Framework noch nie gehört hat – also keinerlei Anpassung –, ohne dass Anzeichen dafür vorhanden wären, dass dies der Fall ist.

Wie es funktioniert

Eine Abstraktion über allem

Alle diese Middleware-Komponenten basieren auf einem einzigen Mechanismus, der zu LangChain gehört und nicht zu Deep Agents. LangChain 1.0 fügte Punkte hinzu, an denen Code ausgeführt werden kann, wenn eine Ausführung beginnt oder endet, vor und nach jedem Modellaufruf sowie bei jedem Toolaufruf – dadurch kann ein einziger Agent-Loop ganz unterschiedliche Designs unterstützen. Die Before-Hooks werden in der Reihenfolge ihres Registrierens ausgelöst, während die After-Hooks in umgekehrter Reihenfolge funktionieren, was der Art entspricht, wie Web-Frameworks ihre Middleware anordnen. Ein Wrapper-Hook kann einen Aufruf erneut versuchen, ihn aus dem Cache liefern oder ihn vollständig abfangen. Supervisor-Einstellungen, Swarms, Reflection-Loops und Deep Agents sind letztendlich alle ein einziger Loop mit unterschiedlichen angehängten Hooks – create_deep_agent() ist lediglich eine bestimmte Auswahl davon.

Dateien: zwei Backend-Optionen, zwei Garantien

Dateien können an zwei Orten gespeichert sein, und welche Variante aktiv ist, bestimmt, was ein Schreibvorgang eines Agents tatsächlich bedeutet.

StateBackend, die Standardoption, speichert Dateien in einem Kanal des LangGraph-Zustands: Graphendaten mit eigenen Zusammenführungsregeln, nicht auf der Festplatte. Es funktioniert nur während des laufenden Graphenbetriebs. Ob der Inhalt über einen einzelnen Aufruf hinaus erhalten bleibt, hängt davon ab, ob es sowohl einen Checkpointer als auch eine stabile Thread-ID gibt. Ohne diese beginnt jeder Aufruf leer – das erklärt, warum eine reine create_deep_agent()-Aufruf immer einen leeren Arbeitsverzeichnis anzeigt.
FilesystemBackend führt tatsächliche Festplatten-Lesungen und -Schreibvorgänge durch, wodurch eine zuverlässige Speicherung mit echten Sicherheitsrisiken einhergeht. In der Dokumentation heißt es ausdrücklich, dass es sich für lokale Entwicklung sowie CI/CD eignet, aber nicht für Systeme geeignet ist, die Nutzern zugänglich sind, da der Agent alles lesen kann, was er erreichen kann – einschließlich sensibler Daten – und seine Änderungen nicht rückgängig gemacht werden können. Bei dem Standardwert virtual_mode=True bleibt der Zugriff auf den Wurzelverzeichnisbereich beschränkt, ein Durchqueren des Verzeichnisses wird sowohl am Rohpfad als auch am bereinigten Pfad abgelehnt, und echte absolute Pfade werden in der Ausgabe des Agents versteckt, damit der Standort des Wurzelverzeichnisses nicht preisgegeben wird.

Ein einziges Berechtigungssystem deckt beides ab. Eine Regel verknüpft eine Aktion mit einem Pfadmuster sowie einem von drei Modi: erlauben, verweigern oder unterbrechen. Löschvorgänge werden sorgfältig anhand der Schreibregeln geprüft. Eine rekursive Löschung wird abgelehnt, wenn irgendeine Verweigerungsregel mit Inhalten unterhalb des Ziels übereinstimmt – und nicht nur mit der ersten passenden Regel –, sodass eine frühe, allgemeine Erlaubnis nicht dazu führen kann, dass etwas gelöscht wird, was durch eine später eingefügte, engere Regel geschützt werden soll.

Subagenten, aus Designgründen isoliert

Zu Subagenten gelangt man auf dieselbe Weise wie zu jedem anderen Tool. Wenn das Modell task aufruft, startet ein völlig separater Agent, ausgestattet mit seinem eigenen Modell, Tools und Middleware. Die Modellkonfiguration akzeptiert entweder einen provider:model-String oder ein bereits erstelltes Modellobjekt; daher erfordert das Einsetzen eines Subagenten auf einem anderen Provider als dem Elternteil nur eine Konfigurationszeile – keine umfangreichen ingenieurtechnischen Anpassungen.

Das Gedächtnis wird nicht automatisch übertragen. Die Subagenten-Spezifikation verfügt über kein Gedächtnisfeld, und die Logik zur Weitergabe von Berechtigungen hat kein Gegenstück für das Gedächtnis. Der isolierte, saubere Kontext ist beabsichtigt – das bedeutet, alles, was über das Gedächtnis des Elagenten gespeichert wird, ist für einen Subagenten unsichtbar, es sei denn, ihm wird eigene Gedächtnis-Middleware zur Verfügung gestellt.

Das Gedächtnis ist änderbar, nicht bindend

Ein Gedächtnisfile gelangt nach dem Laden nicht direkt in den Systemprompt. Er kommt in einem klar gekennzeichneten Block an, der zusätzliche Anweisungen des Frameworks enthält, die dem Modell mitteilen, dass der Inhalt Referenzmaterial sein könnte, das veraltet ist oder von jemand anderem erstellt wurde – und nicht ein Befehl, dem ohne Frage Folge geleistet werden muss. Dies entspricht einem niedrigeren Vertrauensniveau als der Systemprompt und passt zur vorgesehenen Rolle: Etwas, das der Agent beim Arbeiten liest und anpasst, nicht ein Regelbuch, das ein Entwickler einmal schreibt und von dem er erwartet, dass es vollständige Autorität hat.

Ein Skalierungsaspekt

Der Zustand der Konversation beruht auf einem benutzerdefinierten Reducer mit dem Namen DeltaChannel, der so konzipiert ist, dass die Speicherung der Checkpoints linear, O(N), mit zunehmender Länge der Konversation wächst, anstatt quadratisch, O(N²).

Verhalten an den Rändern

Zwei Bedingungen sollten verstanden werden, bevor man entscheidet, inwieweit in der Produktion Subagenten genutzt werden sollen – beide werden im aktuellen Repository überprüft.

Ein Fehler, viele Ausfälle (Problem #694). Wenn mehrere Unteragenten gleichzeitig ausgeführt werden und einer eine Ausnahme wirft, werden die übrigen zusammen mit ihm abgebrochen. Die Batch-Verarbeitung ist entweder erfolgreich oder fehlschlägt als Ganzes – es gibt keine Trennung zwischen den einzelnen Komponenten. Der Bericht stammt aus Januar 2026 von einer frühen Version, und das Problem wurde seitdem geschlossen, obwohl die Codeänderung, die es behoben hat, weder im Code der Unteragenten noch in der Tool-Execution-Schicht von LangChain nachvollzogen werden kann. Planen Sie dennoch damit: Behandeln Sie jede Aufteilung in unabhängige Unteraufgaben als potenziell teilweise fehleranfällig, bis im tatsächlich eingesetzten Version anders bestätigt wird.

Fehler erreichen den falschen Empfänger (#947). Nachdem ein Tool einen Fehler meldet, sollte das Modell normalerweise erneut versuchen oder Anpassungen vornehmen. In einigen beobachteten Fällen wandte es sich jedoch direkt an den Endnutzer mit Text, der eigentlich als interne Korrektur gedacht war, sodass eine Person eine Fehlermeldung sah, die niemals für sie bestimmt war. Das Problem war zum Zeitpunkt der Überprüfung noch ungelöst. Ein separater Bericht weist darauf hin, dass nach einem späteren Framework-Update bestimmte Tool-Ausnahmen den Agenten vollständig stoppen, anstatt die Nachricht als erneut verarbeitbaren Hinweis an das Modell weiterzuleiten, wie es in früheren Versionen der Fall war.

Zwei ältere Berichte aus dem gleichen Bereich sind abgeschlossen: Unteragente, die die Recursionsschranke des Elternagents ignorieren (#1698), sowie Unterbrechungen bei der Wiederaufnahme von Abläufen aufgrund von Bearbeitungs- und Ablehnungsentscheidungen (#554). Die Lösung für die Recursionsschranke wurde außerdem anhand der installierten Quelle überprüft. Sie zeigen, wie schnell Probleme in diesem Bereich in der Regel behoben werden, weshalb es keinen Grund gibt, das Design zu ändern.

Praktische Alternativen

Heute gibt es drei praktische Optionen zur Entwicklung von Agenten mit langfristiger Ausrichtung: Deep Agents, das Claude Agent SDK und das OpenAI Agents SDK. Jede dieser Optionen spiegelt eine andere Entscheidung darüber wider, was das jeweilige Team selbst kontrolliert und was es nach außen bereitstellt, und keine davon ist eine unvollständige Version der anderen.

Eine Unterscheidung wird häufiger verwechselt als jede andere: der Unterschied zwischen einer Übertragung und einem Unteragenten. Zwei der drei Optionen nutzen dasselbe zugrundeliegende Muster, das unabhängig voneinander von zwei Teams erreicht wird. Die dritte ist ein wirklich anderer Mechanismus.

Die Wahl zwischen ihnen hängt von zwei Fragen ab und nicht von einer Rangliste, und für keine gibt es eine universelle Antwort. Jede Frage kann nur im Hinblick auf die tatsächlichen Einschränkungen eines bestimmten Systems beantwortet werden.

Was man mitnehmen sollte

Langfristige Agenten benötigen eine Struktur, da der angesammelte Kontext das Signal bereits lange vor dem Erreichen der vollen Zeitfensterstrecke abschwächt. Deep Agents bauen diese Struktur auf einer viergliedrigen Grundlage auf, gestützt durch eine sich ändernde Ansammlung von Middleware-Komponenten sowie ein Dateisystem, Unteragenten und Speicher, die jeweils spezifische Garantien und Lücken aufweisen. Das Bewusstsein für diese Lücken – wie fehlende Profile bei neueren Modellen, Speicherinhalte, die für Unteragenten unsichtbar sind, parallele Fehler im „Alles-oder-Nichts“-Prinzip sowie Tool-Fehler, die an die Benutzer weitergeleitet werden – ist es, was das bewusste Nutzen des Frameworks vom Vertrauen in seine Standardeinstellungen unterscheidet.