Skip to main content
انتقل OpenClaw من طبقة واسعة للتوافق مع الإصدارات السابقة إلى بنية Plugin حديثة تعتمد على استيرادات مركزة وموثقة. إذا كان Plugin الخاص بك قد بُني قبل البنية الجديدة، فسيساعدك هذا الدليل على الترحيل.

ما الذي يتغير

كان نظام Plugin القديم يوفر سطحين واسعين ومفتوحين يتيحان لـ Plugins استيراد أي شيء تحتاج إليه من نقطة دخول واحدة:
  • openclaw/plugin-sdk/compat - استيراد واحد يعيد تصدير عشرات المساعدات. قُدّم لإبقاء Plugins الأقدم المعتمدة على الخطافات تعمل بينما كانت بنية Plugin الجديدة قيد البناء.
  • openclaw/plugin-sdk/infra-runtime - حزمة مساعدات تشغيلية واسعة تمزج أحداث النظام، وحالة Heartbeat، وطوابير التسليم، ومساعدات الجلب/الوكيل، ومساعدات الملفات، وأنواع الموافقة، وأدوات غير ذات صلة.
  • openclaw/plugin-sdk/config-runtime - حزمة توافق إعدادات واسعة ما تزال تحمل مساعدات التحميل/الكتابة المباشرة المهملة خلال نافذة الترحيل.
  • openclaw/extension-api - جسر منح Plugins وصولاً مباشراً إلى مساعدات جانب المضيف مثل مشغّل الوكيل المضمّن.
  • api.registerEmbeddedExtensionFactory(...) - خطاف Plugin مضمّن خاص بالمشغّل المضمّن فقط تمت إزالته، وكان يستطيع مراقبة أحداث المشغّل المضمّن مثل tool_result.
أصبحت أسطح الاستيراد الواسعة الآن مهملة. ما تزال تعمل في وقت التشغيل، لكن يجب ألا تستخدمها Plugins الجديدة، وينبغي لـ Plugins الحالية الترحيل قبل أن يزيلها الإصدار الرئيسي التالي. أزيلت واجهة برمجة تطبيقات تسجيل مصنع Plugin الخاصة بالمشغّل المضمّن فقط؛ استخدم وسيط نتائج الأدوات بدلاً من ذلك. لا يزيل OpenClaw سلوك Plugin الموثق أو يعيد تفسيره في التغيير نفسه الذي يقدم بديلاً. يجب أن تمر تغييرات العقود الكاسرة أولاً عبر محول توافق، وتشخيصات، ومستندات، ونافذة إهمال. ينطبق ذلك على استيرادات SDK، وحقول البيان، وواجهات إعداد API، والخطافات، وسلوك التسجيل في وقت التشغيل.
ستزال طبقة التوافق مع الإصدارات السابقة في إصدار رئيسي مستقبلي. ستتعطل Plugins التي ما تزال تستورد من هذه الأسطح عند حدوث ذلك. لم تعد تسجيلات مصنع Plugin المضمّن القديمة تُحمّل بالفعل.

لماذا تغير هذا

تسبب النهج القديم في مشكلات:
  • بدء تشغيل بطيء - كان استيراد مساعد واحد يحمّل عشرات الوحدات غير ذات الصلة
  • اعتماديات دائرية - جعلت إعادة التصدير الواسعة إنشاء دورات استيراد أمراً سهلاً
  • سطح API غير واضح - لم تكن هناك طريقة لمعرفة أي الصادرات مستقرة وأيها داخلية
يصلح SDK Plugin الحديث هذا: فكل مسار استيراد (openclaw/plugin-sdk/\<subpath\>) هو وحدة صغيرة ومكتفية ذاتياً لها غرض واضح وعقد موثق. اختفت أيضاً طبقات التسهيل القديمة للمزودين الخاصة بالقنوات المضمّنة. كانت طبقات المساعدة ذات العلامة القنوية اختصارات خاصة بمستودع أحادي، وليست عقود Plugin مستقرة. استخدم بدلاً منها مسارات SDK فرعية عامة وضيقة. داخل مساحة عمل Plugin المضمّنة، أبقِ المساعدات المملوكة للمزود داخل api.ts أو runtime-api.ts الخاصة بذلك Plugin. أمثلة المزودين المضمّنين الحالية:
  • يحتفظ Anthropic بمساعدات البث الخاصة بـ Claude في طبقة api.ts / contract-api.ts الخاصة به
  • يحتفظ OpenAI ببناة المزودين، ومساعدات النموذج الافتراضي، وبناة مزود الوقت الحقيقي في api.ts الخاصة به
  • يحتفظ OpenRouter بباني المزود ومساعدات الإعداد/التكوين في api.ts الخاصة به

