我们如何通过 Cloudflare OS 重新思考 Cloudflare 的工作方式
Sam Rhea 是 Cloudflare 的首席信息官。
大约六个月前，当我们销售团队的一位成员联系我索要 API 密钥时，我就知道我们遇到了问题。密钥是复数。他们用 AI 构建了一个他们称之为 SuperApp 的东西，这将改变我们的市场推广团队。他们所需要的只是生产环境访问 Cloudflare 内部大约十几个记录系统，以及一个部署管道的管理员权限，就能让它工作。
在 2025 年期间，我们对在 Cloudflare 推广 AI 采取了相当谨慎的态度。我们部署了信息类聊天应用，并尝试使用 AI 帮助编写一些样板代码，但我们认为这项技术还没有准备好改变我们的工作方式。
然后，在去年年底的几天里，更好的模型和更强大的工具改变了这种考量。AI 代理可以做事情，而且它们可以做得很好。Cloudflare 的数百名团队成员，无论是技术岗位还是非技术岗位，都在新年期间相对安静的几周里尝试新工具，这些工具让构建变得比以往任何时候都更容易。
那位销售团队成员构建他们的 SuperApp 只是人们纷纷举手使用这些工具来改变他们做事方式的第一例。我们有义务为他们提供装备和支持。但我们也有义务保护我们的系统、内部数据和客户数据的安全。
在过去的几个月里，我们一直在 Cloudflare 内部构建一个平台来做到这一点。我们称之为 Cloudflare OS。我们首先将来自我们的开发者和零信任平台的现成组件拼接在一起，比如 Cloudflare Workers 和
. 随着我们对挑战的了解加深，我们还创建了针对这种新工作方式定制的服务。
__Access__与 Cloudflare 的许多产品一样，我们着手解决一个内部问题。事实证明，你们中的许多人也有同样的问题。这就是为什么今天我们很高兴分享 Cloudflare OS，这是我们在内部推出的所有成果的总和，旨在让我们的团队成员能够安全且高效地使用 AI 并部署代理。您可以在 Phillip 的这篇文章 中了解更多关于当前可用的内容。
在这篇文章中，我想回顾一下我们内部走向这一发布的历程，包括哪些进展顺利，哪些地方我们犯了错误。共有五个部分：我们开始制定的原则；我们如何试点以确定需要完成的工作；我们为工程师和非工程师构建了什么；以及我们如何在组织内创建推动变革的倡导者。
在过去的几个月里，我感觉自己是世界上最幸运的首席信息官，因为我支持的团队能够接触到这些新兴技术。今天的目标是与每个团队分享这个平台及其经验教训。
制定基本规则
我们首先围绕这项工作应该如何进行定义了一套原则。Cloudflare 的首席技术官和我在德克萨斯州奥斯汀的办公室里坐下来，开始勾勒我们在采用 AI 时需要满足的条件。我们邀请了来自组织各处的领导者对草案提出反馈。结果就是下面的指导方针。
1) 我们使用AI是为了花更多时间与客户在一起，并构建技术来解决他们更多的问题。
我们不想为了使用AI而使用AI。我们推动团队首先定义他们的“待完成工作”，即痛点、瓶颈或错失的机会，这些可以改善我们服务客户的方式。然后我们找到合适的工具。
2) 每个人都应该拥有超能力。
AI非常非常擅长编写代码。因此，第一波能够采取行动的AI工具由开发者已经使用的界面组成：命令行、代码编辑器、终端、Git仓库。
这些格式可能会让我们团队中的大部分人掉队。虽然我们拥有非常技术化和好奇的员工队伍，但并非每个团队成员都在开发者工具中度过一天。我们认为他们不需要这样！我们希望员工带来他们的领域专业知识，我们将为他们提供一个直观的平台，他们可以用它来重新思考我们的工作方式。
3) 人类拥有输出。
我们将AI视为工具和工具制造者，而不是团队成员。我们期望人类负责定义质量、测试以及依赖AI输出的工作流程。
这条规则也适用于部署代理。发布代理的用户和团队对其代理的输出负责。有人离开？他们的经理继承其代理的责任，就像继承他们的其他工作流程一样。
4) 来自组织的上下文比模型更重要。
我们在Cloudflare部署的工作流程和代理需要了解Cloudflare。我们花在技术上的时间必须与投入在精心策划的、规范的上下文层上的时间相匹配。
5) 使用AI时，你绝不应该拥有对记录系统的更多权限。
Cloudflare的每个人对Cloudflare底层数据都有范围限定的视图，这是有充分理由的。我们使用自己的产品，根据设备、角色、地区等因素来细分数据访问。我们还配置和监控第三方应用程序中的控制。
当我管理一个与相同数据交互的AI代理时，这些控制需要适用。使用AI工具时，我绝不应该拥有“更多”的数据访问权限，我的AI代理应该只拥有它们确切需要的访问权限，仅此而已。如果我部署一个代理并与他人共享，该代理为他们提供的访问权限应反映他们的权限，而不是我的。
在用户所在之处满足他们
有了这些规则，我们开始工作。我们运行了两个并行项目：一个针对我们的工程团队，另一个针对所有其他类型的工作。
为工程师提供护栏
AI工具让工程师已经做的工作变得更快——快到我们的审查流程跟不上。由于AI，Cloudflare的任何人都可以更快地写出糟糕的代码。我们需要更好的护栏。
因此，我们为工程构建了一个上下文层。我们称之为Cloudflare工程准则。准则是一份权威指南。我们的准则阐述了我们的工作原则和实践。政策告诉你不能做什么，而准则告诉你应该做什么。它是有主见的设计。我们代码库的每个部分都有一个领域所有者，负责该部分的好样子。
我们在软件开发生命周期中展现了这一上下文层。代理使用 Codex 帮助工程师规划工作。一个代理根据 Codex 要求审查每个合并请求。另一个代理在实施开始前审查技术设计。第三个代理审查事件报告。在过去的四个月里，这些代理标记了近25万个潜在问题，并阻止了16,000次合并。他们在编写一行代码之前，在近600个设计中发现了架构问题。
您可以在Timo关于AI代码审查的博客文章中更详细地了解我们如何构建此代码审查工作流程。我们现在正将重点转向为工程师提供工具，以定义评估其代理所产生工作的循环。
为每个人提供神奇的电子邮件别名
我们早期犯的一个错误是，给工程部门以外的每个人提供相同的工具，但用户界面稍微友好一些。工程师可以将代码仓库克隆到笔记本电脑上，添加一个像AGENTS.md这样的上下文文件，并将其工具指向工作。然而，市场上的工具在映射到其他类型的知识工作方面表现不佳，这些工作涉及用户创建一次性输出并处理涉及数十个记录系统的项目。
如果你给每个人一个擅长编写代码的工具工作区，你最终会得到比你需要的多得多的代码。结果是一大堆寻找问题解决的vibe编码应用。所以我们反向工作。
我们告诉Cloudflare的每个人，他们可以将不想做的工作发送给一个“神奇的AI电子邮件机器人”，该机器人会回复他们需要的输出。在幕后，一个小团队使用AI工具来管理这个电子邮件别名。
出于某种原因，人们不太愿意将他们的vibe编码想法发送给他们认为是自动化的系统，但非常愿意发送他们不想做的工作。在管理电子邮件别名的数百次和数千次会话中，我们确定了团队成员希望自动化的平凡工作。
我们手动对这些进行分类，随着时间的推移，我们观察到了模式。我们创建了技能和上下文文件，绘制了数据连接，并定义了用户需要的输出类型。有了这些，我们可以自动化对此电子邮件别名的部分回复。
我们非常积极地停止为这项服务配备人员。这很痛苦。长期目标是利用我们整理的这些材料来创建技能来解决这些问题，以便我们的用户能够自己解决问题。这个电子邮件别名背后的手动工作一直持续到我们觉得已经捕获了Cloudflare中足够多的常见“待完成工作”，以便为我们的团队提供自动化的先机。现在，我们只需要为他们提供一个可以轻松安全地运行这些工作流程的平台。
为团队成员提供解决问题的平台
该平台的第一个版本，我们称之为Cloudflare OS，由一个在Cloudflare基础设施上的容器中运行的简单工具组成。用户通过Web浏览器访问它，一旦通过Cloudflare Zero Trust进行身份验证，他们就可以运行我们在神奇电子邮件阶段开始收集的技能文件和工作流程。
所有这些都发生在他们的浏览器中，无需本地配置。用户可以打开笔记本电脑，立即投入工作。我们听说销售团队的新成员在入职几天内就感觉可以自动化完成那些在上一份工作中需要数周才能完成的工作。
用户还可以合上电脑，去喝杯咖啡或使用洗手间，而工作仍在继续。不再需要拿着打开的笔记本电脑在办公室里走来走去。
我们认为基于云的工作空间不仅仅惠及用户。一个临时的基于云的环境只能访问用户引入会话的数据，而不是像使用本地工具时那样可能访问你面前笔记本电脑上的所有内容。我们的安全团队对环境具有审计可见性和网络控制，包括能够过滤它可以连接的互联网位置。
当用户需要完成工作时，他们首先运行由我们跨部门识别的常见工作流定义的技能文件。公司在魔法邮件阶段积累的上下文和技能，现在只需单击即可执行。
右侧面板会渲染给定技能文件的输出，例如技术架构文档或幻灯片。用户可以与队友分享输出结果。
我们通过连接记录系统，通过我们的 模型上下文协议（MCP）门户 为 Cloudflare OS 提供数据访问。MCP 标准是一个框架，定义了如何将你的 AI 工具连接到记录系统，以告知 AI 工具哪些数据和操作可用。遵循我们的权限规则，Cloudflare OS 中用户会话的访问权限仅限于其在给定记录系统中的现有权限集。
在大多数情况下，我们为每个记录系统构建并部署我们自己的 MCP 服务器实现，即使记录系统提供了原生版本。通过构建我们自己的，我们可以添加额外的控制层，例如按角色或地区限制速率。Cloudflare Workers 为我们提供了一个简单的构建位置，并且作为一个无服务器平台，持续的维护负担几乎为零。
当 Cloudflare OS 使用 AI 推理时，我们通过我们的 AI 网关 进行路由。这使我们能够过滤、记录和审计用户与这些 AI 系统之间的所有交互。例如，我们可以重用
数据丢失防护以阻止某些数据集被发送到提供商。
安全 Web 网关
AI Gateway 还让我们能够控制模型的使用。并非每个用户都需要访问最新前沿实验室模型的最高思考模式。我们也不希望团队成员每小时花费 20 美元来总结他们的电子邮件收件箱。我们可以使用 AI Gateway 按角色限制模型，或将用例（尤其是更自主的用例，如定时技能文件运行）引导到更高效的模型上。
现在，通过为所有人提供的代理，使其更具确定性
Cloudflare OS 为我们的团队提供了一个 AI 工作空间，用户可以在其中运行技能文件和自己的工作流。然而，用户运行的每个技能文件都会启动一个消耗大量令牌的推理会话。我们做的大部分工作基本上是确定性的；一系列步骤，在适当的位置加入一些推理（或人工判断）。我们不需要 AI 总是作为工具，而更需要 AI 成为工具制造者。
我们着手在 Cloudflare OS 的更新中解决这个问题，这就是我们今天与您分享的版本。此版本允许用户用自然语言描述工作流，让 AI 代理创建支持该工作流的代码，然后按需、按计划或由事件触发运行代理。我们不是试图构建适用于整个组织的通用代理，而是让每个团队成员都能创建默认隔离的安全应用程序。
例如，与我合作的团队之一是我们的 IT 帮助台。我们为 Cloudflare 的团队成员提供他们工作所需的硬件和软件支持，从配置到调试再到离职处理。我们通过经典工单队列来管理这些工作。
每天早上，我都想查看我们的未结工单队列以及我们服务这些内部客户的能力指标。在 Cloudflare OS 之前，我会手动完成这项工作。我们的工单系统有内置仪表板，但它们相当基础。我会下载 CSV 文件并导入到 Google Sheets 中，在那里创建图表。然后我会手动点击查看夜间收到的每个工单。这既耗时，又在我们的记录系统之外创建了冗余数据。
在 Cloudflare OS v1 中，我将其作为连接到我们工单软件 MCP 服务器的技能文件运行。虽然更安全（且更少手动），但这意味着我每天早上要消耗数千个令牌来重新创建一份基本相同的报告。我还在浪费令牌来分类和起草对夜间工单的回复。
Cloudflare OS v2 为我以及任何有类似问题需要解决的人处理了这个问题。我描述了我想查看的图表，它使用 AI 代理编写支持这些图表的代码，并通过我们称为 gatekeeper 的服务安全连接到数据集。该 gatekeeper 处理我的代理对数据集的一致查询，缩小应用程序的上下文范围，而无需任何 API 密钥管理。
当我确实需要 AI 推理时，我可以将其嵌入到应用程序中。我构建了用 AI 起草工单回复的选项。我可以查看回复并发送。所有这些都在一个安全的工作空间内完成，无需我创建和管理任何集成或部署管道。
当我与他人分享我构建的代理时，他们通过相同的守门人使用自己的权限进行身份验证，因此我们不会跨越数据边界。而且我每次加载初始报告时，消耗的令牌恰好为零。
派出冠军，分享你的胜利
Cloudflare OS 为我们提供了所需的平台，但我们仍然需要赋能我们的团队。为此，我们没有聘请专门的 AI 团队。相反，我们在不同角色中找到了早期采用者，并让他们成为能够帮助同事使用这个新平台的冠军。我们联系了伦敦的一位销售负责人、德克萨斯州的一位解决方案工程师、葡萄牙的一位投资者关系负责人、日本的一位业务发展团队成员、美国的一位销售运营负责人等，并请他们与各自的团队合作，重新思考他们的工作。
我们还成功地将实习生嵌入到现有团队中。我们宣布了今年引入 1,111 名实习生的目标，许多加入我们的实习生正在各部门工作，他们的简单目标是“通过为团队配备我们的 AI 工具，使这个团队成为全明星团队”。
结果继续让我们惊叹。每周有数千名 Cloudflare 团队成员使用该平台，每个工作日的活跃用户数都在增长。仅在过去一个月，我们估计销售团队成员在诸如区域规划和提案创建等以前手动任务上节省了超过 10,000 小时。在这 30 天里，用户创建了超过 4,000 个应用和工具来解决特定挑战。
下一步是什么？
我们远未完成，但每天我都能看到更多的进展，因为我们痴迷于重新思考解决问题所需的工作。昨晚有人给我发了一个 Cloudflare OS 中报告的链接，该报告帮助我们诊断采购瓶颈，而以前这需要手动爬取电子表格数天。今天早上，IT 团队的一位成员与里斯本办公室坐在旁边的财务团队成员分享了一个基于该平台构建的跟踪笔记本电脑更换的工作流代理。这些微小的自动化和知识共享行为正在累积。
正如我们致力于赋予 Cloudflare 每个人超能力一样，我们认为 Cloudflare 之外的每个团队也应该拥有这些能力。今天，我们很高兴与您分享 Cloudflare OS，并且我们预计它将随着我们共同学习而快速发展。如果有人想坐下来交流关于内部 AI 部署中哪些有效、哪些无效的笔记，请告诉我们。我很乐意进行人与人之间的交流。