一个 Worker 就能跑

Kukuroo 的核心是一个自托管的 Web Push 服务，部署在一个 Cloudflare Worker 中。它只需一个 Worker 加一个 KV 命名空间，没有需要常驻的服务器，也无需续期或凌晨三点重启。

更重要的是「中间没有公司」：密钥留在你自己的 Worker 里，推送内容以加密形式发往设备，任何第三方后台都看不到你的提醒。

iOS 原生渲染，无需上架

从 iOS 18.4 起，系统已原生支持声明式 Web Push（Declarative Web Push）。这意味着用户无需从 App Store 下载应用，也不必每年花 99 美元只为在锁屏显示几个字——只要把页面添加到主屏幕，从图标打开即可。苹果（Apple）的规则要求每台设备完成一次这样的添加操作。

一行命令完成接入

整套配置不到一分钟。一条命令会写入 Worker、生成所有密钥、安装并配置存储、完成部署：

npx kukuroo init my-push

执行后便拥有了一台属于自己的推送服务器。在 iPhone 的 Safari 中打开打印出的地址，选择「添加到主屏幕」，从图标进入即可。

任何能发 HTTP 请求的地方都能触发

触发推送的入口很轻量：正在运行的智能体（agent）跑完或停下来询问时、定时任务（cron）、CI 流程、树莓派（Raspberry Pi）、后端服务，乃至一个 shell 别名——任何能发起 HTTP 调用的程序都能让手机响一声。例如用 curl 带上令牌（token）即可发送：

curl -X POST https://push.example.com/push/send -H "authorization: Bearer $KUKUROO_SEND_TOKEN" -d '{"notification":{"title":"任务 W13 完成","body":"W14 已解锁，可以开始"}}'

免费额度够个人使用

前置条件很克制：仅运行在 Cloudflare Workers 上；声明式 Web Push 目前只在 Safari 落地；需要 iOS 18.4 及以上，且页面在主屏幕、从图标打开；以及一个 Cloudflare 账户。

免费套餐已能支撑个人使用：每次发送覆盖 50 台设备、每日 10 万次请求；若规模增长，每月 5 美元可将单次发送扩展到 1 万台设备、每日 1000 万次请求。

对于想把关键提醒从聊天群和收件箱里捞出来、又不想为它单独养服务器或开发应用的人来说，用 Cloudflare Worker 自建一套推送，是一个轻量且自主可控的选择。

来源：Kukuroo 项目页 / Hacker News

最刺眼的数字出现在今年 4 月 22 日。那一天，PatronView 单日收到了 360 万次请求，来源是 361844 个独立 IP，而且几乎全都位于中国。运营者调侃着想象了这些机器人长什么样，但数字本身是真实的。

同行的数据更能说明问题。Cloudflare 曾披露，Anthropic 的爬虫大约每带来一个被引荐的访客，会发起约 3000 次抓取；而 PatronView 运营者实测的比例是 35000 比 1。就在发稿前几天，他还封掉了亚马逊的 AI 搜索爬虫——那个爬虫每天读取 11.7 万页，却从没给网站带来过一个真实访客。

验证码也没能拦住什么。PatronView 的验证码通过率只有 0.24%，也就是说，机器人甚至懒得尝试破解，直接放弃，转而去撞下一页。更隐蔽的是统计盲区：运营者用自托管的 Plausible 做访问统计，这款工具只记录会执行 JavaScript 的访客，而几乎没有机器人会这么做。表面上看，网站每天只有约 500 个访客，显得很安静；但服务器每周要应答数百万次真实请求。发稿那一周，服务器对外应答了 250 万次请求、吐出 128 万整页，而可见的页面浏览量只有 5977 次——换算下来，每 1 次真人加载背后，约有 214 次机器人加载。

传统 SEO 爬虫同样不消停。SemrushBot、AhrefsBot、MJ12bot、DataForSEOBot 这类工具反复爬遍每一个页面，光靠 robots.txt 根本请不走。运营者最终在 Cloudflare 层面逐条加安全规则才勉强挡住。

这件事的启示并不复杂：今天大多数网站的流量早已不是真人。可见的访问统计和实际服务器负载之间，隔着一道巨大的、由机器人组成的鸿沟。对一个靠公开数据起家的「爬虫」网站来说，反爬成了一场没有终点的猫鼠游戏。

来源：PatronView

