DeerFlow：字节跳动Agent框架

可视化演示

展示DeerFlow三层架构设计、工作流引擎执行流程、与Dify/Coze平台对比。切换模式查看不同维度。

认识DeerFlow：把后厨打包开源

这家“未来智能餐厅”开业第一天就爆单——每天几十万位客人同时点单，还要求 3 秒内上菜。如果只靠一个主厨在灶台前手忙脚乱，厨房早就瘫痪了。于是餐厅老板决定：把后厨流程标准化，洗菜、备料、炒制、装盘各自分工，再由一套系统统一调度。这套系统就是 DeerFlow。

在 AI 行业里，这套“后厨管理系统”的学名叫“AI Agent 应用开发框架”。所谓 Agent（智能体），就是能自己理解任务、制定计划、调用工具并最终交付结果的 AI 程序。DeerFlow 正是字节跳动开源的企业级 Agent 框架，它解决的核心问题不是“大模型强不强”，而是“如何把大模型、规划、记忆、工具组装成一条能稳定运转的生产线”。

业内常用一个公式来描述 Agent 的组成：

$$\displaystyle \text{Agent}=\underbrace{\text{LLM}}_{\text{主厨大脑}}+\underbrace{\text{Planning}}_{\text{排菜计划}}+\underbrace{\text{Memory}}_{\text{点单记忆}}+\underbrace{\text{Tools}}_{\text{厨房厨具}}$$

1. 主厨大脑 LLM：大语言模型负责理解用户请求、生成自然语言回复，是整套系统最聪明但不会动手的“脑力担当”。

$$\underbrace{\text{LLM}}_{\text{理解与生成}}$$

2. 排菜计划 Planning：把“帮我订一张周五晚上的餐厅”这类大任务拆解成“查餐厅→选座位→提交预订”的小步骤。

$$\underbrace{\text{Planning}}_{\text{任务拆解与排序}}$$

3. 点单记忆 Memory：短期记忆记录对话上下文，长期记忆沉淀用户偏好，相当于后厨记录客人习惯的小本本。

$$\underbrace{\text{Memory}}_{\text{短期上下文+长期档案}}$$

4. 厨房厨具 Tools：查天气、查库存、发邮件等外部能力，让 Agent 从“只说不做”变成“能动手干活”。

$$\underbrace{\text{Tools}}_{\text{外部能力接口}}$$

回到餐厅比喻：DeerFlow 不会替主厨变聪明，但它把“大脑、配方卡、小本本、厨具”科学地组织在同一条流水线上——这正是它作为“后厨管理系统”的价值。客人只关心菜好不好吃，企业只关心 Agent 靠不靠谱，而框架的质量决定这条流水线能扛住多大的订单量。

架构设计：前厅、后厨与仓库

走进这家“未来智能餐厅”，你会发现它的空间被严格分成三块：最外面是接待客人的前厅，中间是主厨指挥调度的后厨，最里面是储藏食材与厨具的仓库。任何一家餐厅想高效运转，这三层缺一不可。

DeerFlow 的架构也按这个逻辑分成三层。最外层是接入层：提供 API、SDK、Web 前端，相当于前厅的点餐台，负责接收用户请求并把回复端出去。中间是核心层：负责 Agent 编排、记忆管理和任务规划，相当于后厨的调度台。最底层是工具层：通过 MCP、插件等方式接入各种外部能力，相当于堆满食材和厨具的仓库。

用一句话描述一次请求在这三层之间的流动，可以写成：

$$\displaystyle Y = f_{\text{core}}\big(X,\, \underbrace{\mathcal{T}}_{\text{工具集}},\, \underbrace{\mathcal{M}}_{\text{记忆}}\big)$$

1. 用户输入 X：客人说“今天北京天气怎么样”，这条消息就是 X，它由接入层接收并规范化后传入核心层。

$$\underbrace{X}_{\text{用户请求}}$$

2. 核心调度 f_core：核心层像调度台一样决定“先规划、再选工具、最后生成回复”的整体流程。

$$\underbrace{f_{\text{core}}}_{\text{核心编排引擎}}$$

3. 工具集 T：仓库里所有可用工具的集合，包括天气查询、订单查询等外部服务。

$$\underbrace{\mathcal{T}}_{\text{可用工具集合}}$$

