标签: Google

Google发现卖铲子比自己挖金矿更赚钱之后,DeepMind怎么办?

这几天,Google对DeepMind进行了一次很大的调整。Demis Hassabis不再负责日常运营,转任Google DeepMind董事长和Alphabet首席科学家;原CTO Koray Kavukcuoglu接手Gemini模型、前沿AI研究、Gemini App和开发者团队。Jeff Dean和Sanjay Ghemawat也离开Google。Google说这是为了让Demis把更多精力放在AGI和科学上,但SemiAnalysis最新的文章《Gemini is Cooked but GCP is Cooking》却给出另一个解释:Gemini可能正在失去前沿优势,而Google Cloud正成为越来越确定的商业回报。

这让我想到那个老套的淘金故事。当所有人都在山里找金矿时,最稳定的生意往往不是自己挖到金子,而是卖铲子。Google现在似乎发现,它甚至不需要Gemini永远最强,只要AI公司都需要TPU、数据中心和云服务,Google就有机会从整个产业增长中赚钱。问题也因此变得有意思:当卖铲子已经是一门足够好的生意之后,Google还会不会继续给DeepMind留下足够资源,去寻找那些不知道什么时候才能挖出来的金矿?

一、Gemini可以不是第一,但Google未必会输

过去两年,我们习惯于用模型排行榜理解AI竞争,但Google早已不只是一家模型公司。Alphabet今年第二季度财报显示,Google Cloud收入达到248亿美元,同比增长82%;营业利润达到88亿美元,利润率提高到35.6%,Cloud backlog达到5140亿美元。更值得注意的是,Google第一次明确披露,已经开始把完整的TPU系统卖到客户自己的数据中心,现有TPU系统销售协议的大部分收入预计将在2027年确认。Google正在从“出租算力”,进入直接销售AI基础设施的生意。

SemiAnalysis甚至估算,未来Google会把相当大比例的TPU提供给Anthropic等外部AI公司。数字来自它自己的模型,不能当成Google已经确认的事实,但商业逻辑很清楚:如果Claude成为最强模型,却大量运行在Google Cloud上,Google并没有输;新的AI公司把融资花在Google的TPU和数据中心里,Google一样可以赚钱。OpenAI需要GPT赢,Anthropic需要Claude赢,但Google不一定需要Gemini每一代都赢。

二、当一块TPU可以直接赚钱,DeepMind面对的问题就变了

SemiAnalysis最值得关注的,并不是它断言“Gemini已经不行了”。这种判断太绝对,Google官方仍表示已经开始Gemini 4迄今最雄心勃勃的预训练。真正值得讨论的是,DeepMind和Google Cloud都需要同一种资源——算力。

一块TPU留给DeepMind,可以训练下一代Gemini,赌的是未来模型能力;交给Google Cloud,却可以很快变成合同、backlog和收入。Google在Q2财报中也明确表示,目前仍处于算力供应受限状态,外部Cloud客户和Google内部业务都在争夺容量。于是算力分配越来越像资本配置:同样一块芯片,是投入一个几年后可能成功的研究项目,还是现在就变成一份利润可见的云合同?

站在Google Cloud的角度,把TPU卖给Anthropic完全可以理解;但站在DeepMind的角度,你的竞争对手可能正在使用你所在公司的算力训练下一代模型。这是两种不同的商业逻辑。

三、DeepMind真正值得留下来的,也许从来不是Gemini

如果DeepMind存在的意义只是做一个更好的聊天机器人,这个问题并没有那么重要。即使某一天Gemini只能排第三、第五,用户可能也只是换一个应用、换一个API。

但DeepMind过去十几年真正让我觉得它值得存在的,并不是Gemini,而是AlphaFold。2020年,AlphaFold 2解决了困扰生物学界几十年的蛋白质结构预测问题。今天,AlphaFold数据库已经提供超过2亿个蛋白质结构预测,被190多个国家的300多万研究人员使用,其中超过30%的相关研究用于理解疾病。Demis Hassabis和John Jumper也因为蛋白质结构预测获得2024年诺贝尔化学奖。

这几年DeepMind又做出了AlphaMissense、AlphaGenome、AlphaProteo。今年推出的Co-Scientist,则试图把Gemini变成科学家的研究伙伴。在斯坦福的一项肝纤维化研究中,它提出的三个候选药物里有两个在实验中表现出抗纤维化效果,其中一个阻断了91%的相关损伤反应。

这些工作短期内很难像Cloud一样显示ARR,也很难用季度收入证明回报率,但它们可能改变药物研发、疾病研究乃至基础科学的速度。所以我并不认为DeepMind一定要在每一代Gemini上击败OpenAI和Anthropic,但我仍然希望Google把它真正保留下去。

四、这次调整,也可能不是坏事

把这次调整直接解释成Google为了赚钱开始放弃DeepMind,同样过度了。Google官方给出的解释恰恰相反:Sundar Pichai说,让Demis转任Google DeepMind董事长和Alphabet首席科学家,是为了让他把更多精力放在AGI和科学的未来;Demis自己的内部信也写得很明确,他一直相信AI的第一应用应该是改善人类健康,现在到了AI向世界证明其价值的时候,包括帮助人类最终攻克癌症这样的疾病。

