الانتقال إلى المحتوى الرئيسي
تهدف حزمة QA الخاصة إلى اختبار OpenClaw بطريقة أكثر واقعية ومشابهة لشكل القنوات مما يمكن لاختبار وحدة واحد أن يقدمه. المكونات الحالية:
  • extensions/qa-channel: قناة رسائل اصطناعية مع أسطح للرسائل المباشرة، والقنوات، والخيوط، والتفاعلات، والتعديل، والحذف.
  • extensions/qa-lab: واجهة مستخدم للتصحيح وناقل QA لمراقبة النص المفرغ، وحقن الرسائل الواردة، وتصدير تقرير Markdown.
  • qa/: أصول بذور مدعومة بالمستودع لمهمة الانطلاق وسيناريوهات QA الأساسية.
تدفق مشغل QA الحالي هو موقع QA ذي لوحتين:
  • اليسار: لوحة معلومات Gateway (واجهة التحكم) مع الوكيل.
  • اليمين: QA Lab، ويعرض نصًا مفرغًا على نمط Slack وخطة السيناريو.
شغّله باستخدام: 
pnpm qa:lab:up
سيؤدي ذلك إلى بناء موقع QA، وبدء مسار gateway مدعوم بـ Docker، وكشف صفحة QA Lab حيث يمكن لمشغّل أو لحلقة أتمتة إعطاء الوكيل مهمة QA، ومراقبة سلوك القناة الحقيقي، وتسجيل ما نجح، أو فشل، أو بقي محجوبًا. للتكرار الأسرع على واجهة QA Lab من دون إعادة بناء صورة Docker في كل مرة، ابدأ الحزمة مع حزمة QA Lab مركّبة عبر bind mount: 
pnpm openclaw qa docker-build-image
pnpm qa:lab:build
pnpm qa:lab:up:fast
pnpm qa:lab:watch
يحافظ qa:lab:up:fast على خدمات Docker على صورة مبنية مسبقًا ويركّب عبر bind mount extensions/qa-lab/web/dist داخل حاوية qa-lab. ويعيد qa:lab:watch بناء هذه الحزمة عند التغيير، ويعيد المتصفح التحميل تلقائيًا عندما تتغير قيمة تجزئة أصول QA Lab. لتشغيل مسار smoke حقيقي للنقل عبر Matrix، شغّل: 
pnpm openclaw qa matrix
يقوم هذا المسار بتجهيز homeserver مؤقت من Tuwunel داخل Docker، ويسجّل مستخدمين مؤقتين للسائق، وSUT، والمراقب، وينشئ غرفة خاصة واحدة، ثم يشغّل Plugin Matrix الحقيقي داخل child تابع لـ QA gateway. ويحافظ مسار النقل الحي على إعداد child محصورًا في النقل قيد الاختبار، بحيث يعمل Matrix من دون qa-channel في إعداد child. ويكتب عناصر التقرير المنظمة وسجلًا مدمجًا لـ stdout/stderr داخل دليل إخراج Matrix QA المحدد. ولالتقاط خرج البناء/المشغّل الخارجي scripts/run-node.mjs أيضًا، اضبط OPENCLAW_RUN_NODE_OUTPUT_LOG=<path> على ملف سجل محلي ضمن المستودع. لتشغيل مسار smoke حقيقي للنقل عبر Telegram، شغّل: 
pnpm openclaw qa telegram
يستهدف هذا المسار مجموعة Telegram خاصة حقيقية واحدة بدلًا من تجهيز خادم مؤقت. ويتطلب OPENCLAW_QA_TELEGRAM_GROUP_ID, وOPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN, و OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN، بالإضافة إلى بوتين مختلفين داخل المجموعة الخاصة نفسها. ويجب أن يمتلك بوت SUT اسم مستخدم Telegram، وتعمل المراقبة بين البوتات بأفضل شكل عندما يكون لدى كلا البوتين Bot-to-Bot Communication Mode مفعّلًا في @BotFather. ينهي الأمر التنفيذ برمز غير صفري عند فشل أي سيناريو. استخدم --allow-failures عندما تريد العناصر الناتجة من دون رمز خروج فاشل. يتضمن تقرير Telegram وملخصه قيمة RTT لكل رد من طلب إرسال رسالة السائق حتى الرد الملحوظ من SUT، بدءًا من canary. لتشغيل مسار smoke حقيقي للنقل عبر Discord، شغّل: 
pnpm openclaw qa discord
يستهدف هذا المسار قناة guild خاصة حقيقية واحدة في Discord مع بوتين: بوت سائق يتحكم فيه الـ harness وبوت SUT يبدأه child التابع لـ OpenClaw gateway عبر Plugin Discord المضمّن. ويتطلب OPENCLAW_QA_DISCORD_GUILD_ID, وOPENCLAW_QA_DISCORD_CHANNEL_ID, وOPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN, وOPENCLAW_QA_DISCORD_SUT_BOT_TOKEN, وOPENCLAW_QA_DISCORD_SUT_APPLICATION_ID عند استخدام بيانات اعتماد البيئة. ويتحقق المسار من التعامل مع الإشارات في القناة ويتأكد من أن بوت SUT قد سجّل الأمر الأصلي /help لدى Discord. ينهي الأمر التنفيذ برمز غير صفري عند فشل أي سيناريو. استخدم --allow-failures عندما تريد العناصر الناتجة من دون رمز خروج فاشل. تشترك مسارات النقل الحية الآن في عقد أصغر واحد بدلًا من أن يخترع كل منها شكله الخاص لقائمة السيناريوهات: يبقى qa-channel مجموعة واسعة من سلوك المنتج الاصطناعي وليس جزءًا من مصفوفة تغطية النقل الحي.
المسارCanaryضبط الإشارةحظر allowlistرد على المستوى الأعلىاستئناف بعد إعادة التشغيلمتابعة الخيطعزل الخيطمراقبة التفاعلاتأمر helpتسجيل الأوامر الأصلية
Matrixxxxxxxxx
Telegramxxx
Discordxxx
يبقي هذا qa-channel كمجموعة واسعة لسلوك المنتج، بينما تشترك Matrix وTelegram ووسائط النقل الحية المستقبلية في قائمة تحقق صريحة واحدة لعقد النقل. لتشغيل مسار Linux VM مؤقت من دون إدخال Docker في مسار QA، شغّل: 
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
يقوم هذا بتشغيل guest جديد في Multipass، وتثبيت التبعيات، وبناء OpenClaw داخل guest، وتشغيل qa suite، ثم نسخ تقرير QA العادي والملخص إلى .artifacts/qa-e2e/... على المضيف. ويعيد استخدام سلوك اختيار السيناريو نفسه الخاص بـ qa suite على المضيف. تنفذ عمليات suite على المضيف وMultipass عدة سيناريوهات محددة بالتوازي مع عمّال gateway معزولين افتراضيًا. ويستخدم qa-channel قيمة توازٍ افتراضية قدرها 4، مع حد أقصى بعدد السيناريوهات المحددة. استخدم --concurrency <count> لضبط عدد العمال، أو --concurrency 1 للتنفيذ التسلسلي. ينهي الأمر التنفيذ برمز غير صفري عند فشل أي سيناريو. استخدم --allow-failures عندما تريد العناصر الناتجة من دون رمز خروج فاشل. تُمرِّر التشغيلات الحية مدخلات مصادقة QA المدعومة التي تكون عملية بالنسبة إلى الـ guest: مفاتيح المزوّد القائمة على البيئة، ومسار إعداد مزوّد QA الحي، وCODEX_HOME عند وجوده. أبقِ --output-dir تحت جذر المستودع بحيث يتمكن الـ guest من الكتابة مرة أخرى عبر مساحة العمل المركّبة.

