普通视图

发现新文章,点击刷新页面。
昨天以前首页

实测有沉思能力的智谱 AutoGLM ,我们离会思考的 agent 又近了一步

作者 杜晨
2025年3月31日 13:00

如果有一个会思考但是不会做事的 AI

还有会做事但是不会思考的 AI。

 

你会选哪个?

如果让我来选,我会说:why not both?

今天在中关村论坛智谱 Open Day 上,智谱发布了 AutoGLM 沉思——首个带有沉思能力的桌面端 agent。

这是第一个存在于电脑桌面的,能先思考在做事,且做的过程中不断思考的 agent。

抛给它一个问题,它会逐步分解问题,然后在你面前(或者你不看着它也行)打开一个又一个浏览器标签页,自己上去搜索、查找、记录、汇总、分析信息,最终为你生成一份经过充分查证和深度思考的结果报告。

如果你还不知道这是个什么东西,简单前情提要一下:

AutoGLM 是智谱推出的 Agent 产品,能够实现对手机屏幕和电脑浏览器的操作。重点在于实现方式是前台的图形界面 (GUI),而不是后台的应用接口 (API)。你可以理解为 AutoGLM 学习人类通过「手眼并用」的方式,直接在用户界面上进行操作。这和市面上绝大多数基于 API 的 agent 产品有着明显的交互方式区别。

而沉思能力,正如字面意思,让 AI 可以一边想、一边搜,自主解决开放式的、训练语料不包含的问题,模仿深度思考和展现深度研究的能力。智谱在今年 3 月初拿到新一轮融资的时候就对外预告正在研发沉思,而这个功能的开关也已经在该公司开发的「智谱清言」(ChatGLM) 大模型产品里上线了。

而在 AutoGLM 沉思的身上,智谱独特的 GUI agent 功能,和人们最追捧和爱用的沉思能力,终于实现了融合。

AutoGLM 沉思背后的模型基座,也在本次 Open Day 上正式发布:

GLM-4-Air-0414 基座模型,具有 320 亿参数量,但性能足以对标 DeepSeek-V3、R1 (670B)、Qwen 2.5-Max 等更大参数量的模型。

因为参数量更少,GLM-4-Air0414 可以快速执行 agent 类工作,为 agent 的能力提升以及大规模落地应用提供基础,也一定程度上确保了终端用户的试用体验。

智谱还发布了 GLM-Z1-Air 推理模型,相比 DeepSeek-R1(激活 37B)推理速度提升了 8 倍,而成本降低到只有后者的三十分之一。

这也是一个可以在消费级显卡上运行的推理模型,能够显著提高开发者的使用体验。

智谱还基于 GLM-Z1 模型,使用自进化强化学习方式,训练了一个新的沉思模型 GLM-Z1-Rumination,能够实时联网搜索、动态调用工具,深度分析和自我验证。这个沉思模型能够自主理解用户需求,在复杂任务中不断优化推理、反复验证与修正假设,使研究成果更具可靠性与实用性。

也就是说:AutoGLM 沉思的基础模型架构是这样的:

中层推理和沉思模型 GLM-Z1-Air、GLM-Z1-Rumination

+

底层语言模型 GLM-4-Air-0414

加上工程/产品层的 AutoGLM 工具,就形成了 AutoGLM 沉思的整个技术栈。

智谱也计划在 4 月 14 日正式开源 AutoGLM 沉思背后的所有模型。

此前智谱曾分享过团队对于 AGI 路线图的判断:如果用自动驾驶层级打比方的话,目前大模型产品大体上获得了自我学习的能力,接近于 L3;而沉思、反思、自我批评等能力则是 L4 阶段。

需要注意的是,目前 AutoGLM 沉思还处于 beta 测试阶段。上个周末,APPSO 深度使用了这个产品。从测试结果来看,它在处理复杂工作上的效果确有提高的空间,底层逻辑也需要优化,但作为一个非常新颖的大模型-agent 产品,总体效果已经令人惊艳。

智谱已经踏入了大模型 agent 的 L4 阶段,虽然只是进来了半只脚。

目前 AutoGLM 的沉思功能,目前已经正式上线智谱清言网页端、PC 端和手机 App,免费、不限量地开放。

附上体验🔗

https://autoglm-research.zhipuai.cn/?channel=chatglm#get_started

 

