Skip to main content
O OpenClaw substituiu uma ampla camada de compatibilidade retroativa por uma arquitetura moderna de plugins construída com importações pequenas e específicas. Se o seu plugin for anterior a essa mudança, este guia o adapta aos contratos atuais.

O que mudou

Duas superfícies de importação totalmente abertas permitiam que os plugins acessassem quase qualquer coisa por um único ponto de entrada:
  • openclaw/plugin-sdk/compat - reexportava dezenas de auxiliares para manter plugins antigos baseados em hooks funcionando enquanto a nova arquitetura era desenvolvida.
  • openclaw/plugin-sdk/infra-runtime - um barrel amplo que combinava eventos do sistema, estado de heartbeat, filas de entrega, auxiliares de fetch/proxy, auxiliares de arquivos, tipos de aprovação e utilitários sem relação entre si.
  • openclaw/plugin-sdk/config-runtime - um barrel amplo de configuração que ainda mantinha auxiliares diretos obsoletos de carregamento/gravação durante o período de migração.
  • openclaw/extension-api - uma ponte que dava aos plugins acesso direto a auxiliares do host, como o executor de agente incorporado.
  • api.registerEmbeddedExtensionFactory(...) - um hook removido, exclusivo do executor incorporado, que observava eventos desse executor, como tool_result. Em vez disso, use middleware de resultados de ferramentas do agente (consulte Migrar extensões de resultados de ferramentas incorporadas para middleware).
Essas superfícies estão obsoletas: elas ainda funcionam, mas novos plugins não devem usá-las, e os plugins existentes devem migrar antes que a próxima versão principal as remova. registerEmbeddedExtensionFactory já foi removido; registros legados não são mais carregados.
A camada de compatibilidade retroativa será removida em uma versão principal futura. Os plugins que ainda importarem dessas superfícies deixarão de funcionar quando isso ocorrer.
O OpenClaw não remove nem reinterpreta comportamentos documentados de plugins na mesma alteração que introduz uma substituição. Alterações incompatíveis de contrato passam primeiro por um adaptador de compatibilidade, diagnósticos, documentação e um período de descontinuação. Isso se aplica a importações do SDK, campos de manifesto, APIs de configuração, hooks e comportamento de registro em tempo de execução.

Por quê

  • Inicialização lenta - importar um auxiliar carregava dezenas de módulos não relacionados.
  • Dependências circulares - reexportações amplas facilitavam a criação de ciclos de importação.
  • Superfície de API pouco clara - não havia como distinguir exportações estáveis das internas.
Agora, cada openclaw/plugin-sdk/<subpath> é um módulo pequeno e independente com um contrato documentado. As interfaces legadas de conveniência de provedores para canais integrados também foram removidas - os atalhos de auxiliares específicos de canais eram conveniências privadas do monorepo, não contratos estáveis de plugins. Em vez disso, use subcaminhos genéricos e específicos do SDK. No workspace de plugins integrados, mantenha os auxiliares pertencentes ao provedor no api.ts ou runtime-api.ts do próprio plugin:
  • A Anthropic mantém auxiliares de stream específicos do Claude em sua própria interface api.ts / contract-api.ts.
  • A OpenAI mantém construtores de provedores, auxiliares de modelo padrão e construtores de provedores em tempo real em seu próprio api.ts.
  • A OpenRouter mantém o construtor de provedor e os auxiliares de integração/configuração em seu próprio api.ts.

Política de compatibilidade

O trabalho de compatibilidade de plugins externos segue esta ordem:
  1. Adicionar o novo contrato.
  2. Manter o comportamento antigo conectado por meio de um adaptador de compatibilidade.
  3. Emitir um diagnóstico ou aviso que indique o caminho antigo e seu substituto.
  4. Abranger ambos os caminhos em testes.
  5. Documentar a descontinuação e o caminho de migração.
  6. Remover somente após o período de migração anunciado, geralmente em uma versão principal.
