☰
为什么说 Windows 桌面 Agent「能启动」,不等于「已经按发行要求隔离」?
2026/10/1 8:15:16 网站建设 项目流程
编者按|FinOS

>

企业 AI 落地翻车,很少是因为「模型不够聪明」,而是因为没有共享的操作系统:谁能代表哪个租户行动、代码在什么边界里跑、对存量系统的写操作谁说了算、员工用的入口是不是企业自己的。本系列讲清这些层,并用可核对的工程事实说话——企业 AI 操作系统。

先说结论

进程能起来,只说明启动没当场失败;发行要核对的是:主机上实际用的隔离档位,和对外承诺是否同一档。RestrictedToken 是把进程令牌削薄,兼容面宽、隔离偏弱,网络往往不会自动变成能力开关。AppContainer(内核里常叫 LowBox)是能力模型:没有对应能力就不能出网、碰设备或别人的窗口,网络锁定更严。发行前 preflight 应在只剩弱回退时拒绝上线,而不是悄悄降级还能跑。

前两篇沙箱稿讲过策略落到哪组主机机制、隔离为什么要跟具体 Agent 解开,这里不重画。本篇只追问发行:桌面安装包若允许 RestrictedToken 回退顶上,评审看到绿灯,主机上跑的可能是另一档隔离。对存量系统的写谁批准,仍是后面的行动治理。

下面从一次「周五过评审、周一抽查对不上」的现场说起。

一、复盘:「它能启动」和「发行说明写沙箱」不是同一句

RestrictedToken 说的是把进程令牌削薄。令牌是 Windows 发给进程的身份和权限清单:你是谁、能用哪些特权、访问文件时过哪几道检查。削薄就是从这份清单里拿掉特权、把一部分身份标成只能拒绝。AppContainer 是另一套能力模型:进程带着容器身份和能力清单启动。弱后端,指的是强的那套起不来时,改用较弱的那套隔离仍把进程拉起来。

周五,Windows 桌面 Agent 过了安全评审,材料写「已沙箱」。周一抽查进程:令牌是削薄过的 RestrictedToken,出网仍接近登录用户。复盘会上两句话同时出现。「它能启动啊。」「发行说明写的是沙箱。」第一句是事实。第二句把「能启动」写成了「已经按发行要求隔离」。

能启动只证明进程起来了。发行要证明的是:实际用的那套隔离,和对外承诺的那一档对得上。

二、启动成功回答的是可用性,不是隔离档位

现场最容易把两件事焊成一句汇报。「沙箱启动成功」听起来像隔离已经生效。启动成功只回答:进程没有在进门时崩溃。它不回答:文件能写到哪里,是不是和承诺的那一档一样;出网是能力开关,还是口头约定;失败之后有没有一条更弱的路径悄悄顶上。

桌面安全负责人看到的,往往是机队里的绿灯:安装包能打开,进程在,帮助台不再接到「打不开」的单。绿灯统计的是可用性。隔离要统计的是另一张表:这一台实际用的是哪一档,和发行说明是否同一档。两张表合成一句「已沙箱」,弱回退就会从缺口里漏出去。

RestrictedToken 和 AppContainer 从一开始就不是同一档。前者裁的是当前用户,不换身份,只拿掉特权、收紧身份。访问对象时,Windows 会做两次检查:一次看令牌里还启用的身份,一次看被收紧后的那份名单,两次都过才放行。桌面代理、带控制台的脚本往往还能活,因为登录用户这层身份还在。Microsoft 自己的说明也写:它不是完整的安全边界,默认桌面上的窗口消息仍可能被滥用,网络也不会自动变成能力开关。

后者从启动就换了一套身份。令牌里同时带着容器身份和能力清单。用户有权而容器没权,结果是没权。没有网络能力就出不去,没有显式授权就写不进用户目录。对「限制出网」更硬。需要跟普通桌面程序同一档信任级别才能打开的对象、要碰登录会话里其他窗口的程序,会在这里先死。死掉不是策略写错了,是这套机制和程序形态不匹配。

把其中一档说成「Windows 沙箱」,评审会问错问题。会上争论「要不要再买一个带沙箱的桌面 Agent」,却不问:发行说明承诺的是哪一档;启动失败后弱后端能不能顶上;审计有没有记下实际用的那一套。弱后端能跑,不等于文件系统和网络与 AppContainer 对等。

你看见的

它证明

它通常不证明

进程起来了

启动命令没有当场失败

隔离已经按发行要求生效

RestrictedToken 能跑

兼容面够宽

网络和文件范围与 AppContainer 对等

发行说明写了「已沙箱」

材料里有这个词

主机上没有弱回退

两套机制是不同用途的选择,不是后面那一档自动替换前面那一档。选哪一档,先写威胁模型,再写发行检查:弱回退能不能被拒绝。Windows 上不是只有一种永远最强的后端。把其中一档喊成唯一答案,下一次兼容和锁定打架时,现场只会悄悄换一条还能跑的路。

弱回退能跑,不能证明文件系统和网络已经跟强后端对等。

三、工作负载形状决定原语,弱回退不能冒充强隔离

行业里已经有人把这件事写成公开工程说明,而不是产品对比表。OpenAI 在 2026 年 5 月写 Codex 的 Windows 沙箱时,先看了 AppContainer。它是能力模型,适合事先知道自己要碰什么的应用,隔离硬。Codex 要跑的是开放式编码工作:外壳、Git、Python、包管理器,以及模型临时决定要调用的其它程序。程序实际要干什么,和 AppContainer 当初服务的那类应用对不上。他们没有把 AppContainer 当成唯一正确答案,也没有因此改成登录用户裸跑。