从这个角度看,这次调整甚至可能是在把两件不同的事情拆开。Gemini已经是拥有9.5亿月活用户、API每分钟处理约220亿tokens的大规模产品,需要工程效率和商业执行;Demis真正感兴趣的AGI、生命科学和基础研究,则需要另一套时间尺度。

所以真正应该观察的,不是Demis的职位名称,也不是Gemini下一次在榜单上排第几,而是人才、算力和时间。Google是否还愿意把最好的研究人员留给没有直接产品目标的项目,是否愿意为科学研究提供足够的计算资源,是否允许一个项目几年都无法证明自己的商业回报。只要这三样东西还在,DeepMind就还是DeepMind。

五、Google可以卖铲子,但别停止寻找金矿

我能理解Google现在的选择。Alphabet已经把2026年资本开支预期提高到1950亿至2050亿美元,这些钱最终必须找到商业回报。Google Cloud高速增长、TPU能够卖出去,对Alphabet来说都不是坏事;而且只有一家企业能够持续赚钱,它才有能力长期承担那些高风险、低确定性的研究。

所以我真正担心的,从来不是Google开始用AI赚钱,而是当赚钱越来越容易以后,一家公司还有没有耐心继续做那些暂时不知道怎么赚钱的事情。如果当年的DeepMind在AlphaGo之后就被要求证明下一个项目能带来多少订阅和Cloud收入,后来有没有AlphaFold,很难说。今天回头看,它创造的价值也很难被放进Alphabet某一条财报科目里。

Google当然可以卖铲子,而且最好把铲子卖得足够赚钱。Gemini也不必永远排名第一,Google依然可能成为AI时代最大的赢家之一。但我还是希望DeepMind能够继续做那些不知道什么时候才能看到回报的事情,因为这个世界并不缺更好的聊天机器人,也不缺更便宜的token和更大的数据中心。真正稀缺的,是还有人愿意拿最好的AI、人才和算力,去解决疾病、生命、能源、材料这些人类至今没有解决的问题。

如果最后只满足于卖铲子,那才是真的把AI想小了。

谢尔盖·布林重新回到Google AI权力中心,DeepMind为什么必须退半步?

这几天Google AI最大的一次变化,不是新模型,而是人事。Demis Hassabis不再负责Google DeepMind的日常运营,转任DeepMind董事长和Alphabet首席科学家,把更多精力放到AGI、科学研究以及Isomorphic Labs;原DeepMind CTO、Google首席AI架构师Koray Kavukcuoglu接过日常管理。与此同时,谢尔盖·布林出现在Google AI的权力中心。

严格来说,布林并没有获得“Google AI负责人”的正式头衔,Koray是日常执行者。但《金融时报》报道,Koray去年已从伦敦搬到Mountain View,现在就在布林旁边办公;此前《The Information》也报道,当布林需要为AI团队协调算力、招聘或人员调动时,找的人就是Koray。布林从ChatGPT出现后回到Google,也早已不是偶尔参加会议,而是直接参与Gemini的训练和产品讨论。

所以,如果只把这次变化理解成一次管理层换届,可能低估了它的意义。Google真正要解决的是:DeepMind过去十几年形成的研究文化仍然很重要,但在今天与OpenAI、Anthropic、xAI进行近乎按月计算的模型和产品竞争时,仅靠这种文化已经不够了。

DeepMind没有失败,只是AI竞争换了游戏

我一直很喜欢DeepMind。它最吸引我的地方,从来不是做出更聪明的聊天机器人,而是相信AI最终应该去解决那些人类长期解决不了的问题。AlphaFold就是最好的例子:今天它已经提供超过2亿个蛋白质结构预测,被全球190多个国家的300多万研究人员使用,超过30%的相关研究与疾病有关。这样的成果,很难用季度收入衡量。

DeepMind之所以能做出这些东西,也因为它长期保持着接近研究机构的文化,允许科学家研究短期看不到商业回报的问题。但ChatGPT之后,前沿研究第一次和大规模商业竞争几乎重叠在了一起。今天一个模型训练完成,还要迅速完成评测、安全、API、开发工具、Agent能力和产品集成;Anthropic靠Claude Code建立开发者优势,OpenAI不断用新模型和Agent改变产品形态,xAI也在快速追赶。在这样的竞争里,两三个月都可能改变开发者的使用习惯。

Google应该很清楚这一点。Transformer论文来自Google,但后来真正把大语言模型变成大众产品的却是OpenAI。研究领先和市场领先,从来不是一回事。

Google现在最缺的,可能不是技术,而是组织速度

我不太认同“Google调整DeepMind,是因为Google AI已经落后”这种说法。从数据看,Google一点都不弱:今年第二季度Gemini App月活已经达到9.5亿,Google Cloud收入同比增长82%,Search仍增长17%;Alphabet还把2026年资本开支指引提高到1950亿至2050亿美元。Google拥有其他AI公司很难同时具备的算力、产品和分发体系。

问题可能恰恰出在资源太多。一家创业公司做出新模型,核心团队很快就能决定上线;Google发布旗舰模型,却要同时考虑Search、Cloud、Android、YouTube、开发者、安全、法律和几十亿用户。每个部门都有合理诉求,最后叠在一起,就可能拖慢组织速度。

Gemini 3.5 Pro的延期是一个很现实的例子。Google在5月曾表示Pro版本预计6月推出,但到现在仍在测试。报道显示,它尤其在Coding能力上没有达到内部目标,多层利益相关方参与发布也增加了协调成本。当然,这不能简单证明“DeepMind研究文化导致延期”,但至少说明Google今天需要的不只是更好的研究,还需要缩短研究到产品之间的距离。

