Dagger 1.0 Beta 发布：Docker 之父要为 AI Agent 重做 CI/CD

本文永久链接 – https://tonybai.com/2026/10/29/dagger-1-0-beta-third-generation-ci-cd-for-ai-agents

大家好，我是Tony Bai。

【导读】

AI Coding Agent 正在以前所未有的速度生成代码，但构建、测试和验证却逐渐成为新的瓶颈。Docker 联合创始人 Solomon Hykes 推动的 Dagger 发布 1.0 Beta，提出了一个大胆的定位：继 Jenkins、GitHub Actions 之后的第三代 CI 平台。它试图改变的，不只是流水线怎么写，而是整个软件交付系统如何执行、缓存、反馈，以及如何与 AI Agent 协同工作。

【文章要点】

• 第一代：Jenkins 把构建与测试自动化，核心仍是服务器上的任务与脚本。
• 第二代：GitHub Actions 等云端 CI 平台引入事件驱动、临时运行环境和托管工作流。
• 第三代：Dagger 尝试把可复用执行单元、增量计算、缓存、沙箱、测试结果和运行追踪整合进同一个执行模型。
• 真正的差异：不只是把 CI 放到云上，而是让同一套构建与测试逻辑可以在开发机、Agent 沙箱和远程执行引擎中运行。
• 1.0 Beta 的信号：官方模块、工作区、测试级反馈、自主编排测试、开发 Shell、远程执行，以及原生 GitHub 集成。
• 理性判断：Dagger 并不意味着 Jenkins 或 GitHub Actions 已经失去价值。它的实际优势仍需结合项目复杂度、缓存命中率、运行成本和迁移成本验证。

AI 写代码越来越快，CI/CD 却拖了后腿

过去两年，软件开发领域发生了一个显著变化。

以前，开发者写完代码，提交 Git，等待 CI 构建和测试，然后根据结果修复问题。代码生产速度主要受限于人类的编码速度。

现在，情况变了。

一个 Coding Agent 可以在几分钟内修改多个文件、生成测试、调整依赖，甚至完成原本需要开发者花费数小时的任务。但当 Agent 把这些改动交给 CI 时，它可能需要等待数分钟，甚至更久，才能得到一次完整反馈。

如果测试失败，Agent 还要读取日志、分析原因、修改代码，再次触发构建和测试。

于是，一个新的问题出现了：代码生成的速度已经上去了，验证代码的基础设施却没有跟上。

2026 年 10 月 23 日，Dagger 发布 1.0 Beta。该项目由 Docker 联合创始人 Solomon Hykes 参与推动，其官方公告直接把问题指向了传统 CI 平台的底层设计。

Dagger 的判断是，继续购买更大的机器、增加更多的 Runner，并不能从根本上解决问题。

传统 CI 的核心仍然是：在服务器上运行一组 Shell 脚本，然后把执行日志交给开发者。

无论服务器是在办公室的机柜里，还是云端的临时虚拟机中，底层的执行模型并没有发生根本改变。

这会产生四类浪费：

• 重复计算。一点代码发生变化，流水线可能重新执行大量不受影响的构建与测试任务。
• 环境不一致。本地能通过的测试，到了 CI 中可能失败；Agent 只能通过提交、等待、读取错误来反复试错。
• 反馈信息不足。一大段文本日志很难准确描述哪个测试失败、运行环境是什么、消耗了多少资源。
• 算力利用率低。为应对高峰而配置的计算资源，在任务较少时可能大量闲置。

对人类开发者而言，这些问题已经令人头疼。对高速工作的 Agent 而言，它们会进一步放大：每一次等待都可能拖慢整个任务，每一次无效重试都可能消耗额外的模型调用与上下文。

Dagger 想做的，是从执行模型入手，缩短从代码修改到可靠反馈的整个闭环。

从 Jenkins 到 GitHub Actions，再到 Dagger

要理解 Dagger，先要理解 CI/CD 为什么可能需要第三次进化。

注：这里的“三代”是 Dagger 提出的产品定位，并非行业统一采用的分类标准。

第一代：Jenkins，让构建和测试自动化

Jenkins 代表了传统 CI 的重要阶段。

它将编译、测试、打包等操作串联成自动化任务，让团队不再依赖开发者手工执行所有步骤。

它解决的核心问题是：如何把软件构建和测试自动化？

