{"id":1278,"date":"2023-10-04T07:24:02","date_gmt":"2023-10-04T14:24:02","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/semantic-kernel\/?p=1278"},"modified":"2024-01-11T20:44:07","modified_gmt":"2024-01-12T04:44:07","slug":"skills-to-plugins-fully-embracing-the-openai-plugin-spec-in-semantic-kernel","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/agent-framework\/skills-to-plugins-fully-embracing-the-openai-plugin-spec-in-semantic-kernel\/","title":{"rendered":"Skills to plugins: fully embracing the OpenAI plugin spec in Semantic Kernel"},"content":{"rendered":"

\"Image<\/a><\/h2>\n

Over the past several weeks, the Semantic Kernel team has been hard at work preparing for the v1.0.0 release at the end of the calendar year. As part of this change, we wanted to complete any remaining breaking changes so developers could have a stable API moving forward. If you are interested in seeing what these changes are, you can preview them using our nightly builds<\/a>.<\/p>\n

We will provide a blog post with all of the significant changes next week when we provide the first release candidate (RC), but before then, we wanted to provide clarity of the biggest change we’re making: renaming “skills” to plugins<\/em>. We’ve done this so we can better align the internal workings of Semantic Kernel with the plugin specification developed by OpenAI. We believe this will help reduce concept counts and make Semantic Kernel even simpler to use moving forward.<\/p>\n

What are “plugins” today?<\/h2>\n

Thanks to the spec defined by OpenAI, any developer can take their existing APIs, describe them using both an OpenAPI specification and an ai-plugin.json file so ChatGPT can intelligently perform actions on behalf of a user. A common (and powerful) example is to use the Bing plugin so ChatGPT can answer questions using current information from the world wide web.<\/p>\n

Because OpenAI plugins simply describe the behavior of APIs served up on HTTP endpoints, plugin authors can allow their plugins to be used by any other AI service. In the future, this will include Teams Business Chat and Bing Chat. This is powerful because it means you as a developer can write code once and allow your customers to leverage your plugin no matter which agent they use.<\/p>\n

\"AI<\/p>\n

Today, you can already import these plugins into Semantic Kernel.<\/h3>\n

If you\u2019re building your own<\/em> agent with Semantic Kernel, we also make it easy to import plugins defined with an OpenAI spec so your planners can leverage the functions when auto-generating plans for users. Below is a code sample of how you would previously import an AI plugin.<\/p>\n

\/\/ Add the math plugin using the plugin manifest URL\r\nconst string pluginManifestUrl = \"http:\/\/localhost:7071\/.well-known\/ai-plugin.json\";\r\nvar mathPlugin = await kernel.ImportAIPluginAsync(\"MathPlugin\", new Uri(pluginManifestUrl));<\/pre>\n
\u201cSkills\u201d in Semantic Kernel aren\u2019t that much different…<\/h2>\n
What\u2019s traditionally been called \u201cskills\u201d in Semantic Kernel are like OpenAI plugins. Like plugins, they have the following traits:<\/p>\n\n\n\n\n\n\n
Similarity<\/strong><\/td>\nSkills<\/strong><\/td>\nPlugins<\/strong><\/td>\n<\/tr>\n
Both have a collection of actions that can be performed by an agent.<\/td>\nSKFunctions<\/td>\nHTTP endpoints<\/td>\n<\/tr>\n
Both semantically describe what the action is, when it should be used, and how to use.<\/td>\nSKFunction decorators<\/td>\nOpenAPI route specification<\/td>\n<\/tr>\n
Both can be imported into the kernel so they can be invoked and used in plans.<\/td>\n\n
ImportSkill()<\/pre>\n<\/td>\n
\n
ImportAIPluginAsync()<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The only difference is where they\u2019re run: locally or remotely.<\/h3>\n
Whereas OpenAI plugins are remote services that you can call with HTTP requests, \u201cskills\u201d are native or semantic functions that are called by the same process that\u2019s running your kernel.<\/p>\n
There are pros and cons to both approaches. By running \u201cskills\u201d in the same process, you can get performance improvements and more easily debug your code if something went wrong. Unfortunately, \u201cskills\u201d are difficult to share with others and cannot be seamlessly imported into agents like ChatGPT, Teams Business Chat, or Bing chat.<\/p>\n
This makes it difficult to choose: build a plugin or a \u201cskill\u201d?<\/h2>\n
Because of the subtle differences, developers have a hard choice. Do you build a \u201cskill\u201d to get the efficiency gains? Or spin up a new service that your customers can use in their own AI applications?<\/p>\n
\"Image<\/a>This choice is also hard because it\u2019s not easy today to convert between the two types. Not only would you need to refactor your code to express each SKFunction as an HTTP endpoint, but you\u2019d also need to retest your code with Semantic Kernel because planners today treat \u201cskills\u201d and plugins subtly differently.<\/p>\n
This is changing; \u201cskills\u201d will become plugins.<\/h2>\n
Instead of forcing developers like yourself to make a choice, we want to remove the choice all together. In the future, you won\u2019t build \u201cskills\u201d or OpenAI plugins; you\u2019ll just build plugins<\/span><\/em>.<\/p>\n
The future version of \u201cskills\u201d (i.e., plugins) will have the following benefits:<\/p>\n