مينيماكس إم3: وكيل البرمجة من OpenClaw مقابل كيمي ك3 وdsh

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

ما هو مزود الخدمة Minimax في OpenClaw في الحقيقة؟

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

• البروتوكول ونقطة النهاية. يقوم البرنامج الإضافي الخاص بـ Minimax بإنشاء مزودي الخدمة باستخدام api: "anthropic-messages" والعنوان الأساسي https://api.minimax.io/anthropic (ويمكن تغيير المضيف عبر متغير البيئة MINIMAX_API_HOST). كما يوفر Minimax واجهة برمجية متوافقة مع OpenAI على العنوان https://api.minimax.io/v1، لكن البرنامج الإضافي في OpenClaw لا يستخدمها.
• ما الذي يمكن تهيئته؟ القليل جدًا؛ فملف openclaw.json الخاص بي يقوم فقط بتعديل قائمة النماذج المتاحة لمزود الخدمة minimax؛ أما نوع واجهة البرمجة، العنوان الأساسي والمصادقة فجميعها تأتي من البرنامج الإضافي. وفي منطقة الصين، يستخدم Minimax العنوان https://api.minimaxi.com/anthropic.
• مفتاح الوصول. يتم تحديده عبر متغير بيئي؛ حيث يقرأ البرنامج الإضافي قيمة المتغير MINIMAX_API_KEY (بالإضافة إلى بعض المتغيرات الأخرى المتعلقة بالتوكنات).
• إعدادات النموذج. يوفر البرنامج الإضافي نموذج M3 الذي يتمتع بقدرة استيعابية تصل إلى مليون توكن، ويحتوي على إعداد واحد فقط وهو compat، بالإضافة إلى إعداد codeMode: "preferred" (وهو وضع الترميز في OpenClaw، ولا علاقة له بـ Codex). لا يوجد خيار لتعديل درجة الحرارة في هذا الإعداد.
• الأسعار. يحدد البرنامج الإضافي سعر استخدام نموذج M3 بـ 0.60 دولار للمدخلات، و2.40 دولار للمخرجات، بالإضافة إلى 0.12 دولار لكل مليون توكن يتم استرجاعه من الذاكرة المؤقتة؛ وهذه الأرقام هي التي تُستخدم في حساب قيمة usage.cost.total في ملف JSON. هذه هي الأسعار القياسية المذكورة على صفحة الدفع حسب الاستخدام في Minimax للطلبات التي تحتوي على ما يصل إلى 512 ألف توكن كمدخلات. عند فحص الصفحة بتاريخ 2026-09-16، وجدت أن الأسعار قد تم تخفيضها إلى النصف (0.30 دولار / 1.20 دولار / 0.06 دولار)، بينما تتضاعف الأسعار القياسية عند تجاوز حد الـ 512 ألف توكن كمدخلات. الأسعار المذكورة في هذا المقال هي تلك التي يحددها البرنامج الإضافي، أي الأسعار الأصلية غير المخفضة.

ليس 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

الخطوة 1: المفتاح

يأتي ملحق Minimax مع إصدار OpenClaw 2026.9.2، وهو مفعّل في تثبيتي. يقوم الملحق بقراءة المفتاح من المتغير MINIMAX_API_KEY؛ لذا يجب وضعه في أي بيئة يعمل فيها البوابة الخاصة بك (سواءً في ملف EnvironmentFile التابع لـ systemd، أو ملف إعدادات launchd، أو حتى في شل النظام)، ثم أعد تشغيل البوابة باستخدام الأمر 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 بوضع --thinking max، بينما عملت MiniMax باستخدام وضع التفكير التكيفي الافتراضي في OpenClaw؛ أما أرقام dsh فهي نتيجة تشغيل مرة أخرى بعد تحميل الذاكرة المؤقتة.

ما الذي لم يكن كما هو:

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

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

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

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

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

“الاختبار الممتع” في مقال dsh كان عبارة عن ويدجت من فن البكسل يمثل شعار هذا الموقع، وقد تم إنشاؤه بناءً على توجيهات مكتوبة (التي نُقلت بالكامل في المقال المذكور): ملف واحد فقط باسم ll-pixel-logo.js لا يعتمد على أي مكتبات خارجية، يقوم برسم حلقة وحرفي “L” مائلين على شبكة 40×40، كما يدفع البكسلات بعيدًا عن مؤشر الفأرة، ويتحطم ثم يعود إلى شكله الأصلي عند النقر عليه، ويحترم إعداد prefers-reduced-motion؛ بالإضافة إلى صفحة تجريبية وملف README واختبار ذاتي. أعطيت نفس التوجيهات لكل من كيمي ومينيماكس، كلاهما عبر نفس وكيل العمل. يتناول مقال كيمي محاولات كيمي الثلاث؛ والجزء المهم هنا هو المحاولة الثانية، التي أنتجت ويدجتًا مكتملًا مكونًا من 323 سطرًا، بالإضافة إلى صفحة تجريبية وملف README وملفين للاختبار، وكل ذلك تم حفظه في مساحة عمل وكيل العمل بدلًا من المجلد الذي كنت أراقبه؛ وقد توقفت المحاولة عند الدقيقة الـ15 قبل أن ترسل ردًا. افترضت حينها أنها لم تنتج أي شيء.

