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

作者： -

圖片
上個月協助客戶做技術評估時，他們的 CTO 會後跟我聊了個問題。

「你知道我們團隊最近在研究把 AI 整合進現有的系統與開發流程…」他闔上記事本(實體，有紙張的那種)，帶著思索的表情說到「你知道的，其實就自動化一些日常任務，像是程式碼掃描、Code Review、各種文件生成、自動化測試、應用程式部署、以及運行狀況檢查…這些。我們一開始看了 OpenAI API、後來也研究過 GitHub Copilot CLI、但最近又出了 GitHub Copilot SDK，老實說，不太確定該選哪個?」

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

我打開投影片準備跟他慢慢解釋，心裡想「呵呵，你不是第一個問的…最近有太多人對這些新工具"們"感到困惑。很正常，你沒搞混我才覺得奇怪…」

GitHub Copilot SDK 是啥？

最近我發現，只要聊到 Copilot，幾乎一定會卡在這個地方。

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

注意，是整合 GitHub Copilot 的能力，而非在程式碼裡面整合 LLM(大語言模型) 的能力，兩者完全不同。

要在程式碼裡面整合 LLM(大語言模型) 的能力，三年前的 OpenAI API 就可以做到了。

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

你應該曾經在 VS Code 裡面用 GitHub Copilot Agent Mode 來產程式碼。那個嚴格來說叫做 Copilot Extension，是安裝在 VS Code、Visual Studio 裡面，自動幫你補全(或生成)程式碼的幫手，也就是現在大部分開發人員已經在用的那個 AI輔助開發工具。(也就是坊間所謂的 AI 輔助開發，或是 Vibe Coding 工具)

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

GitHub Copilot 的能力並非只是 LLM/ChatGPT 的能力，對吧? 兩者截然不同，GitHub Copilot 還可以呼叫 MCP、可以運行 Agent Skill，必要時它可以自主上網搜尋，修改檔案、文件、執行 script、生成你需要的內容，這和 LLM/ChatGPT 所提供的LLM基本能力是不同的。

那，當你的程式碼可以藉由 GitHub Copilot SDK 去呼叫 GitHub Copilot 的能力時，又能幹嘛呢?

它具體有什麼用？

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

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

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

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

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

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

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

更強的部份來了。

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

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

它會怎麼做？

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

中間你完全不用插手。
有點像是 GitHub Copilot Agent Mode? 又有點像是 GitHub Copilot CLI 能做的事情? 沒錯，都對。

但這次是透過你的程式碼(而不是 VS Code 或 command line)來驅動並完成這些工作的。

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

好，我們先來看底下這段程式碼。

