LangChains DeepAgents-Framework

 (blog.langchain.com)
21 Punkte von GN⁺ 2025-08-07 | 1 Kommentare | Auf WhatsApp teilen
  • Herkömmliche LLM-basierte Agenten folgen meist einer „flachen“ Agentenstruktur, bei der lediglich Tools wiederholt aufgerufen werden. Deep Agents sind dagegen planvolle und strukturiert arbeitende KI-Agenten, die auch komplexe und langfristige Aufgaben tiefgehend lösen können
  • Neuere Agenten wie Deep Research, Manus, Claude Code setzen „Deep Agents“ um, die eine tiefere Themenerschließung und besseres Kontextmanagement ermöglichen
    • Detaillierte System-Prompts, Planungstools, Sub-Agenten und die Nutzung eines Dateisystems sind der Kern von „Deep Agents“
  • LangChain veröffentlicht das Open-Source-Paket deepagents, damit jeder leicht einen eigenen Deep Agent passend zum jeweiligen vertical (Domänenbereich) bauen kann
    • Benutzerdefinierte Prompts, Tools und Sub-Agenten lassen sich konfigurieren; zudem wird ein universelles Framework bereitgestellt, das sich in verschiedenen Bereichen wie Forschung und Entwicklung einsetzen lässt

Grenzen bestehender LLM-Agenten und Merkmale von Deep Agents

  • Traditionelle Agenten: Das LLM läuft in einer Schleife und ruft nur Tools auf → geeignet nur für kurzen Kontext sowie kurzfristige und einfache Aufgaben
  • Deep Agents: Können auch langfristige Ziele und komplexe Tasks selbstständig zerlegen, planen, nachverfolgen und kollaborativ bearbeiten

Die 4 Bausteine von Deep Agents

  1. Detaillierte System-Prompts

    • Wie bei bekannten Beispielen wie Claude Code kommen Prompts zum Einsatz, die Tool-Nutzung und Verhaltensbeispiele detailliert festhalten
    • Komplexe Anweisungen und Few-Shot-Beispiele fördern ein „tieferes“ Denken und Ausführen

  2. Planungs-Tools

    • Auch ohne echte Funktion werden Planungstools wie eine „To-do-Liste“ in die Routine eingebunden, um Kontextmanagement und Ausführungsfähigkeit aufrechtzuerhalten
    • Selbst als no-op (ohne tatsächliche Aktion) liefern sie dem Prompt wirksamen Kontext

  3. Sub-Agenten

    • Für Teilaufgaben werden Sub-Agenten erzeugt und aufgeteilt; jeder Agent arbeitet separat und die Ergebnisse werden anschließend zusammengeführt
    • Auch große und komplexe Probleme lassen sich so durch Parallelisierung und Arbeitsteilung bearbeiten

  4. Dateisystem

    • Dient nicht nur für echte Dateioperationen, sondern auch als Ablage für Notizen und Kontext
    • Mehrere Agenten und Sub-Agenten können ein Dateisystem gemeinsam nutzen, um zusammenzuarbeiten und langfristigen Kontext zu bewahren

LangChains Deep-Agents-Framework: deepagents

  • Open-Source-Python-Paket (pip install deepagents), mit konfigurierbaren Prompts, Tools und Sub-Agenten
    • System-Prompt inspiriert von Claude Code, aber allgemeiner angepasst
    • no-op-To-do-Listen-Planungstool (wie bei Claude Code)
    • Erzeugung von Sub-Agenten sowie benutzerdefinierte Festlegung möglich
    • Virtuelles Dateisystem auf Basis von LangGraph-Konzepten (unter Nutzung des Agentenstatus)
  • Als Beispiel wird ein Deep-Research-Agent bereitgestellt; damit lassen sich vertical-spezifische Agenten leicht erstellen

