什麼是 GitHub Copilot 計畫模式

已完成

Visual Studio Code 中的 GitHub Copilot 提供三個內建代理，每個代理在不同程度的自主性下運作，並與你的工作空間有不同的關係：

• 代理：完全自主的實作代理。 它將目標分解成子任務，執行工具呼叫（檔案讀寫、終端機指令、MCP 伺服器呼叫），並直接將變更套用到你的工作區。 代理迴圈會持續運作，直到目標達成或遇到無法解決的模糊狀態。
• Ask：一個無狀態的問答系統代理，擁有唯讀的工作區域訪問權限。 它能推理你的程式碼、解釋概念並提出方法，但從不撰寫或執行任何東西。
• 計畫：一種以推理為優先的代理程式，以審慎的雙階段模式運作。 研究與綜合先行，接著是實施，兩者之間必須有人工審查門檻。

對營運工作來說，重要的區別不僅僅是安全。 關鍵在於人類判斷在能動迴圈中的位置。 使用代理人後，您會對產出進行事後審查。 在計畫代理人手中，您先審查並核准方案，然後才進行單一修改狀態的工具呼叫。

計畫代理人內部運作方式

計畫代理人是更廣泛代理人模式中的一個實例，稱為 「計畫與執行」，其中對該做什麼的推理與執行是分開的。 了解代理在每個階段如何蒐集資訊，有助於你撰寫更好的提示，並更批判地解讀其輸出。

第一階段：背景蒐集

當你提交提示時，計畫代理人不會立即產生計畫。 它首先透過依序呼叫一組唯讀工具，建立環境的上下文模型：

• Workspace 檔案列舉：代理會掃描你的工作區檔案樹以了解專案結構。 包含哪些語言、框架和設定檔。
• 目標檔案閱讀：根據檔案樹，代理會讀取與你請求相關的檔案。 對於基礎結構提示，它會讀取現有的 Bicep 模組、參數檔，以及任何 bicepconfig.json。 對於 PowerShell 提示詞，它會讀取現有腳本、模組清單和 PSScriptAnalyzer 設定。
• 自訂指令：代理程式會 .github/copilot-instructions.md 讀取該指令是否存在於工作區根目錄中。 此檔案被視為權威性上下文，會影響代理程式在該工作區中產生的每一個計畫。
• 會話記憶體：代理程式會讀取 /memories/session/ 來獲取這段對話中先前的上下文。 之前的計畫、釐清問題的回答，或你之前提到的事實。

此階段不會對文件網站或 API 進行外部網路呼叫。 代理對 Azure 服務、PowerShell API 或 Bicep 語法的了解來自訓練資料，而非即時查詢。

第二階段：釐清問題

若第一階段所蒐集的背景不足以產生明確計畫，代理人會提出釐清問題。 這些問題不是隨機產生的。 它們對應於實施過程中的決策點，不同答案會導致有意義的不同計畫。

對於操作提示，典型的決策點包括：

• 範圍：目標是哪個訂閱、資源群組或伺服器？
• 相依關係：新資源是否需要引用已存在的東西，還是應該自行建立相依？
• 限制：是否有命名慣例、合規要求或預算限制排除某些方法？
• 測試策略：計畫中應該包含試演或假設驗證步驟，如果包含，應該針對哪個環境？

代理人提出的問題品質是一個有用的訊號。 如果代理人不問任何澄清問題，卻立即針對複雜且未明確說明的提示提出計畫，則應對最終計畫加以審視。 它做出的假設可能與你的環境不符。

第三階段：計畫綜合

在足夠的脈絡下，代理人會綜合出一個結構化的計畫。 這其中涉及推理：

• 相依順序：必須建立哪些資源或設定步驟，其他人才能參考。
• 風險面：哪些步驟可逆，哪些不可，以及驗證閘門應設置在哪裡。
• Tooling alignment：根據限制條件及工作空間中現有的模式，哪些Azure CLI指令、PowerShell 指令或Bicep結構是合適的。
• 驗證結束：哪些證據能證明每一步都成功，以及如何在不需人工介入的情況下收集這些證據。

計畫輸出會自動寫入 /memories/session/plan.md，使其可在後續對話中隨時參考。

第四階段：迭代

該計畫在第一次生成後尚未定案。 你提交的每個後續提示都會讓代理人重新進入合成階段，並更新上下文。 包括先前的計畫、你的回饋，以及你引入的任何新限制，都會被納入考量。 代理人不會從頭開始;它將先前的計畫視為可修改的先行計畫。

