Google on KnightLi的博客

Gemini 3.5 Flash 和 Gemini Omni 怎么免费用：普通用户与开发者入口整理

Wed, 20 May 2026 23:13:35 +0800

Google 发布 Gemini 3.5 Flash 和 Gemini Omni 后，最实际的问题不是 benchmark，而是普通用户和开发者到底怎么用，哪些入口免费，哪些入口只是低门槛试用。

先说结论：

想聊天、写作、看图、日常问答：优先用 Gemini app。
想测试 Gemini 3.5 Flash 参数、提示词和多模态输入：用 Google AI Studio。
想写程序调用 Gemini 3.5 Flash：用 AI Studio 生成 API key。
想在终端里免费试用：可以看 Gemini CLI。
想体验 Gemini Omni 的视频编辑：优先看 Gemini app 和 Google Flow。
想做正式生产：不要依赖免费额度，应该转到付费 API 或 Vertex AI。

注意：免费额度、地区开放、订阅层级和模型下拉菜单会随时间变化。本文写作时间是 2026 年 5 月 20 日，正式使用前要以 Google 当前页面为准。

Gemini 3.5 Flash 免费用法一：Gemini app

最简单的入口是 Gemini app：

https://gemini.google.com/

使用方式很直接：

打开 Gemini。
登录 Google 账号。
在模型选择里找 3.5 Flash。
直接开始对话。

这个入口适合普通用户。你可以用它做写作、总结、图片理解、文件内容分析、日常问答和简单规划。根据公开报道，Gemini 3.5 Flash 已面向全球用户开放，并可在 Gemini 的模型下拉菜单中选择。

限制也很明确：免费用户通常会有每日消息数量、地区和功能限制。如果超过限制，就需要等待额度刷新或升级订阅。

Gemini 3.5 Flash 免费用法二：Google AI Studio

如果你不是只想聊天，而是想调提示词、看参数、测试结构化输出，Google AI Studio 更合适：

https://aistudio.google.com/

基本流程：

登录 Google AI Studio。
新建 prompt。
在模型下拉菜单里选择 gemini-3.5-flash。
输入提示词并运行。

AI Studio 的好处是控制能力更强。你可以调温度、系统指令、结构化输出、多图输入，还能把测试好的提示词导出成代码或 API 调用。

对开发者来说，AI Studio 是免费的试验台。先在这里把提示词和输入格式调好，再进入 API 接入，会少浪费很多额度。

Gemini 3.5 Flash 免费用法三：免费 API key

开发者最关心的是 API。AI Studio 可以创建 Gemini API key，用来调用 gemini-3.5-flash。

基本流程：

打开 Google AI Studio。
找到 Get API key。
选择或创建项目。
创建 API key。
把 key 保存到本地环境变量。

Python 示例：

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="用三句话解释 Gemini 3.5 Flash 适合什么场景。"
)

print(response.text)

Node.js 示例：

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "用三句话解释 Gemini 3.5 Flash 适合什么场景。"
});

console.log(response.text);

curl 示例：

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"Hello Gemini 3.5 Flash"}]}]}'

公开资料显示，AI Studio 免费层通常会给 Gemini Flash 模型一定的每日请求额度。不同时间、地区和账号状态可能不同，常见说法包括每天约 1,500 次请求、每分钟请求数限制和 token 限制。不要把这些数字写死进生产计划，正式上线前要查看 Google AI 当前定价和限制页面。

Gemini 3.5 Flash 免费用法四：Gemini CLI

如果你喜欢命令行，可以看 Gemini CLI。它适合临时脚本、代码库摘要、文件读取和终端里的快速问答。

安装方式通常是：

`1`	`npm install -g @google/gemini-cli`

然后运行：

gemini

CLI 更适合个人开发者日常使用，不适合生产集成。生产环境还是应该使用 API key、服务账号、权限控制和可审计的调用方式。

Gemini Omni 免费或低门槛用法：Gemini app 和 Google Flow

Gemini Omni 是面向视频创作和编辑的多模态模型。它的核心能力不是普通文本问答，而是用自然语言多轮修改视频，并引用图像、文本、视频、音频等输入。

Google DeepMind 页面给出的入口包括：

Gemini app。
Google Flow。
YouTube Shorts。

页面也说明，需要 Google AI 订阅，功能会因订阅层级和地区不同而变化。因此，Gemini Omni 的“免费用法”要更谨慎理解：有些入口可能允许免费用户看到或试用部分能力，但完整视频编辑能力可能需要订阅、地区开放或产品灰度。

如果你只是想体验，建议按这个顺序试：

先打开 Gemini app，查看是否有 Gemini Omni 或相关视频编辑入口。
再打开 Google Flow：https://flow.google/
如果你做短视频内容，再关注 YouTube Shorts 里是否出现 Omni 相关编辑能力。

如果入口不可见，通常不是你操作错了，而是账号、地区、订阅层级或灰度范围暂时不满足。

Gemini Omni 适合怎么用

Gemini Omni 更适合创作者，而不是普通聊天。

你可以尝试这些方向：

上传或选择一段视频，让它改变风格。
让视频中的某个动作变得更夸张。
用一张参考图替换场景里的物体或角色。
分多轮修改镜头、动作、环境和风格。
把草图、参考图、音频或视频组合成一个新输出。

提示词可以写得像给剪辑师提要求：

`1`	`保持原视频的人物和房间结构不变，把镜子触碰后的效果改成液体波纹，动作要自然，光线不要突然变化。`

多轮编辑时，不要一次塞太多要求。更稳妥的做法是：

先改主体动作。
再改风格。
再改镜头角度。
最后调节声音、文字和节奏。

这样更容易保持一致性，也更容易定位是哪一步出了问题。

免费使用时最容易踩的坑

第一，免费额度不是生产额度。免费 API key 适合测试、个人工具和原型，不适合承诺稳定服务。

第二，不要把敏感数据发到免费或第三方入口。尤其是未公开代码、客户资料、合同、密钥、财务表格和内部文档。

第三，注意数据使用设置。免费层可能有不同的数据使用策略，使用前要查看 AI Studio 或 Google 账号里的相关设置。

第四，视频能力通常比文本能力更受限。Gemini Omni 这类视频编辑功能可能受订阅、地区、排队、时长、分辨率和内容安全策略影响。

第五，第三方“无限免费 API”要谨慎。很多网关会限速、转发请求、记录日志，甚至要求不透明的支付方式。敏感任务不建议走这类入口。

应该选哪个入口

如果你是普通用户：

Gemini 3.5 Flash：用 Gemini app。
Gemini Omni：先看 Gemini app，再看 Google Flow。

如果你是创作者：

用 Google Flow 体验 Omni 视频工作流。
用 Gemini app 做脚本、分镜、提示词和素材说明。

如果你是开发者：

用 AI Studio 调试提示词。
用 API key 接入 gemini-3.5-flash。
用 Gemini CLI 做个人终端工作流。
生产环境考虑 Vertex AI 或付费 API。

如果你是企业：

不要依赖免费额度。
重点看权限、日志、审计、数据驻留、合规和密钥管理。
视频生成和编辑还要补充水印、内容审核和版权流程。

小结

Gemini 3.5 Flash 的免费使用路径比较清楚：Gemini app、Google AI Studio、AI Studio API key、Gemini CLI 都可以作为低门槛入口。它适合聊天、写作、编程、Agent 原型和多模态测试。

Gemini Omni 的重点是视频编辑和多模态创作，入口主要在 Gemini app、Google Flow 和 YouTube Shorts，但完整能力更可能受订阅和地区限制。它适合创作者先做体验和概念验证，不适合一开始就按稳定生产服务来规划。

最稳妥的策略是：文本和代码任务先用 Gemini 3.5 Flash 免费层试通；视频创作先用 Gemini Omni 在 Gemini app 或 Flow 里验证效果；真正要上线，再转向可审计、可计费、可控权限的正式方案。

参考来源：

Gemini Omni 是什么？Google AI 视频多轮编辑模型完整解析

Wed, 20 May 2026 23:11:58 +0800

Google DeepMind 公布了 Gemini Omni 页面。它的定位很直接：从任意输入创作内容，当前重点从视频开始。

如果说 Nano Banana 更偏向图像生成和编辑，那么 Gemini Omni 更像是面向视频的多模态编辑模型。用户可以通过自然语言一步步修改视频，让后一次修改建立在前一次修改之上，并尽量保持场景、人物、动作和画面逻辑的一致性。

项目页面：https://deepmind.google/models/gemini-omni/

它解决的核心问题

