Dagger 1.0 beta：AI 寫完程式後，如何減少 CI 等待與重跑？
Dagger 1.0 beta 讓 AI 程式代理共用本機與遠端測試，加入官方模組、逐測試結果、失敗終端機與 GitHub 檢查。整理增量執行、快取計價及 0.x 遷移限制，判斷能否縮短 CI 等待。
AI 已經把程式改好，開發者卻還在等雲端測試。測試失敗時，代理又得從長日誌找原因，修改後再推一次，工作速度便取決於這段往返。
Dagger 在 2026 年 10 月 23 日宣布 1.0 beta，希望把同一套建置與測試放進本機、遠端與推送後的檢查流程。這次仍是測試版，官方也邀請社群用自己的專案找出相容問題。
它的重點不只是換一台更快的機器，而是把測試、產物、相依環境與快取放在同一個執行模型，讓代理看見哪一項失敗，並重跑需要的部分。
這也改變導入時要驗收的東西：原有工具設定如何被讀入、失敗環境能否重現、遠端執行送出哪些資料，以及舊版命令如何遷移。
我的判斷是，已有 CI 的團隊可以先讓一項常用檢查在兩個環境得到一致結果，再決定要搬多少流程。官方效能數字不能代替自己專案的等待時間。
先看 Dagger 為什麼要把「一個工作失敗」拆成「哪個測試、在哪個環境失敗」，才能理解後面的快取與遷移。
Dagger 1.0 beta 先解決哪一段 CI 往返？
Dagger 想讓代理在推送前後使用同一套建置與測試，減少推送後才發現環境不同的往返。CI 是持續整合，會在程式改動後自動執行檢查，讓團隊知道修改是否破壞原有功能。
當代理連續修改程式，檢查的次數也會增加。如果每次都要上傳、排隊、重新建立環境，代理寫得再快，也無法略過這些等待。失敗後還得讀日誌，才能知道問題出在程式還是環境。
官方發布文把目標放在縮短這段回饋。原本只在雲端執行的檢查，可以先在開發環境執行，再由遠端引擎接手較大的工作，推送後仍沿用相同流程。
這代表開發者不必為了「先看測試過不過」才建立一次提交。若本機已能呈現錯誤，代理便能帶著檢查結果繼續改，減少為了取得資訊而反覆推送。
這也有助於把代理的時間花在修正上。若它每輪都重新讀大量沒有分類的紀錄，就得一再還原同一份背景。測試結果附帶環境與輸入，才更接近可以立即採取動作的資訊。
同樣在處理測試等待的 Jog 專用執行器偏向硬體與執行資源。這次更新則把工作如何描述、哪些結果能重用，一起納入執行模型。
延伸閱讀：Jog 把 CI 搬到專用硬體：AI 寫程式變快後，測試等待怎麼算？
要做到這件事，檢查必須先從不透明的腳本，變成能辨識輸入與結果的工作。
官方模組與工作區如何接回原有工具？
新版用工作區載入官方或自訂模組，讓模組讀取原有工具設定，找出程式、容器與測試等產物。工作區通常對應一個程式儲存庫，設定檔 dagger.toml 決定要載入哪些能力。
模組可以理解為一組可重用的開發工具接法。官方已維護 Go、pytest、ESLint 與 Playwright 等工具的模組，因此採用者不必先寫完自己的整合程式，才能開始執行檢查。
這些工具原本各自負責編譯、測試或檢查程式風格。模組讀取它們既有的設定，能減少「工具已改、CI 裡另一份設定卻沒改」的落差，讓專案原本的規則繼續發揮作用。
系統再把來源檔、容器、產生的檔案和測試結果視為不同類型的產物。類型讓程式知道眼前的是可執行容器還是測試結果，而不必把所有內容都當成一段終端機文字。
例如，團隊可以選取測試結果作為合併前的關卡，也可以選一個建置中的容器開啟檢查環境。兩者使用同一份專案脈絡，卻對應不同的下一步工作。
當測試成為可單獨辨識的產物，失敗後便不必只面對整份工作日誌。
測試原生 CI 與失敗現場，為何會影響代理修正？
官方模組可以辨識並個別回報測試，開發者也能在命令失敗當下的容器狀態開啟終端機。容器把程式及其執行環境放在一起，方便保留錯誤發生時的條件。
以一個假設的網站專案為例，畫面測試失敗時，只知道「測試工作失敗」還不足以修正。代理需要知道哪個測試、預期與實際結果差在哪裡，才能判斷是畫面改錯還是測試條件需要更新。
Test-native CI 說明讓每個測試可以分別呈現並重新執行。定位完成後，代理可以先驗證受影響的測試，再依團隊規則跑較完整的檢查，避免每輪修改都從頭找問題。
測試需要資料庫時，環境也要能重現
整合測試通常還需要資料庫或服務端點。新版允許測試呼叫模組建立自己的依賴，讓測試所需的環境更接近測試本身，減少開發環境與雲端各維護一套啟動方式。
若命令失敗，dagger check -i 可在失敗狀態開啟互動終端機。這能保留當時看到的檔案與容器條件，讓人直接查看原因，而非只憑另一台電腦上的成功結果猜測。
能指出失敗測試與保留環境，才有條件減少重跑範圍，而重跑成本接著取決於快取與執行安排。
增量執行、快取與效能數字該怎麼看？
Dagger 以延後計算的相依圖安排隔離函式，官方也公布幾項操作耗時改善，但各項測量並非整個產品的統一倍速。相依圖會記下工作需要哪些輸入，以及哪些產物建立在其他結果之上。
當使用者要求一個結果，系統才計算取得它所需的部分。快取則保存可重用的結果，讓相同條件下的工作有機會直接取用，減少一再產生相同產物的成本。
這也說明為何工作描述重要。若檢查只是一大段看不清輸入的腳本，便難以知道哪部分沒變。拆成能辨認的工作後，才有條件對照輸入與重用結果。
官方列出的兩項操作測量如下，它們只能解釋對應項目的改善。
| 操作 | 官方舊耗時 | 官方新耗時 |
|---|---|---|
| 同時執行一千個容器 | 三十五至六十一秒 | 十六至十七秒 |
| 收集三百個檔案 | 十一點八秒 | 一點一秒 |
對大量細碎檔案或容器的工作，這些差距可能影響回饋速度。但真實流程還包含下載、網路服務與測試本身，不能把其中一個比值直接套在整段 CI。
團隊比較時，可以分開記錄首次執行、相同輸入重跑與修改一個檔案後的結果。這樣才能知道節省來自操作開銷、快取，還是原本測試就比較少。
減少重做並不代表所有工作都留在自己的電腦，遠端模式需要另外理解檔案與憑證如何傳遞。
遠端執行與 GitHub 檢查如何接上？
同一條流程可以交給自架或 Dagger Cloud 引擎，Cloud 也能接收 GitHub 事件並回報檢查狀態。這讓本機負責操作，較重的建置則在遠端執行。
官方說明遠端模式會按需要傳送本地檔案、秘密憑證、網路通道與終端機資料。因此，採用遠端也包含資料流的選擇，不能只因命令仍在自己電腦輸入，就認為內容沒有離開本機。
對團隊來說，要確認的是選用哪個引擎、哪些資料會送過去，以及遠端如何取得測試需要的服務。官方宣稱執行有隔離保護，但專案仍要按自己的資料範圍安排使用方式。
GitHub 整合則讓 Cloud 在推送後直接跑檢查，再把狀態送回儲存庫。它可取代這些檢查原本使用的 Actions 工作流程檔案，並不表示儲存庫裡其他用途的工作都會自動搬好。
例如，部署通知與測試可能原本寫在同一份工作流程裡。搬出檢查後，團隊仍得決定通知由誰發出、部署在哪個條件才開始，避免把檢查成功誤當成整個交付流程完成。
Cloud 新定價按每條流程實際資源用量計費，閒置容量免費。官方也說，可由快取提供的操作價格低五倍，無論該次是否真的命中快取。這與整體帳單低五倍是不同的計算。
採用遠端前，要連同資源用量一起判斷。若流程只是移到另一個地方重新做相同工作，仍要回頭看模組、快取與檢查安排是否發揮作用。
0.x 升級要一起調整哪些檔案與命令？
官方遷移文件允許逐步保留舊設定，但新版改變若干命令語義，並把工作區與模組設定拆成兩個檔案。既有使用者可以先升級命令列工具，確認原專案仍能執行，再進一步轉換。
要先處理的是同名命令做了不同事情。例如新版 dagger shell 會開啟容器或目錄的終端機，舊的模組建立與依賴安裝命令也有調整，所以不能只更換執行檔就忽略腳本。
官方遷移指南把原本兼任兩種角色的 dagger.json 拆開。dagger.toml 管理工作區，dagger-module.toml 描述模組，讓使用專案與提供能力的設定分別清楚。
轉換前可用 dagger workspace migrate --no-apply 看差異，確認後再選擇套用。官方建議從乾淨的版本控制狀態開始，因為一份集中的修改較容易看出哪些變動來自遷移。
模組還需要重新產生 SDK 程式碼。SDK 是讓程式呼叫另一套系統的開發工具，新版要求提交產生的檔案，缺少它們可能讓模組無法載入，不能只提交那兩份設定。
模組若直接放在儲存庫根目錄，官方另要求明確載入該模組，轉換工具也會產生報告。這類差異會影響原本依賴預設位置的命令，適合連同呼叫它的腳本一起檢查。
使用秘密憑證儲存服務的專案也要留意路徑格式。遷移文件指出，新版的 Vault 憑證位置必須包含掛載名稱，原先依賴預設名稱的設定需要補齊，否則測試環境可能拿不到所需資料。
生成程式碼的步驟也要放進日後維護方式。模組有改動時仍需重新產生並提交結果，這把原本執行時才發生的工作，提前成為可以一起審查的檔案變更。
根目錄模組與部分舊介面另有例外，應沿指南處理。設定轉換後還要產生並提交程式碼，原有檢查能重新跑通，才算完成遷移。
這份驗收最好沿用升級前真的會執行的命令。新範例成功只能證明範例可用，原專案可能還帶著自己的依賴位置、憑證來源與工具設定，需要用同一份工作重新確認。
什麼結果足以支持把既有 CI 搬過來？
對既有團隊，最有說服力的結果是同一個失敗能在本機重現、修正後只重跑必要工作，且資料與用量都在可接受範圍。這些結果可以直接對照開發者每天等待的那一段流程。
如果一個專案目前主要時間花在外部服務回應，換成增量建置也未必改善同樣幅度。相反地，若時間花在反覆建立環境、重做相同產物與讀大段日誌，新執行模型就更切中問題。
我會選一項最常失敗、又能在本機重現的檢查作為遷移起點，保留修改前後的執行紀錄。等到失敗資訊、重跑範圍與費用都能說清楚，再擴大搬移其他工作。
檢查流程的改善也需要配合審查責任。AI 程式驗收教學說明人工審查與測試各自能找哪些問題，能補上工具之外的判斷。
延伸閱讀：AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤
Dagger 1.0 beta 的價值，最終要落在更短且看得懂的回饋循環。已經有穩定流程的團隊，可以沿官方遷移差異逐項評估，保留測試版相容問題的回退空間。
常見問題 FAQ
Dagger 1.0 beta 已經可以當穩定版嗎？
官方仍在收集相容問題，並未宣布穩定發布。既有專案可依官方遷移指南逐步評估，尤其要一起核對命令語義與產生的程式碼。
一定要使用 Dagger Cloud 嗎？
官方說明流程可在本機或自架遠端引擎執行，Dagger Cloud 是提供雲端執行與 GitHub 檢查的選項，採用時另看其用量與資料安排。
可以直接沿用原本測試嗎？
官方模組以讀取原工具設定及辨識測試為方向，但自己的工具版本、依賴與自訂腳本仍要驗收。測試能執行和整個專案已完成遷移，是不同範圍。
