讓 Agent 參與發版：從探索測試到風險判斷

Lauren 在一則 X 貼文中分享團隊的發版流程：release manager Bot「sandcastle」向 PR 貢獻者收集阻礙、啟動建置，再安排十多個 Agent 操作應用程式。部分 Agent 沿著指定功能路徑測試，另一些隨機探索。發現高優先級問題後，工程 Bot「poteto」啟動 Cursor Project 接手分類與修復，作者再決定修正要進入 patch release，還是下一個一般版本。原始貼文

這個案例描述了工作如何交接，沒有提供覆蓋率、誤報率或發版後缺陷數據。因此，它適合用來分析流程設計；單靠 Agent 數量，還無法判斷 QA 的改善幅度。

貼文稱這組測試為「fuzz swarm」。從公開描述來看，它主要是在使用者介面上執行定向操作與探索式測試。這和 libFuzzer 這類以輸入樣本和程式碼覆蓋回饋驅動的工具，各有不同的觀察方式。UI 探索可能找出新路徑或異常，但若沒有另外量測，就無法從操作量推導程式碼覆蓋率。

把這個案例轉成可採用的 release pipeline，需要補上版本識別、行為判準、測試隔離與風險決策。以下是對案例的工程分析，不是作者團隊已實作全部措施的描述。

先讓每次測試對應到固定版本

啟動測試前，要先知道 Agent 操作的是哪個 commit、哪份建置產物，以及哪組部署設定。測試期間若同一個網址持續被新版本覆蓋，影片裡的錯誤就很難對應到某一次變更。

最小的版本紀錄可以包括 commit SHA、build ID 或產物 digest，再加上會影響行為的設定和測試資料版本。PR 清單方便向貢獻者收集資訊；最終驗證則要綁定實際準備發布的產物。

同時區分兩個情境：尚未發布的 release candidate 可以暫停；已經影響使用者的版本則可能需要先回滾、停用功能或限制流量，再準備 patch。兩者的處理時序不同。

功能地圖要連到獨立的行為判準

定向測試回答關鍵流程是否符合預期；探索式測試則尋找既有路徑之外的狀況。兩種結果都需要判準，例如需求中的權限規則、產品規格或資料一致性條件。

這個判準不能只從目前程式碼推回來。若程式碼已把退款金額算錯，Agent 讀取實作後把同樣結果寫成「預期值」，測試仍可能通過。驗證需要一個能判斷正誤的依據，測試領域常稱為 oracle。

作者在後續說明中，把流程的效果歸因於驗證技能。連結的 create-verification-skill要求盤點介面、啟動方式、驅動工具和可觀察證據，並建立每個功能的使用路徑與可觀察終態。這讓 Agent 有方法操作真實應用程式，也讓檢查結果可以被接手。

該指引要求實際跑過一個功能，以證明產生的驗證技能能運作。這證明的是技能本身可用；一次發版還須按變更影響和產品風險，選擇應執行的功能與情境。

平行測試需要可控的資料狀態

多個 Agent 若共用會被修改的帳號或資料，一個 Agent 的刪除、登出或設定變更，可能改變另一個 Agent 的測試條件。這時發現的異常，可能來自產品，也可能來自測試互相干擾。

因此，平行執行通常需要獨立測試帳號、資料命名空間或可重置的 fixture。執行 ID 和操作軌跡有助於追查問題，但它們無法阻止資料互相改動。必須共用狀態的測試，可以序列執行，或明確設計成併發情境。

對寄信、付款、刪除和外部 API 的操作，也要確認測試環境實際用了什麼服務與憑證。標示為 dry-run 的流程，仍需檢查它究竟跳過哪些副作用。前述驗證技能的指引也要求，透過檔案、網路或 Git 狀態觀察來確認，而不是相信模式名稱。

缺陷分流先看影響，再看版本來源

問題紀錄至少要讓接手者知道：受測版本與環境、觸發操作、預期與實際結果，以及日誌、畫面或資料狀態等證據。若已查出首次出現的版本，也一併記錄；尚未確認時，保留為未知。

「由這次發版引入」有助於定位原因，卻不是決定能否發版的唯一條件。既有的資料損毀、越權或重大安全問題，同樣可能使候選版本不可接受。

狀況	發版處理
影響超過團隊的阻擋門檻，不論新舊	暫停候選版本；若線上已受影響，先評估緩解或回滾，再安排修復
證據顯示影響有限，殘餘風險可接受	指定缺陷負責人、處理版本與接受風險的決策者
難以穩定重現，但存在重大影響跡象	保留軌跡並升級調查；按風險決定是否暫停相關發布
證據指向失效的測試環境或互相干擾	修正測試條件並重跑，暫不據此判定產品缺陷

難以重現，不等於誤報。間歇性的競態、資源耗盡或資料錯誤，可能只在特定條件下發生。此時要保留發生頻率、時間、狀態和證據；是否阻擋發布，仍由影響與不確定性共同決定。

修復後驗證最終產物

工程 Bot 可以接手分析和修改，release manager Bot 則可以追蹤修復進度。但 cherry-pick 到 release branch 之後，提交的上下文可能改變，原分支上的成功結果不能直接沿用。

修復合併或 cherry-pick 完成後，應從最終 commit 重新建置。先驗證原缺陷，再執行受影響範圍與關鍵流程的回歸檢查，並把結果綁定到準備發布的產物。這才能確認「被測過的版本」和「實際發布的版本」一致。

發版流程還需要明確的 go/no-go 決策者或預先授權政策，以及中止條件。Agent 可以在既定權限內重試與修復；超過時間、成本或風險門檻時，應回報目前證據與未解問題，交由負責人決定下一步。

用可比較的結果衡量流程

已確認且去重的缺陷數，可以描述有效發現的數量；重複回報率、重現成功率和待查問題則分開記錄。這些數字本身不能證明覆蓋率：沒有發現問題，可能是版本穩定，也可能是沒有測到重要區域。

若要看流程是否改善，可以比較：

• 預先定義的關鍵流程、角色和設定組合，有多少通過、失敗或尚未執行；
• 回報中有多少需要人工排除、補證據或重新分類；
• 發版後在一致觀察期間內，出現多少相關缺陷或事故；
• 每次 release 的驗證時間、運算成本與人工分流時間。

Agent 執行具有隨機性，評估時也要對代表性版本重複執行，和既有流程用相近條件比較。看到一次漂亮的結果，還不足以判斷長期收益。

這條 pipeline 最後應交付兩樣東西：對最終候選產物的驗證紀錄，以及每個未解問題的風險處置。Agent 增加探索與處理的能力；團隊用版本識別、行為判準和發版政策，把這些活動接成可追溯的決策。