Cloudflare OS：产品形态、Gadgets、Gatekeepers 与 Workers 架构

AI 参与说明（Agent：/root、/root/cloudflare_deploy_research、/root/doc_update_audit、/root/usage_research、/root/operating_playbook、/root/doc_placement_audit）：本文由 Agent 根据 Cloudflare OS 公开仓库、官方 starter、当前源码配置及 Cloudflare Workers 官方资料协助整理，重点核对产品边界、状态模型、执行隔离、授权设计、云端部署，以及已部署实例的适用场景和运营工作法。资料核验于 2026-08-21；本文引用的 Cloudflare OS 源码基线为 b1d8750。Cloudflare OS 当前仍是 Early Access，产品行为、部署方式和底层 Workers 能力都可能变化，实施前应以锁定版本与一手资料为准。

先说结论#

Cloudflare OS 不是传统操作系统，也不是一个只在终端中运行的 Coding Agent。它是一套可部署到自有 Cloudflare 账户的 AI productivity environment：用户在一个公司工作区中与 Agent 对话、生成或修改小型应用，并在最小授权下把这些应用连接到 GitHub、Google、Slack 等外部系统。

它的核心主张可以压缩为三件事：

Agent chat：让 Agent 在公司知识与连接的系统上下文中完成任务。
Gadgets：每个用户运行自己的小型应用实例；用户可以让 Agent 生成、测试和改写该应用，再安全地分享给协作者。
Gatekeepers：将外部资源包装成带授权、最小资源范围、审计和延迟审批的 capability，而不是把一组全局 MCP 凭据直接交给所有 Agent。

因此，它与 DeepSeek Harness（dsh）不处于同一层：dsh 的重点是可组合的本地 Agent runtime；Cloudflare OS 则把 Agent、用户身份、应用生成、协作、外部服务授权与 Workers 运行环境一起做成完整产品。Cloudflare 官方也明确将当前 v2 标为 Early Access，而非可直接当作稳定企业平台的成品。Cloudflare OS README

1. 产品形态：不是“一个聊天框”，而是 Agent 驱动的应用工作区#

Cloudflare OS 希望部署者把它改造成自己的“Company OS”。对终端用户而言，体验接近在线办公套件：聊天、文档、白板、仪表盘等都是可打开、可协作的工作单元；不同之处在于，这些单元可以是 Agent 按需求即时生成或改写的应用。

层次	用户可见的对象	它解决的问题
Agent	聊天、任务和代码生成	将自然语言目标转成读取、生成、测试和调用能力的步骤。
Gadget	用户自己的文档、白板、看板或定制小应用	让一次性需求不必等待中心化 SaaS 增加功能。
Blueprint	可复制的 Gadget 设计	分享代码和连接需求，让其他人创建独立实例。
Gatekeeper	某个仓库、文档、邮箱或其他外部资源的受控连接	把 OAuth、最小范围、审计和审批集中在资源边界。
Workshop	工作区、身份、协作和运行时协调	连接人、Agent、Gadget 与 Gatekeeper，并实施隔离和访问控制。

这里的 Gadget 不是“所有人共用一套 SaaS 后端中的一条记录”。README 的描述是：用户创建应用时，会得到自己的私有实例；Blueprint 共享的是源代码快照和所需 binding 的形状，而不是原 Gadget 的聊天记录、SQLite 数据或凭据。由 Blueprint 创建的每个实例都拥有独立的 bindings、storage 和 chat history。Blueprints

这项设计的价值在于把“可修改性”和“隔离性”一起放进产品模型：用户可以要求 Agent 给自己的应用新增功能，同时不让这次改动天然触及其他用户的实例或第三方账号。

2. 运行原理：Workers 运行时承载的多租户工作区#

Cloudflare OS 的 README 用操作系统作了一个有用的技术类比：workshop-backend 类似 kernel，Gatekeepers 类似连接外部设备的 drivers，Gadgets 类似 processes，Blueprints 类似 executables。这个类比不能理解为它模拟了 Linux 内核；准确含义是它把运行、状态、访问控制和外部 capability 放进了同一个协调层。架构类比与底层能力

