🔶 Cloudflare OS：面向 Agent、应用与工作的开放平台

每个组织都有自己的使命，也就是其存在的理由。组织会将这一使命——连同其术语、流程、系统、标准和工作方式——传递给员工。员工则结合这些背景以及自身经验，为实现组织使命而工作。

工作可以有多种形式：代码、文档和幻灯片、人际关系，以及现实世界中的成果。

其中一些形式相对直接：代码要么能运行，要么不能运行。过去几年里，Agent 一直利用这种反馈循环，为开发者产出能够“正常工作”的代码。但其他人怎么办？

将同样的生产力杠杆带给组织中的其他成员，是一个更难的问题。Agent 需要理解公司的背景，并能够访问人们完成工作所使用的系统。它们需要将这些背景和访问权限转化为能够推动组织实现使命的工作。

这就是我们创建 Cloudflare OS 的原因。它为每个人提供一个围绕其公司构建的 Agent 和工作空间：了解公司如何运作、掌握哪些知识，以及依赖哪些系统。

今年 5 月，我们向 Cloudflare 的每一位员工开放了 Cloudflare OS 的第一个版本。各职能部门的数千名员工——其中许多人并非工程人员——每天使用它创建文档和幻灯片、自动化可重复任务，以及构建用于数据可视化并辅助工作的轻量应用。

Cloudflare OS 还为所有人提供了由 Cloudflare 各团队构建的共享上下文和技能库。它将我们的术语、流程以及执行重复性工作的最佳已知方式，沉淀为 Agent 可以遵循的指令。当一个人发现更好的做事方法时，其他所有人都可以使用它。

**今天，我们开源了新版 Cloudflare OS。**任何组织都可以部署它、将其连接至内部系统，并将其改造成适合自身的版本。

我们从第一个版本中学到了什么

我们今天开源的 Cloudflare OS，基于我们在内部运行第一个版本时获得的经验。我们的 CIO Sam Rhea 在他的博客文章中介绍了这段历程。

第一个版本以个人通过私有工作空间与 Agent 协作为中心。应用是静态的，而不是连接内部系统的实时软件；并且，大多数确定性任务仍需要再次运行 Agent 技能，从而消耗更多模型 token。

协作暴露了一个更根本的挑战。访问一个MCP server可以告诉我们 Agent 能调用哪些工具，却不能告诉我们 Agent 已观察到哪些底层资源。一旦人们开始共享工作空间、应用和输出，我们就必须确保协作不会暴露某人无权查看的信息。

我们在全新的基础上重建了 Cloudflare OS，以解决这些问题。安全必须成为平台的一部分，而不能是每个构建应用或使用 Agent 的人都必须自行正确实现的事情。

最终得到的是一个旨在归属于运行它的公司的平台。你可以自定义界面、连接工具，并添加能够体现组织运作方式的技能和上下文。

Cloudflare OS 简介

与许多其他 AI 工具一样，Cloudflare OS 从浏览器中的一段对话开始。不同之处在于，每段对话都以组织精心整理的上下文和技能为基础。为工作空间设定一个目标后，它便可以利用这些知识，并使用组织已经在用的工具和数据来实现目标。

Cloudflare OS 由三部分组成：

• 一个 Agent 工作空间：以公司整理的上下文和技能为基础，并提供隔离运行时，供 Agent 编写和运行代码。
• 一套新的安全与治理框架：用于安全访问内部数据和服务。
• 一个用于个人化、可修改应用的平台：用户可以构建、共享并持续修改这些应用。

一段对话可以演变为文档、应用，或持续执行工作的工作流。

面向公司每位成员的 Agent 工作空间

Agent 工作空间旨在供组织中的每个人使用。你可以在浏览器中与其交互，因此无需是开发者，也不必知道如何使用终端。

一个工作空间整合了 Agent 会话、持久状态、输出和文件、资源访问权限，以及可供 Agent 编写和运行代码的隔离运行时。

其中预加载了团队或公司收集整理的上下文和技能。不必再为每项任务重复造轮子——如果团队中的某个人已经摸索出完成某件事的最佳方式，每个人都能从中受益。人们不再需要在每次启动任务时，向模型重复解释同一套流程、术语和最佳实践。

以下是一些可完成的工作：

研究与提问

让工作空间使用公司上下文以及你向其开放的资源来研究某个主题。Agent 可以编写代码以搜索、筛选、联结和分析信息，而不必将整个数据集都拉入模型的上下文窗口。