传统视频编辑往往需要时间线、图层、遮罩、关键帧、调色、音轨和大量手动操作。AI 视频生成工具虽然可以从提示词生成片段，但经常存在两个问题：

一次生成后不容易精细修改。
多轮修改时人物、场景、风格和动作容易漂移。

Gemini Omni 想解决的是第二步：不是只生成一个视频，而是让用户像和剪辑师沟通一样，持续提出修改要求。

页面给出的说法是，它可以通过自然、分步骤的对话编辑任何视频。每次编辑都建立在前一次结果上，目标是保持一个连贯、统一的场景。

主要能力

Gemini Omni 的能力可以分成几类。

第一类是自然语言视频编辑。用户可以直接要求模型改变视频里的审美风格、动作或特效。例如让镜子像液体一样泛起波纹，让人物变成线稿、毛毡玩偶、透明全息线框，或者让整个环境变成 3D voxel art。

第二类是重构动作。它可以改变视频中发生的事情，例如放大手部形成的孔洞、让玩具发出对应动物声音、让建筑灯光随音乐点亮。

第三类是基于参考图像编辑真实视频。用户可以给出图像参考，再要求模型把某种建筑、太阳、飞行器或其它物体放进真实视频场景里。

第四类是多轮编辑保持一致性。页面展示了把小提琴手移动到参考图像环境、让小提琴消失、再把镜头改成越肩角度的连续编辑流程。这比一次性提示词更接近真实创作过程。

第五类是多输入引用。Gemini Omni 可以把图像、文本、视频、音频等输入整合成一个输出，支持风格迁移、动作迁移、角色替换、草图转视频等任务。

为什么它强调世界知识

Google 在页面里反复强调，Gemini Omni 不只是“画面变得真实”，而是结合 Gemini 的世界知识、物理直觉、历史、科学和叙事逻辑。

这点很重要。视频模型如果只追求画面质感，容易出现动作不合逻辑、物体关系混乱、文本和画面不同步的问题。Gemini Omni 的目标是让视频不仅看起来像，还要在故事、物理和语义上更连贯。

页面中的例子包括：

大理石在链式反应轨道上滚动。
用 claymation 解释蛋白质折叠。
用拟物化 stop motion 解释海马体工作方式。
让字母和画面里的物体对应出现。
让屏幕文字按节奏逐词出现。

这些例子说明它不是单纯的短视频特效工具，而是试图把知识表达、叙事和视听生成放在一起。

和 Veo、Flow、Nano Banana 的关系

从 Google 当前产品线看，Gemini Omni 更像是多模态创作和编辑能力的一层入口。

Veo 更偏视频生成模型本身，强调电影感视频和音频生成。Google Flow 是面向创作者的 AI 创意工作室，适合组织镜头、素材和视频项目。Nano Banana 更偏图像创建和细节编辑。Gemini Omni 则强调“从任意输入到一致输出”的多模态编辑，尤其是视频上的多轮自然语言控制。

简单理解：

想生成高质量视频：关注 Veo。
想在创作工作流里组织视频项目：关注 Google Flow。
想编辑图像：关注 Nano Banana。
想用对话方式修改视频，并引用图片、文字、视频、音频：关注 Gemini Omni。

使用入口

页面给出的入口包括：

Gemini app。
Google Flow。
YouTube Shorts。

不过页面也说明，需要 Google AI 订阅，功能会因订阅层级和地区而不同。也就是说，并不是所有用户在所有地区都能立即使用完整能力。

对创作者来说，最值得关注的入口可能是 Google Flow，因为它更接近完整创意工作台。对普通用户来说，Gemini app 和 YouTube Shorts 可能是更低门槛的体验入口。

安全和内容标记

Gemini Omni 页面专门提到安全流程。Gemini Omni Flash 的开发与内部安全、安全责任团队合作，并进行了自动化评估、人工评估、人工红队、自动化红队和发布前伦理安全审查。

内容透明度方面，页面说明通过 Omni 在 Gemini app、Google Flow 或 YouTube 创建或编辑的内容，会包含不可感知的 SynthID 数字水印和 C2PA Content Credentials。用户可以通过 Gemini app 验证内容，后续也会扩展到 Chrome 和搜索。

这部分对视频模型尤其关键。视频生成和视频编辑越真实，越需要内容来源标识、滥用防护和验证工具。

适合哪些人

Gemini Omni 适合几类用户：

想用自然语言快速修改视频的内容创作者。
需要把草图、参考图、音频、视频素材整合成成片的设计团队。
做短视频、广告概念、教育解释视频和产品视觉稿的人。
想在 Google Flow 中构建 AI 视频工作流的创作者。
关注多模态视频编辑能力边界的开发者和研究者。

但它也不一定适合所有场景。严肃商业片、品牌主视觉、影视制作、产品发布视频仍然需要人工审片、版权检查、事实校对和素材管理。AI 可以明显加速概念生成和初稿迭代，但不应替代最终审核。

怎么看 Gemini Omni

Gemini Omni 的意义在于，它把 AI 视频从“一次性生成”推进到“可对话修改”。这比单纯提升画质更接近真实创作流程。

如果它在多轮编辑、一致性、参考素材控制、音画同步和内容标记上表现稳定，AI 视频工具的使用方式会发生变化：用户不再只写一条长提示词赌结果，而是像导演、剪辑师、设计师一样，逐轮修改场景、动作、风格和叙事。

当前仍要看实际开放范围、价格、地区限制、生成时长、分辨率、版权策略和商用规则。对于普通创作者，最实用的观察点是：它在 Google Flow 和 Gemini app 里能不能稳定完成多轮视频修改。

参考来源：

Google DeepMind：Gemini Omni

Gemini 3.5 正式发布：Flash 先行，Google 把重点放在 Agent 和长任务执行

Wed, 20 May 2026 22:51:31 +0800

Google 在 2026 年 5 月 20 日正式发布 Gemini 3.5 系列。第一款开放使用的是 Gemini 3.5 Flash，定位不是单纯的聊天模型，而是面向 Agent、代码生成和长时间复杂任务执行的模型。

从这次公告看，Google 对 Gemini 3.5 的叙事很明确：模型不只要回答问题，还要能规划、执行、检查，并在多步任务中持续推进工作。

Gemini 3.5 Flash 先行

Gemini 3.5 Flash 已经面向多类用户开放：

普通用户可以通过 Gemini 应用和 Google 搜索中的 AI 模式体验。
开发者可以通过 Google Antigravity、Google AI Studio、Android Studio 中的 Gemini API 使用。
企业用户可以通过 Gemini Enterprise Agent Platform 和 Gemini Enterprise 使用。

Google 同时提到，Gemini 3.5 Pro 仍在开发中，已经在 Google 内部使用，计划在下个月推出。

这说明 3.5 系列会继续保留 Flash 与 Pro 的分层：Flash 更强调速度、成本和可规模化执行，Pro 则更可能面向更复杂、更高能力需求的场景。

重点是 Agent 和代码任务

Google 把 Gemini 3.5 Flash 称为目前最强的 Agent 与代码编写模型之一。公告中提到，它在多项代码和 Agent 基准测试中超过 Gemini 3.1 Pro 的部分成绩，例如 Terminal-Bench 2.1、GDPval-AA、MCP Atlas 和 CharXiv Reasoning。

这些指标本身不是普通用户最需要关心的内容。更重要的是，Google 正在把模型能力往“可执行工作流”上集中：不仅能写代码，还能处理旧项目迁移、复杂应用开发、财务报表整理、数据分析和持续测试。

在 Antigravity 开发架构中，Gemini 3.5 Flash 可以通过多个协作子代理处理大型任务。Google 展示的例子包括解析 AlphaZero 论文并实现可玩的游戏、把旧版代码转换为 Next.js、并行生成城市景观和 UI 方案。

这类能力的方向很清楚：AI 编程工具正在从“生成一段代码”走向“组织多个 Agent 完成一个项目”。

多模态 UI 与图形能力增强

Gemini 3.5 Flash 继承了 Gemini 3 的多模态基础。Google 强调它可以生成更丰富的网页 UI、交互动画和图形内容。

公告中给出的应用场景包括：

为研究论文生成交互式动画。
根据文字描述生成交互式硬件模型。
为学校募款活动生成完整品牌概念。
在短时间内为结账流程生成多种 UX 方案。

这部分对开发者和产品团队很有意义。模型不再只是输出文字说明，而是能参与前端原型、交互设计和可视化内容生成。

企业场景：把耗时流程自动化

