CloudflareOS开源企业AI工作台

很高兴你来到这里。每周一至周五，我们都会为你送上 TNS 最优质的内容，帮助你及时掌握新闻动态，始终保持最佳状态。

请查看收件箱中的确认邮件，你可以在其中调整偏好设置，甚至加入更多群组。

在你喜欢的社交媒体平台上关注 TNS。

在 LinkedIn 上关注 TNS。

等待第一期 TNS 新闻简报期间，不妨先看看最新的精选报道和热门文章。

Cloudflare 本周推出了开源 AI 工作空间平台 CloudflareOS，承诺为每位员工提供一个安全的工作空间，其中配备 AI 工具，并且能够访问公司内部系统。

传统虚拟桌面基础设施（VDI）服务只是通过远程屏幕交付一套固定不变的应用；现代 VDI 虽然进一步实现了动态应用交付、应用屏蔽和流式传输，但 CloudflareOS 的定位显然远不止于此。它从根本上提供了一种更加动态的工作方式，让员工能够使用公司内部的工具、文档和系统。

Cloudflare 的 CloudflareOS 通过安全连接点开放应用和服务。系统会在授予访问权限之前，对每一位用户、每一次 Agent 请求以及每一个连接点进行验证。

在 AI 时代，每个新的工作会话都从零开始

这项技术所解决的问题，建立在一个基本事实之上：典型的企业 AI 工具对外部世界了解甚多，却几乎不了解某家具体公司如何运作，也不了解其内部系统的结构、审批流程，以及各个团队实际如何完成工作。

这意味着每次开启新的工作会话时，一切都要从零开始，员工不得不反复向 AI 解释它本应已经掌握的上下文。但问题在于：如何安全地开放这种能够感知全新业务上下文的 Agent 访问权限？

Cloudflare 开发者与 AI 副总裁 Rita Koslov 告诉 The New Stack，要支撑现代 Agent 用例，意味着“数据往往会首次大规模离开受控系统”。

Koslov 表示：“过去的情况是，比如人们会在数据仓库中提出分析问题，而组织对数据仓库拥有控制权。如今，员工开始为自己的工具、Agent 等申请 API keys。这带来了一类全新的安全问题，而 Cloudflare OS 正是为了帮助解决这些问题。”

基于 capability 的访问方式胜过直接把原始 API keys 交给 Agent

Cloudflare 构建了一套可称为“基于 capability 的访问机制”，该公司承诺，这种方式优于直接把原始 API keys 交给 Agent。

Koslov 强调：“API keys 会赋予 Agent 对系统的广泛访问权限；基于 capability 的访问方式则允许我们只授权某一项特定资源，然后准确记录 Agent 看到了什么，并验证所有查看其工作成果的人是否同样有权访问源数据。”

Cloudflare OS 让 Agent 能够创建文档、幻灯片、电子表格、工作流、其他 Agent，甚至全新的 full-stack 应用，而且所有内容都可以根据员工的工作需求量身定制。它创建的内容可以持续连接实时数据源，能够被安全地修改和共享，也可以直接供人和 Agent 使用。

“API keys 会赋予 Agent 对系统的广泛访问权限；基于 capability 的访问方式则允许我们只授权某一项特定资源，准确记录 Agent 看到了什么，并验证所有查看其工作成果的人是否同样有权访问源数据。”

至于开发者和系统运维专业人员应该如何看待这项产品，Koslov 认为，如今“真正困难的问题并不是生成一个应用”。真正的挑战在于，如何安全地运行成千上万，乃至数百万个动态生成的应用，同时让每个应用都拥有持久化状态和受控访问权限。

Koslov 表示：“Cloudflare OS 使用 Dynamic Workers，为每个应用提供轻量级的隔离运行时，按需加载其代码；同时使用 Durable Objects Facets，在平台监管下为应用提供隔离的 SQLite 存储。出站网络连接默认处于禁用状态，而 Gatekeepers 只会开放用户明确授权的资源。之所以发明 Dynamic Workers 和 Durable Objects Facets，是因为过去根本无法做到这一点。”

为了完整说明这一点——这同样是 Cloudflare 的原创技术服务——Gatekeeper 是一种针对特定服务的 Worker，位于 Cloudflare OS 与外部服务之间，负责解释和理解该服务的 API、资源，以及可以对这些资源执行的操作。

当一切都出问题时会怎样

Koslov 证实，她很清楚在缺乏管理的环境中，事情会以多么严重的方式失控。

她补充道：“无论是从我们自己的经历，还是与其他公司的交流中，我们都看到了这一点。他们分享过这样的案例：内部数据被复制到 IT 部门根本不知道正在使用的 AI 工具中；AI keys 被嵌入 Agent 构建的应用里；甚至数据在公司内部被分享给了通常无权访问的人，有时还被公开分享出去。”