Se um campo de manifesto ainda for aceito, continue usando-o até que a documentação e os diagnósticos indiquem o contrário. Código novo deve preferir a substituição documentada; plugins existentes não devem deixar de funcionar durante versões secundárias comuns. Audite a fila de migração atual com pnpm plugins:boundary-report: pnpm plugins:boundary-report:ci é executado com os três sinalizadores de falha. Cada registro de compatibilidade tem uma data removeAfter explícita (não uma vaga “próxima versão principal”) - o relatório agrupa registros obsoletos por essa data, conta referências locais no código/documentação, revela importações reservadas do SDK entre proprietários e resume a ponte privada do SDK do host de memória. Subcaminhos reservados do SDK devem ter o uso do proprietário rastreado; exportações reservadas não utilizadas devem ser removidas do SDK público.

Como migrar

1

Migrar auxiliares de carregamento/gravação da configuração em tempo de execução

Plugins integrados devem deixar de chamar api.runtime.config.loadConfig() e api.runtime.config.writeConfigFile(...) diretamente. Prefira a configuração já passada ao caminho de chamada ativo. Manipuladores de longa duração que precisam do snapshot atual do processo podem usar api.runtime.config.current(). Ferramentas de agente de longa duração devem ler ctx.getRuntimeConfig() dentro de execute para que uma ferramenta criada antes de uma gravação de configuração ainda veja a configuração atualizada.As gravações de configuração passam pelo auxiliar transacional com uma política explícita após a gravação:
Use afterWrite: { mode: "restart", reason: "..." } quando a alteração exigir uma reinicialização limpa do gateway e afterWrite: { mode: "none", reason: "..." } somente quando o chamador for responsável pela ação subsequente e suprimir deliberadamente o planejador de recarga. Os resultados da mutação incluem um resumo tipado followUp para testes e logs; o gateway continua responsável por aplicar ou agendar a reinicialização.loadConfig e writeConfigFile permanecem como auxiliares de compatibilidade obsoletos para plugins externos e emitem um aviso uma única vez com o código de compatibilidade runtime-config-load-write. Plugins integrados e o código do repositório em tempo de execução são protegidos por pnpm check:deprecated-api-usage e pnpm check:no-runtime-action-load-config: o novo uso em plugins de produção falha imediatamente, gravações diretas de configuração falham, métodos do servidor do gateway devem usar o snapshot de tempo de execução da solicitação, auxiliares de envio/ação/cliente de canais em tempo de execução devem receber a configuração de seu limite, e módulos de longa duração em tempo de execução não permitem nenhuma chamada ambiente a loadConfig().Código novo de plugin deve evitar o barrel amplo openclaw/plugin-sdk/config-runtime. Use o subcaminho específico para a tarefa:Plugins integrados e seus testes são protegidos por verificação contra o barrel amplo, para que importações e mocks permaneçam locais ao comportamento necessário. O barrel ainda existe para compatibilidade externa, mas código novo não deve depender dele.
2

Migrar extensões de resultados de ferramentas incorporadas para middleware

Plugins integrados devem substituir manipuladores de resultados de ferramentas exclusivos do executor incorporado api.registerEmbeddedExtensionFactory(...) por middleware independente do ambiente de execução:
Atualize o manifesto do plugin ao mesmo tempo:
Plugins instalados também podem registrar middleware de resultados de ferramentas quando explicitamente habilitados e quando cada ambiente de execução de destino estiver declarado em contracts.agentToolResultMiddleware. Registros de middleware instalado não declarados são rejeitados.
3

Migrar manipuladores nativos de aprovação para fatos de capacidade

Plugins de canal com capacidade de aprovação expõem o comportamento nativo de aprovação por meio de approvalCapability.nativeRuntime mais o registro compartilhado de contexto em tempo de execução:
  • Substitua approvalCapability.handler.loadRuntime(...) por approvalCapability.nativeRuntime.
  • Remova autenticação/entrega específica de aprovação da conexão legada plugin.auth / plugin.approvals e passe-a para approvalCapability.
  • ChannelPlugin.approvals foi removido do contrato público de plugins de canal; mova os campos de entrega/nativos/renderização para approvalCapability.
  • plugin.auth permanece apenas para fluxos de login/logout do canal; o núcleo não lê mais hooks de autenticação de aprovação nesse local.
  • Registre objetos de tempo de execução pertencentes ao canal (clientes, tokens, aplicativos Bolt) por meio de openclaw/plugin-sdk/channel-runtime-context.
  • Não envie avisos de redirecionamento pertencentes ao plugin a partir de manipuladores nativos de aprovação; o núcleo é responsável pelos avisos de roteamento para outro local com base nos resultados reais da entrega.
  • Ao passar channelRuntime para createChannelManager(...), forneça uma superfície createPluginRuntime().channel real - stubs parciais são rejeitados.
