blog.cloudflare.com/how-we-use-ai-with-cloudflare-os · 2026-08-05 · Sam Rhea（Cloudflare CIO）

Cloudflare OS 图解：给全员「超能力」的 agent 平台

当 AI agent 突然变得能干活，公司需要的不是给每人发更好的工具，而是一个平台：权限不放大、上下文有来源、模型有路由、人人能造 agent。Cloudflare 用半年时间把「魔法邮箱」试出来的工作流，变成了一台全员可用的 agent 平台。

Agents Week · 2026-08定位：企业内部 AI 落地的方法论 + 平台架构实例

一、为什么必须建一个平台

故事的起点是 CIO Sam Rhea 收到一个销售同事的请求：开口就要一批 API keys。他们用 AI 造了个想改造 go-to-market 的 SuperApp，需要十几个系统 of record 的生产访问权 + 部署管道的 admin 权限。Cloudflare 2025 年对 AI 一直谨慎（聊天应用 + 写样板代码），但 2025 年底「更好的模型 + 更强大的 harness」让 AI agent 第一次真正能干活，几百人开始自发尝试。公司既想赋能，又必须守住系统、内部数据和客户数据的安全。答案：不是分发工具，而是建平台。

动手之前先定规则。CTO 与 CIO 在奥斯汀办公室起草，请全组织领导评审，最后变成五条原则：

01 先定 JTBD 为顾客解决问题 先找痛点再找工具 不为 AI 而 AI 02 人人超能力 不只在命令行 非工程师也能 用领域知识干活 03 人拥有输出 AI 是工具/工具maker 不是团队成员 agent 责任随人继承 04 上下文>模型 组织知识要成体系 curated canonical context layer 05 绝不放大权限 agent 只用我 既有视图内的数据 分享 agent = 对方用自己的权限
五条原则：先定义要解决的问题（JTBD），再让平台服务于人——安全边界（05）是后面一切架构的前提。

二、演进：从魔法邮箱到 agent 平台

工程师之外的人群怎么找到「要自动化什么」？Cloudflare 没有先建平台，而是先做一个反向试点：告诉大家「不想干的活发给魔法 AI 邮箱」。背后其实是一小撮人用 AI 工具人工值班。人们不愿意把 vibe coding 点子发给"自动化系统"，却很愿意把不想干的活丢进去——几百到几千次会话之后，常见的「jobs to be done」浮现出来，再沉淀成 skill 文件、context 文件和数据连接。

2025 保守期 聊天应用 + 样板代码 「技术还没准备好」 年底能力跃迁 模型/harness 质变 几百人新年自发尝试 魔法邮箱 人工值班 + AI 工具 沉淀 skills / JTBD OS v1 浏览器 harness MCP Portal + AI GW OS v2（今天） 人人造 agent 确定性优先 · gatekeeper 先试再建 需求爆炸 JTBD 积累 安全跑 skill 安全造 agent
演进的关键不是「先有平台再找需求」，而是「先人工干出需求清单，再让平台接管」。
⚠ 一个早期错误：直接把 harness 发给所有人

给非工程师发"友好版"工程工具，结果是一堆没有问题的 vibe coded apps。市面上的 harness 擅长写代码，对「一次性输出 + 涉及几十个系统 of record」的知识工作映射很差。所以反向操作：先收集「不想干的活」，再据此做平台。

三、v2 架构：人人能造 agent，权限不放大

v1 是「浏览器里的 skill runner」：云端 ephemeral 容器 harness，Zero Trust 认证，只接触用户引入会话的数据，Security 可审计可过滤网络。但每个 skill 运行都是一次烧 token 的推理会话——而大部分工作其实是确定性流程 + 少量推理。v2 的答案是：用户自然语言描述工作流，AI agent 写出代码，然后作为隔离应用跑起来——加载日常报告 0 token，需要时才把推理嵌进应用（如草拟工单回复，人审后发送）。