4. 记忆 M：对话历史与用户画像，让 Agent 记住“客人不吃香菜”这样的细节。

$$\underbrace{\mathcal{M}}_{\text{对话与偏好记忆}}$$

5. 最终回复 Y：把加工完成的“菜品”交给接入层，最终送回客人面前。

$$\underbrace{Y}_{\text{最终输出回复}}$$

正因为有了前厅、后厨、仓库的分工，DeerFlow 才能在不打扰客人的前提下，让主厨专注思考、让仓库按需供货。三层各司其职，也让企业在替换前端或更换工具时，不需要把整间厨房推倒重建。

工作流引擎：配方卡与传送带

高档餐厅的后厨里，每道菜都有一张配方卡：第一步腌肉 5 分钟，第二步同时开两个灶口，第三步装盘前撒葱花。而连接各工位的传送带保证——上一道工序没做完，半成品绝不会流到下一个工位。

工作流引擎正是 DeerFlow 后厨里的“配方卡+传送带”。开发者用代码声明一个工作流：哪些节点必须串行、哪些节点可以并行、哪个条件成立时才走某个分支。引擎拿到这份“配方卡”后，自动安排每个节点在合适的时机执行，并且节点执行时会记录状态，进程崩溃后还能从断点恢复。

计算机里，这种工作流的结构是一个有向无环图（DAG），它的执行规则可以写成：

$$\displaystyle G=(V,E),\qquad v_j\text{ 可执行}\iff \bigwedge_{v_i\in \operatorname{pred}(v_j)} \operatorname{done}(v_i)$$

1. 节点集合 V：V 是所有工序（节点）的集合，比如“查天气”“查库存”各是一个节点。

$$\underbrace{V}_{\text{任务节点集合}}$$

2. 有向边集合 E：E 中的每条有向边表示“必须先完成后才能开始下一个”的依赖关系。

$$\underbrace{E}_{\text{依赖关系边}}$$

3. 前驱集合 pred(v_j)：指向节点 v_j 的所有上游节点，相当于这道工序之前必须完成的备料步骤。

$$\operatorname{pred}(v_j)=\{v_i\mid (v_i,v_j)\in E\}$$

4. 全部完成判定：∧ 表示“并且”，所有前驱 done 为真时 v_j 才满足执行条件，从而支持并行分支各自等待。

$$\bigwedge_{v_i\in \operatorname{pred}(v_j)} \operatorname{done}(v_i)$$

有了“配方卡+传送带”，DeerFlow 的后厨可以同时开很多条流水线：不同客人的订单互不干扰，同一订单里“查天气”和“查空气”还能并行。这也是工作流引擎相比简单 if-else 脚本的核心优势——把复杂任务编排得井井有条。

工具集成：厨具抽屉与点菜卡

后厨仓库里有一面工具墙，每把厨具都挂着一张小小的“点菜卡”，写着名字和用法，比如“查天气→需要城市名，返回温度与天气”。主厨只需要瞥一眼卡片，就能决定用哪把刀，而不用把整个仓库翻个底朝天。

DeerFlow 的工具集成机制正是这个思路。每个工具必须向框架“注册”自己的名字、参数和返回值（schema），大模型根据用户需求从注册表里选工具、生成参数。工具之间的通信遵循 MCP（Model Context Protocol）协议，这就好比给所有厨具统一了插头规格——无论哪家厂商的烤箱，插上就能用。

当多个工具都“看起来有用”时，框架如何决定选谁？可以理解成一个打分后归一化的过程：

$$\displaystyle \pi(a_t\mid s_t)=\frac{\exp\bigl(\operatorname{score}(s_t,a_t)\bigr)}{\sum_{a'\in \mathcal{A}}\exp\bigl(\operatorname{score}(s_t,a')\bigr)}$$

1. 当前状态 s_t：包括用户请求、对话上下文和已有结果，是主厨做决策时的“厨房现场”。

$$\underbrace{s_t}_{\text{当前任务状态}}$$

2. 单个工具得分：score(s_t, a_t) 表示工具 a_t 在当前状态下的匹配程度，可来自大模型或规则。

$$\operatorname{score}(s_t,a_t)$$

3. 分母归一化：对所有候选工具 a' 的得分求和，把分数转换为概率分布，保证概率之和为 1。

