GitHub 於 2026 年 10 月 1 日宣布 Dynamic Workflows 在 GitHub Copilot CLI、Copilot app 和 Copilot SDK 公開預覽。這項能力讓使用者以程式碼定義一個可重用的代理流程，把多個自動化步驟、工具呼叫和一個或多個 agent 組合起來；流程可以是順序執行、平行執行，或兩者混合。
GitHub 的說明把 Dynamic Workflow 和單次指令或 /fleet 分開。/fleet 著重把工作分派給多個 agent，而 Dynamic Workflow 則描述整個有明確階段的程序：每個階段可以呼叫命令、工具或服務，把結構化結果傳給下一階段，也可以在中途要求使用者輸入、等待人工批准，或讓一個 subagent 驗證另一個 subagent 的結果。這令代理協作更接近一個可閱讀、可測試和可重複執行的流程定義。
實際上，這種結構適合有清晰入口、步驟和完成條件的工作。例如事故資料整理可以先收集 log，再平行分析不同服務，最後由另一個 agent 彙整和檢查；版本發布檢查可以把測試、依賴、變更摘要和人工批准放在同一條流程；程式碼審查或大型 codebase sweep 亦可以把工作拆成多個可觀察的階段。對需要長時間執行的研究、計劃及修改任務，檢查點和結構化交接尤其重要。
Dynamic Workflows 的價值不只是讓 agent 數量增加，而是令「怎樣協作」成為可管理的程式資產。流程可以固定允許的工具、輸入格式、重試或停止條件，並把結果留在明確的階段邊界。這有助於降低每次重新描述流程的成本，也讓團隊有機會比較不同版本的工作流，而不是只比較一次對話的最後答案。
不過，公開預覽仍然不代表每種任務都適合自動化。流程越長、工具越多，越需要處理權限、錯誤恢復、部分完成、重複執行和敏感資料傳遞。團隊應先在低風險及可重設的工作中驗證，為每個階段設定可檢查的輸出，並在付款、刪除、發佈或修改生產環境前保留人工批准。GitHub 亦指出 CLI 的使用需要開啟實驗性功能，而 Copilot app 的介面則可直接使用預覽能力；具體功能和限制仍可能變更。
今次更新顯示 agent 工程正由「叫幾個代理同時做事」走向「把一條代理程序寫清楚」。對企業而言，最值得先建立的不是最複雜的多代理系統，而是幾條有明確輸入、輸出、驗證及責任邊界的可重用流程，再逐步加入並行化和更高程度的委派。
