今年Build大會上，微軟不只宣布將擴大支持生成式AI對話應用Copilot，還披露了微軟更大的戰略，是要構建出完整的Copilot開發生態系，不只讓自家產品能夠全面支持Copilot，更要讓企業、開發人員都能將他們自己的應用和服務集成到Copilot中，並在各自的行業領域中應用。而微軟Copilot生態圈戰略發展其中一個很重要的關鍵，就是支持標準的插件程序。
微軟迄今推出多種類型的Copilot應用，適用於不同的微軟產品，從最早在GitHub中提供輔助程序開發的Copilot，到後來針對低程序代碼工具Power平台的專用Copilot，再到提高生產力而設計的Copilot，也就是M365 Copilot。此外，還有提升員工參與度的Viva使用的Copilot，以及支持CRM相關應用的Copilot，其他還有搭載在搜尋引擎Bing和瀏覽器Edge上，用於網頁及安全相關Copilot，就連微軟Windows 11作業系統將很快支持Copilot，意味著Copilot將變成Windows桌面環境中的常駐程序，提供用戶更多支持和協助。
微軟全力發展Copilot開放生態系
微軟要讓Copilot開始能夠支持插件擴展功能，就是為了替開發者打開一道入口，可以將Copilot連接到企業或開發者自己的軟體或服務中來進行互動。微軟首席技術官Kevin Scott甚至以數字世界中的驅動器來比喻插件的關鍵作用。（圖片來源／微軟）
微軟雖然推出了許多不同用途Copilot，但是，微軟首席技術官Kevin Scott顯然認為這些延伸功能還不夠，還有許多有用的Copilot功能有待挖掘，需要更多開發人員和合作夥伴加入Copilot的開發行列，共同推動Copilot的發展，「Copilot必須成為一個開放的生態系統。」他這樣說道。
微軟讓Copilot開始能夠支持插件擴展功能，就是要打開一道入口，將Copilot連接到企業和開發人員擁有的軟體或服務中，來進行互動。
Kevin Scott甚至用「數字世界中的驅動器」來比喻插件的關鍵作用。當插件用戶以文本輸入提問時，Copilot會根據提問內容調用開發人員所創建的插件功能，來協助他們完成各種任務和操作，例如訪問即時資訊、檢索消息或執行跨應用操作等。
微軟最先在Bing的Copilot中推出了OpenTable和Wolfram Alpha兩個插件功能，可以協助用戶查找和預定餐廳，或者回答計算和分析問題。隨後，更多第三方插件加入Bing，包括Expedia、Instacart、Kayak、Klarna、Redfin、TripAdvisor和Zillow等，涵蓋了旅行規劃、購物、金融和房地產等領域。通過集成了這些插件功能，Copilot在Bing上能夠提供用戶更具體的回應，大大提升了其搜尋引擎的能力，「未來幾年，人們對於所有軟體都會期待用這種模式來運行。」Kevin Scott強調。
除了Bing Chat以外，微軟也宣布，將有更多微軟Copilot產品能夠支持這項插件機制，包括M365 Copilot、 Power Platform Copilot、 Dynamics 365 Copilot，以及Windows Copilot等。
舉例來說，在M365的Copilot插件中，還提供了三種不同插件形式，一個ChatGPT插件、Teams對話消息擴展組件和Power平台連接器。ChatGPT插件採用基於ChatGPT形式的插件API，Teams消息擴展組件和Power平台連接器則是具有能夠支持定製化消息和連接企業內部數據的插件功能。一開始就有多達50個第三方插件，可以支持M365的Copilot，包括Atlassian、Adobe、ServiceNow、Thomson Reuters、Moveworks和Mural等。微軟預計在未來幾個月內還會推出上千個插件，進一步擴大M365的Copilot功能和應用範圍。
插件生態圈也支持企業用Azure AI自建的Copilot
除了微軟官方和合作夥伴推出的第三方插件以外，企業還能為不同微軟服務的Copilot創建自己的插件功能，來滿足特定需求與業務場景。甚至，企業在Azure AI上通過語言模型微調或訓練而創建的Copilot，同樣可以利用這個插件機制，進一步擴展企業Copilot的能力，以滿足更多的應用需求。隨著越來越多開發者加入並推出支持不同應用或服務的插件，將形成一個豐富且多樣的插件的生態系。
不僅如此，微軟更藉助ChatGPT的影響力來加速其創建Copilot的插件生態圈，而決定採用與其相同的開放的插件標準，讓這兩個不同平台之間的插件可以彼此互通。對於開發人員而言，這樣做的好處是，只要創建一個插件程序，就可以掛載到任何支持這個標準的Copilot或ChatGPT平台中，因為使用相同的插件標準，在其中一方創建的插件使用的文件或文件，也可以應用到另一方的插件中，不需重新創建。
微軟現有開發工具開始集成插件標準，來簡化插件功能的開發流程。例如,微軟已經將Visual Studio Code、GitHub Codespaces等工具與新的插件標準集成，可以直接在這些工具中來創建、部署或調度在Copilot接口運行的插件功能。對於想要在M365 Copilot中提供插件的開發者，也能夠利用Visual Studio和命令行接口（CLI）中提供的Teams Toolkit工具，協助其進行插件的創建、測試和調度。
快速了解ChatGPT插件標準
微軟Copilot插件機制採用了與OpenAI ChatGPT相同的開放標準，因此，開發者在其中一方創建插件使用的文件或文件，也可以應用到另一方的插件中，不需重新創建。在插件API設計上，Copilot採用和ChatGPT一樣的OpenAPI規範作為標準。（圖片來源／微軟）
由於微軟Copilot的插件功能採用了與OpenAI的ChatGPT相同的開放標準，開發者也能藉由ChatGPT公開的插件規範，快速了解未來創建自己的Copilot應用時，所需遵循相關的標準和規範。
根據OpenAI的說明，開發人員可以利用ChatGPT的插件功能，將其與第三方應用程序進行連接，並使用API與ChatGPT互動。
不過，設計ChatGPT的插件時，開發者需創建至少一個調用的API端點，並在該文件中包含標準化的manifest文件。manifest文件如同提供一個指南給ChatGPT，讓它知道何時該用這個插件來回應用戶。所有跟插件相關的metadata資訊都統一記錄於這個文件中，例如插件名稱、logo商標等，其他還有記載身份驗證所需的資訊，如驗證類型、OAuth URL等。
在manifest文件中還定義了插件各項功能，其中包含了對於API回應內文的字符數上限，以不超過10萬個字符為限，但同時也保留了未來調整的彈性空間。每個manifest文件創建完成後，需存儲為JSON格式，並託管在插件API域名下指定」well-known「文件夾路徑中。
ChatGPT插件的API設計採用OpenAPI規範作為標準，並參考了OpenAPI規範3.0.1版，來定義API中的插件名稱、描述和版本號等相關資訊，提供開發者在設計API時的參照和指引。舉例來說，插件名稱可設為」TODO plugin」，版本號則可以使用」v1」表示插件的初始版本。
此外，在API規範中，對於每個API端點的摘要和參數描述也設有上限，最多不能超過200個字符數，其他則遵照既有OpenAPI格式。公開的API端點中，除了manifest文件之外，必須包含OpenAPI規範文件。
一旦插件API端點創建完成並公開後，會有兩種插件的執行環境供開發者使用，本地的開發環境和遠程伺服器環境。考慮到安全性，遠程伺服器環境中要求使用HTTPS伺服器，而在本地開發環境中使用插件的話，則需要事先創建身份驗證機制，否則插件將無法執行。
