新版 Flow 灰度账号文生图失败：NARWHAL 返回 code=[5]，Nano Banana 2.1 的 ID 为 BELUGA；ogiZ0b 请求体多一个 null #187

问题描述

部分账号已被 Google 灰度到新版图片模型列表：Flow 网页的模型下拉框只剩 Nano Banana Pro / Nano Banana 2 Lite / Nano Banana 2.1，原来的 Nano Banana 2 已经没有了。账号配置里的版本串也带有 nb21 标记（cPZSdc / Yizz8d 响应中可见 …-v0-nb21-…）。

在这类账号上，基于最新代码 c35b8df 测试，出现两个问题：

1. gemini-3.1-flash-image-* 全部失败，报 code=[5]（gRPC NOT_FOUND）。
2. 换成能识别的模型 ID 之后，文生图大多数请求返回 PUBLIC_ERROR_UNUSUAL_ACTIVITY。Pro (GEM_PIX_2) 同样会遇到。

同一账号在 Flow 网页上生成一切正常。

复现

• 打码：YesCaptcha RecaptchaV3TaskProxylessM1S9
• 账号：Pro（PAYGATE_TIER_ONE），Cookie 有效，查余额 nzlxg 正常

model: gemini-3.1-flash-image-landscape
错误: 生成失败: Flow frontend RPC rejected: rpc=ogiZ0b, code=[5]

把模型 ID 改成 BELUGA 之后：

错误: 生成失败: Flow frontend RPC rejected: rpc=ogiZ0b, error=PUBLIC_ERROR_UNUSUAL_ACTIVITY

排查过程中排除的假设

根因

在网页上分别用三个模型文生图，抓取 batchexecute?rpcids=ogiZ0b 的 f.req，与 flow2api 逐槽比对。

① 图片模型 ID 已变更

视频 YhhmEf 的 model key（abra_t2v_4s、veo_3_1_t2v_lite、veo_3_1_t2v_fast、veo_3_1_t2v）及参数结构均与现有代码一致，不受影响。

另外，项目设置里的模型存储名（Kcr7Ub 的 default_generation_settings.image_defaults）是小写的 harbor_seal、nano_banana_pro，与 ogiZ0b 里的大写 ID 不是同一套，不要混用。

② ogiZ0b 内层 request 多一个 null（即 #182 末尾提到的 14 槽 / 15 槽问题）

网页真实请求（14 槽）：

[null, null, null, <seed>, 3, "BELUGA", null, <clientContext>, [[["一个苹果"]]], null, null, null, "<UUID>", "<UUID>"]

当前实现 _build_frontend_image_generation_argument（15 槽）：

[None, None, <refs>, <seed>, <aspect>, <model>, None, <clientContext>, [[[prompt]]], None, None, None, None, session_id, <uuid>]

#182 中提到，非灰度账号文生图带着这个多余槽「一直正常」。但在灰度账号上，修正为 14 槽前后差异明显（见下方验证）。

建议修复

1. generation_handler.py：gemini-3.1-flash-image-* 的 model_name 改为 BELUGA，模型列表的 listed 判断同步改为 BELUGA；新增一组 Lite 模型（HARBOR_SEAL），比例与 2K/4K 档位与 3.1 相同。
2. flow_frontend.py：_build_frontend_image_generation_argument 中，[[[prompt]]] 之后只保留 3 个 None，使 session_id 与 UUID 位于第 12、13 槽。
3. 兼容性考虑：未灰度账号可能仍只认 NARWHAL。可以在收到 code=[5] 时回退到另一个 ID，或者把模型 ID 做成可配置项。我只有灰度账号，未验证未灰度账号的情况。

本地补丁要点：

-            [[[prompt]]],
-            None,
-            None,
-            None,
-            None,
-            session_id,
-            str(uuid.uuid4()).upper(),
+            [[[prompt]]],
+            None,
+            None,
+            None,
+            session_id,
+            str(uuid.uuid4()).upper(),

 "gemini-3.1-flash-image-landscape": {
     "type": "image",
-    "model_name": "NARWHAL",
+    "model_name": "BELUGA",

另外加了一个单元测试，锁定布局：len(request) == 14、request[9:12] == [None] * 3、request[12] == session_id。

验证

同一账号、同一服务器、YesCaptcha。下表按单次尝试统计（每次尝试打一次码、提交一次 ogiZ0b）：

失败均为 PUBLIC_ERROR_UNUSUAL_ACTIVITY。按默认 max_retries = 3 跑的 3 个请求（2.1 / Lite / Pro 各 1 个）全部出图，耗时 48s / 18.4s / 38.7s。

结论（样本量不大）：

• 改 ID 解决了 code=[5]。
• 改为 14 槽后，单次通过率从约 10% 提高到约 33%。
• 仍有约 2/3 的单次尝试被 UNUSUAL_ACTIVITY 拒绝，靠重试兜住。剩余差异推测与 flow2api 不发送 Chrome 专有请求头（x-browser-validation、x-client-data、完整 sec-ch-ua-*）有关，这些头无法在服务端生成，未做改动。

补充观察：_call_flow_frontend_rpc 与网页行为不一致（可选修复）

• 网页请求的 Referer 为 https://flow.google.com/，flow2api 用的是 https://flow.google.com/project/<id>。
• 网页请求首次就带上 at（xsrf）参数。flow2api 每次 RPC 先发一次不带 at 的请求，拿到 400 后再重发，所以每个 RPC 都多一个 400，生成类 RPC 的一次性 reCAPTCHA token 也会被提交两次。

我在本地改成：首个请求直接带上 bootstrap 中的 SNlM0e（_extract_stream_chat_at_token 已有现成实现），Referer 改为站点根路径，并保留收到 xsrf 400 后重发的兜底。

改后调试日志确认，每次生成只发 1 个 ogiZ0b，不再出现 400。但单次通过率没有可测变化（上表「ID + 14 槽」中的 6 次尝试就是在这个改动之后测的，2/6），所以偶发的 UNUSUAL_ACTIVITY 与此无关。这一条只作为对齐网页行为、减少多余请求的建议。

环境

• flow2api c35b8df，Docker（python:3.11-slim），Linux 服务器
• captcha_method = "yescaptcha"，RecaptchaV3TaskProxylessM1S9
• Flow 前端版本 boq_labs-ai-sandbox-frontend_20261007.14_p0
• 账号类型 Pro，已灰度 Nano Banana 2.1（nb21）
• 浏览器侧对照：Chrome 154（Windows）

说明

抓包得到的 HAR 中含有 Cookie、reCAPTCHA token 等敏感信息，以上只摘录了结构，没有附原始文件。