AI Agent视频节点多模式提示词存储与协作方案

1. 一个视频节点为什么要存多份提示词：从一次协作翻车说起

如果你正在做 AI Agent 相关的产品，尤其是涉及视频生成、多模态内容编排的方向，大概率遇到过这样一个场景：同一个视频节点，在“文生视频”模式下跑得好好的，切到“图生视频”模式之后，输出质量突然断崖式下跌。你以为是模型的问题，换了模型还是不行；你以为是参数的问题，调了采样步数、CFG scale、运动强度，依然不稳定。最后排查半天，发现根因特别朴素——这个节点在两种模式下共用了一份提示词。

Breatic 团队在做实时协作功能的时候，就撞上了这个问题。我们内部把这类节点统称为“视频节点”，它承担的是从一段文本或一张参考图出发，生成一段短视频的职责。早期设计里，一个视频节点只有一份 prompt 字段，用户写什么就是什么。后来我们引入了“模式”的概念，一个节点可以切换不同的生成模式，比如纯文本驱动、首帧图驱动、首尾帧驱动、风格迁移驱动等等。模式一多，问题就来了：同一份提示词，在不同模式下的语义权重完全不一样。

举个很具体的例子。在纯文本模式下，你写“一只鹈鹕骑着自行车穿过黄昏的街道”，模型需要从零构建整个画面，提示词里的每一个名词、形容词、动作词都在参与构图。但在首帧图模式下，画面主体已经由参考图确定了，提示词的作用从“构建画面”变成了“控制运动与氛围”。这时候如果你还保留“一只鹈鹕骑着自行车”这种主体描述，模型会试图在已有画面上再叠加一个主体，结果就是画面撕裂、主体重影、运动轨迹混乱。

这就是为什么一个视频节点必须为每种模式保存不同的提示词。它不是产品设计上的“锦上添花”，而是生成质量稳定性的“底层刚需”。这篇文章我会把 Breatic 团队在这个问题上的完整思考链路拆开讲：从模式差异的本质，到提示词字段的存储结构设计，再到实时协作场景下的冲突处理，最后给出一套可以直接参考复现的方案。不管你是做 AI Agent 开发、提示词工程，还是多模态产品设计，这套逻辑都能直接迁移。

2. 模式差异到底差在哪里：四种典型视频节点的提示词语义拆解

2.1 文本驱动模式：提示词是“从零构建”的施工图

文本驱动模式是最直观的一种。用户输入一段描述，模型从噪声开始，一步步去噪，最终生成视频。这个过程中，提示词的每一个 token 都在参与“无中生有”的构建。我实测下来，这种模式下提示词的信息密度要求最高，因为它要同时承担四个职责：主体定义、场景定义、运动定义、风格定义。

主体定义就是“画面里有什么”，比如“一只鹈鹕”“一辆自行车”“一条街道”。场景定义是“这些东西在哪里、什么时间”，比如“黄昏”“海边”“雨后”。运动定义是“它们怎么动”，比如“骑着”“穿过”“缓缓停下”。风格定义是“画面长什么样”，比如“电影感”“胶片颗粒”“低饱和”。

这四类信息在文本模式下是平权的，模型没有先验知识告诉你哪个更重要。所以你会发现，文本模式下提示词写得越具体，输出越可控。但具体不等于堆砌，我见过太多人把提示词写成了一篇小作文，结果模型反而抓不住重点。这里有个经验：文本模式下，主体和运动要放在提示词的前三分之一，风格和氛围放在后三分之一，中间用逗号分隔的短句比长句更有效。

2.2 首帧图驱动模式：提示词退居为“运动导演”

首帧图模式下，画面第一帧已经由参考图确定了。模型的任务不是“画什么”，而是“怎么动”。这时候提示词的语义权重发生了根本性变化：主体定义基本失效，场景定义部分失效，运动定义和风格定义成为核心。

