Software 2.0

DeerFlow 2.0 简明指南

admin -

ByteDance 的 DeerFlow 2.0 让我大吃一惊。

它为代理提供了一个真正的隔离计算机，即具有文件系统、bash 终端以及能够读取、写入和执行文件的 Docker 容器。

在你问"它与本地模型运行得如何？"之前，让我在深入细节之前简要说明一下：

  • 本地模型能否处理任务分解所需的推理？ DeerFlow 的主代理需要决定何时生成子代理，如何将复杂的提示分解为结构化的子任务，以及如何综合结果。这需要强大的指令遵循和结构化输出能力。像 Qwen 3.5 和 DeepSeek 这样的模型可能能够处理。较小的模型可能不行。
  • 多模型的 VRAM 限制。 如果你想为不同的子代理使用不同的专用模型（例如，Qwen 用于编程，DeepSeek 用于导航），你需要足够的 VRAM 来同时运行它们。
  • 模型之间的上下文传输很棘手，因为每个模型具有不同的分词器和上下文限制。

此外，提供的渐进式技能加载和激进摘要在这里有帮助，它们保持上下文需求较低，但这不是对仅本地部署用于生产工作负载的认可。

这个更广泛的区别也出现在我对 DeerFlow 的研究中，我了解到它最初是 ByteDance 内部的一个深度研究工具，后来内部团队将其扩展到数据管道、仪表板和完整的 Web 应用程序。

ByteDance 看到了正在发生的事情，并从头开始重写了整个东西。

DeerFlow 2.0 是一个专门构建的 SuperAgent harness。

让我们直接深入了解。

1、执行鸿沟

当你构建一个生成漂亮报告的研究代理，但你需要手动将报告转换为幻灯片，或手动执行它建议的 SQL，或手动部署它草绘的网站。

代理完成了 60% 的认知工作，0% 的执行工作。

在那种情况下，DeerFlow 的时机是有意义的。

我们已经达到了一个点：

  1. LLM 足够强大，可以可靠地规划多步骤任务（不完美，但可靠到足以有用）。
  2. 容器隔离很便宜。 Docker、Kubernetes 和沙盒运行时已经成熟。给代理自己的文件系统不再是一个工程登月任务。
  3. 社区想要执行引擎，而不是更多的聊天界面。DeerFlow 2.0 在 2026 年 2 月 28 日发布后不久就在 GitHub Trending 上排名第一，攀升至 17.7k+ 星标和 74 个贡献者。

我认为这个赌注在方向上是正确的，即使执行在某些地方仍然粗糙。

2、DeerFlow 2.0 简要介绍

DeerFlow（Deep Exploration and Efficient Research Flow）2.0 是一个开源的 SuperAgent harness。

它是一个包含电池的系统，用于编排子代理、内存、沙盒执行和可扩展的技能，以处理复杂的多步骤任务。

技术栈：

DeerFlow 是模型无关的，它适用于任何实现 OpenAI 兼容 API 的 LLM，例如 GPT-5、Claude、Gemini、DeepSeek、Qwen，或通过 Ollama 的完全本地模型。

你在 conf.yaml 中配置你的模型，系统的其余部分不在乎你选择了哪个提供商，这意味着你的编排层与你的推理层解耦。

3、沙盒：拥有自己计算机的 AI

每个任务都在一个具有真实文件系统的隔离 Docker 容器中运行：

/mnt/user-data/
├── uploads/  ← your files
├── workspace/  ← agents' working directory
└── outputs/  ← final deliverables

代理读取文件、写入文件、执行 bash 命令、安装 pip 包、查看图像。

所有都是沙盒化的、可审计的，并且会话之间零污染。

DeerFlow 根据你的部署支持三种沙盒模式：

  • 本地执行： 直接在主机上运行（最快，最少隔离）
  • Docker 执行： 隔离的容器（推荐用于开发）
  • Docker + Kubernetes： 通过 provisioner 服务进行完整的 pod 隔离（生产级）