创建文档、幻灯片和电子表格

工作空间可以将研究成果转化为可继续编辑的文档、演示文稿或电子表格。这些输出不一定是静态文件。它们可以持续连接实时数据，随着来源变化而更新，同时仍可导出为熟悉的格式，或导出至 Google Drive 等服务。

为团队创建协作式、互联的应用

当文档或电子表格无法满足需求时，Agent 可以构建拥有自身界面、逻辑和状态的应用。该应用可以使用已连接的公司资源，并支持多人协同工作。

运行确定性工作流

并非每项工作都需要完整的 Agent 会话。许多工作都是已知的步骤序列，只在一两个环节需要判断。工作空间可以将这些工作转化为以确定性为主的工作流：针对可预测步骤使用代码，只在模型能带来价值的地方使用模型。工作流可以按需运行、按计划运行，或在已连接系统中发生事件时运行。

Cloudflare OS 通过 Gatekeeper 为 Agent 和应用提供受治理的记录系统访问权限（详见下文安全章节）。它还通过 MCP Server Portals 支持组织已在使用的 Model Context Protocol (MCP) server。

用于安全访问内部数据和服务的新安全与治理框架

当人们开始在工作中尝试使用 AI 时，他们最先提出的请求之一通常是获取公司系统的 API key。这很合理：如果 AI 无法访问人们用于完成工作的系统，它在工作中的价值就十分有限。

但向人和 Agent 直接交付 API key 既危险，也无法扩展。密钥通常提供范围广泛、长期有效的访问权限，难以限制、难以安全共享，也难以审计。

MCP 为 Agent 使用这些系统提供了更好的方式。MCP server 可以保管凭据，并暴露一组定义明确的工具，而不是将密钥直接交给 Agent。但控制 Agent 可以调用哪些工具只是第一步。仅靠 MCP 并不能告诉我们 Agent 已观察到哪些底层资源。Agent 可以跨系统组合信息，将其发送至限制较少的地方，或通过应用和输出将其暴露给可能无权查看原始资源的人。授权必须考虑数据接下来可能流向何处。

Agent 默认没有任何访问权限

Cloudflare Access控制谁可以进入 Cloudflare OS。在系统内部，每个 Agent 和应用初始均无任何访问权限。Agent 可以请求访问特定资源，而你可以授予或拒绝该请求。生成的代码会以类型化绑定的形式获得该资源：

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});

env.PROJECT 是一种能力（capability），代表在特定策略下使用特定资源的权限。凭据始终与 Agent 及任何生成的代码完全隔离。

服务器代码在全局出站网络已禁用的 Dynamic Worker 中运行。客户端代码则在浏览器的沙箱化 frame 中运行。除非你明确提供相应能力，否则两者都无法访问互联网。

Gatekeeper 治理资源与操作

Gatekeeper 是一个特定服务的 Worker，位于 Cloudflare OS 与外部服务之间。它了解该服务的 API、资源，以及可在这些资源上执行的操作。

让 Agent 访问整个 GitHub 账户，访问范围很可能过于宽泛。Gatekeeper 可以仅授予它访问一个仓库的权限，允许其读取 issue 但不能读取源代码，对特定字段进行脱敏，施加速率限制，并在合并 pull request 前要求审批。

Agent 及其应用看到的是一个小型 TypeScript API。Gatekeeper 负责处理 OAuth、保管凭据、执行策略、记录已读取的内容，并对任何具有外部可见副作用的操作进行中介处理。

策略会跟随 Agent 已经看到的信息

仅控制初始读取并不足够。例如，假设一个 Agent 读取了数据仓库中的敏感表，并利用其生成一个实时仪表盘。共享该仪表盘不能成为向无权直接访问该表的人共享该表的途径。

Cloudflare OS 会记录 Agent 观察到的每项资源。这些观察记录始终附着于 Agent 及其工作。当其他人尝试打开工作空间、与 Agent 交互，或查看其产出时，Gatekeeper 会验证该人员对已观察资源的访问权限。

同一份观察日志还用于辅助制定策略，以决定 Agent 何时可以发出外部请求。读取敏感数据后，策略可以阻止 Agent 向某些来源写入数据、邀请新的协作者、将工作交给另一个 Agent，或发起出站请求。

使用 Agent 或构建应用的人无需担心会犯下这些错误。该平台现在可以用于处理这些问题。

用于构建和共享个人化、可修改应用的平台

