从 twm 说起

twm（Tom 的 Window Manager，也作 Tabbed Window Manager）是 X Window System 上的第一个窗口管理器。在 1980 年代，图形界面随苹果 Macintosh 与初生的 Windows 席卷个人电脑，但 X11 走的是另一条路：它只提供一组图形原语，让开发者用零散的组件拼出界面，而不是交付一个完整的桌面整体。窗口如何摆放由窗口管理器负责，文件导航交给文件管理器，桌面背景另有程序设置。

twm 取代了更早、连窗口边框都不画的 uwm（Ultrix Window Manager），并开始支持用标签页把多个窗口归为一组，思路与今天的标签页浏览一脉相承。尽管后来被更现代的窗口管理器取代，twm 至今仍被视为参考实现并持续维护。

FVWM 带来虚拟桌面

1990 年代早期，Linux 用户逐渐增多，但 GNOME 与 KDE 尚未诞生，图形能力也有限。当时 X11 对硬件要求不低，许多用户干脆只用文本终端。FVWM 由 Robert Nation 在 1993 年基于 twm 改造而来——他当时需要一套能在低配笔记本上运行、用于信号分析的系统，于是给 FVWM 加上了虚拟桌面，并大幅压缩内存占用。

所谓虚拟桌面，是让一块屏幕被划分成多个桌面，用户可以随意切换，在当年显示器比工作站小得多的个人电脑上格外实用。这一功能后来在类 Unix 系统上普及，并最终进入 Windows 的现代版本。FVWM 至今仍是轻量 Linux 系统的可选方案。

Enlightenment 与 Window Maker

1990 年代末，Carsten Haitzler 创立了 Enlightenment。彼时 Linux 正因成为廉价的网络服务器与互联网基础设施而声名鹊起，个人电脑也已有余力流畅运行 X。Enlightenment 比此前的窗口管理器更加野心勃勃，在别人力求精简时不断堆功能，一度被认为臃肿，却拥有忠实的用户群，最终事实上成长为一个完整的桌面环境。

另一个分支 vtwm 也是最早支持虚拟桌面的窗口管理器之一，它还引入了类似今日 Windows 任务栏的图标管理器，用来调出已最小化的程序。而受 NeXTSTEP 启发的 Window Maker，则延续了那种优雅而克制的设计语言——NeXTSTEP 虽未获商业成功，却深刻影响了后来的 macOS 乃至 iPhone。

这些古老的窗口管理器之所以沿用至今，不仅因为资源占用极低，也因为它们承载了一段计算史。今天看似理所当然的桌面功能，许多都源自那个什么都自己拼的 Unix 年代。

来源：How-To Geek（作者 David Delony，2026 年 8 月 16 日）

开源远程桌面工具 RustDesk 近期放出一个预览版构建，首次在 Linux 的 Wayland 显示协议下提供了「真正的无人值守远程访问」：配置完成后，即便远端电脑前空无一人，也能从登录界面直接连入，并且支持多显示器环境。对于长期被 Wayland 远程控制短板困扰的 Linux 用户来说，这是一次迟到但关键的能力补齐。

之前卡在哪：Wayland 不让人「偷偷连」

Wayland 作为新一代显示协议，在安全性上比老旧的 X11 更严格，却也把远程桌面的很多「理所当然」打掉了——尤其是无人值守场景：传统方案要么要求远端有人点击批准每一次会话，要么干脆只支持 X11 会话。RustDesk 团队在公告中写道，Wayland 支持一直是 Linux 远程桌面里最难啃的部分之一。新构建让会话不再依赖远端有人值守，重启机器后也能从登录界面接手，多显示器同样可用。

预览版先用起来，再进主流发行版

目前该能力以独立预览版形式放出，面向 x86_64 架构、基于 Debian/Ubuntu 的发行版，版本号为 1.4.9（安装包以 .deb 提供）。RustDesk 表示希望在转为默认行为前收集更多真实环境反馈；一旦实现稳定，计划把无人值守 Wayland 访问带到 Fedora、Arch Linux 等更多发行版，并最终并入标准版 RustDesk。团队也呼吁正在使用 Wayland、尤其是多显示器的用户试用预览版并反馈问题。

横向对比：友商还在「实验」阶段

RustDesk 在公告中顺势点名了两家商业对手的差距：AnyDesk 目前在 Linux 入站会话上仍要求 Xorg；TeamViewer 则把 Wayland 支持描述为常见桌面环境下的「实验性」能力。换句话说，在 Wayland 无人值守这一具体方向上，这款开源方案暂时走在了商业软件前面。

