当大语言模型从对话界面走向真实任务执行，如何安全地让智能体操作文件系统、执行代码、调用外部工具，成为工程化落地的关键挑战。字节跳动于 2026 年 2 月发布的 DeerFlow 2.0 给出了自己的答案 —— 一个基于 LangGraph 构建的 SuperAgent 框架，其核心设计理念是为每个任务提供独立的沙盒执行环境。从研究框架演进为 SuperAgent harness，DeerFlow 通过沙盒化架构实现了智能体与宿主系统的彻底解耦，为复杂多步骤任务的可靠执行提供了基础设施支撑。

从 Deep Research 到 Super Agent Harness

DeerFlow 的故事始于一个 Deep Research 框架。社区开发者将其用于数据管道构建、幻灯片生成、仪表盘搭建、内容工作流自动化等远超预期场景。这促使团队重新思考 DeerFlow 的定位 —— 它不应该只是一个研究工具，而应该成为一个通用的智能体运行基础设施。2.0 版本因此从底层完全重写，基于 LangGraph 和 LangChain 构建，提供了开箱即用的完整能力：文件系统访问、长期记忆、可扩展技能系统、沙盒化执行环境，以及子智能体规划和 spawn 能力。

这种定位转变背后有一个核心工程哲学：智能体需要的不仅是对话接口和工具列表，而是一个能够实际执行任务的计算机。DeerFlow 将这个理念体现为「每个任务运行在独立隔离环境中」的设计原则，这使其与传统的 ChatGPT 式对话 Agent 形成了本质区别。当 Agent 能够执行代码、操作文件、运行 bash 命令时，隔离就变成了安全与可靠性的必修课。

三层沙盒化执行模式

DeerFlow 的沙盒架构支持三种执行模式，分别对应不同的隔离强度与部署场景。理解这三种模式的差异，是正确选型的前提。

本地执行模式是最轻量的选项，智能体代码直接运行在宿主机上，不经过容器化封装。这种模式适用于开发调试阶段或信任度极高的内部场景。其优势在于零容器开销，启动速度快，调试方便；代价是完全没有进程级隔离，智能体的文件系统操作直接作用于主机，存在意外删除或修改关键文件的理论风险。DeerFlow 在配置文件中通过sandbox.use参数控制模式切换，本地模式配置为deerflow.community.aio_sandbox:AioSandboxProvider即可启用。

Docker 执行模式是生产环境的默认选择。每个智能体任务在独立的 Docker 容器中运行，拥有完整的文件系统视图。容器内的路径结构遵循 DeerFlow 的约定：/mnt/user-data/下划分uploads/、workspace/和outputs/三个子目录，分别用于用户上传文件、智能体工作区、最终交付物。这种设计确保了任务之间的完全隔离 —— 一个任务的崩溃或异常不会影响其他任务，更不会污染主机文件系统。容器退出后，所有运行时数据随之销毁，实现了天然的会话隔离。

Kubernetes 执行模式面向大规模生产部署。当任务量达到一定规模后，单纯依赖单机的 Docker daemon 已经无法满足资源调度和弹性伸缩的需求。DeerFlow 通过 provisioner 服务将沙盒工作负载调度到 Kubernetes 集群中的 pod 内执行。这种模式下，每个 pod 拥有独立的 Linux 命名空间和网络策略，实现了多租户级别的隔离。集群管理员可以通过 Kubernetes 的网络策略精细控制每个 pod 的出站入站流量，限制敏感数据的流转路径。

值得注意的是，DeerFlow 的 Docker 执行采用了私有 Docker 守护进程设计。在每个沙盒 VM 内部运行一个 private Docker daemon，智能体执行的docker build或docker run操作都发生在沙盒自身的 daemon 上下文中，而非主机全局的 Docker 环境。这避免了传统容器逃逸攻击中常见的影响范围扩大问题 —— 即使沙盒内的容器被攻破，攻击者也无法访问主机上的其他容器、镜像或数据卷。

