Agent Plugins 1.0 em Detalhes: O Padrão Portátil para Habilidades e Servidores MCP Entre Agentes de IA

Nome: Saudação
Descrição: Cumprimentar o usuário e oferecer ajuda.

Cumprimentar brevemente o usuário e perguntar como pode ajudar.

### Etapa 4: Adicionar MCP somente quando necessário

Se o plugin precisar de ferramentas, adicione:

```Plaintext
mcp.json

Não é obrigatório que um plugin configure um MCP vazio apenas para ser válido.

A ausência de componentes opcionais em determinadas posições não é considerada um erro.

Etapa 5: Testar em clientes compatíveis

Teste o núcleo portátil em cada cliente que você planeja suportar.

Não presuma que "compatível com plugins de agente" significa que todos os componentes e transportes estão implementados.

Os clientes podem adotar componentes de forma progressiva.

Um pacote mais útil pode ter a seguinte estrutura:

reporting-plugin/
├── plugin.json
├── skills/
│   └── weekly-report/
│       └── SKILL.md
├── mcp.json
└── bin/
└── reporting-server

Manifesto:

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "reporting-plugin",
"version": "1.0.0",
"description": "Fluxos de trabalho e ferramentas portáteis de relatórios."
}

Configuração MCP:

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
"mcpServers": {
"reporting": {
"type": "stdio",
"command": "./bin/reporting-server",
"cwd": "${PLUGIN_ROOT}"
}
}
}

Um cliente em conformidade com o padrão pode descobrir:

• A identidade do plugin
• A habilidade de relatório semanal
• O servidor MCP de relatórios

Sem que o autor precise reorganizar esses componentes portáteis em estruturas completamente diferentes para cada cliente.

O isolamento de erros torna os plugins mais resilientes

Uma parte cuidadosamente projetada da especificação é que muitas falhas de componentes são locais, e não catastróficas.

Por exemplo:

• Uma habilidade inválida pode ser ignorada enquanto outras continuam carregando.
• Uma entrada inválida de servidor MCP não desabilita necessariamente todos os servidores.
• Uma conexão MCP com falha não deve impedir o carregamento de habilidades independentes.
• Os clientes podem ignorar tipos de componentes não suportados.

Isso é essencial em um ecossistema real de múltiplos clientes.

Um plugin pode fornecer:

Habilidade A
Habilidade B
Servidor MCP A
Servidor MCP B
Extensões de cliente

Se um cliente não suporta um transporte específico, o restante útil e portátil deve continuar funcionando sempre que possível.

Caso contrário, a interoperabilidade se torna frágil: um recurso opcional não suportado desabilitaria o plugin inteiro.

Clientes em conformidade podem adotar o padrão progressivamente

Os clientes não precisam implementar todos os recursos do v1.

Um cliente que suporta apenas habilidades ainda pode estar em conformidade se carregar corretamente o manifesto e implementar o comportamento relevante das habilidades.

Um cliente que suporta MCP deve atender às regras de transporte aplicáveis.

Esse modelo incremental reduz a barreira de adoção.

Clientes menores podem começar com:

plugin.json
+
skills/

E adicionar MCP posteriormente.

Clientes maiores podem implementar o núcleo portátil completo, além de seus próprios namespaces de extensão.

O projeto é governado pela comunidade, não controlado por um único fornecedor

O título do AIBase descreve a introdução dos plugins de agente pela OpenAI.

A OpenAI é claramente um participante importante.

Os documentos oficiais de governança tornam o modelo de propriedade mais amplo.

Os plugins de agente se apresentam como

um projeto neutro em relação a fornecedores e governado pela comunidade.

Seu comitê técnico de direção é composto por mantenedores principais independentes, sem assentos corporativos reservados.

O estatuto estabelece:

• Nenhum fornecedor individual pode controlar a maioria dos assentos de mantenedores principais.
• Propostas técnicas e discussões são públicas.
• A participação no projeto é aberta, de acordo com regras explícitas.
• Materiais de especificação e documentação usam CC BY 4.0 por padrão.
• Materiais de esquema, código e software usam Apache 2.0 por padrão.

A página inicial do projeto atualmente lista mantenedores principais iniciais representando:

• Amazon
• Cursor
• Microsoft
• OpenAI
• Vercel

Essa estrutura multiforncedor é importante porque os padrões de interoperabilidade ganham credibilidade quando clientes concorrentes têm um caminho de participação.

O padrão já possui vários clientes compatíveis

A página oficial de compatibilidade atualmente lista:

• VS Code
• Cursor
• GitHub Copilot
• ChatGPT e Codex
• Kiro

Isso é um ponto de partida mais forte do que um padrão suportado apenas por seu criador original.

A matriz de suporte ainda não é idêntica.

Por exemplo, vários clientes listados atualmente suportam SSE tradicional, enquanto ChatGPT e Codex listam atualmente stdio e Streamable HTTP.

O resultado importante é que o formato de pacote já atravessa as fronteiras entre fornecedores.

Autores de plugins agora podem segmentar um núcleo compartilhado sem assumir que cada ambiente de agente é um ecossistema completamente separado.

Por que isso se torna mais importante à medida que os agentes se tornam sistemas de longa duração

Quando os agentes executam trabalho real, o problema da fragmentação de plugins se destaca ainda mais.

Um chatbot simples pode operar com uma pequena lista fixa de ferramentas.

Um agente sério pode precisar de:

• Processos específicos da empresa
• Acesso a bancos de dados
• Automação de navegador
• Ferramentas de implantação
• Verificações de segurança
• Fluxos de trabalho de documentação
• Instruções de domínio reutilizáveis
• Scripts dedicados
• Múltiplos serviços MCP

À medida que esses componentes se multiplicam, a portabilidade se torna infraestrutura.

Sem um mecanismo de empacotamento compartilhado, cada empresa corre o risco de manter uma matriz como esta:

Capacidades × Cliente de agente × Versão × Plataforma

Um formato de pacote portátil reduz uma dimensão dessa matriz.

Ele não elimina o trabalho específico do cliente.

Mas reduz o esforço duplicado necessário para manter um núcleo reutilizável consistente.

Plugins de agente, MCP e habilidades de agente resolvem problemas diferentes

Esses três conceitos estão relacionados, mas não devem ser confundidos.

Um modelo mental útil é:

Habilidades
= o que o agente deve saber ou como deve trabalhar

MCP
= como o agente se conecta a capacidades externas

Plugins de agente
= como essas partes reutilizáveis são empacotadas para funcionar em clientes compatíveis

Portanto, os plugins de agente são uma camada acima dos padrões de componentes existentes, e não um substituto para eles.

O que os plugins de agente não resolvem

O escopo do padrão é deliberadamente estreito.

Ele não resolve todos os problemas de compatibilidade entre agentes.

Ele não padroniza

modelos

O mesmo plugin pode se comportar de maneira diferente quando carregado em modelos diferentes.

Ele não unifica interfaces de permissão

Um cliente pode exigir confirmação antes de executar uma ação, enquanto outro usa políticas em nível de espaço de trabalho.

Ele não unifica autenticação

OAuth e armazenamento de credenciais continuam gerenciados pelo cliente.

Ele não garante suporte para todos os transportes MCP

Os clientes podem implementar subconjuntos diferentes.

Ele não unifica hooks ou comandos no v1

Esses continuam definidos por cada cliente.

Ele não cria um mercado de aplicativos unificado

A distribuição permanece fora do escopo da especificação central.

Ele não isola processos MCP em sandbox

A inclusão de caminhos no pacote não equivale a isolamento em tempo de execução.

Ele não garante comportamento idêntico

Portabilidade significa que clientes podem descobrir e carregar componentes com base em um contrato compartilhado. Isso não significa que cada runtime de agente raciocinará ou invocará o componente exatamente da mesma forma.

Considerações de segurança para autores de plugins

Plugins portáteis podem ampliar o alcance da distribuição.

Isso também aumenta a importância de configurações de segurança por padrão.

Não incorpore informações confidenciais

Evite armazenar credenciais nos seguintes locais:

plugin.json
cabeçalho do mcp.json
valores de variáveis de ambiente no mcp.json
arquivos empacotados

Use autenticação gerenciada pelo cliente.

Mantenha os caminhos do pacote restritos

Não confie em escapar do diretório raiz do plugin para acessar arquivos arbitrários do host.

Trate servidores MCP locais como código executável

Servidores stdio podem iniciar processos.

Usuários e administradores empresariais devem estar cientes do que estão instalando.

Minimize as permissões necessárias

Plugins que precisam apenas de leitura não devem exigir operações de escrita.

Documente serviços externos

Servidores MCP remotos devem ter políticas claras de propriedade, privacidade e uso de dados.

Seja cauteloso com o versionamento

Mesmo que a estrutura de diretórios permaneça válida, mudanças no comportamento do servidor podem constituir alterações de quebra.

O que os desenvolvedores devem fazer agora

Etapa 1: Diferencie partes portáveis de partes específicas do cliente

Determine quais partes do plugin atual são verdadeiramente reutilizáveis:

Habilidades (Skills)
Servidores MCP
Metadados compartilhados

Migre comportamentos exclusivos do cliente para os namespaces de extensão correspondentes.

Etapa 2: Adicione o esquema com versão

Declare explicitamente o Agent Plugins 1.0.0 no plugin.json.

Etapa 3: Padronize a localização das habilidades

Coloque as habilidades de agente portáveis em:

skills//SKILL.md

Etapa 4: Padronize a configuração do MCP

Use o arquivo de nível raiz:

mcp.json

Em vez de depender apenas de arquivos de configuração nativos do cliente.

Etapa 5: Remova informações confidenciais portáveis

Migre credenciais para os sistemas de autenticação de cada cliente.

Etapa 6: Teste o pacote em vários clientes

A interoperabilidade deve ser verificada por demonstração prática, e não presumida.

Etapa 7: Acompanhe as atualizações da especificação

Como a especificação atual ainda está marcada como rascunho de trabalho, monitore mudanças no repositório do projeto, discussões, padrões e páginas de compatibilidade.

Conteúdo confirmado e o que precisa de esclarecimento adicional

Perguntas frequentes

O que é o Agent Plugins 1.0?

O Agent Plugins 1.0 é um formato de pacote aberto e neutro em relação a fornecedores para extensões reutilizáveis de agentes de IA. Ele padroniza como configurar Agent Skills e servidores MCP em um diretório de plugin portátil.

O Agent Plugins é um padrão exclusivo da OpenAI?

Não. A OpenAI participa do projeto e oferece suporte ao formato no ChatGPT e no Codex, mas o projeto oficial é governado pela comunidade e é neutro em relação a fornecedores. Sua equipe inicial de mantenedores principais inclui pessoas ligadas à Amazon, Cursor, Microsoft, OpenAI e Vercel.

Quais arquivos um Agent Plugin requer?

Cada plugin requer um arquivo raiz plugin.json. As habilidades podem ser armazenadas em skills/, enquanto os servidores MCP podem ser descritos no arquivo raiz mcp.json; funcionalidades específicas do cliente podem usar extensões de namespace.

O Agent Plugins substituirá o MCP?

Não. O MCP continua definindo o protocolo usado entre clientes e servidores MCP. O Agent Plugins define uma forma portátil de empacotar configurações de servidores MCP e outros componentes reutilizáveis de agentes.

Hooks (ganchos) fazem parte do Agent Plugins 1.0?

Não como componentes centrais portáveis. A versão 1 padroniza Habilidades e servidores MCP; hooks podem ser implementados por meio de namespaces de extensão específicos do cliente, onde houver suporte.

Quais clientes oferecem suporte ao Agent Plugins?

A página oficial de compatibilidade lista atualmente VS Code, Cursor, GitHub Copilot, ChatGPT e Codex, e Kiro. Eles suportam transportes MCP diferentes, portanto, os autores devem consultar a matriz atualizada.

Um Agent Plugin se comporta da mesma forma em todos os clientes?

Não. O padrão cobre descoberta de pacotes e componentes portáveis; não aborda modelos, interfaces de permissão, fluxos de autenticação, mercados ou comportamentos de tempo de execução específicos do cliente. Plugins podem ser portáveis, mas não necessariamente produzir o mesmo comportamento de execução.

O Agent Plugins 1.0 é considerado uma versão final?

1.0.0 é a versão publicada atual e fornece o padrão. A página da especificação marca atualmente o status do projeto como “rascunho de trabalho”, portanto, os desenvolvedores devem continuar acompanhando os processos públicos de governança e versionamento.

Ferramentas relacionadas

• Agent Plugins: site oficial de documentação para pacotes portáteis de Agent Plugins.
• Agent Skills: especificação aberta para componentes reutilizáveis de habilidades em Agent Plugins.
• Model Context Protocol: protocolo usado por clientes e servidores MCP empacotados via mcp.json.
• Plugins do ChatGPT: sistema de plugins atual da OpenAI para fluxos de trabalho no ChatGPT e Codex.
• Agent Plugins do VS Code: documentação da Microsoft sobre como carregar Agent Plugins no VS Code.
• Plugins do GitHub Copilot: documentação do GitHub sobre pacotes de plugins e suporte à especificação de plugins abertos.

Links relacionados

• Especificação Agent Plugins 1.0.0: restrições normativas completas do formato portátil atual.
• Como criar Agent Plugins: tutorial oficial mínimo de plugins e guia de estrutura de pacotes.
• Clientes compatíveis: lista atual de clientes compatíveis.

org/compatible-clients): Matriz de suporte atual para VS Code, Cursor, GitHub Copilot, ChatGPT e Codex, e Kiro.

• Repositório de especificação de plugins de agente: Padrões públicos, governança, problemas, discussões e código-fonte da especificação.
• Governança de plugins de agente: Estatuto de governança da comunidade e regras neutras de fornecedores.
• Licenciamento de plugins de agente: Termos de licenciamento para a especificação, documentação, padrões e código.
• Plugins OpenAI no ChatGPT e Codex: Documentação de nível do produto da OpenAI sobre plugins, aplicativos, habilidades e controles de espaço de trabalho.

Resumo

O Agent Plugins 1.0 resolve um problema prático no crescente ecossistema de agentes: desenvolvedores empacotam repetidamente as mesmas habilidades e integrações MCP de formas diferentes para cada cliente.

A especificação define um núcleo pequeno e portátil — o plugin.json obrigatório, habilidades no diretório skills/, configuração MCP em mcp.json, regras de empacotamento, esquemas versionados e extensões de cliente com namespace. Distribuição, mercados, permissões, autenticação e interface do usuário permanecem sob controle do cliente.

O projeto lista suporte para vários clientes de agente importantes, incluindo VS Code, Cursor, GitHub Copilot, ChatGPT e Codex, e Kiro. Isso faz dele mais do que um formato de plugin exclusivo da OpenAI, embora a OpenAI seja um dos mantenedores participantes.

A versão 1.0.0 é o contrato atualmente publicado, embora a página de especificação ainda a rotule como rascunho de trabalho. Os desenvolvedores podem adotá-la agora, mas devem acompanhar os processos públicos de governança e versionamento.

A principal mudança é simples: em vez de reescrever as mesmas extensões de agente para cada plataforma, os desenvolvedores podem tratar habilidades e integrações MCP como componentes portáteis com uma estrutura de pacote unificada.