微软AI新战略：加速Copilot生态圈发展并支持标准插件扩展
今年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服务器，而在本地开发环境中使用插件的话，则需要事先创建身份验证机制，否则插件将无法执行。