对中文用户而言，RustDesk 的意义不止于「又多一个远程工具」。作为 TeamViewer、AnyDesk 的开源替代，它在国内长期拥有相当人气，常被用作自建中继、注重数据自主的远程控制方案；而 ToDesk 等国产同类产品也在快速迭代。Wayland 如今已是 Ubuntu、Fedora 等主流发行版的默认或推荐选项，能否在 Wayland 下提供和 X11 一样顺滑的无人值守体验，正在成为远程桌面工具的新分水岭。

来源：RustDesk 官方博客（经 Hacker News 收录）

一条流水线式的调研流程

用户提出问题后，Mole 会先把问题拆解成子问题，再依次执行检索、抓取、提取主张、逐条核对引用、寻找主张之间的矛盾，最后综合出带引文的答案。

具体来说，规划器把任务分解为子问题并随证据动态调整；执行器为每一条线索预留并结算预算；抓取端完成搜索、读取、提取「主张」这一步时，要求每条主张都附带与源页面逐字匹配的引文；核验端则把相关主张两两配对、裁定冲突、构建关系图，并对样本重新回读；输出阶段再从通过核验的主张中综合出答案。

预算是硬上限，不是估算

Mole 最特别的地方，在于预算不是「建议值」而是架构层面的强制约束。每次模型调用前，系统会在账本里先预留额度，调用结束后再结算，账本本身不允许出现负数。`–usd 0.50` 意味着运行严格停在 50 美分，官方测试语料的溢出率为 0%。

同样，可验证引用要求每条主张必须携带出自源页面、逐字匹配的引文，否则在提取阶段就被丢弃；留存的命题之后还能被重新回读核查，无法支撑的说法会在报告里被标记出来。

本地数据不出本机

分析本地 CSV 或文件夹时，Mole 的内容留在机器内。模型只能选择假设模板和列名，真正的 SQL 由 Mole 渲染并执行，返回结果仅限于聚合值——计数、均值，以及不少于 5 条记录的的分桶统计。想知道有哪些信息离开了本机，可以执行 `mole crossings` 做审计。

Mole 提供两种运行模式。自主模式下，Mole 持有模型，负责规划、挖掘和撰写；工具包模式下，推理由调用方自己的模型完成，Mole 只负责确定性较强的一半工作，比如引文检查、配对检索和 SQL 渲染，适合已经订阅了 Claude、通义千问等服务的用户。

模型与安装

抓取端支持网页、学术（Crossref、OpenAlex、arXiv、PubMed）和本地计算三类数据源，并内置了 SSRF 防护、 robots 协议处理和速率限制。模型方面可接入 Anthropic（如 Claude Sonnet 5、Claude Haiku 4.5），以及 DeepSeek、Ollama、llama.cpp、vLLM 等兼容 OpenAI 接口的端点；搜索提供商支持 Tavily 与 Brave。密钥存放在权限为 0600 的本地配置文件里，不会写进环境变量或工程配置。

安装渠道很全：一条带 SHA-256 校验的脚本命令、Homebrew、Arch 的 AUR、Debian/Ubuntu 的 deb/rpm 包，以及 Go 1.25 以上的源码编译都可用。项目以 Apache-2.0 许可证发布。

对开发者而言，Mole 解决的正是三类痛点：聊天式联网搜索成本不可控，它用硬预算把溢出压到零；模型容易编造引文，它用逐字核查把不实主张挡在门外；本地敏感数据怕外泄，它用隐私边界只输出聚合量。对于已订阅大模型服务的团队，工具包模式还能把闲置的算力复用起来。

来源：GitHub 项目 lajosdeme/mole

长期混迹 Linux 桌面的人，大多有一段「反复横跳」的经历：今天装这个发行版，明天删那个，最后在某个熟悉的系统上安定下来。科技媒体 How-To Geek 的作者 David J. Buck 就是这样一个典型——他用了很久 Linux Mint 的 Cinnamon 桌面，却在虚拟机里试过 Debian 13（代号 Trixie）之后，直言这块系统修好了他对 Mint 最大的几处不满，下一台设备打算直接把 Debian 装进主分区。

一次虚拟机里的「试水」

Buck 的 Linux 履历不算短：早年玩过树莓派上的 Raspbian、也用过 Ubuntu，中间回归过一段 Windows，最终落在 Linux Mint 并积累了不少经验。让他重新动心的，是 Debian 13 这个新版本。他先在 Mint 本机上用一条命令装好 Gnome Boxes 虚拟机工具（也可走 Flathub 的 Flatpak 渠道），再在虚拟机里以图形化方式安装 Debian。

