lunanting/ai-chatbot

Fork 0

Your Name 159137b3d7

Lint / build (20) (push) Has been cancelled

Details

Playwright Tests / test (push) Has been cancelled

Details

feat: formalize agent conversation state protocol

2026-03-13 13:24:09 +08:00

18 KiB

Raw Blame History

Agent 模式与 DeerFlow 对比说明（大白话版）

写给谁看：不懂技术，但想真正看明白这个项目的人。
更新时间：2026-03-13。
本文已经按今天实际落地的代码重写，不再沿用旧判断。

先说结论

一句话结论

我们这个项目，现在已经不是“普通聊天 + 一堆工具”的形态了。
它正在变成一个面向视觉生产的统一 Agent Runtime。
DeerFlow 仍然更像一个通用超级智能体底座。
它更擅长：通用任务拆解、子代理协作、沙箱执行、技能体系、长期记忆、MCP 集成。

现在最准确的判断

过去说我们项目“还只是主脑 + 一堆补丁”，今天之后就不完全对了。

因为我们已经补上了这些关键层：

conversation action resolver
conversation memory composer
conversation thread state builder
conversation state protocol
conversation state protocol events
human-confirmation-gate
storyboard-subagent
image-generation-subagent
image-edit-subagent

也就是说：

我们还不是 DeerFlow 那种通用超级智能体平台，但已经明确进入“统一运行时 Agent”阶段。

1. 这个项目现在的 Agent，到底是什么

这个项目现在有两层 Agent：

1.1 运行时 Agent

这是核心大脑，负责：

理解用户这轮到底在说什么
判断用户到底指哪张图
判断这是普通聊天、看图、修图、生图、视频、还是分镜任务
恢复上一轮工作记忆
根据当前 workflow 决定是继续、修改、确认、取消，还是新开任务
选择工具、选择模型、执行

主要代码：

