如果你还把 DeerFlow 记成 planner、researcher、reporter 三个 agent 接力的深度研究框架，那已经是上一版故事了。当前 DeerFlow 2.0 更像一个长任务的 SuperAgent harness。它最有意思的地方也不再是“有多少 agent”，而是一串看起来很不浪漫的 middleware。
模型前后，站着一整排工程设施
lead agent 最终仍由 LangChain 的 create_agent 创建，但进入模型之前，状态要依次经过动态上下文、skill 激活、延迟工具发现、sandbox、todo、memory 等处理；模型输出之后，又有 summarization、loop detection、安全检查、subagent 数量限制和澄清机制收尾。
这不是装饰器随便叠一叠。顺序会改变行为：
- skill 先决定任务需要什么知识，tool search 才能只暴露相关工具，避免 MCP schema 把上下文塞满；
- sandbox 先确定执行边界，后面的 todo 和 subagent 才不会把计划建立在不存在的权限上；
- memory 写入要看到完整 turn，但 summarization 又必须在上下文溢出前发生；
- loop detection 必须观察历史动作，safety 则要在危险动作真正执行前拦下。
我读这段代码的感觉像看机场塔台：飞机当然重要，可真正让长航程不出事的是航线、间隔、备降和交接。
多 agent 只是其中一种工具
DeerFlow 仍支持 subagent，但 delegation 被放进显式预算里。lead agent 决定何时拆任务，subagent 在独立上下文中工作，结果再回到主流程；限制器防止模型把“再叫一个人”当成逃避困难的默认动作。
长任务还需要 compaction。DeerFlow 会在检查点把早期上下文压缩成可继续工作的状态，而不是无限追加 transcript。这里最重要的不是摘要写得漂亮，而是摘要之后，todo、文件、sandbox 产物和关键决策还能对齐。语言模型负责压缩语义，harness 负责保住可验证状态。
为什么从固定流水线转向 middleware
固定的 planner / researcher / reporter 很容易演示，也很容易被任务类型绑死。middleware 把稳定的横切需求抽出来：任何 agent 都需要限环、记忆、压缩、工具发现和安全边界。任务结构可以变，控制设施不用重写。
代价也真实存在。middleware 越多，隐式耦合越容易出现；一次异常可能不是模型错了，而是某层读到了上一层尚未准备好的状态。因此这类框架的护城河不会只是组件数量，而是顺序不变量、事件追踪和失败复现。
我的思考
DeerFlow 会特别打动自动化工程师、研究运营团队和需要跑数十分钟任务的产品开发者。他们早已知道 demo 能跑不等于系统可靠，更愿意为 checkpoint、sandbox、预算和可恢复性买单。
市场会因此分成两层：基础 agent loop 越来越像公共零件，真正有价值的是能把模型带过长任务泥潭的 harness。与此同时，“多 agent”这个营销标签会退潮，因为用户最终只关心任务是否按时、按预算、可追责地完成。
我还看到一个更大的变化：middleware 生态会把 agent 工程从 prompt 手艺推向运行时工程。未来团队争论的可能不再是“提示词怎么写”，而是“哪一层拥有状态、哪一层可以中止、哪一个 save point 能恢复”。这听起来不性感，却正是技术开始成为基础设施的声音。