如果你喜欢 Rust ，喜欢 AI，喜欢 Omarchy ，欢迎来今年深圳 RustChinaConf 2026 现场交流。大会官网： https://rustchinaconf.org/

早鸟票 / 议题征集/ 赞助商招募 均以开启。欢迎联系。

RustChinaConf 2026 早鸟票开售｜10 月 15–17 日，深圳

RustChinaConf 2026 CFP Open

RustChinaConf 2026 赞助商招募开启

如果你只是把 Omarchy 看作又一个 Linux 定制桌面，而不是面向 Agent 的 Native 桌面 OS，那你可能会错过一些东西。我说的只是可能性。 本文不是传道，只是在我高强度使用 Omarchy 十天之后的简单分享。

Omarchy 并不是简单地在 Linux 桌面里预装一个聊天机器人。它通过统一 CLI、版本化 Skills、Hyprland 桌面控制、Quickshell 交互界面和 mise 工具供应链，把系统组织成一个适合人类持续监督、随时委托和快速接管的 Agent 工作台。

我认为对 Omarchy 当前更准确的定位是： 一个为 coding agent 精心整理过操作面的桌面 Linux，而不是一个由 agent 安全自治的 OS。

 它已经解决了 agent 使用 Linux 最常见的三个问题：

  1. 不知道有哪些能力。

  2. 不知道应该修改哪一层。

  3. 修改后不知道怎样验证。

  但尚未彻底解决另外三个更难的问题：

  1. agent 获得了哪些能力。

  2. 一次操作实际改变了什么。

  3. 出错时能否自动、精确地恢复。

当然，也可能我看的很片面，总之，Omarchy 的未来我很期待啊。

总之，Omarchy 在“Agent 能否发现并调用系统能力”方面已经非常成熟；它目前更接近一个 agent-ready desktop OS，距离严格意义上的 agent-safe OS，主要还差统一 capability policy、操作审计和事务式回滚。

目录

1. 背景与时间线

2. 总体架构

3. 源码架构与能力接口

4. Hyprland、Quickshell、mise 协同

5. UX、快捷键与平铺工作流

6. Crash Capture：系统事件如何变成 Agent 任务

7. 展望：本地模型运行层

背景与时间线

Omarchy 的 Agent 工作台不是演示项目，而是一家公司日常工程实践的产物：

• 2025-08：DHH 宣布 37signals 全面切换到 Omarchy——三年内随硬件换新，把 Ops 和 Ruby 团队全部迁移，并把改进回馈社区。硬件同步标准化为 Framework 笔记本/台式机与 Beelink 的 AMD 平台。

• 2026-08：Omacom Foundation 成立（8 位创始赞助人各出 100 万美元，后增至 1000 万美元）；同月发布 v4.0（quattro），Crash Capture 等 Agent 集成随之落地。

从个人工具到公司标准，再到有长期资金的基础设施生态，这条时间线本身就是"投资通用原语而非具体模型"路线的证据：Crash Capture 这类功能的打磨来自真实团队的日常反馈，统一的 AMD 硬件基线也让 hw-* 硬件检测和 crash 诊断有了可预期的环境。

总体架构

源码架构与能力接口

1. CLI 是系统的 Agent API

Omarchy 将四百多项系统操作（quattro 当前注册 436 条命令）收敛到统一入口：

omarchy <group> <action>

当前源码中的 omarchy-* 脚本通过文件名自动成为命令，并在文件头声明元数据（共 8 个 key：group、name、summary、args、examples、aliases、hidden、requires-sudo）：

# omarchy:summary=...
# omarchy:args=...
# omarchy:requires-sudo=true

omarchy commands --json 能输出 route、binary、group、参数、示例、别名和 requires_sudo 布尔值。这相当于一个轻量 tool schema：Agent 可以先发现能力和参数，再执行命令，而不必猜菜单坐标或脚本名称。

路由器还包含适合自动化的保护：

• 在执行前拦截 --help，防止查询帮助意外触发更新或安装。

• 必填参数缺失时显示 usage，而不是盲目进入交互流程。

