note

• DeerFlow是一个面向长程任务的 Agent Runtime：规划 → 调度 → 执行 → 观察 → 修正 → 记忆 → 产出
• 单靠模型本身，很难稳定完成长程任务。因为模型没有天然的文件系统、执行环境、长期记忆、任务调度和失败恢复机制。所以 DeerFlow 做的是补齐这些缺失的基础设施。
• 把 LLM 的生成能力，接入了一个可执行、可恢复、可协作、可交付的运行时环境：
  • 任务调度器：决定下一步做什么
  • 工具系统：提供外部能力
  • 沙箱环境：执行代码和文件操作
  • 文件系统：保存中间产物和最终产物
  • 记忆系统：保存状态和经验
  • 技能系统：复用已有工作流
  • 子 Agent 系统：拆分和并行任务
  • 消息网关：管理长任务过程中的通信和状态返回
• DeerFlow 的 skill 机制是“Prompt 摘要路由 + 文件渐进加载 + 工具权限过滤”。

DeerFlow：长程任务执行 Runtime

最近看 DeerFlow，第一感觉是：它不是一个“再包一层 function call”的 Agent demo，而更像一个给大模型配齐干活基础设施的 long-horizon agent runtime。

很多 Agent 框架的问题是，它们看起来会规划、会调用工具、会回答问题，但真正遇到复杂任务时，很快会暴露几个现实问题：

• 任务一长，上下文就爆；
• 中间状态没人管，做着做着就丢信息；
• 模型能写代码，但代码谁来跑、文件谁来存；
• 工具调用失败后，怎么恢复、怎么继续；
• 一个任务拆成多个子任务后，谁负责调度、汇总；
• 最后用户要的是可交付产物，而不是一段“看起来很努力”的回答。

DeerFlow 想解决的正是这些问题。

它的核心不是“模型会不会调用工具”，而是：如何把大模型放进一个可持续执行任务的运行时系统里，让它能稳定推进分钟到小时级的复杂任务，并最终交付真实结果。

---

一、DeerFlow 的本质

1、把 LLM 变成 long-horizon task operator

传统对话式 LLM 更像一个“会说话的大脑”：你问一句，它答一句；你让它写代码，它给你一段代码；你让它规划任务，它给你一份计划。

但真实任务不是这么运行的。

真实任务需要：

• 查资料；
• 写代码；
• 执行代码；
• 读写文件；
• 调工具；
• 多轮修正；
• 保存中间状态；
• 失败后重试；
• 最后产出报告、代码、网页、图表或其他文件。

所以 DeerFlow 的思路不是简单让模型“多想一点”，而是给模型配一个完整工作台：

有总控 Agent，有工具系统，有沙箱环境，有文件系统，有记忆，有技能库，有子 Agent，有消息通道，有产物管理。

DeerFlow框架的模块：

模块	作用	通俗理解
Coordinator / 主控 Agent	接收任务、控制全局状态、决定下一步	项目经理
Planner	把长任务拆成多个阶段和子任务	任务拆解器
Sub-Agents	不同 Agent 负责搜索、代码、内容生成等子任务	专家团队
Skills	可扩展能力包，规定某类任务怎么做	SOP / 专家技能
Memory	记录历史上下文、经验、偏好和中间状态	长期记忆
Sandbox	隔离执行代码、文件处理、实验验证	安全工作台
Tools / MCP / Browser	搜索、浏览、API、代码执行等外部能力	工具箱
Message Gateway	负责 Agent 之间通信和任务分发	调度总线
Reporter	汇总中间结果，形成最终报告/文件	交付负责人

注意点：

• DeerFlow Gateway 管的是 Agent 内部协作（用于主 Agent 与 Sub-Agent、工具、沙箱之间的任务分发、状态同步和结果回传）；
• OpenClaw Gateway 管的是外部用户消息和设备通道。

2、和其他agent框架区别

普通 function call Agent 的典型流程是：

用户请求 → 模型判断要不要调工具 → 调工具 → 根据工具结果回答

这个流程适合简单任务，比如查天气、搜资料、调用一次接口、生成一段文本。

但长程任务不一样。

长程任务可能是：

用户请求
→ 拆解任务
→ 搜索资料
→ 写代码
→ 运行代码
→ 发现报错
→ 修改代码
→ 生成文件
→ 再检查文件
→ 调整格式
→ 汇总结果
→ 输出最终产物

这里真正难的不是“会不会调一个工具”，而是整个执行过程的稳定性。

DeerFlow 关心的是：

任务如何被持续推进？
状态如何被保存？
上下文如何被压缩？
工具如何被编排？
代码如何被执行？
文件如何被管理？
子任务如何被分派？
产物如何被交付？

所以它不是一个轻量工具调用壳子，而是一套长程任务执行底座。

---

二、DeerFlow 的核心架构

可以把 DeerFlow 拆成几层来看。先看总体流程图：

1. Lead Agent：任务总控

Lead Agent 可以理解为整个系统的大脑和项目经理。

它负责理解用户目标、拆解任务、决定下一步该做什么：

• 是先搜索资料？
• 是写代码？
• 是调用某个工具？
• 是使用某个 Skill？
• 是派一个子 Agent 去处理？
• 是继续执行，还是结束任务？

这比单纯的“模型直接回答”多了一层任务调度能力。

---

2. Middleware Chain：运行时注入层

DeerFlow 真正有 runtime 味道的地方，在于它不是把所有东西都硬塞进 prompt，而是通过一系列 middleware 给 Agent 注入运行时能力。

