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

في الثاني والعشرين من يونيو 2026، أطلقت Sakana AI ومقرها طوكيو منتجَها Sakana Fugu مستهدفةً هذا التحول بدقة. Fugu نظام وكلاء متعدد يُنسق نماذج LLM متعددة ديناميكيًا، بينما تظهر للمستخدم على شكل واجهة برمجة نموذج واحد. الجانب اللافت أن Fugu بحد ذاته “نموذج لغوي مُدرَّب على استدعاء نماذج أخرى.” نموذج يقود نماذج.

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

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

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

هذا ممكن لأن Fugu ليس مجموعة قواعد توجيه، بل نموذج لغوي مُدرَّب على التنسيق ذاته. يتخصص Fugu في فهم متى يُفوِّض، وكيف تتواصل الوكلاء، وكيف يُدمج نواتجها في إجابة واحدة موثوقة. يستند هذا النهج إلى ورقتَي بحث نشرتهما Sakana AI في ICLR 2026: TRINITY (arXiv:2512.04695) التي تُقدم منسقًا تطوريًا لنماذج LLM، وConductor (arXiv:2512.04388) التي تدرس تعلُّم تنسيق الوكلاء باللغة الطبيعية.

تفصيل تصميمي يستحق الإشارة: يمكن لـ Fugu استدعاء نُسَخه الخاصة بصورة تكرارية داخل مجموعة الوكلاء. من الخارج تستدعي نموذجًا واحدًا، ومن الداخل منظومة متخصصة منسقة هي التي تؤدي العمل. صُممت مجموعة الوكلاء لتكون قابلة للاستبدال بهدف معلن هو تقليص الاعتماد على مزود بعينه.

البنية المعمارية: نظام بيئي تعاوني خلف واجهة برمجية واحدة

الادعاء المحوري لـ Fugu هو أن “نموذج التنسيق هو الحدود التالية.” منذ تأسيسها، أكدت Sakana AI أن أقوى أنظمة الذكاء الاصطناعي ستكون أنظمة بيئية تعاونية لا نماذج ضخمة معزولة. Fugu هو التجسيد المنتجي لهذا الاعتقاد.

تقنيًا، يعالج Fugu أربع مراحل داخلية ضمن استدعاء واجهة برمجية واحد:

• الاختيار (Selection): يقرأ طبيعة الطلب ويحدد ما إذا كان سيتولاه مباشرة أم يستعين بنماذج متخصصة.
• التفويض (Delegation): يفصل التخطيط عن التنفيذ ويوزع المهام الفرعية على الوكلاء المناسبين.
• التحقق (Verification): يراجع ناتج كل وكيل داخليًا.
• التوليف (Synthesis): يدمج النتائج في إجابة واحدة متسقة.

كل هذا يجري خلف سطر واحد من واجهة برمجية متوافقة مع OpenAI. يتناقض ذلك مع أطر الوكلاء التقليدية التي تُلقي على عاتق المطور تعقيداتٍ من تعريف الرسوم البيانية وتوجيه الرسائل وإدارة الحالة. Fugu محاولة لاستيعاب تلك التعقيدات داخل أوزان النموذج. بالمقارنة مع بنية فرق الوكلاء متعددة الأدوار التي تديرها ThakiCloud فعلًا، يخطو Fugu خطوة إضافية: يجعل المُنسِّق نموذجًا مُدرَّبًا لا شفرة برمجية مكتوبة يدويًا.

تمتلك Sakana AI سوابق تؤيد هذا الاتجاه؛ إذ حل ALE-Agent المنسق البرمجي في المرتبة الحادية والعشرين في مسابقة برمجة شارك فيها ألف خبير بشري. Fugu يمتد من تلك التجربة إلى منتج تنسيق للأغراض العامة.

النموذجان: Fugu وFugu Ultra

عند الإطلاق، يتوفر Fugu بنموذجين مُصمَّمَين لأحجام عمل مختلفة، ويُمكن الوصول إليهما عبر واجهة برمجية واحدة متوافقة مع OpenAI.

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

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

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

كيف تقرأ معايير الأداء

أعلنت Sakana AI أن Fugu Ultra يُجاري نماذج رائدة كـ Fable 5 وMythos Preview من Anthropic في معايير الأداء الصعبة لمجالات الهندسة والعلوم والاستدلال. هذا الادعاء يستوجب قراءة متأنية.

أولًا، جميع نتائج خط الأساس باستثناء نتائج Fugu نفسه مصدرها تقارير مزودي النماذج أنفسهم، لا مقارنة مستقلة خاضعة لشروط موحدة. ثانيًا، أهداف المقارنة – Fable 5 وMythos Preview – غير متاحة للعموم وغير مدرجة في مجموعة وكلاء Fugu. أي أن Fugu يدّعي اقتراب أدائه من نموذجين لا يستدعيهما داخليًا. ثالثًا، استُخدم mini-swe-agent scaffolding في تقييم مهام عائلة SWE، ونوع الـ scaffolding يؤثر تأثيرًا ماديًا في النتائج، فلا يمكن اعتبارها مقارنةً في ظروف متكافئة.

في المرحلة الراهنة، تظل قضية “تكافؤ Fugu Ultra مع النماذج الحدية” ادعاءً قائمًا على تقارير ذاتية. الأرقام التفصيلية مُجمَّعة في التقرير التقني لـ Sakana AI (github.com/SakanaAI/fugu)، لكن ريثما تتراكم عمليات التحقق المستقلة، التمييز بين الأرقام التسويقية والأداء المُتحقَّق منه أمر لازم. لا يستشهد هذا المقال بأرقام فردية غير مُتحقَّق منها، بل يُسجِّل طبيعة الادعاءات فحسب.

الانعكاسات على منصة ThakiCloud للذكاء الاصطناعي وتعلم الآلة على K8s

التساؤلات التي يطرحها Fugu تتقاطع مع استراتيجية منصة ThakiCloud بدقة. تُشغِّل ThakiCloud وكلاء متعددي المستأجرين في بيئات عملاء متنوعة، وتدير سحابة عمليات وكلاء تُسمى Praxis فوق K8s وجدولة GPU القائمة على Kueue وخدمة vLLM. الأطروحة التي يسعى Fugu لإثباتها – أن “طبقة التنسيق نفسها تصبح منتجًا” – تتجه في الاتجاه ذاته الذي نسلكه.

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

من منظور ThakiCloud، يتيح تصميم Fugu استخدامين: الأول هو قيمته بوصفه تطبيقًا مرجعيًا لأنماط التنسيق؛ فبنية التوجيه الديناميكي للنماذج المفتوحة المُستضافة ذاتيًا على K8s – بالجمع بين نماذج البرمجة والاستدلال والتخصص الحقلي حسب طبيعة المهمة – فكرة قابلة للتطبيق مباشرة على عمليات وكلاء Praxis. الثاني هو الامتثال القائم على الاستثناء: إمكانية استثناء وكلاء بعينهم من المجموعة ترتبط بشكل طبيعي بسياسات تقييد النماذج المسموح بها لكل مستأجر في البيئة متعددة المستأجرين.

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

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

Fugu منتج جدير بالاهتمام، لكن منطقه التسويقي يحمل نقاطًا تستحق التدقيق.

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

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

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

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

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

المصادر

• Sakana AI, “Sakana Fugu: One Model to Command Them All”, 2026-06-22, sakana.ai/fugu-release
• Sakana Fugu Technical Report, Fugu Team, Sakana AI, 2026, github.com/SakanaAI/fugu
• Xu et al., “TRINITY: An Evolved LLM Coordinator”, ICLR 2026, arXiv:2512.04695
• Nielsen et al., “Learning to Orchestrate Agents in Natural Language with the Conductor”, ICLR 2026, arXiv:2512.04388
• THE DECODER, “Sakana AI’s Fugu orchestrates multiple LLMs to match Anthropic’s Fable and Mythos benchmarks”, 2026-06-22, the-decoder.com

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

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

يقرأ هذا المقال الشراكة من منظور التقنية التحتية لا ردود فعل سوق الأسهم. يتناول سبب تحوّل الذاكرة إلى ساحة معركة في بنية الذكاء الاصطناعي التحتية، وما يغيره التصميم المشترك للذاكرة والتخزين، والانعكاسات على ThakiCloud بوصفها مشغّلة لمنصة خدمة AI/ML مستندة إلى K8s.

ما الذي جرى

يتضمن صميم الشراكة المُعلَنة ثلاثة محاور.

أولًا، عقد توريد متعدد السنوات. ستوفر Micron لـAnthropic ذاكرة النطاق الترددي العالي (HBM)، وذاكرة DRAM، وأقراص الحالة الصلبة (SSD)، وهي المنتجات الرئيسية لمراكز البيانات. يُعدّ هذا عقدًا طويل الأمد لضمان حجوم توريد مستقرة، لا عملية شراء لمرة واحدة.

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

ثالثًا، الاستثمار الاستراتيجي في حقوق الملكية. ضخّت Micron استثمارًا استراتيجيًا في جولة تمويل Series H لشركة Anthropic، دون الإفصاح عن مبلغ الاستثمار. من خلال هذه الجولة، قُيِّمت Anthropic بنحو 965 مليار دولار [تقديري]، لتصبح أعلى شركة ذكاء اصطناعي خاصة قيمةً، مع مشاركة Samsung وSK hynix وAltimeter Capital وSequoia وAmazon وفقًا للتقارير. يتضمن الاتفاق أيضًا نشر Claude عبر عمليات Micron الداخلية.

ارتفع سهم Micron قرابة 5.5% مباشرة عقب الإعلان. غير أن محور هذا المقال ليس سعر السهم، بل الانعكاسات التقنية التي يحملها هذا التحالف لتصميم بنية الذكاء الاصطناعي التحتية.

لماذا تُعدّ الذاكرة عائق البنية التحتية للذكاء الاصطناعي

يُعدّ الاستدلال في نماذج اللغة الكبيرة عملًا مقيَّدًا بالذاكرة في جوهره. في كل مرة يُولَّد فيها رمز (token)، يجب قراءة المجموعة الكاملة لأوزان النموذج من الذاكرة. مهما بلغت سرعة وحدات المعالجة، فإن GPU ستقف مكتوفة تنتظر البيانات إن لم تُسَدَّ بالأوزان بسرعة كافية. لذا تتحدد إنتاجية الاستدلال في الغالب بعرضة النطاق الترددي للذاكرة لا بطاقة المعالجة.

يتضح التسلسل الهرمي لذاكرة خادم استدلال الذكاء الاصطناعي في المخطط أعلاه.

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

