في الآونة الأخيرة، تداول مجتمع المطورين خبرا قصيرا بشكل لافت. وهو أن أنثروبيك أزالت نحو 80 بالمئة من التعليمات النظامية في Claude Code. والجزء المثير للاهتمام لم يكن التقليص بحد ذاته، بل السبب وراءه. فقد قال طارق شيهيبار (@trq212) من أنثروبيك إن سلسلة النماذج الجديدة Fable 5 “تريد تعليمات نظامية أصغر”، وأوضح أن إدراج الكثير من التعليمات والأمثلة قد يعيق النموذج فعليا. والسبب، بحسب قوله، أن النموذج أكثر خيالا من القواعد التي نكتبها له.

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

تشغّل Thaki Cloud منصة SaaS للذكاء الاصطناعي وتعلم الآلة قائمة على Kubernetes، وتدير من خلال طبقة تحكم الوكلاء Paxis العاملة فوقها أكثر من 960 مهارة وعشرات القواعد الدائمة كإطار عمل. لذلك، فإن سؤال “كم يجب أن ندرج في التعليمات النظامية” ليس بالنسبة لنا جملة رائجة بل قرار تصميم نواجهه يوميا. يستعرض هذا المقال ما يعنيه هذا التقليص، ولماذا تريد النماذج الأذكى إطارا أرق، وكيف يمكن ترجمة هذا المبدأ إلى ممارسة تشغيلية فعلية.

ما الذي تغيّر

يتلخص جوهر الخبر المنشور في نقطتين. الأولى أن حجم التعليمات النظامية في Claude Code انخفض بشكل كبير. والثانية أن السبب ليس “النموذج ضعيف فنملؤه أكثر” بل على العكس “النموذج أصبح قويا فنملؤه أقل”.

بحسب تفسير أنثروبيك، ازدادت قدرة النموذج الجديد على استيعاب معايير السلوك داخليا أثناء التدريب. فما كان يجب سابقا كتابته بالتفصيل في التعليمات النظامية عند لحظة النشر، أصبح النموذج الآن يحمله إلى حد ما داخل أوزانه. ونتيجة لذلك، انتقل دور التعليمات النظامية من “دفتر لوائح يحتوي كل القواعد” إلى “مُعِدّ سياق خفيف”، بحسب التفسير المرافق للخبر. كما وردت إشارة إلى توجيه النموذج بالاعتماد على السياق بدلا من صيغ المنع الجافة مثل “لا تفعل هذا”.

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

flowchart TB
    subgraph OLD["سابقا: تعليمات نظامية ثقيلة"]
        A1["تحديد كل القواعد والاستثناءات<br/>والصيغ في التعليمات النظامية"] --> A2["توقع أن يتبع النموذج<br/>التعليمات كما هي"]
        A2 --> A3["قد تحد التعليمات<br/>من القدرة الفعلية"]
    end
    subgraph NEW["حاليا: إطار رقيق مع سياق"]
        B1["التعليمات النظامية تحدد<br/>سياقا خفيفا فقط"] --> B2["استثمار الحكم<br/>الذي استوعبه النموذج داخليا"]
        B2 --> B3["تُحقن القواعد كسياق<br/>عند الحاجة فقط"]
    end
    OLD -.الانتقال مع تعاظم قوة النموذج.-> NEW

وهنا نقطة تستحق الحذر. فـ”تقليص التعليمات النظامية” لا يعني “إلغاء التعليمات”. ما تقلص هو الإطار الدائم الذي كان مرفقا دوما عند لحظة النشر، أما المعرفة المجالية وأساس الأحكام فلا تزال بحاجة إلى مكان تُحفظ فيه. الذي تغيّر هو مكان تخزين هذه المعرفة.

لماذا تريد النماذج الأذكى تعليمات أرق

هذه الظاهرة ليست حديثا يدور بالحدس وحده. فهناك أبحاث تشير إلى أن زيادة سقالات الوكيل (الإطار) لا تُحسّن الأداء بالضرورة، بل قد تسبب تداخلا بينها. على سبيل المثال، تتناول ورقة “More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding” (arXiv 2605.05716) النقطة التي يبدأ عندها إضافة المزيد من مكونات الإطار في خلق تداخل بين هذه المكونات، مما يؤدي إلى تراجع الأداء الإجمالي. وهذه ملاحظة تفيد بأن إضافة المزيد من التعليمات ليست منفعة متزايدة باطراد.

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

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

غير أن هذا المنطق ليس مطلقا. فإزالة الحد الأدنى قد ترفع المتوسط، لكنها تزيد التباين في الوقت نفسه. أي أن الحاجز الوقائي الذي كان يمنع ظهور مخرجات سيئة من حين لآخر يختفي. لهذا السبب، فإن “ما الذي يجب إزالته” أهم عمليا من “كم يجب إزالته”.

من القواعد إلى السياق

أكثر ما يفيد عمليا في هذا الخبر هو جزء “التوجيه بالسياق بدلا من صيغ المنع الجافة”. فهناك طريقتان لنقل النية نفسها.

الأولى هي القاعدة الصارمة. وتُصاغ بالمنع والإلزام، مثل “لا تستخدم مصطلحات تقنية” أو “التزم حتما بهذه الصيغة”. هذه الطريقة واضحة، لكنها إذا تراكمت كإطار دائم تُنتج التداخل المذكور آنفا. أما الثانية فهي إعداد السياق. وفيها يُوصف الحالة المرجوة للنتيجة، مثل “اكتب هذا النص بمستوى يسهل على قارئ في السادسة عشرة فهمه”. وغالبا ما تعمل الطريقة الثانية بثبات أكبر مع النماذج القوية. ليس لأنها لا تفهم الصيغ السلبية، بل لأن الهدف المصاغ إيجابا يمنح النموذج مساحة ليملأ التفاصيل بنفسه.

وهنا ينشأ تمييز مهم. فالأمر لا يتعلق بإزالة كل المعرفة من التعليمات النظامية، بل بفصل الإطار الدائم عن المعرفة المطلوبة عند الحاجة. يُبقى فقط ما يلزم في كل لحظة دائما، بينما تُستدعى المعرفة اللازمة لمهمة محددة كسياق عند بدء تلك المهمة. وبهذا يظل الإطار الدائم رقيقا، بينما تُقدَّم المعرفة المجالية بكثافة عند اللحظة المطلوبة.

غير أن ما يجب ألا يتزعزع، مثل اتساق الصيغة، ينبغي أن يبقى بحوزة الشيفرة الحتمية. فبدلا من أن نطلب من النموذج “أجب دائما بالصيغة نفسها من JSON”، يكون من الأسلم أن تفرض الشيفرة صيغة المخرجات والتجميع، ويكتفي النموذج بتوليد المحتوى فقط. وتيار جعل التعليمات أرق لا يتعارض مع مبدأ تثبيت الصيغة بالشيفرة، بل يكمل كل منهما الآخر. فما لا يجوز أن يتزعزع يُنزَّل إلى الشيفرة، وما يحتاج إلى حكم يُترك للنموذج، وكلاهما يُخفَّف من الإطار الدائم.

دلالات على مستوى منتجات Thaki Cloud

يتقاطع هذا التيار بدقة مع فلسفة تصميم منصة الوكلاء Paxis الخاصة بـ Thaki Cloud. فـ Paxis طبقة تحكم للسحابة الأصيلة للوكلاء (Agent-Native Cloud) تعمل فوق ai-platform، وتتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. ومن أبرز مبادئ التصميم فيها “إطار رقيق، ومهارات ثقيلة”. فحلقة النموذج والصلاحيات والأمان، أي الإطار، تُبقى عند الحد الأدنى، بينما تُكدَّس المعرفة المجالية والأحكام وحالات الفشل بكثافة في المهارات.

لا يضع إطار المهارات في Paxis أكثر من 960 مهارة كلها في التعليمات النظامية الدائمة. بل يختار عند وصول الطلب، عبر بحث BM25، المهارات ذات الصلة فقط ويستدعيها كسياق في تلك اللحظة تحديدا. وهذا بالضبط تجسيد لما يعنيه هذا الخبر بـ”مُعِدّ السياق الخفيف”. إذ يظل الإطار الدائم الذي يُدفع ثمنه في كل حالة رقيقا، بينما تُقدَّم المعرفة الكثيفة فقط عند مهمة محددة. ومنذ لحظة إدراج أي مهارة في الفهرس، يبدأ اسمها ووصفها بتحمل تكلفة رمزية (توكن) في كل جلسة، لذلك نحكم على إدراج كل جملة في الإطار الدائم بمعيار: هل يخطئ الوكيل من دونها؟

يرتبط مبدأ التوجيه بالسياق أيضا بتشغيلنا. فبوابات السياسات وسجلات التدقيق في Paxis تفرض بالشيفرة الحتمية القواعد التي لا يجوز أن تتزعزع. أما المجالات التي تتطلب جودة محتوى أو حكما، فتُترك للنموذج، مع توجيه اتجاهه فقط بقاعدة رقيقة. ولأن القواعد الدائمة تُدفع ثمنها رمزيا في كل دورة تفاعل، نُبقي دائما فقط ما هو ضروري باستمرار، بينما نُنزّل ما يُحتاج إليه أحيانا إلى مهارات تُحمَّل عند الطلب. وبهذا نطبق يوميا في رسم الحدود بين المهارات والقواعد الدرس نفسه الذي تعلمته أنثروبيك من تعليماتها النظامية.

وهناك دلالة أيضا من منظور البنية التحتية. فحين تصبح التعليمات النظامية أرق، تقل رموز الإدخال (input tokens)، وهذا يؤثر مباشرة على تكلفة الخدمة والتأخير. وفي بيئة تخدم فيها ai-platform النماذج عبر vLLM بتشغيل متعدد المستأجرين، فإن تقليص الإطار الدائم ليس مسألة جودة فحسب بل مسألة اقتصادية أيضا. فانخفاض تكلفة الخدمة يُتيح تشغيل الوكلاء بشكل أكثر تواترا وعلى نطاق أوسع، وهذه القدرة بدورها تصنع جدوى اقتصادية للوكلاء.

الحدود والاعتراضات

يجب توخي الحذر عند تعميم هذا التيار كما هو. وفيما يلي بعض الاعتراضات نطرحها بأمانة.

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

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

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

خلاصة القول، هذا التقليص مؤشر واحد يكشف عن انتقال مركز ثقل هندسة التعليمات. فكلما اشتد ذكاء النموذج، يزداد الإطار الدائم رقة، وتُعاد صياغة القواعد وتوزيعها بين السياق والشيفرة. وقد طبقت Thaki Cloud هذا المبدأ فعليا من خلال إطار Paxis الرقيق ومهاراته الثقيلة، ويؤكد هذا الخبر أن هذا الاتجاه ليس ذائقة خاصة بنا بل تيار تتجه إليه الصناعة معا.

المصادر

• تصريح علني منسوب لطارق شيهيبار (@trq212) من أنثروبيك، نقلا عن موقع the-decoder.com
• “Anthropic Slashes Claude Code System Prompt by 80%”, ClaudeAINews
• “More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding”, arXiv 2605.05716

يستعرض هذا المقال ماهية Kimi Code CLI، وما تقدمه فعلياً، ولماذا تستحق المتابعة من منظورنا كمشغّلين لمنصة ذكاء اصطناعي قائمة على K8s. وقد خصصنا مساحة واسعة لشرح لماذا يُعد معيار Agent Client Protocol المفتوح قطعة قد تغير قواعد اللعبة في منظومة الوكلاء.

ما هو Kimi Code CLI

Kimi Code CLI أداة برمجة عاملة بأسلوب الوكيل تعمل من الطرفية، وتنتمي إلى نفس فئة Claude Code وGemini CLI وCodex CLI. المستودع الرسمي هو MoonshotAI/kimi-code، وقد تطور من المشروع السابق MoonshotAI/kimi-cli مع الحفاظ على استمرارية الجلسات والإعدادات القديمة. كلا المستودعين رسميان من Moonshot، وينبغي الحذر من الخلط بينهما وبين مشاريع طرف ثالث تحمل أسماء مشابهة.

وهنا يجب توضيح تصحيح أول. الاسم الرسمي لهذه الأداة ليس “CLI مخصصة لـ Kimi K3” بل Kimi Code CLI. فهي أداة غير مقيدة بنموذج واحد، وتستخدم افتراضياً نموذج Moonshot المتخصص في البرمجة Kimi K2.7 Code، لكن يمكن عبر الإعدادات التحول إلى نماذج أخرى بما فيها K3. أي أن K3 هو أحد النماذج المتعددة التي يمكن ربطها بهذه الأداة، وليست الأداة مصممة حصراً له. أما K3 نفسه فهو نموذج MoE مفتوح بحجم 2.8 تريليون معلمة أطلقته Moonshot في 16 يوليو 2026، ويعتمد على Kimi Delta Attention مع نافذة سياق تصل إلى مليون رمز. وقد غطت هذا الإطلاق وسائل إعلام رئيسية مثل CNBC وBloomberg وForbes.

من المفيد رسم الصورة الكاملة أولاً لتترابط التفاصيل لاحقاً بسهولة أكبر. جوهر الأمر هو الدور المزدوج الذي تلعبه Kimi Code CLI: فمن جهة تتصل بالأدوات والبيانات كعميل MCP، ومن جهة أخرى تتصل بالمحررات كخادم ACP.

flowchart TB
    subgraph EDITOR["محرر المطور (عميل ACP)"]
        ZED["Zed"]
        JB["عائلة JetBrains"]
        VSC["VS Code / Neovim"]
    end
    ACP["Agent Client Protocol<br/>JSON-RPC over stdio"]
    subgraph CLI["Kimi Code CLI (نواة الوكيل)"]
        MAIN["الوكيل الرئيسي<br/>يحافظ على سجل المحادثة"]
        SUB["الوكلاء الفرعيون<br/>coder · explore · plan<br/>لكل منهم سياق معزول"]
    end
    MODEL["طبقة النموذج<br/>Kimi K2.7 Code / K3<br/>أو نقطة نهاية متوافقة مع OpenAI"]
    subgraph MCP["خوادم MCP (الأدوات والبيانات)"]
        T1["Context7"]
        T2["Chrome DevTools"]
        T3["موصلات داخلية"]
    end

    EDITOR --> ACP
    ACP -->|kimi acp| MAIN
    MAIN --> SUB
    MAIN -->|طلب استدلال| MODEL
    SUB -->|طلب استدلال| MODEL
    MAIN -->|استدعاء أداة| MCP

