用Gemini Omni Flash实操视频编辑

把视频生成集成到工作流里最恶心的一点就是“没记忆”。以前用那些工具，想改个光影得把整段 Prompt 重新写一遍，结果场景变了，人物脸崩了，纯粹是在抽奖。最近在公司尝试把 Google 的 gemini-omni-flash-preview 通过 MCP (Model Context Protocol) 接入到 Antigravity CLI 里，发现这种“有状态”的编辑逻辑确实能救命。

简单来说，Omni Flash 支持一个 store=True 的参数，它会给每次生成返回一个 Interaction ID。这意味着你可以先让它生成个“狐狸在雪地跑”的视频，接着直接说“改成深夜下雪”，它能基于之前的视觉上下文进行微调，而不是重新随机生成一个新视频。

核心能力拆解

这个模型其实是个多模态杂食者，输入可以是纯文本，也可以是 Base64 图片或通过 File API 上传的视频。实测下来，它主要覆盖这五种实操场景：

• 纯文本生成： 直接出 MP4，支持 16:9 或 9:16。
• 单图动画： 给张静态图 + 动作指令（比如“让画面里的人挥手”），把图变活。
• 双图补帧： 给 A 和 B 两张图，让它做关键帧插值（比如从日出平滑过渡到日落）。
• 一致性生成： 给参考图 + 场景描述，保证主体在视频里不走样。
• 视频重绘： 上传一个现有视频，直接下指令改风格（比如“改成皮克斯动画风”）。

部署指南与避坑实操

要把这个能力变成一个可调用的 Skill，需要把它封装成 FastMCP Server。以下是核心部署逻辑，如果你要在公司环境推行，建议直接走这个路径。

1. 环境准备与依赖

首先确保你有 Gemini API Key，并且安装了必要的依赖。

pip install fastmcp google-generativeai

2. 核心配置示例

在编写 MCP Server 时，最关键的是处理 interaction_id。一个典型的工具调用配置应该是这样的（伪代码）：

# 核心调用逻辑参考
response = model.generate_content(
    contents=[
        {"text": "make it nighttime with snowfall"}, 
        {"interaction_id": "prev_video_123"} # 这里的ID是维持状态的关键
    ],
    generation_config={"store": True} 
)

3. 踩坑细节（重点）

在实际部署过程中，有几个坑必须注意，否则你的程序会莫名其妙地卡死或崩溃：

• 同步阻塞问题： Omni Flash 的生成是同步的且速度极慢。如果你的 CLI 没有异步处理机制，界面会直接卡死直到视频生成完毕。建议在调用层增加 loading 状态提示。
• 文件大小限制： 这是一个很隐蔽的坑。如果生成的视频超过 4MB，通过 Base64 传输会导致请求体过大而报错。这时候必须强制切换到 Gemini File API 交付模式，通过 URL 引用。
• 计费陷阱： 它是按次计费的，而且由于支持多轮对话（Stateful），如果你在循环里反复微调，额度掉得飞快。

落地效果评估

在团队内部试用了一周，最明显的提效点在于“快速原型”。以前做个简单的演示视频，得在 Web 界面反复调参，现在直接在终端输入一行命令，不满意就跟改代码一样跟进一句“把背景调暗一点”，出片速度快了大概 3 倍。

最硬核的链路是：终端指令 → MCP Server → Gemini Omni Flash → 本地预览 → 一键上传 YouTube。整个过程不需要离开 IDE 或终端，对于习惯了命令行操作的开发人员来说，这种工作流才叫顺畅。

这种基于 MCP 的状态管理模式，其实给所有 AI Agent 提供了新思路：不再是简单的“输入-输出”，而是让模型拥有一个临时的、可迭代的“工作空间”。