体验的反差从安装就开始了。他回忆，当年第一次装 Linux Mint，是从 U 盘引导 ISO，过程「大致算引导式安装，但在他的机器上折腾了一会儿才跑起来」；而 Debian 13 在 Gnome Boxes 里「几分钟就装完，而且全程有引导」，和那些需要更多手动操作的发行版完全不同。Gnome Boxes 底层基于 QEMU/KVM，比传统虚拟机方案更轻量。

三处体验差异：安装、桌面与文件管理器

装好之后，最让 Buck 意外的不是某个炫酷功能，而是日常手感的顺滑。他把 Debian 13 的桌面形容为「和 Cinnamon 有相似之处，但感觉非常顺滑」。与 Mint 不同，Debian 13 没有明显的主菜单按钮，而是右上角一个搜索栏加一条类似 macOS 的应用栏——习惯之后效率不低。

真正的分水岭在文件管理器。Buck 写道，Debian 13 的文件管理器比 Mint 更流畅，而且他「不必再为了文件夹内图片预览和像样的截图能力去额外装 Sushi 或 Flameshot」。Sushi 和 Flameshot 是两款在 Mint 上常被补装的实用小工具，一个负责空格预览，一个负责截图标注；Debian 13 开箱就把这类能力备齐了。对一个每天在文件夹里翻图、随手截图的人来说，这种「不用折腾」的体感差异，比参数表上的项目更影响日常满意度。

他的总体评价也很直白：Debian 13 比 Mint「更直观、也更有意思」。这句话听起来主观，但落到操作上，指的就是上面这些少装软件、少绕弯子的细节。

预装生态与包管理：开箱即用的底气

另一个被点名夸的是「开箱即用的软件储备」。Buck 说，Debian 13（Trixie）基本带齐了他需要的绝大部分东西，还提供像 Debian HamRadio 这样按用途策展的元数据包——一类面向业余无线电爱好者的工具集合。他自己平时用终端跑 Python、写 Textual 界面程序，也用 CHIRP、PyQSO 这两款火腿无线电应用，这些在 Debian 的生态里都能顺畅就位。

包管理上两者其实同源：Linux Mint 基于 Ubuntu，Ubuntu 又衍生自 Debian，所以 apt 这套命令两家通用。区别不在「能不能装」，而在「装好之后顺不顺」。Buck 的体会是，Debian 13 把常用工具和按需扩展组织得更省心，让他愿意把它当成下一台机器的首选。

不是换坑，是多了一种踏实

值得说明的是，Buck 并没有把 Mint 说得一无是处——他仍喜欢 Mint，只是「开始觉得，当初安定下来之前，应该多花点时间和 Debian 相处」。他计划「百分之百把 Debian 作为下一台设备（无论办公、家庭实验室还是别的用途）的主分区」。

对普通用户而言，这篇体验的价值不在于「Mint 不好」，而在于把一个常见误区说清了：很多人默认 Mint 是对新手最友好的 Debian 衍生版，于是装机直接从 Mint 起步，却没意识到原版 Debian 如今的图形安装和开箱体验，已经友好到可以作为日常主力。想尝鲜又怕折腾的人，完全可以先在虚拟机里用 Gnome Boxes 跑一趟 Debian 13，几分钟就能判断它是否对味。

来源：How-To Geek（作者 David J. Buck，2026 年 8 月 14 日）

免 root 的真发行版

UserLAnd 是一款免费、开源、上架 Google Play 的应用。它的核心思路并不玄乎：借助 PRoot（chroot 系统调用的用户态实现）搭配一套自研的 SSH 或 VNC 连接层，在安卓现有内核之上圈出一块隔离的 Linux 环境。因为安卓本身基于 Linux，内核本就兼容 Linux 二进制文件，所以 UserLAnd 可以直接运行发行版原生的软件包，既不需要重新编译，也不需要做完整虚拟化。

打开应用后，用户会看到一份可选清单：完整发行版涵盖 Ubuntu、Debian、Kali Linux、Alpine 等；也可以只挑单个应用环境，比如独立启动一个 Firefox，或者开一段 XFCE 桌面会话。选好之后走一遍简短的设置，应用会自动下载文件系统镜像、配置环境，几分钟内就能进入一个可用的命令行或图形桌面。整个过程不需要任何命令行「黑魔法」，这正是它和多数同类方案最不一样的地方。

和 Termux 到底差在哪