Koray的重要性也正在这里。他过去几年一直负责组织Gemini研究团队,去年成为Google首席AI架构师后,又负责把Gemini推进整个Google。《The Information》把他称为Google AI内部的“fixer”。这次调整,与其说Google把DeepMind交给了一个“更商业的人”,不如说是把日常执行交给了一个更擅长穿透组织的人。

布林真正带回来的,可能不是技术,而是权力

我不太愿意把这件事写成“Pichai不行,所以创始人回来救公司”。过去几年Google合并Brain和DeepMind、大幅增加AI投入,都说明Pichai并不保守。但职业经理人和创始人在巨型公司里的作用确实不同。Pichai需要对整个Alphabet负责,要平衡搜索广告、Cloud、监管和资本回报;布林却可以只盯着一件事:Google不能输掉这一轮AI。

更重要的是,他拥有普通高管很难拥有的跨部门权威。算力给谁、哪个团队应该合并、哪个研究员必须留下、什么项目应该提高优先级,这些在大公司里往往不是技术问题,而是组织问题。技术范式剧烈变化时,大公司最稀缺的有时不是流程,而是有人能越过原有利益边界重新排序资源。

因此,布林与Koray的组合才值得关注:一个拥有足够的组织影响力,一个擅长把复杂事情真正推进下去。《金融时报》认为这次调整进一步强化了布林在Google AI中的影响力,这比“布林正式接管Google AI”准确得多。

但DeepMind只能退半步,不能退出

如果因为商业竞争激烈,就把DeepMind彻底变成Gemini产品部门,我反而认为会是Google的损失。今天大家讨论AI,注意力很容易被Benchmark、Coding和Agent吸走,但如果十年以后回头看,AI给人类带来的最大价值,也许不是帮我们多写了多少代码,而是有没有解决疾病、衰老、能源、材料这些过去解决不了的问题。AlphaFold已经证明,这条路值得有人长期坚持。

所以我更愿意把Demis这次变化理解成“退半步”。他不再承担Gemini每天面对的产品、进度和组织管理,把这些交给Koray;同时成为Alphabet首席科学家,继续把精力放到AGI、AI for Science和Isomorphic Labs。现有报道也显示,这次调整并不等于Google放弃长期研究,而是让Demis重新聚焦自己最独特的能力。

如果Google能把这套结构运行起来,它实际上是在建立两种时间尺度:一边是布林和Koray,需要几个月交一次答卷,让Gemini在Coding、Agent、API和产品上保持竞争力;另一边是Demis和DeepMind的科学研究,允许一些项目五年、十年以后才看到结果。Pichai则负责让两套体系都能获得足够资源。

这比“商业派战胜研究派”更接近Google需要的答案。我也因此更加期待Gemini 3.5 Pro,以及已经开始推进的下一代Gemini模型。Google已经表示,新的预训练正在进行,而且是迄今“最雄心勃勃”的一次。3.5 Pro能不能把Coding和Agent的短板补上,下一代Gemini能不能重新建立明显领先,会成为这次调整最直接的检验。

Google过去最宝贵的能力,是DeepMind愿意研究十年以后的问题;今天最紧迫的任务,却是Gemini必须几个月就交一次答卷。这两件事都重要,也不该让任何一件吞掉另一件。

所以我真正期待的,不是布林回来后把DeepMind变成只追逐模型榜单的AI公司,而是让Google跑得更快,同时让Demis继续有空间去做那些短期没有收入、却可能真正改变人类未来的研究。如果这件事能做到,那么DeepMind这次退的半步,也许会让Google的AI走得更远。

Google首席科学家Jeff Dean离职创业,他把“AI成功率1%”的选题法用在了自己身上吗?

在宣布离开Google创业之前,Jeff Dean其实已经把自己的创业逻辑讲了出来。

7月25日,在Y Combinator的Startup School现场,面对约6000名创业者,他被问到:当基础模型越来越强,创业公司还能选择什么方向?Jeff Dean的回答有些反直觉。他建议创业者不要优先寻找模型已经能够完成20%的任务,而应该寻找模型目前只能成功0%或1%的问题。因为如果模型已经能做20%,说明这种能力已经开始出现,随着训练数据和模型规模继续增长,它很可能很快变得更好。

十天之后,Jeff Dean宣布结束自己在Google近27年的职业生涯,与Sanjay Ghemawat、Oriol Vinyals和Quoc Le共同创办Discovery Loop。这家公司不是再做一个聊天机器人,而是尝试自动化科学与工程研究的完整循环:提出实验、运行实验、评价结果,再根据反馈进入下一轮。

这里要先澄清,“成功率1%”说的不是创业公司的成功概率,而是通用模型完成某类任务的成功率。Jeff Dean不是鼓励创业者去赌一个几乎不可能成功的项目,而是在提醒他们:基础模型进步越快,最容易做出来的AI产品,越可能最先被模型本身吞掉。

一、AI已经能做20%,为什么反而可能更危险?

传统软件创业,往往从一个已经被证明可行的需求开始。技术能解决20%,创业公司补齐剩下的80%,再通过产品、渠道和服务建立优势。这套逻辑能够成立,是因为底层技术一般不会在几个月内突然完成一次能力跃迁。

