GitHub Copilot SDK：當你的程式碼有了自己的靈魂

作者： DD - 2月 01, 2026

上個月協助客戶做技術評估時,他們的 CTO 私下跟我聊了個問題。

「我們團隊最近在研究怎麼把 AI 整合進現有的系統…」他打開筆記本，帶著一絲疑惑地說「你知道的，就自動化一些日常任務，像是 Code Review、說明文件生成、部署狀況…檢查這些。我們看了 OpenAI API、也看過 GitHub Copilot CLI、但最近又出了 GitHub Copilot SDK，老實說，實在不太確定該選哪個。」

他頓了一下，「還有，開發人員是不是常用一個 GitHub Copilot Agent? 它和 GitHub Copilot CLI 是什麼關係? 我們的開發主管說他每天都在用 GitHub Copilot Agent, 但我不確定這三個東西是不是在做同一件事…」

我心裡OS: 「放心，你一點都不孤單，因為有太多人對這些新工具感到困惑。」

GitHub Copilot SDK 到底是啥？

今天，就來幫大家理清楚這些概念，並介紹一下 GitHub Copilot SDK 到底是什麼、它能做什麼，以及為什麼你應該關注它。

先講結論：GitHub Copilot SDK 就是 GitHub 提供的一套開發套件，讓你可以在自己的程式裡面整合 Copilot 的能力。

注意，並非在程式碼裡面結合 LLM(大語言模型) 的能力，這是 OpenAI API 就可以做到的範疇。

而 GitHub Copilot SDK 則更進一步，讓你可以直接利用 GitHub Copilot 的 AI 能力來執行任務、調用工具，甚至讓 AI 自己進入一個循環，持續執行特定任務，並且持續改進，直到該任務真正完成。

請注意，不是在 VS Code 裡面用 GitHub Copilot Agent 寫程式碼的那種機制。那個嚴格來說叫做 Copilot Extension，是安裝在 VS Code、Visual Studio 裡面，自動幫你補全程式碼的幫手，也就是現在大部分開發人員已經在用的那個 AI輔助開發工具。

而我們現在在說的 GitHub Copilot SDK，則是讓你可以自己寫一個程式，並在這個你寫的程式當中，去呼叫 Copilot 的 AI 能力的套件。

聽起來有點於迂迴？

它有什麼用？

我們先講個實務上的案例。

假設你在做 DevOps相關工作，每天都要處理一堆雜事：檢查部署後的狀態、查看測試報告、整理網站運行安全日誌、產生摘要…

瑣碎歸瑣碎，但也不是太複雜。

以前，你想要自動化，可能會寫一堆 script，把這些操作步驟程序化。但每次只要 Pipeline 稍微改了一下，你又要去翻改那些 script。而且這些 script 通常沒啥彈性，只能做固定的事情。需求一變，你就得自己調整，改來改去，非常麻煩。

有了 GitHub Copilot SDK，你可以把這需求寫成一個小工具，它能理解自然語言。像是：

「幫我檢查最近三次的部署狀態，有問題的話提醒我」
「把今天的測試報告整理成一份摘要，email 給 PM」
「找出這個月失敗最多次的 pipeline，分析可能的原因」

這種東西，以前要寫死一堆邏輯。現在，AI 可以自己理解你的意圖，然後去調用你提供的工具（比如查詢 API、讀取檔案、執行命令等等），最後直接回報給你結果。

更強的部份來了。

因為可以程式化，這意味著，你可以讓它進入一個自我迭代的工作循環。

比如說，你可以丟給它一個任務：「幫我把這個專案的程式碼重構一下，讓它更符合 SOLID 原則」。

它會怎麼做？

它會自己去讀程式碼、找出問題、修改檔案、執行測試、看看有沒有錯誤，然後再繼續改進。一直到所有測試都通過、並讓整個系統符合 SOLID 原則為止。

中間你完全不用插手。
這才叫真正的自動化，不是嗎？

來個最簡單的範例（C#）

好，廢話不多說，直接來段程式碼。

假設我們要寫一個小工具，讓 AI 幫我們執行一個任務，可以是底下這樣。

using GitHub.Copilot.SDK;