flowchart TD
    user["用户 / 协作者"] --> frontend["Workshop Frontend"]
    frontend --> backend["Workshop Backend"]
    backend --> workspace["Workspace<br/>Durable Object 协调边界"]
    workspace --> agent["Agent chat / Code Mode"]
    workspace --> gadget["Gadget<br/>Dynamic Worker Facet"]
    gadget --> iframe["Sandboxed iframe client"]
    iframe -->|"postMessage + Cap'n Web RPC"| gadget
    workspace --> gatekeeper["Gatekeeper Facet"]
    gatekeeper --> remote["GitHub、Google、Slack 等外部资源"]
    workspace --> state["Durable Object SQLite"]
    workspace --> blueprint["Blueprint metadata / code snapshot"]
    blueprint --> kv["Workers KV"]
    blueprint --> r2["R2"]

上图是根据公开 README 和 Blueprint 文档作的抽象，实际工程还包含路由、前端包与每个服务的独立 Worker。关键的运行边界是：

以 Durable Objects 划定工作区与状态协调边界。 官方说明称每个 workspace 是一个 Durable Object；Gadget 的协作也依赖 Durable Objects。因此，状态和实时协作不是依赖某个永久存活的 Node server，而是围绕对象身份、持久存储和连接重建来设计。有关这一原语的基础可参见 Durable Objects 使用方式与接口整理。
Gadget server 在 Dynamic Worker Facet 中运行。 每个 Gadget 会运行在独立的 Dynamic Worker Facet；Gatekeeper 也会把 Facet 安装进 workspace。这样，运行中的应用和外部连接都可以按 workspace 的 capability 组合，而不是用一个全局、始终拥有全部 binding 的 Worker 处理所有用户。
客户端与服务端通过 Cap’n Web RPC 交互。 Gadget 的 client 与 server 被要求以 Cap’n Web RPC 通信；这让 Agent 能从同一份应用接口获取可调用能力，而不必为每个 Gadget 再手写一套 MCP server。
Blueprint 把“可复制应用”而非“共享线上实例”作为分发单位。 代码快照以 Yjs 文档形式保存，公开查找元数据放在 Workers KV，具体 code content 放在 R2；实例化后会创建自己的状态和 binding。它更像可带版本的应用模板，而不是 SaaS 的 fork 按钮。Blueprint storage architecture

2.1 Agent 如何真正执行工作#

Cloudflare OS 的 Agent 不只产出文字或文件补丁。当前实现基于 pi-agent-core / pi-ai 的 Agent loop：它可以编辑 Gadget 文件，也可以把模型生成的 JavaScript 交给 executeCode 立即运行。这个 Code Mode 代码同样被动态装载为 Worker，globalOutbound 被设为 null，只有当前 chat 已明确授予的 bindings 会进入运行时 env。这解释了为什么项目把“能力授予”放在对话和资源介绍的边界，而不是只靠 Prompt 要求模型自律。Code Mode loader

这里的 pi-agent-core 是一个依赖库，不等同于 Pi Coding Agent 入门与社区玩法所介绍的完整 Pi CLI 产品。以本文锁定的仓库版本为准，Agent loop 还设有 30 turn 的上限，长任务不应假设可以无限循环执行。Agent loop limit

需要把两类网络能力分开看：Gadget 和 Code Mode 动态 Worker 默认没有互联网出口；Agent 内建的 webFetch 则是另一个受控工具，只允许公共 HTTPS、不会携带 cookie 或 Authorization，并限制响应大小。后者不是给生成的 Gadget 代码打开通用网络权限。webFetch boundary

3. Gadget 的两层隔离：Worker server 与浏览器 client#

Cloudflare OS 不把“Agent 写出的应用”默认当成可信代码。当前设计在 server 和 browser 两侧都加了一层边界：

Server：Gadget 运行在一个被禁用互联网访问的 Dynamic Worker 中；它只可通过用户明确指定的 Workers bindings 接触外部资源。
Client：Gadget UI 运行在 sandboxed iframe；iframe 仅通过 parent frame 提供的 postMessage() Cap’n Web RPC session 与自己的 server 通信，并受 iframe sandbox 和 Content-Security-Policy 限制。

这意味着“某段生成代码有网络访问”不是默认能力，而要先被授予特定 connection。它与 Dynamic Workers：Worker Loader、受控 Binding 与安全执行中 Dynamic Workers 的受控 binding 思路一致，但 Cloudflare OS 又在上层补上了用户资源、协作和审批语义。Sandboxed and secure by default

不要把这理解成“任何代码绝对无风险”。隔离的正确性仍取决于 Dynamic Workers、浏览器、Gatekeeper 实现、部署配置及所连接第三方 API；尤其是自行增加的 Gadget、Gatekeeper 或 OAuth 配置必须单独审计。当前源码还把 WebRTC/STUN 未被 CSP / 请求拦截完全覆盖列为 TODO，因此“禁止互联网访问”应理解为已实现的主要 egress 边界，而不是对任意浏览器通道的形式化安全保证。Known implementation caveat