基础模型改变了这种节奏。模型能够完成20%,有时并不意味着创业窗口已经打开,反而意味着这个任务已经进入模型能力的覆盖范围。创业公司可能花一年时间优化提示词、补充工作流和产品界面,下一代模型更新以后,原来最核心的功能就变成了标准能力。

所以,“1%选题法”真正关心的不是难度,而是耐久性:创业公司究竟是在利用模型,还是把自己的命运完全交给模型供应商?如果产品价值主要来自模型暂时不稳定的能力,那么模型越强,产品的护城河反而越薄。

这不意味着所有模型已经能做20%的方向都不值得进入。消费产品仍可依靠品牌和分发建立价值,企业应用也可能掌握模型厂商拿不到的数据与流程。更准确的问题是:即使明天模型能力提升一倍,这家公司是否仍有独立存在的理由?

二、Discovery Loop几乎就是这套方法的标准答案

今天的AI已经能够读论文、生成假设、编写实验代码,也可以帮助分析数据。但让一个系统独立完成开放式科学研究,持续提出值得尝试的新方向,正确运行实验、识别失败原因,再将结果用于下一轮决策,仍然远未成为可靠能力。Discovery Loop选择的不是其中某个环节,而是试图把它们连成一个持续运行的闭环。

公司的路线是先把自己作为第一个客户,从机器学习研究开始,让系统自动提出、执行和评价大量实验,用这些实验改进自己的模型和算法,再扩展到芯片设计、生物、药物和材料等领域。Oriol Vinyals也承认,当前模型并不擅长提出真正新颖的想法,因此最初仍会由人与AI共同选题。

四位创始人的能力也与这条路线高度匹配:Jeff Dean与Sanjay Ghemawat长期负责Google的大规模计算和搜索基础设施,Oriol Vinyals曾是Gemini的重要技术负责人,Quoc Le参与创建Google Brain,并参与了自动发现机器学习算法的AutoML-Zero。后者早在2020年就尝试让系统从基本数学操作出发,自动发现完整的机器学习算法。

Discovery Loop采用公共利益公司结构,获得Khosla Ventures、Radical Ventures等机构支持,融资金额与估值尚未公开。Google虽然失去四位核心科学家,却没有与他们切割,而是成为创始投资者和云合作伙伴,并将在第一年提供计算资源。

Jeff Dean选择的不是“AI已经能做,只是体验还不够好”的产品,而是“AI目前还不能可靠完成,但一旦形成闭环就可能产生巨大价值”的问题。Discovery Loop即使不是按一条公式算出来的项目,也几乎是“1%选题法”的一次自我示范。

三、真正值钱的不是困难,而是能把失败变成反馈

仅仅选择一个AI不会做的问题,并不等于找到了创业机会。很多问题的成功率为0%,只是因为技术路径、数据条件和成本结构都不成立。

“1%问题”能够变成一家公司,关键是失败能否被快速验证,并转化为下一轮决策的反馈。结果需要能够评价,实验需要自动或半自动执行,单次尝试的成本要能够下降,实验结果还要重新进入系统。

这也是Discovery Loop先从机器学习研究开始,而不是直接进入新药研发的原因。机器学习实验天然数字化,模型结构、训练方法和性能指标都可以在计算环境中运行和评价;到了生物、药物和材料领域,许多实验仍需要真实实验室、漫长周期和监管验证,自动化难度会明显上升。

Google已有的AI Co-Scientist、ERA和AlphaEvolve也说明,这条路线并非空想。它们分别尝试生成可验证的科学假设、编写计算实验软件,以及把大模型生成代码、自动评价器和进化搜索结合起来。这些系统还不能独立完成完整科学发现,却证明了一个关键逻辑:只要评价标准清晰,模型偶尔产生的正确答案,就可以通过大规模实验被筛选和放大。

因此,Discovery Loop真正想建立的护城河,未必是某个单独模型更强,而是模型、实验环境、评价器、算力和领域知识组成的闭环。实验如何设计、结果如何评价、反馈如何进入下一轮,这些才可能成为长期资产。

四、Google自己已经在做,为什么还要离开?

这也是整件事最值得讨论的矛盾。Google并不缺少相关项目,也不缺模型、算力和人才。既然这些技术已经在Google内部出现,四位核心科学家为什么还要单独成立一家方向相近的公司?

现有信息不足以给出确定答案,但组织问题可能比技术问题更重要。Oriol Vinyals在采访中提到,大型组织总有很强的惯性,要推动激进变化需要克服很多阻力。Discovery Loop可以把“自动发现循环”设为唯一目标,让模型、基础设施、人才和产品围绕这一件事重新组织,而不必同时服务Google的多个业务。

Google成为投资者并提供算力,也让这次离开不像传统意义上的决裂,更像是把一项高风险、长期、难以按现有组织方式推进的研究放到外部公司。Discovery Loop获得创业公司的专注和速度,同时继续使用Google的资源;Google失去直接管理权,却保留投资关系和潜在回报。

这或许也是大公司越来越常见的一种创新方式。不是把所有前沿项目都留在内部,也不是等核心科学家彻底离开,而是允许一部分团队独立出去,用新的组织结构承担更高风险,同时通过投资、云服务和技术合作保留联系。对于Google而言,Discovery Loop既是一次人才流失,也可能是一次研究能力的外部延伸。

