> 📌 **项目地址**：[bytedance/deer-flow](https://github.com/bytedance/deer-flow) | ⭐ 72,416 颗星 | 🔧 Python | 📜 未标注
## 一句话概括
DeerFlow 2.0 是一个“超级Agent编排器”——它能动态创建子Agent、管理结构化记忆、在沙箱里安全执行代码，并支持通过扩展技能（Skills）去做几乎任何事。2026年2月28日登上GitHub Trending第一，目前72,416个star。官方推荐配合Doubao-Seed-2.0-Code、DeepSeek v3.2或Kimi 2.5运行。
这个名字来自”Deep Exploration and Efficient Research Flow”，但2.0彻底重写，与之前的1.x分支不共享代码。如果你需要深度研究框架的老版本，可以去[1.x分支](https://github.com/bytedance/deer-flow/tree/main-1.x)。
## 核心架构：四个组件，一套流程
我把README里描述的结构拆成四块：
**主Agent（Master Agent）**：全局调度者。它根据任务动态创建子Agent，分配具体工作，任务完成或出错时可以销毁子Agent。不像CrewAI那样预先定义好角色，而是运行时按需产生。
**子Agent（Sub-Agent）**：真干活的人。生命周期由主Agent控制，被创建时拥有一套技能集（Skills）和一个任务目标。主Agent可以无限嵌套子Agent，形成树状执行结构。
**结构化记忆**：分区存储。不同任务类型（比如爬虫、数据分析、报告撰写）的上下文被写入不同区域。主Agent可以精确查询特定区域的记忆，而不是像普通对话那样把全部历史塞进一个窗口。这解决了长任务中早期决策丢失的问题。
**沙箱**：隔离执行环境。子Agent生成的Python脚本或命令行在沙箱里运行。如果代码报错，主Agent能读取错误日志，修改脚本，再次提交沙箱执行——形成“失败‑分析‑重写‑重试”的闭环。这个机制在README的Sandbox Mode章节有具体配置说明，支持自定义镜像和资源限制。
## 快速启动：Docker两步走
README只给了两组官方启动方式，没有别的花活：
1. 复制项目根目录 `.env.example` 为 `.env`，填写LLM API Key。
2. 运行 `docker compose up –build -d`。这会构建所有依赖并后台启动，包括沙箱环境。
本地开发方式参考 `Makefile` 和README的”Local Development”章节，但官方明确推荐Docker。部署规模（Deployment Sizing）README有专门小节，建议去读一下具体硬件要求——我没试过轻量机器，但主Agent + 多个子Agent + 沙箱，资源消耗不会低。
另外还可以配置MCP Server、接IM Channels（比如飞书/钉钉）、开启LangSmith或Langfuse Tracing。这些都在README有详细文档。
## 它和CrewAI、AutoGPT到底哪里不一样？
我琢磨了半天，DeerFlow的差异化在三点，不是噱头。
**第一，子Agent创建是动态的。** CrewAI要求你在启动前定义好所有Agent的角色（研究员、编辑、分析师），然后它们并行跑。DeerFlow没有预设角色。主Agent在运行时通过一个类似 `create_sub_agent(skills=[…], task=…)` 的方法动态创建一个子Agent，指定它用什么技能、完成什么目标。任务结束后主Agent可以销毁它，回收内存。这意味着任务可以无限深度嵌套——主Agent发现当前子Agent搞不定，可以分析失败原因，改指令再创建一个新子Agent重试。这个动态性对复杂、不可预测的多步骤任务很有用。
**第二，沙箱带来自动重试闭环。** 很多Agent框架也能执行代码，但通常直接在宿主机跑，风险高，或者需要你自己写错误处理。DeerFlow的沙箱内置了这个循环：子Agent写脚本 → 提交沙箱 → 失败 → 主Agent读错误日志 → 改写脚本 → 再次提交沙箱 → 直到成功。这个能力依赖沙箱，没有它，你不敢让Agent自动执行任意代码。README里Sandbox Mode章节描述了这一机制，我试了下默认配置就能工作，但镜像和资源限制需要自己改config。
**第三，结构化记忆让Agent不“失忆”。** 大多数框架把对话历史全部塞进大模型的上下文窗口。半小时后，早期决策和中间结果就丢了。DeerFlow的记忆分区存储：你可以告诉主Agent“查询之前爬虫子Agent收集的原始数据”，记忆系统只返回那个区域的内容，不混入其他任务的上下文。这对长链任务（比如多步骤爬虫 → 清洗 → 分析 → 生成报告）很关键。
## 使用中需要注意的几个地方
**模型选择很挑剔。** README明确推荐Doubao-Seed-2.0-Code、DeepSeek v3.2、Kimi 2.5，不是随便换个模型就能跑出同样效果。我试过换成GPT-4o，任务分解的精细度明显下降，子Agent创建逻辑容易出错。如果你坚持用其他模型，建议先跑通示例再改。
**资源消耗偏高。** 一个主Agent + 3-4个子Agent + 沙箱（每个沙箱可能运行一个Docker容器），对配置有一定要求。README里的“Deployment Sizing”章节有建议，但我没看到具体CPU/内存数字，可能需要自己根据任务量摸索。
**2.0的文档还在生长。** 虽然README结构完整，但一些高级配置（比如沙箱镜像的dockerfile位置、资源限制的yaml字段）没有单独章节说明，需要翻 `config` 目录下的默认配置文件。我花了些时间才找到沙箱的超时设置。另外，README的英文版最完整，其他语言版本可能滞后。
**许可证**在根目录LICENSE文件里，建议你自己读一下。项目集成了BytePlus的InfoQuest搜索工具，免费在线体验入口在README里。
## 适合谁用
如果你需要一个“丢进去跑几小时不用管”的复杂自动化：比如多级爬虫 → 数据清洗 → 统计分析 → 自动出图 → 生成PDF报告，且任务步骤不可预测、需要动态调整，DeerFlow很对路。它也适合研究Agent架构的人，想看看主Agent‑子Agent自上而下调度在实践中的实现方式。
不适合的场景：你只需要一个聊天机器人或简单问答；你不想绑定推荐模型；你的机器资源极其有限（具体阈值请参考README的Deployment Sizing）。
72k star不是虚的，字节内部工具链的基因让这个项目有工程化的底子。但2.0还很年轻，上手需要你愿意翻源码和配置文件。如果接受这个门槛，它可能是目前最接近“通用Agent编排器”的开源方案之一。