4. Gatekeepers：把外部访问从环境变量变成 capability#

最有辨识度的部分是 Gatekeeper。一般 Agent 产品常在启动时预配置 MCP server，使 Agent 在每次对话中都能看见一组广泛的服务能力。Cloudflare OS 采用另一条路径：用户把某个具体资源“介绍”给某个 Agent 或 Gadget 后，才创建相应 Gatekeeper 并授予可用 capability。

一个 Gatekeeper 的职责包括：

将外部服务的原生 API 包装为 Cap’n Web API；
处理 OAuth 或其他授权；
限制到用户明确选择的具体资源，而非整个账号的环境权限；
记录 Agent 或 Gadget 的动作；
对有副作用的动作提供 human-in-the-loop 审批。

其 human-in-the-loop 设计也不同于“每一步停下来等待确认”。当 Gatekeeper 支持模拟时，它可以先给 Agent 返回本地模拟结果，让 Agent 继续规划并积累操作；用户稍后再批量或逐项批准、拒绝。这是为了避免用户离开后 Agent 因第一项确认而完全停滞，但它也意味着模拟读回不能当作已提交事实。模拟并非强制能力：没有实现模拟的 Gatekeeper 会进入 awaitDecision，Agent 仍会等待人工决定后再继续。Gatekeepers Gatekeeper session semantics

协作权限同样在应用层完成：build 协作者可以编辑代码、使用 AI chat 和管理 bindings，use 协作者只能渲染和使用 Gadget UI。项目通过在打开时计算权限图并返回不同的 capability interface 来实现 default-deny；撤销后会让相关 Durable Object restart，使已打开的 session 重新评估权限。Sharing

5. 在 Cloudflare Workers 部署到自有账户#

前文只说明了“可部署到自己的 Cloudflare account”，这还不足以构成可上线的方案。Cloudflare OS 主仓库的本地入口和 Workers 云端部署是两回事：pnpm run-local 用于试用，官方明确不把它作为生产路径；当前独立 workerd server 的部署说明仍是 “Coming soon”。Cloudflare OS Quick Start

5.1 两条官方路径#

路径	适用场景	关键边界
hosted deploy flow	希望在自有 Cloudflare account 中快速获得实例，主要调整品牌、登录和管理员	官方托管流程不需要本地构建；如只做基础定制，这是最低运维面的入口。
Cloudflare OS starter	需要自定义域名、Cloudflare Access、复用既有 KV/R2、增加 Gatekeeper、保留日志与明确控制升级	starter 在本地生成生产 Wrangler 配置并部署一组 Worker，适合把部署配置纳入自己的版本控制与发布流程。

不要在 Cloudflare OS 主仓库根目录把裸 wrangler deploy 当成完整生产方案：官方的生产入口是上面的 deploy flow 或 starter。以下拓扑与命令针对 starter 的固定快照 3d211477，不是对任意 Cloudflare OS commit 的无条件承诺。

5.2 starter 的六个 Worker 拓扑#

starter 默认部署 六个 Worker。Router 是唯一的公共入口；其余 Worker 不配公网 route，只通过 Service Bindings 被 Router 或 Workshop 调用。这样，身份验证和对外 HTTP 入口不会分散到每个后端组件。starter architecture

flowchart TD
    user["用户"] --> access["Cloudflare Access"]
    access --> router["Router Worker<br/>唯一公开 route；提供前端"]
    router -->|Service Bindings| backend["Private backend plane<br/>Workshop、Context、Scheduler、custom Gatekeeper、Error Reporter<br/>Durable Objects · KV · R2 · Loader · Browser · AI"]

在此拓扑中，Workshop 仍是 Gadget 与状态的核心：它需要 Durable Objects、BLUEPRINTS / AVATARS KV、BLUEPRINT_CONTENT R2、Dynamic Worker Loader、Browser binding 和模型相关 binding。上游 workshop-backend 的 Wrangler 配置也能看到对应的 DO migration、KV、R2、LOADER 和 BROWSER 声明；它们不是可有可无的外围服务。starter generated bindings upstream Workshop config

