TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Dagger 1.0 beta 把 CI 拆到單一測試，AI 代理少等少重跑
Dagger 在 2026 年 10 月 23 日公開宣布 1.0 beta，把建置、測試與快取收進同一個執行模型：測試從日誌文字變成可單獨辨識、可單獨重跑的單位，AI 程式代理能列出每個測試、只重跑失敗那個、在失敗現場開終端機。官方模組目錄現有 14 個，效能數字全部是操作級測量，Cloud 改按實際資源用量計費，0.x 遷移則有多項破壞性變更。
用 AI 摘要這篇文章：
Dagger 在 2026 年 10 月 23 日公開宣布 1.0 beta。這個以容器起家、開源五年都停在 0.x 的建置引擎，這次把自己定位成接在 Jenkins 與 GitHub Actions 之後的下一代 CI，對準的問題很具體：AI 程式代理寫碼的速度上來了，驗證程式的 CI 卻還是上傳、排隊、讀長日誌那一套。1.0 beta 的核心改動，是把測試從日誌裡的一段文字，升級成系統看得見、可以單獨重跑的單位。
這跟兩種人直接有關：已經讓代理大量寫碼（例如用一個看板同時管住十多個代理的團隊）、發現日常變成等雲端檢查的開發者；以及正在評估 CI 要不要搬家的技術主管。以下整理這次實際改了什麼、效能數字怎麼讀、以及現在還不能期待什麼。
10 月 23 日的宣布文，替五年的 0.x 定下時間點
宣布文由 Dagger 創辦人 Solomon Hykes 署名，10 月 23 日發在官方部落格；官方 X 帳號同日發出宣布貼文，依貼文 ID 解碼的時間是當天 15:51 UTC，訊息內容與部落格一致。官方給自己的定位一句話講完：接在 Jenkins 與 GitHub Actions 之後的下一代 CI，為了配合程式代理（coding agent）的速度與規模而設計，不浪費算力與 token。
有兩個時間點值得先對齊，因為它們決定你該用什麼態度看這則新聞。
1.0 的 beta 標籤不是這禮拜才開始跑。GitHub 儲存庫的標籤紀錄顯示，v1.0.0-beta.1 打在 2026 年 5 月 29 日，到宣布當天已經迭代到 beta.21。10 月 23 日發生的事情是公開宣布：把這五個月的累積正式端上檯面，推出新定價與新版文件。也就是說，你現在裝到的 beta 不是第一天出生的實驗品，但也還在每週多次的快速迭代裡。
舊的 0.x 線也還活著。宣布前兩天的 10 月 21 日，儲存庫剛發布 v0.21.11；官方遷移文件明言 1.0 可以原樣執行 0.x 專案，一個專案可以一步一步搬。兩條版本線並行，對既有使用者是緩衝，對新接觸的人則代表文件會同時存在新舊兩套命令，查資料時要認清楚版本。
順帶一提，官方部落格 9 月 15 日先發過一篇長文，論點是買更大的機器救不了 CI 瓶頸，問題出在 CI 平台本身的執行與資料模型。10 月的宣布文就是那篇論述的產品答案，兩篇對照著看，可以看出這次改版想解的到底是誰的問題。
官方把浪費拆成四種，根因都是 CI 看不懂自己的工作
要理解 1.0 改了什麼，先看官方在宣布文裡對現況的診斷。今天的 CI 不管跑在哪，剝掉專有名詞之後本質都是「在伺服器上跑腳本、讀輸出」。GitHub Actions 用拋棄式虛擬機跑，Jenkins 時代機器在機房，模型沒有變。官方把這個模型造成的浪費列成四項：機器只能靠超額配置應付尖峰，平常閒置；腳本分不出哪些輸入變了，同樣的產物一再重算；檢查在開發環境和 CI 行為不一致，代理只能先推再說，每一輪往返都燒 token；日誌巨大又沒結構，看不出哪個測試失敗、用了多少資源、環境裡有什麼依賴，代理每輪都從頭重建這些脈絡。
1.0 對這四項給的是同一個答案：讓 CI 的每份產出變成有類型的東西。模組（module）直接讀你工具的原生設定，例如 Go 的專案設定、pytest 的設定檔，不必為 CI 再維護一份；專案被描述成有類型的產物（typed artifact），原始碼、容器、執行檔、測試結果都各自是可辨識的單位。系統記得每個產物由哪些輸入算出來，需要的時候才計算，輸入沒變的結果直接重用。官方稱這套安排為延後計算的相依圖，白話說就是：把「跑一堆腳本」換成「記帳」，帳本上每筆都寫清楚從哪來、算出什麼。
這個資料模型是底下所有功能的共同地基。測試能被單獨看見，是因為測試結果是有類型的產物；失敗現場能保存，是因為執行環境本身也在模型裡；快取能精準重用，是因為輸入有被記下來。
測試不再是日誌裡的文字，是可以單獨重跑的單位
Test-native CI 是這次宣布的主打賣點之一，官方的說法是「Dagger 看見你的每個測試，而不只是跑它們的那個工作」。實際的命令長這樣：dagger check -l 列出專案裡每個測試；dagger check –go-test=TestGet 只重跑指定的那一個。粒度依工具而異，Go 可以逐測試指定，Vitest、Jest、Playwright 與 pytest 以檔案為單位。測試本身不用改。
每個測試在執行紀錄（trace）裡有自己的狀態、耗時與日誌，並附一個重跑相同測試的連結。底層用的是 OpenTelemetry 的標準測試屬性，官方模組跑測試時自動加上；如果你的測試工具本來就會送這些屬性，也直接相容。對代理來說，這代表失敗回報從「job 紅了，去讀三千行 log」變成「第 14 個測試的斷言差在哪」，來回的 token 與等待都省下來。
要讓模組找得到測試，靠的是官方模組目錄。宣布文點名 Go、pytest、ESLint、Playwright 四個，實際文件站上的目錄到 10 月 27 日有 14 個：Go、golangci-lint、Staticcheck、Deno、Jest、Vitest、Playwright、ESLint、Prettier、Biome、Pytest、ShellCheck、PSScriptAnalyzer、Helm。安裝一行命令，例如 dagger module install dagger.io/go。這個設計等於官方把常用工具的接線先接好，你的規則留在原設定檔裡，不會出現工具改了、CI 裡另一份設定沒跟著改的漂移。讓設定只維護一份的思路，與把同一份設定同步給八種 AI 工具的開源做法是同一個方向。
失敗的現場也被保存下來。dagger check -i 直接在命令失敗當下的狀態開一個互動終端機，檔案與容器條件都是出事當時的樣子；dagger shell 則可以在工作區提供的任何容器裡開終端機。除錯不再靠另一台機器上的成功結果反推。
整合測試需要的依賴也有新解法。過去資料庫或 API 伺服器由 CI 工作或 docker-compose 在測試外面架好，開發環境與 CI 各寫一套。1.0 讓測試可以呼叫模組自己把依賴開起來，同一份測試在哪跑都一樣。這對「本機重現不了 CI 的失敗」這類老問題是直接的改進。
效能數字要一項一項讀，官方沒有給整體倍速
changelog 列了七項操作級的改善，全部附上對應的 GitHub PR 連結：
| 操作 | 官方舊耗時 | 官方新耗時 |
|---|---|---|
| 1,000 個容器同時執行 | 35 至 61 秒 | 16 至 17 秒 |
| 收集 300 個檔案 | 11.8 秒 | 1.1 秒 |
| 大目錄裡單一檔案的 checksum | 255 毫秒 | 15 毫秒 |
| CLI 連線 | 607 毫秒 | 476 毫秒 |
| 41 個模組的工作區載入 | 基準值 | 快 30% |
| 100 個容器序列啟動（改用 crun） | 基準值 | 快 40% |
| Dang 模組每次呼叫 | 170 毫秒 | 72 毫秒 |
這些都是單一操作的測量，沒有一項是整條 CI 的倍速。真實流程裡還有下載、外部服務回應與測試本身的時間，把其中一個比值套到整條流程是誤讀。如果瓶頸落在下載端，也有人用把 GitHub 與 AI API 的拉取改走快取的思路處理，那與執行模型是兩件事。官方也沒有對外宣稱整體提速多少，這個空白是誠實的，採用前值得照這個分法量自己的流程：首次執行、相同輸入重跑、改一個檔案後重跑，三個時間點分開記，才知道節省來自操作開銷、快取，還是本來測試就少。
表格裡的 Dang 是官方自家的腳本語言，這次所有官方模組與 SDK 執行環境都改用純 Dang 撰寫，你自己的模組仍然可以用 Go、Python、TypeScript 等 SDK 語言寫，不必學它。
遠端引擎與計費：離開本機之前先看資料流
同一套檢查可以交給遠端引擎執行，引擎有三種選擇：用 SSH 連自己的機器、連 Kubernetes 叢集，或直接用 Dagger Cloud 的代管引擎。官方的賣點是本機與遠端共用同一個模型，較重的工作丟出去，本機留給互動操作。
採用遠端之前，官方文件裡有一句話值得逐字讀：遠端模式會按需要串流本機檔案、秘密（secrets）、網路通道與終端機內容。命令列是在自己電腦上敲，內容卻可能離開本機。要確認的事情因此很明確：哪些檔案會送過去、秘密怎麼傳遞、測試需要的內部服務遠端怎麼拿到。官方稱執行全程有沙箱隔離，但資料範圍的安排仍然是你自己的決定。
Dagger Cloud 同時接上了 GitHub。Cloud Checks 可以直接接收 GitHub 事件，每次 push 跑檢查並把狀態回報給儲存庫，啟用只需要在儲存庫裡跑 dagger cloud checks on。官方明言這取代的是檢查用的 GitHub Actions，不需要 CI workflow file，也不需要額外的第三方服務。注意範圍：被取代的是檢查這一段，原本寫在同一份 workflow 裡的部署、通知之類的其他工作不會自動搬家，那些要另外安排。
計費模式跟著新架構重算。Cloud 按每條流程實際用掉的資源計費，閒置容量免費；四個計價軸是 CPU（每 CPU 分鐘 0.5 美分）、記憶體（每 GB 分鐘 0.5 美分）、輸入流量（每 GB 2.5 美分）與輸出流量（每 GB 10 美分）。最有設計感的一條：凡是輸入與最近 30 天內跑過的操作相同的，一律以五分之一價計費，無論快取實際上有沒有命中。官方自己解釋了動機，這個定價獎勵把流程最佳化的人，也獎勵官方去加速它。計量方式也寫得公開：CPU 取自 Linux cgroup 的 cpu.stat，記憶體每秒取樣，輸入流量計 git 物件、容器映像、HTTP 抓取與本機檔上傳。
方案層另有門檻：Starter 每月 20 美元（單人，追蹤紀錄保留一個月）、Scale 每月 200 美元（無限人數，保留一年）、Enterprise 客製，帳單金額取方案價與實際用量中較高者。評估成本時，這個最低消費別漏算。
0.x 使用者的遷移帳單，與官方給代理加的安全閘
1.0 有破壞性變更，官方沒有迴避：核心引擎與 API 不變，但不少命令列命令換了語義。dagger 不帶參數現在印用法，原本的 Shell 要改用 dagger -c；dagger shell 現在是對容器或目錄開終端機；dagger init 改成建工作區；dagger develop 移除；dagger update 會直接失敗並指給你替代命令。寫進腳本與 CI 工作裡的舊命令要跟著清。
設定檔從一個變兩個。原本身兼兩種角色的 dagger.json 拆成 dagger.toml（工作區設定）與 dagger-module.toml（模組清單）。遷移有工具幫忙：dagger workspace migrate –no-apply 先看差異，確認後再套用；官方建議從乾淨的版本控制狀態開始，讓遷移變成一份可審視的 diff。兩個細節容易踩坑：1.0 模組不再在執行時生成 SDK 程式碼，生成的檔案要提交進儲存庫，缺了模組會直接載入失敗；模組放在儲存庫根目錄的專案，之後要加 -m . 明確載入。用 Vault 管秘密的專案，路徑也要補上掛載名稱。
遷移文件裡有一節標題就叫 Coding agents，寫得相當直白：當系統偵測到正在執行遷移命令的是程式代理，會強制它先做明確選擇，要嘛 -y 套用，要嘛 –no-apply 只看不動，不讓代理預設默默改檔。一個 CI 工具把「代理會來動我的遷移」當成必須設計進去的情境，這本身就是這波代理化開發的註腳。宣布文甚至附了一段可以直接複製給代理用的提示詞，讓代理替你把本機檢查、快取驗證與 Cloud 設定一次跑完。
現在能做什麼，以及還不能期待什麼
先講清楚狀態：這是 beta，官方自己說得明白，他們無法拿你的私有儲存庫測試，請你在本機的專案 checkout 上試跑，壞了上 Discord 回報。changelog 上另有一排掛著 Coming soon 的項目：跨引擎共享的分散式快取、把大型測試套件拆到多引擎的測試拆分、只跑受變更影響檢查的 Smart checks、把自家機器接進 Cloud 的自帶算力、arm64 引擎。這些都還是承諾，不是功能。
還不能期待的：穩定版的時程沒有日期；整條 CI 的提速幅度沒有官方數字；宣布文上 Typesafe、Fastly、Nvidia 等公司名單屬官方頁面單方刊載的宣稱。檢查的速度只是代理工作線的下游，上游的設計品質也有人用讓另一個代理在動工前先審設計的開源做法補強，兩者解決的是不同段落的問題。背景資料方面，dagger/dagger 儲存庫目前約 16,500 星、Apache-2.0 授權、2019 年建立、主要語言是 Go；開源引擎與商業雲端是並存的兩塊，用開源部分不強迫上雲。
回到一開始的判斷題。官方列的四種浪費剛好可以當檢查表：如果你團隊的等待主要花在反覆建環境、重算一樣的產物、讀大段日誌找哪個測試掛了，1.0 的執行模型正對這些；如果等待主要來自外部服務的回應速度，換執行模型幫助有限，先量再說。beta 階段的合理姿態是拿一個儲存庫在本機試，對照新舊命令的差異，把找到的相容問題回報給官方，這正是官方這次公開宣布想換到的東西。
