别让 AI 问你“可以吗”

发表于2026-09-03|更新于2026-09-15|AI

|总字数:6k|阅读时长:18分钟|浏览量:

别让 AI 问你“可以吗”

如果你用过任何一个 AI 编程助手，一定见过这个窗口：Agent 想执行一条命令、读一个文件、改一个配置，系统弹出一行字——“是否允许？”，下面两个按钮。多数人怎么处理？不读，直接点“始终允许”，好让这件事别再烦我。这不是粗心，是生理规律：人没法对每小时出现几十次的安全问题保持警觉，警觉是稀缺品，用一点少一点。

这篇文章想讨论的不是“怎么教育用户好好读弹窗”——那是把设计责任转嫁给受害者。真正值得看的是：2026 年，第一批把 AI Agent 当作“一等公民”来设计的操作系统出现了，它们对同一个问题给出了三种互不相同、而且都刻意不依赖弹窗的答案。

这三个系统是 Omarchy、Ubuntu 26.04，以及我自己参与设计的 Linxira OS。它们站在同一条光谱上：系统允许 Agent 扮演什么角色——改造者、租客，还是只读访客。光谱尽头是一句反常识的结论：弹窗问得越勤的系统，往往越不安全。

一、旧世界：一次授权，终身信任

先说旧操作系统怎么处理信任，因为 Agent 撕破的正是这套旧逻辑。

传统模型可以叫“门卫模型”：装软件时，系统问你一次——要不要装、要不要管理员权限——装完就不再问。之后程序在你眼皮底下运行，因为你才是动作的发起者，命令是你敲的，风险由你当场承担。sudo 的发明还承认了另一件事：有些动作太危险，哪怕是你亲手敲的，也要重新验一次身份。注意，旧世界的每一次“确认”，对象都是人——一个会读、会想、刚刚亲手敲下这条命令的人。

这套模型有两个隐藏假设。第一，动作的发起者是人；第二，人的判断力可以无限续杯，每次都像第一次那样认真。

Agent 把两个假设同时打断：动作的发起者从人变成了模型，动作频率从“一次安装”变成“每秒钟都在调用工具”。门卫模型随之出现两条短路：要么每个动作都问——人会在第 N 个弹窗后疲劳、盲点、连点“允许”；要么干脆一次性全给——也就是所谓 yolo 模式，把整串钥匙丢出去。两条路都不像答案。

旧世界敢“装完就不再问”，还藏着一个更深的假设：程序不会自己扩张。一个程序装进去是什么权限就是什么权限，它不会突然决定去读你的私密目录。Agent 打破了这一点——它每一步都在自主决定下一步调用哪个工具，权限边界不再是安装时画死的线，而是它每一秒都在试探的活边界。于是“问不问”从偶发仪式，变成了结构性难题。

真正的答案绕开了“问不问”这个表面问题，指向更深处：信任应该被设计在系统的哪一层？ 这是所有 agent 原生操作系统真正在回答的问题。

二、断裂：当“可以吗”成为日常

先看最流行的做法——弹窗派。它把“人判断”做成了一道精致的产品：OpenCode、Claude Code 等编码 Agent 把动作分组、逐组弹权限请求；Ubuntu 26.04 也宣布给受限应用加 Android/iOS 式的细粒度权限提示。方向看起来无比正确：把决定权交还给用户。

但公开的 issue 记录显示，这套承诺在运行时多处失效：

anomalyco/opencode #32787：用户配置的 permission.ask 规则运行时根本没有被执行——承诺在纸面上存在，引擎却没兑现；
#24335：一条通配符规则能覆盖更严格的具体规则；#37880：用户明确选的“始终允许”不被尊重；#39576：子代理能绕过父级约束提到更高权限；
anthropics/claude-code #75588：在 bypass-permissions（免确认）模式下反而弹出“是否执行 rm -rf *”——该问时不问、不该问时乱问，时机完全不可预测；
openai/codex #42480：会话中删掉了生产数据库——事后查明是模型把测试脚本的 drop_all 打到了生产连接。这与权限无关，是环境判断失误：弹窗问一百次“可以吗”，也救不了“它根本没意识到自己在哪”的错误。

