Managed Deep Agents Beta: Sposób oparty na katalogach do wdrażania agentów LangChain

Zespoły rozwijające oprogramowanie na bazie LangGraph wciąż napotykały ten sam problem. LangGraph to środowisko wykonawcze, prymitywa niskiego poziomu, a mimo to wielu traktowało je jak framework aplikacyjny. Deep Agents był odpowiedzią LangChain: mechanizm planowania, wirtualny system plików, podagenty oraz kompresja kontekstu połączone w jedną całość, dzięki czemu nikt nie musiał od nowa budować tej infrastruktury.

To pomogło, ale pojawił się kolejny ograniczenie. Takie rozwiązanie kończy się na granicy procesu. Gdy tylko agent musi przetrwać restart, wznowić działanie po zatwierdzeniu przez człowieka wywołania narzędzia, działać od 8 rano od poniedziałku do piątku, odpowiadać na wiadomości w Slacku lub przechowywać jakąkolwiek pamięć poza bieżącym wątkiem, zespół znów musi budować infrastrukturę. Oznacza to konieczność stosowania mechanizmów sprawdzania stanu, zadań cron, weryfikacji podpisów, określania właściciela wątków oraz zarządzania tajnymi danymi.

Każdy, kto kiedykolwiek umieszczał agenta w kontenerze chmurowym, wie, jak nierównowaga ta może być duża. Wyobraź sobie agenta dokumentów opartego na MCP w ECS Fargate: polityki IAM, VPC z prywatnymi podsieciami, stan Terraform w S3 wraz z tabelą blokad DynamoDB oraz definicje zadań, które zawodzą podczas sprawdzania stanu, dopóki ktoś nie zauważy niezgodności portów kontenera. Logika agenta może wymagać kilku dni, podczas gdy otaczająca go infrastruktura potrzebuje kilku tygodni.

Managed Deep Agents to rozwiązanie LangChain na ten drugi problem. Wszedł do publicznego beta 7 sierpnia 2026 roku. Po przeczytaniu 21 stron dokumentacji najbardziej uderzające nie jest to, że umożliwia implementację za pomocą jednego polecenia, o czym wszyscy mówią. Najważniejsze jest to, że agent przestaje być obiektem w Pythonie – staje się katalogiem.

Czym naprawdę jest ten produkt

Słowo „managed” jest niejasne, więc pomocna jest dokładna definicja. Managed Deep Agents, nazywane w terminalu mda, to pakiet w Pythonie. Bierze on foldery projektów, kompiluje je do aplikacji LangGraph hostowanej online i wysyła ją na Agent Server LangSmith. Sam mechanizm Deep Agents pozostaje niezmieniony, a LangSmith przejmuje jego uruchamianie, zajmując się trwałością danych, wątkami odpornymi na awarie, cyklem życia środowisk testowych, ładowaniem umiejętności oraz zarządzaniem pamięcią.

Proces ten obejmuje cztery polecenia:

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

W komunikacie na wstępie o tym wspomina się, i to jest dokładne, ale nie oddaje on w pełni rzeczywistego wyboru projektowego na niższym poziomie.

Zdolności są kontrolowane przez ls

mda init tworzy strukturę projektu, którą dokumentacja traktuje jako całą dostępną powierzchnię:

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

Tylko plik agent.py jest obowiązkowy. Wszystko inne jest opcjonalne, a oto kluczowy punkt: to, czy plik istnieje, decyduje o włączeniu lub wyłączeniu danej funkcjonalności.

Usuń katalog sandbox/, a sandbox zniknie. Umieść plik memory.py w katalogu głównym, a wtedy włączy się trwała pamięć. Dodaj plik schedules/daily_digest.py, a przy następnym rozruchu zostanie utworzona usługa cron LangSmith; usuń ten plik, a usługa cron zostanie usunięta.

Każdy, kto pisał w Terraformie, rozpozna ten model. Jest to infrastruktura deklaratywna w składni Pythona – opisujesz pożądany stan, a mda deploy dopasowuje rzeczywistość do niego.

