تجسيد تجريدي لفكرة نموذج صُمم من الأساس للبرمجة ومهام الوكلاء.

نظرة عامة

Grok 4.5 هو نموذج أعلنت SpaceXAI أنها دربته من الصفر للبرمجة والوكلاء المستقلين. لم يُموضَع كروبوت محادثة استهلاكي، بل كأداة للتطوير والعمل المعرفي، ويستهدف قواعد الأكواد الكبيرة واستخدام الأدوات والمهام طويلة الأمد. وصفه Elon Musk بأنه نموذج “بمستوى Opus لكنه أسرع وأكثر كفاءة من حيث الرموز وأقل تكلفة”. وOpus المشار إليه هنا كان حتى وقت قريب فئة النماذج الأعلى لدى Anthropic.

سبب تجاوز هذا الإعلان مجرد إطلاق نموذج جديد يكمن في السعر وطريقة التدريب. سُعّر Grok 4.5 بـ2 دولار لكل مليون رمز إدخال، و6 دولارات لكل مليون رمز إخراج. طرح أداء بمستوى الطليعة (frontier) بهذا السعر يهز الافتراض السائد بأن “النماذج الذكية باهظة الثمن بحيث يصعب تشغيلها كوكلاء لفترات طويلة”. من منظور Thaki Cloud، هذا التحول ليس شأناً بعيداً عنا. فالذكاء الوكيلي الرخيص يغيّر مباشرة اقتصاديات المنصات التي تشغّل الوكلاء بشكل دائم.

ماذا أُعلن

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

كُشف أيضاً عن البنية التحتية للتدريب. أوضحت الشركة أنها دربت هذا النموذج على عشرات الآلاف من وحدات معالجة الرسوميات NVIDIA GB300، واستثمرت بشكل كبير في التعلم المعزز (RL) لرفع الذكاء لكل رمز (per-token intelligence). وتشرح SpaceXAI أن هذا الاستثمار بالتحديد هو ما خلق فجوة الكفاءة في الرموز مقارنةً بـOpus 4.8. بمعنى آخر، دُرِّب النموذج على إنجاز المهمة ذاتها بعدد أقل من الرموز، وهو ما يترجم مباشرة إلى خفض تكلفة الاستخدام الفعلي.

ماذا يعني “التدريب المخصص للبرمجة والوكلاء”

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

flowchart TB
    A["تعليمات المهمة من المطوّر"] --> B["الوكيل: استكشاف قاعدة الأكواد"]
    B --> C["استدعاء الأدوات: تعديل الملفات واختبارها"]
    C --> D["مراقبة النتائج الوسيطة"]
    D --> E{"هل اكتملت المهمة؟"}
    E -->|"لا"| B
    E -->|"نعم"| F["الناتج النهائي"]
    G["تدريب RL على الذكاء لكل رمز"] -.تأثير.-> C
    G -.تأثير.-> D

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

التحول الذي يصنعه السعر

تقديم أداء بمستوى الطليعة مقابل 2 دولار لكل مليون رمز إدخال و6 دولارات لكل مليون رمز إخراج يغيّر حسابات الربح والخسارة في تشغيل الوكلاء. في مسارات العمل التي يستهلك فيها الوكيل ملايين الرموز وهو يتنقل طوال اليوم عبر قاعدة الأكواد، يحدد سعر الرمز مباشرة هامش ربح الخدمة. وإذا تقارب الأداء، يفوز النموذج الأرخص. وبالفعل تشير عدة تحليلات إلى أن Grok 4.5 أرخص بكثير من Fable 5 وGPT 5.5، بحيث قد يُختار على أساس السعر وحده إذا لم تكن فجوة النتائج القياسية (benchmark) كبيرة.

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

من منظور Thaki Cloud

ظهور نماذج الوكلاء الرخيصة يمسّ منتجَي Thaki Cloud كليهما.

من منظور Paxis، تعزز نماذج الوكلاء منخفضة التكلفة وعالية الأداء مثل Grok 4.5 فرضية Agent-Native Cloud. Paxis هي طبقة تحكم للوكلاء تعمل فوق ai-platform، وتتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. في بنية ينفّذ فيها الوكيل مهمة طويلة عبر عشرات الخطوات، تحتاج - أياً كان النموذج المستخدم - إلى طبقة تُمرِّر سلوكه عبر بوابات السياسات وتُسجّله في سجلات التدقيق. فكلما رخُص النموذج، زاد تشغيل الوكلاء أكثر ولفترات أطول، وكلما زادت قيمة التنسيق (orchestration) والحوكمة. الذكاء الرخيص لا يقلل من الحاجة إلى منصة الوكلاء، بل يزيدها.

من منظور ai-platform، تتضح المفاضلة مع الاستضافة الذاتية. سعر API المنخفض جذاب، لكنه عائق أمام المؤسسات التي لديها متطلبات سيادة البيانات والامتثال التنظيمي والنشر داخل المنشأة (on-premise) بسبب التبعية. تقدّم ai-platform التابعة لـThaki Cloud نماذج مفتوحة الأوزان (open-weight) تُخدَّم في بيئتها الخاصة اعتماداً على K8s وKueue، مما يتيح تشغيل مسارات عمل الوكلاء دون إخراج البيانات إلى الخارج. الجمع بين “الذكاء لكل رمز” والخدمة الفعالة الذي أظهره Grok 4.5 يطرح على معسكر الاستضافة الذاتية تحدياً في الاتجاه نفسه: للمنافسة مع واجهات برمجة التطبيقات السحابية الرخيصة، لا بد من تحقيق كفاءة في الرموز وتكلفة خدمة منخفضة أيضاً على مستوى المنشأة. وهذا يتقاطع تماماً مع توجهنا الذي يجعل من انخفاض تكلفة الخدمة ميزة تنافسية.

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

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

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

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

المصادر

• Axios, “Scoop: SpaceXAI launches new model, Grok 4.5”
• TechCrunch, “SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’”
• The Decoder, “Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much”

لكن GLM-5.2 الذي كشفت عنه Zhipu يسير عكس هذا التيار تمامًا. تخلى هذا النموذج عن الأسلوب النسبي الجماعي وعاد إلى PPO باستخدام نموذج قيمة مدرَّب من جديد، وعالج بدلاً من ذلك عدم التطابق بين توزيعي التدريب والاستدلال، وهو أحد أكبر مصادر عدم الاستقرار المزمنة في التعلم المعزز، عبر تقنية تُسمى IcePop. والمثير أن هذا الاختيار ليس مجرد رجوع بسيط، بل يحمل طابع الدحض العملي للفكرة الشائعة مؤخرًا بأن «GRPO هو الحل الشامل».

تصوير لتحول الاتجاه في التدريب اللاحق بالتعلم المعزز، من التخلي عن الـ critic إلى استعادته مجددًا.

نظرة عامة

GLM-5.2 نموذج مفتوح الأوزان بنافذة سياق تصل إلى مليون رمز (token)، ويُظهر أداءً قويًا في اختبارات المعايير الطويلة النفَس للبرمجة والوكلاء (agents). ما يتناوله هذا المقال ليس أرقام أداء النموذج نفسه، بل قرارات التصميم في التدريب اللاحق بالتعلم المعزز التي أنتجت هذا الأداء. والجوهر هنا نقطتان. الأولى، العودة إلى PPO باستخدام نموذج قيمة مدرَّب بدلاً من الأسلوب النسبي الجماعي (GRPO). والثانية، تخفيف عدم التطابق بين التدريب والاستدلال الناتج عن ذلك عبر IcePop، مع إزالة حد التنظيم KL الذي كان موجودًا في الصياغة الأصلية لـ IcePop من أجل رفع سرعة تحسّن التعلم المعزز.

هذا الموضوع مهم من منظور ThakiCloud لسبب واضح. خط أنابيب تدريب النماذج اللغوية الكبيرة الذي نشغّله يدعم عدة أساليب للتدريب اللاحق مثل SFT وCPT وDPO وGRPO وGKD. اختيار منهجية التعلم المعزز ليس مجرد تفضيل خوارزمي، بل قرار بنيوي يؤثر مباشرة في ميزانية وحدات معالجة الرسوميات (GPU) واستقرار التدريب وقابلية إعادة الإنتاج. حالة GLM-5.2 تدفعنا إلى إعادة طرح السؤال، ليس «ماذا نستخدم» بل «لماذا نستخدمه».

الجدار الذي اصطدم به GRPO: ثمن التخلي عن الـ critic

لنبدأ أولاً بسبب انتقال هذا العدد الكبير من الفرق إلى GRPO. الـ PPO التقليدي بنية actor-critic. السياسة (actor) تولّد الرموز، ونموذج قيمة منفصل (critic) يقدّر المكافأة المتوقعة لكل حالة. من هذا التقدير تُحسب الأفضلية (advantage، غالبًا عبر GAE)، وتُحدَّث السياسة عبر دالة هدف بديلة (surrogate) مقصوصة (clipped). المشكلة هي تكلفة تدريب هذا الـ critic. يجب إضافة نموذج آخر بحجم يقارب حجم السياسة نفسها، وإذا تقارب الـ critic بشكل خاطئ، يهتز التدريب بأكمله.

يتخلى GRPO عن هذا الـ critic تمامًا. بعد أخذ عينات من عدة استجابات لنفس المُوجِّه (prompt)، يُطبَّع المكافأة داخل تلك المجموعة، فتُبنى الأفضلية اعتمادًا فقط على التفوق النسبي. باختفاء الـ critic، تنخفض الذاكرة المستخدمة، ويختفي معه عدم استقرار تدريب نموذج القيمة. وبفضل أناقته الرياضية أيضًا، انتشر بسرعة.

لكن لا توجد وجبة مجانية. تتلاشى إشارة الأفضلية في الأسلوب النسبي الجماعي عندما يكون التباين داخل المجموعة صغيرًا، أي عندما تكون الاستجابات متقاربة في الجودة سواء كانت جيدة أو سيئة. كذلك يصعب إسناد الفضل (credit assignment) الدقيق على مستوى الرمز في التسلسلات الطويلة. لو وُجد نموذج قيمة، لأمكن تقدير «مدى إسهام هذا الرمز في المكافأة النهائية» لكل حالة، لكن التطبيع الجماعي وحده لا يوفر هذه الدقة. تبرز هذه المحدودية بوضوح في المسائل ذات المسارات الطويلة والمكافآت النادرة، كأعمال البرمجة والوكلاء طويلة النفَس. وهذا بالضبط المجال الذي استهدفه GLM-5.2.

