كيمي ك3 في OpenClaw مقابل dsh: 5/5 مهام، أبطأ بـ 9 مرات، وتكلفة أعلى بـ 48 مرة.

لقد وجهت وكيل العمل OpenClaw نحو نموذج Kimi K3، وهو النموذج الرئيسي للاستدلال من شركة Moonshot، ثم قمت بتشغيله على نفس المهام البرمجية الخمس الصغيرة التي استخدمتها في أغسطس لاختبار DeepSeek Harness (dsh). نجح Kimi في تنفيذ جميع المهام. وفي نفس اليوم، أعدت تشغيل dsh على DeepSeek V4-Flash مرتين؛ مقارنةً بالمرة الثانية (عندما كان الكاش ساخنًا)، استغرق Kimi وقتًا أطول بحوالي 9 مرات (309.9 ثانية مقابل 35.7 ثانية) وتكلف أكثر بحوالي 48 مرة ($0.531 مقابل $0.011). أما مقارنةً بالمرة الأولى عندما كان الكاش باردًا (44.8 ثانية، $0.024)، فإن الفارق في الوقت يبلغ حوالي 7 مرات وفي التكلفة حوالي 22 مرة.

بعد ذلك، قدمت لـ Kimi موجز شعار بأسلوب الرسومات البكسلية الذي استخدمه dsh في إنشاء ويدجت خاص به. احتاج Kimi إلى ثلاث محاولات؛ المحاولة الأولى لم تؤدِ إلى أي ويدجت، والثانية أنتجت ويدجت كاملًا من 323 سطرًا لكن في مجلد خاطئ، وتوقفت قبل أن يُعلن عن ذلك بسبب انتهاء مدة التشغيل المسموح بها، لذا لم ألاحظ ذلك في البداية. أما المحاولة الثالثة فنجحت بعد أن قصرت التعليمات وأمرته بتخطي مرحلة التخطيط؛ الويدجت الموجود أدناه هو نتيجة تلك المحاولة، والخطأ في إعدادات التكوين في الخطوة الثانية هو الجزء الأكثر قيمة للاستفادة منه.

الإعدادات: على أي نظام قمت بتشغيله

هذه هي الأوامر التي نفذتها على جهازي في تاريخ 2026-09-11، مع مخرجاتها الفعلية:

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2
$ openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'
{"id":"moonshot","enabled":true,"version":"2026.9.2"}
$ openclaw config get models.providers.moonshot.models.0.compat
{
  "supportsReasoningEffort": true,
  "supportsTemperature": false,
  "supportedReasoningEfforts": [
    "low",
    "high",
    "max"
  ]
}
$ openclaw config get models.providers.moonshot.models.0.contextTokens
262144

هناك أمران يجب معرفتهما قبل تشغيل أي شيء:

• K3 يقوم دائمًا بالتفكير المنطقي. يقوم المكون الإضافي بإرسال reasoning_effort: "max" بشكل افتراضي، كما يقبل القيم low وhigh وmax؛ لقد استخدمت الخيار --thinking max أثناء تشغيل الاختبار. كما يقوم المكون الإضافي بإلغاء أي إعدادات للأخذة العشوائية مثل temperature وtop_p لأن K3 يحددها بنفسه، ويذكر إدخال النموذج الخاص بي نفس الشيء عبر خاصية supportsTemperature: false. حتى الأمر "أرجع بالنص التالي بالضبط: PONG." استهلك 53 رمزًا من رموز التفكير المنطقي، لذا احسب ذلك في ميزانية الموارد المستخدمة.
• يُعلن عن دعم سياق بسعة 1 مليون رمز؛ لكنني أحدده بحد أقصى. يذكر كتالوج Moonshot التابع لـ OpenClaw أن K3 يدعم سياقًا بسعة 1,048,576 رمزًا. لكنني حددت قيمة contextTokens: 262144 في إعدادات النموذج، حتى تُختصر الجلسات عند نفس النقطة التي تختصر عندها جلسات النماذج الأخرى لديّ. وبهذا الحد، ستكون السعة الفعلية المستخدمة 256 ألف رمز وليس مليونًا. إذا رفعتم هذا الحد، فإن تكلفة قراءة الذاكرة المؤقتة وتأخر الاستجابة لكل طلب سيزدادان حسب حجم الجلسة.

الخطوات، من الأساسية إلى المتقدمة

الخطوات من 1 إلى 3 تمنحك نموذجًا يعمل بشكل صحيح؛ أما الخطوتان 4 و5 فهي ما قمت به لاحقًا.

الخطوة الأولى: تثبيت المكون الإضافي وإدخال المفتاح

هذه هي الخطوات المذكورة في وثائق OpenClaw الرسمية. على جهازي، كان المكون الإضافي والمفتاح موجودين بالفعل، لذا قمت فقط بتنفيذ الأمر المذكور في السطر الأخير (وناتج تنفيذه موضح في كتلة الإعدادات أعلاه):

openclaw plugins install @openclaw/moonshot-provider
openclaw gateway restart
openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'

