Canonical将AI融入Ubuntu的方式,微软应当学习

Canonical工程副总裁Jon Seager近日发文,详述Ubuntu 26.04如何以开放、克制的方式整合AI:优先采用开放权重模型,默认本地推理,不将系统品牌化为AI产品。AI功能分为"隐式"(后台静默增强,如语音识别、无障碍功能)和"显式"(用户主动选择的AI工作流)两类。相比之下,微软将Copilot强制嵌入Windows与Microsoft 365,依赖云端处理并形成厂商锁定。Canonical的路线强调本地控制、开源透明与用户自主选择。

Canonical工程副总裁Jon Seager在一篇新博文中详细介绍了公司如何将AI融入Ubuntu Linux 26.04及后续版本的桌面与服务器体验。与微软在Windows中将Copilot标签贴得到处都是的做法不同,Canonical以开放的方式将AI集成到Linux发行版中:尽可能采用开放模型,默认本地推理,且不将发行版重新包装成AI产品。

Seager表示,Canonical正在"以专注且有原则的方式加大对AI工具的使用"。这一方法意味着明确倾向于采用许可条款与Ubuntu长期开源价值观相符的开放权重模型,同时配合开源工具链。Canonical的开发团队可以自行选择适合自己的工具,但要求在团队层面保持统一。

他强调,Ubuntu不会被重新定位为AI产品,但"经过深思熟虑的AI集成"将使这一操作系统对已经依赖它的用户来说更加强大和高效。在内部,Canonical计划对工程师开展培训,明确AI真正能带来价值的场景,并避免使用"你用了多少AI"这类粗糙的度量方式,转而关注AI辅助工作的质量、可控性和可审查性。

Ubuntu AI框架的核心在于区分"隐式"与"显式"AI功能。隐式AI功能将主要在后台运行,增强Linux现有能力,用户感受到的是"系统变得更好用了",而非一个新的AI产品。例如,Ubuntu 26.04提供一流的语音转文字和文字转语音功能,以及由本地模型驱动的更强屏幕阅读和无障碍改进。

显式AI功能则以全新的可选功能形式出现,并明确标注为AI驱动。这些功能可能包括生产力工作流中的生成式文本工具、用于文件或项目管理的智能体助手,以及直接与模型交互的专用界面。Seager将这一方式描述为分阶段推进:首先悄然提升Ubuntu的现有能力,再为主动有需求的用户叠加"AI原生"工作流。

不想使用这些AI功能?完全没问题。但在Windows 11上,你很难做到这一点。

Ubuntu的AI路线以本地运行为核心。Canonical希望大多数Ubuntu AI功能默认在设备端推理,这使得这些功能可以离线使用,潜在隐私性更强,也不依赖专有云端后端,同时使用成本更低。

这一方向与Canonical在内核调优、GPU及加速器硬件支持以及与芯片厂商合作方面的现有工作相互呼应,为普通Ubuntu安装实现高效本地推理奠定了基础。

无障碍访问是此次AI推进的首批具体目标之一。Seager将系统级语音转文字、文字转语音以及更丰富的屏幕阅读能力定位为核心操作系统功能,而非炫目的"AI附加功能"。他展望道:"今天看似只有借助前沿AI工厂才能实现的事情,在未来数月乃至数年内将变得触手可及。"

除单项功能外,Canonical还在推动Ubuntu成为AI智能体和智能体工作流更安全的运行平台。Seager表示,用户与智能体协作已越来越普遍,他"非常期待"通过智能体驱动的界面让Linux的强大能力变得更易获取。目标是打造一个"上下文感知操作系统",智能体能够理解用户的环境和任务,同时受到Ubuntu现有安全模型的约束。

在这方面,Ubuntu默认的应用容器方案Snap成为Canonical保障AI智能体安全的手段。通过Snap,智能体将在沙箱中运行,无法访问受限数据和资源。Canonical正在探索以"符合用户群体期待、尊重隐私和安全价值观"的方式集成此类工作流,并明确回应了社区对AI被强加的忧虑。

在微软将AI作为核心品牌标签大力推广的背景下,Seager着力凸显Ubuntu方式的差异。他拒绝以AI产出量来衡量Canonical员工的绩效,也表示公司不打算将AI"强加"给用户或将Ubuntu变成一个以AI为核心的产品。与此同时,他坦承AI对工程工作的影响:虽然Canonical无意用AI取代员工,但擅用AI工具的工程师确实可能超越不善用者。

用户不应期待有一个通用的"AI关闭开关"。Seager坦言,实现这样的开关在技术上相当复杂,因为部分AI功能将融入后台系统改进,而非以独立应用的形式存在。重点在于保持AI功能的约束性、可审计性,并符合开源预期,同时让Ubuntu在AI迅速成为现代计算基础的世界中持续演进。