当 Agent 有了沉思能力,AI 终于学会自己干活了?

去年 Anthropic 发布了「Computer Use」,同时展现了足够的模型能力以及较强的设备交互能力,让 agent(智能体)的设想终于首次得到实践。今年 1 月,Anthropic 在美国的最大对手 OpenAI 也通过新产品 Operator,做出对于 GUI agent 理念的演绎。

也是在去年 10 月,智谱和 Anthropic 几乎同时发布了各自在 agent 方向上的最新尝试。智谱的 AutoGLM 是第一家国内机构推出的基于 GUI 的 agent。

而今天的 AutoGLM 沉思,不仅将 agent 的执行任务能力带到了桌面端,更是把工具操作能力、深度研究能力、推理能力和大预言能力进行了首次融合。

这种多重能力驱动的 agent,非常适合信息检索、提炼、汇总型任务。

这就好比是让 agent「开车」,过去你得给他一辆车,教他方向盘、油门刹车、档位怎么用,甚至告诉它开车和倒车的时候分别要往哪看——而现在,agent 已经可以「自动驾驶」了。

让它制作一份「不同于网上所有主流路线的日本两周小众经典行攻略,要求绝对不去最火的目的地,要小众景点,但也要评价比较好的。」

AutoGLM 沉思比较准确地拆解了需求,思考逻辑也比较清楚:它首先去搜了最简单的关键词「日本旅游」,了解主流路线和景点,然后又去搜索了「日本小众旅游景点」之类的关键词——通过这几个步骤,它在本次对话的记忆内部构建了一个知识库,也即什么是主流的,什么是小众的。

这个任务总共做了 20 多次思考。有时候几次思考之间会有重复,比如搜索的是相同的关键词,访问了相同或者相似的链接等。这有可能是因为单次搜索到的信息不足够,毕竟沉思/深度搜索的本质其实也是不断地自我怀疑和推翻,直到达到足够置信度时候才进入下一步。

APPSO 还注意到它会过度依赖特定的网站作为信息来源,打开的所有 tab 里有 90% 都是小红书和知乎(各一半左右)。反而真正的旅行专业资料库,比如马蜂窝、穷游,或者哪怕是 OTA 平台,它一次没用过。

如果要做一份真正的小众攻略,重度依赖小红书的结果可能并不理想。毕竟能上小红书的热门笔记,这个景点应该并不真的小众。一个真正的小众景点旅行者,恐怕不想去 momo 们已经去过或者都想去的地方……

APPSO 注意到,AutoGLM 沉思在沉思过后自己提出了「路线规划合理,不要有无意义的反折」、「行程节奏合理,别太特种兵」之类的要求。

只是实际结果没有完美体现它自己提出的这些要求:比如头几天在濑户内海来回折返,有时候一天内去两三个相隔一小时以上的地点,略微特种兵;第二周从青森向南到仙台,然后又从仙台飞机向北大跨度飞到了北海道,并且北海道只留了两天。考虑到日本大跨度旅行基本都靠 JR,票价昂贵,合理的路线应该是顺着一个方向不回头,除非不得不去大城市换车,一般不应该折返。

但总体来讲,这份攻略是有效的:它呈现了一些提问者未曾考虑过的目的地,也试图在一次行程里去到季节、气候、风格完全不一样的地方(而不是围在大东京、富士山、京坂奈区域来回打转)。

从这个角度,它遵循了提示的要求,并且展现出了深度思考的结果。

就像你不应该直接把 AI 生成的结果直接拿去用一样,这份攻略提供了一个还算不错的基础,让旅行者可以自行优化具体的目的地、路线和中间的交通方式。旅行不只是上车睡觉下车拍照,还应该兼顾人文和自然,深入当地文化传统,探索自然景观,以及至少感受一把在地最有特色的体验项目。

只要你的期待不是即问即用,AutoGLM 沉思给出的答案是足够令人满意的。

点击查看智谱清言的回答 https://chatglm.cn/share/FQoLp

考虑到 AutoGLM 沉思与其它深度思考型大模型最大的特别之处在于浏览器的操控能力,APPSO 也更深入和严苛地测试了一下他的 browser use 能力。

让它做一份关于科创板云计算公司的研报,看看结果怎么样。