يقرأ المكون الإضافي المفتاح من متغير البيئة MOONSHOT_API_KEY. أنا أحفظ هذا المتغير في ملف إعدادات خدمة البوابة الخاصة بي، بينما لا يحتوي ملف openclaw.json على أي مفتاح. كما توفر الوثائق الأمر openclaw onboard --auth-choice moonshot-api-key إذا كنتم ترغبون في الحصول على إرشادات خطوة بخطوة. النقطة النهائية الافتراضية هي https://api.moonshot.ai/v1، بينما تستخدم منطقة الصين النقطة التالية: https://api.moonshot.cn/v1 (مع خيار المصادقة moonshot-api-key-cn).

<pيتضمن كتالوج المكون الإضافي نماذج K3، وK2.7 Code، وK2.7 Code HighSpeed. كما يتعامل المكون الإضافي مع الخصائص الفريدة لنموذج Kimi تلقائيًا؛ فنموذج K2.7 يتطلب حذف كل من المعلمتين thinking وreasoning_effort من طلباته، وهو ما يقوم به المكون الإضافي بالفعل. انتبهوا إلى أسماء متغيرات البيئة؛ فـ MOONSHOT_API_KEY يخص منصة Moonshot Open Platform، بينما ينتمي KIMI_API_KEY إلى خدمة Kimi Code المستقلة (kimi/kimi-for-coding).

الخطوة الثانية: وجه وكيل العمل الخاص بك نحو K3

الأجزاء ذات الصلة من ملف openclaw.json الخاص بي أثناء الاختبار، حيث تم تغيير اسم وكيل العمل إلى worker:

{
  agents: {
    entries: {
      worker: {
        model: {
          primary: "moonshot/kimi-k3",
          fallbacks: ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"],
        },
      },
    },
  },
  models: {
    providers: {
      moonshot: {
        baseUrl: "https://api.moonshot.ai/v1",
        api: "openai-completions",
        timeoutSeconds: 1200,
        models: [
          {
            id: "kimi-k3",
            name: "Kimi K3",
            reasoning: true,
            input: ["text", "image"],
            cost: { input: 3, output: 15, cacheRead: 0.3, cacheWrite: 0 },
            contextWindow: 1048576,
            maxTokens: 131072,
            contextTokens: 262144,
            compat: {
              supportsTemperature: false,
              supportsReasoningEffort: true,
              supportedReasoningEfforts: ["low", "high", "max"],
            },
          },
        ],
      },
    },
  },
}

هناك خطأ كاد أن يتسبب في مشكلة: في إصدار OpenClaw 2026.9.2، يقوم الكتل النصية من نوع compat الموجودة في إدخال النموذج بـ استبدال كائن compat الخاص بالإضافة نفسها، دون دمجه معه. كان هناك إصدار سابق من إدخالي يحتوي فقط على supportsTemperature: false، وهو ما أدى إلى إلغاء دعم الإضافة لخاصية reasoning-effort بشكل صامت. لذا، إذا كتبت أي قيمة في حقل compat، فعليك كتابة الكائن بأكمله، كما هو موضح أعلاه.

الخطوة الثالثة: اختبار التحقق، والبيانات بتنسيق JSON التي يُعيدها

كانت كل مهمة من مهام الاختبار عبارة عن استدعاء واحد من هذا النوع، مع استخدام مفتاح جلسة جديد في كل مرة:

openclaw agent --agent <your-agent-id> --model moonshot/kimi-k3 --thinking max \
  --session-key "<fresh-key>" --message-file prompt.txt --json > out.json

فيما يلي الحقول المهمة، المستخرجة من بيانات الاختبار الخاصة بمهمة PONG:

$ jq '.result | {harness: .meta.agentMeta.agentHarnessId, model: .meta.executionTrace.winnerModel, usage: .meta.agentMeta.usage}' out.json
{
  "harness": "openclaw",
  "model": "kimi-k3",
  "usage": {
    "input": 15068,
    "output": 70,
    "reasoningTokens": 53,
    "total": 15138,
    "cost": {
      "total": 0.046254
    }
  }
}

harness: "openclaw" يعني أن العملية تمت داخل حلقة التشغيل الخاصة بـ OpenClaw؛ أما إذا تمت العملية عبر خادم تطبيقات Codex، فإن القيمة ستكون "codex". winnerModel: "kimi-k3" يخبرنا أن العملية تمت فعلاً على نموذج K3 ولم يتم اللجوء إلى نموذج أقل تكلفة. reasoningTokens يتم حسابها ضمن output (المجموع هو مجموع الرموز المدخلة والخارجة)، لذا فإن الـ 53 رمزًا من نوع reasoningTokens هي جزء من المجموع الكلي البالغ 70.

المعيار: نفس المهام الخمس