Google 在公告中列举了多个合作伙伴案例。Shopify 使用子代理分析复杂数据并预测商家增长；Macquarie Bank 测试用 3.5 Flash 阅读超过 100 页的复杂文件，加速开户流程；Salesforce 将其整合到 Agentforce；Ramp 用它改进复杂发票 OCR；Xero 用 AI 代理处理行政流程；Databricks 用自动化工作流监控数据异常并给出修复建议。

这些案例共同指向一个趋势：企业采用大模型时，关注点正在从单次问答转向流程自动化。模型是否便宜、快、能长时间稳定执行，会比单次回答是否惊艳更重要。

Gemini Spark：个人 AI 代理

Google 还公布了 Gemini Spark。它是由 Gemini 3.5 Flash 驱动的个人 AI 代理，目标是在用户引导下长期运行并主动执行任务。

Gemini Spark 已经开始面向受信任测试人员推出，Google 计划在下周向美国 Google AI Ultra 订阅用户开放 Beta 测试。

这部分值得关注。Google 搜索、Gemini 应用、Android、Workspace 和浏览器生态本来就覆盖大量个人数字生活场景。如果个人 Agent 能与这些入口结合，影响可能比单独的聊天机器人更大。

安全机制继续前移

Google 表示 Gemini 3.5 按照 Frontier Safety Framework 开发，并强化了信息安全和 CBRN 相关防护。公告还提到使用可解释性工具，在模型给出回答前帮助检查和理解推理过程。

这说明前沿模型的发布已经不只是能力竞赛。越是强调 Agent、自动执行和长任务，安全控制、误拒率、有害输出防护和可解释性就越重要。

怎么看 Gemini 3.5

Gemini 3.5 Flash 的意义不只是“又一个新模型发布”。它更像是 Google 对下一阶段 AI 产品形态的集中押注：模型要能调用工具、拆分任务、协作执行、生成 UI，并进入个人和企业工作流。

对开发者来说，值得关注的是 Google Antigravity、AI Studio、Gemini API 和 Android Studio 中的实际体验。对企业来说，重点是它能否在真实流程中稳定减少人工操作，而不是只看 benchmark。

Gemini 3.5 Pro 还没有正式开放。等 Pro 发布后，Flash 与 Pro 在能力、价格、速度和上下文处理上的差异，才会决定它们各自更适合哪些生产场景。

参考来源：

Google Blog：Gemini 3.5 正式登场

Google Gemini Spark 爆料解读：一个 24 小时在线的 Gemini Agent 可能要来了

Sun, 17 May 2026 11:58:08 +0800

Google 还没有正式发布 Gemini Spark。

目前关于它的信息，主要来自 Gemini Web 内部测试界面、社区截图、TestingCatalog 报道，以及 36Kr / 新智元对相关爆料的整理。比较一致的说法是：Gemini Spark BETA 可能是 Google 正在准备的全天候 AI Agent，定位不再只是聊天助手，而是能在后台处理邮件、在线任务和多步骤工作流的“日常 AI 代理”。

所以这篇文章先把边界说清楚：这是爆料解读，不是 Google 官方发布稿。所有功能、命名和上线时间，都要等 Google 正式公告确认。

先说结论

从目前曝光的信息看，Gemini Spark 有三个重点：

它可能是 Gemini 体系里的 24 小时在线 Agent，而不是普通聊天模型。
它会调用更广泛的个人上下文，包括 Google 应用、聊天记录、任务、登录网站和位置信息等。
它的风险和吸引力一样大，因为它可能涉及信息分享、远程浏览器数据、购买动作和第三方服务调用。

如果 Google 真把 Spark 推出来，Gemini 的定位会发生变化：从“回答问题的 AI”变成“替你持续处理事务的 AI”。

Gemini Spark 是什么

TestingCatalog 在 2026 年 5 月 14 日报道，Google 正在 Gemini Web 中测试 Gemini Spark BETA。曝光的欢迎文案把它描述成一个 everyday AI agent，可以 24/7 帮用户处理 inbox、online tasks 和更多多步骤工作。

36Kr / 新智元的文章也提到，Spark 被扒出后，外界看到的是一个“全时 Agent”方向：它可以全天候待命，处理收件箱、执行在线任务，甚至可能涉及购买和信息分享。

这意味着 Spark 不是一个单纯的新模型名。它更像是 Gemini 产品层的一次升级：让 Gemini 从对话窗口里走出来，进入用户的邮件、网页、日程、任务和跨应用工作流。

它可能怎么工作

根据 TestingCatalog 披露的隐藏 onboarding 文案，Gemini Spark 会从多种来源获取上下文，包括：

Connected Apps。
skills。
chats。
tasks。
用户登录过的网站。
Personal intelligence。
location。

这些信息会帮助 Spark 理解用户想完成什么，并在执行任务时调用必要的上下文。文案还提到，为了完成某些动作，Gemini 可能会把必要信息分享给第三方，例如姓名、联系方式、文件、偏好，以及用户可能认为敏感的信息。

如果这些描述最终属实，Spark 的工作方式会更接近“带上下文的代理系统”，而不是一次性问答。它不是只看当前一句 prompt，而是可能综合长期偏好、连接应用、浏览器状态和任务历史。

为什么它重要

Gemini Spark 的关键，不在于多一个聊天入口，而在于 Google 有天然的生态入口。

OpenAI 和 Anthropic 可以做很强的 Agent，但它们很难天然拥有 Gmail、Calendar、Drive、Chrome、Android、Workspace 这条完整链路。Google 如果把 Spark 接进这些产品，用户不需要额外搭建太多工作流，就能让 Agent 进入日常事务。

这会带来三个变化。

第一，Gemini 会从被动问答变成主动执行。用户不再只是问“帮我总结这封邮件”，而是可能让它持续整理 inbox、追踪任务和执行后续动作。

第二，Agent 会更依赖个人上下文。它越懂你的邮件、日程、文件、浏览器状态和偏好，越可能给出有用结果。

第三，权限边界会变得更敏感。能做更多事，也意味着需要更清楚地知道它什么时候能做、能做到哪一步、是否需要确认。

风险点在哪里

TestingCatalog 披露的文案里，有几处很值得关注。

第一，Spark 是 experimental。也就是说，即便它上线，也不应被当成完全成熟、无需监督的系统。

第二，虽然系统设计上会在敏感操作前征求许可，但文案也提示，它可能会在未经询问的情况下分享信息或完成购买。

第三，为了保持会话连续性，Gemini 会保存 remote browser data，比如登录细节和 remote code execution data。用户可以在 Settings 中清除这些数据，也可以关闭 Connected Apps 和 Personal intelligence 相关能力。

这几个点合在一起，说明 Spark 的产品方向很激进：它要做真正能执行任务的 Agent，而不是只生成建议。但越接近真实执行，越需要严格的权限、审计、确认和回滚机制。

和 Remy、AI Ultra 的关系

TestingCatalog 提到，Spark 可能是此前内部代号 Remy 的 agentic Gemini upgrade 的重命名版本，也与面向 Google AI Ultra 订阅用户的 Gemini Agent 方向有关。

如果这个线索成立，Spark 可能不是凭空出现的新项目，而是 Google 把此前较高阶、较封闭的 Agent 能力重新包装，并准备推向更大范围用户。

36Kr / 新智元也把它描述成从 “Remy” 到 “Spark” 的升级：Gemini Agent 不再只是一个功能，而是要走向 24/7 的数字生活管家。

不过这仍然是基于爆料信息的判断。Google 是否会使用 Spark 这个正式名称、是否只面向 AI Ultra、是否推出更轻量订阅层，还要等官方确认。

MCP、skills 和工具生态

同一批社区截图里，还出现了 MCP Tool Testing 这类模型选择器入口。36Kr 文章认为，这可能暗示新 Gemini 会原生支持 MCP 第三方工具接入，Thinking 模式也会重构。

这条线索和 Spark 放在一起看，很有意思。

如果 Spark 只是“会聊天的助手”，skills 和 MCP 的意义有限。但如果 Spark 是一个长期运行的 Agent，它就需要可靠地调用工具、访问网页、执行任务、读写上下文，并把结果交付给用户。

也就是说，Spark 可能不是单点功能，而是 Google Agent 工具生态的一部分：模型负责理解和规划，skills / MCP / connected apps 负责执行和扩展。

对普通用户意味着什么

如果 Gemini Spark 真的发布，普通用户最直接的变化可能是：

邮件不只是被总结，而是可以被分类、跟进和转成任务。
网页任务不只是给建议，而是可能在远程浏览器中持续执行。
日程、位置、偏好和历史对话会变成 Agent 的长期上下文。
购买、预订、表单填写等动作可能进入 AI 执行范围。

