Omarchy 最近热度飙升，隐约成为今年最火的 Linux 桌面系统，甚至可能是首个进入 Agent 时代的操作系统。
开发者 David Heinemeier Hansson（DHH）功不可没。作为 Ruby on Rails 的创造者、37signals 联合创始人兼 CTO，过去 25 年他以手写代码闻名。即便一年前他对 Agent 编程仍持怀疑态度，但 Quattro 版本发布的新功能代码已无一行出自他本人之手，全部由 Agent 编写。
DHH 将 Omarchy 定位为第一个「Agent 原生操作系统」。在他看来，若 Agent 已能理解自然语言、调用系统工具并编写软件，操作系统本身也应随之变革。界面、功能乃至整套系统，均可按个人需求随时改写。过去是人学习如何使用计算机，而在他的设想中，计算机将按人的意愿被重塑。
近期，DHH 做客 Lex Fridman 的播客节目。在超过五小时的对谈中，两人从 Omarchy 出发，深入探讨了 AI 时代操作系统的形态，以及软件生产和编程方式的剧变。
鉴于播客时长较长，Founder Park 编辑节选了以下核心内容。
01
没有手写一行新代码，DHH 做出了 Agent 原生的操作系统
Lex Fridman：先介绍一下，Omarchy 是什么？
DHH：Omarchy 是一套漂亮、现代且取舍明确的 Linux 系统，旨在替代 macOS 和 Windows。它基于 Arch Linux 和 Hyprland 平铺式窗口管理器。名字中的「Oma」源自日语 omakase（意为「交给厨师」），我就是那个厨师，负责替你完成技术选型。
该项目诞生仅一年多。去年夏天，我在勒芒 24 小时耐力赛间隙观看 Linux 美化视频时再次入坑。初次尝试名为 Omakub，基于 Ubuntu，虽不错但我希望掌控更底层的内容，于是有了基于 Arch Linux 的 Omarchy。
早期 Omarchy 诞生于 Agent 普及之前，Bash 脚本皆为我手写。随后几个版本开始部分采用 Agent。到了 Quattro 版本，过去三个月几乎全速使用 Agent，最近两个月更是达到 100%。
Quattro 最终发布的新功能代码，没有一行是我亲手写的。关键的模型层代码我会审查整体结构和具体实现，而许多 UI 和辅助代码我甚至未逐行查看。三个月内，我合并了超过 1000 个 Pull Request。代码由 Agent 完成，我负责掌舵。
这带来了截然不同的开发体验。过去，开发能力限制了我的野心；现在，我可以看着 Windows、macOS 或其他 Linux 系统中的任何功能说：「我也想要这个。」Agent 通常五分钟即可交付，复杂需求需 20 分钟，极个别夸张需求也不过两小时。
这就像精灵从瓶中跳出，告诉你操作系统里梦想的功能都能实现，令人无比兴奋。
但我未被这种能力压垮，因为我有明确目标：创造一台完美的计算机。所有 AI 实验均指向此结果。Agent 带来的真正变化，是增加了大脑想法与屏幕软件之间的带宽，如同从拨号上网直接切换至光纤。
Lex Fridman：为什么偏偏选择重做操作系统？Ubuntu 已经相当成熟，你为何觉得自己可以做得更好？
DHH：起初野心没这么大，我只是想让 Ubuntu 更现代、美观，并预装我真正使用的软件。
但随着深入底层，我发现距离内核和具体软件包越近，拥有的自由越多，野心也随之膨胀。我对计算机的工作方式、呈现形式、预装程序，甚至安装耗时是 42 分钟还是 45 秒，都有非常明确的想法。
操作系统是人机交互的基础，但该领域停滞太久。今天的 macOS 与十年前差异不大，甚至在某些方面更封闭：用户无法自由安装软件，快捷键需手动修改，连切换工作区的动画时间都难以调整。
我不想要一台被锁住的计算机。我想真正拥有它，更进一步，我想随时改变它。当用户已经可以通过 Vibe Coding 创造出任何应用时，也应该能够 Vibe Coding 自己的操作系统。
02
AI OS 的界面，应该可以被用户随时改写
Lex Fridman：你把 Omarchy 称为「可塑计算机」。它与今天在操作系统里增加一个 AI 助手有何不同？
DHH：Omarchy 拥有一套更完整的插件系统。用户可以创建插件，改写操作系统的界面、面板和功能。例如，Omarchy 默认带有一个日历，点击时钟即可弹出，但它不支持 iCal。几天内，社区已做出了约 17 种不同的日历实现。
插件市场上线三天便出现了 330 个插件。这是我参与过的项目中从未见过的增长速度。我从未见过如此广泛的参与，也从未见过这么多人能如此快地为自己创造有意义的软件，且这些软件也能被他人使用。
关键在于，Omarchy 内置了一组 Skill，告诉用户带来的任何 Agent 该如何为这套系统开发扩展。用户无需先理解插件架构，只要说清需求，Agent 就能将其实现。
过去，只有程序员输入严格命令才能让计算机发生变化。现在，一个人可以用自然语言描述 20 分钟：「这里最好有个面板，不对，应该放到另一边，再加上这个信息。」最终，操作系统就会变成他想要的样子。
这就是我所说的可塑计算机。Commodore 64 开机后直接进入 BASIC，计算机从一开始就是可塑的，只不过当时必须先学会一套近似象形文字的语言。
现在，Agent 给了我们一块「罗塞塔石碑」。用户可以直接说出需求，让计算机按照自己的意愿发生变化。一旦体验过这种力量，就很难再回到一套只能接受厂商预设的系统。
注：罗塞塔石碑制作于公元前 196 年，是破解失传千余年古埃及象形文字的关键钥匙。
Lex Fridman：Agent 会如何改变系统的软件分发、更新和维护？
DHH：Agent 天生契合 Unix 哲学，这也是 Linux 适合 Agent 的原因。普通用户不喜欢 Linux，正因为里面充满了配置文件和命令行工具。以前这让普通人望而却步，现在这恰好是 Agent 最擅长操作的界面。地球上没有哪个主流操作系统能像 Linux 一样完美支持这种机制。
真是讽刺，宇宙开了个玩笑：五分钟前 Linux 的缺点，现在成了它的主要卖点。
四个月前，我以为周末只能用 Mac 了。像 Raycast 这类工具没有配置文件，必须进 GUI 导出再用 U 盘导入。你无法自动化整台 Mac 的配置，甚至不能自动化默认键绑定，只能像原始人一样用鼠标点击。
而 Agent 消除了 Linux 所有的困难。自今年年初起，我的 Linux 机器上没有一个问题是 Agent 无法诊断的。以前需要泡论坛找答案，现在 Agent 知晓 Linux 的 4000 万行源码及我机器上每个软件的源码。当 Linux 报出对人类毫无意义的晦涩错误时，Agent 能立刻将其与训练数据中的源码关联，精确定位问题。错误信息越具体、越晦涩，对 Agent 反而越有用。
新工具发布后也能迅速进入系统。ChatGPT Codex 客户端发布约两小时后，我已将其封装好并放入 Omarchy 的安装菜单。用户搜索 ChatGPT 并按下回车，即可完成安装。
Agent Harness 的更新频率更为夸张，有时一天七次。传统软件包管理器并非为此速度设计，因此我们使用 mise 管理这些快速变化的开发工具。
故障处理也在变革。Omarchy Quattro 内置崩溃监视器，任何应用崩溃后，系统都会询问用户是否让 AI 诊断。Agent 可以查看系统日志、找到应用源代码，定位到某个 Rust 文件的具体行，并替用户整理 Bug Report。
Lex Fridman：那么，未来的主要交互界面会是什么？
DHH：终端一定会保留。但模型公司需服务数十亿用户，不可能要求所有人都学会终端，因此它不会是唯一入口。
Agent 编程最初从 TUI（终端用户界面）和 CLI 开始，我非常喜欢这一点。鼠标和图形界面降低了门槛，让普通人可通过点击探索系统；终端则适合希望理解和控制计算机的人。
Lex Fridman：你用语音吗？
DHH：我自己不用，我喜欢打字。但 Omarchy 内置了 VoxType 语音转写。
很多人会觉得，直接对计算机说「给我做一个股票面板，我想追踪 Apple 和 Dell」非常自然。Agent 可以通过语音接收需求、完成开发，随后操作系统里就真的多出一个面板。
我能想象，如果有一天，对着操作系统诉说 20 分钟，其界面和功能就能不断生成、变化，那就是《钢铁侠》中 Jarvis 的感觉——定制化应用凭空出现。这也是 Linux 会全面胜出的原因之一。
03
很多组织的限制不是实现能力，是愿景和品味
Lex Fridman：你真觉得普通人会从 Mac 切到 Linux？
DHH：若无令人信服的理由，人们很难切换系统。这正是 Omarchy 的主要设计目标之一。Ubuntu 曾试图做一个「便宜版 Mac」，结果失败，因为人们不要更差的仿制品。Omarchy 走的是完全不同的路：不是模仿，而是提出一种全新的可能性。平铺式窗口管理器、键盘驱动、Agent 原生，这些东西一旦体验过就回不去了。
Lex Fridman：很多人无法离开 Windows 或 macOS，是因为依赖 Premiere、Photoshop 等少数软件。Agent 会改变这种局面吗？
DHH：完全可能。过去关于 Microsoft Office 有个玩笑：每个人都只使用其中 5% 的功能，只不过大家用的是不同的 5%。那么，为什么不各自做出自己需要的 5%？
完整重写 Office 是巨大工程，但只实现某类用户真正需要的 5%，却是完全不同的任务，今天的 Agent 已很擅长完成它。
我以前主要写 Ruby，必要时碰一点 Bash。最近两个月，我却做了 C++ 和 Rust 应用。
我在 Mac 上很喜欢 iA Writer，换到 Linux 后使用 Typora。Typora 很好，但大量功能我并不需要。大约六七周前，我突然想到：我只需要 Typora 的 5%。
我告诉 Agent，用 C++ 和 Qt 做一个符合 Omarchy Quattro 风格的写作工具。大约 20 分钟后，第一版出炉。我一边使用一边反馈，两天后彻底放弃 Typora，之后的文章都写在 Omawrite 里。
我刻意不查看任何一行 C++ 代码，将其视为黑盒实验。假设我只是一个对数字打字机有明确意见的作家，是否也能做出自己想要的软件？答案是可以。
熟悉视频剪辑的人深知 Adobe Premiere 哪里难用，却过去无力改进。现在，他们可以先为自己做出一个版本。它未必覆盖原产品的全部功能，但可能更精准地解决一类用户的问题。
Lex Fridman：AI 已大幅提高开发效率，为何 Photoshop、Premiere 等成熟软件的更新速度尚未明显加快？
DHH：原因有很多。最关键的一点是，一旦涉及人类团队协作，瓶颈通常不是实现，而是人的带宽和沟通。
产品经理、设计师、VP 和 CTO，每个人都要参与塑造产品过程并证明自身存在价值，生产力便消耗于此。
开发 Omarchy 给我的最大启示是：若想获得 10 倍、100 倍甚至 1000 倍的提升，人必须直接与 Agent 互动，中间不能再隔着另一个人，否则带宽太低。
当一家公司仍保留三层审批、复杂管理机制和多人协作流程时，代码实现只是其中很小一部分。我们不应将 Agent 的理论能力直接等同于整个组织可获得的效率提升。
还有一个更根本的问题：大多数组织并不知道自己想要什么，也不知道怎样把产品变得更好。它们受到限制的不是实现能力，而是想法、愿景和品味。如果好想法的数量未超过实现能力，让更多糟糕的想法更快变成现实，并不会产生更好的软件。
大型科技公司过去几十年已拥有数以万计的程序员，这足以证明单纯增加代码产能不会自动产生优秀产品。
Lex Fridman：所以正确的做法是从头开始？通过开源或创建新公司，而不是在大公司内部加速进入 Agent 时代？
DHH：这是经典的创新者困境。这些公司发展得过于成熟和根深蒂固，其结构、管理层级和流程都适应于一个已过时的时代。你无法改变它们，它们就像超级油轮，根本无法转型。这就是科技行业最终会如此动荡不安的原因。
有段时间我对 Apple 和 Google 在移动端的双寡头垄断很不满，因为看不到打破它的路径。但游戏变了，移动端不再是最重要的计算平台。各种新形态正在出现，包括眼镜、耳机等。
计算平台本身也在经历 40 年来的首次洗牌。Linux 自 1991 年诞生，在桌面端从未起飞，但在其他所有地方都占据了统治地位。你桌上的设备、冰箱、烤箱全都跑 Linux，除了你的电脑。现在有了突破口：如果有一款软件把你绑在 Windows 上，你完全有能力自己重写它。
Omarchy 能获得关注，也因为它没有试图成为廉价版 Windows 或 macOS。Omakub 更熟悉、更接近传统桌面，影响始终有限。Omarchy 使用平铺式窗口管理，提出了另一种计算机工作方式的愿景，反而从一开始就获得了更强的吸引力。
04
同时开 16 个 Agent 线程，人类负责判断
Lex Fridman：13 个月前，我们坐在这里讨论编程。当时你对 AI 在编程中的作用还有些怀疑，之后我们经历了 Agentic Engineering 的快速演变。你对 AI 在编程中角色的看法发生了什么变化？是兴奋还是害怕？
DHH：我无比兴奋，没有任何存在性威胁的感觉。那种威胁仅停留在理智层面，而在情感层面，是百分之百纯粹的喜悦、乐观以及对计算机做到这些事情的惊叹。
13 个月前的对话像发生在另一个宇宙。有人说「有些几十年里什么都没有发生，有时几周内就发生了几十年的变化」。过去九个月，我们就看到了几十年的进步。
我的基本判断其实没变。去年我不喜欢的是当时提供的 AI 形态：自动补全和聊天机器人。它们可以是好老师或助手，但不会取代我亲手雕琢代码，只是提高了原有效率，并未改变我与计算机的关系。
在第一阶段，我仍需坐在驾驶位：告诉 Agent 做什么、去哪找答案，在它偏离时拉回，并审查结果。它让我快了很多，但我仍是驾驶员。
真正的分界线是 2025 年 11 月 24 日 Opus 4.5 发布。我过了两天才试，给了几个任务后发现，它输出的代码和我自己写的已非常接近。我向后一靠，心里只有一个问题：刚刚发生了什么？
几个月前还是糟糕的自动补全，几个月后它已能操作计算机、调用工具、检查工作并真正完成任务。它不仅解决问题，采取的路径也基本符合我的判断，写出的 Ruby 代码甚至是我愿意合并的。
今年春天，Harness 开始支持子 Agent。一个任务可被拆开交给八个 Agent 并行完成，耗时降至原来的五分之一甚至十分之一。
到了夏天，随着 Opus 5、Fable、GPT Sol 以及一些开放权重模型发布，我们终于进入第三阶段。在这个新时代，我不再需要告诉 Agent 去哪里或规定路径，只需描述问题或模糊想法，它会告诉我目标是什么以及该如何到达。
我当然还会看，因为我喜欢计算机且对过程好奇。但严格来说，在选择路径并产出代码这部分，人已变成了可选项。
Lex Fridman：你现在具体怎样和 Agent 一起工作？
DHH：最大的变化是从人脑里的单线程开发转向并行处理。
过去，我在 TextMate 或 Neovim 里亲手写代码，一次专注一个问题。Agent 却显得太快又太慢，每个任务都要运行一段时间。若只启动一个 Agent，人只能坐在那里等待。
因此，我开始并行运行多个 Agent。最初用 tmux 打开不同窗格，后来换成带通知的 Herdr。再后来，一台机器不够了，我把几台闲置迷你电脑接起来，通过 Tailscale 访问不同办公室的设备。目前，我大约可同时维持 16 条开发线程。
这时，人的工作变成了持续作出判断：解除某个 Agent 的阻塞、决定下一步方向、检查结果并启动新任务。
我通常还会让一个模型执行，再用另一个不同来源的模型审查。例如由 Opus 或 Fable 完成工作，最后固定让 Codex 审查。与其寻找一个绝对正确的模型，不如把相互独立的检查写进工作流。
我们也在 Basecamp 中尝试把 Agent 当作同事，直接分配 To-do 和卡片。为异步协作设计的工具可能比聊天框更适合 Agent。聊天会诱使人坐等回复，而把任务交给一位「同事」，你天然不会期待立刻收到回复。
05
手写代码没必要了，程序员更需要产品经理的能力
Lex Fridman：你曾经花很多时间讨论如何雕琢漂亮的 Ruby 代码，现在却不再亲手写了。你不难过吗？
DHH：我仍然在意漂亮的代码，尤其在修改 37signals 的 Ruby 系统时会仔细看实现细节。但我也越来越清楚，这件事的经济回报正在迅速下降。
过去 25 年，我审慎对待每一行代码，是因为清晰、简单、一致的架构更容易被人理解和修改。小团队因此能低成本持续迭代，也不易因一处变化引入大量 Bug。这个经济逻辑建立在人类负责后续修改的前提上。
今天，漂亮的架构仍有价值。因为 Token 依然有限，Agent 处理结构清晰的系统不必每次重新理解全部 Context，后续改动成本也更低。若连续叠加多个质量平庸的改动，代码库同样会变成一团泥。
但这只是当前阶段。未来 Token 更充足、模型更强后，过去建立的很多经验可能不再拥有相同价值。
手写代码不会消失，就像今天仍有人给 Game Boy 或 Commodore 64 写新游戏，也有人喜欢骑马。但人们这样做是因为享受限制和过程，而非因为它仍是最高效的交通方式。
我很庆幸自己经历了 20 多年手写代码具有经济价值的时代。现在，我也想看看新的东西。
Lex Fridman：如果代码主要由 Agent 产出，程序员还剩下什么价值？
DHH：软件正在变成产品管理。很多程序员并不是好的产品经理，而现在软件开发需要的恰恰是这些能力：它应该做什么、为谁而做、以什么方式实现、优先级是什么、第一版包括什么，这些才是需要回答的问题。
如果你热爱编程的唯一原因仅仅是机械地将正确逻辑结构组合起来完成他人指派的工作，那么我认为你很难适应新现实，因为这种机械化过程正受威胁。但如果你真正喜欢的是创造东西，我不认为你面临同样威胁。
软件变得更便宜后，人们也可能需要更多软件。最终岗位增加还是减少尚无定论。在一些任务固定的公司里，原本十个人的工作确实可能只需一人完成。
我的建议是：不要试图预测两次模型迭代后会怎样，那只会把人逼疯。行业里最聪明的人也不知道两年后会发生什么。关注现在，看看最先进的工具能做到什么，然后真正去做一个东西。
如果你过去一年都在徒步现在才回来，两周也足够追上前沿。很多短暂流行的循环、图和 Harness 已被快速实验筛掉，你不需要重走所有弯路。
未来无论你是否喜欢都会到来。与其花两年抱怨行业变了，不如重新理解今天的世界如何运转，再去创造更多东西。
06
与 Agent 协作，人给的指令可能越少越好
Lex Fridman：程序员和非程序员使用 Agent，得到的结果应该还是不同的吧？程序员懂循环、函数和软件工程原则，能够更系统地描述目标和验证方式。
DHH：在一段时间里，懂得太多编程知识对我反而是负担。
最初，我会按经验规定 Agent 该怎么做，它也很擅长照办，看起来非常高效。但很快，Agent 已能根据结果和问题，找到比程序员预先指定路线更好的解法。
Lex Fridman：但好的程序员仍然擅长系统设计和严谨思考。即使通过自然语言控制 Agent，也要清楚说明目标、验证方式和安全测试。
DHH：六个月前我会和你说法完全相同。但最近的经验让我意识到，很多时候需要有足够的谦逊，承认 Agent 更清楚该怎么做。
AGENTS.md 和 CLAUDE.md 就是很好的例子。曾经大家热衷于微调这些文件，给 Agent 写很长指令。但 Opus 5 的系统提示词据说缩短了 80%，因为模型不仅不再需要那么多人类指令，过度规定还会损害其表现。
任何遇到过外行老板指挥怎么写代码的程序员都应理解这种感觉：如果老板不了解具体情况却强制采用违背判断的方案，通常只会写出更差的代码。Agent 也一样。
Lex Fridman：那么，人应该提供多少信息？
DHH：尽可能模糊地开始，先让某个东西出现，然后与它互动。
敏捷开发最重要的洞见是人们无法在开始前准确知道自己想要什么。过去几十年，我们试图先把软件完整定义出来写成详尽规格再交给程序员，结果很少有人满意，因为只有真正拿到软件开始使用时，你才会知道自己要什么。
Agent 让这种方式变得非常便宜。先做出一点软件亲自试用，再决定哪里重要、哪里不重要。你不需要第一次就说清所有事情。
Lex Fridman：我会让 Agent 给出几种完全不同的设计和实现，再做一个页面，自己投票选择喜欢的版本。
DHH：对，这正是人类擅长的事情：差异化评估。
给人三个方案，他通常一眼就能选出喜欢的那个；给他 22 个，反而会被选择压垮。很多判断先来自直觉，随后大脑才替它寻找理由。如果你愿意放开一些理性的前期加工，让直觉来驱动，Agent 时代将会让你大开眼界。
07
Agent 的想法，可能比人提出的更好
Lex Fridman：当每个人都能用 Agent 为自己开发工具，怎样从只服务一个人的产品走向更多用户？
DHH：比你想象得简单。为自己做完工具后，直接让 Agent 把它放到 GitHub。它会创建代码仓库、写 README、管理 Release，甚至比大多数人更耐心地处理开源维护中的琐事。
今天一些开源维护者抱怨 Agent 带来了大量 Pull Request，我完全不理解。你可以接受也可以拒绝。开源一直承诺所有人都能贡献，但过去真正能参与的只是少数技术高手。
现在，程序员这个曾经横在人和计算机之间的「神职人员」阶层正在被绕过，有点像一次宗教改革。更多人可以直接把自己的想法变成代码，再贡献给公共项目。
Lex Fridman：难道不需要这些技术大牛来维持代码质量吗？
DHH：当然需要。我维护开源项目已 25 年，看过成千上万名程序员的工作。很多人不在 Bug 报告里提供足够信息，不解释 Pull Request 背后的原因，不写必要注释，不检查工作也不补单元测试。
但是你知道谁会做所有这些事吗？那就是 Agent。只要提出要求，Agent 大多数时候都会非常认真执行指令，有时甚至到了吹毛求疵的地步。
这意味着，如果把一个普通程序员和他们提交的 Pull Request 放到普通开源项目中，他们已经被 Agent 远远甩在后面了。
过去三个月，Omarchy 合并了超过 1000 个 Pull Request。其中很多来自非传统程序员或不熟悉 Linux 发行版开发的程序员。Agent 让他们能够贡献好想法，我再从中挑选最有价值的部分。
目前项目里还有约 400 个尚未合并的 Pull Request，我已不再逐一审查。Agent 会先过滤错误、重复和低质量内容，在虚拟机里验证 Bug 修复，再把真正需要人作决定的部分交给我。
开源项目管理的所有苦差事都在以闪电般的速度消失，留给我们的是软件开发中最精华的部分：这个项目应该做什么，下一步往哪走。
Lex Fridman：你觉得最终好的想法、想法的核心，还是起源于人脑吗？还是说可以全部由 Agent 完成？
DHH：在 Agent 的第一阶段，我确实认为所有想法都来自人类，人类告诉 Agent 去做什么。但我现在完全不这么认为了。我见过从模型中涌出的好想法，好到让我这个以好想法自居的人都感到谦卑。
那些仍然停留在「Agent 只是鹦鹉、只是复述已有想法」这种分析的人，对过去六到九个月的进步是完全脱节的。
Ropedia 刘子纬：具身智能的 Scaling Law，不是算力，是人类的经验
mirumi 创始人：不需要 AI，也可以设计出让人类爱上的机器人
诺亦腾机器人对谈源策未来：具身智能到底需要什么样的数据？需要多少数据？