هذه هي نفس المهام الخمس التي تم تنفيذها في مقال dsh؛ حيث تم تنفيذ كل مهمة في مجلد منفصل، مع بدء جلسة جديدة لكل مهمة باستخدام Kimi. أعدت تشغيل أداة dsh على نموذج V4-Flash في نفس اليوم، مع تحديد النموذج deepseek-v4-flash في ملف الإعدادات الخاص بالأداة. استغرقت الجلسة الأولى 44.8 ثانية وتكلفت 0.024 دولار، وذلك مع وجود ذاكرة تخزين مؤقت فارغة؛ أما العمود التالي في الجدول فيمثل الجلسة الثانية، وهي الأسرع والأقل تكلفة من بين جميع الجلسات التي قمت بتشغيلها، وهي القيمة المستخدمة في جميع الحسابات الواردة في هذا المقال ما لم يُذكر خلاف ذلك. صياغة الأوامر لم تكن متطابقة تمامًا؛ فأداة dsh تعمل في المجلد الذي يتم تشغيلها منه، لذا كانت أوامرها تشير إلى “المجلد الحالي”. أما أوامر Kimi فقد ذكرت المسار الكامل لمجلد كل مهمة، كما أن أمر تصحيح الأخطاء الخاص بـ Kimi تضمن جملة “إذا لم يكن برنامج pytest متاحًا، فقم بتثبيته أولاً باستخدام الأمر ‘pip install --user pytest’”؛ رغم أن برنامج pytest كان مثبتًا بالفعل، ولم يقم Kimi بتنفيذ أمر التثبيت أبدًا. أما أعمدة V4-Pro وGemma-4-26B فهي مستمدة من مقال dsh الذي نُشر في شهر أغسطس، ولم يتم إعادة تشغيلها. يشمل الوقت الإجمالي كامل عملية التنفيذ؛ وتأتي بيانات عدد الرموز الترويجية والتكلفة الخاصة بـ Kimi من ملف JSON الصادر عن OpenClaw، بينما تأتي بيانات dsh من سجل الجلسات الخاص بها.

المهمة	Kimi K3	dsh V4-Flash (في نفس اليوم)	dsh V4-Pro (أغسطس، بيانات تاريخية)	Gemma-4-26B (أغسطس، بيانات تاريخية)
الرد بكلمة "PONG" (بعد التشغيل واستدعاء واحد)	✅ 6.1 ثانية · 0 أدوات	✅ 1.7 ثانية · 0 أدوات	✅ 2.8 ثانية	✅ 13.2 ثانية*
كتابة وتشغيل برنامج FizzBuzz	✅ 22.8 ثانية · 2 أدوات (كتابة، تنفيذ)	✅ 5.3 ثانية · 3 أدوات	✅ 8.4 ثانية · 2 أدوات	✅ 4.9 ثانية · 2 أدوات
إصلاح خطأين لكي تمر اختبارات الوحدة (دون تغيير الاختبارات)	✅ 86.6 ثانية · 6 أدوات (تنفيذ، كتابة، تحرير)	✅ 11.3 ثانية · 7 أدوات	✅ 15.8 ثانية · 7 أدوات	✅ 10.4 ثانية · 8 أدوات
تلخيص كود مكون من 6 وحدات (<150 كلمة)	✅ 65.5 ثانية · 10 أدوات (قراءة، تنفيذ، كتابة)	✅ 5.1 ثانية · 7 أدوات	✅ 10.9 ثانية · 7 أدوات	✅ 12.1 ثانية · 7 أدوات
إعادة تسمية دالة في 3 ملفات بالإضافة إلى الاختبارات، مع التأكد من نجاح الاختبارات	✅ 128.9 ثانية · 9 أدوات (تنفيذ، كتابة؛ استخدام أمر sed على الملفات)	✅ 12.3 ثانية · 11 أداة	✅ 18.2 ثانية · 12 أداة	✅ 12.2 ثانية · 11 أداة
إجمالي الوقت المستغرق	309.9 ثوانٍ	35.7 ثوانٍ	56.1 ثوانٍ	52.8 ثوانٍ
عدد التوكينات: مدخلات / قراءة من الذاكرة المؤقتة / مخرجات (للتفكير المنطقي)	91,470 / 355,328 / 9,990 (4,053)	6,141 / 147,328 / 4,697 (1,984)	41.4 ألف / 107 آلاف / 3.2 ألف	40.5 ألف / 237 ألف / 5.6 ألف
التكلفة	≈ 0.531 دولار (3 دولارات / 15 دولارًا / 0.30 دولار لكل مليون توكين)	≈ 0.011 دولار (0.44 دولار / 1.32 دولار / 0.014 دولار لكل مليون توكين)	≈ 0.072 دولار	0 دولار (تكلفة الكهرباء فقط)

