AutoOS：从 Language as OS 到 AI、语言与系统的协作
资料截至 2026 年 10 月 1 日。历史节点来自设计文档、代码提交和已归档计划；未来方向按当前项目理念说明。
返回 OS 总览 · 了解当前桌面 · 阅读 AI 生态的演进
AutoOS 最初从一个语言问题出发：如果一种语言能够描述应用、界面、并发任务和系统能力，它能否进一步成为组织操作系统的基础？
这个问题后来有了两个相互承接的表达。Language as OS（LaOS）关注系统如何实现：用 Auto 组织部件，让语言与运行环境适配不同生态。OS over OS 关注目前如何使用：让 AutoOS 的虚拟桌面在已有系统上运行，与宿主桌面共存。长期的 AI + Lang + OS 则进一步问：这样的系统怎样帮助人管理知识、处理工作和安排生活？
理解这段演进，需要同时看理念和工程。前者解释为什么要做，后者说明哪些已经成为产品、哪些仍是研究与规划。
起点：让语言能够表达系统
在目前可追溯的仓库记录中，2025 年 12 月已有关于 OS、Task 与生命周期的设计提交。早期 LaOS 文档将进程、线程和任务放进同一个讨论框架，尝试让程序中的状态、执行与资源寿命具有系统层面的意义。早期设计提交
这不表示当时已有操作系统，也不表示那份历史文档中的每个语法例子都是今天的接口。它留下的是一个起点：语言的职责可以延伸到“系统由什么组成、部件如何运行和协作”。
LaOS 的范围因此不只包括内核。UI 库、合成器、桌面、系统应用、配置、启动器、监控、Shell 和系统服务，都是可以用语言组织的部件。不同设备可以采用不同的底层实现，面向应用和人的接口则尽量保持一致。
这里的“一致”包括命令、UI、通知、启动与通信等语义。它是一项需要逐层兑现的工程目标。当前底层仍主要依赖 Rust 和既有系统生态；AutoOS 尚未实现自己的内核。
从应用界面走向桌面
跨平台 UI 的推进使 LaOS 有了一个具体入口。AutoUI 已有浏览器与原生桌面运行路径，但多个应用能分别打开窗口，并不自动产生一套完整的桌面体验。焦点、窗口排布、工作区、任务栏和启动器之间，还需要共同的语义。
2026 年 8 月 26 日的虚拟桌面设计将这条边界明确下来：桌面 App 负责窗口语义，宿主负责合成。窗口外观、交互和桌面表面尽量由 AutoUI 描述；不同宿主负责把它们显示出来、连接输入与平台能力。虚拟桌面设计 · 奠基提交
这使桌面成为可组合的运行环境。独立应用窗口与虚拟桌面可以共享模型：一个单独窗口是较简单的配置，多个应用则由桌面组织。浏览器和原生宿主的显示方式不同，应用的组件、布局和交互定义可以继续复用。
设计也明确了现实的一致性口径：布局、交互和主题逐项验证，平台文字栅格化等差异仍然存在。这样，一致体验有了可以检查的对象，而不只是一个形容词。
OS over OS：从现有系统中生长
虚拟桌面带来了一个渐进的产品形态。人可以继续使用宿主系统，在其中打开 AutoOS 的桌面和自带应用。已有内核、驱动、文件系统和网络能力继续提供基础，AutoOS 逐步建设自己的外壳与工作环境。
OS over OS 就是从这个视角描述 LaOS。它使系统建设可以从已有环境开始，先形成可使用、可验证的桌面，再推进更深的平台接入。
宿主应用的兼容与协作也是这条路线的一部分。项目已有针对具体平台的原生窗口、剪贴板等接入工作；具体支持仍取决于平台与接缝。自带应用、宿主应用以及不同进程的渲染来源，要共享桌面体验，仍需分别解决窗口、输入和通信问题。
Linux 方向提供了另一种接入环境。2026 年 9 月，Smithay 宿主 Stage 1 已完成嵌套合成循环、纹理呈现和桌面首帧验证。此时它验证的是宿主接缝的早期基础，完整 Linux 桌面会话、驱动集成和发行版产品还有后续工作。Smithay 当前模块说明 · Stage 1 计划
语言框架与产品逐渐分工
2026 年 9 月 7 日，auto-os 作为产品组织根建立。此前集中在语言仓中的桌面表面、应用资产与产品集成，开始有了自己的归属。auto-os 初始提交
这次分工沿两条轴展开：auto-lang 继续维护语言、编译器、VM 与 AutoUI 框架；auto-os 组织桌面表面、系统应用和产品集成。桌面 Shell 资产迁入产品仓，语言仓保留必要的运行接缝和同步回退。应用清单也把独立工具接入同一个桌面组织方式。迁移设计 · 桌面表面迁移提交
它改变了“框架示例”和“实际产品”的关系。教学示例用于验证语言与组件，产品应用还要承担配置、启动、数据、持续使用和版本维护。看板、终端、编辑器、知识工具和监控等项目，可以各自演进，再通过集成规则进入桌面。
这些应用的成熟度和实现方式并不相同。当前集合应从实际应用清单与各项目状态了解，而不是用一个固定总数代表所有能力。应用集成清单
渲染与运行形态继续演进
桌面成形后，另一个问题变得突出：解释执行适合快速修改，而编译后的应用和跨进程渲染需要稳定的接口。窗口语义已经有了共同定义，渲染来源还需要共同协议。
2026 年 9 月的桌面 Shell 编译化设计保留了两种路径：解释装载支持开发迭代；编译形态通过协议与合成宿主协作。RenderQueue、桌面状态投影和命令接缝因此成为分离应用、桌面与合成器的重要基础。桌面 Shell 编译化设计
这些路径不能简化成“解释器已经被替换”。应用的实际运行方式由集成声明与启动实现选择，解释执行、编译生成和原生接入继续保留各自用途；RQHost 桌面端点也已经进入启动流程。两条桌面壳路径的设计 · RQHost 启动接入
这段演进说明，系统的一致性需要来自组件定义、协议与验证。应用位于同一进程还是不同进程、使用解释还是编译形态，都是可以按场景选择的实现条件。
当前 AutoOS 到了哪里
目前可以看到的 AutoOS，是由多项已实现能力组成的宿主桌面环境：窗口与工作区、桌面表面、启动器、配置中心，以及集成清单中的系统应用和独立工作工具。
AutoShell 提供命令和脚本接口；AutoTerm 提供终端能力；配置项目管理应用和系统设置；AI 项目提供模型服务与 Agent 基础。这些部件逐步通过语言、UI 与系统接缝连接起来。
它们仍依赖宿主提供的基础能力，平台与功能覆盖也有具体范围。系统的下一阶段，需要继续把可运行的部件变成可持续使用、可部署和可维护的整体。
未来的三种运行形态
接下来可以从三个层次理解 AutoOS 的发展方向。
与宿主共存的虚拟桌面继续改善跨应用工作体验，并逐步接入宿主应用和能力。这是最直接的当前产品路线。
复用现有内核的独立系统在适合的设备上提供桌面与系统外壳。Linux 内核与必要服务是一条方向；与 OpenHarmony 结合也是长期产品选项。具体设备适配、系统服务、部署与维护需要分别完成。早期 COSMIC 探索是这段历史的一部分，当前目标没有被限定为某一种固定发行版。OpenHarmony 方向记录
拥有自有内核的完整系统是更长期的研究方向。LaOS 的长期设想也包含未来由 Auto 继续实现底层部件、探索语言底座的自实现原生路径。目前没有自有内核，相关方向需要新的设计、实现和验证。
三种形态共享理念和已有部件，推进到哪一层，应由实际需求与技术条件决定。
从桌面延伸到知识与工作生活
更长期的 AI + Lang + OS，把问题重新交回使用系统的人：知识能否持续保存和联系起来？任务能否在应用之间衔接？AI 能否帮助理解和处理工作，而让人始终看清状态与结果？
AI 深入参与了 Auto 的开发，也正在成为共享服务和应用能力。AutoLang 提供表达数据、操作与界面的底座；OS 和应用承载知识、任务与日常使用。现有看板、编辑器、知识工具、Shell 与 Agent 应用，已经提供了一些起点。
这些入口还需要继续连接。统一的个人知识体系、跨应用长期协作，以及更广的工作生活场景，仍有产品和工程问题需要解决。AutoOS 的未来展望因此可以从人的任务出发：在适配不同设备与生态的同时，让知识、工具和工作成果形成可理解、可掌控的环境。