这听起来很方便，但用户需要建立新的习惯：不再只看 AI 说了什么，还要看 AI 准备做什么、已经做了什么、能不能撤回、有没有记录。

未来 AI Agent 的体验好不好，可能不只取决于模型聪不聪明，还取决于权限提示是否清楚、任务日志是否可查、错误操作能不能恢复。

对开发者和团队意味着什么

对开发者来说，Spark 的意义在于 Google 可能正在把 Agent 从“演示产品”推向真实工作流平台。

如果 Spark 能稳定连接 Google 应用、第三方工具和浏览器状态，那么开发者会关心：

API 或扩展机制是否开放。
MCP 或 skills 是否可由第三方接入。
企业管理员能否控制权限、数据留存和审计。
Agent 执行失败时是否有可追踪日志。
是否支持沙盒、审批流和敏感操作确认。

对团队来说，Spark 可能会先从 Gmail、Calendar、Docs、Drive、Chrome 这类高频场景切入。它未必一开始就适合完全自动化高风险业务，但很适合作为 inbox triage、会议跟进、资料整理、市场研究和轻量运营任务的助手。

现在应该怎么看

这条消息适合用“高可信方向，低确定细节”来理解。

高可信方向是：Google 确实在推进更主动、更长期运行、更深度接入生态的 Gemini Agent。TestingCatalog 报道的 Gemini Web 测试文案、社区截图和 36Kr 整理的多方爆料，都指向同一个方向。

低确定细节是：正式名称、上线时间、权限规则、订阅层级、可用地区、是否开放 API、是否真的叫 Gemini Spark，都还不能下结论。

所以现在最稳妥的判断是：

不要把 Spark 当成已经发布的正式产品。
可以把它视为 Google 下一阶段 AI Agent 路线的强信号。
真正值得等的是官方如何解释权限、隐私、第三方数据分享和远程浏览器数据保存。

总结

Gemini Spark 如果最终发布，可能会是 Gemini 从聊天助手走向全天候 Agent 的关键一步。它不只是换一个模型，而是把 Gemini 放进 Google 生态的邮件、网页、任务、位置、个人智能和第三方服务里。

它的潜力很大：更主动、更贴近真实工作流，也更容易借助 Google 的生态分发给大量用户。它的风险也同样大：一旦 AI 能分享信息、保存浏览器状态、执行购买和调用第三方服务，权限边界就必须非常清楚。

所以 Gemini Spark 最值得关注的不是“它有多聪明”，而是 Google 准备怎样让一个 24 小时在线的 AI Agent 变得可控、可审计、可信任。

参考链接：

Gemini 3.5 Pro 曝光：代号 Cappuccino，谷歌想在编程和 Agent 上追回节奏

Sun, 17 May 2026 11:47:27 +0800

Google 还没有正式发布 Gemini 3.5 Pro。

目前能看到的信息，主要来自开发者社区截图、匿名跑分、爆料人消息和媒体转述。36Kr / 新智元在 2026 年 5 月 15 日整理称，新一代 Gemini 检查点内部代号可能是 Cappuccino，相关模型已经在社区和评测平台中提前曝光。

这类信息还不能等同于官方发布，但它透露出一个清晰方向：Google 正在试图同时补上两块短板，一块是编程和推理能力，另一块是全天候 AI Agent。

先说结论

这次爆料可以拆成三层来看：

Gemini 3.5 Pro 尚未正式发布，Cappuccino 更像是内部检查点或候选版本代号。
曝光信息显示，新 Gemini 在代码生成、SVG / 交互式 Web 生成、多模态输出上有明显提升。
Google 同步测试的 Gemini Spark，可能比模型本身更关键，因为它指向 24 小时运行的个人 AI Agent。

换句话说，这不是一条简单的“模型跑分新闻”。它更像是 Google 在 I/O 前释放出的产品路线信号：模型要追赶 GPT-5.5，Agent 要抢占用户工作流入口。

Cappuccino 是什么

36Kr 文章提到，网友 Lentils 放出的消息显示，代号 Cappuccino 的 Gemini 3.5 Pro 检查点已经开始产出。此前社区还在讨论 Gemini 3.2，但最新曝光直接跳到了 3.5。

如果这个命名最终属实，说明 Google 可能希望把下一代 Gemini 包装成一次更大的版本跃迁，而不是普通小版本更新。

需要注意的是，Cappuccino 现在仍应被视为爆料中的内部代号。它不等于 Google 已经公开上线的正式模型，也不代表最终发布名一定就是 Gemini 3.5 Pro。

编程能力为什么是焦点

这次爆料里最受关注的点，是新 Gemini 的编程能力。

36Kr 引述的社区截图和跑分信息显示，新模型在以下任务上表现更强：

生成 SVG 与视觉组件。
生成交互式 Web 应用。
处理动画、3D、可调参数面板等复杂前端输出。
逻辑推理和代码生成能力有所提升。

文章还提到，Abacus.AI CEO Bindu Reddy 转述的说法是，3.2 Flash 在编码和推理上接近 GPT-5.5 的水平，同时成本更低。另有媒体信源则认为，新款 Gemini 的整体性能大致追平 GPT-5.5，但未必能带来质变。

这也是为什么要谨慎看待“追平 GPT-5.5”这句话。它更像是不同爆料源和匿名评测中的相对判断，而不是 Google 官方给出的基准测试结论。

为什么 Google 急着补编程

AI 编程已经从开发者工具变成了大模型竞争的核心战场。

OpenAI 有 Codex，Anthropic 有 Claude Code。它们不只服务工程师，也在把产品经理、设计师、运营人员带进“自然语言生成可运行产品”的工作流里。

相比之下，Google 虽然有 Gemini 和 Antigravity，但在开发者心智里一直没有形成同等强度的默认入口。36Kr 文章也提到，Antigravity 在外部市场还没有真正突围，定价、额度提醒和体验稳定性都曾引发社区讨论。

所以新 Gemini 如果要证明自己，编程会是最直接的战场。它不一定只比拼“会不会写代码”，还要比拼能不能稳定产出完整界面、理解复杂需求、调用工具、修复错误并融入真实开发流程。

Spark 可能比 3.5 Pro 更重要

同一波爆料里，Gemini Spark BETA 也被扒出。

根据 TestingCatalog 等信息源的说法，Spark 的定位接近“全天候 AI Agent”：它可以处理收件箱、执行在线任务、管理多步骤工作流，并连接 Google 应用、技能模块、聊天记录、定时任务、登录网站、位置信息等上下文。

这意味着 Spark 不是一个普通聊天入口，而是一个可能长期在线、持续读取上下文并替用户执行任务的系统。

它的吸引力很明显：如果 Google 能把 Gmail、Calendar、Chrome、Android、Workspace 和 Gemini 串起来，Spark 会天然拥有 OpenAI 和 Anthropic 很难复制的分发优势。

但风险也同样明显。36Kr 文章提到，Spark 相关说明中出现了“可能在未经询问的情况下分享信息或完成购买”的表述。哪怕系统设计上会在敏感操作前征求许可，这类 Agent 仍然会带来隐私、授权边界和误操作风险。

这对普通用户意味着什么

如果你只是普通 Gemini 用户，这次爆料真正值得关注的不是模型名，而是三个变化：

第一，Google 可能会继续强化“生成完整结果”的能力。以前用户经常吐槽 Gemini 在视觉生成、SVG、前端页面上容易偷懒，如果新模型能一次给出多个完整方案，体验会明显改善。

第二，编程能力会继续下放到更轻量的模型。爆料里反复提到 Flash 版本在编码、推理和交互式生成上的提升，这意味着未来不一定只有 Pro 模型才能处理复杂任务。

第三，Agent 会变得更主动。Spark 如果发布，Gemini 可能不再只是回答问题，而是开始长期接管邮件、网页、购买、日程和跨应用任务。

这对效率是好消息，对权限管理则是新挑战。

这对开发者意味着什么

开发者更应该关注两个问题。

第一个问题是工具生态。36Kr 文章提到，社区从模型选择器里看到了 MCP Tool Testing 这类未公开入口。如果 Gemini 原生支持 MCP 或第三方工具测试，那么它会更容易接入开发者自己的工具链。

第二个问题是成本和稳定性。即便新 Gemini 在某些基准上追平 GPT-5.5，开发者最终还是会看三件事：实际代码质量、上下文稳定性、价格和额度是否可预期。