但现在还不能把它写成成功案例。Discovery Loop刚刚成立,没有公开产品、客户和研究成果,创始团队在公司公布时甚至尚未开始大规模招聘。顶级团队能够获得资金和算力,并不代表它一定能把AI变成真正的科学研究者。在提出原创问题、验证复杂因果关系,以及把计算实验转化为现实结果这些环节,当前模型仍有很长的路要走。

五、普通创业者不该照抄“1%”,但应该用它检查自己

Jeff Dean有资格选择一个模型成功率接近0%的问题,是因为他拥有可能最适合解决这类问题的团队,还有Google的计算资源和顶级投资机构支持。普通创业者如果只记住“越难越好”,得到的很可能不是护城河,而是一个永远无法交付的产品。

这套方法真正值得借鉴的,不是具体百分比,而是一次反向压力测试:如果下一代模型直接提供了你的核心功能,用户为什么还需要你的产品?你是否拥有模型厂商拿不到的数据、评价体系和真实工作流?用户使用后能否留下独有反馈?AI除了回答问题,能否进入业务中执行和验证结果?

大量AI产品争夺的是模型已经会做的事情,区别只是界面更漂亮、提示词更完整、某个流程暂时更顺畅。这些产品并非没有价值,但如果不能继续沉淀数据、工作流、评价标准和客户关系,模型升级越快,它们面临的替代压力也越大。

所以,Jeff Dean是否把“AI成功率1%”的选题法用在了自己身上?

目前没有公开证据证明,他依据这条规则决定创办Discovery Loop。但可以确认的是,他在YC现场描述“自动化科学方法”时,这家公司已经在秘密筹备;他提出的选题逻辑与Discovery Loop的方向,也来自同一种判断:不要只做AI今天已经能做一点、明天很可能会做得更好的事情,而要寻找AI仍然不会做,但你有办法让每一次失败都推动它向前一步的问题。

Discovery Loop最终能否成功,现在还无法判断。它甚至可能再次证明,自动化科学远比自动化写代码困难。但至少在选题上,Jeff Dean给出了一个清楚的答案:真正的“1%”,不是创业成功的概率,而是基础模型尚未占领的能力空间。

AI模型开始不拼最强了,Google正在把竞争拉回成本和规模

最近 Google 发布了 Gemini 3.6 Flash、Gemini 3.5 Flash-Lite 和 Gemini 3.5 Flash Cyber 三个模型。比较有意思的是,这次发布并没有像过去的旗舰模型一样,在社交媒体上形成一轮“谁是最强模型”的大讨论。很多媒体反而把注意力放在了另一个问题上:Gemini 3.5 Pro 为什么还没有发布。

Google 发布了 Gemini 3.6 Flash、Gemini 3.5 Flash-Lite 和 Gemini 3.5 Flash Cyber 三个模型

这也很正常。过去两年,我们已经习惯了一种评价 AI 模型的方式。一个新模型出来,先看 benchmark,再看 Coding 排名,然后问一句:它超过 GPT 了吗?超过 Claude 了吗?是不是现在世界上最强的模型?

但我自己最近越来越觉得,这种评价方式可能正在过时。

Google 这次发布 Gemini 3.6 Flash,真正值得关注的,并不是它又在某几个 benchmark 上提高了多少,而是 Google 开始把模型竞争重新拉回一个非常现实的问题:一个 AI 到底能不能更快、更便宜地完成任务,而且能够被大规模使用。

这件事,在 AI Coding 上已经非常明显了。

一、最强的模型,不一定是我最愿意用的模型

我现在同时使用几个主流的 AI Coding 工具和模型,一个很明显的感受是,不同模型之间最大的区别已经不只是“谁更聪明”,还有完成一个任务需要多少时间。

比如 Claude Opus 4.8 配合 Superpower,处理复杂问题确实很强,尤其是在理解代码、深入分析和长时间规划方面,它经常会考虑得非常完整。但代价也很明显,就是慢。在我自己的实际开发任务中,同一个级别的任务,Claude Opus 4.8 + Superpower 花费的时间,经常是 GPT-5.6 Sol + 原生 Plan 模式的数倍,有些任务甚至能达到一个数量级的差距。

Gemini 给我的感觉则完全不同。

从 Gemini 3.5 Flash 开始,我最大的感受就是快,而且不是聊天时快几秒钟这么简单,而是在 Coding Agent 连续执行几十个步骤之后,整个任务的完成时间明显缩短。对于很多日常开发任务,比如改一个页面、调整接口、增加字段、修改已有逻辑、修普通 Bug,甚至按照已经确定的方案批量修改代码,我并不需要模型每一步都进行非常深入的推理。很多时候,我需要的是它能够快速理解要求,然后准确执行。

Gemini 3.6 Flash 延续的其实就是这条路线。Google 官方数据显示,它相比 3.5 Flash 在 Artificial Analysis Index 上减少了约 17% 的输出 Token,同时在多步骤工作流中减少推理步骤和工具调用,API 输出价格也下降到了每百万 Token 7.5 美元。Google 给这个模型的定位非常直接,就是用于大规模运行 AI Agent。

我觉得这里真正发生变化的,不只是 Gemini 又快了一点,而是模型竞争的评价标准正在发生变化。

二、Agent改变了模型的经济账

