Skip to main content
OpenClaw перейшов від широкого шару зворотної сумісності до сучасної архітектури Plugin із цільовими, задокументованими імпортами. Якщо ваш Plugin було створено до нової архітектури, цей посібник допоможе вам мігрувати.

Що змінюється

Стара система 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.
Широкі поверхні імпорту тепер застарілі. Вони досі працюють під час виконання, але нові Plugin не повинні їх використовувати, а наявні Plugin мають мігрувати до того, як наступний major-реліз їх видалить. API реєстрації фабрики розширення лише для embedded-runner було видалено; натомість використовуйте middleware для результатів інструментів. OpenClaw не видаляє й не переінтерпретовує задокументовану поведінку Plugin у тій самій зміні, яка вводить заміну. Зміни контракту, що порушують сумісність, мають спершу пройти через адаптер сумісності, діагностику, документацію та вікно застарівання. Це стосується імпортів SDK, полів маніфесту, API налаштування, хуків і поведінки реєстрації під час виконання.
Шар зворотної сумісності буде видалено в майбутньому major-релізі. Plugin, які досі імпортують із цих поверхонь, після цього зламаються. Застарілі реєстрації фабрик вбудованих розширень уже більше не завантажуються.

Чому це змінилося

Старий підхід створював проблеми:
  • Повільний запуск - імпорт одного допоміжного засобу завантажував десятки непов’язаних модулів
  • Циклічні залежності - широкі повторні експорти спрощували створення циклів імпорту
  • Нечітка поверхня API - не було способу визначити, які експорти стабільні, а які внутрішні
