04. 整体架构：DeerFlow 到底在调度什么

先看一张脑内地图

DeerFlow 不是一个单文件 Agent。

它更像一套把任务跑起来的系统。一次请求进来以后，会经过 API 层、运行时、Agent、工具、沙盒、外部服务，最后变成可返回、可追踪的结果。

可以先粗略理解成：

Gateway API
|
Runtime / Run Manager
|
Lead Agent
|
Middleware
|
Tools / Skills / Sub-agents / MCP / Sandbox
|
Artifacts / Streaming / Tracing

这张图不需要一开始就背下来。后面每一篇都会拆其中一块。

Gateway：请求入口

官方后端有 gateway 相关路由，目录大致在：

backend/app/gateway/routers/

这里能看到 threads、runs、thread_runs、models、skills、mcp、memory、uploads、artifacts 等路由。

这说明 DeerFlow 不是只有一个 /chat 接口。它在 API 层已经把“会话、运行、技能、工具、文件、记忆”这些概念拆开了。

Runtime：任务怎么被管理

runtime 相关代码在：

backend/packages/harness/deerflow/runtime/

这里会处理 run 的状态、事件、存储、stream bridge、checkpointer 等问题。

你可以把 runtime 理解成：

负责让一次任务被创建、执行、记录、恢复和输出

如果后面你遇到“任务创建了但没输出”“页面没收到流式事件”这类问题，runtime 是重点区域。

Lead Agent：主调度者

Lead Agent 是任务的主入口。

它负责理解目标、决定下一步、调用工具或拆给子 Agent，并把结果汇总回来。

它不是万能的。真正的能力来自它能调度的东西：tools、skills、sub-agents、MCP、sandbox、memory。

Middleware：中间层约束

middleware 的作用不是让系统更复杂，而是把一些横切逻辑从 Agent 主体里拆出来。

例如：

上下文处理
工具限制
子 Agent 限制
状态更新
沙盒注入

如果所有逻辑都塞进一个 Agent prompt，系统很快就不可维护。

Tools / Skills / Sub-agents 的关系

这三者容易混。

可以先这样分：

Tool：一次可调用的动作
Skill：一套可复用的方法和约束
Sub-agent：把一部分任务交给另一个 Agent 上下文

后面 07-15 会分别拆。

Sandbox / MCP / Memory / Tracing

这几块是工程化 Agent 很重要的部分：

• Sandbox 负责执行边界和文件安全；
• MCP 负责把外部服务接进来；
• Memory 负责长期上下文；
• Tracing 负责看清一次任务为什么成功或失败。

这些不是锦上添花。Agent 真正跑复杂任务时，问题大多出在这些地方。

这一篇你要记住

DeerFlow 的核心不是“模型回答问题”。

它调度的是一整套执行系统：入口、运行时、Agent、工具、子 Agent、外部服务、沙盒、记忆和产物。

下一篇看项目结构，把这张地图落到真实目录上。