Skip to main content
OpenClaw sustituyó una amplia capa de compatibilidad con versiones anteriores por una arquitectura de plugins moderna construida a partir de importaciones pequeñas y específicas. Si el plugin es anterior a ese cambio, esta guía permite adaptarlo a los contratos actuales.

Qué cambió

Anteriormente, varias superficies de importación muy abiertas permitían que los plugins accedieran a casi cualquier cosa desde un único punto de entrada:
  • openclaw/plugin-sdk y openclaw/plugin-sdk/compat: reexportaban decenas de auxiliares mientras se desarrollaba el SDK específico. Ambas raíces se han eliminado; importe en su lugar una subruta documentada.
  • openclaw/plugin-sdk/infra-runtime: un barrel amplio que mezclaba eventos del sistema, estado de Heartbeat, colas de entrega, auxiliares de obtención/proxy, auxiliares de archivos, tipos de aprobación y utilidades no relacionadas.
  • openclaw/plugin-sdk/config-runtime: un barrel de configuración amplio conservado únicamente durante su ventana de compatibilidad posterior; se han eliminado los auxiliares directos de carga/escritura en tiempo de ejecución.
  • openclaw/extension-api: un puente eliminado que proporcionaba a los plugins acceso directo a auxiliares del lado del host, como el ejecutor de agentes integrado.
  • api.registerEmbeddedExtensionFactory(...): un hook eliminado exclusivo del ejecutor integrado que observaba eventos de dicho ejecutor, como tool_result. Use en su lugar middleware de resultados de herramientas del agente (consulte Migrar extensiones de resultados de herramientas integradas a middleware).
Se han eliminado el SDK raíz, el barrel de compatibilidad, el puente de extensiones y la fábrica de extensiones integradas. infra-runtime y config-runtime se mantienen únicamente durante sus ventanas posteriores registradas por separado; los plugins nuevos deben usar subrutas específicas.
Los plugins que importan las superficies raíz, de compatibilidad o de extensión eliminadas ya no se cargan. Siga las correspondencias indicadas a continuación antes de actualizar.
OpenClaw no elimina ni reinterpreta el comportamiento documentado de los plugins en el mismo cambio que introduce un reemplazo. Los cambios incompatibles en los contratos pasan primero por un adaptador de compatibilidad, diagnósticos, documentación y un periodo de obsolescencia. Esto se aplica a las importaciones del SDK, los campos del manifiesto, las API de configuración, los hooks y el comportamiento de registro en tiempo de ejecución.

Motivos

  • Inicio lento: importar un auxiliar cargaba decenas de módulos no relacionados.
  • Dependencias circulares: las reexportaciones amplias facilitaban la creación de ciclos de importación.
  • Superficie de API poco clara: no había forma de distinguir las exportaciones estables de las internas.
Ahora, cada openclaw/plugin-sdk/<subpath> es un módulo pequeño y autónomo con un contrato documentado. También se han eliminado las antiguas interfaces auxiliares de proveedores para los canales incluidos: los atajos auxiliares específicos de cada canal eran recursos privados del monorrepositorio, no contratos estables para plugins. Use en su lugar subrutas genéricas y específicas del SDK. Dentro del espacio de trabajo de plugins incluidos, mantenga los auxiliares propiedad del proveedor en los api.ts o runtime-api.ts del propio plugin:
  • Anthropic mantiene los auxiliares de flujos específicos de Claude en su propia interfaz api.ts / contract-api.ts.
  • OpenAI mantiene los constructores de proveedores, los auxiliares de modelos predeterminados y los constructores de proveedores en tiempo real en su propio api.ts.
  • OpenRouter mantiene el constructor de proveedores y los auxiliares de incorporación/configuración en su propio api.ts.

Política de compatibilidad

El trabajo de compatibilidad de plugins externos sigue este orden:
  1. Añadir el nuevo contrato.
  2. Mantener el comportamiento anterior conectado mediante un adaptador de compatibilidad.
  3. Emitir un diagnóstico o una advertencia que indique la ruta anterior y su reemplazo.
  4. Cubrir ambas rutas en las pruebas.
  5. Documentar la obsolescencia y la ruta de migración.
  6. Eliminar únicamente después del periodo de migración anunciado, normalmente en una versión principal.
Si todavía se acepta un campo del manifiesto, siga utilizándolo hasta que la documentación y los diagnósticos indiquen lo contrario. El código nuevo debe preferir el reemplazo documentado; los plugins existentes no deben dejar de funcionar durante actualizaciones menores ordinarias.