Cloudflare 在 8 月 6 日推出了 WebMCP 的开发者预览版，试图改变这一局面：网站只需在控制台里打开一个开关，无需编写任何代码，也不改动源站，浏览器中的 AI 代理就能直接调用这个网站提供的工具。Cloudflare 会向页面注入一个轻量桥接层，为访客的代理注册一套可用工具集。

从「爬」到「调用」

过去，AI 获取网站内容的通行做法是爬虫抓取：把内容复制回自己的服务器，往往既不给原网站带去流量，也不留下多少署名。Cloudflare 认为存在一条更好的路径，而且这条路径不需要爬取。

WebMCP 是一项新的浏览器标准，目前已在 Chrome 146 中实验性上线，在页面里以 document.modelContext 的形式呈现。网站可以主动向浏览器内运行的代理暴露一组工具，代理就不必再对着为人类设计的页面元素反复猜测。这样一来，代理的浏览体验可以与人类用户完全不同，token 花在真正要完成的任务上，而不是消耗在无谓的页面导航中。唯一的门槛在于：网站必须自己去实现它。

Cloudflare 一直在这条链路的两端同时布局。其远程浏览器 BrowserRun 已支持 WebMCP，代理可以发现并调用网站暴露的工具；Cloudflare Radar 也即将提供自己的 WebMCP 工具。这次的预览版针对的是另一端——让任何托管在 Cloudflare 上的网站，通过一个开关、零代码就获得这些能力。

技术实现：边缘注入加浏览器桥接

手动实现 WebMCP 本身就是一个不小的工程：需要设计要暴露哪些工具、把它们接入现有界面，还要随着标准演进持续维护。Cloudflare 的目标是把这件事简化成拨动一个设置开关。

这些工具以「工具包」（pack）的形式组织，相关工具可以整体启用。工具包的设计考虑了扩展性：随着 Cloudflare 陆续增加新包，网站只需打开开关即可接入更多能力，无需重新部署。当前开发者预览版包含两个工具包，两者都完全在浏览器中运行。

整套实现由两部分组成，均位于源站之前，不触碰网站自身代码，且对静态站点和单页应用一视同仁。

第一部分是边缘注入。当网站在 Cloudflare 控制台中开启 WebMCP 后，Cloudflare 使用 HTMLRewriter 在每个 HTML 响应中添加一行内容——一个指向桥接脚本的引用。标签和它加载的脚本都来自边缘节点、同源提供，页面的其他部分保持原样：

<script
  type="module"
  src="/.webmcp/bridge.js"
  data-packs="c2pa,mcp-server-client"
  data-mcp-url="/mcp"></script>

其中 data-packs 属性列出要激活的工具包。如果网站已有自建的 MCP（Model Context Protocol，模型上下文协议）服务器，data-mcp-url 就指向该服务器，默认为同源的 /mcp 路径。

第二部分是桥接层。它在页面中运行，负责寻找 WebMCP 接口。如果浏览器不支持该接口，脚本直接返回、什么也不做，页面行为与之前完全一致。

找到接口后，桥接层会把 data-packs 中列出的工具包合成一份工具清单，逐个通过 .registerTool 注册。一个工具包就是一组 MCP 工具描述符及其处理函数。像内容凭证包这样的静态包会预先声明自己的工具；而像站点 MCP 服务器包这样的动态包，则在启动时先发现工具，再进行注册。

在当前预览版中，每个工具都完全在访客的浏览器内运行，不存在向 Cloudflare 服务器的往返请求。内容凭证包在本地抓取图片并解析其前几 KB 的内容溯源元数据；站点 MCP 服务器包则从页面直接与网站的 MCP 服务器端点通信，使用访客所在的源和其已有的会话。

桥接层代码由运行在边缘的 Worker 提供。Cloudflare 表示这为后续扩展留出了空间——未来的工具包将能够调用这个 Worker，去完成页面自身无法独立完成的任务，比如用 Workers AI 总结站点地图，或查询 AI 搜索索引。

对代理而言，这些都只是普通的 MCP 工具。Cloudflare 直接沿用了 Model Context Protocol 自身的 Tool 和 CallToolResult 类型，因此一个已经能与 MCP 服务器对话的代理，不需要任何额外改造就能驱动页面。用 Cloudflare 的说法：浏览器只是 MCP 运行的又一个场所。

两个预览工具包