عدد الاستدعاءات يمثل عدد مرات استخدام الأدوات. أما بيانات Kimi فهي مأخوذة من toolSummary.calls في ملف JSON الخاص بـ OpenClaw، مع ذكر أنواع الأدوات بين قوسين؛ بينما تأتي بيانات dsh من سجل الجلسات الخاص به. *الاستدعاء الأول بعد تحميل النموذج على الجهاز. تُعد معدلات Kimi هي تلك الموجودة في قائمة OpenClaw، والتي يستخدمها OpenClaw لحساب تكلفة كل مهمة؛ يمكنكم الاطلاع على الأرقام الحالية في صفحة تسعير Moonshot. أما تكلفة dsh V4-Flash فهي مبنية على نفس المعدلات القصوى المذكورة في مقالة dsh (تسعير DeepSeek)؛ بينما تمثل صفوف V4-Pro وGemma الأرقام الواردة في تلك المقالة.

ما توضحه الجدولة:

• درجة 5/5 في كل عمود. لم تواجه كيمي أي صعوبات في أداء هذه المهام. عادت نتيجة تنفيذ برنامج PONG كما كان مطلوبًا. طبع برنامج FizzBuzz الـ15 سطرًا بشكل صحيح. كانت إصلاحات الأخطاء عبارة عن تغييرين بسيطين في سطر واحد فقط (إضافة كلمة return ونقصان == 1 الذي كان يجب أن يكون == 0)، مع بقاء اختبارات البرنامج كما هي ونجاحها جميعًا. كان الملخص عبارة عن فقرة واحدة مكونة من 107 كلمات وصفت بشكل صحيح ست وحدات برمجية متطابقة تتولى عمليات الاسترجاع والتحويل والتحقق من الصحة. أما عملية إعادة التسمية فكانت باستخدام أمر sed في أربعة ملفات، مما أدى أيضًا إلى إعادة تسمية دالة الاختبار، ثم نجاح جميع الاختبارات الأربعة. طلبت من كيمي تنفيذ أمر grep على المجلد بأكمله، وكان المجلد يحتوي أيضًا على نسخة من طلبي، لذا قامت كيمي بتطبيق نفس أمر sed على ذلك الملف وأفادت بذلك في ردها. هذه مهام بسيطة؛ لم أختبر إعادة هيكلة تشمل عدة ملفات.

كيمي يقضي وقتًا أطول في التفكير. استخدم نموذج K3 ما مجموعه 53، 241، 315، 1,586، و1,858 رمزًا من رموز الاستدلال عبر المهام الخمس (بإجمالي 4,053 رمزًا). أما نموذج dsh على منصة V4-Flash فهو أيضًا يقوم بالاستدلال، لكن بدرجة أقل: 0، 52، 834، 5، و1,093 رمزًا (بإجمالي 1,984 رمزًا). معظم الوقت الإضافي الذي يقضيه كيمي يذهب للتفكير واتخاذ خطوات إضافية.

الذاكرة المؤقتة تتحمل تكلفة المعالجة. كل مهمة من مهام Kimi تبدأ بحوالي 15 ألف رمز من تعليمات النظام وتعريفات الأدوات. في المهام الخمس، أرسل Kimi 91,470 رمزًا كمدخلات غير مخزنة في الذاكرة المؤقتة، بينما قرأ 355,328 رمزًا من الذاكرة المؤقتة (157,952 رمزًا فقط في مهمة إعادة التسمية). وبذلك، جاء 80% من رموز التعليمات من الذاكرة المؤقتة بتكلفة قدرها 0.30 دولار لكل مليون رمز بدلاً من 3 دولارات. لو تم احتساب جميع الرموز كمدخلات غير مخزنة، لكانت التكلفة حوالي 1.49 دولار بدلاً من 0.53 دولار؛ أي أن استخدام الذاكرة المؤقتة خفض التكلفة إلى ثلثها تقريبًا. ومع ذلك، فإن سعر 0.30 دولار يظل سعرًا مرتفعًا؛ فهو يعادل حوالي 21 ضعف سعر قراءة البيانات من الذاكرة المؤقتة في نظام dsh V4-Flash، والذي يبلغ 0.014 دولار.

بالنسبة للمهام البسيطة، فإن V4-Flash هو الخيار الأفضل. في حالة المعالجة الحرارية، كان dsh أسرع بحوالي 9 مرات وأقل تكلفة بـ 48 مرة للحصول على نفس النتيجة. أما في حالة المعالجة الباردة، فكان أسرع بحوالي 7 مرات وأقل تكلفة بـ 22 مرة. في كل الأحوال، النتيجة واحدة. عملية إعادة التسمية وحدها استغرقت من كيمي 128.9 ثانية وتكلفت 0.180 دولار، بينما استغرق dsh 12.3 ثانية وتكلف 0.0043 دولار فقط.

نظرة سريعة على Kimi K3 في OpenClaw مقابل dsh

كلاهما عبارة عن حلقات عملاء (agent loops) تقرأ الملفات وتنفذ أوامر الشل، كما أنهما يحسبان التكاليف بناءً على عدد الرموز المستخدمة. لكنهما يختلفان في الجهة المنتجة لهما وفي طريقة التحكم بهما.

	Kimi K3 في OpenClaw	dsh
