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

Nome: greet Descrição: Cumprimenta o usuário e oferece ajuda. --- Cumprimenta brevemente o usuário e pergunta como pode ajudar. Se o plugin precisar de ferramentas, adicione: mcp.json de texto simples necessário para o plugin

发布于 2026年8月7日generalGEO 评分: 08 次阅读
A imagem é um gráfico promocional do 'Agent Plugins 1.0 Explained', com fundo escuro. No topo, há o logotipo 'AGENT PLUGINS'. À esquerda, estão os 'AI AGENTS', listando ChatGPT, Claude, Gemini, entre outros. À direita, estão os 'MCP SERVERS', com opções como Files, Database, etc. No centro, destaca-se 'AGENT PLUGINS 1.0', e abaixo o texto 'A Portable Standard for Skills and MCP Servers Across AI Agents'. Na parte inferior, há a etiqueta 'Skills (Plugins)' com ícones de habilidades como Search, Code Runner, Data Analysis, Web Scraper, entre outros. A imagem está alinhada com o conteúdo apresentado no documento sobre o Agent Plugins 1.0, ilustrando de forma direta seu conceito e aplicação.

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.

Exemplo de plugin com servidor MCP local

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.

Padrão Função principal
Habilidades de agente Definem ativos reutilizáveis de instruções/fluxos de trabalho para agentes
MCP Define a comunicação entre clientes de IA e servidores externos de ferramentas/dados
Plugins de agente Definem como empacotar habilidades e configurações MCP de forma portátil

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/<nome-da-habilidade>/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

Declaração Status
A especificação Agent Plugins 1.0.0 foi publicada Confirmado
A especificação define o empacotamento portátil de habilidades e servidores MCP Confirmado
O arquivo raiz plugin.json é obrigatório Confirmado
skills/ é o local fixo das habilidades Confirmado
O arquivo raiz mcp.json é o local da configuração MCP Confirmado
stdio e Streamable HTTP são os transportes MCP padrão Confirmado
O SSE legado é reconhecido, mas opcional para clientes Confirmado
Extensões específicas do cliente usam namespaces de domínio reverso Confirmado
Distribuição, instalação, permissões e experiência do usuário foram padronizadas Não; explicitamente fora do escopo
Hooks (ganchos) são componentes portáveis do Agent Plugins v1 Não; eles podem ser extensões do cliente
A OpenAI possui ou gerencia exclusivamente o Agent Plugins Não
O projeto é neutro em relação a fornecedores e governado pela comunidade Confirmado pela governança oficial
A versão 1.0.0 é uma norma final totalmente congelada Não; a página da especificação está atualmente marcada como rascunho de trabalho
Todo cliente compatível suporta todos os componentes e transportes MCP Não
ChatGPT, Codex, VS Code, Cursor, GitHub Copilot e Kiro estão listados como compatíveis Confirmado na página de compatibilidade atual

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

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

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.

Agent Plugins 1.0 详解:跨 AI 智能体的技能与 MCP 服务器的便携标准