这里有一个容易遗漏的点：starter 的六个 Worker 不等于已经覆盖 GitHub、Google、Slack 等所有 OAuth Gatekeeper。要加入这类 Gatekeeper，通常还要为它同时配置 Router 的 HTTP Service Binding、Workshop 的 GatekeeperVendor RPC binding，以及该 Gatekeeper 自己的 BASE_URL、CLIENT_ID / CLIENT_SECRET secret；不是“多发布一个 Worker”就够了。Gatekeeper binding manifest

5.3 以 starter 为基线的部署顺序#

以下是 starter README 派生的命令流程，本文未实际执行部署。在其锁定快照中，前置条件是 Node.js >=24.19、pnpm 11.17，以及已开通所需的 Workers、KV、R2、Browser Rendering、Dynamic Worker Loaders；默认模型目录还会使用 Workers AI 与 AI Gateway。starter deployment prerequisites

# 位于 cloudflare-os-starter checkout
git submodule update --init
pnpm install
pnpm --dir cloudflare-os install
pnpm exec wrangler login

# 编辑 deployment.jsonc 后，先预检再部署
pnpm check
pnpm deploy

deployment.jsonc 应保存可公开审阅的部署数据，而非密码。至少要确定 account ID、六个稳定且唯一的 Worker 名、Router 的 Custom Domain 或 workers.dev 路由、publicBaseUrl、Cloudflare Access 的 issuer / audience / 管理员列表、AI Gateway、KV/R2 复用或自动创建设置，以及 observability。默认值为 null 时，Wrangler 可以自动 provision 所需 KV namespace 和 R2 bucket；接管已有数据时则应填入已有资源标识。starter configuration

第三方 OAuth 凭据、跨 account AI Gateway token 等敏感值应使用对应 Worker 的 secret，不应写入 deployment.jsonc、Gadget 或 Blueprint。Cloudflare 提供 wrangler secret put 管理 Worker secret；同 account 的默认 Workers AI / AI Gateway binding 不需要把 API token 写进项目。Workers secrets starter AI configuration

pnpm check 不只是类型检查：starter 会生成临时生产 Wrangler 配置、构建，并进行 deploy dry run。真实发布依赖顺序是 Error Reporter（启用时）→ Context → Scheduler → custom Gatekeeper → Workshop → Router；Router 最后发布，因为它绑定前面的私有 Worker。生成文件会在结束时清理。deployment sequence

5.4 上线前后必须核验的边界#

先确认只有 Router 可公开访问。 Custom Domain / workers.dev route 只属于 Router；starter 同时关闭所有 Worker 的 preview URL，避免形成绕过 Router 与 Access 的另一条入口。发布后应从外部验证 Access 是否先于应用生效。route and preview URL configuration
把 Worker 名和状态资源当成持久身份。 Workshop 的 Durable Object 数据按 Worker script identity 划分；把既有 Workshop 改成新 Worker 名会得到新的、看似空白的 DO namespace。迁移已有实例还必须复用相应 KV/R2 标识，并保持 publicBaseUrl / Context sharing boundary 一致，否则 Context 数据和 OAuth redirect 可能落到另一套边界。migrating from hosted deploy
用低敏感度资源做端到端演练。 验证管理员身份、Gatekeeper 的最小 scope 与撤销、Context / Scheduler、AI、Error Reporter 和日志；确认私有 Worker 没有独立公网地址，再把团队数据接入。
锁定并审查上游版本。 本文的 Cloudflare OS 源码基线是 b1d8750，但 starter 3d211477 的 submodule 实际锁定 6478a144；后者并不自动等同于本文前面分析的主仓库源码。升级时应记录 gitlink、审查 Wrangler 基础配置与 Gatekeeper contract，并重新执行检查、部署与验证，而不是无审查地跟随 upstream。version comparison starter upgrade guidance

本地试用仍然有价值，但不能取代以上核验：

# 前提：已安装 pnpm，并在 Cloudflare OS 仓库根目录
pnpm run-local

它会在 http://localhost:8787 启动本地栈，数据写入 .wrangler。wrangler dev 为了本地服务会允许 localhost，因此与生产中 global_fetch_strictly_public 的 SSRF / 私网 egress 边界不等价。local runtime boundary

6. 已部署后如何用好：适用场景、工作法与边界#

本节是依据前述公开架构给部署者的实践建议，不是 Cloudflare 给出的官方行业方案或安全保证。尤其在 v2 仍为 Early Access 的阶段，应把每次接入外部数据和写操作当作独立的风险决策。

6.1 先把产品定位对#