隔离机制的技术细节

从技术实现角度，DeerFlow 的沙盒隔离覆盖了三个核心维度：进程隔离、文件系统隔离和网络隔离。

进程隔离依赖于 Linux 命名空间和 cgroups 的组合。容器内的进程运行在独立的 PID 命名空间中，无法看到或 kill 主机或其他容器的进程。cgroups 则限制了每个容器的 CPU、内存和 IO 配额，防止恶意或失控的智能体任务耗尽宿主机资源。DeerFlow 还通过 seccomp 过滤了部分危险系统调用，缩小了内核攻击面。

文件系统隔离是智能体安全的另一关键层面。沙盒容器看到的根文件系统是精心裁剪过的，只包含必要的运行时依赖和 DeerFlow 预置的工具链。智能体的所有写入操作被限制在/mnt/user-data/范围内，尝试访问容器外路径会触发权限错误。这种白名单式的路径管控从架构层面杜绝了越权文件访问的可能性。

网络隔离通过 iptables 规则或 Kubernetes 网络策略实现。默认情况下，沙盒容器无法直接访问宿主机网络，只能通过 DeerFlow 的 Gateway 代理进行受控的 HTTP 请求。这意味着一旦智能体被恶意输入诱导发起网络扫描或攻击，攻击者的活动范围也被限制在沙盒内部，难以横向移动到其他服务。

这种多层隔离设计让 DeerFlow 能够在「给予智能体充分执行能力」与「保护系统安全」之间取得平衡。智能体可以读取文件、运行代码、调用外部 API—— 这些是完成任务所必需的能力；同时，这些操作都被约束在隔离边界内，异常行为不会造成系统级灾难。

工具链与工作流设计

沙盒化执行不仅是安全隔离，还需要为智能体提供完整的工作能力。DeerFlow 通过 Skills 系统和工具集成的设计，让隔离环境内的智能体能够执行复杂的多步骤任务。

Skills 系统是 DeerFlow 的能力扩展单元。每个 Skill 是一个结构化的 Markdown 文件，定义了工作流、最佳实践和参考资源。框架默认内置了 research、report-generation、slide-creation、web-page、image-generation 等技能，覆盖了从信息收集到内容生成的典型场景。更重要的是，Skills 支持按需加载 —— 只有当任务确实需要某项技能时，对应的 Skill 才会被加载到上下文中。这种惰性加载机制避免了将所有能力一股脑塞入上下文窗口，保持了 token 消耗的合理性。

Skills 的安装通过 Gateway 完成。开发者可以将自定义 Skill 打包成.skill归档文件，通过 API 部署到 DeerFlow 实例。框架接受带有可选 frontmatter 元数据的外部 Skill 定义，包括version、author、compatibility等字段，便于版本管理和依赖校验。部署后的 Skill 在沙盒内的路径为/mnt/skills/public/或/mnt/skills/custom/，智能体可以根据任务需求动态引用。

工具集成遵循同样的扩展哲学。DeerFlow 提供了核心工具集 ——web search、web fetch、file operations、bash execution—— 并支持通过 MCP 服务器和 Python 函数添加自定义工具。MCP 服务器的配置支持 OAuth token 流程，包括client_credentials和refresh_token模式，便于与企业身份认证系统集成。对于需要编写自定义工具的场景，开发者只需实现标准的函数签名，即可被 DeerFlow 的编排层自动发现和调用。

子智能体架构是处理复杂任务的核心机制。Lead Agent 可以将任务分解为多个子任务，分别 spawn 子智能体并行执行。每个子智能体运行在独立的隔离上下文中，拥有自己的 scoped context、工具集和终止条件。子智能体完成工作后返回结构化结果，Lead Agent 负责将多个结果综合为最终交付物。例如，一个研究任务可能 fans out 到十几个子智能体，每个负责一个细分方向的信息收集，最终汇总成一份完整的报告或演示文稿。

