Kimi K2.6 وادعاء «13 ساعة من البرمجة»: قصة لها مصدر، لكنها ليست برهانًا كاملًا

الحكم المختصر: لا دخان بلا نار، ولا برهان قاطع أيضًا

يمكن تقسيم الصورة الحالية إلى ثلاث طبقات:

• توجه المنتج واضح. Microsoft Foundry يصف Kimi K2.6 بأنه نموذج agentic ومتعدد الوسائط موجه للاستدلال طويل الأفق، والبرمجة، والتنفيذ الذاتي. كما تصفه SiliconFlow وOllama بأنه نموذج للبرمجة طويلة الأفق، وتنسيق الوكلاء، والتنفيذ الاستباقي أو تنظيم مهام على هيئة أسراب وكلاء.
• رقم 12 إلى 13 ساعة له مصادر. إعلان Kimi Forum يتحدث عن 4,000+ استدعاء أدوات وأكثر من 12 ساعة من التنفيذ المتواصل. ومقال في DEV Community ينقل عن مدونة إطلاق Moonshot أن Kimi K2.6 قضى 13 ساعة في تعديل أجزاء من exchange-core، مع أكثر من 1,000 استدعاء أدوات وتعديل أكثر من 4,000 سطر من الشيفرة.
• القدرة العامة المستقرة غير مثبتة. معظم المواد المتاحة هي إعلانات، صفحات منصات، مقالات شارحة، أو منشورات اجتماعية. هذه تكفي لإثبات أن القصة طُرحت علنًا، لكنها لا تعوّض سجلًا كاملًا للتنفيذ أو تجربة يمكن لطرف ثالث إعادة تشغيلها ومراجعتها.

ماذا تقول المنصات عن Kimi K2.6؟

Kimi K2.6 ليس مقدَّمًا كنموذج دردشة عادي فقط. Microsoft Foundry يضعه ضمن فئة نماذج agentic ومتعددة الوسائط، ويقول إن اتجاهه يشمل الاستدلال طويل الأفق، والبرمجة، والتنفيذ الذاتي.

SiliconFlow يصفه بأنه نموذج مفتوح المصدر متعدد الوسائط، ويركز على long-horizon coding، وتنسيق الوكلاء ذاتيًا، والتصميم المدفوع بالبرمجة. وتعرض الصفحة أيضًا أرقامًا معيارية مثل 58.6 على SWE-Bench Pro و86.3 على BrowseComp Agent Swarm.

أما Ollama فيصف Kimi K2.6 بأنه نموذج مفتوح المصدر، متعدد الوسائط بطبيعته، ومصمم للتقدم في البرمجة طويلة الأفق، والتصميم القائم على الشيفرة، والتنفيذ الذاتي الاستباقي، وتنظيم المهام عبر أسراب من الوكلاء.

الخلاصة هنا: من العادل القول إن Kimi K2.6 موجه فعلًا نحو نمط coding agent طويل المدى. لكن صفحة منتج أو رقم benchmark لا يثبتان وحدهما أنه يعمل بلا إشراف لساعات طويلة على مشاريع حقيقية وبجودة قابلة للدمج.

من أين جاء رقم «13 ساعة»؟

أقرب مصدر مباشر في المواد المتاحة هو إعلان Kimi Forum، حيث يذكر قسم البرمجة طويلة الأفق 4,000+ استدعاء أدوات، وأكثر من 12 ساعة من التنفيذ المتواصل، مع تعميم عبر لغات مثل Rust وGo وPython.

الرواية الأكثر تحديدًا عن 13 ساعة تظهر في مقالات ومنشورات تنقل قصة exchange-core. مقال DEV Community يقول إن Kimi K2.6 قضى 13 ساعة في إعادة كتابة أجزاء من محرك المطابقة المفتوح المصدر exchange-core، ونفذ أكثر من 1,000 استدعاء أدوات، وعدّل أكثر من 4,000 سطر، وحقق تحسنًا في معدل المعالجة، ويصف ذلك بأنه جرى من دون تدخل بشري.

The Neuron يورد رواية مشابهة عن تشغيل دام 13 ساعة على exchange-core مع أكثر من 1,000 استدعاء أدوات. كما يلخص منشور من حساب Kimi_Moonshot على X تنفيذًا مدته 13 ساعة، مرّ عبر 12 استراتيجية تحسين، وشمل أكثر من 1,000 استدعاء أدوات.

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

ما الذي ينقص قبل اعتبارها قدرة مثبتة؟