• 未知命令提供前缀列表和建议。

• 通过 exec 保留底层命令的 exit code。

• omarchy commands --check 检测元数据错误和路由冲突。

路由层还有两个值得一提的设计：每个命令同时注册 canonical 路由和文件名路由，元数据移动路由后旧写法仍然可用；分发采用两遍策略——快路径只做文件名探测、不解析任何元数据头，别名和被移动的路由才回退到全量元数据解析，从而在四百多个命令的规模下保持低延迟。

2. Agent 是可替换的系统角色

Omarchy 没有绑定单一模型厂商。用户可以在 10 个 harness 中选择默认 Agent：Codex、Claude Code、OpenCode、GitHub Copilot、Grok（xAI 官方 CLI）、Pi（badlogic 的编码 agent）、Oh My Pi、Ori（OpenRouter 的 harness）、Crush 和 Antigravity（原 Gemini CLI 入口）。

统一启动器负责：

• 保存和读取默认 Agent（~/.config/omarchy/defaults/agent；系统不预设默认值，首次使用时通知邀请用户选择）。

• 将统一 prompt 翻译成各 harness 的参数形式。

• 使用统一 org.omarchy.agent Wayland app-id。

• 从 $HOME 顶层启动且 ~/Work 存在时切换到 ~/Work，避免让 Agent 信任整个 home。

• 通过同一快捷键（SUPER+SHIFT+CTRL+A）、菜单和 CLI 入口启动不同 Agent。

因此，桌面记住的是“Agent”这个角色，而不是某个具体产品。更换 Agent 后，快捷键、窗口规则、workspace 和用户肌肉记忆不变。

3. Skills 是随 OS 版本发布的操作知识

在用户 finalize 阶段（omarchy-provision-user），Omarchy 将内置 Skills（当前为 omarchy 和 diagnose-crash 两个）链接到多个 harness 的约定目录：

• ~/.agents/skills

• ~/.claude/skills

• ~/.codex/skills

• ~/.pi/agent/skills

• ~/.gemini/config/skills

Skills 编码的不是百科知识，而是当前 Omarchy 版本对应的操作约束：

• 哪些文件属于 package，不应直接修改。

• 用户配置和主题 overlay 应写在哪里。

• 什么时候使用 sudo 或 pkexec。

• 修改 Hyprland、Quickshell、主题、hook 后如何验证。

• 哪些 reset 或外部提交需要用户明确确认。

这比依赖网上可能过期的教程可靠，因为知识和实现随同一个软件包升级。

4. 状态分层降低修改歧义

Omarchy 将状态划分为：

/usr/share/omarchy       包拥有的源码和默认值，只读参考
~/.config                用户有意维护的配置和 overlay
~/.local/state/omarchy   生成状态、当前主题、迁移与运行记录

用户文件又通过 seed、finalize 和显式 resync 三阶段生成。Agent 因此更容易判断应该修改用户配置、默认模板还是迁移脚本，并且不容易把临时生成文件误当成权威配置。

flowchart LR
    P[/usr/share/omarchy<br/>包文件：只读参考] -->|读取默认值| A[Agent]
    A -->|安全定制| C[~/.config<br/>用户配置与 overlay]
    C --> R[Hyprland / Quickshell 运行态]
    R --> S[~/.local/state/omarchy<br/>生成状态与记录]
    S -->|观察和验证| A

5. 可验证性

仓库同时提供：

• CLI router 和 metadata lint。

• 可在临时 $HOME 中运行的 shell tests。

• 可通过 Node 测试的 Quickshell 纯 JavaScript model。

• 无 compositor 时自动跳过的 headless tests。

• disposable VM 中的图形 acceptance tests。

• 对视觉修改的运行中 UI verification 流程。

这使 Agent 可以遵循“小范围修改 → 聚焦测试 → 运行态验证”的闭环，而不是只根据代码外观宣布完成。

