AI的下一个战场,是操作系统

这是我的第 345 篇原创文章

作者｜柏导

整个AI行业还在比谁的模型跑分高，但真正的战线已经悄悄挪了位置。2026年8月，两个项目几乎同时进入公众视野：DHH把他的Omarchy Linux发行版推到了4.0，把整个桌面shell用Quickshell重写了一遍，核心目的是让AI编程代理成为桌面的一等公民；DeepSeek则发布了Harness的开发者预览版，试图在模型和工具之间塞进去一整个可编程的运行时层——权限、沙箱、会话状态、子代理调度、审计轨迹，全部插件化。这两个东西不是竞品。它们甚至不在同一层。但放在一起看，它们指向了同一个判断：模型本身正在变成基础设施，真正的产品竞争正在向上（操作系统）和向中间（运行时/harness）两个方向同时展开。

先说Omarchy。媒体喜欢把它写成"AI Linux"或者"内置大模型的操作系统"，这是误导。翻开它的官方AI手册就知道，Omarchy自己没有任何模型推理引擎。它做的事情是把Claude Code、Codex、OpenCode、Copilot、Grok等一堆外部编程代理的命令行工具，通过mise的懒加载机制统一暴露到系统路径里，然后给它们配上默认值、快捷键、桌面菜单和系统事件入口。你按一个快捷键就能启动你选定的默认代理；你敲一行omarchy agent prompt "帮我审查这个项目"，它就会用无人值守模式把任务丢给代理去跑。更有意思的是它的崩溃诊断流程：systemd-coredump抓到一个crash，Omarchy弹通知，你点一下，crash上下文就被喂给默认代理做分析。这才是它真正的创新——是让系统状态本身变成了代理的上下文来源。

这个设计选择其实非常明智。模型和代理工具的更新速度远远快于操作系统发行版，如果Omarchy自己绑定某个特定模型的生命周期，它会被拖死。所以它把稳定边界画在"桌面入口和系统整合"这一层，把模型和harness留在可替换的外面。今天默认用Claude Code，明天换Codex，后天换一个还没出现的东西，操作系统不需要跟着改。这比那些把"我们内置了GPT-5.6"当卖点的产品成熟得多。

但Omarchy有一个很大的问题，而且是结构性的。4.0版本引入了shell插件体系，社区反应极快——DHH在发布四天后说已经有超过400个插件，中文媒体随后报道说十天达到了1074个。问题在于，官方文档自己表示：第三方shell插件是运行在长期桌面进程中的、没有沙箱的任意用户代码。也就是说，一个恶意或被接管的插件，跟你的桌面用户拥有完全相同的权限——你的SSH密钥、API token、源代码、剪贴板、出站网络，它全都能碰。社区marketplace有审核流程，但审核本身不等于安全审计，而且插件指向的是Git上游，审核时看的代码和你安装时拉到的代码之间没有密码学绑定。这意味着"marketplace审过版本A"不能证明"你机器上跑的就是A"。对于一个插件规模正在爆炸式增长的桌面环境，这个缺口是最需要优先堵上的。

再加上omarchy agent prompt的无人值守模式。效率确实高，但如果代理正在处理一个包含prompt injection的仓库——恶意的build脚本、README里藏的指令、不可信的依赖——自动批准越彻底，模型犯错或被间接注入后造成真实系统操作的概率就越不能忽视。Omarchy的snapshot回滚能帮你恢复系统状态，但已经通过网络外泄的数据是回滚不回来的。

然后看DeepSeek Harness。它解决的是完全不同层面的问题。如果说Omarchy回答的是"开发者怎么在桌面上最方便地启动和切换代理"，DSH回答的是"代理启动之后，怎么控制它能干什么、不能干什么、干了什么"。

DSH的核心抽象是"Agent = Model + Harness"。模型是可以替换的插件，工具、权限、沙箱、会话、存储、子代理、调度器、UI也全都是插件。底下的Cordis内核负责插件的生命周期管理、依赖解析和事件通信。一个完整的代理是通过配置组装出来的，而不是写死的单体程序。它甚至提供了不同的执行预设——Standard模式是完整的编程代理，带文件编辑、shell、搜索、规划和子代理；Code模式让模型生成TypeScript程序来组合工具调用；Minimal模式只给bash和一个文本编辑器。同一个模型在不同harness配置下，表现成完全不同的产品。这才是"模型商品化"之后真正重要的事。

DSH最让我觉得方向对了的设计有两个。第一个是权限门控：工具调用进入统一的permission pipeline，结果是allow、deny或ask；如果当前执行环境没有用户审批界面，ask不会悄悄变成allow，而是当作拒绝处理。这个fail-closed的性质对企业场景至关重要。第二个是append-only的会话轨迹：系统提示词、推理过程、工具调用和返回结果、子代理调度、上下文注入，全部作为不可篡改的日志记录下来，支持检视、恢复、分叉和重放。这让"代理到底做了什么"变成了一个运行时的一等数据结构，不是事后从shell history里拼凑的碎片。

但DSH同样有明显的短板。它现在还是开发者预览版，官方明确警告API会快速变化、可能出现兼容性破坏。而且"所有东西都是插件"本身不等于安全，插件越强大，供应链和权限边界就越关键。另外，完整的agent轨迹本身就是一个高度敏感的数据集——系统提示词、推理内容、工具返回的文件内容，里面很可能包含机密信息。轨迹的留存策略、加密方式、访问控制和脱敏机制，这些数据治理问题在当前的developer preview材料里还看不到完整的企业级回答。

把两个项目放到一个技术栈里看，层级关系非常清楚：Omarchy在最上面，负责桌面入口、快捷键、系统上下文和agent发现；DSH在中间，负责模型路由、工具权限、沙箱、会话状态和审计轨迹；模型在最下面，负责推理。Omarchy优化的是用户到达代理的摩擦，DSH优化的是代理到达真实世界工具时的控制与可观测性。两者更可能互补而不是互斥。

我认为这两个项目共同揭示的趋势，比它们各自的产品形态更重要：AI软件栈正在从"模型嵌入应用"转向"代理成为运行时，操作系统成为代理的宿主"。未来开发工具的竞争是"哪个模型×哪个harness×哪套工具×哪种权限策略×哪个OS上下文"的组合。IDE可能逐步失去"所有能力必须发生在编辑器窗口内"的中心地位，变成代理的一个视图而不是唯一宿主。

如果这两条路线继续收敛，下一代开发者操作环境最可能的样子不是一个"自带某个大模型的AI OS"，会是一个不绑定特定模型、能感知harness、有权限管控、有审计轨迹、能回滚的代理宿主操作系统。Omarchy 4.0的意义在于它已经把这组问题——代理如何进入系统、获得上下文、调用能力、接受约束、留下记录并在失败后恢复——提前组合出来了。