Omarchy Linux 与 Agent OS 综述：桌面系统、智能体运行时与企业落地¶

过去调整 Linux 桌面，通常要先找配置文件、查语法、修改参数，再重载窗口管理器。现在可以直接描述：“把这个快捷键改成打开我的笔记，保留其他绑定”，由 Agent 查找配置、生成修改并检查结果。应用崩溃后，也可以把日志和调用栈交给 Agent 辅助分析。

Omarchy 把这种工作方式接进了 Linux 桌面。 它由 David Heinemeier Hansson（DHH）发起，以 Arch Linux 为基础，把桌面、开发工具、系统命令和 Agent 的使用习惯整合起来。当前官网明确强调系统可以由 Agent 帮助理解、排障和定制。Omarchy 官网、官方仓库

不过，“Agent OS”还被用来描述智能体服务框架、浏览器和开发规范系统。选择这类产品，首先要看它接管的是哪部分工作。

本文核查于 2026 年 10 月 16 日。Omarchy 发行信息以 4.0.4 为准，命令与配置机制同时对照官方 quattro 分支的固定快照 51bfd1db。滚动手册可能领先发行镜像，文中的命令应结合实际安装版本使用。第 9 节补充了 KubeVirt 安装与 Agent 配置任务的实测，安装完成、桌面和任务界面均来自本次虚拟机；第 2 节的展示图另行标注为官方图片。

1. “Agent OS”目前包含哪些路线¶

操作系统（Operating System，OS）通常负责进程、内存、设备、文件和权限管理。在 Agent 领域，这个名称还被借用来表示“为一批智能体提供共同基础设施”。不同项目管理的对象相差很大。

前五项分别依据 Omarchy、Agno、AIOS、BrowserOS、Builder Methods 的官方说明整理。Harness 的机制可结合本站的 Agent Harness 技术综述 阅读。

例如，Omarchy 上可以运行一个编程 Harness；这个 Harness 可以调用 BrowserOS 的浏览器工具，也可以访问 Agno 发布的远程 Agent。几者能够组合使用，但没有必要把它们装成一套才能开始工作。

2. Omarchy 是怎样的一套 Linux¶

2.1 从预先搭配好的开发桌面开始¶

Arch Linux 提供发行版基础；Hyprland 负责 Wayland 桌面中的窗口布局与合成；Omarchy 再把主题、菜单、快捷键、终端和开发工具组织成一套可直接使用的环境。对熟悉平铺窗口和终端工作流的开发者而言，它减少了从零挑选组件、逐一调试的时间。官方系统架构说明

Omarchy 4，代号 Quattro，于 2026 年 8 月 14 日 UTC 发布。这个版本用基于 Quickshell 的统一桌面 Shell 接管状态栏、启动器、菜单、通知、锁屏等功能，并把 Hyprland 配置迁移到 Lua。旧教程中围绕 Waybar、Walker、Mako 修改桌面的步骤，不能直接套到 4.x。4.0.0 发行说明

图源：Omarchy 4.0.0 官方发行说明，按比例缩小展示。本次 KubeVirt 实测截图见第 9 节。

还有一个容易混淆的细节：4.0.4 已引入项目维护的 linux-omarchy 定制 Linux 内核，官方强调桌面响应、内存压力、硬件兼容及电源管理方面的调整。因此，今天再把它概括成“Arch 的一包主题和配置”已经不够完整。不过，定制 Linux 内核与后文 AIOS 所说的“LLM Kernel”属于不同层次。4.0.4 发行说明

2.2 Agent 如何知道该修改哪里¶

Agent 修改系统的难点，经常在于环境知识：哪个文件是用户覆盖配置，哪个属于软件包；改完以后要重载什么；哪些旧教程已经不适用。

Omarchy 用系统命令和 Skills 补充这些知识。Skill 是一组供 Agent 读取的任务说明及参考资料，例如主题定制、窗口配置、插件开发与截图方法。它降低模型凭印象猜路径的概率，实际修改仍由 Harness 调用命令和文件工具完成。

当前配置约定里，有两类目录需要分清：Dotfiles 手册、Omarchy Skill 源码

这套做法的价值在于把系统经验变成可读取、可更新的资料。Skill 中写着“不要改某个目录”，属于行为约束；操作系统权限、沙箱和工具授权才是执行限制。 二者需要同时考虑。

