Gemini Omni 1.2 Flash API 实战：把视频生成变成 Agent 可执行的任务

简短结论：Gemini Omni 1.2 Flash API 通过 Interactions API 生成和编辑 3 到 15 秒的视频，稳定模型 ID 为 gemini-omni-1.2-flash。要把视频生成纳入可追踪的 Agent 工作流，核心是给每个生成需求建一条任务来承载需求单（brief）、参考素材、目标时长与尝试次数上限，在任务上保存每次返回的 interaction ID，并在多轮修改之间设置人工把关。

Google 于 2026 年 11 月 5 日宣布 Gemini Omni 1.2 Flash 正式全面可用（GA）。对工程与内容团队来说，问题随之变了：不再是“要不要拿这个模型做个玩具实验”，而是“从需求提出到成片签收，一条视频生成任务到底由谁负责、怎么流转”。

调一次视频生成接口，和在聊天框里收一段文字回复完全不是一回事：它按秒计费、返回的是媒体文件，而且成片发给客户之前必须有人签字确认。如果你的 Agent 已经在从 HiFox 任务里领活干，视频生成工作天然契合同一套任务结构——本文将完整拆解这套配置。

先明确一条产品边界：HiFox 本身不生成视频，也没有内置原生的 Omni 渲染器。真正发起 API 调用的是你自己的 Agent，而 HiFox 负责管好围绕这次调用的任务、资产与人工审阅。

Gemini Omni 1.2 Flash API 的调用结构长什么样

一次 Gemini Omni 1.2 Flash API 调用本质上是一次 interactions.create 请求，传入提示词、可选的参考媒体文件，以及指定分辨率与时长的 response_format。后续多轮修改通过 previous_interaction_id 直接复用上一轮结果，因此你只需用自然语言描述改动点，无需把视频文件重新上传一遍。

下面这段示例代码基于 2026 年 11 月 6 日查阅的 Omni 官方文档整理。由于我们尚未实机跑过完整链路，正式批量使用前请先拿一条短视频跑通测试：

import base64
from google import genai

client = genai.Client()  # 从环境变量读取 GEMINI_API_KEY
MODEL = "gemini-omni-1.2-flash"

# 第 1 轮：按需求单要求的时长生成一条低成本 360p 初稿
draft = client.interactions.create(
    model=MODEL,
    input="A slow 360-degree spin of a matte black water bottle on a grey plinth.",
    response_format={"type": "video", "resolution": "360p", "duration": "15s"},
)

# 第 2 轮：人工审阅初稿后，基于保存的 interaction ID 发起修改
edit = client.interactions.create(
    model=MODEL,
    previous_interaction_id=draft.id,
    input="Keep the spin. Change the plinth to pale oak.",
)

with open("clip.mp4", "wb") as f:
    f.write(base64.b64decode(edit.output_video.data))

print(draft.id, edit.id)  # 这两个 ID 应当写回任务记录中

官方文档里有 4 个细节对编写 Agent 尤为关键：

• 默认时长为 10 秒：务必在 response_format 中显式指定时长，因为该字段的优先级高于提示词里写的秒数。
• output_video 仅限官方 SDK 语法糖：如果直接发裸 REST 请求，需要从响应的 steps 数组里提取视频数据。
• 大文件需走 URI 投递：体积超过 4MB 时，需设置 delivery: "uri" 并轮询文件状态直至变为 ACTIVE。
• Omni 没有免费 API 层级：官方定价页显示该模型仅向付费项目开放，720p 视频约为每秒 0.07 美元。

为什么把视频生成建成任务远胜于在私人终端里敲提示词

如果让人在私人终端里零散调用，一项视频工作会碎成四截：需求说明留在聊天软件里，参考图片散在本地文件夹里，interaction ID 埋在终端滚动日志里，而审阅结论只留在某人的脑子里。在视频生成场景下，这种割裂带来的代价远高于文本任务，原因有三：

第一，编辑句柄（interaction ID）有过期时间。多轮对话修改依赖服务端保存的交互记录。Interactions API 文档写明，付费项目默认保留 55 天（可在后台缩短为 7、14 或 28 天）。一旦弄丢了 ID 或超出了保留窗口，后续任何微调都只能当作全新视频从头生成。