这些能力包括：

• 当前工作目录；
• 文件上下文；
• 记忆信息；
• sandbox 状态；
• 工具列表；
• skill 信息；
• 上下文压缩结果；
• 任务执行状态。

也就是说，模型每一步看到的不是一坨原始对话历史，而是被运行时整理过的、对当前决策有用的信息。

这对长程任务非常关键。

因为长任务里最容易出问题的地方，就是上下文越来越乱，模型不知道自己做到哪一步，也不知道哪些信息重要。

---

3. Sandbox：让 Agent 真正“动手干活”

很多 Agent demo 最大的问题是：模型能说，但不能真的做。

比如模型可以说：

我建议你运行这段 Python 代码。

但真实任务里，用户更希望它直接把代码跑完，检查结果，必要时修改，再生成文件。

DeerFlow 的 sandbox 就是为了解决这个问题。

有了 sandbox，Agent 不只是生成文本，而是可以：

• 创建文件；
• 运行代码；
• 调试报错；
• 读取输出；
• 生成图表；
• 保存结果；
• 管理中间产物。

这让 Agent 从“建议者”变成“执行者”。

这也是 DeerFlow 和普通聊天助手的重要区别。

---

4. Subagents：不是一个 Agent 硬扛所有任务

复杂任务往往天然适合拆分。

比如一个调研任务，可能包括：

• 一个子任务负责搜索资料；
• 一个子任务负责整理结构；
• 一个子任务负责写代码分析数据；
• 一个子任务负责生成最终报告。

如果所有事情都让一个 Agent 从头做到尾，就会出现上下文过长、职责混乱、推理不稳定的问题。

DeerFlow 引入 subagents，本质上是在做多 Agent 分工：

Lead Agent 负责总控
Subagents 负责局部任务执行
最后再汇总结果

这更接近真实工作流：不是一个人从头干到尾，而是项目经理协调多个执行者。

---

5. Skills：把高频能力封装成可复用模块

如果每次任务都让模型从零开始想怎么做，成本很高，也不稳定。

Skill 的价值在于，把一类高频任务流程沉淀下来。

比如：

• 如何做深度研究；
• 如何生成报告；
• 如何处理某类文件；
• 如何跑某种数据分析；
• 如何生成某类代码产物。

有了 Skill，Agent 不需要每次重新发明流程，而是可以调用已有能力。

这和普通工具不同。工具通常是一个具体接口，比如搜索、读文件、执行代码。Skill 更像是一套封装好的任务模式或操作手册，里面可能包含步骤、约束、脚本、资源和经验。

所以 DeerFlow 里的 Skill 更接近“可复用工作流能力”，不是简单 API。

【Skill 是怎么进入 Prompt 的】
参考代码deer-flow/backend/packages/harness/deerflow/agents/lead_agent/prompt.py
注意事项：
1、加了LRU缓存，避免重复拼 prompt
2、模型先看skill description，如果query和对应skill match，就去使用read_file工具读取对应skill的文件内容（渐进式披露）

@lru_cache(maxsize=32)
def _get_cached_skills_prompt_section(
    skill_signature: tuple[tuple[str, str, str, str], ...],
    available_skills_key: tuple[str, ...] | None,
    container_base_path: str,
    skill_evolution_section: str,
) -> str:
    filtered = [(name, description, category, location) for name, description, category, location in skill_signature if available_skills_key is None or name in available_skills_key]
    skills_list = ""
    if filtered:
        skill_items = "\n".join(
            f"    <skill>\n        <name>{name}</name>\n        <description>{description} {_skill_mutability_label(category)}</description>\n        <location>{location}</location>\n    </skill>"
            for name, description, category, location in filtered
        )
        skills_list = f"<available_skills>\n{skill_items}\n</available_skills>"
    return f"""<skill_system>
You have access to skills that provide optimized workflows for specific tasks. Each skill contains best practices, frameworks, and references to additional resources.

**Progressive Loading Pattern:**
1. When a user query matches a skill's use case, immediately call `read_file` on the skill's main file using the path attribute provided in the skill tag below
2. Read and understand the skill's workflow and instructions
3. The skill file contains references to external resources under the same folder
4. Load referenced resources only when needed during execution
5. Follow the skill's instructions precisely

**Skills are located at:** {container_base_path}
{skill_evolution_section}
{skills_list}

</skill_system>"""

对应流程图如下：

6. Memory：解决长任务状态和经验积累问题

长程任务里，记忆很重要。

没有 memory，Agent 每一步都只靠当前上下文，很容易出现：

• 忘记用户最初要求；
• 忘记前面生成过什么；
• 忘记某个工具失败过；
• 重复做已经完成的步骤；
• 任务跨会话后无法接续。

DeerFlow 把 memory 作为基础组件，目的就是让 Agent 能保存任务状态、中间结论和历史经验。

这也是从“单轮助手”走向“长期执行系统”的必要能力。

---

三、它的技术价值在哪里？

1. Agent Orchestration

它关注如何编排任务、工具、Skill 和子 Agent，而不是只关注单次模型输出。

2. Execution Environment

它给 Agent 提供真实执行环境，让模型可以运行代码、操作文件、生成产物。

3. Long-horizon State Management

它处理长任务里的上下文、状态、记忆和中间结果，避免任务执行过程中信息丢失。

4. Reusable Capability

通过 Skills 和 Memory，把一次任务中的经验变成后续任务可复用的能力，而不是每次从零开始。

Reference

[1] https://github.com/bytedance/deer-flow