正如前一次做旅行攻略一样,AutoGLM 沉思的「思考过程」是没有任何问题的。从下图中可以看到,它:

  1. 准确拆解了筛选条件,
  2. 明确需要多轮搜索和迭代,
  3. 制定了分步骤的计划,
  4. 通过「一般搜索」找到了大概的搜索目标
  5. 开始执行分步操作

但是 browser use 的过程实在让人有点抓头:AutoGLM 工具一次又一次地试图打开证监会指定的信息披露网站(巨潮资讯),解析网页的信息。它顺利地找到了网站数据库的条件筛选工具,但经常无法正常筛选,要么选不好时间区间,要么找不到对应板块的下拉菜单在哪。

APPSO 观察到,AutoGLM 沉思给每一步骤的定时通常是 3 分 20 秒左右,但如果访问网站不顺利,就会因为操作超时而导致「本轮思考」失败。

另外,根据 APPSO 之前体验去年的 AutoGLM 以及其它 GUI agent 产品的经验,当需要用户进行登录操作、输入付款信息、点击发送按钮这种敏感性操作时,agent 可以停下来等待用户操作。而在使用 AutoGLM 沉思的过程中,它的确可以等候用户登陆,但遇到「用不明白网站」的情况,并没有呼唤用户接管,而是只会傻傻地等着。

在本次任务中,连续两轮思考失败之后,AutoGLM 沉思开始进入一个重新思考-跟之前导致失败的思考结果一样-再重新思考的循环过程,一直循环往复了五六次,最后败下阵来,把目标转向了知乎。

步骤进行到这里的时候,其实已经算任务失败了,因为输入的原始指令是查找和汇总上市公司资料和公告,数据的专业准确性很重要,而知乎并不是一个可靠的上市公司信息披露平台。

经过了好几次艰难的测试,最后终于吐出了结果:华为、紫光、UCloud 三家公司,虽然都跟边缘计算有关,但三家的股票代码都写错了,更别提有两家并没上科创板。

Agent 「自动驾驶」能力,和路况、驾驶位有很大关系

在其它更轻松的任务(比如做旅行规划、游戏攻略、查找简单信息等)当中,AutoGLM 工具的 browser use 能力是没有太大问题的。

但 APPSO 发现,一旦当前网站的视觉设计相对复杂,或者设计的有一些陷阱,AutoGLM 工具就很容易被「使绊子」。

一个最直接的例子就是电商网站。APPSO 给出明确提示,「去淘宝或京东购买一件重磅日系 T 恤」,AutoGLM 沉思制定了宏伟的计划和明确的分工——然而却连淘宝首页的山门都进不去,甚至找不到搜索框在哪里。而且它似乎被「找不到搜索框」这件事完全阻挡住了,甚至也没有去看网页的其它位置——如果它看了的话,肯定会发现相关商品早就出现在首页推荐里了。

对于这个测试中发现的意外情况,智谱 CEO 张鹏表示,「点背不能赖社会」,AutoGLM 沉思目前仍在 beta 阶段,还有很大的进化空间,而且目前的升级速度也很快(APPSO 在正式发布版上测试淘宝的使用效果,已经没那么磕绊了)。

张鹏指出,在模型作为服务或作为产品 (MaaS) 的理念下,模型产品自己的能力要像木桶一样,高且全面。或许现在 AutoGLM 工具的视觉能力还不如人,处理意外情况的能力还不够,归根结底可能是泛化能力还不够,但这些能力的提升并不是模型问题,而是纯粹的工程层面——不需要担心。

从模型底座层面,AutoGLM 沉思也有提升的空间。

经常用大语言模型产品的朋友都知道,提示写的越具体,规则和边界设定的越明确,它的效果越好,越有希望生成符合用户提示的结果。基于大语言模型的 agent 也是一样。

但是提示不能无限扩展,就好比你招了一个秘书帮你干活,但你不应该总是每次都把「找谁」、「什么地点」、「什么时候」、「去哪」等一切的信息都讲清楚,ta 才能勉强顺利地帮你搞定一个饭局的准备工作。

大语言模型很强大,但也有它糟糕的地方:只受到文本规则的约束,缺乏真正的实际问题的规划能力,任务过程中容易被卡住;缺乏足够长的上下文记忆空间,任务持续时间太长就持续不下去;上一个步骤的错误会随着步骤逐渐放大,直至失败。

AutoGLM 沉思也是一个基于大语言模型的 agent,即便在 agent 能力上做了很多工作,但仍然难免受到大语言模型的诅咒。思考能力越强,越容易想多、想歪。