الوكلاء الفرعيون: تقسيم السياق للحفاظ على نظافة الوكيل الرئيسي

توفر Kimi Code CLI ثلاثة أنواع من الوكلاء الفرعيين المدمجين. الوكيل coder هو المسؤول الهندسي العام الذي يقرأ الملفات ويكتبها وينفذ الأوامر لتطبيق التغييرات الفعلية. الوكيل explore مخصص للاستكشاف، إذ يتصفح قاعدة الشيفرة للقراءة فقط. أما الوكيل plan فيقتصر عمله على تقديم خطط التنفيذ وتصاميم البنية دون تنفيذ أي أوامر في الصدفة. هذا التقسيم موثق في الصفحة الرسمية Agents and Sub-Agents.

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

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

MCP: تجربة إعداد دون تعديل JSON يدوياً

تُدار عمليات ربط Model Context Protocol عبر مسارين. الأول هو الأوامر الفرعية لسطر الأوامر، حيث تُدار الخوادم عبر kimi mcp add وkimi mcp list وkimi mcp remove وkimi mcp authorize. على سبيل المثال يمكن ربط خادم بحث في الوثائق عبر نقل HTTP، أو ربط خادم أتمتة متصفح عبر نقل stdio.

# نقل HTTP (يدعم خيار OAuth)
kimi mcp add --transport http context7 https://mcp.context7.com/mcp

# ربط عملية محلية عبر نقل stdio
kimi mcp add --transport stdio chrome-devtools -- npx chrome-devtools-mcp@latest

أما المسار الثاني فهو الأمر التفاعلي بشرطة مائلة /mcp-config الذي يُستخدم داخل واجهة TUI، ويتيح إضافة الخوادم وتعديلها والمصادقة عليها دون تحرير ملف إعدادات JSON مباشرة. ويعرض الأمر /mcp قائمة الخوادم المتصلة حالياً والأدوات المحمّلة. والجزء الذي أبرزه تعريف LinkedIn، وهو أنه لا حاجة لتعديل JSON مباشرة، صحيح فعلاً. لكن هذه الميزة بحد ذاتها ليست غائبة عن Claude Code، وسنعود إلى هذه النقطة لاحقاً. الوثائق ذات الصلة موجودة في إعداد MCP.

Agent Client Protocol: أهم قطعة في هذه الأداة

هذا هو الجزء الأكثر إثارة للاهتمام في هذا المقال. Agent Client Protocol، ويُختصر بـ ACP، هو معيار مفتوح صممه فريق محرر Zed. يعمل برخصة Apache، ويتبادل الرسائل عبر JSON-RPC 2.0 فوق stdio. تُشغّل المحررات الوكيل كعملية فرعية وتتواصل معه عبر المدخلات والمخرجات القياسية، وآلية النقل نفسها مطابقة لبروتوكول خادم اللغة.

التشبيه هنا يساعد كثيراً على الفهم. قبل ظهور LSP، كان على كل محرر أن يبني تكاملاً منفصلاً لكل لغة برمجة. حوّل LSP هذه المسألة من مشكلة M ضرب N إلى مشكلة M زائد N، فما إن ينفذ محرر واحد المعيار حتى يستفيد من أي خادم لغة بغض النظر عمن صنعه. ويفعل ACP الشيء ذاته تماماً مع الوكلاء، فما إن ينفذ محرر واحد ACP حتى يتصل به أي وكيل بطريقة موحدة بغض النظر عن صانعه. يمكن الاطلاع على هذا المفهوم في تعريف Zed بـ ACP وفي مقال مارك نوري التوضيحي.

من السهل الخلط بينه وبين MCP، لكن الاتجاه معاكس تماماً. يتجه MCP من الوكيل نحو الأدوات والبيانات، وفي هذه الحالة يكون الوكيل عميل MCP. أما ACP فيتجه من المحرر نحو الوكيل، وهنا يكون الوكيل خادم ACP والمحرر عميل ACP. أي أن الوكيل نفسه يلعب دور عميل MCP من جهة، ودور خادم ACP من جهة أخرى في آن واحد. وهذا هو السبب الذي جعل الرسم البياني السابق يوضح هذا الدور المزدوج.

تدعم Kimi Code CLI هذا البروتوكول بشكل أصلي عبر الأمر الفرعي kimi acp دون الحاجة إلى أي تثبيت إضافي. يتصل بها Zed بشكل أصلي، بينما تتصل به JetBrains عبر إضافة، وقد ظهرت بالفعل عدة تكاملات مع محررات أخرى وفق سجل ACP الخاص بـ Zed. بذلك يستطيع المطور تشغيل جلسة Kimi دون مغادرة المحرر الذي اعتاد عليه.

إدخال الصور والفيديو، إلى أي حد فعلياً

ذكر تعريف LinkedIn أنه يمكن تمرير لقطة الشاشة كما هي كمدخل. وهذا يحتاج إلى تصحيح. فالميزة التي تبرزها Moonshot فعلياً ليست لقطة شاشة ثابتة بل إدخال مقطع فيديو مسجّل للشاشة. يذكر وصف المستودع أنه عند إسقاط تسجيل شاشة أو مقطع عرض توضيحي في المحادثة، يستطيع الوكيل مشاهدة وفهم السلوك الذي يصعب شرحه بالكلام مباشرة. وبالطبع تدعم نافذة الإدخال في سطر الأوامر لصق الصور أيضاً، إذ إن النموذج الافتراضي Kimi K2.7 Code هو نموذج متعدد الوسائط أصلي مزوّد بمُرمّز رؤية MoonViT بحجم 400 مليون معلمة، يستقبل النص والصور والفيديو معاً. غير أنه عند ربط نموذج مخصص، يجب تحديد دعم الصور صراحة ضمن modalities الخاصة بذلك النموذج ليعمل بشكل صحيح. وخلاصة القول إن إدخال الصور متاح فعلاً، لكن ما يُروَّج له كفارق حقيقي هو إدخال الفيديو، وتعبير لقطة شاشة غير دقيق تماماً.

التثبيت فعلياً في ثلاث خطوات

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

# 1) تشغيل سكربت التثبيت (يثبّت uv في الوقت نفسه)
curl -LsSf https://code.kimi.com/install.sh | bash

# 2) التشغيل داخل دليل المشروع
kimi

# 3) إعداد المصادقة
/login

بالنسبة لنظام macOS تتوفر brew install kimi-code، وبالنسبة لويندوز يتوفر أيضاً سكربت PowerShell. للتطوير من الشيفرة المصدرية يلزم Node بإصدار 24.15 أو أحدث مع pnpm. ولأن الرخصة MIT، فإن القيود قليلة على قراءة الشيفرة وعمل fork لها وتوزيعها داخل المؤسسة.

انفتاح النماذج ومزودي الخدمة

يبلغ أقصى طول للسياق في عائلة K2.6 نحو 256 ألف رمز، بينما يصل في K3 وفق مواد تسويق Moonshot إلى مليون رمز. لكن الأهم من ذلك هو انفتاح مزودي الخدمة. ففي ملف ~/.kimi-code/config.toml يمكن تسجيل عدة مزودين في آن واحد، من نقاط نهاية متوافقة مع OpenAI، إلى مفاتيح Anthropic API، وصولاً إلى Google GenAI أو Vertex AI. وهذا يعني أن الأداة غير مقيدة بنموذج واحد بعينه. كما تعالج تلقائياً حقل reasoning_content الخاص بنماذج الاستدلال من أطراف ثالثة. الوثائق ذات الصلة في Providers and models.

هل هي ميزات غير موجودة في Claude Code: مقارنة صريحة

أكثر العبارات انتشاراً في التعريف كانت أنها تقدم ميزات غير موجودة في Claude Code. وبعد التحقق تبين أن هذا الإطار في معظمه مبالغ فيه.

فالوكلاء الفرعيون وعزل السياق يقدمهما Claude Code أيضاً بالطريقة نفسها عبر ميزة الوكلاء الفرعيين. وMCP مدعوم أصلاً بنضج في Claude Code عبر نقل stdio وSSE وHTTP. كما أن لصق الصور موجود فيه أيضاً. هذه العناصر الثلاثة إذن ليست فوارق حقيقية.

الفارق الحقيقي يكمن في نقطتين. الأولى هي طريقة دعم ACP. فـ Kimi Code CLI تدمج ACP كميزة أساسية من الدرجة الأولى داخل الأداة نفسها عبر الأمر الفرعي kimi acp. أما Claude Code فيتصل بها عبر حزمة محول منفصلة صنعها Zed، وما تزال في مرحلة تجريبية. من منظور المستخدم، الأولى تعمل فور تفعيل الأداة، بينما الثانية تتطلب إضافة جسر إضافي. النقطة الثانية هي انفتاح النماذج. فـ Kimi مفتوح على سلسلة K مفتوحة الأوزان مع إمكانية التحول بين عدة مزودين، بينما يقتصر Claude Code على نماذج Anthropic حصرياً. ومن هذه النقطة يتفرع فارق ثالث يتعلق بإمكانية الاستضافة الذاتية. فبما أن Kimi أداة مفتوحة المصدر مع نموذج مفتوح الأوزان، يمكن تشغيله داخل المؤسسة، بينما تظل Claude Code أداة مفتوحة لكن نموذجها متاح عبر واجهة API فقط. يمكن الاطلاع على الدليل ذي الصلة في مقال Zed حول Claude Code عبر ACP التجريبي.

دلالات على منتجات ThakiCloud

يمس هذا الموضوع أداة وكيل من جهة، ومحور بنية تحتية يتعلق بالنماذج المفتوحة والاستضافة داخل المؤسسة من جهة أخرى. لذلك نستخدم العدستين معاً.

من عدسة Paxis، تتداخل بنية Kimi Code CLI إلى حد كبير مع اتجاه تصميم منتجنا. فPaxis هو مستوى التحكم الخاص بـ ThakiCloud لسحابة أصيلة الوكلاء (Agent-Native Cloud)، ويتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. والطريقة التي يعمل بها الوكلاء الفرعيون coder وexplore وplan لدى Kimi بالتوازي وفي سياقات معزولة، تشترك في الفلسفة نفسها مع طريقة عمل حاضنة المهارات في Paxis، التي تختار من بين أكثر من 960 مهارة باستخدام BM25 وتنفذها في صناديق اختبار معزولة. وACP بشكل خاص، بوصفه معياراً محايداً تجاه المزودين، يمثل فرصة مباشرة لـ Paxis. فأي وكيل ننشره، بما في ذلك الوكلاء المزودة بنماذج خضعت لضبط دقيق خاص بنا، يمكنه إذا نفذ ACP أن يتصل بمحررات المطورين لدى العملاء مثل Zed أو JetBrains بطريقة موحدة. وهذا المزيج من معيارين، MCP للاتصال بالبيانات وACP للاتصال بالمحررات، يمثل بالضبط الصورة التكاملية التي نتجه إليها.

ومن عدسة ai-platform، الانفتاح يعني حرية النشر مباشرة. فبوضع سلسلة K مفتوحة الأوزان فوق جدولة GPU عبر Kueue وخدمة vLLM في عنقودنا، وتوجيه الأداة نحو نقطة نهاية داخلية، يمكن بناء وكيل برمجة داخلي دون الاعتماد على API خارجي أو إخراج البيانات إلى الخارج. وهذا ينسجم مع متطلبات الأمن الخاصة بالاستضافة داخل المؤسسة في قطاعي المال والقطاع العام حيث لا يجوز خروج الشيفرة إلى الخارج، وكذلك مع متطلبات جهات مثل NIS. وقد سبق أن تناولنا في مقالات سابقة فكرة أنه كلما أصبحت القدرات شائعة ورخيصة، فإن ما تدفعه الشركات فعلياً هو بيئة تنفيذ محكومة. وأهمية Kimi Code CLI تكمن في أنها فتحت طبقة التنفيذ هذه كمصدر مفتوح.

القيود والاعتراضات

هناك عدة نقاط ينبغي النظر إليها بموضوعية. أولاً، أسماء المحركات الداخلية أو هياكل الطبقات التي تُذكر في تحليلات طرف ثالث معمقة لا ترد في الوثائق الرسمية، وقد تكون نتيجة هندسة عكسية، لذا من الأسلم الاستناد إلى الوثائق الرسمية قبل اعتبارها حقائق. ثانياً، توجد تقارير من المجتمع تفيد بأن مسار ACP يقدم جودة استجابة أفضل من طرق الاتصال الأخرى، لكنها انطباعات وليست قياسات أداء موثقة، أي أنها ليست أرقاماً محققة. ثالثاً، حتى مع كون النموذج مفتوح الأوزان، فإن خدمة نموذج بحجم 2.8 تريليون معلمة فعلياً داخل المؤسسة تتطلب موارد GPU كبيرة، والانفتاح لا يعني بالضرورة سهولة الاستضافة الذاتية، إذ يظل مسار API خياراً واقعياً للفرق الصغيرة. رابعاً، قد يتفوق نضج واستقرار منظومة الأدوات لدى Claude Code أو Codex CLI. وكون الأداة مفتوحة المصدر لا يعني بالضرورة أنها جاهزة للإنتاج.

ومع ذلك، فإن الاتجاه نحو ارتباط رخو بين الوكلاء والمحررات فوق معايير مفتوحة هو تيار واضح. فعالم يستطيع فيه المطور تبديل النموذج والمحرر كل على حدة دون التقيد بأداة سطر أوامر من مزود معين، هو عالم أكثر فائدة للمطورين. وتُعد Kimi Code CLI إحدى القطع التي تُقرّب هذا العالم.

المصادر

• MoonshotAI/kimi-code (المستودع الرسمي)
• MoonshotAI/kimi-cli (المستودع السابق)
• دليل بدء Kimi Code CLI
• وثائق Agents and Sub-Agents
• وثائق إعداد MCP
• Zed - Agent Client Protocol
• ACP: The LSP for AI Coding Agents
• Zed - Claude Code via ACP (تجريبي)
• MarkTechPost - إطلاق Kimi K3

نظرة عامة

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

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

المقطع أعلاه هو الذي انتشر. ويُذكر أنه جزء من حوار مع الرئيس التنفيذي لشركة BlackRock، لاري فينك، في المنتدى الاقتصادي العالمي في دافوس.

ما قاله ماسك فعلًا

