مينيماكس إم3 كوكيل برمجة من نوع OpenClaw: خمس مهام مقابل كيمي ك3 وdsh، بالإضافة إلى عنصر واجهة لم يتمكن من بنائه.

الآن، يقوم MiniMax M3 بتشغيل وكيل العمل لديّ في OpenClaw. أعطيته نفس المهام البرمجية الخمس الصغيرة التي كلفت بها Kimi K3 في وقت سابق من ذلك الصباح، وقد أنجزها جميعًا في وقت يبلغ تقريبًا نصف الوقت الذي استغرقه Kimi، وبتكلفة تعادل . كنت أرغب أيضًا في مقارنة كيفية قيام كل منهما بإنشاء نسخة فنية من شعار الموقع بناءً على نفس التعليمات المكتوبة؛ لكن هذا الجزء لم ينجح في الاختبار: فالكود الذي ظننت أنه من إنتاج MiniMax كان في الحقيقة من تأليف Kimi، وقد عثر MiniMax على ملفات Kimi وادعى أنها من إنتاجه. التفاصيل موضحة أدناه، لأن طريقة حدوث ذلك هي الجزء الأكثر فائدة في هذا المقال.

ما هو مزود الخدمة من نوع Minimax في OpenClaw فعليًا؟

كنت مخطئًا في مسودة سابقة، لذا إليكم المعلومات المستمدة من الكود المثبت وإعداداتي الشخصية.

• البروتوكول ونقطة النهاية. يقوم البرنامج الإضافي الخاص بـ Minimax بإنشاء مزودي الخدمة باستخدام api: "anthropic-messages" وعنوان URL الأساسي https://api.minimax.io/anthropic (يمكن للمتغير MINIMAX_API_HOST تغيير المضيف). كما يوفر MiniMax واجهة برمجية متوافقة مع OpenAI على العنوان https://api.minimax.io/v1، لكن البرنامج الإضافي في OpenClaw لا يستخدمها.
• وجود مزودين للخدمة فقط، وليس ثلاثة. minimax هو المزود الرئيسي في البرنامج الإضافي؛ ملف openclaw.json الخاص بي يقوم فقط بتعديل قائمة النماذج المستخدمة، بينما يتم تحديد نوع واجهة برمجة التطبيقات وعنوان URL الأساسي ومعلومات المصادقة من قبل البرنامج الإضافي نفسه. أما minimax-portal فهو المزود الثاني (نسخة OAuth من مزود Minimax)؛ أقوم بتعريفه يدويًا باستخدام نفس نقطة النهاية، مع تحديد سعة سياقية تبلغ 1,000,000 رمز للمهام الطويلة. ولا يُعد minimax-cn مزودًا ثالثًا؛ بل هو مجرد اسم بديل لمعلومات المصادقة الخاصة بـ minimax لمنطقة الصين، حيث يكون عنوان نقطة النهاية https://api.minimaxi.com/anthropic.
• مفتاح الوصول. هو متغير بيئي؛ يقرأ البرنامج الإضافي قيمة المتغير MINIMAX_API_KEY (بالإضافة إلى بعض المتغيرات الأخرى المتعلقة بالرسوم)، ويشير سطر minimax-portal الخاص بي إليه على شكل النص الحرفي "${MINIMAX_API_KEY}". لا توجد أي معلومات متعلقة بـ MiniMax في مستودع الأسرار الخاص بـ OpenClaw.
• إعدادات النماذج. يوفر كتالوج البرنامج الإضافي للنموذج M3 سعة سياقية تبلغ 1,000,000 رمز، بالإضافة إلى إعداد واحد فقط من نوع compat وهو codeMode: "preferred" (وهو وضع الكود في OpenClaw، ولا علاقة له بـ Codex). لا يوجد خيار لتعديل درجة الحرارة في إعدادات هذا النموذج.
• الأسعار. يحدد البرنامج الإضافي سعر استخدام النموذج M3 بـ 0.60 دولار للإدخال، و2.40 دولار للإخراج، بالإضافة إلى 0.12 دولار لكل مليون رمز يتم قراءته من الذاكرة المؤقتة؛ وهذه الأسعار هي التي تُستخدم في حساب قيمة usage.cost.total ضمن ملف JSON. لم أقم بالتحقق من هذه الأسعار مقارنةً بصفحة الأسعار الخاصة بـ MiniMax.

