--- title: "DeerFlow 2.0：Docker 部署、沙箱与记忆机制" canonical: https://wavect.io/zh/blog/deerflow-2-docker-setup-sandbox-memory/ language: zh description: "DeerFlow 2.0 Docker 部署指南：补齐配置和初始化步骤，区分子智能体上下文与沙箱隔离，排查记忆提取和 token 成本问题，并用生产检查清单验证权限、恢复与预算。" image: "https://wavect.io/img/blog/headers/header_deerflow-2-docker-setup-sandbox-memory.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年9月28日 最近审核 2026年9月28日 [**下一篇**](/zh/blog/agent-harness-engineering/) # DeerFlow 2.0：Docker 部署、沙箱与记忆机制 要点速览 DeerFlow 2.0 是字节跳动开源的智能体执行框架，用于协调模型、工具、子智能体、技能与任务执行。进行本地 Docker 评估时，应先生成配置、选择沙箱提供方，再运行 make docker-init 和 make docker-start。对话上下文分离不一定意味着沙箱分离，持久记忆也不会消除 token 成本。成功启动只是验证的起点，并不能证明系统已经适合生产环境。 **DeerFlow 2.0 是智能体执行框架，而不是另一个模型。**真正值得问的是：它能否减少自建集成代码，协调工具、文件和专业子智能体，同时保留可验证的运行边界？ [字节跳动官方仓库](https://github.com/bytedance/deer-flow) 将版本 2 描述为一次从头重写，而非此前深度研究系统的小幅更新。 **审阅范围：**本文基于 2026 年 9 月 28 日公开的 2.x `main` 分支文档和实现编写。这不是发布当日新闻，也不是实际安装测试或独立复现的性能基准。后续修订与早期 2.0 代码可能不同，执行以下步骤前请记录所用 commit。 ## DeerFlow 实际负责哪些编排工作？ DeerFlow 基于 LangGraph 和 LangChain，将智能体运行时、工具执行、工作文件与可复用技能整合在一起。 [架构文档](https://github.com/bytedance/deer-flow/blob/main/backend/docs/ARCHITECTURE.md) 介绍了智能体中间件以及基于 `SKILL.md` 文件的扩展方式。它并不替代 LangGraph，而是在这些基础能力之上提供更完整的执行环境。 我们的判断是：当任务需要跨多个步骤研究资料、检查文件、执行代码并产出可验证交付物时，DeerFlow 值得评估。如果固定脚本或普通队列工作流已经能解决问题，增加这套系统的收益就未必明显。关于框架类别与选型，可参考 [智能体执行框架工程指南](/zh/blog/agent-harness-engineering/) 。本文则聚焦 DeerFlow 本身的配置与运行。 执行框架可以减少协调代码，但团队仍需定义成功标准、需要审批的动作、允许发送给模型的数据，以及故障处理责任人。合适的起点是一个有明确边界的工作流，而不是给通用助手接入公司的全部系统。 ## DeerFlow 2.0 Docker 部署：一行命令遗漏了什么？ **克隆仓库后直接启动，并不等于完成首次配置。**以下命令需要 Git、Make、Python 3、合适的 shell、正在运行的 Docker 引擎及 Docker Compose。本次检查的上游说明要求 Compose v2.24 或更高版本。应使用当前 checkout 自带的配置示例，不要混用旧版本文章中的片段。 ### 1. 克隆上游仓库并生成配置 ``` set -eu git clone https://github.com/bytedance/deer-flow.git cd deer-flow git rev-parse HEAD docker compose version make config ``` 将输出的 commit 哈希保存在评估记录中。 [配置初始化脚本](https://github.com/bytedance/deer-flow/blob/main/scripts/configure.py) 会根据示例创建 `config.yaml`、`.env` 和 `frontend/.env`。如果项目根目录已经存在配置，它会中止。这不意味着应该删除可用配置；应先备份，再检查仓库提供的升级路径。 ### 2. 配置真实可用的模型，并选择任务沙箱 启动前编辑生成的文件。至少配置一个受支持的模型，填入真实提供方凭据，并检查前端环境变量要求。不要将密钥提交到仓库或放入共享诊断输出。看起来完整的安装示例，只要还保留模型名称或密钥占位符，就不能当作可运行配置。 对于使用 AIO 容器的本地评估，将 `config.yaml` 中已有的 `sandbox:` 块替换为以下最小配置，不要追加第二个同名 YAML 键： ``` sandbox: use: deerflow.community.aio_sandbox:AioSandboxProvider ``` [沙箱配置指南](https://github.com/bytedance/deer-flow/blob/main/backend/docs/CONFIGURATION.md) 区分了本地提供方与 AIO 容器执行。DeerFlow 应用运行在 Docker 中，并不自动代表任务使用独立沙箱。这个示例面向本地 AIO 容器，不适用于已经配置远程供应服务的环境。修改之前应检查现有提供方设置。 ### 3. 初始化镜像并启动开发环境 ``` make docker-init make docker-start ``` 打开 `http://localhost:2026`。本次检查的 [Makefile](https://github.com/bytedance/deer-flow/blob/main/Makefile) 将 `make docker-start` 归类为 Docker 开发环境启动命令，对应停止命令是 `make docker-stop`。独立的生产路径为 `make up`，配套使用 `make prod-logs` 和 `make down`。名称中带有“生产”并不意味着通过了安全认证。 查看开发环境日志： ``` make docker-logs ``` 接入真实工作流前，先执行合成冒烟测试：上传一个只含数值 2 和 3 的小型 CSV，要求智能体通过代码工具计算总和，并生成内容包含 5 的结果文件。独立检查文件和工具调用记录。聊天回答“已完成”，既不能证明代码确实执行，也不能证明交付物真实存在且可访问。 ## 先排查启动问题，不要急着扩大权限 [上游安装指南](https://github.com/bytedance/deer-flow/blob/main/backend/docs/SETUP.md) 要求 `config.yaml` 位于仓库根目录，并将运行数据默认放在 `.deer-flow`，也可通过 `DEER_FLOW_HOME` 指定其他位置。不要把所有失败都归因于模型，先检查路径与实际挂载的配置。下表是建议的排查顺序，并不表示每个安装环境都会遇到这些问题。 | 症状 | 首先检查 | 不要采用的捷径 | | --- | --- | --- | | 配置缺失或被拒绝 | 根目录、实际挂载文件、YAML 语法，以及与当前 checkout 示例的兼容性。 | 删除有效配置，或重复粘贴顶层键。 | | 界面能打开，模型调用失败 | 模型标识、端点、凭据、提供方访问权限和网关日志。 | 将界面可用当成模型配置正确的证明。 | | Shell 执行失败 | 实际选择的沙箱提供方、镜像是否可用，以及提供方与容器的连接。 | 只为消除报错就启用不受限制的本地 shell。 | | 首次代码任务似乎卡住 | 镜像拉取进度、容器启动情况及工具超时证据。 | 不看日志就重复提交同一项高成本任务。 | | 重启后结果消失 | 状态后端、持久化挂载、身份信息和交付物路径。 | 假设所有内存中的运行组件都会持久保存。 | ## DeerFlow 子智能体之间真的相互隔离吗？ **对话上下文独立，不代表容器独立。**本次检查的 [子智能体执行器](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/subagents/executor.py) 可以将主智能体的沙箱传入委派执行。即使对话历史分开，只要多个智能体使用同一沙箱，就应按共享文件系统参与者来设计。新的模型上下文不是租户之间的安全边界。 当前 [AIO 提供方实现](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/community/aio_sandbox/aio_sandbox_provider.py) 通过用户与线程身份映射沙箱归属。配置 `provisioner_url` 时选择远程后端，否则使用本地容器后端。这两种机制都不保证每个专业子智能体拥有一个独立容器。 第一个工作流应给每个并行分支分配不同的输出文件名，在支持的情况下将输入文件设为只读，并让一个汇总步骤负责最终报告。测试一个分支能否覆盖另一个分支的文件。如果服务不同客户，应验证服务器推导的身份、授权与存储边界，而不是依赖提示词中的客户名称。 本地提供方是另一种选择：任务在应用自身的环境内执行，不会额外创建任务容器。如果本地 shell 已被禁用，不要轻易解除限制。 [OpenSandbox 评测](/zh/blog/opensandbox-ai-agent-sandbox-review/) 单独讨论沙箱基础设施；沙箱提供方和完整智能体执行框架解决的是不同层面的问题。 ## DeerFlow 的记忆如何工作，为什么仍然消耗 token？ 需要区分三个问题：当前对话、跨对话复用的记忆，以及恢复任务所需的运行状态。 [共享记忆配置](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/config/memory_config.py) 区分启用记忆、向提示词注入记忆和选择后端。因此，“已开启记忆”不能证明新事实正在被提取，也不能证明所有未完成任务都能在重启后恢复。 在本次检查的 [配置示例](https://github.com/bytedance/deer-flow/blob/main/config.example.yaml) 中，DeerMem 的 `max_injection_tokens` 位于 `memory.backend_config` 下，示例值为 2000。提取模型需要单独配置；省略这些模型设置时，自动提取不可用，但不依赖 LLM 的记忆操作仍可能正常工作。应核对当前代码版本实际加载的配置。 对话压缩是另一个机制。 [摘要中间件](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/agents/middlewares/summarization_middleware.py) 负责这一层，但它不等于持久的业务记忆。摘要可能丢失细节，加入模型上下文的内容仍会占用容量。不要把“限制注入量”解释为“无限记忆且没有 token 成本”。 我们建议将记忆测试拆为三步。先保存一个无敏感信息的偏好，在同一身份下新建对话并验证能否召回；然后更正偏好，确认旧值不再持续覆盖新值；最后使用另一个测试身份查询，确认无法获取前一个用户的偏好。除了最终回答，还应检查日志与存储。 记录实际提示词及提供方总用量。如果记忆增加了成本，却没有改善验收通过的结果，就减少注入内容或收窄工作流。如果现有智能体系统只是缺少记忆层，应先参考 [OpenViking 记忆评测](/zh/blog/openviking-agent-memory-review/) 评估这个更具体的需求，而不是默认替换整套系统。 ## 自定义 DeerFlow 技能：描述流程，不等于授予或限制权限 第一个有用的技能应该定义可重复的输出约定，而不是要求智能体无限自主。下面使用前文介绍的文件格式，给出一个带来源引用的供应商简报 `SKILL.md` 示例。请按照当前 checkout 的技能发现与审批规则接入并测试；它不是经过实际运行验证的插件包。 ``` --- name: vendor-evidence-brief description: Prepare a source-linked vendor brief for human review. --- Use only the approved input documents and permitted sources. Record a source URL or input filename for each factual claim. Mark missing evidence as unknown; never invent a reference. Write research branches to separate output files. Produce a draft, not an approval or a published report. Do not send messages, change accounts, or execute payments. ``` 这一区别很重要：“不要发送消息”是一条指令，不是技术层面的消息权限禁令。应通过本次运行实际可用的工具和凭据执行限制。第三方技能文件、附带脚本与依赖，应作为需要审核的代码或指令处理，而不是默认可信的扩展。 可复用流程放在技能中，具体任务事实放在任务输入中。这样更容易审阅、比较版本，并使用正常与恶意样例进行测试。不要把真实客户密钥或其他敏感信息写进可重复使用的指令。 ## 有边界的工作流：从供应商研究到可追溯草稿 **以下是建议的试点设计，不是已完成的 DeerFlow 客户项目。**从三份经过批准的供应商文档和一个固定问题开始：哪些方案满足指定技术要求？将交付范围限制为比较草稿和证据文件，不接入采购、付款或外发邮件动作。 | 阶段 | 预期交付物 | 验收检查 | | --- | --- | --- | | 准备输入 | 已批准的文件和明确的比较标准。 | 输入不含不必要的敏感信息，范围与允许来源已记录。 | | 并行研究 | 每家供应商一个独立证据文件。 | 每条事实引用输入文件或允许的来源 URL；未知内容保留为未知。 | | 汇总 | 带有限制说明的比较草稿。 | 陈述能够追溯到证据文件；缺乏证据不能被写成满足或不满足条件。 | | 独立验证 | 结构化验证结果。 | 必需文件存在，机器可读输出可解析，抽查陈述与来源一致。 | | 人工发布审批 | 获批或被拒绝的草稿。 | 由明确指定的审核人决定内容是否可以分享或用于行动。 | 验收样例中应加入刻意冲突的来源、缺失文档和执行中断。要求系统显露不确定性，而不是编造一个看起来完整的答案。如果简单的单智能体基线表现更好，就保留它。更多子智能体是一种实现选择，不是业务成果指标。 ## DeerFlow 生产检查清单：必须拿出哪些证据？ 不要将早期“没有身份认证”的描述当成当前事实。本次检查的 [身份认证设计](https://github.com/bytedance/deer-flow/blob/main/backend/docs/AUTH_DESIGN.md) 包含首次初始化和已认证用户处理。在其他人能访问服务前，通过本地 `/setup` 流程完成首个管理员设置，并使用不同账户测试授权边界。 本次检查的 [生产 Compose 文件](https://github.com/bytedance/deer-flow/blob/main/docker/docker-compose.yaml) 默认将公开入口绑定到 `127.0.0.1`，并要求设置 `BETTER_AUTH_SECRET`。评估期间应保持环回访问。公开暴露服务必须经过明确的部署审查，而不是随手修改 `BIND_HOST`。 以下是建议的上线门槛，并不表示 DeerFlow 已经提供或默认启用了每一项控制。 | 控制项 | 需要验证的证据 | | --- | --- | | 身份与权限 | 用户不能获取其他用户的线程、文件或记忆；特权操作必须由明确授权的身份执行。 | | 运行时隔离 | 审查挂载、外连网络、密钥和资源限制。如果 AIO 使用宿主机 Docker socket，应单独评估这条特权控制路径。 | | 持久化与恢复 | 执行期间重启，重新连接并检查状态。验证备份恢复，确认重试不会重复触发外部动作。 | | 成本与取消 | 通过代表性故障验证支出上限、任务截止时间、取消行为和并行工作限制。 | | 技能与工具信任 | 审查可执行扩展、MCP 启动器和技能变更。不可信内容不得取得管理工具的操作权。 | | 升级责任 | 固定应用与镜像版本，保留脱敏调用记录，重复执行验收测试，并由明确的运维责任人验证回滚。 | 最终发布评审可使用 [软件上线前 QA 检查清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 作为通用交付检查，再补充上述智能体专属案例。一次正常演示通过，不足以批准账户修改、付款或其他不可逆操作。 ## DeerFlow 值得采用吗？ 建议衡量**每项验收通过任务成本 =（模型总成本 + 工具总成本 + 运行时总成本 + 人工审核成本）/ 验收通过任务数**。统一成本核算单位，将失败尝试计入相应总成本，包含记忆提取和委派调用，并用相同任务与现有方案比较。同时记录完成时间、人工纠错次数、恢复成功率和被阻止的不安全动作。如果没有任何任务通过验收，应明确报告失败，而不是计算误导性的平均值。 当集成执行环境可能减少真实的编排工作时，适合开展 DeerFlow 试点。如果更小的框架或确定性工作流能以更低运维复杂度满足验收约定，就应保留更简单的方案。 [LangChain Deep Agents 评测](/zh/blog/langchain-deep-agents-review/) 有助于理解这种更聚焦的框架选择。 Wavect 的 [AI 开发服务](/zh/services/artificial-intelligence/) 可协助定义有边界的工作流、权限与验收测试。 [TwinSoft AI 案例](/zh/case-studies/twinsoft-ai/) 提供的是相关交付背景，不是 DeerFlow 已部署的证据。如需判断它是否适合现有系统，可 [与 Wavect 讨论工作流及其失败场景](/zh/contact/) 。 ## DeerFlow 2.0 常见问题 ### DeerFlow 2.0 是什么？ DeerFlow 2.0 是字节跳动基于 LangGraph 和 LangChain 构建的开源智能体执行框架，整合任务执行、子智能体、工具、沙箱接入、记忆和技能。它不是新的基础模型，也不保证工作流必然成功。 ### 只执行 git clone 和 make docker-start 就够了吗？ 这不是完整的首次安装流程。应先准备配置和环境文件，配置可用模型，选择沙箱提供方并初始化沙箱镜像，然后启动开发环境。 ### 每个 DeerFlow 子智能体都有独立的 Docker 容器吗？ 不能这样假设。对话隔离和沙箱隔离是不同概念。子智能体可能使用主智能体的沙箱并共享文件，必须验证实际提供方与部署方式的隔离边界。 ### 为什么 DeerFlow 的记忆没有学到新信息？ 同时检查共享记忆配置与所选后端。在本次检查的 DeerMem 示例中，自动提取需要单独配置提取模型。还应检查凭据、身份作用域、存储和日志。注入已有记忆与提取新事实是两个不同操作。 ### DeerFlow 记忆能消除 token 成本吗？ 不能。注入的记忆、检索内容、摘要和提取调用都可能消耗 token。应衡量包含失败尝试与人工审核的每项验收通过任务总成本，而不是仅看某个提示词的长度。 ### DeerFlow 可以用于生产环境吗？ 应先用固定代码版本验证实际工作负载。仓库提供单独的 Docker 生产启动命令和身份认证，但仍需验证权限、持久化、隔离、恢复、支出控制及运维责任。 模型与基础设施 ## 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 [从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [LiteAgents SDK：逐轮模型路由、安装与迁移指南](/zh/blog/liteagents-sdk-per-turn-model-routing/) - [mcp-memory-service：让 Claude Code 与 Cursor 共享持久记忆](/zh/blog/mcp-memory-service-claude-code-cursor/) - [Claude Opus 5.5 使用指南：适用场景、提示词与思考强度](/zh/blog/claude-opus-5-5-best-use-cases-workflows/) - [Laya 与 Jev 的企业应用：6 个实用工作流](/zh/blog/laya-jev-business-workflows-roi/) - [Laya vs Jev：基准结果与 AI 创业护城河](/zh/blog/laya-vs-jev-benchmark-ai-startup-moat/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年9月28日 最近审核 2026年9月28日 [**下一篇**](/zh/blog/agent-harness-engineering/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/deerflow-2-docker-setup-sandbox-memory/#webpage", "@type": "WebPage", "dateModified": "2026-09-28", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-28", "url": "https://wavect.io/zh/blog/deerflow-2-docker-setup-sandbox-memory/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "DeerFlow 2.0 是字节跳动开源的智能体执行框架，用于协调模型、工具、子智能体、技能与任务执行。进行本地 Docker 评估时，应先生成配置、选择沙箱提供方，再运行 make docker-init 和 make docker-start。对话上下文分离不一定意味着沙箱分离，持久记忆也不会消除 token 成本。成功启动只是验证的起点，并不能证明系统已经适合生产环境。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 DeerFlow 2.0：Docker 部署、沙箱与记忆机制 要点速览 DeerFlow 2.0 是字节跳动开源的智能体执行框架，用于协调模型、工具、子智能体、技能与任务执行。进行本地 Docker 评估时，应先生成配置、选择沙箱提供方，再运行 make docker-init 和 make docker-start。对话上下文分离不一定意味着沙箱分离，持久记忆也不会消除 token 成本。成功启动只是验证的起点，并不能证明系统已经适合生产环境。 DeerFlow 2.0 是智能体执行框架，而不是另一个模型。真正值得问的是：它能否减少自建集成代码，协调工具、文件和专业子智能体，同时保留可验证的运行边界？字节跳动官方仓库将版本 2 描述为一次从头重写，而非此前深度研究系统的小幅更新。 审阅范围：本文基于 2026 年 9 月 28 日公开的 2.x main 分支文档和实现编写。这不是发布当日新闻，也不是实际安装测试或独立复现的性能基准。后续修订与早期 2.0 代码可能不同，执行以下步骤前请记录所用 commit。 DeerFlow 实际负责哪些编排工作？ DeerFlow 基于 LangGraph 和 LangChain，将智能体运行时、工具执行、工作文件与可复用技能整合在一起。架构文档介绍了智能体中间件以及基于 SKILL.md 文件的扩展方式。它并不替代 LangGraph，而是在这些基础能力之上提供更完整的执行环境。 我们的判断是：当任务需要跨多个步骤研究资料、检查文件、执行代码并产出可验证交付物时，DeerFlow 值得评估。如果固定脚本或普通队列工作流已经能解决问题，增加这套系统的收益就未必明显。关于框架类别与选型，可参考智能体执行框架工程指南。本文则聚焦 DeerFlow 本身的配置与运行。 执行框架可以减少协调代码，但团队仍需定义成功标准、需要审批的动作、允许发送给模型的数据，以及故障处理责任人。合适的起点是一个有明确边界的工作流，而不是给通用助手接入公司的全部系统。 DeerFlow 2.0 Docker 部署：一行命令遗漏了什么？ 克隆仓库后直接启动，并不等于完成首次配置。以下命令需要 Git、Make、Python 3、合适的 shell、正在运行的 Docker 引擎及 Docker Compose。本次检查的上游说明要求 Compose v2.24 或更高版本。应使用当前 checkout 自带的配置示例，不要混用旧版本文章中的片段。 1. 克隆上游仓库并生成配置 set -eu git clone https://github.com/bytedance/deer-flow.git cd deer-flow git rev-parse HEAD docker compose version make config 将输出的 commit 哈希保存在评估记录中。配置初始化脚本会根据示例创建 config.yaml、.env 和 frontend/.env。如果项目根目录已经存在配置，它会中止。这不意味着应该删除可用配置；应先备份，再检查仓库提供的升级路径。 2. 配置真实可用的模型，并选择任务沙箱 启动前编辑生成的文件。至少配置一个受支持的模型，填入真实提供方凭据，并检查前端环境变量要求。不要将密钥提交到仓库或放入共享诊断输出。看起来完整的安装示例，只要还保留模型名称或密钥占位符，就不能当作可运行配置。 对于使用 AIO 容器的本地评估，将 config.yaml 中已有的 sandbox: 块替换为以下最小配置，不要追加第二个同名 YAML 键： sandbox: use: deerflow.community.aio_sandbox:AioSandboxProvider 沙箱配置指南区分了本地提供方与 AIO 容器执行。DeerFlow 应用运行在 Docker 中，并不自动代表任务使用独立沙箱。这个示例面向本地 AIO 容器，不适用于已经配置远程供应服务的环境。修改之前应检查现有提供方设置。 3. 初始化镜像并启动开发环境 make docker-init make docker-start 打开 http://localhost:2026。本次检查的 Makefile 将 make docker-start 归类为 Docker 开发环境启动命令，对应停止命令是 make docker-stop。独立的生产路径为 make up，配套使用 make prod-logs 和 make down。名称中带有“生产”并不意味着通过了安全认证。 查看开发环境日志： make docker-logs 接入真实工作流前，先执行合成冒烟测试：上传一个只含数值 2 和 3 的小型 CSV，要求智能体通过代码工具计算总和，并生成内容包含 5 的结果文件。独立检查文件和工具调用记录。聊天回答“已完成”，既不能证明代码确实执行，也不能证明交付物真实存在且可访问。 先排查启动问题，不要急着扩大权限 上游安装指南要求 config.yaml 位于仓库根目录，并将运行数据默认放在 .deer-flow，也可通过 DEER_FLOW_HOME 指定其他位置。不要把所有失败都归因于模型，先检查路径与实际挂载的配置。下表是建议的排查顺序，并不表示每个安装环境都会遇到这些问题。 DeerFlow Docker 评估：按症状进行首次检查 症状首先检查不要采用的捷径 配置缺失或被拒绝根目录、实际挂载文件、YAML 语法，以及与当前 checkout 示例的兼容性。删除有效配置，或重复粘贴顶层键。 界面能打开，模型调用失败模型标识、端点、凭据、提供方访问权限和网关日志。将界面可用当成模型配置正确的证明。 Shell 执行失败实际选择的沙箱提供方、镜像是否可用，以及提供方与容器的连接。只为消除报错就启用不受限制的本地 shell。 首次代码任务似乎卡住镜像拉取进度、容器启动情况及工具超时证据。不看日志就重复提交同一项高成本任务。 重启后结果消失状态后端、持久化挂载、身份信息和交付物路径。假设所有内存中的运行组件都会持久保存。 DeerFlow 子智能体之间真的相互隔离吗？ 对话上下文独立，不代表容器独立。本次检查的子智能体执行器可以将主智能体的沙箱传入委派执行。即使对话历史分开，只要多个智能体使用同一沙箱，就应按共享文件系统参与者来设计。新的模型上下文不是租户之间的安全边界。 当前 AIO 提供方实现通过用户与线程身份映射沙箱归属。配置 provisioner_url 时选择远程后端，否则使用本地容器后端。这两种机制都不保证每个专业子智能体拥有一个独立容器。 第一个工作流应给每个并行分支分配不同的输出文件名，在支持的情况下将输入文件设为只读，并让一个汇总步骤负责最终报告。测试一个分支能否覆盖另一个分支的文件。如果服务不同客户，应验证服务器推导的身份、授权与存储边界，而不是依赖提示词中的客户名称。 本地提供方是另一种选择：任务在应用自身的环境内执行，不会额外创建任务容器。如果本地 shell 已被禁用，不要轻易解除限制。OpenSandbox 评测单独讨论沙箱基础设施；沙箱提供方和完整智能体执行框架解决的是不同层面的问题。 DeerFlow 的记忆如何工作，为什么仍然消耗 token？ 需要区分三个问题：当前对话、跨对话复用的记忆，以及恢复任务所需的运行状态。共享记忆配置区分启用记忆、向提示词注入记忆和选择后端。因此，“已开启记忆”不能证明新事实正在被提取，也不能证明所有未完成任务都能在重启后恢复。 在本次检查的配置示例中，DeerMem 的 max_injection_tokens 位于 memory.backend_config 下，示例值为 2000。提取模型需要单独配置；省略这些模型设置时，自动提取不可用，但不依赖 LLM 的记忆操作仍可能正常工作。应核对当前代码版本实际加载的配置。 对话压缩是另一个机制。摘要中间件负责这一层，但它不等于持久的业务记忆。摘要可能丢失细节，加入模型上下文的内容仍会占用容量。不要把“限制注入量”解释为“无限记忆且没有 token 成本”。 我们建议将记忆测试拆为三步。先保存一个无敏感信息的偏好，在同一身份下新建对话并验证能否召回；然后更正偏好，确认旧值不再持续覆盖新值；最后使用另一个测试身份查询，确认无法获取前一个用户的偏好。除了最终回答，还应检查日志与存储。 记录实际提示词及提供方总用量。如果记忆增加了成本，却没有改善验收通过的结果，就减少注入内容或收窄工作流。如果现有智能体系统只是缺少记忆层，应先参考 OpenViking 记忆评测评估这个更具体的需求，而不是默认替换整套系统。 自定义 DeerFlow 技能：描述流程，不等于授予或限制权限 第一个有用的技能应该定义可重复的输出约定，而不是要求智能体无限自主。下面使用前文介绍的文件格式，给出一个带来源引用的供应商简报 SKILL.md 示例。请按照当前 checkout 的技能发现与审批规则接入并测试；它不是经过实际运行验证的插件包。 --- name: vendor-evidence-brief description: Prepare a source-linked vendor brief for human review. --- Use only the approved input documents and permitted sources. Record a source URL or input filename for each factual claim. Mark missing evidence as unknown; never invent a reference. Write research branches to separate output files. Produce a draft, not an approval or a published report. Do not send messages, change accounts, or execute payments. 这一区别很重要：“不要发送消息”是一条指令，不是技术层面的消息权限禁令。应通过本次运行实际可用的工具和凭据执行限制。第三方技能文件、附带脚本与依赖，应作为需要审核的代码或指令处理，而不是默认可信的扩展。 可复用流程放在技能中，具体任务事实放在任务输入中。这样更容易审阅、比较版本，并使用正常与恶意样例进行测试。不要把真实客户密钥或其他敏感信息写进可重复使用的指令。 有边界的工作流：从供应商研究到可追溯草稿 以下是建议的试点设计，不是已完成的 DeerFlow 客户项目。从三份经过批准的供应商文档和一个固定问题开始：哪些方案满足指定技术要求？将交付范围限制为比较草稿和证据文件，不接入采购、付款或外发邮件动作。 第一个 DeerFlow 工作流的建议验收约定 阶段预期交付物验收检查 准备输入已批准的文件和明确的比较标准。输入不含不必要的敏感信息，范围与允许来源已记录。 并行研究每家供应商一个独立证据文件。每条事实引用输入文件或允许的来源 URL；未知内容保留为未知。 汇总带有限制说明的比较草稿。陈述能够追溯到证据文件；缺乏证据不能被写成满足或不满足条件。 独立验证结构化验证结果。必需文件存在，机器可读输出可解析，抽查陈述与来源一致。 人工发布审批获批或被拒绝的草稿。由明确指定的审核人决定内容是否可以分享或用于行动。 验收样例中应加入刻意冲突的来源、缺失文档和执行中断。要求系统显露不确定性，而不是编造一个看起来完整的答案。如果简单的单智能体基线表现更好，就保留它。更多子智能体是一种实现选择，不是业务成果指标。 DeerFlow 生产检查清单：必须拿出哪些证据？ 不要将早期“没有身份认证”的描述当成当前事实。本次检查的身份认证设计包含首次初始化和已认证用户处理。在其他人能访问服务", "articleSection": "AI 工程", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "字节跳动官方仓库", "url": "https://github.com/bytedance/deer-flow" }, { "@type": "WebPage", "name": "架构文档", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/ARCHITECTURE.md" }, { "@type": "WebPage", "name": "配置初始化脚本", "url": "https://github.com/bytedance/deer-flow/blob/main/scripts/configure.py" }, { "@type": "WebPage", "name": "沙箱配置指南", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/CONFIGURATION.md" }, { "@type": "WebPage", "name": "Makefile", "url": "https://github.com/bytedance/deer-flow/blob/main/Makefile" }, { "@type": "WebPage", "name": "上游安装指南", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/SETUP.md" }, { "@type": "WebPage", "name": "子智能体执行器", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/subagents/executor.py" }, { "@type": "WebPage", "name": "AIO 提供方实现", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/community/aio_sandbox/aio_sandbox_provider.py" }, { "@type": "WebPage", "name": "共享记忆配置", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/config/memory_config.py" }, { "@type": "WebPage", "name": "配置示例", "url": "https://github.com/bytedance/deer-flow/blob/main/config.example.yaml" }, { "@type": "WebPage", "name": "摘要中间件", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/agents/middlewares/summarization_middleware.py" }, { "@type": "WebPage", "name": "身份认证设计", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/AUTH_DESIGN.md" }, { "@type": "WebPage", "name": "生产 Compose 文件", "url": "https://github.com/bytedance/deer-flow/blob/main/docker/docker-compose.yaml" } ], "dateModified": "2026-09-28", "datePublished": "2026-09-28", "description": "DeerFlow 2.0 是字节跳动开源的智能体执行框架，用于协调模型、工具、子智能体、技能与任务执行。进行本地 Docker 评估时，应先生成配置、选择沙箱提供方，再运行 make docker-init 和 make docker-start。对话上下文分离不一定意味着沙箱分离，持久记忆也不会消除 token 成本。成功启动只是验证的起点，并不能证明系统已经适合生产环境。", "headline": "DeerFlow 2.0：Docker 部署、沙箱与记忆机制", "image": "https://wavect.io/img/blog/headers/header_deerflow-2-docker-setup-sandbox-memory.svg", "inLanguage": "zh", "keywords": "DeerFlow 2.0, Docker 部署, 智能体执行框架", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/deerflow-2-docker-setup-sandbox-memory/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/deerflow-2-docker-setup-sandbox-memory/", "wordCount": 461 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/deerflow-2-docker-setup-sandbox-memory/", "name": "DeerFlow 2.0：Docker 部署、沙箱与记忆机制", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "DeerFlow 2.0 是字节跳动基于 LangGraph 和 LangChain 构建的开源智能体执行框架，整合任务执行、子智能体、工具、沙箱接入、记忆和技能。它不是新的基础模型，也不保证工作流必然成功。" }, "name": "DeerFlow 2.0 是什么？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "这不是完整的首次安装流程。应先准备配置和环境文件，配置可用模型，选择沙箱提供方并初始化沙箱镜像，然后启动开发环境。" }, "name": "只执行 git clone 和 make docker-start 就够了吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不能这样假设。对话隔离和沙箱隔离是不同概念。子智能体可能使用主智能体的沙箱并共享文件，必须验证实际提供方与部署方式的隔离边界。" }, "name": "每个 DeerFlow 子智能体都有独立的 Docker 容器吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "同时检查共享记忆配置与所选后端。在本次检查的 DeerMem 示例中，自动提取需要单独配置提取模型。还应检查凭据、身份作用域、存储和日志。注入已有记忆与提取新事实是两个不同操作。" }, "name": "为什么 DeerFlow 的记忆没有学到新信息？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不能。注入的记忆、检索内容、摘要和提取调用都可能消耗 token。应衡量包含失败尝试与人工审核的每项验收通过任务总成本，而不是仅看某个提示词的长度。" }, "name": "DeerFlow 记忆能消除 token 成本吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "应先用固定代码版本验证实际工作负载。仓库提供单独的 Docker 生产启动命令和身份认证，但仍需验证权限、持久化、隔离、恢复、支出控制及运维责任。" }, "name": "DeerFlow 可以用于生产环境吗？" } ] } ```