但随着项目规模增长，团队往往需要维护大量插件、脚本、构建节点和流水线配置。环境管理、缓存、任务调度和日志分析也逐渐成为独立的运维问题。

Jenkins 可以扩展，但这不意味着所有环节天然拥有统一的数据模型。

第二代：GitHub Actions，把 CI 带入云端与事件驱动时代

以 GitHub Actions 为代表的第二代平台，让 CI 更紧密地融入代码托管与协作流程。

Pull Request、Push、Release 等事件可以触发工作流，开发者也可以利用托管 Runner 和生态中的 Action 组合任务。

它解决的核心问题是：如何让 CI 更容易接入开发协作，并按需运行？

这是一次重要进步，但从 Dagger 的视角看，底层仍然经常是工作流配置驱动 Shell 命令，在 Runner 上执行，再输出日志。

即使 Runner 是临时创建的，如果系统不知道任务之间的精确依赖关系，也无法有效识别哪些结果可以复用，那么增加机器只能缓解排队，不能消除重复计算。

第三代：Dagger，让 CI 变成可组合、可增量计算的执行系统

Dagger 的思路与前两代有所不同。

它不只是提供一个调度 Shell 脚本的平台，而是试图将容器执行、任务调度、缓存、沙箱和追踪整合到统一的执行模型中。

它解决的核心问题是：如何让每次代码修改都能以更低成本、更短延迟获得可靠反馈，并让 Agent 可以直接参与这个过程？

三代 CI/CD 的差异，可以概括如下：

需要说明的是，Jenkins 和 GitHub Actions 同样支持缓存、并行任务和测试报告，不能简单理解为它们完全没有这些能力。真正的区别在于：Dagger 希望把这些能力整合到一个统一的执行模型中，而不是主要依赖开发者在各个任务之间手工拼接。

这也是 Dagger 所谓“第三代”的核心含义。

Dagger 的核心：从 Shell 脚本到增量执行 DAG

Dagger 的关键创新，不是换一种 YAML 写法，而是改变自动化任务的组织和执行方式。

传统 CI 流水线通常类似这样：

这种模式能够工作，但每次失败后，Agent 往往需要从日志中重建问题上下文。如果依赖安装、编译和测试之间没有足够精确的缓存与依赖描述，还可能重复执行大量工作。

Dagger 希望将这些操作变成一个有明确依赖关系的执行图。

图示为概念模型，用于说明依赖、缓存与反馈关系，并非 Dagger 内部引擎的完整实现图。

这里最值得关注的是三个机制。

1. 增量计算：只重新执行真正需要执行的部分

Dagger 将执行任务组织成有向无环图，即 DAG。

每个节点代表一个有明确输入与输出的操作。一个节点的结果可以被缓存，后续执行在输入和相关依赖没有变化时，就有机会直接复用已有结果。

假设一个 Go 项目包含三个步骤：

• 编译程序。
• 运行单元测试。
• 运行集成测试。

如果一次改动只影响某个测试文件，那么理想情况下，系统就不必从头安装依赖、重新构建所有产物，再运行整个测试套件。

它可以复用仍然有效的结果，将计算集中在真正受影响的部分。

这里有一个关键细节：增量计算不是简单地给 Shell 命令加一个缓存，而是需要明确知道每项操作依赖什么。

Dagger 通过可组合的函数、类型化输入输出和执行依赖关系，试图让这种复用成为执行引擎的基础能力。

当然，缓存是否有效，仍然取决于输入是否被完整描述、任务是否存在未声明的副作用，以及缓存策略是否正确。

2. 统一执行环境：本地、CI 和 Agent 不再各自为政

Dagger 从诞生之初就强调一个目标：流水线可以编写一次，然后在不同环境中运行。

2022 年的首次公开发布，重点是可移植的 CI/CD 开发工具、可组合组件、本地调试，以及避免被特定 CI 平台锁定。

到了 1.0 Beta，这个目标对 Agent 变得更重要。

开发者可以在本地执行检查，在失败的容器环境中进入交互式 Shell，也可以把同一套执行逻辑交给远程引擎运行。

Dagger 1.0 提供了 dagger shell，可以进入工作区提供的容器环境；dagger check -i 则允许开发者进入命令失败时的具体环境。

这意味着，Agent 不必只靠日志猜测问题。