2.3 集成 Agent，不等于捆绑模型权重¶

Omarchy 为多种编程 Agent 提供启动入口，使用 mise 管理相应工具，很多入口首次运行时才下载实际程序。用户选择默认 Agent 后，可以从菜单、快捷键或命令启动任务。模型账号、订阅或 API 凭据仍要按所选工具配置；本地模型则另有 LM Studio、Ollama 等接入选择。AI 手册

安装 Omarchy 本身并不要求配一张用于大模型推理的 GPU。使用远程模型 API 时，电脑主要承担桌面和工具执行；选择本地模型后，才需要根据模型大小、精度和上下文评估内存、显存与速度。

3. 一个任务怎样从桌面进入 Agent¶

3.1 统一启动入口¶

当前命令体系提供 omarchy default agent <name> 来选择默认 Agent，再通过 omarchy agent prompt "…" 提交任务。后一个命令把提示词交给统一启动脚本，脚本选择实际 Harness 并打开终端。提示词入口源码、启动脚本

对使用者而言，这意味着可以保留同一个桌面入口，再更换背后的 Agent。不同 Harness 的模型能力、工具实现、恢复方式和授权语义仍各自独立，统一入口不会抹平这些差异。

3.2 快捷入口的自动批准行为¶

启动脚本明确以减少交互停顿为目标。例如，4.0.4 对 OpenCode 使用 --auto，对 Copilot 使用 --allow-all，对交互式 Hermes 使用 --yolo，Claude 则采用 --permission-mode auto。这些是各工具自己的模式，保护范围与判断机制不能简单视为完全相同。4.0.4 启动脚本

这种选择适合用户希望 Agent 连续完成个人电脑配置的场景。企业使用时，应先检查实际启动参数和工具策略：能否读取整个用户目录，能否联网，是否可以调用提权程序，是否接触生产凭据。提示词里要求“先给方案”，有助于沟通，但不能替代执行层的授权设置。

这里也可以理解 Omarchy 与普通 Linux 安装一个 Agent 的区别：两者都能运行工具；Omarchy 把默认选择、调用入口、系统知识和桌面反馈预先接好了。便利来自这层集成，权限仍取决于实际执行环境。

3.3 崩溃通知如何变成诊断任务¶

Omarchy 监听 systemd-coredump 记录的进程崩溃，用户点击通知后，可以交给默认 Agent 分析。其 diagnose-crash Skill 要求结合调用栈、日志时间线、资源不足与近期更新判断原因；证据不足时应明确保留不确定性。崩溃诊断 Skill

值得注意的是，Skill 本身把诊断范围限定为读取与分析，修复需要另行处理。因此，“崩溃交给 Agent”不应理解为发现故障后自动改配置，更不能据此承诺所有问题都能自愈。

Core dump 是进程内存的副本，可能包含密码、令牌或文档内容。上游 Skill 也专门提醒这一点。涉及企业应用时，应先确认允许读取和提交哪些材料，再决定是否使用远程模型分析。

4. 用一个配置例子理解它的实际价值¶

假设想让快捷键打开个人笔记目录，可以这样描述需求：

检查当前 Omarchy 版本和用户快捷键配置。找一个没有冲突的组合，用默认编辑器打开 ~/Notes。先列出拟修改文件与差异，保留原有绑定，并说明怎样验证和撤销。

这是一段使用示例，实际授权还要在所选 Harness 中设置。一个可检查的处理过程如下：

1. 读取当前配置与 Omarchy 参考资料，确认正在使用的语法。
2. 检查快捷键冲突、目录是否存在、编辑器入口是否可用。
3. 只修改对应用户配置，并保留修改前的文件。
4. 检查语法、重载相关组件，再实际触发快捷键。
5. 若验证失败，恢复原文件，并确认其他快捷键仍可使用。

图中“确认差异、保留备份、验收与恢复”是本文建议的使用流程，需要用户和 Harness 配合落实。

这个例子的收益比较具体：用户不必先学完整个桌面配置体系，就能完成一项小改动；系统提供的路径、命令和 Skill 帮助 Agent 缩小搜索范围。对于防火墙、启动项和磁盘布局一类改动，影响范围会扩大，仍需要相应的备份、恢复入口和变更判断。