验证闭环的速度上限由本地算力决定。37signals 的实测是：HEY 的 Rails 测试套件在运行 Linux 的 Framework Desktop 上比最快的 Mac（M4 Max）快近一倍，且 Docker 原生运行。快速的本地测试不只是开发者体验——它直接决定 Agent 每一轮“修改 → 测试 → 验证”迭代的物理时长。

6. 当前短板

Omarchy 的能力发现和执行体验很强，但安全模型仍偏向顺畅执行：默认 Agent launcher 为 10 个 harness 中的 8 个注入了 auto-approve、allow-all 或同类免确认开关（只有 Pi 和 Ori 没有对应参数）。

尚未统一表达的命令语义包括：

• 会修改哪些文件。

• 是否访问网络或打开 GUI。

• 是否幂等。

• 是否可逆以及 rollback 命令。

• 是否会重启 session。

• 成功输出的 JSON schema。

下一阶段最有价值的改进，是为命令补充 effect metadata，并由 OS 执行 capability、审计和 transaction policy。

Hyprland、Quickshell、mise 协同

Omacom Foundation 赞助 Hyprland（独家赞助，3 年 + 2 年续约选项）、Quickshell 和 mise（均为 Premier 级），可以理解为对 Agent 执行栈的纵向投资，而不只是对三个依赖项目的一般性支持。

1. mise：Agent 工具供应层

mise 为不同来源的 Agent CLI 提供统一安装和运行方式：

npm / GitHub Releases / registry / runtime backend
                       ↓
                     mise
                       ↓
       codex / claude / opencode / pi / ori ...

Omarchy 只预置轻量 lazy wrapper，首次运行时才下载实际工具；wrapper 每次调用都会执行 mise use -g，因此它同时也是升级点。这同时获得了开箱即用和低镜像体积，并把安装、版本解析、升级和 PATH 管理收敛到同一机制。

战略价值在于：模型和 harness 会快速更替，但工具供应与版本管理是长期稳定的基础设施。支持 mise，可以避免 Omarchy 自己维护另一套 Agent 包管理系统。

2. Hyprland：桌面执行与感知层

Hyprland 通过 hyprctl 暴露大量结构化桌面状态：

hyprctl clients -j
hyprctl monitors -j
hyprctl activewindow -j
hyprctl devices -j

Agent 可以准确查询窗口、workspace、monitor、焦点和输入设备，并通过 dispatch 或 Lua API 执行窗口聚焦、移动、布局、DPMS、透明度和截图等操作。

这优于依赖视觉识别和鼠标坐标：JSON 状态更稳定、更快，也更容易测试。

统一 org.omarchy.agent app-id 进一步把各种 harness 抽象成一个桌面角色，使窗口规则、主题、workspace 和 focus 行为与具体模型解耦。

3. Quickshell：人机控制面和反馈层

Omarchy Shell 是一个长期运行的 Quickshell 实例，承载：

• bar、menu、panel 和 overlay。

• notification、OSD 和 lock screen。

• headless service。

• plugin host 和 IPC。

CLI 与 GUI 通过 IPC 操作同一份运行状态，例如 summon plugin、reload config、应用主题、调整 bar widget、列出 plugin 和输出有效配置。

因此同一个系统动作可以拥有多种入口：

人类：快捷键或菜单
Agent：omarchy CLI
系统：notification、hook、systemd service
                 ↓
           Quickshell IPC
                 ↓
            同一桌面状态

Agents panel 则把订阅额度、token 用量和模型分布变成类似网络、电池的系统指标。各 Agent collector 写入本地 JSON，Quickshell 只负责观察和呈现，增加新 Agent 不需要重写整个 UI。

4. 三者构成的生命周期闭环

启动

Hyprland 快捷键
  → omarchy-agent
  → mise 确保 harness 可用
  → Hyprland 创建统一 Agent 窗口
  → Quickshell 呈现 Agent 状态

定制

自然语言要求
  → Skill 给出配置边界
  → Agent 修改 ~/.config
  → Quickshell 热加载或 IPC reload
  → Hyprland reload/dispatch
  → Agent 查询 JSON/IPC 验证

更新