假設我們要寫一個小工具，透過 GitHub Copilot SDK 讓 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>
    輸出一律使用繁體中文。
    """;
}

repo: https://github.com/isdaviddong/TestCopilotSdk

就這樣。

當你執行這個程式，AI 就會開始工作。它會依照程式碼中的提示詞 “使用 .net core 以 WebApp 建立一個 BMI 計算程式，同時必須有 MSTEST 單元測試。建立在 D:\BMIApp 資料夾下。” 運作…

你會看到 AI 開始自己建立專案(在 D:\BMIApp 資料夾唷)、編寫程式碼、執行測試，驗證結果，最後跟你說「任務完成！」。

這跟過去我們在程式碼中整合 LLM 完全不同，過去你在程式碼中呼叫 OpenAI API(或其他API)，整合 LLM 的能力，大多都只能你問一句、AI回答一句。

但你有沒有發現，當你在程式碼中以 GitHub Copilot SDK 整合 GitHub Copilot 的能力時，是可以 建立檔案、修改文件、上網查詢、甚至執行 power shell command…的。

為了實現你給的目標，AI 會自己想辦法來達成，整個過程，你只需要給它提示詞即可。

在上面這個例子裡，最後 AI 會在D:\BMIApp 資料夾下，幫你使用 .net core 建立一個 BMI 計算程式，然後撰寫完整的單元測試。

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

我們來一個一個比較。

GitHub Copilot SDK vs. OpenAI API

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

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

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

GitHub Copilot Agent

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

GitHub Copilot CLI

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

你可以問它「怎麼用 git 還原上一次的 commit？」，它會給你建議，你可以選擇執行或不執行。有點像是離開了 IDE 的 Copilot Agent，但仍然是「你問，它答」或是「你下指令，它(藉由MCP)動作」的互動模式。因此，你當然也可以跟它說 : 『請幫我將這個專案還原到上一次 commit 的狀況』這時候 GitHub Copilot CLI 就會自動幫你去試著執行該動作。

無可否認的， GitHub Copilot CLI 已非常強悍了，因為它也已經具有 建立檔案、修改文件、上網查詢、甚至執行 power shell command…的能力。

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

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

主要差異點

  1. 整合度：GitHub Copilot SDK 已經幫你處理好一堆細節。自動管理前後文、記憶、對談與Token、處理串流回應、執行階段的工具調用（tool calling）、甚至可以直接讀寫你的程式碼、檔案資料夾。若是只用 OpenAI API 的話？這些當然都得自己來。

  2. 工具調用：GitHub Copilot CLI 本就內建了一堆 MCP tools，像是讀取檔案、執行命令、搜尋程式碼等等。AI 可以自己決定要用哪個工具，然後自動執行。這本質上就是過去 OpenAI API 中 function calling 的功能，但使用 OpenAI API 你得自己實現那些 function，自己管理執行邏輯。而 GitHub Copilot SDK 在GitHub Copilot CLI 的基礎上，讓開發人員可以把這些東西程式化。

  3. 上下文管理：GitHub Copilot SDK 會自動幫你處理對話歷史、Context上下文、工具執行結果、修正錯誤…等。OpenAI API？你得自己儲存對話記錄，自己組裝 prompt messages，萬一出錯了，得自己收拾爛攤子。

  4. 自我迭代：GitHub Copilot SDK 因為可以程式化，以至於它能讓 AI 進入一個自我改進的循環。它可以自己檢查結果、找出問題、再繼續改進。

所以說，如果你要快速做一個 AI Agent 工具，用 GitHub Copilot SDK 會比串 OpenAI API 方便太多。

在這個基礎上，其實你根本可以自己用程式碼，輕鬆的撰寫出一個類似最近很紅的 Clawdbot / Moltbot / OpenClaw AI Agent。

未來的可能性

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

1. AI Agent 普及化

目前大部分人用 AI，還停留在「問答」階段。
但 GitHub Copilot SDK 則讓開發「AI Agent」（自主運作的 AI），變得容易很多，它可以輕易的實現許多功能(當然，如果你採用的模型不夠聰明，本質上它就是拿 token 換結果)。

想像一下，底下這些都是(不久的)將來你可以看到的例子：

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

這些不再是小說中的劇情。
如今有了 SDK，這些基本上都已經做得到(就是你願不願意燒 token 讓它迭代實現)。

2. AI 真的從「工具」慢慢變成「同事」

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

以前，AI 是你的工具。你給指令，它給你執行結果。就像一個函式庫，你呼叫 API，它回覆。
但如今，AI 愈來愈像是你的「同事」。

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

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

這個轉變我們過去早就知道，但如今將變得更具體。
也意味著，未來的軟體開發，會是人類與 AI 協作的時代。

3. 開發方式的革命

再進一步想。

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

這個時代，估計不遠了。

結語

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

它是「AI 已經不只能輔助開發，而是可以自主開發」的信號。

當然，它現在還很年輕。
功能不夠完整，作業機制也不夠完善，
目前你可能要用許多 token 才能迭代出一個比較理想的自動化運行結果，但這個方向已經愈來愈清晰了。

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

延伸閱讀：

相關課程：

留言

張貼留言

這個網誌中的熱門文章

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

雖然可恥但很有用的技術 - ADO Pipeline 客製報表呈現頁面

作者： -
圖片
上禮拜在改 Azure DevOps 的 Pipeline，因為客戶遇到一個很實際的問題。 用戶抱怨，每次 Pipeline 跑完，他們團隊的 PM 和相關人等都跑來問：「這次測試過了幾個？Coverage 多少？部署有沒有成功？Sonar 掃描的報表結果如何?」 苦主耐心地一一回答：「這些資訊都在 Pipeline 的 tasks 裡面啊，你們自己點進去看就好。」 但是，這些大爺們從來不想自己去一個一個 tasks 去點，他們希望有個「一目了然」的整合頁面，能直接看到他們想要的重點數字就好。 『就算我說服了他們，他們也真的自己去看，但沒多久又在 LINE 上問我：那個 Log 到底是什麼意思？這個掃描報告要在哪裡找?』 就這樣『來來回回，他們累了，我也累了。』 苦主無奈地說。 需求很簡單：給我一個摘要頁面就好 大爺們最後跟苦主說：「你能不能幫我們在 pipeline 裡面弄一個 Summary 頁面？我們只要打開就能看到重點數字，不用再去翻那些 log?」 恩恩，我被問到的就是這個… Pipeline 跑完之後，能不能有個漂亮的摘要頁面，一進來就看到重點： 測試通過幾個、失敗幾個、Coverage 趨勢 部署到哪個環境、- 有沒有什麼重要的警告 源碼掃描報告的摘要是如何? 自動化測試結果? 能不能上正式機? … 就這樣。 說的很簡單，要蒐集到需要的資訊似乎也還算容易。 但問題是，要怎麼把這些資訊「塞」進 Azure DevOps 的 Pipeline Summary 頁面？ 然後我發現了個神奇的東西 在翻 Azure DevOps 的文件時，我發現一個很有趣的機制。 你知道那些客製化的 Extensions 是怎麼樣讓你在 Pipeline 的 Summary 頁面看到額外的資訊(例如掃描報告、測試報告)的嗎? 類似底下這樣： 答案可能會讓你傻眼，不是呼叫什麼 REST API、不用設定什麼 Token、也不用安裝套件。 ADO 用的方法超級簡單： 監聽你在 Build Agent 裡面的 console 輸出 。 對，就是 stdout。 你只要在 Pipeline 運行的 script 裡面 echo 一行特定格式的字串： echo "##vso[task.uploadsummary]...
Read more »

你想做什麼?

作者： -
圖片
下課後，有個學員帶著問題走了過來， 戴著一幅黑框眼鏡，看起來就是那種勤奮型的人。 「老師，想請教你個問題」他說，「不知道你怎麼安排時間學習新的技術的? 現在 AI 發展這麼快，每天都有新東西出來。今天這個模型紅了，明天那個工具又說是必學。我根本不知道該從什麼地方開始，感覺永遠追不完…」 我點了點頭，收拾著背包。 這問題，我打從 AI 還沒出現的年代，就被問到現在。 說實在的，這年頭當開發者，挺累。 你打開社群網站，滿滿都是「不學這個你就落伍了」的暗示、 「202x 必學的 10 個技術」讓大家一窩蜂地膜拜新功能，那怕根本不知道那是幹嘛用的。 焦慮感一波一波襲來，搞得你晚上睡覺都不安穩。 但我想告訴大家一個事實： 其實，你永遠學不完的。 真的，別再想了。接受這個事實，你會輕鬆很多。 問題不在「學什麼」，而在「為什麼學」 我反問他：「你為什麼想學？」 他愣了一下，「因為…大家都在學啊。」 (我心想：又來了，面對熊來了，大家都只是想跑得比身邊的人快一些，是吧? 🤔) 大部分人學東西，是因為害怕。怕跟不上，怕被市場淘汰，怕面試被問倒。 所以瘋狂囤課、狂買書、把教學平台的購物車塞得滿滿的。結果呢？買了一堆課，上了5分鐘就放著長灰塵。 其實這不是學習，這是焦慮的發洩出口而已。 教育訓練從販賣知識變成販賣焦慮，我想作者本人應該也不願意吧。 其實，真正有效的學習，永遠從 解決問題 開始。 你現在手上有什麼專案？遇到什麼問題讓你卡關？你想做出怎樣的東西？從這裡出發，你才知道該學什麼。 不是「我要學完 Vue才能開始做專案」，而是「我要做這個功能，所以我得搞懂 Vue 的這個部分」。 差別在哪？前者你可能永遠學不完，後者你今天就能做出東西。 AI時代更要會「選擇」 如今，AI都會能自己程式了，直接 Vibe Coding 就好，還要學什麼？ 不，不是的! AI 越厲害，你越需要知道「該問什麼問題」。你得知道要做什麼、怎麼拆解問題、如何判斷 AI 給的答案對不對。 這些能力，從來都不是靠狂學一堆技術就能培養的。而是靠你真正去 做 、去 踩坑 、去 修bug 累積出來的。 (注意到關鍵字 修bug 了沒，這句是寫給想 Vibe Coding 的同學看的) 我常跟學員說，與其花三個月把一門課從頭到尾看完，不如花十天先做出一個爛爛...
Read more »