内容凭证包用于读取图片的溯源元数据，服务于 C2PA 内容凭证计划的参与方。其中 scan_images_c2pa 会扫描页面上的每一张图片，返回一份简短摘要，包含图片总数、已扫描数量、带有 C2PA 信息的数量，以及每张图的格式、声明生成方（例如 Adobe Firefly）、标题和签名者等字段。若需要更细致的信息，inspect_image_c2pa 可以解码单张图片的完整清单，包括编辑历史、声明的作者以及签名证书。

另一个是站点 MCP 服务器包。它会读取网站自有 MCP 服务器通过 tools/list 公布的每一个工具，为其注册一个代理封装。当代理调用该工具时，封装函数会以同源方式向 /mcp 发起 POST 请求，携带访客现有的会话凭据，并将返回的 CallToolResult 原样传回。

对站点运营者来说，这一变化的实际意义在于 AI 流量的处理方式：代理不必再从原始 HTML 中反推网站意图，而是可以调用结构化工具、拿到准确且符合预期的结果，同时保留会话上下文，网站方也能完整看到代理的交互行为。

WebMCP 采用 MCP 2026-07-28 版本规范，该版本将协议从有状态的会话管理转向基于 Streamable HTTP 的无状态模型，代理通过标准 POST 请求调用工具，用 Mcp-Method 和 Mcp-Name 请求头路由指令，从而更适合在边缘基础设施上横向扩展。

需要注意的是，这仍是开发者预览版，WebMCP 标准本身在 Chrome 中也处于实验阶段。站点运营者可以将 BrowserRun 指向自己的域名，查看代理究竟会发现哪些工具、又会如何调用它们，然后再决定是否放行生产流量。

来源：Cloudflare 官方博客、Cloudflare Browser Run 开发者文档

Cloudflare 给出的答案叫 Cloudflare OS。8 月 5 日，这家公司宣布把它开源，任何组织都可以自行部署、接入内部系统并按需改造。

先在自家跑了三个月

今年 5 月，Cloudflare 向全体员工开放了第一个版本。据其官方博客描述，各职能部门数千人每天使用，其中很多人并非工程师——他们用它撰写文档和幻灯片、把重复性任务自动化、搭建小型应用来可视化数据。

更关键的是共享层。Cloudflare OS 为所有人提供了一个由各团队共建的上下文与技能库，把公司的术语、流程和处理常规工作的最佳做法，沉淀成智能体可以直接遵循的指令。一个人摸索出更好的做法，其他人立刻就能复用。

第一版也暴露了问题。它以个人私有工作区为中心，生成的应用是静态的，而非连接内部系统的活体软件；即便是几乎完全确定的重复任务，也得重新跑一遍智能体技能，白白消耗模型 token（模型处理文本的计费单位）。

协作环节的问题更根本。接入 MCP 服务（模型上下文协议，用于让智能体调用外部工具）只能告诉系统智能体可以调用哪些工具，却无法说明它实际读取过哪些底层资源。一旦开始共享工作区、应用和产出，就必须确保协作不会让人看到本不该看到的信息。

于是 Cloudflare 把整套系统在新底座上重建了一遍，核心判断是：安全必须是平台自带的能力，而不是每个搭应用、用智能体的人各自去正确实现一遍。

三个组成部分

新版 Cloudflare OS 由三块拼成：一个以公司自建上下文与技能为基础的智能体工作区，内置可让智能体编写并运行代码的隔离运行时；一套面向内部数据与服务的安全治理框架；以及一个支持个人搭建、共享并持续修改应用的平台。

工作区在浏览器里使用，不需要懂终端。它能做四类事：调用公司上下文与已授权资源做研究，且智能体是通过写代码去搜索、筛选、连接和分析信息，而不是把整个数据集塞进模型的上下文窗口；把研究结果转成可继续编辑的文档、演示或表格，这些产出可以与实时数据保持连接、随数据源更新，也能导出为常见格式；在文档表格不够用时，直接构建带界面、逻辑和状态的应用，供多人协同；以及把已知步骤的重复工作转成基本确定性的流程，用代码处理可预测部分，只在真正需要判断的环节调用模型，流程可按需触发、定时执行或由连接系统的事件驱动。

安全设计：智能体的默认权限是零

员工接触 AI 后最常提的诉求，往往是索要公司系统的 API 密钥。Cloudflare 的判断很明确：把密钥直接交给人和智能体既危险也无法规模化，密钥通常权限宽泛、有效期长，难以约束、难以安全共享、难以审计。