System.Console.OutputEncoding = System.Text.Encoding.UTF8;

var prompt = "使用 .net core 以 WebApp 建立一個 BMI 計算程式，同時必須有 MSTEST 單元測試。建立在 D:\\BMIApp 資料夾下。";

// 建立 Copilot 客戶端
await using var client = new CopilotClient();
await client.StartAsync();

// 建立會話
await using var session = await client.CreateSessionAsync(new SessionConfig
{
    Model = "Claude Sonnet 4.5",
    Streaming = true,
    SystemMessage = new SystemMessageConfig
    {
        Mode = SystemMessageMode.Append,
        Content = BuildSystemPrompt()
    }
});

// 建立完成信號
var completionSource = new TaskCompletionSource();

// 監聽事件
session.On(evt =>
{
    switch (evt)
    {
        case AssistantMessageDeltaEvent delta:
            Console.Write(delta.Data.DeltaContent);
            break;

        case ToolExecutionStartEvent toolStart:
            Console.WriteLine($"\n 🛠️ {toolStart.Data.ToolName}");
            break;

        case SessionIdleEvent:
            Console.WriteLine("\n ✅ 任務完成！");
            completionSource.TrySetResult(); // 標記完成
            break;
    }
});

// 發送提示詞
await session.SendAsync(new MessageOptions { Prompt = prompt });

// 等待任務完成
await completionSource.Task;

static string BuildSystemPrompt()
{
    return """
    你是一個專業的開發助手。
    請根據用戶的指示，建立或修改程式碼。
    完成後，請輸出：<promise>任務完成！🥇</promise>
    輸出一律使用繁體中文。
    """;
}

就這樣。

你執行這個程式，AI 就會開始工作。它會自己建立專案、寫程式碼、執行測試，驗證結果，最後跟你說「任務完成！」。

整個過程，你只需要給它一句話(提示詞)。

剩下的呢？AI 自己搞定。

那它跟 GitHub Copilot CLI 或 OpenAI API 差在哪？

好問題。來一個一個比較。

GitHub Copilot vs. OpenAI API

OpenAI API 就是個 REST API，包裹著 LLM（大型語言模型），你發 HTTP request，它回傳 response。你送一段文字，它回傳 LLM 生成的內容。

OpenAI API 或大部分 LLM 所提供的服務，僅僅是針對你的提示詞，招喚模型進行「文字生成」而已。

兩者都是在你自己寫的程式碼調用，但 GitHub Copilot SDK 則更進一步。它不只是讓你跟 LLM 對話，還幫你處理了「工具調用」（tool calling）、上下文管理、循環執行等複雜邏輯。

GitHub Copilot Agent

GitHub Copilot Agent 是安裝在 IDE 裡面的擴充功能，幫你寫程式碼、補全程式碼。背後也是 LLM 沒錯，但它的主要的任務是在 IDE 當中，幫助你生成或修改程式碼。隨著 MCP（Multi-Copilot Platform）的推出，Copilot Agent 也開始支援更多互動式的功能，但它的核心仍然是「在 IDE 裡面幫你寫程式碼」。

GitHub Copilot CLI

GitHub Copilot CLI 是一個命令列工具，讓你可以在終端機裡面跟 Copilot 對話。

你可以問它「怎麼用 git 還原上一次的 commit？」，它給你建議，你可以選擇執行或不執行。有點像是離開了 IDE 的 Copilot Agent，但仍然是「你問，它答」、「你命令，它(藉由MCP)動作」的互動模式。

但 GitHub Copilot SDK 則不同，它讓你把這個 CLI 的能力帶入你的程式碼當中，讓你可以寫一個「自主運作的程式」。這個程式可以依照你的目標，自己跟 LLM 對話、(在LLM認為需要的時候)自己執行工具(MCP tools)、自己進入運作循環。你不用一直盯著，它能自己把事做完。

沒錯，這些機制後面都是 LLM 這個大腦提供的能力，但這幾年下來，一層一層的被包裝起來，如今，逐漸讓開發者可以專注在「我要讓 AI 幫我(或用戶)做什麼」，而不是「我該要怎麼跟 LLM 互動」。

