ai-chatbot/docs/DeerFlow调研与Agent升级建议-2026-03-12.md

DeerFlow 调研与 Agent 升级建议（2026-03-12）

目标：在不推翻现有架构的前提下，吸收开源 DeerFlow 在对话理解、技能调用、上下文工程、子代理协作上的强项，提升本项目 Agent 能力。
适用范围：ai-chatbot-main 当前聊天 Agent、视频分镜 Agent、无限画布 Agent。

---

1. 先说结论

建议学习 DeerFlow，但不建议直接整套迁移。

原因：

1. DeerFlow 强项在于：
   • 复杂任务拆解
   • 子代理协作
   • 工具/技能编排
   • 人类确认与工作流状态管理
   • 长期记忆与上下文工程
2. 我们当前项目已经有：
   • LangGraph
   • 工具注册表
   • specialist/skill route
   • context memory
   • 画布上下文
   • 视频 storyboard pipeline 骨架
3. 真正缺的不是“换框架”，而是把这些能力从“分散模块”升级成更稳定的 统一 Agent Runtime。

所以最合理的路线是：

• 不替换现有 Agent
• 吸收 DeerFlow 的 runtime 设计思想
• 补齐我们自己的 workflow state / middleware / subagent / human-in-the-loop

---

2. DeerFlow 值得学习的核心能力

根据 DeerFlow 官方仓库与文档，它不是一个简单的聊天机器人，而是一个偏“super agent runtime”的框架。对我们最有价值的点主要有 6 个。

2.1 技能系统（Skills）

DeerFlow 把技能视为可复用的高阶能力，不只是单个 tool call。

对我们有启发的是：

• 技能应该带有清晰的职责边界
• 技能可以组合成工作流
• 技能不等于单个模型调用

这和我们当前“九宫格检测 / 分镜映射 / 视频调度”其实天然契合。

2.2 子代理系统（Subagents）

DeerFlow 强调把复杂任务拆给不同子代理，而不是一个主代理包办所有规划与执行。

这对我们尤其重要，因为我们现在的任务已经明显分裂成多个 domain：

• 普通对话
• 看图分析
• 修图
• 生图
• 生视频
• 画布发布
• 分镜任务

再往后还有：

• 多宫格分镜图生成
• 高清镜头图重生
• 用户确认管理
• 视频镜头调度

这些都非常适合子代理化。

2.3 Middleware 机制

DeerFlow 2.0 文档里一个很重要的方向，是把“状态处理、确认、内存更新、节点前后处理”抽成 middleware，而不是全写在单个 graph 节点里。

这正是我们当前最缺的部分。

我们现在虽然有：

• smart-analyzer
• skill-router
• specialists
• auto-agent-graph

但缺少一个统一的 middleware 层来做：

• 目标图绑定
• 任务确认门
• 安全/策略过滤
• 记忆更新
• 结果发布策略

2.4 明确的 Workflow State

DeerFlow 明显在往“显式工作流状态”方向演进，而不是只靠 prompt 和记忆里的隐式语义。

这对我们的视频分镜任务尤其关键。

比如我们现在正在设计的多宫格视频流程，天然就应该有：

• draft
• slicing
• hd_image_generating
• awaiting_user_confirmation
• confirmed
• video_generating
• completed

这类状态不应该只存在数据库里，也应该存在 Agent Runtime 的显式状态里。

2.5 Human-in-the-loop

DeerFlow 支持人在流程里介入确认，这一点和我们当前需求高度一致。

我们后面做多宫格分镜视频时，最重要的一条就是：

• 用户没确认，不允许开始生视频

如果没有“人类确认是 runtime 的一等公民”这个理念，后续会很容易又退回“模型自己判断继续执行”的老路。

2.6 Long-term Memory / Context Engineering

DeerFlow 已经把长期记忆和上下文工程放进核心能力里。

我们当前项目也已经开始做这件事，但还偏“局部补丁式”：

• 当前图像目标定位
• working memory
• 画布选中上下文

真正还没形成的是：

• 用户偏好长期记忆
• agent 可消费的结构化记忆摘要
• 任务过程中的 thread state 与 memory state 分层

---

3. 我们当前项目已经有什么

从当前代码来看，我们其实已经有了一个不错的基础，不需要从零重做。

3.1 当前已有能力

Agent Graph

• lib/ai/auto-agent-graph.ts

已经使用 LangGraph，而不是简单的 if/else 路由，这一点和 DeerFlow 的底层理念是一致的。

Intent Analyzer

• lib/ai/smart-analyzer.ts

已经在做：