大多数生产力套件提供一组固定应用：文档、电子表格和演示文稿。在 Cloudflare OS 中，每个“文件”都可以成为其自身的应用，由 Agent 为一个人、一个项目或一个团队编写。

这些并非需要导出并部署到其他地方的原型。每个应用都是完整的全栈应用，包含客户端代码、服务器代码、API 和持久状态。应用默认私有，但可以像文档一样共享。

每个应用都是一个 Worker

当你要求工作空间构建应用时，Agent 会编写两部分内容：

• 用于在浏览器中渲染应用 UI 的客户端代码
• 用于存储状态并实现应用行为的服务器代码

服务器会按需加载为一个 Dynamic Worker，并实例化为一个 Durable Object Facet（两者都是我们为该项目构建的功能）。Facet 为应用提供自己的 SQLite 数据库，与管理它的 Cloudflare OS 运行时相互分离。Dynamic Worker 使用轻量级 V8 isolate，因此每个应用都可以拥有独立的隔离运行时，无需常驻专用服务器或容器。

浏览器客户端使用 Cap’n Web 与服务器通信；这是 Cloudflare 开源的、基于对象能力（object-capability）的远程过程调用（RPC）系统。客户端可以像调用普通 JavaScript 函数一样调用服务器方法：

const issues = await app.listIssues({
 status: "done",
});

特殊之处在于，Agent 也可以调用同一个方法。

因此，如果你能构建一个工具来自己完成某项工作，Agent 就能在你不在时使用这个工具完成该工作。

共享应用，或共享其构建方式

在 Cloudflare OS 中构建应用后，你有两种共享方式：

• 共享应用本身，可让其他人使用相同状态进行实时协作。
• 共享应用蓝图，可让其他人创建自己的一份应用副本。

从蓝图实例化的应用包含原始应用的代码，但不包含其 SQLite 数据、对话历史、凭据或已连接资源。每个新应用都以独立的状态和资源开始。

这意味着，当你与团队共享应用时，他们可以借助 AI 自行修改应用，而不必提交功能请求再指派给你。

使用任意模型，并控制其成本

Cloudflare OS 可以搭配任何模型使用。每次推理调用都会经过 Cloudflare AI Gateway，让组织可以在一个位置决定哪些模型可用，以及哪个模型应处理每项工作。

并非每项任务都需要最昂贵的模型。你可能不希望每天早晨用最昂贵的前沿模型来总结未读邮件。AI Gateway 提供了所需的控制能力，确保昂贵模型只被用于最困难的工作。

每个请求都会归属至发起请求的个人、团队或工作空间。管理员可以查看推理支出流向，设置预算和速率限制，并决定达到限制后应如何处理。

开源，s

Every organization has a mission, a reason for being. Organizations pass that mission — along with their terminology, procedures, systems, standards, and ways of working — to their people. People, in turn, take this context together with their own experience and work towards the mission.

Work can take many forms, from code, to documents and slides, to relationships, to outcomes in the physical world.

Some of these are straightforward: code either runs or it doesn’t. Agents have been using this feedback loop to produce code that “works” for developers over the last couple of years. But what about the rest of us?

Bringing the same leverage to the rest of the organization is a harder problem. Agents need to understand the context of the company and be able to reach the systems people use to do their jobs. They need to turn that context and access into work that moves the organization towards its mission.

That’s why we created Cloudflare OS. It gives every person an agent and workspace built around their company: how it works, what it knows, and the systems it relies on.

In May of this year, we gave every person at Cloudflare access to the first version of Cloudflare OS. Thousands of people across every function, many of them outside of engineering, use it every day to create documents and slides, automate repeatable tasks, and build small apps to visualize data and help them do their work.

Cloudflare OS also gave everyone a shared library of context and skills built by teams at Cloudflare. It captures our terminology, procedures, and best-known ways of doing recurring work as instructions an agent can follow. When one person figures out a better way to do something, everyone else can use it.

Today, we are open sourcing a new version of Cloudflare OS. Any organization can deploy it, connect it to internal systems, and make it their own.

What we learned from the first version

The Cloudflare OS we are open sourcing today is based on what we learned from running the first version internally, a journey our CIO, Sam Rhea, covers in his blog post.

The first version centered on individuals working with agents through private workspaces. Apps were static rather than live software connected to internal systems, and mostly deterministic jobs still required running an agent skill again and consuming more model tokens.

Collaboration exposed a more fundamental challenge. Access to an MCP server told us which tools an agent could call, but not which underlying resources the agent had observed. Once people began sharing workspaces, apps, and outputs, we needed to ensure that collaboration could not expose information someone was not permitted to see.