Consulte Plugins de canal para conhecer a estrutura atual da capacidade de aprovação.
4

Auditar o comportamento de fallback de wrappers do Windows

Se o seu plugin usar openclaw/plugin-sdk/windows-spawn, wrappers do Windows .cmd/.bat não resolvidos agora falham de forma fechada, a menos que você passe explicitamente allowShellFallback: true:
Se o chamador não depender intencionalmente do fallback de shell, não defina allowShellFallback e, em vez disso, trate o erro lançado.
5

Encontrar importações obsoletas

6

Substituir por importações específicas

Cada exportação da superfície antiga corresponde a um caminho moderno de importação específico:
Para helpers do lado do host, use o runtime do plugin injetado em vez de importar diretamente:
O mesmo padrão se aplica a outros helpers de ponte legados:
7

Substitua importações amplas de infra-runtime

openclaw/plugin-sdk/infra-runtime ainda existe para compatibilidade externa, mas o código novo deve importar a superfície específica de que realmente precisa:Os plugins integrados são protegidos por verificação contra infra-runtime, portanto o código do repositório não pode regredir para o barrel amplo.
8

Migre os helpers de rota de canal

O novo código de rota de canal usa openclaw/plugin-sdk/channel-route. Os nomes antigos de chave de rota e destino comparável permanecem como aliases de compatibilidade:Os helpers modernos de rota normalizam { channel, to, accountId, threadId } de forma consistente em aprovações nativas, supressão de respostas, desduplicação de entrada, entrega por cron e roteamento de sessões.Não adicione novos usos de ChannelMessagingAdapter.parseExplicitTarget, dos helpers de rota carregada baseados em parser (parseExplicitTargetForLoadedChannel, resolveRouteTargetForLoadedChannel) nem de resolveChannelRouteTargetWithParser(...) de plugin-sdk/channel-route — eles estão obsoletos e permanecem apenas para plugins antigos. Novos plugins de canal devem usar messaging.targetResolver.resolveTarget(...) para normalização do ID de destino e fallback quando não houver correspondência no diretório, messaging.inferTargetChatType(...) quando o núcleo precisar antecipadamente do tipo de par e messaging.resolveOutboundSessionRoute(...) para a identidade nativa do provedor de sessão e thread.
9

Compile e teste

Referência de caminhos de importação

Esta tabela contém o subconjunto comum de migração, não toda a superfície do SDK. O inventário de pontos de entrada do compilador fica em scripts/lib/plugin-sdk-entrypoints.json; as exportações do pacote são geradas a partir do subconjunto público. Os pontos de integração auxiliares reservados para plugins incluídos foram removidos do mapa de exportações do SDK público, exceto por fachadas de compatibilidade explicitamente documentadas, como o shim obsoleto plugin-sdk/discord, mantido para plugins externos que ainda importam diretamente o pacote publicado @openclaw/discord. Auxiliares específicos do proprietário ficam dentro do pacote do plugin proprietário; comportamentos compartilhados do host passam por contratos genéricos do SDK, como plugin-sdk/gateway-runtime, plugin-sdk/security-runtime e plugin-sdk/plugin-config-runtime. Use a importação mais específica que corresponda à tarefa. Se você não encontrar uma exportação, verifique o código-fonte em src/plugin-sdk/ ou pergunte aos mantenedores qual contrato genérico deve ser responsável por ela.

Descontinuações ativas