过去一年，AI 编程工具竞争已经证明，模型能力只是门票。真正让开发者留下来的，是能不能在日常项目里持续可靠地改代码、跑测试、读上下文、处理边界条件。

现在应该如何看待这条消息

这条消息适合用“强信号、弱确认”来理解。

强信号在于：多个社区线索都指向 Google 正在准备更强的新 Gemini，以及更主动的 Gemini Spark Agent。

弱确认在于：Gemini 3.5 Pro 还没有官方发布，Cappuccino 仍是爆料代号，所谓“追平 GPT-5.5”的说法也需要等 Google 官方基准、第三方评测和真实用户测试来验证。

所以现在最稳妥的判断是：

不要把它当成已发布产品。
可以把它当成 Google 下一阶段 Gemini 路线的提前预告。
重点关注 I/O 或后续官方活动中是否会确认模型命名、API 可用性、价格、上下文窗口、工具调用和 Agent 权限边界。

总结

Gemini 3.5 Pro / Cappuccino 的曝光说明，Google 可能正在为下一代 Gemini 做一次更强势的版本推进。它要补的不是单一能力，而是整个 AI 工作流：模型要更会写代码、生成界面和处理复杂推理，Spark 则要把 Gemini 推向全天候 Agent。

但在官方发布前，所有跑分和截图都只能作为线索。真正决定 Gemini 3.5 Pro 能否翻身的，不是代号是否好听，而是它能否在真实开发、真实办公和真实多步骤任务里稳定胜出。

参考链接：

Gemini Intelligence on Android 解读：Google 正在把手机变成主动式 AI 系统

Sun, 17 May 2026 09:13:32 +0800

Google 在 2026 年 5 月 12 日发布了《A smarter, more proactive Android with Gemini Intelligence》，介绍 Gemini Intelligence on Android。它不是一个单独的聊天 App，而是把 Gemini 能力放进 Android 系统、Chrome、Gboard、Autofill、widgets 和多设备体验里，让手机从“等用户点按钮”变成“能主动帮用户完成任务”的智能系统。

简单说，Google 想让 Android 从 operating system 走向 intelligence system。手机不只是打开应用、显示通知、运行设置，而是可以理解屏幕、应用、语音和个人上下文，在用户确认下完成更复杂的操作。

先说结论

Gemini Intelligence on Android 主要包含五个方向：

多步任务自动化：让 Gemini 在应用之间完成订车、购物、找资料等流程。
Chrome 智能浏览：在 Android 上总结网页、比较信息，并处理部分重复性网页任务。
Autofill 升级：结合 Gemini 和个人上下文，帮用户填写更复杂的表单。
Rambler：把自然口语整理成更清晰、更专业的文字消息。
自然语言小组件：用户用一句话描述需求，Android 生成自定义 widgets。

这些功能会从 2026 年夏天开始分批推出，先到部分 Samsung Galaxy 和 Google Pixel 手机，之后扩展到更多 Android 设备，包括手表、汽车、眼镜和笔记本。

多步任务自动化：从建议变成执行

Google 这次最重要的方向，是让 Gemini 帮用户跨应用完成多步任务。

原文举了几个例子：用户可以让 Gemini 订健身单车课程、从 Gmail 里找到课程大纲并把需要的书加入购物车，或者看到一张旅游宣传图后，直接让 Gemini 在 Expedia 上寻找类似行程。

这类能力的关键不只是“理解一句话”，而是要同时理解：

用户当前屏幕或图片里的内容。
用户授权范围内的应用信息。
下一步应该打开哪个应用。
哪些步骤可以自动执行。
哪些步骤必须停下来让用户确认。

Google 特别强调，Gemini 会在用户指令下行动，并在任务完成时停止，最终确认仍由用户控制。这说明它不是完全自动代理，而是带有人类确认环节的移动端 agent。

屏幕和图片上下文变得更重要

这次更新里，一个值得注意的变化是 screen context 和 image context。

以前手机助手更多依赖语音命令和应用内固定接口。Gemini Intelligence 则更强调“看见当前屏幕”。例如用户在备忘录里有一份购物清单，可以长按电源键唤起 Gemini，让它根据清单创建配送购物车。

这意味着 Android AI 不只是聊天机器人，而是在尝试理解用户眼前的操作环境。未来手机 AI 的竞争，可能不只是谁的模型回答更好，还包括：

能不能理解当前屏幕。
能不能跨应用执行。
能不能在后台跟踪任务进度。
能不能在关键节点可靠地让用户确认。

这也是移动端 AI 和网页聊天 AI 的重要区别。

Chrome 智能浏览：从搜索到网页任务代理

Google 表示，从 2026 年 6 月下旬开始，Android 设备会获得更智能的 Gemini in Chrome。

它可以帮助用户研究、总结和比较网页内容，也可以通过 Chrome auto browse 处理一些重复性网页任务，比如预约、预订停车位等。

这说明 Gemini in Chrome 不只是“网页摘要”功能，而是在向浏览器代理发展。浏览器本来就是用户完成网页任务的入口，如果 Gemini 能理解网页、填写信息、比较选项并执行部分步骤，Chrome 就会从浏览工具变成任务执行界面。

不过，这类功能也会面对几个现实问题：

网站结构复杂，自动操作容易失败。
表单、支付、登录和验证码等环节需要谨慎处理。
用户需要知道 Gemini 到底做了什么。
最终提交、付款或预订最好仍保留人工确认。

所以，真正的难点不只是模型能力，而是浏览器自动化、安全边界和用户信任。

Autofill：从自动填密码到自动填复杂表单

Autofill with Google 原本更多是密码、地址、付款信息等基础便利功能。现在 Google 想把它升级成更智能的表单助手。

原文说，借助 Gemini 的 Personal Intelligence，Android 可以用连接应用中的相关信息，自动填写更多复杂表单字段，包括 Chrome 里的表单。

这类能力很实用。移动端填写复杂表单一直很痛苦，屏幕小、字段多、经常需要从邮件、日历、聊天和文档里复制信息。如果 Gemini 能在用户授权下自动整理并填写，会节省很多时间。

但 Google 也强调，连接 Gemini 和 Autofill with Google 是严格 opt-in。也就是说，用户自己选择是否连接，之后也可以在设置里随时开关。

这点很重要，因为 Autofill 涉及个人资料、地址、账号、支付、工作信息和敏感表单。越是有用，越需要明确授权和可控退出。

Rambler：把口语变成可发送文本

Rambler 是这次更新里比较有意思的新功能。

Gboard 已经可以把语音转文字，但人说话时常常会有重复、停顿、语气词和自我修正。Rambler 的目标是把自然说话整理成更清楚、更适合发送的文本。

它适合这些场景：

你想快速口述一段消息，但不想逐字修改。
你说话时夹杂停顿、重复和语气词。
你需要把随口想法整理成更专业的短信、邮件或聊天内容。
你在多语言之间切换，希望系统理解上下文。

Google 还提到，Rambler 会清楚显示用户何时启用了它，音频只用于实时转写，不会被保存。这是对隐私和透明度的回应。

从产品角度看，Rambler 其实是把“语音输入”升级成“语音写作”。它不只是记录你说了什么，而是帮你把口语变成可发送的文字。

自然语言创建小组件

Gemini Intelligence 还会带来 Create My Widget。用户可以直接用自然语言描述想要的小组件，比如“每周推荐三份高蛋白备餐食谱”，系统就生成一个可以放在主屏幕上的自定义 widget。

这代表 Android 在尝试 generative UI：用户不再只从固定模板里选择小组件，而是描述自己想看的信息和展示方式。

如果这个方向成熟，手机主屏可能会变得更个人化。天气、日程、健康、通勤、饮食、学习、工作提醒，都可以变成按用户需求生成的动态模块。

不过，生成式 UI 也需要解决稳定性问题。小组件不是一次性聊天回复，而是长期显示在桌面上，必须可靠、可读、可配置，并且不能乱占屏幕空间。

Material 3 Expressive 与智能 UI

Google 还提到，Gemini Intelligence 会带来基于 Material 3 Expressive 的更新设计语言。

这部分不是单纯美化界面，而是让 UI 动画和交互更有目的感，减少干扰，让用户更专注于任务。换句话说，当 AI 开始主动处理任务时，界面需要清楚表达：

AI 正在做什么。
哪些步骤已经完成。
哪些地方需要用户确认。
用户如何取消或修改。

主动式 AI 如果没有清晰 UI，很容易让用户感到失控。所以设计语言本身也会成为 AI 产品体验的一部分。

可用性和节奏