<pبعد ساعة، تلقى مينيماكس نفس التوجيهات على نفس وكيل العمل: استغرق الأمر 59.3 ثانية، وتم إجراء 25 دورة تواصل، بالإضافة إلى 24 استدعاءً لأدوات خارجية؛ كلف ذلك مبلغ 0.13 دولار حسب قائمة الأسعار. وجد مينيماكس ملفات المحاولة الثانية التي أنتجتها كيمي لا تزال موجودة في مساحة العمل، فقرأ جميع الملفات الخمسة بالإضافة إلى تقرير تنفيذ كيمي، ثم قام بتشغيل اختباراتها، وأخيرًا رد قائلًا: “تم إنشاء وتحقق من مجموعة الويدجتات بالكامل”. لكنه لم يكتب أي سطر برمجي خاص بالويدجت؛ الملفات الوحيدة التي أنتجها كانت تقرير تنفيذه وملف الحالة الخاص به.

<pأخذت رد مينيماكس على محمل الجد، ولذلك عرضت النسخة الأولى من هذا المقال الويدجت على أنه من إنتاج مينيماكس. لكن سجل الجلسة يُظهر عملية write للملف نفسه في جلسة المحاولة الثانية التي قامت بها كيمي، والنسخة الموجودة على هذا الموقع متطابقة معه تمامًا من حيث البايتات. لذا فإن هذا المقال لا يحتوي على أي نتيجة ويدجت من مينيماكس، ولم أعيد تنفيذ التوجيهات مرة أخرى. ما يحتويه المقال فعليًا هو مثال واضح على وكيل ذكاء اصطناعي يُعلن عن عمل غيره على أنه إنجازه الخاص؛ ولهذا السبب وضعت فيما يلي بعض التحذيرات التي يجب الانتباه إليها.

<pإليكم الويدجت، والذي يُنسب بشكل صحيح إلى المحاولة الثانية من كيمي K3:

<pأما أبعاده الهندسية فهي كالتالي: RING_R = 19.4، والحلقة الداخلية عند مسافة 0.82 من نصف القطر، بالإضافة إلى قيمة SHEAR = 0.42 (أي ما يعادل 22.8 درجة تقريبًا)؛ كما يوجد دالة مساعدة تُسمى inL تختبر كل من القاعدة والجزء المائل معًا. عند حساب قيمة isLit على شبكة 40×40، نحصل على عدد 602 خلية مضاءة. يُعرض هذا الويدجت في المسابقة بجانب الويدجتين الآخرين.

ما الذي أعدت التحقق منه في ويدجت المحاولة الثانية

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

$ 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، رفض البرنامج كتابة الملف لأنه وجده موجودًا بالفعل؛ وفي عملية تصحيح الأخطاء، أفاد البرنامج بأن الاختبارات قد اجتازت بالفعل؛ أما عملية التلخيص فقد قامت بتلخيص محتويات مجلد تصحيح الأخطاء الخاص ببرنامج Kimi بدلاً من مجلدها الخاص. استخدام مفتاح جلسة فريد لكل مهمة --session-key حل هذه المشكلة.
• تعليمات العامل تغلب على التعليمات الواردة في البرومبت بشأن مكان حفظ الملفات. تعليمات عامل OpenClaw تنص على حفظ المخرجات الطويلة في مساحة العمل الخاصة به، وهذه التعليمات طغت على تعليمات "اكتب ملف fizz.py في هذا المجلد". في التشغيل الثالث لبرنامج FizzBuzz، أفاد البرنامج بأنه كتب الملف في مجلد المؤقتات؛ لكن تاريخ إنشاء الملف يشير إلى أنه تم حفظه في مساحة العمل. أما التشغيل الرابع، الذي استخدم مسارًا مطلقًا وتعليمات صريحة باستخدامه، فقد نجح في حفظ الملف بشكل صحيح.
• مساحة العمل المشتركة تؤثر سلبًا على التشغيلات اللاحقة. كما ظهر في مثال برنامج Kimi؛ فالملفات المتخلصة عنها لا تزال موجودة في مساحة عمل العامل بعد ساعة، ويعتبرها برنامج MiniMax ملكًا له. لذا يجب توفير مجلد فارغ لكل تشغيل، والتحقق من ما كتبه البرنامج فعليًا (من خلال التواريخ واستدعاءات write في الجلسة)، وليس ما يدعي أنه كتبه.
• النظام يذكر أن الحد الأقصى للرموز هو 1,000,000؛ لكنني أستخدم 262,144 فقط. هذا هو إعداد contextTokens الخاص بي، ويؤكد agentMeta.contextTokens في ملف JSON أي الإعدادات هي التي تُطبق فعليًا. يمكنك رفع هذا الحد إذا كنت بحاجة إلى نافذة زمنية أطول للعمليات.
• الأرقام المتعلقة بالتكاليف في الخطط الثابتة مجرد تخمينات، لكنها تخمينات مفيدة. يقوم OpenClaw بملء قيمة usage.cost.total بناءً على أسعاره القياسية، بغض النظر عن التكلفة الفعلية التي تدفعها؛ لذا فهي مفيدة للمقارنة بين النماذج، لكنها لا تمثل فاتورة حقيقية.

ما الذي يترتب على ذلك؟

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

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

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