常被拿来比较的 Termux 更像是一个终端模拟器加包管理器，它在安卓上提供了一套类 Linux 的命令行环境，但本质上不是一套「完整发行版」——你没有原生的 systemd、没有标准的桌面栈，很多需要真发行版支撑的软件跑起来并不顺。

UserLAnd 走的是另一条路：它给的是货真价实的发行版，带原生的包管理器（apt、apk 等），可以像在一台普通电脑上那样安装 GIMP、LibreOffice、Firefox，也能通过 VNC 或 XSDL 把 LXDE、Xfce4 这类桌面环境投到屏幕上。换言之，Termux 适合「在手机里敲命令」，UserLAnd 适合「在手机里跑一台 Linux 电脑」。

还有哪些替代方案

想在同一方向更进一步，也有别的选项，但各有门槛。Andronix 同样主打安卓上的完整发行版，不过部分功能需要订阅；Linux Deploy 能力更强，却要求设备已经 root；QEMU 走的是纯模拟路线，兼容性最好但性能损耗明显，在手机上偏慢。UserLAnd 的定位恰好卡在中间：零门槛、免 root、开箱即用，代价是 PRoot 用户态隔离带来了一定运行开销，性能上限不如真正拿到 root 的方案。

怎么用、能用来做什么

实际连接时，UserLAnd 支持 SSH、VNC、XSDL 三种访问方式。选命令行就本地 SSH 直连；想要图形界面，则启动 VNC 服务，再用手机上的 VNC 客户端连到本机即可。一个实用的细节是：同一个文件系统可以挂在多个会话上，既能开一个轻量 SSH 会话敲命令，也能同时开一个 VNC 图形会话，看当下需要灵活切换。

对开发者而言，它相当于把一台随身 Linux 实验机装进了口袋——临时编译、跑脚本、验证环境都很方便；对普通爱好者，则能在手机上体验 GIMP 修图、LibreOffice 写文档，或把手机当成一个可被其他电脑通过 SSH 接入的小型服务器。

边界与取舍

需要清醒看待的是，UserLAnd 不是为了替代桌面或服务器而生。图形界面依赖 VNC / X Server 中转，安卓直接掌控 GPU，桌面渲染的流畅度受手机硬件制约；PRoot 的隔离也意味着它无法做到真 root 那般贴近系统底层。它最适合的场景，是「想要一个真正的 Linux 环境，但又不想解锁 bootloader、不想冒 root 风险」的轻度到中度需求。

对这类用户来说，UserLAnd 把原本需要手动折腾 chroot、配网络、挂文件系统的繁琐流程，压缩成了几次点选。想顺手在安卓上拥有一台完整 Linux，它确实是目前门槛最低的那一个。

来源：How-To Geek（作者 Arol Wright）

支持哪些发行版

该应用面向全球发布，Linux 用户可在其中使用 ChatGPT、ChatGPT Work 与 Codex。OpenAI 列出的受支持发行版包括 Ubuntu 24.04 与 26.04 长期支持版（LTS）、Debian 13，以及 Fedora 43 与 44。Linux 社区由数百个发行版组成，OpenAI 选择的这些版本是众多「下游」桌面发行版的基础，因此衍生版本也应当兼容。

对开发者群体而言，原生 Linux 客户端意味着无需再依赖浏览器标签页或命令行工具，即可在本地调用 ChatGPT 与 Codex；ChatGPT Work 则是面向企业的版本，支持团队与企业级功能。

落后竞争对手一个月

在 Linux 桌面端，OpenAI 其实慢了一步。竞争对手 Anthropic 约一个月前已发布 Claude 的 Linux 桌面应用，支持 Ubuntu 22.04 等版本。随着 ChatGPT 桌面版登陆 Linux，两大主流 AI 聊天工具均已覆盖 Windows、macOS 与 Linux 三大平台，开源开发者长期呼吁的本地客户端终于落地。

由于本次发布仍处于预览阶段，部分功能与发行版兼容性可能随后续更新逐步完善。

来源：TechCrunch

一、下载安装并选择模型

1. 到 GitHub 的 eigent-ai/eigent 仓库下载安装包，按提示完成安装。它采用 Electron 前端加 Python 后端的架构，开箱即用，无需自己搭环境。
2. 打开设置页选模型：本地方案可选 Ollama、LM Studio、vLLM、SGLang、LLaMA.cpp；云端则填入自备密钥，支持 Gemini、Anthropic、OpenAI、Grok、Qwen、DeepSeek、Moonshot 等。切换只是下拉框里选一下，小显卡跑本地模型卡顿时也能随时退回云端。

二、用内置智能体与技能干活