خطة ترحيل Talk والصوت في الوقت الحقيقي

تنتقل شيفرة Talk الخاصة بالصوت في الوقت الحقيقي، والاتصالات الهاتفية، والاجتماعات، والمتصفح من مسك دفاتر الدور المحلي لكل سطح إلى متحكم جلسة Talk مشترك يصدّره openclaw/plugin-sdk/realtime-voice. يمتلك المتحكم الجديد مظروف أحداث Talk المشترك، وحالة الدور النشط، وحالة الالتقاط، وحالة الصوت الخارج، وسجل الأحداث الحديثة، ورفض الأدوار القديمة. ينبغي أن تظل Plugins المزودين مالكة لجلسات الوقت الحقيقي الخاصة بالمورّد؛ وينبغي أن تظل Plugins الأسطح مالكة لخصوصيات الالتقاط، والتشغيل، والاتصالات الهاتفية، والاجتماعات. ترحيل Talk هذا كاسر ونظيف عمداً:
  1. أبقِ متحكم/بدائيات وقت التشغيل المشتركة في plugin-sdk/realtime-voice.
  2. انقل الأسطح المضمّنة إلى المتحكم المشترك: مرحّل المتصفح، وتسليم الغرفة المُدارة، ووقت الاتصال الصوتي الحقيقي، وSTT المتدفق للاتصال الصوتي، ووقت Google Meet الحقيقي، والضغط الأصلي للتحدث.
  3. استبدل عائلات RPC القديمة الخاصة بـ Talk بواجهة API النهائية talk.session.* و talk.client.*.
  4. أعلن عن قناة أحداث Talk حية واحدة في Gateway hello-ok.features.events: talk.event.
  5. احذف نقطة نهاية HTTP القديمة للوقت الحقيقي وأي مسار لتجاوز التعليمات وقت الطلب.
ينبغي ألا تستدعي الشيفرة الجديدة createTalkEventSequencer(...) مباشرة إلا إذا كانت تنفذ محولاً منخفض المستوى أو أداة اختبار. فضّل المتحكم المشترك حتى لا يمكن إصدار أحداث نطاق الدور من دون معرف دور، ولا يمكن لاستدعاءات turnEnd / turnCancel القديمة مسح دور نشط أحدث، وتبقى أحداث دورة حياة الصوت الخارج متسقة عبر الاتصالات الهاتفية، والاجتماعات، ومرحل المتصفح، وتسليم الغرفة المُدارة، وعملاء Talk الأصليين. شكل API العام المستهدف هو:
تستخدم جلسات WebRTC/provider-websocket المملوكة للمتصفح talk.client.create، لأن المتصفح يمتلك تفاوض المزود ونقل الوسائط، بينما يمتلك Gateway بيانات الاعتماد والتعليمات وسياسة الأدوات. talk.session.* هو السطح المشترك المُدار بواسطة Gateway للوقت الحقيقي عبر gateway-relay، والنسخ عبر gateway-relay، وجلسات STT/TTS الأصلية في الغرفة المُدارة. ينبغي إصلاح الإعدادات القديمة التي وضعت محددات الوقت الحقيقي بجانب talk.provider / talk.providers باستخدام openclaw doctor --fix؛ لا يعيد Talk في وقت التشغيل تفسير إعداد مزود الكلام/TTS باعتباره إعداد مزود وقت حقيقي. توليفات talk.session.create المدعومة صغيرة عمداً: خريطة الطرق المُزالة: كما أن مفردات التحكم الموحدة ضيقة عمداً: لا تُدخل حالات خاصة بالمزوّد أو المنصة في النواة لجعل هذا يعمل. تملك النواة دلالات جلسة Talk. وتملك إضافات المزوّد إعداد جلسة البائع. وتملك المكالمات الصوتية وGoogle Meet محوّلات الهاتفية/الاجتماعات. وتملك تطبيقات المتصفح والتطبيقات الأصلية تجربة مستخدم التقاط/تشغيل الجهاز.