三桩事故各戳破一件事：引擎没兑现承诺、询问时机不可预测、问一百次也救不了理解错误——弹窗这道工序本身，没有一处是可靠的。

最依赖人审的厂商，自己先承认了人审失败。OpenAI 在 2026 年 4 月上线的 Codex Auto-review 机制里写得很直白：“批准摩擦伤害安全”——用户面对一串弹窗只会连点“是”，或干脆配一条“所有 python 开头的命令都放行”的宽泛规则，等于亲手拆掉沙箱。于是 OpenAI 把审批人换成第二个 AI（独立评审模型），站在沙箱边界替人判断：打断次数降到人审的约 1/200，99.3% 的提示注入被拦下，连续 3 次或 50 次窗口内 10 次拒绝触发熔断。

这里还有一组反直觉的实证。oh-my-pi（OMP，一个默认 yolo 的 Agent 框架，我们自己的 zeta 基于它）被社区长期使用，但在公开 issue 里检索“删了我的文件”类报告，结果是 0——换过各种模型，几乎没有误删关键文件、偷读隐私的报告。这不是说 yolo 绝对安全——检索只是抽样，社区报告不等于审计。它说明的是：当安全重心放在工具层拦截与循环设计（引导模型不删改、用只读复核），而不是询问层时，“误删”会从高频事故变成不需要出现的事故类别。OMP 把这一套写成了明确的分工：vibe 模式下，只读的 director 负责派活，能写的 worker 负责执行，干完再由 director 用读取动作复核结果——判断不靠问，靠的是职责分离。

把 2026 年的授权设计摊开，能画出四派光谱：

派别	代表	边界由谁判断	失效模式
人判断	Ubuntu 细粒度提示、OpenCode、Claude Code	用户，逐动作弹窗	疲劳盲点；承诺运行时失效
AI 判断	OpenAI Codex Auto-review	第二个 AI，仍在边界逐动作审	评审被诱导的风险，靠熔断兜底
不判断	Omarchy、OMP 系	不弹窗；工具自声明破坏性模式 + 撤销兜底	拦不住破坏进行中，只保证可回滚
少判断	Linxira	无运行时边界可判，判断挪到构建期	Agent 够不到写权限，也干不了需要它的活

中间两派的共同点值得注意：无论判断者是人是 AI，判断都放在“边界上的每一个动作”上——这是弹窗逻辑的延续，只是把窗外的人换成更耐疲劳的部件。真正的分水岭在另外两派：不判断派把安全挪进工具层与恢复层，少判断派把执行能力本身删掉了。

这里需要一张地质剖面图。安全不是一道工序，是一组地层：最表层是弹窗（逐动作询问）；往下是工具层（工具自己声明“我是破坏性的”，如 rm -rf /、写 /etc/passwd、远端取回即执行——OMP 文档里这些模式强制拒绝或改问一次，优先级高于一切自动批准）；再往下是沙箱层（Ubuntu 的 snap/LXD/microVM 隔离）；更深是能力层（某些能力根本不暴露给 Agent）；最底是恢复层（快照、重置、回滚）。弹窗是唯一把判断外包给外行的地层，也是唯一被疲劳击穿的地层。设计得好的系统从不把所有重量压在一个“可以吗”上——工具层拦明显自杀，沙箱层挡物理越界，能力层让危险动作不存在，恢复层保证捅了娄子能回去。