自行构建一套量身定制的替代方案绝非小项目：一个具备完善安全机制、并且真正与内部系统集成的平台，可能需要数年时间开发，并耗费数百万美元进行维护。在此期间，员工会寻找各种变通方案，IT 部门逐渐无法掌握正在运行哪些 AI 工具、又有哪些人在使用它们；成本则不断累积，最终往往还拿不出多少实际成果。

CloudflareOS 采用了不同的出发点：公司只需以 AI 能够真正执行的形式，一次性沉淀自身的知识、流程和工作方式；从第一天开始，这些知识就会随每位员工的工作空间一同存在。

如何衡量业务“上下文”？

Koslov 证实：“这里所说的已沉淀业务‘上下文’，可以包括公司术语、政策、操作规程、产品文档、技术标准、销售流程、模板，以及处理重复性工作的既定方式。”

CloudflareOS 最初是 Cloudflare 为支持自身员工工作而构建的平台。Cloudflare 各个团队的数千名员工每天都在使用它开展研究、创建连接实时数据的文档、自动执行重复性任务，以及为日常工作构建可直接运行的应用。

如今，同一个平台已经以开源软件的形式向所有组织开放。由于它是开源的，并且运行在公司自己的 Cloudflare 账户中，因此组织拥有在该平台上构建的内容。

平台本身可以配合任何 AI model 使用，并能对成本进行控制。通过 Cloudflare AI Gateway，组织可以使用任意 AI model 提供商，因此不会被锁定在单一供应商上。管理员能够准确查看支出情况，并按个人、团队或应用进行拆分。他们还可以设置支出预算和速率限制，或者在不需要顶级 model 的情况下，将常规任务路由到规模更小、价格更低的 model。

按 token 为平台计价，完全用错了衡量尺度

企业 AI 架构师、Besk Tech 创始人 Vladimir Beskorovainyi 对这一更宏大的发展趋势持谨慎乐观态度。他告诉 The New Stack，传统上，这个行业一直按照 token 为此类平台计价，但在他看来，“这完全用错了衡量尺度”。

Beskorovainyi 表示：“以 Cloudflare OS 为例，一家公司在这里真正购买的，是把由 AI 驱动的业务流程究竟如何运作写清楚的责任，并且随着底层业务不断变化，持续确保这份描述符合实际。Model 才是商品化的部分。真正需要投入真金白银的是经过精心整理的上下文，但没有人会为这样一个事实编列预算：上下文从写下来的那一天起就开始失效，而这恰恰决定了整套方案在真正进入生产环境后能否存活下来。”

“按个人、团队和应用拆分成本，这是我第一次看到供应商把支出当作工程信号，而不是一张账单；把日常工作交给更小的 model，则是顺理成章的下一步，但大多数企业至今仍未能做到。

Beskorovainyi 坚称，在这场竞争中胜出的组织，“未必是运行最佳 model 的组织”；真正的赢家会是那些早在 Agent 提问之前，就“已经能够用书面形式回答自己的审批流程究竟是什么”的组织。

Beskorovainyi 建议：“按个人、团队和应用拆分成本，这是我第一次看到供应商把支出当作工程信号，而不是一张账单；把日常工作交给更小的 model，则是顺理成章的下一步，但大多数企业至今仍未能做到。”

拥有自己的上下文，不等于上下文本身足够好

他进一步澄清了自己的观点，并解释说，这里的限定条件在于：“拥有自己的上下文，不等于你的上下文本身足够好。”开源工具、社区连接以及组织自己的账户，只能解决由谁持有上下文文件的问题。

Beskorovainyi 补充道：“但这些都无法告诉我们，上下文文件中记录并留下日志的内容，在本季度是否依然符合实际。这项工作将永久由客户承担。我预计，大多数此类部署最终都会在这里瓦解，而不是因为 Cloudflare 构建的任何东西出了问题。”

Cloudflare 联合创始人兼 CEO Matthew Prince 曾表示，他的团队之所以构建 Cloudflare OS，“是因为没有其他产品能满足我们的需求”。因此，如今任何公司都可以直接从 Cloudflare 内部软件工程团队耗费多年才抵达的位置起步。

它显而易见的吸引力，归根结底应该来自 Cloudflare OS 的动态特性，以及它能够在经过定制设计、能够感知业务上下文的层面上配合并应用 AI 工具，同时默认采用 zero trust。该平台可以把任何输出转化为一个可运行的应用，并为其配备独立的隔离数据库、实时能力和访问控制——再说一次，这可不是传统虚拟桌面，对吧？

无需开发者（暂时）

Cloudflare 给出的结论是，员工可以直接使用 Cloudflare OS 上的任何应用，也可以根据自己的需求加以调整，从而真正做到“无需开发者”——至少在下一个集成任务需要有人承担之前，或者下一件大事出现之前，又或者两者同时发生之前，确实如此。