Cloudflare OS：我们如何重新思考在 Cloudflare 的工作方式
*Sam Rhea 是 Cloudflare 的首席信息官。*
大约六个月前，我意识到我们遇到了一个问题，当时我们销售团队的一位成员联系我，要求 API 密钥，复数形式。他们利用 AI 创建了一个他们所描述的超级应用程序，这个应用能够改变我们的市场推广团队。他们所需的只是对大约十个 Cloudflare 的数据系统的生产访问权限和一个部署管道的管理员权限。
在 2025 年，Cloudflare 对 AI 的推出采取了相当谨慎的态度。我们部署了一些信息聊天应用程序，并尝试使用 AI 来帮助编写一些标准代码，但我们感觉这项技术尚未准备好改变我们的工作方式。
然而，在去年年末的几天内，更好的模型和更强大的工具改变了这种判断。AI 代理可以*做到*事情，而且能够很好地完成。Cloudflare 的数百名团队成员（无论是技术角色还是非技术角色）在新年的安静时光里，纷纷开始实验那些让构建工作变得前所未有简单的新工具。
那位构建自己超级应用的销售团队成员只是第一位举手要求利用这些工具的人，随后便是一波又一波的员工希望利用这些工具来改变他们的工作方式。我们有责任为他们提供和支持这样的能力。但我们同样有责任保护我们的系统、内部数据和客户数据的安全。
过去几个月，我们一直在构建一个平台，正是为了达到这个目的。我们称之为 Cloudflare OS。我们首先将来自我们开发者和零信任平台的现成组件连接在一起，比如 Cloudflare [Workers](https://www.cloudflare.com/products/workers/) 和 [Access](https://www.cloudflare.com/sase/products/access/)。随着对挑战了解的加深，我们还创建了适合这种新工作方式的定制服务。
正如 Cloudflare 的许多产品一样，我们开始时是为了内部解决一个问题。结果发现，许多企业也面临同样的问题。这就是为什么今天我们兴奋地分享 Cloudflare OS，它汇集了我们内部员工使用 AI 和部署代理所需的能力。你可以在 [这里](http://blog.cloudflare.com/cloudflare-os) 了解更多关于当前可用内容的信息。
在这篇文章中，我想带你走过我们内部旅程，这个旅程导致了这个版本的发布，内容包括我们的成功和失误。这篇文章分为五个部分：我们开始时制定的原则；我们如何进行试点以确定应完成的任务；我们为工程师和非工程师构建的东西；以及我们如何在组织内创造 champions 以推动变革。
在过去的几个月里，我感觉自己是世界上最幸福的首席信息官，因为我支持的团队能够接触到这些新兴技术。今天的目标是与每一个团队分享这个平台及其经验。
## 制定基本规则
我们首先定义了一套原则，来指导我们如何使用 AI。Cloudflare 的首席技术官和我在德克萨斯州奥斯汀的办公室坐下来，开始勾勒出我们如何采用 AI 的必要条件。我们邀请了来自组织各地的领导对草稿给予反馈。结果形成了以下指南。
**1) 我们使用 AI 来花更多时间与客户沟通并构建技术以解决他们的问题。**
我们并不希望仅仅出于使用 AI 的目的去使用 AI。我们敦促团队首先定义他们的“工作要实现的目标”，即那些可以改善我们为客户服务的痛点、瓶颈或错失的机会。然后我们寻找合适的工具。
**2) 每个人都应该拥有超能力。**
AI 在编写代码方面非常出色。因此，首批能够采取行动的 AI 工具的接口主要是开发人员已经在使用的工具：命令行、代码编辑器、终端、Git 仓库。
这些工具的形式可能会留下我们团队的大部分成员。而虽然我们拥有一支技术娴熟且好奇的员工队伍，但并不是每位成员都需要每天都使用开发者工具。我们希望员工能够带来他们的专业知识，而我们将为他们提供一个直观的平台，以重新思考我们的工作方式。
**3) 输出由人负责。**
我们将 AI 视为工具和工具的创造者，而不是团队成员。我们期望人们对依赖 AI 输出的质量、测试和工作流程承担责任。
这一原则也适用于代理的部署。发布代理的用户和团队对这些代理的输出负责。某个人离开了？他们的经理就像继承其他工作流程那样需要继承代理的责任。
**4) 组织的上下文比模型更重要。**
我们在 Cloudflare 部署的工作流和代理必须了解 Cloudflare。本组织的技术投入时间必须与投入在策划的权威上下文层的时间相匹配。
**5) 当使用 AI 时，您不应该对数据系统拥有更多权限。**
Cloudflare 每个人都可以根据合理的理由对底层数据有范围有限的查看权限。我们使用自己的产品，通过设备、角色和地区等因素划分数据访问权限。我们还配置和监控第三方应用程序内部的控制。
当我管理与同一数据交互的 AI 代理时，这些控制也需要适用。我在使用 AI 工具时不应该拥有“更多”数据访问权限，我的 AI 代理仅应访问它们所需的确切数据，不能更多。如果我发布一个代理并与他人共享，则该代理提供给他们的访问权限应反映他们的权限，而不是我的。
## 以用户为中心
有了这些规则，我们就开始着手了。我们进行了两个平行的计划：第一个针对我们的工程团队，第二个针对所有其他类型的工作。
### 给工程师提供护航
AI 工具加速了我们工程师本来就能完成的工作——比我们的审核过程更快。现在，Cloudflare 的任何人都可以迅速编写出糟糕的代码，而 AI 则加速了这一过程。我们需要更好的保护。
因此，我们为工程构建了一个上下文层。我们称之为 Cloudflare 工程法典。法典是一个权威指南。我们的法典明确了我们遵循的原则和实践。政策告诉你不能做什么，而法典则告诉你应该做什么。它是有偏见的设计。我们代码库的每个部分都有域负责人，负责确保在该区域内实现良好的标准。
我们在软件开发生命周期中展示这个上下文层。代理会使用该法典帮助工程师规划工作。一个代理会根据法典要求审查每个合并请求。另一个在实施开始前审查技术设计。第三个审查事件报告。在过去的四个月中，这些代理标记了近 25 万个潜在问题，并阻止了 16,000 次合并，它们在代码行编写之前就捕获了近 600 个设计中的架构问题。
你可以在 [Timo 的博客](http://blog.cloudflare.com/engineering-standards-enforcement) 上详细阅读我们是如何构建这个代码审核工作流程的。现在我们正转向为工程师提供工具，以定义评估其代理工作成果的循环。
### 为每个人提供一个神奇的电子邮件别名
我们犯的一个早期错误是给工程之外的每个人提供相同的工具，但稍微友好的用户界面。工程师可以将代码仓库克隆到他们的笔记本电脑上，添加一个上下文文件如 [AGENTS.md](http://AGENTS.md)，并将它们的工具指向工作。然而，市场上的工具对于其他类型的知识工作来说映射都很糟糕，用户在其中创建一次性输出来进行涉及几十个数据系统的项目。
如果你给每个人一个擅长编写代码的工作区，结果将会是你所需代码的洪流。结果，出现了一大堆寻找解决方案的 vibe 编码应用。因此，我们从后向前工作。
我们告诉 Cloudflare 的每一个人，他们可以将不想做的工作发送到一个“魔法 AI 电子邮件机器人”，它将回应他们所需的输出。在幕后，一小组人员利用 AI 工具来进行这些工作，维护这个电子邮件别名。
人们不太愿意将他们的 vibe 编码想法发送给他们认为是自动系统的邮件，但很乐意发送自己不想做的工作。通过数百次甚至成千上万次管理电子邮件别名的会话，我们识别出团队成员希望自动化的日常工作。
我们对此进行了手动分级，随着时间的推移观察到一定的模式。我们创建了技能和上下文文件，绘制出数据连接，定义用户所需的输出类型。有了这些，我们就可以自动化部分对此电子邮件别名的回复。
我们非常希望停止维护这个服务。这是件痛苦的事情。长期目标是将我们整理的这些材料创建技能来解决这些问题，以便我们的用户能够自己解决问题。手动完成这个电子邮件别名的工作持续到我们觉得已经捕获足够的 Cloudflare 上的“待完成的工作”，以启动自动化。现在我们只需一个平台，让他们能够轻松、安全地运行这些工作流程。
## 为团队成员提供一个解决问题的平台
这个平台的第一个版本，我们称之为 Cloudflare OS，由一个简单的运行在 Cloudflare 基础设施上的工具组成。用户可以在浏览器中访问它，一经通过 [Cloudflare Zero Trust](https://www.cloudflare.com/products/access/) 身份验证，他们便可以运行我们在魔法邮件阶段开始收集的技能文件和工作流程。
所有这一切都在他们的浏览器内部发生，无需本地配置。用户可以打开他们的笔记本电脑，立即开始工作。我们从新加入的销售团队成员那里听到，他们在开始后几天就能自动化工作，而在他们的前一个工作场所，这些工作可能需要几周的时间才能完成。
用户还可以在完成工作时关闭电脑，去喝咖啡或上卫生间。再也不需要在办公室里打开笔记本电脑走来走去。
我们认为基于云的工作空间不仅对用户有益。一个短暂的基于云的环境只能访问用户在会话中引入的数据，而不是在你使用本地工具时随便访问的一切。我们的安全团队对环境进行审计可见性和网络控制，包括过滤其可以连接的互联网位置的能力。
当用户需要完成工作时，他们开始运行那些由我们识别的跨部门的常见工作流定义的技能文件。公司在魔法邮件阶段积累的上下文和技能，可以通过单击一下打开。
右侧的面板会渲染给定技能文件的输出，例如技术架构文档或幻灯片。用户可以与队友分享这些输出。
我们通过连接 [Model Context Protocol (MCP) 门户](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/) 为 Cloudflare OS 提供了对数据的访问。这项标准定义了如何将你的 AI 工具连接到数据系统，能够告诉 AI 工具可用的数据和操作。遵循关于权限的规则，用户会话在 Cloudflare OS 的访问范围仅限于他们在各个数据系统中的现有权限集。
在大多数情况下，即使数据系统提供原生版本，我们也会为每个数据系统构建和部署自己的 MCP 服务器。通过自己构建，我们可以为角色或地区添加额外的控制层，例如速率限制。Cloudflare Workers 为我们提供了一个简单的构建位置，并且作为无服务器平台，它的长期维护负担几乎为零。
当 Cloudflare OS 使用 AI 推理时，我们通过 [AI Gateway](https://www.cloudflare.com/products/ai-gateway/) 进行路由。这使我们能够过滤、记录和审计用户与这些 AI 系统之间的所有交互。例如，我们可以重用来自 [Data Loss Prevention](https://www.cloudflare.com/products/dlp/) 的规则，阻止某些数据集发送给提供者。
AI Gateway 还使我们能够 [控制模型使用](https://blog.cloudflare.com/ai-gateway-spend-limits/)。并不是每个用户都需要访问最新前沿模型的最大思维模式。我们也不希望团队成员花费 20 美元每小时总结他们的电子邮件收件箱。我们可以使用 AI Gateway 按角色限制模型，或将使用案例（尤其是自主性更强的，例如计划技能文件运行）引导到更有效的模型。
## 现在通过代理让每个人都更加可预测
Cloudflare OS 为我们的团队提供了一个 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 草拟对到达工单的回复的选项。我可以审核回复并发送。所有这一切都在一个安全的工作区内，无需我创建和管理任何集成或部署管道。
当我与他人共享我构建的代理时，他们会通过相同的 gatekeeper 在各自的权限下对代理进行身份验证，因此我们不会跨越数据边界。并且每当我加载初始报告时，我消耗的令牌为零。
## 派出 champions 并分享你的胜利
Cloudflare OS 为我们提供了必要的平台，但我们仍然需要赋能我们的团队。为此，我们没有聘请专门的 AI 团队。相反，我们在各个角色中发现早期采用者，并将他们变成 champions，帮助他们的同事使用这个新平台。我们邀请了来自伦敦的一名销售领导、德克萨斯州的一名解决方案工程师、葡萄牙的一名投资者关系领导、日本的一名业务开发团队成员以及美国的销售运营领导等人，让他们与团队合作重新思考工作。
我们还成功地将实习生嵌入到已建立的团队中。我们宣布今年的目标是招募 1,111 名实习生，其中许多人在部门工作，目标很简单：“让这个团队成为明星，装备他们以我们的 AI 工具。”
结果让我们很惊讶。每周有成千上万的 Cloudflare 团队成员使用这个平台，每天的活跃用户数每天都有增长。在上个月，我们估计我们的销售团队成员在以前手动任务（如区域规划和提案创建）上节省了超过 10,000 小时的时间。在过去的 30 天中，用户创建了超过 4,000 个应用程序和工具，以解决特定挑战。
## 下一步是什么？
我们还远未完成，但每天我都看到一些进展，因为我们过于专注于重新思考我们需要做的工作来解决问题。昨晚，有人给我发来一份在 Cloudflare OS 中的报告链接，帮助我们诊断一个采购瓶颈，这在以前可能需要几天的手动电子表格爬行。今天早上，IT 团队的一名成员向坐在里斯本办公室附近的财务团队人员分享了基于该平台构建的用于跟踪笔记本电脑更换的工作流代理。小规模的自动化和知识共享正在积累。
就像我们致力于赋予 Cloudflare 的每一个人超能力一样，我们认为 Cloudflare 外部的每一支团队也应该拥有这一点。我们很高兴今天能与您分享 Cloudflare OS，随着我们共同学习，我们期待它继续快速发展。如果有人想坐下来交换关于内部 AI 推出成功与失败的经验，就 [告诉我们](http://www.cloudflare.com/resource/cloudflare-os-interest-landing-page/)。我很乐意交流。
---
原文链接：[点击查看](https://blog.cloudflare.com/how-we-use-ai-with-cloudflare-os/)
大约六个月前，我意识到我们遇到了一个问题，当时我们销售团队的一位成员联系我，要求 API 密钥，复数形式。他们利用 AI 创建了一个他们所描述的超级应用程序，这个应用能够改变我们的市场推广团队。他们所需的只是对大约十个 Cloudflare 的数据系统的生产访问权限和一个部署管道的管理员权限。
在 2025 年，Cloudflare 对 AI 的推出采取了相当谨慎的态度。我们部署了一些信息聊天应用程序，并尝试使用 AI 来帮助编写一些标准代码，但我们感觉这项技术尚未准备好改变我们的工作方式。
然而，在去年年末的几天内，更好的模型和更强大的工具改变了这种判断。AI 代理可以*做到*事情，而且能够很好地完成。Cloudflare 的数百名团队成员（无论是技术角色还是非技术角色）在新年的安静时光里，纷纷开始实验那些让构建工作变得前所未有简单的新工具。
那位构建自己超级应用的销售团队成员只是第一位举手要求利用这些工具的人，随后便是一波又一波的员工希望利用这些工具来改变他们的工作方式。我们有责任为他们提供和支持这样的能力。但我们同样有责任保护我们的系统、内部数据和客户数据的安全。
过去几个月，我们一直在构建一个平台，正是为了达到这个目的。我们称之为 Cloudflare OS。我们首先将来自我们开发者和零信任平台的现成组件连接在一起，比如 Cloudflare [Workers](https://www.cloudflare.com/products/workers/) 和 [Access](https://www.cloudflare.com/sase/products/access/)。随着对挑战了解的加深，我们还创建了适合这种新工作方式的定制服务。
正如 Cloudflare 的许多产品一样，我们开始时是为了内部解决一个问题。结果发现，许多企业也面临同样的问题。这就是为什么今天我们兴奋地分享 Cloudflare OS，它汇集了我们内部员工使用 AI 和部署代理所需的能力。你可以在 [这里](http://blog.cloudflare.com/cloudflare-os) 了解更多关于当前可用内容的信息。
在这篇文章中，我想带你走过我们内部旅程，这个旅程导致了这个版本的发布，内容包括我们的成功和失误。这篇文章分为五个部分：我们开始时制定的原则；我们如何进行试点以确定应完成的任务；我们为工程师和非工程师构建的东西；以及我们如何在组织内创造 champions 以推动变革。
在过去的几个月里，我感觉自己是世界上最幸福的首席信息官，因为我支持的团队能够接触到这些新兴技术。今天的目标是与每一个团队分享这个平台及其经验。
## 制定基本规则
我们首先定义了一套原则，来指导我们如何使用 AI。Cloudflare 的首席技术官和我在德克萨斯州奥斯汀的办公室坐下来，开始勾勒出我们如何采用 AI 的必要条件。我们邀请了来自组织各地的领导对草稿给予反馈。结果形成了以下指南。
**1) 我们使用 AI 来花更多时间与客户沟通并构建技术以解决他们的问题。**
我们并不希望仅仅出于使用 AI 的目的去使用 AI。我们敦促团队首先定义他们的“工作要实现的目标”，即那些可以改善我们为客户服务的痛点、瓶颈或错失的机会。然后我们寻找合适的工具。
**2) 每个人都应该拥有超能力。**
AI 在编写代码方面非常出色。因此，首批能够采取行动的 AI 工具的接口主要是开发人员已经在使用的工具：命令行、代码编辑器、终端、Git 仓库。
这些工具的形式可能会留下我们团队的大部分成员。而虽然我们拥有一支技术娴熟且好奇的员工队伍，但并不是每位成员都需要每天都使用开发者工具。我们希望员工能够带来他们的专业知识，而我们将为他们提供一个直观的平台，以重新思考我们的工作方式。
**3) 输出由人负责。**
我们将 AI 视为工具和工具的创造者，而不是团队成员。我们期望人们对依赖 AI 输出的质量、测试和工作流程承担责任。
这一原则也适用于代理的部署。发布代理的用户和团队对这些代理的输出负责。某个人离开了？他们的经理就像继承其他工作流程那样需要继承代理的责任。
**4) 组织的上下文比模型更重要。**
我们在 Cloudflare 部署的工作流和代理必须了解 Cloudflare。本组织的技术投入时间必须与投入在策划的权威上下文层的时间相匹配。
**5) 当使用 AI 时，您不应该对数据系统拥有更多权限。**
Cloudflare 每个人都可以根据合理的理由对底层数据有范围有限的查看权限。我们使用自己的产品，通过设备、角色和地区等因素划分数据访问权限。我们还配置和监控第三方应用程序内部的控制。
当我管理与同一数据交互的 AI 代理时，这些控制也需要适用。我在使用 AI 工具时不应该拥有“更多”数据访问权限，我的 AI 代理仅应访问它们所需的确切数据，不能更多。如果我发布一个代理并与他人共享，则该代理提供给他们的访问权限应反映他们的权限，而不是我的。
## 以用户为中心
有了这些规则，我们就开始着手了。我们进行了两个平行的计划：第一个针对我们的工程团队，第二个针对所有其他类型的工作。
### 给工程师提供护航
AI 工具加速了我们工程师本来就能完成的工作——比我们的审核过程更快。现在，Cloudflare 的任何人都可以迅速编写出糟糕的代码，而 AI 则加速了这一过程。我们需要更好的保护。
因此，我们为工程构建了一个上下文层。我们称之为 Cloudflare 工程法典。法典是一个权威指南。我们的法典明确了我们遵循的原则和实践。政策告诉你不能做什么，而法典则告诉你应该做什么。它是有偏见的设计。我们代码库的每个部分都有域负责人，负责确保在该区域内实现良好的标准。
我们在软件开发生命周期中展示这个上下文层。代理会使用该法典帮助工程师规划工作。一个代理会根据法典要求审查每个合并请求。另一个在实施开始前审查技术设计。第三个审查事件报告。在过去的四个月中，这些代理标记了近 25 万个潜在问题，并阻止了 16,000 次合并，它们在代码行编写之前就捕获了近 600 个设计中的架构问题。
你可以在 [Timo 的博客](http://blog.cloudflare.com/engineering-standards-enforcement) 上详细阅读我们是如何构建这个代码审核工作流程的。现在我们正转向为工程师提供工具，以定义评估其代理工作成果的循环。
### 为每个人提供一个神奇的电子邮件别名
我们犯的一个早期错误是给工程之外的每个人提供相同的工具，但稍微友好的用户界面。工程师可以将代码仓库克隆到他们的笔记本电脑上，添加一个上下文文件如 [AGENTS.md](http://AGENTS.md)，并将它们的工具指向工作。然而，市场上的工具对于其他类型的知识工作来说映射都很糟糕，用户在其中创建一次性输出来进行涉及几十个数据系统的项目。
如果你给每个人一个擅长编写代码的工作区，结果将会是你所需代码的洪流。结果，出现了一大堆寻找解决方案的 vibe 编码应用。因此，我们从后向前工作。
我们告诉 Cloudflare 的每一个人，他们可以将不想做的工作发送到一个“魔法 AI 电子邮件机器人”，它将回应他们所需的输出。在幕后，一小组人员利用 AI 工具来进行这些工作，维护这个电子邮件别名。
人们不太愿意将他们的 vibe 编码想法发送给他们认为是自动系统的邮件，但很乐意发送自己不想做的工作。通过数百次甚至成千上万次管理电子邮件别名的会话，我们识别出团队成员希望自动化的日常工作。
我们对此进行了手动分级，随着时间的推移观察到一定的模式。我们创建了技能和上下文文件，绘制出数据连接，定义用户所需的输出类型。有了这些，我们就可以自动化部分对此电子邮件别名的回复。
我们非常希望停止维护这个服务。这是件痛苦的事情。长期目标是将我们整理的这些材料创建技能来解决这些问题，以便我们的用户能够自己解决问题。手动完成这个电子邮件别名的工作持续到我们觉得已经捕获足够的 Cloudflare 上的“待完成的工作”，以启动自动化。现在我们只需一个平台，让他们能够轻松、安全地运行这些工作流程。
## 为团队成员提供一个解决问题的平台
这个平台的第一个版本，我们称之为 Cloudflare OS，由一个简单的运行在 Cloudflare 基础设施上的工具组成。用户可以在浏览器中访问它，一经通过 [Cloudflare Zero Trust](https://www.cloudflare.com/products/access/) 身份验证，他们便可以运行我们在魔法邮件阶段开始收集的技能文件和工作流程。
所有这一切都在他们的浏览器内部发生，无需本地配置。用户可以打开他们的笔记本电脑，立即开始工作。我们从新加入的销售团队成员那里听到，他们在开始后几天就能自动化工作，而在他们的前一个工作场所，这些工作可能需要几周的时间才能完成。
用户还可以在完成工作时关闭电脑，去喝咖啡或上卫生间。再也不需要在办公室里打开笔记本电脑走来走去。
我们认为基于云的工作空间不仅对用户有益。一个短暂的基于云的环境只能访问用户在会话中引入的数据，而不是在你使用本地工具时随便访问的一切。我们的安全团队对环境进行审计可见性和网络控制，包括过滤其可以连接的互联网位置的能力。
当用户需要完成工作时，他们开始运行那些由我们识别的跨部门的常见工作流定义的技能文件。公司在魔法邮件阶段积累的上下文和技能，可以通过单击一下打开。
右侧的面板会渲染给定技能文件的输出，例如技术架构文档或幻灯片。用户可以与队友分享这些输出。
我们通过连接 [Model Context Protocol (MCP) 门户](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/) 为 Cloudflare OS 提供了对数据的访问。这项标准定义了如何将你的 AI 工具连接到数据系统，能够告诉 AI 工具可用的数据和操作。遵循关于权限的规则，用户会话在 Cloudflare OS 的访问范围仅限于他们在各个数据系统中的现有权限集。
在大多数情况下，即使数据系统提供原生版本，我们也会为每个数据系统构建和部署自己的 MCP 服务器。通过自己构建，我们可以为角色或地区添加额外的控制层，例如速率限制。Cloudflare Workers 为我们提供了一个简单的构建位置，并且作为无服务器平台，它的长期维护负担几乎为零。
当 Cloudflare OS 使用 AI 推理时，我们通过 [AI Gateway](https://www.cloudflare.com/products/ai-gateway/) 进行路由。这使我们能够过滤、记录和审计用户与这些 AI 系统之间的所有交互。例如，我们可以重用来自 [Data Loss Prevention](https://www.cloudflare.com/products/dlp/) 的规则，阻止某些数据集发送给提供者。
AI Gateway 还使我们能够 [控制模型使用](https://blog.cloudflare.com/ai-gateway-spend-limits/)。并不是每个用户都需要访问最新前沿模型的最大思维模式。我们也不希望团队成员花费 20 美元每小时总结他们的电子邮件收件箱。我们可以使用 AI Gateway 按角色限制模型，或将使用案例（尤其是自主性更强的，例如计划技能文件运行）引导到更有效的模型。
## 现在通过代理让每个人都更加可预测
Cloudflare OS 为我们的团队提供了一个 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 草拟对到达工单的回复的选项。我可以审核回复并发送。所有这一切都在一个安全的工作区内，无需我创建和管理任何集成或部署管道。
当我与他人共享我构建的代理时，他们会通过相同的 gatekeeper 在各自的权限下对代理进行身份验证，因此我们不会跨越数据边界。并且每当我加载初始报告时，我消耗的令牌为零。
## 派出 champions 并分享你的胜利
Cloudflare OS 为我们提供了必要的平台，但我们仍然需要赋能我们的团队。为此，我们没有聘请专门的 AI 团队。相反，我们在各个角色中发现早期采用者，并将他们变成 champions，帮助他们的同事使用这个新平台。我们邀请了来自伦敦的一名销售领导、德克萨斯州的一名解决方案工程师、葡萄牙的一名投资者关系领导、日本的一名业务开发团队成员以及美国的销售运营领导等人，让他们与团队合作重新思考工作。
我们还成功地将实习生嵌入到已建立的团队中。我们宣布今年的目标是招募 1,111 名实习生，其中许多人在部门工作，目标很简单：“让这个团队成为明星，装备他们以我们的 AI 工具。”
结果让我们很惊讶。每周有成千上万的 Cloudflare 团队成员使用这个平台，每天的活跃用户数每天都有增长。在上个月，我们估计我们的销售团队成员在以前手动任务（如区域规划和提案创建）上节省了超过 10,000 小时的时间。在过去的 30 天中，用户创建了超过 4,000 个应用程序和工具，以解决特定挑战。
## 下一步是什么？
我们还远未完成，但每天我都看到一些进展，因为我们过于专注于重新思考我们需要做的工作来解决问题。昨晚，有人给我发来一份在 Cloudflare OS 中的报告链接，帮助我们诊断一个采购瓶颈，这在以前可能需要几天的手动电子表格爬行。今天早上，IT 团队的一名成员向坐在里斯本办公室附近的财务团队人员分享了基于该平台构建的用于跟踪笔记本电脑更换的工作流代理。小规模的自动化和知识共享正在积累。
就像我们致力于赋予 Cloudflare 的每一个人超能力一样，我们认为 Cloudflare 外部的每一支团队也应该拥有这一点。我们很高兴今天能与您分享 Cloudflare OS，随着我们共同学习，我们期待它继续快速发展。如果有人想坐下来交换关于内部 AI 推出成功与失败的经验，就 [告诉我们](http://www.cloudflare.com/resource/cloudflare-os-interest-landing-page/)。我很乐意交流。
---
原文链接：[点击查看](https://blog.cloudflare.com/how-we-use-ai-with-cloudflare-os/)
评论
暂无评论。