Cloudflare 构建 Cloudflare OS 以安全部署 AI 代理
Cloudflare AI··作者 Sam Rhea
关键信息
Cloudflare 最初使用了 Workers 和 Access 等现成组件来搭建，随后又根据内部需求补充了定制服务。公司表示，该平台的目标是让员工获得“超能力”，而不是只面向开发者，因为很多用例来自销售和其他非工程团队。
资讯摘要
Cloudflare CIO Sam Rhea 说，公司之所以意识到问题已经发生变化，是因为一名销售员工来找他索要多个 API 密钥，并要求获得大约十几个内部系统的生产访问权限，以及部署流水线的管理员权限，目的是构建一个由 AI 驱动的“SuperApp”。在此之前，Cloudflare 对 2025 年的 AI 推进一直比较谨慎，主要只把它用于信息问答和帮助编写样板代码。到了上一年的年底，随着更强的模型和更强的 harness 出现，情况突然改变，AI 代理开始真正具备执行任务的能力。新年期间，Cloudflare 数百名来自技术和非技术岗位的员工开始试用新工具，探索更容易的构建方式。
公司很快发现，内部对这类能力的需求增长非常快，因此既要帮助员工使用这些工具，也要保护系统、内部数据和客户数据的安全。过去几个月里，Cloudflare 围绕这个目标搭建了 Cloudflare OS，这是一个受治理的内部平台，用于安全地使用 AI 和部署代理。公司先把自家的 Developer 和 Zero Trust 产品中的现成组件拼接起来，包括 Workers 和 Access，然后在此基础上补充了定制服务。Cloudflare 表示，这些内部能力现在被整理并公开分享，同时这段经历也为公司如何组织 AI 采用提供了经验教训。
资讯正文
Sam Rhea 是 Cloudflare 的首席信息官。
大约六个月前，当我们销售组织中的一名成员联系我要 API key 时，我意识到我们有问题了。不是一个 key，而是复数个 key。他们用 AI 构建了一个他们称之为 SuperApp 的东西，希望它能改变我们的 go-to-market 团队。他们所需要的，只是能够访问 Cloudflare 大约十几个系统记录的生产权限，以及一个部署流水线的管理员权限，这样它才能运行起来。
在 2025 年，我们对在 Cloudflare 推广 AI 采取了相当谨慎的方式。我们部署了信息类聊天应用，也试着用 AI 来帮助编写一些样板代码，但我们觉得这项技术还没有准备好改变我们的工作方式。
而到了去年年底的几天时间里，更好的模型和更强大的 harness 改变了这种判断。AI agents 开始能做事，而且能做得很好。Cloudflare 里数百名团队成员，无论技术岗位还是非技术岗位，都在新年周围较为清闲的那几周里尝试了这些新工具，它们让构建应用比以往任何时候都更容易。
那位正在搭建 SuperApp 的销售团队成员，只是后来蜂拥而至、举手要求使用这些工具来改变工作方式的人中的第一位。我们有责任为他们提供工具并赋能他们这么做。但我们也有责任保护我们的系统、内部数据和客户数据安全。
过去几个月里，我们一直在 Cloudflare 内部构建一个平台，正是为了实现这一点。我们把它叫作 Cloudflare OS。我们先从现成组件开始拼接，使用了 Developer 和 Zero Trust 平台中的产品，比如 Cloudflare Workers 和 Access。随着我们对这一挑战了解得更多，我们也创建了专门为这种新工作方式量身定制的自定义服务。
和 Cloudflare 的许多产品一样，我们最初是为解决内部遇到的问题而出发。事实证明，你们中的很多人也面临同样的问题。这就是为什么今天我们很高兴分享 Cloudflare OS——它汇集了我们在内部推出的一切，目的是让我们自己的团队成员能够安全且高效地使用 AI 和部署 agents。你可以在这里阅读 Phillip 的文章，了解目前已经可用的内容。
在这篇文章里，我想回顾一下促成这次发布的我们自己的内部历程，包括哪些地方进展顺利，哪些地方我们也曾失手。文章分为五个部分：我们最初建立的原则；我们如何通过试点来弄清楚需要完成哪些工作；我们为工程师以及非工程师分别构建了什么；以及我们如何在整个组织内培养倡导者，帮助推动变革。
在过去几个月里，我感觉自己像是世界上最幸运的 CIO，因为我所支持的团队能够接触到这些新兴技术。今天的目标，是把这个平台以及从中得到的经验分享给每一个团队。
设定基本规则
我们首先定义了一套关于这件事应该如何运作的原则。Cloudflare 的 CTO 和我坐在德克萨斯州奥斯汀的办公室里，开始梳理在采用 AI 这件事上，哪些条件必须成立。我们邀请了来自整个组织的领导者对草案提出反馈。最终形成了下面这些指导原则。
1）我们使用 AI，目的是花更多时间与客户在一起，并构建技术来解决他们更多的问题。
我们不想为了使用 AI 而使用 AI。我们推动各团队首先定义他们的“待办任务”（jobs to be done），也就是那些痛点、瓶颈或错失的机会，以便改进我们服务客户的方式。然后我们再寻找合适的工具。
2）每个人都应该拥有超能力。
AI 在编写代码方面非常、非常擅长。由此推及，第一波能够采取行动的 AI 工具，所采用的接口都是开发者已经在使用的：命令行、代码编辑器、终端、Git 仓库。
这些形式可能会把我们团队中的很大一部分人排除在外。虽然我们的员工整体上非常技术化，也充满好奇心，但并不是每个团队成员每天都在开发者工具里工作。我们也不认为他们有这个必要！我们希望员工带来他们的专业领域知识，而我们则为他们提供一个直观的平台，让他们重新思考我们如何开展工作。
3）人类对结果负责。
我们把 AI 视为工具和工具制造者，而不是团队成员。我们期望人类对定义质量、测试以及依赖 AI 输出的工作流承担责任。
这一规则同样适用于部署 agent。发布 agent 的用户和团队，要对这些 agent 的输出负责。有人离职了？他们的经理会像继承其他工作流一样，继承这些 agent 的责任。
4）来自组织的上下文，比模型本身更重要。
我们在 Cloudflare 部署的工作流和 agent，需要了解 Cloudflare。我们花在技术上的时间，必须与投入到一个经过筛选、权威且统一的上下文层上的时间相匹配。
5）在使用 AI 时，你绝不应该比使用系统记录（systems of record）时拥有更多权限。
Cloudflare 的每个人都能以受限范围查看 Cloudflare 的底层数据，这是有充分理由的。我们使用自己的产品，按设备、角色、地区等因素分段控制数据访问。我们也会在第三方应用中配置并监控这些控制措施。
当我管理一个与同样数据交互的 AI agent 时，这些控制措施也必须适用。使用 AI 工具时，我绝不应该对数据拥有“更多”访问权限；我的 AI agent 也只能访问它们恰好需要的内容，一点都不能多。而如果我部署了一个 agent 并与他人共享，那么这个 agent 赋予他们的访问权限也应该反映他们自己的权限，而不是我的。
在用户所在的地方与他们相遇
在这些规则到位之后，我们开始着手工作。我们并行推进了两个项目：第一个面向我们的工程团队，第二个面向其他所有类型的工作。
为你的工程师提供护栏
AI 工具把我们工程师原本就做的工作变得更快了——快到我们的审查流程都跟不上了。现在，Cloudflare 的任何人都可以借助 AI 更快地写出糟糕的代码。我们需要更好的护栏。
于是我们为工程构建了一层上下文。我们把它称为 Cloudflare Engineering Codex。Codex 是一份权威指南。我们的这份指南明确了我们遵循的原则和实践。政策告诉你不能做什么，而 Codex 告诉你应该做什么。它从设计之初就是带有明确立场的。我们代码库的每一部分都有一个领域负责人，对那里的“好”应该是什么样子负责。
我们把这一层上下文贯穿到了整个软件开发生命周期中。智能体使用 Codex 来帮助工程师规划工作。一个智能体会根据 Codex 要求审查每一条 Merge Request。另一个会在实施开始前审查技术设计。第三个会审查事故报告。在过去四个月里，这些智能体已经标记出近 25 万个潜在问题，并阻止了 16,000 次合并。它们还在真正写下一行代码之前，就在接近 600 份设计中发现了架构问题。
你可以在 Timo 关于 AI Code Review 的博客文章中，读到我们如何构建这一代码审查工作流的更详细介绍。我们现在正把重点转向为工程师提供工具，让他们定义评估智能体产出工作的循环。
给每个人一个“魔法邮箱别名”
我们早期犯的一个错误，是把同样的工具交给工程团队之外的所有人，只是界面稍微友好了一些。工程师可以把代码仓库克隆到自己的笔记本电脑上，添加像 AGENTS.md 这样的上下文文件，并把自己的 harness 指向这项工作。然而，市面上的这些 harness 并不太适用于其他类型的知识工作；在那些场景里，用户会创建一次性的输出，并围绕涉及数十个系统记录的项目开展工作。
如果你给每个人一个特别擅长写代码的 harness 工作区，你最终得到的代码会远远超过所需。结果就变成了一波寻找问题来解决的 vibe coded 应用。于是我们反过来思考。
我们告诉 Cloudflare 的每个人，他们可以把自己不想做的工作发到一个“魔法 AI 邮件机器人”，它会回复他们所需要的输出。幕后有一个小团队使用 AI 工具来处理这些工作，并以此维护这个邮箱别名。
不知为什么，人们不太愿意把自己的 vibe coding 想法发给他们认为是自动化系统的东西，但却非常愿意把自己不想做的工作发出去。在管理这个邮箱别名的数百次、后来又成千上万次会话中，我们识别出了团队成员希望自动化的琐碎工作。
我们把这些内容手动分流，随着时间推移观察到了模式。我们创建了技能和上下文文件，梳理了数据连接，并定义了用户所需要的输出类型。有了这些之后，我们就可以把发往这个邮箱别名的部分回复自动化。
我们非常希望停止为这项服务继续安排人手。那体验糟透了。我们的长期目标，是把这些已经汇编起来的材料整理成技能来处理这些需求，这样用户就能自己解决问题。围绕这个邮箱别名的人工工作一直持续到我们觉得，已经捕捉到了足够多 Cloudflare 内部常见的“待办工作”，足以让我们的团队在自动化上获得一个好的起点。现在，我们只需要给他们一个平台，让他们能够轻松而安全地运行这些工作流。
给团队成员一个解决问题的平台
我们将这个平台的第一个版本称为 Cloudflare OS，它由一个简单的支架组成，运行在 Cloudflare 基础设施上的容器中。用户可以通过网页浏览器访问它，并在通过 Cloudflare Zero Trust 完成身份验证后，运行我们在“magic email”阶段开始收集的技能文件和工作流。
这一切都在他们的浏览器中完成，无需任何本地配置。用户可以打开笔记本电脑，立刻投入工作。我们听说，销售团队的新成员在入职几天后就觉得，自己已经能够自动化处理那些在上一家公司里需要花上几周才能完成的工作。
用户还可以在工作进行时合上电脑去喝杯咖啡，或者去洗手间。再也不用抱着一台打开着的笔记本电脑在办公室里来回走动了。
我们认为，基于云的工作空间带来的好处不只是对用户而言。一个短暂存在的云端环境，只能访问用户在会话中引入的数据，而不是像本地支架那样，可能访问你面前那台笔记本电脑上的几乎所有内容。我们的安全团队能够对该环境进行审计可见性和网络控制，包括过滤它可以连接到互联网哪些位置的能力。
当用户需要完成工作时，他们会先运行我们根据跨部门识别出的常见工作流定义的技能文件。我们在“magic email”阶段收集到的公司积累的上下文和技能，都能通过一次点击变成可执行内容。
右侧面板会渲染某个技能文件的输出，例如一份技术架构文档或一套幻灯片。用户可以把这些输出分享给队友。
我们通过将各类系统记录连接到我们的 Model Context Protocol（MCP）Portal，为 Cloudflare OS 提供数据访问能力。MCP 标准是一个框架，用来定义如何把 AI 工具连接到系统记录，并向 AI 工具说明哪些数据和操作是可用的。按照我们关于权限的规则，Cloudflare OS 中某个用户会话拥有的访问权限，会被限定在其在特定系统记录中已有的权限集合之内。
在大多数情况下，即便某个系统记录提供了原生版本，我们也会为每个系统记录构建并部署我们自己的 MCP 服务器实现。通过自己构建，我们可以增加更多控制层，例如按角色或地区设置速率限制。Cloudflare Workers 为我们提供了一个构建这些服务的简单位置，而作为无服务器平台，其持续维护负担几乎为零。
当 Cloudflare OS 使用 AI 推理时，我们会通过 AI Gateway 来路由。这使我们能够过滤、记录并审计用户与这些 AI 系统之间的所有交互。例如，我们可以复用 Secure Web Gateway 中的数据泄露防护（DLP）规则，阻止某些数据集被发送给服务提供商。
AI Gateway 也让我们能够控制模型使用。并不是每个用户都需要访问最新前沿实验室模型的最大“思考”模式。我们也不需要团队成员每小时花 20 美元去总结自己的电子邮件收件箱。我们可以使用 AI Gateway 按角色限制模型访问，或者引导某些使用场景——尤其是更自主的场景，比如按计划运行的 skill file——转向更高效的模型。
现在，让代理为每个人带来更确定性的工作方式
Cloudflare OS 为我们的团队提供了一个 AI 工作区，用户可以在其中运行 skill file 以及自己的工作流。不过，用户每运行一次 skill file，都会触发一次非常消耗 token 的推理会话。我们所做的大部分工作本质上是确定性的：一系列步骤，在合适的位置加入一些推理（或者人工判断）。我们并不总是需要 AI 作为工具本身，更多时候我们需要 AI 成为“造工具的人”。
我们着手在 Cloudflare OS 的一个更新版本中解决这个问题，这也是我们今天与大家分享的版本。这个版本允许用户用自然语言描述一个工作流，让 AI agent 创建驱动该工作流的代码，然后按需、按计划，或者在事件触发时运行这些 agent。我们并不是试图打造一套大家都共享的、适用于所有场景的通用 agent，而是赋予每一位团队成员创建安全应用的能力，并且默认彼此隔离。
举个例子，我合作的一个团队是我们的 IT 帮助台。我们为 Cloudflare 的团队成员提供完成工作所需的硬件和软件支持，从设备开通到故障排查，再到离职交接。我们通过一个传统的工单队列来管理这些工作。
每天早上，我都希望查看我们的未结工单队列，以及与我们服务这些内部客户能力相关的指标。在 Cloudflare OS 之前，我会手动完成这件事。我们的工单系统内置了仪表盘，但功能相当基础。我会下载 CSV 文件并导入 Google Sheets，然后自己制作图表。接着，我还会手动逐个打开前一天夜里进入的每张工单。这既耗时，又会在我们的记录系统之外产生重复数据。
在 Cloudflare OS v1 中，我把这件事做成了一个连接到我们工单软件 MCP 服务器的 skill file。虽然更安全一些，也少了一些手工操作，但这意味着我每天早上都要花掉数千个 token，去重新生成一份大体相同的报告。我还会在处理夜间工单、起草回复时白白消耗 token。
Cloudflare OS v2 已经替我，以及任何面临类似问题的人，处理好了这些事情。我先描述了自己想查看的图表，然后它使用一个 AI agent 来编写驱动这些图表的代码，并通过一个名为 gatekeeper 的服务与数据集建立安全连接。这个 gatekeeper 负责处理 agent 对数据集发起的一致性查询，在不需要任何 API key 管理的情况下，为应用缩减上下文。
当我确实需要 AI 推理时，我可以把它嵌入到应用中。我已经构建了用 AI 为新到工单起草回复的选项。我可以审阅这些回复并发送出去。所有这些都发生在一个受保护的工作区内，而且我不需要创建和管理任何集成或部署流水线。
当我把自己构建的智能体分享给其他人时，他们会通过同样的门禁，使用自己的权限对该智能体进行身份验证，因此我们不会跨越数据边界。而且，每次我加载初始报告时，都会恰好消耗零个 token。
派出先锋，分享成果
Cloudflare OS 为我们提供了所需的平台，但我们仍然需要让团队真正用起来。为此，我们没有聘请一个专门的 AI 团队。相反，我们在不同岗位中找到了早期采用者，把他们培养成“先锋”，帮助同事使用这个新平台。我们邀请了伦敦的一位销售负责人、德克萨斯的一位解决方案工程师、葡萄牙的一位投资者关系负责人、日本的一位业务拓展团队成员、美国的一位 Sales Ops 负责人等，让他们与各自团队协作，重新思考自己的工作方式。
我们在把实习生嵌入成熟团队方面也取得了成功。我们宣布今年的目标是招募 1,111 名实习生，而其中许多加入我们的人都在各个部门内工作，目标很简单：借助我们的 AI 工具，把这个团队打造成为“全明星”。
结果仍然让我们感到惊喜。每周都有成千上万名 Cloudflare 团队成员使用这个平台，而且每日活跃用户数在每一个工作日都在增长。仅在上个月，我们估计销售团队成员就已经节省了超过 10,000 小时的时间，这些时间原本会花在以往需要人工完成的任务上，比如区域规划和提案撰写。在这 30 天里，用户创建了超过 4,000 个应用和工具，用来解决具体挑战。
接下来是什么？
我们离完成还差得很远，但我每天都能看到一点点进展，因为我们始终专注于如何重新思考我们为解决问题而需要做的工作。昨晚，有人把 Cloudflare OS 中一份报告的链接发给我，这份报告帮助我们诊断一个采购瓶颈；如果放在以前，这需要耗费数天的人工电子表格排查。今天早上，IT 团队的一名成员把一个基于该平台构建的笔记本更换跟踪工作流智能体分享给了旁边坐着的一位财务团队成员，地点是在里斯本办公室。这样的自动化和知识共享看似微小，却会不断累积成效。
正如我们致力于让 Cloudflare 的每个人都拥有超能力一样，我们也认为 Cloudflare 之外的每个团队都应该拥有这些能力。我们很高兴今天与大家分享 Cloudflare OS，并且我们预计，随着我们共同学到更多东西，它还会继续快速演进。如果有人想坐下来交流一下，聊聊在内部 AI 推广中哪些有效、哪些无效，请告诉我们。我很乐意聊一聊，人与人之间地聊。
来源与参考
收录于 2026-08-06