DeerFlow 2.0：字节跳动开源的 Agent 运行时，和 LangChain 不是一回事2月28号，DeerFl

2月28号，DeerFlow 登顶 GitHub Trending。

刷到这个新闻的时候，我第一反应是"又一个 AI Agent 框架"。仔细看了下文档，发现定位不太一样——它不是框架，是一个运行时平台。

官方的定义是 Super Agent Harness。Harness 这个词用得有意思，它想说的是：这不是给你积木让你自己搭，而是开箱即用的完整运行环境。

框架 vs 运行时

LangChain 提供了链式调用，LangGraph 提供了状态机编排。这些都是"积木"。

但你要跑一个真正能干活的 Agent，光有积木不够。你还需要：

文件系统在哪？Agent 写的文件放哪？
Agent 执行代码怎么隔离？不能让它把宿主机搞挂
多个 Agent 怎么协作？并行几个合适？
上次聊了什么，下次怎么记住？

这些东西框架不帮你解决，你得自己写胶水代码。

DeerFlow 把这些都打包好了。配置好模型，跑起来就能用。

它瞄准的场景叫 Long-horizon Agent——那些需要跑几分钟甚至几小时、自主决策、最后产出一个"初稿"的任务。比如：

帮我写一份新能源汽车出海市场的调研报告

这种任务不是扔给 GPT 一个 prompt 就能搞定的。Agent 需要搜索、阅读、分析、汇总、写文档。整个过程可能持续20分钟。

DeerFlow 就是为这种场景设计的。

目录结构

clone 下来看一眼：

deer-flow/
├── backend/           # Python 后端
│   ├── agents/        # Agent 定义
│   ├── subagents/     # 子智能体管理
│   ├── sandbox/       # 沙箱执行
│   ├── skills/        # 技能加载
│   └── mcp/           # MCP 集成
├── frontend/          # Next.js 前端
├── skills/            # 技能定义（Markdown）
└── docker/            # 部署配置

有一个细节值得注意：skills/ 目录和 backend/ 是平级的。技能是 Markdown 文件，不是代码。这意味着产品经理或者运营也能写技能，不用找开发。

Lead Agent 和 Sub-Agent

整个系统有一个 Lead Agent，是用户直接交互的主入口。它负责：

理解用户意图
判断要不要拆任务
如果拆，创建 Sub-Agent 去执行

Sub-Agent 有两种：

一种是 general-purpose，继承了 Lead Agent 的大部分工具，用来做复杂推理、搜索、分析。

另一种是 bash，只有 bash、ls、read_file、write_file 这几个工具，专门跑命令行任务，比如构建项目、跑测试。

几个硬性限制：

最多 3 个 Sub-Agent 并行
每个 Sub-Agent 最多跑 15 分钟
Sub-Agent 不能再创建 Sub-Agent（防止无限嵌套）

有一个设计决策我挺认同：Sub-Agent 看不到 Lead Agent 的对话历史。

一开始我觉得这是个 bug，后来想明白了。当你让一个 Sub-Agent 去搜索"Python 异步编程最佳实践"时，它不需要知道用户之前问过天气预报、Lead Agent 执行过什么文件操作。这些信息不但没用，还会占用宝贵的上下文窗口。

所以 Lead Agent 给 Sub-Agent 下发任务时，必须把所有背景信息、约束条件都写清楚。这就像给外包团队写需求文档——你不能把整个项目历史甩过去，得写一份完整独立的任务说明书。

记忆系统

大多数 Agent 框架的会话一结束就失忆了。DeerFlow 维护了一套持久化的记忆系统。

结构分三层：

user:          # 用户画像
  workContext      # 工作背景
  personalContext  # 个人偏好
  topOfMind        # 当前关注点

history:       # 时间线
  recentMonths     # 近期活动
  earlierContext   # 更早的上下文

facts:         # 事实库
  - content: "偏好 Vim"
  - category: preference
  - confidence: 0.95

置信度低于 0.7 的事实会被过滤掉。这个阈值设计得合理——只有"用户明确说的"和"强烈暗示的"信息才值得记住。

记忆会注入到系统提示词里，但有 2000 token 的上限。超出就截断。

Skills 系统

这个设计我挺喜欢。一个 Skill 就是一个目录加一个 SKILL.md 文件。

---
name: deep-research
description: 网络研究时用这个技能，代替简单的 WebSearch
---

# Deep Research Skill
研究方法分四个阶段...

加载策略分三层：

name + description：始终在 Agent 的上下文里
SKILL.md 正文：匹配到了才加载
脚本、模板：执行时按需读取

这样做的好处是：17 个内置 Skill 不会把上下文窗口撑爆。Agent 只在需要的时候才去读完整的操作手册。

内置的 Skill 挺丰富的：deep-research、data-analysis、ppt-generation、image-generation、video-generation...

比较有意思的是 skill-creator——一个用来创建其他 Skill 的 Skill。Meta。

沙箱环境

Agent 执行代码不能在宿主机上裸跑。DeerFlow 提供了三种沙箱：

Local：开发用，直接操作文件系统
Docker：生产用，进程隔离
K8s：大规模部署，Pod 管理

所有文件操作、代码执行都在沙箱里进行。

中间件管道

这是架构里最精妙的部分。

DeerFlow 有一串中间件，每个处理一个横切关注点：

MemoryMiddleware：记忆注入和更新
SandboxMiddleware：沙箱管理
ThreadDataMiddleware：线程数据目录
TitleMiddleware：自动生成标题
ToolFilterMiddleware：工具权限过滤

每个中间件都有 before_agent 和 after_agent 两个钩子。这比硬编码的流程灵活多了——想加什么功能，写个中间件插进去就行。

技术栈

后端是 Python，核心依赖：

LangGraph：Agent 编排引擎
LangChain：模型和工具适配
FastAPI + SSE：API 网关

前端是 Next.js + React，通过 SSE 实现实时流式渲染。用户能看到 Agent 每一步在干什么。

模型支持：Claude、GPT-4、Gemini、DeepSeek、豆包、Kimi，以及任何 OpenAI 兼容的 API。

v1 到 v2 的故事

DeerFlow v1 是 2025 年 5 月出的，定位是 Deep Research 框架。

社区拿它干了些团队没预料到的事：数据分析、PPT 生成、内容工厂、运维巡检...

团队发现，Deep Research 只是 DeerFlow 能做的第一个 Skill。它的本质是通用 Agent 平台。

于是 2026 年春节，团队决定从头重写。v2 和 v1 不共享任何代码。

几个值得借鉴的设计

单层委派。Sub-Agent 不能再创建 Sub-Agent。这避免了递归深度不可控的问题。

配置三层分离。config.yaml 放核心配置，extensions_config.json 放运行时开关，.env 放密钥。敏感信息不会进配置文件，运行时配置可以热更新。

模型降级策略。用户请求的模型不存在时，会静默降级到默认模型，不会崩。

Skill 渐进式加载。元数据始终可见，正文按需加载。上下文窗口不会被撑爆。

和竞品的区别

产品	开源	可自托管
DeerFlow	MIT	是
OpenAI Operator	否	否
Manus	否	否

DeerFlow 的核心卖点是开源+可自托管。你可以在自己的服务器上跑，用自己选的模型，扩展自己的技能。

怎么跑起来

git clone https://github.com/bytedance/deer-flow.git
cd deer-flow
cp config.example.yaml config.yaml
# 编辑 config.yaml，填入 API Key
make run

然后访问 http://localhost:2026。

资源：