​
بذور مدعومة بالمستودع

توجد أصول البذور في qa/:
  • qa/scenarios/index.md
  • qa/scenarios/<theme>/*.md
وُضعت هذه في git عمدًا بحيث تكون خطة QA مرئية لكل من البشر والوكيل. يجب أن يبقى qa-lab مشغّل Markdown عامًا. وكل ملف Markdown خاص بالسيناريو هو مصدر الحقيقة لتشغيل اختبار واحد ويجب أن يعرّف:
  • بيانات وصفية للسيناريو
  • بيانات وصفية اختيارية للفئة، والإمكانات، والمسار، والمخاطر
  • مراجع الوثائق والشيفرة
  • متطلبات Plugin اختيارية
  • تصحيح إعداد Gateway اختياري
  • qa-flow القابل للتنفيذ
يُسمح لسطح وقت التشغيل القابل لإعادة الاستخدام الذي يدعم qa-flow أن يبقى عامًا وعابرًا للجوانب. على سبيل المثال، يمكن لسيناريوهات Markdown أن تجمع بين مساعدات جانب النقل ومساعدات جانب المتصفح التي تقود واجهة التحكم المضمنة عبر وصلة Gateway ‏browser.request من دون إضافة مشغّل بحالة خاصة. يجب تجميع ملفات السيناريو حسب إمكانات المنتج بدلًا من مجلد شجرة المصدر. حافظ على استقرار معرّفات السيناريو عند نقل الملفات؛ واستخدم docsRefs وcodeRefs لإمكانية التتبع على مستوى التنفيذ. يجب أن تبقى القائمة الأساسية واسعة بما يكفي لتغطية:
  • الدردشة في الرسائل المباشرة والقنوات
  • سلوك الخيوط
  • دورة حياة إجراءات الرسائل
  • استدعاءات Cron
  • استدعاء الذاكرة
  • تبديل النماذج
  • تسليم إلى وكيل فرعي
  • قراءة المستودع وقراءة الوثائق
  • مهمة بناء صغيرة واحدة مثل Lobster Invaders

​
مسارات محاكاة المزوّد

يحتوي qa suite على مساري محاكاة محليين للمزوّد:
  • mock-openai هو محاكي OpenClaw الواعي بالسيناريو. ويبقى مسار المحاكاة الحتمي الافتراضي لـ QA المدعوم بالمستودع وبوابات التكافؤ.
  • يبدأ aimock خادم مزوّد مدعومًا بـ AIMock لتغطية تجريبية للبروتوكول، والتهيئة، والتسجيل/إعادة التشغيل، والفوضى. وهو إضافة ولا يستبدل موزّع السيناريو mock-openai.
يوجد تنفيذ مسار المزوّد تحت extensions/qa-lab/src/providers/. ويمتلك كل مزوّد إعداداته الافتراضية، وبدء الخادم المحلي، وإعداد نموذج gateway، واحتياجات تجهيز ملف تعريف المصادقة، وأعلام الإمكانات الحية/الوهمية. ويجب أن يوجّه code suite وgateway المشترك عبر سجل المزوّدين بدلًا من التفرع حسب أسماء المزوّدين.

​
محولات النقل

يمتلك qa-lab وصلة نقل عامة لسيناريوهات QA في Markdown. ويُعد qa-channel أول محول على هذه الوصلة، لكن هدف التصميم أوسع: يجب أن تتصل القنوات المستقبلية، الحقيقية أو الاصطناعية، بمشغّل suite نفسه بدلًا من إضافة مشغّل QA خاص بالنقل. على مستوى البنية، يكون التقسيم كما يلي:
  • يمتلك qa-lab تنفيذ السيناريو العام، وتوازي العمال، وكتابة العناصر الناتجة، وإعداد التقارير.
  • يمتلك محول النقل إعداد Gateway، والجاهزية، ومراقبة الإدخال والإخراج، وإجراءات النقل، وحالة النقل الموحّدة.
  • تحدد ملفات سيناريو Markdown تحت qa/scenarios/ تشغيل الاختبار؛ بينما يوفر qa-lab سطح وقت التشغيل القابل لإعادة الاستخدام الذي ينفذها.
يوجد دليل الاعتماد الموجّه للمشرفين لمحولات القنوات الجديدة في الاختبار.

​
إعداد التقارير

يصدر qa-lab تقرير بروتوكول Markdown من الخط الزمني المرصود للناقل. ويجب أن يجيب التقرير عن:
  • ما الذي نجح
  • ما الذي فشل
  • ما الذي بقي محجوبًا
  • ما السيناريوهات اللاحقة الجديرة بالإضافة
بالنسبة إلى فحوصات الشخصية والأسلوب، شغّل السيناريو نفسه عبر عدة مراجع نماذج حية واكتب تقرير Markdown محكّمًا: 
pnpm openclaw qa character-eval \
  --model openai/gpt-5.4,thinking=medium,fast \
  --model openai/gpt-5.2,thinking=xhigh \
  --model openai/gpt-5,thinking=xhigh \
  --model anthropic/claude-opus-4-6,thinking=high \
  --model anthropic/claude-sonnet-4-6,thinking=high \
  --model zai/glm-5.1,thinking=high \
  --model moonshot/kimi-k2.5,thinking=high \
  --model google/gemini-3.1-pro-preview,thinking=high \
  --judge-model openai/gpt-5.4,thinking=xhigh,fast \
  --judge-model anthropic/claude-opus-4-6,thinking=high \
  --blind-judge-models \
  --concurrency 16 \
  --judge-concurrency 16
يشغّل الأمر عمليات child محلية لـ QA gateway، وليس Docker. ويجب أن تضبط سيناريوهات تقييم الشخصية persona عبر SOUL.md، ثم تشغّل أدوار مستخدم عادية مثل الدردشة، والمساعدة في مساحة العمل، ومهام الملفات الصغيرة. ويجب ألا يُخبَر النموذج المرشح بأنه قيد التقييم. ويحافظ الأمر على كل نص مفرغ كامل، ويسجّل إحصاءات تشغيل أساسية، ثم يطلب من نماذج التحكيم في الوضع السريع مع استدلال xhigh عند الدعم أن ترتب التشغيلات حسب الطبيعية، والإحساس، والفكاهة. استخدم --blind-judge-models عند مقارنة المزوّدين: فما تزال مطالبة التحكيم تحصل على كل نص مفرغ وحالة تشغيل، لكن يتم استبدال مراجع المرشحين بتسميات محايدة مثل candidate-01؛ ويعيد التقرير ربط التصنيفات بالمراجع الحقيقية بعد التحليل. تستخدم تشغيلات المرشحين افتراضيًا مستوى التفكير high، مع medium لـ GPT-5.4 وxhigh لمراجع تقييم OpenAI الأقدم التي تدعمه. ويمكنك تجاوز مرشح محدد ضمنيًا باستخدام --model provider/model,thinking=<level>. وما يزال --thinking <level> يضبط قيمة رجوع عامة، كما تم الإبقاء على الصيغة الأقدم --model-thinking <provider/model=level> للتوافق. تستخدم مراجع مرشحي OpenAI افتراضيًا الوضع السريع بحيث تُستخدم المعالجة ذات الأولوية عند دعم المزوّد لذلك. أضف ,fast أو ,no-fast أو ,fast=false ضمنيًا عندما يحتاج مرشح واحد أو حكم واحد إلى تجاوز. ومرر --fast فقط عندما تريد فرض الوضع السريع على كل نموذج مرشح. ويتم تسجيل مدد المرشحين والحكام في التقرير لتحليل القياس المرجعي، لكن مطالبات التحكيم تنص صراحةً على عدم الترتيب حسب السرعة. تستخدم تشغيلات نماذج المرشحين والحكام كلاهما قيمة توازٍ افتراضية قدرها 16. اخفض --concurrency أو --judge-concurrency عندما تجعل حدود المزوّد أو ضغط gateway المحلي التشغيل صاخبًا جدًا. عند عدم تمرير أي --model للمرشح، يستخدم تقييم الشخصية افتراضيًا openai/gpt-5.4 وopenai/gpt-5.2 وopenai/gpt-5 وanthropic/claude-opus-4-6, وanthropic/claude-sonnet-4-6 وzai/glm-5.1, وmoonshot/kimi-k2.5، و google/gemini-3.1-pro-preview عندما لا يتم تمرير --model. وعند عدم تمرير --judge-model، يستخدم الحكام افتراضيًا openai/gpt-5.4,thinking=xhigh,fast و anthropic/claude-opus-4-6,thinking=high.

​
وثائق ذات صلة