اختيار GLM-5.2: PPO بإحياء نموذج القيمة

هنا يستعيد فريق GLM-5.2 نموذج القيمة المدرَّب. أي أنهم يستعيدون الـ critic الذي تخلى عنه GRPO، لاستعادة دقة تقدير الأفضلية على مستوى الرمز. وعلى عكس التصور السائد بأن «ضجة PPO مبالغ فيها»، راهن الفريق على أن نموذج قيمة مدرَّبًا جيدًا يمنح إشارة أكثر استقرارًا في المسارات الطويلة.

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

flowchart TB
    A["دفعة من المُوجِّهات (prompts)"] --> B["محرك الاستدلال SGLang<br/>توليد التجارب (rollout)"]
    B --> C["الرموز المولَّدة + المكافآت"]
    C --> D["محرك التدريب Megatron<br/>إعادة حساب forward"]
    D --> E{"احتمال الاستدلال ≠ احتمال التدريب<br/>عدم تطابق التوزيع"}
    E -->|"بلا تصحيح"| F["انفجار نسبة الأهمية<br/>انهيار التدريب"]
    E -->|"إخفاء IcePop"| G["كبح الرموز عالية عدم التطابق<br/>تحديث سياسة مستقر"]
    G --> H["تحديث PPO لنموذج القيمة"]
    H --> A

IcePop: كيفية معالجة عدم التطابق بين التدريب والاستدلال

يتنقل التدريب اللاحق الحديث بالتعلم المعزز بين محركين مختلفين. يتولى توليد التجارب (rollout) محرك استدلال عالي الإنتاجية مثل SGLang، بينما يتولى حساب forward الفعلي لتحديث السياسة محرك تدريب مثل Megatron. المشكلة أن هذين المحركين، حتى لو استخدما نفس أوزان النموذج، يختلفان في تنفيذ النواة (kernel) والدقة العددية وترتيب العمليات، فينتجان احتمالات مختلفة قليلاً لنفس الرمز.

يصحّح التعلم المعزز عادةً هذه الفجوة عبر أخذ العينات بالأهمية (importance sampling)، أي ضرب نسبة احتمال السياسة وقت الاستدلال إلى احتمالها وقت التدريب. لكن عند الرموز التي يتباعد فيها التوزيعان، تنفجر هذه النسبة صعودًا أو هبوطًا بشكل حاد. وإذا سيطرت بضعة رموز ذات نسبة متطايرة على التدرّج (gradient)، يهتز التدريب بأكمله، وقد ينهار في الحالات الشديدة. وكلما طال المسار، أي زاد عدد الرموز، ارتفع احتمال تراكم هذا التطاير. وكان هذا تحديًا حاسمًا بالنسبة لـ GLM-5.2 الذي استهدف الأعمال طويلة النفَس.

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

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

البنية التحتية: slime وMegatron وSGLang

لكي لا تبقى هذه الخوارزمية مجرد فكرة على الورق وتعمل فعليًا، لا بد من بنية تحتية تتحمل توسّع التعلم المعزز. جرى التدريب اللاحق لـ GLM-5.2 على إطار عمل لتوسيع التعلم المعزز يُسمى slime، ويستخدم Megatron-LM للتدريب الموزَّع وSGLang لتوليد التجارب عالي الإنتاجية. وعدم التطابق بين التدريب والاستدلال الذي شرحناه سابقًا ينبع بالضبط من هذا التكوين. تتباعد الاحتمالات لأن Megatron (التدريب) وSGLang (الاستدلال) يستخدمان كل منهما نواة محسَّنة خاصة به، ويستهدف IcePop تحديدًا هذه الفجوة البنيوية.

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

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

منصة ai-platform لدى ThakiCloud بنية تحتية للذكاء الاصطناعي وتعلم الآلة قائمة على K8s، تشغّل خط أنابيب تدريب يدعم جدولة وحدات معالجة الرسوميات عبر Kueue وأساليب متعددة للتدريب اللاحق (SFT وCPT وDPO وGRPO وGKD). حالة GLM-5.2 تحمل دلالات مباشرة لتصميم هذا الخط.

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

ثانيًا، عدم التطابق بين التدريب والاستدلال ليس أمرًا بعيدًا عنا. عند تشغيل تعلم معزز مُقسَّم (يُستخرج فيه التجريب من محرك استدلال من عائلة vLLM/SGLang بينما يجري التحديث في محرك التدريب) في بيئة متعددة المستأجرين، تنشأ فجوة الاحتمالات نفسها. وإذا جهّزنا تصحيحًا لانتقاء الرموز على غرار IcePop كخيار في بيئة التشغيل التدريبية، يمكن أن نرفع بشكل كبير استقرار التدريب لدى العملاء الذين يريدون صقل نماذجهم الخاصة بالتعلم المعزز في بيئات محلية (on-premise) أو سيادية. تكلفة خدمة منخفضة وخط أنابيب تدريب مستقر ميزتان تنافسيتان حاسمتان لأي فريق يدرس الاستضافة الذاتية.

من منظور الوكلاء (agents)، ترتبط هذه الحالة أيضًا بـ Paxis. Paxis سحابة أصيلة الوكلاء (Agent-Native Cloud) تعمل فوق ai-platform، تتعامل مع المهارات والأدوات والسياسات كموارد من الدرجة الأولى. تدريب مسارات الوكلاء طويلة النفَس الذي شدّد عليه GLM-5.2 هو في جوهره تعزيز لقدرة الوكيل على إنجاز المهام عبر استدعاء الأدوات على مدى خطوات متعددة. والدرس المستفاد من هذه الحالة، وهو أن نموذج قيمة مدرَّبًا جيدًا يمنح إشارة دقيقة في المسارات الطويلة، مرجع يستحق الاعتبار عند التفكير في استراتيجية تدريب ترفع جودة تدفقات عمل الوكلاء متعددة الخطوات التي تتعامل معها Paxis.

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

يجب توخي الحذر عند تعميم هذه الحالة. أولاً، لا ينبغي قراءتها كخلاصة مبسطة مفادها أن «PPO أفضل من GRPO». اختيار GLM-5.2 حكمٌ في سياق مسألة محددة تتسم بالمسارات الطويلة والمكافآت النادرة. في المسائل ذات المكافآت القصيرة وعالية الكثافة، قد تفوق تكلفة الحفاظ على الـ critic فائدتَه، وفي هذه الحالة يبقى GRPO خيارًا معقولاً. كما أن القيد الواقعي المتمثل في عودة ميزانية ذاكرة وحدات معالجة الرسوميات إلى الارتفاع بمجرد إحياء نموذج القيمة يظل قائمًا كما هو.

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

أخيرًا، الشرح التقني في هذا المقال توليف من تحليلات منشورة وورقة بحثية (على arXiv بعنوان “GLM-5: from Vibe Coding to Agentic Engineering”) وشروحات ثانوية. يجب التحقق من المعاملات الفائقة (hyperparameters) الدقيقة والأرقام الفعلية لاختبارات المعايير من المصدر الأصلي مباشرة، وقد تكون تفاصيل تنفيذية لم يتطرق إليها هذا المقال حاسمة في إعادة الإنتاج الفعلية. التدريب اللاحق بالتعلم المعزز مجال يصعب فيه إعادة الإنتاج بشكل خاص، لذا من الأسلم تلقّي هذا المقال باعتباره «اتجاهًا يستحق التفكير فيه» لا «وصفة مضمونة النجاح».

المصادر

• arXiv, “GLM-5: from Vibe Coding to Agentic Engineering” (arXiv:2602.15763)
• “Why is GLM-5.2 So Good: The GRPO to PPO Switch”, Medium (Coding Nexus)
• “Zhipu’s GLM-5.2: A Usability Breakthrough for Chinese Open-Source Models?”, Weijin Research

An abstract depiction of a model designed from the ground up for coding and agentic work.

Overview

Grok 4.5 is a model that SpaceXAI says it trained from scratch for coding and autonomous agents. Rather than positioning it as a consumer chatbot, the company frames it as a tool for development and knowledge work, aimed at large codebases, tool use, and long-running tasks. Elon Musk introduced the model as “Opus-class, but faster, more token-efficient, and cheaper.” The Opus referenced here is Anthropic’s top model tier until recently.

What makes this announcement more than just another model launch is its pricing and training approach. Grok 4.5 is priced at $2 per million input tokens and $6 per million output tokens. Offering frontier-level performance at this price point shakes the long-standing assumption that “smart models are too expensive to run as agents for long stretches.” From ThakiCloud’s perspective, this shift is not someone else’s problem. Cheap agentic intelligence directly changes the economics of any platform that runs agents around the clock.

What Was Announced

Here is a summary of the disclosed facts. Grok 4.5 is SpaceXAI’s first model trained specifically for coding and agentic work, and the company claims it outperforms peer models on engineering and knowledge-work tasks. Training took place alongside the code editor Cursor, in the context of SpaceXAI having acquired Cursor and then refining the model within that usage environment. In fact, Grok 4.5 is available across all Cursor plans from launch, and it is also offered through Grok Build and the SpaceXAI console. As of the announcement, however, it is not yet available in the EU.

The training infrastructure was also disclosed. The company trained this model across tens of thousands of NVIDIA GB300 GPUs, and stated that it invested heavily in reinforcement learning (RL) for per-token intelligence. SpaceXAI explains that this investment is precisely what created the token-efficiency gap versus Opus 4.8. In other words, the model was trained to handle the same task using fewer tokens, which directly translates into lower real-world costs.

What “Training Specifically for Coding and Agents” Means

The phrase “trained for coding and agents” is easy to dismiss as marketing copy, but it carries a concrete design direction. General-purpose conversational models are optimized to answer naturally across a broad range of topics. Agentic models, by contrast, live or die on their ability to call tools across many steps, observe intermediate results, revise plans, and carry a long task through to completion. That ability cannot be learned from single-response quality alone; reinforcement learning that feeds the success or failure of an entire trajectory back as a reward signal plays a major role.