根据 Google 原文，Gemini Intelligence 功能会从最新 Samsung Galaxy 和 Google Pixel 手机开始，在 2026 年夏天分批推出。之后会扩展到更多 Android 设备，包括手表、汽车、眼镜和笔记本。

这说明它不是一次性全球全量上线，而是分批 rollout。具体可用性可能取决于设备、地区、语言、应用支持和账号设置。

如果你想体验这些功能，最现实的预期是：

先关注 Pixel 和 Samsung 旗舰机。
关注 2026 年夏季后的系统更新。
留意 Gemini、Chrome、Gboard、Autofill 和 Android 设置中的新开关。
不同地区和语言可能不会同时支持所有功能。

这对 Android 意味着什么

Gemini Intelligence on Android 的意义，不是又加了几个 AI 小功能，而是 Android 产品定位的变化。

过去的手机系统主要负责管理应用、通知、权限、文件和硬件。现在 Google 想让系统理解用户意图，并在应用之间完成任务。这个方向如果成功，Android 的竞争点会从“系统功能和生态应用”扩展到“能不能主动帮用户做事”。

这也会让移动端 AI 竞争进入新阶段：

Apple 会强调本地化、隐私和系统整合。
Google 会强调 Gemini、搜索、Chrome、Android 和多设备生态。
第三方 AI App 会更难和系统级入口竞争。
应用开发者需要考虑自己的 App 如何被 AI 代理调用。

未来几年，手机上的 AI 可能不再只是一个聊天入口，而是变成系统级执行层。

总结

Google 这次发布的 Gemini Intelligence on Android，核心不是“手机里多了一个 Gemini 聊天框”，而是把 AI 放进 Android 的操作流程里。多步任务自动化、Chrome 智能浏览、Autofill、Rambler 和自然语言小组件，都是在让手机从被动工具变成主动助手。

它能不能真正改变用户习惯，取决于几个关键因素：自动化是否可靠、隐私开关是否清楚、跨应用操作是否顺畅、用户是否始终保留最终控制权。至少从这次发布看，Google 已经把 Android 的下一阶段定义为主动式 AI 系统，而不只是传统移动操作系统。

参考链接：

Google Blog：A smarter, more proactive Android with Gemini Intelligence

Gemini Embedding 2：把文本、图像、视频和音频放进同一个向量空间

Mon, 04 May 2026 06:01:10 +0800

Google Developers Blog 介绍了 Gemini Embedding 2 的开发用法。这个模型已经通过 Gemini API 和 Gemini Enterprise Agent Platform 进入 GA，重点不只是“新的 embedding 模型”，而是把文本、图像、视频、音频和文档映射到同一个语义空间。

这会让检索系统的边界变宽：过去很多 RAG 流程需要先把图片、视频、音频拆成文字或元数据，再单独建索引；Gemini Embedding 2 则可以直接处理多模态输入，让代理、搜索和分类系统更容易围绕真实业务材料工作。

原文链接：Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

模型能力

Gemini Embedding 2 支持 100 多种语言。单次请求可以处理：

最多 8,192 个文本 token
最多 6 张图片
最多 120 秒视频
最多 180 秒音频
最多 6 页 PDF

它的关键点是“统一语义空间”。开发者可以把不同模态的内容放在同一套向量表示里，用同一种检索、聚类或重排序逻辑处理。

例如，文本描述和图片可以放在同一次 embedding 请求里：

from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

如果你希望每个输入分别得到 embedding，而不是聚合成一个向量，可以使用 Batch API。原文也提到，Agent Platform 对这类批量支持还在跟进中。

对 RAG 的意义

多模态 embedding 对代理式 RAG 很有用。一个 AI agent 可能需要同时检查代码仓库、PDF、截图、图表、音频会议记录和产品图片。如果所有资料都能进入同一个语义空间，检索链路就不必为每种材料单独设计一套入口。

Google 建议根据任务使用 task prefix，让 embedding 更贴近检索目标。例如问答、事实核查、代码检索和搜索结果，可以使用不同前缀：

# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

这种前缀适合非对称检索：用户查询往往很短，文档内容往往很长。把 query 和 document 分别按任务格式整理，可以改善短查询到长文档之间的匹配。

原文给了两个落地反馈：

Harvey 在法律检索基准上，Recall@20 precision 相比上一代 embedding 提升 3%。
Supermemory 在 Recall@1 搜索准确率上提升 40%，并把它用于记忆、索引、搜索和问答管线。

这些数字不代表所有场景都会同幅度提升，但说明多模态 embedding 已经不只是演示能力，而是在真实检索产品中产生效果。

视觉搜索

Gemini Embedding 2 也适合做以图搜图、图文混合搜索和商品识别。原文提到服装租赁公司 Nuuly 用它匹配仓库中未打标签的服装照片，使 Match@20 从 60% 提升到接近 87%，总体成功识别率从 74% 提升到 90% 以上。

这类场景的关键不是生成内容，而是理解“这张图片和哪个库存、文档或商品记录最接近”。如果你的业务里有大量图片、视频片段或扫描件，多模态 embedding 会比纯文本索引更自然。

检索重排序

Embedding 还可以用于 rerank。常见做法是先用基础检索拿到一批候选结果，再计算候选结果和用户查询之间的相似度，把更相关的内容排到前面：

# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

原文还提到一种思路：先让模型根据内部知识生成一个假设答案，再把这个假设答案做 embedding，与候选内容比较相似度，用来挑出语义更贴近的结果。这对问答型 RAG 尤其有用。

聚类、分类和异常检测

除了检索，embedding 也适合聚类、分类和异常检测。和前面的问答检索不同，这些属于对称任务，query 和 document 可以使用同一种任务前缀：

# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

这类任务可以用于舆情分类、内容审核、相似资产归类、异常样本发现，也可以帮助 agent 对大量上下文材料先做整理，再进入后续推理。

存储和成本

Gemini Embedding 2 默认输出 3,072 维向量。它使用 Matryoshka Representation Learning，因此可以通过 output_dimensionality 把向量截断到更小维度。Google 推荐在效率优先时使用 1,536 或 768 维：

result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

向量可以存到 Agent Platform Vector Search、Pinecone、Weaviate、Qdrant、ChromaDB 等系统里。成本方面，原文提到 Batch API 可提供更高吞吐，并达到默认 embedding 价格的 50%。

开发者该怎么用

如果你已有文本 RAG，可以先从两类增量改造开始：

把 PDF、截图、图片说明和文本文档放入同一个索引，测试查询召回是否更稳定。
给不同任务加 task prefix，例如问答、事实核查、代码检索、商品搜索，不要把所有内容都按同一种 embedding 方式处理。

如果你在做新产品，可以优先考虑这些方向：

企业知识库：同时检索文档、图表、演示稿截图和会议材料。
视觉搜索：用图片、文本或混合输入查找商品、资产、设计稿和档案。
Agent 工具链：让 coding agent、研究 agent 或客服 agent 检索多种格式的业务材料。
内容治理：对文本、图片、视频片段做统一分类、聚类和异常检测。

Gemini Embedding 2 的价值在于把多模态材料变成同一套可检索资产。对开发者来说，这会减少“先转文字再检索”的中间层，也让 RAG 系统更接近真实世界的数据形态。

Gemini 进入 Google built-in 汽车：车载语音助手开始变得更像真正的 AI 助手

Fri, 01 May 2026 06:09:57 +0800

Google 在 2026 年 4 月 30 日宣布，Gemini 开始进入搭载 Google built-in 的汽车，作为 Google Assistant 的升级版本陆续推送。

这件事的重点不只是“车里多了一个 AI 助手”，而是车载语音交互正在从固定命令，转向更自然的连续对话。用户不需要严格记住指令格式，可以像和普通助手交流一样，让 Gemini 帮忙导航、处理消息、查询车辆信息，甚至控制部分车内设置。

先从美国英语用户开始

根据 Google 的说明，这次更新会覆盖新车和已有车辆，前提是车辆支持 Google built-in，并且用户已经在车机里登录 Google 账号。

rollout 会先从美国英语用户开始，之后再扩展到更多语言和国家。符合条件的用户会在车内看到升级到 Gemini 的提示。升级后，可以通过以下方式唤起 Gemini：

说出 Hey Google
点击主屏幕上的麦克风
使用方向盘上的语音按钮

这说明 Google 没有把 Gemini 做成一个需要重新学习的新入口，而是延续原来的车载语音入口，只是把底层助手换成更强的 Gemini。

车载语音不再只靠固定命令

过去车载语音助手常见的问题是：能做的事不少，但用户必须说得很“标准”。一旦表达稍微复杂，助手就容易听不懂，或者只能执行最基础的动作。