最合适的定位是：受控的内部 AI 工作区，加上一座为个人或小团队制作专属小工具的工厂。它的价值不在于替代所有聊天产品，也不在于一开始就承接无人值守自动化；而在于把下面这条链路放在同一个权限模型中：

一次性任务 → 可反复使用的 Gadget → 可分发的 Blueprint → 在必要时才连接一个受控的外部资源。

建议按“持续主题或敏感边界”划分 Workspace，例如一个仓库、一个客户项目或一个内部流程各用一个 Workspace，而不是把所有工作混在同一个长期对话中。每个 Workspace 对应独立的 Durable Object，且拥有自己的 conversation、Gatekeeper 与 outputs；这种划分能让后续的撤权、审计和归档更清楚。Cloudflare OS README

优先级	适合从这里开始	首个可交付物	为什么适合
1	个人或小团队的低敏生产力工具	发布前检查表、会议/周报模板、项目风险看板、工时或预算计算器	不接外部资源也能验证 Gadget 的生成、交互和迭代体验。
2	重复出现的团队小流程	可复用的需求收集页、只读质量检查面板、交付物模板	稳定后可发布为 Blueprint；使用者得到独立实例，而不是共享原始数据和聊天记录。
3	有明确负责人、可复核的外部数据分析	单个仓库的 issue/PR 状态摘要、单个项目的变更报告、文档检索后的草稿	Gatekeeper 能把资源范围和操作权限收窄到具体对象；先只读，人工确认后再放开有限写入。
4	低风险、可幂等的定时任务	每日晨报草稿、周期巡检、待办汇总	仅在部署中实际启用 Scheduler 后使用；任务应允许重试或重复投递，且不把“触发成功”当成外部写入已经完成。

如果 Gatekeepers 中出现了 Context，可将少量高质量的项目说明、术语表和 Runbook 放进去，作为 Agent 的只读知识源；当前上游主站的 Context 页面仍有预览性质，因此应以自己的部署中是否实际可启用为准，而不要先围绕它设计关键流程。Context Gatekeeper implementation Context UI route

6.2 一个稳妥的采用阶梯#

flowchart TD
    scope["明确一个低敏任务"] --> private["无外部连接的私有 Gadget"]
    private --> verify["人工验收输出和边界"]
    verify --> blueprint["重复使用后做成 Blueprint"]
    blueprint --> readonly["接入单一只读资源"]
    readonly --> approval["小范围写入 + 人工审批"]
    approval --> review["定期复核与撤权"]

这不是必须逐项走完的产品流程，而是很适合首次部署的风险递增顺序。

先写清任务契约。 为第一个 Workspace 定义输入、输出、禁止动作和验收标准。例如“输入文章标题、链接和发布平台；输出可勾选检查项与风险提示；不保存 token、不连接服务、不执行写操作”。这样可以把 Agent 的成功标准从“看起来回答得不错”变成可验证的交付物。
先做无连接 Gadget。 让 Agent 用示例数据生成一个小界面，然后亲自测试异常输入、移动端布局和结果是否可复现。一次性的总结或提纲不必强行做成 Gadget；只有重复三次以上、需要交互界面或持续状态的工作，再把它产品化。
稳定后再沉淀成 Blueprint。 Blueprint 会复制代码、binding 需求和元数据，但不复制聊天历史、SQLite 数据、凭据或已连接资源。因此它适合把验证过的工作法交给团队，而不是把原 Workspace 当作共享模板。Blueprints
外部连接一次只引入一个窄资源，并从只读开始。 例如只连接一个测试仓库、一个项目目录或一份资料，而非整个组织、邮箱或云盘。要求 Agent 在执行前复述“能访问什么、不能做什么、会不会产生副作用”；得到输出后再核对目标系统中的真实状态。
将写操作当作单独的发布环节。 首次写入应落在低风险目标（如测试仓库的一条草稿评论），并要求人工批准。支持模拟的 Gatekeeper 可以让 Agent 继续规划，但模拟结果不是外部系统已经变更的证据；批准后仍应独立验证。Gatekeeper session semantics
再考虑协作和定时。 希望同事只使用成品时授予 use；只有需要修改代码、使用 AI 或管理 binding 的可信共同维护者才授予 build。Scheduler 只用于可幂等、低风险的草稿和巡检；上游实现默认新任务未启用，漏掉的执行不会补跑，回调也可能被重复投递。Sharing Scheduler semantics

下面这个提示词适合作为第一天的起点：