Compatibilidad de la configuración de canales publicados

Los paquetes de Slack, Discord, Signal y Microsoft Teams publicados mediante 2026.7.1 importan esquemas de configuración específicos del canal desde openclaw/plugin-sdk/bundled-channel-config-schema. Los paquetes publicados de Slack y Discord también importan createLegacyCompatChannelDmPolicy y promptLegacyChannelAllowFromForAccount desde openclaw/plugin-sdk/setup-runtime. Esas exportaciones siguen disponibles como adaptadores de compatibilidad en tiempo de ejecución obsoletos. Los plugins nuevos y republicados deben gestionar localmente sus propios esquemas de configuración y su política de configuración mediante primitivas genéricas de channel-config-schema y setup-runtime. Las exportaciones de compatibilidad solo pueden eliminarse cuando las versiones mínimas admitidas de los paquetes publicados ya no las importen.

Compatibilidad de campos de entrada de configuración de canales

ChannelSetupInput ahora mantiene tipado permanentemente solo el contenedor de configuración común a todos los canales. Los campos específicos de cada canal permanecen tipados en un nivel de compatibilidad obsoleto para que los plugins externos existentes sigan compilándose mientras sus autores trasladan esos campos a tipos de entrada de configuración locales del plugin. OpenClaw no publica versiones principales. Un análisis del registro realizado el 2026-07-22 inspeccionó 426 plugins de canal externos publicados y eliminó 21 campos sin lectores. Cada uno de los 22 campos conservados tiene un lector publicado conocido. Cada campo adicional se elimina en cuanto ningún plugin publicado lo lee; el conjunto conservado se reduce a medida que los autores de plugins migran a tipos de entrada de configuración locales del plugin. El mismo análisis eliminó 23 claves heredadas de promoción de adaptadores no declaradas sin dependientes publicados. Permanecen seis claves comunes y la clave exclusiva de configuración rooms. Ese conjunto también se reduce a medida que los plugins publicados declaran singleAccountKeysToMove. El tipo compartido no tiene firma de índice. Las claves propiedad del plugin pueden seguir presentes en los objetos de entrada en tiempo de ejecución; declárelas en una intersección local del plugin o redúzcalas mediante el esquema de configuración del plugin propietario. El nivel heredado de promoción de adaptadores no declarados sigue la misma política basada en lectores. Declare singleAccountKeysToMove, incluido un array vacío cuando el plugin no necesite claves de promoción adicionales, para que el recurso compartido alternativo pueda retirarse clave por clave.

Verificación de lectores

  1. Recorra por páginas https://clawhub.ai/api/v1/packages?family=code-plugin&limit=100 con cada nextCursor y conserve los paquetes cuyos categories incluyan channels.
  2. Añada candidatos de npm desde npm search --json --searchlimit=1000 "openclaw channel plugin". Añada candidatos disponibles solo como código fuente a partir de búsquedas de código de GitHub para openclaw/plugin-sdk/channel-setup, openclaw/plugin-sdk/setup y openclaw/plugin-sdk/core.
  3. Determine la última versión publicada de cada candidato. Ejecute npm pack <package>@<version> --json --pack-destination <temp-dir>, desempaquétela e inspeccione el JavaScript y las declaraciones distribuidos en dist para detectar lecturas directas o desestructuradas de campos. Descargue el artefacto de ClawHub cuando un paquete no tenga una versión en npm.
  4. Registre el paquete, la versión, el campo o la clave de promoción y el archivo coincidente. Un campo o una clave solo puede eliminarse cuando ningún artefacto publicado de un plugin lo lea. Mantenga sincronizados con el análisis los nombres de los lectores en los comentarios del código junto a las listas de campos y claves conservados.
Este es únicamente un registro de compatibilidad de código fuente/tipos. No tiene ningún adaptador en tiempo de ejecución ni entrada en el registro de compatibilidad porque los objetos de entrada de configuración en tiempo de ejecución y el comportamiento de configuración no han cambiado. Audite la cola de migración actual con pnpm plugins:boundary-report: pnpm plugins:boundary-report:ci se ejecuta con las tres opciones de error. Los registros obsoletos suelen tener una fecha removeAfter explícita en lugar de una imprecisa «próxima versión principal». Un registro cuyo propietario no haya aprobado una fecha deja removeAfter ausente, aparece como no-date y nunca puede eliminarse. El informe agrupa los registros obsoletos por fecha, cuenta las referencias locales de código/documentación, muestra las importaciones reservadas del SDK entre propietarios y resume el puente privado del SDK del host de memoria. Las subrutas reservadas del SDK deben tener un uso registrado por parte del propietario; las exportaciones reservadas sin usar deben eliminarse del SDK público.