لتحويل حالة إطلاق أو عرض تقني إلى إثبات قدرة، نحتاج عادة إلى أكثر من أرقام موجزة. المواد الحالية تعطينا عناوين كبيرة مثل مدة التشغيل وعدد استدعاءات الأدوات وحجم التعديل في الشيفرة، لكنها لا تجيب علنًا عن أسئلة أساسية.

من الأسئلة التي يجب أن تكون قابلة للمراجعة:

• ما نص المهمة الأصلي أو الـ prompt الكامل؟
• ما الـ commit الذي بدأ منه العمل، وما الـ diff النهائي؟
• هل سجل استدعاءات الأدوات، خطوة بخطوة، متاح للتدقيق؟
• ما صلاحيات الأدوات، وبيئة العزل، والعتاد، والتكلفة، وسياسات timeout وإعادة المحاولة؟
• ما أوامر الاختبار وملفات benchmark المستخدمة، وهل يمكن إعادة تشغيلها؟
• هل حدث أي تدخل بشري، أو إيقاف مؤقت، أو إعادة تشغيل، أو محاولات فاشلة لم تُنشر؟
• هل أعاد طرف ثالث تنفيذ التجربة بالشروط نفسها؟

من دون هذه التفاصيل، لا يمكن القفز من «حدثت حالة مثيرة للاهتمام» إلى «النموذج ينجز عمومًا 13 ساعة من البرمجة الذاتية بثبات».

ليست المسألة نموذجًا فقط

حتى لو كان النموذج أفضل في التخطيط واستخدام الأدوات، فالوكيل البرمجي طويل المدى هو مسألة نظام كامل لا مسألة نموذج لغوي وحده. VentureBeat يشير إلى أن كثيرًا من أطر تنسيق الوكلاء صُممت أصلًا لوكلاء يعملون لثوانٍ أو دقائق، وأن الوكلاء طويلو التشغيل يكشفون حدود تنسيق المؤسسات وإدارة الحالة المستمرة.

بمعنى آخر، تشغيل مهمة تمتد 13 ساعة يعتمد على النموذج، نعم، لكنه يعتمد أيضًا على إطار الوكلاء، وواجهات الأدوات، وإدارة الحالة، واستعادة الأخطاء، واختبارات الشيفرة، والمراقبة. كما أن إتاحة Kimi K2.6 على Cloudflare Workers AI، ووجود صفحات له في Microsoft Foundry وSiliconFlow وOllama، يوسّع إمكانية وصول المطورين إليه؛ لكنه لا يساوي إثباتًا مستقلًا لقدرة 13 ساعة في بيئة إنتاجية.

صياغة آمنة للادعاء

يمكن قول الآتي بثقة أعلى:

• Kimi K2.6 يُعرض في عدة منصات كنموذج موجه إلى البرمجة طويلة الأفق والتنفيذ الوكيلي وتدفقات عمل متعددة الوكلاء.
• توجد مواد إطلاق ومنشورات تنقل حالات تشغيل ذاتي تتجاوز 12 ساعة أو تصل إلى 13 ساعة.
• إحدى الروايات المركزية تدور حول exchange-core، مع حديث عن 13 ساعة، وأكثر من 1,000 استدعاء أدوات، وأكثر من 4,000 سطر شيفرة معدّل.

والأصح تجنب صيغ مثل:

• ثبت من طرف ثالث أن Kimi K2.6 يكتب الشيفرة وحده 13 ساعة بثبات.
• أي مستودع كبير يمكن تركه للنموذج طوال الليل وسيخرج بنتيجة موثوقة.
• أرقام benchmark أو إدراج النموذج في منصات المطورين تعني تلقائيًا تحققًا هندسيًا كاملًا.

الخلاصة

ادعاء «Kimi K2.6 كتب الشيفرة 13 ساعة متواصلة» لا ينبغي رميه فورًا في خانة الخيال؛ فهناك مصادر علنية تشير إلى حالة من هذا النوع، وهناك بالفعل تموضع واضح للنموذج حول البرمجة طويلة الأفق والتنفيذ الوكيلي.

لكن الادعاء الأقوى — أن Kimi K2.6 ثبت مستقلًا أنه يستطيع في المشاريع الواقعية العامة أن يبرمج 13 ساعة بلا إشراف وبثبات — غير قائم حتى الآن. النتيجة الأكثر إنصافًا: Kimi K2.6 يطرح نفسه بجدية كـ coding agent طويل المدى، لكن رقم 13 ساعة لا يجب التعامل معه كضمان إنتاجية مثبت من طرف ثالث.