flowchart TB
    A["Developer task instruction"] --> B["Agent: explore codebase"]
    B --> C["Tool call: edit files, run tests"]
    C --> D["Observe intermediate results"]
    D --> E{"Task complete?"}
    E -->|"No"| B
    E -->|"Yes"| F["Final output"]
    G["Per-token intelligence RL training"] -.influences.-> C
    G -.influences.-> D

The “per-token intelligence” SpaceXAI emphasizes should be read in this context. The structural reason token consumption explodes when an agent works on a long task is that the model tends to think more verbosely than necessary before reaching the same conclusion, or repeats unnecessary tool calls. Training the model to pack more judgment into each token lets it complete the same task in a shorter trajectory. Training inside Cursor, a real coding environment, ties into this as well. Using real-world tool-call patterns as a training signal can push an agent toward handling tools more efficiently.

What the Pricing Changes

Offering frontier-level performance at $2 per million input tokens and $6 per million output tokens changes the profit-and-loss math of running agents. In workflows where an agent burns through millions of tokens all day moving across a codebase, the per-token price directly determines the service’s margin. If performance is comparable, the cheaper model wins. Several analyses point out that Grok 4.5 is dramatically cheaper than Fable 5 or GPT 5.5, and that if the benchmark gap is not large, price alone could decide which model gets chosen.

This matters because cheap agentic intelligence reopens workflows that had previously been shelved due to cost. Tasks that consume large amounts of tokens, such as automated code review, large-scale refactoring, or always-on monitoring agents, benefit the most from a lower per-token price. That said, this math comes with a caveat. A low API price is also the cost of depending on a cloud vendor. Data leaves your environment, and pricing policy and availability are dictated by the vendor’s decisions. The fact that Grok 4.5 is not yet available in the EU shows that this dependency risk is real, not theoretical.

ThakiCloud’s Perspective

The arrival of cheap agentic models touches both of ThakiCloud’s products.

From Paxis’s perspective, a low-cost, high-performance agentic model like Grok 4.5 reinforces the premise of the Agent-Native Cloud. Paxis is the agent control plane that runs on top of ai-platform, treating skills, tools, policies, and audit logs as first-class resources. In a structure where agents carry out long tasks across dozens of steps, you need a layer that routes that behavior through policy gates and records it in audit logs, regardless of which model is doing the work. As models get cheaper, agents get run more often and for longer, and the value of orchestration and governance grows accordingly. Cheap intelligence does not reduce the need for an agent platform; it increases it.

From the ai-platform perspective, the trade-off with self-hosting becomes sharper. A low API price is attractive, but for organizations with data sovereignty requirements, regulatory obligations, or on-premise needs, that dependency becomes an obstacle. ThakiCloud’s ai-platform serves open-weight models on its own K8s and Kueue-based infrastructure, allowing agentic workflows to run without data ever leaving the environment. The combination Grok 4.5 demonstrates, per-token intelligence paired with efficient serving, poses the same challenge to the self-hosting camp. In other words, to compete with cheap cloud APIs, on-premise deployments must also achieve token efficiency and low serving costs at the same time. This is precisely the direction we are pursuing: making low serving cost our competitive edge.

Limitations and Counterpoints

A few things need to be held in reserve when evaluating this announcement. First, much of the performance claim rests on the company’s own statements. Phrases like “Opus-class” or “outperforms peers” are safer treated as marketing until independently benchmarked. How the model actually stacks up in real coding and agentic work will vary widely depending on each user’s workload.

Second, price competitiveness does not automatically mean it is the best choice. A cheap rate comes bundled with vendor lock-in, data movement, and availability risk. Regional and regulatory constraints, like unavailability in the EU, are real, and such constraints can become decisive obstacles in domains like domestic public sector or finance where data sovereignty matters. Deciding on adoption based on performance and price alone risks running into regulatory and governance requirements later and having to walk it back.

Finally, the facts in this piece are drawn from a synthesis of public reporting and company statements. Detailed benchmark figures and precise training specifics should be verified directly from primary sources, and the picture may change as independent evaluations accumulate over time.

Sources

• Axios, “Scoop: SpaceXAI launches new model, Grok 4.5”
• TechCrunch, “SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’”
• The Decoder, “Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much”

Zhipu’s GLM-5.2, however, runs directly against this trend. The model abandons the group-relative approach and goes back to PPO with a trained value model, while addressing RL’s chronic instability problem, the train-inference distribution mismatch, with a technique called IcePop. What makes this interesting is that the choice is not a simple regression. It amounts to an empirical rebuttal of the recent conventional wisdom that “GRPO is universally superior.”

Depicting the directional shift in RL post-training: dropping the critic, then bringing it back.

Overview

GLM-5.2 is an open-weight model with a one-million-token context window that shows strong performance on long-horizon coding and agentic benchmarks. This post is not about the model’s raw performance numbers, but about the RL post-training design decisions behind that performance. There are two key points. First, the model went back to PPO with a trained value model instead of the group-relative approach (GRPO). Second, it mitigated the resulting train-inference mismatch with IcePop, while removing the KL regularization term that was part of the original IcePop formulation, in order to speed up RL improvement.

This topic matters from ThakiCloud’s perspective for a concrete reason. The LLM training pipeline we operate supports several post-training methods, including SFT, CPT, DPO, GRPO, and GKD. The choice of RL methodology is not merely a matter of algorithmic taste. It is an infrastructure decision that directly affects GPU budget, training stability, and reproducibility. GLM-5.2’s case pushes us to ask not just “what should we use” but “why should we use it.”

The Wall GRPO Hit: The Cost of Dropping the Critic

Let’s first look at why so many teams moved to GRPO. Traditional PPO uses an actor-critic structure. A policy (the actor) generates tokens, while a separate value model (the critic) estimates the expected reward of each state. This value estimate is used to compute advantage (typically via GAE), and the policy is updated with a clipped surrogate objective. The problem is the cost of training this critic. You need to run an additional model that is roughly the same size as the policy, and if the critic converges poorly, the entire training run can become unstable.

GRPO removes the critic entirely. It samples multiple responses for the same prompt, normalizes the reward within that group, and derives advantage purely from relative standing. With no critic, memory usage drops, and the instability that comes from training a value model disappears along with it. The approach is also mathematically clean, which helped it spread quickly.

But there is no free lunch. The group-relative approach loses signal when the variance within a group is small, that is, when the responses are all similarly good or similarly bad. It also struggles with fine-grained, token-level credit assignment over long sequences. A value model can estimate, state by state, “how much did this token contribute to the final reward.” Group normalization alone cannot deliver that resolution. This limitation is most pronounced in problems with long trajectories and sparse rewards, such as long-horizon coding and agentic tasks. That is precisely the territory GLM-5.2 was targeting.

GLM-5.2’s Choice: PPO with a Revived Value Model

The GLM-5.2 team brought the trained value model back. In other words, they restored the critic that GRPO had discarded, in order to regain token-level advantage estimation resolution. Contrary to the prevailing sentiment that “the PPO hype is overblown,” they bet instead that a well-trained value model gives a more stable signal over long trajectories.

The problem is that the moment you revive the critic, the training instability mentioned earlier comes back with it. And on top of that, a newer headache specific to modern RL stacks compounds the issue: train-inference distribution mismatch.

flowchart TB
    A["Prompt batch"] --> B["Inference engine SGLang<br/>generates rollouts"]
    B --> C["Generated tokens + reward"]
    C --> D["Training engine Megatron<br/>recomputes forward pass"]
    D --> E{"Inference probability differs<br/>from training probability<br/>distribution mismatch"}
    E -->|"No correction"| F["Importance ratio explodes<br/>training collapses"]
    E -->|"IcePop masking"| G["Suppress high-mismatch tokens<br/>stable policy update"]
    G --> H["Value model PPO update"]
    H --> A

IcePop: Fixing the Train-Inference Mismatch

Modern RL post-training moves back and forth between two different engines. Rollouts, that is response generation, are handled by a high-throughput inference engine such as SGLang, while the forward computation for the actual policy update is handled by a training engine such as Megatron. The problem is that even when these two engines use the same model weights, differences in kernel implementation, numerical precision, and computation order cause them to produce subtly different probabilities for the same token.

RL typically corrects for this gap using importance sampling, which multiplies by the ratio between the inference-time policy probability and the training-time policy probability. But for tokens where the two distributions diverge, this ratio can explode or collapse. When a handful of tokens with runaway ratios come to dominate the gradient, the entire training run becomes unstable, and in severe cases it collapses. The longer the trajectory, that is, the more tokens involved, the higher the probability that these spikes accumulate. For GLM-5.2, which targets long-horizon tasks, this was an especially critical problem.

IcePop tackles this mismatch head on. It identifies tokens where the inference distribution and the training distribution diverge significantly, and suppresses or masks that token’s contribution, so the gradient is not dragged around by a small number of unstable tokens. The result is that only the signal from stable tokens is retained and used in the policy update. This lets the training keep the benefits of PPO with a revived value model while avoiding the collapse caused by train-inference mismatch.

Where GLM-5.2 diverges from the original IcePop is that it removes the KL regularization term. Many RL recipes apply a KL penalty to keep the policy from drifting too far from the reference policy. This term improves stability, but it also caps how much the policy is allowed to improve. The GLM-5.2 team judged that IcePop’s distribution-mismatch masking already handled most of the instability, so they dropped the KL term and allowed the policy to improve more aggressively. In effect, they removed one stability mechanism and handed that role over to IcePop’s token selection.

Infrastructure: slime, Megatron, SGLang

For this algorithm to work in practice rather than remain an idea on paper, it needs infrastructure that can withstand RL at scale. GLM-5.2’s post-training was carried out on top of an RL scaling framework called slime, using Megatron-LM for distributed training and SGLang for high-throughput rollout generation. The train-inference mismatch described above arises directly from this configuration. Because Megatron (training) and SGLang (inference) each use their own optimized kernels, probabilities diverge between the two, and IcePop is designed precisely to target this structural gap.

In other words, IcePop is less a pure algorithmic improvement and more a joint system-and-algorithm design response to a system-level problem that inevitably arises in modern RL stacks that separate the training engine from the inference engine. The lesson for practitioners is clear. When choosing an RL methodology, you cannot look at the algorithm alone. You have to consider the combination of training and inference engines that algorithm runs on.

Implications for ThakiCloud’s Product

ThakiCloud’s ai-platform is a K8s-based AI/ML infrastructure that operates a training pipeline supporting GPU scheduling through Kueue and multiple post-training methods (SFT, CPT, DPO, GRPO, GKD). GLM-5.2’s case has direct implications for how this pipeline should be designed.