Proyección heredada de medios

El registro de compatibilidad media-legacy-projection abarca los antiguos campos paralelos de medios, los constructores de payloads, los alias de metadatos de hooks y los nombres de plantillas de medios. Su fecha removeAfter aprobada es 2026-10-01 (dos ciclos de publicación después de que se distribuyeran los reemplazos basados primero en hechos). Además, su eliminación requiere en ese momento un análisis limpio de los artefactos de plugins publicados; migre antes de la fecha. Para la entrada de canales, sustituya los valores singular/plural MediaPath, MediaUrl, MediaType, MediaPaths, MediaUrls, MediaTypes, MediaTranscribedIndexes, MediaWorkspaceDir y MediaStaged por hechos ordenados:
Use event.media en los hooks inbound_claim y message_received. Si los medios remotos no se han preparado localmente, use event.originalMedia para identidad/diagnósticos y espere a event.media; event.mediaStagingPending distingue ese estado. No lea las propiedades singular/plural obsoletas de event.metadata. Para los modelos multimedia de la CLI, sustituya {{MediaPath}}, {{MediaUrl}}, {{MediaType}} y {{MediaDir}} por {{AttachmentPath}}, {{AttachmentUrl}}, {{AttachmentContentType}} y {{AttachmentDir}}. Use {{AttachmentIndex}} cuando la posición de los archivos adjuntos sea importante. Para la política de lectura de medios locales, importe getAgentScopedMediaLocalRoots(...) o getAgentScopedMediaLocalRootsForSources(...) desde openclaw/plugin-sdk/media-local-roots. La fachada openclaw/plugin-sdk/agent-media-payload y su proyección buildAgentMediaPayload(...) están obsoletas.

Cómo migrar

1

Migrar los auxiliares de carga/escritura de configuración en tiempo de ejecución

Los plugins incluidos deben dejar de llamar directamente a api.runtime.config.loadConfig() y api.runtime.config.writeConfigFile(...). Es preferible usar la configuración ya pasada a la ruta de llamada activa. Los controladores de larga duración que necesiten la instantánea actual del proceso pueden usar api.runtime.config.current(). Las herramientas de agente de larga duración deben leer ctx.getRuntimeConfig() dentro de execute para que una herramienta creada antes de una escritura de configuración siga viendo la configuración actualizada.Las escrituras de configuración pasan por el auxiliar transaccional con una política explícita posterior a la escritura:
Use afterWrite: { mode: "restart", reason: "..." } cuando el cambio requiera un reinicio limpio del Gateway, y afterWrite: { mode: "none", reason: "..." } solo cuando el llamador sea responsable del seguimiento y suprima deliberadamente el planificador de recarga. Los resultados de las mutaciones incluyen un resumen tipado followUp para pruebas y registros; el Gateway sigue siendo responsable de aplicar o programar el reinicio.loadConfig y writeConfigFile se han eliminado del entorno de ejecución de plugins. Los plugins incluidos y el código del entorno de ejecución del repositorio están protegidos por pnpm check:deprecated-api-usage y pnpm check:no-runtime-action-load-config: el nuevo uso en producción de plugins falla por completo, las escrituras directas de configuración fallan, los métodos del servidor Gateway deben usar la instantánea del entorno de ejecución de la solicitud, los asistentes de envío/acción/cliente de canales del entorno de ejecución deben recibir la configuración desde su límite, y los módulos de larga duración del entorno de ejecución no permiten ninguna llamada ambiental a loadConfig().El código nuevo de plugins debe evitar el barrel amplio openclaw/plugin-sdk/config-runtime. Use la subruta específica para la tarea:Los plugins incluidos y sus pruebas están protegidos mediante análisis contra el barrel amplio para que las importaciones y los mocks permanezcan limitados al comportamiento que necesitan. El barrel sigue existiendo por compatibilidad externa, pero el código nuevo no debe depender de él.
2

Migrar las extensiones de resultados de herramientas integradas a middleware

