Deep Agents 评测：LangChain 全家桶里的“带电池”代理框架，值不值得用
包括电池的代理安全带。当您想要一个更轻的安全带而不需要捆绑中间件时，请使用 LangChain 的 create_agent。
秒懂
- 它是什么？
- Deep Agents 是 LangChain 官方推出的“开箱即用”代理框架，内置文件系统、子代理、上下文管理等功能。本文基于仓库文档和发布信息，分析它的定位、机制、上手方式，以及它和 LangGraph、create_agent 的边界。
- 适合谁用？
- Deep Agents 适合需要快速构建多步骤、长上下文任务的团队，尤其是已经使用 LangChain 或 LangGraph 的工程。它把文件系统、子代理、上下文管理这些常见需求打包好了，你不需要自己拼装。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，为谁准备
Deep Agents 解决的是“代理框架选型”中的一类痛点：当你需要多步骤、长时长的任务，比如研究、写代码、操作文件，你不想从零搭一个代理循环。LangGraph 是图运行时，create_agent 是最小化的代理封装，而 Deep Agents 在这个基础上加了一层“默认配置”。它自称是“batteries-included agent harness”，意思是把文件系统、子代理、上下文管理、shell 访问这些能力都内置了。目标用户很明确：正在使用 LangChain 生态，需要快速构建生产级代理的工程师。
架构层次：LangGraph、create_agent 与 Deep Agents 的关系
从 README 的 FAQ 可以清楚看到三层关系。LangGraph 是底层图运行时，它管理状态、流式输出、持久化。create_agent 是 LangChain 提供的最小代理封装，它只负责工具调用的循环。Deep Agents 则是在 create_agent 之上构建的“更固执己见”的封装，它把文件系统、子代理、上下文管理、技能这些中间件捆绑进来。这里的关键设计是“可组合性”：任何 LangGraph 的 CompiledStateGraph 都可以作为子代理传给 Deep Agent。这意味着你可以把自定义的图编排逻辑插入到 Deep Agents 的默认流程中，而不需要 fork 整个项目。
核心机制：子代理与上下文管理
Deep Agents 的核心机制之一是子代理，它允许主代理将任务委托给具有独立上下文窗口的子代理。这在长任务中很有用，因为子代理可以隔离上下文，避免主代理的上下文被无关信息污染。另一个机制是上下文管理，它能够总结长线程，并将工具输出卸载到磁盘。这解决了 LLM 上下文窗口有限的问题。你需要理解的是，这些机制不是简单的“调用工具”，而是由框架内置的中间件在代理循环中自动处理的。例如，当工具输出过大时，框架会自动将其写入磁盘，而不是全部塞进上下文。
快速上手：真实命令与配置
安装和启动非常简单。README 给出的命令是 `uv add deepagents`，这是一个 Python 包，通过 uv 安装。然后你导入 `create_deep_agent` 函数，传入模型标识和工具列表。示例代码是：`agent = create_deep_agent(model="openai:gpt-5.5", tools=[my_custom_tool], system_prompt="You are a research assistant.")`。注意模型标识符是 `openai:gpt-5.5`，这是 LangChain 的标准格式。调用 `agent.invoke({"messages": "Research LangGraph and write a summary"})` 即可运行。它支持任何支持工具调用的模型，包括本地模型，通过 Ollama、vLLM 或 llama.cpp 部署。
安全模型：信任 LLM 的代价
README 的安全部分明确说，Deep Agents 遵循“信任 LLM”的模型。这意味着代理可以执行其工具允许的任何操作，框架不会主动限制模型的行为。文档建议在工具或沙箱层面强制执行边界，而不是期望模型自我约束。这是一个重要的设计取舍。对于内部工具链，这可能没问题，但如果你的代理需要访问敏感系统，你必须确保沙箱环境是严格隔离的。否则，一个被提示注入的模型可能会执行任意命令。这是采用 Deep Agents 时最需要认真对待的约束。
开发与调试：LangSmith 的整合
Deep Agents 构建在 LangGraph 之上，因此天然支持流式输出、持久化和检查点。文档提到它与 LangSmith 有“first-class”的集成，用于追踪、评估和部署。这意味着你可以用 LangSmith 来调试代理的每一步操作，查看工具调用、上下文管理事件等。对于生产环境，文档专门有一节“Going to production”的指南，说明它被设计为可用于生产。但注意，LangSmith 是 LangChain 的商业产品，使用它需要额外的成本。如果你不想依赖商业服务，你可能需要自己实现日志和监控。
替代方案与适用边界
如果你不需要 Deep Agents 捆绑的中间件，LangChain 的 `create_agent` 是一个更轻量的选择。它只提供基本的工具调用循环，没有文件系统或子代理。如果你需要完全自定义的编排逻辑，比如非线性的工作流，那么直接使用 LangGraph 更合适。Deep Agents 的定位是“开箱即用”，但这也意味着它的默认行为可能不适合所有场景。例如，如果你只需要一个简单的问答代理，使用 create_agent 会更简单，避免引入不必要的复杂度。
维护与许可
Deep Agents 使用 MIT 许可证，这是一个宽松的开源许可，允许商业使用、修改和分发。仓库显示最近的发布频率较高，0.7.11 版本在 2026 年 8 月 28 日发布，说明项目处于活跃维护状态。作为 LangChain 官方项目，它有持续的支持和社区讨论。但需要注意，它的依赖包括 LangGraph 和 LangChain，这些库的更新可能会影响 Deep Agents 的行为。升级时，你需要关注依赖的兼容性。另外，README 提到 Deep Agents 还提供了 JavaScript/TypeScript 版本（deepagents.js），这可能会增加维护成本，如果你在多语言环境中使用。
编辑结论
Deep Agents 适合需要快速构建多步骤、长上下文任务的团队，尤其是已经使用 LangChain 或 LangGraph 的工程。它把文件系统、子代理、上下文管理这些常见需求打包好了，你不需要自己拼装。但如果你只需要一个简单的工具调用循环，或者你的编排逻辑不是标准的“代理循环”，那么 create_agent 或直接使用 LangGraph 更合适。在决定采用之前，先验证两点：你的模型是否支持工具调用，以及你的沙箱环境能否满足 Deep Agents 的“信任 LLM”安全模型。如果你需要严格的权限控制，必须自己实现工具级别的边界，不能依赖模型自我约束。
社区笔记