以下是一些你会在生产环境中想要的资源控制沙盒模式：

需要明确的是，开箱即用的沙盒不是生产硬化的。

你应该在部署之前*"添加 MCP/Python REPL 的身份验证"*，这是一个你对最后一英里安全负责的情况。

感谢阅读本文。我正在写一本关于 Agentic SaaS 的深入电子书，悄悄地为 2026 年最具创新性的初创公司提供动力的新兴设计模式。
你可以在这里阅读： Agentic SaaS Patterns Winning in 2026，充满了真实世界的例子、架构和工作流程，你在其他地方找不到。

4、处理上下文溢出

上下文溢出是代理工作流程的无声杀手。

DeerFlow 用三种机制处理这个问题：

4.1 渐进式技能加载

技能仅在任务需要时加载，而不是一次性加载。

这使上下文窗口保持精简。

对于具有严格令牌预算的本地模型（想想 8K–32K），这是可以工作和在第 3 步崩溃之间的区别。

4.2 摘要中间件

SummaryMiddleware 监控上下文大小，并在可配置的触发器触发时压缩它，基于令牌数、消息数或上下文分数。

它保留最近的消息，同时总结较旧的消息。

在一个会话中，DeerFlow 还将中间结果卸载到文件系统，因此即使对于长时间运行的多步骤任务，活动上下文也保持在模型限制内。

对于我自己的工作，我发现最有用的模式是摘要 + 文件系统卸载。

这与我一直手动使用的方法相同，但 DeerFlow 在编排层自动化了它。

4.3 长期记忆

DeerFlow 构建你的个人资料、偏好和跨会话积累的知识持久记忆。

你越多使用它，它就越了解你的写作风格、你的技术堆栈、你的重复工作流程。

记忆存储在本地并保持你的控制之下。

DeerFlow 使用 LLM 驱动的提取从对话中提炼持久事实，并使用防抖更新存储在 JSON 中。

此外，LangGraph 检查点（Postgres 或 MongoDB）处理用于恢复中断工作流的线程状态持久性。

这与从 OpenClaw 生态系统出现的情况一致，代理也在那里持久化记忆，但通过 ~/.openclaw/workspace/ 中的纯文本 Markdown 文件（MEMORY.md、SOUL.md）。

这种权衡是否对你有效完全取决于你重视结构化的 LLM 提取记忆（DeerFlow）还是 git 友好的透明度（OpenClaw）。

5、在ChatGPT订阅上运行DeerFlow

社区已经在以 ByteDance 可能没有预料到的方式扩展 DeerFlow。

OAuth 桥接，让 DeerFlow 使用你现有的 ChatGPT Plus/Pro 订阅与 GPT-5.4 对话。

桥接器在 127.0.0.1:8462 本地运行，并在 DeerFlow 的 Chat Completions 格式和 OpenAI 的 Codex Responses API 之间进行翻译。

设置：

git clone https://github.com/trentster/deerflow-oauth-bridge.git
cd deerflow-oauth-bridge
./setup.sh  # Creates venv, browser OAuth login (one-time)
python server.py  # http://127.0.0.1:8462

然后在 DeerFlow 的 config.yaml 中：

- name: gpt-5.4
    display_name: GPT-5.4 (OAuth Bridge)
    use: langchain_openai:ChatOpenAI
    model: gpt-5.4
    api_key: "not-needed"
    base_url: http://127.0.0.1:8462/v1
    max_tokens: 4096
    temperature: 0.7

完整的工具调用、网络搜索、多步骤研究、流式传输都将工作。

这是社区构建的，不是 ByteDance 或 OpenAI 官方支持的，但它展示了关于 DeerFlow 架构的一个关键点。

因为它是模型无关的并使用标准的 OpenAI 兼容端点，社区扩展的表面积是巨大的。

通过桥接确认工作的模型包括 GPT-5 到 GPT-5.4（推荐）。GPT-5-mini、nano 和 codex 变体不支持 Codex OAuth。