Los plugins incluidos deben reemplazar los controladores de resultados de herramientas api.registerEmbeddedExtensionFactory(...), exclusivos del ejecutor integrado, por middleware independiente del entorno de ejecución:
Actualice al mismo tiempo el manifiesto del plugin:
Los plugins instalados también pueden registrar middleware de resultados de herramientas cuando esté habilitado explícitamente y cada entorno de ejecución de destino esté declarado en contracts.agentToolResultMiddleware. Los registros de middleware instalado no declarado se rechazan.
3

Migrar los controladores nativos de aprobación a hechos de capacidad

Los plugins de canal con capacidad de aprobación exponen el comportamiento nativo de aprobación mediante approvalCapability.nativeRuntime junto con el registro compartido de contexto del entorno de ejecución:
  • Reemplace approvalCapability.handler.loadRuntime(...) por approvalCapability.nativeRuntime.
  • Traslade la autenticación/entrega específica de aprobaciones fuera del cableado heredado de plugin.auth / plugin.approvals y pásela a approvalCapability.
  • ChannelPlugin.approvals se ha eliminado del contrato público de plugins de canal; traslade los campos de entrega/nativos/renderizado a approvalCapability.
  • plugin.auth se mantiene únicamente para los flujos de inicio/cierre de sesión del canal; el núcleo ya no lee allí los hooks de autenticación de aprobaciones.
  • Registre los objetos del entorno de ejecución propiedad del canal (clientes, tokens, aplicaciones Bolt) mediante openclaw/plugin-sdk/channel-runtime-context.
  • No envíe avisos de redireccionamiento propiedad del plugin desde los controladores nativos de aprobación; el núcleo controla los avisos de redireccionamiento a otro lugar a partir de los resultados reales de entrega.
  • Al pasar channelRuntime a createChannelManager(...), proporcione una superficie createPluginRuntime().channel real; los stubs parciales se rechazan.
Consulte Plugins de canal para conocer la disposición actual de la capacidad de aprobación.
4

Auditar el comportamiento de respaldo de los wrappers de Windows

Si el plugin usa openclaw/plugin-sdk/windows-spawn, los wrappers de Windows .cmd/.bat no resueltos ahora fallan de forma cerrada, salvo que se pase explícitamente allowShellFallback: true:
Si el llamador no depende intencionadamente del respaldo del shell, no establezca allowShellFallback y gestione en su lugar el error generado.
5

Buscar importaciones obsoletas

6

Reemplazar por importaciones específicas

Cada exportación de la superficie anterior se corresponde con una ruta de importación moderna específica:
Para los asistentes del lado del host, use el entorno de ejecución del plugin inyectado en lugar de realizar una importación directa:
El mismo patrón se aplica a otros asistentes de puente heredados:
7

Reemplazar las importaciones amplias de infra-runtime

openclaw/plugin-sdk/infra-runtime sigue existiendo por compatibilidad externa, pero el código nuevo debe importar la superficie específica que realmente necesita:Los plugins incluidos están protegidos mediante análisis contra infra-runtime, por lo que el código del repositorio no puede volver a usar el barrel amplio.
8

Migrar los asistentes de rutas de canal

El código nuevo de rutas de canal usa openclaw/plugin-sdk/channel-route. Los nombres anteriores de claves de ruta se mantienen como alias de compatibilidad:Los asistentes modernos de rutas normalizan { channel, to, accountId, threadId } de forma coherente entre las aprobaciones nativas, la supresión de respuestas, la desduplicación entrante, la entrega de Cron y el enrutamiento de sesiones.No añada usos nuevos de ChannelMessagingAdapter.parseExplicitTarget ni resolveChannelRouteTargetWithParser(...) desde plugin-sdk/channel-route; están obsoletos y se mantienen únicamente para plugins anteriores. Los plugins de canal nuevos deben usar messaging.targetResolver.resolveTarget(...) para la normalización del identificador de destino y el respaldo cuando no se encuentra el directorio, messaging.inferTargetChatType(...) cuando el núcleo necesite conocer de forma anticipada el tipo de par, y messaging.resolveOutboundSessionRoute(...) para la identidad de sesión e hilo nativa del proveedor.
9

Compilar y probar

Referencia de rutas de importación

