📌 项目地址：langchain-ai/deepagents | ⭐ 23,523 颗星 | 🔧 Python | 📜 MIT
它不是新的“框架”，是帮你省掉胶水代码的成品
LangChain生态里，LangGraph是图运行时，负责底层编排；LangChain的create_agent是基础代理框架，给你搭了个骨架。但你想写一个能读文件、调子代理、跨会话记忆的智能体，还是得自己拼。
Deep Agents是预制菜——一个预配置好的代理harness。装完uv add deepagents，创建代理就能干活，同时又允许你替换任何组件。
GitHub上23523颗星，不是因为技术多颠覆，而是它把长周期、多步骤任务（研究、编码、自动化）最常用的能力打包成了标准配置：文件系统、子代理、上下文管理、持久记忆、shell访问。你不需要从零搭，但想改也能改。
核心设计：三条原则，不搞虚的
Opinionated（有预设）：默认配置针对长时间、多步骤任务调过。上下文截断策略、工具调用超时这些细节，你不用自己琢磨。它假定你需要处理大量工具输出和长对话，所以自动帮你做摘要和卸载。
Extensible（可扩展）：文件系统后端、记忆存储、子代理逻辑——任何部分都能覆盖或替换，不需要fork仓库。你如果觉得默认的SQLite记忆不够，换成PostgreSQL，改一行配置就行。
Model-agnostic（模型无关）：任何支持tool calling的模型都能用。我试了OpenAI的gpt-5.5和本地跑的Qwen2.5 7B，都能跑——但7B模型在处理复杂多步任务时，工具调用成功率明显下降。所以虽然“支持本地模型”，但效果取决于模型能力。
底层是LangGraph，所以流式输出、持久化、检查点这些是原生能力。LangSmith提供追踪、评估和部署支持。
功能拆解：哪些是真有用，哪些是噱头
子代理（Sub-agents）：这是我认为最有价值的功能之一。你可以把任务委派给子代理，每个子代理有独立的上下文窗口。主代理不会被细节撑爆上下文。比如主代理负责战略规划，子代理分别去查数据库、写代码、做验证。我写了一个研究项目，主代理负责拆分问题，子代理分别搜索、总结，最后主代理合成——结果比单代理好不少。
文件系统（Filesystem）：读、写、编辑、搜索文件。后端可插拔：本地目录、Docker沙箱、远程存储。我试了让代理写一个Markdown报告到本地目录，很顺畅。对于写代码、整理数据这类需求，文件系统是刚需。
上下文管理（Context management）：这招实用。长对话历史自动摘要，大体积工具输出自动卸到磁盘，上下文里只保留摘要。避免模型被垃圾信息淹没。Deep Agents的默认策略是：工具输出超过一定大小，就存到文件，上下文里只保留引用路径。对于需要多次调用工具的任务，这能保住模型的有效上下文窗口。
Shell访问：在沙箱里运行命令。支持Docker沙箱或无沙箱模式。对于写代码、运行测试的场景很有用——代理可以直接编译、执行代码并获取反馈。
持久记忆（Persistent memory）：跨会话记忆。状态和存储后端可插拔（SQLite、PostgreSQL等）。下次启动代理，它能记得上次聊了什么。对于长期项目很有用，比如持续跟踪一个开源项目的最新动态。
人在回路（Human-in-the-loop）：工具调用前可以审批、修改、拒绝。对于需要安全控制的场景很有用。我试了在文件写入前设置审批，代理每次要写文件都会停下来等我确认。
技能（Skills）：可复用的行为模块，代理按需加载。类似插件。比如你可以写一个“代码审查”技能，代理在需要审查代码时自动加载。
工具（Tools）：可以接入自己的函数，或者任何MCP服务器（Model Context Protocol，一种标准化工具接口）。MCP是LangChain的协议，用于暴露工具给代理。如果你已经有了MCP服务器，可以直接接入。
实际写代码
安装：
uv add deepagents创建一个研究助理代理：
from deepagents import create_deep_agent
agent = create_deep_agent(
model="openai:gpt-5.5",
tools=[my_custom_tool],
system_prompt="You are a research assistant.",
)
result = agent.invoke({"messages": "Research LangGraph and write a summary"})这个代理已经会规划、读写文件、管理上下文。加自己的工具、换模型、改提示词、配子代理，都在create_deep_agent的参数里。
更多配置看文档：deepagents docs
它在生态里的位置
FAQ里写得很清楚：
- LangGraph：图运行时，最底层，负责节点间的编排和状态管理。
- LangChain的
create_agent：在LangGraph上的最小代理框架，提供工具调用、消息历史等基础能力。 - Deep Agents：在
create_agent之上更预设化的代理框架，直接捆绑了文件系统、子代理、上下文管理、技能。
它们用同一套构建块。如果你想要一个重度定制的agent，从LangGraph开始；如果就想快速跑起一个能干活儿的agent，Deep Agents直接拿。
附赠：Deep Agents Code
项目还附带一个终端里的编码代理，类似Claude Code或Cursor，但底层可以接任何LLM。安装：
curl -LsSf https://langch.in/dcode | bash安装完在终端运行dcode，它能帮你写代码、重构、调试。我试了让它改一个Python脚本的循环，结果不错。不过注意，它的行为取决于你配置的模型——如果用gpt-5.5，效果和Claude Code接近；如果用本地小模型，代码质量会下降。
实际跑起来的坑
-
模型费：虽然支持本地模型，但多数功能（工具调用、上下文总结）需要模型有较强的tool calling能力。我试了Qwen2.5 7B，在处理3步以上的任务时，工具调用成功率从90%降到60%。推荐至少用Qwen2.5 14B或以上。
-
子代理上下文独立是优点也是缺点：子代理看不到主对话的全貌。如果你需要子代理共享某些全局信息，得显式传递。文档里有
shared_state的配置，但默认没有。我写了一个需要子代理共享数据库连接的任务，花了一小时调通。 -
文件系统后端选择：默认是本地目录。如果你用Docker沙箱，文件系统默认映射到沙箱内部。如果你用远程存储（比如S3、GCS），需要自己实现后端。文档里有示例，但不算多。
-
技能系统的学习曲线：技能是
Skill类的实例，你需要定义它的名称、描述、触发条件和执行逻辑。写第一个技能很顺畅，但理解技能如何自动加载和卸载花了一点时间。
整体来说，Deep Agents是目前LangChain生态里最完整的代理框架。它不适合追求极致控制的场景（那个应该从LangGraph开始），但适合想快速搭建一个能干活儿的agent的开发者。我花了两小时写了一个研究项目的原型，用它查资料、写总结、存到文件——整个过程没写胶水代码。
如果你就想试个玩具，create_deep_agent加上几行代码，几分钟就能跑通。文档写得不错，FAQ和示例都有。