Cloudflare 发布 @cloudflare/ci SDK,允许用 TypeScript Workflow 类替代 YAML 定义 CI/CD 流水线,支持 artifact 事件触发和并行执行。
本周的版本发布集中围绕两个主题:消除配置仪式感(YAML 流水线、手动缓存清除、投机解码配置)和修复真实的生产痛点(内存泄漏、工具调用失败、依赖膨胀)。Rspack 2.0 和 Cloudflare CI 的发布尤其释放了一个信号:TypeScript 和 ESM 正在成为开发者工具的默认底座,而非事后补救。
Cloudflare 新的 @cloudflare/ci SDK 让你可以将 CI/CD 流水线定义为 TypeScript Workflow 类,而非 YAML 文件。流水线直接在 artifact 推送时触发——无需事件订阅接线,无需队列样板代码。依赖缓存和并行步骤执行是一等公民,所有内容都会在现有的 Workflows 可观测性仪表板中呈现。
为什么现在重要:基于 YAML 的 CI 一直以来都是一种 leaky abstraction。你最终还是会用 shell 脚本去绕它。用 TypeScript 定义流水线意味着真正的类型安全、可组合的步骤逻辑,以及平台团队可以将单个 CI 定义作为可导入模块发布到每个客户仓库的能力。原生的 artifact 事件触发器也移除了一整类 webhook/队列基础设施,而大多数团队都是东拼西凑搭建这些的。
结论:值得发布——对于新的 Cloudflare 原生项目,没有理由不从这里起步。从 GitHub Actions 迁移是可行的,但并非开箱即用的替代品;需要预留时间重新思考触发模型,而不仅仅是翻译 YAML。需要带有 events 字段的 wrangler 配置,以及已接入的 Artifacts 仓库。
在 blob 读取时传入 useCache: false 可以绕过 CDN 缓存,在覆盖后 60 秒内获得保证的读后写一致性。不加这个标志,你获得的是最终一致性加上 CDN边缘性能。加上它,你会付出稍高一些的成本(Fast Origin Transfer 费用)并接受更慢的读取速度,换取数据新鲜度。
为什么现在重要:有状态的 AI 系统——Agent 记忆文件、会话转录、实时报告生成——在最终一致性下会以微妙的方式崩溃。调试一个每二十次请求才出现一次的陈旧读取是极其痛苦的。提供一个标志让一致性按需逐调用选择,这正是正确的 API 设计:你不需要在任何地方都付出成本,只在真正重要的路径上才付出。
结论:谨慎发布——只在会产生正确性问题的热路径上添加 useCache: false。需要 @vercel/blob@2.6.1+。不要无差别应用;成本和延迟的权衡是真实存在的。
v0.32.1-rc0 修补了 MLX 模型缓存的内存泄漏,稳定了 Gemma 4 在多轮交互中的工具响应连续性,并为 Agent 调用添加了工作目录上下文。
为什么现在重要:MLX 缓存泄漏对于运行持久化 Agent 进程的人来说是一个真实的生产问题——长生命周期会话中的内存增长会迅速累积,迫使重启,而重启会破坏连续性。Gemma 4 工具调用修复对于构建多轮推理链的人来说很重要;损坏的工具响应连续性很难检测,会产生微妙的逻辑错误而非明显的崩溃。
结论:值得发布——这是从 v0.32.0 的直接补丁升级。如果你观察到多请求会话中的内存增长,或者使用 Gemma 4 进行工具调用工作流,现在就升级。对其他模型用户没有破坏性变更。
v0.32.6-rc0 中的 MLX 引擎现在为 Qwen3.5 自动启用通过 MTP head 实现的投机解码——无需手动配置。流式响应格式也已与 OpenAI 的有线协议对齐,意味着 finish_reason 和 usage 字段现在遵循 OpenAI 的结构。
为什么现在重要:Apple Silicon 上的投机解码能显著降低本地部署的推理延迟,而之前需要手动配置意味着大多数用户没有获得这个收益。OpenAI 流式输出对齐的意义不容小觑:在本地 Ollama 实例和 OpenAI 托管模型之间切换时移除格式转换层,这是成本敏感型生产系统的常见模式。
结论:值得评估——如果你使用 Apple GPU 硬件或构建同时面向 Ollama 和 OpenAI 端点的客户端,值得升级。将其视为候选版本而非稳定版本。一个重要的警告:此版本中图像生成已损坏;在其恢复之前停留在 0.32.5。升级后验证你的流式消费者是否正确处理 finish_reason 和 usage——不要假设结构变化是透明的。
Quail 2 中的 Agent Mode 移除了顺序任务瓶颈,让你可以跨多个 LLM 运行同时对话,而 Android Bench 负责跨它们的基准测试。LeakCanary 集成将堆分析从受约束的测试设备转移到开发机器上,将分析时间缩短 5 倍。
为什么现在重要:顺序 Agent 工作流会造成停机时间——你提交一个重构任务后必须等待才能开始下一个。在多个 Agent 之间并行化改变了你组织工作方式。LeakCanary 的改进是更直接具体的收益:在中档测试设备上做堆分析非常缓慢,将计算转移到开发机器上这种减少摩擦的方式真正改变了你是否会运行这个分析。
结论:值得发布——Quail 2 稳定版现已可用。LeakCanary 集成是自动的。如果你经常调试内存泄漏或使用 Agent Mode,升级简单直接,5 倍堆分析改进是可测量的,不是愿景性的。
Rspack 2.0 将核心重写为纯 ESM,并将 @rspack/dev-server 从 192 个依赖削减到 1 个。构建速度快 10%,持久缓存优化得到改进,webpack 配置兼容性维持在约 95%。放弃 Node 18 支持;需要 Node 20.19+ 或 22.12+。
为什么现在重要:192 减到 1 是头条,但 ESM 优先架构才是结构性转变。企业项目上供应链安全越来越不可或缺,而只有一个依赖的开发服务器与有 192 个依赖的开发服务器是完全不同的安全面。webpack API parity 意味着迁移不需要重写配置——大多数情况下是直接替换,加上 Node 版本门槛。
结论:新项目值得发布;迁移项目值得评估——如果你要启动一个新的 React/TypeScript 项目,Rspack 2.0 是正确的默认选择。如果你从 webpack 迁移,95% 兼容性是真实的,但剩下的 5% 是边缘情况所在——预留一天时间来暴露它们。从 Rspack 1.x 迁移是直接的。生态成熟度仍然落后于 webpack 和 Vite,所以对于严重依赖社区插件的团队要把这个因素考虑进去。
如果你正在构建的东西与这些相关,Dev Signal 每周都会覆盖这类版本分析——没有废话,只有变更内容和是否值得你花时间。如果你愿意花五分钟阅读而不是花一个小时梳理发布说明,订阅吧。