以前使用 ChatGPT,一次对话就是一次模型调用。你问一个问题,模型思考几十秒还是一分钟,差别虽然存在,但还可以接受。在这种模式下,当然是模型越聪明越好,因为调用次数并不多。

Agent 完全不是这么回事。

一个 Coding Agent 接到任务之后,要先读取代码、搜索文件、理解架构、制定计划,然后修改代码、运行程序、发现错误、继续修改、执行测试,最后再检查结果。一个看起来不复杂的任务,背后可能已经调用模型几十次;复杂一点的任务,模型调用和工具调用可能达到上百次。

这时候,每一次慢一点,最后都会累积成非常大的差距。

如果一个模型每一步都比另一个模型多思考十几秒,执行五十步以后,差距就已经不是“回复稍微慢一点”,而是十几分钟甚至几十分钟。再加上模型可能因为推理路径更长而产生更多 Token、更多工具调用和更多修改循环,一个模型看起来单次能力更强,完成整个任务的效率却未必更高。

所以到了 Agent 时代,我们可能需要换一种计算方法。

过去大家关心的是每百万 Token 多少钱,以后真正重要的指标可能是:完成一个任务到底需要多少钱,需要多少时间。

Google 在介绍 Gemini 3.6 Flash 时,反复强调的恰恰不是单纯降低 Token 单价,而是更少的输出 Token、更少的推理步骤、更少的工具调用和更少的代码修改循环。在 DeepSWE 等测试中,Google甚至观察到部分场景 Token 使用量大幅下降。

这背后其实是一种完全不同的产品思路。模型不是为了在一道特别难的问题上证明自己有多聪明,而是为了让一个 Agent 连续工作几百次以后,仍然足够快、足够便宜。

三、很多开发任务,根本不需要每次都用最强模型

这也是我实际使用 AI Coding 之后越来越明显的感受。

我们很容易把“Coding 能力”理解成一种单一能力,然后去寻找一个最强的 Coding 模型。但真实的软件开发并不是这样。设计一个复杂系统架构,和把已经确定好的接口增加一个字段,显然不是同一种任务;排查一个非常隐蔽的并发 Bug,和按照设计稿调整页面样式,也没有必要使用相同级别的推理能力。

真正困难的任务,需要 Claude Opus 4.8、GPT-5.6 这类更强的模型深入分析。但软件开发中还有大量工作其实属于执行型任务。一旦需求明确、方案确定,接下来更重要的是执行速度、准确性和稳定性。

这也是我觉得 Gemini Flash 特别适合的地方。

Google 在今年 5 月发布 Gemini 3.5 Flash 时,就已经把它定位成面向 Agent 和 Coding 的主力模型,并强调它在保持较强能力的同时拥有更高的输出速度。到了 3.6 Flash,Google 又进一步减少 Token 消耗和执行循环。

换句话说,Google 似乎并不打算让每一个任务都去调用最强大的 Pro 模型。

这可能才是更合理的 AI 架构。

复杂任务先由强模型理解目标、设计方案和处理真正困难的问题,Flash 负责大量执行,Flash-Lite 再去承担分类、提取、转换、搜索和简单子任务。Google 这次同时发布的 3.5 Flash-Lite,速度达到每秒约 350 个输出 Token,价格只有每百万输入 Token 0.3 美元、输出 2.5 美元,它存在的意义显然也不是挑战“世界最强模型”,而是为了让大量 Agent 工作负载真正跑得起来。

这和云计算其实很像。没有人会因为某一种服务器性能最强,就把公司所有业务都部署到最昂贵的机器上。真正成熟的基础设施,一定会根据任务进行分层。

AI 模型最终可能也会如此。

四、速度正在从“体验”变成一种真正的模型能力

过去我们谈模型速度,很容易把它理解成用户体验。一个答案两秒出来还是十秒出来,当然是两秒更舒服。

但到了 Agent 时代,速度已经不只是体验问题,而是生产力问题。

一个人使用聊天机器人时,慢一点可能只是多等几十秒;一个 Agent 一天运行几百个任务时,速度直接决定它一天到底能完成多少工作;一家企业同时运行几千甚至几万个 Agent 时,延迟、Token 数量和工具调用次数最终都会变成服务器、GPU 和真金白银的成本。

这时候,模型能力就不能只看智力。

至少应该同时看四件事:能力、速度、成本和可靠性。

一个模型即使 benchmark 高 5%,但完成同样的任务慢几倍、成本高几倍,它也未必适合成为大规模 Agent 的默认模型。反过来,一个模型只要能力跨过了“足够好”这条线,速度更快、成本更低,就可能获得远远更多的实际调用。

这可能也是为什么 Google 现在如此重视 Flash。

媒体仍然在等待 Gemini 3.5 Pro,因为旗舰模型代表 Google 在前沿模型上的技术上限,Reuters 和 TechCrunch 对这次发布的报道,也都把 3.5 Pro 的延期作为一个重点。但从商业上看,真正贡献海量 Token 消耗和 Agent 工作负载的,未来未必是 Pro,而更可能是 Flash 这一层。

五、Google可能根本不想只赢“最强模型”这场比赛

过去两年,OpenAI、Anthropic 和 Google 都在争夺同一个位置:谁拥有世界上最聪明的模型。

这个位置当然重要,因为最强模型决定技术上限,也决定品牌影响力。但随着模型整体能力不断提高,我觉得另一个市场正在变得更大:大量原本根本不会交给 AI 的工作,现在开始可以被 Agent 自动完成。