员工（浏览器） 描述工作流 / 运行 agent 无需本地配置 Zero Trust 认证 Cloudflare Access · 设备/角色/地区 会话权限 = 用户既有 scoped 视图 云端 workspace（v2） ephemeral 容器 harness skills + 用户自建 agent on demand / schedule / event 隔离应用 · 无部署管道 MCP Portal 自建 MCP server （跑在 Workers） rate limit 按角色/地区 维护成本≈0 系统 of record Salesforce · Jira · Gmail ticketing 等 数据只在用户权限内 Gatekeeper（v2） agent 与数据的唯一通道 一致查询 · scoping context 无需 API key 管理 分享 = 对方权限重新认证 AI Gateway 所有推理统一出口 过滤 · 日志 · 审计 DLP 阻止敏感数据出网 按角色 gate 模型 自治场景导向经济模型 （模型市场：Claude / GLM / DeepSeek / Qwen / GPT…） 分享 agent 同事用自己的权限 经同一 gatekeeper 认证 不跨数据边界
架构的骨架：权限在左边不放大（gatekeeper 按用户身份取数），模型在右边不失控（AI Gateway 统一路由），中间是人人可用的 workspace。
原文架构图：AI Inference → AI Gateway → AI Agent Workspace → Deployed Apps & Agents；Content Library 与 Systems of Record 经 MCP Portal 连接
原文图：Cloudflare OS 架构流程——内容库（curated content + skills）与系统 of record 汇入 agent workspace。

四、v1 vs v2：从「烧 token 的 skill」到「确定性的 agent」

CIO 自己的例子：IT helpdesk 每天清晨的工单队列报告。手工做法是下载 CSV、导入 Google Sheets 画图、逐个点开隔夜工单；v1 用 skill 跑，安全多了但每天烧几千 token 重建同一份报告；v2 一次描述需求，agent 写的代码 + gatekeeper 数据连接常驻，加载报告 0 token，需要时才把推理嵌进去。

维度OS v1OS v2
运行单元skill 文件（每次推理会话）agent 生成的确定性应用
日常成本每次运行烧几千 token加载初始报告 0 token
创建方式平台预置 skill自然语言描述 → AI 写代码
触发手动运行on demand / schedule / event
数据连接MCP servergatekeeper：一致查询 + scoping，无 API key 管理
隔离会话级应用级，isolated by default
分享共享输出共享 agent，对方用自己的权限认证
核心哲学：AI 不需要总是工具，更需要是工具maker

「我们不需要 AI 每次都是工具，而是需要 AI 成为工具maker」——用一次推理造出长期运行、确定性优先的应用，把烧 token 的重复劳动变成一次性的构建成本。这与「人拥有输出」（agent 责任随人继承）一起构成平台的治理底座。

五、工程侧与推广：Codex、champions、数字

两条平行线：工程师那边建了 Cloudflare Engineering Codex（opinionated 的权威指南，告诉 agent 应该怎么做，每个代码域有 domain owner），让 agent 贯穿 SDLC；非工程师这边用平台 + 找各角色早期采用者当 champion（伦敦销售、德州解决方案工程师、葡萄牙 IR……），外加实习生带着「用 AI 工具把团队变成 all-star」的目标嵌入团队。

25 万 潜在问题被标记 16,000 次合并被阻止 ~600 个设计缺陷 （Codex agent · 4 个月） 10,000+ h 销售团队近一个月 节省在手工任务上的时间 （territory planning、 proposal 创建） 4,000+ 30 天内用户创建的 应用和工具 数千人每周使用 日活每天增长 1,111 今年实习生目标 嵌入成熟团队 不设专职 AI 团队 靠 champions 辐射
成果不是「用 AI 干了多少活」，而是「少干了多少活 + 造了多少工具」——以及让多少人开始造。
一句话总结

Cloudflare OS 的故事是三层递进：原则先于工具（JTBD、人拥有输出、上下文>模型、权限不放大）→ 试点先于平台（魔法邮箱找出真正的需求）→ 平台让技能成为可运行、可分享、有边界的东西。AI 的规模化问题从来不是模型不够强，而是组织有没有把它安全地交到每个人手里。

来源：How we're rethinking work at Cloudflare with Cloudflare OS · Cloudflare Blog · Sam Rhea（CIO） · 2026-08-05