原文：Continuous Integration — A Primer

作者：Astasia Myers

来源：SandHill.io #307 推荐阅读 · 行业动态与分析 ｜ RecodeX 编译

导读：当 AI 智能体承担越来越多写代码的工作，“生成改动”变得廉价，“验证改动”反而成了瓶颈。Felicis 投资人 Astasia Myers 在这篇入门文中梳理了持续集成（CI）的概念与组成、长期痛点、AI 带来的需求激增数据，以及新一代 CI 厂商可以在哪些方面建立差异化。

什么是持续集成

CI 是指频繁将小的代码改动合入共享主干，并通过自动化构建与测试加以验证，目标是在改动尚小、作者仍有上下文时就发现问题。它常与持续交付、持续部署并提：

图：持续集成、持续交付、持续部署的区别——CI 只负责“集成改动→构建与测试”，让问题尽早暴露；持续交付在此基础上让软件随时可发布，但由人工审批决定何时上线；持续部署则让通过检查的改动自动部署到生产环境
图：三种实践的自动化边界不同；仅使用 CI 工具并不等于实践了频繁集成

作者强调，CI 既是一种工程实践，也是一类工具：团队可以用 CI 而不自动部署，流水线也可以跑在功能分支上却并不频繁集成。

CI 如何运作

以修改电商结账流程为例：开发者提交 PR，触发安装依赖、代码质量检查、构建与测试；失败则查看日志、修正后重跑；团队可要求检查通过才能合并。关键组件包括：

  • 工作流（Workflow）：自动化流程及其触发条件；
  • 作业（Job）：在某环境中执行的一组步骤，可并行或相互依赖；
  • 运行器（Runner）：执行作业的机器，可由服务商托管或客户自建；
  • 制品（Artifact）：保留的产出，如二进制、容器镜像、测试报告；
  • 缓存（Cache）：可复用的依赖或构建结果。

GitHub Actions 用仓库内 YAML 定义工作流，支持托管与自托管运行器，把“定义与协调”与“执行”分开。这一分离在商业上很重要：创业公司可以只改进执行层，而无需客户更换工作流平台。

为什么 CI 依然痛苦

  • 慢：仓库和测试规模增大后，需编译多个服务、启动数据库、构建镜像、跨系统和架构测试。延迟来自排队等运行器、准备环境、重复劳动、等待上游任务；加机器并不能缩短最长依赖链。
  • 不可靠：不稳定测试（flaky test）在代码无关变化时时过时败，重跑变绿却没解决问题，久而久之开发者不再信任本应保护他们的系统。
  • 难调试：远程环境与本地不一致时，复现失败可能需要连续提交多次；对智能体而言，这意味着更多工具调用、模型消耗和重试。

因此问题不是“买便宜算力”，而是以可接受的总成本获得快速、可靠的反馈。

AI 如何改变机会

文中汇集了多组数据：

  • Anthropic（2026 年 9 月）：六个月内 CI 作业量增长 25 倍，测试数量增长 10 倍，工程人数几乎未变；代码生成和 PR 审查加速把瓶颈推到 CI，迫使其重构测试选择基础设施。
  • Pydantic（Logfire 团队）：同等规模团队在 2026 年 8 月的 30 天内合并 2032 个 PR，一年前为 365 个；主 CI 工作流 5 月运行 4194 次，截至 8 月 30 日达 20659 次，约 4.9 倍。
  • Honeycomb：AI 辅助开发加快改动节奏，CI 跟不上，于是为编码智能体提供 CLI 以检查和修复失败。
  • Blacksmith（2025 年 9 月）：现有客户每位开发者的 CI 用量过去一年每季度增长 60%。
  • CircleCI《2026 软件交付现状》（基于 2025 年 9 月 2870 万次工作流）：日均运行次数同比增长 59%，但前 5% 团队增长 97%，中位数团队仅增长 4%——增长极不均衡。
  • 上游产出：Cursor（2026 年 9 月）称新 Projects 用户多合并 30% PR，重度用户为 6 倍；OpenAI（2025 年 12 月）称使用 Codex 的工程师合并 PR 多约 70%。
  • DORA（2026 年 3 月）：代码编写节省的时间被重新分配到审计和验证上——活动增多不等于交付更快。

