写作现场：2026 年 2 月 28 日。 DeerFlow 2.0 是一次不兼容 1.x 的重写。旧版围绕 deep research 的固定流程组织，新版改成通用 Agent loop，并将文件系统、Skills、上下文压缩、子任务和记忆放入同一运行时。本文关注的不是“多 Agent 是否更聪明”，而是长任务如何获得隔离、预算和可交付状态。

运行时构成：Middleware 顺序与渐进式能力

2.0 的核心组装大致如下：

create_agent(
    model=model,
    tools=tools,
    middleware=[
        ThreadDataMiddleware(),
        UploadsMiddleware(),
        SandboxMiddleware(),
        DanglingToolCallMiddleware(),
        SummarizationMiddleware(...),
        TodoListMiddleware(...),
        SubagentLimitMiddleware(...),
        MemoryMiddleware(),
    ],
)

middleware 顺序构成运行协议，而非装饰性扩展。thread 数据必须先进入 runtime，上传文件与 sandbox 才能绑定正确工作区；dangling tool call 要在历史进入下一轮前修复；summarization 必须在上下文溢出前执行；memory 写回放在结果生成之后，避免记忆后端阻塞主任务。

Skills 采用渐进披露。system prompt 只提供能力目录，Agent 在需要时读取对应 SKILL.md 与参考文件。这样做的收益不是单纯节省 token，而是缩小每轮有效指令集，避免无关规则和示例干扰当前决策。能力层可以持续增加，主循环不必同步膨胀。

文件工作区承担大对象和可交付成果。网页、脚本、数据与中间报告不必反复进入 transcript，主 Agent 与 subagent 也可通过约定路径交换结果。这使上下文窗口退回控制信息，而不是充当临时文件系统。

有界并行、隔离与失败语义

subagent 拥有独立上下文和工具，可并行处理互相独立的检索或生成任务。SubagentLimitMiddleware 会在模型输出后截断超额 task 调用，将单次回复中的并发限制在 2–4 个。相比 prompt 中的“不要创建太多任务”，这是可执行约束。

该限制仍不等于总预算。主 Agent 可以在多轮中继续派工，每个 subagent 也可能消耗大量 token 或长时间无进展。完整的长任务控制面还需要累计调用数、wall-clock timeout、总成本、无进展检测、取消传播和明确的停止原因。

DeerFlow 提供本地、Docker 与 Kubernetes provisioner。sandbox 只描述执行承载方式：local 仍继承宿主机环境；容器与集群模式还取决于网络策略、凭据挂载、资源上限和镜像来源。隔离环境也不会撤销已经提交到外部系统的副作用。

MemoryMiddleware 在任务完成后过滤消息并异步写回，使成果交付不受记忆服务延迟影响；代价是进程退出时可能丢失尚未持久化的记忆。类似地，文件已经生成不代表任务可恢复，subagent 已返回也不代表结果经过验收。

DeerFlow 适合研究、内容生产和工程原型等会产生多份中间文件的任务。它把长任务所需的主要构件放在同一 runtime 中，但可靠性的最终指标应是单位可验收成果的成本、失败后的恢复位置和副作用可追踪性，而不是 subagent 数量。

版本与源码

信息边界：本文只采用 2026-02-28 及此前已经公开的事实和当日 f2123ef 源码，不把后续正式版机制写回 2.0 发布现场。