Сучасний SDK Plugin це виправляє: кожен шлях імпорту (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 навмисно є чистою зі змінами, що порушують сумісність:
  1. Тримайте спільний контролер/runtime-примітиви в plugin-sdk/realtime-voice.
  2. Переведіть bundled поверхні на спільний контролер: browser relay, managed-room handoff, voice-call realtime, voice-call streaming STT, Google Meet realtime і native push-to-talk.
  3. Замініть старі сімейства RPC Talk на фінальний API talk.session.* і talk.client.*.
  4. Оголосіть один live-канал подій Talk у Gateway hello-ok.features.events: talk.event.
  5. Видаліть старий realtime HTTP endpoint і будь-який шлях перевизначення інструкцій під час запиту.
Новий код не повинен викликати createTalkEventSequencer(...) напряму, якщо тільки він не реалізує низькорівневий adapter або тестову fixture. Віддавайте перевагу спільному контролеру, щоб події в межах ходу не могли бути emitted без id ходу, застарілі виклики turnEnd / turnCancel не могли очистити новіший активний хід, а події життєвого циклу вихідного аудіо лишалися узгодженими в телефонії, зустрічах, browser relay, managed-room handoff і native клієнтах Talk. Цільова форма публічного API:
Сесії WebRTC/provider-websocket, якими володіє браузер, використовують 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 навмисно невеликі: Мапа видалених методів: Уніфікований контрольний словник також навмисно вузький: Не додавайте в core спеціальні випадки для провайдерів або платформ, щоб це працювало. Core володіє семантикою сеансів Talk. Plugin провайдерів володіють налаштуванням сеансів постачальників. Голосові виклики та Google Meet володіють адаптерами телефонії/зустрічей. Браузерні й нативні застосунки володіють UX захоплення/відтворення пристроїв.

Політика сумісності

Для зовнішніх Plugin робота із сумісністю відбувається в такому порядку:
  1. додати новий контракт
  2. зберегти стару поведінку, підключену через адаптер сумісності
  3. видати діагностику або попередження, що називає старий шлях і заміну
  4. покрити обидва шляхи тестами
  5. задокументувати застарівання та шлях міграції
  6. видаляти лише після оголошеного вікна міграції, зазвичай у 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-релізів.

Як мігрувати

1

Мігруйте helper для завантаження/запису runtime-конфігурації

Вбудовані Plugin мають припинити напряму викликати 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, що відповідає завданню:Вбудовані Plugin та їхні тести захищені scanner від широкого barrel, щоб імпорти й моки залишалися локальними до потрібної їм поведінки. Широкий barrel усе ще існує для зовнішньої сумісності, але новий код не повинен від нього залежати.
2

Мігруйте вбудовані розширення результатів інструментів до middleware

Вбудовані Plugin повинні замінити обробники результатів інструментів api.registerEmbeddedExtensionFactory(...), призначені лише для embedded-runner, на runtime-нейтральне middleware.
Одночасно оновіть маніфест Plugin:
Установлені Plugin також можуть реєструвати middleware результатів інструментів, коли вони явно ввімкнені й оголошують кожен цільовий runtime у contracts.agentToolResultMiddleware. Неоголошені реєстрації middleware встановлених Plugin відхиляються.
3

Мігруйте approval-native обробники до фактів capability

Channel Plugin із підтримкою approval тепер показують нативну поведінку approval через approvalCapability.nativeRuntime плюс спільний реєстр runtime-context.Ключові зміни:
  • Замініть approvalCapability.handler.loadRuntime(...) на approvalCapability.nativeRuntime
  • Перенесіть специфічні для approval auth/delivery зі старої прив’язки plugin.auth / plugin.approvals на approvalCapability
  • ChannelPlugin.approvals видалено з публічного контракту channel-plugin; перенесіть поля delivery/native/render на approvalCapability
  • plugin.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.
4

Перевірте fallback-поведінку Windows wrapper

Якщо ваш Plugin використовує openclaw/plugin-sdk/windows-spawn, нерозв’язані Windows .cmd/.bat wrappers тепер fail closed, якщо ви явно не передасте allowShellFallback: true.
Якщо ваш викликач не покладається навмисно на shell fallback, не встановлюйте allowShellFallback і натомість обробіть викинуту помилку.
5

Знайдіть застарілі імпорти

Знайдіть у своєму Plugin імпорти з будь-якої із застарілих поверхонь:
6

Замініть на сфокусовані імпорти

Кожен експорт зі старої поверхні відповідає конкретному сучасному шляху імпорту:
Для host-side helper використовуйте інжектований runtime Plugin замість прямого імпорту:
Той самий шаблон застосовується до інших застарілих допоміжних bridge-функцій:
7

Replace broad infra-runtime imports

openclaw/plugin-sdk/infra-runtime досі існує для зовнішньої сумісності, але новий код має імпортувати зосереджену допоміжну поверхню, яка йому фактично потрібна:Вбудовані плагіни захищені сканером від infra-runtime, тому код репозиторію не може повернутися до широкого barrel-імпорту.
8

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.
9

Build and test

Довідник шляхів імпорту

Ця таблиця навмисно є спільною підмножиною міграції, а не повною поверхнею SDK. Інвентар точок входу компілятора міститься в 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 з його канонічною заміною.
Старе (openclaw/plugin-sdk/command-auth): buildCommandsMessage, buildCommandsMessagePaginated, buildHelpMessage.Нове (openclaw/plugin-sdk/command-status): ті самі сигнатури, ті самі експорти - просто імпортовані з вужчого підшляху. command-auth реекспортує їх як заглушки сумісності.
Старе: resolveInboundMentionRequirement({ facts, policy }) і shouldDropInboundForMention(...) з openclaw/plugin-sdk/channel-inbound або openclaw/plugin-sdk/channel-mention-gating.Нове: resolveInboundMentionDecision({ facts, policy }) - повертає один об’єкт рішення замість двох окремих викликів.Нижчі за потоком channel-плагіни (Slack, Discord, Matrix, MS Teams) уже перейшли на нього.
openclaw/plugin-sdk/channel-runtime є прокладкою сумісності для старіших channel-плагінів. Не імпортуйте її з нового коду; використовуйте openclaw/plugin-sdk/channel-runtime-context для реєстрації runtime- об’єктів.Допоміжні засоби channelActions* в openclaw/plugin-sdk/channel-actions застаріли разом із сирими channel-експортами “actions”. Натомість виставляйте можливості через семантичну поверхню presentation - channel- плагіни оголошують, що вони рендерять (картки, кнопки, списки вибору), а не які сирі назви дій вони приймають.
Старе: фабрика tool() з openclaw/plugin-sdk/provider-web-search.Нове: реалізуйте createTool(...) безпосередньо в provider-плагіні. OpenClaw більше не потребує допоміжного засобу SDK для реєстрації обгортки інструмента.
Старе: formatInboundEnvelope(...)ChannelMessageForAgent.channelEnvelope) для побудови плаского plaintext- конверта prompt з вхідних повідомлень каналу.Нове: BodyForAgent плюс структуровані блоки контексту користувача. Channel-плагіни прикріплюють метадані маршрутизації (тред, тема, відповідь на, реакції) як типізовані поля замість конкатенації їх у рядок prompt. Допоміжний засіб formatAgentEnvelope(...) досі підтримується для синтезованих конвертів, спрямованих до асистента, але вхідні plaintext- конверти поступово вилучаються.Зачеплені області: inbound_claim, message_received і будь-який кастомний channel-плагін, який постобробляв текст channelEnvelope.
Старе: api.on("deactivate", handler).Нове: api.on("gateway_stop", handler). Подія та контекст є тим самим контрактом очищення під час завершення роботи; змінюється лише назва хука.
deactivate залишається підключеним як застарілий псевдонім сумісності до часу після 2026-08-16.
Старе: 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, а не статичний об’єкт.
Старе (три окремі хуки в ProviderThinkingPolicy): isBinaryThinking(ctx), supportsXHighThinking(ctx) і resolveDefaultThinkingLevel(ctx).Нове: один resolveThinkingProfile(ctx), що повертає ProviderThinkingProfile з канонічним id, необов’язковим label і ранжованим списком рівнів. OpenClaw автоматично понижує застарілі збережені значення за рангом профілю.Контекст містить provider, modelId, необов’язково об’єднаний reasoning і необов’язково об’єднані факти compat моделі. Provider- плагіни можуть використовувати ці факти каталогу, щоб виставляти профіль, специфічний для моделі, лише коли налаштований контракт запиту це підтримує.Реалізуйте один хук замість трьох. Застарілі хуки продовжують працювати протягом вікна застаріння, але не компонуються з результатом профілю.
Старе: реалізація зовнішніх auth-хуків без оголошення провайдера в маніфесті плагіна.Нове: оголосіть contracts.externalAuthProviders у маніфесті плагіна і реалізуйте resolveExternalAuthProfiles(...).
Старе поле маніфесту: providerAuthEnvVars: { anthropic: ["ANTHROPIC_API_KEY"] }.Нове: віддзеркальте той самий пошук env-var у setup.providers[].envVars у маніфесті. Це консолідує метадані env для setup/status в одному місці та уникає запуску runtime плагіна лише для відповіді на пошуки env-var.providerAuthEnvVars залишається підтримуваним через адаптер сумісності, доки вікно застаріння не закриється.
Старе: три окремі виклики - api.registerMemoryPromptSection(...), api.registerMemoryFlushPlan(...), api.registerMemoryRuntime(...).Нове: один виклик в API memory-state - registerMemoryCapability(pluginId, { promptBuilder, flushPlanResolver, runtime }).Ті самі слоти, один виклик реєстрації. Адитивні допоміжні засоби prompt і корпусу (registerMemoryPromptSupplement, registerMemoryCorpusSupplement) не зачеплені.
Старе: api.registerMemoryEmbeddingProvider(...) плюс contracts.memoryEmbeddingProviders.Нове: api.registerEmbeddingProvider(...) плюс contracts.embeddingProviders.Загальний контракт embedding-провайдера придатний для повторного використання поза memory і є підтримуваним шляхом для нових провайдерів. API реєстрації, специфічний для memory, залишається підключеним як застаріла сумісність, доки наявні провайдери мігрують. Інспекція плагінів повідомляє про використання не-bundled плагінами як борг сумісності.
Два застарілі псевдоніми типів досі експортуються з src/plugins/runtime/types.ts:Runtime-метод readSession застарів на користь getSessionMessages. Та сама сигнатура; старий метод викликає новий.
Старе: runtime.tasks.flow (однина) повертав live-аксесор task-flow.Нове: runtime.tasks.managedFlows зберігає runtime мутацій керованого TaskFlow для плагінів, які створюють, оновлюють, скасовують або запускають дочірні задачі з flow. Використовуйте runtime.tasks.flows, коли плагіну потрібні лише читання на основі DTO.
Описано вище в “Як мігрувати → Мігруйте вбудовані розширення результатів інструментів на middleware”. Додано тут для повноти: вилучений шлях лише для embedded-runner api.registerEmbeddedExtensionFactory(...) замінено на api.registerAgentToolResultMiddleware(...) з явним списком runtime у contracts.agentToolResultMiddleware.
OpenClawSchemaType, реекспортований з openclaw/plugin-sdk, тепер є однорядковим псевдонімом для OpenClawConfig. Надавайте перевагу канонічній назві.
Застаріння рівня розширень (усередині bundled channel/provider-плагінів у extensions/) відстежуються всередині їхніх власних barrel-файлів api.ts і runtime-api.ts. Вони не впливають на контракти сторонніх плагінів і тут не перелічені. Якщо ви споживаєте локальний barrel bundled-плагіна напряму, прочитайте коментарі про застаріння в цьому barrel перед оновленням.

Графік вилучення

Усі основні Plugin-и вже мігровано. Зовнішні Plugin-и мають мігрувати до наступного мажорного релізу.

Тимчасове приглушення попереджень

Установіть ці змінні середовища під час роботи над міграцією:
Це тимчасовий запасний вихід, а не постійне рішення.

Пов’язане