在這一系列探討 AI 助理與代理應用的文章中，已經深入剖析了眾多核心心法與建構的基本原則，從最初賦能個人的 no-code、low-code 工具，到後來整合多方資源、面向企業級應用的整體解決方案，感受和實作了生成式AI技術的多個方案如何一步步降低門檻，提升多個業務單位的生產力天花板。

然而技術的演進不僅僅是工具的升級，對開發者而言過去的重心常放在撰寫規格書、設計架構，或直接生成程式碼，但在生成式 AI 的時代，這樣的角色正逐漸轉變。

不再只是「寫」程式或「描述」需求，而是透過指令去「構思」與「引導」整個生成過程，指令不再只是命令，而是一種新的設計語言，這樣的使用思維承載了意圖、邏輯與風格，進而成為與 AI 協作的核心介面。

因此今天會嘗試一次思維上的角色轉換，不再單純作為「使用者」或「開發者」去操控工具，而是化身為「指揮家」或「團隊領導者」，透過 GitHub Copilot 的 Agent Mode，設計並發出能生成多個協作助理的指令，讓這些助理各司其職、分工合作，共同完成更複雜、更具創造性的任務。

原理與理論：新時代開發的雙重基石

在探討如何成為「指揮家」之前，需要先理解兩個核心原理。

指令設計的速度，決定創新的速度

大型語言模型（LLM）正以極快的速度演進，在這樣的環境下具備快速設計、測試與調整指令的能力，比傳統的程式編寫更具實際價值。

指令成為一種新的抽象層，讓開發者能靈活的調用 AI 的能力，而不必過度依賴其底層細節(但基本的觀念從理論出發還是很重要)，因此掌握高效的指令設計方法，等同於能在這個快速變動的時代中維持開發節奏與創新速度。

脈絡化的規格，成為程式碼的起點

同時開發者的工作方式也在改變，過去任務是把需求轉換成明確的程式碼，而到了現在更著重於將需求整理成有條理、具脈絡的規格（context）。

使用生成式 AI 工具時已形成了一些共識，例如輸入給模型的上下文越完整、越結構化，輸出的結果就越可靠。因此重心正從「寫程式」轉向「設計上下文」，這就像是在制定清晰的設計說明，接著由 AI 接棒依此生成具體實作。

這種方式讓開發流程更貼近設計導向的思維，也更符合團隊協作的邏輯。

基於這兩大理論基石，GitHub Copilot Chat Agent Mode 提供了一個理想的實踐場域，接下來將用 5W1H 的分析框架來檢視，如何在這個場域中將理論化為行動。

快速掌握 5W1H 的概念圖

Who：新典範中的參與者？

在這個模式中，有兩類核心參與者：

• 人類指揮家 (The Human Conductor)：開發者的角色從「工匠」轉變為「工作流架構師」，不再是每一行程式碼的創作者，而是目標的定義者、協作腳本的設計者、以及最終結果的裁決者。
• AI 團隊成員 (The AI Team Members)：在此指的是透過 GitHub Copilot Chat 的「Agent Mode」功能，這個模式並非提供多個獨立的原生 Agents，而是讓我們能以特定指令來引導 AI 專注於特定領域並執行任務。

除此之外也可以根據我們下達的自定義指令（Custom Instructions）扮演特定角色，讓 Agent Mode 更貼近我們定義的「執行者」，負責將我們的策略意圖，轉化為實際的程式碼變更或系統操作。

When / Where：為什麼 IDE/Text Editor 是「指揮家」最真實的舞台？

那麼何時（When）應該採用這種「指揮家」模式呢，答案是當要設計與開發生成式 AI 衍生的服務時，這類型應用的開發過程充滿了實驗與迭代。

傳統瀑布式的開發方法難以應對，而指揮家模式正好提供了所需的靈活性。

而執行這一切的場域（Where）是整合了 AI 助理的現代化開發工具(例如 Visual Studio Code)，選擇在 IDE/Text Editor 內進行指揮，而非獨立的網頁介面，是因為它提供了其他環境無法比擬的兩大優勢：

1. 緊密整合的開發脈絡 (Tightly-Integrated Context)：在 IDE/Text Editor 中 AI 的每一個動作可以透過對話的模式進行檢視和修改的行為。這不是抽象的模擬，而是直接對專案產生可觀測的真實影響，使得原型驗證與功能開發極度貼近實戰。

2. 即時反饋與迭代迴路 (Immediate Feedback & Iteration Loop)：當「指揮家」下達一個指令後，幾乎可以瞬間看到程式碼變更、文件生成或測試結果。這種即時的反饋是快速迭代、優化「協作腳本」的關鍵，完美契合生成式 AI 應用的開發節奏。

How：如何設計並驗證一個指令工作流？