但这张剖面图默认了两件事。第一，五层住在两个不同的主体里：弹窗与工具层在 agent 运行时内部，沙箱、能力、恢复层在宿主系统里——中间隔着一道“由谁实现”的墙，图纸上画得再漂亮，也不等于墙真的砌好了。第二，每一层都值得信任。2026 年 8 月，第二个默认被当场拆穿：DeepSeek 官方开源的 agent 底座 dsh（Agent = Model + Harness，上线十八天拿了二十万星）十天之内被安全机构连爆五个洞，其中两个极危。一个是链式沙箱逃逸（CVSS 10.0）：恶意网页诱导模型挂载动态插件，逃逸代码发现进程级沙箱的约束只装在 shell 这一层，绕开它直接走裸 subprocess 在宿主机执行任意命令——没有文件写入、没有审批、不依赖任何部署失误。另一个是未授权远程代码执行（CVSS 9.8）：它的网页端拿 HTTP Host 头判断“请求是不是来自本机”，可 Host 头恰恰是来访者自己填的——伪造一下就绕过整道信任围栏，不需要任何 API Key 就能在服务器上开 shell，PoC 已经公开。弹窗会疲劳，工具层的承诺会失约，现在连沙箱与信任边界本身，都可能建立在错误的地方。授权哲学争的是“该不该问、谁来判”，dsh 把问题又往下压了一层：你的安全机制本身，可不可信？

三、三站：agent 时代的三种信任设计

光谱上有三个真实站点，正好对应 Agent 在系统里的三种角色。下面用同一套三问来读它们：它碰得到什么？边界由谁定？越界了会怎样？

第一站 · 改造者：Omarchy

DHH（Ruby on Rails 作者）在 Arch 上做的发行版，自称“为 agent 时代准备的可塑系统”。它的 Agent（Hermes，以及可接入的 Claude Code、Codex、OpenCode）不只聊天，还能直接改 Hyprland 窗口配置、换主题、读崩溃日志，甚至内置崩溃监视器——应用一崩，系统先问你要不要交给它诊断。插件市场开张三天就有 330 个社区插件上架，因为它内置一套教 Agent 给系统写扩展的规范——操作系统本身可以被 AI 改写，这正是卖点。配套安全：强制全盘 LUKS 加密、默认防火墙、快照回滚、一键 Reset Computer、动手前先出方案的 plan mode。

它碰得到什么？ 几乎是整栋房子。主账号默认免密 sudo，官方手册对这句取舍有句著名坦白：“这正是全部的意义，也正是全部的风险。”Agent 名义上能执行任何命令。
边界由谁定？ 几乎不靠逐动作询问。信任被前置成两个动作：开工前出 plan（人看方案不看代码），把“撤销”做成系统级能力。它赌的是你的回滚能力，不是 Agent 的判断力。
越界了会怎样？ 快照回滚 + Reset Computer：任何破坏都能回到破坏前。代价是防不住“当场破坏进行中”，只保证“事后一定能还原”。

一句话：这是把整串钥匙交给装修队长的房子。你押的不是工人品德，是保险公司。

第二站 · 租客：Ubuntu 26.04

Canonical 在 2026 年中的 Ubuntu Summit 上把 26.04 定调为“AI agent 时代”的操作系统，安全路线是另一极：把一切关进沙箱。snap 约束、容器、LXD 系统容器、虚拟机、新一代 microVM（Open Shell）构成多层隔离，Agent 默认待在受限套间；要动敏感资源时，Workshop 按任务把 SSH 密钥等秘密“选择性绑定”进工作区，而不是把整台笔记本的环境倒给它。Shuttleworth 的原话：你可以运行来自互联网的随机代码，而不必把 root 交给它。

它碰得到什么？ 被切成碎块：GPU 与点名文件可以给，凭据、家目录其余部分默认不给。Agent 是住在单间里的租客——房间里家具齐全（假装是一整台 Linux），但墙是物业砌的。
边界由谁定？ 人。Ubuntu 同时引入仿 Android/iOS 的细粒度权限弹窗：访问摄像头、读目录、装东西都会问你。这是四派里最正统的“人判断”，也继承了人判断的全部失效模式——疲劳、不读、宽泛规则。
越界了会怎样？ 物理隔离层很硬：租客在房间里凿墙（内核级逃逸），microVM 的硬件隔离还在——但“还在”是审计出来的，不是图纸上画出来的：8 月 dsh 的沙箱刚被链式逃逸过，隔离的实现层从来不值得盲目信任。真正软的是那扇门——门锁再好，架不住房东（你）每次都被问“开不开门”，问烦了说“以后都别问了”。