生产环境部署的关键考量

将 DeerFlow 投入生产环境使用时，沙盒模式的选择直接影响系统的安全边界、运维成本和弹性能力。以下是几个关键的决策点。

资源配额是第一优先级。Kubernetes 模式下，每个 pod 的 CPU 和内存请求需要根据任务复杂度设定上限。对于执行代码生成、数据分析等重计算任务的场景，建议分配至少 2 核 CPU 和 4GB 内存；同时设置 Limits 防止个别任务抢占整集群资源。Docker 单节点部署时，可以通过--memory和--cpus参数对容器进行资源约束。

网络策略的精细程度决定了被攻破后的影响半径。在 Kubernetes 环境中，建议为每个任务 pod 配置独立的 NetworkPolicy，限制其只能访问必要的外部服务端点。对于需要调用大模型 API 的场景，API 密钥应该通过 Secret 管理，避免明文写入配置文件或代码仓库。DeerFlow 支持从环境变量读取敏感配置，这是生产环境推荐的做法。

日志和审计是事后追踪的基础。沙盒内智能体的所有文件操作和命令执行都应该记录到集中式日志系统。DeerFlow 的 Gateway 层提供了任务状态追踪能力，但更细粒度的系统调用审计需要依赖容器内的日志收集 agent。建议将容器 stdout/stderr 接入 Elasticsearch 或类似的日志聚合平台，便于问题排查和安全审计。

密钥轮换和容器镜像更新频率也需要纳入运维流程。DeerFlow 的基础镜像应该定期重建以获取安全补丁；模型 API 密钥应设置过期时间并通过密钥管理服务轮换。对于运行在 Kubernetes 上的大规模部署，可以考虑使用 ImagePullPolicy 设为 Always 确保始终使用最新镜像。

与传统 Agent 框架的本质区别

对比市场上其他的 Agent 框架，DeerFlow 的沙盒化设计代表了 一种不同的工程取舍。传统 Agent 框架如 AutoGPT、LangChain Agent 通常以「工具调用」为核心 —— 模型生成函数调用请求，框架执行后返回结果。这种模式下，Agent 的操作本质上是对宿主进程的函数调用，存在被恶意输入诱导执行危险操作的风险。

DeerFlow 则将执行环境从宿主进程彻底剥离。模型生成的「操作意图」不再直接作用于主机，而是被翻译为沙盒内的动作。这种设计牺牲了一定的交互延迟（每次操作都涉及容器通信），换取了架构层面的安全性。对于需要处理不受信任输入或执行敏感操作的场景，这种取舍是值得的。

另一个显著差异在于执行模型的持久性。许多框架将 Agent 视为短生命周期会话 —— 调用即执行，执行完即释放。DeerFlow 通过沙盒的会话保持能力，允许智能体在较长时间跨度内维护工作状态，跨步骤累积上下文。这对于报告生成、代码项目开发等需要多轮迭代的任务尤为重要。

结语

DeerFlow 2.0 的沙盒化架构展示了智能体工程化的一个重要方向：将「执行能力」与「隔离边界」作为框架的核心抽象而非事后补救。从三种执行模式的灵活切换，到私有 Docker 守护进程的细节设计，再到 Skills 和工具的扩展性支持，每个工程决策都指向同一个目标 —— 让智能体能够可靠地完成真实世界的多步骤任务，同时将失控风险控制在可接受范围内。

对于需要在生产环境中部署 AI Agent 的团队，沙盒化不是可选项而是必选项。DeerFlow 的价值在于它已经将这套复杂的基础设施封装为开箱即用的框架，开发者可以专注于任务逻辑和技能构建，而不必从零实现隔离、执行和资源调度机制。随着大模型能力的持续提升，这种「安全执行底座」的价值只会越来越凸显。

资料来源：