DeerFlow 如何配置 E2B 云沙箱并为多 Gateway 部署启用 Redis ownership【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow如果你的 DeerFlow 部署需要把 Agent 的命令执行放到云上隔离环境并且会以多 Gateway 实例多 worker 或负载均衡方式对外提供服务你需要完成两件事在config.yaml里把沙箱 provider 切换为E2BSandboxProvider并为sandbox.ownership启用 Redis 后端。只做第一步的话多个 Gateway 进程会在启动和周期性对账时互相接管、销毁对方的 E2B 沙箱启用 Redis ownership 后所有权租约保证一个 Gateway 不会收养或销毁另一个存活 Gateway 正在使用的沙箱。以下内容依据 配置指南 的 Sandbox 章节和 config.example.yaml 编写。准备工作按文档说明切换到 E2B 前只需要确认三件事E2B API key。sandbox.api_key是必填项也可以改用E2B_API_KEY环境变量。不需要额外安装 SDK。e2b-code-interpreter已经作为deerflow-harness的核心依赖内置直接提供 API key 并在config.yaml里切换 provider 即可。多 Gateway 场景需要一个可达的 Redis。e2b-code-interpreter与 Redis 都是 DeerFlow 依赖链的一部分但 Redis 实例本身需要部署方提供config.example.yaml中给出的示例地址是redis://redis:6379/0即 Docker Compose 网络内的服务名形式单机部署请替换为你自己的连接串。配置文件位置遵循常规规则config.yaml放在项目根目录deer-flow/config.yaml如果进程可能从其他工作目录启动设置DEER_FLOW_PROJECT_ROOT或用DEER_FLOW_CONFIG_PATH指向具体文件。单 Gateway配置 E2B provider把config.yaml的sandbox:段替换为示例值来自 配置指南/path/on/host是文档示例占位符替换为你要一次性上传的宿主机目录不需要可整段删除mountssandbox: use: deerflow.community.e2b_sandbox:E2BSandboxProvider api_key: $E2B_API_KEY # required; or set the E2B_API_KEY env var template: code-interpreter-v1 # e2b sandbox template id # domain: e2b.dev # optional; for self-hosted e2b deployments home_dir: /home/user # /mnt/user-data is remapped under this directory idle_timeout: 600 # forwarded to e2bs server-side set_timeout() replicas: 3 # max concurrent sandboxes per gateway process mount_upload_deadline_seconds: 120 # per-sandbox time budget for mount uploads (seconds) ownership: # 单 Gateway 可以省略默认 memory 后端 type: redis redis_url: $REDIS_URL reconciliation_interval_seconds: 60 reconciliation_grace_seconds: 120 reconciliation_orphan_ttl_seconds: 3600 reconciliation_max_pages: 10 reconciliation_max_items: 200 reconciliation_max_seconds: 15 mounts: # one-shot upload of host files at sandbox start - host_path: /path/on/host container_path: /home/user/shared read_only: false environment: # forwarded to the sandbox at create time OPENAI_API_KEY: $OPENAI_API_KEY各字段在文档中的用途replicas每个 gateway 进程内活跃加保活沙箱的最大数量。idle_timeout转发给 e2b 服务端set_timeout()provider 在每次 release 时刷新该超时让保活沙箱撑到下一次 acquire。reconciliation_*对账reconciliation的周期与上限。对账受分页、条数和时间三重预算限制摘要日志会暴露 discovered、adopted、duplicate、deferred、killed、dead 和 budget-exhausted 计数供运维监控。mount_upload_deadline_seconds单个沙箱 mount 上传的时间预算provider 在每次 mount 前、目录预检和每次 SDK 写入前都会检查省略时保持 120 秒默认值。如果部署了多 Gatewayskills.container_path还有一条硬性约束它必须是规范化的绝对非根 POSIX 路径不能包含./..也不能落在或包含 DeerFlow 保留挂载/mnt/user-data、/mnt/acp-workspace、/mnt/integrations/lark-cli之内。E2B 会把该 root 记录进远端 metadatarefuse 收养为其他 root 创建的 VM所以修改后必须重启 Gateway。多 Gateway启用 Redis ownership单 Gateway 部署可以完全省略ownership:段——文档明确说明默认的内存存储只对单 gateway 进程安全。多 worker / 负载均衡部署则必须设置sandbox: ownership: type: redis redis_url: $REDIS_URL关于 Redis 后端config.example.yaml的 ownership 注释给出了与内存后端相同的租约语义renewal_interval_seconds: 30、ttl_multiplier: 4、key_prefix: deerflow:sandbox:owner为可选配置项并强调两点运维边界fail-closed与 stream bridge 的 fail-hard 策略一致。Redis.from_url是懒连接Redis 宕机不会阻塞 Gateway 启动但一个无法发布 ownership 的沙箱不会被交付——acquire直接抛错而不是无主放行。文档建议 Redis 本身跑 HA 或配置重启策略。租约 TTL 是安全边界lease TTL renewal_interval_seconds x ttl_multiplier。一次 Redis 中断时长超过 TTL 时正在对账的实例可能收养存活 owner 的沙箱因为过期租约与死亡 owner 无法区分——一整个 TTL 就是收养前的全部安全余量。文档建议按你的 Redis 可用性目标来设定这个值。另外有一条自动推断路径如果你的部署已经配置了 Redis stream bridgesandbox.ownership.type: redis会被自动推断出来即使ownership段被省略——这也是文档把多 Gateway 必须用 redis ownership写成硬性要求的原因。修改config.yaml后重启 Gateway 使 provider 与 ownership 生效如果此前跑的是本地或 Docker 沙箱旧沙箱实例由各自的对账流程清理与 E2B 对账互不干扰。验证配置是否生效文档给出的可观察判据有三个按顺序核对启动/对账摘要日志。E2B 的每个 DeerFlow thread 通过 metadatadeer_flow_user、deer_flow_thread、deer_flow_skills_root绑定沙箱启动和周期性对账会探测所有有界的候选沙箱采纳一个健康的规范沙箱并在宽限期后清掉重复项。摘要日志中的 adopted/duplicate/killed 等计数就是你确认每个 Gateway 只接管自己的沙箱的直接证据。实际跑一条命令。在 Web UI 发起一个需要执行代码的会话确认工具调用在 E2B 沙箱内完成。注意文件回传路径E2B 不能反向 bind-mount gateway 文件系统沙箱内的改动不会自动落回磁盘用download_file工具或把产物写到/mnt/user-data/outputs/对应沙箱内home_dir/outputs/经标准 artifact 管道回到 gateway。多 Gateway 场景下观察 Redis 中断行为。按 fail-closed 语义Redis 不可用期间新沙箱获取应直接报错而非静默继续——如果看到无主沙箱被交付说明 ownership 没有真正走 Redis 后端回到第一步检查ownership.type与redis_url。限制与边界单 Gateway 不要误开多实例语义ownership默认memory对单 gateway 进程是安全的此时不必引入 Redis。mount 是一次性的mounts只在沙箱启动时上传一次沙箱内的后续修改不会自动同步回宿主机这是 E2B 与本地 Docker 沙箱在文件回传上的本质差异。skills root 变更要求重启E2B 会拒绝收养 skills root 与 provider 启动快照不一致的 VM并在宽限期后清掉它们改skills.container_path后必须重启 Gateway。mount_upload_deadline_seconds不会中断进行中的写入它只是预算检查点活跃的 filesystem / E2B SDK 调用不会被该 deadline 打断。完成以上配置并看到对账摘要里 adopted 计数稳定、无重复收养后多 Gateway E2B 的部署即达到文档描述的目标状态后续调整replicas、idle_timeout或对账参数时改完config.yaml重启 Gateway 即可生效。【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