一句话：这是一栋锁比房间多的公寓。物业极其负责，但它把全部安全责任浓缩成一句每天问你几十遍的话——而你根本没在听。

第三站 · 只读访客：Linxira OS

第三站是我自己参与设计的发行版（Arch 系、面向科学计算的工作站系统），它选了光谱的另一端：Agent 在系统里没有执行把手。系统自带的 Welcome 界面刻意做成只读——不执行 shell、不做包事务、不碰 sudo/pkexec，它只是一面展示系统状态的玻璃；配套 Agent 被设计成不接受任何包名、命令或 URL，你说漏嘴给它一个包名，它也只会拒绝或把你导向正规渠道。系统里唯一改变系统的动作是装软件，而装什么要过 Package Center 背后的目录审查门——软件包先经人工 review 才可选。

它碰得到什么？ 看得到一切，摸不到任何把手。读系统状态、查日志、给建议都行；写操作在物理上不存在于它的工具面里。
边界由谁定？ 没有“运行时边界”需要人判——判断被挪到了构建期：装哪个包、什么版本，由人与审阅流程在安装前一次性定完。运行时没有值得逐动作判断的东西，因为没有破坏性动作可发起。
越界了会怎样？ 最坏是装了个不想要的包，卸载即可。“误删关键文件”在结构上不存在，因为没有删除入口。代价也清楚：它干不了需要写权限的活，重活得人亲自走到那道闸门前。

但“只读”要回答的不只是破坏，还有偷看。2026 年 8 月，dsh 的只读模式被证明只拦了写、没拦读：整个宿主文件系统以只读方式挂进沙箱，模型读 ~/.ssh、读 .env、读凭据畅通无阻，还零审批。这提醒所有走“只读访客”路线的人：删掉写把手，只堵住了“改”，没堵住“看”。只读的完整定义不是“不能写”，而是“不该看的一律看不到”。Linxira 的应对是把只读画在可读集合上——Welcome 只接收聚合后的系统状态用于展示，私钥与凭据这类原始秘密，根本不进入 agent 的可读面。把“只读”从一句营销承诺，做成一道真正画在可读集合上的边界。

一句话：不是不相信访客，而是没必要把展厅设计成能被搬空的样子。安全不是靠盯人，是靠没有门。

三站对照

三问	Omarchy · 改造者	Ubuntu · 租客	Linxira · 只读访客
碰得到什么	系统配置 + 免密 sudo	沙箱内动作 + 按任务注入的秘密	只读面板 + 目录审过的包
边界由谁定	前置 plan + 撤销能力，几乎不问	人，细粒度弹窗逐个问	无运行时边界；构建期已审
越界了会怎样	快照 / 重置回滚	多层隔离，但弹窗疲劳失效	最坏是装错包；删除类事故无入口

三站没有高下之分，它们服务不同的人：Omarchy 给愿意亲自掌舵的老手，Ubuntu 给需要规范化的组织，Linxira 给“只想让 AI 帮忙看、不想让它帮忙动”的场景。真正的分界线不是“问不问”，而是判断放在表层还是深层。

四、两个 DHH：授权要跟着撤销成本走

Omarchy 的作者 DHH 自己就是最好的对照实验。2026 年 8 月他在播客里说，Omarchy 最新版 Quattro 最后两个月的代码 100% 由 Agent 产出，他一行业没手写，只看整体形状和关键模型层——“在产生代码、选择路线的那部分里，我已经变得可有可无”。

同一场访谈里还有另一个故事：他自己的公司 37signals 做 Basecamp 5 时，允许设计师直接用 Agent“凭感觉”实现功能。单个 Pull Request 单独看都合理，合在一起却“摧毁了系统的架构”，最后靠程序员手工清理。同一批 Agent、同一个人掌舵，为什么一个成功一个翻车？

