devgo.cn核心观点
- Managed Deep Agents 以 API 优先的方式把开源 Deep Agents harness 搬进 LangSmith：`/v1/deepagents` 接口可编程创建、更新、运行长期运行的 Agent，无需自建 Agent Server。
- 定位清晰：构建 Agent 越来越容易，运行 Agent 才是难点——持久化执行、流式、记忆、文件、工具、人工审批、沙箱、追踪，自建的成本远高于模型调用本身。
- Agent 定义以熟悉的项目形态（AGENTS.md、skills/、subagents/、tools.json）托管在 LangSmith 并版本化；Context Hub 提供跨运行的可更新上下文。
- 与 LangSmith Engine 打通后，Agent 可在运行间隙复盘真实对话、从使用中学习并更新 Context Hub 文件，实现「从实际工作改进自己」。
内容精讲
2026 年的 Agent 开发有一个明显落差：写出一个能用的 Agent 越来越容易，把它跑进生产却依旧艰难。长期运行的 Agent 需要的不是一次模型调用，而是一整套配套——持久化执行、流式输出、跨轮次记忆、文件与工具访问、人工审批（human-in-the-loop）、沙箱执行、全链路追踪，以及持续改进的闭环。团队可以自己搭，但在 Agent 触达用户之前就得先维护一整套运行时基础设施：文件存储、工具配置、沙箱、线程状态、追踪、反馈回路。Managed Deep Agents 把这一层运维打包进托管运行时，让开发者把精力放回 Agent 行为本身。
**API 优先的发布形态。** 这套托管运行时在私有测试阶段就采用 API-first 设计：开发者通过 Managed Deep Agents API 创建、更新、管理并运行 Agent，再上传或引用定义它的文件（指令、技能、子 Agent、工具配置）。之后从自有应用或平台工作流里创建 thread、流式运行 run，全程不需要部署自定义 Agent Server。API 面位于 `/v1/deepagents`。
**Agent 定义可以进化。** Managed Deep Agents 保留 Deep Agents 熟悉的项目形态：AGENTS.md、skills/、subagents/、tools.json 分别定义行为、可用工具、可加载技能和可委派的子 Agent。这些文件被托管在 LangSmith 并做版本化——Agent 定义随时间演进，而不是发布后冻结。这回应了生产 Agent 的真实生命周期：指令和工具需要根据线上反馈持续调整。
**Context Hub：跨运行的持久上下文。** 长期 Agent 的上下文必须在时间上存活。Context Hub 给 Agent 一个托管的位置来保存并更新它「知道」的东西——用户偏好、项目细节、研究笔记、操作规程。默认情况下这些内容来自部署时的提示词，而 Context Hub 让它能随真实使用持续更新。配合 LangSmith Engine，Agent 能在两次运行之间复盘对话、从实际工作学习、更新 Context Hub 文件：比如一个支持分类 Agent，发现用户反复问同一个内部流程，就自动更新自己的操作规程。
**工具、沙箱与可见性。** 工具通过 tools.json 配置（与 Deep Agents 同一套模型），任何工具都可开启 human-in-the-loop；需要代码、shell 和文件 I/O 的工作流支持沙箱后台执行——分析数据、处理文件、跑脚本、产出工件，无需每个 Agent 重建工具与沙箱配置。所有运行自动追踪进 LangSmith，工具调用、中间步骤、行为调试都在熟悉的观测界面里。
**适用画像与价值。** 这类托管运行时瞄准的是需要长时间工作、使用工具、保留上下文并产出工件的 Agent：跨长线程工作的支持与分类 Agent（记住前情、需要时升级、从重复问题更新操作规程）、研究 Agent（收集来源、写笔记）、编码与数据类 Agent。构建者在「长时 + 有状态 + 需审批」的场景里，不再需要把运行时当副业来养。
阅读价值
对 Agent 基础设施选型者，这是托管运行时形态的样板：API 面、项目结构、Context Hub、自动改进闭环四件套可对照评估；对用 LangChain 栈的团队，它指明了从开源 harness 平滑过渡到托管运行时的路径。
内容与图片版权归原作者所有 · 原文: https://www.langchain.com/blog/introducing-managed-deep-agents