$$\sum_{a'\in \mathcal{A}}\exp\bigl(\operatorname{score}(s_t,a')\bigr)$$

4. 最终选择概率：π(a_t|s_t) 是选中工具 a_t 的概率，引擎按概率采样或直接取最大者执行。

$$\pi(a_t\mid s_t)\in[0,1]$$

工具墙的设计让 DeerFlow 的“餐厅”可以不断添置新厨具：企业内部系统、第三方 API、甚至另一个 Agent，都可以通过统一协议接入。主厨不用记住每把厨具的内部构造，拿起“点菜卡”就能上手——这大大降低了 Agent 接入真实业务系统的门槛。

生态对比：三种餐厅流派

社区里其实开着三种“AI 餐厅”。Dify 像标准化的快餐中央厨房：可视化操作、配方统一，适合快速出餐；Coze 像开放市集的小摊：人人都能摆摊，不用懂编程；而 DeerFlow 更像可深度定制的高端餐厅后厨：需要会写代码的厨师，但能做出最有辨识度的菜。

从技术定位看，三者的差异很清晰。Dify 是开源的 LLMOps 平台，主打可视化编排和模型运营，适合产品经理快速搭 AI 应用；Coze（扣子）是字节推出的无代码 Agent 平台，面向 C 端玩家，内置大量插件和 Bot 商店；DeerFlow 则是代码优先的 Agent 开发框架，强调高并发、异步编排和深度定制，面向企业开发者。

选型时可以用一个简单模型评估总投入：

$$\displaystyle C_{\text{total}}=C_{\text{dev}}+C_{\text{run}}+C_{\text{learn}}$$

1. 开发成本 C_dev：从零搭出一个可用 Agent 所需的人力与时间，Dify/Coze 显著低于 DeerFlow。

$$\underbrace{C_{\text{dev}}}_{\text{开发成本}}$$

2. 运行成本 C_run：并发规模增大后的算力与运维开销，DeerFlow 的异步高并发设计更占优势。

$$\underbrace{C_{\text{run}}}_{\text{运行成本}}$$

3. 学习成本 C_learn：团队掌握该平台所需的学习曲线，代码框架对新手更陡。

$$\underbrace{C_{\text{learn}}}_{\text{学习成本}}$$

三家“餐厅”没有绝对的高下：快餐店求速度、市集小摊求热闹、高端餐厅求品质。企业应该先想清楚自己的客群和菜品——需要灵活定制复杂企业流程，DeerFlow 是更合适的那口锅。

字节技术栈：自家的食材供应链

一家高端餐厅的底气，往往来自稳定的食材供应链。DeerFlow 背后，字节跳动同样铺设了一条完整的“供应链”：顶级的食材由豆包大模型提供，冷链物流由火山引擎负责，仓库管理系统则跑在云原生底座上。

具体来说，豆包（Doubao）大模型为 Agent 提供底层的理解和生成能力；火山引擎的 ModelArk 等云服务负责模型部署、推理加速与算力调度；基础设施层基于 Kubernetes 等云原生技术，让工作流引擎可以弹性伸缩。整条链路从模型到算力再到框架，形成了字节自有的 Agent 技术栈。

从用户发起请求到收到回复，整条链路的时延可以分解成：

$$\displaystyle T_{\text{e2e}}=T_{\text{gateway}}+T_{\text{llm}}+\sum_{k=1}^{K}T_{\text{tool},k}+T_{\text{memory}}$$

1. 网关时延 T_gateway：接入层转发请求的开销，通常为毫秒级，与框架路由性能相关。

$$\underbrace{T_{\text{gateway}}}_{\text{网关转发时延}}$$

2. 大模型时延 T_llm：豆包等大模型推理生成内容的时间，是整个链路中占比最大的部分。

$$\underbrace{T_{\text{llm}}}_{\text{大模型推理时延}}$$

3. 工具调用时延求和：K 次工具调用（查库存、查物流）各自耗时的总和，并行执行时取最大值而非求和。

$$\sum_{k=1}^{K}T_{\text{tool},k}$$

4. 记忆读写 T_memory：读写短期上下文与长期记忆的耗时，数据库与缓存设计会影响这一项。

$$\underbrace{T_{\text{memory}}}_{\text{记忆读写时延}}$$