Descontinuações mais específicas no SDK de plugins, no contrato de provedores, na superfície de runtime e no manifesto. Cada uma ainda funciona atualmente, mas será removida em uma futura versão principal. Cada entrada mapeia a API antiga para sua substituição canônica.
Antigo (openclaw/plugin-sdk/command-auth): buildCommandsMessage, buildCommandsMessagePaginated, buildHelpMessage.Novo (openclaw/plugin-sdk/command-status): mesmas assinaturas, mesmas exportações — apenas importadas do subcaminho mais específico. command-auth as reexporta como stubs de compatibilidade.
Antigo: resolveMentionGating(params) e resolveMentionGatingWithBypass(params) de openclaw/plugin-sdk/channel-inbound ou openclaw/plugin-sdk/channel-mention-gating.Novo: resolveInboundMentionDecision({ facts, policy }) — um único objeto de decisão em vez de dois formatos de chamada separados.Adotado no Discord, iMessage, Matrix, MS Teams, QQBot, Signal, Telegram, WhatsApp e Zalo. O modelo de eventos app_mention próprio do Slack não usa esse auxiliar.
openclaw/plugin-sdk/channel-runtime é um shim de compatibilidade para plugins de canal antigos. Não o importe em código novo; use openclaw/plugin-sdk/channel-runtime-context para registrar objetos de runtime.Os auxiliares channelActions* em openclaw/plugin-sdk/channel-actions estão obsoletos, assim como as exportações brutas de “ações” de canal. Exponha recursos pela superfície semântica presentation — plugins de canal declaram o que renderizam (cartões, botões, seleções), em vez dos nomes brutos de ações que aceitam.
Antigo: fábrica tool() de openclaw/plugin-sdk/provider-web-search.Novo: implemente createTool(...) diretamente no plugin do provedor. O OpenClaw não precisa mais do auxiliar do SDK para registrar o wrapper da ferramenta.
Antigo: api.runtime.channel.reply.formatInboundEnvelope(...) (e o campo channelEnvelope nos objetos de mensagens recebidas) para criar um envelope de prompt simples em texto simples a partir de mensagens recebidas do canal.Novo: BodyForAgent mais blocos estruturados de contexto do usuário. Plugins de canal anexam metadados de roteamento (thread, tópico, resposta a, reações) como campos tipados, em vez de concatená-los em uma string de prompt. O auxiliar formatAgentEnvelope(...) continua compatível com envelopes sintetizados destinados ao assistente, mas os envelopes recebidos em texto simples estão sendo descontinuados.Áreas afetadas: inbound_claim, message_received e qualquer plugin de canal personalizado que pós-processava o texto antigo do envelope.
Antigo: api.on("deactivate", handler).Novo: api.on("gateway_stop", handler). Mesmo contrato de limpeza no encerramento; somente o nome do hook muda.
deactivate permanece conectado como um alias de compatibilidade obsoleto até ser removido após 2026-08-16.
Antigo: api.on("subagent_spawning", handler) retornando threadBindingReady ou deliveryOrigin.Novo: deixe o núcleo preparar as vinculações de subagentes com thread: true por meio do adaptador de vinculação de sessão do canal. Use api.on("subagent_spawned", handler) somente para observação após a inicialização.
subagent_spawning, PluginHookSubagentSpawningEvent, PluginHookSubagentSpawningResult e SubagentLifecycleHookRunner.runSubagentSpawning(...) permanecem apenas como superfícies de compatibilidade obsoletas enquanto os plugins externos migram, sendo removidas após 2026-08-30.
Quatro aliases de tipos de descoberta agora são wrappers leves sobre os tipos da era de catálogos:Além do antigo conjunto estático ProviderCapabilities — plugins de provedores devem usar hooks explícitos de provedor, como buildReplayPolicy, normalizeToolSchemas e wrapStreamFn, em vez de um objeto estático.
Antigo (três hooks separados em ProviderThinkingPolicy): isBinaryThinking(ctx), supportsXHighThinking(ctx) e resolveDefaultThinkingLevel(ctx).Novo: um único resolveThinkingProfile(ctx) que retorna um ProviderThinkingProfile com o id canônico, um label opcional e uma lista ordenada de níveis. O OpenClaw rebaixa automaticamente valores armazenados obsoletos de acordo com a classificação do perfil.O contexto inclui provider, modelId, o reasoning combinado opcional e os fatos combinados opcionais de compat do modelo. Plugins de provedores podem usar esses fatos do catálogo para expor um perfil específico do modelo somente quando o contrato de solicitação configurado oferece suporte a ele.Implemente um hook em vez de três. Os hooks antigos continuam funcionando durante o período de descontinuação, mas não são compostos com o resultado do perfil.
Antigo: implementar hooks externos de autenticação sem declarar o provedor no manifesto do plugin.Novo: declare contracts.externalAuthProviders no manifesto do plugin e implemente resolveExternalAuthProfiles(...).
Campo de manifesto antigo: providerAuthEnvVars: { anthropic: ["ANTHROPIC_API_KEY"] }.Novo: replique a mesma consulta de variável de ambiente em setup.providers[].envVars no manifesto. Isso consolida os metadados de ambiente de configuração/status em um só lugar e evita inicializar o runtime do plugin apenas para responder a consultas de variáveis de ambiente.providerAuthEnvVars continua compatível por meio de um adaptador de compatibilidade até o encerramento do período de descontinuação.
Antigo: três chamadas separadas — api.registerMemoryPromptSection(...), api.registerMemoryFlushPlan(...), api.registerMemoryRuntime(...).Novo: uma chamada na API de estado de memória — registerMemoryCapability(pluginId, { promptBuilder, flushPlanResolver, runtime }).Mesmos slots, uma única chamada de registro. Auxiliares adicionais de prompt e corpus (registerMemoryPromptSupplement, registerMemoryCorpusSupplement) não são afetados.
Antigo: api.registerMemoryEmbeddingProvider(...) mais contracts.memoryEmbeddingProviders.Novo: api.registerEmbeddingProvider(...) mais contracts.embeddingProviders.O contrato genérico de provedor de embeddings pode ser reutilizado fora da memória e é o caminho compatível para novos provedores. A API de registro específica de memória continua conectada como compatibilidade obsoleta enquanto os provedores existentes migram. A inspeção de plugins relata o uso não incluído como dívida de compatibilidade.
Dois aliases de tipos antigos ainda exportados de src/plugins/runtime/types.ts:O método de runtime readSession está obsoleto em favor de getSessionMessages. Mesma assinatura; o método antigo encaminha a chamada para o novo.
A migração de sessões/transcrições para SQLite remove ou descontinua APIs voltadas a plugins que expunham armazenamentos sessions.json ativos, caminhos de transcrições JSONL ou listas de arquivos de sessão. Plugins de runtime devem usar a identidade da sessão e os auxiliares de runtime do SDK, em vez de resolver ou modificar arquivos ativos.Os arquivos legados de transcrição JSONL continuam válidos como artefatos de importação, arquivamento, exportação e suporte. Eles não são mais o contrato de runtime de estado estável para sessões ativas.Os plugins oficiais lançados com v2026.7.1-beta.5 importavam os quatro auxiliares obsoletos acima. openclaw/plugin-sdk/session-store-runtime mantém exatamente essa ponte até 2026-10-12; novos plugins devem usar as substituições. resolveStorePath(...) continua sendo um auxiliar compatível do SDK e não faz parte desta descontinuação.openclaw plugins inspect --all --runtime relata plugins não integrados cujos erros de carregamento ou diagnósticos ainda fazem referência a essas APIs de arquivo removidas. A verificação consultiva do @openclaw/plugin-inspector deve usar a versão 0.3.17 ou mais recente para que as verificações de pacotes externos também sinalizem auxiliares de sessão para o armazenamento inteiro, auxiliares de caminho de arquivo de sessão, destinos legados de arquivo de transcrição e auxiliares de transcrição de baixo nível antes do lançamento.
Antigo: runtime.tasks.flow (singular) retornava um acessador de fluxo de tarefas ativo.Novo: runtime.tasks.managedFlows mantém o runtime gerenciado de mutação do TaskFlow para plugins que criam, atualizam, cancelam ou executam tarefas filhas a partir de um fluxo. Use runtime.tasks.flows quando o plugin precisar apenas de leituras baseadas em DTO.
Removido após 2026-07-26.
Abordado em Como migrar acima. Incluído aqui para fins de completude: o caminho removido api.registerEmbeddedExtensionFactory(...), exclusivo do executor incorporado, foi substituído por api.registerAgentToolResultMiddleware(...), com uma lista explícita de runtimes em contracts.agentToolResultMiddleware.
OpenClawSchemaType, reexportado de openclaw/plugin-sdk, agora é um alias de uma linha para OpenClawConfig. Prefira o nome canônico.
As descontinuações no nível das extensões (dentro dos plugins integrados de canal/provedor em extensions/) são rastreadas nos próprios barrels api.ts e runtime-api.ts. Elas não afetam os contratos de plugins de terceiros e não estão listadas aqui. Se você consumir diretamente o barrel local de um plugin integrado, leia os comentários de descontinuação desse barrel antes de atualizar.