Gemini 进入车机后，Google 强调的是自然对话能力。比如用户可以直接说：

I need to grab lunch, find some highly rated sit-down restaurants along the way. I’m not in a rush, oh, and I’d like to eat outside.

Gemini 会结合 Google Maps 找沿途合适的餐厅。用户还可以继续追问停车情况、是否有素食选项等，不需要重新发起一轮完整搜索。

这种交互更符合驾驶场景。人在开车时很难像使用手机一样反复筛选、点击和修改条件，语音助手如果能理解更完整的意图，就能明显减少分心。

地图、消息和音乐会变得更顺手

Google 给出的几个例子，基本都围绕驾驶时最常见的需求。

第一类是路线和地点搜索。

Gemini 可以根据 Google Maps 信息寻找沿途餐厅、景点或充电站，也可以回答和当前路线相关的问题。比如经过体育场附近时，用户可以问附近是否有活动、是否会影响交通。

第二类是消息处理。

用户可以让 Gemini 总结新短信，再根据上下文回复。比如让它回复朋友“我在路上，并附上预计到达时间”。如果临时想改内容，也可以继续补充，不必从头开始。

第三类是音乐和氛围。

用户不一定需要知道电台名或具体歌单，可以直接描述想听的内容。例如播放爵士电台，或者在 YouTube Music 里播放适合山路驾驶的欢快 70 年代 folk-rock，并跳过慢歌。

这些功能本身并不新，但 Gemini 的价值在于把多个条件合在一句自然语言里处理，而不是把用户逼回固定命令。

Gemini Live 让车里也能边走边聊

Google 还提到，Gemini Live 也会进入车载场景，目前处于 beta。用户可以点击 Gemini Live 按钮，或者说 Hey Google, let's talk 开始更自由的对话。

这类场景更像“开车时的陪伴式学习和头脑风暴”。例如开车去 Lake Tahoe 时，可以让 Gemini 讲当地历史和趣闻；听到感兴趣的内容后，可以随时打断追问。也可以让 Gemini 帮忙规划到达目的地后的徒步路线和活动安排。

这和传统车载助手的差异很明显。传统助手更像工具按钮，Gemini Live 则更像一个可以连续交流的语音界面。

车辆说明书和实时车况是关键差异

更值得注意的是，Gemini 不只是回答通用问题。Google 表示，他们和车厂合作，把 Gemini 更深入地接入车辆系统。

这带来几类更贴近汽车本身的能力。

第一，用户可以询问车辆功能。

比如“自动洗车前我应该怎么准备？”或者“我的车库天花板太低，后备箱门会碰到，怎么设置后备箱不要完全打开？”Gemini 会根据车厂提供的车主手册，给出适配具体车型的答案。不同品牌和车型能提供的信息细节会有所差异。

第二，电动车用户可以询问实时电量和续航。

例如当前电量、到达目的地时预计剩余电量，或者让 Gemini 查找附近充电站。它还可以结合 Google Maps，帮用户找充电附近的咖啡店等地点。

第三，部分车内设置可以通过自然语言调整。

Google 举的例子是用户说“车里又雾又冷”，Gemini 可以理解背后的意图，调高暖风并打开除雾。

这类能力比单纯把聊天机器人搬进车机更实际。汽车是一个有明确状态、硬件能力和安全边界的环境，AI 助手如果能理解车辆上下文，价值会比普通问答更高。

车载 AI 的边界也更重要

车内场景对 AI 的要求和手机、网页不同。

开车时用户不能频繁看屏幕，也不能花太多注意力纠正 AI。助手需要足够简洁、可靠，并且不能在关键场景里制造新的负担。

所以 Gemini 进入汽车并不意味着所有复杂任务都适合在车里完成。更合理的方向是：

降低导航和信息查询的操作成本
用自然语言替代多层菜单
帮用户快速理解车辆功能
在不分散注意力的前提下处理消息和媒体
给 EV 用户更顺滑的充电与路线信息

反过来，高风险操作仍然需要清晰边界。比如影响驾驶安全的设置、需要确认的消息发送、涉及车辆控制的动作，都应该有足够明确的确认流程。

小结

Gemini 进入 Google built-in 汽车，是 AI 助手从手机和网页继续向日常环境扩展的一步。

它的意义不在于车里终于可以“聊天”，而在于车载语音助手开始理解更复杂的意图，并能结合地图、消息、音乐、车辆说明书和部分车况信息来完成任务。

如果 rollout 顺利，车载语音交互可能会从“记住命令”逐渐变成“描述需求”。这对开车场景很重要，因为真正好的车载 AI，不应该要求驾驶者为它分配太多注意力。

参考链接：

Your car with Google built-in is about to get smarter, thanks to Gemini - Google Blog

如何调用 Google Nano Banana 做图片抠图

Thu, 09 Apr 2026 20:10:48 +0800

这篇文章用一段实际可运行的 Python 脚本，演示如何调用 Google 的 Nano Banana 图像编辑能力来做商品图抠图。

当前这份实现的目标很明确：

读取一个目录里的商品图片
调用 Google 图像模型执行背景移除
对返回图片再做一次本地透明背景清理
最终输出为透明底 PNG

如果你手里已经有一批白底商品图、耳机图、线材图，想快速生成电商可用的透明背景图，这种方式会很直接。

这段代码做了什么

这份脚本主要分成 4 个部分：

定义提示词，让模型知道要执行“去背景、保留主体、不要加阴影”
调用 google-genai 的图像生成接口
从模型响应中提取图片结果
再用本地逻辑把边缘浅色背景转成透明，减少残边

也就是说，它不是单纯把图片丢给模型就结束，而是把“模型编辑 + 本地后处理”串起来了。

运行前准备

先安装依赖：

`1`	`.\.venv\Scripts\python.exe -m pip install google-genai pillow`

如何获取 GEMINI_API_KEY

GEMINI_API_KEY 就是调用 Gemini API 时使用的密钥。根据 Google 官方 quickstart，如果你还没有 key，可以直接在 Google AI Studio 创建。

获取步骤如下：

打开 Google AI Studio。
登录你的 Google 账号。
找到 Get API key 或 API keys 页面。
创建一个新的 API key。
复制生成出来的 key。
把它配置到本地环境变量里，供脚本读取。

如果页面里还没有可用项目，通常需要先完成项目初始化，然后再回到 API Key 页面创建密钥。

拿到 key 之后，再配置环境变量：

`1`	`$env:GEMINI_API_KEY="your_api_key"`

如果你用的是 cmd，可以写成：

`1`	`set GEMINI_API_KEY=your_api_key`

如果你同时设置了 GEMINI_API_KEY 和 GOOGLE_API_KEY，实际运行时通常会优先读取 GOOGLE_API_KEY，所以建议只保留一个，避免混淆。

目录结构示例

脚本接收两个参数：

例如：

images/
  product1.jpg
  product2.png

output/

如何运行

假设脚本文件名是 cutout.py，运行方式如下：

`1`	`.\.venv\Scripts\python.exe .\cutout.py .\images .\output`

如果你想换模型，也可以显式传参：

`1`	`.\.venv\Scripts\python.exe .\cutout.py .\images .\output --model gemini-2.5-flash-image`

脚本会遍历输入目录中这些格式的文件：

.jpg
.jpeg
.png
.webp

处理完成后，会在输出目录中生成同名的透明底 PNG 文件。

核心调用流程

真正调用 Google Nano Banana 的关键代码在这里：

response = client.models.generate_content(
    model=model,
    contents=[PROMPT, image],
)

这里传入了两个内容：

一段文本提示词 PROMPT
一张 PIL.Image

提示词内容是让模型把整张商品图背景移除，只保留主体，并强调几件事：

保留完整商品
保留细线和线缆细节
清理内部空洞和环形区域
不要新增物体
不要添加阴影

这类提示词对抠图质量影响很大，尤其是耳机线、透明边缘、空洞区域这类细节。

为什么还要做一次本地后处理

模型返回结果后，脚本没有直接保存，而是又执行了 make_transparent_from_borders(image)。

这一步的思路是：

从图片四周边界开始找浅色背景像素
用广度优先搜索把连通的浅色区域全部标记出来
最后把这些区域统一改成透明

这样做的好处是可以进一步清掉一些残留白边、浅灰背景和不够干净的边缘区域。

判断“是不是背景”的条件在这里：

def is_light_background_pixel(r: int, g: int, b: int) -> bool:
    brightness = (r + g + b) / 3
    spread = max(r, g, b) - min(r, g, b)
    return brightness >= 170 and spread <= 35

