# Cloudflare 如何用 Cloudflare OS 重构内部工作方式 - 来源：Cloudflare Blog - 作者：Sam Rhea - 发布时间：2026-08-05 21:00 - AIHOT 分数：61 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmsg5h9ax06dtrolg09b7xrd8 - 原文链接：https://blog.cloudflare.com/how-we-use-ai-with-cloudflare-os ## 精选理由 Cloudflare OS 将内部试错总结为产品，把零信任权限、MCP 集成和 AI 网关打包，让团队能在不突破既存数据边界的前提下自动化重复任务。 ## AI 摘要 Cloudflare 推出 Cloudflare OS，整合 Workers 与 Access 等组件，让员工安全使用 AI 并部署智能体。平台源于销售团队用 AI 构建 SuperApp 引发的内部需求，遵循“人负责输出”“权限不因 AI 扩大”等五项原则，面向工程师与非工程师分别提供支持。 ## 正文 Sam Rhea 是 Cloudflare 的首席信息官。 大约六个月前，我就知道我们遇到了问题——当时销售团队的一位成员联系我，索要 API 密钥。注意，是密钥们（复数）。他们用 AI 构建了一个他们口中的“超级应用”，声称将彻底改变我们的市场推广团队。他们需要的只是 Cloudflare 内部大约十几个核心业务系统的生产环境访问权限，以及一个部署管道的管理员权限，就能让这一切运转起来。 2025 年期间，我们在 Cloudflare 内部推行 AI 时采取了相当谨慎的态度。我们部署了信息类聊天应用，也尝试用 AI 辅助编写一些样板代码，但我们当时认为这项技术还没有成熟到足以改变我们的工作方式。 然而，就在去年年底的短短几天内，更强大的模型和更强大的工具框架改变了这一判断。AI 智能体能够做事了，而且能做得很好。Cloudflare 上下数百名员工，无论技术岗位还是非技术岗位，都在新年假期前后那段相对清闲的几周里，尝试了各种新工具——这些工具让构建变得前所未有的简单。 那位销售团队成员构建他们的“超级应用”，只是汹涌浪潮中的第一朵浪花——越来越多的人主动请缨，希望用这些工具来改变他们完成任务的方式。我们有责任为他们提供装备和支持，让他们能够这样做。但同时，我们也有责任确保我们的系统、内部数据和客户数据的安全。 过去几个月，我们一直在 Cloudflare 内部构建一个平台，正是为了实现上述目标。我们称之为 Cloudflare OS。我们首先将 Developer 和 Zero Trust 平台中的现成组件（如 Cloudflare Workers 和 Access）拼接在一起。随着我们对挑战的理解不断加深，我们还针对这种新的工作方式创建了定制化服务。 与 Cloudflare 的许多产品一样，我们最初是为了解决内部遇到的问题。事实证明，你们中的许多人也面临着同样的问题。因此，今天我们很高兴地分享 Cloudflare OS——这是我们在内部推出的所有成果的总和，旨在让我们的团队成员能够安全、高效地使用 AI 并部署智能体。你可以在 Phillip 的这篇文章中了解更多当前可用的功能。 在这篇文章中，我想回顾我们内部从最初到最终发布这段旅程的完整经历，既包括进展顺利的部分，也包括我们曾经失误的地方。全文分为五个部分：我们最初确立的原则；我们如何通过试点来明确需要完成的任务；我们为工程师和非工程师分别构建了什么；以及我们如何在组织内部培养变革推动者来助力转型。 在过去的几个月里，我感觉自己是全世界最幸运的 CIO，因为我所支持的团队能够接触到这些新兴技术。今天的目标，就是把这一平台及其经验教训分享给每一个团队。 制定基本规则 我们首先围绕这项工作应该如何推进，定义了一套原则。Cloudflare 的 CTO 和我坐在我们位于得克萨斯州奥斯汀的办公室里，开始勾勒我们在采用 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 工程准则（Cloudflare Engineering Codex）。Codex 是一份权威指南。我们的 Codex 阐述了我们所遵循的原则和实践。政策告诉你什么不能做，而 Codex 告诉你应该怎么做。它天生就带有明确立场。我们代码库的每个部分都有一个领域负责人，负责定义该领域的“优秀”标准。 我们将这一上下文层贯穿到软件开发生命周期的各个阶段。智能体使用 Codex 帮助工程师规划工作。一个智能体根据 Codex 要求审查每一个合并请求。另一个智能体在技术设计开始实施之前对其进行审查。第三个智能体负责审查事故报告。在过去四个月里，这些智能体标记了近二十五万个潜在问题，并阻止了 16,000 次合并。它们还在编写任何代码之前，在近 600 个设计中发现了架构问题。 关于我们如何构建这套代码审查工作流，你可以在 Timo 关于 AI 代码审查的博客文章中阅读到更详细的介绍。我们现在正将重点转向为工程师提供工具，让他们能够定义评估其智能体所产出工作的循环。 为每个人提供一个神奇的电子邮件别名 我们早期犯的一个错误是，给工程部门以外的所有人提供相同的工具，只是用户界面稍微友好一些。工程师可以将代码仓库克隆到笔记本电脑上，添加一个像 AGENTS.md 这样的上下文文件，然后将他们的工作框架指向这些工作。然而，市场上的这些工作框架很难映射到其他类型的知识工作上，因为这类工作的用户通常创建一次性的输出，并且所参与的项目涉及数十个记录系统。 如果你给每个人一个擅长编写代码的工作框架工作区，你最终会得到远超你需要的代码。结果就是大量“氛围编程”应用泛滥，它们都在寻找一个需要解决的问题。于是我们反其道而行之。 我们告诉 Cloudflare 的每个人，他们可以把不想做的工作发送给一个“神奇的 AI 电子邮件机器人”，这个机器人会回复他们需要的输出结果。在幕后，一个由少数人组成的小团队使用 AI 工具来操作这个电子邮件别名，完成这些工作。 出于某种原因，人们不太愿意把他们的“氛围编程”想法发送给他们认为的自动化系统，但却非常愿意把不想做的工作发送过去。在管理这个电子邮件别名的数百次乃至数千次会话过程中，我们识别出了团队成员希望自动化的那些琐碎工作。 我们手动对这些请求进行了分类，随着时间推移，我们观察到了其中的规律。我们创建了技能文件和上下文文件，梳理了数据连接关系，并定义了用户所需的各类输出。有了这些基础，我们就能对发往这个邮箱别名的一部分回复实现自动化处理。 我们非常迫切地想停止为这项服务配备人力。那实在太痛苦了。长期目标是把我们整理好的这些材料转化为技能，用来解决这些问题，让用户能够自行处理。这个邮箱别名背后的手工工作一直持续到我们觉得已经充分掌握了 Cloudflare 内部常见的“待完成工作”，足以让各团队在自动化方面有一个良好的起点。接下来，我们只需要给他们一个平台，让他们能够轻松、安全地运行这些工作流。 给团队成员一个解决问题的平台 这个平台的第一版，我们称之为 Cloudflare OS，由一个运行在 Cloudflare 基础设施上容器内的简单运行框架组成。用户通过网页浏览器访问它，一旦通过 Cloudflare Zero Trust 完成身份验证，就可以运行我们在“魔法邮箱”阶段开始收集的技能文件和工作流。 这一切都在他们的浏览器内完成，无需任何本地配置。用户打开笔记本电脑就能立即投入工作。我们听到销售团队的新成员反馈说，入职几天内，他们就觉得自己能自动化完成那些在上一家单位需要数周才能做完的工作。 用户还可以合上电脑，去喝杯咖啡或上个厕所，工作照常进行。再也不需要端着打开的笔记本电脑在办公室里走来走去了。 我们认为基于云的工作空间受益的不只是用户。一个临时的云端环境只能访问用户引入会话的数据，而不像使用本地运行框架时那样，可能访问到你面前笔记本电脑上的所有内容。我们的安全团队对环境拥有审计可见性和网络控制权，包括能够过滤它可以连接到的互联网范围。 当用户需要完成工作时，他们首先会运行技能文件，这些文件基于我们在各部门识别出的常见工作流程而定义。公司在“魔法邮件”阶段积累的上下文和技能，只需一次点击即可执行。 右侧面板会渲染某个技能文件的输出结果，比如技术架构文档或幻灯片演示文稿。用户可以与团队成员分享这些输出内容。 我们通过模型上下文协议（MCP）门户连接各记录系统，从而让 Cloudflare OS 能够访问数据。MCP 标准是一个框架，它定义了如何将你的 AI 工具连接到记录系统，并以一种告知 AI 工具可用数据和操作的方式来实现。遵循我们在权限方面的规则，用户在 Cloudflare OS 中某个会话的访问权限，被限定在其于特定记录系统中已有的权限集范围内。 在大多数情况下，即使记录系统提供了原生版本的 MCP 服务器，我们也会为每个记录系统自行构建并部署自己的 MCP 服务器实现。通过自行构建，我们可以增加额外的控制层，比如按角色或地区设置速率限制。Cloudflare Workers 为我们提供了一个简单的构建场所，而且作为一个无服务器平台，后续的维护负担几乎为零。 当 Cloudflare OS 使用 AI 推理时，我们会通过 AI Gateway 进行路由。这使我们能够过滤、记录和审计用户与这些 AI 系统之间的所有交互。例如，我们可以复用安全 Web 网关中的数据防泄漏（DLP）规则，阻止某些数据集被发送给提供商。 AI Gateway 还让我们能够控制模型的使用。并非每个用户都需要访问最新前沿实验室模型的最高思考模式。我们也不需要团队成员每小时花 20 美元来总结他们的电子邮件收件箱。我们可以使用 AI Gateway 按角色对模型进行门控，或将使用场景（尤其是更自主的场景，如定时运行的技能文件）引导到更高效的模型上。 现在，通过为所有人提供智能体，让这一切变得更加确定性。 Cloudflare OS 为我们的团队提供了一个 AI 工作空间，用户可以在其中运行技能文件和自己的工作流。然而，用户运行的每个技能文件都会启动一次消耗大量 token 的推理会话。我们做的很多工作大多是确定性的；即在正确的位置穿插一些推理（或人工判断）的步骤序列。我们需要的不仅仅是让 AI 始终作为一个工具，更需要让 AI 成为一个工具制造者。 我们着手在 Cloudflare OS 的更新中解决这个问题，也就是今天与大家分享的这个版本。这个版本让用户可以用自然语言描述工作流，由 AI 智能体创建驱动该工作流的代码，然后按需、按计划或由事件触发来运行这些智能体。我们不是试图构建适用于整个组织的通用型智能体，而是让每个团队成员都能创建默认隔离的安全应用。 例如，与我合作的一个团队是我们的 IT 帮助台。我们为 Cloudflare 的团队成员提供他们工作所需的硬件和软件支持，从配置、调试到离职交接。我们通过经典工单队列来管理这些工作。 每天早晨，我都想查看我们未处理的工单队列，以及我们服务这些内部客户能力的相关指标。在 Cloudflare OS 之前，我会手动完成这项工作。我们的工单系统有内置仪表盘，但它们相当基础。我会下载 CSV 文件并导入到 Google Sheets 中，在那里创建图表。然后我会手动点开每一个隔夜进来的工单。这既耗时，又在我们记录系统之外产生了冗余数据。 在 Cloudflare OS v1 中，我通过连接到我们工单软件 MCP 服务器的技能文件来运行此流程。虽然更安全（也更少手动操作），但这意味着我每天早晨要消耗数千个 token 来重新生成一份内容基本相同的报告。同时，我也在浪费 token 来处理隔夜工单的分类和草拟回复。 Cloudflare OS v2 为我以及任何有类似问题需要解决的人处理了这一切。我描述我想查看的图表，它便使用一个 AI 智能体来编写驱动这些图表的代码，同时通过一个我们称之为“守门人”的服务与数据集建立安全连接。这个守门人处理我的智能体对数据集发出的一致查询，在无需任何 API 密钥管理的情况下，为应用缩小上下文范围。 当我确实需要 AI 推理时，我可以将其嵌入到应用程序中。我构建了用 AI 为收到的工单起草回复的选项。我可以审阅这些回复并发送出去。这一切都在一个安全的工作区内完成，无需我创建和管理任何集成或部署管道。 当我与他人分享我构建的智能体时，他们会通过相同的守门人，使用自己的权限对该智能体进行身份验证，因此我们不会跨越数据边界。而且，每次我加载初始报告时，消耗的 token 恰好为零。 派出先锋，分享你的成功 Cloudflare OS 为我们提供了所需的平台，但我们仍然需要赋能我们的团队。为此，我们没有聘请专门的 AI 团队。相反，我们在各个岗位中找到了早期采用者，并将他们培养成能够帮助同事使用这个新平台的先锋。我们联系了伦敦的一位销售负责人、德克萨斯州的一位解决方案工程师、葡萄牙的一位投资者关系负责人、日本的一位业务拓展团队成员、美国的一位销售运营负责人等，并请他们与各自的团队合作，重新思考他们的工作方式。 我们在将实习生嵌入成熟团队方面也取得了成功。我们宣布了今年引入 1，111 名实习生的目标，许多加入我们的实习生正在各部门工作，他们的目标很简单：“通过为团队配备我们的 AI 工具，让这个团队成为全明星团队。” 结果持续令我们惊叹。每周都有数千名 Cloudflare 团队成员使用该平台，每日活跃用户数在每个工作日都在增长。仅在过去一个月，我们估计销售团队成员在原本需要手动完成的任务（如区域规划和提案撰写）上节省了超过 10,000 小时。在这 30 天里，用户创建了超过 4,000 个应用和工具来解决具体挑战。 接下来是什么？ 我们远未完成，但每一天我都能看到更多进展，因为我们专注于重新思考如何解决工作中的问题。昨晚有人给我发了一个 Cloudflare OS 报告的链接，它帮助我们诊断采购瓶颈，而这项工作以前需要数天的手动电子表格排查。今天早上，IT 团队的一位成员与坐在里斯本办公室旁边的财务团队成员分享了一个基于该平台构建的追踪笔记本电脑更换的工作流智能体。这些微小的自动化和知识共享行为正在不断累积。 正如我们致力于赋予 Cloudflare 每一位员工超能力一样，我们认为 Cloudflare 之外的每个团队也应该拥有这些能力。今天我们很高兴与大家分享 Cloudflare OS，并期待它随着我们共同学习而快速持续演进。如果有人想坐下来交流内部 AI 部署中哪些有效、哪些无效的经验，请告诉我们。我很乐意进行人与人之间的交流。