First, RL methodology is not something to fix in place. It is a choice to be made based on the problem at hand. For short-trajectory preference alignment, critic-free GRPO remains economical, but for problems where token-level credit assignment matters, such as long coding or agentic trajectories, PPO with a value model can provide a more stable signal. In a platform like ours that supports multiple methods, exposing this choice so users can switch based on the characteristics of their problem creates real, practical value.

Second, train-inference mismatch is not someone else’s problem for us either. If you run a decoupled RL setup, drawing rollouts from an inference engine (the vLLM/SGLang family) while running the update on a training engine, in a multitenant environment, the same kind of probability mismatch can occur. Preparing a token-selection correction like IcePop as an option in the training runtime can significantly improve training stability for customers who want to fine-tune their own models with RL in an on-premises or sovereign environment. Low serving cost combined with a stable training pipeline is a decisive advantage for teams considering self-hosting.

From an agent perspective, this connects to Paxis as well. Paxis is the Agent-Native Cloud that runs on top of ai-platform, treating skills, tools, and policies as first-class resources. GLM-5.2’s emphasis on long-horizon agent trajectory training is, at its core, about strengthening an agent’s ability to complete tasks by calling tools across multiple steps. The lesson from this case, that a well-trained value model provides finer-grained signal over long trajectories, is worth keeping in mind when thinking through training strategies to improve the quality of the multi-step agent workflows Paxis handles.

Limitations and Counterarguments

This case should be generalized with caution. First, it should not be read as a simple conclusion that “PPO is better than GRPO.” GLM-5.2’s choice is a judgment made within a specific problem setting characterized by long horizons and sparse rewards. For problems with short, dense reward signals, the cost of maintaining a critic can outweigh the benefit, in which case GRPO remains a reasonable choice. The practical constraint that reviving the value model increases the GPU memory budget again also still applies.

Removing IcePop’s KL term is not a universal solution either. KL regularization is a safeguard against the policy running away from the reference policy. Removing it and relying entirely on distribution-mismatch masking for stability only holds up under the assumption that the masking works well. That assumption could break down under a different data distribution or a different combination of inference engines, so rather than porting this decision over directly, teams need a process to verify stability in their own environment.

Finally, the technical explanation in this post is a synthesis of publicly available analyses and papers (arXiv’s “GLM-5: from Vibe Coding to Agentic Engineering”) as well as secondary commentary. Specific hyperparameters and exact benchmark numbers should be confirmed directly against the original source, and implementation details not covered here may prove decisive for actual reproduction. RL post-training is a particularly difficult area to reproduce, so it is safer to treat this as “a direction worth considering” rather than “a recipe that just works.”

Sources

• arXiv, “GLM-5: from Vibe Coding to Agentic Engineering” (arXiv:2602.15763)
• “Why is GLM-5.2 So Good: The GRPO to PPO Switch”, Medium (Coding Nexus)
• “Zhipu’s GLM-5.2: A Usability Breakthrough for Chinese Open-Source Models?”, Weijin Research

코딩과 에이전트 작업을 위해 처음부터 설계된 모델이라는 방향성을 추상적으로 형상화했습니다.

개요

Grok 4.5는 SpaceXAI가 코딩과 자율 에이전트를 위해 처음부터 훈련했다고 밝힌 모델입니다. 소비자용 챗봇이라기보다 개발과 지식 노동을 위한 도구로 포지셔닝됐고, 큰 코드베이스·도구 사용·장기 실행 작업을 겨냥합니다. Elon Musk는 이 모델을 “Opus급이지만 더 빠르고 토큰 효율이 높으며 비용이 낮은” 모델이라고 소개했습니다. 여기서 참조된 Opus는 최근까지 Anthropic의 최상위 모델군이었습니다.

이 발표가 단순한 신모델 출시 이상인 이유는 가격과 훈련 방식에 있습니다. Grok 4.5는 백만 입력 토큰당 2달러, 백만 출력 토큰당 6달러로 책정됐습니다. 프론티어급 성능을 이 가격대에 내놓는 것은, “똑똑한 모델은 비싸서 에이전트로 오래 굴리기 어렵다”는 그동안의 전제를 흔듭니다. ThakiCloud 관점에서 이 변화는 남의 일이 아닙니다. 값싼 에이전트 지능은 곧 에이전트를 상시 운용하는 플랫폼의 경제성을 바꾸기 때문입니다.

이 글은 새 모델의 정체성부터 토큰당 지능, 에이전트 단가 변화, ThakiCloud 전략적 함의까지 네 갈래로 짚습니다.

무엇이 발표되었나

공개된 사실을 정리하면 다음과 같습니다. Grok 4.5는 코딩과 에이전트 작업에 특화해 훈련된 SpaceXAI의 첫 모델이며, 회사는 이 모델이 엔지니어링과 지식 노동에서 동급 모델을 능가한다고 주장합니다. 훈련은 코드 편집기 Cursor와 나란히 이뤄졌는데, SpaceXAI가 Cursor를 인수한 뒤 그 사용 환경 안에서 모델을 다듬었다는 맥락입니다. 실제로 Grok 4.5는 출시와 함께 Cursor의 모든 플랜에서 쓸 수 있고, Grok Build와 SpaceXAI 콘솔에서도 제공됩니다. 다만 발표 시점 기준으로 EU에서는 아직 사용할 수 없습니다.

훈련 인프라도 공개됐습니다. 회사는 이 모델을 수만 개의 NVIDIA GB300 GPU에 걸쳐 훈련했고, 토큰당 지능(per-token intelligence)에 강화학습(RL)을 크게 투자했다고 밝혔습니다. SpaceXAI는 바로 이 투자가 Opus 4.8 대비 토큰 효율 격차를 만들었다고 설명합니다. 즉 같은 작업을 더 적은 토큰으로 처리하도록 학습시켰다는 것이며, 이는 곧 실사용 비용의 절감으로 이어집니다.

소비자용 챗봇이 아니라 큰 코드베이스·도구 사용·장기 실행 작업을 겨냥한 아키텍처로, Cursor 환경에서 훈련되고 수만 개 GB300 GPU로 학습됐습니다.

‘코딩·에이전트 전용 훈련’이 의미하는 것

“코딩과 에이전트를 위해 훈련했다”는 표현은 마케팅 문구로 흘려듣기 쉽지만, 그 안에는 구체적인 설계 방향이 담겨 있습니다. 일반 대화형 모델은 폭넓은 주제에 자연스럽게 답하도록 최적화됩니다. 반면 에이전트 모델은 여러 스텝에 걸쳐 도구를 호출하고, 중간 결과를 관찰하고, 계획을 수정하며 긴 작업을 완수하는 능력이 핵심입니다. 이 능력은 단일 응답의 품질만으로는 학습되지 않으며, 궤적 전체의 성공 여부를 보상 신호로 되먹이는 강화학습이 큰 역할을 합니다.

flowchart TB
    A["개발자 작업 지시"] --> B["에이전트: 코드베이스 탐색"]
    B --> C["도구 호출 파일 편집·테스트"]
    C --> D["중간 결과 관찰"]
    D --> E{"작업 완료?"}
    E -->|"아니오"| B
    E -->|"예"| F["최종 산출물"]
    G["토큰당 지능 RL 훈련"] -.영향.-> C
    G -.영향.-> D

SpaceXAI가 강조한 “토큰당 지능”은 이 맥락에서 읽어야 합니다. 에이전트가 긴 작업을 돌 때 토큰 소비가 폭증하는 구조적 이유는, 모델이 같은 결론에 도달하기까지 필요 이상으로 장황하게 생각하거나 불필요한 도구 호출을 반복하기 때문입니다. 토큰당 더 많은 판단을 담도록 훈련하면, 같은 작업을 더 짧은 궤적으로 끝낼 수 있습니다. Cursor라는 실제 코딩 환경 안에서 훈련했다는 점도 여기에 맞물립니다. 실사용 도구 호출 패턴을 학습 신호로 쓰면, 에이전트가 도구를 더 효율적으로 다루도록 유도할 수 있습니다.

기존 에이전트가 불필요한 도구 호출과 장황한 사고로 궤적을 늘리는 반면, 궤적 전체의 성공을 보상으로 학습한 모델은 더 적은 스텝으로 목적에 도달합니다.

가격이 만드는 변화

프론티어급 성능을 백만 입력 2달러, 출력 6달러에 제공한다는 것은 에이전트 운용의 손익 계산을 바꿉니다. 에이전트가 하루 종일 코드베이스를 오가며 수백만 토큰을 소비하는 워크플로에서는, 토큰 단가가 곧 서비스의 마진을 결정합니다. 성능이 비슷하다면 더 싼 모델이 이깁니다. 실제로 여러 분석은 Grok 4.5가 Fable 5나 GPT 5.5보다 훨씬 저렴해, 벤치마크 격차가 크지 않다면 가격만으로도 선택받을 수 있다고 지적합니다.

백만 토큰당 입력 2달러·출력 6달러라는 가격은 코드 리뷰 자동화·상시 모니터링·대규모 리팩터링처럼 단가에 막혀 있던 에이전트 워크플로를 경제적으로 풀어 줍니다.

이 지점이 중요한 이유는, 값싼 에이전트 지능이 그동안 비용 때문에 접었던 워크플로를 다시 열어 주기 때문입니다. 코드 리뷰 자동화, 대규모 리팩터링, 상시 모니터링 에이전트처럼 토큰을 많이 먹는 작업일수록 단가 인하의 효과가 큽니다. 다만 이 계산에는 단서가 붙습니다. 낮은 API 단가는 클라우드 벤더에 종속되는 대가이기도 합니다. 데이터가 외부로 나가고, 가격 정책과 가용성이 벤더의 결정에 좌우됩니다. Grok 4.5가 아직 EU에서 제공되지 않는다는 사실은 이 종속성이 실재하는 리스크임을 보여 줍니다.

ThakiCloud 관점

값싼 에이전트 모델의 등장은 ThakiCloud의 두 제품 모두와 맞닿아 있습니다.