它可以在更接近真实执行现场的环境中检查依赖、运行命令、验证修复，再次执行检查。

3. 结构化反馈：让 Agent 不必反复阅读整份日志

对 Agent 而言，CI 的价值不仅是告诉它“通过”或“失败”。

更重要的是回答：

• 哪一个测试失败了？
• 失败发生在哪个执行环境中？
• 哪些输入导致了这个结果？
• 修复之后，需要重新执行哪些检查？

Dagger 1.0 的一个重要变化，是向测试级 CI 演进。

官方模块可以发现项目中的测试，运行指定测试，并分别报告测试结果。失败后，开发者可以只重跑对应测试，而不必每次重新执行整个测试套件。

这改变了 Agent 与 CI 的交互方式。

过去，Agent 得到的往往是一份需要进一步解析的文本日志；现在，目标是让执行系统直接提供更细粒度、可定位、可复用的结果。

这既能减少无效计算，也有望降低 Agent 为理解失败原因而消耗的上下文和 Token。

Dagger 1.0 Beta：五项值得关注的变化

经过约五年的 0.x 迭代，Dagger 终于进入 1.0 Beta 阶段。

这次发布并非简单的版本号升级，而是试图将执行引擎、模块生态和 CI 使用体验整合成一套更完整的产品。

1. 官方模块：减少重复造轮子

Dagger 开始维护官方模块目录，覆盖 Go、pytest、ESLint、Playwright 等常见工具。

模块可以读取项目的原生配置，发现项目结构，并提供相应的自动化能力。

这降低了采用门槛：团队不必从零编写所有 CI 逻辑，也不必为每种语言和工具重新设计一套集成。

对于 Agent 而言，官方模块还提供了一个更标准化的入口。它可以尝试安装和调用已有模块，而不是每次都从 Shell 脚本开始拼装整个流程。

2. Workspaces：明确工作区与模块配置

Dagger 1.0 引入了工作区概念：一个工作区通常对应一个 Git 仓库。

工作区通过 dagger.toml 配置要加载的模块和其他设置，模块也可以通过新的 API 动态访问工作区，按需读取文件、发现项目并解析原生配置。

这使 Dagger 的项目组织方式更加清晰，也有助于减少配置分散的问题。

需要注意的是，Dagger 1.0 对部分配置和 CLI 命令进行了调整。旧版的 dagger.json 配置在新版本中被拆分为 dagger.toml 和 dagger-module.toml，升级时需要检查兼容性。

3. 更快的执行：让重复计算真正成为例外

Dagger 官方公布了两项性能测试结果：

• 并行运行 1000 个容器：从 35～61 秒缩短到 16～17 秒。
• 收集 300 个文件：从 11.8 秒缩短到 1.1 秒。

这些结果来自官方发布说明中的测试，不应直接等同于所有真实项目都能获得相同比例的加速。实际效果仍然取决于工作负载、缓存状态和运行环境。

但这两项测试传递了一个明确信号：Dagger 不仅在增加 Agent 集成能力，也在持续优化执行引擎本身。

如果一个系统需要服务大量并行 Agent，那么容器启动、文件操作、缓存持久化和任务调度的开销，都会直接影响整体吞吐量。

4. 测试自编排：让测试自己声明依赖

集成测试通常需要数据库、API 服务等外部依赖。

传统做法是由 CI Job 或 docker-compose 在测试之外启动这些服务。这可能导致本地与 CI 的环境配置存在差异。

Dagger 提供了另一种选择：测试可以调用 Dagger 模块来准备自己的依赖，让同一套测试逻辑在本地和 CI 中使用相同的依赖管理方式。

这对 Agent 很有价值。

Agent 不仅可以运行测试，还能在统一的执行环境中复现测试所依赖的服务，减少“本地通过、CI 失败”这类问题。

5. 远程执行与原生 GitHub 集成：从开发机走向规模化

当一个团队同时运行多个 Coding Agent 时，本地计算资源很容易成为瓶颈。

Dagger 支持将流水线交给远程引擎执行，包括自有基础设施和 Dagger Cloud。执行过程可以按需传输本地文件和密钥、建立网络隧道与终端连接，同时利用沙箱隔离任务。

另外，Dagger Cloud 还提供原生 GitHub 集成，可以直接接收 GitHub 事件、执行检查并回传状态。对于这类检查，不必再通过 GitHub Actions 工作流文件来完成触发与状态反馈。