我做过一组对照测试。同一张鹈鹕骑自行车的首帧图，提示词 A 是“一只鹈鹕骑着自行车穿过黄昏的街道”，提示词 B 是“镜头缓慢推进，鹈鹕的翅膀轻微摆动，自行车轮转动，黄昏光线渐暗”。结果 A 的 output 出现了明显的画面抖动和主体边缘撕裂，因为模型试图在已有鹈鹕的基础上再生成一只鹈鹕。B 的 output 则非常稳定，运动自然，光线过渡平滑。

这个测试说明了一个关键点：首帧图模式下，提示词应该只描述“变化”，不描述“存在”。存在的东西已经由参考图提供了，你再去描述它，就是在给模型制造矛盾信号。所以在这个模式下，提示词模板应该围绕“镜头运动”“主体微动”“环境变化”“光线演变”来组织。

2.3 首尾帧驱动模式：提示词是“过渡路径”的规划书

首尾帧模式比首帧模式更复杂。用户提供第一帧和最后一帧，模型要生成中间的过程。这时候提示词的作用是“规划过渡路径”。它要回答的问题是：从 A 到 B，中间发生了什么？

这种模式下，提示词如果只写运动，模型可能会生成一条直线过渡，看起来很机械。如果只写风格，模型又可能忽略首尾帧的约束。我试过很多次，最有效的写法是“三段式”：起始状态确认、中间过程描述、结束状态确认。比如“从静止开始，鹈鹕逐渐加速蹬踏，自行车从画面左侧移动到右侧，最后减速停在路灯下”。

这里有个坑要注意：首尾帧模式下，提示词里的“结束状态”必须和尾帧图一致。如果尾帧图里鹈鹕是停着的，你提示词写“继续骑行”，模型就会在最后几帧产生剧烈冲突，输出会崩。这个细节在官方文档里通常不会写，但实际跑起来非常致命。

2.4 风格迁移模式：提示词是“风格锚点”的校准器

风格迁移模式下，参考图提供的是风格，不是内容。提示词的作用是告诉模型“保留哪些内容，迁移哪些风格”。这种模式下，提示词的写法又不一样了。它需要明确区分“内容词”和“风格词”。

内容词是你要保留的，比如“鹈鹕”“自行车”“街道”。风格词是你要迁移的，比如“水彩”“赛博朋克”“水墨”。我实测下来，这种模式下提示词里风格词的权重应该调高，内容词的权重应该调低，否则模型会过度保留原图内容，导致风格迁移不彻底。

四种模式的提示词语义差异，我用一张表来总结：

这张表是我们团队内部反复测试后沉淀下来的，每次新人进来我都会让他们先看这张表。理解了这个差异，你才能理解为什么一份提示词不可能通吃所有模式。

3. 存储结构设计：从单字段到模式化提示词映射

3.1 为什么不能简单地在节点上挂一个 prompt 对象

最直觉的方案是：视频节点上挂一个prompts对象，key 是模式名，value 是提示词。比如：

{ "nodeId": "video-node-001", "prompts": { "text2video": "一只鹈鹕骑着自行车穿过黄昏的街道", "firstFrame2video": "镜头缓慢推进，鹈鹕翅膀轻微摆动", "firstLastFrame2video": "从静止开始逐渐加速，最后减速停下", "styleTransfer": "水彩风格，保留鹈鹕和自行车" } }

这个结构看起来没问题，但在实时协作场景下会暴露三个问题。

第一个问题是模式切换时的提示词继承。用户从文本模式切到首帧模式，系统应该展示什么提示词？如果直接展示文本模式的那份，用户很可能忘记改，直接跑，然后输出崩了。如果展示空白，用户又觉得之前的输入白费了。我们最后的选择是：切换模式时，系统自动把当前模式的提示词做一次“语义降级”转换，作为新模式的初始值，但明确标记为“待确认”。

第二个问题是协作冲突的粒度。如果两个人同时在编辑同一个节点的不同模式提示词，用一个大对象存储，冲突检测会变得很麻烦。我们后来改成了每个模式独立存储，独立版本号，独立锁。