Paxis 관점에서 보면, Grok 4.5 같은 저비용·고성능 에이전트 모델은 Agent-Native Cloud의 전제를 강화합니다. Paxis는 ai-platform 위에서 도는 에이전트 제어 평면으로, 스킬·도구·정책·감사 로그를 일급 리소스로 다룹니다. 에이전트가 긴 작업을 수십 스텝에 걸쳐 수행하는 구조에서는, 어떤 모델을 쓰든 그 행동을 정책 게이트로 통과시키고 감사 로그로 남기는 계층이 필요합니다. 모델이 싸질수록 에이전트를 더 많이, 더 오래 굴리게 되고, 그럴수록 오케스트레이션과 거버넌스의 가치가 커집니다. 값싼 지능은 에이전트 플랫폼의 필요를 줄이는 것이 아니라 오히려 키웁니다.

ai-platform 관점에서는 자체 호스팅과의 트레이드오프가 선명해집니다. 낮은 API 단가는 매력적이지만, 데이터 주권·규제 대응·온프레미스 요구가 있는 조직에는 종속성이 걸림돌입니다. ThakiCloud의 ai-platform은 K8s·Kueue 기반으로 오픈웨이트 모델을 자체 환경에서 서빙하며, 데이터를 밖으로 내보내지 않고도 에이전트 워크플로를 운용할 수 있게 합니다. Grok 4.5가 보여 준 “토큰당 지능”과 효율적 서빙의 결합은, 자체 호스팅 진영에도 같은 방향의 과제를 던집니다. 즉 값싼 클라우드 API와 경쟁하려면, 온프레미스에서도 토큰 효율과 낮은 서빙 비용을 함께 달성해야 합니다. 이는 정확히 낮은 서빙 비용을 경쟁력으로 삼는 우리의 지향과 겹칩니다.

값싼 지능은 오히려 스킬·도구·정책·감사 로그를 다루는 제어 평면의 필요를 키우고, 동시에 온프레미스가 클라우드 API와 경쟁하려면 토큰 효율과 낮은 서빙 비용을 함께 달성해야 하는 과제를 남깁니다.

한계 및 반론

이 발표를 평가할 때는 몇 가지를 유보해야 합니다. 먼저 성능 주장의 상당 부분은 회사 자체 발표에 기반합니다. “Opus급”, “동급 능가” 같은 표현은 독립적인 벤치마크로 교차 검증되기 전까지는 마케팅으로 취급하는 편이 안전합니다. 실제 코딩·에이전트 작업에서의 우열은 사용자별 워크로드에 따라 크게 갈립니다.

둘째, 가격 경쟁력이 곧 최선의 선택을 뜻하지는 않습니다. 값싼 단가는 벤더 종속·데이터 이동·가용성 리스크와 함께 옵니다. EU 미제공처럼 지역·규제 제약이 실제로 존재하며, 이런 제약은 국내 공공·금융처럼 데이터 주권이 중요한 영역에서 결정적 걸림돌이 될 수 있습니다. 성능과 가격만 보고 도입을 결정하면, 나중에 규제·거버넌스 요구에 부딪혀 되돌아와야 할 수 있습니다.

값싼 단가는 벤더 종속과 데이터 주권 포기를 요구하고, EU 미제공 같은 지정학적 제약이 실재하며, 성능 주장은 독립 벤치마크로 교차 검증되기 전까지 유보해야 합니다.

마지막으로 이 글의 사실은 공개된 보도와 회사 발표를 종합한 것입니다. 세부 벤치마크 수치나 정확한 훈련 디테일은 원문에서 직접 확인해야 하며, 시간이 지나며 독립 평가가 쌓이면 그림이 달라질 수 있습니다.

출처

• Axios, “Scoop: SpaceXAI launches new model, Grok 4.5”
• TechCrunch, “SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’”
• The Decoder, “Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much”

그런데 Zhipu가 공개한 GLM-5.2는 이 흐름을 정면으로 거스릅니다. 이 모델은 그룹 상대 방식을 버리고 학습된 value model을 다시 쓰는 PPO로 돌아갔고, 대신 RL의 고질적 불안정 요인인 학습-추론 분포 불일치를 IcePop이라는 기법으로 잡았습니다. 흥미로운 점은 이 선택이 단순한 회귀가 아니라, “GRPO가 만능”이라는 최근의 통념을 실측으로 반박하는 성격을 띤다는 것입니다.

critic을 버렸다가 다시 불러오는 RL 포스트트레이닝의 방향 전환을 형상화했습니다.

개요

GLM-5.2는 100만 토큰 컨텍스트 윈도우를 갖고 장기 호흡의 코딩·에이전트 벤치마크에서 강한 성능을 보인 오픈웨이트 모델입니다. 이 글이 다루는 것은 모델 자체의 성능 수치가 아니라, 그 성능을 만든 RL 포스트트레이닝의 설계 결정입니다. 핵심은 두 가지입니다. 첫째, 그룹 상대 방식(GRPO) 대신 학습된 value model을 쓰는 PPO로 돌아갔다는 것. 둘째, 그 과정에서 발생하는 학습-추론 불일치를 IcePop으로 완화하되, 원래 IcePop 정식화에 있던 KL 정규화 항을 제거해 RL 개선 속도를 끌어올렸다는 것입니다.

이 주제가 ThakiCloud 관점에서 중요한 이유가 있습니다. 우리가 운용하는 LLM 훈련 파이프라인은 SFT·CPT·DPO·GRPO·GKD 같은 여러 포스트트레이닝 방법을 지원합니다. RL 방법론의 선택은 단순한 알고리즘 취향이 아니라, GPU 예산·학습 안정성·재현성에 직접 영향을 주는 인프라 결정입니다. GLM-5.2의 사례는 “무엇을 쓸 것인가”보다 “왜 그것을 쓰는가”를 다시 묻게 만듭니다.

전통적 PPO에서 GRPO로, 다시 GLM-5.2의 PPO 회귀로 이어지는 RL 포스트트레이닝의 구조적 흐름입니다. 알고리즘은 한 방향으로만 진화하지 않습니다.

GRPO가 부딪힌 벽: critic을 버린 대가

먼저 왜 그렇게 많은 팀이 GRPO로 옮겨 갔는지부터 짚겠습니다. 전통적인 PPO는 actor-critic 구조입니다. 정책(actor)이 토큰을 생성하고, 별도의 value model(critic)이 각 상태의 기대 보상을 추정합니다. 이 value 추정치로 advantage를 계산하고(대개 GAE), 클리핑된 surrogate 목적함수로 정책을 업데이트합니다. 문제는 이 critic을 학습시키는 비용입니다. 정책과 거의 같은 크기의 모델을 하나 더 얹어야 하고, critic이 잘못 수렴하면 전체 학습이 흔들립니다.

GRPO는 이 critic을 아예 없앱니다. 같은 프롬프트에 대해 여러 응답을 샘플링한 뒤, 그 그룹 안에서 보상을 정규화해 상대적 우열만으로 advantage를 만듭니다. critic이 사라지니 메모리가 줄고, value 학습의 불안정성도 함께 사라집니다. 수학적으로도 깔끔해서 빠르게 퍼졌습니다.

GRPO는 정책과 같은 크기의 critic을 덜어 내 메모리와 연산을 절약하지만, 그 대가로 그룹 내부의 상대 우열이라는 저해상도 신호만 남습니다.

하지만 공짜 점심은 없었습니다. 그룹 상대 방식은 그룹 내부의 분산이 작을 때, 즉 응답들이 서로 비슷하게 좋거나 비슷하게 나쁠 때 advantage 신호가 뭉개집니다. 또한 긴 시퀀스에서 토큰 단위의 세밀한 credit assignment가 어렵습니다. value model이 있었다면 “이 토큰이 최종 보상에 얼마나 기여했는가”를 상태별로 추정할 수 있지만, 그룹 정규화만으로는 그 해상도가 나오지 않습니다. 장기 호흡의 코딩·에이전트 작업처럼 궤적이 길고 보상이 희소한 문제에서 이 한계가 두드러집니다. GLM-5.2가 겨냥한 영역이 바로 그런 문제였습니다.

짧은 궤적에서는 그룹 정규화가 잘 작동하지만, 궤적이 길어지고 보상이 희소해질수록 토큰 단위 신호의 해상도가 무너집니다.

GLM-5.2의 선택: value model을 되살린 PPO

GLM-5.2 팀은 여기서 학습된 value model을 다시 불러옵니다. 즉 GRPO가 버렸던 critic을 복원해, 토큰 단위의 advantage 추정 해상도를 되찾는 방향입니다. “PPO 하이프는 과장됐다”는 세간의 정서와 반대로, 이들은 오히려 잘 학습된 value model이 장기 궤적에서 더 안정적인 신호를 준다는 쪽에 베팅했습니다.

GLM-5.2는 버려졌던 학습된 value model을 다시 불러와, 장기 호흡 에이전트 작업에서 토큰 단위의 고해상도 신호를 되찾는 쪽에 베팅했습니다.

문제는 critic을 되살리는 순간, 앞서 언급한 학습의 불안정성도 함께 돌아온다는 점입니다. 그리고 여기에 최근 RL 스택 특유의 새로운 골칫거리가 하나 더 겹칩니다. 바로 학습-추론 분포 불일치입니다.

flowchart TB
    A["프롬프트 배치"] --> B["추론 엔진 SGLang<br/>롤아웃 생성"]
    B --> C["생성 토큰 + 보상"]
    C --> D["학습 엔진 Megatron<br/>forward 재계산"]
    D --> E{"추론 확률 ≠ 학습 확률<br/>분포 불일치"}
    E -->|"보정 없음"| F["중요도 비율 폭주<br/>학습 붕괴"]
    E -->|"IcePop 마스킹"| G["불일치 큰 토큰 억제<br/>안정적 정책 업데이트"]
    G --> H["value model PPO 업데이트"]
    H --> A

IcePop: 학습-추론 불일치를 잡는 법

현대의 RL 포스트트레이닝은 두 개의 서로 다른 엔진을 오갑니다. 롤아웃(응답 생성)은 SGLang 같은 고처리량 추론 엔진이 담당하고, 실제 정책 업데이트를 위한 forward 계산은 Megatron 같은 학습 엔진이 담당합니다. 문제는 이 두 엔진이 같은 모델 가중치를 쓰더라도 커널 구현·수치 정밀도·연산 순서가 달라, 같은 토큰에 대해 미묘하게 다른 확률을 내놓는다는 것입니다.