عند تفريغه، تُختزل تصريحات ماسك في ثلاثة توقّعات. بكلماته: “خلال خمس سنوات، أي بحلول 2031 تقريبًا، أعتقد أن الذكاء الرقمي سيتجاوز مجموع كل الذكاء البشري.” “ستكون هناك، خلال خمس سنوات، ربما مئة مليون روبوت بشري على الأقل، وربما مليار.” “أتوقّع أن يبلغ حجم الاقتصاد ضعف حجمه الحالي خلال خمس، وربما ست أو سبع سنوات، لأنك ستدخل فترة مضاعفة، حيث يزداد الناتج الاقتصادي بسرعة كبيرة إلى حد أنك، مع فارق بضع سنوات زيادة أو نقصانًا، سترى تغيّرات هائلة.”

ثلاثة ادّعاءات إذًا. أولًا، خلال خمس سنوات تقريبًا يتجاوز الذكاء الرقمي مجموع كل الذكاء البشري. ثانيًا، خلال المدة نفسها تنمو الروبوتات البشرية إلى ما بين 100 مليون ومليار. ثالثًا، يتضاعف الاقتصاد خلال خمس إلى سبع سنوات. كل واحد من هذه على ساعة من خمس سنوات، لا ثلاث.

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

لماذا نأخذ التوقّع على محمل الجد

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

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

ثانيًا، الروبوتات. الروبوتات البشرية هي ما يبدو عليه الأمر حين يتوقّف الذكاء عن العيش في البرمجيات فقط ويكتسب جسدًا يمتد به إلى العمل المادي. وسواء كان العدد 100 مليون أو مليارًا فذلك يتوقّف على الطاقة التصنيعية ومنحنيات الكلفة ويحمل هامش خطأ واسعًا، لكن الاتجاه نفسه، أي أن حصة معتبرة من العمل المادي تبدأ في الانتقال إلى الآلات، بات مرئيًا في المصانع وسلاسل الإمداد.

ثالثًا، الاقتصاد. حين يرتفع عرض الذكاء والعمل بحدّة يرتفع الناتج، وحين يرتفع الناتج بسرعة يدخل الاقتصاد فترة مضاعفة. توقّع ماسك بمضاعفة خلال خمس إلى سبع سنوات متفائل، لكن الآلية نفسها درسها علم الاقتصاد طويلًا. وحتى لو انزلق التوقيت بضع سنوات، يبقى الاتجاه قائمًا.

وبصدق، صحّة الاتجاه وصحّة التوقيت أمران مختلفان. تنطبق هنا ملاحظة روي أمارا القديمة على توقّعات التقنية: نميل إلى المبالغة في تقدير الأثر قصير المدى للتقنية والتقليل من أثرها بعيد المدى. قد يكون رقم الخمس سنوات خاطئًا. لكن الاتجاه أصعب في وصفه بالخطأ. من الأنزه أن نقول إن الاتجاه صحيح والسرعة غير مؤكّدة.

من العمل إلى الأصول: الجزء المتين والجزء الهشّ

يبدأ استنتاج المنشور الأصلي بتعريف الراتب بأنه ثمن إعارتك لوقتك. فإذا استطاعت الآلات أداء عمل ذلك الوقت بكلفة أقل وثبات أكبر، تنخفض قيمة الوقت الذي تعيره، وفي النهاية لا يبقى إلا ما تملكه.

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

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

أين يعمل هذا الذكاء

هنا نخطو خطوة من زاوية مدوّنة تقنية. الذكاء الرقمي الذي وصفه ماسك، وأدمغة الروبوتات البشرية، والناتج الذي يُفترض أنه يضاعف الاقتصاد، لا يحدث شيء من ذلك في الفراغ. فالحوسبة الفعلية التي تدرّب النماذج وتشغّل الاستدلال وتتحكّم في الروبوتات تحدث على وحدات GPU في مكان ما. بعبارة أخرى، الجوهر المادي لذكاء يتجاوز مجموع البشرية هو الحوسبة، والطاقة والبنية التحتية التي تُبقي تلك الحوسبة تعمل.

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

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

من منظور ThakiCloud

ثمة سبب يجعلنا لا نتعامل مع هذا الموضوع كأنه قصة شخص آخر. فما تبنيه ThakiCloud هو بالضبط تلك الأرضية التي يعمل عليها الذكاء.

العدسة الأولى هي ai-platform. إن ai-platform من ThakiCloud بنية تحتية للذكاء الاصطناعي والتعلّم الآلي تخصّص موارد GPU وتدرّب النماذج وتقدّم الاستدلال فوق Kubernetes. وثمة نقطة تحمل وزنًا خاصًا لدينا. فبدلًا من تسليم الحوسبة بالجملة لسحابة شخص آخر، نتيح للمؤسسة تشغيل نماذجها الخاصة على بياناتها الخاصة في بيئتها الخاصة. On-prem والذكاء الاصطناعي السيادي وكلفة التقديم المنخفضة والاستضافة الذاتية كلمات مفتاحية نعود إليها مرارًا. وبتطبيق المنطق أعلاه، الأمر يتعلّق بإعادة القدرة على امتلاك الحوسبة التي يستهلكها الذكاء والتحكّم بها إلى المؤسسات. ويثقل هذا المنظور أكثر في القطاع العام والصناعات المنظَّمة حيث تهمّ سيادة البيانات.

العدسة الثانية هي Paxis. امتلاك الحوسبة نصف الطريق فقط. فلا بدّ من مستوى تحكّم يحوّل تلك الحوسبة إلى عمل مؤتمت فعلي. Paxis سحابة أصلية للوكلاء تعمل فوق ai-platform، تعامل المهارات والأدوات والسياسات وسجلّات التدقيق كموارد من الدرجة الأولى. تختار من بين مئات المهارات لتشغيلها في صناديق رمل معزولة، وتنسج عدة وكلاء في مخطط DAG للتعاون، وتمرّر كل فعل عبر بوابة سياسات وسجلّ تدقيق. إذا كانت الحوسبة هي المصنع الذي يولّد القيمة، فإن Paxis أمر العمل لذلك المصنع وآلية أمانه. التقديم منخفض الكلفة يصنع اقتصاديات الأتمتة، وطبقة الوكلاء فوقه تحوّل تلك الاقتصاديات إلى نتائج عمل فعلية.

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

ما ينبغي مراقبته بحذر

مع الاتّفاق على الاتجاه العام، تبقى بضع نقاط ينبغي التمسّك بها حتى لا ننجرف.

أولًا، التوقيت. قد ينزلق رقم الخمس سنوات، ورقم الثلاث المنتشر أكثر. وإذ نتذكّر أن القيادة الذاتية الكاملة وُصفت بأنها “جاهزة العام المقبل” كل عام لأكثر من عقد، فكلما ثبّتت النبوءة تاريخًا بدقة أكبر، كان هدفها الشعور الذي تثيره أكثر من التاريخ نفسه. صدّق الاتجاه، لكن لا تصدّق الرزنامة.

ثانيًا، الوصفة. صحّة تشخيص ميل الدخل نحو رأس المال أمر مختلف عمّا ينبغي شراؤه الآن. فالأخير يُقدَّم عادة بنبرة يقين دون تحقّق. وكلما زادت الجملة يقينًا، ازدادت الحاجة إلى عادة التحقّق من أساسها على حدة.

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

خاتمة

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

المصادر

• الفيديو المصدر: مقطع لإيلون ماسك في حوار مع الرئيس التنفيذي لشركة BlackRock، لاري فينك، في المنتدى الاقتصادي العالمي في دافوس. اقتباسات هذا المقال فُرّغت مباشرة من ذلك الفيديو.
• تحقّق متقاطع من التصريحات: توقّعات ماسك الخمسية (تجاوز الذكاء الرقمي مجموع الذكاء البشري، ومئة مليون إلى مليار روبوت بشري، ومضاعفة الاقتصاد خلال خمس إلى سبع سنوات) نقلتها عدة وسائل إعلام بوصفها تصريحات دافوس.
• عبارة “ثلاث سنوات” المنتشرة هي تأطير صاحب المنشور الذي اقتبس المقطع، لا تصريح ماسك نفسه.
• ملاحظة روي أمارا (المبالغة قصيرة المدى والتقليل بعيد المدى) قاعدة إرشادية شائعة الاستشهاد في توقّعات التقنية.

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

مستودع everything-claude-code هو مجموعة إعدادات مفتوحة المصدر تعالج هذا الهيكل تحديدًا. نشر أحد الفائزين بهاكاثون Anthropic كامل إعداداته بمستوى إنتاجي بعد أن صقلها أكثر من ستة أشهر على مشروع خدمة TypeScript مصغّرة حقيقي، وجمع المستودع نجومًا بسرعة بعد الإصدار (نحو 9,700 بحسب التغريدة المصدر، [تقديري]). يستعرض هذا المقال ما يحتويه المستودع، والمبادئ التصميمية التي يقوم عليها، وكيف تتصل تلك المبادئ بمنصة الوكلاء التي تبنيها ThakiCloud. وقد تبنّت ThakiCloud مجموعة قواعد هذا المستودع كمعيار داخلي فعلي، لذا فهذا رأي قائم على التجربة لا مجرد تعريف.

ما هو everything-claude-code

يعرّف everything-claude-code (اختصارًا ECC) نفسه بأنه “نظام تحسين أداء هيكل الوكيل”. وهو يجمّع ستة أنواع من أصول الإعداد: وكلاء فرعيون يعالجون المهام المفوّضة (agents)، وحزم معرفة متخصصة تُستدعى عند الطلب (skills)، وخطّافات تتدخّل تلقائيًا قبل تنفيذ الأدوات وبعده (hooks)، وأوامر مائلة تغلّف الأعمال المتكررة (commands)، وقواعد تُطبَّق دائمًا (rules)، وإعدادات خوادم MCP التي تربط الأدوات الخارجية (MCPs).

والأهم أن هذا ليس إعداد مشروع هواية. فقد فاز المؤلف بهاكاثون Anthropic x Forum Ventures في سبتمبر 2025 ببناء منتج باستخدام Claude Code وحده، ثم صقل هذا الإعداد أكثر من عشرة أشهر وهو يشحن منتجات حقيقية يوميًا. ومؤشرات الجودة التي يذكرها المستودع محدّدة: 1,282 اختبارًا، وتغطية 98٪، و102 قاعدة تحليل ساكن. إن كون مجموعة إعدادات تحمل هذا المستوى من الانضباط هو بذاته دليل على أن المؤلف يفصل بين “قواعد تُسلَّم للذكاء الاصطناعي” و”كود يتحقق من الالتزام بتلك القواعد”.

سمة أخرى هي حياد الهيكل. صُمِّم ECC ليعمل ليس فقط في Claude Code بل أيضًا في وكلاء برمجة آخرين مثل Codex وOpencode وCursor. وفكرة إعادة استخدام القواعد والمهارات نفسها عبر أدوات متعددة هي نتيجة طبيعية لفلسفة التصميم التي نناقشها أدناه.

البنية: هيكل رفيع، مهارات ثقيلة

قلب ECC مبدأ واحد: ابنِ القدرة في المهارات لا في الهيكل. فالهيكل نفسه، أي الهيكل التنفيذي لحلقة النموذج والوصول إلى الملفات والصلاحيات والأمان، يبقى في حدّه الأدنى، بينما تُكدَّس المعرفة المجالية ومعايير الحكم والقوالب وحالات الفشل بكثافة في المهارات والقواعد. هذا ما يتيح للمهارة نفسها أن تعمل عبر أكثر من هيكل، سواء Claude Code أو Cursor.

تقود هذه الفلسفة مباشرة إلى تمييزين عمليين. الأول هو الفصل بين أدوار القواعد (Rules) والمهارات (Skills). القواعد معايير وقوائم تحقّق واسعة تُطبَّق دائمًا، مثل “تغطية اختبار 80٪ أو أعلى” أو “لا أسرار مكتوبة في الكود”. وهي تُحمَّل كل دور. أما المهارات فمعرفة تنفيذية مطلوبة بعمق لمهمة محدّدة، تُحمَّل فقط حين يستدعيها الطلب. القواعد تحدّد ماذا تفعل، والمهارات تخبرك كيف.

الثاني هو أن القواعد نفسها تُكدَّس في طبقات. يحتوي مجلد common/ على المبادئ العامة المستقلّة عن اللغة (أسلوب البرمجة، سير عمل git، الاختبار، الأمان، وغيرها)، وفوقه تمدّد المجلدات الخاصة باللغة مثل typescript/ وpython/ وgolang/ وweb/ القواعدَ العامة أو تتجاوزها. تعمل الأولوية مثل خصوصية CSS أو قواعد .gitignore: القاعدة الأكثر تحديدًا تتغلب على الأكثر عمومية. مثلًا توصي القواعد العامة بعدم القابلية للتغيير كمبدأ افتراضي، لكن قواعد Go الخاصة باللغة تنصّ على أن تعديل البنية عبر مستقبِلات المؤشرات أمر اصطلاحي، فتتجاوز تلك النقطة وحدها.

تبدو البنية الكاملة على النحو التالي.

flowchart TB
    A[طلب المطوّر] --> B[هيكل رفيع<br/>حلقة النموذج، الصلاحيات، الأمان]
    B --> C{يُحمَّل كل دور}
    C --> D[Rules<br/>معايير دائمة وقوائم تحقّق]
    C --> E[مُشغِّل الطلب]
    E --> F[Skills<br/>خبرة عند الطلب]
    D --> G[قواعد common العامة]
    G --> H[قواعد اللغة<br/>الخاص يتجاوز العام]
    B --> I[Agents<br/>مختصّون مفوَّضون]
    B --> J[Hooks<br/>تحقّق آلي قبل/بعد التنفيذ]
    B --> K[خوادم MCP<br/>ربط الأدوات الخارجية]
    F --> L[مخرجات متسقة]
    H --> L
    I --> L

يبدأ اتضاح كيف تحلّ هذه البنية مشكلة “نسيان القواعد كل مرة” السابقة. فالقواعد تُحمَّل تلقائيًا كل جلسة، فلا يحتاج المطوّرون إلى إعادة لصق الأعراف. والمهارات تُحمَّل فقط عند الحاجة، فلا تهدر نافذة السياق. والخطّافات تتحقق على مستوى الكود مما إذا كانت أداة قد خالفت قاعدة. بعبارة أخرى، فحوصات حتمية تفرض الجودة بدل الاعتماد على تقرير النموذج الذاتي.