作者归纳三点影响：

  1. 验证量增速快于最终交付的代码：智能体会尝试多种方案并各自跑 CI，最后只合并一个，合并 PR 数只反映部分需求。
  2. 并发改变基础设施需求：多个智能体同时工作、各需隔离环境，突发负载需要快速供给，否则再快的机器也会被排队拖累。
  3. CI 融入开发过程本身：智能体在“执行—查看失败—修正—重跑”中循环，若每次都重建环境、重装依赖，准备时间就成了重复成本；开发环境与验证环境将更紧密结合。例如 Depot CI 允许对未提交改动运行工作流，RWX 支持推送前验证并与智能体沙箱共享执行环境。

CI 竞争格局

图：CI 竞争格局（2026 年 10 月示意）——第一代“成熟 CI”包括 GitHub Actions、GitLab、CircleCI、Buildkite、Jenkins、Azure Pipelines、Harness、TeamCity、CloudBees、Bitbucket、AWS CodeBuild、Google Cloud Build；第二代“智能体时代的 CI”包括 Blacksmith、Namespace、Depot、RWX、Dagger、WarpBuild、Ubicloud、RunsOn
图：两代 CI 厂商一览；代际反映起源与思路，而非“能否支持智能体”的硬性划分

作者区分了工作流产品（触发、依赖、密钥权限、结果报告）与执行环境（机器/容器、系统、依赖与资源）。厂商可提供其一或两者：

  • 只做执行层：团队保留 GitHub Actions，用 Blacksmith、Namespace、Depot 运行器、WarpBuild、Ubicloud 执行作业；RunsOn 则在客户自己的 AWS 账户内供给运行器。切换成本低。
  • 两层都做：Depot CI、RWX 自带工作流模型与执行环境；Dagger 提供可编程流水线与运行时，推送前后可运行同一流水线，也能嵌入现有 CI。控制力更强，但迁移更重。

新公司的差异化方向

  1. 让现有工作流更快更便宜：兼容型运行器易于试用对比，但难在现有平台改进基础设施后保持优势。
  2. 为 CI 专门打造基础设施：CI 负载反复检出代码、安装依赖、读写文件、启动短作业，可从处理器、存储、网络、调度与缓存位置协同优化。Blacksmith 与 Namespace 自建基础设施，例如把作业放在依赖附近以减少传输和准备时间。
  3. 让失败可操作：区分代码回归与基础设施故障、复现环境、给出最小可行下一步；掌握作业历史、环境、资源指标和日志的厂商比通用日志摘要更有优势。
  4. 让智能体直接使用 CI：通过 API 或 CLI 启动运行、取回相关日志、理解失败并重试。随着 CI 延伸到智能体工作环境，还将与开发环境及智能体基础设施公司竞争。

市场规模

Mordor Intelligence 估计 2026 年全球 CI 工具市场 20.9 亿美元，2031 年达 53.6 亿美元（CAGR 20.72%）；Fortune Business Insights 估计 2026 年 25.8 亿美元，2034 年达 126.6 亿美元（CAGR 22.02%）。口径不同，但都指向年增 20% 以上。作者最看好兼具高效执行与可靠、可复现反馈的产品，并欢迎智能体原生开发者工具创业者联系。（原文附免责声明：观点不代表 Felicis。）

本文由 RecodeX 编译自 Continuous Integration — A Primer（作者：Astasia Myers），首发于 SandHill.io #307 推荐阅读。本文为中文编译稿，非全文翻译，完整内容请阅读原文。译文仅供学习交流，观点不代表本站立场，版权归原作者所有。