RL은 보통 중요도 샘플링(importance sampling)으로 이 간극을 보정합니다. 추론 시 정책과 학습 시 정책의 확률 비율을 곱해 주는 방식입니다. 그런데 두 분포가 어긋난 토큰에서는 이 비율이 폭발적으로 커지거나 작아집니다. 비율이 튀는 토큰 몇 개가 그래디언트를 지배하면 학습 전체가 흔들리고, 심하면 붕괴합니다. 궤적이 길수록, 즉 토큰이 많을수록 이런 튐이 누적될 확률이 높아집니다. 장기 호흡 작업을 겨냥한 GLM-5.2에게는 특히 치명적인 문제였습니다.

같은 가중치라도 학습 엔진(Megatron)과 추론 엔진(SGLang)의 커널·정밀도 차이로 확률이 어긋나, 중요도 비율이 폭발하며 학습을 붕괴시킵니다.

IcePop은 이 불일치를 정면으로 다룹니다. 추론 분포와 학습 분포가 크게 어긋나는 토큰을 식별해, 그 토큰의 기여를 억제하거나 마스킹하는 방식으로 그래디언트가 소수의 불안정 토큰에 끌려가지 않게 만듭니다. 결과적으로 안정적인 토큰의 신호만 살려 정책 업데이트에 반영합니다. 이렇게 하면 value model을 되살린 PPO의 이점을 취하면서도, 학습-추론 불일치가 일으키는 붕괴를 피할 수 있습니다.

GLM-5.2가 원래 IcePop과 다른 지점은 KL 정규화 항을 제거했다는 것입니다. 많은 RL 레시피는 정책이 참조 정책에서 너무 멀어지지 않도록 KL 페널티를 겁니다. 이 항은 안정성을 높이지만, 동시에 정책이 개선될 수 있는 폭을 억제합니다. GLM-5.2 팀은 IcePop의 분포 불일치 마스킹이 이미 불안정성을 상당 부분 잡아 준다고 보고, KL 항을 떼어 내 정책이 더 공격적으로 개선되도록 허용했습니다. 안정성 장치를 하나 덜어 내는 대신, 그 역할을 IcePop의 토큰 선별에 맡긴 셈입니다.

IcePop은 분포가 크게 어긋나는 토큰을 식별해 그 기여를 억제하고, GLM-5.2는 여기서 KL 정규화 항까지 제거해 정책 개선의 폭을 넓혔습니다.

인프라: slime, Megatron, SGLang

이 알고리즘이 종이 위의 아이디어에 그치지 않고 실제로 돌아가려면, RL 스케일링을 견디는 인프라가 필요합니다. GLM-5.2의 포스트트레이닝은 slime라는 RL 스케일링 프레임워크 위에서 이뤄졌고, 분산 학습에는 Megatron-LM을, 고처리량 롤아웃 생성에는 SGLang을 씁니다. 앞서 설명한 학습-추론 불일치가 바로 이 구성에서 나옵니다. Megatron(학습)과 SGLang(추론)이 각자 최적화된 커널을 쓰기 때문에 확률이 어긋나는 것이고, IcePop은 정확히 이 구조적 간극을 겨냥한 대응입니다.

즉 IcePop은 순수한 알고리즘 개선이라기보다, 학습 엔진과 추론 엔진을 분리한 현대적 RL 스택에서 필연적으로 발생하는 시스템 수준의 문제에 대한 시스템-알고리즘 공동 설계에 가깝습니다. 이 점이 실무자에게 주는 교훈은 분명합니다. RL 방법론을 고를 때는 알고리즘만 보면 안 되고, 그 알고리즘이 어떤 학습·추론 엔진 조합 위에서 도는지를 함께 봐야 합니다.

ThakiCloud 제품 적용 시사점

ThakiCloud의 ai-platform은 K8s 기반의 AI/ML 인프라로, Kueue를 통한 GPU 스케줄링과 다양한 포스트트레이닝 방법(SFT·CPT·DPO·GRPO·GKD)을 지원하는 훈련 파이프라인을 운용합니다. GLM-5.2의 사례는 이 파이프라인의 설계에 직접적인 시사점을 줍니다.

K8s·Kueue 기반의 ai-platform이 학습-추론 불일치를 방어하고, 그 위에서 모듈형 RL 런타임과 Paxis의 장기 에이전트 워크플로가 동작하는 구조입니다.

첫째, RL 방법론은 하나로 고정할 대상이 아니라 문제에 맞춰 고르는 선택지입니다. 짧은 궤적의 선호 정렬에는 critic 없는 GRPO가 여전히 경제적이지만, 긴 코딩·에이전트 궤적처럼 토큰 단위 credit assignment가 중요한 문제에서는 value model을 쓰는 PPO가 더 안정적인 신호를 줄 수 있습니다. 우리처럼 여러 방법을 한 플랫폼에서 지원하는 구조라면, 이 선택을 사용자가 문제 특성에 따라 바꿀 수 있게 노출하는 것이 실질적 가치를 만듭니다.

둘째, 학습-추론 불일치는 우리에게도 남의 일이 아닙니다. 롤아웃을 추론 엔진(vLLM/SGLang 계열)에서 뽑고 업데이트를 학습 엔진에서 도는 분리형 RL을 멀티테넌트 환경에서 돌리면, 같은 종류의 확률 불일치가 발생합니다. IcePop 같은 토큰 선별 보정을 훈련 런타임의 옵션으로 준비해 두면, 온프레미스·소버린 환경에서 자체 모델을 RL로 다듬으려는 고객의 학습 안정성을 크게 높일 수 있습니다. 낮은 서빙 비용과 안정적인 학습 파이프라인은 자체 호스팅을 검토하는 팀에게 결정적인 경쟁력입니다.

에이전트 관점에서는 Paxis와도 연결됩니다. Paxis는 ai-platform 위에서 도는 Agent-Native Cloud로, 스킬·도구·정책을 일급 리소스로 다룹니다. GLM-5.2가 강조한 장기 호흡 에이전트 궤적의 학습은, 결국 에이전트가 여러 스텝에 걸쳐 도구를 호출하며 작업을 완수하는 능력을 강화하는 일입니다. 잘 학습된 value model이 긴 궤적에서 세밀한 신호를 준다는 이 사례의 교훈은, Paxis가 다루는 다단계 에이전트 워크플로의 품질을 끌어올리는 학습 전략을 고민할 때 참고할 만한 지점입니다.

한계 및 반론

이 사례를 일반화할 때는 신중해야 합니다. 먼저 “PPO가 GRPO보다 낫다”는 단순 결론으로 읽으면 안 됩니다. GLM-5.2의 선택은 장기 호흡·희소 보상이라는 특정 문제 설정에서의 판단입니다. 짧고 밀도 높은 보상의 문제에서는 critic 유지 비용이 이득을 상쇄할 수 있고, 이 경우 GRPO가 여전히 합리적입니다. value model을 되살리는 순간 GPU 메모리 예산이 다시 늘어난다는 현실적 제약도 그대로입니다.

IcePop의 KL 항 제거도 만능은 아닙니다. KL 정규화는 정책이 참조 정책에서 폭주하는 것을 막는 안전장치입니다. 이를 떼어 내고 분포 불일치 마스킹에 안정성을 전적으로 맡기는 것은, 마스킹이 잘 작동한다는 전제 위에서만 성립합니다. 다른 데이터 분포나 다른 추론 엔진 조합에서는 이 전제가 깨질 수 있으므로, 그대로 이식하기보다 자체 환경에서 안정성을 검증하는 절차가 반드시 필요합니다.

마지막으로, 이 글의 기술적 설명은 공개된 분석과 논문(arXiv의 “GLM-5: from Vibe Coding to Agentic Engineering”) 및 2차 해설을 종합한 것입니다. 세부 하이퍼파라미터나 정확한 벤치마크 수치는 원문에서 직접 확인해야 하며, 여기서 다루지 않은 구현 디테일이 실제 재현에서 결정적일 수 있습니다. RL 포스트트레이닝은 특히 재현이 까다로운 영역이므로, “이렇게 하면 된다”보다 “이런 방향으로 고민해 볼 수 있다”로 받아들이는 편이 안전합니다.

출처

• arXiv, “GLM-5: from Vibe Coding to Agentic Engineering” (arXiv:2602.15763)
• “Why is GLM-5.2 So Good: The GRPO to PPO Switch”, Medium (Coding Nexus)
• “Zhipu’s GLM-5.2: A Usability Breakthrough for Chinese Open-Source Models?”, Weijin Research

أخبار اليوم انقسمت في اتجاهين

اتجاه واحد كان قصة عن الذكاء والحوسبة وهما يتحولان إلى سلعة متاحة للجميع. كشفت مجموعة Ant الصينية عن نموذج رؤية بالذكاء الاصطناعي قادر على التعرف على الأسطح العاكسة مثل الزجاج والمرايا، وتصدّر 12 معيار قياس دفعة واحدة، لكن اللافت لم يكن الأداء بل الحجم. بـ1.1 مليار معامل فقط، تفوق النموذج على نظير له بحجم 7 مليارات معامل. أظهر ذلك إلى أي مدى وصلت استراتيجيات الكفاءة في بيئة يصعب فيها الوصول إلى وحدات معالجة الرسوميات المتقدمة من Nvidia. في اليوم نفسه، تنافست OpenAI وAnthropic على استقطاب الشركات الناشئة المبكرة إلى منظومتيهما عبر تقديم رموز مجانية لأفضل نماذجهما، بينما حاولت Qualcomm إحداث شرخ في هيمنة Nvidia عبر شريحة مراكز بيانات منخفضة الاستهلاك تتجاوز الحاجة إلى ذاكرة HBM أصلا. كما وسّعت Anthropic استراتيجيتها متعددة الشرائح، موزعة أحمال العمل بين Amazon Trainium وGoogle TPU ووحدات معالجة Nvidia. لم يعد الذكاء ولا السيليكون الذي يشغّله مرتبطا بمكان واحد.

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

الذكاء يتحول إلى أمر عادي، والاختناق انتقل مكانه

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

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