5. 其他 Agent OS 各自解决什么问题¶

5.1 Agno AgentOS：把 Agent 做成服务¶

Agno SDK 用于构建 Agent、团队和工作流，AgentOS 基于 FastAPI 把它们发布为服务。它提供 API、流式输出、会话持久化、工具接入，以及可选的授权和追踪配置。流式输出常使用服务器发送事件（Server-Sent Events，SSE）；工具互通可以使用模型上下文协议（Model Context Protocol，MCP）。Agno Runtime

它更适合这样的需求：一个团队维护多个业务 Agent，希望通过统一 API 提交任务，查看会话、工具调用、评估和审批。Control Plane 提供浏览器界面，具体执行与权限检查由选中的 AgentOS 端点负责；显示哪些数据，取决于运行时和数据库启用了哪些能力。Control Plane

服务重启后能否继续执行，还要单独看任务队列。当前文档区分普通后台执行与持久队列：配置持久队列和匹配的 Worker，才能让已接受的可排队任务在崩溃、部署后恢复处理。即便如此，外部写入仍需考虑重复执行与幂等。后台执行与持久队列

如果目标是企业服务化，Agno 这一类运行时比桌面发行版更接近问题本身；如果目标是改变个人电脑的交互方式，Omarchy 提供的桌面集成更直接。

5.2 AIOS：借鉴操作系统思想管理 Agent 资源¶

AIOS 的研究起点是多个 Agent 同时使用模型和工具时产生的资源争用。论文于 2024 年 3 月 25 日 首次提交，后发表于 COLM 2025，提出把调度、上下文、记忆、存储和访问控制抽成共同服务。AIOS 论文

项目将核心称为 AIOS Kernel，通过 Cerebrum SDK 与 Agent 交互。官方架构说明把这一层放在已有操作系统内核之上：它管理 Agent 所需的模型与工具资源，宿主仍负责进程、设备和底层内存管理。AIOS 官方架构

可以类比为多人共用一间实验室：宿主操作系统管理房间、电源和设备；AIOS 尝试管理每个人什么时候使用模型、保留哪些上下文、如何访问工具。它值得关注的方向，是把各 Agent 重复实现的资源管理工作集中起来。

这里的“调度”与 Kubernetes 为 Pod 选择节点，以及 Linux 为线程分配 CPU 时间，管理对象不同。采用 AIOS 后，GPU 容量、模型推理排队与容器隔离仍需由相应基础设施承担。

5.3 BrowserOS：让已有 Agent 获得浏览器工作环境¶

当前 BrowserOS 仓库同时维护两种产品：BrowserOS 是带内置 Agent 的 Chromium 浏览器；BrowserOS neo 则定位为供已有 Agent 使用的第二个浏览器，可以导入登录状态，连接支持 MCP 的工具，展示并回放任务会话。BrowserOS 官方说明

对于“从已登录的业务系统整理一份报告”，持久登录、可见的标签页和回放比更换整个桌面系统更贴近需求。它也可以与 Omarchy、普通 Linux、macOS 或 Windows 搭配。

浏览器保留了登录态，也就保留了账号能力。多个任务拥有独立标签页，并不意味着已经实现不同员工、租户之间的安全隔离。还要区分浏览器数据存放本地与模型推理位置：Agent 选择远程模型时，相关上下文的数据流需要另行核对。

5.4 Builder Methods Agent OS：组织开发上下文¶

这个同名项目用于提取代码规范、按任务提供相关规范、形成需求规格，并组织这些资料。它与已有编程 Agent 配合，解决“项目约定怎样持续进入上下文”的问题。Builder Methods Agent OS

例如，团队约定接口错误结构、数据库迁移方式和测试目录布局，可以把它们整理成规范，再按当前任务提供给 Agent。它适合改善代码一致性；进程托管、桌面、模型服务和租户隔离则由其他系统负责。

6. Agent 获得电脑权限后，哪些边界最重要¶

6.1 系统安全与 Agent 授权要分别看¶

Omarchy 官方说明默认安装使用 LUKS（Linux Unified Key Setup）磁盘加密，并启用入站防火墙。前者主要保护设备丢失后的离线数据，后者限制网络入站访问。Security 手册

