都在往模型层和框架层挤，这账本身就错层了。先把判断搁这：agent 安全这个方向，现在最拥挤的地方，恰恰是最不该堆人的地方。一群人忙着让 agent 保证自己会负责任地 curl，给 prompt 加护栏，在 agent 框架里做权限检查。说句扫兴的，这些全是软建议，不是边界。那篇 ShrekOS 的帖子有句话我越看越对：agent 就是个 client，云模型也好、本地模型也好、以后换哪个也好，安全本来就不该住在 agent 以内。真正该做的是把信任决策从 agent 手里拿走，放到操作系统那一层去。可这活没人愿意碰。它不赚钱，没故事。护城河还未必长得起来。
上个月我在 dev.to 刷到一篇，标题叫 Why I'm Building ShrekOS When Containers Already Exist。点进去之前我以为又是整活。结果这哥们从 ffmpeg 开始讲，讲到一半我就知道，他是真撞见过那堵墙。
他想让 agent 干普通电脑的活：装 ffmpeg、编译代码、看项目、开工具、访问网络。结果发现让 LLM 吐出正确的 shell 命令并不难，真正难的是——这命令该带多大 authority。等他试着把 agent 变得真有用，总是滑向两个坏结果之一：要么环境收紧到连装个依赖都别扭，要么把真机器交出去，一次幻觉、一个被投毒的依赖、一句 prompt injection，就能造成实际损失。
他说得挺直接：核心问题从来不是 ffmpeg 本身，而是“装它”这个动作，等于把一个不可预测的程序放到了你自己的机器上。apt install 一下，包库被改，没审计过的依赖进来了，安装脚本跑起来，符号链接建好，配置文件写到它想写的地方，还要 root 去动系统目录。今天要 ffmpeg，明天要个别的，每装一个，host 上就多一层不可控状态。几个月之后，那台机器与其说是你的，不如说是它和它那些依赖一起编辑出来的。你细品一下这句话。
先算笔账。护栏那条路线：agent 每要干一件事，前头加一道模型或者规则判断，token 多烧一轮，漏判率就算只有 1%，碰上 prompt injection 或者 poisoned dependency 这个数还得重算。agent 每多跑一步，成本就往上走。安全性是概率。OS 边界那条路线：AppArmor 写一次路径规则——他选 AppArmor 就是看中路径模型，策略是能读懂的普通文件——之后每次执行由内核强制，不允许就是不允许。每次跑的成本几乎为零，安全性是判定，不是概率。一笔账算下来，护栏等于给事故买保险，保单还是模型自己写的。
谁在赚？卖护栏的公司、做 agent 安全咨询的、往框架里塞安全模块的，这些人赚得最舒服。因为护栏天然适合做成订阅，持续消耗、持续更新、持续需要人来盯。谁在亏？最后拿 agent 跑真实机器的人。他以为上了护栏就安全了，其实是把事故从今天挪到了改天，保费先交了，真出事儿的时候还得自己赔。
OS 层这活为什么没人挤？因为它天然反商业化。你去翻那篇帖子，作者自己说得明明白白：ShrekOS 不是从零写的操作系统，没写内核，没发明容器，也没发明沙箱。它只是把 containers、namespaces、cgroups、egress filtering、package managers、mandatory access control、immutable filesystems、signed boot 这些早就有的东西，组合成一个连贯的运行模型，给一个运行时自己请求能力的 workload 用。你数数这一串，哪样不是现成的。组合本身很难收钱。你卖的是个思路，不是产品。思路这玩意儿，别人抄起来连招呼都不打。
还有个细节我觉得比帖子主线更值钱。作者一开始倾向 Fedora，冲着它那个 sealed verified boot 的工作去的，结果当天下午就反转，选了 Debian。理由特直白：base distro 大概只占项目的 15%，真正有趣的部分跟 distro 无关；而这玩意是要维护多年的，Debian 里他更快。他选 Debian，做成 sealed、immutable，原子更新，坏了能回滚。Fedora 最后只留了两个位置：一个在 VM 里当参考镜像，一个在 build tooling 里当便宜的逃生通道。
我一开始其实也站 Fedora 那边，觉得 sealed boot 是硬安全赢家。后来看完他的理由才回过味：那 15% 真不是胜负手，真正贵的是他后面那句话——只要发现一个所谓的硬安全赢家不是承重墙，他就立刻反转。这不是摇摆，这是方法论。一个不承重的安全卖点，留着只会给你虚假的确定性。这个判断，比选 Debian 还是 Fedora 贵多了。
插一句不相干的。这作者其他文章的标题也挺离谱，什么“多少 LLM agent 才能拧一个灯泡”、果蝇的遗传记忆那类。跟今天这笔账没关系，拉回来。
泼完冷水，我给条窄路。OS 层这事没护城河，别人能抄，作者自己也承认 ShrekOS 不是新发明。但眼下 agent 落地最缺的，恰恰不是一个更聪明的护栏，而是一个“临时强大但不会自动变成权威”的地方。他结尾说下一篇要先写个更小、更具体的东西：让 agent 可以暂时有力，却不因为这份力自动获得对你机器的 authority。
这两者的区别，就是那笔最容易漏算的账。很多 agent 工具图省事，跑起来就给 root 或者全家桶权限，把“现在能把事办了”直接等同于“它可以一直对这台机器说了算”。短期看账是平的，甚至省了配置时间。长期看，这台机器的状态、数据、网络出口都在替一个你管不住的程序兜底。等真出了岔子，你可能连它到底碰过哪条路径都说不清。
所以现在如果有人想卡个位，别去卷第 N 个护栏框架了。去做那个能力授权层：在 agent 启动之前就把“这台机器上什么能碰、什么不能碰”定义死，做成硬边界。这条路窄，赚不到快钱，但账算得过来——纯工程成本，没有模型推理开销，边界是确定性。而且这件事早做的人有定义权。等 agent 真进了生产环境，事故多起来，谁能先把这套跑通，再回头看，同一句话说出来就不是现在这个价了。
作者最后问了一句：agent 应该被允许改什么？我看那几条评论，没人接得住。因为答案根本不在模型层，也不在框架层，在每一台实际机器的文件系统路径和 package database 上。这活又脏又没掌声，正好没什么人跟你抢，账反而比谁都清。这笔账，你自己算。咱下篇见。