供应链强大，后厨才能放开手脚。字节的这套技术栈让 DeerFlow 一出生就“含着金汤匙”：深度适配豆包模型、无缝对接火山引擎云服务，同时也保持了对其他模型和云厂商的开放——毕竟一家餐厅总不能只吃自家农场种的菜。

企业落地：连锁餐厅的标准化扩张

当一家餐厅要开成连锁时，最大的挑战不是一道菜好不好吃，而是如何把后厨流水线复制到每家分店、并保证所有分店出品一致。企业级 Agent 落地也是如此：代码写好了只是开始，稳定、可运维、可评估才是关键。

DeerFlow 在企业落地中最常见的场景包括智能客服、营销助手和数据分析 Agent。以智能客服为例，工作流被拆成“意图识别→查订单→查物流→生成回复”四个节点；工具层对接企业订单系统；状态管理保证多轮对话不漏信息；事件驱动让“物流有更新就主动通知用户”这类长时任务真正可行。

衡量落地效果，最核心的指标是任务成功率：

$$\displaystyle R=\frac{1}{M}\sum_{m=1}^{M}\mathbb{1}[\text{任务}_m\text{ 成功}]$$

1. 测试样本数 M：选择 M 条真实或模拟的用户请求作为评估集，M 越大评估越可靠。

$$\underbrace{M}_{\text{测试任务数}}$$

2. 单次成功指示：指示函数 1[·] 在任务成功时取 1，失败或未完成时取 0。

$$\mathbb{1}[\text{任务}_m\text{ 成功}]$$

3. 求平均成功率：对所有样本的指示值求平均，得到 0 到 1 之间的成功率，越高说明 Agent 越可靠。

$$R=\frac{1}{M}\sum_{m=1}^{M}\mathbb{1}[\cdot]$$

连锁餐厅的扩张从来不是把厨房图纸复制一遍那么简单——每个分店的场地、客流、食材供应都不同。DeerFlow 的价值在于：它提供了一套可复制、可监控、可扩展的后厨标准，让企业把精力花在“菜品研发”（业务逻辑）上，而不是每次都重新砌一遍灶台。

AI 应用场景

Python 演示

"""mini_deerflow.py: 迷你版DeerFlow工作流引擎演示"""from collections import deque  class Node:    """工作流中的一个任务节点"""    def __init__(self, name, deps, fn):        self.name = name        self.deps = deps      # 前置节点名列表        self.fn = fn          # 节点执行的函数        self.done = False  class MiniDeerFlow:    """支持DAG依赖检查的迷你工作流引擎"""    def __init__(self):        self.nodes = {}     def add(self, node):        self.nodes[node.name] = node     def run(self):        state = {}        ready = deque(n for n in self.nodes.values() if not n.deps)        while ready:            node = ready.popleft()            state.update(node.fn(state))            node.done = True            print("[执行] %s -> %s" % (node.name, state))            for n in self.nodes.values():                if not n.done and all(self.nodes[d].done for d in n.deps):                    if n not in ready:                        ready.append(n)        return state  def fn_city(st):    return {"city": "北京"}  def fn_weather(st):    return {"weather": "晴 26C"}  def fn_air(st):    return {"air": "空气优"}  def fn_reply(st):    return {"reply": "%s今日%s, %s" % (st["city"], st["weather"], st["air"])}  def main():    flow = MiniDeerFlow()    flow.add(Node("确定城市", [], fn_city))    flow.add(Node("查询天气", ["确定城市"], fn_weather))    flow.add(Node("查询空气", ["确定城市"], fn_air))    flow.add(Node("生成回复", ["查询天气", "查询空气"], fn_reply))    result = flow.run()    print("最终回复:", result["reply"])  if __name__ == "__main__":    main()

1. ready = deque(n for n in self.nodes.values() if not n.deps)找出所有没有前置依赖的节点作为流水线起点
2. state.update(node.fn(state))执行节点函数并把结果写入全局状态，相当于半成品在工序间传递
3. all(self.nodes[d].done for d in n.deps)检查某个节点的所有前置节点是否都已完成，这是“传送带不放行”的判定
4. if n not in ready防止同一个节点被重复加入待执行队列
5. flow.add(Node("查询天气", ["确定城市"], fn_weather))用依赖声明把节点挂进工作流，“配方卡”由此生成

常见误区

面试题