الجهة المنتجة	النموذج: Moonshot AI؛ حلقة العملاء: OpenClaw	DeepSeek (النموذج وأداة التشغيل)، بالإضافة إلى MIT
كيفية استدعائه من سكريبت	openclaw agent --agent <id> --model moonshot/kimi-k3 -m "…" --json	dsh --profile headless "…"
تغيير النماذج المستخدمة	عبر تعديل قيمة model.primary في ملف openclaw.json	عبر تعديل ملف ~/.dsh/settings.yaml
اختبار الأداء بدون واجهة مستخدم، 5 مهام بسيطة	309.9 ثانية، تكلفة تقريبية 0.531 دولار، نجاح في جميع المهام الخمس	35.7 ثانية، تكلفة تقريبية 0.011 دولار، نجاح في جميع المهام الخمس (باستخدام V4-Flash؛ أما في الحالة الباردة فقد استغرق الأمر 44.8 ثانية بتكلفة تقريبية 0.024 دولار)
إنشاء عنصر واجهة مستخدم من نوع بكسل-آرت، بنفس التعليمات	تمت ثلاث محاولات؛ نجحت اثنتان منها؛ المحاولة المعروضة هنا استغرقت 7.4 دقائق وتكلفت تقريبًا 0.47 دولار	تمت محاولتان؛ المحاولة الناجحة استغرقت 25 دقيقة بتكلفة تقريبية 0.49 دولار
الإصدار الذي تم اختباره	OpenClaw 2026.9.2، وإضافة Moonshot الإصدار 2026.9.2	0.1.1-rc.2 (نسخة تجريبية للمطورين)

كانت هناك في المقارنات السابقة على هذا الموقع عمود خاص بـ Reasonix؛ لكنني أوقفت استخدام Reasonix على جهازي بتاريخ 2026-09-09، لذا فهو غير موجود هنا؛ ومع ذلك يظل مقال يوليو الخاص به متاحًا كسجل تاريخي. كما قمت أيضًا باختبار MiniMax M3 باستخدام نفس مجموعة الاختبارات؛ شركة MiniMax منفصلة عن Moonshot، ولهذا الاختبار مقال خاص به.

الاختبار الترفيهي: نفس مواصفات الويدجت، كيمي مقابل dsh

كان “الاختبار الترفيهي” في مقال dsh عبارة عن ويدجت فني من نوع بكسل آرت يمثل شعار هذا الموقع؛ وقد قام dsh ببنائه باستخدام أداة V4-Flash بناءً على مواصفات مكتوبة. لقد سلمتُ كيمي نفس المواصفات دون تعديل، وقمتُ بقياس الوقت المستغرق. باختصار، تتضمن المتطلبات ما يلي:

• ملف واحد مكتوب بلغة JavaScript عادية، وهو ll-pixel-logo.js، لا يحتوي على أي تبعيات أو استدعاءات شبكية؛ يقوم هذا الملف بإنشاء عنصر Canvas عالي الدقة داخل كل عنصر من نوع .ll-pixel-logo، كما يوفر دالة window.LLPixelLogo.mount(el). بالإضافة إلى ذلك، يجب توفير ملف عرض تجريبي index.html وملف README.md.
• فن توليدي آلي، وليس رسم يدوي: شبكة مكونة من 40×40 خلية يتم إضاءتها باستخدام دالة isLit(col, row) لتشكيل حلقة نصف قطرها يتراوح بين 0.82R وR، بالإضافة إلى شكلين مائلين على هيئة حرف “L”، كل منهما مكون من مستطيلين متشابهين.
• التفاعلات: تأثير طرد المؤشر مع عودة تلقائية للوضع الأصلي، تأثير نقرة قوي، حركة بسيطة عند الخمول، دعم لوضع تقليل الحركة، بالإضافة إلى اختبار ذاتي (node --check) يحسب عدد الخلايا المضاءة دون الحاجة إلى DOM.

يحتوي اختبار الويدجتات الفنية على نص المواصفات كاملاً.

كيف تعاملت كيمي مع المهمة:

• المحاولة الأولى (مع نفس المواصفات دون تعديل): توقفت بعد 8.8 دقائق، دون إنتاج أي كود للويدجت، بتكلفة تقارب $0.31. قامت K3 بدراسة شعار المرجع وفهمت الهندسة الرياضية والخطوات المطلوبة، لكنها لم تكتب أي من الملفات المطلوبة. فشلت محاولة dsh الأولى أيضاً بنفس الطريقة (حلقة عمل استمرت 10 دقائق لرسم صورة بكسلية في ذهنه)، رغم أن المواصفات آنذاك سمحت بالرسم اليدوي.
• المحاولة الثانية (مع نفس المواصفات مرة أخرى): تم إنتاج ويدجت كامل، لكن في مسار خاطئ، بتكلفة تقارب $0.72. بعد حوالي 8 دقائق، كتبت كيمي ملفاً يحتوي على 323 سطراً باسم ll-pixel-logo.js، ثم صفحة عرض تجريبي وملف README وملفين للاختبار؛ قامت بتشغيل الاختبارات وتعديل الكود حتى نجحت جميعها، ثم كتبت تقريراً مختصراً. لكن كل هذه الملفات ذهبت إلى مساحة العمل الخاصة بوكيل المعالجة وليس إلى المسار الذي كان يراقبه سكريبتي، فوصلت الجلسة إلى حد الـ15 دقيقة الذي حددته. من مكان مراقبتي، لم تظهر أي نتائج من المحاولة الثانية، لذا لم أنتظرها وبدأت المحاولة الثالثة بعد حوالي 7 دقائق.
• المحاولة الثالثة (مع مواصفات مختصرة وتوجيهات صارمة): استغرقت 7.4 دقائق، وأنتجت جميع الملفات الثلاثة، بتكلفة تقارب $0.47. أبقيتُ على المتطلبات الفنية والتفاعلية، ووضعتُ في أعلى النص التوجيهي التالي: TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. كما استبدلتُ قسم الاختبار بجملة تنتهي بهذا النص: Do NOT do a "node --check" or playwright test — just write the files and print a short report listing what you wrote. الويدجت الناتج يحتوي على تأثير طرد المؤشر مع عودة تلقائية، تأثير تفتت وإعادة تجميع عند النقر، حركة بسيطة عند الخمول، بالإضافة إلى وضع تقليل الحركة. أما التحقق من الصحة فقد تم لاحقاً.

بذلك، استغرقت المحاولات الثلاث 8.8 دقيقة و15 دقيقة و7.4 دقيقة على التوالي، بتكلفة تقارب $0.31 و$0.72 و$0.47؛ أي حوالي $1.50 لإنتاج ويدجتين. تكلفة المحاولة الثالثة مستمدة من إيصال JSON الخاص بها، بينما لم تحصل المحاولتان الأولى والثانية على إيصالات، فتم حساب تكلفتهما عبر جمع تكاليف كل رسالة في كل جلسة وفقاً لنظام OpenClaw؛ وهذا المجموع يتطابق مع قيمة الإيصال الخاص بالمحاولة الثالثة.

<pبعد حوالي ساعة، ظهر ويدجت المحاولة الثانية مجدداً عندما قام نموذج MiniMax M3 بتشغيله على نفس بيئة المعالجة، فوجد الملفات وشغّل عليها الاختبارات وأعلنها كعمل خاص به. يمكن الاطلاع على تفاصيل ذلك في تقرير MiniMax M3، كما يظهر كل من ويدجتي كيمي إلى جانب ويدجت dsh في اختبار الويدجتات الفنية.

<pفيما يلي أول 30 سطراً تقريباً من ملف ll-pixel-logo.js الذي أنتجته كيمي:

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 *
 * Self-contained vanilla JS: no dependencies, no build step, no network.
 * Embed on any page with:
 *
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 *
 * Every .ll-pixel-logo element gets a <canvas> mounted inside it at load.
 * Programmatic API: window.LLPixelLogo.mount(el) -> instance.
 *
 * Art: 40x40 pixel grid, rasterised procedurally from geometry (ring + two
 * interlocking italic Ls). Interactions: pointer repulsion with spring-back,
 * click/tap shatter-and-reassemble, idle shimmer/twinkle, reduced-motion
 * support. Mouse and touch. No scroll hijacking (all listeners passive).
 */