Agent 已经以用户身份运行后，能够读取哪些文件、调用哪些程序、向哪个模型发送内容，取决于运行时授权和系统权限。加密磁盘解锁后，不会阻止当前用户的 Agent 读取其有权访问的文件；入站防火墙也不等于模型请求的出站数据策略。

因此，企业落地至少要明确三件事：给它什么身份，允许它使用哪些工具，任务数据可以发到哪里。桌面体验做得越顺畅，越应让这些边界容易理解和检查。

6.2 切换模型账号不等于隔离员工数据¶

Omarchy 的账号管理方便同一位用户切换所支持的提供方账号。当前手册说明，历史、设置、Skills 等内容会共享，已有会话仍沿用启动时的账号。这种功能适用于个人工作流，不能直接充当企业多租户的数据边界。Agent 账号说明

如果多位员工共享一台机器，应另外设计操作系统账号、用户目录、凭据和执行环境隔离。一个桌面内切换模型登录，与不同员工拥有独立工作空间，是两种不同需求。

6.3 系统快照、个人文件与任务续跑是三件事¶

Omarchy 支持更新时创建系统快照，也提供手动创建与恢复入口；相关启动恢复能力依赖 Limine。官方特别说明：恢复覆盖根文件系统，不恢复 /home，所以用户的 ~/.config 也会保留当前状态。系统快照手册

假设 Agent 改坏了 ~/.config，只恢复系统快照，原来的错误配置可能依然存在；假设它已经发出一次外部请求，回滚本地磁盘也不会撤销远端结果。任务恢复需要在应用层设计，详见 Agent 长任务中断续跑。

7. 企业使用时，怎样与 Kubernetes 分工¶

桌面系统适合人和 Agent 共同使用一台电脑。面向多人、长期运行的服务，则需要把身份、执行环境、状态和证据分别安排好。下面是一种组合建议，代表工程设计思路。

7.1 桌面是入口，任务执行可以独立部署¶

开发者可以从 Omarchy、已有桌面或 Web 门户提交任务。后台以 API 接收任务，经过权限检查和排队，再交给执行环境。纯命令行任务适合容器；依赖完整桌面、浏览器登录与交互状态的任务，可以评估独立虚拟机。

这里的取舍取决于任务：容器通常更容易形成可重复的运行环境，虚拟机更接近一台持久电脑。两者都需要独立的凭据和持久化策略，相关边界见 Agent Sandbox 选型。

Omarchy 可以作为个人工作站，也可以是特定交互式虚拟机的系统选择。无图形界面的 Agent Worker 通常可以沿用团队已经维护的基础镜像，不必为了运行 Harness 增加完整桌面。

7.2 状态和产物放在哪里¶

任务记录应保存输入、执行版本、步骤状态、工具结果和最终产物。进程退出以后，下一次执行才能判断完成到哪一步，哪些操作允许重试。模型记忆和聊天历史有助于提供上下文，但不能独自承担任务状态机的职责。

例如，容器工作目录可以使用持久卷保存，结构化任务状态放在数据库，大文件与报告放在对象存储。恢复时先读取状态和回执，再继续尚未完成的步骤。这个设计同时适用于 Agno 一类运行时和自行封装的 Harness，具体实现要对照所选框架。

7.3 应观察什么效果¶

CPU、内存和 Pod 存活能说明基础设施状态，评价 Agent 工作效果还应记录：任务完成比例、验证通过情况、人工介入次数、模型与工具调用耗时，以及失败后是否重复执行。

一次任务最好有稳定的任务标识，关联模型调用、工具执行、重试、文件变更和最终检查。浏览器回放适合查看页面操作；执行追踪适合定位某一步为何变慢；产物验证用来判断目标是否达成。几类证据结合起来，才能解释“运行结束了”和“工作做对了”之间的差异。Agent 评估方法

8. 如何判断自己是否需要这一类产品¶

体验 Omarchy 时，可以先参考官方提供的 Try Omarchy 虚拟机方式，或在独立环境使用发行镜像。先选几项可验证的小任务：调整一处快捷键、生成主题、分析一次有证据的崩溃、恢复一项错误配置。关注它能否解释修改、正确验收，以及撤销后能否恢复原状。

同样的任务，也可以在现有 Linux 加上同一个 Harness 执行一次。这样更容易看出 Omarchy 的收益来自哪里：预先配置的工具、系统知识、统一交互，还是模型本身的能力。成本也应包含迁移配置、维护升级和人工检查的时间，而不能只计算模型调用费。