Migração do Talk e de voz em tempo real

O código de voz em tempo real, telefonia, reuniões e Talk no navegador compartilha um único controlador de sessão do Talk exportado por openclaw/plugin-sdk/realtime-voice. O controlador é responsável pelo envelope comum de eventos do Talk, pelo estado do turno ativo, pelo estado de captura, pelo estado do áudio de saída, pelo histórico de eventos recentes e pela rejeição de turnos obsoletos. Os plugins de provedor são responsáveis pelas sessões em tempo real específicas de cada fornecedor; os plugins de superfície são responsáveis pelas particularidades de captura, reprodução, telefonia e reuniões. Todas as superfícies integradas são executadas no controlador compartilhado: retransmissão do navegador, transferência para sala gerenciada, chamada de voz em tempo real, STT de chamada de voz por streaming, Google Meet em tempo real e pressionar para falar nativo. O Gateway anuncia um único canal de eventos do Talk ao vivo em hello-ok.features.events: talk.event. O novo código não deve chamar createTalkEventSequencer(...) diretamente, a menos que esteja implementando um adaptador de baixo nível ou um fixture de teste. Use o controlador compartilhado para impedir que eventos com escopo de turno sejam emitidos sem um ID de turno, que chamadas obsoletas de turnEnd / turnCancel apaguem um turno ativo mais recente e para manter os eventos do ciclo de vida do áudio de saída consistentes entre telefonia, reuniões, retransmissão do navegador, transferência para sala gerenciada e clientes nativos do Talk. O formato da API pública:
As sessões WebRTC/websocket de provedor pertencentes ao navegador usam talk.client.create, pois o navegador é responsável pela negociação com o provedor e pelo transporte de mídia, enquanto o Gateway é responsável pelas credenciais, instruções e políticas de ferramentas. talk.session.* é a superfície comum gerenciada pelo Gateway para tempo real com retransmissão pelo Gateway, transcrição com retransmissão pelo Gateway e sessões nativas de STT/TTS em salas gerenciadas. Configurações legadas que colocam seletores de tempo real ao lado de talk.provider / talk.providers devem ser reparadas com openclaw doctor --fix; o runtime do Talk não reinterpreta a configuração do provedor de fala/TTS como configuração do provedor de tempo real. As combinações compatíveis com talk.session.create são intencionalmente limitadas: Mapa de métodos para leitores que estão migrando das famílias antigas talk.realtime.* / talk.transcription.* / talk.handoff.* (todas removidas): O vocabulário unificado de controle também é deliberadamente limitado: Não introduza casos especiais de provedor ou plataforma no núcleo para fazer isso funcionar. O núcleo é responsável pela semântica das sessões do Talk. Os plugins de provedor são responsáveis pela configuração das sessões dos fornecedores. Chamadas de voz e Google Meet são responsáveis pelos adaptadores de telefonia/reunião. Navegadores e aplicativos nativos são responsáveis pela experiência de captura/reprodução nos dispositivos.

Cronograma de remoção

Todos os plugins do núcleo já foram migrados. Os plugins externos devem ser migrados antes da próxima versão principal. Execute pnpm plugins:boundary-report para verificar quais registros de compatibilidade das superfícies usadas pelo seu plugin vencerão primeiro.

Suprimir temporariamente os avisos

Esta é uma saída de emergência temporária, não uma solução permanente.

Relacionados