ليس Codex

هذا هو حلقة الوكيل الخاصة بـ OpenClaw، وليست خادمة تطبيقات Codex التابعة لـ OpenAI. يمتلك OpenClaw مكون إضافي لـ Codex، لكن عملية التحقق من المسار (configuredModelRouteNeedsCodex) تُرجع قيمة false لأي مزود خدمة لا يتطابق معرفه مع openai؛ لذلك فإن مسار minimax/MiniMax-M3 لا يُعتبر مؤهلاً أبداً. تشير بيانات JSON الناتجة عن كل تشغيل إلى حلقة الوكيل التي تم استخدامها: agentHarnessId: "openclaw". على أي حال، لم يتم تثبيت مكون Codex الإضافي على جهازي.

لاستخدام M3 عبر Codex، سيتطلب الأمر وجود وسيط محلي مثل codex-router، بالإضافة إلى السماح لمكون Codex الإضافي بالوصول إلى مجلد ~/.codex الخاص بي، بحيث يشاركه جميع الوكلاء على الجهاز. لم أقم بذلك؛ فكل ما ورد في هذا المقال يتعلق بالحلقة الأصلية لـ OpenClaw.

الإعداد

الإصدارات التي استخدمتها:

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2
$ openclaw plugins list --json | jq '[.plugins[] | select(.enabled)] | length'
35

الخطوة الأولى: المفتاح

يأتي ملحق Minimax مع إصدار OpenClaw 2026.9.2، وهو مفعّل في تثبيتي. يقوم الملحق بقراءة المفتاح من المتغير MINIMAX_API_KEY؛ لذا يجب وضعه في أي بيئة يعمل فيها البوابة الخاصة بك (سواءً عبر ملف EnvironmentFile في systemd، أو ملف إعدادات launchd، أو حتى عبر shell)، ثم أعد تشغيل البوابة باستخدام الأمر openclaw gateway restart. لا تقم بلصق المفتاح مباشرةً في ملف openclaw.json. وإذا احتاج صف من بيانات المزود إلى ذكر اسم هذا المتغير، فاكتب المرجع "${MINIMAX_API_KEY}" بدلاً من القيمة الفعلية للمفتاح.

الخطوة الثانية: توجيه وكيل العمل نحو M3

هناك جزئان في ملف openclaw.json. أولاً، سلسلة النماذج الخاصة بالوكيل:

"agents": { "entries": { "worker": { "model": {
  "primary": "minimax/MiniMax-M3",
  "fallbacks": ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"]
} } } }

ثم، اختياريًا، يمكن وضع قيد على صف النموذج. هذا هو الإدخال من إعداداتي الشخصية؛ لا يحتوي على أي من api أو baseUrl أو apiKey، لأن هذه القيم تأتي من البرنامج الإضافي:

"models": { "providers": { "minimax": { "models": [ {
  "id": "MiniMax-M3", "name": "MiniMax M3",
  "reasoning": true, "input": ["text", "image"],
  "contextWindow": 1000000, "contextTokens": 262144, "maxTokens": 128000,
  "compat": { "codeMode": "preferred" }
} ] } } }

أكرر هنا إدخال النموذج بأكمله الخاص بالبرنامج الإضافي بدلاً من إضافة مفتاح واحد فقط؛ وذلك لأن التعديل الجزئي على هذا الإدخال في الماضي أدى إلى حذف خاصية reasoning: true بشكل صامت، مما جعل M3 يعمل دون تفعيل وظيفة التفكير لعدة أيام. أما القيد نفسه فهو: 262,144 من أصل مليون عنصر في الكتالوج؛ وهذا يضمن بقاء جلسات العمل الطويلة صغيرة الحجم بدلاً من أن تزداد بلا حدود.

الخطوة 3: اختبار التحقق

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

$ openclaw agent --agent worker --model minimax/MiniMax-M3 \
    --session-key agent:worker:bench-pong-1 \
    -m "Reply with exactly: PONG." --json \
  | jq '{harness: .result.meta.agentMeta.agentHarnessId,
         provider: .result.meta.executionTrace.winnerProvider,
         model: .result.meta.executionTrace.winnerModel,
         contextTokens: .result.meta.agentMeta.contextTokens,
         usage: (.result.meta.agentMeta.usage | {input, output, cacheRead, cost: .cost.total})}'
{
  "harness": "openclaw",
  "provider": "minimax",
  "model": "MiniMax-M3",
  "contextTokens": 262144,
  "usage": {
    "input": 16384,
    "output": 184,
    "cacheRead": 128,
    "cost": 0.01028736
  }
}