سياسة التوافق

بالنسبة إلى الإضافات الخارجية، يتبع عمل التوافق هذا الترتيب:
  1. أضف العقد الجديد
  2. أبقِ السلوك القديم موصولًا عبر محوّل توافق
  3. أصدِر تشخيصًا أو تحذيرًا يذكر المسار القديم والبديل
  4. غطِّ كلا المسارين في الاختبارات
  5. وثّق الإيقاف التدريجي ومسار الترحيل
  6. أزِل فقط بعد نافذة الترحيل المُعلنة، عادةً في إصدار رئيسي
يمكن للمشرفين تدقيق قائمة انتظار الترحيل الحالية باستخدام pnpm plugins:boundary-report. استخدم pnpm plugins:boundary-report:summary للحصول على أعداد موجزة، و--owner <id> لإضافة واحدة أو مالك توافق واحد، و pnpm plugins:boundary-report:ci عندما ينبغي لبوابة CI أن تفشل عند وجود سجلات توافق مستحقة، أو استيرادات SDK محجوزة عابرة للمالكين، أو مسارات SDK فرعية محجوزة غير مستخدمة. يجمع التقرير سجلات التوافق الموقوفة تدريجيًا حسب تاريخ الإزالة، ويعدّ مراجع الكود/المستندات المحلية، ويُظهر استيرادات SDK المحجوزة العابرة للمالكين، ويلخّص جسر SDK الخاص بمضيف الذاكرة بحيث يبقى تنظيف التوافق صريحًا بدلًا من الاعتماد على عمليات بحث مخصصة. يجب أن يكون للمسارات الفرعية المحجوزة في SDK استخدام مالك متتبّع؛ وينبغي إزالة صادرات المساعدين المحجوزة غير المستخدمة من SDK العام. إذا كان حقل manifest لا يزال مقبولًا، فيمكن لمؤلفي الإضافات الاستمرار في استخدامه حتى تقول المستندات والتشخيصات خلاف ذلك. ينبغي للكود الجديد تفضيل البديل الموثّق، لكن لا ينبغي أن تتعطل الإضافات الموجودة أثناء الإصدارات الثانوية العادية.

كيفية الترحيل

1

ترحيل مساعدات تحميل/كتابة إعدادات وقت التشغيل

ينبغي للإضافات المضمّنة التوقف عن استدعاء api.runtime.config.loadConfig() و api.runtime.config.writeConfigFile(...) مباشرةً. فضّل الإعدادات التي تم تمريرها بالفعل إلى مسار الاستدعاء النشط. يمكن للمعالجات طويلة العمر التي تحتاج إلى لقطة العملية الحالية استخدام api.runtime.config.current(). وينبغي لأدوات الوكيل طويلة العمر استخدام ctx.getRuntimeConfig() الخاص بسياق الأداة داخل execute بحيث تظل الأداة التي أُنشئت قبل كتابة إعدادات قادرة على رؤية إعدادات وقت التشغيل المحدّثة.يجب أن تمر كتابات الإعدادات عبر المساعدات المعاملاتية وأن تختار سياسة ما بعد الكتابة:
استخدم afterWrite: { mode: "restart", reason: "..." } عندما يعرف المستدعي أن التغيير يتطلب إعادة تشغيل نظيفة لـ Gateway، و afterWrite: { mode: "none", reason: "..." } فقط عندما يملك المستدعي المتابعة ويريد عمدًا كبت مخطط إعادة التحميل. تتضمن نتائج الطفرة ملخص followUp ذا نوع محددًا للاختبارات والتسجيل؛ يظل Gateway مسؤولًا عن تطبيق إعادة التشغيل أو جدولتها. يظل loadConfig وwriteConfigFile مساعدَي توافق موقوفين تدريجيًا للإضافات الخارجية أثناء نافذة الترحيل ويحذّران مرة واحدة باستخدام رمز التوافق runtime-config-load-write. تتم حماية الإضافات المضمّنة وكود وقت تشغيل المستودع بواسطة حواجز الماسح في pnpm check:deprecated-api-usage و pnpm check:no-runtime-action-load-config: يفشل استخدام إضافات الإنتاج الجديد مباشرةً، وتفشل كتابات الإعدادات المباشرة، ويجب أن تستخدم طرق خادم Gateway لقطة وقت تشغيل الطلب، ويجب أن تتلقى مساعدات إرسال/إجراء/عميل قناة وقت التشغيل الإعدادات من حدودها، ولا يُسمح لوحدات وقت التشغيل طويلة العمر بأي استدعاءات loadConfig() محيطة.ينبغي لكود الإضافة الجديد أيضًا تجنب استيراد برميل التوافق الواسع openclaw/plugin-sdk/config-runtime. استخدم مسار SDK الفرعي الضيق الذي يطابق المهمة:تتم حماية الإضافات المضمّنة واختباراتها بالماسح ضد البرميل الواسع بحيث تبقى الاستيرادات والمحاكيات محلية للسلوك الذي تحتاجه. لا يزال البرميل الواسع موجودًا للتوافق الخارجي، لكن لا ينبغي للكود الجديد الاعتماد عليه.
2