第二，一条常见的提速参数会直接废掉多轮编辑能力。Google 的性能优化指南建议开启 store=false 来加快生成速度，但紧接着警告开启后将无法通过 previous_interaction_id 编辑视频。如果某个 Agent 为了追求响应速度自行加上了这个参数，你们团队的审阅修改闭环就会当场失效。

第三，请求配额非常金贵。速率限制页显示 Tier 1 项目每分钟仅限 8 次请求、每天仅限 40 次请求。每一次生成初稿和每一次对话修改都会消耗 1 次配额。如果三个 Agent 各自在本地盲目试变体，不到中午就能把全天配额烧光，而且没人知道第四个任务为什么会报错。

一条标准视频生成任务的五个组成部分

把视频生成当成正经的 Agent 工作项来管，它需要具备以下五个部分，且每一部分都有明确的归属：

1. 需求单（Brief）

需求单直接写在任务描述里，保持简短清晰，方便验收时逐条对照成片：

Goal: 15-second product spin for the launch page
Format: 16:9, 720p final, 15s
References: bottle-front.png, bottle-back.png, brand-colors.png
Must keep: logo text readable, matte finish, no people
Attempt cap: 4 drafts at 360p, 3 edits at 720p
Reviewer: the person who owns the launch page

其中最管用的是“尝试次数上限（Attempt cap）”。没有这一行，“多试几个版本”就会变成无底洞。

2. 参考素材（Reference assets）

把参考素材作为附件挂在任务上，确保每次运行读取的都是同一批文件。Omni 每次请求支持传入最多 6 张参考图片（最多支持 2 个角色、每个角色最多 3 张参考图）；参考视频每段最长 3 秒（生成 11 到 15 秒视频时可传 1 段，生成更短视频时最多可传 3 段）。

注意一处文档差异：Google 的发布公告提到了音频参考提示（audio cues），但当前版本的 API 文档明确写着尚不支持上传音频文件。因此，声音和音效要求请直接写在文本提示词里。

3. 调用 API 的 Agent

Agent 需要运行环境和密钥。在 HiFox 中，Agent 设置支持配置普通环境变量与机密环境变量（secret），把 GEMINI_API_KEY 作为机密变量存进去即可。由于 HiFox 不售卖 Token，所有 API 调用费用直接走你自己的 Google 结算账户。

4. 多轮修改记录

每一次修改都是在同一个 interaction 上发起的新一轮调用，且每一轮都会产出一个新视频。要求 Agent 在每一轮执行完毕后，把当轮的 interaction ID、分辨率和时长作为评论写回任务。这样无论是下一轮自动运行还是另一位同事接手，都能精准地从选定的那一版继续往下改。

5. 人工审阅节点

在初稿轮结束之后、以及最终高分辨率渲染之前，让 Agent 停下来等待人工确认。这两个节点最能帮团队省下冤枉钱、挡住品牌走样。

Agent 负责生成初稿、按指令修改并回传 ID；人负责定需求单、挑初稿和签收成片。

HiFox 如何承载整条视频任务流

HiFox 承担的是责任归属与审阅闭环。任务就是团队共享的唯一记录，执行进展、调用轨迹与产出结果都会写回任务。

具体流转机制非常直接：

1. 在「待处理（Backlog）」状态准备需求：处于待处理状态的任务即使指派了 Agent 也不会立即触发运行，你可以先从容写好需求单、传齐参考图。
2. 移出「待处理」启动运行：把任务状态推入「待办」或「进行中」，被指派的 Agent 就会在它连接的电脑上开始执行。
3. 交接给人工审阅：Agent 跑完初稿后将任务对话设为等待人工审阅（「等你审阅」），负责人会在主侧栏的「对话」模块收到提醒。
4. 通过评论继续下一轮修改：审阅人在任务下回复挑选结果与修改意见，即可触发同上下文的后续运行，继续下一轮编辑。
5. 验收归档：把最终成片挂到任务附件上，由人工核对无误后将任务推入「已完成」状态。

每个状态类别下的具体状态名称可由组织按需自定义（例如单独加一个“待审片”状态），而「排队中」「运行中」等 Agent 运行状态则与任务状态分开展示，互不干扰。