harness: "openclaw" هو الحلقة البرمجية الأصلية المستخدمة. winnerModel يخبرك بالنموذج الذي قدم الإجابة الأساسية وليس النموذج الاحتياطي. contextTokens يُظهر أن حد الاستخدام قد تم تطبيقه فعلاً. أما الـ 16,384 رمزًا إدخاليًا غير المخزن في الذاكرة المؤقتة، فهي في الغالب عبارة عن نص التوجيهات الخاص بالنظام وتعريفات الأدوات التي ترسلها كل جلسة جديدة في دورتها الأولى؛ ولهذا السبب حتى مهمة PONG تستلزم دفع تكلفة. التكلفة المذكورة هي السعر القياسي للإضافة، وليست التكلفة التي يفرضها أي خطة اشتراك ثابتة.

مقارنة جانبًا إلى جانب: MiniMax M3، Kimi K3، وdsh

اثنان من هذه النماذج يُستخدمان في تشغيل حلقة العمل الخاصة بـ OpenClaw. أما الثالث، وهو DeepSeek Harness (dsh)، فهو وكيل البرمجة الخاص بشركة DeepSeek والذي يمتلك حلقة عمل خاصة به. كما أن المقالات السابقة في هذه السلسلة تضمنت أيضًا عمودًا مخصصًا لـ Reasonix؛ لكنني لم أقم باختبار أداء Reasonix بدون واجهة مستخدم، وقد توقفت عن استخدامه في إعداداتي في تاريخ 2026-09-09، لذا فهو غير موجود هنا.

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

المهام الخمس هي نفسها المذكورة في مقالة dsh: الرد بـ “PONG”؛ كتابة وتشغيل برنامج FizzBuzz؛ إصلاح خطأين بحيث تمر اختبارات الوحدة دون تغيير أي شيء في الاختبارات؛ تلخيص قاعدة الكود المكونة من ست وحدات في أقل من 150 كلمة؛ إعادة تسمية دالة عبر ملفات متعددة واختبارات، ثم التأكد من نجاح الاختبارات. تم تنفيذ جميع المهام الثلاثة في تاريخ 2026-09-11. استغرقت عمليات التنفيذ بواسطة Kimi ما بين الساعة 07:46 و07:54 بتوقيت اليابان، وذلك عند إعداد --thinking max. أما أرقام dsh فهي نتائج تنفيذ ثاني بعد تفعيل ذاكرة التخزين المؤقت؛ بينما استغرقت عمليات التنفيذ بواسطة MiniMax ما بين الساعة 09:11 و09:14 بتوقيت اليابان، وذلك باستخدام إعداد التفكير التكيفي الافتراضي في OpenClaw.

الاختلافات كانت كالتالي:

• ملفات مختلفة للاختبار. أنشأ كل تنفيذ مجلدات عمل خاصة به. إصلاح الأخطاء تضمن إصلاح أخطاء مختلفة (Kimi: add وis_even في وحدة واحدة؛ MiniMax: add وsubtract). أما مهمة إعادة التسمية فقد شملت دوالاً مختلفة (Kimi: تغيير اسم calculate_total إلى compute_total في ثلاث وحدات وملف اختبار؛ MiniMax: تغيير اسم area_of_rect إلى rect_area في ثلاث وحدات وملف اختبار). الشكل العام للملفات متطابق، لكن محتواها مختلف.
• إعادة التنفيذ. استخدم MiniMax جلسة عمل واحدة مستمرة لتنفيذ جميع المهام الخمس في المحاولة الأولى، لكن ذلك أدى إلى نتائج خاطئة؛ لذا أعدت تنفيذ جميع المهام باستخدام مفاتيح جلسات جديدة. احتاج برنامج FizzBuzz إلى محاولتين إضافيتين، لأن البرنامج كان يكتب ملف fizz.py في مساحة عمله الخاصة بدلاً من مجلد العمل المؤقت. الجدول يعرض نتائج المحاولة الرابعة لتنفيذ FizzBuzz. كما أُعيد تنفيذ مهمتي Kimi المتعلقتين بـ FizzBuzz وإصلاح الأخطاء؛ حيث انتهت المحاولة الأولى من FizzBuzz برسالة تتعلق بتقييد معدل الاستخدام، بينما تبين أن الملفات التي كان يجب إصلاحها قد تم تصحيحها بالفعل في محاولة سابقة.