في هذا السياق يُقرأ إعلان معهد Hana للتكنولوجيا المالية المتكاملة، في اليوم نفسه، عن نموذج ذكاء اصطناعي متخصص في الأعمال المالية لدعم تقييم الائتمان المؤسسي والاستشارات. سبب تحوّل بنوك مثل K bank وShinhan Bank وKB Kookmin Bank بالفعل نحو نماذج خاصة بمجالها يعود إلى بيئة كورية خاصة، تشمل لوائح فصل الشبكات وقيود نقل بيانات العملاء إلى خارج الشبكة الداخلية. تتجه البنوك نحو نماذج خفيفة ومتخصصة تعمل داخل شبكتها الخاصة بدلا من النماذج التأسيسية الضخمة العامة، والسبب ليس الأداء بل القدرة على التحكم. عليها أن تُبقي في يدها أين يعمل النموذج وماذا يترك من أثر إن أرادت اجتياز المراجعة التنظيمية.

نطاق ما يصبح عاديا يتسع أكثر فأكثر

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

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

إشارة إلى أننا نحكم على المسار لا على النتيجة وحدها

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

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

السجلات ليست ميزة تُضاف لاحقا

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

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

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

تُسجَّل كل خطوة تنفيذية يتخذها الوكيل بعد تجاوز بوابة السياسات كسجل تدقيق مرافق، ويبقى ذلك المسار داخل بنية Kubernetes سيادية محلية، بحيث يمكن إعادة تتبعه لاحقا.

تحمل هذه البنية قيمة خاصة في الصناعات المنظمة مثل التصنيع والقطاع العام والقطاع المالي. في اليوم نفسه، أعلنت Naver Cloud تعاونها مع Mistral AI الأوروبية لتطوير ذكاء اصطناعي سيادي متخصص في التصنيع بشكل مشترك، وهو نهج مصمم لطبيعة شركات التصنيع التي يصعب عليها إرسال بياناتها إلى الخارج. أطلقت الحكومة استراتيجية K-Physical AI، وتخطط لضخ 20 تريليون وون من القطاعين العام والخاص حتى عام 2030 لبناء مكتبة بيانات تصنيعية وطنية وتحويل حتى المعرفة الضمنية لكبار الحرفيين إلى بيانات، بينما تحوّل LG CNS محور أعمالها نحو التمويل والذكاء الاصطناعي الفيزيائي. القاسم المشترك بين هذه الجهات هو قيد عدم إمكان خروج البيانات إلى الخارج، وحاجة لا بد من الإمساك بها إلى الأثر الذي يتركه القرار الآلي. السيادة وسجلات التدقيق ليستا مطلبين منفصلين، بل مطلب واحد يُنظر إليه من الأمام ومن الخلف.

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

ما أصبح عاديا وما أصبح نادرا

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

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

المصادر

• 中 앤트그룹, 로봇 최대 난제 ‘유리·거울 인식’ 모델 공개 · AI타임스
• 하나금융융합기술원, 금융 업무용 AI 모델 공개…기업여신·상담 지원 적용 · 더데일리포스트
• 2026년 1월 시행 앞둔 ‘AI 기본법’…한국, 세계 첫 전면 적용 국가 되나 · MS투데이
• 슈퍼마이크로, 70억 달러 유상증자로 엣지부터 초대형 데이터센터까지 공급 확대 · ZDNet Korea
• 네이버클라우드, 미스트랄AI와 제조 특화 소버린 AI ‘동맹’ · ZDNet Korea
• 산업 하프타임: ‘3개월 1만 대’ 물량…’K-피지컬 AI’ 민관 20조원 엔진 가동 · 디지털데일리
• 오픈AI와 앤트로픽, 스타트업 잡으려 컴퓨팅 무료 공세 · 한국경제
• 세계 1만5천 AI 석학들 서울 총집결…ICML 2026, 한국 AI 위상 높인다 · 인공지능신문
• KT, ‘AX연결 허브’ 도약…수요 기반 AI 인프라 확충 · ZDNet Korea
• SKT, 15GW 규모 AI 데이터센터 구축…”아시아 AI 인프라 허브될 것” · SK텔레콤 뉴스룸

</content>

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

نظرة عامة

وسّعت Anthropic نطاق Claude Code من مجرّد واجهة سطر أوامر تفاعلية إلى بيئة تشغيل أتمتة. يتتبّع هذا المسارَ الإعلانُ المرتبط (“Enabling Claude Code to work more autonomously”)، ومقالة تصميم الوضع التلقائي (“How we built Claude Code auto mode”)، ومدوّنة التوجيه (“Steering Claude Code”). الرسالة الجوهرية واحدة: تشغيل Claude Code ذاتياً ليس مسألة انتظار نموذج أذكى، بل مسألة كيف تصمّم التجهيزة المحيطة به.

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

المشكلة: وكلاء يحتاجون إنساناً في كل مرة

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

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

1. الوضع الرأسي: نفّذ مرةً واحدة دون إنسان

يشغّل الوضع الرأسي Claude Code كعملية سطر أوامر واحدة دون TTY. استدعِه بصيغة claude -p "<موجَّه>" فينفّذ المهمة ويخرج، دون محادثة. تتيح هذه الخاصية البسيطة تكاملات غير مراقَبة مثل المهام المجدولة وأنابيب CI وفحوص ما قبل الالتزام. والأهمّ أن الوضع الرأسي يعيد استخدام الإعدادات والخطّافات وقواعد الأذونات نفسها الخاصة بالواجهة التفاعلية. أي إن تجهيزة تحقّقت منها تفاعلياً تنتقل مباشرةً إلى بيئة غير مراقَبة.

تشغّل ThakiCloud هذا على نطاق واسع بالفعل. فتحت scripts/launchd/ يوجد 35 ملف launchd plist، يستدعي كلٌّ منها مشغّل مهارة عبر claude -p في وقت محدّد. والأنبوب نفسه الذي يُنتج هذا المقال هو مثال على مشغّل رأسي. فالتدفّق كلّه، من سحب مرشّحي المدوّنة من الخطّ الزمني في تويتر إلى طابور، وصياغة كلٍّ منها، وتمريرها عبر بوابات التحقّق، وصولاً إلى النشر، يجري دون تدخّل إنسان في كل خطوة.

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

2. الخطّافات: تحكّم حتمي بدورة الحياة

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

يربط .claude/hooks/ في ThakiCloud 12 خطّافاً. يحقن خطّاف بدء الجلسة التعلّم السابق كموجز مقيم كي لا تبدأ كل جلسة من صفحة بيضاء. ويطفو خطّاف تقديم الموجَّه مرشّحي المهارات ذوي الصلة تلقائياً بعد تحليل الطلب. ويكتشف خطّاف الخروج ملف علَم ويشغّل المعالجة اللاحقة اللازمة، مثل تصريف مرشّحي المدوّنة المتراكمين في الطابور أو إعادة تجميع قاعدة المعرفة. وهذا الخطّاف الأخير خصوصاً يستخدم نمطاً تتقارب فيه الكلفة إلى صفر إن غاب العلَم، ويشغّل العمل الثقيل فقط عند وجوده. وإطلاق العمل المكلف فقط بعد دور مُنتِج، لا في كل دور، محوريٌّ في التحكّم بكلفة أنبوب ذاتي.

3. الوكلاء الفرعيون: تفويض خبير معزول

الوكلاء الفرعيون مساعدون معزولون لمهام محدّدة. تعرّفهم كملفات markdown تحت .claude/agents/، محدّداً النموذج المستخدَم ونطاق الوصول للأدوات إلى جانب اسم ووصف. يمكن للوكيل الرئيسي بناء الواجهة الأمامية بينما يقيم وكيل فرعي واجهة API الخلفية بالتوازي. العزل مهمّ لسببين: يركّز الوكيل الفرعي على مهمته وحدها دون تلويث السياق الرئيسي، ويعيد ملخّص نتيجته فقط.

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

ولأضِف انضباطاً واحداً: قبل دمج نتائج توسّع (fanout) الوكلاء الفرعيين، يجب إغلاق الحلقة بمرحلة تحقّق. فإن أطلقت عدة وكلاء متوازين، شغّل تحقّقاً خصومياً مرةً واحدة بدل دمج النتائج مباشرةً للمستخدم. فتوسّع بلا بوابة تحقّق يراكم الهلوسة.

4. المهارات: خبرة تُحمَّل عند الحاجة فقط

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

يضمّ .claude/skills/ في ThakiCloud 1751 مهارة. عند هذا الحجم، أيّ مهارة تُستدعى ومتى هو ما يحدّد الجودة. لذلك يربط موجِّه الطلبات باللغة الطبيعية بمرشّحي المهارات عبر بحث معجمي من صنف BM25 ويطفو المرشّحين الأعلى فقط إلى السياق. فبتجاوز 1700 مهارة، لا يستطيع إنسان انتقاء كلٍّ منها، فمن دون خطوة تضييق المرشّحين هذه يصبح نظام المهارات نفسه ضجيجاً. المهارة ليست موجَّهاً بل منتَج قدرة مُدار الإصدارات، يتمايز عن الموجَّه العادي بأنه يُعاد استخدامه عبر تجهيزات متعددة.

دلالات لـ ThakiCloud

هذا الموضوع هو تنسيق الوكلاء بعينه، فعدسة Paxis تناسب مباشرةً. Paxis هو مستوى التحكّم Agent-Native Cloud لدى ThakiCloud، يعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. وتتطابق المحاور الأربعة أعلاه واحداً لواحد مع القدرات التي يهدف Paxis لتوفيرها على مستوى المنتج. يتطابق التنفيذ الرأسي مع تشغيلات غير مراقَبة مجدولة بـ NL Cron، والخطّافات مع بوابات السياسة وسجلّات التدقيق، والوكلاء الفرعيون مع تنسيق DAG متعدّد الوكلاء، والمهارات مع Skill Harness الذي يختار بين أكثر من 960 مهارة عبر BM25.

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

على جانب البنية التحتية، تناسب عدسة ai-platform أيضاً. فالمشغّلات الرأسية وتوسّع الوكلاء الفرعيين هي في النهاية أحمال تعمل على K8s، واستدعاءات haiku وsonnet وopus المدفوعة بتوجيه النموذج تتحوّل إلى كلفة خدمة. ولا تصمد اقتصاديات تشغيل الوكلاء الذاتيين باستمرار (Paxis) إلا مع أساس خدمة منخفض الكلفة (ai-platform).

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

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