حين توفّر شركة واحدة التسلسل الهرمي بأكمله، يغدو تحسين حركة البيانات عبر كل الطبقات ممكنًا وفق فلسفة تصميم متسقة. كون Micron تغطي HBM وDRAM وSSD هو الأصل الاستراتيجي المحوري في هذه الشراكة.

ما الذي يغيره التصميم المشترك للذاكرة والتخزين

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

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

ثانيًا، تُظهر الشراكة أن بنية الذكاء الاصطناعي التحتية تتجه نحو التكامل الرأسي بصورة متزايدة. إنها إشارة إلى أن شركات الذكاء الاصطناعي الرائدة تسعى إلى تأمين ليس GPU فحسب، بل الذاكرة أيضًا على مستوى سلسلة التوريد ومرحلة التصميم. مشاركة شركات ذاكرة كـSamsung وSK hynix في جولة Series H ذاتها تُقرأ في السياق نفسه. قدرة توريد الذاكرة تتحول إلى جزء من القدرة التنافسية في الذكاء الاصطناعي.

منظور منصة ThakiCloud K8s AI/ML SaaS

هذه صفقة بين شركات كبرى، لكنها تحمل دروسًا مباشرة لـThakiCloud بوصفها مشغّلة لمنصة خدمة AI/ML مستندة إلى K8s.

أولًا، يتأكد من جديد أن الذاكرة هي نقطة الانطلاق لتحسين تكاليف الخدمة. تُشغّل ThakiCloud الاستدلال متعدد المستأجرين فوق جدولة GPU المستندة إلى vLLM وKueue. في هذه البيئة، الرافعة الأكثر فاعلية لزيادة الإنتاجية هي في الغالب استخدام الذاكرة لا المعالجة. إدارة KV cache واستراتيجيات الدفعات وتوزيع النماذج المُعيَّر وفق طاقة HBM هي التقنيات المحورية لمعالجة طلبات متزامنة أكثر على GPU ذاتها. سبب استقطاب تقنيات كـPagedAttention في vLLM للاهتمام يعود في نهاية المطاف إلى كفاءة الذاكرة.

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

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

تحفظات وحجج مضادة

لتجنب الإفراط في تأويل هذه الشراكة، تستحق بعض النقاط الإشارة.

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

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

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

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

المصادر

• Micron Technology, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, investors.micron.com
• Yahoo Finance, “Micron and Anthropic Announce Strategic Agreement to Scale Next-Generation AI Infrastructure”, 2026-06-22, finance.yahoo.com
• Crypto Briefing, “Micron signs supply agreement with Anthropic AI, invests in Series H round”, 2026-06-22, cryptobriefing.com

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

نظرة عامة

تحليل المستندات، أي تحويلها إلى بنية قابلة للقراءة آلياً، بات أكثر أهمية في عصر RAG والعوامل الذكية. فالصفحة الواحدة من PDF قد تجمع نصاً سردياً وجداول ومعادلات ومخططات وتخطيطاً متعدد الأعمدة، وعلى النموذج أن يفك هذا التشابك بترتيب قراءة دقيق حتى تستطيع النماذج اللغوية الكبيرة الاستفادة منه. حتى وقت قريب، كان هذا الميدان حكراً على النماذج متعددة الوسائط العملاقة كـ GPT-4o وGemini 2.5 Pro، أو على أدوات المعالجة الأنبوبية الثقيلة.

PaddleOCR-VL الصادر عن فريق PaddlePaddle (Baidu) يزعزع هذه المعادلة. فنموذجه الأساسي PaddleOCR-VL-0.9B لا يتجاوز 960 مليون معامل، نموذج رؤية-لغة بالغ الصغر، غير أنه يُفيد بأداء متصدر في تحليل المستندات على مستوى الصفحة كاملاً، وكذلك في التعرف على المكونات الفردية. الرخصة Apache-2.0 تتيح الاستخدام التجاري بحرية، ويشهد النموذج إقبالاً واسعاً على Hugging Face إذ تجاوز عدد التنزيلات 120,000 مرة.

في ThakiCloud نشغّل فعلياً بنية تحتية للاستدلال متعدد المستأجرين ومعالجة المستندات على منصة AI/ML SaaS مبنية على Kubernetes. لهذا لم نكتفِ بمراجعة النموذج نظرياً، بل ثبّتناه وأجرينا عليه استدلالاً فعلياً على مستندات تجمع الكورية والإنجليزية والعربية. نوضح هنا ما إذا كان النموذج الصغير جديراً بالاستخدام الفعلي، وأين يناسب منصتنا.

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

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

البنية ثنائية المراحل التي تفصل تحليل التخطيط عن التعرف على المكونات.

المرحلة الأولى، تحليل التخطيط (PP-DocLayoutV2): نموذج خفيف متخصص يرصد المناطق الدلالية في المستند ويصنّفها ويتنبأ بترتيب القراءة. يستخدم RT-DETR للكشف عن الكائنات، وشبكة مؤشر مكوّنة من ست طبقات محوّلة للتنبؤ بترتيب القراءة. بفصل استدلال التخطيط عن نموذج الرؤية-اللغة الثقيل، تحقق النماذج نتائج مستقرة حتى في التخطيطات متعددة الأعمدة.

المرحلة الثانية، التعرف على المكونات (PaddleOCR-VL-0.9B): تتلقى هذه المرحلة المناطق التي رصدتها المرحلة الأولى وتتعرف بدقة على النص والجداول والمعادلات والمخططات. تتبع البنية نمط LLaVA مع مشفّر بصري ذي دقة ديناميكية على غرار NaViT (مُهيَّأ من نموذج الرؤية Keye-VL) لمعالجة الصور بأي دقة دون تشويه. يربط مُسقِط MLP مزدوج الطبقات مع تفعيل GELU (بحجم دمج 2) السمات البصرية بفضاء تضمينات النموذج اللغوي، فيما يعمل المُفكِّك ERNIE-4.5-0.3B المعزز بـ 3D-RoPE مُفكِّكاً. اختيار نموذج لغوي صغير مقصود: كلما صغر المُفكِّك تسارع فك الترميز رمزاً بعد رمز.

تُكمل وحدة مُعالجة لاحقة خفيفة الدورة بدمج مخرجات المرحلتين في Markdown وJSON منظّمَين. يدعم النموذج 109 لغة تشمل الكورية واليابانية والعربية والسيريلية والديفانغاري (الهندية) إضافة إلى الأبجديات اللاتينية.

التثبيت والتكامل

لنُجرِ التثبيت بأنفسنا. البيئة: MacBook بمعالج Apple Silicon (macOS، معالج مركزي فقط، بلا تسريع GPU)، Python 3.12.8. تعمل PaddleOCR-VL فوق منظومة PaddlePaddle، فنثبّت الحزمتين التاليتين:

# التثبيت في البيئة الافتراضية المشتركة (.venv) وفق قواعد python-runtime
VIRTUAL_ENV="$PWD/.venv" uv pip install paddlepaddle paddleocr
# الإصدارات المثبتة: paddlepaddle==3.3.1, paddleocr==3.7.0

عند المحاولة الأولى للاستدلال ظهر الخطأ التالي:

RuntimeError: A dependency error occurred during pipeline creation.
Please refer to the installation documentation to ensure all required dependencies are installed.

يتطلب خط أنابيب PaddleOCR-VL تبعيات إضافية خاصة بتحليل المستندات. حلّينا الأمر بسطر واحد:

VIRTUAL_ENV="$PWD/.venv" uv pip install "paddleocr[doc-parser]"

شيفرة الاستدلال نفسها مختصرة؛ يقوم خط الأنابيب بتنزيل النماذج اللازمة تلقائياً:

from paddleocr import PaddleOCRVL

pipe = PaddleOCRVL()                 # تنزيل النموذج تلقائياً عند الاستدعاء الأول
out = pipe.predict("sample_doc.png") # صورة المستند ← مخرجات منظمة
for res in out:
    res.save_to_markdown(save_path="paddleocr_out")

ثمة نقطة جديرة بالإشارة: اختارت paddleocr==3.7.0 تلقائياً PP-DocLayoutV3 نموذجاً للتخطيط، وPaddleOCR-VL-1.6-0.9B نموذجاً للتعرف. بمعنى أن الحزمة لا تجلب الإصدار الأوّلي الوارد في الورقة البحثية (2510.14528)، بل نموذج 1.6 المحدَّث ونموذج تخطيط أحدث. رقم “96.33% SOTA على OmniDocBench” الذي انتشر على تويتر ينتمي تحديداً إلى PaddleOCR-VL-1.6 (وفق OmniDocBench v1.6)، وهو مختلف عن الأرقام الأولية التي أوردتها الورقة البحثية. سنوضح هذا التمييز لاحقاً.

نتائج التجربة الفعلية

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

• تهيئة النموذج (الاستدعاء الأول، شاملاً التنزيل): 74.7 ثانية
• الاستدلال (predict): 32.65 ثانية / صفحة واحدة
• الوقت الإجمالي (من الاستيراد حتى الحفظ): 137.4 ثانية
• سجل بنية المُفكِّك: GQA (انتباه مجمّع الاستعلامات)، num_heads 16 / num_key_value_heads 2

كانت مخرجات Markdown للتعرف على النحو التالي:

## ThakiCloud Document Intelligence
Kubernetes AI/ML SaaS Platform - Invoice No. 2026-0623
타키클라우드 멀티테넌트 추론 비용 보고서
GPU hours: 1,284 Total: $9,640.00
E = mc^2 sum_{i=1}^{n} x_i