• 意图识别
• prompt 优化
• 视频/图片/分析任务区分

Skill Route / Specialists

• lib/ai/skill-router.ts
• lib/ai/specialists/index.ts

已经有了“specialist + tool allowlist”的雏形，这可以视为 DeerFlow 风格 subagent 的前身。

Tool Registry

• lib/ai/tools-registry.ts

已经有运行时工具注册和上下文过滤能力。

Context Memory

• lib/ai/context-memory/types.ts

已经支持：

• 当前上传图
• 画布选中图
• 历史结果图
• working memory

视频 Storyboard Pipeline 骨架

• lib/video-agent/pipeline/ruxa-nine-grid-pipeline.ts
• lib/video-agent/task-store.ts

已经具备：

• 切片检测
• 分镜映射
• 调度
• DB 任务状态

这说明我们不是“要不要上 Agent”的阶段，而是“Agent Runtime 要不要体系化升级”的阶段。

---

4. 我们当前真正缺什么

4.1 缺少统一的 Agent Runtime State

当前很多信息分散在：

• analysis
• plan
• execution
• DB task
• canvas state
• working memory

但缺少一层统一状态对象把这些东西串起来。

后果是：

• 复杂任务越多，graph 越难维护
• 确认态、重试态、部分完成态难做
• 很难把“Agent 理解能力”和“任务执行能力”解耦

4.2 缺少 Middleware 层

我们现在很多逻辑都直接塞在 graph planning 或 API route 里。

这会导致：

• 加一个新能力就要改很多地方
• 很难复用“确认门”“上下文整理”“结果回写策略”
• 视频、画布、详情生成无法共享行为层

4.3 缺少真正的 Subagent Delegation

现在我们虽然有 specialist，但更多像“专家路由 + 工具白名单”，还不是完整子代理。

完整子代理至少应该具备：

• 自己的职责边界
• 自己的输入/输出结构
• 可以被主代理调用
• 可以独立测试

4.4 缺少 Skill Package 化

我们现在的“skill”更像是代码模块，不像 DeerFlow 那样是可以被稳定调度和演进的能力包。

当前问题：

• 技能定义分散
• 调用方式不统一
• 很难做版本化和可观测性

4.5 缺少强约束的人类确认机制

我们现在可以“提示用户确认”，但还没有把“确认门”上升为系统级策略。

这会导致：

• 一旦某个链路忘记拦截，就可能直接执行
• 视频、多宫格、批量任务这些高成本流程风险很高

---

5. 建议吸收 DeerFlow 的方式

不做框架替换，做 能力吸收式升级。

5.1 第一层：统一 Agent Runtime

建议新增：

• lib/ai/runtime/agent-thread-state.ts
• lib/ai/runtime/agent-workflow-state.ts
• lib/ai/runtime/agent-context-builder.ts

职责：

• 管理单轮对话状态
• 管理任务工作流状态
• 统一拼装上下文、记忆、画布、任务状态

5.2 第二层：Middleware 体系

建议新增：

• lib/ai/runtime/middlewares/intent-guard.ts
• lib/ai/runtime/middlewares/target-binding.ts
• lib/ai/runtime/middlewares/human-confirmation-gate.ts
• lib/ai/runtime/middlewares/memory-update.ts
• lib/ai/runtime/middlewares/publish-policy.ts

这样后续像“多宫格确认门”就不是写死在某个 route 里，而是一个通用中间件。

5.3 第三层：Subagent 体系

建议把现有 specialist 升级成真正可调用的 subagent：

• conversation-subagent
• vision-subagent
• image-edit-subagent
• image-generate-subagent
• video-subagent
• canvas-subagent
• storyboard-subagent

新增最重要的两个：

• storyboard-subagent
• confirmation-subagent

前者负责：

• 宫格规划
• 镜头归一化
• 高清镜头图规划

后者负责：

• 输出确认文案
• 识别用户确认/修改意图
• 阻止未确认执行

5.4 第四层：Skill Package 化

建议把“技能”升级为可注册能力包，而不是只保留 TS 函数。

可以采用轻量形式：

• lib/agent-skills/<skill-id>/index.ts
• lib/agent-skills/<skill-id>/manifest.ts

manifest.ts 建议包含：

• id
• name
• version
• domain
• inputSchema
• outputSchema
• requiresHumanConfirmation
• producesAssets
• canPublishToCanvas

优先 package 化的技能：

1. storyboard-grid-detector
2. storyboard-script-normalizer
3. storyboard-hd-redraw
4. storyboard-confirmation-gate
5. storyboard-video-sequencer

5.5 第五层：长期记忆增强

