假装成功：人还没点同意，系统先骗 Agent 说已经办好了

这套做法写在给 Gatekeeper 开发者看的接口说明里：

建议看门人对尚未批准的动作做「模拟」，也就是说，Session 这个接口应该表现得就像所有动作都已经执行过了一样。

It is suggested that the gatekeeper "simulate" actions that have not been approved yet, that is, the Session interface should reflect the state of the resource as if all actions had been applied.

cloudflare/cloudflare-os · gatekeeper.ts

有一个细节值得说清楚：模拟并不是强制要求，做不做由各个 Gatekeeper 的作者自己决定。真正不能碰的红线是另外三条，每个操作都必须进审批队列、读取必须先过授权、有副作用的动作在批准之前绝不能真的执行。「假装成功」只是让 Agent 别卡住的一个可选优化。

沙箱隔离：每份文档关在自己的单间里，代码写烂了也波及不到别人

Cloudflare OS 的主导者、Cloudflare Workers 的作者 Kenton Varda，在发布当天的原话是：沙箱安全到你可以随便折腾，AI 不可能引入重大的安全漏洞；一家公司的安全团队可以放心让不懂技术的同事去 vibe coding，然后晚上睡得着觉。

这个「每份文档一个隔离实例」的思路，来自 Kenton 十年前的创业公司 Sandstorm，当年没做成。为什么没做成，有两个说法。一是太贵：那时候只能拿容器做隔离，开一个实例的开销远比现在大。二是 Kenton 自己给的原因：世界还没准备好，没有足够多的人有本事或者有耐心去改自己的软件。两个原因凑一起才说得通，技术上终于便宜了，同时也终于有人会用了。

便宜了多少，官方给的数字是这样：

isolate 是 V8 引擎（Chrome 跑网页用的那个）开出来的轻量执行环境。剖析文章里说容器「冷启动要好几秒」，比官方口径夸大了一个数量级，本站按官方数字。

剥夺密钥：Agent 永远拿不到密钥，只能调几个规定好的方法

这套「只给方法不给钥匙」的做法有个正经名字，叫对象能力模型（object-capability），是个在安全圈子里研究了几十年的老思路。

追踪数据来源：系统记着 Agent 读过什么，分享前先查对方有没有资格看

极速兜底（锁定模式）：有些数据太敏感，现有的规则还没法精细描述该怎么管，那就干脆给它挂一个「禁止一切分享」的标志。gadget 只要读了一次这种数据，立刻掉进锁定模式，还能继续读，但从此不能通过任何一个看门人做任何一个动作，彻底封死泄密通路。代码注释里也承认这是个临时办法，以后要换成更精细的规则。

顺带一提，prompt 注入在这套架构里仍然没有解决。源码的待办清单里还写着两条想做没做的事：判断一次读取里有没有可能藏着注入攻击的自由文本，以及判断哪些人往这些内容里写过东西。

连人类贡献者也不信任：外部提交的代码超过十几行，直接关掉

一份没人审过的贡献就是不可信输入，至于它是一个马虎的人写的还是一个自信的模型写的，几乎不重要。系统对 AI 的不信任，就这样延伸到了对人类贡献者的不信任。

这套设计的代价：管得越死，它能帮你干的活越少

前面五道机制都很聪明。但它们有一个共同的代价：你把 AI 管得越死，它能帮你干的活就越少。具体是两件事。

第一，Agent 永远拿不到密钥，就永远干不了必须拿密钥才能干的活。比如让它自己去续费一个服务、去调一个没人提前给它开过口子的接口，它做不到。系统设计上就不给它这个能力，它只能在你提前圈好的范围里活动。范围之外的事，还是得人来。

第二，写操作永远要人批，等于人永远离不开这个流程。这套设计确实让你不用每一步都盯着，但那一批挂起的动作，最后还是得你来看、你来点。而 Agent 本来要解决的就是「不用人一直盯着」这件事。绕了一圈，人还在流程里，只是从「每一步都在」变成了「最后一步一定在」。

一句话概括这个取舍：拴住它、让它不闯祸的那根绳，也正是让它拉不动多远车的那根。你不可能同时要最大的自主和最大的安全。Cloudflare 选了安全，而且选得很硬。他们赌的是：一个被拴着、但你敢放进公司用的 Agent，比一个自由、但你不敢部署的 Agent 更值钱。

还有一个矛盾：它谁都不信，唯独信自己

这套系统的逻辑是「谁都不能信」：AI 不能信，用户写的代码不能信，外面来的程序员也不能信。

但有一方例外，就是 Cloudflare 自己。

因为用来做隔离、做审批、做记录的那些技术（Workers、Durable Objects 这些），全是 Cloudflare 自家的东西，有几样甚至是专门为这个项目才做出来的，别处根本没有。于是这套「谁都不信」的系统，它自己的地基恰恰是「你必须信 Cloudflare」。

好在它整个开源，跑在同样开源的 workerd 运行时上，理论上你可以搬到自己的服务器，这一点已经比大多数同类产品强。但只要你用它，就得先接受这个前提。

最后：连造它的人都还没想好该怎么定义 Agent

仓库里有一张表，把 Cloudflare OS 的每个部件对应到传统操作系统上：内核对应什么、驱动对应什么、进程对应什么。前面几行都对得上，只有最后一行空着，写着三个问号。

问号那一行的意思是：传统操作系统里，压根没有「AI Agent」这个东西。

它算不上普通用户：用户的权限是提前定好的，而 Agent 得对某个具体的人负责，权限还要随时收放。它也算不上普通程序：程序的代码是提前写死的，而 Agent 是现写现跑。

Cloudflare 给的答案是，这种东西最合适的管法是「你只能干我准许你干的这几件事」（也就是前面说的能力模型），而不是传统那种「你属于哪个组、有哪些权限」的清单。

但他们也没把这一行填上。这是一个新物种，连造它的人都还没想好该怎么定义它。

Agent 想干一件有后果的事，合并代码、发邮件、往正式系统里写一行数据，必须走一个叫看门人（Gatekeeper）的小服务。人工批准之前，看门人会说谎。

有个限定得说清：模拟并不是强制，做不做由各个看门人的作者自己定。真正不能碰的红线是另一条，有副作用的动作在批准之前绝不能真的执行。

剩下四道机制各管一段，串起来是同一句话的四个推论。跟着小互做一份季度汇报走一遍：

沙箱这招十年前就有人试过，Kenton Varda 的创业公司 Sandstorm，当年只能用容器做隔离，太贵，没做成。现在便宜了这么多：

这三个数字出自 Cloudflare 的 Dynamic Workers 技术博客，第三方尚未复现；剖析文章把容器写成「冷启动好几秒」，差一个数量级，本站不采用。

五道锁全上之后，Agent 手上还剩什么：