到了这个阶段,竞争规则自然会变化。

一个模型偶尔解决一道世界上最难的问题,和一个模型每天被调用几百亿次,是两种完全不同的商业价值。前者证明技术高度,后者决定产业规模。

Google 的优势恰恰可能在后者。

Google 做搜索、广告、YouTube、Android 和云计算这么多年,本来最擅长的就不是只造一个最昂贵的产品,而是把一种技术降低成本,然后服务几十亿用户。当 AI 从聊天工具变成基础设施,这种能力可能会重新变得重要。

所以我觉得 Gemini 3.6 Flash 真正值得关注的地方,并不是它有没有超过 GPT-5.6,也不是它能不能打败 Claude Opus 4.8。

它代表的是另一种竞争思路。

过去两年,我们一直在问:谁能造出最聪明的 AI?

接下来真正决定市场格局的问题可能会变成:谁能让足够聪明的 AI,以足够低的成本、足够快的速度,被调用足够多次。

最强模型仍然重要,但它决定的可能只是 AI 的上限。

真正决定 AI 能走多远、进入多少行业、完成多少工作、最终形成多大市场的,可能是那些没有拿到“世界第一”头衔,却每天完成最多任务的模型。

从这个角度看,Google 这次没有拿出大家一直等待的 Gemini 3.5 Pro,当然有些遗憾。但 Gemini 3.6 Flash 所代表的方向,可能同样值得重视。

因为 AI 模型的战争,正在从一场跑分比赛,慢慢变成一场效率和规模的战争。

Google AdSense西联汇款收款

上两次收Google Adsense的汇款,都是采用支票的方式,时间长,而且在中国银行办理还需要50-60元的手续费,后来在网上看到Google AdSense可以采用西联汇款收款,我也把我Google AdSense帐户里的付款方式改为了西联汇款,帐户里够了100美金,上个月底就看到了付款详情,今天我到农业银行,提取了这笔汇款,没有手续费,我直接换成人民币现金取走。

在设置西联汇款的时候有几个地方注意,它页面上虽然写了“为了领取您的付款,您需要持有政府核发的与以下收款人姓名完全一致的有效证件。”,但是在填写收款人姓名的时候还是写英文,并注意姓名的顺序,比如你的名字是“张三”,那要在“收款人名”填写“San”,“收款人姓”填写“Zhang”,到时持你的身份证到银行取款,是没有问题的。

在国内,西联汇款的代理机构是农业银行和邮政储蓄,在http://www.westernunion.cn/sc/location_search.php可以查到代理的网点,但好像不太准,我今天去的江宁路农业银行在上面就没有,我想应该是大一点的分行或是支行都应该有这样的业务。

到农业银行后先填写两张单子,一个是西联汇款的收汇单,里面收汇人和发汇人姓名地址都写英文,也就是你Google AdSense里留的信息,汇款监控号码非常重要,这也是表示这笔汇款的依据,另一张单子是个人结汇申请书,结汇类型是“现汇”,结汇资金入账方式选“取现”,结汇资金来源就选“其他”,结汇用途写“零用”,其实可以随便写的,之后一些必要的签字等等,连同身份证交给柜台上之后会按照当前的汇率兑换为人民币,拿到人民币就OK啦。

用Google API来取得Google帐户的联系人列表

昨天写了一篇从Web Mail里取得用户通讯录的方法的文章,里面提到了Google的Account Authentication API,今天我们就用Account Authentication APIGoogle Contacts Data API来做一个取得Google帐户联系人的测试。

首先我们要看一下Account Authentication API,对于网络应用来说我们选择对网络应用程序的验证,对网络应用程序的验证也提供了 OAuthAuthSub 两种认证方式,我们选择AuthSub的认证方式,认证过程如下图

Google Authsub Diagram

用户在第三方Web应用上向Google Accounts Authentication发送AuthSub的HTTP请求,如果用户没有登录Google,则会显示登录页面,用户登录之后,会提示用户是否接受或拒绝这个第三方Web应用的访问请求,如果用户同意,Google就会生成一个token,转回第三方Web应用,第三方Web应用凭此token,可以请求Google的相关Sevice,比如联系人的服务,从而取得相关数据。

AuthSub有两种接口,一个是AuthSubRequest(A call to this method sends the user to a Google Accounts web page, where the user is given the opportunity to log in and grant Google account access to the web application. If successful, Google provides a single-use authentication token, which the web application can use to access the user’s Google service data.)另一个是AuthSubSessionToken(A call to this method allows the web application to exchange a single-use token for a session token),按照Google文档的理解,AuthSubRequest是一个单次的认证,AuthSubSessionToken应该是带会话(Session)的。

我们就举Google提供的例子

https://www.google.com/accounts/AuthSubRequest?
   next=http%3A%2F%2Fwww.yourwebapp.com%2Fshowcalendar.html
   &scope=http%3A%2F%2Fwww.google.com%2Fcalendar%2Ffeeds%2F
   &session=1
   &secure=1

https://www.google.com/accounts/AuthSubRequest就是AuthSub请求的地址,next表示认证之后要转回的地址,一般就是第三方Web应用的地址,也就是你网站的一个地址,Google会把token附带到这个地址后面,scope是你要请求的Google服务地址,这个例子里是要访问Google日历的数据,另外两个参数看Google的文档吧。

