Що змінюється
Стара система Plugin надавала дві широко відкриті поверхні, які давали змогу Plugin імпортувати все потрібне з однієї точки входу:openclaw/plugin-sdk/compat- один імпорт, який повторно експортував десятки допоміжних засобів. Його було запроваджено, щоб старіші Plugin на основі хуків працювали, поки будувалася нова архітектура Plugin.openclaw/plugin-sdk/infra-runtime- широкий barrel runtime-допоміжних засобів, який змішував системні події, стан Heartbeat, черги доставлення, допоміжні засоби fetch/proxy, допоміжні засоби для файлів, типи схвалення та непов’язані утиліти.openclaw/plugin-sdk/config-runtime- широкий barrel сумісності конфігурації, який досі містить застарілі прямі допоміжні засоби завантаження/запису протягом вікна міграції.openclaw/extension-api- міст, який давав Plugin прямий доступ до допоміжних засобів на боці хоста, як-от вбудований runner агента.api.registerEmbeddedExtensionFactory(...)- видалений хук bundled розширення лише для embedded-runner, який міг спостерігати події embedded-runner, такі якtool_result.
Чому це змінилося
Старий підхід створював проблеми:- Повільний запуск - імпорт одного допоміжного засобу завантажував десятки непов’язаних модулів
- Циклічні залежності - широкі повторні експорти спрощували створення циклів імпорту
- Нечітка поверхня API - не було способу визначити, які експорти стабільні, а які внутрішні
openclaw/plugin-sdk/\<subpath\>)
є малим, самодостатнім модулем із чітким призначенням і задокументованим контрактом.
Застарілі зручні шви provider для bundled каналів також видалено.
Допоміжні шви з брендингом каналу були приватними скороченнями mono-repo, а не стабільними
контрактами Plugin. Натомість використовуйте вузькі generic підшляхи SDK. Усередині bundled
робочого простору Plugin тримайте допоміжні засоби, що належать provider, у власному api.ts або
runtime-api.ts цього Plugin.
Поточні bundled приклади provider:
- Anthropic тримає допоміжні засоби потоків, специфічні для Claude, у власному шві
api.ts/contract-api.ts - OpenAI тримає builders provider, допоміжні засоби default-model і builders realtime provider
у власному
api.ts - OpenRouter тримає builder provider і допоміжні засоби onboarding/config у власному
api.ts
План міграції Talk і голосу реального часу
Код Talk для голосу реального часу, телефонії, зустрічей і браузера переходить від локального для поверхні обліку ходів до спільного контролера сесії Talk, який експортуєopenclaw/plugin-sdk/realtime-voice. Новий контролер володіє спільним
envelope подій Talk, станом активного ходу, станом захоплення, станом вихідного аудіо, нещодавньою
історією подій і відхиленням застарілих ходів. Plugin provider мають і далі володіти
realtime-сесіями, специфічними для постачальника; Plugin поверхонь мають і далі володіти нюансами
захоплення, відтворення, телефонії та зустрічей.
Ця міграція Talk навмисно є чистою зі змінами, що порушують сумісність:
- Тримайте спільний контролер/runtime-примітиви в
plugin-sdk/realtime-voice. - Переведіть bundled поверхні на спільний контролер: browser relay, managed-room handoff, voice-call realtime, voice-call streaming STT, Google Meet realtime і native push-to-talk.
- Замініть старі сімейства RPC Talk на фінальний API
talk.session.*іtalk.client.*. - Оголосіть один live-канал подій Talk у Gateway
hello-ok.features.events:talk.event. - Видаліть старий realtime HTTP endpoint і будь-який шлях перевизначення інструкцій під час запиту.
createTalkEventSequencer(...) напряму, якщо тільки він не
реалізує низькорівневий adapter або тестову fixture. Віддавайте перевагу спільному контролеру,
щоб події в межах ходу не могли бути emitted без id ходу, застарілі виклики turnEnd /
turnCancel не могли очистити новіший активний хід, а події життєвого циклу вихідного аудіо
лишалися узгодженими в телефонії, зустрічах, browser relay, managed-room
handoff і native клієнтах Talk.
Цільова форма публічного API:
talk.client.create,
бо браузер володіє узгодженням provider і медіатранспортом, тоді як
Gateway володіє credentials, інструкціями та політикою інструментів. talk.session.* є
спільною керованою Gateway поверхнею для gateway-relay realtime, gateway-relay
transcription і managed-room native STT/TTS сесій.
Застарілі конфігурації, які розміщували realtime selectors поруч із talk.provider /
talk.providers, слід виправити за допомогою openclaw doctor --fix; runtime Talk
не переінтерпретовує конфігурацію speech/TTS provider як конфігурацію realtime provider.
Підтримувані комбінації talk.session.create навмисно невеликі:
Політика сумісності
Для зовнішніх Plugin робота із сумісністю відбувається в такому порядку:- додати новий контракт
- зберегти стару поведінку, підключену через адаптер сумісності
- видати діагностику або попередження, що називає старий шлях і заміну
- покрити обидва шляхи тестами
- задокументувати застарівання та шлях міграції
- видаляти лише після оголошеного вікна міграції, зазвичай у major-релізі
pnpm plugins:boundary-report. Використовуйте pnpm plugins:boundary-report:summary для
компактних підрахунків, --owner <id> для одного Plugin або власника сумісності, і
pnpm plugins:boundary-report:ci, коли CI-гейт має падати через прострочені
записи сумісності, міжвласницькі зарезервовані імпорти SDK або невикористані зарезервовані
підшляхи SDK. Звіт групує застарілі
записи сумісності за датою видалення, рахує локальні посилання в коді/документації,
показує міжвласницькі зарезервовані імпорти SDK і підсумовує приватний
міст SDK memory-host, щоб очищення сумісності залишалося явним, а не
покладалося на ситуативні пошуки. Зарезервовані підшляхи SDK повинні мати відстежене використання власником;
невикористані зарезервовані експорти helper слід видалити з публічного SDK.
Якщо поле маніфесту все ще приймається, автори Plugin можуть продовжувати його використовувати, доки
документація й діагностика не скажуть інакше. Новий код має віддавати перевагу задокументованій
заміні, але наявні Plugin не повинні ламатися під час звичайних minor-релізів.
Як мігрувати
Мігруйте helper для завантаження/запису runtime-конфігурації
api.runtime.config.loadConfig() і
api.runtime.config.writeConfigFile(...). Віддавайте перевагу конфігурації, яку
вже передано в активний шлях виклику. Довготривалі обробники, яким потрібен
поточний знімок процесу, можуть використовувати api.runtime.config.current(). Довготривалі
інструменти агента мають використовувати ctx.getRuntimeConfig() з контексту інструмента всередині
execute, щоб інструмент, створений до запису конфігурації, все одно бачив оновлену
runtime-конфігурацію.Записи конфігурації повинні проходити через транзакційні helper і вибирати
політику після запису:afterWrite: { mode: "restart", reason: "..." }, коли викликач знає,
що зміна потребує чистого перезапуску Gateway, і
afterWrite: { mode: "none", reason: "..." } лише тоді, коли викликач володіє
подальшою дією й навмисно хоче придушити планувальник перезавантаження.
Результати мутації містять типізований підсумок followUp для тестів і логування;
Gateway залишається відповідальним за застосування або планування перезапуску.
loadConfig і writeConfigFile залишаються застарілими helper сумісності
для зовнішніх Plugin протягом вікна міграції й один раз попереджають із
кодом сумісності runtime-config-load-write. Вбудовані Plugin і runtime-код репозиторію
захищені scanner-обмеженнями в
pnpm check:deprecated-api-usage і
pnpm check:no-runtime-action-load-config: нове production-використання Plugin
одразу падає, прямі записи конфігурації падають, методи сервера Gateway повинні використовувати
runtime-знімок запиту, runtime-helper надсилання/action/client каналів
повинні отримувати конфігурацію зі своєї межі, а довготривалі runtime-модулі мають
нуль дозволених ambient-викликів loadConfig().Новий код Plugin також має уникати імпорту широкого
compatibility-barrel openclaw/plugin-sdk/config-runtime. Використовуйте вузький
підшлях SDK, що відповідає завданню:Мігруйте вбудовані розширення результатів інструментів до middleware
api.registerEmbeddedExtensionFactory(...), призначені лише для embedded-runner,
на runtime-нейтральне middleware.contracts.agentToolResultMiddleware. Неоголошені реєстрації middleware встановлених Plugin
відхиляються.Мігруйте approval-native обробники до фактів capability
approvalCapability.nativeRuntime плюс спільний реєстр runtime-context.Ключові зміни:- Замініть
approvalCapability.handler.loadRuntime(...)наapprovalCapability.nativeRuntime - Перенесіть специфічні для approval auth/delivery зі старої прив’язки
plugin.auth/plugin.approvalsнаapprovalCapability ChannelPlugin.approvalsвидалено з публічного контракту channel-plugin; перенесіть поля delivery/native/render наapprovalCapabilityplugin.authзалишається лише для потоків входу/виходу каналу; approval auth hooks там більше не читаються core- Реєструйте runtime-об’єкти, що належать каналу, як-от клієнти, токени або Bolt
apps, через
openclaw/plugin-sdk/channel-runtime-context - Не надсилайте повідомлення про reroute, що належать Plugin, із native approval handlers; core тепер володіє повідомленнями routed-elsewhere на основі фактичних результатів доставки
- Передаючи
channelRuntimeуcreateChannelManager(...), надайте справжню поверхнюcreatePluginRuntime().channel. Часткові stubs відхиляються.
/plugins/sdk-channel-plugins для поточної структури approval capability.Перевірте fallback-поведінку Windows wrapper
openclaw/plugin-sdk/windows-spawn, нерозв’язані Windows
.cmd/.bat wrappers тепер fail closed, якщо ви явно не передасте
allowShellFallback: true.allowShellFallback і натомість обробіть викинуту помилку.Знайдіть застарілі імпорти
Замініть на сфокусовані імпорти
Replace broad infra-runtime imports
openclaw/plugin-sdk/infra-runtime досі існує для зовнішньої
сумісності, але новий код має імпортувати зосереджену допоміжну поверхню, яка
йому фактично потрібна:infra-runtime, тому код репозиторію
не може повернутися до широкого barrel-імпорту.Migrate channel route helpers
openclaw/plugin-sdk/channel-route.
Старі назви route-key і comparable-target залишаються як псевдоніми
сумісності протягом вікна міграції, але нові плагіни мають використовувати назви
маршрутів, які безпосередньо описують поведінку:{ channel, to, accountId, threadId }
для нативних схвалень, приглушення відповідей, вхідної дедуплікації,
доставки Cron і маршрутизації сесій.Не додавайте нові використання ChannelMessagingAdapter.parseExplicitTarget або
parser-backed допоміжних функцій завантажених маршрутів (parseExplicitTargetForLoadedChannel
чи resolveRouteTargetForLoadedChannel) або
resolveChannelRouteTargetWithParser(...) з plugin-sdk/channel-route.
Ці hooks застаріли й залишаються лише для старіших плагінів протягом
вікна міграції. Нові канальні плагіни мають використовувати
messaging.targetResolver.resolveTarget(...) для нормалізації target id
і fallback у разі directory-miss, messaging.inferTargetChatType(...), коли core
потребує раннього типу peer, і messaging.resolveOutboundSessionRoute(...)
для provider-native сесії та ідентичності thread.Build and test
Довідник шляхів імпорту
Таблиця поширених шляхів імпорту
Таблиця поширених шляхів імпорту
scripts/lib/plugin-sdk-entrypoints.json; експорти пакета генеруються з
публічної підмножини.
Зарезервовані допоміжні шви bundled-плагінів вилучено з мапи експортів
публічного SDK, за винятком явно задокументованих фасадів сумісності, як-от
застарілої прокладки plugin-sdk/discord, збереженої для опублікованого
пакета @openclaw/discord@2026.3.13. Допоміжні засоби, специфічні для
власника, містяться всередині пакета плагіна-власника; спільна поведінка хоста
має проходити через загальні контракти SDK, такі як
plugin-sdk/gateway-runtime, plugin-sdk/security-runtime і
plugin-sdk/plugin-config-runtime.
Використовуйте найвужчий імпорт, який відповідає завданню. Якщо не можете
знайти експорт, перевірте джерело в src/plugin-sdk/ або запитайте
супровідників, який загальний контракт має ним володіти.
Активні застаріння
Вужчі застаріння, що застосовуються в усьому SDK плагінів, контракті провайдера, runtime-поверхні та маніфесті. Кожне з них досі працює сьогодні, але буде вилучене в майбутньому мажорному випуску. Запис під кожним елементом зіставляє старий API з його канонічною заміною.Допоміжні побудовники command-auth → command-status
Допоміжні побудовники command-auth → command-status
openclaw/plugin-sdk/command-auth): buildCommandsMessage,
buildCommandsMessagePaginated, buildHelpMessage.Нове (openclaw/plugin-sdk/command-status): ті самі сигнатури, ті самі
експорти - просто імпортовані з вужчого підшляху. command-auth
реекспортує їх як заглушки сумісності.Допоміжні засоби обмеження згадок → resolveInboundMentionDecision
Допоміжні засоби обмеження згадок → resolveInboundMentionDecision
resolveInboundMentionRequirement({ facts, policy }) і
shouldDropInboundForMention(...) з
openclaw/plugin-sdk/channel-inbound або
openclaw/plugin-sdk/channel-mention-gating.Нове: resolveInboundMentionDecision({ facts, policy }) - повертає
один об’єкт рішення замість двох окремих викликів.Нижчі за потоком channel-плагіни (Slack, Discord, Matrix, MS Teams) уже
перейшли на нього.Прокладка runtime каналу та допоміжні засоби дій каналу
Прокладка runtime каналу та допоміжні засоби дій каналу
openclaw/plugin-sdk/channel-runtime є прокладкою сумісності для старіших
channel-плагінів. Не імпортуйте її з нового коду; використовуйте
openclaw/plugin-sdk/channel-runtime-context для реєстрації runtime-
об’єктів.Допоміжні засоби channelActions* в openclaw/plugin-sdk/channel-actions
застаріли разом із сирими channel-експортами “actions”. Натомість
виставляйте можливості через семантичну поверхню presentation - channel-
плагіни оголошують, що вони рендерять (картки, кнопки, списки вибору), а
не які сирі назви дій вони приймають.Допоміжний tool() провайдера вебпошуку → createTool() у плагіні
Допоміжний tool() провайдера вебпошуку → createTool() у плагіні
tool() з openclaw/plugin-sdk/provider-web-search.Нове: реалізуйте createTool(...) безпосередньо в provider-плагіні.
OpenClaw більше не потребує допоміжного засобу SDK для реєстрації обгортки
інструмента.Plaintext-конверти каналу → BodyForAgent
Plaintext-конверти каналу → BodyForAgent
formatInboundEnvelope(...) (і
ChannelMessageForAgent.channelEnvelope) для побудови плаского plaintext-
конверта prompt з вхідних повідомлень каналу.Нове: BodyForAgent плюс структуровані блоки контексту користувача.
Channel-плагіни прикріплюють метадані маршрутизації (тред, тема,
відповідь на, реакції) як типізовані поля замість конкатенації їх у рядок
prompt. Допоміжний засіб formatAgentEnvelope(...) досі підтримується для
синтезованих конвертів, спрямованих до асистента, але вхідні plaintext-
конверти поступово вилучаються.Зачеплені області: inbound_claim, message_received і будь-який
кастомний channel-плагін, який постобробляв текст channelEnvelope.Хук deactivate → gateway_stop
Хук deactivate → gateway_stop
api.on("deactivate", handler).Нове: api.on("gateway_stop", handler). Подія та контекст є тим самим
контрактом очищення під час завершення роботи; змінюється лише назва хука.deactivate залишається підключеним як застарілий псевдонім сумісності до
часу після 2026-08-16.Хук subagent_spawning → прив'язка треду в core
Хук subagent_spawning → прив'язка треду в core
api.on("subagent_spawning", handler), що повертає
threadBindingReady або deliveryOrigin.Нове: дозвольте core підготувати прив’язки субагента thread: true
через адаптер прив’язки сесії каналу. Використовуйте
api.on("subagent_spawned", handler) лише для спостереження після запуску.subagent_spawning, PluginHookSubagentSpawningEvent,
PluginHookSubagentSpawningResult і
SubagentLifecycleHookRunner.runSubagentSpawning(...) залишаються лише як
застарілі поверхні сумісності, доки зовнішні плагіни мігрують.Типи виявлення провайдера → типи каталогу провайдера
Типи виявлення провайдера → типи каталогу провайдера
ProviderCapabilities - provider-плагіни
мають використовувати явні хуки провайдера, такі як buildReplayPolicy,
normalizeToolSchemas і wrapStreamFn, а не статичний об’єкт.Хуки політики мислення → resolveThinkingProfile
Хуки політики мислення → resolveThinkingProfile
ProviderThinkingPolicy):
isBinaryThinking(ctx), supportsXHighThinking(ctx) і
resolveDefaultThinkingLevel(ctx).Нове: один resolveThinkingProfile(ctx), що повертає
ProviderThinkingProfile з канонічним id, необов’язковим label і
ранжованим списком рівнів. OpenClaw автоматично понижує застарілі
збережені значення за рангом профілю.Контекст містить provider, modelId, необов’язково об’єднаний
reasoning і необов’язково об’єднані факти compat моделі. Provider-
плагіни можуть використовувати ці факти каталогу, щоб виставляти профіль,
специфічний для моделі, лише коли налаштований контракт запиту це
підтримує.Реалізуйте один хук замість трьох. Застарілі хуки продовжують працювати
протягом вікна застаріння, але не компонуються з результатом профілю.Зовнішні auth-провайдери → contracts.externalAuthProviders
Зовнішні auth-провайдери → contracts.externalAuthProviders
contracts.externalAuthProviders у маніфесті плагіна
і реалізуйте resolveExternalAuthProfiles(...).Пошук env-var провайдера → setup.providers[].envVars
Пошук env-var провайдера → setup.providers[].envVars
providerAuthEnvVars: { anthropic: ["ANTHROPIC_API_KEY"] }.Нове: віддзеркальте той самий пошук env-var у
setup.providers[].envVars у маніфесті. Це консолідує метадані env для
setup/status в одному місці та уникає запуску runtime плагіна лише для
відповіді на пошуки env-var.providerAuthEnvVars залишається підтримуваним через адаптер сумісності,
доки вікно застаріння не закриється.Реєстрація memory-плагіна → registerMemoryCapability
Реєстрація memory-плагіна → registerMemoryCapability
api.registerMemoryPromptSection(...),
api.registerMemoryFlushPlan(...),
api.registerMemoryRuntime(...).Нове: один виклик в API memory-state -
registerMemoryCapability(pluginId, { promptBuilder, flushPlanResolver, runtime }).Ті самі слоти, один виклик реєстрації. Адитивні допоміжні засоби prompt і
корпусу (registerMemoryPromptSupplement, registerMemoryCorpusSupplement)
не зачеплені.API провайдера embedding для memory
API провайдера embedding для memory
api.registerMemoryEmbeddingProvider(...) плюс
contracts.memoryEmbeddingProviders.Нове: api.registerEmbeddingProvider(...) плюс
contracts.embeddingProviders.Загальний контракт embedding-провайдера придатний для повторного
використання поза memory і є підтримуваним шляхом для нових провайдерів.
API реєстрації, специфічний для memory, залишається підключеним як
застаріла сумісність, доки наявні провайдери мігрують. Інспекція плагінів
повідомляє про використання не-bundled плагінами як борг сумісності.Типи повідомлень сесії субагента перейменовано
Типи повідомлень сесії субагента перейменовано
src/plugins/runtime/types.ts:readSession застарів на користь getSessionMessages. Та
сама сигнатура; старий метод викликає новий.runtime.tasks.flow → runtime.tasks.managedFlows
runtime.tasks.flow → runtime.tasks.managedFlows
runtime.tasks.flow (однина) повертав live-аксесор task-flow.Нове: runtime.tasks.managedFlows зберігає runtime мутацій керованого
TaskFlow для плагінів, які створюють, оновлюють, скасовують або запускають
дочірні задачі з flow. Використовуйте runtime.tasks.flows, коли плагіну
потрібні лише читання на основі DTO.Вбудовані фабрики розширень → middleware результатів інструментів агента
Вбудовані фабрики розширень → middleware результатів інструментів агента
api.registerEmbeddedExtensionFactory(...) замінено на
api.registerAgentToolResultMiddleware(...) з явним списком runtime у
contracts.agentToolResultMiddleware.Псевдонім OpenClawSchemaType → OpenClawConfig
Псевдонім OpenClawSchemaType → OpenClawConfig
OpenClawSchemaType, реекспортований з openclaw/plugin-sdk, тепер є
однорядковим псевдонімом для OpenClawConfig. Надавайте перевагу
канонічній назві.extensions/) відстежуються всередині їхніх власних barrel-файлів api.ts і
runtime-api.ts. Вони не впливають на контракти сторонніх плагінів і тут не
перелічені. Якщо ви споживаєте локальний barrel bundled-плагіна напряму,
прочитайте коментарі про застаріння в цьому barrel перед оновленням.Графік вилучення
Тимчасове приглушення попереджень
Установіть ці змінні середовища під час роботи над міграцією:Пов’язане
- Початок роботи - створіть свій перший Plugin
- Огляд SDK - повний довідник імпортів підшляхів
- Plugin-и каналів - створення Plugin-ів каналів
- Plugin-и провайдерів - створення Plugin-ів провайдерів
- Внутрішня архітектура Plugin-ів - поглиблений огляд архітектури
- Маніфест Plugin - довідник схеми маніфесту