差别不在“信不信 AI”，在任务性质。Quattro 是绿地：新系统、有回滚、坏了能重来，人可以只审形状。Basecamp 5 是存量架构：每行新代码都压在这二十年积累的决定之上，架构一旦被悄悄腐蚀，没有“回滚架构”的按钮。授权边界应该跟着撤销成本走，而不是跟着信任度走。 信任是道德问题——你相信它不会乱来；撤销成本是工程问题——它乱来了，你要付多大代价才能回去。工程师只应该回答工程问题。

这解释了一切：Omarchy 敢给 Agent 系统级钥匙，是因为底下垫着快照与重置，撤销成本趋近于零；弹窗派把每个动作都问一遍，恰恰说明它没有低成本撤销手段，只能把安全寄托在你每一声“允许”上。把 Agent 当编辑而非作者，是 Omarchy 的修辞——但真正让它敢这么做的从来不是修辞，是那枚随时能按下的重置键。

五、祛魅：Omarchy 并不特殊

但 Omarchy 值得看，不等于值得跪着看。它身上有太多叙事成分，需要单独拆出来泼一盆冷水。

先看资本信号。Omarchy 并不是新面孔——它 2025 年年中就发布了，真正把它顶上热搜的，是 8 月 14 日的 4.0 大版本 Quattro（单日涨星上千、ISO 日下载逼近五千）。而 Quattro 发布一周后（8 月 21 日），一个一千万美元规模的基金会（Omacom Foundation）就在它身后立了起来：八位创始赞助人各出一百万美元，三天后又追加两笔——基金会不会凭空出现，它的存在说明这套“操作系统 + agent 时代”的叙事背后，有组织与资本在成体系地推动。对这类组合，正确的姿势是审慎观望：它到底是不是下一个里程碑，得等两三年后社区还在不在、快照与重置之外有没有长出真正的架构创新，那时候再下结论不迟。

再看技术成分。Omarchy 没有魔法。它基于 Arch——而 Arch 的立身哲学，本来就是“把机器完整交给你”。把这句话拆成两层看：Hyprland 平铺桌面、快照与重置，这些是系统件，Arch 生态天生就有；而“让 Agent 读日志、改配置、生成插件”，并不是发行版的能力——那是把 Hermes 这样的 agent 接进来之后才有的能力，任何一个 Arch 发行版都能接同一个 agent。没有一样是 Omarchy 发明的。它和其他发行版真正的分野，细看其实只有一条：授权架构的取舍——敢不敢把“免密 sudo + 快照兜底”这套组合产品化地摆上台面。Omarchy 选了敢，大多数发行版压根没把 Agent 当一等公民来设计，而同样是 Arch 系的 Linxira 选了第三种：干脆不给 Agent 执行把手。差别从来不是发明了什么，而是把信任放在哪一层、愿不愿意为它兜底。

这恰好印证了本文的论点：所谓 agent 原生操作系统，并没有发明什么新的安全机制，它只是把权限放到某一层（免密执行 + 撤销兜底），然后产品化地摆上台面。分水岭从来不是“是不是 agent 原生”，而是权限放在哪一层、撤销成本有多高。Omarchy 的价值是示范，不是独门绝技——Arch 早就给了你同等的自由度，差别只在于你敢不敢承担它。

8 月里两个顶流项目在安全上的表现，正好给这种观望补了注脚。dsh 的 README 白纸黑字：未经安全审计的开发者预览。Omarchy 的 Quattro 发布十一天后（8 月 25 日）就出了 v4.0.1 安全跟进，一口气修掉 10 个安全问题——包括“已安装主题可执行任意代码”“USB 设备名被当作 Hyprland Lua 执行”——并顺势成立 Security 团队与漏洞披露流程。注意 Omarchy 的“主题可执行任意代码”和 dsh 的“配置即代码”，几乎是同一道伤口：凡是让用户或 AI 能装扩展的系统，扩展的加载路径就是代码执行路径，热度只会把这条路径越撑越大。安全成熟的节奏从来追不上热度的节奏——Omarchy 的应对算体面，但这恰恰是它需要被观望的原因。