OpenClaw Bug：Vertex Gemini 3.1 Pro Preview 在 2026.4.5 中返回空白回复
OpenClaw News 编辑部
社区最新反馈指出：在 OpenClaw 2026.4.5 中使用 google-vertex/gemini-3.1-pro-preview 时，运行流程看起来会“正常结束”，但最终写入的 assistant 回复却是 空字符串。
这个问题麻烦的点不在于“报错很响”，而在于它不够响：
- 请求确实打到了 Vertex AI
stopReason会被记录为stop- 看起来不像典型 provider crash
- 但 assistant 文本为空，output tokens 还是
0
如果你在生产或半生产环境里跑 OpenClaw，这类问题特别容易把人带偏：团队会优先怀疑 GCP 鉴权、配额、区域，但 issue 里的交叉验证又显示，同环境下 Vertex Playground 是能跑通的。
- 上游来源： openclaw/openclaw#62027
TL;DR
如果你在 OpenClaw 2026.4.5 里使用 google-vertex/gemini-3.1-pro-preview，结果总是空白回复：
- 先确认模型确实是
google-vertex/gemini-3.1-pro-preview。 - 检查该次运行是否满足：
stopReason=stop、assistant 文本为空、output tokens = 0。 - 用同环境下的 google-vertex/gemini-3-flash-preview 或 Vertex Playground 做一次交叉验证。
- 如果交叉验证正常，就别先把时间都浪费在 IAM、配额或网络排查上。
- 在上游给出明确修复前，优先采用低风险绕过方案。
这个 bug 的实际表现
根据 issue 描述，问题路径大致是这样：
- provider：
google-vertex - model：
gemini-3.1-pro-preview - OpenClaw 版本：
2026.4.5 - 结果：请求到了 Vertex AI，但 assistant 回复被保存成空字符串
- 记录状态：
stopReason: stop、output tokens: 0
这组信号很关键。
因为如果是 provider 明确拒绝请求，通常会更容易排查：你至少能拿到一条直观错误。而这里更像是“成功完成，但没有可用文本输出”，对运维来说反而更难处理。
如何确认你撞到的是这个问题
建议按下面顺序做，避免排错方向跑偏。
1）先确认它不是“整个 Vertex 都坏了”
该 issue 给了两个非常有价值的对照条件：
- Vertex Playground 可以正常使用 Gemini 3.1 Pro
- 同一个 OpenClaw 安装里，google-vertex/gemini-3-flash-preview 可以正常工作
如果你的环境也呈现出同样分裂：Flash 正常、Playground 正常、只有 3.1 Pro Preview 在 OpenClaw 里空白，那么它更像是 OpenClaw 对该模型的运行时处理问题，而不是一场通用的 Vertex 故障。
2）查看 OpenClaw 的会话结果
重点找满足以下条件的那次运行：
- provider 是
google-vertex - model 是
gemini-3.1-pro-preview - assistant 文本是
"" stopReason是stop- output tokens 是
0
如果这几项都成立，和 issue 的重合度就很高。
3）只换模型，再跑一次对照测试
最务实的做法，是保持其余条件不变，只替换模型：
- 同一个 OpenClaw 安装
- 同一套 Vertex 鉴权
- 同一区域
- 同一个 prompt
- 改测
google-vertex/gemini-3-flash-preview
如果 Flash 正常吐字，而 3.1 Pro Preview 继续空白，那么你就更有理由把问题定位到 OpenClaw 对该模型的处理链路，而不是基础设施层。
为什么这事不只是“一次回答为空”
空白回复的问题，实际破坏面比表面大。
常见后果包括：
- 聊天流程看起来像“模型没说话”，但没有明确错误
- 自动化任务把空字符串误当成合法结果继续往下跑
- 运维人员不断轮换密钥、查配额、换区域，白白烧时间
- 因为运行以
stop结束，监控层不一定会把它识别为失败
换句话说，这不只是质量问题，它还会变成 可观测性和故障响应 问题。
现阶段最稳妥的绕过方案
按风险从低到高讲。
方案 A：先把受影响工作流切到邻近可用模型
如果你的场景今天并不强依赖 Gemini 3.1 Pro Preview，本阶段最简单的解法是把对应工作流暂时切到已知能正常出字的 Vertex 模型，例如：
google-vertex/gemini-3-flash-preview
这是最稳的办法，因为不需要改网关代码，也不需要改鉴权体系。
方案 B：先用 Vertex Playground 复现一次，再停止在 IAM 上兜圈子
很多团队看到空输出，会本能地先查权限、配额和区域。
但如果同样的 prompt 在 Vertex Playground 里可以正常返回文本，而 OpenClaw 里却被记成空回复，那么这条证据本身就很重要：它能帮你尽早停止在下面这些方向过度投入：
- 反复轮换凭证
- 盲猜配额问题
- 不断切区域
- 排查无关的网络或防火墙
方案 C：在上游明确修复前，不要把这个模型放进无人值守流程
如果你依赖定时任务、自动总结、客服对话或其他无人值守场景，那么“成功但空白”的模型输出是危险的，因为它不像硬错误那样容易被告警抓到。
在上游 issue 明确前，建议避免把这个模型用于：
- cron 驱动任务
- 面向用户的聊天链路
- 总结/汇总流水线
- 任何会把空输出当成合法结果的自动化流程
上游大概率需要澄清什么
就目前 issue 提供的信息看，这不像是“Vertex 根本没回”，更像是“OpenClaw 在完成运行时没有正确提取或保存可用文本”。
后续上游大概率需要检查这些层面：
- google-vertex provider 对 Gemini 3.1 Pro Preview 的响应解析
- 该模型返回结构是否和旧模型不完全一致
- token / candidate 提取逻辑是否对 preview 模型存在分支遗漏
- 某种“无文本 candidate”是否被误判为成功完成
什么时候才算真的修好
后续如果上游发了修复，不要只看“没崩”。要针对这次坏掉的核心症状复测：
- assistant 文本不再为空
- output tokens 大于
0 - 回复能正常进入 OpenClaw 聊天历史
- 重复测试时表现稳定，不是偶发空白
常见判断问题 FAQ
如果 stopReason=stop，为什么还不能把这次运行当成功？
因为这类故障的关键不在“流程有没有结束”，而在“有没有产出可用 assistant 文本”。
如果最终结果同时满足：
stopReason=stop- assistant 文本为空
output tokens = 0
那更像是 成功收尾但没有有效输出，而不是一次真正可交付的模型完成。
什么时候更该先做模型对照，而不是继续查 IAM / 配额 / 区域？
如果同环境下的 Vertex Playground 正常，同安装里的 google-vertex/gemini-3-flash-preview 也正常，而只有 gemini-3.1-pro-preview 为空，那就更该先做模型对照结论，而不是继续把时间砸在 IAM、quota 或 region 上。
这种分裂现象本身，就是很强的“问题不在基础设施层”的证据。
搜 gemini 3.1 pro preview empty reply 的人，页面最该先帮他分哪三个支路？
最该先分这三个：
- 是所有 Vertex 模型都空，还是只有 3.1 Pro Preview 空
- 是真的 provider 报错，还是
stop结束但正文为空 - Vertex Playground 在同环境下能不能正常回字
这三步最能帮助用户快速从“广义 Vertex 故障”收缩到“OpenClaw 对特定 preview 模型的处理问题”。
下一步优先覆盖的精确 Vertex Gemini 空回复搜索词
当读者从 Gemini 3.1 Pro Preview 或 Vertex AI 的窄搜索进入这里，先把 blank assistant turn 和普通延迟、quota、prompt 问题分开。
- Google Vertex Gemini 3.1 Pro Preview empty assistant reply：重试前先保存原始 provider response，确认 candidates、parts 或 finish reasons 是否缺失。
- Vertex Gemini returns empty response in OpenClaw 2026.4：用同一 prompt 对比另一个 Gemini model，区分 preview model 行为和 OpenClaw adapter 处理问题。
- fix Gemini 3.1 Pro Preview blank response OpenClaw：先 pin 到已知可用模型，或把受影响任务从 preview 路由移走，直到 adapter 能保留足够诊断信息。
从 empty reply 流量转成证据化排查
如果你是因为 Google Vertex Gemini 3.1 Pro Preview 返回空 assistant reply 搜到这里，先不要只重试同一个 prompt。要把问题拆成三层证据：模型 API 是否返回候选、OpenClaw runtime 是否吞掉内容、以及 channel adapter 是否把空消息当成成功投递。
最小排查路径是保存一次原始响应、一次 runtime trace、一次最终 channel payload，并记录模型名、region、请求时间和 safety/finish reason。只有三层证据都显示内容为空时，才把它归为上游模型问题；否则优先修解析、降级路由或空回复兜底。
切换模型前，先做空回复分层排查
如果你是搜“Gemini 3.1 Pro empty assistant reply”或“Vertex AI returns blank response in OpenClaw”来到这里，第一轮先把它当成 response shape 问题排查，不要立刻换模型。建议顺序是：
- 在 OpenClaw 归一化之前，先抓原始 Vertex response body、status code 和 finish reason；
- 对比同一条 prompt 在 Vertex console、直接 API 调用和 OpenClaw runtime 里的返回是否一致；
- 检查 safety ratings、candidate filtering、tool-call output 或 streamed chunks 是否被 adapter 丢掉；
- 用更短 prompt、关闭工具调用重试一次，区分是上下文压力还是 provider 行为；
- 只有确认空回复属于 provider 侧、adapter 侧，还是特定 prompt shape 后，再把流量切到 fallback model。
这能保住高意图 Gemini 排障流量：先给操作者一条安全诊断路径，再决定是否轮换凭据、降级模型，或暴露底层 adapter bug。
相关阅读
- OpenClaw Bug: Google usageMetadata is not mapped into usage.input/output on Gemini Code Assist and CLI flows
- OpenClaw Bug: ACPX 0.4.x may fail to create sessions silently even though the MCP stream comes up
- OpenClaw Bug: ACP Session transcripts may exist on disk while session history APIs still return empty
生产告警规则：不要只等用户发现空白气泡
如果这篇已经被你放进事故手册，下一步就该把症状变成告警，而不是等值班同学肉眼发现聊天气泡为空。第一条规则可以很窄：model 等于 google-vertex/gemini-3.1-pro-preview，finish reason 等于 stop，assistant 文本长度为 0，output tokens 也是 0。
这条规则故意不要写得太宽。它不会把普通 provider 报错都打成同一个告警，但能抓住最危险的情况：OpenClaw 把运行记成完成，下游自动化却拿不到任何可用答案。
如果这条链路价值更高，建议再给事件补两个标签：
- 同一时间窗口里，其他 Vertex 模型是否能正常返回文本；
- 原始 Vertex 响应里到底是有 text parts、有非文本 parts，还是完全没有 candidate 文本。
这两个标签能把后续排查直接拆成三类：provider 整体故障、特定模型响应结构变化、OpenClaw 组装 assistant message 的链路问题。
Sources
- 社区 bug 报告： openclaw/openclaw#62027
值班时的快速决策树
如果你在值班窗口里看到 Gemini 3.1 Pro Preview 返回空 assistant reply，不要先把它当成普通模型超时。更稳的分流顺序是：
- HTTP 请求成功，但 assistant 内容为空
- 优先怀疑 provider 响应映射、finish reason 或空内容归一化链路，而不是先把锅甩给网络。
- 先保留原始响应体，再对比 OpenClaw 最终落下来的 assistant 内容。
- 只有 Vertex Gemini 3.1 Pro Preview 出现，其他模型正常
- 先把它当成模型或 provider 适配边界问题，不要误判成整个对话系统都坏了。
- 切到其他 Gemini / OpenAI / Anthropic 后恢复正常
- 先用切流止血，再确认是不是这个特定 preview 型号的兼容性回归。
宣布问题收口前，还要补验什么
即便你已经让回复重新出现，也别只看一次成功样本就结束。至少还要补验这四件事：
- 同类 prompt 重复执行多次后，assistant reply 都稳定非空，不再出现间歇性空白；
- 原始 provider 响应、OpenClaw 归一化结果和最终展示层内容三者一致；
- 回退模型或兼容性补丁不会顺带破坏 usage、tool calls 或多轮上下文；
- 事故记录里已经保存空响应样本、受影响模型版本、临时绕过方案和恢复条件。
相关阅读
- OpenClaw Bug：Gemini Token 统计全是 0（如何验证、影响点、临时绕过方案）
- OpenClaw Agents 排障指南：任务卡住、工具不回、结果异常时先查什么
- OpenClaw Core Schema 与官方 Feishu 插件不兼容时，为什么消息会过不去、该先查哪里
- OpenClaw 完整安装指南：自托管搭建、检查点与常见坑
搜索入口分流：Gemini 返回空 assistant reply 先看什么
如果你是从 “Gemini empty assistant reply”、“Vertex Gemini 3.1 Pro 空回复” 或 “OpenClaw Google provider no content” 搜到这里，先把问题拆成四层：
- 确认是模型空内容还是 provider 映射空内容：检查原始 Vertex 响应里是否有 candidates、finish reason、safety 或 tool call。
- 确认 usageMetadata 不等于可读文本：有 token 统计只说明请求被处理，不代表 assistant message 已被正确组装。
- 确认安全/截断/多模态字段：空文本可能来自 safety block、candidate parts 结构变化，或只返回非 text part。
- 保留原始响应样本：比起只贴“空回复”，保留 provider、模型版本、request id、candidate parts 更容易定位。
这类问题不要只在 UI 层补兜底文案。最短路径是同时验证 Vertex 原始响应、OpenClaw provider mapping、最终 assistant message 三段是否一致。
