Multi-Agent
Context Engineering
LangGraph
DeerFlow 2.0 深度解析:字节跳动开源的多智能体上下文管理方案
DeerFlow 2.0 Deep Dive: ByteDance's Open-Source Multi-Agent Context Management Solution
发布日期:2026-04-25
Published: 2026-04-25
•
来源:字节跳动 GitHub + 技术博客
Source: ByteDance GitHub + Tech Blog
一、背景:多智能体系统的"失忆症"
2026年初,字节跳动在GitHub上悄悄更新了DeerFlow 2.0。
没有大张旗鼓的发布会,但Star数在两个月内从10k飙到52k,LangChain创始人Harrison亲自转发推文,AI工程师圈里炸开了锅。
人们兴奋的点不是"又一个Agent框架",而是它解决了一个长期折磨工程师的老大难问题:
当AI需要执行数小时、数十步骤的复杂任务时,它总是"忘事"。
1.1 多智能体系统的三大"失忆症"
| 问题 |
表现 |
根因 |
| 上下文窗口枯竭 |
Token被无关信息撑爆,模型胡言乱语 |
有限上下文 vs 无限积累 |
| 上下文污染 |
子Agent被主Agent思路干扰,偏离原始任务 |
共享上下文架构缺陷 |
| 跨会话失忆 |
会话结束Agent像失忆,下次从头开始 |
无持久记忆机制 |
二、DeerFlow 2.0 整体架构
DeerFlow 2.0将自己定位为Super Agent Harness(超级智能体运行框架)——一套完整的AI任务执行基础设施。
核心公式:
DeerFlow 2.0 = Sub-Agents + Memory + Sandbox + Extensible Skills
核心架构
╔═══════════════════════════════════════════════════════════════════╗
║ DeerFlow 2.0 整体架构 ║
╠═══════════════════════════════════════════════════════════════════╣
║ ║
║ ┌─────────────────────────────────────────────────────────┐ ║
║ │ Frontend (Next.js) │ ║
║ │ http://localhost:2026 │ ║
║ └──────────────────────────┬──────────────────────────────┘ ║
║ │ HTTP / SSE ║
║ ┌──────────────────────────▼──────────────────────────────┐ ║
║ │ Gateway (FastAPI) │ ║
║ │ ┌───────────┐ ┌───────────┐ ┌───────────────────┐ │ ║
║ │ │IM Channels│ │ Skills │ │ Threads Manager │ │ ║
║ │ │ Telegram │ │ Loader │ │ (Session 隔离) │ │ ║
║ │ │Slack/飞书 │ │ 按需加载 │ │ uuid.uuid4() │ │ ║
║ │ └───────────┘ └───────────┘ └───────────────────┘ │ ║
║ └──────────────────────────┬──────────────────────────────┘ ║
║ │ ║
║ ┌──────────────────────────▼──────────────────────────────┐ ║
║ │ LangGraph Agent Server (Python) │ ║
║ │ │ ║
║ │ ╔═══════════════════════════════════════════════════╗ │ ║
║ │ ║ Lead Agent (主智能体) ║ │ ║
║ │ ║ ┌──────────────┐ ┌──────────────┐ ║ │ ║
║ │ ║ │ Coordinator │──▶│ Planner │ ║ │ ║
║ │ ║ │ (意图识别) │ │ (任务分解) │ ║ │ ║
║ │ ║ └──────────────┘ └──────┬───────┘ ║ │ ║
║ │ ║ │ ║ │ ║
║ │ ║ ┌───────────────────────┼─────────────────────┐ ║ │ ║
║ │ ║ ▼ ▼ ▼ ║ │ ║
║ │ ║ ┌────────────┐ ┌────────────┐ ┌────────────┐ ║ │ ║
║ │ ║ │ Sub-Agent │ │ Sub-Agent │ │ Sub-Agent │ ║ │ ║
║ │ ║ │(隔离上下文) │ │(隔离上下文) │ │(隔离上下文) │ ║ │ ║
║ │ ║ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ ║ │ ║
║ │ ║ └───────────────┼───────────────┘ ║ │ ║
║ │ ║ ▼ ║ │ ║
║ │ ║ ┌──────────────────┐ ║ │ ║
║ │ ║ │ Reporter │ ║ │ ║
║ │ ║ │ (报告汇总) │ ║ │ ║
║ │ ║ └──────────────────┘ ║ │ ║
║ │ ╚═══════════════════════════════════════════════════╝ │ ║
║ │ │ ║
║ │ ┌───────────────────────────────────────────────────┐ │ ║
║ │ │ Memory System(双层记忆) │ │ ║
║ │ │ 短期(Session内) ←────────────────→ 长期(跨Session)│ │ ║
║ │ └───────────────────────────────────────────────────┘ │ ║
║ └──────────────────────────┬──────────────────────────────┘ ║
║ │ ║
║ ┌──────────────────────────▼──────────────────────────────┐ ║
║ │ Sandbox (Docker 隔离) │ ║
║ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ ║
║ │ │ /uploads │ │ /workspace │ │ /outputs │ │ ║
║ │ │ 用户文件 │ │ 工作目录 │ │ 产出物 │ │ ║
║ │ └──────────────┘ └──────────────┘ └──────────────┘ │ ║
║ └─────────────────────────────────────────────────────────┘ ║
╚═══════════════════════════════════════════════════════════════════╝
三、第一层解法:Coordinator 防火墙
3.1 核心设计理念
上文丢弃(Discard)——当用户说"你好"、"你能做什么"时,Coordinator直接响应,终止对话并清空历史消息,不让这些无关信息污染后续任务的上下文。
3.2 Coordinator 决策树
┌─────────────────────────────────────────────────────────────────┐
│ Coordinator 决策树 │
│ │
│ 用户输入 │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ 意图分类器 │ │
│ └───────┬───────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ▼ ▼ ▼ │
│ 闲聊/问候 不当言论 真实任务请求 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 直接回复 直接拒绝 移交 Planner │
│ 清空历史 清空历史 保留上下文继续 │
│ │
│ 关键:此处执行 "Discard" 策略 │
│ 即便是无关对话产生了消息,也不进入研究工作流 │
└─────────────────────────────────────────────────────────────────┘
3.3 设计价值
| 价值 |
说明 |
| 防止无意义闲聊缠绕后续推理 |
"你好"之类的话不会污染任务上下文 |
| 降低上下文初始噪音 |
入口处就过滤掉无关信息 |
| 保证后续模块拿到干净信息 |
每个模块只处理真实任务 |
四、第二层解法:Sub-Agent 上下文隔离
这是DeerFlow 2.0最核心的创新,解决"上下文污染"的关键。
4.1 三层上下文隔离体系
| 层级 |
隔离维度 |
实现方式 |
| Level 1 |
线程级隔离 |
每个请求→uuid.uuid4()→独立thread_id |
| Level 2 |
Sub-Agent隔离 |
每个子Agent只有当前Step任务描述 |
| Level 3 |
Docker沙箱隔离 |
文件系统+进程级完全隔离 |
4.2 Sub-Agent 只接收"最小必要上下文"
# DeerFlow 源码中的 Sub-Agent 输入构造
agent_input = {
"messages": HumanMessage(content=f"""
# Task
## title
{step.title}
## description
{step.description}
""")
}
核心思想:一个负责"搜索技术文档"的Sub-Agent,它的上下文里只有这一项具体任务,看不到:
- Lead Agent的整体规划思路
- 其他Sub-Agent的搜索结果
- 用户之前的闲聊对话
比喻:就像给每个工人一张独立的工单,而不是把整个项目文档扔给他。
4.3 并行执行的上下文隔离优势
| 传统方式(串行混乱) |
DeerFlow方式(并行高效) |
| Agent → 任务A → [全量上下文+A结果] → 任务B → ... |
任务A (Sub-Agent A, 独立上下文) |
| 上下文不断膨胀,噪音不断累积 |
主Agent ─┤ 任务B (Sub-Agent B, 独立上下文) ─→ 汇总 |
|
任务C (Sub-Agent C, 独立上下文) |
|
三个Agent可以并行跑,上下文互不干扰 |
五、第三层解法:上下文工程策略
5.1 策略一:信息压缩(Compression)
不把原始数据留在上下文里,把它换成摘要。
子任务执行完毕
│
▼
┌──────────────────────────────────────────────────┐
│ 压缩决策:返回什么给 Lead Agent? │
│ │
│ ❌ 原始搜索结果(可能有几千 tokens) │
│ ❌ 完整的代码执行日志 │
│ ✅ 任务完成状态 + 一句话概要 │
│ ✅ 关键数据/结论(结构化格式) │
└──────────────────────────────────────────────────┘
│
▼
上报给 Lead Agent 的是摘要,而非原文
5.2 策略二:结果外存(Offload)
把中间产物存到文件系统,不堆在内存里。
┌──────────────────────────────────────────────────────────┐
│ 结果外存机制 │
│ │
│ 长文本/大量数据 → 写入 /workspace/intermediate/ │
│ │
│ 留在上下文中的仅是: │
│ "已生成分析文件:/workspace/analysis_result.md" │
│ │
│ 需要时再读取,而不是一直占据 Token 窗口 │
└──────────────────────────────────────────────────────────┘
5.3 策略三:上下文充分性评估(Has Enough Context)
够用就停,不过度执行。
class State:
# Planner 判断是否已有足够信息
has_enough_context: bool = False
# Planner 节点逻辑
if state.has_enough_context:
# 跳过额外的研究步骤
# 直接生成报告,节省 Token
goto(reporter_node)
else:
# 继续执行研究步骤
goto(research_team_node)
5.4 三大策略对比
| 策略 |
作用 |
收益 |
| 压缩 |
中间结果 → 摘要后回传 |
减少Token占用,降低上下文噪音 |
| 外存 |
大量数据写入文件系统 |
释放Token窗口,按需加载 |
| 充分性评估 |
判断信息是否已足够 |
避免过度执行,减少不必要消耗 |
六、第四层解法:按需加载 Skills
DeerFlow 2.0引入了Skills(技能)系统,将"能力"与"上下文"解耦。
6.1 Skills 本质
每个Skill是一个Markdown文件,描述了完成某类任务的工作流和最佳实践:
/mnt/skills/public/
├── research/
│ └── SKILL.md # 研究任务的工作流定义
├── report-generation/
│ └── SKILL.md # 报告生成的工作流定义
├── slide-creation/
│ └── SKILL.md # 幻灯片制作的工作流定义
├── web-development/
│ └── SKILL.md # 网页开发的工作流定义
└── image-generation/
└── SKILL.md # 图像生成的工作流定义
/mnt/skills/custom/
└── your-skill/
└── SKILL.md # 用户自定义技能
6.2 按需加载 vs 全量加载
| 传统方式(Token浪费) |
DeerFlow按需加载(精准控制) |
| ❌ 一次性把所有工具文档塞入系统提示词 |
✅ 任务需要时才加载对应Skill |
| 系统Prompt可能达到几万Token |
仅加载当前任务需要的1-2个Skill |
| 大多数Skill此刻用不到 |
其他Skills休眠,不占用Token窗口 |
"只有任务确实需要时才加载,这样能把上下文窗口控制得更干净,也更适合对token比较敏感的模型。"
七、第五层解法:双层记忆系统
7.1 双层记忆架构
Layer 1:短期记忆(Session 内)
• LangGraph MemorySaver(可选)
• 支持会话中断后恢复(断点续传)
• 保存当前任务的规划状态、执行进度
• 会话结束可选择是否清除
任务完成后,提取有价值的信息沉淀
Layer 2:长期记忆(跨 Session)
本地持久化存储:
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 用户偏好 │ │ 知识背景 │ │ 工作习惯 │
│ │ │ │ │ │
│ 写作风格 │ │ 技术栈偏好 │ │ 工作流程模式 │
│ 输出格式 │ │ 专业领域背景 │ │ 常用模板格式 │
└──────────────┘ └──────────────┘ └──────────────┘
• 数据控制权在用户本地
• 使用越多,越了解用户
• 内置去重机制,避免无限累积
7.2 两种运行模式
# 无记忆模式(默认):每次请求都是全新会话
app = build_graph()
# 带记忆模式:使用 MemorySaver 支持跨请求状态保持
app = build_graph_with_memory()
| 模式 |
适用场景 |
特点 |
| 无记忆模式 |
隐私敏感场景 |
每次对话后状态完全清除,无数据泄漏风险 |
| 带记忆模式 |
连续交互场景 |
Agent记住用户偏好和上下文,下次无需重复 |
7.3 记忆更新与去重机制
用户交互产生新信息
│
▼
┌───────────────────────┐
│ 信息提取与分类 │
│ • 用户偏好 │
│ • 知识背景 │
│ • 工作习惯 │
└──────────┬────────────┘
│
▼
┌───────────────────────┐
│ 去重检测 │ ← 防止记忆无限膨胀
│ 与已有记忆比对 │
└──────────┬────────────┘
│
┌─────┴──────┐
▼ ▼
重复信息 新信息
直接跳过 写入 Memory Store
│
▼
本地持久化存储(用户可控)
八、完整上下文管理流程示例
用户输入:"分析2026年AI Agent市场竞争格局,生成一份研究报告"
│
├─ Step 1:Coordinator(防火墙)
│ • 识别为真实任务请求
│ • 不清空历史,移交 Planner
│ • [上下文:仅用户原始请求]
│
├─ Step 2:Background Investigator(背景预研)
│ • 执行初步搜索
│ • 输出加 Prefix 标识,隔离上下文
│ • [上下文:仅用户 query,独立执行]
│
├─ Step 3:Planner(任务规划)
│ • 接收背景调查摘要 + 用户 query
│ • 分解为 3 个 Sub-Tasks:
│ - Task A:调研主流 Agent 框架
│ - Task B:分析市场份额数据
│ - Task C:收集用户评价
│ • [上下文:背景摘要 + 规划结果]
│
├─ Step 4:Sub-Agent 并行执行(上下文隔离)
│ ├─ Sub-Agent A:[上下文:仅 Task A 描述]
│ │ 搜索 → 分析 → 返回摘要
│ ├─ Sub-Agent B:[上下文:仅 Task B 描述]
│ │ 搜索 → 分析 → 返回摘要
│ └─ Sub-Agent C:[上下文:仅 Task C 描述]
│ 搜索 → 分析 → 返回摘要
│
├─ Step 5:上下文压缩与汇总
│ • 每个 Sub-Agent 只返回"一段话摘要 + 关键数据"
│ • 中间大量数据写入 /workspace/(外存)
│ • Lead Agent 上下文:规划 + 三个摘要(Token 可控)
│
├─ Step 6:Planner 充分性评估
│ • has_enough_context = True(三个方向均已覆盖)
│ • 跳过额外搜索,直接生成报告
│
└─ Step 7:Reporter(报告生成)
• 从文件系统读取必要细节
• 生成结构化研究报告
• 输出到 /outputs/
总耗时:约 80 分钟
全程上下文:始终处于可控范围
九、与主流框架对比
| 维度 |
DeerFlow 2.0 |
AutoGen |
CrewAI |
LangChain |
| Sub-Agent上下文隔离 |
✅ 完全隔离 |
⚠️ 部分隔离 |
⚠️ 共享 |
❌ 无 |
| 中间结果压缩 |
✅ 自动摘要 |
⚠️ 手动 |
❌ 无 |
❌ 无 |
| 结果外存机制 |
✅ 文件系统 |
❌ 无 |
❌ 无 |
❌ 无 |
| 长期跨会话记忆 |
✅ 本地持久化 |
❌ 无 |
❌ 无 |
⚠️ 需配置 |
| Skills按需加载 |
✅ 内置支持 |
❌ 无 |
❌ 无 |
❌ 无 |
| 并行Sub-Agent |
✅ 原生支持 |
✅ 支持 |
⚠️ 有限 |
❌ 无 |
| 长链路任务可靠性 |
⭐⭐⭐⭐⭐ |
⭐⭐⭐ |
⭐⭐⭐ |
⭐⭐ |
十、Context Engineering 方法论总结
DeerFlow 2.0的上下文管理方案,本质上是一套完整的Context Engineering(上下文工程)方法论。
六字原则:过滤、隔离、压缩
Context Engineering 六字原则
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 过 滤 │ │ 隔 离 │ │ 压 缩 │
└──────────┘ └──────────┘ └──────────┘
│ │ │
• Coordinator • 线程级隔离 • 中间结果摘要
防火墙过滤无关 Sub-Agent 结果外存文件
输入,避免历史 上下文完全 充分性评估
噪音污染任务 独立,互不 按需加载
执行流程 干扰 Skills
效果: 效果: 效果:
Token 干净 执行精准 窗口可控
入口可控 结果可靠 成本降低
设计哲学
让每个Agent只看它需要看的,只记它需要记的,只做它应该做的。
这与软件工程中的:
- 最小权限原则(Principle of Least Privilege)
- 关注点分离(Separation of Concerns)
高度契合。把软件工程的经典智慧移植到AI工程,这正是DeerFlow团队的洞见所在。
十一、对工程师的启示
11.1 从"Coordinator防火墙"学到的
✅ 在任何多Agent系统前设置意图分类器,将无关请求在入口处拦截,而不是让它们进入核心流程。
11.2 从"Sub-Agent上下文隔离"学到的
✅ 为每个执行单元构建最小上下文输入,用结构化的任务描述替代全量历史传递。Sub-Agent只应该"知道自己这一步该做什么"。
11.3 从"结果压缩与外存"学到的
✅ 不要让原始工具输出直接堆积在上下文。搜索结果、代码执行日志、文件内容,都应当经过摘要或外存处理后,以引用形式留在上下文里。
11.4 从"Skills按需加载"学到的
✅ 把工具描述/能力文档从系统提示词里剥离,改为根据任务类型动态注入。这对Token的节省效果非常显著。
11.5 从"双层记忆"学到的
✅ 区分"任务内记忆"和"跨任务记忆"。前者服务于当前执行链路,后者沉淀可复用的用户偏好和知识,两者存储机制应当分离。