omarchy update
  → OS package 更新
  → mise 更新 harness
  → Skills 随包同步
  → Quickshell/Hyprland 配置迁移

5. 基金会赞助形成的护城河

赞助使 Omarchy 能把实际 AI 桌面场景反馈给上游：

• mise：非交互安装、供应链验证、版本锁定和更多 Agent provider。

• Hyprland：结构化事件流、安全 dispatch、事务式配置和稳定 IPC。

• Quickshell：plugin schema、hot reload、调试接口和 plugin sandbox。

这比投资某个具体模型更有持续性。无论未来主流 Agent 是谁，它仍然需要工具供应、桌面控制和人机反馈这三类通用原语。

UX、快捷键与平铺工作流

Omarchy 没有为 AI 发明孤立的聊天界面，而是把 Agent 嵌入原有的键盘驱动、平铺窗口、workspace 和终端工作流。

1. 快捷键降低调用摩擦

默认 Agent 被提升为系统级动作。用户可以在任意应用和 workspace 中通过快捷键立即召唤 Agent，而不必先打开浏览器、进入聊天网站、重新选择项目。

调用成本降低后，AI 不再只服务于大型任务，也适合高频小任务：解释错误、修改快捷键、调整窗口规则、分析截图或审查当前项目。

快捷键表达的是稳定意图，而不是易变的 GUI 坐标。它也构成从人类操作到可程序化接口的过渡：

鼠标点击
  → 快捷键表达意图
  → omarchy CLI
  → Hyprland / Quickshell IPC

2. 平铺布局支持共视和监督

典型 Agent 开发布局可以同时呈现：

用户可以同时看到 Agent 的命令、代码 diff、测试结果和运行日志。这使 Agent 从异步黑箱变成可以持续监督的执行者。

Omarchy 的 tmux helpers 进一步提供（均需在 tmux 会话内使用）：

• tdl <agent>：编辑器（左）、Agent（右侧 30% 栏）、终端（底部）；agent 参数必填。

• tdl <agent1> <agent2>：第二个 Agent 在右侧栏内上下堆叠。

• tds：编辑器（nvim）、diff watcher、终端和一个 opencode pane 的固定四格布局。

• tsl <数量> <命令>：把任意命令铺满 N 个平铺 pane，传入 agent 命令即得到 Agent swarm。

• tdlm <agent>：为每个子目录开一个 tdl 窗口。

多 pane 是一种轻量、可视化的多 Agent orchestration；但多个 Agent 操作同一 working tree 仍可能冲突，最好配合 git worktree。

3. Workspace 和 scratchpad 提供空间隔离

不同 workspace 可以承载不同任务语境：主项目、运行应用、文档浏览器和临时 Agent。Agent 可以在 special workspace 中持续编译或测试，用户继续在主 workspace 工作，需要时再快速切回。

空间布局本身是一种外部记忆：用户知道“左边是代码、右边是 Agent、下方是验证”，不需要在多个全屏窗口间反复重建上下文。

4. Menu 补足快捷键的可发现性

快捷键效率高，但新用户不容易记忆。Omarchy Menu、CLI 和快捷键形成三层入口：

新用户：Menu 发现能力
熟练用户：快捷键执行
Agent：CLI 调用

三者围绕 theme、refresh、toggle、capture、plugin 等共享词汇组织，用户可以把在菜单里看到的概念直接用于 prompt，Agent 也能映射到同名 CLI。

5. 普通终端提供可接管性

Agent 默认运行在普通 PTY 终端，而不是隐藏后台服务：

• 用户能看到命令和输出。

• 可以随时 Ctrl+C。

• 需要认证时可以人工接管。

• shell 历史和 exit code 自然保留。

• 不需要新的专用 Agent UI 协议。

这是一种简单但强大的监督界面。

6. 截图、OCR 和剪贴板提供受控多模态上下文

区域截图、OCR、录屏和剪贴板历史可以将屏幕现象转化成由用户主动选择的 Agent 上下文：

