Cloudflare OS 托管代理工作区从开源项目转向候补名单服务
Cloudflare 在将底层平台开源仅一个月后，便为其首个全面托管的 Cloudflare OS 代理工作区开放了候补名单。这一变化将 Cloudflare OS 从需要企业自行运营的项目，转变为 Cloudflare 计划代为管理的服务。
这听起来像是常规的托管版本，但 Cloudflare 的目标是扮演更大的角色。它希望为每位员工提供一个持久化工作区，能够理解公司流程，并可在获批系统中执行操作。该工作区可以研究信息、创建文档、修改代码，并将重复性任务转化为应用程序。
这给已经销售企业代理平台的 Microsoft、Google 及其他云服务商带来了压力。这些厂商的产品受益于其在办公套件和云账户中的深度布局。Cloudflare 则押注于，身份管理、网络控制、模型路由和隔离执行能够成为工作场所代理同等重要的基础。
Cloudflare OS 托管代理工作区进入候补名单阶段
Cloudflare 并未宣布全面上市。它正在测试企业是否希望使用开源平台，同时免除运营负担。
Cloudflare 于 2026 年 10 月 1 日宣布了这一托管选项。组织可以加入候补名单，但该公司尚未提供上线日期、服务级别承诺、区域可用性列表或商业条款。
这一差别很重要，因为开源版本已经可用。企业可以将其部署到自己的 Cloudflare 账户中，自定义其界面，并连接内部资源。同时，它们也必须自行配置、运营、更新和保护该部署。
Cloudflare 现在提出了不同的责任划分。客户将选择获授权用户、公司上下文、组织技能、已连接系统、自定义域名及相关访问策略。Cloudflare 将处理其余的部署和运营工作。
根据这份托管服务公告，组织还将选择其部署所使用的 AI Gateway。AI Gateway 位于工作区与模型提供商之间，可在此应用路由、日志记录和策略控制。
Cloudflare 表示，在开源发布后的一个月内，已有数千家组织开始使用 Cloudflare OS。该数字来自 Cloudflare，尚未获得独立验证。公司没有披露其中有多少部署处于活跃、试验状态，或已在整个组织内投入使用。
不过，候补名单反映了开源发布带来的一项具体经验：发布代码可以消除许可和定制化障碍，却不能消除部署工作。企业仍需建立身份规则、连接系统、保护凭据、测试升级并调查故障。
托管服务是 Cloudflare 对这一采用缺口的回应。它为企业提供定制能力，而无需每个客户围绕该平台建立专门的运营流程。
这一时机也揭示了 Cloudflare 的目标市场。Cloudflare OS 并不只是被定位为面向软件团队的代理开发工具包。公司将其描述为面向销售、财务、支持、运营和工程等各部门员工的工作区。
一次客户会议说明了其覆盖范围。员工可以要求代理审查客户记录、检查支持工单、分析产品使用情况，并准备一份演示文稿。这项任务跨越多个系统，产出的是可编辑的工作成果，而非简短的聊天回复。
Cloudflare 也在平台上线后的首月进行了更新。用户现在可以连接 GitHub 仓库，并要求代理检查代码、编辑文件、创建提交或发起拉取请求。这些功能将软件开发带入了一个最初围绕更广泛知识工作推出的产品。
Google Workspace 集成也有所扩展。Cloudflare 表示，代理可以研究 Gmail 邮件线程、创建草稿、发送消息，并使用已连接的 Drive 资源。管理员可以开放整个 Drive、某个文件夹或单个文档。
该工作区可以将文档和数据导出为 Excel 文件、CSV、PDF、Markdown 或 HTML。Word 和 PowerPoint 导出功能已在规划中，但在 Cloudflare 发布该公告时尚不可用。
这些新增能力扩大了产品可覆盖的工作范围，也扩大了其风险面。能够阅读电子邮件、访问文件、修改代码和发送消息的代理，需要比仅起草文本的聊天机器人更严格的控制。
这种张力直接引出了 Cloudflare 的核心卖点。该公司销售的是托管运营服务，但其更大的主张是对企业数据实施治理化访问。
真正的产品是治理化执行层
Cloudflare OS 将面向员工的工作区与控制代理可查看、运行、保留和共享内容的基础设施结合在一起。
一个工作区保存对话、文件、输出、权限、任务和计划事件。与普通聊天会话不同，用户关闭浏览器后，它仍能保留状态。这种持久性支持跨多个会话持续推进的项目。
Cloudflare 的参考架构将 Workers 和 Agents SDK 置于编排层。Durable Objects 负责维护状态，而 Dynamic Workers 和沙箱容器则执行需要代码的任务。
AI Gateway 控制对获批准模型的访问。Model Context Protocol 门户将工作区连接至企业工具。MCP 是一种标准接口，代理可借此发现可用工具并调用其操作。
该架构将模型与凭据及策略执行分离开来。这种分离十分重要，因为语言模型不应在每次需要公司数据时都获得权限过宽的 API 密钥。
Cloudflare 在 Cloudflare OS 与外部系统之间使用名为 Gatekeepers 的服务。每个 Gatekeeper 都了解目标服务、可用资源、允许的操作以及相关组织策略。
一个 GitHub Gatekeeper 可以仅开放一个仓库，而不暴露整个账户。它可以允许访问议题，同时不提供源代码。它还可以要求在代理合并拉取请求前获得人工批准。
代理看到的是受限的编程接口，而不是底层凭据。Cloudflare 表示，凭据始终与生成代码隔离。除非管理员提供已批准的能力，服务器端代码也会在禁用出站网络访问的情况下运行。
该模型从默认无访问权限开始。代理或生成的应用程序必须获得其所使用每项资源的许可。这一结构遵循最小权限原则，即将身份访问范围限制在完成指定任务所需的资源内。
Cloudflare 还会跟踪代理观察到的资源。如果代理读取受限数据集并创建仪表板，该仪表板将保留与该来源的关联。
当另一名员工打开该输出时，Gatekeepers 可以检查该员工是否有权访问已被观察到的资源。其目标是防止生成的输出绕过原始数据附带的权限。
这一问题已成为企业代理的核心议题。传统授权机制回答的是用户是否可以打开文件或查询应用程序。代理型系统则能够组合来自多个资源的信息，并生成新的工件。
新工件可能包含敏感事实，却不再保留原始系统的访问控制。摘要、图表、应用程序或电子邮件草稿，都可能成为绕过数据边界的间接路径。
Cloudflare 的方法将信息溯源视为授权的一部分。平台试图记住代理看过什么，并在判断谁可以访问其工作成果时使用这段历史。
这不只是一个连接器框架，而是试图在代理转换数据后继续对其进行治理。
开源发布文章解释了 Cloudflare 为何围绕这一需求重构平台。其首个内部版本支持私有工作区，但协作暴露了共享应用程序和输出方面的风险。
Cloudflare 得出结论：对 MCP 工具的访问权限，并不能揭示通过该工具观察到的所有底层资源。因此，它增加了在工作区界面之下运行的控制机制。
该设计还将确定性工作与模型推理分离。代理可以将重复流程转化为代码，仅在需要判断时才使用模型。
以支持仪表板为例。软件可以检索工单数量、分组记录并渲染图表，而无需要求模型反复执行这些步骤。模型仍可用于分类异常案例或起草建议回复。
这种分离可以减少不必要的推理，并创建更可预测的工作流。它还使输出更易于检查，因为标准代码负责处理可重复的操作。
Cloudflare 表示，其自身团队已将这一模式用于内部工单报告。代理创建了一个连接工单数据的应用程序，而员工仍保留对起草回复的审核权。
这仍是公司自行报告的案例，而非独立性能研究。不过，它说明了该平台预期的发展路径：对话、可复用工作流和持久化应用程序。
该公司的源代码仓库也明确标有早期访问警告。它将第二版描述为一次完整重写，并指出仍存在一些粗糙之处。这一警告应影响对托管服务的任何评估。
托管部署可以简化运营，但无法自动让尚未成熟的软件适用于关键工作流。买方必须区分基础设施管理与应用成熟度。
Microsoft 和 Google 掌控应用，Cloudflare 则瞄准控制平面
Cloudflare 面临的首要挑战并非再打造一个代理，而是如何超越那些已经控制员工工作场所的竞争对手。
Microsoft 可以将代理置于 Microsoft 365、Teams、SharePoint、Dynamics 和 Power Platform 之中。Google 则可以将代理连接至 Workspace、Cloud、Drive、Gmail 和组织搜索。
这些布局降低了采用摩擦。员工可以在熟悉的应用程序中接触代理，而管理员可以复用现有的身份、合规和数据控制措施。
Microsoft 的企业代理计划涵盖低代码工具、托管运行时、连接器和开发者服务。Copilot Studio 支持业务团队，而 Microsoft Foundry 则面向构建更高度定制系统的开发者。
Google 采取了类似的平台战略。其企业产品结合了员工界面、模型访问、搜索、连接器、代理创建和集中式管理。
Cloudflare 并不拥有大型生产力套件。它无法假设员工已经在 Cloudflare 的文档编辑器、收件箱、电子表格或协作应用程序中度过一天。
相反，Cloudflare 正将 Cloudflare OS 定位于这些系统之上。该工作空间连接现有工具，而 Cloudflare 提供执行、网络、身份强制与模型治理能力。
这是一种控制平面策略。控制平面负责制定策略并协调资源，而连接的应用仍是记录系统。
这种方式可能为混合环境带来优势。许多组织同时使用 Microsoft 应用、Google 服务、GitHub、Salesforce、内部数据库和多家模型提供商。理论上，一个中立的工作空间可以跨越这些边界。
Cloudflare OS 还允许客户选择通过 AI Gateway 访问的模型。该设计避免将工作空间界面绑定到某一个模型系列，但可用集成及托管服务条款仍不明确。
这一架构与 Cloudflare 在企业网络和应用安全领域的既有定位相契合。客户可能已经使用 Cloudflare Access 实现具备身份感知能力的应用入口，或通过 AI Gateway 控制模型流量。
对这些组织而言，Cloudflare OS 可以将既有策略层扩展至员工 Agent。当客户已经配置好周边服务时，其销售论点会更有说服力。
不过，中立性也有代价。Microsoft 和 Google 可以在各自套件内部提供更深入的原生行为。Cloudflare 必须通过 Gatekeepers 和外部 API 重现或协调这些操作。
每项集成都增加维护工作。API 行为会变化，认证流程会演进，企业权限也因租户而异。若想让托管产品体现出统一工作空间的体验，Cloudflare 必须保持这些连接的可靠性。
该平台还必须与云服务商提供的托管 Agent 基础设施竞争。Amazon 的 AgentCore runtime 为已部署的 Agent 管理扩缩容、会话处理、基础设施与隔离。
AgentCore 更直接聚焦于运行 Agent 应用，而 Cloudflare OS 则包含员工界面以及用于生成持久化工作成果的工具。即便用户体验不同，两类产品仍在托管执行层面存在重叠。
这种竞争表明，市场正在分化为多个层级。模型提供商提供推理系统，云平台运行 Agent，生产力套件提供用户界面，集成服务连接企业工具。
Cloudflare 正试图将多个层级打包在一起，同时并不拥有其底层应用。它的差异化取决于：治理和跨系统执行能力，是否胜过套件原生 Agent 的便利性。
这使采购背景成为决定性因素。标准化使用 Microsoft 365 的公司，可能更倾向于现有的管理环境。系统异构的组织，则可能更看重模型中立、应用中立的工作空间。
开发者面临类似选择：他们可以为单项工作构建独立 Agent，也可以向员工提供一个共享工作空间，使其能随着需求出现而创建工具。
工作空间模式能够减少碎片化。员工保留一份 Agent 历史、一套获批准的能力，以及一个组织技能库。团队可以共享流程，而无需为每项任务重复编写提示词。
但它也可能集中风险。一个连接众多系统的工作空间会成为重要的安全边界。配置错误或集成缺陷可能影响多个工作流，而非单一狭窄的 Agent。
这项权衡解释了托管版本为何重要。Cloudflare 要求客户信任其运营一个横跨敏感系统的工作空间，而不仅是托管一个网页界面。
托管运营无法解决信任问题
候补名单减少了部分部署工作，但 Cloudflare 尚未提供足够证据来解决安全性、可靠性和采用方面的问题。
首个不确定性涉及产品成熟度。Cloudflare OS 仍是处于早期访问阶段的开源软件，托管服务尚未公布可用日期。
候补名单可以在 Cloudflare 投入容量和支持资源前衡量市场兴趣。但这也意味着买家尚无法评估最终合同、服务边界或运营模式。
Cloudflare 尚未公布托管服务的详细信息，涵盖数据驻留、备份政策、事件响应、升级计划、恢复目标或支持的集成。这些细节将比安装便利性更重要。
第二个不确定性涉及授权准确性。追踪已观察到的资源是应对数据泄露的一种周全做法，但真实的企业权限十分复杂。
访问规则可能取决于角色、地点、项目、设备状态、记录字段、法律保全要求或临时例外。Gatekeeper 必须在读取和共享时都能正确解释这些约束。
生成的应用又增加了一层复杂性。应用可能保存数据、转换字段、缓存结果，并接收多名用户的输入。策略强制必须贯穿所有这些转换过程。
Cloudflare 表示 Gatekeepers 会记录观察结果，并在工作成果共享时检查访问权限。独立测试尚未证实该模型如何处理所有转换、撤销或间接推断情形。
权限撤销尤其值得关注。若员工在 Agent 生成输出后失去对源数据的访问权限，系统必须决定该员工能否保留派生材料。
管理员还需要易于理解的审计记录。如果调查人员无法判断哪些记录影响了输出，仅显示 Agent 调用了某个工具的日志并不足够。
第三个不确定性涉及生成的代码。Cloudflare OS 允许 Agent 在隔离环境内编写和运行软件。隔离可以降低暴露风险，但生成的代码仍可能包含逻辑错误。
一个工作流可能选错记录、错误应用筛选条件、发送不完整报告，或执行非预期操作。这些故障即使没有逃离沙箱也可能发生。
审批控制可以限制有害的副作用。但若每一项重要操作都需要人工确认，也可能持续增加审核负担。
组织需要针对不同任务设定不同的自主级别。读取已批准文档的风险低于发送电子邮件、修改源代码或更新客户记录。
第四个不确定性涉及集成深度。Cloudflare 强调 GitHub 和 Google Workspace，但大多数公司依赖许多其他系统。只有当连接器匹配实际工作时，托管工作空间才会有用。
连接系统还不够。集成必须理解细粒度权限、维持稳定认证、处理故障，并以 Agent 能够安全使用的形式提供操作。
第五个不确定性涉及采用。为每位员工配备 Agent，并不保证员工会围绕它重新设计工作方式。
员工需要可信的组织技能、清晰示例、审核实践和支持。团队还需要就哪些输出必须验证达成共识。
Cloudflare 表示，数千名员工正在使用内部平台，团队已创建数千个工具。这些数字体现了内部活动，但仍是来自其自身环境的公司估算。
Cloudflare 员工还能以不同寻常的方式接触产品构建者。外部客户可能面临不同的上手、支持、合规和变更管理条件。
托管部署可以减少基础设施工作，但无法整理公司知识、解决不清晰的流程，也无法决定哪些工作流值得自动化。
组织应将这项准备视为知识管理项目。可靠的团队知识库需要明确所有权、访问规则、最新材料以及纠正过时指导的流程。
Cloudflare OS 依赖经过整理的上下文和可复用技能。若这些输入相互冲突或变得过时，Agent 可能会更高效地执行错误流程。
因此，托管服务必须证明两件事：Cloudflare 必须可靠地运营技术平台，而客户必须维护为 Agent 提供有用指令的组织层。
这两项责任都不会因几次部署点击而消失。
三个信号将显示 Cloudflare OS 能否成为企业基础设施
下一阶段取决于服务细节、生产环境证据，以及 Cloudflare 的治理模型能在自身组织之外奏效的证明。
第一个信号是明确的托管服务发布。Cloudflare 需要公布可用性、支持地区、集成覆盖范围、管理控制和责任边界。
没有这些细节的发布会削弱其基础设施论点。具备文档说明的运营模式则会增强这一论点，尤其对于评估长期使用的安全和合规团队而言。
买家应寻找关于数据位置、模型路由、日志、备份、事件处理、升级和租户隔离的明确答案。他们还应审视托管部署与客户自行运营安装之间的差异。
第二个信号是独立的生产环境采用。Cloudflare 关于数千家组织的表述描述了早期兴趣，但并未揭示持续使用情况。
更有力的证据包括具名客户、明确工作流、部署规模、管理员反馈和可量化的错误率。案例研究应说明组织如何处理权限和人工审核。
使用深度比候补名单规模更重要。一个创建示例演示文稿的试点，与一个连接运营系统的工作空间，其意义截然不同。
Cloudflare 还应区分活跃用户与注册用户。平台价值取决于重复性工作、可复用应用和共享的组织技能。
第三个信号是 Microsoft、Google 和 Amazon 如何回应工作空间模式。它们的产品已经覆盖许多周边能力，而且各方都可以通过更紧密的集成弥补差距。
若主要平台增加更强的跨系统来源追溯能力和可移植的组织技能，Cloudflare 的治理差异化将会缩小。若它们仍以自身套件为中心，Cloudflare 的中立定位就会更有价值。
Cloudflare 还需要证明其开源版本和托管版本能够同步演进。开源代码会吸引定制和审查，而托管服务则会带来稳定性压力。
如果客户可以检查平台、控制集成，并在不同运营模式之间迁移，这种组合就能成为优势。如果版本变化过快，以至于企业无法验证，则会成为负担。
因此，Cloudflare OS 托管 Agent 工作空间不仅是一项托管公告。它检验的是企业是否希望拥有一个受治理的环境，让员工能够在既有系统之间开展研究、创作、编程和自动化。
Cloudflare 已展示了该环境可信的架构。它尚未展示完成的托管产品，也未提供证明该模式可跨多样化企业运行的独立证据。
考虑加入候补名单的组织应从狭窄且可逆的工作流开始。它们应明确所需数据、允许操作、人工审批节点，以及组织技能的所有权。
最有价值的问题并不是是否应让每位员工都获得一个 Agent，而是一个受治理的工作空间能否安全地替代不断增加、彼此脱节的 Agent 实验集合。
Cloudflare 现在必须证明，托管运营、细粒度访问和持久化工作成果能够在生产环境中回答这个问题。