1. 开箱自带五类专用智能体：Developer（拥有终端、代码执行、文件操作）、Search、Document、Multi-Modal、Social Media，各自带着工具箱，不必从零搭工作流。
2. 系统内置 200 多个 MCP 工具（Notion、Google Calendar、Slack、GitHub 等），也能自行接入更多。
3. 用 Skills 沉淀个人流程：新建一个文件夹，写入 SKILL.md 描述触发条件与行为（结构与 Claude Skills 一致），之后一条命令就能触发。例如写一个读取心愿单、比价本地零售商并生成带日期报告的任务。

三、隔离浏览器与访问本机文件

1. 浏览器工具会在应用内通过 Playwright 拉起独立的 Chromium 实例，每次任务都从全新无痕会话开始，不携带本机浏览器的 Cookie、登录态和历史，避免身份泄露。
2. 默认每个任务被沙箱到自己工作目录；若要操作目录外的文件夹，在应用里新建一个指向该文件夹的 Space（下拉一次即可），否则会拒绝访问。

注意事项：Eigent 基于 CAMEL-AI 多代理框架，适合做知识管理、调研和自动化，并非只给开发者用。首次访问沙箱外目录记得先建 Space，否则任务会被拒。

来源：XDA Developers

换了一条技术路线

在 Triton 之前，社区尝试过一种“偷梁换柱”的做法：把开源实现的 d3d11.dll 和 dxgi.dll 直接丢到游戏目录里，让程序加载这些替代文件而不是 Windows 自带的系统库。这种办法确实能让部分游戏跑起来，但代价明显。

UTM 团队在技术博客中列出了三个硬伤：一是性能上不去，桌面合成器把画面当成一张普通图片处理，需要用处理器把显存里的图像逐帧搬到窗口位置，桌面体验不可能流畅；二是这两个文件属于系统核心组件，无法整体替换，带反作弊机制的游戏还会把这种改动直接判定为作弊；三是每装一个游戏就要复制一次文件，谈不上什么使用体验。

Triton 走的是另一条路——不去实现 DirectX 的应用接口，而是实现设备驱动接口，也就是显卡厂商真正要做的那一层。应用程序照常调用系统的 Direct3D 库，系统再把整理过的指令交给驱动，驱动通过虚拟化通道把活儿甩给宿主机。整套链路里，Windows 客户机看到的是一块“正常显卡”，而不是被人动过手脚的系统文件。

为什么没照抄现成方案

开源世界里能参考的样本极少。团队提到，Mesa 项目有一个 DirectX 10 的用户态驱动，但受限于苹果系统上虚拟图形渲染组件的功能缺失，无法直接沿用；VirtualBox 拥有目前唯一可用的开源 DirectX 11 用户态驱动，却被两个理由排除在外。

第一是技术上的顾虑。VirtualBox 的做法是把驱动接口调用先编译成一种中间字节码，再由宿主机把字节码还原成 DirectX 调用。多出来的这道转换意味着更多延迟和更多出错机会，社区论坛上大量游戏在 VirtualBox 中跑不起来，正与此有关。第二是许可协议不兼容，VirtualBox 采用的协议与 QEMU 和虚拟图形渲染组件所用的宽松协议存在冲突，代码无法直接引入。

Triton 的思路更取巧：既然系统的 Direct3D 库负责把接口调用翻译成驱动指令，那驱动这一侧干脆做一次“逆向翻译”，把指令还原回标准的 DirectX 调用，再交给此前已经跑通的传输层送到宿主机。宿主机收到的东西本身就是可以直接执行的调用，省掉了解释器这一整个环节。

苹果电脑上的进展与遗留问题

在 Linux 宿主机上，画面最终由 DXVK 转译成 Vulkan 完成渲染，已经能看到 Windows 桌面合成正常工作。苹果电脑这边情况更复杂：Vulkan 本身要再经过一层转译才能落到 Metal 上，稳定性和兼容性都有欠缺。团队因此把重心放在 DXMT 上——这个项目跳过中间环节，直接把 DirectX 11 翻译成 Metal，团队为它做了原生版本的分支，补上了共享纹理和共享栅栏这两项虚拟化必需的能力。

按照官方说法，目前这套驱动的稳定性还谈不上成熟，部分场景仍会崩溃，也尚未随 UTM 正式版本发布。相关代码已经分散在多个开源仓库中公开，包括 QEMU 的定制分支、虚拟图形渲染组件的分支以及 DXMT 的原生化改造版本，愿意自行编译的用户可以提前尝鲜。

