本文内容
DeerFlow 2.0：Docker 部署、沙箱与记忆机制
DeerFlow 2.0 是智能体执行框架，而不是另一个模型。真正值得问的是：它能否减少自建集成代码，协调工具、文件和专业子智能体，同时保留可验证的运行边界？字节跳动官方仓库将版本 2 描述为一次从头重写，而非此前深度研究系统的小幅更新。
审阅范围：本文基于 公开的 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 指定其他位置。不要把所有失败都归因于模型，先检查路径与实际挂载的配置。下表是建议的排查顺序，并不表示每个安装环境都会遇到这些问题。
| 症状 | 首先检查 | 不要采用的捷径 |
|---|---|---|
| 配置缺失或被拒绝 | 根目录、实际挂载文件、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 客户项目。从三份经过批准的供应商文档和一个固定问题开始：哪些方案满足指定技术要求？将交付范围限制为比较草稿和证据文件，不接入采购、付款或外发邮件动作。
| 阶段 | 预期交付物 | 验收检查 |
|---|---|---|
| 准备输入 | 已批准的文件和明确的比较标准。 | 输入不含不必要的敏感信息，范围与允许来源已记录。 |
| 并行研究 | 每家供应商一个独立证据文件。 | 每条事实引用输入文件或允许的来源 URL；未知内容保留为未知。 |
| 汇总 | 带有限制说明的比较草稿。 | 陈述能够追溯到证据文件；缺乏证据不能被写成满足或不满足条件。 |
| 独立验证 | 结构化验证结果。 | 必需文件存在，机器可读输出可解析，抽查陈述与来源一致。 |
| 人工发布审批 | 获批或被拒绝的草稿。 | 由明确指定的审核人决定内容是否可以分享或用于行动。 |
验收样例中应加入刻意冲突的来源、缺失文档和执行中断。要求系统显露不确定性，而不是编造一个看起来完整的答案。如果简单的单智能体基线表现更好，就保留它。更多子智能体是一种实现选择，不是业务成果指标。
DeerFlow 生产检查清单：必须拿出哪些证据？
不要将早期“没有身份认证”的描述当成当前事实。本次检查的身份认证设计包含首次初始化和已认证用户处理。在其他人能访问服务前，通过本地 /setup 流程完成首个管理员设置，并使用不同账户测试授权边界。
本次检查的生产 Compose 文件默认将公开入口绑定到 127.0.0.1，并要求设置 BETTER_AUTH_SECRET。评估期间应保持环回访问。公开暴露服务必须经过明确的部署审查，而不是随手修改 BIND_HOST。
以下是建议的上线门槛，并不表示 DeerFlow 已经提供或默认启用了每一项控制。
| 控制项 | 需要验证的证据 |
|---|---|
| 身份与权限 | 用户不能获取其他用户的线程、文件或记忆；特权操作必须由明确授权的身份执行。 |
| 运行时隔离 | 审查挂载、外连网络、密钥和资源限制。如果 AIO 使用宿主机 Docker socket，应单独评估这条特权控制路径。 |
| 持久化与恢复 | 执行期间重启，重新连接并检查状态。验证备份恢复，确认重试不会重复触发外部动作。 |
| 成本与取消 | 通过代表性故障验证支出上限、任务截止时间、取消行为和并行工作限制。 |
| 技能与工具信任 | 审查可执行扩展、MCP 启动器和技能变更。不可信内容不得取得管理工具的操作权。 |
| 升级责任 | 固定应用与镜像版本，保留脱敏调用记录，重复执行验收测试，并由明确的运维责任人验证回滚。 |
最终发布评审可使用软件上线前 QA 检查清单作为通用交付检查，再补充上述智能体专属案例。一次正常演示通过，不足以批准账户修改、付款或其他不可逆操作。
DeerFlow 值得采用吗？
建议衡量每项验收通过任务成本 =（模型总成本 + 工具总成本 + 运行时总成本 + 人工审核成本）/ 验收通过任务数。统一成本核算单位，将失败尝试计入相应总成本，包含记忆提取和委派调用，并用相同任务与现有方案比较。同时记录完成时间、人工纠错次数、恢复成功率和被阻止的不安全动作。如果没有任何任务通过验收，应明确报告失败，而不是计算误导性的平均值。
当集成执行环境可能减少真实的编排工作时，适合开展 DeerFlow 试点。如果更小的框架或确定性工作流能以更低运维复杂度满足验收约定，就应保留更简单的方案。LangChain Deep Agents 评测有助于理解这种更聚焦的框架选择。
Wavect 的 AI 开发服务可协助定义有边界的工作流、权限与验收测试。TwinSoft AI 案例提供的是相关交付背景，不是 DeerFlow 已部署的证据。如需判断它是否适合现有系统，可与 Wavect 讨论工作流及其失败场景。