ترحيل امتدادات نتائج الأدوات المضمّنة إلى وسيط

يجب على الإضافات المضمّنة استبدال معالجات نتائج الأدوات الخاصة بالمشغّل المضمّن فقط api.registerEmbeddedExtensionFactory(...) بوسيط محايد لوقت التشغيل.
حدّث manifest الإضافة في الوقت نفسه:
يمكن للإضافات المثبّتة أيضًا تسجيل وسيط نتائج الأدوات عندما تكون مفعّلة صراحةً وتعلن كل وقت تشغيل مستهدف في contracts.agentToolResultMiddleware. تُرفض تسجيلات الوسيط المثبّتة غير المعلنة.
3

ترحيل معالجات الموافقة الأصلية إلى حقائق الإمكانات

تعرض إضافات القنوات القادرة على الموافقة الآن سلوك الموافقة الأصلي عبر approvalCapability.nativeRuntime بالإضافة إلى سجل سياق وقت التشغيل المشترك.التغييرات الرئيسية:
  • استبدل approvalCapability.handler.loadRuntime(...) بـ approvalCapability.nativeRuntime
  • انقل المصادقة/التسليم الخاصين بالموافقة من توصيلات plugin.auth / plugin.approvals القديمة إلى approvalCapability
  • تمت إزالة ChannelPlugin.approvals من عقد إضافة القناة العام؛ انقل حقول التسليم/الأصلي/العرض إلى approvalCapability
  • يبقى plugin.auth لتدفقات تسجيل الدخول/الخروج للقناة فقط؛ لم تعد النواة تقرأ خطافات مصادقة الموافقة هناك
  • سجّل كائنات وقت التشغيل المملوكة للقناة مثل العملاء أو الرموز أو تطبيقات Bolt عبر openclaw/plugin-sdk/channel-runtime-context
  • لا ترسل إشعارات إعادة التوجيه المملوكة للإضافة من معالجات الموافقة الأصلية؛ تملك النواة الآن إشعارات التوجيه إلى مكان آخر من نتائج التسليم الفعلية
  • عند تمرير channelRuntime إلى createChannelManager(...)، قدّم سطح createPluginRuntime().channel حقيقيًا. تُرفض الجذوع الجزئية.
راجع /plugins/sdk-channel-plugins للتخطيط الحالي لإمكانات الموافقة.
4

تدقيق سلوك الرجوع الاحتياطي لمغلّف Windows

إذا كانت إضافتك تستخدم openclaw/plugin-sdk/windows-spawn، فإن مغلّفات Windows .cmd/.bat غير المحلولة تفشل الآن بشكل مغلق ما لم تمرر صراحةً allowShellFallback: true.
إذا لم يكن المستدعي لديك يعتمد عمدًا على الرجوع الاحتياطي عبر الصدفة، فلا تضبط allowShellFallback وتعامل مع الخطأ المرمى بدلًا من ذلك.
5

العثور على الاستيرادات الموقوفة تدريجيًا

ابحث في إضافتك عن الاستيرادات من أي من السطحين الموقوفين تدريجيًا:
6