对普通用户来说，这件事的意义或许要等到功能正式集成进 UTM 之后才能体会。但对开源虚拟化生态而言，QEMU 第一次在 Windows 客户机上拥有了完整的现代图形驱动栈，这条路走通本身就比跑起哪一款游戏更重要。

来源：UTM Blog

谷歌 DeepMind 与谷歌研究院联合开发的人工智能模型 WeatherNext 选择了后者。在登陆前五天，它以 80% 的置信度预测，这团风暴将以五级飓风的形态登陆牙买加。

结果是飓风梅丽莎（Melissa）带来了灾难性的洪水与山体滑坡。但因为这份提前量，预报员得以更早向沿途社区发出警告。这也是美国国家飓风中心（NHC）首次在风暴还只是一级强度时，就成功预判出它会升级为五级。

一天的提前量，等于十年的进步

2026 年 8 月 6 日，相关研究成果发表于《自然》（Nature）杂志。论文显示，WeatherNext 在热带气旋预报上的准确度达到了前所未有的水平：在路径、强度、风场结构三项指标上，相比现有主流业务模型平均多出至少 24 小时的预警提前量。换句话说，它提前三天给出的预报，精度相当于过去模型提前两天的水平。

研究人员表示，按照以往的节奏，把预报提前一天需要整整十年的持续攻关。

这多出来的一天意味着什么？美国国家飓风中心主任迈克·布伦南（Mike Brennan）给出的答案很直接：「哪怕只多几个小时都会有区别。」组织疏散、调配物资、把应急资源提前送到位，全都是对时间高度敏感的工作，一旦判断失误，代价极其沉重。「在这类决策上，时间是真正的黄金，能把预报精度往前推整整一天，价值非常大。」

作为参照，过去五十年间热带气旋在全球已造成超过 70 万人死亡和约 1.4 万亿美元的经济损失。

少见的样本，怎么训练模型

极端天气对机器学习本身就是个难题：模型需要大量训练数据，而极端事件按定义就是罕见的。

「气旋数据并不多，但天气数据很多。」论文第一作者之一、谷歌 DeepMind 研究科学家费兰·阿莱特（Ferran Alet）解释了团队的思路，「所以我们训练了一个既擅长常规天气、也擅长气旋的模型。」最终的训练素材包含近 20TB 的大气数据，以及 IBTrACS 数据库中近 5000 场历史风暴记录。

飓风难预测的另一层原因在于它同时涉及多个空间尺度。论文作者之一、大气研究合作研究所（CIRA）热带气旋研究组负责人凯特·马斯格雷夫（Kate Musgrave）指出：判断风暴往哪走，需要全球尺度的天气数据，比如冷锋位置和盛行风；而判断风暴会变多强，则要依赖局地的大气与海洋条件。「后面这类信息，全球模型根本给不了。」她说，早前的 AI 模型在预测路径上已经不错，「但强度这块完全不行。」

在真正投入实战之前，团队先用历史数据做了回溯测试。「结果好到让我们怀疑实时演示里根本达不到。」马斯格雷夫回忆，但预报员把模型接入实际业务流程后，表现依旧成立，「所有人都对它的实际效果感到意外。」

连开发者也解释不了的「黑箱」

真正让业界震动的，是这套模型对输入数据精度的要求低得离谱。

传统观点认为，要准确预报风暴强度，必须依赖极高的空间分辨率。而 WeatherNext Cyclones 的输入数据只有 28×28 公里的粗网格，比传统区域模型粗约 100 倍；更精简的 WeatherNext 2-mini 甚至跑在 111×111 公里的网格上，表现依然出色。

「当我们告诉同行模型只用了相对粗糙的分辨率时，他们都震惊了，因为这意味着低分辨率输入里包含的信号，比此前认为的要多得多。」阿莱特说。

至于模型究竟从粗网格里捕捉到了什么，研究者自己也答不上来。「说到底它就是个黑箱，但这给了物理学家一个信号——有些此前没被理解的东西正在发生。」

另一处关键改进是集合预报规模。模型不会只吐出一个结论，而是生成一整组可能情景，用来捕捉所谓的「蝴蝶效应」。去年每场风暴生成 50 组情景，今年已扩大到 1000 组。「以现有算力，传统数值模型根本做不到这一点。」马斯格雷夫说。一次 15 天的预报，在单块 TPU 上跑完不到一分钟。

开源，以及人的位置

谷歌 DeepMind 同时宣布，将飓风季实际运行的 WeatherNext 系列模型开源，代码与权重一并公开，托管在 GitHub 上。开放的版本包括论文对应的 WeatherNext Cyclones、后续升级的 WeatherNext 2，以及可在单块 TPU 上运行的精简版 WeatherNext 2-mini。阿莱特希望，把模型交给研究社区，能帮忙揭开气旋运行机制中尚未被理解的部分。