建议新增：

• lib/ai/memory/user-preference-memory.ts
• lib/ai/memory/task-memory.ts

分开存两类内容：

1. 用户长期偏好
   • 喜欢哪种风格
   • 常用比例
   • 常用模型
   • 是否偏好先确认再执行
2. 任务过程记忆
   • 当前宫格类型
   • 当前镜头草案
   • 已确认镜头
   • 待重生镜头

这样才能让 Agent 既懂“这个用户平时怎么用”，又懂“这次任务现在到了哪一步”。

---

6. 对多宫格视频需求的直接帮助

DeerFlow 思路对我们当前多宫格视频需求最直接的帮助，不是“更会聊天”，而是让整个流程更稳定。

6.1 生成多宫格图前

由 storyboard-subagent：

• 判断该用 4/6/9 宫格
• 自动追加标准宫格 prompt
• 输出结构化镜头规划

6.2 切片与高清图阶段

由 skill chain：

• grid-detector-skill
• shot-mapper-skill
• hd-redraw-skill

每个技能都有固定输入输出，不混在一个大函数里。

6.3 用户确认阶段

由 human-confirmation-gate middleware：

• 拦住视频执行
• 给用户输出可修改镜头文案
• 监听“确认开始生成视频”之类确认语义

6.4 视频执行阶段

由 video-subagent + sequencer-skill：

• 按确认后的镜头串行执行
• 支持失败重试
• 支持只重跑单镜头

---

7. 不建议直接照搬 DeerFlow 的地方

7.1 不建议整套替换 UI / 交互模型

DeerFlow 更偏通用 super agent / deep research 形态。

我们当前项目是：

• 多模态创作
• 无限画布
• 图片/视频生成
• 强任务流

所以 UI、消息结构、画布联动、媒体资产回流这些都不能直接照搬。

7.2 不建议立刻重构成完全独立 repo 架构

我们当前代码已经深度绑定：

• Next.js route handlers
• Vercel AI SDK
• LangGraph
• canvas 状态
• DB task store

直接大迁移只会让功能倒退。

7.3 不建议先做“通用超级代理”，再回头补产品链路

当前最正确顺序应该是：

1. 先用 DeerFlow 思路补强我们的产品主链路
2. 再抽象出通用 Agent Runtime

而不是反过来。

---

8. 推荐升级路线

Phase 0：最小升级

目标：不换架构，只补关键 runtime 能力

• 增加 workflow state
• 增加 confirmation middleware
• 增加 storyboard-subagent
• 增加 skill manifest 机制

Phase 1：多宫格视频先吃到红利

• 用 subagent 重构多宫格分镜理解
• 用 middleware 实现“未确认不得执行”
• 用 skill package 管理分镜检测/切片/高清图/视频调度

Phase 2：扩到全局 Agent

• 图片编辑
• 生图
• 视频
• 画布
• AI 详情

统一切到同一个 Agent Runtime 层。

Phase 3：长期记忆与偏好学习

• 用户偏好长期记忆
• 任务级 thread state
• 记忆摘要和召回策略

---

9. 我建议现在立刻做的事情

如果目标是“先把多宫格视频方案做好”，我建议不要先做大重构，而是先做 4 个高价值改造：

9.1 新增 human-confirmation-gate

这是当前收益最大的一步。

直接服务于：

• 多宫格分镜视频
• 高成本视频任务
• 批量图片任务

9.2 新增 storyboard-subagent

把下面几件事从当前大 graph 里拆出去：

• 宫格数量判断
• 分镜归一
• 标准宫格 prompt 注入
• 高清镜头图阶段规划

9.3 技能 manifest 化

先从视频分镜链路做试点：

• grid-detector
• script-normalizer
• hd-redraw
• video-sequencer

9.4 Thread State 显式化

至少先给视频任务做 thread state：

• 当前 gridType
• 当前 shots
• 当前 confirmationStatus
• 当前 hd image progress
• 当前 video progress

这一步做完后，后续所有复杂 Agent 流程都会更容易。

---

10. 最终判断

DeerFlow 值得认真研究，原因不是它“更强”，而是它已经把很多 super agent 必须补的工程层问题想清楚了：

• workflow state
• middleware
• subagent
• skills
• long-term memory
• human-in-the-loop

这些正好都是我们现在开始碰到的瓶颈。

所以建议是：

• 理念全面学习
• 实现局部吸收
• 架构不整套迁移
• 先用在多宫格分镜视频链路上试点

如果这条链路跑通，再把同样的 runtime 能力推广到图片编辑、生图、画布和 AI 详情。