接下来,我们要取得Google帐户的联系人,我们先看看Google提供了多少可以访问的服务吧,访问Google数据API,Google提供的数据还着不少,有日历、文档、图书搜索、网路相册等等,当然也包括我们所需要的联系人的API,Google数据API要好好了解一下,总体来说Google提供一个Gdata的数据格式,和RSS的feed类似的格式,通过相关服务的访问地址,就可以返回Gdata数据,至于Gdata的读取,已经有了很多程序语言的封装好的程序(http://code.google.com/intl/zh-CN/apis/gdata/clientlibs.html),直接用就可以了,我们用PHP举例,PHP对Gdata的封装,是Zend Framework里的Gdata包,在http://framework.zend.com/download/gdata下载就可以了,但是现在Zend Gdata的包里没有直接的Google contacts的组件,但不要紧,通过Zend Gdata里基础数据的访问,可以取得Google contacts。

我们看看Google Contacts Data API的开发人员指南吧,取得联系人的Feed URL是

http://www.google.com/m8/feeds/contacts/userEmail/full 
或 
http://www.google.com/m8/feeds/contacts/default/full

那我们就用PHP来写一个取得联系人的程序吧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
require_once 'Zend/Loader.php';
Zend_Loader::loadClass ( 'Zend_Gdata' );
Zend_Loader::loadClass ( 'Zend_Gdata_AuthSub' );
Zend_Loader::loadClass ( 'Zend_Gdata_ClientLogin' );
Zend_Loader::loadClass ( 'Zend_Gdata_Query' );
Zend_Loader::loadClass ( 'Zend_Gdata_Feed' );
 
$my_contacts = 'http://www.google.com/m8/feeds/contacts/default/full';
 
if (! isset ( $_SESSION ['cal_token'] )) {
	if (isset ( $_GET ['token'] )) {
		// You can convert the single-use token to a session token.
		$session_token = Zend_Gdata_AuthSub::getAuthSubSessionToken ( $_GET ['token'] );
		// Store the session token in our session.
		$_SESSION ['cal_token'] = $session_token;
	} else {
		// Display link to generate single-use token
		$googleUri = Zend_Gdata_AuthSub::getAuthSubTokenUri ( 'http://' . $_SERVER ['SERVER_NAME'] . $_SERVER ['REQUEST_URI'], $my_contacts, 0, 1 );
		echo "Click <a href='$googleUri'>here</a> " . "to authorize this application.";
		exit ();
	}
}
 
// Create an authenticated HTTP Client to talk to Google.
$client = Zend_Gdata_AuthSub::getHttpClient ( $_SESSION ['cal_token'] );
 
$gdata = new Zend_Gdata ( $client );
$query = new Zend_Gdata_Query ( $my_contacts );
//$query->setMaxResults(10);
$query->setMaxResults ( 2000 );
$feed = $gdata->getFeed ( $query );
 
foreach ( $feed as $entry ) {
 
	$parts = $entry->getExtensionElements ();
	foreach ( $parts as $p ) {
		$element = $p->getDOM ();
		switch ($element->tagName) {
			case 'email' :
				print ( "Email: " . $element->getAttribute ( 'address' ) . "<br/>" );
				break;
			case 'phoneNumber' :
				print ( "Phone: " . $element->nodeValue . "<br/>" );
				break;
			default :
				continue;
		}
	}
 
}

放在你服务器上运行一下吧(别忘了Zend Gdata包要加进去)。

从JavaEye上找的Google翻译JavaScript脚本

在Blog或新闻发布的时候,我们希望URL是一段有意义的字串,例如我Blog里的《Linux下切分Tomcat的catalina.out日志文件》文章链接是https://i.laoer.com/2009/02/18/rotating-catalina-out-in-tomcat-using-cronolog/,这样有利于SEO(搜索引擎优化),对于我们母语为中文的小虾,有时候要翻译标题还是有点头疼的,还好有了Google翻译,让翻译的事情变得简单了一点,但对于开发者,怎么使用户也方便的翻译,特别是在写Blog的时候就能把标题翻译好,还要动点脑筋,我看到JavaEye里发布新闻的地方有个“让Google帮助生成永久链接”的功能挺好的,看了一下他们的源码,得到以下这段,顺别也解释一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<script type="text/javascript" src="http://www.google.com/jsapi"></script> //载入Google的jsapi
 
<script type="text/javascript">  
 
  function slugify(str) { //这个方法应该是将字符转为小写,并把一些特殊字符转为"-"
    return str.toLowerCase().replace(/[^a-z0-9-_]+/g, '-').replace(/^-|-$/g, '');
  }
 
  google.load("language", "1"); //载入Google的language Ajax库
 
  function translate_title() { //这里就是翻译文章标题了,里面的方法需要jQuery支持,之前要引入jQuery的包,这里就省略了
    if($F("news_title").blank()) {
      alert("请先填写标题");
      return;
    }
    $("news_slug_url").value = "正在翻译中...";
    google.language.translate($F("news_title"), "zh", "en", function(result) {
      if (!result.error) {
        $("news_slug_url").value = slugify(result.translation);
      }
    });
  }  
</script>

这里有个地方要说一下,Google的Ajax库API还是挺好的,可以load几种Ajax的库,另外Google的Web 工具包也可以看看。