第三个问题是历史回溯。用户想看看“上周三首帧模式下的提示词是什么”，如果所有模式混在一起存，回溯逻辑会非常复杂。独立存储之后，每个模式有自己的版本历史，回溯就变成了简单的按模式查询。

3.2 我们最终采用的存储模型

经过几轮迭代，我们最终采用的存储模型是这样的：

{ "nodeId": "video-node-001", "activeMode": "firstFrame2video", "modePrompts": { "text2video": { "prompt": "一只鹈鹕骑着自行车穿过黄昏的街道", "version": 12, "updatedAt": "2025-01-15T10:30:00Z", "updatedBy": "user-a", "status": "confirmed" }, "firstFrame2video": { "prompt": "镜头缓慢推进，鹈鹕翅膀轻微摆动，自行车轮转动", "version": 8, "updatedAt": "2025-01-15T11:20:00Z", "updatedBy": "user-b", "status": "confirmed" }, "firstLastFrame2video": { "prompt": "从静止开始逐渐加速，最后减速停在路灯下", "version": 3, "updatedAt": "2025-01-14T16:45:00Z", "updatedBy": "user-a", "status": "draft" }, "styleTransfer": { "prompt": "水彩风格，保留鹈鹕和自行车，背景做水墨化处理", "version": 5, "updatedAt": "2025-01-13T09:10:00Z", "updatedBy": "user-c", "status": "confirmed" } } }

这个模型有几个关键设计点。activeMode记录当前激活的模式，前端根据这个字段决定展示哪份提示词。modePrompts是一个 map，每个模式独立存储。每个模式内部有version、updatedAt、updatedBy、status四个元字段。

status字段是我们踩坑之后加的。最早没有这个字段，用户切换模式后，系统自动填充的提示词和用户手动确认的提示词混在一起，协作时根本分不清哪些是“定稿”、哪些是“草稿”。加了status之后，协作界面上会用不同颜色标记，confirmed是绿色，draft是黄色，deprecated是灰色。

3.3 模式切换时的提示词转换逻辑

模式切换是这套设计里最容易被低估的部分。用户从文本模式切到首帧模式，如果系统只是简单地把文本模式的提示词复制过去，那基本等于埋雷。我们的做法是做一个轻量的“语义降级”转换。

具体来说，文本模式的提示词通常包含主体、场景、运动、风格四类信息。切到首帧模式时，转换逻辑会尝试剥离主体和场景描述，只保留运动和风格。实现上我们用一个简单的规则引擎加一个可选的 LLM 调用。规则引擎负责识别“主体词”和“运动词”，LLM 负责在规则不确定的时候做兜底判断。

def downgrade_prompt_for_first_frame(text_prompt): # 规则引擎：识别并剥离主体描述 subject_patterns = [r"一只\w+", r"一个\w+", r"一辆\w+"] motion_keywords = ["推进", "拉远", "摆动", "转动", "移动", "加速", "减速"] # 提取运动相关片段 motion_parts = [] for keyword in motion_keywords: if keyword in text_prompt: # 找到包含该关键词的短句 sentences = text_prompt.split("，") for s in sentences: if keyword in s: motion_parts.append(s) if motion_parts: return "，".join(motion_parts) else: # 规则无法处理时，走 LLM 兜底 return llm_downgrade(text_prompt, target_mode="firstFrame2video")

这个转换不是完美的，但它给了用户一个“可编辑的起点”，而不是一个空白框或者一个错误的继承值。实测下来，用户对这个设计的接受度很高，因为大部分情况下转换后的提示词只需要微调，不需要重写。

4. 实时协作下的冲突处理：当两个人同时改不同模式的提示词

4.1 为什么模式化存储反而让协作更简单

乍一看，把提示词拆成多份存储，协作复杂度应该更高才对。但实际跑下来，我们发现恰恰相反。原因在于：冲突的粒度变细了。

在单字段时代，两个人同时编辑同一个节点的提示词，冲突是必然的，因为只有一个字段。系统只能做“后写覆盖”或者“弹窗让用户选”。但在模式化存储之后，A 用户在改文本模式的提示词，B 用户在改首帧模式的提示词，这两个操作在数据层面是完全隔离的，根本不会产生冲突。