El mapa de exportaciones del paquete público es la fuente de verdad de las subrutas importables del SDK. Use las guías temáticas del SDK enlazadas desde la descripción general del SDK y prefiera la subruta pública documentada más específica. El inventario del compilador en scripts/lib/plugin-sdk-entrypoints.json también contiene entradas locales privadas utilizadas para compilar plugins incluidos; su presencia allí no las convierte en exportaciones públicas del paquete. Esta tabla es el subconjunto común de migración, no toda la superficie del SDK. El inventario de puntos de entrada del compilador se encuentra en scripts/lib/plugin-sdk-entrypoints.json; las exportaciones del paquete se generan a partir del subconjunto público. Las interfaces auxiliares reservadas para plugins incluidos se han retirado del mapa de exportaciones del SDK público, salvo las fachadas de compatibilidad documentadas explícitamente, como el shim obsoleto plugin-sdk/discord, conservado para plugins externos que todavía importan directamente el paquete publicado @openclaw/discord. Los asistentes específicos de cada propietario residen dentro del paquete del plugin correspondiente; el comportamiento compartido del host se canaliza mediante contratos genéricos del SDK, como plugin-sdk/gateway-runtime, plugin-sdk/security-runtime y la API del plugin inyectada. Use la importación más específica que corresponda a la tarea. Si no encuentra una exportación, consulte el código fuente en src/plugin-sdk/ o pregunte a los responsables qué contrato genérico debe asumirla.

Superficies de compatibilidad eliminadas

La revisión de julio de 2026 eliminó los barrels raíz y de compatibilidad del SDK, el puente de la API de extensiones, los alias caducados de subrutas del SDK, las subrutas del SDK sin uso y las exportaciones públicas de módulos del SDK exclusivos de plugins incluidos. Los módulos exclusivos de plugins incluidos siguen disponibles para sus propietarios del repositorio mediante asignaciones de compilación locales privadas; no pueden importarse desde el paquete publicado.

Publicación global del proceso de proveedores de API

registerApiProvider(...) y unregisterApiProviders(...) se eliminaron de openclaw/plugin-sdk/llm. Publicaban transportes de API en el estado global del proceso, que los entornos de ejecución de modelos administrados por el ciclo de vida debían copiar después en cada registro preparado. Los plugins de proveedores deben registrar los proveedores de inferencia de texto mediante api.registerProvider(...). El código y las pruebas propiedad del host que construyan un ApiRegistry deben registrarse directamente en ese registro para que la propiedad del proveedor y su desmontaje permanezcan limitados al entorno de ejecución preparado.

Barrel privado de pruebas

openclaw/plugin-sdk/testing era local del repositorio y estaba excluido de los artefactos del paquete distribuido, por lo que se eliminó antes de su fecha removeAfter de 2026-07-28. Las pruebas del repositorio usan subrutas específicas como plugin-sdk/plugin-test-runtime, plugin-sdk/channel-test-helpers, plugin-sdk/channel-target-testing, plugin-sdk/test-env y plugin-sdk/test-fixtures.

Referencia de migración