创建一个“发布前检查表”Gadget：输入为文章标题、链接、发布平台；
输出为可勾选的检查项和风险提示。先只使用示例数据，不连接外部服务，
不保存任何 token，也不要执行写操作。完成后列出：功能、测试用例、
已知限制，以及把它制成团队 Blueprint 前应人工检查的事项。

接入资源时，改用更明确的约束，而不是仅说“帮我看看这个仓库”：

只使用我在本 Workspace 中附加的这个 GitHub 仓库，先进行只读巡检：
总结最近变更、失败测试、风险文件和建议行动。开始前复述你能访问的
具体资源与不能做的操作。不要创建或关闭 issue、评论、push 或修改设置；
请列出数据时间点与无法确认的部分，等待我确认下一步。

6.3 运行和治理的最小清单#

范围	建议	可验证方式
入口	只让 Router 成为公开入口，并让 Cloudflare Access 位于应用之前；管理权限名单应小于普通可进入应用的用户范围。	使用无权限账号或无痕窗口测试访问路径，并确认没有 `workers.dev` 或 preview URL 绕过入口。对于 starter，参见前文的 Router / 私有 Worker 拓扑。
Gatekeeper	每个连接登记负责人、用途、允许资源、允许动作和复核日期；默认单资源、只读、最小 OAuth scope。	在目标服务侧复核 OAuth scope，并撤销一次授权验证 revoke 是否真的生效。
共享	默认给 `use`；`build` 只给能共同维护代码和连接的人员。	用两个测试账号验证二者实际看到的 UI、AI 和 binding 管理权限。
Blueprint	不把链接、标题、描述、代码或 binding 说明当作机密边界。上游可通过持有链接查询 Blueprint metadata；外层 Access 是否遮挡该路径则取决于自己的部署，须实测。	用无权限会话测试分享链接；代码和元数据中不出现 token、客户详情、内部 URL 或真实资源标识。
模型与成本	用一组脱敏的固定任务比较正确率、返工次数、耗时和成本，再确定默认模型与更强模型的回退条件。	若启用了 AI Gateway，使用其请求分析、缓存和 rate limiting 观察真实流量；日志中不要保留完整 prompt、文档、token 或 cookie。
升级	对 starter 和上游 gitlink 锁版本；新增 Gatekeeper、OAuth scope 或自动写入前重新审查。	在测试 Workspace 用低敏样本执行 `pnpm check`、部署演练和端到端回归，再升级生产实例。

Cloudflare Access 的保护不能只凭部署配置推断。Cloudflare 的自托管应用文档明确建议关闭能绕过 Access 的 workers.dev 与 preview URL；应把无权限访问测试纳入每次变更后的验收。Protect self-hosted applications

6.4 不宜一开始就交给 Cloudflare OS 的工作#

目标	为什么不宜直接采用	更稳妥的处理
面向公众的多租户 SaaS 或系统记录库	Cloudflare OS 的核心是受控 Workspace 与 Gadget 实例，不是现成的客户隔离、计费、SLA 与数据主系统。	让它做内部运营台或原型；业务数据仍以专门的产品后端为准。
无人值守的生产变更、资金操作、批量发信或权限管理	Agent 可能达到 turn 上限，Scheduler 不保证精确一次，模拟也不等于真实提交。	采用显式审批、幂等设计、审计和独立的业务工作流；先在测试目标演练。
高敏、受监管或全量企业账户数据	这需要额外完成数据分类、保留策略、访问审计、第三方 OAuth 审核和事故响应，而 Early Access 不应代替这些控制。	先只接公开或低敏样本，并由安全/合规负责人决定是否扩大范围。
重计算、长时间任务或完整 IDE 替代	Dynamic Worker 和 Agent loop 有明确运行边界，当前 Agent loop 还有 30 turn 上限。	将重任务交给适合的 Container、Workflow 或本地开发环境；Cloudflare OS 保留为界面、协作与受控调度层。

只需要让 Agent 在一个本地代码库里执行工具时，DeepSeek Harness（dsh）、Pi 等本地 harness 通常更轻；只需要持久 Agent workspace 而不需要完整办公产品时，Cloudflare Computer 技术解析：持久 Workspace、执行后端与 Agent 集成更接近底层能力。

Cloudflare OS 最值得利用的部分不是把一切称为“OS”，而是同时保留 Gadget 的实例边界、Gatekeeper 的资源 capability 边界，以及 Durable Object 的状态协调边界。把它用作“小步试验、验证、复制、再逐步授权”的工作台，通常比把它直接变成全权限自动化中枢更能发挥这套设计的价值。