Anwendungsbeispiele und Nutzen

  • Optimiert für langfristige und komplexe KI-Aufgaben wie Forschung und Entwicklung, Code-Generierung, Research und komplexe Automatisierung
  • Detailliertes Kontextdesign und eine Struktur mit Arbeitsteilung ermöglichen tiefgehende Ergebnisse
  • Jeder kann einen zum eigenen Domänenbereich passenden „Deep Agent“ aufbauen – ein nächster Schritt in der Nutzung von KI

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-07
Hacker-News-Kommentare

  • Ich bin der Autor. In letzter Zeit fand ich es beeindruckend, dass eine Reihe von Agenten wie claude code, manus und deep research besonders gut Aufgaben über lange Zeithorizonte hinweg ausführen. Im Grunde ruft intern ein LLM in einer Schleife Tools auf. Wenn man das aber gedankenlos macht, entsteht das Problem, dass das LLM komplexe oder lange Aufgaben nicht richtig bewältigt. Deshalb wollte ich wissen, wie andere Agenten das hinbekommen. Gemeinsam aufgefallen sind mir folgende Punkte. 1) Sie verwenden ein Planning-Tool 2) Sie verwenden Sub-Agenten 3) Sie nutzen eine Struktur, die Kontext wie ein Dateisystem auslagert 4) Sie entwerfen detaillierte System-Prompts (Prompt Engineering ist weiterhin wichtig) Jeder einzelne Punkt ist zwar schon bekannt, wird aber bei der tatsächlichen Entwicklung von Agenten nicht breit genutzt. Ich denke, die wichtige Erkenntnis ist eher diese Kombination. Feedback willkommen

  • Wenn ich die verschiedenen Meinungen zusammennehme, stimme ich zu, dass das Konzept der deep agents letztlich nicht stark von einer Kombination aus Agent + Tool abweicht. Für mich sind die Kernpunkte folgende. 1) Für das Grundwissen braucht man ein gutes LLM 2) Ein Prompt, der das LLM richtig anleitet, ist wichtig (damit es als Agent funktioniert) 3) Funktionen ohne eigene Urteilsbildung werden als Tool implementiert 4) Wenn der Agent+Tool-Flow komplex wird, teilt man ihn in Sub-Agenten mit fokussierten Prompts und einer kleinen Zahl von Tools auf und trennt so die einzelnen Domänen

    • Am Ende wird sich das wohl zu einem "Koordinator"-Modell entwickeln, bei dem der Top-Level-Agent auswählt, was getan werden muss, und verteilt, welcher Agent für welche Aufgabe geeignet ist. Diese Struktur kann sich rekursiv fortsetzen (z. B. ein Agent pro Produkt, der dann weiter in Agenten für Frontend-/Backend-Arbeiten verzweigt). In so einer Struktur müssen sich die Agenten, die die eigentliche Arbeit ausführen, nur auf begrenzten Kontext und wenige Tools konzentrieren, und der übergeordnete Agent muss nur wissen, was die Sub-Agenten leisten können

  • deep agents = Agenten mit zusätzlichem Planning + Kombination aus Agenten und Tools, also letztlich ähnlich wie bestehende Agenten. Schade finde ich, dass LangChain selbst einfache Konzepte immer kompliziert verpackt und unnötig neue Begriffe oder Konzepte zur Vermarktung erfindet. Natürlich lässt sich LangSmith so besser verkaufen

    • Früher habe ich solche Beratung gemacht. Es ist vielleicht nicht komplett identisch, aber im Kern ist das ein gängiger Trick. Man verpackt Gewöhnliches theatralisch, schafft eigene Begriffe und Kategorisierungen und verkauft genau das. Der nächste Schritt ist dann, die eigenen Konzepte per SEO überall zu platzieren. Man muss sich nur an populäre Keywords wie deep * und agent dranhängen … Wenn ich über solche Dinge nachdenke, fühlt sich das Unternehmensumfeld grundsätzlich einfach seelenleer an

  • Das ist ziemlich nah an dem Ergebnis, das ich erwartet hatte. Jetzt, wo klarer wird, dass es nicht mehr viel bringt, MCP-Server direkt selbst zu schreiben, braucht es eine neue Methode, mit der man schnell auf den Trend aufspringen kann. Selbst Agenten wie gemini oder claude code zu bauen, ist gerade der Trend. Die Einstiegshürde ist niedrig, es ist in gewissem Maß nützlich, man braucht kein tiefes AI-Fachwissen, und es lässt sich leicht vermarkten. Das ist ein bisschen wie der Ansatz „cursor for X“, nur dass man Produkte damit sogar noch schneller bauen kann. Ich glaube, dass so extrem viele Coding-Agenten entstehen werden, aber bislang fühlt es sich noch nicht wirklich neu an. Trotzdem sehe ich positiv, dass bei so einem schnellen Start der Wert eines intuitiv gebauten claude-code-Klons bald gegen null tendieren dürfte

  • Ich verfolge und analysiere den Code dieses Repos weiter https://github.com/ghuntley/claude-code-source-code-deobfuscation Der Autor betreibt Reverse Engineering von Claude Code und erklärt die Architektur gut. Ich habe den Link auf ein besseres Repo geändert

    • Kannst du erklären, was das zeigen soll? Ich sehe nur ein riesiges README und Systembefehle

  • Ich baue mit rust ein universelles agent-cli + library: https://github.com/fdietze/alors Es ist noch früh in der Entwicklung, aber ich nutze es bereits, um genau dieses Projekt damit zu entwickeln. Feedback willkommen

  • Meiner Meinung nach hat Jetbrains' Junie als Erstes eine extrem hochwertige To-do-List-Funktion geschrieben, und die hat mir am besten gefallen. Seit es kostenpflichtig wurde, habe ich es nicht mehr benutzt, aber damals war Junie langsam und vorsichtig. Cursor hat ständig auch Dateien ohne Probleme überschrieben, und Claude lag gefühlt irgendwo dazwischen

    • Cursor bietet auch eine eigene UI für To-do-Listen und lenkt den Agenten dazu, sie zu verwenden (die UX ist gut, aber man kann die Datei selbst nicht direkt sehen). amazons kiro verwaltet sowohl Aufgaben als auch Spezifikationen über tasks.md. Bei so vielen Tools kann man sich einfach das aussuchen, was am besten passt

  • Der interessanteste Teil bleibt komplett verborgen. Entscheidend ist, wie Tool-Calls vom Parsing bis zur Ausführung verwaltet werden

  • Der wirklich innovative Punkt ist die Trennung des Kontexts durch Sub-Agenten. Der Rest ist einfach ein langgraph react agent

    • Das ist wertvoll, aber keine wirklich neue Idee

  • Ich würde gern mehr darüber wissen, was damit gemeint ist, dass das To-do-List-Tool ein no-op ist. Ich würde gern genau verstehen, wie das funktioniert

    • Wenn du es direkt im Code sehen willst: Unser Sketch-Agent nutzt das TODO-List-Tool auf diese Weise: https://github.com/boldsoftware/sketch/blob/main/claudetool/todo.go Den Agenten dazu zu bringen, das zu nutzen, ist relativ einfach. Die meiste Arbeit steckt darin, es in der UI sichtbar zu machen
    • Gleiche Frage. Ich verstehe nicht ganz, was damit gemeint ist. Aber es scheint ein klarer Grund zu sein, warum Claude Code so stark ist
    • Meiner Meinung nach ist das einfach eine simple Concat-Funktion. Wirklich nützliche Prompt-Techniken sind in der Implementierung meist schlicht. Umso erstaunlicher ist, wie weit einen die einfache TODO-Idee bringt! (In ernsthaften Umgebungen sind Agent-Frameworks trotzdem schwierig. Zum Beispiel sind die richtige Kombination und das passende Setup wirklich schwer, und bei der Infrastruktur muss man Multitenancy, Multithreading, Streaming, Cancellation usw. berücksichtigen.) Ich stimme völlig zu, dass die TODO-Liste wichtig ist. Dinge wie der Security-Log-Analyse-Wettbewerb von louie.ai wurden durch diese Methode enorm beschleunigt. Sie verhindert, dass CoT schon nach ein paar Turns zusammenbricht. Ein interessantes Aha-Erlebnis war, dass verschachtelte To-dos (A.2.i...) gut funktionieren und für das LLM kein großes Problem sind, weil sie ohnehin linearisiert werden. Statt claude code verwalten wir das intern mit einem Plan-Prompt in dieser Art: https://github.com/graphistry/louie-py/blob/main/ai/prompts/PLAN.md
    • Im Kontext wird nur festgehalten, dass ein Tool-Call stattgefunden hat. Die eigentlichen To-do-List-Daten werden nicht erneut geladen
    • Meinem Verständnis nach ist das letztlich nur ein Prompt im Stil von „Schreib eine TODO-Liste“