我们内部做过统计，模式化存储上线之后，协作冲突告警下降了大约 70%。剩下的 30% 冲突，基本都发生在“两个人同时改同一个模式的提示词”这个场景下。这个场景我们用了乐观锁加版本号来解决。

4.2 乐观锁的具体实现

每个模式的提示词都有一个version字段。用户 A 打开编辑面板时，前端记录当前版本号，比如version: 8。用户 A 修改后提交，后端检查当前数据库里的版本号是否还是 8。如果是，更新成功，版本号变成 9。如果不是，说明用户 B 已经改过了，后端返回冲突，前端弹出对比界面。

async function updateModePrompt(nodeId, mode, newPrompt, expectedVersion) { const current = await db.getModePrompt(nodeId, mode); if (current.version !== expectedVersion) { return { success: false, conflict: true, currentPrompt: current.prompt, currentVersion: current.version, currentUpdatedBy: current.updatedBy }; } await db.updateModePrompt(nodeId, mode, { prompt: newPrompt, version: expectedVersion + 1, updatedAt: new Date().toISOString(), updatedBy: currentUserId }); return { success: true, newVersion: expectedVersion + 1 }; }

这个逻辑很朴素，但非常有效。关键是冲突返回时，我们不只是告诉用户“冲突了”，而是把当前版本的内容、修改人、修改时间都返回给前端，让用户能在一个界面里做对比合并。这个体验比简单的“你的修改已被覆盖”要好得多。

4.3 跨模式依赖的隐性冲突

有一种冲突比较隐蔽：用户 A 改了文本模式的提示词，用户 B 改了首帧模式的提示词，但这两个模式的提示词之间存在语义依赖。比如文本模式里写的是“鹈鹕骑着自行车”，首帧模式里写的是“镜头推进，鹈鹕翅膀摆动”。如果用户 A 把文本模式改成了“一只猫骑着自行车”，那首帧模式里的“鹈鹕翅膀摆动”就失效了。

这种冲突系统很难自动检测，因为语义依赖不是显式的。我们的做法是在协作界面上加一个“关联提示”功能：当用户修改某个模式的提示词时，系统会扫描其他模式的提示词，如果发现主体词不一致，就在界面上给出一个非阻塞的提示：“检测到文本模式的主体是‘猫’，首帧模式的主体是‘鹈鹕’，请确认是否需要同步修改。”

这个提示不强制，不阻塞，只是给用户一个提醒。实测下来，这个功能帮我们避免了很多“改了这边忘了那边”的低级错误。

5. 提示词模板与模式绑定：让 Agent 自己知道该用哪份提示词

5.1 从“用户手动切换”到“Agent 自动路由”

模式化存储解决的是“存”的问题，但“用”的问题还没解决。用户不可能每次都手动去选模式、选提示词。尤其是在 Agent 自动编排的场景下，Agent 需要自己判断当前应该用哪个模式的提示词。

我们的做法是在视频节点上挂一个轻量的“模式路由 Agent”。这个 Agent 的输入是当前节点的上下文信息，包括：是否有参考图、参考图的数量、用户的历史操作、当前任务的目标描述。输出是推荐模式。

def route_mode(node_context): if node_context.get("reference_images") is None: return "text2video" elif len(node_context["reference_images"]) == 1: return "firstFrame2video" elif len(node_context["reference_images"]) >= 2: return "firstLastFrame2video" elif node_context.get("style_reference") is not None: return "styleTransfer" else: return "text2video"

这个路由逻辑很简单，但覆盖了 80% 的常见场景。剩下的 20% 复杂场景，我们会让 LLM 做一次判断。关键是，路由结果会直接决定系统读取哪份提示词，用户不需要手动干预。

5.2 提示词模板的版本管理

除了模式绑定，我们还给每个模式做了提示词模板。模板和用户实际提示词是分开存储的。模板是团队沉淀的最佳实践，用户提示词是具体项目的定制内容。

