配了三年 YAML，每次改 CI 都要在缩进里找 bug——今天这件事被 TypeScript 彻底变了

CI 工程师最烦的不是跑不通，是跑不通的时候还要在一堆缩进里找哪个 tab 被谁换成了空格。YAML 写 CI pipeline，本质上是在用字符串配置文件描述一个有状态、有并发、有重试逻辑的系统——这是天然的不匹配。Cloudflare 8 月开源的 @cloudflare/ci 就是来解决这个问题的：把 CI pipeline 直接用 TypeScript 写，每个步骤变成一个 durable Workflowstep，失败自动重试、从断点继续，不用再跑整个管道。

这个工具的核心逻辑一句话就能说清：「本质上，CI/CD 管道就是一种 Workflow」。每个 stage 对应一个 Workflow step，继承了两件事：checkpoint 过的执行状态（失败自动从断点重试，而不是从头开始）和并发执行（除非你主动声明依赖，否则每个 step 独立启动、互不等待）。用 Promise.all() 把 lint、test、typecheck、build 四个独立检查包起来，等全部通过再进 deploy stage——这是以前用 YAML 很难优雅实现的东西。

依赖缓存是第二个痛点。传统 CI 里每次跑 install 都是全新的环境，哪怕只是加了一个新包也要全部重装。@cloudflare/ci 把 install 结果存成 Sandbox 文件系统的快照放在 R2 里，后续步骤直接复用，不用重新下载。官方说这个缓存机制让后续 pipeline 运行「不需要重新安装」，实际效果取决于你的依赖体积，但对于 node_modules 巨大的 monorepo，这个改动是实质性的。

更值得关注的是「自愈」这个例子。官方 demo 里跑了一个 Healing Agent：错误步骤的诊断结果发给 Workers AI，AI 判断根因、在同分支上 push fix commit，工程师只需要 merge。这意味着 CI 不只是「告诉你哪里错了」，而是可以「替你修了再告诉你」。当然这个 Healing Agent 目前只是 example 代码，不是包的一部分，但它展示了 durable execution + AI agent 的组合空间。

现在生产用有几个限制要清楚。第一，步骤跑在 retryable Workflow step 里，所以任何有外部副作用的命令必须幂等——重试不会撤销副作用，retry 一旦触发会再执行一遍。第二，CiRunnerResult.logs 输出原始命令内容，没有做 secret 脱敏，敏感信息的日志要自己处理。第三，目前 source provider 只接了 Cloudflare Artifacts（私有 beta），不是拿来直接替代 GitHub Actions 的。

那这东西适合谁用？如果你已经重度用 Cloudflare 的生态系统（Workers/Workflows/R2/Artifacts），想在一个平台内完成存储→构建→测试→部署全链路，它是目前市面上最干净的方案。如果你还在用 GitHub Actions/Jenkins，这只是一个值得关注的实验方向——但 durable step 模型会成为未来 CI 的主流范式，这个判断可以先记下。

下一步：Cloudflare 的 GitHub 仓库（cloudflare/ci，Apache 2.0）有两个完整 demo，basic pipeline 和 self-healing variant，可以 clone 下来跑一遍感受 durable execution 的行为。如果你在调研下一代 CI 架构，这个方向值得跟踪。

参考来源：

• Cloudflare 官方博客「Run CI/CD for millions of repos — on your platform, on Cloudflare」（blog.cloudflare.com，2026-08-19）
• Machine Herald「Cloudflare Ships an Open-Source CI SDK That Defines Pipelines in TypeScript on Workflows and Sandboxes」（machineherald.io，2026-08-19）
• InfoQ 报道（infoq.com，2026-08）
• @cloudflare/ci GitHub 仓库（github.com/cloudflare/ci，Apache 2.0）