DeerFlow 2.0：字节跳动开源的“超级智能体运行框架”，把子智能体、记忆和沙箱装进一个运行时

DeerFlow 的全名是 Deep Exploration and Efficient Research Flow，最初是字节跳动开源的深度研究框架。README 讲了这个项目后来的变化：社区把它用到了数据管道、生成幻灯片、搭建仪表盘和自动化内容流程上，这些都是团队没有预想到的用法。团队因此认识到，DeerFlow 不只是一个研究工具，而是一个“运行框架”（harness），为智能体提供真正完成工作所需的基础设施，于是决定从头重写。2.0 与 1.x 不共享任何代码，原来的深度研究框架保留在 1.x 分支，活跃开发已经转到 2.0。官方还写道，2.0 发布后，DeerFlow 在 2026 年 2 月 28 日登上了 GitHub Trending 第一名。截至 2026 年 10 月 13 日，仓库约有 83,766 个星标、11,654 个派生，MIT 许可，用 Python 编写，创建于 2025 年 5 月 7 日，最近一次推送就在 10 月 13 日。

按 README 的定义，DeerFlow 2.0 不再是一个需要自己拼装的框架，而是“开箱即用、可完全扩展”的超级智能体运行框架：基于 LangGraph 和 LangChain，自带文件系统、记忆、技能、能感知沙箱的执行，以及规划并派生子智能体处理多步骤复杂任务的能力。它是模型无关的，只要实现了兼容 OpenAI 的接口就可以使用，官方更推荐有长上下文（10 万词元以上）、推理能力、多模态输入和可靠工具调用的模型，并明确建议使用 Doubao-Seed-2.0-Code、DeepSeek v3.2 和 Kimi 2.5 来运行。搜索与抓取方面，它集成了字节跳动 BytePlus 自研的 InfoQuest 工具集，支持免费在线体验。

核心特性可以归为几块。技能与工具：工作区侧栏里的“能力中心”（Capability Center）可以管理插件（MCP 服务器与飞书集成）和技能，内置技能与用户创建或导入的技能分开列出，社区页支持导入 .skill 压缩包。子智能体：每个子智能体默认运行在独立上下文中，看不到主智能体或其他子智能体的内容，这样能让它专注于手头任务；task 调用支持 isolated（默认）和 snapshot 两种模式，snapshot 会把父智能体保留的对话和压缩摘要作为历史背景交给子智能体，代价是更多输入词元。上下文工程：会话内主动做摘要，把已完成子任务的结果卸载到文件系统，压缩不再需要的内容，使它能在多步骤长任务里不撑爆窗口；对工具输出还有预览预算和结构化摘要。长期记忆由名为 DeerMem 的组件负责，按对话、用户和智能体分别做去抖，默认安静期 30 秒，最长等待 300 秒。另外还有会话目标、手动上下文压缩、聊天归档、项目与文档架、定时任务（可预览 cron 触发时间，并有生命周期与安全上限），以及嵌入式 Python 客户端和终端工作台。

运行方式在 README 里分得很细。快速开始部分先配置模型，再选择运行方式，推荐 Docker，也可以本地开发，并可选用 LangGraph Studio 调试；对已有检出的升级、多模型提供方、已存在运行的流式操作、个人访问令牌等都有专门章节。沙箱部分尤其值得看：AIO 沙箱在不确定的隐式 shell 结果或会话创建之后会被回收，回收前网关会把容器 ID 或 Pod UID 记录到隔离目录，这些记录在停止失败和网关重启后仍然保留；只有在后端确认没有残留容器或 Pod 之后，才会清除旧记录，不能把“删除确认”或“健康检查失败”当作充分证据。这种对失败路径的保守处理，说明它是为了长时间无人值守的使用场景写的。

最该提前读的是安全章节。README 说，DeerFlow 具有系统命令执行、资源操作和业务逻辑调用等高权限能力，默认设计为部署在本地可信环境中，也就是只通过 127.0.0.1 回环地址访问。如果把它放在局域网、公有云服务器等多终端可访问的环境里而没有严格措施，会有未授权调用、被互联网扫描器发现后批量触发高风险操作，以及合规和法律风险。Docker 栈默认只在 127.0.0.1 发布入口端口，本地的 make dev 和 make start 也只绑定回环；要从别的机器访问，需要在 .env 里设置 BIND_HOST，并且应当先做好措施：用 iptables 或硬件防火墙做 IP 白名单，用 nginx 之类的反向代理开启强认证，把智能体和可信设备放进专用 VLAN。全新实例没有账号，任何不是仅回环的部署都应在启动后立即通过 /setup 创建管理员账号。README 还特别说明：网关管理员可以注册 stdio MCP 服务器，这些会在网关容器里执行命令；接口只允许默认的 npx、uvx 等白名单命令，并拒绝能求值任意代码的参数，但这只是纵深防御而不是边界，必须把网关管理员视为等同于主机上的代码执行权限。

我们的判断是，DeerFlow 2.0 值得读的是它的工程取舍，而不是星标数。它把子智能体隔离、上下文摘要、文件系统卸载、沙箱回收这些通常藏在内部的细节写进了文档，对想自己搭智能体基础设施的人是一份难得的参照。需要保留的有三点：其一，README 篇幅很大，功能迭代很快，很多章节描述的是当前源码的行为，部署前应对照具体版本；其二，它的威力和风险来自同一件事，也就是能执行命令和读写文件，所以默认的本地回环绑定不应被随手改掉；其三，模型推荐里有明显的厂商倾向，实际效果仍取决于你接入的模型与任务。建议先在隔离的容器里、用只含测试数据的目录运行，再决定是否接入真实数据和外部渠道。