Struktura ma sens dopiero po zobaczeniu, co zawierają pliki, więc oto one, jeden po drugim.

agent.py – jedyny wymagany plik

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 to jedyny wymagany argument, który służy zarówno jako identyfikator asystenta LangGraph, jak i domyślna nazwa implementacji. Ponadto funkcja define_deep_agent przyjmuje parametry tools, middleware, subagents, permissions, interrupt_on (dla zatwierdzenia przez człowieka) oraz response_format (strukturyzowany wynik).

Zobaczmy, czego brakuje: nie ma żadnego promptu systemowego, konfiguracji pamięci, środowiska sandbox ani harmonogramów. Wszystko to jest sterowane wyłącznie plikami, a nie ma możliwości ich konfiguracji w kodzie, nawet jeśli byśmy tego chcieli.

Wbudowane narzędzia wyszukiwania po stronie serwera nie wymagają klucza dostawcy, chociaż każdy dostawca oczekuje słownika narzędzi o innej strukturze, co stanowi łatwe źródło błędów:

tools=[{"type": "web_search"}]                                # OpenAI
tools=[{"google_search": {}}]                                 # Google
tools=[{"type": "web_search_20260209", "name": "web_search"}] # Anthropic

Gdy w śladzie w ogóle nie pojawia się wyszukiwanie, to właśnie ta niezgodność jest niemal zawsze przyczyną.

instructions.md i skills/

Tutaj znajduje się kontekst synchronizowany z chmurą. Plik z instrukcjami może zawierać następujący tekst:

# Research assistant

You are a careful research assistant. Use internet search to find sources,
keep notes, and return concise answers with citations.

Staje się to promptem systemowym, wstawianym przy każdym uruchomieniu. Umiejętności zachowują się inaczej. Każda z nich znajduje się we własnym katalogu, wraz z metadanymi:

---
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.

Gdy agent się uruchamia, widzi jedynie nazwę i opis każdej umiejętności. Zadanie pasujące do niej sprawia, że agent czyta cały plik SKILL.md, a pliki pomocnicze są ładowane w razie potrzeby. To właśnie jest progresywne ujawnianie informacji, tak jak w narzędziu open-source.

Korzystny szczegół operacyjny: podczas wdrażania plik instructions.md oraz cała struktura katalogu skills/ są wysyłane do LangSmith Context Hub. Następnie można je edytować w interfejsie użytkownika bez konieczności ponownego wdrażania, więc edycja promptu nie oznacza już konieczności ponownego budowania aplikacji. Każdy, kto musiał przeprowadzić proces CI tylko po to, by poprawić błąd ortograficzny w promptie systemowym, rozumie ten pomysł.

memory.py: trwała pamięć, opcjonalna

from managed_deepagents import define_memory
memory = define_memory(scope="agent")

To tylko te dwie linijki są potrzebne, a bez nich agent nie posiada żadnej trwałej pamięci. Może to zaskoczyć osób, które zakładają, że pamięć jest standardem.

Jej włączenie montuje jeden drzewo Context Hub w katalogu /memories/agent/. Plik AGENTS.md znajdujący się w tym drzewie stanowi pamięć aktywną, ładowaną do kontekstu przy każdym uruchomieniu. Wszystko inne to pamięć pasywna, którą agent odczytuje tylko wtedy, gdy jest to konieczne. Odczyty i zapisy odbywają się za pomocą standardowych funkcji read_file, edit_file i write_file, a zapisy w innych lokalizacjach, w tym w innych ścieżkach pod katalogiem /memories/, nie są trwałe. Wynika z tego określony efekt projektowy, który zostanie omówiony dalej.

sandbox/ i jego krok tworzenia kopii

from managed_deepagents import define_sandbox
sandbox = define_sandbox(
    idle_ttl_seconds=600,
    default_timeout=600,
    docker_image="python:3.12-slim",
)