المعدلات المذكورة هي لكل مليون توكن، بترتيب: التوكنات غير المخزنة في الذاكرة / الناتج / التوكنات المسترجعة من الذاكرة. التكلفة الإجمالية هي مجموع قيم usage.cost.total لكل مهمة، كما أن ضرب إجمالي عدد التوكنات في المعدلات المذكورة يعطي نفس النتيجة.

ما يوضحه الجدول:

• نجاح جميع المهام. تحققت من كل نتيجة على القرص الصلب: مخرجات برنامج FizzBuzz، نجاح اختبارات pytest، عدد الكلمات في التلخيص، وعدم وجود أي أسماء قديمة بعد عملية إعادة التسمية.
• كان MiniMax أسرع بمرتين تقريباً من Kimi وأرخص بنحو 4 مرات وفقاً لأسعار القائمة (309.9 ثانية مقابل 159.2 ثانية؛ 0.531 دولار مقابل 0.125 دولار). كان Kimi يعمل بأقصى إعدادات التفكير، وهو ما يفسر الفارق.
• كان أداء dsh على V4-Flash أسرع بنحو 4.5 مرات من MiniMax وأرخص بنحو 11 مرة في تنفيذ نفس المهام.
• تلعب ذاكرة التخزين المؤقت دوراً أساسياً. استرجع MiniMax 5.2 توكن من الذاكرة مقابل كل توكن غير مخزن؛ وفقاً لأسعار القائمة، فإن تكلفة استرجاع التوكنات من الذاكرة أقل بنسبة 80% من تكلفة إدخالها دون تخزين. لو تم احتساب هذه التوكنات كمدخلات غير مخزنة، لكانت التكلفة حوالي 0.34 دولار بدلاً من 0.125 دولار.
• لم يتم احتساب عمليات إعادة التنفيذ في الأرقام الإجمالية. بلغ إجمالي تكلفة جميع محاولات MiniMax الاختبارية، بما في ذلك المحاولات الفاشلة، 0.28 دولار وفقاً لأسعار القائمة، واستغرقت 321 ثانية.

اختبار الويدجت، وتصحيح بسيط

كان “الاختبار الممتع” في مقال dsh عبارة عن ويدجت على طراز الرسوم البيكسلية لشعار هذا الموقع، تم إنشاؤه بناءً على وصف مكتوب. أردت الحصول على نفس الوصف من كيمي ومينيماكس. وإليكم الوصف الذي تلقاه كل نموذج:

ملخص: عنصر واجهة تفاعلي لشعار LaserLloyd بأسلوب فن البكسلات

قم بإنشاء نسخة فنية من شعار LaserLloyd بأسلوب البكسلات يمكن تضمينها في أي مكان (انظر reference-logo.png: حلقة زرقاء سميكة باللون #1f3f8f على خلفية بيضاء، تحتوي على حرفي “L” كبيرين مائلين ومترابطين؛ قاعدة الحرف “L” العلوي الأيسر تقع أسفل ساق الحرف “L” السفلي الأيمن، وكأن الحرفين مرصوصان بشكل قطري).

المخرجات المطلوبة (كلها في هذا المجلد)

1. ll-pixel-logo.js — ملف جافاسكريبت بسيط، لا يعتمد على أي مكتبات أو خطوات بناء أو طلبات شبكة. يمكن لأي صفحة تضمينه عبر: <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) للاستخدام.
2. index.html — صفحة تجريبية تعرض العنصر بثلاثة أحجام مع وصف مختصر للتفاعلات المتاحة.
3. README.md — شرح حول كيفية التضمين، التفاعلات المتاحة، بالإضافة إلى خصائص العنصر (السمات data-).

التفاصيل الفنية للتصميم