Canonical明确倾向于采用开放权重模型、开源工具链,以及与自由软件价值观相符的模型许可协议,而非单纯追求基准测试中表现最优的模型。Seager指出:"获取模型权重固然有意义,但这与开源社区所习惯的透明度并不等同。"他补充道,Canonical将依据许可条款而非仅凭性能来选择模型。

相比之下,微软的主流AI布局依托专有云服务,如Microsoft 365的Copilot和Azure OpenAI。微软确实允许使用多种模型,但微软始终是把关者——在Windows中使用AI,必须遵守微软的规则,包括其定价、政策和遥测机制。

Canonical的计划是将本地推理设为默认。理想情况下,所有AI增强的操作系统功能应在设备上离线运行,仅在真正需要外部服务时才通过明确定义的接口调用。这一方式发挥了Linux在硬件调优和GPU/加速器支持方面的优势,同时将数据和工作流留在用户自己的设备上。

微软的策略则是"云优先":Windows和Microsoft 365中的Copilot从根本上依赖云端托管的模型和数据处理,即使部分客户端NPU参与其中也不例外。这种方式便于大规模推出功能,但同时也集中了数据和算力,加深了厂商依赖,并让用户更难了解或限制数据的流向。

正如Seager所述,Ubuntu将AI区分为"隐式"(悄然提升语音转文字、屏幕阅读等无障碍能力)和"显式"(用户可自主选择采用的新型AI工作流或智能体),目的是让AI使Ubuntu"真正更强大",而非将其打造为AI品牌产品,也不强迫不需要AI的用户接受。

微软的立场则是将AI推入默认用户体验:Copilot直接出现在Windows Shell和Microsoft 365应用中,微软还在探索在365内置持续运行的智能体,作为办公工作流的运营层。如果你已深度绑定微软生态,这自然很有吸引力,而且显然有很多人对此并无异议——但在我看来,这未免有些短视。

然而,绑定微软意味着你必须默认与AI交互,而非经过深思熟虑后主动选择。你现在能接受,当AI成本持续攀升时,你还能坦然面对吗?

Canonical的AI方案高度依赖Ubuntu现有的安全机制,尤其是Snap隔离,为AI智能体提供严格限定的权限、清晰的可审计性,以及从只读分析到受控写入的不同访问等级。目标是打造一个"上下文感知操作系统",智能体可以发挥强大作用,但运行在透明的开源沙箱中,用户和审计人员均可审查。

微软的智能体方向更侧重于将智能体直接集成到业务工作流中,例如可跨邮件、文档和业务系统操作的Microsoft 365智能体。这种集成有利于自动化,但用户难以理解其运作机制,治理依赖于IT管理员配置的策略控制台和连接器,而非用户可见、可独立审查和分叉的开放安全模型。

Canonical将Ubuntu定位为本地AI实验和开源工作流的低门槛平台,开发者可以轻松替换模型、框架和工具,便于团队在实验阶段使用本地模型、向量数据库和智能体框架进行原型开发,并有效避免厂商锁定。

微软的优势在于庞大的用户基础和高度集成的工具链,但这种深度集成也使得早期实验更容易演变为对微软技术栈的长期依赖,数据、工作流和治理全部绑定于同一厂商。

如果你重视开放模型、本地控制以及了解和塑造AI融入系统方式的能力,Ubuntu是你的理想选择。微软的模式对于深度耦合的云优先企业工作流颇具吸引力,但它以开放性和可移植性换取了锁定、深度集成与便利。我已经知道自己会选择哪一种。

Q&A

Q1:Ubuntu 26.04的AI功能和Windows的Copilot有什么区别?

A:Ubuntu 26.04的AI功能默认在本地设备上运行,优先使用开放权重模型,不强制用户使用,分为隐式(后台静默增强)和显式(用户主动选择)两类。而Windows的Copilot依托微软专有云服务,深度嵌入默认用户体验,用户难以关闭,且数据处理依赖微软云端,存在较强的厂商锁定。

Q2:Ubuntu的AI功能可以关闭吗?

A:Canonical并未提供一个通用的"AI关闭开关",因为部分AI功能会融入后台系统改进,难以独立关闭。但Canonical的原则是不强迫用户使用AI,显式AI功能均为可选项,整体设计强调约束性和可审计性,用户对AI功能有较高的自主权。

Q3:Canonical在Ubuntu中如何保障AI智能体的安全?

A:Canonical利用Ubuntu默认的应用容器方案Snap来保障AI智能体安全。通过Snap沙箱机制,智能体被限制在严格限定的权限范围内运行,无法随意访问受限数据和资源,并提供从只读分析到受控写入的不同访问等级,整个安全模型透明、可审查,符合开源社区的预期。

来源:ZDNET

0赞

好文章,需要你的鼓励

2026

04/29

09:36

分享

点赞

邮件订阅