他们组合的是另一组零件:RestrictedToken、专门为沙箱造的身份(合成 SID,不对应真实用户,只出现在访问控制名单里)、以及提权安装后的独立沙箱用户。不提权的一档网络锁定偏弱,用环境变量拦网只是劝告,进程可以不理;防火墙也套不到「令牌里带着某个合成身份」这种条件上。提权后的一档换了运行身份:命令跑在 Codex 自己建的沙箱用户下,再套 RestrictedToken,防火墙才能对准这个用户。公开文档把两档都写在名字上:elevated 更硬,unelevated 是回退。企业还可以在管理配置里只允许 elevated,不许用户自己掉到 unelevated。这已经是发行闸门:哪一档准许出厂,写在管理配置里,而不是写在「反正能启动」里。

同一套权限说明还写了一句对发行更有用的话。选中的策略如果没法被平台沙箱执行,Codex 拒绝跑这条命令,而不是悄悄改成没有沙箱。Windows 上,unelevated 执行不了「这块只读、那块可写」的拆法时,也会被拒绝。裸跑要另开一档,名字就叫危险的完全访问,必须故意打开。社区里也有失败关闭的记录:安装助手起不来时,命令根本没有启动,没有自动改成不受限执行。

这不是拿 Codex 打榜,也不是说「编码 Agent 就该用 RestrictedToken,企业桌面就该用 AppContainer」。它证明的是两句能核对的判断。程序实际要干什么,决定用哪组操作系统机制:开放式编码和「事先知道要碰什么」的应用,不是同一套。弱回退不能冒充强隔离:回退可以存在,但必须叫自己的名字;无法按选中的策略对等执行时,拒绝裸跑,而不是把「还能启动」写成「已经隔离」。

程序实际怎么干活,决定用哪组机制。较弱的那条路径,不能对外说成已经达到较强隔离。

四、五种把「能跑」写成「已隔离」的做法

现场反复出现的,不是「Windows 没有沙箱」,而是发行把能启动当成了已隔离。

1. 启动成功就写「已沙箱」。评审问落到哪一档令牌、出网是不是能力开关,回答是「安装包能打开」。

2. 强后端起不来,弱令牌悄悄顶上。界面还是同一句「沙箱已启用」。审计没有记下实际用的那一套。用户看到的隔离名字没变,主机上已经换档。

3. 把兼容回退写成发行默认。RestrictedToken 偏兼容,不少程序还能跑。发行如果把它当成「反正能出包」,网络锁定那一档从未被核对。兼容是实验室里把程序跑起来的理由,不是发给整机队的理由。

4. 把某一种后端说成永远最强。兼容和锁定从一开始就不是同一档。唯一正确答案会逼现场在发不出包时撒谎。

5. 把「用户点过完全访问」和「启动失败后的静默降级」当成同一件事。前者是操作员故意打开的宽权限。后者是发行路径自己换了档,还沿用原来的功能名。

更好的做法很短。先写发行承诺的那一档:文件范围,出网范围,落到 RestrictedToken 还是 AppContainer。再写检查:只剩弱回退就拒绝上线,不要悄悄降级还能跑。回退如果存在,必须出现在审计里,并且不能沿用强后端的名字。沙箱只约束怎么跑;跑什么留给运行时,对核心系统的写留给行动治理。

发行检查要拦的,是实际隔离已经换档、对外名字还叫沙箱。

五、一条可核对的发行前拒绝

分层讲到这里,已经不依赖任何一家供应商。需要的是存在性证明:Windows 桌面有没有两档后端,发行向启动能不能在只剩弱回退时拒绝。

凡泰的 FinSafe 按公开文档,定位为主机隔离层。Windows 桌面同时提供 RestrictedToken(偏弱、偏兼容)和 AppContainer / LowBox(网络锁定更强),并配有 Windows 指南和安装设置流程。这只证明双后端被写下了,不证明「只有一种后端且永远最强」。

发行向启动落在另一条检查上。Windows 发行向启动要求 AppContainer / LowBox;仅仅落到 RestrictedToken 的回退,会被启动前检查拒绝,因为它无法提供文件系统与网络对等。进程还能起,过不了这道检查。这只证明「能启动」过不了发行关,不证明运行时选对了任务,也不证明对 ERP 的写已经被批准。某一款封闭桌面 Agent 是否已经全面商用纳管,公开材料给不出这张清单,本文也不写。

发行前检查拒绝弱回退,证明的是「能启动」过不了关。它不证明下一步任务选对了,也不证明写接口已经被批准。

这只是沙箱层在发行这一步的存在性证明,不是「过了检查等于有了操作系统」。操作系统还要有连接面、常驻执行器与租户路径、行动面治理、企业自己的入口。没有发行前拒绝,后面的层会在弱令牌里跑,还对外说已经隔离;只有这一层,生产写操作照样会从旁路溜走。

公开文档能核对的是:Windows 双后端、发行向启动要求 AppContainer / LowBox、仅 RestrictedToken 的回退会被检查拒绝。核对不了吞吐量、客户名单、等保结论,也核对不了「某款桌面 Agent 已全面纳管」。把能启动说成已隔离,和把权限弹窗说成内核隔离,是同一种层错位。读者带走的应是可复述的两问:发行承诺的是哪一档;只剩弱回退时,是拒绝上线,还是照样出包。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询