从 APPSO 的试用过程中可以看到,除了一些绝对基础的概念(比如「旅游」、「T 恤」、「公司」)之外,它并没有稍微复杂的上层知识。用户每次发出任何指令,它都要先自己打开浏览器,上网学习一遍,明确用户的所指,在本次对话的有限记忆空间内建立一个知识库,然后再去进行后续的步骤。

而就它目前最擅长和依赖的那几个信息来源来看,一旦用户任务的复杂性、专业性「上了强度」,想要它在用户可接受的时间(目前官方定的是每任务总共 15 分钟左右)内,查到真实、准确和有价值的信息,就真的有点勉强了,更别提给到用户有效的结果(APPSO 的测试中有一半无法输出完整的结果)。

不过这并不是个太大的问题。

有这样一个很实际的观点,可以套用到 AutoGLM 沉思上:

今天的 agent 水平,将它视为「主驾驶」可能能力尚有不足。但它仍然是一个很好的副驾驶 (copilot)。

在 AutoGLM 沉思上,我们看到了足够的思考能力,也看到了优秀(但确实受制于客观因素)的 browser use 能力。很显然,智谱作为中国目前非巨头公司当中,少数模型能力最强的选手之一,肯定会在这两个能力上面继续进步,而且会很快。

自从 APPSO 拿到测试资格,到 AutoGLM 沉思正式发布,中间已经更新了数个版本,在模型基座和浏览器操控能力上面都有了改进。

但如果我们想要的是一个真正会思考且能办事的 agent,我们恐怕需要比现有范式的大语言模型更强大的智能体基座。

而智谱推出的「语言+推理+沉思+行动」的 Agent 框架,尽管产品层面仍然笨拙,但看起来是一个非常明确可行的方向。

诚然,国产大模型和基于大模型的 agent 产品,现阶段的目标如果放在「追赶硅谷对手」上可能反而更实际一点。AutoGLM 沉思从操作逻辑和实现目的上,都是明显区别于目前国内所有同类和近似产品的「新物种」,和 Anthropic、OpenAI 也正在拉近距离。

对于这样一家非巨头、脱胎于中国顶级学府的大模型创新领导者来说,大多数的不足都可以被容忍,而看到它在做的事情的独创性和领导性,才更重要。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


独家 | Google 决定终止开源 Android

作者 杜晨
2025年3月27日 12:07

出于新闻报道和纯兴趣讨论目的,爱范儿对知名科技公司的战略做过各式各样的「沙盘推演」,设想了许多场景。

但没想到,最不可能的一种情况,居然正在 Google 身上发生。

Google 已经决定停止 Android 开源项目AOSP

AOSP(Android Open Source Project) 是 Google 主导的开源项目,为所有 Android 设备操作系统提供基础框架和核心组件。它相当于一个「毛坯房」,开发者可自由下载、修改和分发其代码,并基于此构建定制化系统,包括 Xiaomi HyperOS、vivo OriginOS、OPPO 的 ColorOS、甚至 Pixel 手机的 Android 系统,都是基于 AOSP 构建的。

Google 对 Android 的维护分为两条路径:公开的 AOSP 分支面向全球开发者开放,包含纯净的开源代码,不涉及任何 Google 专有服务。任何厂商或个人均可基于此分支开发系统。而内部闭源分支仅供签署了 GMS(Google Mobile Services) 协议的厂商使用。

具体来说,Google 将不再维护目前 AOSP 的公开分支,逐渐关闭相关的的支持性资源,并可能停止更新有法定开源义务(GPL 等协议的代码)外的组件的源代码。

海外媒体 Android Authority 最先报道了这一情况,Google 也确认了此事。