主要差異點

整合度：GitHub Copilot SDK 已經幫你處理好一堆細節。自動管理 token、處理串流回應、執行階段的工具調用（tool calling）、甚至可以直接讀寫你的程式碼、檔案資料夾。OpenAI API 的話？這些你當然都得自己來。
工具調用：GitHub Copilot CLI 本就內建了一堆 MCP tools，像是讀取檔案、執行命令、搜尋程式碼等等。AI 可以自己決定要用哪個工具，然後自動執行。這本質上就是過去 OpenAI API 中 function calling 的功能，但使用 OpenAI API 你得自己實現那些 function，自己管理執行邏輯。而 GitHub Copilot SDK 在GitHub Copilot CLI 的基礎上，讓開發人員可以把這些東西程式化。
上下文管理：GitHub Copilot SDK 會自動幫你管理對話歷史、Context上下文、工具執行結果等等。OpenAI API？你得自己儲存對話記錄，自己組裝 prompt messages。
自我迭代：GitHub Copilot SDK 因為可以程式化，以至於它能讓 AI 進入一個自我改進的循環。它可以自己檢查結果、找出問題、再繼續改進。

所以說，如果你要快速做一個 AI 工具，而且你已經有 GitHub Copilot 訂閱，用 SDK 會比直接串 OpenAI API 方便太多。

未來的可能性

最後，我想聊聊這個東西的未來。

1. AI Agent 普及化

大部分人用 AI，還停留在「問答」階段。你問，AI 答。再問，再答。但 GitHub Copilot SDK 讓「AI Agent」（自主運作的 AI）變得容易多了。

想像一下：

夜班 AI 工程師：晚上睡覺前丟給它一個任務清單，隔天早上醒來，程式碼寫好了、測試跑完了、PR 建好了。
自動化 Code Review：每次有 PR，AI 會自己去檢查程式碼、找出問題、甚至直接修改。
持續改進循環：給 AI 一個目標（比如「把測試覆蓋率提升到 80%」），它會自己去寫測試、執行、分析結果、再寫更多測試。直到達成目標。

這些不再是科幻小說。
有了 SDK，這些都做得到。

2. 從「工具」變成「同事」

更深層的意義在於，AI 的角色正在改變。

以前，AI 是你的工具。你給指令，它執行。就像一個函式庫，你呼叫 API。如今，AI 開始慢慢變成你的「同事」。

你可以給它一個籠統的目標，它會自己分解任務、選擇方法、執行動作、檢查結果。

就像你在團隊裡跟另一個工程師說「欸，幫我處理一下那個 bug」，然後他會自己去看、去改、去測試。

這個轉變，意味著未來的軟體開發，會是人類與 AI 協作的時代。不是取代，而是分工合作。

3. 開發方式的革命

再進一步想。

未來的軟體開發，可能不再是「人類寫程式碼」，而是「人類設計系統、AI 實現系統」。我之前幻想的，當人們在會議室坐著開會討論一個系統的同時，AI就在旁邊聽著，一邊聽，一邊幫你把系統做出來，人們開完會的同時，系統也同時出現在你面前。

這個時代，估計不遠了。

未來，人們專注在架構設計、需求分析、商業邏輯。具體的程式碼實現、測試撰寫、錯誤修復？完全交給 AI。

但也正如我們之前說的，工程師的角色必須提升，從「寫程式碼的人」，變成「設計系統的人」、「判斷決策的人」、「解決複雜問題的人」。

結語

GitHub Copilot SDK，不只是個工具包或套件。
它是一個時代來臨的信號。

告訴我們「AI 已經不只是輔助，而是可以自主運作」的信號。

當然，它還很年輕。功能還不夠完整，作業模式還不夠完善，大夥兒對它未來能做的事情，也都還在摸索中。

但方向已經很清楚了。

未來的軟體開發，會是人類與 AI 協作的時代。不是取代，是分工。人類負責思考、判斷、創意；AI 負責執行、優化、驗證。

這條路，才剛開始。但這個趨勢，看來是擋不住的。

延伸閱讀：

GitHub Copilot SDK 官方文件

搜尋此網誌

.NET Walker