Cloudflare OS 的做法分三层。

默认无权限。 由 Cloudflare Access 控制谁能进入系统，进来之后每个智能体和应用的初始权限是零。智能体可以申请访问某个具体资源，由人决定批准或拒绝，生成的代码以类型化绑定的形式拿到该资源，凭据始终与智能体和代码完全隔离。服务端代码运行在关闭了全局出站网络的 Dynamic Worker 中，客户端代码运行在浏览器的沙箱框架内，两者除了显式授予的能力之外都无法访问互联网。

Gatekeeper 管资源和动作。 这是一个针对特定服务的 Worker，夹在 Cloudflare OS 与外部服务之间，理解该服务的接口、资源和可执行操作。官方举的例子是：把整个 GitHub 账号交给智能体范围太大，而 Gatekeeper 可以只开放单个仓库、只允许读取议题而不能读源码、屏蔽特定字段、施加速率限制，并要求合并请求前必须经人工审批。智能体看到的只是一个小巧的 TypeScript 接口，OAuth 授权、凭据保管、策略执行、读取记录和外部副作用的中介，全部由 Gatekeeper 承担。

策略跟着智能体看过的东西走。 只管住第一次读取是不够的。官方设想了这样一种场景：智能体读取数据仓库中一张敏感表，据此生成实时看板，分享看板不能变成把这张表分享给无权访问的人。为此，Cloudflare OS 记录智能体观察到的每一项资源，这些记录始终附着在智能体及其产出上。当另一个人试图打开工作区、与智能体交互或查看产出时，Gatekeeper 会核验此人对那些被观察资源的访问权限。同一套观察日志还用于判定智能体何时可以发起外部请求——读取过敏感数据，可能就会禁止它向特定目标写入、邀请新协作者、把工作移交给另一个智能体或发起外部请求。

每一个“文件”都是一个完整应用

多数生产力套件给的是固定几件套：文档、表格、演示。Cloudflare OS 的思路不同——每个“文件”都可以是一个应用，由智能体为某个人、某个项目或某个团队专门编写。

这些不是需要导出再另行部署的原型，而是自带客户端代码、服务端代码、接口和持久状态的全栈应用，默认私有，可像文档一样共享。智能体写应用时产出两部分：渲染界面的客户端代码，以及存储状态、实现逻辑的服务端代码。服务端以 Dynamic Worker 按需加载，并实例化为 Durable Object Facet（这两项能力都是为该项目专门构建的）。Facet 给每个应用一个独立的 SQLite 数据库，与管理它的运行时相互分离；Dynamic Workers 使用轻量级 V8 隔离环境，因此每个应用都能拥有独立运行时，而不必长期占用一台服务器或容器。

浏览器客户端通过 Cap’n Web 与服务端通信，这是 Cloudflare 开源的对象能力式远程过程调用系统。服务端方法可以像普通 JavaScript 函数一样从客户端调用——特别之处在于，智能体也能调用同一个方法。用官方博客的说法，只要一个人能造出工具来完成某项工作，那么在这个人不在的时候，智能体也能用同一件工具把活干完。

共享方式有两种：共享应用本身，其他人可基于同一份状态实时协作；共享应用的“蓝图”，其他人可创建属于自己的副本。从蓝图创建的应用包含原应用的代码，但不包含其 SQLite 数据、对话历史、凭据和已连接资源，每个新应用都从独立的状态和资源开始。这意味着团队成员可以自己用 AI 修改应用，而不必提工单等着原作者排期。

模型可换，花销可控

Cloudflare OS 支持任意模型，所有推理调用都经由 Cloudflare AI Gateway，组织可在同一处决定哪些模型可用、哪项工作交给哪个模型。官方给出的理由很实际：不是每项任务都需要最贵的模型——每天早上总结未读邮件，未必值得动用最昂贵的前沿模型。

每一次请求都会归属到发起它的人、团队或工作区。管理员可以看到推理支出流向，设定预算与速率限制，并决定触及上限后如何处理。

开源之后

代码已在 GitHub 的 cloudflare-os 仓库放出，可部署到自有 Cloudflare 账号，配合自家的 Access 策略、AI Gateway 配置、数据与集成。Cloudflare 一共发布两个仓库：Cloudflare OS 核心，以及一个基于其内部运行方式的示例部署；部署仓库不修改核心即可使用，用于承载配置、自定义界面、内部集成、分析和部署流水线。

