LangChain 在 2026 年 5 月 13 日推出 Managed Deep Agents private beta。這個更新值得注意，因為它切中的不是「怎麼寫一個 agent demo」，而是「一個 deep agent 要怎麼長時間可靠運作」。
很多團隊現在已經可以用 LangChain、LangGraph、Claude Code、Deep Agents 或其他框架做出原型。真正卡住的地方通常是 production runtime：執行中斷怎麼恢復、工具權限怎麼控、檔案怎麼保存、上下文怎麼版本化、trace 怎麼檢查、人類審核怎麼插入。
Managed Deep Agents 的定位，就是把這些 agent operational layer 放進 LangSmith。
Managed Deep Agents 是什麼？
Managed Deep Agents 是 API-first 的 hosted runtime，讓開發者可以建立、更新、管理和執行 deep agents。
它保留 Deep Agents 的專案形狀，例如：
AGENTS.md。skills/。subagents/。tools.json。
但 agent 的 durable execution、thread、checkpoint、context、sandbox 和 tracing 由 LangSmith 提供。換句話說，團隊仍然在 repo 裡定義 agent 行為，但不用自己重新架一套 agent server。
它解決哪一層問題？
一般 LLM application 只要接收輸入、呼叫模型、回傳結果。Deep agent 不同，它可能需要：
- 連續跑很久。
- 讀寫檔案。
- 使用多個工具。
- 委派 subagent。
- 等待人工批准。
- 保留跨任務 context。
- 從前一次失敗恢復。
- 產出 artifacts。
- 被 tracing 和 eval 監控。
這些不是 prompt 本身能解決的問題，而是 runtime 問題。
核心能力整理
| 能力 | 對 production agent 的意義 |
|---|---|
| Durable threads | 任務不中斷，或中斷後可以恢復 |
| Checkpointing | 重要步驟可保存狀態，降低長任務失敗成本 |
| Streaming runs | 前端或內部工具可以即時看到 agent 進度 |
| Human-in-the-loop | 高風險工具呼叫前可以暫停審核 |
| Context Hub | 保存使用者偏好、流程筆記、任務狀態與操作準則 |
| Tools and sandboxes | 讓 agent 能執行程式、操作檔案、產出 artifacts |
| LangSmith tracing | 追蹤每次 model call、tool call、context 使用與錯誤 |
這些能力放在一起，代表 agent 從「一次性執行」往「可營運系統」移動。
和一般 tool calling 有什麼不同？
Tool calling 通常解決的是「模型可以呼叫某個函式」。Managed Deep Agents 解決的是「一個會呼叫工具、會保留狀態、會產出檔案、可能跑很久的 agent，要在哪裡可靠執行」。
差異可以這樣看：
| 類型 | 核心問題 |
|---|---|
| Tool calling | 這次回合要不要呼叫工具？參數是否正確？ |
| Agent framework | agent 怎麼規劃、呼叫工具、組合步驟？ |
| Agent runtime | agent 長時間執行、保存狀態、審核、恢復與監控怎麼做？ |
Managed Deep Agents 屬於第三層。
適合哪些場景？
比較適合的場景包括：
- Support triage agent：處理長對話、查內部文件、整理工單、必要時升級。
- Research agent：跨多次 session 收集資料、寫筆記、保留來源和中間結論。
- Coding agent：需要 filesystem、shell、測試、diff、修正與重跑。
- Data analysis agent：執行程式、保存圖表、整理 artifacts。
- Internal ops agent：處理 onboarding、政策查詢、流程協調與例外案件。
這些任務的共同點是：不是一次模型回答就結束，而是需要狀態、工具、檔案和可追蹤的執行過程。
導入前要問的問題
企業評估 Managed Deep Agents 或類似 runtime 時，可以先問：
- Agent 需要跑多久？是秒級、分鐘級，還是跨天任務？
- 哪些工具可以自動呼叫？哪些必須人工審核？
- Sandbox 能接觸哪些檔案、網路和 credentials？
- Trace 是否會保留敏感資料？
- Context Hub 裡的知識誰可以改？誰負責審核？
- 成本要用 agent、team、workflow 還是 tool call 來追？
- 失敗後要重跑全部，還是從 checkpoint 繼續？
如果這些答案不清楚，agent 上 production 之後通常會變成難以維護的黑盒。
和 LangSmith evaluation 的關係
Managed Deep Agents 自動接到 LangSmith tracing，這讓後續 evaluation 更自然。
實務上可以形成這個循環：
- Agent 在 managed runtime 執行。
- 每次 run 都留下 trace。
- Trace 中的失敗案例被轉成 eval dataset。
- 團隊比較 prompt、model、tool schema 或 workflow 版本。
- 較好的版本重新部署。
- Production trace 繼續補回新的測試案例。
這也是為什麼 agent runtime 和 agent evaluation 會越來越靠近。沒有 trace，就很難知道 agent 到底在哪一步做錯；沒有 eval，就很難判斷修改是否真的變好。
官方來源
結論
Managed Deep Agents 的訊號很清楚：agent 競爭已經不只是在模型和 prompt，而是在 runtime、context、sandbox、tracing、evaluation 和 governance。
如果團隊只做小型 demo，不一定需要這種 managed runtime。但只要 agent 開始處理長任務、真資料、真工具和真使用者，就不能只問「它會不會完成任務」，還要問「它失敗時能不能被看見、被恢復、被改善」。