ثانياً، تصميم الخطّافات والتوجيه السيّئ يجعل كلفة كل دور تنمو خطياً. فإن تضخّمت القواعد المحمّلة دائماً، أو وضعت عمل الاستطلاع (polling) في حلقة الوكيل الساخنة، تعود الذاتية انفجاراً في الكلفة. المراقبة المتكرّرة مكانها cron لا الوكيل، كمبدأ.

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

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

المصادر

• Enabling Claude Code to work more autonomously (Anthropic)
• How we built Claude Code auto mode (Anthropic Engineering)
• Steering Claude Code: skills, hooks, rules, subagents and more (مدوّنة Claude)
• claude-code-action (GitHub, Anthropic)

عند تصفح أخبار هذا الصباح، يتضح أن الذكاء الاصطناعي يكبر في اتجاهين في آن واحد. الاتجاه الأول هو الرؤية الأفضل. كشفت Ant Group عن نموذج رؤية من الجيل التالي يتعرف على أسطح كانت نماذج الرؤية السابقة تفوّتها، مثل الزجاج والأسطح العاكسة، وتزعم أن نموذجها المكوّن من 1.1 مليار معلمة يتفوق على نماذج من فئة 7 مليارات معلمة. الاتجاه الثاني هو الحركة الأكبر. أطلقت الحكومة والقطاع الخاص استثمارا مشتركا بقيمة 20 تريليون وون في الذكاء الاصطناعي الفيزيائي الكوري (K-Physical AI)، وأسست مدينة أولسان تحالفا صناعيا للذكاء الاصطناعي، بينما تنتقل شركة RealWorld، وهي شركة ناشئة لنماذج أساسية في الروبوتات، إلى مرحلة التسويق التجاري بعد استقطاب قيادي استراتيجي عالمي جاء من AWS.

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

نشرة اليوم تحمل نوعين مختلفين من “السجلات”

تحمل النشرة الواحدة نوعين مختلفين من السجلات. ما يتناوله نموذج الرؤية من Ant Group هو سجل الإدراك، أي مدى دقة رؤيته للعالم وفهمه للفراغ. أما سجلات الأفعال التي تناولها تقرير “تشغيل الذكاء الاصطناعي” في صحيفة IT Chosun فهي مختلفة في طبيعتها. الأمر يتعلق بحفظ تدفق التنفيذ بأكمله: أي أدوات استدعاها الوكيل، وأي صلاحيات مارسها، وماذا غيّر ذلك في النتيجة.

من دون النوع الأول من السجلات، يصبح الذكاء الاصطناعي غبيا. ومن دون النوع الثاني، لا يُتبنى الذكاء الاصطناعي أصلا. هذا الفرق مهم، لأن الأداء يُثبت عبر المعايير القياسية، بينما تُثبت الثقة عبر السجلات. وكما أشار التقرير، تعزز منصات المراقبة في الخارج مثل Datadog قدرتها على تتبع استدعاءات أدوات الوكيل واستجاباته كتدفق تنفيذ واحد، بينما تتجه أدوات مثل AgentOps وArize وLangSmith نحو دمج التتبع والتقييم وحواجز الحوكمة معا. هذا مؤشر على أن سوق قابلية المراقبة يعيد تشكيل نفسه بسرعة من أدوات مراقبة الأداء التقليدية (APM) إلى أدوات مخصصة للوكلاء.

النماذج تتجه نحو المجانية، والسؤال المتبقي هو “التشغيل”

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

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

البنية التحتية تُبنى، لكن الحسم يقع فوقها

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

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

كلما اتسعت قاعدة التبني، اتسع معها مطلب التدقيق

تبرز اليوم أيضا عدة أخبار تبنٍّ محلية. تدفع LG CNS بأعمالها في المالية والذكاء الاصطناعي الفيزيائي إلى الأمام، بينما استضافت Krafton بالشراكة مع CJ Olive Young هاكاثون “الأصيل في الذكاء الاصطناعي”، فتشاركت صناعتان مختلفتان تماما، الألعاب والتجزئة، ثقافة تطوير واحدة للذكاء الاصطناعي. واستحوذت Daekyo CNS على شركة الشبكات والأمن Handreamnet، موسّعة محفظتها التقنية لتجمع الذكاء الاصطناعي والأمن معا.

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

التنظيم يفرض تسريع هذا المسار

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

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

كلما كان الذكاء الاصطناعي أكثر فيزيائية، أصبح الدليل شرطا لا خيارا

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

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

موقف ThakiCloud: إمكانية التدقيق كإعداد افتراضي

هذه النقطة بالتحديد هي ما دفع ThakiCloud إلى تصميم Paxis. Paxis منتج متكامل يتبنى مفهوم Agent-Native Cloud، ويتعامل مع Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. لا يتوقف الأمر عند تحديد ما يُطلب من الوكيل فعله (Skills) وأي أدوات تُمنح له (Tools)، بل يضع ما لا يجوز للوكيل فعله (Policies) وما فعله فعلا (Audit Logs) على المستوى المعماري نفسه. هذا يعني تضمين تتبع تدفق التنفيذ، الذي طالب به تقرير IT Chosun اليوم من مسار القرار وترتيب استدعاء الأدوات وسجل ممارسة الصلاحيات، كسلوك افتراضي للمنصة، لا كلوحة تحكم تُضاف لاحقا.

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

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

تتقارب أربعة آلام برزت من أخبار مختلفة، التدقيق والسيادة والتنفيذ الآمن واستقرار التكلفة، في ميدان التبني الفعلي ضمن طبقة تشغيل واحدة تحمل اسم Paxis.

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

المصادر

• 앤트그룹, ‘유리’까지 인식하는 차세대 비전 AI 공개…12개 벤치마크서 SOTA · AI타임스
• 산업 하프타임 ⑩ 中 ‘3개월 1만 대’ 물량…’K-피지컬 AI’ 민관 20조원 엔진 가동 · 디지털데일리
• 울산, 제조업 AI 전환 시동…민관 AX 협의체 출범 · 부산일보
• 리얼월드, 글로벌 진출 리더로 AWS 출신 ‘카르틱 크리슈나무르티’ 영입 · 로봇신문
• 오픈AI·앤트로픽, 무료 토큰으로 스타트업 쟁탈전 본격화 · ZDNet Korea
• KT, 통신 본업에 AI 성장 더한다…1GW 데이터센터 확장 기대 · 이데일리
• 2026년 1월 시행 앞둔 ‘AI 기본법’…한국, 세계 첫 전면 적용 국가 되나 · MS투데이
• 하나금융, 금융 AI 자체 개발…기업여신·내부통제에 활용 · 디지털데일리
• 네이버클라우드, 미스트랄AI와 제조 특화 소버린 AI ‘동맹’ · ZDNet Korea

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

نظرة عامة

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

مع منتصف عام 2026، بدأ هذا الجدار يتراجع بشكل ملحوظ، وفي صميم هذا التحول يقف Claude Fable 5 من Anthropic. سجّل المطور Viktor Oddy، في دليل عملي منشور بعنوان “Claude Fable 5 Just Changed Web Design Forever!”، العملية كاملة من البداية إلى النهاية، موضحًا كيف يمكن إنتاج موقع ثلاثي الأبعاد وتفاعلي ومزوّد بالحركة من مطالبة واحدة فقط. ثم ظهر لاحقًا في المجتمع معرض مفتوح المصدر يجمع تجارب واجهات مستخدم مبنية بـ Fable 5. يتتبّع هذا المقال هذه الموجة، ويوضّح ما الذي تغيّر فعليًا، وماذا تعنيه بالنسبة لشركة مثل ThakiCloud التي تتعامل مع الوكلاء كبنية تحتية.

الفيديو أعلاه هو الدليل العملي الذي سجّله Viktor Oddy لعملية بناء موقع ويب تفاعلي ثلاثي الأبعاد باستخدام Fable 5.

ما الذي يميّز Fable 5

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

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

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

كيف يُبنى تصميم الويب التفاعلي

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

flowchart TB
    A["مطالبة القصد<br/>(تحديد المزاج والمرجعية والتقنية)"] --> B["توليد المسودة<br/>التخطيط + هيكل المشهد ثلاثي الأبعاد"]
    B --> C["ربط التفاعل<br/>تقدّم التمرير → حالة المشهد"]
    C --> D["التأثيرات البصرية<br/>تظليل GLSL · مواد Three.js"]
    D --> E["مراجعة بشرية<br/>الأداء · إمكانية الوصول · الهوية البصرية"]
    E -->|"تعليمات تعديل"| C
    E -->|"اجتياز"| F["البناء · النشر<br/>React · Tailwind · Three.js"]

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

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

أمثلة واقعية ومعرض مفتوح المصدر

الدليل على أن هذه الموجة ليست تباهيًا فرديًا موجود في المصادر المنشورة. سجّل Viktor Oddy المذكور آنفًا العملية بأكملها في دليله، كما أُتيح في المجتمع معرض مفتوح المصدر pulkitxm/claude-directory الذي يجمع تجارب واجهات مستخدم مبنية بـ Fable 5. يضم هذا المستودع أمثلة لصفحات هبوط وأقسام رئيسية وتظليل GLSL وأنظمة تصميم وحركات ومشاهد ثلاثية الأبعاد، مُنفّذة فوق React وTailwind وThree.js، ويمكن فتح النتائج مباشرة والاطلاع على الشيفرة كاملة. وبما أنه يمكن معاينة كل تجربة في المتصفح مباشرة، فإن السؤال “هل هذا يعمل فعلًا؟” يمكن التحقق منه بالتشغيل الفعلي لا بمجرد لقطة شاشة، وهذا أمر مهم.

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

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

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

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

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

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

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

الاكتفاء بالتفاؤل يُخلّ بالتوازن. لذا نوضّح هنا بعض النقاط المقابلة بجلاء.

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

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

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

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

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

المصادر

• Viktor Oddy، “Claude Fable 5 Just Changed Web Design Forever!” (فيديو ومقال إرشادي)، https://www.youtube.com/watch?v=_JF_s-ZRTyY
• pulkitxm/claude-directory، معرض مفتوح المصدر لتجارب واجهات مستخدم مبنية بـ Fable 5 (React·Tailwind·Three.js·GLSL)، https://github.com/pulkitxm/claude-directory
• “I Built a Cinematic Scroll Website Using Claude Fable 5 and Higgsfield MCP”، Medium، https://medium.com/@info.booststash/i-built-a-cinematic-scroll-website-using-claude-fable-5-and-higgsfield-mcp-72fbcebb8ad1