openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh uk translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-29 02:59:30 +00:00
parent 35567979f4
commit 10e2ea286a
2 changed files with 694 additions and 631 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

937
docs/uk/plugins/architecture-internals.md
View File

File diff suppressed because it is too large Load Diff

388
docs/uk/plugins/architecture.md
View File

@ -1,26 +1,26 @@
---
read_when:
- Збирання або налагодження нативних плагінів OpenClaw
- Розуміння моделі можливостей Plugin або меж володіння
- Розуміння моделі можливостей Plugin або меж відповідальності
- Робота над конвеєром завантаження Plugin або реєстром
- Реалізація хуків середовища виконання провайдера або Plugin для каналів
- Реалізація хуків середовища виконання провайдера або плагінів каналів
sidebarTitle: Internals
summary: 'Внутрішня архітектура Plugin: модель можливостей, право власності, контракти, конвеєр завантаження та допоміжні засоби середовища виконання'
title: Внутрішні механізми Plugin
summary: 'Внутрішні механізми Plugin: модель можливостей, володіння, контракти, конвеєр завантаження та допоміжні засоби середовища виконання'
title: Внутрішня реалізація Plugin
x-i18n:
generated_at: "2026-04-28T11:18:49Z"
generated_at: "2026-04-29T02:56:30Z"
model: gpt-5.5
provider: openai
source_hash: 6afc634508c1d623fa1caceb6b463917f5a8adbaabf42b5381974bd86d117f5d
source_hash: 1516e0784a005af87a6c081d8027a1e2dc10445e47b6824488e9d9987bb96975
source_path: plugins/architecture.md
workflow: 16
---
Це **поглиблений архітектурний довідник** для системи plugins OpenClaw. Для практичних посібників почніть з однієї зі спеціалізованих сторінок нижче.
Це **поглиблений архітектурний довідник** для системи plugins OpenClaw. Для практичних посібників почніть з однієї з наведених нижче тематичних сторінок.
<CardGroup cols={2}>
<Card title="Установлення та використання plugins" icon="plug" href="/uk/tools/plugin">
Посібник для кінцевих користувачів щодо додавання, увімкнення й усунення несправностей plugins.
<Card title="Встановлення та використання plugins" icon="plug" href="/uk/tools/plugin">
Посібник для кінцевих користувачів із додавання, увімкнення та усунення несправностей plugins.
</Card>
<Card title="Створення plugins" icon="rocket" href="/uk/plugins/building-plugins">
Посібник зі створення першого plugin з найменшим робочим маніфестом.
@ -32,45 +32,45 @@ x-i18n:
Створіть plugin постачальника моделей.
</Card>
<Card title="Огляд SDK" icon="book" href="/uk/plugins/sdk-overview">
Довідник щодо карти імпортів і API реєстрації.
Довідник з карти імпортів і API реєстрації.
</Card>
</CardGroup>
## Публічна модель можливостей
Можливості є публічною моделлю **нативних plugin** в OpenClaw. Кожен нативний plugin OpenClaw реєструється для одного або кількох типів можливостей:
Можливості є публічною моделлю **нативного plugin** всередині OpenClaw. Кожен нативний plugin OpenClaw реєструється для одного або кількох типів можливостей:
| Можливість | Метод реєстрації | Приклади plugins |
| Можливість | Метод реєстрації | Приклади plugins |
| ---------------------- | ------------------------------------------------ | ------------------------------------ |
| Текстове виведення | `api.registerProvider(...)` | `openai`, `anthropic` |
| Бекенд CLI-виведення | `api.registerCliBackend(...)` | `openai`, `anthropic` |
| Мовлення | `api.registerSpeechProvider(...)` | `elevenlabs`, `microsoft` |
| Текстовий inference | `api.registerProvider(...)` | `openai`, `anthropic` |
| Backend inference CLI | `api.registerCliBackend(...)` | `openai`, `anthropic` |
| Мовлення | `api.registerSpeechProvider(...)` | `elevenlabs`, `microsoft` |
| Транскрипція в реальному часі | `api.registerRealtimeTranscriptionProvider(...)` | `openai` |
| Голос у реальному часі | `api.registerRealtimeVoiceProvider(...)` | `openai` |
| Розуміння медіа | `api.registerMediaUnderstandingProvider(...)` | `openai`, `google` |
| Генерація зображень | `api.registerImageGenerationProvider(...)` | `openai`, `google`, `fal`, `minimax` |
| Голос у реальному часі | `api.registerRealtimeVoiceProvider(...)` | `openai` |
| Розуміння медіа | `api.registerMediaUnderstandingProvider(...)` | `openai`, `google` |
| Генерація зображень | `api.registerImageGenerationProvider(...)` | `openai`, `google`, `fal`, `minimax` |
| Генерація музики | `api.registerMusicGenerationProvider(...)` | `google`, `minimax` |
| Генерація відео | `api.registerVideoGenerationProvider(...)` | `qwen` |
| Отримання вебвмісту | `api.registerWebFetchProvider(...)` | `firecrawl` |
| Вебпошук | `api.registerWebSearchProvider(...)` | `google` |
| Канал / обмін повідомленнями | `api.registerChannel(...)` | `msteams`, `matrix` |
| Генерація відео | `api.registerVideoGenerationProvider(...)` | `qwen` |
| Веб-отримання | `api.registerWebFetchProvider(...)` | `firecrawl` |
| Веб-пошук | `api.registerWebSearchProvider(...)` | `google` |
| Канал / повідомлення | `api.registerChannel(...)` | `msteams`, `matrix` |
| Виявлення Gateway | `api.registerGatewayDiscoveryService(...)` | `bonjour` |
<Note>
Plugin, який реєструє нуль можливостей, але надає hooks, tools, служби виявлення або фонові служби, є **застарілим plugin лише з hooks**. Цей шаблон досі повністю підтримується.
Plugin, який реєструє нуль можливостей, але надає hooks, tools, служби виявлення або фонові служби, є **застарілим plugin лише з hooks**. Цей шаблон і досі повністю підтримується.
</Note>
### Позиція щодо зовнішньої сумісності
Модель можливостей уже додано в core і сьогодні використовується в вбудованих/нативних plugins, але сумісність зовнішніх plugins усе ще потребує суворішої планки, ніж «це експортовано, отже це зафіксовано».
Модель можливостей уже є в core і сьогодні використовується bundled/native plugins, але сумісність зовнішніх plugins все ще потребує суворішого критерію, ніж "це експортовано, отже це заморожено."
| Ситуація з plugin | Рекомендації |
| Ситуація з plugin | Настанова |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| Наявні зовнішні plugins | Підтримуйте працездатність інтеграцій на основі hooks; це базова лінія сумісності. |
| Нові вбудовані/нативні plugins | Надавайте перевагу явній реєстрації можливостей замість vendor-specific reach-ins або нових дизайнів лише на hooks. |
| Зовнішні plugins, що впроваджують реєстрацію можливостей | Дозволено, але вважайте допоміжні поверхні, специфічні для можливостей, такими, що еволюціонують, якщо документація не позначає їх стабільними. |
| Наявні зовнішні plugins | Підтримуйте роботу інтеграцій на основі hooks; це базовий рівень сумісності. |
| Нові bundled/native plugins | Надавайте перевагу явній реєстрації можливостей замість vendor-specific reach-ins або нових дизайнів лише з hooks. |
| Зовнішні plugins, що впроваджують реєстрацію можливостей | Дозволено, але вважайте допоміжні поверхні для конкретних можливостей такими, що розвиваються, якщо docs не позначають їх стабільними. |
Реєстрація можливостей є цільовим напрямком. Застарілі hooks залишаються найбезпечнішим шляхом без поломок для зовнішніх plugins під час переходу. Експортовані допоміжні підшляхи не всі рівноцінні — надавайте перевагу вузьким задокументованим контрактам над випадковими допоміжними експортами.
Реєстрація можливостей є запланованим напрямом. Застарілі hooks залишаються найбезпечнішим шляхом без поломок для зовнішніх plugins під час переходу. Експортовані допоміжні subpaths не є однаковими — надавайте перевагу вузьким документованим контрактам, а не випадковим допоміжним експортам.
### Форми plugin
@ -78,43 +78,43 @@ OpenClaw класифікує кожен завантажений plugin за ф
<AccordionGroup>
<Accordion title="plain-capability">
Реєструє рівно один тип можливості (наприклад, plugin лише постачальника, як-от `mistral`).
Реєструє рівно один тип можливості (наприклад, plugin лише постачальника, як `mistral`).
</Accordion>
<Accordion title="hybrid-capability">
Реєструє кілька типів можливостей (наприклад, `openai` володіє текстовим виведенням, мовленням, розумінням медіа та генерацією зображень).
Реєструє кілька типів можливостей (наприклад, `openai` володіє текстовим inference, мовленням, розумінням медіа та генерацією зображень).
</Accordion>
<Accordion title="hook-only">
Реєструє лише hooks (типізовані або користувацькі), без можливостей, tools, команд або служб.
Реєструє лише hooks (типізовані або користувацькі), без можливостей, tools, commands або services.
</Accordion>
<Accordion title="non-capability">
Реєструє tools, команди, служби або маршрути, але без можливостей.
Реєструє tools, commands, services або routes, але без можливостей.
</Accordion>
</AccordionGroup>
Використовуйте `openclaw plugins inspect <id>`, щоб побачити форму plugin та розбивку його можливостей. Докладніше див. [довідник CLI](/uk/cli/plugins#inspect).
Використовуйте `openclaw plugins inspect <id>`, щоб переглянути форму plugin і розбивку його можливостей. Докладніше див. у [довіднику CLI](/uk/cli/plugins#inspect).
### Застарілі hooks
Hook `before_agent_start` залишається підтримуваним як шлях сумісності для plugins лише з hooks. Застарілі реальні plugins досі залежать від нього.
Hook `before_agent_start` залишається підтримуваним як шлях сумісності для plugins лише з hooks. Застарілі реальні plugins усе ще залежать від нього.
Напрямок:
Напрям:
- підтримувати його працездатність
- підтримувати його роботу
- документувати його як застарілий
- надавати перевагу `before_model_resolve` для роботи з перевизначенням моделі/постачальника
- надавати перевагу `before_model_resolve` для роботи з перевизначенням model/provider
- надавати перевагу `before_prompt_build` для роботи зі зміною prompt
- видалити лише після того, як реальне використання зменшиться, а покриття fixtures підтвердить безпеку міграції
- видаляти лише після зменшення реального використання та коли покриття fixtures доведе безпечність міграції
### Сигнали сумісності
Коли ви запускаєте `openclaw doctor` або `openclaw plugins inspect <id>`, ви можете побачити одну з цих міток:
| Сигнал | Значення |
| Сигнал | Значення |
| -------------------------- | ------------------------------------------------------------ |
| **config valid** | Config успішно розбирається, а plugins розв’язуються |
| **config valid** | Config успішно розбирається, а plugins resolve |
| **compatibility advisory** | Plugin використовує підтримуваний, але старіший шаблон (наприклад, `hook-only`) |
| **legacy warning** | Plugin використовує `before_agent_start`, який застарів |
| **hard error** | Config недійсний або plugin не вдалося завантажити |
| **legacy warning** | Plugin використовує `before_agent_start`, який є deprecated |
| **hard error** | Config недійсна або plugin не вдалося завантажити |
Ані `hook-only`, ані `before_agent_start` сьогодні не зламають ваш plugin: `hook-only` є рекомендаційним сигналом, а `before_agent_start` лише викликає попередження. Ці сигнали також з’являються в `openclaw status --all` і `openclaw plugins doctor`.
@ -124,87 +124,89 @@ Hook `before_agent_start` залишається підтримуваним як
<Steps>
<Step title="Маніфест + виявлення">
OpenClaw знаходить кандидатні plugins із налаштованих шляхів, коренів робочих просторів, глобальних коренів plugins і вбудованих plugins. Виявлення спочатку читає нативні маніфести `openclaw.plugin.json` та підтримувані маніфести пакетів.
OpenClaw знаходить кандидатні plugins із налаштованих шляхів, workspace roots, глобальних коренів plugins і bundled plugins. Виявлення спочатку читає нативні маніфести `openclaw.plugin.json` плюс підтримувані bundle manifests.
</Step>
<Step title="Увімкнення + перевірка">
Core вирішує, чи виявлений plugin увімкнений, вимкнений, заблокований або вибраний для ексклюзивного слота, наприклад пам’яті.
<Step title="Увімкнення + валідація">
Core вирішує, чи виявлений plugin увімкнено, вимкнено, заблоковано або вибрано для ексклюзивного слота, як-от memory.
</Step>
<Step title="Завантаження під час виконання">
Нативні plugins OpenClaw завантажуються в процесі через jiti і реєструють можливості в центральному реєстрі. Сумісні пакети нормалізуються в записи реєстру без імпортування коду виконання.
<Step title="Завантаження runtime">
Нативні plugins OpenClaw завантажуються in-process через jiti та реєструють можливості в центральному registry. Сумісні bundles нормалізуються в registry records без імпорту runtime code.
</Step>
<Step title="Споживання поверхнями">
Решта OpenClaw читає реєстр, щоб відкривати tools, канали, налаштування постачальників, hooks, HTTP-маршрути, команди CLI та служби.
<Step title="Споживання поверхонь">
Решта OpenClaw читає registry, щоб expose tools, channels, provider setup, hooks, HTTP routes, CLI commands і services.
</Step>
</Steps>
Саме для CLI plugins виявлення кореневих команд поділено на дві фази:
Спеціально для plugin CLI виявлення root commands розділене на дві фази:
- метадані часу розбору надходять із `registerCli(..., { descriptors: [...] })`
- справжній модуль CLI plugin може залишатися ледачим і реєструватися під час першого виклику
- метадані під час parse-time надходять із `registerCli(..., { descriptors: [...] })`
- справжній модуль CLI plugin може залишатися lazy і реєструватися під час першого invocation
Це утримує CLI-код, що належить plugin, всередині plugin, водночас дозволяючи OpenClaw зарезервувати назви кореневих команд до розбору.
Це тримає CLI-код, що належить plugin, всередині plugin, але все одно дозволяє OpenClaw резервувати імена root commands до parsing.
Важлива межа дизайну:
- перевірка маніфесту/config має працювати з **метаданих маніфесту/схеми** без виконання коду plugin
- виявлення нативних можливостей може завантажувати довірений код входу plugin, щоб побудувати знімок реєстру без активації
- нативна поведінка під час виконання надходить зі шляху `register(api)` модуля plugin, коли `api.registrationMode === "full"`
- валідація manifest/config має працювати з **metadata manifest/schema** без виконання коду plugin
- нативне виявлення можливостей може завантажувати trusted entry code plugin, щоб побудувати non-activating registry snapshot
- нативна runtime-поведінка походить зі шляху `register(api)` модуля plugin з `api.registrationMode === "full"`
Такий поділ дає OpenClaw змогу перевіряти config, пояснювати відсутні/вимкнені plugins і будувати підказки UI/схеми до того, як повний runtime стане активним.
Цей поділ дозволяє OpenClaw валідувати config, пояснювати відсутні/вимкнені plugins і будувати підказки UI/schema до того, як повний runtime стане активним.
### Знімок метаданих plugin і таблиця пошуку
### Snapshot метаданих plugin і lookup table
Під час запуску Gateway будує один `PluginMetadataSnapshot` для поточного знімка config. Знімок містить лише метадані: він зберігає індекс установлених plugins, реєстр маніфестів, діагностику маніфестів, карти власників, нормалізатор id plugin і записи маніфестів. Він не містить завантажених модулів plugin, SDK постачальників, вмісту пакетів або runtime-експортів.
Під час запуску Gateway будує один `PluginMetadataSnapshot` для поточного snapshot config. Snapshot містить лише метадані: він зберігає індекс встановлених plugins, manifest registry, manifest diagnostics, owner maps, нормалізатор id plugin і manifest records. Він не містить завантажених модулів plugin, provider SDKs, package contents або runtime exports.
Перевірка config з урахуванням plugins, автоматичне увімкнення під час запуску та bootstrap plugins Gateway споживають цей знімок замість незалежної повторної побудови метаданих маніфесту/індексу. `PluginLookUpTable` виводиться з того самого знімка й додає план plugins запуску для поточної runtime config.
Валідація config з урахуванням plugins, startup auto-enable і bootstrap plugins Gateway споживають цей snapshot замість незалежної перебудови manifest/index metadata. `PluginLookUpTable` виводиться з того самого snapshot і додає startup plugin plan для поточного runtime config.
Після запуску Gateway зберігає поточний знімок метаданих як замінюваний runtime-продукт. Повторне виявлення runtime-постачальників може позичати цей знімок замість реконструкції встановленого індексу та реєстру маніфестів для кожного проходу каталогу постачальників. Знімок очищується або замінюється під час завершення роботи Gateway, змін config/інвентарю plugins і записів установленого індексу; виклики повертаються до холодного шляху маніфесту/індексу, коли сумісного поточного знімка немає. Перевірки сумісності мають включати корені виявлення plugins, такі як `plugins.load.paths` і стандартний робочий простір агента, оскільки plugins робочого простору є частиною області метаданих.
Після запуску Gateway зберігає поточний metadata snapshot як замінний runtime product. Повторне runtime provider discovery може позичати цей snapshot замість реконструювання installed index і manifest registry для кожного provider-catalog pass. Snapshot очищується або замінюється під час завершення роботи Gateway, змін config/plugin inventory і записів installed index; callers повертаються до холодного manifest/index path, коли немає сумісного поточного snapshot. Compatibility checks мають включати plugin discovery roots, як-от `plugins.load.paths`, і стандартний agent workspace, тому що workspace plugins є частиною metadata scope.
Знімок і таблиця пошуку утримують повторні рішення запуску на швидкому шляху:
Snapshot і lookup table тримають повторювані startup decisions на швидкому path:
- власність каналу
- відкладений запуск каналу
- id plugins запуску
- власність постачальника та бекенду CLI
- власність постачальника налаштування, alias команди, постачальника каталогу моделей і контракту маніфесту
- перевірка схеми config plugin і схеми config каналу
- рішення автоматичного увімкнення під час запуску
- channel ownership
- deferred channel startup
- startup plugin ids
- provider and CLI backend ownership
- setup provider, command alias, model catalog provider і manifest contract ownership
- валідація plugin config schema і channel config schema
- startup auto-enable decisions
Межею безпеки є заміна знімка, а не мутація. Перебудовуйте знімок, коли змінюються config, інвентар plugins, записи встановлення або політика збереженого індексу. Не розглядайте його як широкий змінний глобальний реєстр і не зберігайте необмежену історію знімків. Runtime-завантаження plugins залишається окремим від знімків метаданих, щоб застарілий runtime-стан не міг бути прихований за кешем метаданих.
Межа безпеки — це заміна snapshot, а не mutation. Перебудовуйте snapshot, коли змінюються config, plugin inventory, install records або persisted index policy. Не вважайте його широким mutable global registry і не зберігайте необмежені historical snapshots. Runtime plugin loading залишається окремим від metadata snapshots, щоб stale runtime state не міг бути прихований за metadata cache.
Деякі виклики холодного шляху досі реконструюють реєстри маніфестів безпосередньо зі збереженого індексу встановлених plugins замість отримання Gateway `PluginLookUpTable`. Цей запасний шлях зберігає невеликий обмежений кеш у пам’яті, ключований установленим індексом, формою запиту, політикою config, runtime-коренями та сигнатурами файлів маніфесту/пакета. Це запасна сітка безпеки для повторної реконструкції індексу, а не бажаний гарячий шлях Gateway. Надавайте перевагу передаванню поточної таблиці пошуку або явного реєстру маніфестів через runtime-потоки, коли виклик уже має один із них.
Правило cache задокументовано в [Plugin architecture internals](/uk/plugins/architecture-internals#plugin-cache-boundary): metadata manifest і discovery є свіжими, якщо caller не тримає explicit snapshot, lookup table або manifest registry для поточного flow. Hidden metadata caches і wall-clock TTLs не є частиною plugin loading. Лише runtime loader, module і dependency-artifact caches можуть зберігатися після фактичного завантаження code або installed artifacts.
Деякі cold-path callers досі реконструюють manifest registries напряму з persisted installed plugin index замість отримання `PluginLookUpTable` Gateway. Цей path тепер реконструює registry on demand; надавайте перевагу передаванню current lookup table або explicit manifest registry через runtime flows, коли caller уже має один із них.
### Планування активації
Планування активації є частиною control plane. Виклики можуть запитати, які plugins релевантні для конкретної команди, постачальника, каналу, маршруту, harness агента або можливості, перш ніж завантажувати ширші runtime-реєстри.
Планування активації є частиною control plane. Callers можуть запитати, які plugins релевантні для конкретної command, provider, channel, route, agent harness або capability, перш ніж завантажувати ширші runtime registries.
Планувальник зберігає сумісність із поточною поведінкою маніфесту:
Planner зберігає сумісність поточної manifest-поведінки:
- поля `activation.*` є явними підказками планувальника
- `providers`, `channels`, `commandAliases`, `setup.providers`, `contracts.tools` і hooks залишаються запасним варіантом визначення власності з маніфесту
- API планувальника лише з id залишається доступним для наявних викликів
- API плану повідомляє мітки причин, щоб діагностика могла відрізняти явні підказки від запасного визначення власності
- поля `activation.*` є явними підказками planner
- `providers`, `channels`, `commandAliases`, `setup.providers`, `contracts.tools` і hooks залишаються fallback ownership manifest
- ids-only planner API залишається доступним для наявних callers
- plan API повідомляє reason labels, щоб diagnostics могли відрізняти explicit hints від ownership fallback
<Warning>
Не розглядайте `activation` як hook життєвого циклу або заміну для `register(...)`. Це метадані, що використовуються для звуження завантаження. Надавайте перевагу полям власності, коли вони вже описують зв’язок; використовуйте `activation` лише для додаткових підказок планувальника.
Не розглядайте `activation` як хук життєвого циклу або заміну для `register(...)`. Це метадані, які використовуються для звуження завантаження. Віддавайте перевагу полям власності, коли вони вже описують зв’язок; використовуйте `activation` лише для додаткових підказок планувальнику.
</Warning>
### Channel plugins і спільний tool повідомлень
### Канальні плагіни та спільний інструмент повідомлень
Plugin каналів не потрібно реєструвати окремий інструмент send/edit/react для звичайних дій чату. OpenClaw зберігає один спільний інструмент `message` у ядрі, а Plugin каналів володіють специфічним для каналу виявленням і виконанням за ним.
Канальним плагінам не потрібно реєструвати окремий інструмент надсилання/редагування/реакцій для звичайних дій у чаті. OpenClaw зберігає один спільний інструмент `message` у ядрі, а канальні плагіни володіють специфічним для каналу виявленням і виконанням за ним.
Поточна межа така:
- ядро володіє спільним хостом інструмента `message`, підключенням prompt, обліком сесій/threads і диспетчеризацією виконання
- Plugin каналів володіють виявленням дій у межах області, виявленням можливостей і будь-якими специфічними для каналу фрагментами schema
- Plugin каналів володіють граматикою розмови сесії конкретного провайдера, наприклад тим, як conversation ids кодують thread ids або успадковуються від батьківських розмов
- Plugin каналів виконують фінальну дію через свій action adapter
- ядро володіє хостом спільного інструмента `message`, підключенням промптів, обліком сеансів/тредів і диспетчеризацією виконання
- канальні плагіни володіють виявленням дій у межах області, виявленням можливостей і будь-якими специфічними для каналу фрагментами схеми
- канальні плагіни володіють специфічною для провайдера граматикою розмови сеансу, наприклад тим, як ідентифікатори розмов кодують ідентифікатори тредів або успадковуються від батьківських розмов
- канальні плагіни виконують фінальну дію через свій адаптер дій
Для Plugin каналів поверхня SDK — це `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик виявлення дає Plugin змогу повертати видимі дії, можливості та внески до schema разом, щоб ці частини не розходилися.
Для канальних плагінів поверхня SDK — це `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик виявлення дає плагіну змогу повернути свої видимі дії, можливості та внески до схеми разом, щоб ці частини не розходилися.
Коли специфічний для каналу параметр message-tool містить джерело media, як-от локальний шлях або віддалений media URL, Plugin також має повертати `mediaSourceParams` із `describeMessageTool(...)`. Ядро використовує цей явний список, щоб застосувати нормалізацію sandbox path і підказки outbound media-access без жорстко закодованих назв параметрів, що належать Plugin. Надавайте перевагу мапам у межах дії, а не одному плоскому списку на весь канал, щоб media-параметр лише для профілю не нормалізувався для непов’язаних дій, як-от `send`.
Коли специфічний для каналу параметр інструмента повідомлень містить джерело медіа, наприклад локальний шлях або URL віддаленого медіа, плагін також має повертати `mediaSourceParams` з `describeMessageTool(...)`. Ядро використовує цей явний список, щоб застосувати нормалізацію шляхів пісочниці та підказки доступу до вихідних медіа без жорсткого кодування назв параметрів, якими володіє плагін. Віддавайте перевагу мапам у межах дії, а не одному пласкому списку для всього каналу, щоб параметр медіа лише для профілю не нормалізувався в непов’язаних діях, як-от `send`.
Ядро передає runtime scope у цей крок виявлення. Важливі поля включають:
Ядро передає область виконання на цьому кроці виявлення. Важливі поля включають:
- `accountId`
- `currentChannelId`
@ -213,108 +215,108 @@ Plugin каналів не потрібно реєструвати окреми
- `sessionKey`
- `sessionId`
- `agentId`
- довірений inbound `requesterSenderId`
- довірений вхідний `requesterSenderId`
Це важливо для контекстно-залежних Plugin. Канал може приховувати або показувати message actions на основі активного облікового запису, поточної room/thread/message або довіреної ідентичності requester без жорстко закодованих специфічних для каналу гілок у ядрі інструмента `message`.
Це важливо для контекстно-залежних плагінів. Канал може приховувати або показувати дії повідомлень залежно від активного облікового запису, поточної кімнати/треду/повідомлення або довіреної ідентичності запитувача без жорстко закодованих специфічних для каналу гілок у базовому інструменті `message`.
Саме тому зміни маршрутизації embedded-runner все ще є роботою Plugin: runner відповідає за пересилання поточної ідентичності chat/session у межу виявлення Plugin, щоб спільний інструмент `message` відкривав правильну поверхню, що належить каналу, для поточного ходу.
Саме тому зміни маршрутизації вбудованого раннера все ще є роботою плагіна: раннер відповідає за передавання поточної ідентичності чату/сеансу до межі виявлення плагіна, щоб спільний інструмент `message` показував правильну поверхню, якою володіє канал, для поточного ходу.
Для execution helpers, що належать каналу, bundled plugins мають тримати execution runtime всередині власних модулів розширення. Ядро більше не володіє runtime для message-action Discord, Slack, Telegram або WhatsApp у `src/agents/tools`. Ми не публікуємо окремі subpaths `plugin-sdk/*-action-runtime`, і bundled plugins мають імпортувати власний локальний runtime code безпосередньо зі своїх модулів, що належать розширенню.
Для допоміжних засобів виконання, якими володіє канал, вбудовані плагіни мають тримати середовище виконання всередині власних модулів розширення. Ядро більше не володіє середовищами виконання дій повідомлень Discord, Slack, Telegram або WhatsApp у `src/agents/tools`. Ми не публікуємо окремі підшляхи `plugin-sdk/*-action-runtime`, і вбудовані плагіни мають імпортувати власний локальний код середовища виконання безпосередньо зі своїх модулів, якими володіє розширення.
Та сама межа загалом застосовується до provider-named SDK seams: ядро не має імпортувати специфічні для каналу convenience barrels для Slack, Discord, Signal, WhatsApp або подібних розширень. Якщо ядру потрібна поведінка, воно має або споживати власний barrel bundled Plugin `api.ts` / `runtime-api.ts`, або підняти потребу в вузьку generic capability у спільному SDK.
Та сама межа загалом застосовується до названих за провайдерами швів SDK: ядро не має імпортувати специфічні для каналу зручні барелі для Slack, Discord, Signal, WhatsApp або подібних розширень. Якщо ядру потрібна поведінка, або споживайте власний барель `api.ts` / `runtime-api.ts` вбудованого плагіна, або підніміть потребу до вузької загальної можливості у спільному SDK.
Bundled plugins дотримуються того самого правила. `runtime-api.ts` bundled Plugin не має повторно експортувати власний branded facade `openclaw/plugin-sdk/<plugin-id>`. Ці branded facades лишаються compatibility shims для external plugins і старіших consumers, але bundled plugins мають використовувати локальні exports плюс вузькі generic SDK subpaths, як-от `openclaw/plugin-sdk/channel-policy`, `openclaw/plugin-sdk/runtime-store` або `openclaw/plugin-sdk/webhook-ingress`. Новий код не має додавати SDK facades, специфічні для plugin-id, якщо цього не вимагає compatibility boundary для наявної зовнішньої екосистеми.
Вбудовані плагіни дотримуються того самого правила. `runtime-api.ts` вбудованого плагіна не має повторно експортувати власний брендований фасад `openclaw/plugin-sdk/<plugin-id>`. Ці брендовані фасади залишаються сумісними shim для зовнішніх плагінів і старіших споживачів, але вбудовані плагіни мають використовувати локальні експорти плюс вузькі загальні підшляхи SDK, як-от `openclaw/plugin-sdk/channel-policy`, `openclaw/plugin-sdk/runtime-store` або `openclaw/plugin-sdk/webhook-ingress`. Новий код не має додавати специфічні для ідентифікатора плагіна фасади SDK, якщо межа сумісності для наявної зовнішньої екосистеми цього не вимагає.
Конкретно для polls є два шляхи виконання:
Зокрема для опитувань є два шляхи виконання:
- `outbound.sendPoll` — спільна базова лінія для каналів, що відповідають common poll model
- `actions.handleAction("poll")` — бажаний шлях для специфічної для каналу semantics poll або додаткових poll parameters
- `outbound.sendPoll` — це спільна базова лінія для каналів, які відповідають спільній моделі опитування
- `actions.handleAction("poll")` — бажаний шлях для специфічної для каналу семантики опитувань або додаткових параметрів опитування
Тепер ядро відкладає спільний parsing poll, доки диспетчеризація poll Plugin не відхилить дію, тому poll handlers, що належать Plugin, можуть приймати специфічні для каналу poll fields без блокування generic poll parser спочатку.
Тепер ядро відкладає спільний розбір опитування доти, доки диспетчеризація опитування плагіном не відхилить дію, тож обробники опитувань, якими володіє плагін, можуть приймати специфічні для каналу поля опитування без попереднього блокування загальним парсером опитувань.
Див. [внутрішню архітектуру Plugin](/uk/plugins/architecture-internals), щоб переглянути повну послідовність запуску.
Див. [Внутрішня архітектура плагінів](/uk/plugins/architecture-internals) для повної послідовності запуску.
## Модель володіння можливостями
## Модель власності можливостей
OpenClaw розглядає native Plugin як межу володіння для **компанії** або **функції**, а не як випадковий набір непов’язаних інтеграцій.
OpenClaw розглядає нативний плагін як межу власності для **компанії** або **функції**, а не як набір непов’язаних інтеграцій.
Це означає:
- company Plugin зазвичай має володіти всіма поверхнями цієї компанії, зверненими до OpenClaw
- feature Plugin зазвичай має володіти повною поверхнею функції, яку він вводить
- канали мають споживати спільні можливості ядра замість повторної ad hoc реалізації provider behavior
- плагін компанії зазвичай має володіти всіма поверхнями цієї компанії, спрямованими до OpenClaw
- функціональний плагін зазвичай має володіти повною поверхнею функції, яку він вводить
- канали мають споживати спільні можливості ядра замість того, щоб повторно реалізовувати поведінку провайдера ad hoc
<AccordionGroup>
<Accordion title="Мульти-можливість постачальника">
`openai` володіє text inference, speech, realtime voice, media understanding та image generation. `google` володіє text inference плюс media understanding, image generation і web search. `qwen` володіє text inference плюс media understanding і video generation.
<Accordion title="Багатоможливісний постачальник">
`openai` володіє текстовим інференсом, мовленням, голосом у реальному часі, розумінням медіа та генерацією зображень. `google` володіє текстовим інференсом плюс розумінням медіа, генерацією зображень і вебпошуком. `qwen` володіє текстовим інференсом плюс розумінням медіа та генерацією відео.
</Accordion>
<Accordion title="Одна можливість постачальника">
`elevenlabs` і `microsoft` володіють speech; `firecrawl` володіє web-fetch; `minimax` / `mistral` / `moonshot` / `zai` володіють media-understanding backends.
<Accordion title="Одноможливісний постачальник">
`elevenlabs` і `microsoft` володіють мовленням; `firecrawl` володіє web-fetch; `minimax` / `mistral` / `moonshot` / `zai` володіють бекендами розуміння медіа.
</Accordion>
<Accordion title="Feature Plugin">
`voice-call` володіє call transport, tools, CLI, routes і Twilio media-stream bridging, але споживає спільні можливості speech, realtime transcription і realtime voice замість прямого імпорту vendor plugins.
<Accordion title="Функціональний плагін">
`voice-call` володіє транспортом викликів, інструментами, CLI, маршрутами та мостом медіапотоку Twilio, але споживає спільні можливості мовлення, транскрибування в реальному часі та голосу в реальному часі замість прямого імпорту плагінів постачальників.
</Accordion>
</AccordionGroup>
Очікуваний кінцевий стан:
- OpenAI живе в одному Plugin, навіть якщо охоплює text models, speech, images і майбутнє video
- інший постачальник може зробити те саме для власної surface area
- каналам байдуже, який vendor Plugin володіє provider; вони споживають спільний capability contract, відкритий ядром
- OpenAI живе в одному плагіні, навіть якщо охоплює текстові моделі, мовлення, зображення та майбутнє відео
- інший постачальник може зробити те саме для власної поверхні
- каналам байдуже, який плагін постачальника володіє провайдером; вони споживають спільний контракт можливості, відкритий ядром
Ключова відмінність така:
Це ключова відмінність:
- **Plugin** = межа володіння
- **capability** = контракт ядра, який можуть реалізовувати або споживати кілька Plugin
- **плагін** = межа власності
- **можливість** = контракт ядра, який кілька плагінів можуть реалізовувати або споживати
Тож якщо OpenClaw додає новий домен, як-от video, перше питання не "який provider має жорстко закодувати обробку video?" Перше питання — "який core video capability contract?" Коли цей контракт існує, vendor plugins можуть реєструватися для нього, а channel/feature plugins можуть його споживати.
Отже, якщо OpenClaw додає нову доменну область, таку як відео, перше питання не "який провайдер має жорстко кодувати обробку відео?" Перше питання: "яким є контракт можливості відео в ядрі?" Коли цей контракт існує, плагіни постачальників можуть реєструватися під нього, а канальні/функціональні плагіни можуть його споживати.
Якщо capability ще не існує, правильний крок зазвичай такий:
Якщо можливості ще не існує, правильний крок зазвичай такий:
<Steps>
<Step title="Визначте capability">
Визначте відсутню capability у ядрі.
<Step title="Визначте можливість">
Визначте відсутню можливість у ядрі.
</Step>
<Step title="Відкрийте через SDK">
Відкрийте її через Plugin API/runtime типізованим способом.
Відкрийте її через API/середовище виконання плагінів типізованим способом.
</Step>
<Step title="Підключіть consumers">
Підключіть channels/features до цієї capability.
<Step title="Підключіть споживачів">
Підключіть канали/функції до цієї можливості.
</Step>
<Step title="Реалізації постачальників">
Дайте vendor plugins змогу реєструвати реалізації.
Дайте плагінам постачальників зареєструвати реалізації.
</Step>
</Steps>
Це зберігає явне володіння, водночас уникаючи поведінки ядра, що залежить від одного vendor або одноразового code path, специфічного для Plugin.
Це зберігає явну власність і водночас уникає поведінки ядра, що залежить від одного постачальника або одноразового специфічного для плагіна шляху коду.
### Нашарування capabilities
### Нашарування можливостей
Використовуйте цю ментальну модель, коли вирішуєте, де має бути код:
Використовуйте цю ментальну модель, вирішуючи, де має бути код:
<Tabs>
<Tab title="Шар core capability">
Спільна оркестрація, policy, fallback, config merge rules, delivery semantics і typed contracts.
<Tab title="Шар можливостей ядра">
Спільна оркестрація, політика, fallback, правила злиття конфігурації, семантика доставки та типізовані контракти.
</Tab>
<Tab title="Шар vendor Plugin">
Vendor-specific APIs, auth, model catalogs, speech synthesis, image generation, майбутні video backends, usage endpoints.
<Tab title="Шар плагіна постачальника">
Специфічні для постачальника API, auth, каталоги моделей, синтез мовлення, генерація зображень, майбутні відеобекенди, ендпоінти використання.
</Tab>
<Tab title="Шар channel/feature Plugin">
Інтеграція Slack/Discord/voice-call/тощо, яка споживає core capabilities і представляє їх на поверхні.
<Tab title="Шар канального/функціонального плагіна">
Інтеграція Slack/Discord/voice-call/etc., яка споживає можливості ядра та представляє їх на поверхні.
</Tab>
</Tabs>
Наприклад, TTS має таку форму:
- ядро володіє reply-time TTS policy, fallback order, prefs і channel delivery
- `openai`, `elevenlabs` і `microsoft` володіють synthesis implementations
- `voice-call` споживає telephony TTS runtime helper
- ядро володіє політикою TTS під час відповіді, порядком fallback, налаштуваннями та доставкою в канал
- `openai`, `elevenlabs` і `microsoft` володіють реалізаціями синтезу
- `voice-call` споживає допоміжний засіб середовища виконання телефонного TTS
Для майбутніх можливостей варто надавати перевагу тому самому шаблону.
Тому самому шаблону слід віддавати перевагу для майбутніх можливостей.
### Приклад company Plugin із кількома capabilities
### Приклад багатоможливісного плагіна компанії
Company Plugin має відчуватися цілісним ззовні. Якщо OpenClaw має спільні контракти для models, speech, realtime transcription, realtime voice, media understanding, image generation, video generation, web fetch і web search, vendor може володіти всіма своїми поверхнями в одному місці:
Плагін компанії має сприйматися ззовні як цілісний. Якщо OpenClaw має спільні контракти для моделей, мовлення, транскрибування в реальному часі, голосу в реальному часі, розуміння медіа, генерації зображень, генерації відео, web fetch і вебпошуку, постачальник може володіти всіма своїми поверхнями в одному місці:
```ts
import type { OpenClawPluginDefinition } from "openclaw/plugin-sdk/plugin-entry";
@ -368,119 +370,119 @@ const plugin: OpenClawPluginDefinition = {
export default plugin;
```
Важливі не точні назви helper. Важлива форма:
Важливі не точні назви допоміжних засобів. Важлива форма:
- один Plugin володіє vendor surface
- ядро все ще володіє capability contracts
- канали та feature plugins споживають helpers `api.runtime.*`, а не vendor code
- contract tests можуть перевіряти, що Plugin зареєстрував capabilities, якими заявляє володіння
- один плагін володіє поверхнею постачальника
- ядро все ще володіє контрактами можливостей
- канали та функціональні плагіни споживають допоміжні засоби `api.runtime.*`, а не код постачальника
- контрактні тести можуть перевіряти, що плагін зареєстрував можливості, якими заявляє володіння
### Приклад capability: video understanding
### Приклад можливості: розуміння відео
OpenClaw уже розглядає image/audio/video understanding як одну спільну capability. Та сама модель володіння застосовується і там:
OpenClaw уже розглядає розуміння зображень/аудіо/відео як одну спільну можливість. Та сама модель власності застосовується і там:
<Steps>
<Step title="Ядро визначає контракт">
Ядро визначає media-understanding contract.
Ядро визначає контракт розуміння медіа.
</Step>
<Step title="Vendor plugins реєструються">
Vendor plugins реєструють `describeImage`, `transcribeAudio` і `describeVideo`, якщо застосовно.
<Step title="Плагіни постачальників реєструються">
Плагіни постачальників реєструють `describeImage`, `transcribeAudio` і `describeVideo`, якщо застосовно.
</Step>
<Step title="Consumers використовують спільну поведінку">
Channels і feature plugins споживають спільну core behavior замість прямого підключення до vendor code.
<Step title="Споживачі використовують спільну поведінку">
Канали та функціональні плагіни споживають спільну поведінку ядра замість прямого підключення до коду постачальника.
</Step>
</Steps>
Це уникає вбудовування припущень одного provider щодо video у ядро. Plugin володіє vendor surface; ядро володіє capability contract і fallback behavior.
Це уникає вбудовування припущень одного провайдера про відео в ядро. Плагін володіє поверхнею постачальника; ядро володіє контрактом можливості та поведінкою fallback.
Video generation уже використовує ту саму послідовність: ядро володіє typed capability contract і runtime helper, а vendor plugins реєструють реалізації `api.registerVideoGenerationProvider(...)` для нього.
Генерація відео вже використовує ту саму послідовність: ядро володіє типізованим контрактом можливості та допоміжним засобом середовища виконання, а плагіни постачальників реєструють реалізації `api.registerVideoGenerationProvider(...)` під нього.
Потрібен конкретний rollout checklist? Див. [Capability Cookbook](/uk/plugins/architecture).
Потрібен конкретний контрольний список розгортання? Див. [Кулінарна книга можливостей](/uk/plugins/architecture).
## Контракти та примусове застосування
## Контракти та примусове забезпечення
Поверхня Plugin API навмисно типізована й централізована в `OpenClawPluginApi`. Цей контракт визначає підтримувані registration points і runtime helpers, на які може покладатися Plugin.
Поверхня API плагінів навмисно типізована й централізована в `OpenClawPluginApi`. Цей контракт визначає підтримувані точки реєстрації та допоміжні засоби середовища виконання, на які плагін може покладатися.
Чому це важливо:
- автори Plugin отримують один стабільний внутрішній стандарт
- ядро може відхиляти duplicate ownership, наприклад коли два Plugin реєструють той самий provider id
- запуск може показувати actionable diagnostics для malformed registration
- contract tests можуть забезпечувати ownership bundled-plugin і запобігати непомітному drift
- автори плагінів отримують один стабільний внутрішній стандарт
- ядро може відхиляти дублювання власності, наприклад коли два плагіни реєструють той самий ідентифікатор провайдера
- запуск може показувати діагностику з конкретними діями для некоректної реєстрації
- контрактні тести можуть забезпечувати власність вбудованих плагінів і запобігати непомітному дрейфу
Є два рівні enforcement:
Є два шари примусового забезпечення:
<AccordionGroup>
<Accordion title="Примусове застосування реєстрації під час runtime">
Plugin registry перевіряє registrations під час завантаження Plugin. Приклади: duplicate provider ids, duplicate speech provider ids і malformed registrations створюють plugin diagnostics замість undefined behavior.
<Accordion title="Примусове застосування реєстрації під час виконання">
Реєстр Plugin перевіряє реєстрації під час завантаження Plugin. Приклади: дублікати ідентифікаторів провайдерів, дублікати ідентифікаторів провайдерів мовлення та некоректно сформовані реєстрації створюють діагностику Plugin замість невизначеної поведінки.
</Accordion>
<Accordion title="Contract tests">
Bundled plugins фіксуються в contract registries під час тестових запусків, щоб OpenClaw міг явно перевіряти ownership. Сьогодні це використовується для model providers, speech providers, web search providers і bundled registration ownership.
<Accordion title="Контрактні тести">
Вбудовані Plugin фіксуються в контрактних реєстрах під час тестових запусків, щоб OpenClaw міг явно перевіряти володіння. Нині це використовується для провайдерів моделей, провайдерів мовлення, провайдерів вебпошуку та володіння вбудованими реєстраціями.
</Accordion>
</AccordionGroup>
Практичний ефект полягає в тому, що OpenClaw заздалегідь знає, який plugin володіє якою поверхнею. Це дає змогу ядру й каналам безшовно компонуватися, тому що володіння оголошене, типізоване й придатне для тестування, а не неявне.
Практичний ефект полягає в тому, що OpenClaw заздалегідь знає, який Plugin володіє якою поверхнею. Це дає core і каналам змогу безшовно компонуватися, оскільки володіння оголошене, типізоване й тестоване, а не неявне.
### Що належить до контракту
<Tabs>
<Tab title="Добрі контракти">
<Tab title="Хороші контракти">
- типізовані
- невеликі
- специфічні для можливості
- належать ядру
- повторно використовувані кількома plugins
- споживані каналами/функціями без знання постачальника
- малі
- прив’язані до конкретної можливості
- належать core
- повторно використовуються кількома Plugin
- споживаються каналами/функціями без знання постачальника
</Tab>
<Tab title="Погані контракти">
- специфічна для постачальника політика, прихована в ядрі
- одноразові обхідні шляхи plugin, що обходять реєстр
- код каналу, який напряму звертається до реалізації постачальника
- ситуативні runtime-об’єкти, які не є частиною `OpenClawPluginApi` або `api.runtime`
- специфічна для постачальника політика, прихована в core
- одноразові обхідні шляхи Plugin, що обходять реєстр
- код каналу, який звертається напряму до реалізації постачальника
- ad hoc об’єкти часу виконання, що не є частиною `OpenClawPluginApi` або `api.runtime`
</Tab>
</Tabs>
Якщо маєте сумніви, підніміть рівень абстракції: спочатку визначте можливість, а потім дозвольте plugins підключатися до неї.
Коли є сумніви, підніміть рівень абстракції: спочатку визначте можливість, а потім дозвольте Plugin підключатися до неї.
## Модель виконання
Нативні plugins OpenClaw працюють **у процесі** разом із Gateway. Вони не ізольовані в пісочниці. Завантажений нативний plugin має ту саму межу довіри на рівні процесу, що й код ядра.
Нативні Plugin OpenClaw працюють **у процесі** разом із Gateway. Вони не ізольовані в пісочниці. Завантажений нативний Plugin має ту саму межу довіри на рівні процесу, що й код core.
<Warning>
Наслідки нативних plugins: plugin може реєструвати інструменти, мережеві обробники, хуки й сервіси; помилка plugin може спричинити збій або дестабілізувати gateway; а зловмисний нативний plugin еквівалентний виконанню довільного коду всередині процесу OpenClaw.
Наслідки нативного Plugin: Plugin може реєструвати інструменти, мережеві обробники, хуки й сервіси; помилка в Plugin може аварійно завершити або дестабілізувати gateway; а шкідливий нативний Plugin еквівалентний виконанню довільного коду всередині процесу OpenClaw.
</Warning>
Сумісні бандли безпечніші за замовчуванням, тому що OpenClaw наразі розглядає їх як пакети метаданих/контенту. У поточних випусках це здебільшого означає вбудовані skills.
Сумісні пакети безпечніші за замовчуванням, оскільки OpenClaw наразі розглядає їх як пакети метаданих/контенту. У поточних випусках це переважно означає вбудовані Skills.
Використовуйте allowlists і явні шляхи встановлення/завантаження для невбудованих plugins. Розглядайте workspace plugins як код часу розробки, а не як production-стандарт.
Використовуйте allowlist і явні шляхи встановлення/завантаження для невбудованих Plugin. Розглядайте Plugin робочої області як код для часу розробки, а не як продукційні значення за замовчуванням.
Для імен вбудованих workspace-пакетів прив’язуйте id plugin до npm-імені: `@openclaw/<id>` за замовчуванням або затверджений типізований суфікс, як-от `-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли пакет навмисно надає вужчу роль plugin.
Для імен вбудованих пакетів робочої області тримайте ідентифікатор Plugin прив’язаним до npm-імені: `@openclaw/<id>` за замовчуванням або затверджений типізований суфікс, як-от `-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли пакет навмисно надає вужчу роль Plugin.
<Note>
**Примітка щодо довіри:** `plugins.allow` довіряє **plugin ids**, а не походженню джерела. Workspace plugin із тим самим id, що й вбудований plugin, навмисно затіняє вбудовану копію, коли цей workspace plugin увімкнено/додано до allowlist. Це нормально й корисно для локальної розробки, тестування патчів і hotfixes. Довіра до вбудованого plugin визначається зі знімка джерела — маніфесту й коду на диску під час завантаження, — а не з метаданих встановлення. Пошкоджений або підмінений запис встановлення не може непомітно розширити поверхню довіри вбудованого plugin понад те, що фактично заявляє джерело.
**Примітка щодо довіри:** `plugins.allow` довіряє **ідентифікаторам Plugin**, а не походженню джерела. Plugin робочої області з тим самим ідентифікатором, що й вбудований Plugin, навмисно затіняє вбудовану копію, коли цей Plugin робочої області ввімкнено/додано до allowlist. Це нормально й корисно для локальної розробки, тестування патчів і hotfix. Довіра до вбудованого Plugin визначається зі знімка джерела — маніфесту й коду на диску під час завантаження — а не з метаданих встановлення. Пошкоджений або підмінений запис встановлення не може непомітно розширити поверхню довіри вбудованого Plugin за межі того, що заявляє фактичне джерело.
</Note>
## Межа експорту
OpenClaw експортує можливості, а не зручності реалізації.
Залишайте реєстрацію можливостей публічною. Скорочуйте експорти helper-функцій, які не є контрактами:
Залишайте реєстрацію можливостей публічною. Скоротіть експорти допоміжних елементів, що не є контрактами:
- підшляхи helper-функцій, специфічні для вбудованого plugin
- підшляхи runtime-інфраструктури, не призначені як публічний API
- специфічні для постачальника helper-функції для зручності
- helper-функції налаштування/onboarding, які є деталями реалізації
- допоміжні subpath, специфічні для вбудованого Plugin
- subpath інфраструктури часу виконання, не призначені як публічний API
- зручні допоміжні елементи, специфічні для постачальника
- допоміжні елементи налаштування/onboarding, що є деталями реалізації
Зарезервовані підшляхи helper-функцій вбудованих plugins було вилучено зі згенерованої мапи експортів SDK. Тримайте helper-функції, специфічні для власника, всередині пакета plugin-власника; просувайте лише повторно використовувану поведінку хоста до загальних контрактів SDK, як-от `plugin-sdk/gateway-runtime`, `plugin-sdk/security-runtime` і `plugin-sdk/plugin-config-runtime`.
Зарезервовані допоміжні subpath вбудованого Plugin було вилучено зі згенерованої карти експорту SDK. Тримайте специфічні для власника допоміжні елементи всередині пакета Plugin-власника; підвищуйте лише повторно використовувану поведінку хоста до загальних контрактів SDK, таких як `plugin-sdk/gateway-runtime`, `plugin-sdk/security-runtime` і `plugin-sdk/plugin-config-runtime`.
## Внутрішні механізми й довідка
## Внутрішні механізми та довідка
Про конвеєр завантаження, модель реєстру, runtime-хуки постачальників, HTTP-маршрути Gateway, схеми інструментів повідомлень, визначення цілей каналів, каталоги постачальників, plugins рушія контексту й посібник із додавання нової можливості див. [Внутрішня архітектура plugin](/uk/plugins/architecture-internals).
Про pipeline завантаження, модель реєстру, runtime hooks провайдерів, HTTP-маршрути Gateway, схеми інструментів повідомлень, визначення цілей каналів, каталоги провайдерів, Plugin рушія контексту та посібник із додавання нової можливості див. [Внутрішні механізми архітектури Plugin](/uk/plugins/architecture-internals).
## Пов’язане
- [Створення plugins](/uk/plugins/building-plugins)
- [Маніфест plugin](/uk/plugins/manifest)
- [Створення Plugin](/uk/plugins/building-plugins)
- [Маніфест Plugin](/uk/plugins/manifest)
- [Налаштування Plugin SDK](/uk/plugins/sdk-setup)