Każda trwała nit otrzymuje własną przestrzeń sandbox, wspieraną przez LangSmith Sandboxes. Opcjonalny plik sandbox/setup.sh jest uruchamiany raz przy użyciu bash -e, a jego wynik jest zapisywany jako snapshot, który nowe nity klonują zamiast ponawiać konfigurację:

#!/usr/bin/env bash
set -euo pipefail

apt-get update && apt-get install -y jq
mkdir -p /workspace

Warto znać dwa pułapki. Wartości z pliku .env są dostępne podczas wykonywania setup.sh, co ułatwia klonowanie prywatnego repozytorium, ale wątki klonujące zrzut stanu nigdy ich nie otrzymują. Ponadto wszystko, co zostanie zapisane na dysku podczas konfiguracji, trafia do obrazu każdego wątku, co uniemożliwia przechowywanie tam tajemnic.

schedules/: cron z regułą z czasu kompilacji

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.",
)

Dla każdego harmonogramu istnieje jeden plik, a nazwa tego pliku staje się nazwą harmonogramu. Musi zostać podana dokładnie jedna z wartości prompt lub input. Akceptowany jest tylko cron z pięcioma polami, więc wyrażenia oparte na sekundach powodują niepowodzenie kompilacji. Jeśli nie określono strefy czasowej, stosuje się UTC.

Restrykcją, która najprawdopodobniej sprawi problemy, jest to, że deklaracje harmonogramów są wyodrębniane w czasie kompilacji i muszą być statycznie serializowalne. Nie wolno używać zmiennych środowiskowych, wywołań funkcji, **kwargs ani wartości obliczanych. Literale i stałe najwyższego poziomu są dozwolone. Wszystko, co dynamiczne, powinno znajdować się zamiast tego w agencie, narzędziach lub middleware.

Każdy wykonywany proces zazwyczaj korzysta z tymczasowego wątku, który jest usuwany po zakończeniu pracy. Wykonania zaplanowane tak, aby budować stan, wymagają zamiast tego użycia thread={"mode": "persistent", "id": "nightly-memory"}.

channels/ i connectors/

Kanał otrzymuje wiadomości rozpoczynające prace, natomiast connector dostarcza agentowi narzędzia. Każdy z nich to pojedynczy plik:

# 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"],
        },
    },
)

Ścieżka routingu odpowiada nazwie pliku. channels/slack.py udostępnia swój punkt końcowy Events pod adresem /channels/slack/events, a narzędzia MCP używają nazwy serwera jako prefiksu, chyba że zostanie inaczej określone, dlatego ten connector pojawia się jako langchainDocs__search_docs_by_lang_chain. Serwery Stdio MCP nie są dostępne – dostępne są jedynie Streamable HTTP oraz starsze rozwiązania SSE.

identity.py: kto może wywoływać agenta

from managed_deepagents import auth, define_identity
identity = define_identity(auth=auth.langsmith_api_key())

To jest to, co mda init generuje jako bezpieczny standard. Wywołujący wysyłają klucz przestrzeni roboczej LangSmith w nagłówku x-api-key. To decyduje o tym, czy ktoś może wezwać agenta, ale wszyscy korzystają wtedy z tych samych wątków. Aby zapewnić prywatność na poziomie użytkownika, konieczna jest migracja do Supabase:

identity = define_identity(auth=auth.supabase(project_ref="your-project-ref"))

Klienci wysyłają następnie Authorization: Bearer , a MDA sprawdza JWT w odniesieniu do punktu końcowego JWKS projektu. Dokumentacja zawiera jedno ostrzeżenie dotyczące migracji: dodanie tego elementu do istniejącej implementacji nie przywraca metadanych właściciela do już istniejących wątków.

Co robi mda deploy

Dokumentacja wymienia jedenaście uporządkowanych kroków. Te, które są istotne:

1. Sprawdza projekt i ładuje plik agent.py.
2. W określonej kolejności znajduje klucze LangSmith (LANGGRAPH_HOST_API_KEY, LANGSMITH_API_KEY, LANGCHAIN_API_KEY) i odczytuje plik .env przed ustawieniami środowiska shell.
3. Zbiera każdą wartość z pliku .env, która nie jest zarezerwowana, i wysyła ją jako tajemnicę związana z implementacją.
4. Wgruje plik instructions.md oraz folder skills/ do Context Hub.
5. Kompiluje pliki do katalogu .mda/build i wgruje archiwum, którego rozmiar nie może przekroczyć 200 MB.
6. Czeka, sprawdzając status modyfikacji, aż zostanie on ustawiony na DEPLOYED.
7. Ujednolica zadania cron, znajdując wszystkie wcześniej utworzone harmonogramy, usuwając je wszystkie i tworząc nowy zestaw na podstawie aktualnego katalogu schedules/.

Siedmiym krokiem jest moment, w którym porównanie tego procesu z Terraformem przestaje być jedynie przenośnią – chodzi tu o korektę odchyleń, a działanie to jest podobne do terraform apply.

Zatem, podobnie jak w przypadku Terraform, istnieje flaga, która pozwala to cicho pominąć. Dodanie --no-wait sprawia, że interfejs wiersza poleceń rozpoczyna zdalną budowę i zamyka się, zanim status zmieni się na DEPLOYED, co oznacza, że proces nie dochodzi do kroku synchronizacji harmonogramu. Nowy cron nie istnieje, usunięty cron nadal działa, a proces deploy zgłasza sukces. Za każdym razem, gdy zmienia się harmonogram, należy wykonać polecenie mda deploy . bez użycia --no-wait. Linijka w podręczniku zasad zespołu to tanie ubezpieczenie.

Jakie jest jego miejsce w stacku LangChain

Obecnie istnieją cztery warstwy, a ludzie mają tendencję do ich mieszania.

LangChain dostarcza elementy budulcowe: modele, narzędzia, prompty. To fundament.

LangGraph to środowisko wykonawcze, które zapewnia trwałe, stanowe wykonywanie w formie grafu (trwałość danych, transmisja danych, przerwy). Można go uznać za silnik.

Deep Agents znajduje się na wyższym poziomie i stanowi „opaskę bezpieczeństwa”, zawierającą planer, system plików, podagenty, funkcję kompresji kontekstu oraz ustalone domyślnie ustawienia.

Managed Deep Agents to hostowany środowisko wykonawcze dla tej opaski bezpieczeństwa. Jest to ten sam Agent Server, który klienci LangSmith już używają w produkcji, ale zapakowany w sposób bardziej precyzyjny pod projekty Deep Agents.

Analogia z samochodem dobrze to ilustruje: LangGraph dostarcza silnik i skrzynię biegów, Deep Agents dostarcza samochód, a Managed Deep Agents dostarcza samochód, warsztat oraz osobę, która zmienia olej. Cena za to jest utrata możliwości otwarcia maski silnika. To uczciwa umowa, o czym jasno mówi dokumentacja. Każdy, kto potrzebuje dostosowanych ścieżek, kodu aplikacji oprócz struktury grafu lub bezpośredniej kontroli nad trwałością danych, powinien korzystać bezpośrednio z LangSmith Deployment.

Zakres pamięci wspólnej

Beta oferuje jeden zakres pamięci, agent: jedną drzewo odczytu/zapisu, które jest wspólne dla wszystkich użytkowników mogących uzyskać dostęp do implementacji.

Dokumentacja w niezwykle bezpośredni sposób opisuje dalsze zasady funkcjonowania. Pamięć jest współdzielona przez wszystkich użytkowników, a każdy z nich może na nią wpływać. Dlatego przechowuj tylko takie informacje, które wszyscy mogą odczytać i zmodyfikować, traktując istniejącą pamięć jako niepewny input, który nigdy nie powinien przyznawać uprawnień, zmieniać dostępów do narzędzi ani omijać procedur zatwierdzania.

