06. 执行链路：一次任务从入口到结果

这一篇追一条线

前面看了目录，这一篇只追一次任务。

先不要纠结每个类怎么实现。先知道请求从哪里进来，结果从哪里出去。

第一步：前端发起任务

用户在页面输入目标后，前端会调用后端 Gateway。

你在后端目录里能看到和任务相关的路由：

backend/app/gateway/routers/thread_runs.py
backend/app/gateway/routers/runs.py
backend/app/gateway/routers/threads.py

这说明 DeerFlow 把“会话”和“执行”分开了。一个 thread 可以有多个 run，一次 run 才是真正的任务执行。

第二步：runtime 接管 run

run 创建后，runtime 负责管理它的状态。

相关目录：

backend/packages/harness/deerflow/runtime/

这里能看到 runs、events、store、stream_bridge、checkpointer 等模块。

你可以把 runtime 理解成任务执行的底座：它记录 run 状态，也负责把中间事件送回前端。

第三步：Lead Agent 决定下一步

Agent 拿到目标后，不是一次性输出答案。

它会根据上下文决定下一步：

需要搜索吗？
需要抓网页吗？
需要调用工具吗？
需要拆给子 Agent 吗？
需要写文件吗？

这就是 Agent 和普通聊天机器人的差别。

第四步：工具和外部能力参与

工具相关目录：

deerflow/tools/
deerflow/mcp/
deerflow/sandbox/

Tool 负责动作，MCP 负责外部服务，sandbox 负责执行边界。

如果任务涉及文件生成或代码执行，sandbox 就会变得很重要。

第五步：结果返回

结果不只是最后一段文字。

一次任务可能产生：

中间事件
工具调用记录
文件产物
最终回复
tracing 数据

所以排错时不要只看最终回复，要看整条 run 的事件流。

这一篇你要记住

DeerFlow 的执行链路可以先记成：

Gateway → Runtime → Lead Agent → Tools / Sub-agents / MCP / Sandbox → Streaming / Artifacts

后面所有源码篇，都是在拆这条链路上的某一段。