Estas correspondencias abarcan tanto las superficies eliminadas en julio de 2026 como las desaprobaciones activas de periodos posteriores. Una correspondencia es una guía de migración, no una prueba de que la superficie anterior siga disponible; consulte el registro de compatibilidad y el calendario de eliminación para conocer el estado actual.
Anterior (openclaw/plugin-sdk/command-auth): buildCommandsMessage, buildCommandsMessagePaginated, buildHelpMessage.Nuevo (openclaw/plugin-sdk/command-status): las mismas firmas, importadas desde la subruta más específica. Se han eliminado las reexportaciones de compatibilidad de command-auth.
Anterior: resolveMentionGating(params) y resolveMentionGatingWithBypass(params) de openclaw/plugin-sdk/channel-inbound o openclaw/plugin-sdk/channel-mention-gating.Nuevo: resolveInboundMentionDecision({ facts, policy }): un único objeto de decisión en lugar de dos formas de llamada separadas.Adoptado en Discord, iMessage, Matrix, MS Teams, QQBot, Signal, Telegram, WhatsApp y Zalo. El modelo de eventos app_mention propio de Slack no utiliza esta función auxiliar.
Se ha eliminado openclaw/plugin-sdk/channel-runtime. Utilice openclaw/plugin-sdk/channel-runtime-context para registrar objetos del entorno de ejecución.Las funciones auxiliares del esquema de mensajes nativos de openclaw/plugin-sdk/channel-actions se eliminaron junto con las exportaciones de acciones sin procesar del canal. En su lugar, exponga las capacidades mediante la superficie semántica presentation: los plugins de canal declaran qué representan (tarjetas, botones y selectores), en vez de los nombres de acciones sin procesar que aceptan.
Anterior: fábrica tool() de openclaw/plugin-sdk/provider-web-search.Nuevo: implemente createTool(...) directamente en el plugin del proveedor. OpenClaw ya no necesita la función auxiliar del SDK para registrar el contenedor de la herramienta.
Anterior: api.runtime.channel.reply.formatInboundEnvelope(...) (y el campo channelEnvelope de los objetos de mensajes entrantes) para crear un envoltorio plano de solicitud en texto sin formato a partir de mensajes entrantes del canal.Nuevo: BodyForAgent más bloques estructurados de contexto del usuario. Los plugins de canal adjuntan los metadatos de enrutamiento (hilo, tema, respuesta y reacciones) como campos tipados, en lugar de concatenarlos en una cadena de solicitud. La función auxiliar formatAgentEnvelope(...) sigue siendo compatible con los envoltorios sintetizados dirigidos al asistente, pero los envoltorios entrantes de texto sin formato están en proceso de eliminación.Áreas afectadas: inbound_claim, message_received y cualquier plugin de canal personalizado que procesara posteriormente el texto del envoltorio anterior.
Anterior: api.on("deactivate", handler).Nuevo: api.on("gateway_stop", handler). El mismo contrato de limpieza durante el apagado; solo cambia el nombre del enlace.
deactivate continúa conectado como alias de compatibilidad desaprobado hasta su eliminación después del 2026-08-16.
Anterior: api.on("subagent_spawning", handler) devolvía threadBindingReady o deliveryOrigin.Nuevo: permita que el núcleo prepare las vinculaciones de subagentes thread: true mediante el adaptador de vinculación de sesiones del canal. Utilice api.on("subagent_spawned", handler) únicamente para la observación posterior al inicio.
subagent_spawning, PluginHookSubagentSpawningEvent, PluginHookSubagentSpawningResult y SubagentLifecycleHookRunner.runSubagentSpawning(...) se mantienen únicamente como superficies de compatibilidad desaprobadas mientras migran los plugins externos y se eliminarán después del 2026-08-30.
Cuatro alias de tipos de descubrimiento son ahora contenedores ligeros de los tipos de la era del catálogo:Se han eliminado los alias y el contenedor estático heredado ProviderCapabilities. Los plugins de proveedores deben utilizar enlaces explícitos del proveedor, como buildReplayPolicy, normalizeToolSchemas y wrapStreamFn, en lugar de un objeto estático.
Anterior (tres enlaces separados en ProviderThinkingPolicy): isBinaryThinking(ctx), supportsXHighThinking(ctx) y resolveDefaultThinkingLevel(ctx).Nuevo: un único resolveThinkingProfile(ctx) que devuelve un ProviderThinkingProfile con el id canónico, un label opcional y una lista ordenada de niveles. OpenClaw reduce automáticamente los valores almacenados obsoletos según la clasificación del perfil.El contexto incluye provider, modelId, un reasoning combinado opcional y datos combinados opcionales del modelo compat. Los plugins de proveedores pueden utilizar esos datos del catálogo para exponer un perfil específico del modelo únicamente cuando el contrato de solicitud configurado lo admita.Implemente un enlace en lugar de tres. Se han eliminado los enlaces heredados.
Anterior: implementar enlaces de autenticación externa sin declarar el proveedor en el manifiesto del plugin.Nuevo: declare contracts.externalAuthProviders en el manifiesto del plugin e implemente resolveExternalAuthProfiles(...).
Campo anterior del manifiesto: providerAuthEnvVars: { anthropic: ["ANTHROPIC_API_KEY"] }.Nuevo: replique la misma búsqueda de variables de entorno en setup.providers[].envVars dentro del manifiesto. Esto consolida los metadatos de variables de entorno de configuración y estado en un solo lugar, y evita iniciar el entorno de ejecución del plugin únicamente para resolver búsquedas de variables de entorno.providerAuthEnvVars ya no se acepta.
Anterior: tres llamadas separadas: api.registerMemoryPromptSection(...), api.registerMemoryFlushPlan(...), api.registerMemoryRuntime(...).Nuevo: una llamada en la API de estado de memoria: registerMemoryCapability(pluginId, { promptBuilder, flushPlanResolver, runtime }).Las mismas ranuras, una única llamada de registro. Las funciones auxiliares aditivas de solicitud y corpus (registerMemoryPromptSupplement, registerMemoryCorpusSupplement) no se ven afectadas.
Anterior: api.registerMemoryEmbeddingProvider(...) más contracts.memoryEmbeddingProviders.Nuevo: api.registerEmbeddingProvider(...) más contracts.embeddingProviders.El contrato genérico del proveedor de incrustaciones se puede reutilizar fuera de la memoria y es la vía compatible para los proveedores nuevos. La API de registro específica de memoria continúa conectada como compatibilidad desaprobada mientras migran los proveedores existentes. La inspección de plugins informa del uso fuera del paquete como deuda de compatibilidad.
Anterior: devolvía { ok, messageId, error } mediante ChannelSendRawResult y lo normalizaba con createRawChannelSendResultAdapter(...).Nuevo: devuelva los campos OutboundDeliveryResult y adjunte el canal con createAttachedChannelResultAdapter(...). Los envíos fallidos deben generar una excepción en lugar de devolver una cadena de error. El tipo de resultado sin procesar seguirá disponible hasta la próxima versión principal del SDK de plugins.
Dos alias de tipos heredados que aún se exportan desde src/plugins/runtime/types.ts:El método del entorno de ejecución readSession está desaprobado en favor de getSessionMessages. La misma firma; el método anterior delega en el nuevo.
El cambio de sesiones y transcripciones a SQLite elimina o desaprueba las API orientadas a plugins que exponían almacenes sessions.json activos, rutas de transcripciones JSONL o listas de archivos de sesiones. Los plugins del entorno de ejecución deben utilizar la identidad de sesión y las funciones auxiliares del entorno de ejecución del SDK, en lugar de resolver o modificar archivos activos.Los archivos de transcripciones JSONL heredados siguen siendo válidos como artefactos de importación, archivo, exportación y soporte. Ya no son el contrato permanente del entorno de ejecución para las sesiones activas.Los plugins oficiales publicados con v2026.7.1-beta.5 importaban las cuatro funciones auxiliares desaprobadas anteriores. openclaw/plugin-sdk/session-store-runtime mantiene exactamente ese puente hasta el 2026-10-12; los plugins nuevos deben utilizar las sustituciones. resolveStorePath(...) sigue siendo una función auxiliar compatible del SDK y no forma parte de esta desaprobación.openclaw plugins inspect --all --runtime informa de los plugins fuera del paquete cuyos errores de carga o diagnósticos todavía hacen referencia a estas API de archivos eliminadas. El análisis de avisos @openclaw/plugin-inspector debe utilizar la versión 0.3.17 o una posterior, para que los análisis de paquetes externos también detecten las funciones auxiliares del almacén completo de sesiones, las funciones auxiliares de rutas de archivos de sesiones, los destinos de archivos de transcripciones heredados y las funciones auxiliares de bajo nivel para transcripciones antes de la publicación.
Anterior: runtime.tasks.flow (singular) devolvía un descriptor activo de flujo de tareas.Nuevo: runtime.tasks.managedFlows conserva el entorno de ejecución administrado de modificación de TaskFlow para los plugins que crean, actualizan, cancelan o ejecutan tareas secundarias desde un flujo. Utilice runtime.tasks.flows cuando el plugin solo necesite lecturas basadas en DTO.
Los alias heredados se eliminaron en julio de 2026.
Se explica en Cómo migrar más arriba. Se incluye aquí para completar la información: la ruta eliminada exclusiva del ejecutor integrado api.registerEmbeddedExtensionFactory(...) se sustituye por api.registerAgentToolResultMiddleware(...) con una lista explícita de entornos de ejecución en contracts.agentToolResultMiddleware.
Se eliminó el alias OpenClawSchemaType del SDK raíz. Utilice el nombre canónico OpenClawConfig.
Las obsolescencias a nivel de extensión (dentro de los plugins de canal/proveedor incluidos en extensions/) se registran en sus propios barrels api.ts y runtime-api.ts. No afectan a los contratos de plugins de terceros y no se enumeran aquí. Si se consume directamente el barrel local de un plugin incluido, deben leerse los comentarios de obsolescencia de ese barrel antes de actualizar.

