假設同一張 PR，第一次請 agent 檢查，它列出修改檔案、指出風險，還附上對應程式碼。第二次重跑，卻只剩一句「看起來沒問題」。如果這段話會進入合併流程，光把 prompt 存進 repo，幫助不大。

GitHub Copilot 的 Dynamic Workflows 正好讓團隊把流程本身寫成程式。但程式化的步驟，只能保證「輪到誰做事」比較固定；它無法替團隊決定，什麼證據才算交接完成。

先分清楚流程和判斷

Dynamic Workflows 目前是公開預覽功能。它以 Copilot extension 中的程式定義步驟、條件與 agent 之間的交接；確定性的工作可以交給程式，需要判斷的部分再交給 agent。這和 /fleet 每次由 Copilot 臨場拆解任務不同。流程可以重用，agent 的回答仍可能改變。

我會先拿一個小 repo 的 PR 檢查當試點，不急著讓 workflow 自動合併。輸入固定為這次 PR 的提交版本、變更檔案清單，以及要檢查的範圍；程式先整理檔案，agent 才審查指定項目。若 PR 又推了新 commit，就重新記下輸入版本，不沿用上次的「通過」。

真正需要團隊自己訂的是交接契約。以下是建議的驗收設計，不是 GitHub 內建欄位：

這裡有個陷阱：輸出格式正確，只能證明欄位存在，不能證明審查有抓到問題。先準備去識別化的測試 PR，刻意放入一個已知且可定位的錯誤，再確認 workflow 是否留下發現；另一筆正常改動則用來檢查它會不會亂報。這兩筆是驗收案例設計，不是本文已執行的測試結果。

重跑時，比對的是交接，不只是最終答案

workflow 改版後，保留前後兩次使用的輸入版本、流程版本和交接紀錄。人工檢查時，可以將去識別化的兩份交接文字放進文字差異比對工具，先以逐行模式看欄位或設定有沒有消失；比較設定文字時，先關閉忽略空白，免得縮排差異被藏起來。私有程式碼、token 和原始客戶資料不要貼入範例。

Diff 能提醒我們「未完成項」被刪掉了，卻不會告訴我們刪掉是否合理，也不能驗證交接格式、測試結果或程式安全性。決策仍得回到那次 PR 的證據。若 workflow 暫停後恢復，官方說明允許重用已保存的工作結果；沒保存的工作可能重新執行。因此每次重跑也要記清楚：哪些結果沿用、哪些步驟真的又跑了一次。

CLI 執行前，先把可做的事縮到最小

要從 CLI 重複執行既有 workflow，文件提供 copilot workflow run WORKFLOW-NAME；CLI 端仍須啟用 experimental 功能，而且 workflow 得先以 extension 或 plugin 的形式可用。更容易漏看的是：這個非互動命令不會跳出權限核准視窗。需要的工具或網址權限要事先以 --allow-tool、--allow-url 等方式明確授權；無法自動核准的要求會被拒絕。不要為了讓一輪檢查跑完就全面放權。

除了 agent 的工具權限，extension 程式本身也要 review。先用假資料在隔離環境確認讀取範圍、失敗時會不會停下來，再設定並行／總 agent 數與執行時間的限制。AI credits 限制是近似上限，不是能保證絕不超支的硬邊界。若流程拿不到必要權限，就把狀態與原因交回人處理，而不是把失敗當成零風險。

把流程寫成程式很值得做，尤其是需要反覆檢查的工作。但 PR 是否能合併，應該取決於這次輸入對應的證據和人的決策；workflow 跑完，只表示流程跑到了終點。

資料來源

• GitHub Docs：Dynamic workflows
• GitHub Docs：Using dynamic workflows
• GitHub Changelog：Dynamic workflows in Copilot CLI and the Copilot app