模板的版本管理比用户提示词更严格，因为模板一旦更新，所有使用该模板的节点都会受影响。我们的做法是模板更新不自动推送到已有节点，而是生成一个“模板更新建议”，在协作界面上提示用户：“首帧模式模板已更新到 v3，当前节点使用的是 v2，是否升级？”用户可以选择升级、忽略、或者查看 diff。

这个设计避免了“模板一改，全线崩”的问题。我见过太多团队因为模板自动更新导致线上事故，这个坑我们提前避开了。

6. 实测中的意外与经验沉淀

6.1 提示词长度在不同模式下的“隐形上限”

我们原本以为提示词长度限制是模型层面的，所有模式应该一样。但实测发现，不同模式对提示词长度的敏感度完全不同。文本模式下，提示词写到 200 个 token 还能保持稳定。但首帧模式下，提示词超过 80 个 token 之后，模型开始出现“指令遗忘”，后面的运动描述会被忽略。

这个发现让我们在存储层加了一个“模式化长度建议”字段。前端会根据当前模式，给用户一个软性的长度提示。超过建议长度时，输入框会变黄，但不阻止提交。这个细节很小，但用户反馈很好，因为很多人根本不知道不同模式对长度敏感度不一样。

6.2 协作场景下的“提示词锁定”

在实时协作中，我们遇到过一个场景：用户 A 正在编辑首帧模式的提示词，用户 B 突然把节点模式切换到了文本模式。这时候用户 A 的编辑面板还开着，但底层数据已经变了。如果用户 A 提交，就会把首帧模式的提示词写到已经切换到文本模式的节点上，造成数据错乱。

我们的解决方案是加了一个“编辑锁”。当用户打开某个模式的编辑面板时，系统会锁定该模式的提示词，同时锁定节点的模式切换。其他用户可以看到“用户 A 正在编辑首帧模式提示词”的状态，但不能切换模式。这个锁是软锁，超时 5 分钟自动释放，避免用户忘记关闭导致死锁。

6.3 一个反直觉的发现：模式越多，提示词复用率越低

我们原本以为，模式多了之后，用户会在不同模式之间复用提示词片段。但数据告诉我们，复用率反而下降了。原因是：不同模式的提示词语义差异太大，用户发现“复制过去还得大改”，不如重新写。

这个发现影响了我们的产品设计。我们不再强调“提示词复用”，而是强调“提示词模板”和“模式化最佳实践”。我们在每个模式的编辑面板旁边放了一个“该模式写作指南”的折叠面板，里面是团队沉淀的写作要点和示例。这个指南的打开率很高，说明用户确实需要模式化的指导，而不是简单的复用。

7. 给正在做类似功能的团队几条实在建议

如果你正在设计一个多模式的视频节点，或者任何需要为不同模式保存不同提示词的 Agent 系统，下面这几条是我踩过坑之后觉得最值得注意的。

第一，不要等到模式多了再拆存储。一开始就按模式独立存储，哪怕当时只有一个模式。后期迁移的成本远高于前期设计的成本。

第二，模式切换时的提示词转换要做，但不要做太重。规则引擎加 LLM 兜底的组合足够用，不要试图做一个完美的语义转换器，那是个无底洞。

第三，协作冲突的粒度要细。按模式加锁，按模式做版本号，按模式做冲突检测。粒度越细，冲突越少，用户体验越好。

第四，给提示词加状态字段。draft、confirmed、deprecated这三个状态能解决 80% 的协作沟通问题。没有状态字段，协作就是一团乱麻。

第五，模式路由能自动化就自动化。不要让用户手动选模式，Agent 能判断的就让 Agent 判断。用户只需要在 Agent 判断错误的时候能手动覆盖就行。

这套方案我们在 Breatic 内部跑了几个月，视频节点的生成稳定性明显提升，协作冲突告警下降了七成以上。最关键的收获是：提示词不是一段文本，它是一个有模式、有版本、有状态、有依赖的结构化数据。你把它当文本处理，它就给你文本级别的麻烦；你把它当结构化数据处理，它才能给你工程级别的稳定。