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, comotool_result. Em vez disso, use middleware de resultados de ferramentas do agente (consulte Migrar extensões de resultados de ferramentas incorporadas para middleware).
registerEmbeddedExtensionFactory já foi removido;
registros legados não são mais carregados.
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.
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:- Adicionar o novo contrato.
- Manter o comportamento antigo conectado por meio de um adaptador de compatibilidade.
- Emitir um diagnóstico ou aviso que indique o caminho antigo e seu substituto.
- Abranger ambos os caminhos em testes.
- Documentar a descontinuação e o caminho de migração.
- Remover somente após o período de migração anunciado, geralmente em uma versão principal.
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
Migrar auxiliares de carregamento/gravação da configuração em tempo de execução
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: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:Migrar extensões de resultados de ferramentas incorporadas para middleware
api.registerEmbeddedExtensionFactory(...) por middleware
independente do ambiente de execução:contracts.agentToolResultMiddleware. Registros de middleware instalado não declarados
são rejeitados.Migrar manipuladores nativos de aprovação para fatos de capacidade
approvalCapability.nativeRuntime mais o registro compartilhado de contexto
em tempo de execução:- Substitua
approvalCapability.handler.loadRuntime(...)porapprovalCapability.nativeRuntime. - Remova autenticação/entrega específica de aprovação da conexão legada
plugin.auth/plugin.approvalse passe-a paraapprovalCapability. ChannelPlugin.approvalsfoi removido do contrato público de plugins de canal; mova os campos de entrega/nativos/renderização paraapprovalCapability.plugin.authpermanece 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
channelRuntimeparacreateChannelManager(...), forneça uma superfíciecreatePluginRuntime().channelreal - stubs parciais são rejeitados.
Auditar o comportamento de fallback de wrappers do Windows
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:allowShellFallback e, em vez disso, trate o erro lançado.Encontrar importações obsoletas
Substituir por importações específicas
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:infra-runtime,
portanto o código do repositório não pode regredir para o barrel amplo.Migre os helpers de rota de canal
openclaw/plugin-sdk/channel-route. Os
nomes antigos de chave de rota e destino comparável permanecem como aliases
de compatibilidade:{ 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.Compile e teste
Referência de caminhos de importação
Common import path table
Common import path table
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.Auxiliares de ajuda de command-auth -> command-status
Auxiliares de ajuda de command-auth -> command-status
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.Auxiliares de controle de menções -> resolveInboundMentionDecision
Auxiliares de controle de menções -> resolveInboundMentionDecision
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.Shim de runtime de canal e auxiliares de ações de canal
Shim de runtime de canal e auxiliares de ações de canal
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.Auxiliar tool() do provedor de pesquisa na web -> createTool() no plugin
Auxiliar tool() do provedor de pesquisa na web -> createTool() no plugin
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.Envelopes de canal em texto simples -> BodyForAgent
Envelopes de canal em texto simples -> BodyForAgent
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.Hook deactivate -> gateway_stop
Hook deactivate -> gateway_stop
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.Hook subagent_spawning -> vinculação de thread pelo núcleo
Hook subagent_spawning -> vinculação de thread pelo núcleo
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.Tipos de descoberta de provedores -> tipos de catálogo de provedores
Tipos de descoberta de provedores -> tipos de catálogo de provedores
ProviderCapabilities — plugins de provedores
devem usar hooks explícitos de provedor, como buildReplayPolicy,
normalizeToolSchemas e wrapStreamFn, em vez de um objeto estático.Hooks de política de raciocínio -> resolveThinkingProfile
Hooks de política de raciocínio -> resolveThinkingProfile
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.Provedores externos de autenticação -> contracts.externalAuthProviders
Provedores externos de autenticação -> contracts.externalAuthProviders
contracts.externalAuthProviders no manifesto do plugin
e implemente resolveExternalAuthProfiles(...).Consulta de variável de ambiente do provedor -> setup.providers[].envVars
Consulta de variável de ambiente do provedor -> setup.providers[].envVars
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.Registro de plugin de memória -> registerMemoryCapability
Registro de plugin de memória -> registerMemoryCapability
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.API de provedor de embeddings de memória
API de provedor de embeddings de memória
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.Tipos de mensagens de sessão de subagentes renomeados
Tipos de mensagens de sessão de subagentes renomeados
src/plugins/runtime/types.ts:readSession está obsoleto em favor de
getSessionMessages. Mesma assinatura; o método antigo encaminha a chamada
para o novo.APIs de arquivos de sessão e transcrição removidas
APIs de arquivos de sessão e transcrição removidas
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.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.runtime.tasks.flow -> runtime.tasks.managedFlows
runtime.tasks.flow -> runtime.tasks.managedFlows
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.Fábricas de extensão incorporadas -> middleware de resultados de ferramentas do agente
Fábricas de extensão incorporadas -> middleware de resultados de ferramentas do agente
api.registerEmbeddedExtensionFactory(...),
exclusivo do executor incorporado, foi substituído por
api.registerAgentToolResultMiddleware(...), com uma lista explícita de
runtimes em contracts.agentToolResultMiddleware.Alias OpenClawSchemaType -> OpenClawConfig
Alias OpenClawSchemaType -> OpenClawConfig
OpenClawSchemaType, reexportado de openclaw/plugin-sdk, agora é um alias
de uma linha para OpenClawConfig. Prefira o nome canônico.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 poropenclaw/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:
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:
talk.realtime.* / talk.transcription.* / talk.handoff.* (todas removidas):
Cronograma de remoção
pnpm plugins:boundary-report para verificar quais
registros de compatibilidade das superfícies usadas pelo seu plugin vencerão primeiro.
Suprimir temporariamente os avisos
Relacionados
- Primeiros passos - crie seu primeiro plugin
- Visão geral do SDK - referência completa de importação de subcaminhos
- Plugins de canal - criação de plugins de canal
- Plugins de provedor - criação de plugins de provedor
- Detalhes internos dos plugins - análise aprofundada da arquitetura
- Manifesto do plugin - referência do esquema do manifesto