值得一提的是，该项目在 GitHub 上把自己类比为一套真正的操作系统：workshop-backend 相当于内核，各类 Gatekeeper 相当于设备驱动，workshop-frontend 相当于 shell，Gadget 相当于进程，蓝图相当于可执行文件。而传统操作系统尚未管理的那一类对象，正是 AI 智能体——Cloudflare 的观点是，智能体不能简单当成用户对待，它必须对某个人类用户负责，同时拥有自己受限的权限，这种场景下更合适的安全模型是基于能力的安全，而非访问控制列表。

由于 Cloudflare Workers 的运行时 workerd 本身也是开源的，Cloudflare OS 并不局限于只能跑在 Cloudflare 上，完全可以架在自有服务器的 workerd 之上。

代码只是起点。Cloudflare 表示，其战略伙伴 Presidio 和 Happy Cog 会协助企业按自身运作方式定制并推广。后续规划包括：把 Cloudflare OS 做成 Cloudflare 控制台中的全托管产品、为开发流程增加容器支持，以及把工作区接入 Slack 等聊天工具。

来源：The Cloudflare Blog

支撑这两套系统的是同一样东西：Cloudflare Codex——一套同时写给人和智能体看的工程规范。

问题不是没规范，是规范找不着

在 Codex 之前，Cloudflare 的开发指引散落在各处：正式文档、代码仓库里的说明文件、聊天记录，以及资深工程师脑子里的经验。工程师花在找规矩上的时间，常常超过花在解决问题上的时间。更糟的是，就算翻到了某条说法，也未必能判断它是否还有效、是否权威、是否适用于眼下的情况。

公司规模越大，这套模式越撑不住。没有哪个工程师能读完所有规范，评审者也不可能逐条核对每项要求。人员在团队之间流动，沉淀下来的经验越来越难被找回，而那些没被持续提示和执行的指引，最终导致各个项目各行其是。

Cloudflare 的做法是把这些知识重建成 Codex：一套有治理机制的工程规范，智能体可以在工程师干活的当下，把相关条款调取出来并应用。

规范怎么写，又怎么生效

Codex 按领域切分，涵盖架构类（例如前端、控制平面）、横切关注点（安全、可靠性）、具体语言（TypeScript、Rust）等方向，每个领域设一名负责人，对内容、一致性和整体质量负责。

规范采用 RFC（征求意见稿）格式撰写，要求用 RFC 2119 定义的 SHOULD（建议）与 MUST（必须）关键字表述，并在文件头部保留领域、状态等元数据。任何员工只要对某个领域有兴趣和相应能力，都可以按规定结构提交合并请求发起一份 RFC，经过多轮逐步扩大范围的评审，最后由领域负责人拍板，纳入 Codex 并发布到内部站点。

关键设计在于两段式生效。RFC 进入「已批准」状态后，智能体就会开始标记违规，但只提示、不拦截；只有当它被显式提升到「已强制」状态，MUST 类要求才真正具备拦下合并的效力。这个额外的推进步骤给了团队消化新要求的时间，也照顾了那些在执行层面还需要额外准备的情况。

还有一个绕不开的工程问题：Codex 已经积累了 60 多份 RFC 且仍在增加，如果原封不动全部喂给大模型，光是语料体量就会挤爆上下文窗口，反而拉低输出质量。Cloudflare 的解法是用一个专门的智能体，自动把所有 SHOULD 和 MUST 语句抽取压缩成 JSON 结构，并附上支持惰性发现和渐进披露的元数据。每条语句都有一个稳定的标识符，即便所属 RFC 被修订也不会变化——这让同一条要求能够在不同系统间被长期追踪，对监控、分析和例外处理都是必需的。团队最初把语句抽成更简洁的 Markdown 文件，后来才换成结构化程度更高的 JSON，好让智能体能更精准地筛选自己需要的内容。

三个正在用它的地方

目前有三个智能体在日常工作中消费 Codex。

