01. DeerFlow 是什么：先知道你在学什么

这一篇先不装环境

先别急着 clone，也别急着看源码。

DeerFlow 这类项目，如果一开始只看 README，很容易把它理解成“又一个 Agent Demo”。

但它更像一个 Agent harness。

这里的 harness，可以理解成一套把 Agent 跑起来的工程外壳：模型、工具、子 Agent、记忆、沙盒、MCP、文件产物、流式输出，都被放到一条可执行链路里。

所以这篇只解决一个问题：

你到底在学什么？

DeerFlow 解决什么问题

普通聊天机器人主要解决“回答问题”。

DeerFlow 更偏“完成任务”。

一次任务大概会经历这些动作：

接收目标
理解上下文
决定下一步
调用工具
必要时拆给子 Agent
把过程和结果变成可追踪的产物

这也是为什么它不只是一个 prompt 示例。

如果一个项目只是在 system prompt 里写很多规则，它很快会卡在工具调用、状态管理、文件隔离、失败排查这些工程问题上。

DeerFlow 真正值得看的地方，是它把这些工程问题放到了一套框架里。

它不是单纯 RAG

RAG 的重点是：

检索资料 → 把资料交给模型 → 生成回答

DeerFlow 可以用检索，但它不止做检索。

它还要处理：

• 工具怎么注册；
• 工具什么时候调用；
• 调用结果怎么回到 Agent；
• 文件和执行环境怎么隔离；
• 外部服务怎么通过 MCP 接进来；
• 任务过程怎么追踪；
• 最后怎么生成报告和文件产物。

所以不要只用“RAG 框架”理解它。

它也不是普通工作流工具

工作流工具通常更确定：

第一步做什么
第二步做什么
第三步做什么

每一步基本写死。

Agent 框架的问题不一样。它允许模型在运行时判断下一步：要不要搜索，要不要抓网页，要不要调用工具，要不要拆给子 Agent。

这会带来灵活性，也会带来麻烦。

比如：

• 模型可能选错工具；
• 工具可能返回脏数据；
• 子 Agent 可能跑偏；
• 任务链路可能变得不好排查；
• 输出看起来完整，但证据不够。

所以 DeerFlow 里才会有 tools、guardrails、sandbox、tracing、memory 这些工程模块。

它适合拿来学什么

如果你只是想找一个能聊天的应用，DeerFlow 可能有点重。

但如果你想学 Agent 工程，它很适合。

因为它不是只展示一个漂亮 demo，而是把很多真实问题都摆出来了：

• 模型 provider 怎么配置；
• 搜索和抓取怎么接；
• tools 怎么组织；
• skills 怎么约束行为；
• sub-agents 怎么拆任务；
• sandbox 怎么隔离执行；
• MCP 怎么接外部服务；
• memory 怎么参与上下文；
• tracing 怎么看清失败原因。

这也是后面 29 篇教程要拆开的东西。

适合谁学

比较适合这几类人：

• 已经能跑通 AI 应用，但想往 Agent 工程走的人；
• 想看懂 Tools、Skills、MCP 怎么落到代码里的人；
• 想基于开源框架改一个研究型 Agent 的人；
• 已经把 DeerFlow 跑起来，但不知道下一步该看哪个目录的人。

不太适合只想复制一个 prompt 的人。

因为 DeerFlow 的重点不是“写一句神奇提示词”，而是把任务执行过程工程化。

这一篇你只需要记住

DeerFlow 不是让模型多聊几句。

它更像一套 Agent 执行框架：把模型、工具、子 Agent、记忆、沙盒、MCP 和文件产物串成一条任务链路。

后面的教程会沿着这条链路往下拆。

下一篇开始，我们先把它跑起来。