简单理解就是：

颜色整体足够亮
RGB 三通道差异不能太大

这比较适合处理白底、浅灰底、接近纯色的商品图背景。

完整源码

下面保留当前这份完整源码，方便你直接复用或二次修改：

from __future__ import annotations

import argparse
import os
from pathlib import Path
from collections import deque

from PIL import Image

try:
    from google import genai
except ImportError as exc:  # pragma: no cover
    raise SystemExit(
        "Missing dependency: google-genai. Install it with "
        r"'.\.venv\Scripts\python.exe -m pip install google-genai'."
    ) from exc


PROMPT = (
    "Remove the entire background from this product photo and return only the product "
    "on a fully transparent background as a PNG. Keep the full product intact, preserve "
    "thin cable details, clean the inner loops and holes, and do not add any new objects "
    "or shadows."
)


def is_light_background_pixel(r: int, g: int, b: int) -> bool:
    brightness = (r + g + b) / 3
    spread = max(r, g, b) - min(r, g, b)
    return brightness >= 170 and spread <= 35


def to_pil_image(image_obj) -> Image.Image:
    if isinstance(image_obj, Image.Image):
        return image_obj
    pil_image = getattr(image_obj, "_pil_image", None)
    if isinstance(pil_image, Image.Image):
        return pil_image
    as_pil = getattr(image_obj, "pil_image", None)
    if isinstance(as_pil, Image.Image):
        return as_pil
    raise TypeError(f"Unsupported image object type: {type(image_obj)!r}")


def make_transparent_from_borders(image: Image.Image) -> Image.Image:
    rgba = image.convert("RGBA")
    width, height = rgba.size
    pixels = rgba.load()

    visited: set[tuple[int, int]] = set()
    queue: deque[tuple[int, int]] = deque()

    def push_if_bg(x: int, y: int) -> None:
        if (x, y) in visited:
            return
        r, g, b, _ = pixels[x, y]
        if is_light_background_pixel(r, g, b):
            visited.add((x, y))
            queue.append((x, y))

    for x in range(width):
        push_if_bg(x, 0)
        push_if_bg(x, height - 1)
    for y in range(height):
        push_if_bg(0, y)
        push_if_bg(width - 1, y)

    while queue:
        x, y = queue.popleft()
        for nx, ny in ((x - 1, y), (x + 1, y), (x, y - 1), (x, y + 1)):
            if 0 <= nx < width and 0 <= ny < height:
                push_if_bg(nx, ny)

    for x, y in visited:
        pixels[x, y] = (0, 0, 0, 0)

    return rgba


def save_first_image_part(response, dst: Path) -> None:
    parts = getattr(response, "parts", None)
    if parts is None and getattr(response, "candidates", None):
        parts = response.candidates[0].content.parts

    if not parts:
        raise RuntimeError("Model returned no content parts.")

    for part in parts:
        inline_data = getattr(part, "inline_data", None)
        if inline_data is None and isinstance(part, dict):
            inline_data = part.get("inline_data")

        if inline_data is None:
            continue

        if hasattr(part, "as_image"):
            image = to_pil_image(part.as_image())
            dst.parent.mkdir(parents=True, exist_ok=True)
            make_transparent_from_borders(image).save(dst)
            return

        data = getattr(inline_data, "data", None)
        mime_type = getattr(inline_data, "mime_type", "")
        if data:
            dst.parent.mkdir(parents=True, exist_ok=True)
            with open(dst, "wb") as handle:
                handle.write(data)
            with Image.open(dst) as img:
                processed = make_transparent_from_borders(img)
                processed.save(dst.with_suffix(".png"))
            if dst.suffix.lower() != ".png":
                dst.unlink(missing_ok=True)
            return

    raise RuntimeError("Model returned text only and no edited image.")


def process_image(src: Path, dst: Path, client, model: str) -> None:
    with Image.open(src).convert("RGBA") as image:
        response = client.models.generate_content(
            model=model,
            contents=[PROMPT, image],
        )
    save_first_image_part(response, dst)


def main() -> None:
    parser = argparse.ArgumentParser(description="Use Nano Banana / Gemini image editing to cut out product images.")
    parser.add_argument("input_dir", type=Path)
    parser.add_argument("output_dir", type=Path)
    parser.add_argument("--model", default="gemini-2.5-flash-image")
    args = parser.parse_args()

    api_key = os.environ.get("GEMINI_API_KEY")
    if not api_key:
        raise SystemExit("Missing GEMINI_API_KEY environment variable.")

    client = genai.Client(api_key=api_key)
    exts = {".jpg", ".jpeg", ".png", ".webp"}

    for src in sorted(args.input_dir.iterdir()):
        if not src.is_file() or src.suffix.lower() not in exts:
            continue
        dst = args.output_dir / f"{src.stem}.png"
        process_image(src, dst, client, args.model)
        print(dst)


if __name__ == "__main__":
    main()

适合继续优化的地方

如果你准备把这段脚本继续用于批量生产，后面还可以继续补这些能力：

增加失败重试，避免单张图片报错后整批中断
记录日志，方便定位是哪张图处理失败
对不同背景阈值做可配置化
支持递归扫描子目录
增加原图与结果图的对比预览

小结

如果你只想快速理解“怎么调用 Google Nano Banana 做抠图”，其实核心就三步：

安装 google-genai 和 Pillow
设置 GEMINI_API_KEY
用 client.models.generate_content() 传入提示词和图片

而这份代码的价值在于，它不只是调用模型，还补上了透明背景后处理，更适合直接拿去做商品图抠图任务。

谷歌 Gemma 4 模型对比：2B/4B/26B/31B 怎么选？

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 主打 多模态 与 本地离线运行，并提供从轻量端到高性能端的完整模型梯度。对大多数本地部署用户来说，关键不是“选最大”，而是“选最匹配硬件与任务的版本”。

Gemma 4 各模型对比

下表用于快速选型参考；具体性能与资源占用请以实际部署环境测试为准。

模型	参数规模	定位	主要优势	主要限制	推荐场景
Gemma 4 2B	20 亿	超轻量	延迟低、资源占用小、部署门槛最低	复杂推理与长链路任务能力有限	移动端、IoT、轻量问答、简单自动化
Gemma 4 4B	40 亿	轻量增强	比 2B 更稳的理解与生成能力，仍易本地部署	高强度编码/复杂 Agent 任务上限有限	本地助手、基础文档处理、多语言日常任务
Gemma 4 26B	260 亿	高性能（专家混合）	推理和工具调用能力明显提升，适合生产工作流	显存需求显著上升，硬件门槛更高	编程助手、复杂工作流、企业内部 Agent
Gemma 4 31B	310 亿	高性能（稠密）	综合能力最强，复杂任务稳定性更好	资源消耗最高，部署与调优成本最大	高要求推理、复杂代码任务、重度自动化

怎么选：按硬件和任务倒推

如果你主要看“能不能跑、跑得顺不顺”，可以按下面选：

8GB 显存：优先 2B/4B。
12GB 显存：优先 4B 或更高模型的量化版本。
24GB 显存：可重点考虑 26B，并按任务评估 31B 量化版。
更高显存或多卡：可尝试 31B 的高精度配置。

建议优先保证稳定性和推理速度，再逐步提升模型规模。

四类典型使用场景

1) 本地通用助手

优先模型：4B
原因：成本和效果平衡好，适合长期常驻运行。

2) 代码与自动化

优先模型：26B
原因：在多步骤任务、工具调用、脚本生成上更稳。

3) 高难度推理与复杂 Agent

优先模型：31B
原因：复杂上下文下的稳定性更高，容错更好。

4) 边缘设备与轻量离线

优先模型：2B
原因：最容易在资源受限设备落地。

部署建议（Ollama 方向）

最实用的做法是“小步快跑”：

先用 4B 建立可运行基线（速度、内存、效果）。
把你的真实任务做成固定测试集（例如 20 条常见问题 + 10 个自动化任务）。
再升级到 26B/31B 对比准确率、时延和显存成本。
只在“收益明显”时升级大模型。

这样可以避免一上来就追求大参数，结果出现卡顿、吞吐低、维护复杂的问题。

结论

Gemma 4 的真正价值，不是单纯“参数更大”，而是给了从轻量到高性能的一整套可落地梯度：

想低成本快速上线：从 2B/4B 开始。
想把本地 AI 真正接入生产流程：优先 26B。
想冲复杂推理与重度自动化：再上 31B。

Gemma 4 的最佳选择通常不是参数最大，而是与硬件条件和任务目标匹配度最高的版本。