We rebuilt Cloudflare OS on a new foundation to solve these problems. Security had to be part of the platform, not something every person building an app or using an agent has to implement correctly.

The result is a platform designed to belong to the company running it. You can customize the interfaces, connect your tools, and add the skills and context that capture how your organization works.

Introducing Cloudflare OS

Cloudflare OS starts with a conversation in your browser, like many other AI tools. What makes it different is that each conversation is grounded in the context and skills your organization has curated. Give your workspace a goal, and it can draw on that knowledge and work with the tools and data your organization already uses to achieve it.

Cloudflare OS combines three parts:

• An agent workspace grounded in context and skills your company curates, with an isolated runtime where agents can write and run code.
• A new security and governance framework for safe access to internal data and services.
• A platform for personal, modifiable apps that people can build, share, and continue changing.

What begins as a conversation can become a doc, an app, or a workflow that continues doing the work.

An agent workspace for everyone in your company

Agent workspaces were designed for everyone in your organization to use. You interact with them in your browser, so you don’t have to be a developer or know how to use a terminal.Â

A workspace combines agent sessions, persistent state, outputs and files, resource access, and an isolated runtime where the agent can write and run code.

They come loaded with the curated context and skills your team or company has collected. No more reinventing the wheel for every task — if someone on your team has figured out the best way to do something, everyone benefits. People no longer have to explain the same process, terminology, and best practices to a model every time they start a task.

A few things you can do:

Research and ask questions

Ask a workspace to research a topic using company context and the resources you make available to it. The agent can write code to search, filter, join, and analyze information instead of pulling an entire dataset into the model’s context window.

Create docs, slides, and spreadsheets

A workspace can turn its research into a document, presentation, or spreadsheet that you can continue editing. These outputs do not have to be static files. They can remain connected to live data, be updated as their sources change, and still be exported to familiar formats or services such as Google Drive.

Create collaborative, connected apps for your team

When a document or spreadsheet is not enough, the agent can build an app with its own interface, logic, and state. The app can use connected company resources and support multiple people working together.

Run deterministic workflowsÂ

Not every job needs a full agent session. Many are a known sequence of steps with one or two places where judgment is useful. A workspace can turn those jobs into mostly deterministic workflows, using code for the predictable steps and a model only where it adds value. Workflows can run on demand, on a schedule, or when an event occurs in a connected system.

Cloudflare OS gives agents and apps governed access to systems of record through Gatekeepers (more on this in the security section below). It also supports existing Model Context Protocol (MCP) servers your organization already uses via MCP Server Portals.

A new security and governance framework for safe access to internal data and services

As people begin experimenting with AI at work, one of their first requests is often for API keys to company systems. This makes sense: AI isn’t much use at work if it doesn’t have access to the systems people use to do their jobs.

But handing over API keys to people and agents is dangerous and does not scale. Keys often provide broad, long-lived access that is difficult to constrain, share safely, and audit.

MCP gives agents a better way to use these systems. An MCP server can hold the credential and expose a defined set of tools instead of handing the key directly to the agent. But controlling which tools an agent can call is only the first step. MCP alone does not tell us which underlying resources an agent has observed. The agent can combine information across systems, send it somewhere less restricted, or expose it through apps and outputs to people who may not be allowed to see the original resources. Authorization has to account for where the data can go next.

Agents start with no access

Cloudflare Access controls who can enter Cloudflare OS. Inside, every agent and app starts with access to nothing. An agent can ask for access to a specific resource, which you can grant or deny. Generated code receives that resource as a typed binding:

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});

env.PROJECT is a capability representing permission to use a specific resource under a specific policy. The credential remains completely isolated from the agent and any generated code.

Server code runs in a Dynamic Worker with global outbound networking disabled. Client code runs in a sandboxed frame in the browser. Neither can reach the Internet except through capabilities you explicitly provide.

Gatekeepers govern resources and actions

A Gatekeeper is a service-specific Worker that sits between Cloudflare OS and an external service. It understands the service’s API, its resources, and the operations that can be performed on them.

Giving an agent access to your entire GitHub account is likely too broad. A Gatekeeper can give it access to a single repository, allow it to read issues but not source code, mask particular fields, apply rate limits, and require approval before merging a pull request.

The agent and its apps see a small TypeScript API. The Gatekeeper handles OAuth, holds the credential, enforces policy, records what was read, and mediates anything with an externally visible side effect.