استبدالها باستيرادات مركّزة

يطابق كل تصدير من السطح القديم مسار استيراد حديثًا محددًا:
بالنسبة إلى مساعدات جانب المضيف، استخدم وقت تشغيل الإضافة المحقون بدلًا من الاستيراد مباشرةً:
ينطبق النمط نفسه على مساعدات الجسر القديمة الأخرى:
7

استبدل استيرادات infra-runtime الواسعة

لا يزال openclaw/plugin-sdk/infra-runtime موجودًا للتوافق الخارجي، لكن ينبغي للكود الجديد أن يستورد سطح المساعدات المركّز الذي يحتاجه فعليًا:تخضع Plugins المضمّنة لحراسة الماسح ضد infra-runtime، لذلك لا يمكن لكود المستودع أن يتراجع إلى البرميل الواسع.
8

رحّل مساعدات مسارات القنوات

ينبغي لكود مسارات القنوات الجديد استخدام openclaw/plugin-sdk/channel-route. تظل أسماء مفتاح المسار والهدف القابل للمقارنة الأقدم موجودة كأسماء مستعارة للتوافق أثناء نافذة الترحيل، لكن ينبغي للـ Plugins الجديدة استخدام أسماء المسارات التي تصف السلوك مباشرةً:تقوم مساعدات المسارات الحديثة بتطبيع { channel, to, accountId, threadId } بشكل متسق عبر الموافقات الأصلية، وكبت الردود، وإزالة تكرار الوارد، وتسليم cron، وتوجيه الجلسات.لا تضف استخدامات جديدة لـ ChannelMessagingAdapter.parseExplicitTarget أو مساعدات المسارات المحمّلة المدعومة بالمحلل (parseExplicitTargetForLoadedChannel أو resolveRouteTargetForLoadedChannel) أو resolveChannelRouteTargetWithParser(...) من plugin-sdk/channel-route. هذه الخطافات مهملة وتبقى فقط للـ Plugins الأقدم أثناء نافذة الترحيل. ينبغي للـ Plugins القنوات الجديدة استخدام messaging.targetResolver.resolveTarget(...) لتطبيع معرّف الهدف والرجوع عند فقدان الدليل، وmessaging.inferTargetChatType(...) عندما يحتاج core إلى نوع نظير مبكر، وmessaging.resolveOutboundSessionRoute(...) لهوية الجلسة وسلسلة الرسائل الأصلية للمزوّد.
9

ابنِ واختبر

مرجع مسارات الاستيراد

هذا الجدول هو عمدا مجموعة الترحيل المشتركة، وليس سطح SDK الكامل. يوجد مخزون نقطة دخول المصرّف في scripts/lib/plugin-sdk-entrypoints.json؛ وتُولَّد صادرات الحزمة من المجموعة الفرعية العامة. أُحيلت وصلات مساعد Plugin المضمّن المحجوزة إلى التقاعد من خريطة تصدير SDK العامة، باستثناء واجهات التوافق الموثقة صراحة مثل طبقة التوافق المهملة plugin-sdk/discord المحتفظ بها لحزمة @openclaw/discord@2026.3.13 المنشورة. توجد المساعدات الخاصة بالمالك داخل حزمة Plugin المالكة؛ وينبغي أن ينتقل سلوك المضيف المشترك عبر عقود SDK العامة مثل plugin-sdk/gateway-runtime وplugin-sdk/security-runtime وplugin-sdk/plugin-config-runtime. استخدم أضيق استيراد يطابق المهمة. إذا لم تتمكن من العثور على تصدير، فافحص المصدر في src/plugin-sdk/ أو اسأل المشرفين أي عقد عام ينبغي أن يملكه.

الإهمالات النشطة

