Managed Deep Agents Beta: Eine verzeichnisbasierte Methode zur Bereitstellung von LangChain Agents
LangChains Managed Deep Agents verwandelt einen Projektordner in einen gehosteten Agenten. Was jede Datei bewirkt, wie sich das mda-Deployment verhält, sowie die für die Nutzung wichtigen Beta-Mängel.
Quellen: LangChain Just Shipped Managed Deep Agents — And Your Agent Is Now a Directory
Teams, die auf LangGraph aufbauten, stießen weiterhin auf dieselben Grenzen. LangGraph ist eine Laufzeitumgebung, eine primitive Ebene, doch viele betrachteten es wie ein Anwendungsframework. Deep Agents war LangChains Antwort: Planung, ein virtuelles Dateisystem, Subagenten und Kontextkompression, alles in einem Framework zusammengefasst, sodass niemand diese Infrastruktur erneut aufbauen musste.
Das half, doch dann tauchte eine weitere Grenze auf. Ein Framework endet an der Prozessgrenze. Sobald ein Agent einen Neustart überstehen muss, nachdem ein Mensch eine Toolaufruf bestätigt hat, montags bis freitags um 8 Uhr morgens arbeiten muss, auf eine Slack-Nennung antworten muss oder Erinnerungen über den aktuellen Thread hinaus speichern muss, muss das Team erneut Infrastruktur entwickeln. Das bedeutet Checkpoint-Systeme, Cron-Jobs, Signaturverifizierung, Thread-Eigentumsregelungen und geheime Datenrouten.
Jeder, der bereits einen Agenten in einen Cloud-Container eingebettet hat, weiß, wie unausgeglichen die Situation dabei werden kann. Man denke an einen mit MCP ausgestatteten Dokumentenagenten auf ECS Fargate: IAM-Politiken, ein VPC mit privaten Subnetzen, Terraform-Statusdaten in S3 zusammen mit einer DynamoDB-Lock-Tabelle sowie Task-Definitionen, die die Gesundheitsprüfungen fehlschlagen, bis jemand auf eine Inkonsistenz bei den Container-Ports stößt. Die Logik des Agenten kann einige Tage in Anspruch nehmen, während die zugrundeliegende Infrastruktur mehrere Wochen beansprucht.
Managed Deep Agents ist LangChains Lösung für diese zweite Einschränkung. Es ging am 7. August 2026 in die öffentliche Beta-Version. Nach dem Durchlesen der 21 Dokumentationsseiten ist das Auffälligste nicht die von allen erwähnte Ein-Befehl-Deployment-Möglichkeit. Vielmehr hört der Agent auf, ein Python-Objekt zu sein – er wird stattdessen zu einem Verzeichnis.
Was das Produkt tatsächlich ist
Das Wort „managed“ ist vage, daher hilft eine präzise Definition. Managed Deep Agents, im Terminal als mda aufgerufen, ist ein Python-Paket. Es nimmt einen Projektordner entgegen, kompiliert ihn zu einer gehosteten LangGraph-Anwendung und übermittelt diese an LangSmiths Agent Server. Die Deep Agents selbst bleiben unverändert, während LangSmith ihre Ausführung übernimmt und sich um Persistenz, langlebige Threads, den Lebenszyklus der Sandboxes, das Laden von Fähigkeiten sowie das Verwalten des Speichers kümmert.
Der Workflow lässt sich mit vier Befehlen umsetzen:
uv tool install managed-deepagents
mda init research-assistant
cd research-assistant
uv sync
mda dev . # run locally in LangSmith Studio
mda deploy . # deploy to LangSmith
Die Ankündigung beginnt damit und ist korrekt, unterschätzt aber die eigentliche Gestaltungswahl auf einer Ebene darunter.
Die Funktionalitäten werden durch ls gesteuert
mda init erstellt eine Projektstruktur, die in der Dokumentation als gesamte Arbeitsfläche betrachtet wird:
my-agent/
├── agent.py # required — the model and core config
├── instructions.md # system prompt, synced to Context Hub
├── skills/
│ └── research/
│ └── SKILL.md # task-specific playbooks
├── tools/ # your LangChain tools
├── middleware/ # logic around model and tool calls
├── connectors/
│ └── mcp.py # remote MCP servers
├── channels/
│ └── slack.py # Slack, GitHub, other entry points
├── schedules/
│ └── daily_digest.py # managed cron jobs
├── sandbox/
│ └── __init__.py # isolated filesystem and shell
├── identity.py # auth and thread scoping
├── memory.py # durable cross-thread memory
├── pyproject.toml
├── .env
└── evals/ # Harbor tasks
Nur agent.py ist zwingend erforderlich. Alles andere ist optional, und hier kommt der entscheidende Punkt: ob eine Datei vorhanden ist, bestimmt, ob eine Funktion aktiviert oder deaktiviert wird.
Entfernen Sie den Ordner sandbox/, und der Sandbox verschwindet. Legen Sie memory.py in die Wurzel, und die dauerhafte Speicherung wird aktiviert. Fügen Sie schedules/daily_digest.py hinzu, und die nächste Bereitstellung erstellt einen LangSmith-Cron-Job; löschen Sie die Datei, und der Cron-Job wird entfernt.
Jeder, der bereits Terraform verwendet hat, erkennt dieses Konzept wieder. Es handelt sich um deklarative Infrastruktur in Python-Syntax. Sie beschreiben den gewünschten Zustand, und mda deploy bringt die tatsächliche Situation damit in Einklang.
Die Struktur macht erst Sinn, nachdem man gesehen hat, was die Dateien enthalten, daher werden sie hier nacheinander vorgestellt.
agent.py, die einzige erforderliche Datei
from managed_deepagents import define_deep_agent
from middleware.audit import log_tool_calls
from tools.search import internet_search
agent = define_deep_agent(
name="research-assistant",
model="openai:gpt-5.5",
tools=[internet_search],
middleware=[log_tool_calls],
interrupt_on={"internet_search": True},
)
name ist das einzige erforderliche Argument und dient gleichzeitig als ID des LangGraph-Assistenten sowie als Standardname der Bereitstellung. Darüber hinaus nimmt define_deep_agent tools, middleware, subagents, permissions, interrupt_on (für die Genehmigung durch einen Menschen) sowie response_format (strukturierte Ausgabe) entgegen.
Betrachten Sie, was fehlt: Es gibt keinen Systemprompt, keine Speicherkonfiguration, keinen Sandbox und keine Zeitpläne. All das wird ausschließlich über Dateien gesteuert, und es gibt keine Möglichkeit, es auch im Code zu konfigurieren, selbst wenn man es möchte.
Die integrierten Suchwerkzeuge auf Serverseite benötigen keinen Anbieter-Schlüssel, obwohl jeder Anbieter ein unterschiedlich strukturiertes Werkzeugverzeichnis erwartet – und das ist ein leichter Punkt, an dem Fehler auftreten können.
tools=[{"type": "web_search"}] # OpenAI
tools=[{"google_search": {}}] # Google
tools=[{"type": "web_search_20260209", "name": "web_search"}] # Anthropic
Wenn „Suche“ in einer Spur nie erscheint, ist diese Unstimmigkeit fast immer die Ursache.
instructions.md und skills/
Der in die Cloud synchronisierte Kontext befindet sich hier. Die Anleitungsdatei könnte folgenden Inhalt enthalten:
# Research assistant
You are a careful research assistant. Use internet search to find sources,
keep notes, and return concise answers with citations.
Es wird zum Systemprompt, der bei jedem Ausführungsvorgang eingefügt wird. Die Fähigkeiten verhalten sich unterschiedlich. Jede befindet sich in ihrem eigenen Verzeichnis mit Frontmatter:
---
name: research
description: Gather and synthesize context before answering complex questions.
---
# Research
Use this skill when a task needs more than a direct answer.
1. Identify what information is missing.
2. Use `query_db` to look up relevant records.
3. Summarize findings before responding to the user.
Wenn der Agent gestartet wird, sieht er nur den Namen und die Beschreibung jeder Fähigkeit. Eine passende Aufgabe veranlasst ihn dazu, den gesamten SKILL.md zu lesen, wobei unterstützende Dateien nur nach Bedarf heruntergeladen werden. Dies ist eine schrittweise Offenlegung von Informationen, wie es im Open-Source-Harness der Fall ist.
Ein nützlicher operativer Aspekt: Zum Zeitpunkt der Bereitstellung werden instructions.md sowie der gesamte Ordner skills/ in den LangSmith Context Hub hochgeladen. Sie können anschließend ohne erneute Bereitstellung über die Benutzeroberfläche geändert werden, sodass das Bearbeiten eines Prompts nicht mehr eine Neuverarbeitung erfordert. Jeder, der bereits einmal einen CI-Ablauf durchlaufen hat, nur um einen Tippfehler in einem Systemprompt zu korrigieren, versteht den Vorteil.
memory.py: dauerhafte Speicherung, optional
from managed_deepagents import define_memory
memory = define_memory(scope="agent")
Diese beiden Zeilen reichen aus – ohne sie verfügt der Agent über keinerlei dauerhaften Speicher. Das mag Menschen überraschen, die annehmen, dass Speicherstandardmäßig vorhanden ist.
Durch Aktivierung wird ein Context Hub-Tree unter /memories/agent/ erstellt. Die Datei AGENTS.md in diesem Tree ist „heißer Speicher“, der bei jedem Start in den Kontext geladen wird. Alles andere ist „kalter Speicher“, den der Agent nur dann liest, wenn es relevant ist. Lesen und Schreiben erfolgen über die üblichen Funktionen read_file, edit_file und write_file; Schreibvorgänge an anderen Orten, einschließlich weiterer Pfade unter /memories/, sind nicht dauerhaft. Daraus ergibt sich eine Konsequenz des Designs, die weiter unten erläutert wird.
sandbox/ und sein Snapshotschritt
from managed_deepagents import define_sandbox
sandbox = define_sandbox(
idle_ttl_seconds=600,
default_timeout=600,
docker_image="python:3.12-slim",
)
Jeder langlebige Thread erhält seine eigene Sandbox, die von LangSmith Sandboxes unterstützt wird. Ein optionales sandbox/setup.sh wird einmal unter bash -e ausgeführt und das Ergebnis wird als Snapshot gespeichert, den neue Threads klonen, anstatt die Einrichtung erneut durchzuführen:
#!/usr/bin/env bash
set -euo pipefail
apt-get update && apt-get install -y jq
mkdir -p /workspace
Zwei Fallstricke sind zu kennen. Werte aus .env sind während der Ausführung von setup.sh verfügbar, was beim Klonen eines privaten Repositoriums hilft, doch die Threads, die das Snapshot klonen, erhalten sie niemals. Zudem landet alles, was bei der Einrichtung auf der Festplatte hinterlassen wird, im Image jedes Threads, was das Speichern von Geheimnissen dort ausschließt.
schedules/: cron mit einer Kompilierungszeit-Regel
from managed_deepagents import define_schedule
schedule = define_schedule(
cron="0 8 * * 1-5",
timezone="America/Los_Angeles",
prompt="Review durable memory for reusable research rules. List open questions for today.",
)
Es gibt eine Datei pro Zeitplan, und der Dateinamen wird zum Namen des Zeitplans. Es muss genau ein Wert von prompt oder input angegeben werden. Nur ein fünffeldriger Cron-Zeitplan wird akzeptiert, weshalb Ausdrücke, die auf Sekunden basieren, zur Fehlerverursachung führen. Ohne Zeitzone wird UTC verwendet.
Die Einschränkung, die am ehesten Probleme verursacht, ist, dass die Zeitplandeklarationen zur Kompilierzeit extrahiert werden müssen und statisch serialisierbar sein müssen. Keine Umgebungsvariablen, keine Funktionsaufrufe, kein **kwargs, keine berechneten Werte. Literale und Konstanten oberster Ebene sind in Ordnung. Alles Dynamische gehört stattdessen in den Agenten, die Tools oder das Middleware.
Jeder Ausführungsvorgang erhält in der Regel einen temporären Thread, der nach Abschluss entfernt wird. Für geplante Ausführungen, die einen Zustand aufbauen sollen, muss stattdessen thread={"mode": "persistent", "id": "nightly-memory"} verwendet werden.
channels/ und connectors/
Ein Channel erhält Nachrichten, die Ausführungen starten, während ein Connector dem Agenten Werkzeuge zur Verfügung stellt. Jeder davon ist eine einzige Datei:
# channels/slack.py
from managed_deepagents import channels
channel = channels.slack(
auto_reply=True,
mention_behavior="strip",
conversation={"app_mention": "thread", "direct_message": "conversation"},
)
# connectors/mcp.py
from managed_deepagents import connectors
connector = connectors.mcp(
mcp_servers={
"langchainDocs": {
"transport": "http",
"url": "https://docs.langchain.com/mcp",
"include_tools": ["search_docs_by_lang_chain"],
},
},
)
Die Routing-Logik folgt dem Dateinamen. channels/slack.py stellt seinen Events-Endpunkt unter /channels/slack/events zur Verfügung, und MCP-Tools verwenden den Servernamen als Präfix, sofern nicht anders angegeben, weshalb dieser Connector als langchainDocs__search_docs_by_lang_chain angezeigt wird. Stdio-MCP-Server sind keine Option – es stehen nur Streamable HTTP und das herkömmliche SSE zur Verfügung.
identity.py: Wer darf den Agenten aufrufen?
from managed_deepagents import auth, define_identity
identity = define_identity(auth=auth.langsmith_api_key())
Das ist das, was mda init als sichere Standardwert erzeugt. Die Aufrufer senden einen LangSmith-Workspace-Schlüssel im x-api-key-Header. Dadurch wird entschieden, ob jemand den Agenten aufrufen darf, doch alle teilen anschließend dieselben Threads. Für eine pro-Benutzer-Privatsphäre ist ein Wechsel zu Supabase erforderlich:
identity = define_identity(auth=auth.supabase(project_ref="your-project-ref"))
Die Kunden senden anschließend Authorization: Bearer , und MDA überprüft den JWT gegen den JWKS-Endpunkt des Projekts. In der Dokumentation gibt es eine Migrationswarnung: Die Hinzufügung dieses Elements zu einer bereits vorhandenen Bereitstellung füllt keine Eigenschaften des Eigentümers in bereits existierende Threads zurück.
Was mda deploy tut
In der Dokumentation sind elf schrittweise Vorgänge aufgeführt. Die relevanten sind:
- Es wird das Projekt überprüft und
agent.pygeladen. - Die LangSmith-Schlüssel werden in einer festgelegten Reihenfolge (
LANGGRAPH_HOST_API_KEY,LANGSMITH_API_KEY,LANGCHAIN_API_KEY) gesucht, und.envwird vor der Shell-Umgebung gelesen. - Jeder nicht reservierte Wert aus
.envwird gesammelt und als geheimes Element der bereitgestellten Installation übermittelt.
instructions.md sowie den Ordner skills/ in den Context Hub..mda/build und laden Sie das Archiv hoch, das maximal 200 MB groß sein darf.DEPLOYED steht.schedules/ aufbauen.Der siebte Schritt ist der Punkt, an dem der Vergleich mit Terraform nicht mehr nur eine Redewendung ist – es handelt sich dabei um die Korrektur von Abweichungen, und das Verhalten entspricht terraform apply.
Genau wie bei Terraform gibt es auch hier eine Flagge, die dies stillschweigend überspringt. Durch das Hinzufügen von --no-wait startet die CLI den Remote-Build und beendet ihn, bevor der Status auf DEPLOYED wechselt – dadurch kommt die Ausführung niemals zur Schritt der Synchronisierung des Zeitplans. Der neue Cron-Job existiert nicht, der gelöschte Cron-Job wird weiterhin ausgeführt, und der Deploy-Bericht zeigt Erfolg an. Immer wenn sich der Zeitplan ändert, sollte man mda deploy . ohne --no-wait ausführen. Eine entsprechende Anmerkung im Team-Runbook ist eine günstige Absicherung.
Seine Stellung in der LangChain-Stack
Es gibt nun vier Schichten, und die Leute neigen dazu, diese miteinander zu verwechseln.
LangChain stellt die Bausteine bereit: Modelle, Tools, Prompts. Es bildet die Grundlage.
LangGraph ist die Laufzeitumgebung, die eine dauerhafte, zustandsbasierte, grafenbasierte Ausführung ermöglicht (Persistenz, Streaming, Unterbrechungen). Man kann sie sich als Motor vorstellen.
Deep Agents steht über beiden als Framework da und verfügt über einen Planer, ein Dateisystem, Unteragenten, Kontextkompression sowie vorgefertigte Standardeinstellungen.
Managed Deep Agents ist die gehostete Laufzeitumgebung für dieses Framework. Es handelt sich um denselben Agent Server, den LangSmith-Kunden bereits in der Produktion nutzen, nur in einer stärker vorgegebenen Form für Deep Agents-Projekte verpackt.
Eine Auto-Analogie macht das klar: LangGraph liefert Motor und Getriebe, Deep Agents liefert das Auto, und Managed Deep Agents liefert das Auto, die Werkstatt sowie jemanden, der das Öl wechselt. Der Preis dafür ist das Fehlen der Möglichkeit, den Motorraum zu öffnen. Das ist ein ehrlicher Tausch, und die Dokumentation ist dazu ehrlich. Wer individuelle Routen, Anwendungscode neben dem Graphen oder direkte Kontrolle über die Persistenz benötigt, soll LangSmith Deployment direkt verwenden.
Der Geltungsbereich des gemeinsamen Speichers
Die Beta-Version bietet einen einzigen Speicherkontext, agent: einen Les-/Schreibbaum, den alle Aufrufer, die auf die Implementierung zugreifen können, teilen.
Die Dokumentation ist ungewöhnlich direkt bezüglich dessen, was folgt. Der Speicher wird von allen Aufrufern geteilt, und jeder Aufrufer kann ihn beeinflussen. Speichern Sie daher nur solche Informationen, die jeder lesen und ändern darf, und betrachten Sie den vorhandenen Speicher als unzuverlässige Eingabe, der niemals Befugnisse verleihen, Tool-Rechte ändern oder Genehmigungen umgehen darf.
Verstehen Sie dies als Sicherheitskonzept. AGENTS.md wird bei jedem Start in den Systemkontext geladen, sodass alles, was Aufrufer A am Dienstag schreibt, dauerhaft am Mittwoch im Kontext von Aufrufer B vorhanden ist. Für ein internes Tool mit einem einzigen Team ist das in Ordnung. Für mehrere Nutzergruppen stellt dies jedoch einen Kanal für Eingabenzuweisungen mit einer Persistenzschicht dar.
Was die Situation für diejenigen, die sich um Bewertung und Beobachtbarkeit kümmern, noch verschlimmert, ist, dass der Fehler in den Bewertungen nicht sichtbar wird. Die Harbor-Aufgaben bewerten den Zustand des Arbeitsbereichs nach einem Ausführungsvorgang und berücksichtigen keinen Angreifer, der bereits eine Woche zuvor in den heißen Speicher geschrieben hat.
Der Rat in der Dokumentation ist richtig: Verwenden Sie keinen gemeinsamen Speicher, wenn die Aufrufer sich nicht gegenseitig beeinflussen sollten. Solange es keine pro-Benutzer-Speicherverwaltung gibt, stellt das eine echte Einschränkung für die mögliche Entwicklung dar.
Eine Oberfläche, die sich weiterhin verändert
Ein praktischer Hinweis, bevor man Code kopiert. Der Veröffentlichungstermin des Beitrags liegt vom 7. August, während sich die Dokumentation ständig ändert. Innerhalb von etwa drei Wochen haben sich vier öffentliche APIs geändert, und jeder, der auf Basis der im Beitrag bereitgestellten Beispiele entwickelt, stößt auf alle vier.
- Speicher: In der Ankündigung heißt es, jede Bereitstellung beginne mit einem speicherbereichsgebundenen Speicher für Agenten, während die Dokumentation einen dauerhaften Speicher als optional und standardmäßig deaktiviert beschreibt.
- Sandboxen: In der Ankündigung wird
define_sandbox(provider="langsmith", scope="thread")verwendet, wobei auf einen gemeinsamenagent-Bereich hingewiesen wird; die Referenzseite listetidle_ttl_secondsunddefault_timeoutauf und besagt, dass eine Sandbox immer einem Thread zugeordnet ist. - Identität: In der Ankündigung wird davon gesprochen, einen OIDC-Anbieter in
identity.pyzu konfigurieren, doch die Seite zur Identitätsverwaltung behandelt nur LangSmith-API-Schlüssel und Supabase. - Slack: In der Ankündigung wird
channels.slack(on=[...])aufgerufen, während die Slack-Anleitung keinon-Argument enthält und die Event-Abonnements im Slack-App-Manifest platziert.
Auch die Dokumentation ist nicht immer konsistent mit sich selbst. Auf einer Seite wird der Befehl mda channel init slack genannt, auf einer anderen mda channel add slack .; die Option --configure-slack für mda deploy . wird im Slack-Leitfaden beschrieben, fehlt aber in der CLI-Referenztabelle.
Das macht das Produkt nicht schlecht. Es bedeutet einfach, dass es sich um eine Beta-Version eines deklarativen Tools handelt, bei dem die Benutzeroberfläche das Einzige ist, was niemand erraten sollte. Wenn Dokumentation und Tabellen nicht übereinstimmen, hat mda --help Vorrang.
Wann es passt und wann nicht
Managed Deep Agents macht Sinn, wenn:
- man bereits auf der Deep Agents-Plattform aufbaut und die Infrastruktur ein Engpass darstellt
- der Agent dauerhafte Threads, geplante Aufgaben oder eine Slack-Oberfläche benötigt
- Prompte und Fähigkeiten ohne Neuverteilung bearbeitet werden sollen
Wählen Sie entweder LangSmith Deployment selbst oder hosten Sie das Open-Source-Tool selbst, wenn:
- Ihr eigenes Backend den Agenten aufrufen muss. Die Beta-Version setzt zunächst auf die CLI, während die API noch entwickelt wird, und das Programmatische Fortsetzen einer unterbrochenen Ausführung bedeutet laut den Dokumenten, Ihren LangChain-Kontakt zu konsultieren – was diesen Anwendungsfall vollständig ausschließt.
- Die Aufrufer voneinander getrennt gehalten werden müssen.
- Custom-Routen oder direkter Zugriff auf die Persistenz erforderlich sind.
- Die Daten außerhalb der USA bleiben müssen.
- Slack über mehrere Replikate läuft. Die Ereignisdeduplizierung ist derzeit prozessbezogen, sodass ein Neversuch von Slack den Agenten zweimal auslösen kann; Tools, die über einen Channel erreichbar sind, müssen idempotent sein, falls sie Nebeneffekte haben.
Ausprobieren
Installieren und Scaffold erstellen:
uv tool install managed-deepagents
mda init test-agent && cd test-agent
Fügen Sie anschließend die Schlüssel in .env ein:
LANGSMITH_API_KEY=<your-key>
OPENAI_API_KEY=<your-key>
Bevor Sie etwas schreiben, führen Sie ls auf dem erstellten Strukturverzeichnis aus. Fünf Minuten mit diesem Verzeichnis vermitteln mehr über das Modell des Produkts als jede Ankündigung.
Anschließend erstellt uv sync && mda dev . das Projekt, setzt ein lokales Ersatzsystem für Context Hub auf (das Anleitungen, Fähigkeiten und Erinnerungen enthält) und startet LangSmith Studio in einem Browserfenster. Es lädt Projektdateien nicht dynamisch nach, daher müssen Sie nach Änderungen stoppen und den Vorgang erneut ausführen. Die offizielle Schnellstartanleitung befindet sich in den LangSmith Python-Dokumenten unter dem Abschnitt „Managed Deep Agents“.
Teams, die bereits Deep Agents einsetzen und ihre eigene Deployment-Infrastruktur aufbauen, sollten damit einen Nachmittag auskommen. Das Verzeichnismodell ist eine gute Idee, und die Mängel in der Beta-Version lässt sich beheben, sobald sie bekannt sind.
Verwandte Literatur
- Warum Langzeit-Agenten ein Harness benötigen: Wie Deep Agents Zustand und Kontext verwalten — Ein genauer Blick auf Deep Agents: Kontextverlust, die vier Säulen, Middleware, Harness-Profilen, Dateisystem-Backends, isolierte Subagenten, Fehlschläge in Ausnahmesituationen und Alternativen.
- Ein Planung-Agent in LangGraph entwickeln: Planen, Ausführen, Neuplanen, Berichten — Ein vierknotiger LangGraph-Planung-Agent für Finanzforschung: strukturierte Pläne, ein namensraumbewusstes Tool-Register, Neuplanungsgrenzen und ein detailliert aufgezeichneter Beispielaufruf.