这并不是说 Dagger 一定要取代 GitHub Actions。团队也可以将 Dagger 作为执行引擎，继续使用现有 CI 平台负责触发、权限控制和工作流编排。

更值得关注的是，Dagger 将本地开发、Agent 执行与云端 CI 连接到了同一套执行模型中。

Dagger 为什么可能成为 Agent 时代的重要基础设施？

把前面的机制放在一起，就能看出 Dagger 的真正目标。

它不是单纯追求更快的 CI，而是试图减少软件交付过程中的无效工作。

可以把 Agent 的工作循环简化为：

这个循环里，Agent 的能力固然重要，但执行检查的速度、结果的质量，以及失败后的恢复成本，同样决定最终交付效率。

如果每次修改都要等待一整套流水线，如果每次失败都要重新阅读几千行日志，那么即使代码生成速度提高十倍，整个系统也未必能获得相同幅度的效率提升。

反过来，如果系统可以复用已有产物，只执行受影响的检查，提供清晰的失败信息，并让 Agent 在原始失败环境中调试，那么每一次反馈都可能变得更快、更有效。

这就是 Dagger 想构建的基础设施：不只是让 Agent 能调用 CI，而是让 CI 本身按照 Agent 的工作方式重新设计。

从这个角度看，Dagger 的价值也不局限于 AI 编程。

对于大型单体仓库、复杂的多语言项目、大量集成测试，以及需要在不同基础设施间迁移的团队，同样可以从可复用执行、统一环境和结构化反馈中获益。

Dagger 能取代 Jenkins 和 GitHub Actions 吗？

这是一个需要谨慎回答的问题。

Dagger 1.0 Beta 确实提出了第三代 CI 的愿景，但 Beta 版本并不意味着产品已经完成了所有场景的验证。

首先，Jenkins 和 GitHub Actions 的优势不只是执行脚本。它们还拥有成熟的权限体系、插件与 Action 生态、审批流程、触发机制，以及大量团队已经建立起来的运维实践。

其次，Dagger 的缓存和增量执行效果依赖任务是否可以被正确描述。对于存在隐式依赖、外部副作用或不稳定测试的项目，缓存并不能自动解决所有问题。

再次，Agent 时代的 CI 不只是性能问题，还涉及安全边界。远程执行、密钥传递、多 Agent 并行和沙箱隔离，都需要经过实际的安全评估与工程验证。

最后，迁移本身也有成本。现有项目的流水线越复杂，越需要先验证 Dagger 的执行模型能否覆盖已有的构建、测试、发布和审批流程。

因此，更合理的判断不是“Dagger 发布了 1.0，传统 CI 就过时了”，而是：

Dagger 正在尝试把 CI/CD 从以工作流和任务为中心的自动化系统，推进到以可组合执行、增量计算和高质量反馈为中心的交付系统。

这是一条值得关注的技术路线，但它能否成为新一代 CI 的主流，还需要由真实项目的稳定性、性能、生态和总成本来证明。

小结：当代码生产进入 Agent 时代，验证基础设施也必须进化

回看 CI/CD 的发展，Jenkins 推动了构建与测试自动化，GitHub Actions 将 CI 深度融入云端协作，而 Dagger 希望进一步解决重复计算、环境不一致和反馈质量不足的问题。

这三者并不是简单的新旧替代关系，而是对应着不同阶段的软件生产需求。

当人类开发者是主要的代码生产者时，几分钟一次的反馈或许可以接受；当数十个甚至数百个 Agent 并行修改代码时，验证系统的效率就会直接决定整个软件工厂的吞吐量。

这也是 Dagger 1.0 Beta 最值得关注的地方。

它试图将执行环境、缓存、调度、测试与反馈统一起来，让 Agent 不仅能生成代码，也能更快地验证、修复和交付代码。

AI 软件工程的下一场竞争，可能不只发生在谁的模型更聪明、谁的 Agent 更会写代码，还会发生在谁能用更少的计算、更少的等待和更少的无效交互，把代码可靠地变成软件。

Dagger 正在押注这个方向。

参考资料：

1. Dagger 1.0 Beta 官方公告
2. Dagger v1.0.0-beta.21 发布记录
3. Dagger 官方文档：Introduction
4. Dagger 首次公开发布公告（2022）
5. Dagger 官方 Changelog

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。