إهمالات أضيق تنطبق عبر SDK الخاص بـ Plugin، وعقد المزوّد، وسطح وقت التشغيل، والبيان. كل واحد منها ما زال يعمل اليوم، لكنه سيُزال في إصدار رئيسي مستقبلي. يربط الإدخال أسفل كل عنصر 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 }) - يعيد كائن قرار واحدا بدلا من استدعاءين منفصلين.انتقلت Plugins القنوات اللاحقة (Slack وDiscord وMatrix وMS Teams) بالفعل.
openclaw/plugin-sdk/channel-runtime هي طبقة توافق Plugins القنوات الأقدم. لا تستوردها من كود جديد؛ استخدم openclaw/plugin-sdk/channel-runtime-context لتسجيل كائنات وقت التشغيل.مساعدات channelActions* في openclaw/plugin-sdk/channel-actions مهملة إلى جانب صادرات القناة الخام “actions”. اكشف القدرات عبر سطح presentation الدلالي بدلا من ذلك - تصرّح Plugins القنوات بما تعرضه (بطاقات، أزرار، قوائم اختيار) بدلا من أسماء الإجراءات الخام التي تقبلها.
القديم: مصنع tool() من openclaw/plugin-sdk/provider-web-search.الجديد: نفّذ createTool(...) مباشرة على Plugin المزوّد. لم يعد OpenClaw بحاجة إلى مساعد SDK لتسجيل غلاف الأداة.
القديم: formatInboundEnvelope(...)ChannelMessageForAgent.channelEnvelope) لبناء مظروف موجّه نصي مسطح من رسائل القناة الواردة.الجديد: BodyForAgent إضافة إلى كتل سياق مستخدم مهيكلة. ترفق Plugins القنوات بيانات تعريف التوجيه (المحادثة، الموضوع، الرد على، التفاعلات) كحقول ذات أنواع بدلا من دمجها في سلسلة موجّه. ما زال مساعد formatAgentEnvelope(...) مدعوما للمظاريف المصطنعة المواجهة للمساعد، لكن المظاريف النصية الواردة في طريقها إلى الإزالة.المناطق المتأثرة: inbound_claim وmessage_received وأي Plugin قناة مخصص كان يعالج نص channelEnvelope لاحقا.
القديم: api.on("deactivate", handler).الجديد: api.on("gateway_stop", handler). الحدث والسياق هما عقد تنظيف إيقاف التشغيل نفسه؛ يتغير اسم الخطاف فقط.
يبقى deactivate موصولا كاسم بديل توافقـي مهمل إلى ما بعد 2026-08-16.
القديم: api.on("subagent_spawning", handler) يعيد threadBindingReady أو deliveryOrigin.الجديد: دع النواة تجهز روابط الوكيل الفرعي thread: true عبر محوّل ربط جلسة القناة. استخدم api.on("subagent_spawned", handler) فقط للمراقبة بعد الإطلاق.
تبقى subagent_spawning وPluginHookSubagentSpawningEvent وPluginHookSubagentSpawningResult و SubagentLifecycleHookRunner.runSubagentSpawning(...) كأسطح توافقية مهملة فقط أثناء ترحيل Plugins الخارجية.
أصبحت أربعة أسماء مستعارة لأنواع الاكتشاف أغلفة رقيقة فوق أنواع عصر الكتالوج:إضافة إلى حاوية ProviderCapabilities الثابتة القديمة - ينبغي أن تستخدم Plugins المزوّد خطافات مزوّد صريحة مثل buildReplayPolicy وnormalizeToolSchemas وwrapStreamFn بدلا من كائن ثابت.
القديم (ثلاثة خطافات منفصلة على ProviderThinkingPolicy): isBinaryThinking(ctx) وsupportsXHighThinking(ctx) و resolveDefaultThinkingLevel(ctx).الجديد: resolveThinkingProfile(ctx) واحد يعيد ProviderThinkingProfile مع id المعياري، وlabel اختياري، وقائمة مستويات مرتبة. يخفض OpenClaw القيم المخزنة القديمة تلقائيا حسب رتبة الملف الشخصي.يتضمن السياق provider وmodelId وreasoning المدمج الاختياري، وحقائق compat للنموذج المدمجة الاختيارية. يمكن أن تستخدم Plugins المزوّد حقائق الكتالوج هذه لكشف ملف شخصي خاص بالنموذج فقط عندما يدعم عقد الطلب المكوّن ذلك.نفّذ خطافا واحدا بدلا من ثلاثة. تستمر الخطافات القديمة في العمل أثناء نافذة الإهمال، لكنها لا تُركّب مع نتيجة الملف الشخصي.
القديم: تنفيذ خطافات مصادقة خارجية من دون التصريح بالمزوّد في بيان Plugin.الجديد: صرّح بـ contracts.externalAuthProviders في بيان Plugin و نفّذ resolveExternalAuthProfiles(...).
حقل البيان القديم: providerAuthEnvVars: { anthropic: ["ANTHROPIC_API_KEY"] }.الجديد: اعكس بحث متغير البيئة نفسه في setup.providers[].envVars على البيان. يدمج هذا بيانات تعريف بيئة الإعداد/الحالة في مكان واحد ويتجنب تشغيل وقت تشغيل Plugin لمجرد الإجابة عن عمليات بحث متغيرات البيئة.يبقى providerAuthEnvVars مدعوما عبر محوّل توافق إلى أن تُغلق نافذة الإهمال.
القديم: ثلاثة استدعاءات منفصلة - api.registerMemoryPromptSection(...), api.registerMemoryFlushPlan(...), api.registerMemoryRuntime(...).الجديد: استدعاء واحد على API حالة الذاكرة - registerMemoryCapability(pluginId, { promptBuilder, flushPlanResolver, runtime }).الخانات نفسها، واستدعاء تسجيل واحد. لا تتأثر مساعدات الموجّه والمتن الإضافية (registerMemoryPromptSupplement وregisterMemoryCorpusSupplement).
القديم: api.registerMemoryEmbeddingProvider(...) إضافة إلى contracts.memoryEmbeddingProviders.الجديد: api.registerEmbeddingProvider(...) إضافة إلى contracts.embeddingProviders.عقد مزوّد التضمين العام قابل لإعادة الاستخدام خارج الذاكرة، وهو المسار المدعوم للمزوّدين الجدد. تبقى API التسجيل الخاصة بالذاكرة موصولة كتوافق مهمل أثناء ترحيل المزوّدين الحاليين. تبلغ تقارير فحص Plugin عن الاستخدام غير المضمّن باعتباره دينا توافقيا.
اسمان مستعاران قديمان للأنواع ما زالا مصدّرين من src/plugins/runtime/types.ts:طريقة وقت التشغيل readSession مهملة لصالح getSessionMessages. التوقيع نفسه؛ تستدعي الطريقة القديمة الطريقة الجديدة.
القديم: كان runtime.tasks.flow (بصيغة المفرد) يعيد موصل TaskFlow حيا.الجديد: يحتفظ runtime.tasks.managedFlows بوقت تشغيل طفرات TaskFlow المدارة من أجل Plugins التي تنشئ أو تحدث أو تلغي أو تشغل مهام فرعية من تدفق. استخدم runtime.tasks.flows عندما يحتاج Plugin فقط إلى قراءات مبنية على DTO.
مغطى في “كيفية الترحيل → رحّل إضافات نتائج الأدوات المضمّنة إلى وسيط” أعلاه. أُدرج هنا للاكتمال: مسار api.registerEmbeddedExtensionFactory(...) المحذوف والخاص بمشغّل التضمين فقط استُبدل بـ api.registerAgentToolResultMiddleware(...) مع قائمة وقت تشغيل صريحة في contracts.agentToolResultMiddleware.
أصبح OpenClawSchemaType المعاد تصديره من openclaw/plugin-sdk اسما مستعارا من سطر واحد لـ OpenClawConfig. فضّل الاسم المعياري.
تُتتبع الإهمالات على مستوى الإضافة (داخل Plugins القنوات/المزوّدين المضمّنة تحت extensions/) داخل براميل api.ts وruntime-api.ts الخاصة بها. لا تؤثر في عقود Plugins التابعة لجهات خارجية، ولا تُدرج هنا. إذا كنت تستهلك برميل Plugin مضمّن المحلي مباشرة، فاقرأ تعليقات الإهمال في ذلك البرميل قبل الترقية.

الجدول الزمني للإزالة

تم ترحيل كل plugins الأساسية بالفعل. ينبغي أن ترحّل plugins الخارجية قبل الإصدار الرئيسي التالي.

إيقاف التحذيرات مؤقتًا

اضبط متغيرات البيئة هذه أثناء العمل على الترحيل:
هذا مسار مؤقت لتجاوز المشكلة، وليس حلًا دائمًا.

ذات صلة