app/(chat)/api/chat/route.ts
lib/ai/auto-agent-graph.ts
lib/ai/smart-analyzer.ts
lib/ai/skill-router.ts
lib/ai/runtime/*
lib/ai/conversation-*

1.2 预设智能体层

这层更像“模板化工作流”：

默认模型
固定提示词
固定槽位
固定参数

主要代码：

app/api/agents/*
components/agents/*
types/agent.ts

所以一定要分清：

运行时 Agent = 真正思考和调度的系统大脑
预设智能体 = 预先配置好的业务模板

2. 今天升级后，Agent 底层结构已经变成什么样了

今天最重要的升级，不是多接了一个模型，而是把 Agent 的“脑子”和“记忆”开始统一起来。

2.1 现在已经有一套会话协议层

我们已经新增了以下模块：

lib/ai/conversation-action-resolver.ts
lib/ai/conversation-memory-composer.ts
lib/ai/conversation-thread-state-builder.ts
lib/ai/conversation-state-protocol.ts
lib/ai/conversation-state-protocol-events.ts

你可以把它理解成：

以前

像很多项目一样，是：

用户说一句
系统临时判断一次
执行一次
结果存一点

每轮都更像“重新开始”

现在

变成：

先恢复这段对话的会话状态
再判断这句话属于什么动作
再拼装统一上下文
再让 planner 决定下一步
执行完成后，再按统一协议写回状态

也就是说，我们开始有真正的：

会话状态协议

而不是单轮聊天补丁。

2.2 现在已经有统一的动作协议

现在系统会先判断，这轮对话属于哪种动作：

default
grid_confirmation_followup
active_storyboard_followup
image_edit_followup
prompt_carry_forward

这一步在：

lib/ai/conversation-action-resolver.ts

这件事很重要，因为它解决了一个以前特别容易乱的问题：

用户到底是在：

开一个新任务
继续上一轮任务
修改上一轮任务
确认一个待执行任务
取消一个待执行任务

以前这些判断很多散在 chat/route.ts 里。
今天开始，它们在往统一协议收。

2.3 现在已经有统一的 thread state

现在运行时 Agent 已经不只是收到一段文本了。

它会收到一个 threadState，里面可能包含：

当前 workflow
当前 workflow 状态
当前 memory hints
当前上下文摘要
当前 prompt memory
当前 image workflow memory
当前 storyboard preference memory

这一步主要在：

lib/ai/runtime/agent-thread-state.ts
lib/ai/conversation-thread-state-builder.ts
lib/video-agent/agent-thread-state.ts

这意味着：

Agent 已经开始像人一样“带着上下文继续理解”，不是每轮都失忆。

2.4 现在已经有统一的读写协议

今天另一个很关键的变化是：

app/(chat)/api/chat/route.ts 里已经不再直接调用 upsertConversationWorkingState(...)。

写回现在统一走：

persistConversationStateEvent(...)
persistPromptOnlyTurn(...)
persistGridConfirmationTurn(...)
persistStoryboardConfirmedTurn(...)
persistImageWorkflowTurn(...)
persistResolvedTargetTurn(...)
persistVideoWorkflowTurn(...)
persistAgentPresetTurn(...)
persistStoryboardAssistantTurn(...)

也就是说：

聊天主路由已经从“自己管理记忆结构”，升级为“只触发语义事件”。

这是一件很大的架构进步。

2.5 现在已经有协议级调试流

当请求里带 debugProtocol: true 时，前端会收到：

request
bootstrap
composed
event

这些 data-protocolDebug 事件。

前端也已经能显示协议调试面板：

components/protocol-debug-panel.tsx
components/chat.tsx

这意味着你们现在不是只能“看结果”，而是能直接看：

这轮命中了什么动作
这轮 workflow 是什么
Agent 拿到的 memory hints 是什么
这轮写回了哪个协议事件

这对后面继续调优 Agent 非常重要。

3. 现在这套 Agent 实际怎么工作

3.1 先收素材

系统先统一整理：

当前上传图
画布选中图
历史图
上一轮结果图
文本里贴的 URL 图

主要代码：

lib/ai/context-memory/media-input.ts
lib/ai/context-memory/target-resolution.ts

3.2 恢复会话状态

系统会先从数据库恢复：

prompt memory
image workflow memory
storyboard preference memory
active storyboard task
pending grid confirmation

然后用协议层统一拼成：

actionResolution
threadState
contextSummary
memoryHints

主要代码：

lib/ai/conversation-state-protocol.ts
lib/ai/conversation-memory-composer.ts
lib/ai/conversation-thread-state-builder.ts

3.3 先判断“这轮属于什么动作”

比如：

“根据刚才那个提示词来做这张图”
“把第三镜头改成近景”
“先别生成了”
“按 6 宫格来”
“确认开始生成视频”

系统会先给这句话归类。

这不是最终业务意图，而是：

当前回合的会话动作

这一步特别像一个“对话状态机入口”。

3.4 再进入 Auto Agent Graph

当前 graph 主要节点是：

confirmationGate
analyze
plan
prepareExecution
optimize
routeModel

也就是：

flowchart TD
  A["用户输入"] --> B["恢复会话状态"]
  B --> C["conversation action resolver"]
  C --> D["threadState + memory composer"]
  D --> E["confirmationGate"]
  E --> F["analyze"]
  F --> G["plan"]
  G --> H["prepareExecution"]
  H --> I{"要不要优化提示词/分镜"}
  I -- "要" --> J["optimize"]
  I -- "不要" --> K["routeModel"]
  J --> K
  K --> L["执行工具 / 模型"]
  L --> M["协议化写回状态"]

3.5 专家和子代理会介入

现在已经有明确的子代理/专家层：

storyboard-subagent
image-generation-subagent
image-edit-subagent
canvas-specialist

对应文件：

lib/video-agent/storyboard-subagent.ts
lib/ai/image-generation-subagent.ts
lib/ai/image-edit-subagent.ts
lib/ai/specialists/index.ts
lib/ai/skill-router.ts

虽然它们还没有发展成 DeerFlow 那种“很多通用子代理并发工作”的程度，
但已经不是简单的路由白名单了。

它们现在已经会：

给 planner 注入强约束
修正执行计划
改变工具选择
改变结果回画布策略
改变是否继续执行

所以这里要纠正一个旧说法：

旧判断：我们项目还只是“主脑 + 一堆专家修正”，不算真正子代理。

这个说法现在只算“部分正确”。

更准确的说法应该是：

当前项目已经进入了“子代理化早期阶段”，
但还没有发展成 DeerFlow 那种真正的大规模通用子代理系统。

4. 普通生图对话现在怎么理解了

这是今天升级里非常重要的一块。

4.1 以前

用户说：

“帮我根据这张图优化提示词”
下一轮再说：“按上一个优化后的提示词来优化这张图”

以前很多系统会丢上下文，只看到第二句话。

4.2 现在

系统已经有：

promptMemory
imageWorkflowMemory
image_generation_followup workflow

这意味着 Agent 更可能理解成：

使用上一轮优化后的提示词

当前这轮的新图片

当前用户的数量/画幅/清晰度需求
来继续执行这轮生图任务

这一步主要在：

lib/ai/prompt-memory.ts
lib/ai/image-workflow-memory.ts
lib/ai/image-generation-subagent.ts

4.3 多张图能力也已经升级

今天还补了一个很重要的底层能力：

如果用户要 6 张、8 张、12 张图，而当前模型单次只能返回 1 张或 2 张，系统会自动分批调用，直到凑够目标数量。

主要代码：

lib/canvas/generate-image.ts

这说明现在系统对：

“连续生图”
“多张图需求”
“提示词接力”

已经开始形成统一能力，不再是三个分开的 feature。

5. 连续修图对话现在怎么理解了

今天还补了：

image_edit_followup workflow
image-edit-subagent

这意味着如果用户说：

“继续改上一张结果图”
“保留主体不变，只把背景换掉”
“上一版再亮一点”
“这张继续优化”

系统更可能理解成：

这是连续修图任务
目标图优先取上一轮结果图或当前绑定目标图
不要误判成重新生图

这一步主要在：

lib/ai/image-edit-subagent.ts
lib/ai/conversation-thread-state-builder.ts
lib/ai/conversation-action-resolver.ts

6. 分镜视频链路现在是什么水平

这里也要纠正旧判断。

6.1 以前可以说“文档多、草图多、骨架多”

6.2 现在已经不是纯方案阶段了

现在已经实际落地了这些模块：

lib/video-agent/pipeline/ruxa-nine-grid-pipeline.ts
lib/video-agent/execute-storyboard-task.ts
lib/video-agent/revise-storyboard-task.ts
lib/video-agent/storyboard-command-interpreter.ts
lib/video-agent/storyboard-preference-memory.ts
lib/video-agent/task-store.ts
app/(chat)/api/video/storyboard/*

而且链路已经具备：

分镜拼图检测
4/6/9 宫格识别
镜头切片
高清预览图生成
用户确认门
单镜头修改
单镜头重生高清图
确认后逐镜头开始视频执行

所以这里也要纠正一个旧说法：

旧判断：分镜视频还主要停留在方案文档阶段。

现在更准确的说法是：

分镜视频已经进入“半落地工作流阶段”，
不是只有文档，已经有实际 runtime、task-store、API 和前端联动。
但还没有完全进化成通用化的视频工作流平台。

7. 这个项目当前到底像什么

今天之后，再用一句话总结这个项目：

它已经不是单纯的多模态聊天应用，而是一个“面向视觉生产的 Agent 工作流系统”。

更准确一点说，它现在像：

产品层

图片编辑
图片生成
视频生成
分镜工作流
无限画布

Agent 层

统一动作解析
统一记忆合成
统一 thread state
统一 workflow state
统一写回协议
统一协议事件
可选调试面板

也就是说，它现在已经开始具备一个真正 Agent Runtime 的轮廓。

8. DeerFlow 到底是什么，今天要怎么正确看

根据 DeerFlow 官方仓库和架构说明，最准确的大白话是：

DeerFlow 是一个“通用超级智能体运行底座”，不是一个专门给视觉生产做深度业务适配的产品。

它的强项主要在：

通用任务拆解
Sub-agents
Skills
Sandbox
Middleware
Long-term Memory
MCP 集成

简单说：

DeerFlow 擅长

做一个什么都能接的“超级智能体平台”

我们现在擅长

把图片、视频、画布、分镜这种视觉业务做深

DeerFlow 强于我们的地方

通用子代理体系更成熟
沙箱执行更完整
MCP 和工具生态更平台化
长期记忆体系更偏平台级

我们强于 DeerFlow 的地方

图片目标定位更细
画布联动更深
连续修图/连续生图更贴业务
分镜视频确认流程更贴实际视觉生产

9. 现在该怎么评价我们和 DeerFlow 的差距

现在最准确的说法不应该是：

我们只是一个普通业务项目，DeerFlow 才是真 Agent。

这个说法已经不对了。

现在更准确的说法是：

我们已经开始构建自己的统一 Agent Runtime，
但它仍然是视觉业务优先的 Agent Runtime，
不是 DeerFlow 那种通用超级 Agent 底座。

所以差距主要不在“有没有 Agent”，而在：

我们还缺这些

更彻底的 route 解耦
app/(chat)/api/chat/route.ts 仍然是超大总控（现在 9065 行）
更强的通用子代理并发体系
当前已有 subagent，但还不算真正的多工人协作系统
更成熟的长期记忆
现在更强的是会话工作记忆，不是跨会话长期人格/知识记忆
更彻底的执行环境抽象
我们强在视觉业务执行，不强在通用沙箱型任务执行

但我们已经补上的

统一会话协议
统一 workflow 语义
统一协议事件
统一前端调试入口
统一图片/分镜连续任务理解

这说明我们不是“还没开始”，而是已经跨过了最难的第一阶段。

10. 今天最该纠正的旧判断

下面这些是现在必须纠正的：

旧判断 1

当前项目还是一堆业务补丁，没形成统一运行时。

现在更准确

已经形成了统一运行时骨架：

action resolver
memory composer
thread state builder
state protocol
event schema
debug stream

还没彻底清完旧逻辑，但不能再说“没有统一运行时”了。

旧判断 2

specialist 只是一些工具白名单，不算真子代理。

现在更准确

已经进入早期子代理阶段：

storyboard-subagent
image-generation-subagent
image-edit-subagent

它们已经能改变 planning hints、tool 选择、workflow 行为和对话理解。

旧判断 3

当前项目只擅长单轮修图/生图。

现在更准确

多轮能力已经明显增强：

连续生图
连续修图
提示词接力
分镜确认
单镜头修改
单镜头重生

旧判断 4

这套系统不够像真人对话。

现在更准确

它离“真人协作理解”还没完全到位，但已经开始具备几个核心特征：

记得上一轮的提示词
记得上一轮的目标图和结果图
知道当前这句话是在继续任务还是新开任务
知道贵活要不要先确认
能理解“继续改上一版 / 按上一个 prompt 来 / 第三镜头改成……”

这已经不是普通问答模型的水平了。

11. 我现在给这个项目的最准确定位

今天之后，我会把这个项目定位成：

一个以视觉生产为核心、正在持续进化成统一 Agent Runtime 的内容创作系统。

不是：

普通聊天机器人
只会调几个工具的脚手架
纯文档阶段的 Agent 方案

也还不是：

DeerFlow 那种通用超级 Agent 操作系统

而是处在中间的一个非常关键阶段：

业务已经很深，底座开始统一。

这其实是最有价值的阶段。

12. 现在最值得继续做的事

如果后面继续投入，最值得的方向不是乱加功能，而是继续收敛：

12.1 继续把旧逻辑迁入统一协议

现在最该做的，是继续把 chat/route.ts 里剩下的零散判断收进：

conversation state protocol
subagents
workflow state

12.2 把协议消费侧再做强

现在已经有协议调试事件和前端调试面板了，下一步可以继续做：

后台协议事件查看
任务追踪面板
Agent 解释路径可视化

12.3 长期记忆继续补强

下一步建议补：

用户长期风格偏好
常用画幅/清晰度/数量偏好
品牌/行业上下文
跨项目偏好

12.4 真正统一“图片/视频/画布/分镜”工作流状态

现在已经有：

storyboard_video
image_generation_followup
image_edit_followup

后面可以继续扩成完整的统一 workflow catalog。

13. 最后一句人话总结

DeerFlow

像一个通用的超级智能体操作系统。

我们现在的项目

像一个已经非常懂视觉生产业务、而且今天开始真正长出统一 Agent 神经系统的创作引擎。

今天之后最准确的一句话

不要再把我们看成“很多智能 patch 拼起来的聊天应用”，
它已经在往“统一会话协议驱动的视觉 Agent Runtime”演进了。

资料来源

本项目代码与文档

app/(chat)/api/chat/route.ts
app/(chat)/api/chat/schema.ts
components/chat.tsx
components/protocol-debug-panel.tsx
lib/ai/auto-agent-graph.ts
lib/ai/smart-analyzer.ts
lib/ai/skill-router.ts
lib/ai/specialists/index.ts
lib/ai/conversation-action-resolver.ts
lib/ai/conversation-memory-composer.ts
lib/ai/conversation-thread-state-builder.ts
lib/ai/conversation-state-protocol.ts
lib/ai/conversation-state-protocol-events.ts
lib/ai/prompt-memory.ts
lib/ai/image-workflow-memory.ts
lib/ai/image-generation-subagent.ts
lib/ai/image-edit-subagent.ts
lib/video-agent/*
docs/DeerFlow调研与Agent升级建议-2026-03-12.md

DeerFlow 官方资料

官方仓库 README：https://github.com/bytedance/deer-flow
架构/运行说明：仓库内 README、backend/README、backend/CLAUDE.md

18 KiB Raw Blame History Unescape Escape

Agent 模式与 DeerFlow 对比说明（大白话版）

先说结论

一句话结论

现在最准确的判断

1. 这个项目现在的 Agent，到底是什么

1.1 运行时 Agent

1.2 预设智能体层

2. 今天升级后，Agent 底层结构已经变成什么样了

2.1 现在已经有一套会话协议层

以前

现在

2.2 现在已经有统一的动作协议

用户到底是在：

2.3 现在已经有统一的 thread state

2.4 现在已经有统一的读写协议

2.5 现在已经有协议级调试流

3. 现在这套 Agent 实际怎么工作

3.1 先收素材

3.2 恢复会话状态

3.3 先判断“这轮属于什么动作”

3.4 再进入 Auto Agent Graph

3.5 专家和子代理会介入

4. 普通生图对话现在怎么理解了

4.1 以前

4.2 现在

4.3 多张图能力也已经升级

5. 连续修图对话现在怎么理解了

6. 分镜视频链路现在是什么水平

6.1 以前可以说“文档多、草图多、骨架多”

6.2 现在已经不是纯方案阶段了

7. 这个项目当前到底像什么

产品层

Agent 层

8. DeerFlow 到底是什么，今天要怎么正确看

DeerFlow 擅长

我们现在擅长

DeerFlow 强于我们的地方

我们强于 DeerFlow 的地方

9. 现在该怎么评价我们和 DeerFlow 的差距

我们还缺这些

但我们已经补上的

10. 今天最该纠正的旧判断

旧判断 1

现在更准确

旧判断 2

现在更准确

旧判断 3

现在更准确

旧判断 4

现在更准确

11. 我现在给这个项目的最准确定位

12. 现在最值得继续做的事

12.1 继续把旧逻辑迁入统一协议

12.2 把协议消费侧再做强

12.3 长期记忆继续补强

12.4 真正统一“图片/视频/画布/分镜”工作流状态

13. 最后一句人话总结

DeerFlow

我们现在的项目

今天之后最准确的一句话

资料来源

本项目代码与文档

DeerFlow 官方资料

18 KiB

Raw Blame History