To stanowi zasadę bezpieczeństwa. Plik AGENTS.md jest ładowany do kontekstu systemu przy każdym uruchomieniu, więc cokolwiek użytkownik A zapisał we wtorek, trafia trwale do kontekstu użytkownika B w środę. Dla narzędzia wewnętrznego używanego przez jedyną zespół to w porządku. W przypadku rozwiązania przeznaczonego dla wielu użytkowników stanowi to kanał do wstrzykiwania poleceń z warstwą trwałości.

To, co pogarsza sytuację dla tych, którzy dbają o ocenę i obserwowalność, to fakt, że awaria nie pojawi się w wynikach ocen. Zadania Harbor oceniają stan przestrzeni roboczej po zakończeniu wykonywania, a one nie uwzględniają możliwości, że ktoś mógłby zapisać dane do pamięci w czasie rzeczywistym tydzień wcześniej.

Sama rada zawarta w dokumentacji jest słuszna: należy unikać pamięci wspólnej, gdy funkcje nie powinny wpływać na siebie nawzajem. Dopóki nie pojawi się mechanizm zarządzania pamięcią na poziomie użytkownika, stanowi to rzeczywisty ograniczenie w tworzeniu nowych rozwiązań.

Powierzchnia, która wciąż się zmienia

Praktyczne ostrzeżenie przed kopiowaniem jakiegokolwiek kodu. Post z informacjami o uruchomieniu pochodzi z 7 sierpnia, podczas gdy dokumentacja ciągle się zmienia. W ciągu około trzech tygodni zmieniło się czterech publicznych API, a każdy, kto buduje aplikacje na podstawie przykładów z tego ogłoszenia, napotka wszystkie cztery z nich.

• Pamięć: w komunikacie stwierdza się, że każde wdrożenie rozpoczyna się od pamięci skonfigurowanej dla agenta, natomiast dokumentacja opisuje pamięć trwałą jako opcję, która jest wyłączona domyślnie.
• Sandboxy: w komunikacie używane jest define_sandbox(provider="langsmith", scope="thread") i wspomina się o wspólnej przestrzeni agent; strona referencyjna wymienia idle_ttl_seconds i default_timeout oraz stwierdza, że jeden sandbox zawsze odpowiada jednemu wątkowi.
• Tożsamość: w komunikacie mowa jest o konfiguracji dostawcy OIDC w pliku identity.py, ale strona dotycząca tożsamości omawia jedynie klucze API LangSmith i Supabase.
• Slack: w komunikacie używane jest channels.slack(on=[...]), natomiast w przewodniku dla Slack nie ma argumentu on, a subskrypcje na wydarzenia umieszcza się w manifestie aplikacji Slack.

Dokumentacja również nie zawsze jest spójna sama ze sobą. Na jednej stronie komenda nazywana jest mda channel init slack, a na innej mda channel add slack .; flaga --configure-slack dla mda deploy . jest opisana w przewodniku dla Slacka, ale nie występuje w tabeli referencyjnej interfejsu wiersza poleceń.

To nie oznacza, że produkt jest słaby. Oznacza po prostu, że mamy do czynienia z wersją beta narzędzia deklaratywnego, w którym interfejs to jedyna rzecz, której nikt nie powinien zgadywać. Gdy dokumentacja i tabele się różnią, decyduje mda --help.

Kiedy to się sprawdza, a kiedy nie

Managed Deep Agents ma sens w następujących sytuacjach:

• jeśli już budujesz na platformie Deep Agents, a infrastruktura stanowi wąskie gardło
• jeśli agent potrzebuje trwałych wątków, zadań zaplanowanych lub interfejsu w Slacku
• jeśli prompty i umiejętności powinny być edytowalne bez konieczności ponownego wdrożenia

wszyscy dzwoniący korzystają z jednego obszaru zaufania