屏幕现象
 ├── 截图 → 视觉分析
 ├── OCR → 文本分析
 ├── 录屏 → 时序问题
 └── 剪贴板 → prompt 或文件

相比默认持续读取整个屏幕，这种显式捕获更容易理解，也更符合隐私最小化原则。

7. UX 层面的核心优势

• 即时性：任何现场都能快速召唤 Agent。

• 共视性：代码、Agent 和验证结果同时可见。

• 可接管性：用户随时能监督、中断或输入认证。

• 模型无关性：桌面记住的是 Agent 角色，不是厂商产品。

• 意图稳定性：高频 GUI 动作背后通常已有快捷键、CLI 或 IPC。

下一步可以把 workspace、git worktree、Agent pane、测试 pane 和 snapshot 组合成正式的 task workspace，使平铺 UX 从“方便启动 Agent”升级为可视化任务编排。

flowchart LR
    K[快捷键<br/>即时召唤] --> A[Agent Terminal]
    W[Workspace<br/>空间隔离] --> A
    A --> P[平铺共视<br/>代码 + Agent + 测试]
    P --> C[用户监督、打断与接管]
    C --> A

Crash Capture：系统事件如何变成 Agent 任务

Crash Capture 是 Omarchy Agent 集成最有代表性的案例。它不是把 core dump 自动上传给模型，而是把系统事实、规则过滤、用户授权、领域 Skill 和上游反馈组织成一条完整流水线。

1. 从结构化事实开始

Watcher 订阅 systemd-coredump 固定 MESSAGE_ID 的 journal JSON，而不是匹配随机日志文本。事件包含当前用户、进程名、PID、可执行文件、signal 和时间戳。

因此 Agent 的起点不是“桌面刚才好像消失了”，而是系统已经确认的事实：

process: quickshell
PID:     12345
binary:  /usr/bin/quickshell
signal:  SIGSEGV
time:    ...

2. OS 先做确定性筛选

omarchy-crash-watch 在调用 AI 前完成：

• 只处理当前用户的 crash（逐条事件检查，而非服务启动时一次）。

• 没有默认 Agent 时不显示无效通知。

• 用前缀规则排除整个 omarchy-crash-* 和 omarchy-agent-* 命令家族，防止反馈循环。

• 支持用 OMARCHY_CRASH_IGNORE 环境变量（扩展正则）忽略指定进程。

• 按程序名对 crash loop 去重，窗口默认 60 秒（OMARCHY_CRASH_DEDUPE_SECONDS 可覆盖）。

• 只有通知成功送达后才开始去重窗口。

这种 deterministic triage 减少噪声、token 消耗和模型误判。

3. Quickshell 完成人机授权交接

通知只写：

Process crashed: <program>
Click to diagnose with AI

检测和保存证据自动完成，但用户必须点击后才启动 Agent。按钮授权的是“诊断”，不是自动修复或自动报告。

Quickshell 自身 crash 时 notification server 会暂时消失。Watcher 会等待重启后的 shell 重新取得 D-Bus name（上限 10 秒），再补发通知，从而避免最值得诊断的 shell crash 被静默丢失；超时则放弃该条通知，也不开启去重窗口。

点击动作使用离散 argv 传递 PID、进程名、路径和 signal，不使用 sh -c 拼接，避免恶意进程名被重新解析为命令。

4. 事件适配器、诊断策略和执行引擎分离

omarchy-agent-crash 只负责：

• 验证 PID。

• 补充时间戳。

• 整理结构化事实。

• 指向 diagnose-crash Skill。

• 把 prompt 交给默认 Agent。

具体调查方法由 Skill 定义，而不是硬编码在 launcher：

事件适配器：omarchy-agent-crash
诊断策略：diagnose-crash Skill
执行引擎：用户选择的 Codex、Claude、OpenCode 等

这样所有 harness 共享同一套、随 Omarchy 版本更新的诊断方法。

5. Skill 约束证据调查

Skill 要求 Agent：

1. 从 coredumpctl info <pid> 和完整 command line 建立事实。

2. 用 coredumpctl list 判断一次性事件还是重复模式。