Migración de Talk y voz en tiempo real

El código de voz en tiempo real, telefonía, reuniones y Talk en el navegador comparte un único controlador de sesiones de Talk exportado por openclaw/plugin-sdk/realtime-voice. El controlador gestiona el sobre común de eventos de Talk, el estado del turno activo, el estado de captura, el estado del audio de salida, el historial de eventos recientes y el rechazo de turnos obsoletos. Los plugins de proveedor gestionan las sesiones en tiempo real específicas del proveedor. Los plugins de reuniones en el navegador utilizan openclaw/plugin-sdk/meeting-runtime para los mecanismos de sesión, navegador, audio, host de Node, consulta con el agente y llamada de voz, y luego implementan MeetingPlatformAdapter para las reglas de URL, los scripts del DOM, la asignación de acciones manuales, los subtítulos, la creación y los planes de acceso telefónico. Las API REST de la plataforma, OAuth, los artefactos, los selectores y los nombres del protocolo permanecen en el plugin. Los planes de permisos del navegador reciben la URL de reunión solicitada para que cada plataforma pueda conceder únicamente sus orígenes compatibles exactos. Los entornos de ejecución de sesión también deben normalizar el estado de funcionamiento en directo específico de la plataforma tras confirmarse la salida del navegador; los campos históricos de la transcripción pueden permanecer, pero la disponibilidad de subtítulos y audio no debe seguir activa después de salir. Todas las superficies incluidas se ejecutan en el controlador compartido: relay del navegador, transferencia de sala gestionada, llamada de voz en tiempo real, STT de transmisión de llamadas de voz, Google Meet en tiempo real y pulsar para hablar nativo. El Gateway anuncia un único canal de eventos de Talk en directo en hello-ok.features.events: talk.event. El código nuevo no debe llamar directamente a createTalkEventSequencer(...), salvo que implemente un adaptador de bajo nivel o un fixture de prueba. Utilice el controlador compartido para que los eventos limitados a un turno no puedan emitirse sin un identificador de turno, las llamadas obsoletas turnEnd / turnCancel no puedan borrar un turno activo más reciente y los eventos del ciclo de vida del audio de salida permanezcan coherentes entre la telefonía, las reuniones, el relay del navegador, la transferencia de sala gestionada y los clientes nativos de Talk. La forma de la API pública:
Las sesiones de WebRTC/websocket de proveedor gestionadas por el navegador utilizan talk.client.create, porque el navegador gestiona la negociación con el proveedor y el transporte multimedia, mientras que el Gateway gestiona las credenciales, las instrucciones y la política de herramientas. talk.session.* es la superficie común gestionada por el Gateway para las sesiones en tiempo real mediante relay del Gateway, la transcripción mediante relay del Gateway y las sesiones nativas de STT/TTS de salas gestionadas. Las configuraciones heredadas que sitúan selectores de tiempo real junto a talk.provider / talk.providers deben repararse con openclaw doctor --fix; Talk en tiempo de ejecución no reinterpreta la configuración del proveedor de voz/TTS como configuración del proveedor en tiempo real. Las combinaciones compatibles de talk.session.create son intencionadamente reducidas: Mapa de métodos para quienes migren desde las familias anteriores talk.realtime.* / talk.transcription.* / talk.handoff.* (todas eliminadas): El vocabulario de control unificado también es deliberadamente reducido: No introduzca casos especiales de proveedores o plataformas en el núcleo para que esto funcione. El núcleo gestiona la semántica de las sesiones de Talk. Los plugins de proveedor gestionan la configuración de las sesiones del proveedor. Las llamadas de voz y Google Meet gestionan los adaptadores de telefonía/reuniones. Las aplicaciones web y nativas gestionan la experiencia de usuario de captura/reproducción del dispositivo.

Cronología de eliminación

Las subrutas públicas restantes del SDK que aparecen a continuación tienen periodos de eliminación respaldados por el registro. Las filas del 30 de julio se eliminaron tras su revisión anticipada autorizada por los mantenedores: se eliminaron las subrutas no utilizadas y los alias de compatibilidad anteriores, y los módulos exclusivos de los plugins incluidos se degradaron a asignaciones de compilación locales privadas. Todos los plugins del núcleo ya han migrado. Los plugins externos deben migrar antes de la próxima versión principal. Ejecute pnpm plugins:boundary-report para ver qué registros de compatibilidad tienen las fechas más próximas para las superficies que utiliza su plugin.

Supresión temporal de las advertencias

Esta es una vía de escape temporal, no una solución permanente.

Contenido relacionado