اللافت أن النموذج التقط العنوان الإنجليزي بوصفه ترويساً في Markdown (##)، وتعرّف بدقة على الجملة الكورية “타키클라우드 멀티테넌트 추론 비용 보고서”، وقرأ الأرقام والرموز النقدية ($9,640.00، GPU hours 1,284) دون أخطاء. جودة التعرف على الكورية مستقرة بشكل لافت لنموذج بهذا الحجم.

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

فيما يلي الأرقام التي أوردتها الورقة البحثية من المعايير العامة. المخطط أدناه يعرض مسافات التحرير لعدد من اللغات من مجموع 109 لغة (الأقل كلما كان أفضل):

إبراز الكورية والعربية، وهما السوقان الرئيسيتان لـ ThakiCloud. المصدر: arXiv:2510.14528.

الكورية عند 0.052 والعربية عند 0.122، كلتا اللغتين المستهدفتين تُظهران مسافات تحرير جيدة. على صعيد الأداء الشامل على مستوى الصفحة، تُشير الورقة البحثية إلى أن النموذج حقق 92.86 في المجموع على OmniDocBench v1.5، متفوقاً على MinerU2.5-1.2B (90.67) الذي يليه مباشرة.

نموذج 0.9B يتفوق على نموذج 1.2B في الدرجة الإجمالية. المصدر: arXiv:2510.14528 Table 2.

عند الاستشهاد بالأرقام لا بد من توضيح الإصدار. الورقة البحثية (2510.14528) أفادت بـ 92.86 على OmniDocBench v1.5؛ والإصدار اللاحق PaddleOCR-VL-1.5 أفاد بـ 94.5% على v1.5، فيما أفاد PaddleOCR-VL-1.6 بـ 96.33% على v1.6 كرقم [تقديري] (أرقام الإصدارات اللاحقة مستندة إلى تقارير منفصلة). الرقم 96.33% الذي ظهر على تويتر ينتمي إلى أحدث إصدار 1.6. كذلك تجدر الإشارة إلى أن سرعة الاستدلال المقاسة في الورقة تمت على NVIDIA A100 واحد بمعالجة دُفعية لـ 512 مستنداً باستخدام محركات خدمة عالية الأداء كـ vLLM وSGLang وFastDeploy. قياسنا لـ 32.65 ثانية/صفحة على المعالج المركزي هو رقم مرجعي لبيئة بلا تسريع، ولا يعكس الإنتاجية في بيئة الإنتاج.

دلالات التطبيق على منصة ThakiCloud K8s AI/ML SaaS

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

• خدمة متعددة المستأجرين بتكلفة منخفضة: نموذج 0.9B يعمل على بطاقة GPU واحدة من الفئة الاستهلاكية أو الاقتصادية. نشره فوق جدولة GPU المستندة إلى Kueue ومحركات الخدمة vLLM وSGLang يتيح تشغيل نقاط نهاية منفصلة لتحليل مستندات كل مستأجر بتكلفة معقولة، مع التحكم الكامل في التكلفة عبر الاستدلال ذاتي الاستضافة بدلاً من دفع رسوم رمزية لنموذج ضخم.
• سيادة البيانات والتشغيل المحلي: المستندات كثيراً ما تحوي معلومات حساسة كفواتير وعقود وسجلات طبية ومالية يصعب إرسالها خارجياً. الاستضافة الذاتية لنموذج Apache-2.0 تتيح تقديم استخبارات المستندات دون إرسال البيانات إلى واجهات برمجية خارجية، بما يتوافق مع اشتراطات عزل الشبكة وقيود تصدير البيانات في القطاعات الحكومية والمالية.
• تعدد اللغات يعني ملاءمة السوق: يصدر مدونة ThakiCloud بالكورية والإنجليزية والعربية. من موقعنا المُطِل على السوقين الكوري والشرق أوسطي، معالجة الكورية (0.052) والعربية (0.122) بنموذج واحد بشكل موثوق يترجم مباشرة إلى ميزة تنافسية ويُقلل الحاجة إلى محركات OCR مختلفة لكل سوق.
• طرف المدخلات في خط أنابيب RAG: مخرجات Markdown وJSON المنظّمة تتغذى مباشرة في فهرسة RAG واستدعاءات أدوات الوكلاء. النص المحافظ على تخطيطه وترتيب قراءته يرفع جودة القطع ويُسهم مباشرة في دقة الاسترجاع.

في مرحلة أكثر نضجاً، يمكن فصل نموذج التخطيط من المرحلة الأولى عن نموذج التعرف من المرحلة الثانية كخدمتين مستقلتين: التخطيط على عقد المعالج المركزي، والتعرف بنموذج الرؤية-اللغة على عقد GPU. البنية المنفصلة على مرحلتين تُيسّر جدولة الموارد غير المتجانسة في بيئة Kubernetes.

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

لا يصح الاكتفاء بالإيجابيات. إليك نقاط الضعف بناءً على القياس الفعلي والأدبيات:

• بطء على المعالج المركزي: 32.65 ثانية/صفحة التي قسناها غير مناسبة لمعالجة المستندات بكميات كبيرة. الاستخدام الفعلي يستلزم GPU ومحركات خدمة كـ vLLM وSGLang، وإنتاجيات الورقة المُبهرة تستند إلى بيئة دُفعية على A100.
• تبعيات البنية الثنائية: تحتاج إلى إدارة نموذجَي التخطيط والتعرف معاً، مما يزيد تكلفة النشر وإدارة توافق الإصدارات مقارنة بنموذج واحد. في الواقع تجلب الحزمة بشكل افتراضي PP-DocLayoutV3 + PaddleOCR-VL-1.6، وهذا التوليف قد يتغير بمرور الوقت.
• أرقام SOTA مرتبطة بإصدار محدد: 96.33% هو رقم الإصدار 1.6 على OmniDocBench v1.6، وليس العنوان الرئيسي للورقة الأساسية التي اقترحت 0.9B. الاستشهاد دون توضيح الإصدار والمعيار يُفضي إلى التضليل.
• الاعتماد على جودة المعالجة الأولية: كما أظهر اختبارنا العربي، جودة رسم الصورة ودقتها وتشكيل حروفها تحدد النتيجة. في خطوط الأنابيب الإنتاجية، مرحلة توحيد المدخلات لا تقل أهمية عن اختيار النموذج.
• ضعف التعرف على الجداول: أشارت الورقة البحثية نفسها إلى أن TEDS الخاصة بالجداول الإنجليزية على OmniDocBench v1.0 (88.0) منخفضة نسبياً (مع تفسير بتأثير أخطاء التعليق). المستندات الغنية بالجداول تستلزم تحققاً منفصلاً.

خلاصة القول، PaddleOCR-VL خيار مُغرٍ جداً بوصفه نموذج تحليل مستندات “صغيراً لكن قوياً” لاستخبارات المستندات ذاتية الاستضافة. غير أن استخراج قيمته الحقيقية في الإنتاج يتطلب معالجة ثلاثة تحديات تشغيلية معاً: خدمة GPU، وتثبيت الإصدارات، ومعالجة المدخلات الأولية.

المصادر

• ورقة PaddleOCR-VL البحثية (arXiv:2510.14528): Boosting Multilingual Document Parsing via a 0.9B Ultra-Compact Vision-Language Model
• بطاقة النموذج على Hugging Face: PaddlePaddle/PaddleOCR-VL
• الكود المصدري: github.com/PaddlePaddle/PaddleOCR
• أُجريت التجارب الواردة في هذا المقال على بيئة ThakiCloud (macOS، معالج مركزي) مباشرة، وأرقام المعايير المُستشهد بها مستقاة من الورقة البحثية المذكورة أعلاه.

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

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

ورقة من جامعة نيويورك وبرينستون ومتعاونين بعنوان “Human-like autonomy emerges from self-play and a pinch of human data” (arXiv:2606.19370، يونيو 2026) تقدّم إجابة واضحة. كما يقول العنوان، حفنة تكفي. وعمليًا، فإن 30 دقيقة فقط من بيانات القيادة البشرية، أي أقل بـ 2500 مرة من التعلّم بالتقليد، تُنتج سياسة أكثر توافقًا مع البشر. ويكتمل التدريب بأكمله في 15 ساعة على GPU استهلاكي واحد.

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

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

ما هذا البحث

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

كانت المعالجات السابقة تعني هندسة المكافآت بعناية أو نشر التعشية النطاقية. وكلاهما كثيف العمل وهشّ. تقلب هذه الورقة الفكرة. فبدل استخدام بيانات البشر كإشارة تعلّم رئيسية، تحوّل سياسة مرساة بالاستنساخ السلوكي (BC) إلى حدّ تنظيم. تبقى المكافأة بسيطة ومتفرّقة (+1 لبلوغ الهدف، -1 للاصطدام أو الخروج عن الطريق، و0 فيما عدا ذلك)، ويُضاف حدّ KL نحو سياسة المرساة إلى خسارة PPO. وتتحكّم λ في القوة؛ وحين تكون λ صفرًا يُختزل الأمر إلى self-play صرف دون تنظيم.

البنية الكاملة موضّحة أدناه. محرّك self-play رخيص هو القوة الدافعة الرئيسية، ومرساة بشرية مدتها 30 دقيقة تسحب السياسة بلطف نحو البشر عبر خيط رفيع من تنظيم KL.

يستحق قرار تصميمي واحد التأكيد. فحدّ KL هذا يسحب السياسة نحو المرساة لا على توزيع البيانات المسجّلة دون اتصال (offline) بل على الحالات التي تزورها السياسة فعلًا، وهو تنظيم على المسار (on-policy). فإن نظّمت فقط على توزيع BC غير المتصل، لا تستطيع منع السياسة من الانحراف عن توزيع الحالة في الحلقة المغلقة الذي تراه عمليًا. أما KL على المسار فيستدعي المرساة عند نقطة انزياح التوزيع تلك بالضبط. يبدو الأمر طفيفًا لكنه يحكم استقرار الحلقة المغلقة.

تُدرَّب سياسة المرساة نفسها بالـ BC على مسارات سيارة القيادة الذاتية فقط. فمسارات المركبات المحيطة مُعاد بناؤها بواسطة طبقة إدراك، لذا فهي مشوّشة وجودة قيادتها غير مضمونة؛ ولذا تُستخدم أنظف إشارة فقط، أي مسار المركبة الذاتية. يُنتج كل سيناريو نحو 9 ثوانٍ من البيانات، فتبلغ 200 سيناريو نحو 30 دقيقة. ولادعاء “أقل بـ 2500 مرة” اشتقاق صريح: 200 سيناريو في 9 ثوانٍ تساوي 30 دقيقة، بينما مجموعة Waymo الكاملة بنحو 500,000 سيناريو في 9 ثوانٍ تساوي نحو 75,000 دقيقة، أي نسبة حوالي 0.0004.

المنهجية الأساسية: من إشارة رئيسية إلى مرساة

هيكل المنهجية نظيف. الخسارة هي حدّ تدرّج السياسة المقصوص (clipped surrogate) في PPO مضافًا إليه خسارة القيمة ومكافأة الإنتروبيا، مع حدّ تنظيم KL فوقها. وهو أقرب إلى تركيب دقيق لمكوّنات معروفة جيدًا منه إلى خوارزمية جديدة.

تكمن المساهمة الحقيقية لا في الجدّة الخوارزمية بل في نظافة القياس التي أتاحتها البنية التحتية. وسّع الباحثون خبرة الـ self-play إلى 20 مليار انتقال على المحاكي عالي الإنتاجية GPUDrive، وهو ما يعادل نحو 63 عامًا من القيادة البشرية. كانت الأعمال السابقة مقيّدة بسرعة المحاكي (نحو 2000 خطوة في الثانية) عند 140 مليون انتقال ونحو 5 أيام تدريب، فلم يتبقَّ مجال لدراسة توسيع كمية بيانات البشر كمحور مستقل. وبإزالة عنق زجاجة الإنتاجية عبر GPUDrive، أصبحت تجربة التوسيع المنفصل لـ”كمية الـ self-play” و”كمية بيانات البشر” ممكنة لأول مرة.

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

النتائج التجريبية الفعلية

مجموعة البيانات هي Waymo Open Motion Dataset (WOMD). ولأجل تقييم human-replay الذي يقيس التوافق البشري، تُرشَّح السيناريوهات لرفع إشارة التفاعل. فمن بين 10,000 سيناريو تحقّق محجوزة، يُسجَّل مسار المركبة الذاتية بحسب مقدار تقاطعه مع مسارات الوكلاء الآخرين، مع الإبقاء على أعلى 200 مشهد تفاعلي فقط مثل الاندماج والإفساح والتقاطعات المزدحمة التي تتطلب تنسيقًا حقيقيًا.

تُلخَّص النتائج الأساسية في المخطط أدناه. كل رقم مُبلَّغ عنه في الورقة؛ ولا شيء مُختلَق.

النقاط الأساسية كما يلي.

• يحقّق spiced self-play معدل اصطدام بخطأ ذاتي بين 0.6% و0.7% ببيانات بين 30 دقيقة و3 ساعات. ومقارنة بخط الأساس للتعلّم بالتقليد SMART-tiny-CLSFT (1.6%، مُدرَّب على مجموعة Waymo الكاملة، نحو 52 يومًا من البيانات)، يمثّل ذلك تحسّنًا بنحو 2.5 مرة.
• بلغ معدل الاصطدام بخطأ ذاتي لـ self-play النقي دون تنظيم 2.1%. وإضافة حفنة من المرساة فقط جعلته أكثر أمانًا بنحو 3.5 مرة.
• يتجنّب التقييم التباهي بمقياس واحد. فهو ينظر إلى النتيجة ومعدل الإكمال ومعدل الاصطدام ومعدل الاصطدام بخطأ ذاتي وشدّة الاصطدام Δv عبر ثلاث بيئات: self-play (يتشارك جميع الوكلاء السياسة)، وhuman-replay (المركبة الذاتية فقط هي السياسة، والبقية تعيد تشغيل السجلات)، وIDM (الآخرون قائمون على قواعد وتفاعليون).

يختلف الاتساق الداخلي أيضًا. فيُبقي spiced self-play معدل الاصطدام دون 1.5% في بيئة الـ self-play وفي cross-play مع سجلات البشر، بينما يرتفع خط أساس التعلّم بالتقليد إلى نحو 6% في بيئة الـ self-play، مُظهرًا اتساقًا أضعف. ويوضّح الباحثون أن عدم استقرارية بيئة الـ self-play، أي توزيع شريك متغيّر يتحوّل فيه خصم شبه عشوائي ابتداءً إلى كفء تدريجيًا، تساعد فعلًا على التقارب نحو أعراف متبادلة متّسقة.

لكن ليست كل الصورة وردية. فمقياس Waymo Open Sim Agent Challenge (WOSAC) الميتا للواقعية التوزيعية يرتفع من 0.68 لـ self-play النقي إلى 0.725 للنسخة المُنظَّمة، لكن المكسب صغير نسبةً إلى التحسّن الدرامي في الأمان وغير حسّاس تقريبًا للبيانات المضافة. فقد تكون السياسة آمنة وأقل شبهًا بالبشر توزيعيًا في الوقت ذاته، وهي نقطة نعود إليها أدناه.

التطبيق على منصّة ThakiCloud للـ AI/ML SaaS على K8s

القيادة بحد ذاتها ليست مجال ThakiCloud المباشر. ومع ذلك تنتقل الدروس المنهجية لهذه الورقة بشكل شبه مباشر إلى بنيتنا متعددة الوكلاء والتعلّم المعزّز والمحاذاة.

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

ثانيًا، فكرة تنظيم KL على المسار لها إمكان قوي للدمج مع بوّابة التحقّق fan-out لدينا. فيمكننا إطلاق عمّال كثيرين بحرية كالـ self-play، ثم تثبيتهم بمجموعة صغيرة من المسارات الذهبية المعتمدة بشريًا تحت تنظيم KL لكبح الانحراف نحو أعراف غريبة مثل الهلوسة أو انحراف التنسيق. والمفتاح هو تطبيق التنظيم لا على مجموعة ذهبية ثابتة غير متصلة بل على الحالات التي يزورها العمّال فعلًا، وهي بنية تستحق إثبات مفهوم على منصّتنا.

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

أخيرًا، ثمة نقطة فخر واضحة. فبنية تكلفة قوامها 15 ساعة على GPU استهلاكي واحد تشير إلى الاتجاه ذاته الذي أكّدته ThakiCloud: التشغيل في الموقع وكفاءة التكلفة والاستضافة الذاتية. وهذا يعني أن تجارب المحاذاة كهذه يمكن إعادة إنتاجها وتشغيلها بتكلفة معقولة على مكدّس K8s لدينا، بجدولة وحدات GPU عبر Kueue والخدمة عبر vLLM، دون خط أنابيب ضخم لبيانات البشر.

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

إنه عمل علمي تجريبي رصين، لكن بقراءة نقدية تبقى ثلاثة توتّرات.

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

ثانيًا، عدم التماثل بين مكاسب الواقعية التوزيعية ومكاسب الأمان غير مُفسَّر بالكامل. فانتقال مقياس WOSAC الميتا من 0.68 إلى 0.725 متواضع بجانب التحسّن الكبير في معدل الاصطدام، وهو غير حسّاس لمزيد من البيانات. فقد تكون السياسة آمنة وأقل شبهًا بالبشر توزيعيًا، وهو ما يتوتّر مع العنوان القوي “human-like autonomy emerges”. وعدم مواجهة المتن لهذه الفجوة مباشرة يترك مجالًا للمبالغة في الادعاء.

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

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

المصادر

• الورقة: Human-like autonomy emerges from self-play and a pinch of human data (arXiv:2606.19370)، https://arxiv.org/abs/2606.19370
• Hugging Face Papers: https://hf.co/papers/2606.19370
• صفحة المشروع (مقاطع فيديو والمصدر الكامل): https://spiced-self-play.com/

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

نظرة عامة

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

تدير ThakiCloud منصة AI/ML SaaS قائمة على Kubernetes تخدم أعباء عمل الوكلاء لعملاء متعددين في آنٍ واحد. مبدأ “تعاون وكلاء متعددين لإنتاج مخرجات قابلة للتحقق” ليس شأناً غريباً عنا. هذه المقالة توثيق لتجربة دمج تلك الحزمة فعلياً في بيئة وكلاءنا وفحص بنيتها. لسنا هنا للتقديم التسويقي، بل لنرى ما بداخلها، وما يمكن الوثوق به، وما هو مفيد فعلاً من منظور منصتنا.

ما هذه الحزمة؟

Academic Research Skills مجموعة مهارات غير تجارية لـ Claude Code، تجمع سير عمل البحث والكتابة والتحقق والمراجعة والتدقيق وسلامة الاستشهادات في مهارات ووكلاء وبوابات متسلسلة. جوهرها ليس موجهاً واحداً، بل تعاون وكلاء متخصصين متعددين وبوابات تحقق إلزامية بين كل مرحلة. تتوزع الحزمة على أربع مهارات رئيسية.

• deep-research (الإصدار 2.9.4): فريق بحثي مكوَّن من 13 وكيلاً يتناول أي موضوع. يدعم 7 أوضاع: البحث الكامل، الملخص السريع، مراجعة ورقة بحثية، مراجعة الأدبيات، التحقق من الحقائق، الحوار التوجيهي السقراطي، والمراجعة المنهجية مع التحليل التلوي. تتوزع الأدوار على صياغة أسئلة البحث وتصميم المنهجية والبحث المنهجي في الأدبيات والتحقق من المصادر والتوليف المتقاطع وتقييم مخاطر التحيز وكتابة التقارير وفق APA 7.0 والمراجعة التحريرية وتقديم الحجج المضادة.
• academic-paper: خط أنابيب كتابة يُنتج ورقة بحثية فعلية من نتائج البحث. يقبل ملف تعريف الأسلوب ويُطبِّقه، ويُجري فحص جودة الكتابة قبيل الصياغة مباشرةً لرصد العبارات المُبالَغ في استخدامها والتكرار في طول الجمل والمقدمات الحشوية.
• academic-paper-reviewer: يؤدي دور المحكِّم الذي يُقيِّم المخطوطة المكتملة.
• academic-pipeline (الإصدار 3.11.1): المنسِّق الذي يجمع الثلاثة معاً. لا يُنجز عملاً بنفسه، بل يتولى فقط اكتشاف المراحل والتوصية بالأوضاع وإيفاد المهارات وتتبع الحالة. قائد رفيع بلا حجم.

المراحل العشر التي يربطها المنسِّق:

[1] RESEARCH (البحث)
      |
[2] WRITE (الكتابة)
      |
[2.5] INTEGRITY <- بوابة التحقق 100% من الاستشهادات والبيانات
      |
[3] REVIEW (المراجعة الأولى للأقران)
      |
[4] REVISE (المراجعة)
      |
[4.5] RE-REVIEW (المراجعة الثانية المركّزة)
      |
[5] RE-REVISE (إعادة التنقيح)
      |
[5.5] FINAL INTEGRITY (إعادة التحقق النهائي)
      |
[6] FINALIZE (PDF مع سجل المصدر)

ثمة قراران تصميميان يستأثران باهتمامنا في ThakiCloud. الأول أن كلتا المهارتين الأساسيتين تُصرِّح صراحةً بـ data_access_level: verified_only في بياناتهما الوصفية. والثاني وجود بوابة تحقق إلزامية بين كل مرحلة. لا تُستحضر الادعاءات حول الأدبيات من ذاكرة النموذج، بل تُقابَل مع قاعدة بيانات أوراق بحثية فعلية عبر Semantic Scholar API. بدلاً من صياغة استشهادات تبدو منطقية، تُوقف البوابة أي استشهاد غير موجود.

التثبيت والدمج

جرى التثبيت باستنساخ المستودع الخارجي وربطه بدليل .claude/skills/ لدينا عبر وصلات رمزية. بدلاً من نسخة مستقلة، نتابع المصدر ليصلنا التحديثات الأعلى تلقائياً.

# استنساخ المستودع الخارجي (الدليل الرئيسي)
git clone https://github.com/Imbad0202/academic-research-skills.git ~/academic-research-skills

# الربط بدليل مهارات الوكلاء لدينا
cd .claude/skills
ln -s ~/academic-research-skills/deep-research            deep-research
ln -s ~/academic-research-skills/academic-paper           academic-paper
ln -s ~/academic-research-skills/academic-paper-reviewer  academic-paper-reviewer
ln -s ~/academic-research-skills/academic-pipeline        academic-pipeline

بعد الربط تظهر المهارات الأربع كوصلات رمزية:

academic-paper          -> ~/academic-research-skills/academic-paper
academic-paper-reviewer -> ~/academic-research-skills/academic-paper-reviewer
academic-pipeline       -> ~/academic-research-skills/academic-pipeline
deep-research           -> ~/academic-research-skills/deep-research

داخل ThakiCloud، وصّلنا هذه المهارات الأربع بخط أنابيب البحث والتقارير الخاص بنا (عائلة jarvis)، بحيث تستدعي المدخلات ذات الطابع البحثي وضع مراجعة الأوراق أو مراجعة الأدبيات في deep-research. مخرج “الورقة البحثية الكاملة (DOCX)” المرفق بمقالات تصنيف الأوراق البحثية في مدونتنا يستند إلى الفلسفة ذاتها القائمة على التحقق أولاً.

ما بداخل الحزمة فعلاً

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

academic-pipeline/agents/
+-- pipeline_orchestrator_agent.md      # إدارة التبديل بين المراحل والإيفاد
+-- state_tracker_agent.md              # تتبع حالة التقدم ونقاط التفتيش
+-- integrity_verification_agent.md     # التحقق من سلامة الاستشهادات والبيانات
+-- collaboration_depth_agent.md        # تسجيل عمق التعاون البشري-الذكاء الاصطناعي
+-- claim_ref_alignment_audit_agent.md  # تدقيق توافق الادعاء مع المرجع (L3)

تبرز عدة ضمانات لافتة.

• مرحلتا التحقق من السلامة (2.5 و5.5): تُتحقَّق الاستشهادات والبيانات بنسبة 100% مرتين: مرة بعد الكتابة وقبل تقديم المراجعة، ومرة بعد اكتمال التنقيح. الفشل في هذه البوابة يمنع الانتقال إلى المرحلة التالية.
• تدقيق توافق الادعاء مع المرجع (L3): تفعيل العلم ARS_CLAIM_AUDIT=1 يُضيف بوابة تدقيق أمانة الادعاء عند الانتقال من المرحلة 4 إلى 5. تجمع الادعاءات غير المدعومة والانحراف في الادعاءات وانتهاكات القيود وتصنِّفها، وإذا ارتفعت درجة المخاطر ترفض الأداة إنتاج المخرجات. معطَّل افتراضياً وصُمِّم للتفعيل التدريجي مع تراكم بيانات المعايرة.
• جواز المواد (Material Passport): تفعيل ARS_PASSPORT_RESET=1 يرفع نقاط تفتيش المراحل إلى حدود إعادة ضبط السياق. في جلسة جديدة يمكن الاستئناف من مرحلة مسجَّلة باستخدام resume_from_passport=<hash>. آلية عملية لتقطيع المهام الطويلة عند حدود المراحل تجنُّباً لتضخم نوافذ السياق.
• PDF سجل المصدر: بعد اكتمال الخط ينتج تلقائياً مستند يوثِّق كيفية التعاون بين الإنسان والذكاء الاصطناعي. يجعل ذلك تتبع “مدى تدخل الذكاء الاصطناعي” أمراً ممكناً من منظور النزاهة الأكاديمية.

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

التطبيق على منصة ThakiCloud K8s AI/ML SaaS والدلالات

ما لفت انتباهنا أكثر عند دمج هذه الحزمة هو تطابقها الدقيق مع مبدأين نؤكد عليهما في تصميم منصتنا.

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

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

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

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

تصميم جيد، لكنه لا يُقبَل بلا تمحيص. ثمة قيود واضحة.

• بوابات التحقق لها ثمن. تشغيل التحقق من السلامة مرتين عبر 10 مراحل، مع تدقيق اختياري للادعاءات، يُضيف رمزاً ووقتاً كبيرَين لكل مخرج. للحالات التي تستدعي مسودة سريعة، هذا إفراط. لذلك يوجد وضع الملخص السريع بشكل منفصل، وإلزام الخط الكامل في كل مهمة ليس حكيماً.
• التحقق عبر Semantic Scholar ليس شاملاً. أحدث الأوراق التي لم تُفهرَس بعد، والأدبيات غير الإنجليزية، والأدبيات الرمادية قد تقع خارج نطاق التحقق. “محقَّق” لا يضمن الدقة 100%.
• الرخصة غير التجارية مناسبة للتجريب الداخلي لكنها تستلزم مراجعة قانونية قبل التضمين في منتج. إن كان إعادة التوزيع التجاري هو الهدف، لا يمكن استخدامها كما هي.
• عدد الوكلاء لا يتناسب طرديًا مع الجودة. أرقام كـ 13 أو 12 وكيلاً مثيرة للإعجاب، لكن السؤال الجوهري هو ما إذا كان كل وكيل يُضيف تحققاً فعلياً من منظور مختلف. تشغيل الموجِّه ذاته مراراً ليس تحققاً. هذه الحزمة تفصل الأدوار بوضوح وهذا جيد، لكن من يعتمدها ينبغي أن يُقيِّمها بمعيار “تنوع التحقق” لا “عدد الوكلاء.”

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

المصادر

• Academic Research Skills (GitHub): github.com/Imbad0202/academic-research-skills
• تغريدة التعريف الأصلية (عبر @XAMTO_AI): x.com/hjguyhan/status/2069051203229802756
• الإصدارات المثبَّتة: deep-research 2.9.4, academic-pipeline 3.11.1 (فحص محلي بتاريخ 2026-06-23)

نظرة عامة

طالما تطلّب إنتاج الفيديو محرّرات مخصّصة ولمسة بشرية. لكن مؤخرًا ترسّخ نمط حيث يُوصَف الفيديو بالشيفرة ويُعرَض، تمامًا كما تكتب وكلاء البرمجة الشيفرة. يضع digitalsamba/claude-code-video-toolkit هذا النمط فوق Claude Code. عند إصداره يُظهر نحو 1.6 ألف نجمة على GitHub و268 تفريعة و182 إيداعًا، برخصة MIT.

الفكرة الأساسية بسيطة. تصف مشروع فيديو باستخدام Remotion، وهو إطار قائم على React؛ وتفوّض توليد الأصول مثل الصوت والصور والموسيقى ولقطات الـ b-roll إلى نماذج ذكاء اصطناعي مفتوحة المصدر؛ وتربط العملية كلها بأوامر الشرطة المائلة ومهارات Claude Code. ينشئ المستخدم مشروعًا من قالب بأمر /video واحد، ويهيّئ وحدة GPU السحابية والتخزين والصوت بأمر /setup، ثم ينتقل إلى العرض.

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

ما هذه الأداة

تحوّل claude-code-video-toolkit بيئة Claude Code إلى محطة عمل لإنتاج الفيديو. من المفيد فهمها في ثلاث طبقات.

الأولى هي طبقة أوامر الشرطة المائلة. يرشدك /setup تفاعليًا عبر التهيئة الأولى مثل GPU السحابية ونقل الملفات والصوت. ينشئ /video المشاريع ويفتحها، ويساعد /scene-review في المراجعة مشهدًا مشهدًا داخل Remotion Studio. وإلى جانب ذلك توجد أوامر لكل مرحلة من مراحل الإنتاج: /brand و/template و/generate-voiceover و/voice-clone و/redub و/record-demo و/publish وغيرها. يرفع /publish الفيديو المكتمل إلى YouTube ويملأ البيانات الوصفية تلقائيًا من project.json.

الثانية هي طبقة المهارات. تجمّع هذه المعرفة المجالية كي يتعامل معها Claude Code بعمق: remotion (إطار فيديو قائم على React)، وelevenlabs (الصوت)، وffmpeg (معالجة الوسائط)، وplaywright-recording (تسجيل العروض في المتصفح)، وfrontend-design (التصميم البصري)، وqwen-edit (تحرير الصور)، وideogram4 (توليد صور بنص داخلي قوي)، وacestep (الموسيقى)، وltx2 (مقاطع فيديو مدفوعة بالنص والصورة)، وmoviepy (تركيب فيديو بلغة بايثون)، وrunpod (وحدة GPU سحابية)، بإجمالي إحدى عشرة مهارة.

الثالثة هي طبقة القوالب والعلامة التجارية. يتضمّن templates/ قوالب sprint-review وsprint-review-v2 وproduct-demo وconcept-explainer-short للمقاطع العمودية بنسبة 9:16. ويعرّف brands/ ملفات علامة تجارية تحمل الألوان والخطوط وإعدادات الصوت، وتُطبَّق تلقائيًا عند إنشاء مشروع بأمر /video. يوضّح المخطط أدناه كيف تتصل هذه الطبقات الثلاث في خط إنتاج واحد.

flowchart LR
  A["موجّه / سكربت"] --> B["أمر /video"]
  B --> C["ملف العلامة التجارية<br/>brand.json · voice.json"]
  C --> D["تركيبة Remotion<br/>فيديو React"]
  D --> E["طبقة مهارات الذكاء الاصطناعي"]
  E --> E1["Qwen3-TTS<br/>صوت · استنساخ"]
  E --> E2["FLUX.2 · Ideogram4<br/>صور · بطاقات عناوين"]
  E --> E3["ACE-Step<br/>موسيقى"]
  E --> E4["LTX-2<br/>b-roll"]
  D --> F["remotion render<br/>h264 · 1080p · 6x"]
  F --> G["out/video.mp4"]
  G --> H["/publish → YouTube"]

تبرز بنية التكلفة على نحو خاص. صُمّمت الأداة كي تعتمد الأصول التوليدية مثل الصوت (Qwen3-TTS) والصور (FLUX.2) والموسيقى (ACE-Step) على نماذج مفتوحة المصدر بدلًا من واجهات API تجارية. تنشر النماذج على حساب GPU السحابي الخاص بك وتشغّلها بسعر التكلفة. للتخزين تشير إلى الطبقة المجانية من Cloudflare R2 (10 غيغابايت، دون رسوم خروج)، وللحوسبة إلى خطة Modal Starter برصيد مجاني 30 دولارًا شهريًا. هذا الخيار القائم على الاستضافة الذاتية يتطابق تمامًا مع منظور المنصة الذي سنناقشه لاحقًا.

التثبيت والتكامل

البدء السريع الموثّق كالتالي: استنساخ المستودع، وتثبيت اعتماديات بايثون اختياريًا، وفتح Claude Code.

git clone https://github.com/digitalsamba/claude-code-video-toolkit.git
cd claude-code-video-toolkit
python3 -m pip install -r tools/requirements.txt   # اختياري: التعليق الصوتي وتوليد الصور والموسيقى وأمثلة moviepy
claude                                              # تشغيل Claude Code داخل الأداة

ثم داخل Claude Code، تهيّئ GPU السحابية والتخزين والصوت تفاعليًا لنحو خمس دقائق بأمر /setup، وتنشئ مشروعك الأول بأمر /video. المتطلبات هي Node.js 18+ وClaude Code؛ ويُنصح ببايثون 3.9+ لأدوات الذكاء الاصطناعي. أما FFmpeg فاختياري.

الأهم هنا أن ثمة مسارًا منفصلًا للتحقق من العرض فورًا دون أي تهيئة. examples/hello-world مثال مصغّر لا يحتاج أي مفاتيح API. اتّبعت هذا المسار بالضبط وشغّلته فعليًا.

cd examples/hello-world
npm install
npm run render

بالنظر إلى package.json الخاص بـ hello-world، يكون سكربت العرض npx remotion render src/index.ts SprintReview out/video.mp4، والاعتماديات هي إصدار Remotion 4.0.425 وReact 18. أي إنه يحوّل تركيبة React مباشرة إلى فيديو دون أي استدعاءات نماذج خارجية.

نتائج التجربة الفعلية

أجريت التحقق داخل شجرة عمل git معزولة، وكل رقم مأخوذ مباشرة من سجل التشغيل. كانت البيئة Apple Silicon (arm64) وNode.js 24.1.0 وnpm 11.3.0.

أولًا، تثبيت الاعتماديات. أضاف npm install نحو 230 حزمة واستغرق قرابة 3.5 ثانية. لكن التدقيق أبلغ عن 10 ثغرات (7 متوسطة و3 عالية)، وهو ما أعود إليه في قسم القيود.

في خطوة العرض، ينزّل Remotion مرة واحدة عند التشغيل الأول Chrome Headless Shell. في هذا التشغيل نزّل نحو 90.2 ميجابايت، وهي تكلفة لمرة واحدة. ثم تلت ذلك عملية التجميع والتركيب. كانت التركيبة SprintReview، والترميز h264، والتزامن 6x، وعرض كامل الإطارات البالغة 750 إطارًا. ترك السجل الملاحظة “Cached bundle. Subsequent renders will be faster”، موضحًا أن عمليات العرض اللاحقة أسرع بفضل ذاكرة التجميع المؤقتة.

من حالة باردة، بلغ الزمن الفعلي لأمر npm run render، شاملًا التنزيل والتجميع والعرض والترميز، 18.4 ثانية. كان الناتج النهائي فيديو h264 بدقة 1920x1080 و30 إطارًا في الثانية وطول 25.0 ثانية وحجم 2.15 ميجابايت (2,152,829 بايت)، متضمنًا مسار صوت AAC. لم يُستخدم أي مفتاح API على الإطلاق.

الزمن الفعلي لكل مرحلة في خط عرض hello-world بدقة 1080p، مقاسًا دون أي مفاتيح API.

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

التطبيق على منصة ThakiCloud السحابية للذكاء الاصطناعي على Kubernetes

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

النقاط الجديرة بالإبراز هي التكلفة والاستضافة الذاتية. صُمّمت الأداة لتشغيل نماذج مفتوحة الأوزان مثل Qwen3-TTS وFLUX.2 وACE-Step على وحدة GPU الخاصة بك بسعر التكلفة بدلًا من واجهات API تجارية. يتوافق هذا تمامًا مع توجّه ThakiCloud في اعتبار التشغيل المحلي والاستضافة الذاتية نقاط قوة. حين يرغب عميل في تشغيل أحمال توليدية متعددة المستأجرين في بيئة عالية الأمان دون إرسال بيانات أو نماذج إلى الخارج، يمكن لمنصتنا أن تستوعب بطبيعتها خط إنتاج الفيديو والوسائط هذا أيضًا.

زاوية الاستخدام الداخلي واضحة كذلك. قالبا sprint-review وproduct-demo من المخرجات التي تنتجها فرق الهندسة بشكل متكرر. وإذا غلّفت هذا التوليد للفيديو كمهام Kubernetes ووضعتها في طابور Kueue، أمكنك نقل العرض الثقيل من حواسيب المطورين المحمولة إلى مجمّع GPU مشترك يُعالج بحسب الأولوية. كون الأداة نفسها مرتبطة بـ Claude Code قيدٌ، لكن فصل مرحلة عرض Remotion وحدها وتحويلها إلى حاوية يجعل وضعها على بنيتنا الدفعية أمرًا مباشرًا.

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

ثمة نقاط ضعف واضحة إلى جانب نقاط القوة. أولًا، أمان الاعتماديات. حتى npm install للمثال المصغّر أبلغ عن 10 ثغرات (منها 3 عالية). لطرحها في الإنتاج تحتاج أولًا إلى تدقيق الاعتماديات وتثبيتها، والأأمن فرض ذلك كبوابة في خط الأتمتة لديك.

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

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

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

خلاصة القول، يُعدّ claude-code-video-toolkit نقطة انطلاق جيدة لأتمتة الفيديو الصديقة للشيفرة. تجربة إنتاج فيديو 1080p خلال 30 ثانية دون مفاتيح API نقطة قوة واضحة، وفلسفته القائمة على النماذج مفتوحة المصدر والاستضافة الذاتية تتوافق جيدًا مع توجّه منصتنا. ومع ذلك، تحتاج إلى موازنة التكلفة الحقيقية لمرحلة الأصول التوليدية وأمان الاعتماديات والارتباط بالأداة معًا للوصول إلى حكم متوازن.

المصادر

• GitHub: digitalsamba/claude-code-video-toolkit
• Remotion: remotion.dev
• بيئة الاختبار: Apple Silicon (arm64)، Node.js 24.1.0، npm 11.3.0 / جميع الأرقام مستخرجة مباشرة من سجلات التشغيل.

انتشر مؤخرًا اقتباس بسرعة في مجتمعات المطورين: يُقال إن مبتكر Claude Code صرّح بأن “Fable 5 صار يكتب 100% من شيفرتي، وهو أقوى من Opus بثلاثة أضعاف على الأقل.” بمفردها، جملة كهذه أقرب إلى ادعاء تسويقي يصعب التحقق منه. لذلك يفصل هذا المقال أمرين عن قصد: ما هو مؤكَّد رسميًا، وتحليل كيف تُغيِّر هذه الحقائق المؤكَّدة طريقة عمل فرق الهندسة فعليًا.

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

نفصل الحقائق المؤكَّدة عن الاقتباس

أولًا، يبقى الرقمان “100%” و”ثلاثة أضعاف” اقتباسًا فحسب. فالمصدر تصريح فردي، وطريقة القياس غير معلنة. لا نتعامل مع هذه الأرقام بوصفها حقيقة في المتن.

أما ما تؤكده الوثائق العامة فهو الآتي. إن Claude Fable 5 هو أقدر نموذج متقدم متاح للعموم تطرحه Anthropic، وقد أُعلن في يونيو 2026 إلى جانب نموذج Claude Mythos 5 محدود الإصدار. معرّف النموذج هو claude-fable-5. التسعير 10 دولارات لكل مليون رمز إدخال و50 دولارًا لكل مليون رمز إخراج، أي نحو ضعف سعر Opus 4.8. المعالجة الدُّفعية بنصف ذلك عند 5 دولارات للإدخال و25 دولارًا للإخراج، ويهبط الإدخال عند إصابة ذاكرة التخزين المؤقت للموجِّهات إلى دولار واحد لكل مليون رمز. نافذة السياق مليون رمز افتراضيًا، مع إخراج يصل إلى 128 ألف رمز لكل طلب.

أما من حيث الأداء، فادعاء الشركة المعلن هو أنه في معيار تحليلي أساسي يقيس المهام التحليلية المعقدة طويلة الأمد، صار أول من يتجاوز 90%، بتحسُّن نحو 10 نقاط على Opus [تقدير: وفق إعلان الشركة]. كما أوضح فريق Claude Code أنه لأن Fable 5 يعمل لفترة أطول ويتحقق من نفسه وينتج شيفرة أعلى جودة، فإن دور الإنسان ينتقل من “مراقبة ما إذا كان يؤدي العمل بشكل صحيح” إلى “توجيه ما إذا كان يؤدي العمل الصحيح”. هذه الجملة الأخيرة هي في الواقع أهم نقطة في هذا المقال.

ما الذي يختلف في البرمجة الوكيلية

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

[ الإنسان: يحدد النية/الهدف ]
        |
        v
[ الوكيل: يضع خطة ] ---> [ يكتب الشيفرة ] ---> [ اختبار/تشغيل ]
        ^                                            |
        |                                            v
[ الإنسان: مراجعة الاتجاه (توجيه) ] <--- [ حلقة تحقق/إصلاح ذاتي ]
                                              |
                                              v
                                   [ تقديم التغيير عند النجاح ]

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

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

ماذا يعني “كتابة الذكاء الاصطناعي 100% من الشيفرة” لفريق

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

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

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

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

تطبيقه على منصة ThakiCloud السحابية على Kubernetes

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

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

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

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

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

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

لتجنّب قبول هذا الاتجاه دون نقد، نذكر الحجج المضادة بوضوح.

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

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

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

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

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

المصادر

• Anthropic، صفحة “Claude Fable” الرسمية: https://www.anthropic.com/claude/fable
• Anthropic، “Introducing Claude Fable 5 and Claude Mythos 5” (وثائق Claude API): https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
• Anthropic، تسعير Claude API: https://platform.claude.com/docs/en/about-claude/pricing
• ClaudeDevs، “Claude Fable 5 is here … get started in Claude Code”: https://x.com/ClaudeDevs/status/2064394919549210774

نظرة عامة

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

Hermes Bible (hermesbible.com) موقع مجتمعي غير رسمي يواجه هذه المشكلة مباشرة. يفهرس كل صفحة من وثائق Hermes Agent الرسمية إلى جانب سير عمل واقعية بناها المجتمع في مكان واحد، ويوفّر بحثًا نصيًا كاملًا بضغطة مفتاح واحدة. ويذكر الموقع نفسه بوضوح أنه “غير رسمي، من بناء المجتمع، وغير تابع لـ Nous Research”.

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

ما هذا الموقع

الوظيفة الأساسية لـ Hermes Bible هي الفهرسة والبحث. يحتوي الموقع على 169 صفحة من وثائق Hermes Agent مقسّمة إلى 10 أقسام: Getting Started (6 صفحات تشمل التثبيت والبدء السريع ومسار التعلّم)، وCore Features (45 صفحة تشمل نظرة عامة على الميزات والأدوات ونظام المهارات والمنسّق)، وMessaging Platforms (30 صفحة تشمل بوابة المراسلة وتيليجرام وديسكورد وسلاك)، وSecrets (صفحتان)، وSkills، وUsing Hermes (15 صفحة تشمل CLI وTUI والإعداد وتهيئة النماذج)، وغيرها.

يُستدعى البحث بضغطة ⌘K، وهو بحث نصي كامل غامض يمسح كل عنوان صفحة وقسم وترويسة. ووفقًا للموقع تظهر النتائج فور الكتابة دون تحميل أو انتظار. والهدف هو تجربة العثور على الموضع الدقيق في وثائق ضخمة خلال ثوانٍ بكلمة مفتاحية واحدة. يوضّح المخطط أدناه كيف يوحّد الموقع الوثائق الرسمية وسير عمل المجتمع في سطح بحث واحد.

flowchart LR
  A["وثائق Hermes Agent الرسمية<br/>169 صفحة · 10 أقسام"] --> C["Hermes Bible<br/>فهرس نصي كامل (غير رسمي)"]
  B["سير عمل المجتمع<br/>28 سير عمل واقعي"] --> C
  C --> D["بحث نصي كامل غامض ⌘K<br/>عناوين · أقسام · ترويسات"]
  D --> E["نتائج فورية فور الكتابة<br/>دون تحميل"]
  C --> F["تصفّح /docs<br/>10 أقسام"]
  C --> G["/flows<br/>البنى · اقتصاد الرموز"]

عامل التمييز هو مكتبة Flows. فإلى جانب الوثائق الرسمية، تجمع 28 سير عمل واقعيًا لأتمتة متعددة الوكلاء بناها المجتمع فعلًا. ويُنظَّم كل سير عمل بحيث يمكنك البحث فيه ودراسته وتكييفه، شاملًا البنية الكاملة واقتصاد الرموز وأنماط التنسيق. فمثلًا تقدّم إحدى المقالات لوحة Hermes (localhost:9119) التي “لا يتحدث عنها أحد لكنني أفتحها كل يوم” بوصفها سطح تشغيل للحفاظ على صحة وكيل يعمل على مدار الساعة، وتغطي Sessions وMCP وSkills وCron وAnalytics وLogs وSystem. وأخرى بعنوان “المستويات الخمسة عشر لاستخدام Hermes Agent” تعرض كل شيء من أول موجّه بضربة واحدة إلى أتمتة عمل تجاري عبر ملفات متعددة، مع اقتصاد الرموز، وتذكر أنها جرى التحقق منها مقابل Hermes Agent v0.17.0.

للمرجع، Hermes Agent نفسه مشروع برخصة MIT من Nous Research، يُظهر نحو 200 ألف نجمة على GitHub و35.7 ألف تفريعة وأكثر من 12 ألف إيداع حتى كتابة هذه السطور. ويعلن عن “حلقة تعلّم مغلقة” يصنع فيها الوكيل مهارات من التجربة ويحسّنها أثناء الاستخدام ويبني نموذجًا للمستخدم عبر الجلسات. ويمكن النظر إلى Hermes Bible بوصفه استجابة المجتمع لمواكبة هذا المشروع السريع التطوّر.

انعكاسات من منظور منصة ThakiCloud

النظر إلى Hermes Bible لا كموقع بحث فحسب بل كنمط يجعله درسًا مباشرًا لنا. تشغّل ThakiCloud داخليًا أكثر من 1000 مهارة وقاعدة تشغيل، وهي بالضبط المشكلة نفسها لـ “قابلية بحث المعرفة الهائلة” التي تواجهها وثائق Hermes Agent. وفي الواقع تمتلك منصتنا بالفعل بوابة بحث مهارات قائمة على BM25 تُبرز المرشحين في كل دورة عمل. ويوضّح بحث ⌘K النصي الفوري في Hermes Bible جيدًا، من جانب تجربة المستخدم، الطرح نفسه القائل إنه “كلما نمت المعرفة، صار البحث إنتاجية”.

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

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

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

أوضح القيود أنه غير رسمي. فـ Hermes Bible مشروع مجتمعي غير تابع لـ Nous Research، لذا لا ضمان بأن المحتوى المفهرس يطابق دائمًا أحدث الوثائق الرسمية. وHermes Agent مشروع سريع الحركة بأكثر من 12 ألف إيداع. والفهرس غير الرسمي يتأخّر بطبيعته، وخاصة في مجالات مثل الإعداد الحسّاس أمنيًا أو إدارة الأسرار يجب أن تعامل الوثائق الرسمية بوصفها المرجع النهائي.

ثانيًا، عليك مراعاة أن الوثائق الرسمية توفّر بالفعل نقاط دخول صديقة للآلة. إذ تقدّم وثائق Hermes Agent الرسمية ملف /llms.txt (نحو 17 كيلوبايت) الذي يفهرس كل صفحة بوصف قصير، وملف /llms-full.txt (نحو 1.8 ميجابايت) الذي يدمج كل شيء في ملف واحد. ولتحميل الوثائق دفعةً واحدة في نموذج لغوي كبير، يكون هذا المسار الرسمي أكثر موثوقية واستقرارًا. أي إن قوة Hermes Bible تكمن خالصةً في تجربة بحث الإنسان بسرعة وتصفّح سير عمل المجتمع.

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

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

المصادر

• Hermes Bible: hermesbible.com
• Hermes Agent (Nous Research): github.com/NousResearch/hermes-agent
• الوثائق الرسمية: hermes-agent.nousresearch.com/docs

نظرة عامة

حين تقرر تقديم LLM، السؤال الأول الذي تطرحه عادةً هو “أي محرك استدلال أستخدم؟” تصطف الأسماء: vLLM وSGLang وTensorRT-LLM وllama.cpp، وتبدأ مقارنة جداول المعايير. مؤخراً أشار مهندس إلى أن هذا السؤال بحد ذاته يأتي بترتيب خاطئ، فاستقطب الملاحظة اهتماماً. الحجة الجوهرية بسيطة: “لا تختر محرك استدلال، بل استراتيجية أجهزة؛ والمحرك ينبثق منها.”

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

الحجة الأساسية: اختر استراتيجية أجهزة لا محركاً

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

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

خريطة الأجهزة إلى المحركات

ورقة الغش التي قدَّمها المنشور الأصلي ترسم المحركات على حالات الأجهزة. الخلاصة:

الأجهزة / الحالة                                المحرك المناسب
------------------------------------------------------------
CPU، Mac، حافة، بيئة غير مألوفة، VRAM منخفض  -> llama.cpp (GGUF، إلغاء تحميل هجين)
  مع RAM كافٍ في النظام
سير عمل مرتكز على Mac (Apple Silicon)          -> MLX
GPU مستهلك 1-4 بطاقات RTX                       -> ExLlamaV2 / ExLlamaV3
تقديم إنتاجي عام                                -> vLLM
بنية تحتية معقدة، سياق طويل، MoE              -> SGLang (RadixAttention)
أقصى أداء على NVIDIA                            -> TensorRT-LLM (محرك مُصرَّف)

مزيد من التفصيل في طبيعة كل محرك:

• llama.cpp: يعمل في أي مكان تقريباً. قوي حين يكون VRAM محدوداً والـ RAM متوفراً، محققاً التكميم GGUF وإلغاء التحميل الهجين. مناسب للتجارب الشخصية وأجهزة الحافة وأجهزة الكمبيوتر المحمولة.
• MLX: محسَّن لـ Apple Silicon. الخيار الطبيعي لسير العمل المرتكز على Mac.
• ExLlamaV2/V3: متخصص في تشغيل النماذج المكمَّمة بكفاءة على بطاقة إلى أربع بطاقات GPU للمستهلكين.
• vLLM: أوسع تغطية للأجهزة والنماذج مع أداء قابل للتنبؤ. المرشح الافتراضي للتقديم الإنتاجي العام.
• SGLang: قوي للطلبات المتزامنة العالية والسياق الطويل وأعباء عمل MoE عبر RadixAttention وجدولة الاستدعاءات المتعددة. يأتي بتعقيد بنية تحتية أعلى.
• TensorRT-LLM: يُحقق أعلى إنتاجية خام عبر مسار المحرك المُصرَّف على NVIDIA. يأتي بتعقيد تشغيلي كبير.

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

لماذا هذا الترتيب صحيح

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

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

التطبيق على منصة ThakiCloud K8s AI/ML SaaS والدلالات

يتطابق هذا الإطار تقريباً مع فلسفة ThakiCloud في عمليات التقديم. نجمع GPU في مجمَّعات على Kubernetes ونُدير قوائم الانتظار والجدولة بـ Kueue، ونُقدِّم أعباء عمل الاستدلال في إعداد متعدد المستأجرين. في هذه البيئة، تتجسد “استراتيجية الأجهزة أولاً” على النحو التالي.

• شكل مجمَّع GPU يحدد المحركات المرشحة. أنواع GPU وطبولوجيا مجمَّعات العقد لدينا هي استراتيجية الأجهزة. في حالتنا الأساسية المتمثلة في التقديم للأغراض العامة لعدة مستأجرين على GPU من مستوى مراكز البيانات بـ NVIDIA، يُشكِّل vLLM بتغطيته الواسعة وأدائه القابل للتنبؤ الخيار الافتراضي الطبيعي. لذا نبدأ بـ vLLM عند تهيئة نموذج جديد.
• شكل عبء العمل يقود التفريع. حين يميل عبء عمل مستأجر بعينه نحو السياق الطويل أو MoE أو التزامن العالي، تكتسب خصائص مثل RadixAttention في SGLang معنىً. في المقابل، لخدمة شديدة الحساسية للكمون مع أجهزة ونموذج ثابتَين، نقيِّم حينئذٍ مسار TensorRT-LLM المُصرَّف. النقطة الجوهرية أن هذا التفريع يستند إلى عناق زجاجة مقيَّسة لا إلى تخمين.
• ينطبق مباشرةً على النشر المحلي والاستضافة الذاتية. للمؤسسات العامة والجامعات والعملاء الماليين الذين لا يستطيعون الاعتماد على واجهات API خارجية، “ما الأجهزة المتاحة؟” يحدد كل شيء. مطابقة المحرك مع جيل GPU المتاح وعددها، ثم تحسين التكلفة لكل وحدة إنتاجية داخل بنيتهم التحتية الخاصة، هو التمييز بعينه. التفكير بمنطق الأجهزة أولاً أقوى ما يكون في البيئات المقيَّدة.

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

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

هذا الإطار ليس حلاً شاملاً. ثمة نقاط تستحق التأمل.

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

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

المصادر

• التغريدة الأصلية (@TheAhmadOsman): x.com/TheAhmadOsman/status/2051779046468673986
• تغريدة المشاركة (عبر @hjguyhan): x.com/hjguyhan/status/2069049583276298276
• تحليلات مقارنة تكميلية: vLLM vs SGLang vs TensorRT-LLM vs Ollama (LeetLLM, 2026), Best LLM Inference Engines 2026 (Yotta Labs)

For much of the past several years, AI progress has been driven by scale: train bigger models on more data, and compete on monolith benchmarks. But the hard problems of the real world demand a breadth of knowledge and skill that far exceeds any single benchmark score. The ability to judge which model fits which task, to divide planning from execution, and to combine the strengths of different models – collective intelligence – is emerging as the next axis of competition.

On June 22, 2026, Tokyo-based Sakana AI launched Sakana Fugu, a product aimed squarely at this shift. Fugu is a multi-agent system that dynamically coordinates multiple LLMs while presenting a single model API to the caller. What makes it notable is that Fugu itself is “a language model trained to call other models.” A model commands models.

This post analyzes Fugu’s architecture from the perspective of ThakiCloud, an operator of multi-tenant agent platforms. We examine why packaging orchestration inside a single model is a meaningful design choice, how to read the self-reported benchmarks, and what contradictions lurk in the product’s marketing claim that it reduces vendor lock-in.

What This Technology Is

Sakana Fugu is a multi-agent system that behaves like a single model. When a user sends a request to a single endpoint, Fugu decides how to handle it. Simple requests it handles directly; more complex tasks it routes to a coordinated team of specialist models. Model selection, delegation, verification, and synthesis all happen internally, so the complexity of a multi-agent system never surfaces in user code.

This is possible because Fugu is not a set of routing rules but a language model trained on orchestration itself. Fugu is specialized to understand when to delegate, how agents should communicate, and how to synthesize their outputs into a single trustworthy answer. The approach draws on two Sakana AI papers accepted at ICLR 2026: TRINITY (arXiv:2512.04695), which introduces an evolved LLM coordinator, and Conductor (arXiv:2512.04388), which studies learning to orchestrate agents in natural language.

One design detail worth noting: Fugu can recursively call its own instances within the agent pool. From the outside, you are calling one model; from the inside, a coordinated system of specialists is doing the work. The agent pool is designed to be swappable, with the stated goal of reducing dependence on any single provider.

Architecture: A Collaborative Ecosystem Behind a Single API

Fugu’s central claim is that “the orchestration model is the next frontier.” Since its founding, Sakana AI has argued that the most capable AI systems will be collaborative ecosystems, not isolated giant models. Fugu is the product manifestation of that belief.

Technically, Fugu handles four internal stages within a single API call:

• Selection: It reads the nature of the request and decides whether to handle it directly or which specialist models to engage.
• Delegation: It separates planning from execution and distributes sub-tasks to the appropriate agents.
• Verification: It checks each agent’s output internally.
• Synthesis: It combines the results into a single coherent answer.

All of this happens behind one line of OpenAI-compatible API. This contrasts with conventional multi-agent frameworks, which push complexity – graph definitions, message routing, state management – onto the developer. Fugu is an attempt to absorb that complexity into the model weights themselves. Compared to the multi-persona agent team structure ThakiCloud already operates, Fugu takes one step further: it makes the orchestrator a trained model rather than hand-written code.

Sakana AI has prior evidence for this direction. ALE-Agent, a coding orchestrator, placed 21st in a coding competition among 1,000 human experts. Fugu extends that experience into a general-purpose orchestration product.

Two Variants: Fugu and Fugu Ultra

At launch, Fugu is available in two variants sized for different workloads. Both are accessed through a single OpenAI-compatible API.

Fugu (standard) balances performance with low latency. It is a sensible default for interactive services such as coding assistance, code review, and chatbots. Teams with data, privacy, or compliance requirements can exclude specific agents from the pool. This opt-out capability is meaningful for regulated industries and customers with data-sovereignty requirements.

Fugu Ultra is tuned to maximize answer quality on difficult, multi-step problems. It draws on a deeper pool of specialist agents when accuracy and depth matter most. Early users have reportedly put Fugu Ultra to work on high-demand tasks such as AI research, paper reproduction, cybersecurity analysis, and literature and patent search.

The separation of these two variants is essentially a mechanism for exposing the cost-quality trade-off to the user. Orchestration inherently involves multiple model calls, so engaging a deeper pool drives up both latency and cost. Fugu surfaces that trade-off as two product lines.

How to Read the Benchmarks

Sakana AI announced that Fugu Ultra performs “shoulder-to-shoulder” with leading models such as Anthropic’s Fable 5 and Mythos Preview on challenging engineering, science, and reasoning benchmarks. That claim requires careful reading.

First, every baseline score other than Fugu’s own numbers comes from the respective model provider’s self-reports. This is not an independently controlled apples-to-apples comparison; it is a collection of self-announced figures. Second, the comparison targets – Fable 5 and Mythos Preview – are not publicly available and are not included in Fugu’s agent pool. Fugu is claiming near-parity with models it does not internally call. Third, the SWE-family tasks were scored using mini-swe-agent scaffolding. The choice of scaffolding materially affects results, so these cannot be treated as equivalent conditions.

At this point, the proposition that “Fugu Ultra is on par with frontier models” should be treated as a self-reported claim. The specific figures are compiled in Sakana AI’s technical report (github.com/SakanaAI/fugu), but until independent third-party verification accumulates, distinguishing marketing numbers from validated performance is prudent. This post does not cite individual unverified scores; it records only the nature of the claims.

Implications for ThakiCloud’s K8s AI/ML SaaS Platform

The questions Fugu raises map precisely onto ThakiCloud’s platform strategy. ThakiCloud operates multi-tenant agents across diverse customer environments, running an agent operations cloud called Praxis on top of K8s, Kueue-based GPU scheduling, and vLLM serving. The thesis Fugu is trying to prove – that “the orchestration layer itself becomes the product” – is the same direction we are already pursuing.

The core is hedging vendor lock-in. Sakana AI cited the risk of dependence on a single provider as the justification for launching Fugu. As the export-control episode around Anthropic’s Fable and Mythos models illustrated, regulatory boundaries or diplomatic policy shifts can change access to a specific API overnight. In critical sectors such as government, finance, and infrastructure, depending on a single company’s API is a real vulnerability. This logic is the same reason ThakiCloud has emphasized on-premises and self-hosting.

From ThakiCloud’s perspective, Fugu’s design offers two uses. First, it is valuable as a reference implementation of orchestration patterns. The structure of dynamically routing self-hosted open models on K8s – combining coding, reasoning, and domain-specialized models by task type – is an idea that maps directly onto Praxis agent operations. Second, opt-out-based compliance: the ability to exclude specific agents from the pool connects naturally to policies that restrict the set of permitted models per tenant in a multi-tenant environment.

Where ThakiCloud can differentiate from Fugu is clear, however. Fugu is a closed API; ThakiCloud offers a path to self-hosting the orchestration layer inside the customer’s own environment. For domestic customers that must address sovereignty, cost efficiency, and national-security requirements, the option to “put the orchestration inside our own cluster” is a decisive difference. Fine-tuning an open model at the level of Qwen3 for a specific domain, then self-hosting the orchestration layer on top of it, can deliver strong competitiveness at lower serving cost.

Limits and Counterarguments

Fugu is an interesting product, but its marketing logic has several points worth scrutinizing.

The biggest contradiction is that it creates a new dependency while claiming to reduce vendor lock-in. Fugu is a closed commercial API; it is not open-weight. A product launched on the logic that single-provider dependence is dangerous in turn requires dependence on a new single provider: Sakana AI. The fact that Fugu is not available in the EU/EEA at launch also demonstrates that this product, too, is subject to regulation and regional policy. Genuine vendor-lock-in hedging is only possible with self-hostable orchestration.

Second, cost and latency are unpredictable. A structure in which a model calls other models – and sometimes itself recursively – makes it hard to forecast how many model calls a single request will trigger internally. Modes like Fugu Ultra that engage deeper pools can deliver higher quality, but cost and latency may spike accordingly. For production teams managing SLAs and budgets, controlling this unpredictability is the key challenge.

Third, verification and debugging are harder. The fact that the internal delegation path is embedded in model weights is an advantage for ease of use, but it means that when a wrong answer appears, tracing which agent’s judgment caused the problem is difficult. In operational environments where observability matters, this opacity is a liability.

Fourth, as noted earlier, the performance claims are still at the self-reported stage. The comparison targets are non-public models not included in the pool, and the baselines are provider self-reports. Reserving judgment until independent reproduction and verification accumulate is the rational response.

Despite these reservations, the question Fugu raises – “Can orchestration be a learned capability rather than hand-written code?” – is one every multi-agent platform operator will have to face. ThakiCloud intends to answer that question with self-hostable, observable orchestration as its differentiator.

Sources

• Sakana AI, “Sakana Fugu: One Model to Command Them All”, 2026-06-22, sakana.ai/fugu-release
• Sakana Fugu Technical Report, Fugu Team, Sakana AI, 2026, github.com/SakanaAI/fugu
• Xu et al., “TRINITY: An Evolved LLM Coordinator”, ICLR 2026, arXiv:2512.04695
• Nielsen et al., “Learning to Orchestrate Agents in Natural Language with the Conductor”, ICLR 2026, arXiv:2512.04388
• THE DECODER, “Sakana AI’s Fugu orchestrates multiple LLMs to match Anthropic’s Fable and Mythos benchmarks”, 2026-06-22, the-decoder.com