第一个是 AI 代码审查器。它从多个维度评估合并请求，Codex 合规性是其中之一。每次审查时，它先取出相关 RFC 并解析其中的语句，只有在模型或协调器需要更多上下文时才加载 RFC 全文——多数情况下，抽取出的语句已足够解释一处违规。SHOULD 与 MUST 的区别加上 RFC 的状态，共同决定审查器的反应：来自「已批准」RFC 的发现只是不阻塞的建议；一旦 RFC 进入「已强制」状态，未满足的 MUST 要求会让审查器拒绝批准或直接拦下合并，具体取决于严重程度。自今年年初 Codex 建立以来，这个审查器累计标记了近 23 万处违规，其中近 1.6 万处导致合并未获批准。

它也有明显的体验短板：受协调器框架和子智能体执行的拖累，跑完一轮通常要几分钟，工程师抱怨等待时间和返工带来的额外往返。Cloudflare 为此补了两条路。对那些可以机械校验的语言类要求，提供与 Codex 规范对齐的定制 linter（静态检查工具）配置包，毫秒级出结果；TypeScript 率先支持，并统一使用 oxlint——其维护团队 VoidZero 近期已加入 Cloudflare，Rust 版本正在开发，Go 随后跟进。此外，AI 代码审查器现在也可以通过命令行在本地运行，功能与持续集成环境中的协调器一致，结果直接打在终端里。

第二个是设计文档审查器，面向工程师在动手前撰写的技术方案。它跑在 Cloudflare Worker 上，结果和状态存进 D1 数据库，模型请求走 AI Gateway，由定时触发器发起扫描。运行时它先按领域和章节过滤 Codex，把语言特性、实现细节一类与设计无关的 RFC 排除在外，再依据严重程度对发现分级。自 2026 年 5 月初以来，它已审查近 600 份独立的开放设计文档，算上按需重跑和文档变更触发的重跑，累计调用超过 3200 次。绝大多数发现属于「重要」（65%）或「次要」（29%）级别，「严重」级别只占 6%。

第三个是事故报告审查器，把同一套方法用在事故复盘上。除了检查报告是否完整，它还评估报告有没有讲清楚发生了什么、有没有识别出促成因素、有没有记录处置过程、有没有提出有意义的后续行动项。自 2026 年 5 月以来，它已评估 200 多份事故报告，指出过遗漏后续行动项、时间线不完整、漏记检测信号等问题。这些报告中有 93% 对应的是低影响、仅限内部或预防性声明的事故；对于高危事故，这道审查已被设为强制流程的一部分，所有发现被处理完毕之前，报告不算完成。

下一步

Cloudflare 表示将把这套模式扩展到整个软件开发生命周期，让智能体在设计、实现和运维各环节一致地暴露问题。更长期的目标是让智能体不只发现问题，还能以越来越高的自主性提出修复方案，而审阅和批准仍由工程师负责。

Codex 的适用范围也在往工程之外延伸，产品、安全、合规以及信任与安全团队已开始加入各自的标准。

用负责这项工作的工程师 Timo Reimann 的话说，AI 最有用的地方，是在工程师真正动手的那个节点，把对的指引送到他面前。

来源：Cloudflare 官方博客，作者 Timo Reimann

三位工程师讲了三招。第一招，把模型用来记住上下文的「键值缓存」从 16 位精度压到 8 位，Kimi K2.6 能同时装下的上下文量从约 68.6 万词元翻到约 137 万。反常识的地方在这儿：单个请求反而更慢了（每秒 137 个词元降到 125），可同时能处理的请求数从 32 个上限顶到 64 个，峰值吞吐比原来高出 41%，每词元成本降约三成。第二招，把 GLM 5.2 的权重从 8 位浮点压成 4 位整数，模型文件从 705GB 缩到 421GB，单张显卡占用从约 88GB 降到 52GB，解码速度不降反升 55%。

说白了，这是拿「单个用户慢一点」换「同时能服务的人多一倍」——云厂商算的是总账，不是单笔账。而两项常用测评的分数几乎没掉（94.24 对 94.09、89.11 对 89.04），说明这笔账划得来。第三招则是给共享缓存加了一层校验，防止上百个请求读串页，代价不到 1% 的吞吐。

有意思的是，中国开源模型如今成了海外云厂商眼里「最难伺候、也最值得下功夫」的一类。如果要接一个大模型进自己的项目，你会先看效果还是先看单价？

来源：Cloudflare 官方博客《Smaller, faster, safer: running Kimi and GLM at scale》，作者 Alex Reneau、Kevin Flansburg、Chi McIsaac，2026 年 8 月 3 日