3. 先通过内存和 journal 排除 OOM 等资源问题。

4. 以 crash 时间戳关联文件 mtime、邻近日志和最近 package update。

5. 查看所有线程，而不只看 frame 0。

6. 关注 extension、plugin 和 out-of-tree driver，但不在没有证据时归责。

7. 必要时通过 Arch debuginfod 和 gdb 符号化。

8. 明确区分证据证明的事实和推断。

6. Core dump 的隐私边界

Core 是进程内存副本，可能含密码、token、私人文档和 API key。Skill 因此要求：

• 只提取到 mktemp 生成的不可预测路径，不把 core 留在固定 /tmp 文件名。

• 用 trap 保证退出时删除临时 core：core 只在本地临时文件中短暂存在，用完即删。

• 诊断过程保持只读，不顺手修改系统。

Skill 没有一条明文的"禁止上传"条款，但只读加即删的组合在事实上排除了把 core 交给外部服务的空间。

用户点击“Diagnose”只授权读取和分析，没有授权卸载 package、修改配置、重启服务或删除数据。

7. 上游报告需要第二次授权

只有证据显示问题确实位于 Omarchy 控制范围，才进入 reporting 流程。第三方应用自身 crash 通常应归属其上游，而不是 Omarchy。

提交前必须同时满足：

1. 已验证属于 Omarchy 的 bug。

2. 用户看过拟提交的 title/body 并明确同意。

3. 机器已经有可用的 gh 登录；Agent 不擅自安装或认证。

随后还要搜索 open 和 closed issues，避免重复报告；如果已有 issue，只有掌握新增证据时才添加评论。机器生成的报告需注明模型和 harness。

8. 三项基础设施的分工

• Hyprland：承载图形 session、Agent 终端、窗口布局和人工监督。

• Quickshell：将后台 crash 变成可见、可点击的用户事件。

• mise：保证用户选择的 Agent harness 可按需安装和运行。

• Omarchy：监听事件、过滤噪声、构造任务、分发 Skill、规定隐私和授权边界。

9. 可推广的系统事件委托模型

Crash Capture 可以推广到更新失败、磁盘异常、网络故障或性能退化：

事实由 OS 捕获
噪声由规则过滤
意图由用户确认
方法由 Skill 约束
执行由可替换 Agent 完成
外部副作用再次请求授权

下一步可以引入 crash diagnosis 专用 capability profile，只允许 coredumpctl、journalctl、gdb 和只读查询；同时输出结构化诊断 JSON，并将“诊断”“提出修复”“应用修复”“上游报告”拆成四个独立授权阶段。

展望：本地模型运行层

这是全文唯一标注为"展望"的一章：以下方案在 quattro 源码中不存在，讨论对象是一张社区流传的设计草图，而非已实现或已公布的路线图。

当前 Omarchy 的 Agent 栈有一个结构性空缺：模型全部在云端。mise 管理的是 harness 的安装，Agents panel 观测的是云端订阅额度和 token 用量，10 个可选 Agent 连接的都是各家的云端 API。quattro 其实已经修了半座通往本地的桥——Install > AI 菜单预置了 LM Studio 和 Ollama 的安装项，Ollama 那条还会检测 nvidia-smi / rocminfo 自动选择 ollama-cuda / ollama-rocm 包，是硬件感知的。但桥只修到这里：装好的本地模型与 Agent 没有任何关联，没有机制把它注册为任何 harness 的 provider。

1. 一张设计草图

流传的草图把缺失的后半座桥画得很完整（其中的 omarchy-ai-* 命令和 omarchy-local-ai 容器在当前源码中均不存在）：

草图最有价值的一句话是："The agent never knows Omarchy exists — it just sees an OpenAI-compatible URL in its own config."（Agent 永远不知道 Omarchy 存在——它只在自己的配置里看到一个 OpenAI 兼容 URL。）Omarchy 负责容器生命周期和 provider 注册，Agent 只面对一个标准协议 endpoint。

这与本文反复出现的模式完全同构：