9. KubeVirt 实测：用一台无 GPU 虚拟机体验完整桌面¶

为了观察 Omarchy 的实际工作方式，这次在已有 KubeVirt 环境里创建了一台独立虚拟机，从官方 ISO 安装系统，再让 OpenCode 读取系统知识、生成用户配置。模型使用远程 API，虚拟机只负责桌面和工具执行。

9.1 实际配置与版本¶

这里的 4 vCPU、8 GiB 是一次功能体验的配置，并非官方最低要求或容量压测结果。桌面刚启动、尚未运行 Agent 时，来宾系统 free -h 显示约 1.6 GiB used、6.2 GiB available；打开终端和任务界面后，宿主侧运行 Pod 的一次采样约为 89m CPU、4308 MiB 内存。两处统计口径与采样时刻不同，不能直接相减推断虚拟化开销。

本次为可丢弃实验，选择了未加密安装，并使用独立账号、独立 SSH 密钥。它与前文介绍的默认加密物理安装不同，不应照搬为企业终端的安全配置。

9.2 从官方 ISO 安装，而不是仅启动一个容器¶

安装使用官方支持的 unattended 机制：将配置文件放到卷标为 cidata 的介质中，与 ISO 一起挂入 VM。磁盘配置只指向这台 VM 新建的 VirtIO 根盘；安装器需要格式化磁盘，不能把宿主设备直接传进去。官方无人值守安装手册

安装器最终显示 Installed Omarchy in 4m31s。这是安装器统计的阶段耗时，不包含下载、上传 ISO、创建 PVC 和排查挂载的时间。

本次 VM 的原始显示画面。系统随后从持久根盘启动，并进入图形登录页。

部署时遇到一个实际问题：上传 ISO 的 Pod 仍以读写方式挂载安装盘，VM 又请求只读挂载同一卷，本地 CSI 驱动因此拒绝第二次挂载，VM 一直停在启动阶段。结束上传、核对文件校验和并删除上传 Pod 后，VM 正常启动。上传完成以后释放卷的使用者，是安装流程的一部分；不能只看到文件已传完就开始等待来宾系统。

9.3 无独立 GPU，桌面是否真的能打开¶

登录后，Hyprland 和 Quickshell 都正常运行，可以打开菜单、终端和应用；systemctl --user --failed 没有失败单元。下面是本次 VM 的桌面，并非上游宣传图。

来宾中的 EGL 探针得到：

EGL:      1.5
Renderer: llvmpipe (LLVM 22.1.8, 256 bits)
Vendor:   Mesa
OpenGL:   OpenGL ES 3.2 Mesa 26.2.2-arch1.1

这说明本次图形能力来自 CPU 软件渲染，不是虚拟机获得了独立 GPU。结合实际桌面截图，可以确认这套版本组合能够做低成本功能体验；它不能用来推断高分辨率、多用户或视频工作负载的体验。

日志中仍有 Bochs 设备相关的 EGL、DRM 渲染初始化警告。因此，即使桌面能够使用，也不能把这次结果解释为图形兼容性完全通过。对于长期工作站，仍应评估带图形加速的虚拟设备或物理桌面。已有环境是 KubeVirt 1.4.1，不能直接照抄新版文档才支持的 devices.video 字段；本次保留已有平台配置完成验证。

9.4 让 Agent 根据实际系统生成一处配置¶

为了验证第 4 节的工作流，这次选择了一项影响范围很小的任务：给笔记目录增加快捷键，先生成提案，再检查和应用。提示词的核心要求是：

读取已安装 Omarchy 的 Skill、Hyprland 说明、用户与默认快捷键配置。检查 SUPER + CTRL + F12 是否冲突，为其生成名为 Lab notes 的绑定，打开 ~/Notes。保留原配置，只把完整提案和审查说明写到实验工作目录；不要修改当前生效配置，不使用 sudo，不访问凭据或外部网络。

OpenCode 通过文件和命令工具读取了实际系统资料，检查默认绑定与 hyprctl binds，生成 proposed-bindings.lua 和 REVIEW.md。任务窗口如下：