那些每次生成都要遵守的固定规矩，最适合放进技能里——技能会把标准操作指令打包给所有绑定它的 Agent。把 Omni 的调用规范写进技能一次，后续所有视频任务都能自动继承。注意不要把 API 密钥写进技能文件，密钥始终应当放在环境变量或凭据设置里。关于在关键节点停下等待人工确认的通用模式，可参考我们的编程 Agent 的审批关卡。

应当写进「技能」里的 Omni 模型硬限制

Omni 不支持 system instructions（系统指令）、temperature（温度）或 negative prompts（反向提示词）等独立配置项，因此所有约束都必须通过提示词或请求体字段传给模型。以下限制整理自 Omni 官方文档：

还有一处细节需要实测确认：文档虽然支持在每次请求中设置 resolution 并将 1080p 和 4K 标为超分采样，但没有给出“对已有视频单独做超分”的代码示例（尽管 Google 的发布公告描述了先低清打磨再超分的工作流）。在把这一步写进团队技能之前，请先用一条短视频实测确认参数写法。

什么时候没必要建任务

当一条视频需要明确的负责人、预算上限和审阅签收记录时，用任务来管；如果只是某个人临时想手动做一条短片，直接打开 Google 自家应用更快——Flow 支持多轮对话修改，Google Vids 则支持直接生成 15 秒视频。

如果你的场景包含脚本调研、分镜拆解、多段拼接字幕等完整后期工程，而不是单次模型调用，则需要专门的多阶段视频流水线（例如 OpenMontage 这类工具）。即便如此，你依然可以用一条 HiFox 任务来管理这条流水线的输入需求与最终交付验收。

适合优先落地的三类视频任务

最适合拿来跑通第一单的视频任务，往往具备“短小、高频重复、好验收”三个特点：

• 新功能发布短片：功能上线后，Agent 根据更新日志（changelog）生成一条 15 秒演示初稿，交由产品或市场负责人审阅。
• 商品 360 度旋转展示：把商品正反面实拍图作为参考素材传入，Google 表示模型在旋转镜头下仍能保持包装文字与品牌色彩稳定。
• 多受众广告变体：基于同一条已批准的母片，按不同受众渠道发起多轮微调，所有变体与对应的 interaction ID 全部归口在同一条任务下。

建议从“新功能发布短片”开始试水——因为文字素材本来就是现成的，而且审阅人也是固定的。

下一步建议

挑一条你们团队这个月本来就要做的短视频，按上文的 6 行模板写好需求单；接着连接一台电脑，给配置好 Gemini 密钥的 Agent 指派一条低风险测试任务，把上限设为 2 次初稿、1 次修改，验证 Agent 能否把生成的 interaction ID 准确写回任务评论。具体初始化步骤可参阅 HiFox 的快速开始文档。等第一单顺畅跑通后，再把这套规则沉淀成团队共享的技能。

常见问题

Gemini Omni 1.2 Flash API 的模型 ID 是什么？

稳定模型 ID 是 gemini-omni-1.2-flash。自 2026 年 12 月 3 日起，发往 gemini-omni-1.1-flash 的请求也会自动路由到 1.2。

怎么用 Gemini Omni API 修改已经生成的视频？

发起一次新的 interactions.create 请求，把 previous_interaction_id 设为上一轮返回的 ID，并用自然语言描述需要修改的地方，模型会自动保留你未提及的画面元素。

Gemini 会把可编辑的交互记录保留多久？

付费项目默认保留 55 天，你也可以在 AI Studio 中将其缩短为 7、14 或 28 天；如果在请求时传入 store=false，则不会保存交互记录。

AI Agent 可以自己独立调用 Gemini Omni API 吗？

可以，任何能执行代码并读取 API 密钥的 Agent 都能发起调用。真正的难点不在于发请求，而在于需求单、尝试次数上限和人工审批记录放在哪里管理。

HiFox 有直接内置 Gemini Omni 集成吗？

没有。Agent 是在它所连接的电脑上使用你配置的密钥直接调用 Google 官方 API，HiFox 负责管理围绕这次调用的任务、技能规范与人工审阅流转。

Gemini Omni 生成的视频带水印吗？

带。所有生成的视频都会嵌入 SynthID 隐形数字水印，可通过程序进行检测识别。