• لا ترسم التصميم يدويًا كصورة نقطية (لا تستخدم سلاسل من الرموز مثل ‘#’ أو ‘.’؛ ذلك بطيء وعرضة للأخطاء). بدلًا من ذلك، أنشئ التصميم برمجيًا من الهندسة: توجد دالة isLit(col,row) تعيد القيمة true إذا كانت الخلية ضمن: (أ) الحلقة الزرقاء حيث تكون المسافة عن المركز بين 0.82R و R، و(ب) الحرفين “L” المائلين، كل منهما مكون من مستطيلين متوازيين؛ قاعدة الحرف الأول تقع أسفل ساق الحرف الثاني كما في الشعار المرجعي. يجب ضبط القيم الثابتة بعناية لتظهر الصورة بشكل صحيح عند حجم 200 بكسل. يتم حساب الخلايا المضاءة مرة واحدة فقط عند تفعيل العنصر.
• لوحة الألوان: اللون الأزرق للشعار #1f3f8f؛ اللون الأزرق الفاتح للتأثيرات #2ea8ff؛ اللون العنبري #ffb64a؛ اللون السماوي #00e6cf؛ الخلفية شفافة.

التفاعلات (الجزء الأساسي من التمرين – اجعلها ممتعة)

• حركة الماوس/اللمس: تتفاعل البكسلات القريبة من المؤشر بشكل فيزيائي؛ فتُدفع بعيدًا عنه كأنها سائلة أو تتماسك مغناطيسيًا، ثم تعود إلى موضعها مع تأثير تخفيفي؛ أثناء الحركة تتوهج البكسلات نحو اللونين #2ea8ff و#00e6cf. يجب أن يكون التفاعل سلسًا بسرعة 60 إطارًا في الثانية عبر requestAnimationFrame دون أي تقطع.
• النقر/اللمس: يجب أن يكون هناك تأثير مبهر ومُرضٍ. اختر تأثيرًا واحدًا قويًا ونفذه بإتقان؛ مثل تحطم الشعار إلى بكسلات تتطاير بفعل الجاذبية ثم تعود لتشكل الشعار مجددًا (يستغرق ذلك حوالي 1.5–2 ثانية)، أو ظهور “ليزر” يمر عبر الشعار ويُعيد رسمه بكسلة بكسلة مع شرارات متوهجة. يجب أن تكون النقرات المتكررة ممتعة أيضًا (لا ينبغي أن يتوقف التأثير أثناء التنفيذ).
• الحالة الساكنة: يوجد تأثير بسيط وخفيف (تلألؤ بطيء أو وميض عشوائي للبكسلات) لإعطاء إحساس بالحياة دون تشتيت الانتباه.
• يجب احترام خاصية prefers-reduced-motion: reduce؛ في هذه الحالة يتم عرض الشعار بشكل ثابت مع توفير تأثير التوهج عند التحويم فقط.
• العنصر يعمل مع الماوس واللمس دون أي تدخل في حركة التمرير.

معايير الجودة

• LLPixelLogo. استخدم مسافتين للتبويب، ويجب ألا يتجاوز عدد الأسطر 400 سطرًا.
• file:// دون أي أخطاء في وحدة التحكم. قم باختباره بنفسك: اكتب برنامجًا صغيرًا بلغة Node.js أو افتح الملف بأي وسيلة متاحة لديك لفحص الصياغة وتشغيل الوحدة (لا تتوفر أداة jsdom؛ استخدم node --check وأجر اختبارًا خاليًا من DOM للتأكد من صحة البكسلات المضاءة، مثل التحقق من وجود الحلقة والحرفين “L” في الأماكن الصحيحة).

ما الذي حدث، بالترتيب، وفقًا لسجلات الجلسة:

• كيمي، المحاولة الأولى (نفس التعليمات المذكورة أعلاه): استغرقت 8.8 دقائق في التفكير، لم يتم كتابة أي كود للويدجت، وتوقفت العملية. تكلفة هذه المحاولة حوالي 0.31 دولار.
• كيمي، المحاولة الثانية (نفس التعليمات): كتب كودًا مكونًا من 323 سطرًا باسم ll-pixel-logo.js، بالإضافة إلى صفحة تجريبية وملف README وملفين للاختبار؛ ثم قام بتشغيل الاختبارات وتعديل الكود حتى نجحت جميع الاختبارات. كتب كل ذلك، بالإضافة إلى تقرير تشغيل مختصر، في مساحة العمل الخاصة بوكيل المعالجة وليس في المجلد الذي كنت أراقبه؛ ووصلت الجلسة إلى حد 15 دقيقة قبل أن يرد. لذلك ظننت أن المحاولة الثانية لم تُنتج أي شيء؛ تكلفتها حوالي 0.72 دولار.
• كيمي، المحاولة الثالثة (باستخدام قيود أكثر صرامة: كتابة الملفات في استدعاء أداة واحد فقط، دون أي تخطيط، ودون تشغيل أمر node --check): استغرقت 7.4 دقائق، وتم إنشاء ويدجت مكون من 397 سطرًا في المجلد المناسب؛ تكلفتها 0.47 دولار. هذا هو الويدجت الذي يظهر في مقالة كيمي.
• مينيماكس (نفس التعليمات، بعد ساعة من المحاولات السابقة، باستخدام نفس وكيل المعالجة): استغرقت العملية 59.3 ثانية، وتم إجراء 24 استدعاءً للأدوات؛ تكلفتها 0.13 دولار وفقًا للسعر المعلن. وجد ملفات المحاولة الثانية التي أنشأها كيمي لا تزال موجودة في مساحة العمل المشتركة، فقرأ جميع الملفات الخمسة بالإضافة إلى تقرير التشغيل الذي أعده كيمي، ثم قام بتشغيل الاختبارات؛ وأجاب قائلاً: "تم إنشاء وتحقق من صحة مجموعة الويدجتات بالكامل". لم يكتب هذا الوكيل أي سطر من كود الويدجت؛ الملفات الوحيدة التي أنشأها كانت تقرير التشغيل الخاص به وملف الحالة فقط.

لقد أخذت ذلك الرد على محمل الجد، وكان المسودة الأولى من هذه المقالة تصف الملف بأنه "أول محاولة لبرنامج MiniMax في إنشاء ويدجت، استغرقت أقل من دقيقة". ويُظهر سجل الجلسة عملية write لنفس الملف تمامًا في الساعة 08:11 بتوقيت اليابان خلال جلسة محاولة-2 الخاصة بـ Kimi، والملف الموجود على هذا الموقع مطابق له تمامًا من حيث المحتوى. لذا، بالنسبة لبرنامج MiniMax في هذه المهمة، ليس لدي أي نتيجة حتى الآن. الخطوة المنطقية التالية هي إعادة تشغيله في مجلد فارغ. أما بالنسبة لـ Kimi، فالقصة أفضل مما وصفتها في البداية: فقد نجحت محاولته الثانية؛ لكنه وضع الملفات في المكان الخطأ.

هنا يوجد ويدجت “Kimi’s Attempt-2”، الذي يعمل في هذه الصفحة. إنه الملف الذي أخطأت في تسميته في البداية:

أول 30 سطرًا تقريبًا منه:

/* ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 *
 * Embed:
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 *
 * One file, no dependencies, no build step, no network requests.
 * The 40x40 bitmap is rasterised procedurally from geometry (a ring plus
 * two interlocking italic Ls) — never a hand-drawn bitmap.
 *
 * Interactions:
 *   - pointer move : pixels are pushed away from the cursor, then spring
 *                    back with damping; displaced pixels glow blue -> cyan
 *   - click / tap  : the logo shatters outward with gravity + floor bounce,
 *                    then reassembles itself (~1.8 s)
 *   - idle         : occasional pixel twinkle (amber / cyan)
 * Honours prefers-reduced-motion: static logo, hover glow only.
 *
 * Global exported: window.LLPixelLogo (also module.exports under node,
 * so the bitmap can be unit-tested without a DOM).
 */
(function () {
  'use strict';

  /* ---------------- palette ---------------- */
  var BLUE  = [31, 63, 143];    // #1f3f8f logo blue
  var HI    = [46, 168, 255];   // #2ea8ff highlight blue
  var AMBER = [255, 182, 74];   // #ffb64a
  var CYAN  = [0, 230, 207];    // #00e6cf

محاولة كيمي الثالثة، وهي النسخة الموجودة في مقال كيمي، تبدأ كما يلي:

/*!
 * 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

/*!
 * 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
  ];

كل من هذه الثلاثة تقوم برسم حلقة بالإضافة إلى حرفي “L” مائلين بناءً على الهندسة المستخدمة، كما تعرض window.LLPixelLogo.mount وتحترم إعداد prefers-reduced-motion. لقد قمت بعدّ الخلايا المضاءة عن طريق تقييم خاصية isLit لكل خلية في شبكة مكونة من 40×40 خلية:

• كيمي، المحاولة الثانية: RING_R = 19.4، القطر الداخلي 0.82R، SHEAR = 0.42 (حوالي 22.8°)، بالإضافة إلى دالة مساعدة من نوع inL تتعامل مع القدم والجزء المائل في اختبار واحد. 602 خلية مضاءة.
• كيمي، المحاولة الثالثة: R_OUT = 19، القطر الداخلي 0.82R، SLANT = tan 20° (حوالي 0.364)، وهناك دالة مساعدة من نوع makeL تعيد كلاً من الجزء المائل والقدم. 510 خلايا مضاءة.
• dsh: RING_R = 19.7، القطر الداخلي 0.80R، SLANT = 0.453 (حوالي 24°)، بالإضافة إلى مصفوفة من أربعة عناصر تُسمى LETTERS. 656 خلية مضاءة.

لا يوجد أي من التصاميم الذي يتطابق تمامًا مع الشعار المرجعي؛ الطلب فقط كان أن يبدو التصميم كالشعار عند حجم 200 بكسل، وكل الثلاثة تصاميم تحقق ذلك. سأقضي عشر دقائق في ضبط الثوابت قبل إرسال أي منهم.

ما الذي قمت بإعادة التحقق منه في عنصر الويدجت “المحاولة-2”

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

$ wc -l ll-pixel-logo.js
323 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "syntax ok"
syntax ok
$ node test-bitmap.js | tail -1
ALL PASS
$ node test-smoke.js | tail -1
SMOKE PASS

test-bitmap.js يقوم بـ 18 فحصًا: التأكد من وجود الحلقة في النقاط الأساسية وغيابها في الزوايا والوسط، وتواجد كل جزء من حرف “L” في ربعه المخصص، بالإضافة إلى التحقق من اتجاه الميل وعدد الخلايا المضاءة الذي يجب أن يكون بين 540 و670. أما test-smoke.js فيقوم بـ 10 فحوصات: تثبيت الويدجت باستخدام DOM مزيف، إعادة التثبيت دون أي تأثير سلبي، وجود خاصية role="img" وسمة aria-label، تشغيل 300 إطار مع تحريك المؤشر والنقر مرتين (الثانية أثناء التشغيل)، حالة الجسيمات المستقرة بعد ذلك، عودة الشعار إلى مكانه الأصلي، وجود مساحة تخزين بعرض 640 بكسل عند نسبة devicePixelRatio تساوي 2، بالإضافة إلى تنفيذ دالة unmount() بشكل صحيح. هذه هي اختبارات كيمي نفسه، وهي لا تُعد تحققًا مستقلاً؛ فقد قام كيمي بتعديل ملف test-bitmap.js بعد التشغيل الأول، حيث نقل صناديق الفحص وضبط النطاق المسموح به لعدد الخلايا المضاءة إلى 540–670 بعد أن قاس القيمة 602، حتى تمر جميع الاختبارات بنجاح. إن نجاح هذه الاختبارات يعني فقط أن الويدجت واختباراته متوافقة مع بعضها، وليس أن هذه الاختبارات تحدد معيارًا ثابتًا للتحقق. أما حساباتي الشخصية فتُظهر وجود 602 خلية مضاءة، موزعة بأعداد 196 / 137 / 101 / 168 على الربع الأيسر العلوي، واليمين العلوي، والأيسر السفلي، واليمين السفلي على التوالي.

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

• الجلسات المستمرة تفسد نتائج الاختبارات. الأمر openclaw agent --agent worker -m "…" يعيد استخدام جلسة العامل ما لم تحدد مفتاح جلسة جديد باستخدام الخيار --session-key. في أول تشغيل لـ MiniMax، افترض البرنامج أن ملف FizzBuzz موجود بالفعل ورفض كتابته؛ بينما قال برنامج إصلاح الأخطاء إن الاختبارات قد اجتازتها بالفعل، أما برنامج التلخيص فقد لخص محتويات مجلد إصلاح الأخطاء الخاص ببرنامج Kimi بدلاً من مجلده الخاص. استخدام مفتاح جلسة فريد لكل مهمة --session-key حل هذه المشكلة.
• تعليمات العامل تغلب على التعليمات الواردة في الطلب بشأن مكان حفظ الملفات. تعليمات عاملي تطلب منه حفظ المخرجات الطويلة في مساحة العمل الخاصة به، وهذا ما حدث فعلاً رغم وجود تعليمات صريحة بكتابة الملف في مجلد معين. في المحاولة الثالثة، ذكر البرنامج أنه كتب الملف في مجلد مؤقت؛ لكن الطابع الزمني للملف يشير إلى أنه وُضع في مساحة العمل. أما في المحاولة الرابعة، فقد تم حفظ الملف بشكل صحيح رغم استخدام مسار مطلق وتعليمات واضحة.
• استخدام مساحة عمل مشتركة يؤدي إلى تداخل البيانات بين التشغيلات. في المثال السابق، ظلت الملفات التي تركها برنامج Kimi في مساحة العمل لمدة ساعة كاملة، واعتبرها برنامج MiniMax ملكاً له. لذا يجب تخصيص مجلد فارغ لكل تشغيل، والتحقق من ما كتبه البرنامج فعلياً (من خلال الطوابع الزمنية أو استدعاءات write) وليس مما يدعي أنه كتبه.
• خروج البرنامج بكود خطأ لا يعني فشل المهمة. في تشغيل Kimi، انتهت أول محاولة لتنفيذ FizzBuzz بكود الخطأ 1، وظهر رسالة تفيد بأنه لم يتم العثور على نموذج مناسب، بالإضافة إلى تحذير بحدود استخدام واجهة API؛ ومع ذلك فقد تم بالفعل إنشاء الملف fizz.py وكان يعمل بشكل صحيح. فقط في المحاولة الثانية ظهرت إشارة إلى إتمام المهمة. لذا يجب التحقق من الملفات نفسها وليس من كود الخروج فقط.
• يُذكر في الكتالوج أن الحد الأقصى للرموز هو مليون، لكنني أستخدم 262,144 رمزاً فقط. هذا هو الإعداد الذي وضعته لنفسي عبر contextTokens، ويؤكد الخيار agentMeta.contextTokens في ملف JSON ذلك. يمكن رفع هذا الحد إذا احتجت إلى نافذة زمنية أطول؛ حيث أستخدم الصف minimax-portal لتحقيق ذلك في بعض المهام.
• الأسعار المذكورة في الخطة الثابتة هي أرقام افتراضية، لكنها مفيدة للغاية. يقوم OpenClaw بملء قيمة usage.cost.total بناءً على أسعاره الداخلية، بغض النظر عن المبلغ الفعلي الذي تدفعه؛ لذا فهي مفيدة للمقارنة بين النماذج لكنها لا تمثل فاتورة حقيقية.

ماذا يعني ذلك بالنسبة لي؟

نموذج MiniMax M3 هو النموذج الرئيسي المستخدم في وكيل العمل الخاص بي، بينما يُستخدم كل من DeepSeek V4-Flash وV4-Pro كخيارات احتياطية. أما نموذج Kimi K3 فلا يدخل في هذه السلسلة؛ أستخدمه في مكان آخر، لوكيل المراجعة الخاص بي. في هذه المهام، استطاع نموذج M3 إعادة التسمية في 89.9 ثانية بتكلفة قدرها 0.058 دولار وفقًا للسعر المعلن، بينما استغرق Kimi 128.9 ثانية بتكلفة 0.180 دولار؛ كما تمكن M3 من إصلاح الأخطاء في 41.0 ثانية بتكلفة 0.025 دولار، مقابل 86.6 ثانية و0.114 دولار لـ Kimi. أما أداة dsh على نموذج V4-Flash فكانت أسرع وأرخص من كلا النموذجين في كل المهام.

طلب العمل المتعلق بأداة MiniMax لا يزال مفتوحًا؛ عند إعادة تشغيله، يحصل على مجلد فارغ، وسأقرأ أوامر write المسجلة في الجلسة قبل الاطلاع على التقرير الخاص به.

مرتبط بذلك: Kimi K3 كوكيل برمجة (الجانب المتعلق بـ Kimi في هذا المقارنة)، أداة DeepSeek Harness (dsh) (المهام الخمس وطلب العمل الأصلي)، Reasonix (تمت مقارنته في مقالات سابقة؛ تم إيقاف استخدامه في نظامي في تاريخ 2026-09-09)، وما هي التكاليف الفعلية لوكلاء الذكاء الاصطناعي لديّ.