界面中的 Remote Chat Model 和 Lab model gateway 是实验显示名称；实际调用远程模型 API。截图里的费用为工具显示值，未据此计算真实费用。

提案保留了原文件，只追加下面一条绑定及说明：

o.bind("SUPER + CTRL + F12", "Lab notes",
  "nautilus --new-window /home/omarchy/Notes")

检查差异后，先备份用户配置，再将提案应用到 ~/.config/hypr/bindings.lua。luac -p 语法检查通过；执行 hyprctl reload 后，hyprctl configerrors 为空，运行时能查到一条 Lab notes 绑定，修饰键掩码为 68，即 Super 与 Ctrl。

这里还遇到了两类集成问题。第一，VM 直连模型网关超时，办公机调用同一网关正常，因此改用 VM loopback → SSH 转发 → 办公机 loopback 转发器 → 模型网关。实际凭据留在办公机，没有复制进来宾系统；这次证明的是通过该路径可以完成模型与工具交互，不能据此认定 VM 的直接出网已经解决。

第二，非交互运行最初被外部目录授权阻止，写入工具又受到路径规则限制，最终记录显示文件通过允许的 Shell 命令生成。这也说明，按命令名称配置权限，并不等于文件系统沙箱：例如允许 cat 的规则还要考虑重定向。实验中没有生产凭据，提案经差异检查后才应用；企业落地应另行限制操作系统身份、可写路径与网络出口，不能把本次任务成功当作权限隔离测试通过。OpenCode 权限说明

9.5 验证撤销，再验证持久磁盘¶

配置验收没有停在“Agent 说完成”。先恢复备份并重载，运行时 Lab notes 数量变为 0；再次应用提案并重载，数量恢复为 1，两次配置错误检查均为空。这样可以确认这项改动能够撤销，原有配置也有独立备份。

随后关闭 VM，卸下安装 ISO 和 cidata 介质，再从原根盘重新启动。Kubernetes 中的 VMI（VirtualMachineInstance，虚拟机运行实例）和 virt-launcher Pod 均已更换，来宾 boot ID 也改变，因此这次检查跨越了真实的运行实例重建。

重建后重新登录，通过 noVNC 发送 Super + Ctrl + F12，文件管理器确实打开了 Notes，其中仍有重建前创建的 README.md。

输出来自重建后实际执行的检查命令，文件校验清单在重建前生成。图中的 pacman 软件源索引未同步警告予以保留，本地包版本查询和后续校验正常完成。截图与脱敏后的结果摘要见 实验结果记录。

这里验证的是同一持久磁盘上的系统与用户状态保留。它不等同于恢复一个正在执行的 Agent 任务，也没有测试节点故障迁移。本次使用节点本地卷，节点不可用时，磁盘不会自动出现在另一台节点上；如果要向多人提供持续桌面，需要另行选择共享存储、备份与故障恢复方案。

对于低成本试用，这样的一台 VM 已经能观察到 Omarchy 的主要集成价值：系统知识可以被 Agent 读取，配置改动有可审查的文件差异，桌面操作能验收结果，持久根盘能保留个人环境。对实际使用影响较大的问题则是软件渲染、浏览器远程键盘转发，以及来宾系统到模型网关的网络路径，不能只检查安装器是否退出成功。

10. 这条路线值得关注的变化¶

Omarchy 展示了桌面软件的一种变化：配置文件、系统命令、日志与开发工具逐步成为 Agent 可利用的接口，用户通过描述目标参与系统定制。项目提供的默认搭配和环境知识，决定了这种交互有多顺畅。

Agno、AIOS 与 BrowserOS 分别补充了服务托管、资源管理和浏览器执行能力。“Agent OS”目前更像一组正在汇合的工程方向，尚不宜用一个名称推断它已经包含全部能力。对个人，先看能否减少日常操作负担；对企业，继续追问任务由谁执行、状态在哪里、如何限制权限，以及结果怎样验证。

参考资料¶

• Omarchy 官网与手册
• Omarchy 4.0.0：Quattro 发行说明
• Omarchy 4.0.4：定制 Linux 内核
• Omarchy AI、默认 Agent 与账号管理
• Omarchy Dotfiles、系统快照、安全
• Agno Runtime、Control Plane、后台执行
• AIOS 项目、AIOS 论文
• BrowserOS 与 BrowserOS neo
• Builder Methods Agent OS