不过这项研究由参与开发的团队自行评估，论文合著者中包含国家飓风中心、大气研究合作研究所与英国气象局的预报员。

布伦南对这套工具的评价保持克制。他认为 DeepMind 的模型是预报员工具箱里一件很棒的新装备，但也只是众多工具之一：「没有任何保证说，某个模型因为去年表现好、或者在某场风暴上特别准，下一个季度、下一场风暴它还是最好的。」

在他看来，人的判断依旧不可替代：「一场飓风不只是一条路径或一个强度预报，它需要专家把这些数字翻译成实际影响——而真正致命的是影响本身。」

来源：WIRED、Google DeepMind 官方博客、《自然》杂志

Cloudflare 给出的答案叫 Cloudflare OS。8 月 5 日，这家公司宣布把它开源，任何组织都可以自行部署、接入内部系统并按需改造。

先在自家跑了三个月

今年 5 月，Cloudflare 向全体员工开放了第一个版本。据其官方博客描述，各职能部门数千人每天使用，其中很多人并非工程师——他们用它撰写文档和幻灯片、把重复性任务自动化、搭建小型应用来可视化数据。

更关键的是共享层。Cloudflare OS 为所有人提供了一个由各团队共建的上下文与技能库，把公司的术语、流程和处理常规工作的最佳做法，沉淀成智能体可以直接遵循的指令。一个人摸索出更好的做法，其他人立刻就能复用。

第一版也暴露了问题。它以个人私有工作区为中心，生成的应用是静态的，而非连接内部系统的活体软件；即便是几乎完全确定的重复任务，也得重新跑一遍智能体技能，白白消耗模型 token（模型处理文本的计费单位）。

协作环节的问题更根本。接入 MCP 服务（模型上下文协议，用于让智能体调用外部工具）只能告诉系统智能体可以调用哪些工具，却无法说明它实际读取过哪些底层资源。一旦开始共享工作区、应用和产出，就必须确保协作不会让人看到本不该看到的信息。

于是 Cloudflare 把整套系统在新底座上重建了一遍，核心判断是：安全必须是平台自带的能力，而不是每个搭应用、用智能体的人各自去正确实现一遍。

三个组成部分

新版 Cloudflare OS 由三块拼成：一个以公司自建上下文与技能为基础的智能体工作区，内置可让智能体编写并运行代码的隔离运行时；一套面向内部数据与服务的安全治理框架；以及一个支持个人搭建、共享并持续修改应用的平台。

工作区在浏览器里使用，不需要懂终端。它能做四类事：调用公司上下文与已授权资源做研究，且智能体是通过写代码去搜索、筛选、连接和分析信息，而不是把整个数据集塞进模型的上下文窗口；把研究结果转成可继续编辑的文档、演示或表格，这些产出可以与实时数据保持连接、随数据源更新，也能导出为常见格式；在文档表格不够用时，直接构建带界面、逻辑和状态的应用，供多人协同；以及把已知步骤的重复工作转成基本确定性的流程，用代码处理可预测部分，只在真正需要判断的环节调用模型，流程可按需触发、定时执行或由连接系统的事件驱动。

安全设计：智能体的默认权限是零

员工接触 AI 后最常提的诉求，往往是索要公司系统的 API 密钥。Cloudflare 的判断很明确：把密钥直接交给人和智能体既危险也无法规模化，密钥通常权限宽泛、有效期长，难以约束、难以安全共享、难以审计。

Cloudflare OS 的做法分三层。

默认无权限。 由 Cloudflare Access 控制谁能进入系统，进来之后每个智能体和应用的初始权限是零。智能体可以申请访问某个具体资源，由人决定批准或拒绝，生成的代码以类型化绑定的形式拿到该资源，凭据始终与智能体和代码完全隔离。服务端代码运行在关闭了全局出站网络的 Dynamic Worker 中，客户端代码运行在浏览器的沙箱框架内，两者除了显式授予的能力之外都无法访问互联网。

Gatekeeper 管资源和动作。 这是一个针对特定服务的 Worker，夹在 Cloudflare OS 与外部服务之间，理解该服务的接口、资源和可执行操作。官方举的例子是：把整个 GitHub 账号交给智能体范围太大，而 Gatekeeper 可以只开放单个仓库、只允许读取议题而不能读源码、屏蔽特定字段、施加速率限制，并要求合并请求前必须经人工审批。智能体看到的只是一个小巧的 TypeScript 接口，OAuth 授权、凭据保管、策略执行、读取记录和外部副作用的中介，全部由 Gatekeeper 承担。

