كيمي ك3 على منصة موونشوت كوكيل برمجة: دمجه في OpenClaw، قياس أدائه مقارنةً بـ dsh، وطلب منه إنشاء عنصر واجهة مستخدم على شكل شعار فني من نوع بكسل-آرت.
- تاريخ النشر
- 12 سبتمبر 2026
- تاريخ التحديث
- 12 سبتمبر 2026
- بقلم
- جاكوب لويد — كُتب بمساعدة الذكاء الاصطناعي بعد إنجاز المشروع
- مدة القراءة
- قراءة 7 دقيقة
بعبارة مبسطة: لقد دمجت نموذج التفكير Kimi K3 من Moonshot في برنامج الوكيل الذي أستخدمه في المنزل، ثم طلبت منه تنفيذ نفس المهام البرمجية الخمس الصغيرة التي استخدمتها في أغسطس لاختبار مساعد البرمجة من DeepSeek (dsh). كما طلبت منه إنشاء نسخة فنية من شعار الموقع بناءً على نفس التعليمات المكتوبة. نجح النموذج في تنفيذ جميع المهام، لكن الوقت الذي استغرقه كان أطول بـ 9 مرات تقريبًا، والتكلفة كانت أعلى بحوالي 48 مرة مقارنة باستخدام dsh مع نموذج DeepSeek السريع. أما بالنسبة لإنشاء عنصر الشعار، فقد استلزم الأمر ثلاث محاولات: المحاولة الأولى استغرقت حوالي 9 دقائق دون أن ينتج عنها أي نتيجة؛ أما الثانية فأنتجت عنصرًا يعمل بشكل صحيح، لكن تم وضعه في المجلد الخطأ، ونفد الوقت قبل أن يخبرني بذلك، لذا اكتشفته لاحقًا فقط؛ بينما نجحت المحاولة الثالثة بعد أن قصرت التعليمات وأمرته بتخطي مرحلة التخطيط.
لقد وجهت وكيل العمل الخاص بـ OpenClaw نحو نموذج Kimi K3، وهو النموذج الرئيسي للاستدلال من شركة Moonshot، ثم قمت بتشغيله على نفس المهام البرمجية الخمس الصغيرة التي استخدمتها في أغسطس لقياس أداء DeepSeek Harness (dsh). نجح Kimi في تنفيذ جميع المهام. وعند مقارنته بـ dsh على نموذج DeepSeek V4-Flash، والذي تم تشغيله في نفس اليوم على نفس المهام، استغرق Kimi وقتًا أطول بحوالي 9 مرات (309.9 ثانية مقابل 35.7 ثانية)، كما كلف حوالي 48 مرة أكثر ($0.531 مقابل $0.011). بعد ذلك، قدمت له التعليمات المتعلقة بإنشاء شعار من نوع “بكسل آرت” التي استخدمها dsh سابقًا؛ احتاج Kimi إلى ثلاث محاولات لإنجاز المهمة. في المحاولة الأولى، ودون تعديل على التعليمات، لم ينتج عن ذلك أي شيء. وفي المحاولة الثانية، كتب Kimi كودًا كاملاً لكنه وضعه في مجلد خاطئ، وانتهى الوقت المسموح له قبل أن يُخبرني بذلك؛ لذا لم ألاحظ ذلك في البداية. أما المحاولة الثالثة، فنجحت بعد أن قصرت التعليمات وأمرته بتخطي مرحلة التخطيط.
- إنه نموذج Kimi K3 الذي يعمل عبر واجهة برمجة التطبيقات المتوافقة مع OpenAI من شركة Moonshot، ويستخدم حلقة العمل الخاصة بـ OpenClaw (أسمي ذلك “المسار أ”). لكنه ليس تطبيق Codex نفسه؛ فإضافة Codex تستقبل فقط طلبات من مزود OpenAI (وهذا ما تم التحقق منه في كود OpenClaw الإصدار 2026.9.2).
- يتم استخدام إضافة مزود Moonshot (
@openclaw/moonshot-providerالإصدار 2026.9.2)، مع عنوان URL الأساسيhttps://api.moonshot.ai/v1، بالإضافة إلى مفتاحMOONSHOT_API_KEYفي بيئة التشغيل. يسمح إعداد النموذج بتحديد مستوى الجهد المبذول في الاستدلال كـlowأوhighأوmax، ولا يسمح بتعديل قيمةtemperature، ويحدد حجم السياق بـ 262,144 رمزًا فقط من أصل الحد الأقصى المعلن وهو 1,048,576 رمزًا. - تم تنفيذ خمس مهام في مجلدات جديدة؛ نجح Kimi K3 في جميعها (5/5)، واستغرق 309.9 ثانية وتكلف $0.531. أما dsh على نموذج V4-Flash فنجح أيضًا (5/5)، لكنه استغرق 35.7 ثانية وتكلف $0.011 فقط.
- احتاج Kimi إلى ثلاث محاولات؛ في المحاولة الأولى توقف بعد 8.8 دقائق دون إنتاج أي كود. وفي الثانية، كتب كودًا مكونًا من 323 سطرًا بالإضافة إلى اختباراته، لكنه وضعه في مجلد العمل الخاص بالوكيل بدلاً من المجلد الذي كنت أراقبه، وتوقف قبل أن يُخبرني بذلك. أما المحاولة الثالثة، التي استخدمت تعليمات مختصرة تطلب
TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop.، فنجحت في 7.4 دقائق بتكلفة $0.47؛ والويدجت المعروض هنا هو نتيجة هذه المحاولة، وهو يمر باختبارnode --checkويعمل بدون أخطاء. - شكلت الرموز المسترجعة من الذاكرة المؤقتة 80% من إجمالي رموز المدخلات؛ لولا ذلك لكانت التكلفة حوالي $1.49 بدلاً من $0.53. وتبلغ أسعار الاستخدام: $3 لكل مليون رمز مدخل، و$15 لكل مليون رمز مخرج، و$0.30 لكل مليون رمز يتم استرجاعه من الذاكرة المؤقتة.
- كان Kimi هو النموذج المستخدم في هذا الاختبار؛ لكن اعتبارًا من تاريخ 2026-09-11، أصبح النموذج المستخدم في عملياتي هو MiniMax-M3، بينما لا يزال Kimi K3 يُستخدم كوكيل للمراجعة.
المسار أ مقابل المسار ب، بصراحة
كل ما يوجد هنا يندرج تحت المسار أ: حيث يقوم كيمي K3 بتشغيل حلقة الوكيل الخاصة بـ OpenClaw عبر مزود خدمة Moonshot. على جهازي، كان مزود الخدمة مُعدًّا مسبقًا، لذا كان تغيير العامل إلى كيمي مجرد تغيير نموذج واحد.
أما المسار ب فيضع كيمي خلف تطبيق Codex app-server الفعلي، وهو التطبيق الذي يُشغّله إضافة Codex الخاصة بـ OpenClaw (الإضافة تدير إصدار @openai/codex 0.153.4). لم أقم ببناء هذا المسار، ولا يوجد أي شيء في هذه المقالة يعمل عبر Codex. السبب يكمن في كود الإضافة: فالدالة configuredModelRouteNeedsCodex تُرجع قيمة false لأي مزود خدمة لا يكون معرفه الموحد هو openai. ومعرف مزود Moonshot هو moonshot، لذا فإن المسار moonshot/kimi-k3 لا يصل أبدًا إلى بيئة تشغيل Codex.
الحل المعروف لهذه المشكلة هو استخدام codex-router، وهو جسر محلي يوجه طلبات Codex إلى نقطة نهاية على العنوان 127.0.0.1:4202 ثم يحوّلها إلى كيمي (وفقًا لملف README الخاص به). ولكي تتعرف الإضافة على هذا الإعداد، يجب أن تكون قيمة appServer.homeScope في الإضافة هي "user"، وهو ما يؤدي إلى مشاركة مجلد ~/.codex الأصلي (أو $CODEX_HOME) مع الإضافة بدلاً من عزل حالة Codex لكل وكيل OpenClaw على حدة. لم أقرر بعد ما إذا كنت مرتاحًا لهذا الحل، لذا يظل المسار ب مجرد فكرة نظرية.
هناك بعض القيود التي يجب أن تعرفها بخصوص المسار أ. فالتقارير المتعلقة بالعمليات تُظهر قيمة agentHarnessId: "openclaw"، وهو نفس التنسيق المستخدم لأي نموذج آخر تابع لـ OpenClaw. لن تحصل على ميزات مثل استئناف تنفيذ الخيوط في Codex، أو آلية الضغط الخاصة به، أو جسر الأدوات الديناميكي، أو نموذج التنفيذ الخاص بتطبيق app-server. إذا كنت بحاجة إلى أي من هذه الميزات، فالمسار ب هو الخيار الوحيد.
الإعدادات: على أي نظام قمت بتشغيله
هذه هي الأوامر التي نفذتها على جهازي في تاريخ 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 ألف رمز وليس مليون رمز. - الذاكرة المؤقتة هي التي تقلل التكلفة بشكل كبير. يبدأ كل مهمة باستخدام حوالي 15 ألف رمز من نص التعليمات وتعريفات الأدوات. بعد الخطوة الأولى، يتم استرجاع معظم هذه البيانات من الذاكرة المؤقتة بتكلفة قدرها 0.30 دولار لكل مليون رمز بدلاً من 3 دولارات. في مهمة إعادة التسمية، بلغ عدد الرموز المسترجعة من الذاكرة المؤقتة وحدها 157,952 رمزًا.
الخطوات، من الأساسية إلى المتقدمة
الخطوات من 1 إلى 3 تمنحك نموذجًا يعمل بشكل صحيح؛ أما الخطوتان 4 و5 فهي ما قمت به لاحقًا.
الخطوة الأولى: تثبيت الإضافة وإدخال المفتاح الخاص بها
هذه هي الخطوات المذكورة في وثائق Moonshot الخاصة بـ 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).
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، فعليك كتابة الكائن بأكمله، كما هو موضح أعلاه.
السطر contextTokens: 262144 يمثل الحد الأقصى المذكور في تعليمات الإعداد. إذا رفعت هذه القيمة، فتوقع أن تزداد تكلفة قراءة الذاكرة المؤقتة وتأخر الاستجابة لكل دورة حوارية خلال الجلسة.
الخطوة الثالثة: اختبار التحقق، والبيانات بتنسيق 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" هو مؤشر مسار التنفيذ “أ”. أما في حالة تنفيذ نفس المهمة عبر خادم تطبيقات Codex، فإن القيمة ستكون "codex". winnerModel: "kimi-k3" يخبرنا أن المهمة تم تنفيذها فعلاً على وحدة K3 ولم يتم اللجوء إلى وحدة أقل تكلفة. أما reasoningTokens فهي تُحسب ضمن output (المجموع الكلي هو مجموع الرموز المدخلة والمخرجة)، لذا فإن الـ 53 رمزًا من نوع reasoningTokens هي جزء من الـ 70 رمزًا الإجماليين.
مقارنة جانبًا إلى جانب: Kimi K3 في OpenClaw مقابل dsh
كلا الأداتين عبارة عن حلقات وكلاء تقوم بقراءة الملفات وتنفيذ أوامر shell، وتحسب التكلفة بناءً على عدد الرموز المستخدمة. لكنهما يختلفان في الجهة المنتجة لهما وفي طريقة التحكم فيهما.
| 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 دولار، نجاح في جميع المهام (5/5) | 35.7 ثانية، بتكلفة تقريبية 0.011 دولار، نجاح في جميع المهام أيضًا (5/5؛ باستخدام V4-Flash في المرور الثاني) |
| إنشاء عنصر فني من نوع بكسل-آرت، بناءً على نفس التعليمات | تمت ثلاث محاولات؛ نجحت اثنتان منها؛ المحاولة المعروضة هنا استغرقت 7.4 دقائق وتكلفت تقريبًا 0.47 دولار | تمت محاولتان؛ النتيجة الناجحة استغرقت 25 دقيقة وتكلفت حوالي 49 سنتًا |
| الإصدار المستخدم في الاختبار | OpenClaw 2026.9.2، وإضافة Moonshot الإصدار 2026.9.2 | 0.1.1-rc.2 (نسخة تجريبية للمطورين) |
كانت هناك في المقارنات السابقة على هذا الموقع عمودًا خاصًا بأداة Reasonix؛ لكنني أزلتها من جهازي في تاريخ 2026-09-09، لذا فهي غير موجودة هنا؛ ومع ذلك، لا يزال مقال يوليو الخاص بها متاحًا كسجل تاريخي. كما قمت أيضًا بتشغيل أداة MiniMax M3 عبر نفس مجموعة الاختبارات؛ شركة MiniMax منفصلة عن Moonshot، ولهذا الاختبار مقال خاص به.
المعيار المقارن: نفس المهام الخمس
هذه هي نفس المهام الخمس التي تم تنفيذها في مقالة dsh؛ حيث تم تنفيذ كل مهمة في مجلد منفصل، مع جلسة عمل جديدة لكل مهمة. أعدتُ تشغيل أداة dsh على نموذج V4-Flash في نفس اليوم على نفس المهام الخمس، مع تحديد إصدار deepseek-v4-flash في ملف الإعدادات. لم تكن صياغة الأوامر متطابقة تمامًا؛ فأداة dsh تعمل من المجلد الذي يتم تشغيلها منه، لذا كانت أوامرها تشير إلى “المجلد الحالي”. أما أوامر Kimi فقد حددت المسار الكامل لمجلد كل مهمة، كما أضافت رسالة تصحيحية تقول: “إذا لم يكن برنامج pytest متاحًا، فقم بتثبيته باستخدام الأمر ‘pip install --user pytest’ أولاً”؛ علماً بأن برنامج pytest كان مثبتًا بالفعل، ولم يقم Kimi بأي عملية تثبيت. العمود الخاص بـ V4-Flash يمثل المرور الثاني في التنفيذ؛ حيث استغرق المرور الأول 44.8 ثانية وتكلف 0.024 دولار مع ذاكرة تخزين مؤقتة غير مُحمّلة، والمرور الثاني هو الذي أقارنه في جميع أنحاء هذه المقالة. أما أعمدة 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، والتي تُستخدم لحساب تكلفة كل مهمة؛ يمكن الاطلاع على الأسعار الحالية عبر صفحة تسعيرات Moonshot. أما تكلفة dsh V4-Flash فهي محسوبة بناءً على نفس المعدلات القصوى المستخدمة في مقالة dsh (أسعار DeepSeek)؛ بينما تم أخذ بيانات V4-Pro وGemma من تلك المقالة.
ما يوضحه الجدول:
- نجاح في تنفيذ جميع المهام. لم تواجه Kimi أي مشكلة في تنفيذ هذه المهام؛ حيث بقيت الاختبارات كما هي بعد إصلاح الأخطاء، وتمت عملية إعادة التسمية باستخدام أمر
sedعلى أربعة ملفات فقط، ثم تم تشغيل الاختبارات بنجاح، بالإضافة إلى تنفيذ أمرgrepللتأكد من عدم وجود أي آثار للاسم القديم. - Kimi تستهلك وقتًا أكثر في التفكير. استخدمت Kimi K3 ما مجموعه 53,241,315,1,586 و1,858 رمزًا تراكميًا للتفكير خلال المهام الخمس (بإجمالي 4,053 رمزًا). أما dsh على V4-Flash فقد قام بالتفكير أيضًا، لكن بدرجة أقل: 0،52،834،5 و1,093 رمزًا تراكميًا (بإجمالي 1,984 رمزًا). معظم الوقت الإضافي الذي استغرقته Kimi كان مخصصًا للتفكير والخطوات الإضافية.
- الذاكرة المؤقتة تؤثر على التكلفة. خلال تنفيذ المهام الخمس، أرسلت Kimi 91,470 رمزًا تراكميًا كمدخلات غير مخزنة في الذاكرة، بينما استرجعت 355,328 رمزًا من الذاكرة المؤقتة؛ أي أن 80% من الرموز التراكمية جاءت من الذاكرة المؤقتة. ولو تم احتساب هذه الرموز كمدخلات غير مخزنة، لكانت التكلفة حوالي 1.49 دولار بدلًا من 0.53 دولار.
- للأعمال الصغيرة، V4-Flash هو الخيار الأفضل. استغرقت المجموعة الكاملة من المهام 35.7 ثانية بتكلفة تقارب 0.011 دولار؛ وهذا أسرع بـ 9 مرات وأرخص بـ 48 مرة مقارنةً بـ Kimi، مع الحفاظ على نفس النتائج. فقط في مهمة إعادة التسمية، استغرقت Kimi 128.9 ثانية بتكلفة 0.180 دولار، بينما استغرق dsh 12.3 ثانية بتكلفة 0.0043 دولار فقط.
الاختبار الممتع: نفس مواصفات الويدجت، كيمي مقابل dsh
كان “الاختبار الممتع” في مقال dsh عبارة عن عنصر فني من نوع بيكسل آرت يمثل شعار هذا الموقع؛ وقد صممه dsh باستخدام أداة V4-Flash بناءً على وصف مكتوب. سلمت لكيمي نفس الوصف دون تعديل، وقمت بقياس الوقت الذي استغرقه في تنفيذه. والوصف كان كالتالي:
الملخص: عنصر واجهة مستخدم تفاعلي للشعار بأسلوب فن البكسلات لـ LaserLloyd
قم بإنشاء نسخة من فن البكسلات من شعار LaserLloyd يمكن تضمينها في أي مكان (انظر
reference-logo.png: حلقة زرقاء سميكة، لونها #1f3f8f على خلفية بيضاء، تحتوي على حرفي “L” متداخلين ومائلين؛ قاعدة الحرف “L” العلوي الأيسر تقع أسفل ساق الحرف “L” السفلي الأيمن، وكأن الحرفين متراكبان بشكل قطري).المخرجات المطلوبة (كلها في هذا المجلد)
ll-pixel-logo.js— ملف واحد مكتوب بلغة JavaScript العادية، لا يحتاج إلى أي تبعيات أو خطوات بناء أو طلبات شبكة. يمكن لأي صفحة تضمينه عبر:<div class="ll-pixel-logo" data-size="320"></div>+<script src="ll-pixel-logo.js"></script>. يقوم البرنامج بإيجاد كل عنصر.ll-pixel-logoويركّب بداخله عنصر<canvas>. التصميم متجاوب: القماش يملأ عرض الحاوية بشكل مربع، ويظهر بوضوح على شاشات HiDPI (حسب نسبة devicePixelRatio). يجب تصدير الدالةwindow.LLPixelLogo.mount(el).index.html— صفحة تجريبية تُظهر عنصر الواجهة بثلاثة أحجام مع وصف مختصر للتفاعلات الممكنة.README.md— شرح حول كيفية التضمين، التفاعلات المتاحة، وأي خصائص إضافية يمكن تعديلها عبر السمات (data- attributes).تفاصيل التصميم الفني
- لا ترسم الشكل يدويًا كصورة نقطية (لا تستخدم أسطرًا من الرموز مثل ‘#’ أو ‘.’؛ فهذا بطيء وعرضة للأخطاء). بدلًا من ذلك، أنشئ الصورة برمجيًا بناءً على الهندسة: هناك دالة
isLit(col,row)تعيد القيمة true في حالتين: (أ) الخلايا ضمن الحلقة: المسافة من المركز تتراوح بين 0.82R و R؛ (ب) خلايا الحرفين “L” المائلين، حيث يتكون كل حرف من مستطيلين متوازيين (ساق مائلة بزاوية ~20° وقاعدة). قاعدة الحرف العلوي الأيسر تقع أسفل ساق الحرف السفلي الأيمن، تمامًا كما في الصورة المرجعية. يجب ضبط القيم الثابتة بحيث يبدو الشكل مشابهًا للشعار الأصلي عند حجم 200 بكسل. يتم حساب الخلايا المضاءة مرة واحدة فقط عند تركيب العنصر.- الألوان المستخدمة: أزرق الشعار #1f3f8f؛ أزرق التأثيرات #2ea8ff؛ اللون العنبري #ffb64a؛ اللون السماوي #00e6cf؛ الخلفية شفافة.
التفاعلات (الجزء الأساسي من التمرين — اجعلها ممتعة)
- عند تحريك المؤشر أو اللمس: تتفاعل البكسلات القريبة من المؤشر بشكل فيزيائي؛ فتُدفع بعيدًا عنه كما لو كانت سائلة أو تخضع لقوة مغناطيسية، ثم تعود إلى مكانها مع تخفيف التأثير؛ أثناء الحركة تتوهج نحو الألوان #2ea8ff و#00e6cf. يجب أن يكون الأداء سلسًا بمعدل 60 إطارًا في الثانية باستخدام requestAnimationFrame، دون أي تقطع.
- عند النقر أو اللمس السريع: يجب أن يحدث تأثير مميز ومُرضٍ للمستخدم. اختر تأثيرًا واحدًا وقم بتنفيذه بشكل جيد؛ مثلاً: يتحلل الشعار إلى بكسلات تتطاير خارجيًا تحت تأثير الجاذبية والارتداد، ثم تعود لتشكل الشعار مجددًا (تستغرق العملية حوالي 1.5–2 ثانية)؛ أو أن “ليزرًا” يمر عبر الشاشة ليُعيد رسم الشعار بكسلة بكسلة مع وميض لامع. يجب أن تكون النقرات المتكررة ممتعة أيضًا (لا ينبغي أن يتعطل التأثير أثناء التنفيذ).
- في حالة الخمول: يوجد تأثير بسيط وحيوي (وميض خفيف أو وميض عشوائي لبكسلة واحدة) لكي لا يبدو الشعار جامدًا، دون أن يكون مزعجًا.
- احترم إعدادات
prefers-reduced-motion: reduce(في هذه الحالة، اعرض الشعار بشكل ثابت فقط، مع الاحتفاظ بتأثير الوميض عند التحويم).- يعمل البرنامج مع الفأرة واللمس. لا يؤثر على حركة التمرير.
معايير الجودة
- LLPixelLogo. استخدم مسافات بطول 2 لكل تراجع، ويجب ألا يتجاوز طول الكود 400 سطر.
- file:// دون أي أخطاء في وحدة التحكم. قم باختباره بنفسك: اكتب برنامجًا بسيطًا بلغة Node.js أو استخدم أي أداة لفحص الصياغة والوظائف (لا تتوفر مكتبة jsdom؛ لذا استخدم
node --checkواختبر دون الحاجة إلى DOM، مثل حساب عدد الخلايا المضاءة والتأكد من وجود الحلقة والحرفين “L” في المواضع الصحيحة).
كيف تعامل كيمي مع الأمر:
- المحاولة الأولى (الطلب الأصلي دون تعديل): توقفت بعد 8.8 دقائق؛ لم يتم كتابة أي كود للويجت، وتكلفة التنفيذ حوالي 0.31 دولار. قام كيمي بفحص شعار المرجع، ثم فكر في الهندسة والخطط اللازمة لإنشاء الويجت، لكنه لم يكتب أي شيء في النهاية. فشلت محاولة dsh الأولى أيضًا بطريقة مشابهة (حلقة تكرارية استمرت 10 دقائق لرسم صورة نقطية في الذاكرة)، رغم أن الطلب الأصلي كان يسمح برسم الصور يدويًا.
- المحاولة الثانية (نفس الطلب، جلسة جديدة): تم إنشاء ويجت كامل، لكن في المكان الخطأ؛ تكلفة التنفيذ حوالي 0.72 دولار. بعد حوالي ثماني دقائق، كتب كيمي ملفًا باسم
ll-pixel-logo.jsيحتوي على 323 سطرًا، بالإضافة إلى صفحة تجريبية وملف README وملفين للاختبار؛ ثم قام بتشغيل الاختبارات وتعديلها حتى نجحت، وكتب تقريرًا مختصرًا. لكن كل ذلك تم حفظه في مساحة العمل الخاصة بوكيل التنفيذ وليس في المجلد الذي كان يراقبه سكريبتي؛ كما انتهت الجلسة بعد 15 دقيقة دون أن يرد كيمي على الطلب. من مكان مراقبتي، لم تظهر أي نتائج للمحاولة الثانية، لذا لم أنتظرها وبدأت المحاولة الثالثة بعد حوالي سبع دقائق. - المحاولة الثالثة (طلب مختصر مع توجيهات صارمة): استغرقت 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 لكل رسالة في كل جلسة، والتي تم جمعها؛ والمبلغ الناتج للمحاولة الثالثة يتطابق مع ما ورد في إيصالها.
بعد حوالي ساعة، ظهر ويدجت المحاولة الثانية مرة أخرى؛ حيث اكتشف برنامج MiniMax M3 الذي يعمل على نفس الجهاز تلك الملفات، ثم نفذ الاختبارات عليها وأبلغ عنها كأنها من إنتاجه. يوجد تفاصيل هذه القصة في تقرير MiniMax M3، وكلا ويدجتي كيمي موجودان بجانب ويدجت dsh في مسابقة الويدجتس الفنية.
ما أنتجه كيمي، أول 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
prefers-reduced-motion.
يقوم كيمي ببناء كل حرف “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/، بجانب الوصف التفصيلي في ملف BRIEF.md.
للمقارنة، أول 30 سطرًا تقريبًا من ويدجت dsh، كما هو موجود في /assets/uploads/2026/08/deepseek-harness/ll-pixel-logo.js:
/*!
* ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
* Vanilla JS, zero dependencies, no network requests, works from file://.
* <div class="ll-pixel-logo" data-size="320"></div>
* <script src="ll-pixel-logo.js"></script>
* Auto-mounts on .ll-pixel-logo elements; window.LLPixelLogo.mount(el) too.
* Knobs: data-size, data-speed, data-static.
*/
(function (global) {
'use strict';
// ---- 0. palette -----------------------------------------------------
var BLUE = [31, 63, 143]; // #1f3f8f — logo blue
var HI = [46, 168, 255]; // #2ea8ff — hover / repulsion glow
var AMBER = [255, 182, 74]; // #ffb64a — twinkle spark
var CYAN = [0, 230, 207]; // #00e6cf — deep glow
// ---- 1. art: procedural 40x40 raster (no hand-drawn bitmap) ----------
// A cell is lit when it belongs to the ring or to one of the two slanted
// interlocking Ls. Each L is two parallelograms (stem + foot), described by
// top-left (ax,ay), width w, height h, sheared by SLANT (bottom edge shifts
// left): TL=(ax,ay) TR=(ax+w,ay) BL=(ax-SLANT*h,ay+h). The upper-left L's
// foot runs right and tucks under the lower-right L's stem, like the ref.
var GRID = 40; // cells per side
var RING_R = 19.7; // outer ring radius (cells)
var RING_IN = 0.80 * RING_R; // inner ring radius (reference ~0.808R)
var SLANT = 0.453; // shear of stems/feet (~24deg)
var LETTERS = [
{ ax: 15.0, ay: 5.2, w: 4.2, h: 10.6 }, // upper-left L: stem
{ ax: 10.2, ay: 15.8, w: 15.0, h: 3.8 }, // upper-left L: foot
{ ax: 24.7, ay: 13.8, w: 4.2, h: 14.7 }, // lower-right L: stem
{ ax: 18.0, ay: 28.5, w: 15.0, h: 3.8 } // lower-right L: foot
];
window.LLPixelLogo.mount، وكلاهما يلتزم بإعداد prefers-reduced-motion. لكن الثوابت المستخدمة تختلف؛ فـ dsh يستخدم نصف قطر الحلقة الخارجية 19.7، وحلقة داخلية بنسبة 0.80R، بالإضافة إلى زاوية ميل قدرها 0.453 (أي حوالي 24°)؛ بينما يستخدم Kimi القيم 19 و0.82R و20°. كما أن خطوط Kimi أرق؛ فسيقان الحروف وقواعدها بعرض 3 خلايا، بينما سيقان حروف dsh بعرض 4.2 خلايا وقواعدها بارتفاع 3.8 خلايا. ولهذا السبب يضيء شعار Kimi 510 خلايا بينما يضيء شعار dsh 656 خلية. لا يتطابق أي منهما تمامًا مع الشعار المرجعي، لكن كلاهما يبدو كشعار عند النظر إليه للوهلة الأولى. كما قامت محاولة dsh الثانية بكتابة اختبار وحدة باستخدام Node، وبشكل تلقائي أيضًا كتبت سكريبت Playwright؛ بينما طُلب من Kimi في محاولته الثالثة تخطي الاختبارات، ففعل ذلك.
أوامر التحقق التي نفذتها على ويدجت كيمي
لقد أعدت تنفيذ هذه الأوامر في تاريخ 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 (بدون أي عناصر فعلية مثل الكانفاس أو الـ window أو الـ document)، ثم استخدمت الدالة
isLit(col, row)الموجودة في الملف وطبقتها على كل خلية في شبكة 40×40، وقمت بحساب عدد الخلايا المضاءة حسب الربع الذي تقع فيه. وقد بلغ عدد الخلايا المضاءة 510 خلية: 124 في الربع العلوي الأيسر، و103 في الربع العلوي الأيمن، و160 في الربع السفلي الأيسر، و123 في الربع السفلي الأيمن. - فحص عملية التثبيت (mount). باستخدام نفس محاكاة DOM، تأكدت من أن الملف يُعرّف الكائن
window.LLPixelLogo، وأن استدعاء الدالةmount()على عنصر وهمي يعيد كائنًا بدلاً من إحداث خطأ.
الحلقة الوحيدة (أي الخلايا التي تقع مراكزها بين 0.82R وR، حيث R = 19) تحتوي على 352 خلية من أصل 510 خلية؛ مما يترك 158 خلية للحرفين “L”. النصوص البرمجية المستخدمة هي من إعدادي أنا وليست من إعداد كيمي، وهي مجرد اختبارات سريعة وليست اختبارات تُجرى في المتصفح؛ فالصفحة التي تقرأها الآن هي نتيجة الاختبار الذي أُجري في المتصفح.
المصائد (تلك التي واجهتها فعلاً)
- مصطلح "متوافق مع OpenAI" لا يعني بالضرورة "متوافق مع مكون Codex". واجهة
/v1/chat/completionsالخاصة بـ Moonshot تعمل بشكل جيد كمزود خدمة لـ OpenClaw، لكن إضافة Codex harness تقبل فقط المسارات التي يكون فيها معرف المزودopenai. إذا كنت بحاجة تحديدًا إلى استئناف سير العمل في Codex ووصلة الأدوات الديناميكية، فإن المسار باء (الجسر الخاص بـ codex-router) هو الخيار الوحيد. يُرجى الرجوع إلى مقارنة المسار ألف مقابل المسار باء أعلاه.
compat تحل محل الكتلة الأصلية، ولا تدمج معها. إذا أضفت compat إلى إدخال النموذج لرفض استخدام temperature، فعليك أيضًا نسخ حقول reasoning-effort الخاصة بالإضافة؛ وإلا فستفقدها دون أن تلاحظ.contextTokens: 262144 الخاص بي فيعني أن الجلسات تقتصر على 256 ألف رمز فقط. يجب رفع هذا الحد عمدًا، وليس بالصدفة.TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop.، مع ذكر مجلد الوجهة بوضوح. لا يزال نموذج K3 يتعامل مع هذا التوجيه؛ لكنه لم يعد يخطط إلى ما لا نهاية. بغض النظر عن حالة الخروج التي يُظهرها النموذج، يجب النظر إلى ما كتبه خلال الجلسة.fizz.py، وكان تنفيذ الملف صحيحًا. عند إعادة المحاولة، جاء الرد “تم إنشاؤه وتنفيذه بالفعل.”، وكانت هذه هي المعلومة الوحيدة التي تشير إلى اكتمال التنفيذ. كتب البرنامج كل بيانات JSON الخاصة بكل عملية تنفيذ في نفس الملف، لذا تم الكتابة فوق بيانات العملية الفاشلة؛ إلا أن كود الخروج والنص النهائي لا يزالان موجودين في سجل الجلسة التي أجرت الاختبار. الجدول يستخدم بيانات عملية تنفيذ لاحقة وناجحة في جلسة جديدة.cd للانتقال إلى مجلد المهمة، مما أدى إلى كتابة الملفات في مكان خاطئ، واضطررت لإعادة تشغيل جميع المهام الخمس.ماذا يعني ذلك بالنسبة لي؟
في هذه المهام الخمس، كان أداء Kimi K3 صحيحًا لكن بطيئًا ومكلفًا. أما بالنسبة للمهام الصغيرة، فقد قام برنامج dsh على نظام V4-Flash بنفس العمل في حوالي تسعة أضعاف الوقت الأقل وبثمن يبلغ حوالي 1/48 من تكلفة Kimi K3. بعد هذا الاختبار، نقلت وكيل العمليات الخاص بي من Kimi إلى MiniMax-M3؛ بينما ظل Kimi K3 في مكانه الأصلي: خلف وكيل المراجعة لديّ، حيث أن الحصول على إجابة أبطأ وأكثر دقة يستحق الدفع مقابله.
أما المسار “ب”، أي جسر codex-router الذي يربط بين النظام والخادم الفعلي لتطبيق Codex، فلا يزال مجرد فكرة على الورق حتى أطمئن إلى ما يمكن أن يشاركه homeScope: "user". وحتى ذلك الحين، فإن استخدام Kimi كوكيل برمجة يعني أنه يقود الحلقة البرمجية الأصلية لـ OpenClaw، تمامًا مثل أي نموذج آخر يعمل ضمن بيئة OpenClaw.
مرتبط: DeepSeek Harness (dsh) (الأداة التي قارنتها به، وهي مصدر الاختبار والمعايير المستخدمة)، MiniMax M3 (نفس الأداة لكن على النموذج الذي يستخدمه وكيل العمليات لديّ اعتبارًا من تاريخ 2026-09-11)، Reasonix (نموذج قديم؛ تم إيقاف استخدامه في نظامي بتاريخ 2026-09-09)، وما هي التكاليف الفعلية لاستخدام وكلاء الذكاء الاصطناعي لديّ (مقارنة شاملة للأسعار).