它是什么

DeerFlow（Deep Exploration and Efficient Research Flow）是字节跳动开源的一个「超级智能体挂载框架」（super agent harness），由 2.0 版本重新定义。它本身不是模型，也不是一个聊天客户端，而是一层编排系统：把一个复杂、跨越多轮的长期任务拆成可调度的步骤，交给子智能体、记忆、沙箱、工具与可扩展技能共同完成，最终产出研究报告、代码或内容成品。官方描述中把它定位为「long-horizon SuperAgent harness」，关键词是长周期——它假设任务不是一问一答，而是需要几十步、多次试错、反复调用外部能力才能收敛的那种。

背景上有一点必须说清楚：DeerFlow 2.0 是一次推倒重写，与 1.x 不共享任何代码。1.x 就是早期广为流传的那个 Deep Research 框架，目前仍在 1.x 分支上维护，接受贡献，但活跃开发已经全部转移到 2.0。也就是说，2.0 的定位比 1.x 更宽：从「深度研究流程」扩展成「几乎什么都做的通用智能体骨架」，检索、写代码、生成内容都在射程内。README 提到，版本 2 发布后在 GitHub Trending 上登顶，多语言 README（中/英/日/法/俄）也表明其面向的是国际化的开发者群体。

技术栈层面，仓库区分前后端：后端是 Python 项目（要求 Python 3.12+），前端与构建工具链走 Node.js（要求 22+），根目录用 Makefile 作为统一命令入口。协议为 MIT。

核心功能 / 内容清单

• 子智能体编排（sub-agents）：主智能体负责规划与调度，把子任务派发给专职子智能体。这样做的实际价值在于上下文隔离——长任务如果把所有中间过程都塞进一个上下文窗口，很快就会被噪声淹没；拆分后每个子智能体只带自己需要的上下文，同时具备并行推进的可能。
• 沙箱执行环境（sandboxes）：智能体可以在隔离环境中真正运行代码、读写文件，而不是只输出一段「看起来能跑」的代码。这是 DeerFlow 能覆盖「coding」类任务的底座，也是「跑—看结果—修正」这一循环能够自动化的前提。
• 记忆（memory）：跨步骤、跨会话保存信息。长期任务最容易失败的地方不是推理能力，而是中途丢失既定目标、约束条件或此前已经确定的参数；记忆层就是为此存在的。
• 工具与可扩展技能（tools / skills）：技能是可插拔的能力封装，把某类任务的流程、提示与工具组合固化成一个可复用单元，从而不必每次从零描述需求。
• 消息网关（message gateway）：作为任务进出的统一入口，使这套 harness 的输入输出不绑定在某一个前端形态上，便于接入不同的交互渠道。
• 配套工具 LLM Space：姊妹项目，是一个桌面工具，用于原型化智能体想法、逐步检查 harness 的执行过程、回放失败案例以及做性能基准。调试长链路智能体时，能逐步看清每一步发生了什么，往往比结果本身更重要。

典型使用场景

一是多轮迭代的深度调研。 当需要一份关于某个陌生领域的综述，而答案分散在大量资料中、需要反复交叉验证时，可以把题目交给 DeerFlow：主智能体先拆解成若干子问题，子智能体分头检索与整理，中间产物落到沙箱与记忆里，最后汇总成结构化成稿。相比单轮对话，它的优势在于能保留中间结论并持续修正，适合那种「一次问不清楚、需要边查边调整」的题目。

二是带真实执行的数据处理与编码任务。 例如「把这批数据清洗后出图，并写一段说明」——智能体在沙箱里写脚本、运行、读取报错、改脚本再运行，记忆层记下上次选用的字段和参数，避免下一轮重复踩坑。这类任务的共同特征是：执行结果会反过来决定下一步做什么，纯文本生成无法胜任。

三是把同一套能力接到多个消息入口。 通过消息网关统一收派任务，可以用同一套 harness 支撑不同渠道的调用，而不必为每个入口重新实现一遍编排逻辑。

适合谁用

• AI 应用开发者与团队：需要在自托管前提下快速拿到一套包含编排、沙箱、记忆、工具抽象的智能体骨架，避免从零重复造轮子。
• 研究与分析岗位：经常要产出需要多轮检索、交叉核对的调研结论，希望把重复的搜集整理环节自动化。
• 工程效率团队：想把内部那些「步骤多但模式固定」的流程（数据整理、脚本生成、周期性报告）沉淀为可复用技能。
• 想学习 agent harness 设计的人：2.0 把子智能体、技能、网关、沙箱这几层拆得比较清楚，是一份有参考价值的架构样本。
• 相对不适合：只想要一个开箱即用聊天界面的人，以及不愿意同时维护 Python 与 Node.js 两套环境的用户。

快速上手

基本路径是：确认本机 Python 3.12+ 与 Node.js 22+ 环境 → 克隆仓库 → 安装前后端依赖 → 配置模型服务的 API Key 与相关环境变量 → 通过根目录 Makefile 提供的命令启动服务，然后从界面或消息入口下达任务。README 中明确推荐使用 Doubao-Seed-2.0-Code、DeepSeek v3.2、Kimi 2.5 这类模型来驱动 DeerFlow，接入其他兼容模型通常也可行，但效果视模型的长上下文与工具调用能力而定。

如果只是想先看看它长什么样，官方站点提供了允许访问的只读案例展示，无需登录即可浏览，适合在本地部署前建立预期。仓库同时提供中文、日文、法文、俄文版 README，可根据语言偏好选择阅读。具体命令、配置项名称与目录结构请以官方 README 为准，不同版本之间可能有调整。

注意事项

• 版本认知要正确：2.0 与 1.x 无代码继承关系，网上大量针对早期 DeerFlow 的教程、配置说明和教程视频不能直接照搬。如果目标就是当年那个 Deep Research 框架，应转去 1.x 分支。
• 依赖门槛偏高：Python 3.12+ 与 Node.js 22+ 都是相对较新的版本要求，老旧开发机或受管控的企业环境可能需要先升级运行时。
• 权限与安全边界：沙箱让智能体具备真实执行能力，会运行代码、操作文件，可能涉及外部访问。部署时需明确沙箱的隔离强度、网络出站策略，并妥善管理模型密钥等敏感配置，避免把生产凭据暴露给自动生成的代码。
• 成本与耗时：长周期任务意味着多轮模型调用与工具执行，token 开销和等待时间都不低。建议先用小规模任务验证链路是否正确，再投入正式场景。
• 协议范围：代码采用 MIT 协议，允许商用与修改，但需保留版权与许可声明。模型权重、第三方 API 服务则各自适用其独立条款，需另行确认。
• 模型选择的自主判断：README 中对特定模型的推荐附带了火山引擎 Coding Plan 的推广链接，属于厂商建议而非硬性依赖。实际选型应结合可获得性、上下文长度、工具调用稳定性与成本综合决定。