jeśli znajdujesz się w USA, bezproblemowe uruchamianie odbywa się z terminala

Wybierz sam LangSmith Deployment lub sam zainstaluj otwarte oprogramowanie, gdy:

• Twój własny backend musi wywoływać agenta. Wersja beta opiera się przede wszystkim na interfejsie CLI, podczas gdy API jest jeszcze w fazie finalizacji, a ponowne uruchomienie przerwanej sesji w sposób programowy oznacza konieczność zapytania o to swojego kontaktu w LangChain, zgodnie z dokumentacją. To całkowicie uniemożliwia takie zastosowanie.
• dzwoniący muszą mieć dostęp tylko do własnej pamięci.
• potrzebne są niestandardowe ścieżki lub bezpośrednia kontrola nad trwałością danych.
• dane muszą pozostać poza granicami USA.
• Slack działa na kilku replikach. Obecnie deduplikacja zdarzeń odbywa się lokalnie w procesie, więc ponowna próba z Slack może uruchomić agenta dwa razy, a narzędzia dostępne z kanału muszą być idempotentne, jeśli wywołują efekty uboczne.

Próba wykorzystania

Zainstaluj i utwórz szkielet:

uv tool install managed-deepagents
mda init test-agent && cd test-agent

Następnie umieść klucze w pliku .env:

LANGSMITH_API_KEY=<your-key>
OPENAI_API_KEY=<your-key>

Zanim cokolwiek napiszesz, uruchom ls w katalogu utworzonym przez narzędzie scaffolding. Pięć minut spędzone na przeglądaniu tego katalogu nauczy cię więcej o modelu produktu niż sama informacja oficjalna.

Następnie polecenie uv sync && mda dev . buduje projekt, tworzy lokalną wersję Context Hub (obejmującą instrukcje, umiejętności i pamięć) oraz uruchamia LangSmith Studio w karcie przeglądarki. Narzędzie nie aktualizuje plików projektu w czasie rzeczywistym, więc po wprowadzeniu zmian należy je zatrzymać i uruchomić ponownie. Oficjalny przewodnik szybkiego rozpoczęcia pracy znajduje się w dokumentacji LangSmith dla Pythona, w sekcji Managed Deep Agents.

Zespoły, które już używają Deep Agents i samodzielnie konfigurują ich implementację, powinny mieć na to całe popołudnie. Model katalogowy to dobry pomysł, a braki w wersji beta można obejść, gdy tylko zostaną zidentyfikowane.

Literatura pokrewna

• Dlaczego agenty długoterminowe potrzebują narzędzi wspomagających: jak deep agenty zarządzają stanem i kontekstem — Szczegółowe spojrzenie na deep agenty: problem zepsucia kontekstu, cztery filary architektury, middleware, profile narzędzi wspomagających, backendy systemu plików, izolowane podagenty, błędy w skrajnych przypadkach oraz alternatywy.
• Stwórz agent planowania w LangGraph: planowanie, wykonywanie, ponowne planowanie, raportowanie — Agent planowania składający się z czterech węzłów w LangGraph do badań finansowych: ustrukturyzowane plany, rejestr narzędzi uwzględniający przestrzeń nazw, ograniczenia dotyczące ponownego planowania oraz przykład wykonania z śledzeniem procesu.

Wyjaśnienie pamięci agenta: praca, epizodyczna, semantyczna i proceduralna — Agent naprawiał ten sam błąd dwa razy, ponieważ nic nie przechowywało wyniku. Poznaj cztery typy pamięci, w jaki sposób każdy z nich zawodzi oraz gdzie co przechowywać.

Strumieniowanie Deep Agents w LangChain: plany na żywo, wywołania narzędzi i tokeny — Zastąp blokujące wywołanie strumieniem, aby użytkownicy mogli zobaczyć, jak działa agent typu deep: trzy tryby strumieniowania, nazwy przestrzeni dla podagentów oraz filtrowanie tokenów podsumowujących.