كيف تتبنّاه فعليًا

هناك مساران للتبنّي. الأسهل هو تثبيته عبر سوق إضافات Claude Code. والأكثر مباشرة هو استنساخ المستودع ونسخ الأصول التي تحتاجها فقط إلى مجلد إعداد Claude لديك. ولتجنّب كسر البنية الطبقية، انسخ على مستوى المجلد.

# أنشئ مساحة أسماء قواعد ECC مرة واحدة.
mkdir -p ~/.claude/rules/ecc

# انسخ القواعد العامة (مطلوبة لكل المشاريع).
cp -r rules/common ~/.claude/rules/ecc/

# انسخ القواعد الخاصة باللغة المطابقة لحزمة مشروعك.
cp -r rules/typescript ~/.claude/rules/ecc/
cp -r rules/golang ~/.claude/rules/ecc/
cp -r rules/web ~/.claude/rules/ecc/

هنا يحذّر المستودع صراحةً من خطأ شائع. لا تنسخ بالتسطيح عبر نمط بدل مثل rules/common/*. فالمجلدات العامة والخاصة باللغة تحتوي على ملفات بالأسماء نفسها (coding-style.md وtesting.md وغيرهما)، فالتسطيح يجعل ملف اللغة يكتب فوق الملف العام ويكسر المرجع النسبي (../common/). وللحفاظ على التسلسل الهرمي، يجب نسخ المجلدات كاملة.

تحتاج إعدادات خادم MCP إلى معالجة منفصلة. اسحب فقط إعدادات الخوادم التي تحتاجها من mcp-configs، لكن النقطة الأساسية هي عدم تفعيلها كلها دفعة واحدة. يحذّر المستودع بقوة هنا، لأن كثرة الأدوات المرتبطة قد تقلّص نافذة سياق سعتها 200k إلى 70k فعليًا. فكل خادم MCP مفعَّل يدفع كلفة مخطّط كل دور، لذا تحتاج إلى انضباط تفعيل الخوادم التي تستخدمها فعلًا فقط.

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

دلالات التطبيق على منتجات ThakiCloud

تتداخل المبادئ التصميمية التي يطرحها ECC بشكل لافت مع ما تبنيه ThakiCloud. دعوني أقسّم ذلك إلى عدستين.

عدسة Paxis (منصة الوكلاء). إن Paxis من ThakiCloud هو مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform، ويتعامل مع Skills وTools وPolicies وAudit Logs بوصفها موارد من الدرجة الأولى. وفلسفة ECC “هيكل رفيع، مهارات ثقيلة” هي بالضبط النموذج الذي يحوّله Paxis إلى منتج. فـ Skill Harness في Paxis يختار من أكثر من 960 مهارة عبر BM25، وينفّذها في صناديق رمل معزولة، ويمرّر كل فعل عبر بوابات السياسات وسجلات التدقيق. بعبارة أخرى، طبقات القواعد والمهارات والخطّافات التي يديرها ECC يدويًا في مجلد ~/.claude لمطوّر فرد، يرفعها Paxis إلى مستوى سحابة متعددة المستأجرين من الاختيار التلقائي والتنفيذ المعزول وفرض السياسات والتدقيق. ويمكن اعتبار Paxis الصورة التشغيلية بحجم المنصّة للمبادئ التي تحقّق منها ECC في سير عمل فردي. ورؤية ECC بأن “القواعد تُحمَّل كل دور وتدفع إيجارًا” تنتقل مباشرة إلى تصميم Paxis القائم على تحميل المهارات عند الطلب فقط وترشيح الضجيج عبر BM25.

عدسة ai-platform (البنية التحتية). تنطبق فكرة القواعد الطبقية أيضًا على توحيد البنية التحتية. فكما يفصل ECC بين القواعد العامة وقواعد اللغة، تفصل ai-platform من ThakiCloud بين الإعدادات الافتراضية على مستوى المؤسسة والتجاوزات لكل عنقود ولكل مستأجر. إن تعريف معايير البنية مثل K8s وجدولة Kueue GPU وخدمة vLLM مرة واحدة وتطبيقها باتساق عبر بيئات عملاء متعددة، مع تجاوز خصوصيات كل بيئة في الطبقات الأدنى، هو الشكل نفسه لنموذج أولوية القواعد في ECC. وكلما اشتدّت متطلبات العميل المتعلقة بالتشغيل داخل المؤسسة والسيادة، ازداد تحوّل انضباط “افرض معيارًا عُرّف مرة، مع تجاوزه بأمان لكل بيئة” إلى موثوقية تشغيلية.

باختصار، ECC هو خلاصة نظافة الهيكل المصنوعة يدويًا من قِبل فرد، وThakiCloud تبني منتجات تحافظ فيها المنصّة على تلك النظافة تلقائيًا. الخدمة منخفضة الكلفة (ai-platform) تصنع اقتصاديات الوكلاء، وفوقها يصنع تنفيذ المهارات بسياسة وتدقيق (Paxis) الثقة.

الحدود والاعتراضات

من أجل التوازن، دعوني أذكر الجانب الآخر. أولًا، ECC إعداد يعكس بقوة ذوق شخص واحد وسير عمله. فهو نتيجة صقل خدمة TypeScript مصغّرة معيّنة ستة أشهر، لذا فإن نسخه كما هو إلى حزمة مختلفة أو ثقافة فريق مختلفة قد يخلق احتكاكًا بدلًا من ذلك. ولهذا يحذّر المستودع مرارًا من النسخ واللصق كما هو، بل التكييف مع احتياجات مشروعك.

ثانيًا، كلما ازداد الإعداد سماكة، ارتفعت كلفة الصيانة. فتحميل القواعد كل دور يعني استهلاك الرموز كل دور. وبينما تضيف قواعد ومهارات، عليك أن تسأل باستمرار “هل يحتاج هذا فعلًا إلى الوجود في كل جلسة؟”، وإلا تسرّبت ميزانية السياق بهدوء. ويعالج ECC نفسه ذلك بانضباط “كل سطر يجب أن يدفع إيجارًا”، لكن الحفاظ على الانضباط في النهاية مهمة بشرية.

ثالثًا، حياد الهيكل مثالٌ لا ضمان. فالوعد بأن المهارة نفسها تعمل بشكل مطابق في Claude Code وCursor لا يصحّ إلا حين يكون سطح الأدوات ونموذج الصلاحيات في كل هيكل متوافقين فعلًا. فإن اختلفت طريقة تنفيذ الخطّافات أو قواعد الوصول إلى الملفات بين الهياكل، فقد تنحرف مهارة مكتوبة بحياد على هيكل معيّن بهدوء.

ومع ذلك، قيمة ECC واضحة. فمشكلات الجودة في أدوات البرمجة بالذكاء الاصطناعي تنشأ عادةً لا لأن النموذج ضعيف، بل لأنه لا يوجد هيكل قواعد وتحقّق يلفّ النموذج. وقد نشر ECC ذلك الهيكل في صورة مجرَّبة ميدانيًا، وThakiCloud على طريق رفع المبادئ نفسها إلى حجم المنصّة. ولأي فريق يسعى إلى تسليم الكود للذكاء الاصطناعي، تستحق رسالة هذا المستودع، “افحص الهيكل قبل أن تبدّل النموذج”، أن تبقى في البال.

المصادر

• everything-claude-code (affaan-m/everything-claude-code)، GitHub
• ملف المؤلف المتعلق بـ zenith.chat، الفائز بهاكاثون Anthropic x Forum Ventures
• التغريدة الأصلية: ‎@Ryrenz (RT @hjguyhan)، 2026-07-20

نظرة عامة

يمكن تلخيص أخبار الفترة من أواخر يونيو حتى يوليو 2026 في سطر واحد: الاستخدام العشوائي للنماذج المتطورة (frontier models) في كل مهمة يجعل التكلفة يصعب تحملها، بل ويصعب حتى تتبع مصدرها. وقد ظهرت الحادثة بشكل درامي. فقد جرت محاولة تحصيل مبلغ يقارب 2.5 مليار وون من مستخدم محلي واحد، ثم محاولة تحصيل نحو 25 مليار وون لاحقا. ولحسن الحظ لم يُسحب أي مبلغ فعليا بسبب تجاوز حد البطاقة، غير أن تكرار وصول مبلغ غير طبيعي إلى مرحلة طلب موافقة البطاقة، وليس مجرد خطأ عرض، هو ما يمنح الحادثة وزنها المختلف.

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

ماذا حدث في الشهر الأخير

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

المشكلة الثانية كانت في قابلية مراقبة تكلفة الوكلاء. وبحسب تقارير AI Times و The Information، أعلنت شركة ناشئة متخصصة في تدقيق التكاليف تُدعى Vaudit أنها راجعت فواتير 60 شركة بقيمة إجمالية نحو 34 مليون دولار، وخلصت إلى أن نحو 1.7 مليون دولار منها كانت فوترة زائدة. وشكّل استخدام Claude Code جزءا كبيرا من نطاق المراجعة، وذُكرت شركات مثل باناسونيك وHP وهوندا ضمن العملاء. وحسب ادعاء الشركة، فإن الأنماط شملت تسجيل استخدام نموذج رخيص بأسعار نموذج أغلى، وفرض رسوم على مهام لم تُنجز، وتكرار إعادة المحاولة التلقائية بعد الخطأ فيما يُعرف بـعاصفة إعادة المحاولة (retry storm). وهنا ينبغي توضيح نقطتين. أولا، ردت أنثروبيك بأنها لا تفرض رسوما على الطلبات غير المكتملة أو الاستجابات الخاطئة، وأنه لا يوجد دليل واسع على فوترة زائدة. ثانيا، تحصل Vaudit على نسبة من مبالغ الاسترداد الناجحة، أي أنها شركة تدقيق تجارية، لذا يجب قراءة هذه الأرقام كنتيجة تحقيق من طرف واحد لا كتدقيق حسابي مستقل. وبعبارة أخرى، نحن الآن في مرحلة تصادم بين ادعاءات شركة التدقيق ونفي المزود.

المشكلة الثالثة كانت في استجابة السوق. وذكرت The Information أن الشركات بدأت بفصل المهام: النماذج الرخيصة للتصنيف والتلخيص والتحويل البسيط، والنماذج المتطورة للبرمجة المعقدة ومهام الوكلاء، والنماذج مفتوحة الأوزان أو المستضافة ذاتيا للمهام المتكررة عالية الحجم. ونقلت الفايننشال تايمز أن شركات مثل DoorDash وSiemens وAirbnb اعتمدت نماذج DeepSeek أو من عائلة Moonshot لخفض التكلفة. وفي تقرير لـ Business Insider، اعترف حتى مسؤولو المنصة في أنثروبيك بأن ما يُعرف بـالتقنية المعلوماتية الظل (shadow IT)، أي اعتماد كل قسم لأدواته الخاصة بشكل منفصل، أدى إلى تضخم تكاليف الذكاء الاصطناعي في بعض الشركات، لكنهم شددوا على أن الحل ليس إيقاف الاستخدام أو فرض سقف ميزانية موحد، بل اختيار النموذج بحسب المهمة وإدارة مركزية للتكلفة على مستوى المؤسسة. كما تغيرت سياسات التسعير نفسها مرارا: تعدّلت مرات عدة شمولية النماذج عالية الأداء الأحدث ضمن الاشتراك وتوقيت التحول إلى الدفع بحسب الاستخدام، وتكرر تمديد مواعيد انتهاء العروض الترويجية. بل ورد أن إتاحة Claude Fable 5 مجانا امتدت حتى 19 يوليو. وكانت صعوبة توقع تكلفة الشهر القادم أكبر إزعاج لمسؤولي المشتريات، أكثر حتى من مسألة الأداء.

لماذا لا يمكن مراقبة تكلفة الوكلاء

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

flowchart TB
    U["طلب مستخدم واحد"] --> P["وضع خطة الوكيل"]
    P --> L["حلقة التنفيذ"]
    L --> T["استدعاء أدوات · استدعاء نموذج<br/>عشرات إلى مئات المرات"]
    T --> R{"هل نجحت؟"}
    R -->|"فشل"| RS["إعادة محاولة تلقائية<br/>(retry storm)"]
    RS --> T
    R -->|"نجاح"| ACC["توكن · كاش · tool call<br/>تجميع تراكمي"]
    ACC --> INV["الفاتورة: مبلغ نهائي في سطر واحد"]
    INV -.فجوة المراقبة.-> U

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

دلالات التطبيق على منتجات ThakiCloud

هذه المشكلة هي النقطة التي يستهدفها منتجا ThakiCloud من زاويتين مختلفتين. ولأن منظور البنية التحتية ومنظور الوكلاء يكملان بعضهما، نستخدم في هذا الموضوع العدستين معا.

عدسة ai-platform: الملكية هي الحل لأحمال العمل المتكررة. الاستنتاج الذي وصل إليه السوق واضح. فمعالجة حتى المهام السهلة بنماذج متطورة يجعل التكلفة غير محتملة، بينما تصبح استضافة نموذج مفتوح الأوزان ذاتيا خيارا اقتصاديا للمهام المتكررة عالية الحجم. ومنصة ai-platform من ThakiCloud هي بالضبط بنية تحتية للذكاء الاصطناعي وتعلم الآلة قائمة على K8s مصممة لهذه النقطة. فهي تستخدم Kueue لجدولة وحدات GPU في طابور وزيادة معدل استخدامها، وتستخدم vLLM لخدمة النماذج مفتوحة الأوزان، وتعزل الاستخدام بحسب كل قسم عبر عزل متعدد المستأجرين مع فوترة منفصلة. فإذا كانت واجهات برمجة التطبيقات القائمة على الدفع بحسب الاستخدام تنتج فواتير يصعب توقعها، فإن الاستضافة الذاتية تبني بنية تكلفة GPU ثابتة لا يتقلب سعرها حتى مع تزايد الاستخدام. وعلى عكس الأنظمة الخارجية القائمة على الدفع بحسب الاستخدام التي تتغير سياساتها باستمرار، يحوّل النشر الداخلي أو السيادي إمكانية التنبؤ بالتكلفة نفسها إلى أصل قائم بذاته. كما أن عدم خروج البيانات إلى الخارج يمثل قيمة إضافية للمؤسسات ذات متطلبات التنظيم والأمن المحلية العالية.

عدسة Paxis: جعل كل تصرف للوكيل قابلا للتدقيق. كان جوهر فجوة المراقبة هو حلقة الوكيل، وهذا هو بالضبط المجال الذي تعالجه Paxis. فـPaxis هي مستوى التحكم في السحابة الأصيلة للوكلاء (Agent-Native Cloud) من ThakiCloud، وتعمل فوق ai-platform، وتتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. فكل ما يخص أي مهارة استدعاها الوكيل وبأي أداة وكم مرة، وفي أي بيئة معزولة تم التنفيذ، يُسجَّل بالكامل في سجل التدقيق. وفي هذه البنية، بدلا من أن تُضخّم عاصفة إعادة المحاولة الفاتورة بصمت، تظهر حلقة إعادة المحاولة بوضوح في سجل التدقيق، وتوقف بوابات السياسة الاستدعاءات التي تتجاوز العتبة المحددة. فتصميم يختار من بين أكثر من 960 مهارة عبر خوارزمية BM25 وينفذها في بيئة معزولة، ويُمرّر كل تصرف عبر السياسة والتدقيق، هو إجابة بنيوية بالضبط على مشكلة صعوبة معرفة أين نشأت التكلفة من مجرد النظر إلى الفاتورة. فالخدمة منخفضة التكلفة (ai-platform) تجعل الوكلاء اقتصاديين، بينما تجعل المراقبة على مستوى كل تصرف (Paxis) هذه الجدوى الاقتصادية قابلة للتنبؤ. وهكذا تتكامل العدستان.

الحدود والرأي المعاكس

من أجل التوازن، نوضح الجانب المعاكس بجلاء. أولا، ليست النماذج المتطورة تبذيرا بالضرورة. فبحسب تقرير وول ستريت جورنال، ترى شركات مثل Shopify أن النماذج المتطورة، في مهام البرمجة المعقدة والوكلاء متعددة الخطوات، توفر وقت المهندسين بما يبرر سعرها المرتفع. في المقابل، تتوخى شركات مثل Spotify وTwilio الحذر في تقييم ما إذا كان التحسن الطفيف في الأداء يبرر التكلفة الإضافية. أي أن الجواب ليس “تخلَّ عن النماذج المتطورة”، بل “وزّع بحسب صعوبة المهمة”. كما أن الاستضافة الذاتية ليست حلا شاملا لكل شيء؛ فتخفيض المهام التي تتطلب أعلى مستوى من الاستدلال إلى نماذج مفتوحة الأوزان يؤدي إلى تراجع الجودة، ويخلق عبئا تشغيليا جديدا يشمل تشغيل وحدات GPU وتحديث النماذج وتصحيحات الأمان.

ثانيا، الأرقام المتعلقة بالفوترة الزائدة المذكورة في هذا المقال ليست حقائق مؤكدة. فادعاء Vaudit هو إعلان من شركة تدقيق تجارية، وقد نفته أنثروبيك، لذا فإن الأدق حاليا هو قراءة الموقف على أنه تصادم بين طرفين. وحادثة الفوترة بمبلغ 25 مليار وون كذلك لم يُسحب فيها أي مبلغ فعليا، ولم يُكشف بعد عن تفسير تقني لسبب نشوء إعداد الشحن التلقائي. والاستنتاج الذي نخلص إليه من هذه الأخبار لا يستهدف مزودا بعينه، بل هو مبدأ مفاده أنه في عصر الوكلاء، وأيا كان المزود المستخدَم، يجب على الجهة المستخدِمة نفسها أن تؤمّن مراقبة التكلفة وحوكمتها. فمسألة اختيار نموذج جيد ومسألة ضبط ذلك النموذج مسألتان منفصلتان، وما كشفته أخبار الشهر الأخير هو أن المسألة الثانية كانت فارغة طوال الوقت.

المصادر

• ZDNet Korea، “مستخدم محلي تلقى طلب دفع بقيمة 25 مليار وون… جدل حول خطأ فوترة أنثروبيك” (2026-07-09)
• ZDNet Korea، “أنثروبيك التي طالبت بـ25 مليار وون: تبين أنه خطأ في إعداد الشحن التلقائي” (2026-07-16)
• AI Times، “أنثروبيك في جدل ‘الفوترة الزائدة للذكاء الاصطناعي’: تحصيل رسوم حتى على المهام الفاشلة” (2026-06)
• The Information، تقرير عن سيطرة الشركات على تكلفة الذكاء الاصطناعي وتوزيع النماذج (2026-06-23)
• Financial Times، “Companies turn to Chinese AI models to cut costs” (2026-07)
• Business Insider، “Anthropic Official Warns Against ‘Wrong’ AI Cost Response” (2026-07-15)
• The Wall Street Journal، “Meet the Companies Shelling Out for Top AI Models” (2026-07)

نظرة عامة

كل من شغّل نموذج LLM محلياً يصطدم بالجدار نفسه: إذا كانت أوزان النموذج أكبر من ذاكرة الـ GPU، يفيض الزائد إلى ذاكرة الـ CPU. وراية -ngl في llama.cpp (عدد الطبقات التي توضع على الـ GPU) تفعل هذا بالضبط. المشكلة أنها تقطع فقط على مستوى الطبقة. تخلط الطبقة الواحدة موتّرات مختلفة الطبيعة تماماً (أوزان attention، وأوزان FFN، ومعاملات التطبيع)، ومع ذلك تُعامَل بمبدأ الكل أو لا شيء: إما أن يذهب الكل إلى الـ GPU أو يبقى على الـ CPU.

سبب خسارة هذا الوضع الكتلي بسيط. قد يجعل نفس الـ 1GB في الـ VRAM موتّراً أسرع 10 أضعاف وآخر أسرع ضعفين فقط. الـ VRAM مورد نادر، والقطع الكتلي يمنعك من انتقاء الموتّرات ذات الربح الأعلى لكل GB. يستهدف ATSInfer هذا بالضبط. فهو يحلّل أداء كل موتّر على الـ CPU والـ GPU ويملأ الـ VRAM بدءاً من الموتّرات ذات أعلى ربح سرعة لكل GB. إذا كان ktransformers الأخير حيلةً على “مستوى الخبير” تدفع خبراء MoE إلى الـ CPU (انظر مقالتنا ذات الصلة: إعادة إنتاج الـ 28 ضعفاً لـ ktransformers)، فإن ATSInfer هو التعميم الأدق على “مستوى الموتّر”. واللافت أنه ينطبق على النماذج الكثيفة (dense) وليس MoE فقط.

ما هذه التقنية

ATSInfer نظام استدلال هجين CPU-GPU مبنيّ كامتداد لـ llama.cpp بنحو 15 ألف سطر من C++. كما يقول الاسم، فإن “الجدولة الآلية للموتّرات (Automated Tensor Scheduling)” هي الجوهر، وتتشابك ثلاث آليات.

flowchart TB
    A["أوزان النموذج<br/>(RAM، تتجاوز سعة VRAM)"] --> B["تحليل لكل موتّر<br/>قياس ربح السرعة لكل GB"]
    B --> C{"التوزيع الثابت<br/>الموتّرات الأعلى ربحاً إلى VRAM أولاً"}
    C -->|"موتّرات عالية الربح"| D["مقيمة في VRAM"]
    C -->|"موتّرات منخفضة الربح"| E["مقيمة في RAM"]
    D --> F["نقل ديناميكي واعٍ بالحمل<br/>ترقية/تنزيل حسب حمل التشغيل"]
    E --> F
    F --> G["تنسيق غير متزامن بين CPU وGPU<br/>تداخل الحساب ونقل PCIe"]
    G --> H["إخراج الرموز<br/>prefill · decode"]

أولاً، التوزيع الثابت للموتّرات (static placement). قبل تحميل النموذج، يقيس مدى تسارع كل موتّر على الـ GPU، ثم يضع الموتّرات على الـ GPU بترتيب “أكبر سرعة مُعادة لكل GB من الـ VRAM مستخدَم”. هذا قريب من مسألة حقيبة الظهر (knapsack) ويستغل مباشرةً التباين على مستوى الموتّر الذي تجاهله التوزيع الكتلي.

ثانياً، النقل الديناميكي الواعي بالحمل (load-aware dynamic transfer). التوزيع الثابت وحده لا يكفي. خلال الاستدلال الفعلي، يتغير الحمل لحظةً بلحظة مع حجم الدفعة وطول السياق وعدد الطلبات المتزامنة. يرقّي ATSInfer موتّراً معيناً من الـ RAM إلى الـ GPU أو ينزّله بناءً على حالة التشغيل. إذا كان التوزيع الثابت هو خط الانطلاق، فالنقل الديناميكي هو تغيير المسار أثناء القيادة.

ثالثاً، التنسيق غير المتزامن بين CPU وGPU (asynchronous coordination). يُداخِل بين حساب الـ CPU وحساب الـ GPU ونقل الـ PCIe الذي يصل بينهما. التنفيذ الساذج يترك الـ GPU خاملاً ينتظر عمل الـ CPU أو حركة البيانات؛ وطبقة التنسيق هذه تملأ ذلك الوقت الخامل. تُبلّغ الورقة أن هذا يرفع متوسط استغلال SM (المعالج المتعدد التدفق) في الـ GPU بنحو 70%.

النتائج التي تبلّغ عنها الورقة

مرة أخرى: الأرقام أدناه قيم أبلغت عنها الورقة، لا شيء أعدنا إنتاجه. شيفرة ATSInfer لم تُنشر بعد (حتى نقاش التغريدات قال “أيها الباحثون، رجاءً شاركوا الشيفرة مع فريق llama.cpp”)، وإعادة إنتاج نموذج بحجم 120B مع RTX 4090 صعبة في البيئة المعزولة وراء هذه المقالة. لذا بدلاً من إعادة الإنتاج، نركّز على التحليل البنيوي والدلالات.

عنوان الورقة العريض: مقابل الأنظمة الهجينة الحالية (بما فيها إنزال llama.cpp على مستوى الطبقة)، يتحسّن الـ prefill (الإنتاجية حتى أول رمز) حتى 1.94 ضعفاً، والـ decode (الرموز المولّدة في الثانية) حتى 3.29 ضعفاً.

الإعداد هو نظام RTX 4090 (24GB) وRTX 3060 مع 64GB من الـ RAM، والنماذج المُتحقَّق منها هي:

• Llama 3.1-70B (INT4)
• Qwen3-Next-80B-A3B (INT4)
• Qwen3.5-122B-A10B (INT4)
• GPT-OSS-120B (MXFP4)

فالادّعاء المركزي هو تشغيل نموذج بـ 122 مليار معامل (وهو MoE بعدد معاملات نشطة أقل بكثير) على بطاقة 24GB واحدة. اقرأ هنا أمرين منفصلين. أولاً، “3.29 ضعفاً” هو حدّ أقصى تحت ظروف محددة، لا متوسط عبر كل نموذج وكل دفعة. ثانياً، الربح يأتي جوهرياً لا من “إدخال ما لم يكن يدخل في الـ GPU” بل من “جعل حركة CPU-GPU الحتمية أذكى”. تبقى الفيزياء نفسها في أن عرض نطاق الـ PCIe هو عنق الزجاجة، لذا فإن مساهمة ATSInfer هي استخدام ذلك العرض دون هدر وتقليل الوقت الخامل للـ GPU.

دلالات لمنتجات ThakiCloud

منصة ai-platform من ThakiCloud بنية تحتية للذكاء الاصطناعي/تعلّم الآلة تخدم النماذج عبر بيئات عملاء متنوعة على Kubernetes وKueue. الجدولة على مستوى الموتّر مثل ATSInfer تتوافق مع اتجاه نراقبه عن كثب.

أولاً، اقتصاديات البيئات المحلية (on-premises) والسيادية. في السياقات التي لا يمكن أن تغادر فيها البيانات المبنى، كعملاء القطاع العام والمالي المحليين، يجب أن تعمل النماذج على بطاقات GPU مملوكة. إذا استطاعت بضع بطاقات استهلاكية حمل نموذج متوسط إلى كبير بدلاً من رف من ثماني بطاقات H100، تنخفض النفقات الرأسمالية الأولية بشكل كبير. ما تُظهره تجارب ATSInfer هو أن الافتراض “إن نقص الـ VRAM فعليك ببساطة شراء المزيد من الـ GPU” يمكن تخفيفه جوهرياً عبر تحسين توزيع الموتّرات. الثمن، بالطبع، هو انخفاض الإنتاجية، لذا فهو غير مناسب لأحمال حرجة الكمون. الحكم على هذه المقايضة لكل حمل هو دور طبقة الخدمة لدينا.

ثانياً، الاقتران بالجدولة متعددة المستأجرين. “النقل الديناميكي الواعي بالحمل” في ATSInfer هو حركة موتّرات داخل عقدة واحدة، لكن الفكرة تصمد على مستوى العنقود أيضاً. عندما يصفّ Kueue موارد الـ GPU ويوزّعها، فإن سياسة تقرّر أي طلب يُعالَج بأي دقة وأي ملف إنزال بناءً على الحمل هي مجال نفكّر فيه بالفعل. تماماً كما يعصر التحليل على مستوى الموتّر مكاسب الموارد داخل العقدة، يفعل مجدول العنقود الشيء نفسه عبر العقد.

ثالثاً، إعادة تعريف منحنى الكلفة-الجودة. في مقالة إعادة إنتاج ktransformers أظهرنا بالقياس المباشر أن أرقاماً بارزة مثل “28 ضعفاً” تقوم على افتراضات خفية. و”3.29 ضعفاً” في ATSInfer يستحق العدسة نفسها. ليس رقماً تسويقياً، بل القيمة التي تظهر على نماذج عملائنا الفعلية ودفعاتهم الفعلية واتفاقيات مستوى الخدمة الفعلية، هي ما نتحقق منه. التنافسية عند كلفة خدمة منخفضة تأتي في النهاية من تراكم هذا النوع من التحقق بالضبط.

الحدود والحجج المضادة

أكبر حدّ هو عدم نشر الشيفرة. لا يمكن التحقق مما إذا كانت أرقام الورقة قابلة لإعادة الإنتاج، وما إذا كانت تصمد على أجهزة ونماذج أخرى، إلا بعد ظهور الشيفرة. امتداد بـ 15 ألف سطر من C++ هو أيضاً مهمة صيانة ودمج مع المنبع (upstream) غير هيّنة. الفرع (fork) الذي لا يُدمج أبداً يتخلّف عن تغييرات المنبع مع الوقت ويفقد قيمته.

ثانياً، اعتماد المكاسب على الظروف. يعتمد أثر التوزيع على مستوى الموتّر بشدة على أداء الـ CPU، وعرض نطاق الـ RAM، وجيل الـ PCIe. تفترض تجارب الورقة 64GB من الـ RAM؛ فإن نقص الـ RAM لا يترك مجالاً لإبقاء الموتّرات على الـ CPU أصلاً. على أنظمة PCIe 3.0، يرجّح أن يصبح النقل عنق الزجاجة ويقلّص الربح جوهرياً ([تقدير]، لا تفصّل الورقة مقارنةً جيلاً بجيل).

ثالثاً، السقف المتأصّل لتحسين الـ decode. الـ decode مهمة مقيّدة بالذاكرة (memory-bound). مهما أحسنت الجدولة، يجب الوصول إلى الأوزان خارج الـ VRAM بطريقة ما مع كل رمز، فيكون حتماً أبطأ من الإقامة الكاملة في الـ VRAM. ما يفعله ATSInfer هو “تقليل مقدار التباطؤ”، لا “إزالة التباطؤ”. وبناءً على الحجة المعاكسة: لخدمة إنتاجية تحتاج حقاً كموناً منخفضاً وإنتاجية عالية، يبقى استخدام بطاقة GPU تحمل النموذج كاملاً في الـ VRAM هو القرار الصائب. يتألق ATSInfer في مجال التطوير والتقييم والدفعات الصغيرة حيث لا تقدر على تلك البطاقة أو لا تحتاجها.

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

المصادر

• ورقة ATSInfer: arXiv:2607.10183, Automated Tensor Scheduling for Hybrid CPU-GPU LLM Inference on Consumer Devices
• مقالة ذات صلة: رفّ بـ 400 ألف دولار على 24GB؟ أعدنا إنتاج الـ 28 ضعفاً لـ ktransformers

يستعرض هذا المقال أولاً الحقائق المؤكدة حول ماهية Kimi K3، ثم ينتقل إلى كيفية قراءة لوحة نتائجه المبهرة، وأخيراً إلى ما يحتاج المشغّلون للتحقق منه قبل وضع هذا النموذج في منتج فعلي. بالنسبة لشركة بنية تحتية مثل ThakiCloud، التي تخدم وتشغّل النماذج عبر بيئات عملاء متعددة، هذا السؤال ليس فضولاً أكاديمياً بل هو قرار الاعتماد نفسه. إذا وثقنا بسطر نتيجة واحد ونشرنا نموذجاً بـ 2.8 تريليون معامل داخلياً (on-premises)، لنكتشف لاحقاً أنه لا يفي بالتوقعات في العمل الفعلي، فإن التكلفة تقع بالكامل علينا وعلى عملائنا.

ما هو Kimi K3

Kimi K3 هو نموذج مزيج خبراء (Mixture-of-Experts، أو MoE) واسع النطاق أطلقته Moonshot AI في 16 يوليو 2026. يبلغ إجمالي عدد المعاملات 2.8 تريليون، ما يجعله أول نموذج مفتوح الأوزان يدخل فئة الـ 3 تريليون معامل. غير أن هذه الـ 2.8 تريليون هي الحجم الإجمالي، وفي الاستدلال الفعلي يستخدم النموذج بنية متناثرة (sparse) تُفعّل فقط 16 خبيراً من أصل 896 خبيراً، لذا لا تعمل جميع المعاملات في كل رمز (token). إغفال هذه النقطة يقود بسهولة إلى سوء فهم مفاده أن “كامل الـ 2.8 تريليون يعمل دفعة واحدة”.

تتضمن البنية المعمارية عدة عناصر جديدة. تسمي Moonshot هذا إطار عمل Stable LatentMoE، وتوضح أنه يدعم سياق يصل إلى مليون رمز من خلال Kimi Delta Attention (KDA) و Attention Residuals (AttnRes). أُضيفت إلى ذلك مكونات مثل Quantile Balancing لتوزيع الخبراء، وتحسين Per-Head Muon، وتفعيل SiTU، و Gated MLA. تدّعي الشركة أن هذه التحسينات أدت إلى تحسن في كفاءة التوسّع بنحو 2.5 ضعف مقارنة بالإصدار السابق K2. بما أن هذا الرقم هو ادعاء من الجهة المعلنة، فمن الأسلم قراءته كقيمة مرجعية إلى أن يظهر تكرار مستقل من طرف ثالث.

من منظور التقديم (serving)، أهم جانب عملي هو التكميم (quantization). يتعامل K3 مع الأوزان بصيغة MXFP4 ومع القيم التنشيطية بصيغة MXFP8، وطبّق تدريباً واعياً بالتكميم (QAT) بدءاً من مرحلة الضبط الدقيق الموجّه (SFT). ونتيجة لذلك، انخفضت سعة تخزين أوزان النموذج بأكمله (2.8 تريليون) إلى نحو 1.4 تيرابايت، أي ما يقارب ربع الـ 5.6 تيرابايت التي كانت ستتطلبها أوزان FP16. ومع ذلك، يظل 1.4 تيرابايت رقماً كبيراً. من المقرر إصدار الأوزان الكاملة في 27 يوليو بموجب ترخيص MIT معدّل.

فيما يلي مخطط مبسّط لمسار الاستدلال في K3.

flowchart TB
    A[رموز الإدخال<br/>حتى سياق مليون رمز] --> B[Kimi Delta Attention<br/>+ Attention Residuals]
    B --> C{موجّه Stable LatentMoE}
    C -->|اختيار 16 من أصل 896| D[الخبراء النشطون<br/>أوزان MXFP4]
    C -.الخبراء غير النشطين.-> E[قرص/تفريغ<br/>~1.4 تيرابايت إجمالاً]
    D --> F[قيم تنشيطية MXFP8<br/>مع تطبيق QAT]
    F --> G[رموز الإخراج]

ما تقوله المعايير القياسية

بالنظر إلى النتائج وحدها، فإن Kimi K3 مبهر بالتأكيد. عند الإطلاق، سجّل K3 نسبة 93.5% في GPQA Diamond، وهي أعلى نتيجة بين النماذج مفتوحة الأوزان المتاحة علناً في ذلك الوقت. حصل على 88.3% في Terminal-Bench 2.1، وتصدّر SWE Marathon و Program Bench، اللذين يقيسان جلسات البرمجة المستمرة، بالإضافة إلى BrowseComp و OmniDocBench. هذا يشير إلى أنه قوي بشكل خاص في مهام الوكلاء طويلة الأمد وفي البرمجة.

لكنه ليس في المركز الأول في كل المؤشرات. تخلّف K3 عن Fable 5 من Anthropic في FrontierSWE و HLE-Full، ويُقيَّم في المركز الثالث تقريباً، خلف Fable 5 و GPT-5.6 Sol، في التقييمات المركّبة الصعبة للوكلاء والبرمجة. يلخّص الجدول التالي ذلك.

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

لكن هل يمكننا الوثوق بالمعايير القياسية

هنا تبدأ الحجة الأساسية لهذا المقال. حقيقة أن النتيجة عالية وحقيقة أن هذه النتيجة تتكرر في عملنا الفعلي أمران مختلفان. مباشرة بعد إطلاق K3، تداولت آراء على منصة X مفادها أن “Moonshot ربما أفرطت في التكيّف مع المعايير القياسية”. أشار Guillermo Rauch من Vercel، استناداً إلى تقييم داخلي، إلى أن K3 كان في القمة في مهام الأمن السيبراني وأظهر “ذكاءً خاماً (raw IQ) يتجاوز النتائج الظاهرة”، وهو أمر مثير للاهتمام تحديداً لأنه يعتمد على تقييم خاص وليس معياراً قياسياً علنياً. هذا يشكّل إشارة إلى أن نتائج لوحة الصدارة العلنية ونتائج التقييم الخاص قد تتباعد.

جاء انتقاد مماثل من قطاع الأمن والتقييم أيضاً. أشارت إحدى الوسائل الإعلامية إلى أن حالة Kimi K3 تكشف حدود لوحات صدارة المعايير القياسية للذكاء الاصطناعي. تدفع نتائج لوحة الصدارة بسهولة نحو تحسين موجّه لمجموعة اختبار محددة، وإذا اختلطت توزيعات مشابهة للمعايير القياسية في بيانات التدريب، فقد تتضخّم النتيجة عن قدرة النموذج الحقيقية على التعميم. أشار المطوّر Simon Willison إلى أن اختبار النموذج بمهام غير معيارية، مثل “ارسم بجعة”، بدلاً من المعايير القياسية الشائعة، لا يزال نهجاً صالحاً، وهي نقطة تعيد التأكيد على قيمة التقييم المحجوز (held-out) في وضع تسهل فيه ملوثة المعايير القياسية العلنية.

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

ما الذي يحتاج المشغّلون للتحقق منه

لذلك، يجب أن يأتي قرار الاعتماد ليس من لوحة الصدارة، بل من تقييم محجوز (held-out) في أيدينا نحن. من الناحية العملية، نوصي بالتسلسل التالي.

أولاً، إعداد مجموعة تقييم خاصة تتكون من مهام فعلية من مجالنا الخاص. يجب أن تُستخرج من بيانات العملاء التي على الأرجح لم تُعرض أثناء التدريب، ويجب أن نمتلك نحن الإجابات الصحيحة ومعايير التصحيح. المعايير القياسية العلنية ليست سوى سقف مرجعي.

ثانياً، تشغيل النماذج المرشّحة جنباً إلى جنب على نفس الأداة التشغيلية (harness). ما لم تُوحَّد الشروط مثل التلقينات (prompts) والأدوات وميزانية الرموز ودرجة الحرارة (temperature)، لا يمكننا معرفة ما إذا كان الفرق في النتيجة يعود إلى فرق في قدرة النموذج أو فرق في الإعداد. الفخ الذي أشارت إليه BankInfoSecurity في لوحات الصدارة ينبع في النهاية من عدم تطابق الشروط.

ثالثاً، النظر إلى الاتساق عبر الجلسات الطويلة بدلاً من الدقة في محاولة واحدة. حقيقة أن K3 كان قوياً في SWE Marathon تلميح مفيد، لكن ما إذا كان ذلك يستمر في مهمة من 20 خطوة في سير عملنا الخاص يجب التحقق منه بشكل منفصل.

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

دلالات التطبيق على منتجات ThakiCloud

يمسّ هذا النقاش مباشرة كلا منتجَي ThakiCloud.

أولاً، من منظور ai-platform. تقديم (serving) أوزان MXFP4 بحجم 1.4 تيرابايت داخلياً (on-premises) يعني أن ذاكرة GPU والترابط البيني (interconnect) واستراتيجية تفريغ الخبراء يجب أن تُصمَّم معاً. توفر منصة ai-platform من ThakiCloud الأساس لوضع مثل هذه النماذج المفتوحة الضخمة في بيئات العملاء من خلال جدولة GPU المعتمدة على K8s و Kueue، وتقديم من عائلة vLLM، وعزل متعدد المستأجرين (multi-tenant). بالنسبة للعملاء الذين لا يكون فيهم استخدام واجهات برمجة تطبيقات خارجية خياراً أصلاً، سواء بسبب متطلبات جهاز الاستخبارات الوطني أو سيادة البيانات، فإن خيار تشغيل نموذج مفتوح بـ 2.8 تريليون معامل على بنيتهم التحتية الخاصة يحمل قيمة كبيرة في حد ذاته. مع ذلك، وكما شُدّد عليه أعلاه، يجب أن يُحدَّد النموذج المراد تقديمه من خلال تقييم مجال العميل، لا من خلال لوحة الصدارة.

بعد ذلك، من منظور Paxis. Paxis هو مستوى تحكم Agent-Native Cloud الذي يعمل فوق ai-platform، ويتعامل مع Skills و Tools و Policies و Audit Logs كموارد من الدرجة الأولى. موضوع هذا المقال، وهو التحقق من اعتماد النموذج، هو بالضبط المشكلة التي تستهدفها بوابات سياسات Paxis وسجلات التدقيق فيه. عندما يُفرض عبر السياسات، قبل ربط نموذج جديد بسير عمل وكيل، اجتيازُه للتقييم المحجوز، ويُترك سجل تدقيق يوضح أي نموذج اتخذ أي قرار في التشغيل الفعلي، يمكن كبح الدافع نحو “الثقة به لأن النتيجة عالية” على مستوى النظام. نقل مشكلة الثقة بالمعايير القياسية من الانضباط البشري إلى بوابة المنصة، هذه هي القيمة التي يوفرها Paxis بالضبط.

القيود والحجج المضادة

هذا المقال لا يهدف إلى التقليل من شأن K3. حقيقة ظهور نموذج مفتوح الأوزان بفئة 3 تريليون معامل، وبلوغه القمة في عدة مقاييس قدرة، هي في حد ذاتها تقدم كبير. لا يزال الشك في الإفراط في التكيّف قرينة، وقد يتبدد إلى حد كبير بمجرد إصدار الأوزان الكاملة في 27 يوليو وتراكم تقييمات إعادة الإنتاج المستقلة.

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

المصادر

• Moonshot AI Releases Kimi K3: A 2.8 Trillion Parameter Open MoE Model With Kimi Delta Attention and 1M Context - MarkTechPost
• Kimi K3 Model Overview: 2.8T Parameters, MXFP4 Quantization - Hugging Face
• China’s 2.8-trillion-parameter Kimi K3 - Tom’s Hardware
• Kimi K3 Highlights Limits of AI Benchmark Leaderboards - BankInfoSecurity
• Kimi K3, and what we can still learn from the pelican benchmark - Simon Willison
• Guillermo Rauch on internal evals (X)

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

ماذا أُعلن عن Qwen3.8

لنبدأ بالحقائق المؤكدة. أعلن فريق Qwen التابع لعلي بابا في 19 يوليو 2026 عن Qwen3.8 مع الإفصاح عن سياسة الإصدار كأوزان مفتوحة. الرقم الرئيسي هو 2.4 تريليون معلمة، وقُدّم النموذج كنموذج متعدد الوسائط. هذا هو الجزء الذي صرّحت به الجهة المعلنة صراحة.

كما تأكد مسار الوصول إلى النموذج. أصبح Qwen3.8-Max-Preview متاحا بالفعل للاختبار عبر Token Plan التابع لعلي بابا، وكذلك عبر Qoder وQoderWork. بعبارة أخرى، ما يمكن تجربته الآن فعليا هو النسخة التجريبية (Preview)، وهي خدمة مستضافة على منصة علي بابا نفسها. وذكرت الشركة أن النسخة الكاملة من Qwen3.8 ستُطرح لاحقا كأوزان مفتوحة، لكنها لم تلتزم بتاريخ محدد.

يجب هنا التمييز بوضوح بين أمرين. أولا، ما هو متاح للاستخدام الآن هو “نسخة تجريبية” وليس “أوزانا مفتوحة”. ثانيا، عبارة “الإصدار قريبا” لا تحمل أي جدول زمني فعلي. وعندما يختلط هذان الأمران ببعضهما، يسهل الوقوع في وهم امتلاك نموذج لا يمكن تنزيله بعد.

إلى أي مدى يمكن الوثوق بادعاءات الأداء

الجزء الذي يستوجب أقصى درجات الحذر هو الأداء. ادّعت علي بابا أن Qwen3.8 يضاهي النماذج الرائدة المتقدمة، وأنه يأتي في المرتبة التالية مباشرة بعد Fable 5 من Anthropic. وعلى منصة X، ذهبت بعض التفاعلات إلى أبعد من ذلك، مدّعية أنه “يتفوق على GPT-5.6”. غير أن هذه الادعاءات لا تستند إلى أي معايير قياسية منشورة حتى الآن، إذ لم تُرفق أي نتائج تقييم قياسية مع الإعلان. لذلك، يجب قراءة جميع العبارات المتعلقة بالأداء على أنها ادعاءات [تقديري] من الجهة المعلنة والمجتمع، لا أكثر.

كما يوجد الكثير من الغموض على المستوى البنيوي. لم تفصح علي بابا عن عدد المعلمات النشطة (active parameters) ولا عن تكوين مزيج الخبراء (Mixture-of-Experts). وهذا إغفال مهم من الناحية العملية. فرقم 2.4 تريليون يمثل الحجم الإجمالي فقط، ولا يخبرنا بحجم الحساب الفعلي الذي يعمل مع كل رمز (token). وبالمقارنة مع Kimi K3 الذي صدر قبل أيام قليلة وأوضح صراحة أنه يُفعّل 16 خبيرا فقط من أصل 896 خبيرا من إجمالي 2.8 تريليون معلمة، يظل رقم 2.4 تريليون الخاص بـQwen3.8 أقرب إلى رقم إعلاني رئيسي لا يمكن من خلاله تقدير تكلفة الاستضافة بعد.

وفيما يلي ملخص لذلك:

لماذا تظهر النماذج المفتوحة الضخمة تباعا الآن

هذا الإعلان ليس حدثا منعزلا، بل مشهد ضمن تيار أوسع. وصفت إحدى وسائل الإعلام Qwen3.8 بأنه محاولة من علي بابا للحاق بـKimi K3، وهذا الإطار يلخص الوضع جيدا. ففي غضون أيام قليلة، ظهرت نماذج مفتوحة (أو على وشك أن تصبح مفتوحة) ضخمة جدا بحجمي 2.8 تريليون و2.4 تريليون معلمة تباعا، وبات ميزان القوى يتحول نحو أن تصبح القدرات على مستوى الطليعة (frontier) غير حكر على واجهات برمجة التطبيقات المغلقة.

flowchart TB
    A[سباق النماذج الطليعية الضخمة مفتوحة الأوزان<br/>يوليو 2026] --> B[Kimi K3<br/>2.8 تريليون - إصدار فعلي - معايير منشورة]
    A --> C[Qwen3.8<br/>2.4 تريليون - إعلان مبدئي - نسخة تجريبية فقط]
    B --> D[الأوزان قابلة للتنزيل<br/>متوقع 27 يوليو]
    C --> E[الأوزان غير معلنة<br/>الموعد غير محدد]
    D --> F[إمكانية دراسة الاستضافة الداخلية]
    E -.التحقق معلق.-> F
    F --> G[الذكاء الاصطناعي السيادي - إعادة حساب البناء مقابل الشراء]

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

وجهة نظر ThakiCloud: ماذا يعني استضافة نموذج بحجم 2.4 تريليون معلمة داخليا

لنفترض جدلا أن Qwen3.8 صدر فعلا كأوزان مفتوحة كما أُعلن. عندئذ تصبح مهمة استضافة نموذج متعدد الوسائط بحجم 2.4 تريليون معلمة في بيئة داخلية لدى العميل أمرا واقعا. وفي هذه الحالة، لا تكمن العقبة في مدى ذكاء النموذج، بل في ذاكرة وحدات معالجة الرسومات (GPU)، والربط البيني (interconnect)، واستراتيجيات نقل الخبراء (expert offloading) والتكميم (quantization). ونظرا لعدم الإفصاح حتى الآن عن عدد المعلمات النشطة وتكوين MoE، لا يمكننا حساب هذه التكلفة بدقة، ولذلك فإننا لا نحدد خارطة طريق للاستضافة بناء على الإعلان وحده.

توفر منصة ai-platform التابعة لـThakiCloud الأساس اللازم لنقل مثل هذه النماذج المفتوحة الضخمة إلى بيئات العملاء. فجدولة وحدات معالجة الرسومات القائمة على K8s وKueue، والاستضافة المعتمدة على عائلة vLLM، والعزل متعدد المستأجرين (multi-tenant)، كلها عناصر تتيح لنا الشروع سريعا في التحقق فور صدور النموذج فعليا. والقدرة الأساسية هنا هي تحويل “الإعلان” إلى “تحقق” بسرعة فوق خط أنابيب جاهز، لا الانجراف في الحماس المبكر عند مرحلة الإعلان. فميزتا انخفاض تكلفة الاستضافة والسيادة الداخلية لا تؤتيان ثمارهما إلا عندما يصبح النموذج المفتوح في متناول اليد فعليا.

القيود والحجج المضادة

لا يهدف هذا المقال إلى التقليل من شأن Qwen3.8. فسياسة إصدار نموذج متعدد الوسائط بحجم 2.4 تريليون معلمة كأوزان مفتوحة في حد ذاتها إشارة إيجابية للنظام البيئي، ولو تحققت فعليا لكانت حدثا كبيرا. كما أن إمكانية اختبار النسخة التجريبية بالفعل ليست أمرا بلا قيمة.

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

المصادر

• Alibaba Launches Qwen 3.8 With 2.4 Trillion Parameters, Claims Near-Frontier Performance - MLQ News
• Alibaba Announces 2.4 Trillion-Parameter Open-Weight Qwen 3.8 - OfficeChai
• Qwen3.8 Preview: 2.4T Params, Open Weights, Release - BuildFastWithAI
• Qwen3.8 Teases a 2.4 Trillion Parameter Open Model as Alibaba Chases Kimi K3 - Startup Fortune
• Qwen on X (announcement)

نظرة عامة: لماذا الـ harness الآن

في الأشهر الأخيرة، بات يتكرر الطرح القائل إن “الكود المحيط بالنموذج أهم من النموذج نفسه”. فبالنسبة للوكلاء الذين يستخدمون الأدوات، لا يقل أسلوب عرض الأدوات ووصفها، وما يُعاد كمشاهدة (observation) في كل خطوة، أهمية عن أوزان النموذج ذاتها في تحديد الأداء النهائي. وتتناول ورقة استقصائية أخرى تعالج الموضوع نفسه، From Question Answering to Task Completion، تصميم الـ harness باعتباره محوراً بحثياً مستقلاً في أنظمة الوكلاء.

تكمن المشكلة في أن هذين الجانبين - تصميم الـ harness والـ post-training - كانا يُعاملان حتى الآن وكأنهما عمل فريقين مختلفين. فريق البحث يصقل السياسة (policy) عبر التعلم المعزّز، بينما يتولى فريق المنصة ضبط الأدوات والمحفزات (prompts). وتكمن مساهمة هذه الورقة في إثبات خطأ هذا التقسيم؛ فمقدار المعلومات في الـ harness والـ post-training متشابكان بعلاقة ضربية، بحيث يؤدي تحسين أحدهما فقط إلى تبديد معظم مكاسب الآخر. وبالنسبة لمنصة مثل ThakiCloud التي تتعامل مع الـ harness كمورد من الدرجة الأولى، تُترجَم هذه النتيجة مباشرة إلى مبدأ تشغيلي.

ما هو الـ harness وأين يتحدد الأداء

تُعرّف الورقة الـ harness بأنه “السقالة التي تحيط بالنموذج”. وبتحديد أدق، هو الطبقة التي تقرر أي الأدوات تُعرض، وكيف تُوصف هذه الأدوات، وما المعلومات المساعدة التي تُرفق بمشاهدة كل خطوة. ويمكن تمثيل دورة واحدة لوكيل يستدعي الأدوات كما يلي:

flowchart TB
    U[مهمة المستخدم] --> H
    subgraph H[harness: السقالة المحيطة بالنموذج]
      T[اختيار مجموعة الأدوات المعروضة]
      D[وصف الأدوات وتوقيعاتها]
      O[معلومات مساعدة وتلميحات<br/>تُرفق بمشاهدة كل خطوة]
    end
    H --> M[نموذج سياسة LLM]
    M --> A[استدعاء الأدوات والإجراءات]
    A --> E[إرجاع مشاهدة البيئة]
    E --> M
    M --> R[إتمام المهمة]
    H -. post-training واعٍ بالـ harness .-> PT[مرحلة post-training للسياسة]
    PT -. سياسة مدرَّبة مع الـ harness .-> M

المتغير الجوهري هنا هو مقدار المعلومات (informativeness) في الـ harness. فالـ harness ذو المعلومات الغنية يصف الأدوات بتفصيل ويرفق بالمشاهدات تلميحات مفيدة، ما يساعد النموذج على اختيار الأداة الصحيحة دون الاعتماد الكامل على معرفته المسبقة. أما الـ harness منخفض المعلومات فيكتفي بتوقيعات (signatures) دنيا ويترك الباقي لاستدلال النموذج. وهذا الفارق هو ما يحدد النتيجة عند التقائه بالتدريب.

الافتراض الذي يقلبه هذا البحث

لدى من تعامل مع الوكلاء افتراض ضمني شائع: يكفي إضافة harness جيد قبيل النشر مباشرة. النموذج يُدرَّب جيداً بمعزل عن ذلك، ثم يُضبط الـ harness لاحقاً بتنقيح وصف الأدوات، ويُتوقّع أن يرتفع الأداء تبعاً لذلك. وتدحض الورقة هذا الافتراض بشكل مباشر.

أولاً، حتى في وضع zero-shot (بالاعتماد على المحفزات فقط دون تدريب إضافي)، يتحسّن الأداء بشكل مطّرد كلما زاد مقدار المعلومات في الـ harness، ويكون هذا الأثر أوضح في النماذج ذات القدرة الأعلى. وهذا يعني أن المعرفة المسبقة المضمّنة في harness غني بالمعلومات تُترجم مباشرة إلى أداء.

ثانياً، وهذا الاكتشاف الأهم، يكمن في التفاعل مع الـ post-training. فعند مقارنة نموذج دُرِّب مع الـ harness مدمجاً منذ مرحلة التدريب، بنموذج أُضيف إليه الـ harness نفسه بعد انتهاء التدريب، يستعيد النموذج الثاني جزءاً ضئيلاً فقط من المكاسب التي حظي بها الأول. بعبارة أخرى، الـ post-training الواعي بالـ harness (harness-aware post-training) ليس إضافة تُحسّن الأداء، بل شرط أساسي لتحقيق أداء متين. أما نهج استبدال الـ harness بعد التدريب فهو مقاربة ناقصة.

يظهر الفرق الحقيقي عند تغيّر بيئة الأدوات

تأتي النتيجة الأكثر عملية من تجارب خارج التوزيع (OOD). ويُقصد بـ OOD هنا بيئة أدوات لم يرها النموذج أثناء التدريب - كأن تُضاف أدوات جديدة أو تُستبدل، أو تتغيّر توقيعات واجهات API. وفي التشغيل الفعلي، هذا النوع من التغيّر ثابت لا يتوقف؛ فالأدوات تتزايد باستمرار، والإصدارات تتحدّث، ومجموعة الأدوات المعروضة تختلف من مستأجر (tenant) إلى آخر.

تقارن الورقة بين مسارين. فالوكيل الذي خضع لـ post-training واعٍ بـ harness غني بالمعلومات يصمد بمتانة حتى عند تغيّر بيئة الأدوات بشكل كبير، ويُعمِّم عبر مجموعات المهام المختلفة. في المقابل، الوكيل الذي دُرِّب مع harness بُذل في تصميمه جهد محدود ينهار أداؤه سريعاً كلما اشتد تغيّر بيئة الأدوات، ويعجز عن الانتقال إلى بيئات جديدة. بعبارة أخرى، تلعب المعرفة المسبقة المضمّنة في الـ harness دور المرساة (anchor) للتعميم. فالسياسة المدرَّبة مع harness مصمَّم جيداً تحتفظ بحسّها حول ماذا وكيف تستدعي حتى أمام أدوات غير مألوفة، بينما تفقد السياسة المدرَّبة مع harness هزيل ذلك الحسّ بالكامل.

هذه النقطة مؤلمة بشكل خاص لمشغّلي السحابة. فالسبب النمطي وراء انهيار وكيل حقق نتائج جيدة في المعايير القياسية (benchmarks) عند وصوله إلى بيئة الإنتاج هو تحديداً تحوّل بيئة الأدوات. وتقول هذه الورقة إن جزءاً كبيراً من هذا الضعف يتحدد أصلاً في مرحلة تصميم الـ harness.

دلالات التطبيق على منتجات ThakiCloud

يتقاطع هذا الاكتشاف مع محوري منتجات ThakiCloud كليهما، بحيث تفوّت النظرة من زاوية واحدة نصف الصورة.

الزاوية الأولى هي زاوية Paxis. فـ Paxis هي لوحة تحكم Agent-Native Cloud تعمل فوق ai-platform، وتتعامل مع الـ Skills والـ Tools والـ Policies وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. وبلغة هذه الورقة، فإن Skill Harness الخاص بـ Paxis هو تحديداً الـ harness المقصود هنا. فاختيار مجموعة الأدوات المعروضة من بين نحو 960 مهارة (skill) عبر BM25، وتنسيق وصف كل مهارة وتوقيعها، وإعادة نتائج التنفيذ في sandbox معزول كمشاهدة - كل هذه العمليات مجتمعة هي ما يحدد مقدار المعلومات في الـ harness. وتدعم استنتاجات الورقة مبادئ تصميم Paxis: فبناء harness غني بالمعلومات عبر اختيار المهارات بما يناسب المهمة، بدلاً من عرضها جميعاً دون تمييز، ثم تطوير ذلك الـ harness مع حلقة التدريب والتقييم، هو ما يقود إلى المتانة أمام بيئات أدوات غير مألوفة. كما أن البنية التي تُمرِّر كل إجراء عبر بوابات السياسات (policy gates) وسجلات التدقيق تندرج ضمن الهمّ نفسه: إبقاء الـ harness موضوعاً للتجريب وخاضعاً لإدارة الإصدارات.

الزاوية الثانية هي زاوية ai-platform. فاستنتاج أن الـ post-training الواعي بالـ harness شرط أساسي يرفع قيمة إبقاء التدريب والتقديم (serving) داخل بنية تحتية واحدة. وتُشغِّل ai-platform أعباء الـ post-training مثل الـ fine-tuning والـ RLVR جنباً إلى جنب مع تقديم الاستدلال عبر vLLM، فوق جدولة GPU قائمة على K8s وKueue. ولكي يُدمَج الـ harness عند لحظة التدريب، يجب أن يكون بإمكان خط أنابيب التدريب الرجوع مباشرة إلى مخطط الأدوات (tool schema) وصيغة المشاهدات المستخدَمة في التقديم. فإذا انفصل التدريب عن التقديم في منظمتين أو مكدّسين تقنيين مختلفين، ينحرف الـ harness عن مساره، ويقع المرء في فخ المكسب الناقص الذي حذّرت منه الورقة، أي “استبدال الـ harness بعد التدريب”. أما التصميم الذي يعرض مجموعات أدوات مختلفة لكل مستأجر في بيئة متعددة المستأجرين، مع الحفاظ في الوقت ذاته على متطلبات on-premise والسيادة عبر self-hosting يجمع التدريب والتقديم داخل سياج واحد، فهو موقع مؤاتٍ للحفاظ على هذا التوافق بين الـ harness والتدريب.

وتتكامل الزاويتان: تدير Paxis الـ harness كمورد من الدرجة الأولى فتضبط مقدار معلوماته وإصداراته، بينما تُدخِل ai-platform ذلك الـ harness في حلقة التدريب فتُحوّل الـ post-training الواعي بالـ harness إلى واقع ملموس.

القيود والاعتراضات المحتملة

لتجنّب المبالغة في تفسير نتائج هذه الورقة، ينبغي مراعاة عدة نقاط.

أولاً، تحمل فرضية “كلما زاد مقدار المعلومات في الـ harness كان أفضل” تكلفة مصاحبة. فكلما زادت التلميحات المرفقة بالمشاهدات طال السياق (context)، وكلما ازداد ثراء وصف الأدوات ارتفع عدد رموز المحفز (prompt tokens) والتأخير (latency). ومن منظور التقديم (serving)، مقدار المعلومات ليس مجانياً، ويجب موازنته دائماً مع الإنتاجية (throughput). ولذلك يُستحسَن قراءة مفهوم “مقدار المعلومات” في الورقة لا على أنه “المزيد دائماً أفضل”، بل بمعنى أقرب إلى “هل يحمل معرفة مسبقة مفيدة للمهمة”.

كذلك، يتطلب الـ post-training الواعي بالـ harness تكلفة دخول تتمثل في إعادة ضبط خط أنابيب التدريب. وفي كثير من الممارسات العملية التي تستخدم نماذج open-weight جاهزة كما هي، يظل تحسين الـ harness وحده في وضع zero-shot خطوة أولى واقعية. وبما أن الورقة نفسها تؤكد أن مقدار المعلومات يرفع الأداء في وضع zero-shot أيضاً، فهذا يبقى نقطة انطلاق معقولة للفرق التي لا تملك موارد كافية للتدريب.

وأخيراً، من الصعب الجزم بأن تحوّلات بيئة الأدوات التي تتناولها تجارب OOD في الورقة تُمثِّل كامل نطاق التغيّر في بيئة الإنتاج الفعلية. فثمة فجوة بين استبدال الأدوات في المعايير القياسية وبين بيئة تشغيل يحدّث فيها عشرات المستأجرين واجهات API الخاصة بهم كلٌّ على حدة. ومع ذلك، فإن الاتجاه العام - أي أن “الوكيل المصمَّم مع الـ harness منذ التدريب أكثر متانة أمام التغيّر” - يُرجَّح أن يعمل بقوة أكبر كلما كانت السحابة الفعلية أكثر تغيّراً مستمراً في أدواتها.

وخلاصة القول، تدعو هذه الورقة إلى معاملة الـ harness لا كلمسة تشطيب تُضاف قبيل النشر، بل كبنية تُصمَّم مع مرحلة التدريب منذ خطوتها الأولى. والاتجاه القائم على إدارة الـ harness كمورد من الدرجة الأولى، وإبقاء التدريب والتقديم داخل بنية تحتية واحدة، يشير بالضبط إلى الوجهة نفسها التي توصي بها هذه التوصية.

المصادر

• The Interplay of Harness Design and Post-Training in LLM Agents, arXiv:2606.25447: https://arxiv.org/abs/2606.25447
• From Question Answering to Task Completion: A Survey on Agent System and Harness Design, arXiv:2606.20683: https://arxiv.org/abs/2606.20683

A short piece of news has been getting quoted a lot lately in developer circles: Anthropic apparently cut Claude Code’s system prompt by roughly 80 percent. What made it interesting wasn’t the size of the cut so much as the reasoning behind it. Anthropic’s Tariq Shihipar (@trq212) said the new Fable 5 family of models “wants a smaller system prompt,” and that loading it up with instructions and examples can actually work against the model. His explanation: the model is often more imaginative than the rules we write for it.

That single line isn’t just a product optimization note. Prompt engineering has spent the last few years drifting toward “write down everything, don’t leave anything out.” Packing the system prompt tight with what not to do, which formats to follow, and every edge case to watch for was treated as the mark of a good harness. Now there’s a signal that once a model gets strong enough, all that density stops being an asset and starts being a liability.

ThakiCloud runs a Kubernetes-based AI/ML SaaS platform, and on top of it we operate Paxis, our agentic control plane, which manages over 960 skills and dozens of always-on rules as a harness. So “how much goes in the system prompt” isn’t a trend headline for us, it’s a design decision we make daily. This post covers what the cut actually signals, why stronger models want a thinner harness, and how we’ve translated that principle into our own operations.

What Changed

The reported story comes down to two points. First, the sheer length of Claude Code’s system prompt dropped substantially. Second, the reasoning behind it runs in the opposite direction from what you’d expect: not “the model is weaker, so we add more,” but “the model is stronger, so we add less.”

According to Anthropic’s own account, newer models internalize behavioral norms during training to a much greater degree than before. Things that previously had to be spelled out line by line in the deployment-time system prompt are now, to some extent, already baked into the model’s weights. The natural reading is that the system prompt’s role is shifting, from “a rulebook that contains everything” to “a light context setter.” There was also mention of steering the model through context rather than rigid prohibitions, such as “don’t do this.”

The diagram below sketches out the structure of this shift. The thick rulebook approach on the left and the thin context-setting approach on the right build capability in different places.

flowchart TB
    subgraph OLD["Before: Thick System Prompt"]
        A1["Every rule, exception, and format<br/>spelled out in the system prompt"] --> A2["Model expected to<br/>follow instructions literally"]
        A2 --> A3["Instructions can<br/>constrain capability"]
    end
    subgraph NEW["Now: Thin Harness + Context"]
        B1["System prompt sets<br/>only light context"] --> B2["Model draws on<br/>internalized judgment"]
        B2 --> B3["Rules injected as context<br/>only when needed"]
    end
    OLD -.Shift as models get stronger.-> NEW

There’s a catch worth flagging here. “Shrink the system prompt” doesn’t mean “get rid of the instructions.” What shrank is the standing harness that’s always loaded at deployment time. The domain knowledge and reasoning behind those instructions still have to live somewhere. What changed is where that knowledge sits.

Why Smarter Models Want Thinner Prompts

This isn’t a hunch floating around without evidence behind it. There’s a growing body of research showing that adding more agent scaffolding (harness) doesn’t necessarily improve performance, and can instead create interference between components. “More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding” (arXiv 2605.05716), for instance, examines the point at which adding more harness components starts causing them to interfere with each other and drag overall performance down. Piling on more instructions isn’t a monotonically increasing benefit.

The intuition works like this: every rule you add to a system prompt becomes something the model has to treat as a constraint it must satisfy at every single moment. When there are only a few rules, this constraint acts as a useful guardrail. Once there are dozens of them, they start conflicting with each other, or instructions unrelated to the current task muddy the model’s judgment. A weaker model wanders without explicit instructions, so paying that cost used to be worth it. A stronger model, though, has gotten much better at reading the situation on its own, so at some point the interference cost of unnecessary instructions starts to outweigh the benefit those instructions provide.

This is exactly where the line “the model is more imaginative than the instructions we give it” starts to make sense. A dense set of rules sets a floor that keeps the worst outputs from happening, but it also becomes a ceiling that suppresses the best possible output at the same time. Once the model is capable of climbing higher than that ceiling, stripping the rules away is what opens up the performance headroom.

That logic isn’t unconditional, though. Remove the floor and the average can go up, but the variance goes up with it. The guardrail that used to catch the occasional bad output disappears too. In practice, this means what you strip out matters more than how much you strip out.

From Rules to Context

The most practically useful part of this story is the shift from “rigid prohibitions” to “steering through context.” There are two ways to express the same intent.

The first is a hard rule: something like “don’t use jargon” or “you must follow this exact format,” phrased as a prohibition or a mandate. It’s clear, but stacked up as a standing harness it produces exactly the interference described above. The second is context setting: describing the state you want the output to be in, something like “write this so a sixteen year old can follow it easily.” For a strong model, the second approach tends to be more stable in practice. Not because the model can’t parse negative instructions, but because a positively framed goal gives the model room to fill in the details itself.

There’s an important distinction here. This isn’t about pulling all knowledge out of the system prompt, it’s about separating the standing harness from on-demand knowledge. Keep only what’s needed at every single moment as the standing baseline, and pull in knowledge that’s only relevant to a specific task as context when that task actually starts. That way the standing harness stays thin, and domain knowledge gets supplied thickly at the moment it’s actually needed.

That said, anything where consistency of format can’t be allowed to waver should still be owned by deterministic code. Instead of asking the model to “always answer in this exact JSON format,” it’s safer to let code enforce output structure and aggregation while the model only generates content. Making prompts thinner and fixing format through code aren’t in tension. If anything, they reinforce each other. What can’t wobble gets pushed down into code, what requires judgment gets handed to the model, and the standing harness sheds weight on both fronts.

Implications for ThakiCloud’s Product

This trend lines up directly with the design philosophy behind Paxis, ThakiCloud’s agentic platform. Paxis is the agent-native cloud control plane that runs on top of ai-platform, treating skills, tools, policies, and audit logs as first-class resources. One of its core design principles is exactly this: thin harness, fat skills. Keep the model loop, permissions, and security minimal as the harness, and stack domain knowledge, judgment, and lessons from failure thickly into the skills.

Paxis’s skill harness doesn’t load all 960-plus skills into the standing system prompt. Instead, when a request comes in, BM25 search pulls in only the relevant skills as context at that moment. That’s essentially an implementation of what this news calls “a light context setter.” The standing harness cost stays thin, while thick domain knowledge gets supplied only for the specific task that needs it. Once a skill gets indexed, its name and description cost tokens on every single session, so we judge whether each sentence earns a permanent seat by asking: would the agent get this wrong without it.

The context-steering principle connects to our operations too. Paxis’s policy gates and audit logs enforce anything that can’t be allowed to waver through deterministic code. Areas that involve content quality or judgment, on the other hand, get handed to the model, guided only by a thin rule that sets direction. Since standing rules cost tokens on every single turn, we keep only what’s always needed as standing rules and push what’s occasionally needed down into skills that load on demand. What Anthropic learned from its system prompt, we apply daily in how we draw the boundary between skills and rules.

There’s an infrastructure angle too. A thinner system prompt means fewer input tokens, which has a direct effect on serving cost and latency. In an environment where ai-platform serves models through vLLM in a multi-tenant setup, trimming the standing harness isn’t just a quality question, it’s an economics question. Lower serving cost creates room to run agents more often and at greater scale, and that room in turn is what makes agent economics work.

Limits and Counterarguments

Generalizing this trend without qualification would be a mistake. A few honest counterpoints are worth stating.

First, “thinner is always better” is a dangerous conclusion to draw. Trimming a prompt only opens up performance when the model is strong enough, and that threshold varies by model and by task. Strip the harness away too aggressively on a weaker model, or in a high-stakes task, and the floor disappears with it, letting more bad outputs through. In our own operations, when a lower-cost model wobbles on content quality, we respond by locking format down harder through code, not by cutting the harness further.

Second, the specific figures in this story are based on public statements from an Anthropic representative and the media coverage that summarized them, not on published before-and-after prompt lengths or benchmark numbers. The “80 percent” figure is the number that was reported, but we want to be clear that we haven’t independently reproduced or measured its performance effect.

Third, what fills the space left behind matters. Pulling instructions out of the system prompt doesn’t make the knowledge disappear. That knowledge has to move somewhere: into the model’s weights, into a skill loaded on demand, or into a deterministic code gate. Delete without arranging a place for it to land, and the thinner harness just turns into uncontrolled output. In the end, this isn’t a competition to write less, it’s a design question of what goes where.

To sum up, this cut is one data point showing that the center of gravity in prompt engineering is shifting. As models get stronger, the standing harness gets thinner, and rules get split and redistributed between context and code. ThakiCloud has already been running on this principle through Paxis’s thin harness and fat skills, and this news confirms that the direction isn’t just our own preference, it’s where the industry is heading together.

Sources

• Anthropic, summarized public remarks from Tariq Shihipar (@trq212), reported by the-decoder.com
• “Anthropic Slashes Claude Code System Prompt by 80%”, ClaudeAINews
• “More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding”, arXiv 2605.05716