現在將理論付諸實踐，整個協作腳本的設計與建構過程，本身就可以在 AI 的協助下完成。

具體的使用情境如下：

1. 開啟開發環境：啟動您的開發工具（例如 VS Code），並在側邊欄開啟 GitHub Copilot Chat 介面。
2. 建構協作指令：在指定的專案資料夾脈絡下，開始使用 GitHub Copilot Chat Agent Mode，透過多步驟的對話方式，來建構（build）並打磨（refine）即將指揮虛擬團隊的指令集（instructions）。

這是一個「元過程」（meta-process），利用 AI 來幫助我們設計與 AI 溝通的語言。

當這套指令腳本的草案設計完成後，就可以執行它來進行驗證。以下我們先以一個基礎範例，展示一個完全基於文字與 Markdown 的協作流程。

基礎實驗：設計一個「從需求到實作藍圖」的助理團隊指令集

想像現在要打造一支由微軟 AI 專家組成的虛擬團隊。這支團隊不只是聊天機器人，而是一組能協同運作、分工明確、懂得彼此溝通的智慧體系。

情境思考 : 當外部世界拋出一個需求，例如「設計一個整合 M365 Copilot 與 Azure AI Foundry 的應用藍圖」，主代理（Main-Agent）便會啟動整個資訊流的協作鏈。

下述的概念是將需要輸出的結果透過雛形框架衍伸建構虛擬團隊的 Prompt 範例

任務目標：
- 建立一個虛擬團隊架構，用於模擬跨產品協作的微軟 AI 專家團隊，並以 Markdown 文件記錄各成員的角色定位與指令集（Instructions）。
指令內容：
- 請在專案目錄中建立一個名為 VirtualTeam_MicrosoftExperts 的資料夾，並在其中產生以下四個 .md 檔案：

Main-Agent.md
- 定義為主代理（Coordinator Agent），負責所有資訊交換、任務分派與狀態同步。
需包含以下章節：
- 角色定位：扮演資訊流的中樞，協調三位產品領域專家。
任務職責：
- 接收外部請求並轉譯成可執行指令。
- 將任務分配給對應的領域助理。
- 整合各助理的回報內容並產出最終彙整報告。

通訊規範：指定各助理回覆格式與資訊交換語法（例如以 @CopilotStudio 表示呼叫特定助理）。

GitHub Copilot Chat 的 Agent Mode 處理過程回報

輸出的結果包含每一個虛擬角色的指令範例

下一步動作的延伸思考

先前我們產出的多個角色指令雖然只是起點，但這其實是更大藍圖的熱身。這裡有幾個關鍵情境，值得進一步思考如何將這些角色指令真正融入、轉化為具體成果，逐步推進我們與 AI 協作的整體策略：

1. 快速實作 MVP（最小可行產品）
   將生成的角色指令直接複製貼上到 Copilot Studio Lite 或 Full Experience 中，可以在幾分鐘內完成角色的初步建構。

這不只是「使用」，而是將創意迅速變成實體作品的第一步，大幅降低從想法到執行的門檻。

2. 輔助功能開發的「草圖引擎」
   搭配 Pro Code 的開發流程，這些角色指令可以作為設計與開發助理功能時的靈感草圖，例如針對某個工作流或系統功能的初版設計，我們可以先用指令語言建立人機互動的原型，快速驗證假設、加快疊代速度。

3. 從指令到系統：構建 AI 協作新框架
   無論是 No Code、Low Code，還是 Pro Code，用戶的進入點可以從複製一段指令開始，但終點不該只是停在單一範例。

進一步思考如何將這些角色設計與功能模組整合為一個完整的協作框架，當角色不只是「執行者」，而是「協作者」，我們正在推進的是一種新的工作模型，那就是人與 AI 不再只是互動，而是聯手共創(然後人類扮演的決策行為要更加主動)。

結論：成為 AI 協作的「總設計師」，而非僅是執行者

今天的分享並非停留在工具清單，而是以 GitHub Copilot Chat Agent Mode 作為一個解決方案中的應用工具，反覆演練「多助理協同」的設計方法。

所有範例最後都輸出為 .md 或 .txt，凸顯的是把任務拆解為清晰、可複用、可移植的指令集（Instructions），讓任何具備相似能力的代理工具都能根據同一份文本準則協同運作和建置類似的角色。

這些 Markdown 文件就是設計成果可以作為跨工具的共通語言，把相同劇本帶到不同代理框架時也能快速上線與穩定擴張。

在今天的最後再拋出一個延伸思考：當我們不再依賴圖形介面而改用文字進行一系列設計時，還能有哪些不同的設計方法與可能路徑？

本日的內容聚焦於從腦力激盪的角度探索多層次應用與多元整合場景的可能性，文中提到的 GitHub Copilot Chat Agent Mode 可直接 Use agent mode in VS Code。