Policy follows what the agent has seen

Controlling the initial read is not enough. Take, for example, the case where an agent reads a sensitive table in a data warehouse and uses it to produce a live dashboard. Sharing the dashboard must not become a way to share the table with people who could not access it directly.

Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work. When another person tries to open the workspace, interact with the agent, or view what it produced, Gatekeepers verify that person's access to the observed resources.

The same observation log is used to inform policies that determine when agents can make external requests. A read of sensitive data can prevent the agent from writing data to certain sources, inviting new collaborators, handing work to another agent, or making an outbound request.

People using agents or building apps do not have to worry about making these mistakes. The platform can now be used to handle this.

A platform for building and sharing personal, modifiable apps

Most productivity suites give you a fixed set of applications: documents, spreadsheets, and presentations. In Cloudflare OS, each “file” can be its own application, written by an agent for one person, one project, or one team.

These are not prototypes that you have to export and deploy somewhere else. Each one is a full-stack application with client code, server code, an API, and durable state. Apps are private by default, but can be shared like documents.

Every app is a Worker

When you ask your workspace to build an app, the agent writes two parts:

• Client code that renders the app’s UI in the browser
• Server code that stores state and implements the app’s behavior

The server is loaded on demand as a Dynamic Worker and instantiated as a Durable Object Facet (both are features we built for this project). The facet gives the app its own SQLite database, separate from the Cloudflare OS runtime managing it. Dynamic Workers use lightweight V8 isolates, so every app can have its own isolated runtime without needing a dedicated server or container sitting around.

The browser client talks to the server using Cap’n Web, Cloudflare’s open source object-capability Remote Procedure Call (RPC) system. A server method can be called from the client like a normal JavaScript function:

const issues = await app.listIssues({
 status: "done",
});

The special part is that the agent can also call the same method.

So if you can build a tool to do a job yourself, agents can use your tool to do the job when you’re not there.

Share the app, or share how it was built

When you build an app in Cloudflare OS, you have two ways to share them:

• Sharing your app itself lets other people collaborate in real time using the same state.
• Sharing a blueprint of your app lets other people create their own copy of your app.

An app instantiated from a blueprint contains the original app’s code. But it does not contain its SQLite data, conversation history, credentials, or connected resources. Each new app starts with independent state and resources.

This means when you share apps with your team, they can modify them themselves with AI instead of filing a feature request and assigning you.

Use any model, and control what it costs

Cloudflare OS can be used with any model. Every inference call runs through Cloudflare AI Gateway, giving your organization one place to decide which models are available and which model should handle each job.

Not every task needs the most expensive model. You may not want to run the most expensive frontier model to summarize your unread emails every morning. AI Gateway gives you the control needed to make sure expensive models are only being used for the hardest work.

Every request is attributed to the person, team, or workspace that made it. Administrators can see where inference spend is going, set budgets and rate limits, and decide what happens when a limit is reached.Â

Open source, so you can make it yours

Cloudflare OS is available today and is open source. Check out the cloudflare-os GitHub repository. You can deploy it into your own Cloudflare account and use your own Access policies, AI Gateway configuration, data, and integrations.

Our internal deployment reflects Cloudflare’s systems, terminology, policies, and ways of working. Yours should reflect your organization.

Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product.

We are releasing two repositories: the Cloudflare OS core and an example deployment based on how we run it internally at Cloudflare. The deployment repository consumes the core without patching it, providing a place for configuration, custom UI, internal integrations, analytics, and deployment pipelines.

Delivered together with our partners

The source code is only the starting point. The context, skills, workflows, internal systems, and policies are what make Cloudflare OS even more useful for your organization.

Cloudflare’s strategic partners, Presidio and Happy Cog, will work with you to customize Cloudflare OS around how your organization operates and roll it out across your workforce.

Partners can help you curate shared skills and institutional context, build custom interfaces, connect internal systems through Gatekeepers and MCP Server Portals, and configure security, model, and cost controls.

You get your own branded Cloudflare OS, connected to your systems, running on Cloudflare, and shaped around how your people actually work.

Get started

Cloudflare OS is available today on GitHub. You can explore the source code, try the demo, or deploy it into your own Cloudflare account in a few minutes using our starter repository.

We’re just getting started. We’re working on bringing Cloudflare OS to the Cloudflare dashboard as a fully managed product, adding containers for development workflows, and bringing workspaces into Slack and other chat tools.

If you’re interested in talking with our team, we would love to chat. Use this form to reach out!