(function () {
  'use strict';

  // -- constants ------------------------------------------------------------
  var VERSION = '1.0.0';
  var GRID = 40;                                // logical grid: GRID x GRID cells
  var BLUE   = [31, 63, 143];                   // #1f3f8f logo blue
  var HILITE = [46, 168, 255];                  // #2ea8ff highlight blue
  var AMBER  = [255, 182, 74];                  // #ffb64a twinkle amber
  var CYAN   = [0, 230, 207];                   // #00e6cf max-displacement glow

  var CENTER = GRID / 2;                        // grid centre coordinate (20)
  var R_OUT = 19;                               // ring outer radius (cells)
  var R_IN = 0.82 * R_OUT;                      // ring inner radius
  var SLANT = Math.tan(20 * Math.PI / 180);     // ~20 deg italic shear

<pتقوم كيمي ببناء كل شكل “L” عبر استخدام مستطيلين (جذع ومقدمة) بمساعدة دالة صغيرة تسمى makeL، كما تختبر النقاط باستخدام دالة inPara ضمن دالة isLit. كل الثوابت المستخدمة في التحكم بالشكل (نصف قطر الحلقة من 0.82R إلى R، زاوية ميل تبلغ 20° حسب قيمة Math.tan، بالإضافة إلى معاملات الارتداد والتماسك) تم تجميعها في كتلة واحدة في بداية الملف. الملفات التي أنتجتها (ملف ll-pixel-logo.js الذي يحتوي على 397 سطراً، وملف index.html بـ40 سطراً، وملف README.md بـ79 سطراً) متاحة للتحميل من الرابط التالي: /assets/uploads/2026/09/kimi-codex/.

<pتم بناء ويدجت dsh (مصدر الكود، مع عرض مقتطفات في مقال dsh) بنفس الطريقة: كلا الويدجتين يرسمان حلقة وشكلين مائلين على هيئة حرف “L” بناءً على حسابات هندسية، كما يعرض كلاهما دالة window.LLPixelLogo.mount ويحترمان إعدادات prefers-reduced-motion. لكن القيم المستخدمة تختلف؛ فاستخدم dsh نصف قطر خارجي يبلغ 19.7، ونصف قطر داخلي عند 0.80R وزاوية ميل تقارب 24° (أي 0.453)، بينما استخدمت كيمي القيم 19 و0.82R و20°. كما أن خطوط كيمي أرق؛ حيث يبلغ سمك الجذع والمقدمة فيها 3 خلايا، مقابل 4.2 خلية للجذع و3.8 للمقدمة عند dsh. ولهذا السبب يضيء ويدجت كيمي 510 خلايا بينما يضيء ويدجت dsh 656 خلية. لا يتطابق أي من الويدجتين تماماً مع شعار المرجع، لكن كلاهما يوحيان بالشكل نفسه عند النظر إليهما. كما قامت محاولة dsh الثانية بكتابة اختبار وحدة باستخدام Node وبرنامج اختبار Playwright دون طلب صريح؛ بينما تلقت كيمي في المحاولة الثالثة توجيهات بعدم إجراء أي اختبارات، فامتثلت لها.

أوامر التحقق التي نفذتها على ويدجت كيمي

لقد أعدت تنفيذ هذه الأوامر في تاريخ 2026-09-11 على النسخة الموجودة في هذه الصفحة، والتي تقع في المسار /assets/uploads/2026/09/kimi-codex/:

$ wc -l ll-pixel-logo.js
397 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "node --check passed"
node --check passed

هناك فحصان إضافيان قمت بهما بنفسي، باستخدام نصين برمجيين صغيرين (كل منهما أقل من 20 سطرًا) لم أنشرهما؛ لذا سأذكر الطريقة المستخدمة بدلاً من الأوامر التي يمكنك نسخها:

• عدّ الخلايا المضاءة. قمت بتحميل ملف الويدجت باستخدام Node مع واجهة DOM مزيفة (بدون أي عناصر فعلية مثل canvas أو window أو document)، ثم استخدمت الدالة isLit(col, row) الموجودة في الملف وطبقتها على كل خلية في شبكة 40×40، وقمت بحساب عدد الخلايا المضاءة حسب الربع. نتيجة ذلك كانت إضاءة 510 خلايا: 124 في الربع العلوي الأيسر، و103 في الربع العلوي الأيمن، و160 في الربع السفلي الأيسر، و123 في الربع السفلي الأيمن.
• فحص عملية التثبيت. باستخدام نفس واجهة DOM المزيفة، تأكدت من أن الملف يُعرّف المتغير window.LLPixelLogo ككائن، وأن استدعاء الدالة mount() على عنصر مزيف يعيد قيمة كائن بدلاً من إظهار خطأ.

الحلقة الوحيدة (أي الخلايا التي تقع مراكزها بين 0.82R وR، حيث R = 19) تحتوي على 352 خلية من أصل 510، مما يعني أن هناك 158 خلية متبقية لتشكيل حرفي “L”. النصوص البرمجية المستخدمة هي من إعدادي أنا وليست من كيمي، وهي مجرد اختبارات بسيطة وغير قابلة للتنفيذ في المتصفح؛ فالصفحة التي تقرأها الآن هي نتيجة تنفيذ البرنامج في المتصفح.

لماذا لا يعمل هذا عبر Codex؟

توفر OpenClaw أيضًا مكون إضافي يُسمى Codex harness يقوم بتشغيل خادم التطبيقات Codex الفعلي (وهو يدير إصدار @openai/codex 0.153.4). لكن لا شيء في هذا المقال يتم تشغيله عبر ذلك المكون، لأنه لا يمكنه التعامل مع هذا النموذج؛ فوظيفة التحقق من المسار configuredModelRouteNeedsCodex تُرجع قيمة false لأي مزود لا يكون معرفه الموحد هو openai. معرف مزود Moonshot هو moonshot، لذا فإن مسار moonshot/kimi-k3 لا يصل أبدًا إلى بيئة تشغيل Codex. مصطلح “متوافق مع OpenAI” لا يعني بالضرورة “متوافق مع مكون Codex harness”.

لذلك، يتم تشغيل نموذج Kimi هنا ضمن حلقة التشغيل الخاصة بـ OpenClaw، تمامًا مثل أي نموذج آخر مدعوم أصلاً من OpenClaw. لن تحصل على ميزات مثل استئناف تنفيذ الكود في Codex، أو آلية الضغط الخاصة به، أو جسر الأدوات الديناميكي، أو نموذج تشغيل التطبيقات المستخدم فيه. إذا كنت بحاجة إلى تلك الميزات مع نموذج Kimi، فالحل المعروف هو استخدام codex-router، وهو جسر محلي يوجه طلبات Codex إلى نقطة نهاية على العنوان 127.0.0.1:4202 ثم يحولها إلى Kimi (وفقًا لما ورد في README الخاص به). ولكي يكتشف المكون الإضافي هذا الإعداد، يجب أن تكون قيمة الخاصية appServer.homeScope هي "user"، مما يسمح بمشاركة مجلد ~/.codex (أو $CODEX_HOME) مع المكون الإضافي بدلاً من عزل حالة Codex لكل وكيل OpenClaw على حدة. لم أقرر بعد ما إذا كنت موافقًا على ذلك، لذا لم أقم ببناء هذا الحل حتى الآن.

المصائد الشائعة (تلك التي واجهتها فعلاً)

• التعليمات الإبداعية المفتوحة قد توقف عمل نموذج التفكير، وقد يؤدي انتهاء الوقت المسموح إلى إخفاء نجاح العملية. في المحاولة الأولى، استغرق النموذج 8.8 دقائق للتفكير دون أن يكتب أي كود؛ أما في المحاولة الثانية، فقد كتب كود ويدجت يعمل بشكل صحيح، لكن الوقت المسموح انتهى قبل أن يتم حفظ الملفات في المجلد الصحيح، مما جعل الأمر يبدو وكأنه فشل ثانٍ. الحل كان استخدام تعليمات أقصر تحت عنوان TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop.، مع تحديد المجلد المستهدف بشكل واضح. لا يزال نموذج K3 يستخدم هذه الصياغة في التفكير؛ لكنه لم يعد يقوم بالتخطيط إلى ما لا نهاية. بغض النظر عن رمز الخروج، يجب فحص ما كتبه النموذج، وكذلك التحقق من مساحة العمل الخاصة به.
• رمز الخروج “الخطأ” لا يعني بالضرورة فشل المهمة؛ يجب فحص الملفات. في أول محاولة لتنفيذ مهمة FizzBuzz، خرج النموذج برمز خروج 1، ولم يتم تحديد أي نموذج ناجح، وانتهى بعبارة “⚠️ تم تجاوز حدود معدل استخدام الـ API. يرجى المحاولة لاحقاً.” لكن النموذج كان قد كتب بالفعل ملف fizz.py، والذي عمل بشكل صحيح. عند إعادة التشغيل، أجاب النموذج “تم إنشاؤه وتشغيله بالفعل.”، وكان ذلك هو المؤشر الوحيد على اكتمال المهمة. كان البرنامج الخاص بي يكتب بيانات JSON لكل تشغيل في نفس الملف، لذا تم الكتابة فوق بيانات التشغيل الفاشل؛ لكن رمز الخروج والنص النهائي ظلا مسجلين في سجل الجلسة التي أجرت الاختبار. الجدول يستخدم نتائج تشغيل لاحق ونظيف في جلسة جديدة.
• لا تقم بنسخ مجلد البيانات المؤقتة من نتائج تشغيل سابقة لنظام آخر. قمت بإعداد مجلد إصلاح الأخطاء الخاص بـ Kimi عن طريق نسخ الملفات من مجلد النتائج الخاص بـ dsh، بعد أن قام dsh بالفعل بإصلاح تلك الأخطاء؛ لذا وجدت محاولة Kimi الأولى أن الملفات قد تم إصلاحها بالفعل وتحققت فقط من ذلك. يجب نسخ ملفات الاختبار من مصدر نظيف وخالٍ من الأخطاء. أعدت تعيين مجلد البيانات ثم شغّلت العملية في جلسة جديدة؛ الجدول يعرض نتائج هذا التشغيل الثاني.

ما الذي توصلت إليه من كل هذا؟

في هذه المهام الخمس، كان نموذج Kimi K3 صحيحًا في إجاباته، لكنه بطيء ومكلف للغاية. أما بالنسبة للمهام البسيطة، فقد قام نموذج dsh على منصة V4-Flash بنفس العمل في حوالي تسع مرات أقل من الوقت وبتكلفة تعادل 1/48 من تكلفة Kimi K3 (كما ظهر في اختبارات الأداء). بعد هذه الاختبارات، نقلت وكيل العمليات الخاص بي من استخدام نموذج Kimi إلى نموذج MiniMax-M3؛ بينما بقي نموذج Kimi K3 في مكانه الأصلي: خلف وكيل المراجعة لدي، حيث أن الإجابات البطيئة والدقيقة تستحق الدفع مقابلها.

مرتبط أيضًا: DeepSeek Harness (dsh) (الأداة التي قارنتها ضده، وهي مصدر اختبارات الأداء والتعليمات)، مقارنة أدوات الرسوم البكسلية (حيث تم عرض جميع الأدوات الثلاثة جنبًا إلى جنب)، MiniMax M3 (نفس الأداة على النموذج الذي يستخدمه وكيل العمليات لدي اعتبارًا من تاريخ 2026-09-11)، وما هي التكلفة الفعلية لوكلاء الذكاء الاصطناعي لدي؟ (مقارنة أسعار أوسع نطاقًا).