策略跟着智能体看过的东西走。 只管住第一次读取是不够的。官方设想了这样一种场景：智能体读取数据仓库中一张敏感表，据此生成实时看板，分享看板不能变成把这张表分享给无权访问的人。为此，Cloudflare OS 记录智能体观察到的每一项资源，这些记录始终附着在智能体及其产出上。当另一个人试图打开工作区、与智能体交互或查看产出时，Gatekeeper 会核验此人对那些被观察资源的访问权限。同一套观察日志还用于判定智能体何时可以发起外部请求——读取过敏感数据，可能就会禁止它向特定目标写入、邀请新协作者、把工作移交给另一个智能体或发起外部请求。

每一个“文件”都是一个完整应用

多数生产力套件给的是固定几件套：文档、表格、演示。Cloudflare OS 的思路不同——每个“文件”都可以是一个应用，由智能体为某个人、某个项目或某个团队专门编写。

这些不是需要导出再另行部署的原型，而是自带客户端代码、服务端代码、接口和持久状态的全栈应用，默认私有，可像文档一样共享。智能体写应用时产出两部分：渲染界面的客户端代码，以及存储状态、实现逻辑的服务端代码。服务端以 Dynamic Worker 按需加载，并实例化为 Durable Object Facet（这两项能力都是为该项目专门构建的）。Facet 给每个应用一个独立的 SQLite 数据库，与管理它的运行时相互分离；Dynamic Workers 使用轻量级 V8 隔离环境，因此每个应用都能拥有独立运行时，而不必长期占用一台服务器或容器。

浏览器客户端通过 Cap’n Web 与服务端通信，这是 Cloudflare 开源的对象能力式远程过程调用系统。服务端方法可以像普通 JavaScript 函数一样从客户端调用——特别之处在于，智能体也能调用同一个方法。用官方博客的说法，只要一个人能造出工具来完成某项工作，那么在这个人不在的时候，智能体也能用同一件工具把活干完。

共享方式有两种：共享应用本身，其他人可基于同一份状态实时协作；共享应用的“蓝图”，其他人可创建属于自己的副本。从蓝图创建的应用包含原应用的代码，但不包含其 SQLite 数据、对话历史、凭据和已连接资源，每个新应用都从独立的状态和资源开始。这意味着团队成员可以自己用 AI 修改应用，而不必提工单等着原作者排期。

模型可换，花销可控

Cloudflare OS 支持任意模型，所有推理调用都经由 Cloudflare AI Gateway，组织可在同一处决定哪些模型可用、哪项工作交给哪个模型。官方给出的理由很实际：不是每项任务都需要最贵的模型——每天早上总结未读邮件，未必值得动用最昂贵的前沿模型。

每一次请求都会归属到发起它的人、团队或工作区。管理员可以看到推理支出流向，设定预算与速率限制，并决定触及上限后如何处理。

开源之后

代码已在 GitHub 的 cloudflare-os 仓库放出，可部署到自有 Cloudflare 账号，配合自家的 Access 策略、AI Gateway 配置、数据与集成。Cloudflare 一共发布两个仓库：Cloudflare OS 核心，以及一个基于其内部运行方式的示例部署；部署仓库不修改核心即可使用，用于承载配置、自定义界面、内部集成、分析和部署流水线。

值得一提的是，该项目在 GitHub 上把自己类比为一套真正的操作系统：workshop-backend 相当于内核，各类 Gatekeeper 相当于设备驱动，workshop-frontend 相当于 shell，Gadget 相当于进程，蓝图相当于可执行文件。而传统操作系统尚未管理的那一类对象，正是 AI 智能体——Cloudflare 的观点是，智能体不能简单当成用户对待，它必须对某个人类用户负责，同时拥有自己受限的权限，这种场景下更合适的安全模型是基于能力的安全，而非访问控制列表。

由于 Cloudflare Workers 的运行时 workerd 本身也是开源的，Cloudflare OS 并不局限于只能跑在 Cloudflare 上，完全可以架在自有服务器的 workerd 之上。

代码只是起点。Cloudflare 表示，其战略伙伴 Presidio 和 Happy Cog 会协助企业按自身运作方式定制并推广。后续规划包括：把 Cloudflare OS 做成 Cloudflare 控制台中的全托管产品、为开发流程增加容器支持，以及把工作区接入 Slack 等聊天工具。

来源：The Cloudflare Blog