• 三种入口（Bar、Menu、CLI）共用同一个薄 Bash 命令层，与现有四百多个 omarchy-* 命令的组织方式一致；命令一旦落地就自动获得元数据、--help、commands --json 和路由测试。

• 集成边界是上游自己的 JSON 配置文件，不 fork Agent、不要求 Agent 理解 Omarchy——与 Skills 通过约定目录分发是同一哲学。

• 统一 endpoint 解耦下层实现：正如"统一 launcher → 10 种 harness"，这里是"统一 OpenAI 兼容 endpoint → 任意推理 runtime"。草图里有个耐人寻味的细节：容器标注 vLLM，端口却写 12434——那是 Docker Model Runner（基于 llama.cpp）的惯例端口。这处矛盾反倒印证了方案的要点：endpoint 之下的 runtime 本就该可替换。

2. 落地前必须补的边界

草图目前只是一页概念图，正式化至少要解决三件事：

• 容器生命周期不应靠裸 docker start/stop，更合理的归属是 systemd user service——处理 restart、日志、健康检查和重复 toggle 的竞态，这也是 omarchy-crash-watch 已经采用的模式。

• models.json 的 ownership 规则：合并还是覆盖、如何标记 Omarchy 管理的区域、重复运行是否幂等、移除时是否只删自己写入的部分——这正是 Omarchy 配置分层（seed / finalize / resync）一直在回答的那类问题。

• 本机 endpoint 的安全边界：确保端口只绑定 127.0.0.1、防范浏览器页面向 localhost 发请求、绝不把 Docker socket 挂进推理容器。

GPU 矩阵（NVIDIA/AMD/Intel、显存、量化格式）和首次模型下载体验则决定了 omarchy-ai-setup 不会是一个简单脚本，而是又一个 setup- 前缀的硬件感知向导。

3. 隐私叙事的另一半

这一层补上后，Omarchy 的隐私边界故事才完整。Crash Capture 让 core dump 不出本机；本地 provider 让 prompt 和代码也可以不出本机。用户可以按任务选择：私密代码走本地模型、高难度任务走云端旗舰、离线环境走本地 GPU——而快捷键、窗口规则、Skills 和监督界面全部不变，因为桌面记住的仍然是"Agent"这个角色。届时 Quickshell 也有现成的呈现位置：云端 Agents panel 观测订阅与 token，本地面板观测 GPU、模型与吞吐，两者互补。

总结

Omarchy 的核心优势不是某个特定模型，而是把 Agent 所需的工具供应、系统知识、桌面执行、交互反馈和验证流程整合为一个可替换、可观察、可监督的运行环境。Omacom Foundation 对 Hyprland、Quickshell 和 mise 的支持，使这一能力建立在长期通用的桌面基础设施上，而不是绑定短期变化的 AI 产品。

还有一层是闭源桌面给不了的：Agent 运行在一个源码完全可读的系统上。/usr/share/omarchy 的只读参考层意味着 Agent 可以直接读到它所运行的整个桌面的实现——诊断 crash 时查 Quickshell 插件源码，改配置时读默认模板。在 macOS 或 Windows 上，Agent 面对的是黑箱 OS；agent-ready desktop 只可能长在开源栈上。

下一阶段最重要的方向，是在现有流畅体验之上补充 OS 级 capability policy、结构化 effect metadata、操作审计和事务式回滚，使 Omarchy 从 agent-ready desktop 进一步演进为 agent-safe desktop。

参考

• DHH, All-in on Omarchy at 37signals^[1]（2025-08）

• REWORK Podcast: Moving to Omarchy^[2]

• Omacom Foundation sponsorships^[3]

• Omarchy Manual: AI^[4]

• Docker Model Runner: Local models^[5]（12434 端口与 OpenAI 兼容 API 的出处）

• mitkox/omarchy-ai^[6]（社区已有的第三方本地推理集成尝试）

参考资料

[1] 

All-in on Omarchy at 37signals: https://world.hey.com/dhh/all-in-on-omarchy-at-37signals-68162450