6、DeerFlow vs. OpenClaw

让我们看看它们的不同之处。

OpenClaw 非常适合个人自动化和消息优先的工作流程，但对于多步骤研究、代码执行管道和复杂的交付物生成，DeerFlow 的基于主管的编排与并行子代理在架构上更适合。

OpenClaw 的优势在于其消息优先的界面和通过 ClawHub 的 700+ 社区技能。

如果你想要一个监控你的收件箱、管理你的智能家居、并通过 Telegram 提醒你会议的 AI，OpenClaw 在那里获胜。

7、本地运行 DeerFlow

这里是最小设置。

# Clone and generate config files
git clone https://github.com/bytedance/deer-flow.git
cd deer-flow
make config  # Creates config.yaml and .env from templates

# Set your API keys in .env
# OPENAI_API_KEY=your-key
# TAVILY_API_KEY=your-key (for web search)

Docker（推荐）

make docker-init # Pull sandbox image (first time only)
make docker-start  # Start all services
# Access at http://localhost:2026

本地开发

make check  # Verify Node.js 22+, pnpm, uv, nginx
make install  # Install backend + frontend deps
make dev  # Start services
# Access at http://localhost:2026

在 config.yaml 中，你使用 LangChain 类路径定义你的模型：

models:
  - name: gpt-4
    display_name: GPT-4
    use: langchain_openai:ChatOpenAI
    model: gpt-4
    api_key: $OPENAI_API_KEY
    max_tokens: 4096
    temperature: 0.7

对于本地 Ollama 模型，相同的模式：

- name: qwen3.5
  use: langchain_openai:ChatOpenAI
  model: qwen3.5:latest
  api_key: "not-needed"
  base_url: http://localhost:11434/v1

重要的是什么

1. 沙盒优先的架构是正确的默认选择： 这消除了在实践中破坏代理实用性的交接问题。

2. 隔离的子代理上下文是一个特性： 通过给每个子代理自己的作用域上下文，DeerFlow 避免了"共享上下文汤"问题，这个问题会降低多代理性能。

3. 渐进式技能加载被低估了： 按需加载技能而不是将所有内容前置到提示中，对于本地模型兼容性以及在使用云模型时保持令牌成本合理至关重要。

4. 编排层的模型无关性是不可商量的： DeerFlow 的模型工厂在运行时解析 LangChain 类路径，因此你可以在不改变编排逻辑的情况下在 OpenAI、Anthropic、DeepSeek 或本地模型之间切换。这是正确的抽象边界。

然而，我发现当有人诚实地说明它在何处失败时，我更愿意采用一个框架。

所以这是我的列表：

  • 主代理质量随着较弱模型而下降。 整个系统依赖于主代理生成良好的任务分解并知道何时生成子代理。如果你的 LLM 生成模糊或结构不良的计划，每个下游子代理都会受苦。
  • 简单任务的 Docker 开销。 为快速问题启动容器是过度设计。DeerFlow 支持本地执行模式，但在模式之间切换是配置更改。
  • LangChain 依赖权重。 完整的 Python 生态系统（LangChain、LangGraph 以及所有工具依赖）很重。make install 干净地处理它，但冷安装并不快。
  • 安全表面积。 MCP 服务器、Python REPL、bash 执行是强大的工具。如果在没有身份验证的情况下暴露，它们也是攻击向量。默认设置绑定到 localhost，这对于开发是可以的，但不适合部署。
  • 没有原生速率限制或成本控制。 如果你的每个子代理并行进行 50 次 API 调用，你的云账单会线性扩展。没有内置的预算执行。

你可以将 DeerFlow 用于复杂的多步骤研究到交付物管道，你需要代理实际执行代码并生成工件，并将 OpenClaw 用于个人自动化和消息优先的工作流程。

我还建议你继续关注基于 Go 的替代方案，用于二进制可移植性重要的生产部署。

原文链接: DeerFlow 2.0: Open-Source SuperAgent Harness

汇智网翻译整理，转载请标明出处