這幾年,AI 已逐漸進入各種產品與工作流程。聊天機器人、文件摘要、程式碼生成與工作流程自動化,對多數開發者來說都已不算陌生。不過,當 AI 真正接進產品或內部系統,開發工作通常不會停在「送出 Prompt,再取得回應」。上下文要如何延續?工具要怎麼整合?哪些操作需要授權?執行失敗時該如何追蹤?原本只能在本機運作的原型,又該怎麼整理成可部署、可維運的服務?這些問題很快就會成為實際開發時必須處理的事情。
我會想寫這個 GitHub Copilot SDK 系列,是因為它處理的範圍已經超過模型呼叫本身,更接近如何把 Agent 整合進既有系統。整個系列會以一個實際問題為主軸:如果要把 GitHub Copilot 變成產品能力的一部分,具體該怎麼做?
單次對話的流程相對單純:送出 Prompt,等待模型回傳結果。當 AI 開始參與完整的工作流程,它可能需要記住前面的資訊、判斷下一步、呼叫工具,甚至改變系統中的資料或狀態。隨著 Agent 參與程度提高,系統也需要進一步處理狀態如何延續、能力如何整合、操作如何控制,以及服務如何穩定運作等工程問題:
模型能力只是 Agent 應用的一部分。當 AI 開始參與實際工作流程後,狀態怎麼保存、工具怎麼使用、操作如何控制,以及服務能不能穩定執行,都會直接影響最後的使用體驗。
多數人接觸 GitHub Copilot,通常是從編輯器中的程式碼補全、聊天介面或 Agent 功能開始。在這些使用情境中,Copilot 已經可以理解目前的工作脈絡、使用工具,並協助開發者持續推進任務。當我們希望把類似的 Agent 能力帶進自己的產品,就需要一套方式讓應用程式參與整個執行流程。
GitHub Copilot SDK 提供了一條將應用程式接上 Copilot Agent Runtime 的開發路徑。Agent Runtime 可以先理解成負責持續執行 Agent 工作的環境,應用程式則透過 SDK 建立工作階段、傳送訊息、提供工具、接收執行事件,並在需要時控制流程。
這讓開發工作可以沿著同一套方式逐步增加能力。最開始只需要建立一段互動,之後可以加入即時輸出、工具使用、權限確認、流程控制,再進一步處理狀態保存與服務部署。
Copilot SDK 可以協助處理 Agent 執行相關的工作,但產品原本需要負責的事情仍然存在。使用者是誰、可以讀取哪些資料、哪些操作允許執行,都要由應用程式根據自己的規則判斷。Agent 可以提出下一步要做什麼,真正能不能執行,仍然受到產品本身的控制。
這也是我選擇 GitHub Copilot SDK 作為這個系列主題的原因。透過同一條開發路徑,我們可以從最基本的互動開始,逐步延伸到工具、流程控制與服務部署,並觀察 Agent 能力進入實際應用後需要處理哪些工程問題。
整個系列會從 GitHub Copilot SDK 的基本定位開始,先建立可以執行的 Agent App,再逐步加入互動、工具、控制與部署能力。內容分成五個階段:
每個階段都會延續前面已經建立的觀念與能力,讓後續內容能在既有基礎上逐步加入新的工程問題與實作方式。
這個系列適合已經具備應用程式開發經驗,並正在思考如何把 AI 能力整合進產品、工作流程或內部工具的開發者。內容會聚焦在 Agent 如何進入既有系統,以及整合之後需要面對的工程問題。
系列不會深入討論模型訓練或演算法原理,也不以比較模型回答品質為重點。我們會從 Agent 如何持續工作、使用工具、取得使用者輸入與接受流程控制開始,一路延伸到如何整理成可部署、可維運的後端服務。
實戰範例會使用 Node.js 與 TypeScript,示範 GitHub Copilot SDK 各項能力的實作方式。系列重點仍然放在 SDK 的使用方式,以及 Agent 應用進入實際產品後需要處理的工程問題。即使平常使用 Python、Go 或 .NET,這些設計觀念大多仍能延伸到其他技術環境。
當 AI 開始參與持續互動、工具操作與實際工作流程,開發工作也會延伸到狀態管理、操作控制與服務維運等問題。GitHub Copilot SDK 提供了一條將這些 Agent 能力接進應用程式的開發路徑,讓我們可以沿著實際需求逐步加入需要的功能。
接下來要真正開始使用 SDK,首先需要看清楚應用程式、GitHub Copilot SDK 與 Agent Runtime 各自扮演什麼角色,以及它們如何共同完成一次 Agent 執行流程。