从下周开始,所有的 Android 开发工作将仅在 Google 的内部分支进行。在一段时间后,外部分支可能将不再公开甚至彻底关闭。并且,AOSP 的持续集成/交付 (CI/CD) 工具和环境也可能关闭,甚至 Android Gerrit (https://android-review.googlesource.com/) 也可能会关闭。从今往后,只有 Google 内部的员工能够访问 AOSP 的内部分支,或是提交代码。Android 的开发过程将不再透明。

从高维度来看,Google 将逐步缩减 AOSP 所包含的内容,直至 AOSP 作为开源项目,以及作为一种概念,都不复存在。

以史为鉴,OpenSolaris 项目(也就是 Solaris 操作系统对应的开源项目)在 Oracle 在收购 Sun,宣布对 OpenSolaris「延迟开源」后,直到 Solaris 开发部门解散为止,都没有以 CDDL 许可证开放过半句代码。

谁也不知道,Google 对 Android Authority 承诺的「继续开源,只是推迟」,是不是只是一句空话——毕竟无限期的推迟,也是一种推迟。

根据爱范儿的了解,Android 闭源的总体思路是最终只保留 GPL 强传染许可证要求开源的部分,主要是 Linux 内核态驱动和补丁。其他中层、上层等之前采用 Apache 等宽松开源许可证的部分,最终会闭源;未来的 Android 版本发布后也不再对外公开发布、更新源代码。

此事的决策层级在 Google 高层管理者级别。据信他们做出此决定的时间不晚于 2025 年初。整个策略的执行将会在一个更长的期限内完成,至少持续数年,直到 AOSP 彻底失去意义。

Google 此举的真实动机尚不明确,但根据爱范儿的分析和了解,主要是为了节约开支和增加收入

AOSP 在不同的维度上(比如版本号、发布进度等)有着多条代码流水线和大量的分支。再考虑到项目的上下游代码、多公司之间的协作,进一步复杂化,维护管理起来非常困难,产生大量的计算资源和工时成本。Google 可能希望节约这些成本。考虑到 2025 年初 Android 部门已经向所有员工提供了「自愿离职」的选项,削减开支的思维逻辑不难理解。除此之外,签署了合作伙伴协议的厂家也有义务捆绑 Google 服务,为 Google 提高广告收入,变相提高了公司的整体收入。

好在目前来看,闭源 AOSP 对业界的直接影响并非灾难性,对终端手机用户直观影响也微乎其微。

绝大多数主流手机厂商早就和 Google 签订了各种授权合作伙伴协议。在现有协议安排下的厂商,仍然可以得到和使用最新 Android 源代码,获得 Google GMS 认证,正常预装 Google Play、Gmail 等服务和应用,得到 Google 的支持。一切生意照旧。

真正的影响更多不会直接展现,而是会在更长的时间里从侧面体现。后文会详细解读。

 

AOSP,不存在了?

如下几点需要澄清:

  1. 因为大部分 AOSP 代码通过 Apache 2.0 许可证发行,任何人都可以 fork 一份。其他代码服务平台上也有各种 AOSP 的镜像,例如 GitHub 和国内的 Android 社区。Google 无权要求其它「非官方」 AOSP 代码库下线。已经开源的,无法被撤销开源。
  2. 也就是说,只要能从其他非官方渠道下载,人们仍然可以使用 Google 最后更新的 AOSP 代码,也可以按照自己的需要对其进行修改。原则上如果你有足够多厉害的开发者,也可以把之前的 AOSP 变成自己的系统,去维护和更新。

Android/AOSP 从来不是一个真正的开源项目,社区里的原教旨主义者也一直对其颇有微词。

前文提到,Android 目前运行于 Linux 内核上,后者是 GPL 许可证开源的。GPL 是一个强传染性的许可证,要求所有衍生工作都必须按照 GPL 许可证同样开源,从而贯彻无限开源、扩大社区的精神。

而当年 Google 为了构建 Android 商业生态,创建了平衡开源与商业需求的许可模型。Google 将 Android 平台分为几个部分:底层的 Linux 内核部分保留 GPL v2 许可证(按照要求),而 AOSP 的大部分代码则采用了更为宽松的 Apache 2.0 许可证。这种许可结构使设备制造商能够修改和定制 Android 而不必开源所有修改,同时允许企业在 Android 平台上构建专有应用和服务。Google 自己的专有服务 GMS (Google Mobile Services) 则与 AOSP 分开,并采用不同的许可条款。这种混合方法创建了一个既保持开放性又为生态系统提供商业灵活性的模型。

具体来说,Linux 内核基于 GPL 许可证,虽然 kernel module 需要依据 GPL 强制开源,然而 userspace 应用并不受 GPL 传染性的影响,因此无需开源。部分 userspace 应用程序也与传统的 Linux 发行版不同,例如使用 bionic libc 替代 glibc,使用 toybox 替代 busybox 等。此外,Google 还使用了「硬件抽象层」(HAL),允许厂商将不想公开的商业机密资料,比如一些特定的专有功能对应的背后代码和逻辑,存放在这一层上面,即提供了一套 stable ABI(应用二进制界面),使得厂商可以独立于 Android 框架层更新他们的专有代码。

当然 Linux 基金会对 Google 这种违背开源精神的操作方法很不爽,一度将 AOSP 从 Linux 开源项目中除名。

结果就是,AOSP 底层部分按照 GPL 开源的,大量中层按照 Apache 宽松开源(部分闭源),在此基础上的应用就可以自行按照开发者意愿和商业目的选择各自的开闭源属性了。

Google 自己也是这样做的。事实上,自从 2013 年的 Android 4.4 KitKat 之后,所有的 Android 版本都不再完全开源。Google 为 Android 系统开发的一部分驱动、UI,以及应用层的大量大量核心产品和服务,也就是人们熟知的 GMS 套件,都是闭源的。

AOSP 存在着,但它并不是完整的 Android。这也是为什么很多系统开发者都会强调「原生 Android」(指 Google Nexus/Pixel 的操作系统)不等于 AOSP。

尽管 AOSP 是个开源项目,Google 也不常合并第三方提交的合并请求(合并 AOSP 代码需要 Google 员工的批准,而不少 PR 就死在了 Gerrit Review 里)。这也是不少开发者认为 AOSP 和典型开源项目之间的最大区别。让参与者难以在 AOSP 里获得真正的参与感。

在 AOSP 项目的官网上,Google 写了这样一段「治理理念」:

Google 领导 AOSP,负责维护和进一步开发 Android。尽管 Android 由多个子项目组成,但 AOSP 是严格的项目管理。Google 将 Android 视为一个单一、整体的软件产品,而不是一个发行版、规范或可更换部件的集合,并对其进行管理。Google 的意图是让设备制造商将安卓移植到设备上;他们并不实施规范或策划发行版。

这段话已经把 Google 的意图描述的够清楚了。如果 AOSP 是一头干活的驴,那么卸磨杀驴的时候已到。

 

Android 闭源,将会带来怎样的影响?

主要结论:主流手机品牌和它们的用户不需要担心。

首先让我们重温一下Google 和 Android OEM 之间的协议关系:

  1. AOSP,任何厂商都可以使用 AOSP 进行开发,不需要获得Google 的同意;
  2. Android 兼容性承诺协议 ACC、移动应用分发协议 MADA、企业设备补充协议 EDLA 等,不一而足。通过协议,Google 和 OEM 之间建立商业约束。签订了 ACC 协议的 OEM 通过 AOSP 开发的操作系统,才能够称之为 Android 操作系统,获得 Android 商标使用权等权益。
  3. Google 移动服务 GMS,包括Google 服务核心、账号体系等后台功能,以及前台的 Google Play 商城、YouTube、Gmail、Calendar 等应用。公司签署了上述协议,并且手机型号通过了Google 兼容性测试,才可以预装 GMS。

ACC、MADA/EDLA 等协议的组合,确保了Google 对 Android 操作系统有着大体上的绝对控制。

包括小米、vivo、OPPO、三星等在内的当今绝大多数 Android 手机品牌,和Google 都签订了协议。没有意外的话,Google 应该已经联系它们进行安抚,并且确保未来的合作照常进行了。

在过去有相当一部分设备和芯片厂商,它们利用 AOSP 开发产品,却不从 Google 获得 Android 设备认证,设备不需要预装 GMS 全家桶,也能够避开 Google 的认证要求。

非认证 Android 设备五花八门,数以十亿甚至百亿计。通过这次闭源 AOSP,Google 有可能引诱非认证设备厂商向自己低头,签订前面提到的各种协议。

一种极有可能出现的情况是,基于 AOSP 开发的智慧座舱系统,可能代码也不会再无偿提供给全世界的厂商了。除非车企和 Google 签订协议,它们将无法得到最新的代码。当然,车企也可以继续使用已经开源的旧系统开发。

这不是已经发生的事实,只是一种可能性。Google 这次闭源 Android,不排除有一个小的动机就是试图夺回非认证设备市场,或者至少能够从中分一杯羹。这个大市场,虽然是设备厂商自己打下的,但如果没有 AOSP 确实也不会是今天的样子。

顺着这个角度,非认证 Android 设备消费者可能就会受到影响了,当然同样不会很明显。影响主要来自财务方面:OEM 想继续预装 Android 操作系统,就必须要服从 Google 对设备的管理和要求。这个成本当然会被转嫁给消费者,导致支付更高的价格。除此之外,消费者也只能使用 Google Play 等渠道下载应用,第三方应用市场(例如 F-Droid)等的生存空间也变得更少,Google 也可以向所有的应用内支付收一笔费用。

部分厂商可能不愿意屈从 Google,产品退出市场,消费者的选择权就缩减了;但与此同时,任何 Google 在闭源之前已经发布的 AOSP 代码,理论上仍然可以使用。厂商可以随意 fork 代码,自己开发、更新、维护。估计智能冰箱的消费者不会在意冰箱是否预装最新 Android 操作系统。

不过,这恐怕就又回到了「Android 碎片化」的老生常谈:如果非授权设备厂商继续一意孤行,用老的、不再有官方维护的代码去开发产品,届时碎片化恐怕就不是版本号那么简单了——而是可能出现类似于今天的中国,推送、版本、功能、外观、名称、体验等全方位碎片化,并且向全球范围扩大的一副诡异图景。

开发者权益侵害

AOSP 的闭源,对于 Android 应用第三方 ROM 开发者来说,影响更为明显。

曾经 Android 第三方 ROM 百家争鸣的景象,也将被历史掩埋。ROM 开发者的最好结果,是用 AOSP 最后更新的版本去修改,然后维护当前版本,到它慢慢过时,直至最后放弃这项事业。

至于应用开发者,他们仍然可以从 Google 获取需要的 SDK,在后 AOSP 时代内应该不会有太大的直接影响。

不过在此之前,由于 Android 已经存在相当程度的碎片化情况,开发者为了适配各版本系统、各品牌机型,需要获得不同厂商的系统代码,以及设备作为测试机。这对于中小型,特别是独立开发者来说都是不小的成本。目前尚不清楚这种情况在今后会不会愈演愈烈。

如果中小开发者生存环境被遭到进一步挤压,传导效应就是强者恒强,创新被遏制,进而发生更多的垄断。因此,Google 在做了它该做的事情之后,应该要给出后续方案,确保中小开发者的生存。

最极端,却又最不出意外的做法

此前在中美技术脱钩的大背景下,爱范儿曾经构思过 Android 对中国手机厂商「断供」的几种可能性:禁止在海外销售的手机中显示 Android 商标、禁止预装 GMS、对中国厂商「指向性」闭源 AOSP,甚至中止这些厂商的授权并将其从 OHA 中解约/除名。

在所有可能性中,完全闭源 AOSP 是可能性最低的。爱范儿一度认为这样做实在太不体面了。

在智能移动设备的萌芽阶段,Google 做出开源 Android 的决定,不仅获得了技术开放的名誉,更是在当时将大量厂商和用户从塞班、Windows Mobile,以及诺基亚和黑莓的手中赢了过来。

当然,诺基亚、黑莓和微软各自走了弯路,对Google 获胜起到不小的助攻作用。但 Google 开源 Android,毫无疑问,是今天 Android 在移动操作系统市场抢下超七成份额的道路上,最正确的决定。

Google 内部仍有员工认可开源这项事业的科技普及化意义和长期价值。无论出于业务和上级要求,还是个人身份,他们为 Android 项目编写代码,做维护工作,而 AOSP 也是这些工作的载体。然而 AOSP 对于 Android 和 Google 的商业价值,早已不可同日而语。

尽管这次操作的主要动机是节约成本,但长期来看,也会对 Google 增加收入带来一定帮助。毕竟在过去,Google 很难从那些运行基于 AOSP 操作系统的非认证设备上获得直接收入或数据等间接利益。

在这一事件之前,Google 通过 Android 赚钱的方式,主要是在伙伴协议的框架下对 OEM 进行收费授权认证。 想要在商业合规的框架下使用 Android,厂商需要签署协议。具体协议内容方式等细节可能会有不同,但大的规则是不变的。Google 的主要收入来源是通过预装的Google应用和服务(搜索、Play商店等)获取的广告收入和应用分成。

显然,非认证设备无法给 Google 创造收入,AOSP 的存在却「给人做嫁衣」,作为任何一家商业公司恐怕都想要尽快跟这些设备和厂商切割。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


❌
❌