這個迭代迴圈是計畫模式在營運工作中獲得最大價值的地方。 對話中出現的需求可以納入，而不會失去先前回合建立的脈絡。

存取計畫代理程式

您可以透過兩種方式聯繫 Plan 代理人：

• 代理人選擇器：打開聊天視窗（Ctrl+Alt+I），並從代理人下拉選單選擇 「計畫 」。
• 斜線命令：在聊天輸入框中輸入 /plan，然後輸入你的任務描述。 例如：

/plan Create a PowerShell script to audit all expired user accounts in Active Directory

計畫的樣貌是什麼

當計畫代理人產生計畫時，通常會產生三個部分：

• 摘要：對於計畫的達成目標及其採取方法的一個高層次概述。 本文旨在讓技術實作者與非技術利害關係人都能理解。
• 實作步驟：有序的任務描述要建立或修改哪些檔案、撰寫哪些程式碼，以及元件如何彼此連接。 步驟的順序會尊重依賴性。 例如，必須先存在一個子網路，NSG 才能參考它。
• 驗證步驟：確認實作工作正確性的行動，例如執行 az deployment what-if、驗證 DSC 是否符合， Test-DscConfiguration或部署後檢查資源健康狀況。 驗證步驟有明確範圍，能在不需生產環境存取的情況下執行。

例如，如果你請 Plan agent 建立 Azure 資源群組標籤政策，該計畫可能會包含建立政策定義 JSON 檔案、將政策指派給管理群組，以及執行 Azure CLI 指令驗證合規性的步驟。

設計圖存放地點

計畫代理程式會自動將其實施計畫儲存到會話記憶體檔案/memories/session/plan.md中。 你可以透過指令面板中執行 「聊天：顯示記憶體檔案 」指令並選擇 plan.md來存取此檔案。 因此，因為對話結束時會清除會話記憶，計劃無法在後續會話中使用。 如果你需要保留計畫，請在關閉工作階段前將其複製到資料庫中的檔案。

方案模式與代理模式

計畫模式與代理模式的差異主要不在於能力。 兩者都能使用相同的底層模型。 差異在於人類審查閘門在代理迴圈中的位置，以及每種模式所遵循的副作用契約。

尺寸	計畫代理人	代理程式
推理時的副作用	沒有;僅限閱讀	寫入檔案、執行指令、呼叫工具
人類審查閘門	在任何實作開始之前	實施完成後（若在此過程中發生錯誤）
任務中狀態的可逆性	永遠可逆;沒有做任何更改	這取決於執行了什麼
適合變更管理工作流程	是的，計畫就是提交審核的成果物。	不；輸出是成品，可能已經被套用。
上下文視窗的使用	較低；實作步驟不會產生工具呼叫結果	更高層次; 從工具調用中累積結果
歧義處理	在繼續之前，會將不明確之處轉化為問題提出。	會做出假設並繼續執行；可能會失敗或需要回滾。

對營運團隊而言，實際意義是：當任務涉及多個相互依賴的資源、不可逆的步驟（如資料庫架構變更或防火牆規則修改），或需要文件化的核准流程時，計畫模式在結構上是正確的選擇，而不僅僅是較安全的選擇。

當任務有限制、工作區狀態易於恢復，且快速迭代比預先核准的方法更重要時，請使用 Agent 模式。

交由實作

在你確定計畫後，你有幾個選擇可以繼續：

• 在同一工作階段實施：選擇「開始實作」，讓代理程式直接在您的工作區中實作計畫。 代理會接收計畫文件作為初始上下文，並開始執行實施步驟。
• 繼續在 Copilot CLI：選取 [開始實作]>繼續在 Copilot CLI 以在背景工作階段上執行此實作。 Copilot CLI 建立 Git 工作樹；在目前所在的提交版本，將您的存放庫建立一個獨立的副本。 因此程式實作是在一個乾淨的狀態中執行，且不會影響到你的工作樹。
• 在雲端代理程式中繼續：交由在 GitHub 基礎結構上執行的 Copilot 雲端代理程式處理。 雲端代理負責實作實際計畫、開啟拉取請求、建立 CI/CD 管線，並建立可稽核的核准紀錄。

交接機制在架構上非常重要：撰寫到/memories/session/plan.md的計畫文件成為實作代理人的任務規範。 計畫的品質與具體性直接決定執行品質。 模糊的計畫會導致模糊的實作，而帶有明確驗證閘門的計畫會讓實作代理在每個閘口暫停並驗證後才繼續。