نظرة عامة

يقوم هذا المشروع على ملاحظات تعليمية نشرها الأستاذ بنغ سيدا (彭思达) من جامعة تشجيانغ الصينية في مستودع learning_research، ويُعيد صياغة خبرة كتابة الأوراق البحثية في هيئة حزمة Agent Skill. وفق وصف المستودع، يركز المشروع على أوراق ML وCV وNLP، وقد مرّ بعمليات تنظيم وهيكلة تستهدف Codex وClaude Code وGemini. الإسهام الجوهري ليس نسخ نص الملاحظات الأصلية، بل تفكيك النصائح المتناثرة إلى وحدات عمل يمكن للوكيل استدعاؤها باعتبارها قدرات قابلة لإعادة الاستخدام.

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

ما هو Agent Skill؟

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

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

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

استعراض Research-Paper-Writing-Skills

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

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

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

التثبيت والاستخدام

نموذج تثبيت Agent Skill بسيط في مجمله. تنزّل الحزمة وتضعها في مسار الـ Skill الذي تتعرف عليه الأداة، فيستدعي الوكيل الـ Skill المناسب بحسب المهمة. التدفق العام كالتالي:

# استنساخ المستودع
git clone https://github.com/Master-cai/Research-Paper-Writing-Skills.git

# نسخه إلى مجلد Skill الخاص بأداتك (راجع توثيق كل أداة للمسار الصحيح)
# مثال: وضعه تحت .claude/skills/ في مشروع Claude Code
cp -r Research-Paper-Writing-Skills/<skill-dir> .claude/skills/

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

التطبيق والدلالات في منصة ThakiCloud للذكاء الاصطناعي على Kubernetes

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

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

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

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

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

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

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

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

المصادر

• Research-Paper-Writing-Skills: https://github.com/Master-cai/Research-Paper-Writing-Skills
• ملاحظات المؤلف الأصلية learning_research (بنغ سيدا): https://github.com/pengsida/learning_research

بالنسبة لأي فريق يحاول خدمة نموذج استدلال من الطراز الرائد على بنيته التحتية الخاصة، فإن أول جدار يصطدم به هو ذاكرة وحدة معالجة الرسوميات (GPU). تحميل 753 مليار معامل بدقة 16 بت يتطلب ما يقارب 1.5 تيرابايت، أي عدة عُقد GPU. نموذج nvidia/GLM-5.2-NVFP4، الذي صدر على Hugging Face في 25 يونيو 2026، يكمّم نموذج GLM-5.2 من ZAI (zai-org) إلى 4 بت في محاولة لخفض هذا الجدار.

هذه المقالة ليست تعريفاً بنموذج GLM-5.2 نفسه. كيف يعيد طول رموز الاستدلال في النموذج تشكيل حسابات تكلفة الاستضافة الذاتية مشروح في مقالة اقتصاديات رموز الاستدلال، وتكميم GGUF بدقة 1 بت للعتاد الاستهلاكي في مقالة Unsloth GGUF. هذه المقالة تنظر إلى مسار مركز البيانات: ما البنية التي اختارها تكميم NVFP4 الرسمي من NVIDIA، وعلى أي عتاد يُخدَم، وماذا يعني ذلك لمشغّل يدير خدمة متعددة المستأجرين.

كل رقم دقة هنا هو قياس رسمي منشور في بطاقة نموذج NVIDIA. النموذج بحجم 753B مخصص لـ Blackwell فقط ويتطلب توازياً موتّرياً بمقدار 8، لذا لم نتمكن من إعادة إنتاجه في بيئة تطوير ThakiCloud. لذلك فهذه المقالة تحليل مبني على مواد عامة ولم نختلق أي أرقام إعادة إنتاج. الأرقام التي تختلف بين المصادر مُعلَّمة بـ [تقديري].

نظرة عامة

nvidia/GLM-5.2-NVFP4 هو نسخة من zai-org/GLM-5.2 لـ ZAI مكمَّمة بأداة NVIDIA Model Optimizer (ModelOpt). النموذج الأساس هو بنية مزيج خبراء (MoE) للاستدلال والبرمجة، بإجمالي 753 مليار معامل يُفعَّل منها 40 مليار فقط لكل رمز. بنيته الشبكية هي GlmMoeDsaForCausalLM، ويستخدم انتباهاً متناثراً مع مُفهرِس IndexShare لدعم سياق يصل إلى مليون رمز. الترخيص هو MIT، مثل النموذج الأساس، ويتيح الاستخدام التجاري وغير التجاري.

جوهر الأمر في جملة واحدة: MoE يقلّل الحوسبة، والتكميم الانتقائي بـ NVFP4 يقلّل الذاكرة، والأجزاء الحسّاسة للدقة تُستثنى عمداً من التكميم. بفضل بنية MoE، حتى عند 753B تظل الحوسبة لكل رمز محصورة في خبراء الـ 40B المفعَّلين. ثم يُنزِل NVFP4 أوزان الخبراء الموجَّهين، التي تشكّل معظم بصمة الذاكرة، من 16 بت إلى 4 بت، مع إبقاء الخبير المشترك غير مكمَّم بدقة BF16 لتقليل خسارة الدقة.

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

ما هو هذا النموذج

GLM-5.2 هو نموذج استدلال وبرمجة من نوع MoE من ZAI. على عكس النموذج الكثيف (dense) التقليدي، يضع عدة شبكات خبراء داخل كل كتلة محوِّل ويفعّل مجموعة فرعية فقط لكل رمز إدخال. يحمل GLM-5.2 إجمالي 753 مليار معامل، لكن 40 مليار فقط تشارك فعلياً في توليد رمز معيّن. “سعته المعرفية” من فئة 753B، بينما حوسبة الاستدلال أقرب إلى نموذج كثيف بحجم 40B.

علاوة على ذلك، يستخدم GLM-5.2 انتباهاً متناثراً مع مُفهرِس IndexShare. التصميم يدعم سياق مليون رمز مع تجنّب تكلفة الانتباه الكامل الذي يقارن كل زوج رموز. تسمّي بطاقة النموذج هذه البنية glm_moe_dsa وتتطلب transformers>=5.3.0 للتشغيل. هاتان الطبقتان من التناثر، تناثر MoE وتناثر الانتباه، تتكاملان لتقديم استدلال من الطراز الرائد بحوسبة اقتصادية نسبياً، وهذه نقطة انطلاق GLM-5.2.

NVFP4 هو نوع بيانات عائم بدقة 4 بت عرّفته NVIDIA. المفتاح أنه عائم وليس عدداً صحيحاً بـ 4 بت. على وجه التحديد، يحزم قيماً عائمة صغيرة (E2M1) في كتل من 16 عنصراً ويرفق بكل كتلة مقياس FP8 (E4M3)، وهو تحجيم على مستوى الكتل بمرحلتين. لأن كل كتلة تتتبّع مداها الديناميكي الخاص، يحافظ على أذيال التوزيع أفضل بكثير من التكميم الصحيح البسيط. تذكر NVIDIA بوضوح في بطاقة النموذج أن هذا ليس نموذجاً درّبته من الصفر بل نسخة مكمَّمة من نموذج طرف ثالث، أُنتجت بأداة NVIDIA Model Optimizer مفتوحة المصدر.

المفتاح هو التكميم “الانتقائي”

تُكمَّم فقط المعاملات الخطية لخبراء MoE الموجَّهين إلى NVFP4؛ ويبقى الخبير المشترك والانتباه بدقة BF16.

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

• مكمَّم إلى NVFP4 (4 بت): أوزان وتنشيطات المعاملات الخطية لخبراء MoE الموجَّهين. بما أن هنا تعيش معظم معاملات الـ 753B، يأتي تقريباً كل توفير الذاكرة من هنا.
• محفوظ بدقة BF16 (16 بت): الخبير المشترك، ومسار الانتباه المتناثر IndexShare. هذه يعبرها كل رمز، فلها أثر كبير على الدقة.

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

استخدمت المعايرة (calibration) مجموعات بيانات عائلة Nemotron من NVIDIA. تسمّي بطاقة النموذج Nemotron-SFT-Instruction-Following-Chat-v2 وNemotron-Science-v1 وNemotron-Competitive-Programming-v1 وNemotron-SFT-Agentic-v2 وNemotron-Math-v2 وNemotron-SFT-SWE-v2 وNemotron-SFT-Multilingual-v1 كبيانات معايرة. المزيج يشمل الاستدلال والعلوم والبرمجة والوكلاء والرياضيات ومتعدد اللغات، بما يتماشى مع طبيعة معايير التقييم.

القياسات المنشورة: الدقة مقابل FP8

قياسات عامة من بطاقة نموذج nvidia/GLM-5.2-NVFP4. خط الأساس هو GLM-5.2-FP8.

المقارنة التي نشرتها NVIDIA في بطاقة النموذج أدناه. اللافت أن خط الأساس ليس BF16 بل GLM-5.2-FP8 المضغوط أصلاً. أي أن هذا هو السؤال الأصعب: “كم يخسر 4 بت مقارنة بنموذج خُفِّض أصلاً إلى 8 بت”، بدلاً من “مقارنة بالأصل غير المضغوط”.

كانت إعدادات القياس درجة حرارة 1.0 وtop_p 0.95، بحد أقصى للرموز الجديدة 100000 لـ GPQA Diamond و64000 للبقية. قِيس AA-LCR بـ SGLang؛ والبقية بـ vLLM. المعايير الخمسة تقيّم على التوالي الاستدلال العلمي بمستوى الدراسات العليا (GPQA Diamond، 448 سؤالاً)، والبرمجة العلمية (SciCode)، واتّباع التعليمات (IFBench)، واستذكار السياق الطويل (AA-LCR)، واستخدام الأدوات الوكيلي (τ²-Bench Telecom).

انخفض GPQA (−0.13) وSciCode (−0.81) قليلاً، بينما كان IFBench (+0.86) وAA-LCR (+0.75) وτ²-Bench Telecom (+0.35) أعلى فعلياً تحت NVFP4. قد يبدو تفوّق 4 بت على 8 بت غير بديهي، لكن فروقاً بهذا الحجم تُقرأ بأمان أكبر كضوضاء تباين أخذ العينات لا كخسارة تكميم. الرسالة الجوهرية أن “ضغط FP8 خطوة إضافية إلى 4 بت يُبقي الدقة ثابتة فعلياً”، وهي نتيجة مباشرة لاستراتيجية التكميم الانتقائي الموصوفة أعلاه.

النشر: vLLM وSGLang

يدعم هذا النموذج رسمياً بيئتي التشغيل SGLang وvLLM، ويتطلب عتاد NVIDIA Blackwell، ويعمل على Linux. لأن نوى موتّرات NVFP4 موجودة فقط في جيل Blackwell، فإن عدم القدرة على استخدام مسار 4 بت هذا مباشرة على وحدات GPU الأقدم قيد مهم. أمر الخدمة عبر SGLang الذي توفّره بطاقة النموذج هو:

pip install -U "transformers>=5.3.0" && \
python3 -m sglang.launch_server \
    --model nvidia/GLM-5.2-NVFP4 \
    --tensor-parallel-size 8 \
    --quantization modelopt_fp4 \
    --tool-call-parser glm47 \
    --reasoning-parser glm45 \
    --trust-remote-code \
    --chunked-prefill-size 131072 \
    --mem-fraction-static 0.80

بضع إشارات تستحق القراءة هنا. --tensor-parallel-size 8 يعني أن النموذج يفترض عُقدة من 8 وحدات GPU لا واحدة. --quantization modelopt_fp4 يخبر بيئة التشغيل بالتعرّف على صيغة NVFP4 التي أنتجها ModelOpt. --chunked-prefill-size 131072 يقسّم التعبئة المسبقة عند معالجة سياق المليون رمز لمنع قفزات الذاكرة، وهي قيمة تحكم الاستقرار في خدمة السياق الطويل. --tool-call-parser glm47 و--reasoning-parser glm45 يحلّلان صيغتَي استدعاء الأدوات ورموز الاستدلال لعائلة GLM، وهما يرتبطان مباشرة بأحمال العمل الوكيلية.

من ناحية الذاكرة، تقدير تقريبي: خدمة 753B بدقة BF16 تحتاج نحو 1.5 تيرابايت [تقديري]. بما أن الخبراء الموجَّهين يهيمنون على عدد المعاملات ويُنزَلون إلى 4 بت، تنخفض ذاكرة الأوزان الفعلية إلى نحو الثلث فتقع في نطاق قابل للتحميل على عُقدة واحدة بتوازٍ موتّري ثماني (تُبلِغ مرايا NVFP4 المجتمعية عن نحو 1.37 تيرابايت إلى 459 جيجابايت، أي نحو 3 أضعاف [تقديري]). لأن بطاقة النموذج لا تذكر الحجم الدقيق بالجيجابايت قبل التكميم وبعده، يحمل هذا الرقم علامة [تقديري]. ما لا لبس فيه أن أمر --tensor-parallel-size 8 نفسه يشير إلى أن “8 وحدات Blackwell يمكنها خدمة نموذج استدلال بحجم 753B بسياق مليون رمز”.

تطبيقه على منصة ThakiCloud السحابية لخدمات AI/ML على K8s

تشغّل ThakiCloud منصة متعددة المستأجرين تجدوِل وحدات GPU عبر Kueue على K8s وتخدم النماذج عبر vLLM. في هذه البيئة، يهمّ نموذج مكمَّم مسبقاً من الطراز الرائد مثل nvidia/GLM-5.2-NVFP4 بثلاث طرق.

أولاً، يتّسع نطاق مرشّحي الخدمة. يُستبعَد نموذج استدلال من فئة 753B عادةً مبكراً من النظر في الاستضافة الذاتية، لكن إذا جعل تكميم 4 بت الأوزان مع هامش KV تناسب عُقدة Blackwell واحدة بـ 8 وحدات GPU، تصبح الخدمة الذاتية داخل المؤسسة خياراً واقعياً. باستخدام ResourceFlavor وClusterQueue في Kueue لتخصيص تجمّع عُقد Blackwell لاستدلال NVFP4، يتحوّل هامش الذاكرة المكتسب عبر التكميم مباشرة إلى عدد المستأجرين المخدومين معاً. بالنسبة للعملاء الذين لا يستطيعون إرسال البيانات إلى واجهات برمجية خارجية، خصوصاً القطاع العام والمالية حيث تُشترَط الاستضافة الذاتية وسيادة البيانات، فإن إبقاء الاستدلال الرائد داخلياً ميزة تنافسية بحد ذاتها.

ثانياً، لست مضطراً لتشغيل خط أنابيب التكميم بنفسك. معايرة وتكميم 753B بـ ModelOpt يتطلبان وقت GPU وهندسة كبيرين. إذا أمكننا أخذ نموذج معتمَد من NVIDIA ووضعه مباشرة على vLLM/SGLang، يمكننا تركيز الموارد على التوجيه متعدد المستأجرين والتوسّع التلقائي ومراقبة التكلفة بدلاً من التحقق من التكميم. ومع ذلك، يحوي نظام مهارات ThakiCloud بالفعل سير عمل داخلياً يكمّم عائلة Qwen3-MoE إلى NVFP4، لذا فإن الوصفة التي طبّقتها NVIDIA على GLM-5.2، أي “الخبراء إلى 4 بت، الخبير المشترك والانتباه بـ BF16”، تصبح نمطاً عاماً يمكننا اقتباسه مباشرة عند تكميم نماذج مجال العملاء بأنفسنا.

ثالثاً، يستحق التكميم الانتقائي الإدراج في معايير اعتماد النماذج لدينا. المبدأ الذي أظهره هذا النموذج، “بقوة حيث يوجد الكثير المتناثر، وبتحفّظ حيث يُستخدم دائماً”، ينطبق كما هو عند تكميم نماذج MoE أخرى داخلياً. بدلاً من سحق الكل ببساطة إلى 4 بت، يمكن أن يصبح الحفاظ على الخبير المشترك والانتباه بنداً في بوابة اعتماد النماذج. غير أن قيد Blackwell-only مرتبط مباشرة بتكوين تجمّع GPU لدينا، لذا يجب أن تذكر خارطة طريق الاعتماد أن استخدام مسار NVFP4 يفترض تأمين عُقد Blackwell.

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

أكبر قيد هو التبعية للعتاد. يفترض مسار NVFP4 بـ 4 بت نوى موتّرات Blackwell، لذا فإن البيئات التي تملك أجيالاً أقدم فقط مثل Hopper (H100/H200) لا يمكنها تحقيق فوائد هذا النموذج كما هي. سردية “4 بت تجعله رخيصاً” تصحّ فقط عندما تكون عُقد Blackwell مؤمَّنة أو مخطَّطة، وهي فعلاً تفترض إنفاقاً رأسمالياً جديداً.

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

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

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

باختصار، nvidia/GLM-5.2-NVFP4 حالة لإنزال نموذج استدلال MoE رائد بحجم 753B إلى 4 بت دون خسارة دقة، ما يجعل الخدمة الذاتية على عُقدة Blackwell بـ 8 وحدات GPU خياراً واقعياً. من منظور ThakiCloud، يضيف ورقة أخرى لتقديم الاستدلال الرائد للعملاء ذوي متطلبات الاستضافة الداخلية وسيادة البيانات، ومناسبة لإدراج المبدأ العام “التكميم الانتقائي” في معايير اعتماد النماذج. لكن ذلك الباب لا يُفتَح إلا بمفتاح Blackwell.

المصادر

• nvidia/GLM-5.2-NVFP4 · Hugging Face
• النموذج الأساس GLM-5.2 (ZAI) · Hugging Face
• NVIDIA Model Optimizer · GitHub
• Introducing NVFP4 for Efficient and Accurate Low-Precision Inference · NVIDIA Technical Blog

بات التنافس بين نماذج البرمجة مفتوحة الأوزان يتجاوز سؤال “كم تبلغ درجة المعيار؟” إلى سؤال أعمق: “بأي منهجية تدريب تحققت تلك الدرجة؟” Ornith-1.0 الذي أصدرته DeepReinforce في 25 يونيو 2026 هو نموذج تصدّر فيه المنهجية ذاتها العناوين. صُمّم التعلم المعزز فيه ليجعل النموذج يولّد الحلول ويكتب في الوقت ذاته سقالات التدريب (scaffold) التي تقود تلك الحلول.

هذا المقال لا يعرض نتائج إعادة تشغيل المعايير بشكل مستقل. تشغيل نموذج بحجم 397B على معايير البرمجة يستلزم عقد GPU متعددة وساعات استدلال، لذا لم يُجرَ ذلك في هذا التحليل الآني. وعليه، فجميع الأرقام الواردة هنا أرقام أعلنتها DeepReinforce في مواد مفتوحة، وما يتضارب بين المصادر مُشار إليه بـ[تقديري]. لم تُخترع أي أرقام.

نظرة عامة

Ornith-1.0 ليس نموذجاً واحداً، بل عائلة نماذج مفتوحة المصدر متخصصة في البرمجة. تنقسم إلى أربعة أحجام: 9B كثيف، و31B كثيف، و35B Mixture-of-Experts (MoE)، و397B MoE الرائد، وجميعها بترخيص MIT منشور على نطاق deepreinforce-ai في Hugging Face وجاهز للتنزيل الفوري. إلى جانبها نسخ مكمّمة: 9B و35B بصيغة GGUF، و35B و397B بصيغة FP8، مما يدل على أن طيف النشر (من GPU فردي على الحافة إلى عقد متعددة في مراكز البيانات) كان مقصوداً منذ البداية.

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

يمكن تلخيص جوهر النموذج في جملة واحدة: لا تتعلم Ornith-1.0 في مرحلة التعلم المعزز الحلولَ وحسب، بل تتعلم أيضاً السقالات المهمية التي تقود تلك الحلول. ومعالجة السقالة بوصفها هدفاً يتطور عوضاً عن كونها أداة ثابتة هي الفارق عن نماذج RL البرمجية الأخرى.

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

ما هذا النموذج؟

Ornith-1.0 مبني على تدريب ما بعد التدريب المسبق (post-training) فوق نماذج أساس مدرّبة مسبقاً. أعلنت DeepReinforce أنها استخدمت Gemma 4 وعائلة Qwen 3.5 كأساس، أي أن الأمر لا يتعلق بتدريب مسبق من الصفر، بل بتطبيق تعلم معزز مخصص على قواعد مفتوحة قوية لرفع قدرات البرمجة. يتشابه هذا مع ما تفعله NVIDIA حين تعيد توزيع نماذج جهات خارجية مكمّمة، أي مبدأ “القاعدة أصل مشترك، والتمييز في ما بعد التدريب”، وهو نمط تقسيم عمل بارز في المنظومة المفتوحة الراهنة.

النموذج في جوهره نموذج استدلال (reasoning). يفتح استجاباته بكتلة <think> … </think> ليطوّر عملية التفكير أولاً قبل إعطاء الإجابة النهائية. وصفة الخدمة المعلنة توجّه إلى تفعيل محلل reasoning يفصل عملية التفكير في حقل reasoning_content مستقل، ومحلل tool-call يعرض كتل استدعاء الأدوات بصيغة tool_calls متوافقة مع OpenAI. القصد التصميمي واضح: يُوصل مباشرة في حلقات العوامل. أقصى طول للسياق هو 262,144 رمز، وهو طول يستهدف مهام البرمجة ذات الأفق الطويل التي تدفع فيها مستودعات كاملة دفعة واحدة.

DeepReinforce ليست وافداً جديداً على التعلم المعزز. CUDA-L1 الصادر عام 2025 استخدم التعلم المعزز لتحسين نواة CUDA تلقائياً، وأفاد بتسارع متوسط 3.12× وتسارع ذروة يبلغ عشرات الأضعاف على مهام GPU متعددة. الخط البحثي المتواصل القائل “اجعل الكود/النواة تحسّن نفسها بالتعلم المعزز” يمتد الآن إلى هذا النموذج البرمجي.

الجوهر: تعلم معزز بتسقيل ذاتي

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

وفق وصف DeepReinforce، تسير كل خطوة RL في مرحلتين: أولاً يقترح النموذج سقالة مكيّفة شرطياً بالمهمة المعطاة، ثم يولّد طرح حل (rollout) شرطياً بتلك السقالة. يُنشر مكسب المكافأة على كلتا المرحلتين، أي أن “أي سقالة بُنيت؟” و”ماذا حُلّ فوقها؟” كلاهما يُقيَّم ويُحسَّن معاً. السقالة تصبح هدفاً يتطور بالتزامن مع السياسة.

flowchart LR
    T["المهمة (Task)"] --> S1
    subgraph RLSTEP["خطوة RL (مرحلتان)"]
      direction TB
      S1["المرحلة 1: اقتراح السقالة<br/>(شرطي بالمهمة)"] --> S2["المرحلة 2: طرح الحل<br/>(شرطي بالسقالة)"]
    end
    S2 --> R["المكافأة (reward)"]
    R -. "ينتشر إلى السقالة" .-> S1
    R -. "ينتشر إلى السياسة" .-> S2
    S1 -. "تطور مشترك" .- S2

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

المعايير المعلنة

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

تدّعي DeepReinforce تحقيق أعلى أداء بين النماذج مفتوحة المصدر من الحجم ذاته على Terminal-Bench 2.1 وSWE-Bench وNL2Repo وOpenClaw. ويبرز تحديداً أن 35B MoE يتفوق على بعض النماذج الأكبر حجماً، ما يُفسَّر بأن ندرة MoE مقترنة بما بعد التدريب التسقيلي الذاتي ترفع الكفاءة نسبةً إلى عدد المعاملات النشطة. بيد أن معايير SWE-Bench تتفاوت تفاوتاً كبيراً بين نسخها (Verified/Pro/الأصلية)، والمقارنة المباشرة دون التحقق من النسخة المستخدمة ضربٌ من المجازفة، ولهذا وُضعت قيمة SWE-Bench Pro بعلامة [تقديري].

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

التثبيت والخدمة

صُمّمت Ornith-1.0 لتعمل مباشرة على مكدسات الاستدلال القياسية. منطق تدرّج التحقق ينطبق هنا: ابدأ بالأصغر. صُمّم 9B للعمل على GPU فردي، وهو نقطة انطلاق مناسبة لاختبار تكامل أنابيب العمل.

# تنزيل الأوزان من Hugging Face (مثال: 9B)
huggingface-cli download deepreinforce-ai/Ornith-1.0-9B \
  --local-dir ./ornith-1.0-9b

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

# خدمة vLLM (شكل نموذجي، أسماء المحللات تتبع بطاقة النموذج)
vllm serve deepreinforce-ai/Ornith-1.0-9B \
  --max-model-len 262144 \
  --enable-auto-tool-choice \
  --tool-call-parser <محدد في بطاقة النموذج> \
  --reasoning-parser <محدد في بطاقة النموذج>

عند تشغيل 397B MoE الرائد، الذاكرة هي العائق الأول. لذا نُشرت نسخة FP8 (Ornith-1.0-397B-FP8) منذ البداية: تخفّض ذاكرة الأوزان بنسبة النصف مقارنة بـBF16، مما يقلص عدد العقد ودرجة التوازي الموتّري. أما 35B MoE فهو نقطة التوازن المثلى التي يمثّل فيها MoE ميزته الجوهرية “معاملات نشطة أقل، طاقة معرفية أكبر”، وهو مرشح واقعي للخدمة على عقدة واحدة بـGPU متعدد.

# 397B: نسخة FP8 مع توازي موتّري للتعامل مع جدار الذاكرة (هيكل إرشادي)
vllm serve deepreinforce-ai/Ornith-1.0-397B-FP8 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --enable-auto-tool-choice

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

تُجدوِل منصة ThakiCloud للذكاء الاصطناعي أحمال GPU عبر Kueue فوق K8s، وتخدم الاستدلال متعدد المستأجرين عبر vLLM، وتُشغّل عوامل متعددة المستأجرين. نموذج كـOrnith-1.0 ذو صلة بهذا المكدس في ثلاثة محاور:

أولاً السيادة على نموذج عوامل البرمجة الداخلية. الكود من أكثر الأصول حساسية. الطلب على تشغيل عوامل برمجة داخل البنية التحتية الخاصة أو المستأجر المخصص دون إرسال الكود إلى واجهات برمجة مغلقة حاجةٌ كبرى في البيئات المقيّدة بمتطلبات تداول البيانات كالقطاع المالي والحكومي والدفاعي. رخصة MIT مع أوزان قابلة للاستضافة الذاتية هي الإجابة الدقيقة على هذا الطلب. سياق 262K والإخراج بصيغة tool_calls المتوافقة مع OpenAI تتيح استبدال النموذج الأساسي في حلقات عوامل قائمة دون إعادة هندسة.

ثانياً طيف الأحجام يتوافق مع حسابات التكلفة متعددة المستأجرين. يمكن توزيع الأدوار: 9B للمهام المساعدة الخفيفة أو مستويات المستأجرين المنخفضة التكلفة، و35B MoE كنموذج الخدمة الرئيسي بكفاءة عالية للمعاملات النشطة، و397B لأحواض المهام الصعبة حصراً. في بيئة تجدوِل GPU عبر Kueue، تحويل “أي حجم لأي مستأجر بأي أولوية” مباشرةً إلى تكلفة وحدة. امتلاك خيار الحجم في عائلة واحدة يعني المرونة التشغيلية وتحسين التكلفة في آنٍ.

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

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

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

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

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

خلاصة القول: Ornith-1.0 نموذج يستحق الاهتمام لمنهجيته قبل درجاته. كونه مرخّصاً بـMIT يجعله مرشحاً واقعياً لعوامل البرمجة ذاتية الاستضافة، وآلية التسقيل الذاتي فكرة يستحق اقتباسها في تصميم أنابيب تدريب العوامل سواء اعتُمدت الأوزان أم لا. لكن جميع أرقام المعايير تبقى “أرقاماً مُعلنة” ريثما تخضع للتقييم الذاتي.

المصادر

• DeepReinforce، “Ornith-1.0: Self-Scaffolding LLMs for Agentic Coding” (يونيو 2026): https://deep-reinforce.com/ornith_1_0.html
• بطاقات النموذج على Hugging Face: https://huggingface.co/deepreinforce-ai/Ornith-1.0-397B، https://huggingface.co/deepreinforce-ai/Ornith-1.0-9B
• GitHub: https://github.com/deepreinforce-ai/Ornith-1
• MarkTechPost، “DeepReinforce Releases Ornith-1.0” (2026-06-25): https://www.marktechpost.com/2026/06/25/deepreinforce-releases-ornith-1-0-an-open-source-coding-model-family-that-learns-its-own-rl-scaffolds/
• Tech Times (2026-06-26): https://www.techtimes.com/articles/319122/20260626/open-source-coding-model-ornith-10-writes-its-own-training-scaffold-reinforcement-learning.htm
• DeepReinforce، CUDA-L1 (بحث سابق): https://deepreinforce-ai.github.io/cudal1_blog/

نظرة عامة

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

غير أن ورقة arXiv المنشورة في 23 يونيو 2026 بعنوان Are We Ready For An Agent-Native Memory System? تطرح منظوراً يمكن تلخيصه في جملة واحدة: ذاكرة الوكيل لم تعد أداةً للتعزيز بالاسترجاع، بل تطورت لتصبح نظام إدارة بيانات متكاملاً (data management system) يتولى التخزين الدائم والاسترجاع والتحديث والدمج وإدارة دورة الحياة الديناميكية معاً. هذه الورقة هي التي لخّصها dair_ai بالقول: “ذاكرة الوكيل أصبحت الآن نظام بيانات”.

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

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

ما الذي تبحثه هذه الدراسة؟

إشكالية الورقة بسيطة لكنها حادة: كانت طرق تقييم ذاكرة الوكيل حتى الآن تقتصر في معظمها على مقاييس النجاح الشامل من طرف إلى طرف (end-to-end). درجات مثل F1 أو BLEU تُجيب فقط على “هل أجاب الوكيل بصورة صحيحة؟”، فيما يبقى النظام الداخلي للذاكرة التي أنتجت تلك الإجابة صندوقاً أسود مغلقاً.

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

لذلك أجرى المؤلفون، وهم Wei Zhou وXuanhe Zhou وGuoliang Li وZhiyu Li وFeiyu Xiong وآخرون، ولافتٌ أن في صفوفهم باحثين متخصصين في أنظمة قواعد البيانات مما يشكّل هوية الورقة، تجارب منهجية على الذاكرة من منظور إدارة البيانات. ويتجسد هذا في إطار تحليلي يُفكّك ذاكرة الوكيل إلى أربع وحدات جوهرية.

الوحدات الأربع هي:

1. التمثيل والتخزين (Representation & Storage): بأي شكل تُحفظ الذكريات وأين تُخزّن؟ طريقة التمثيل، متجهات أو رسوم بيانية أو أشجار أو نص عادي، تُحدد مباشرةً دقة التمثيل (representation fidelity).
2. الاستخراج (Extraction): مرحلة انتقاء ما يستحق التذكر خلال تنفيذ الوكيل. لا يمكن تخزين كل الرموز، فهنا يُفرز الإشارة من الضجيج.
3. الاسترجاع والتوجيه (Retrieval & Routing): مرحلة الوصول إلى الذكرى الصحيحة في اللحظة المناسبة وإعادتها عبر المسار الملائم. يتجلى هنا مقياس دقة الاسترجاع (retrieval precision).
4. الصيانة (Maintenance): مرحلة دمج الذكريات القديمة وتحديثها وتنظيفها. هنا تُحدَّد دقة التحديث (update correctness) والاستقرار طويل الأمد (long-horizon stability).

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

الاكتشافات الجوهرية

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

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

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

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

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

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

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

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

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

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

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

القيود والانتقادات

للموضوعية، ثمة نقاط ينبغي مراعاتها قبل تبنّي هذا البحث على علّاته.

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

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

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

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

المصادر

• الورقة: Are We Ready For An Agent-Native Memory System? (arXiv 2606.24775)
• HF Papers: hf.co/papers/2606.24775
• الكود المنشور: github.com/OpenDataBox/MemoryData
• السياق الأصلي: dair_ai، “Agent memory is a data system now”

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

نظرة عامة

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

أمر /learn الذي أضافه Nous Research في 24 يونيو 2026 إلى إطار عمل Hermes Agent يُلغي هذه الخطوة اليدوية كليًا. أشِر إلى دليل، أو رابط URL، أو محادثة انتهيت منها للتو، أو ملاحظات لصقتها، فيجمع الوكيل الحيّ المواد مباشرةً ويؤلف SKILL.md مطابقًا للمعيار. أشعل هذا الأمر اهتمامًا واسعًا حين شارك tonbistudio مقطع عرض توضيحي على تويتر يُظهر بناء مهارة من مصادر متعددة، وبما أن ThakiCloud كانت قد ثبّتت Hermes Agent مسبقًا وتشغّله داخليًا، أجرينا التحقق بأنفسنا.

تُشغّل ThakiCloud وكلاء متعددي المستأجرين على منصة SaaS للذكاء الاصطناعي/تعلم الآلة مبنية على Kubernetes. البنية التي يبني فيها الوكيل ذاكرةً إجرائية بنفسه، ثم يخضع هذا البناء لمراجعة بشرية عبر بوابة مخصصة، تتقاطع تمامًا مع المبدأ الذي كنّا نصيغه تحت اسم “Thin Harness, Fat Skills - harness رفيع ومهارات ثرية”، أي أنّ القدرات تتراكم في المهارات لا في الـ harness. /learn أداة تخفّض حاجز الدخول لبناء تلك المهارات، مما يجعلها أكثر من مجرد ميزة مريحة.

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

/learn ليس محرك استيعاب مستقلًا. جوهره أنه “يبني موجّهًا يرشد الوكيل عبر المعايير ثم يُمرره كدورة عادية واحدة.” لذلك تظل عملية جمع المصادر تعمل بالأدوات التي يمتلكها الوكيل بالفعل: الأدلة المحلية تُقرأ عبر read_file وsearch_files، والوثائق الإلكترونية تُجلب عبر web_extract، وسير العمل التي أُنجزت معًا في المحادثة تُلتقط من سياق الحوار مباشرةً.

المسار الكامل لـ /learn: من وصف المصدر، إلى الجمع بأدوات الوكيل، ثم تأليف SKILL.md معياري، ثم العبور عبر بوابة write_approval وcurator.

المصادر المقبولة أربعة أنواع. فيما يلي الأمثلة المأخوذة مباشرةً من التوثيق الرسمي:

# دليل SDK أو وثائق محلية (تُقرأ عبر read_file / search_files)
/learn the REST client in ~/projects/acme-sdk, focus on auth + pagination

# صفحة وثائق إلكترونية (تُجلب عبر web_extract)
/learn https://docs.example.com/api/quickstart

# سير عمل أنجزناها معًا في هذه المحادثة
/learn how I just deployed the staging server

# ملاحظات لُصقت أو إجراء شُرح شفهيًا
/learn filing an expense: open the portal, New > Expense, attach the receipt, submit

يُنظّم الوكيل المواد المجموعة وفق “معيار التأليف الداخلي”: الوصف لا يتجاوز 60 حرفًا، وترتيب الأقسام ثابت، والصياغة مرجعها أدوات Hermes، وقاعدة صارمة بعدم اختراع أوامر غير موجودة. المنتج النهائي SKILL.md مؤلَّف من frontmatter بصيغة YAML وأقسام ثابتة في الجسم:

---
name: my-skill
description: Brief description of what this skill does
version: 1.0.0
platforms: [macos, linux]
metadata:
  hermes:
    tags: [python, automation]
    category: devops
---

# Skill Title

## When to Use
الشروط التي تُطلق هذه المهارة.

## Procedure
1. الخطوة الأولى
2. الخطوة الثانية

## Pitfalls
- أنماط الفشل المعروفة وكيفية معالجتها

## Verification
كيفية التحقق من صحة التنفيذ.

التخزين يتولاه أداة skill_manage. ثمة ضمانة أمان مهمة هنا: إذا كان skills.write_approval مُفعَّلًا، فإن كل كتابة مهارة من الوكيل لا تُطبَّق فورًا، بل تُرحَّل إلى ~/.hermes/pending/skills/. يرى المشغّل التغييرات المعلّقة عبر /skills pending، ويفحص الفرق الكامل عبر /skills diff <id>، ثم يوافق أو يرفض. تنطبق هذه البوابة على المهارات المُنشأة في الدورات الأمامية وعلى تلك التي اقترحها الوكيل في إطار مراجعة التحسين الذاتي الخلفية.

بفضل عدم الاعتماد على محرك استيعاب مستقل، يعمل /learn بالتماثل ذاته في واجهات CLI وTUI وبوابات المراسلة ولوحات التحكم. لا يُهم إذا كانت الخلفية الطرفية محلية أو ضمن Docker أو بعيدة. في لوحة التحكم، تظهر في صفحة Skills زر “Learn a skill” يعرض حقلًا للدليل وحقلًا لعنوان URL ومربع نص حر لتكوين طلب /learn وتشغيله.

سيناريوهات الاستخدام التي يقترحها التوثيق الرسمي ثلاثة. الأول: إعداد API الداخلي. تشغيل /learn على رابط وثائق خاص يُنتج مهارة تضم المصادقة والصفحات وأكثر الاستدعاءات استخدامًا، يستدعيها الأعضاء الجدد كأمر slash. الثاني: التقاط كتاب التشغيل. بعد إجراء نشر staging مع الوكيل، تشغيل /learn how I just deployed the staging server يجعل تلك الإجراءات قابلة للتكرار عبر CLI وأنظمة الدردشة. الثالث: تجميع المهام المتكررة. تقوم حزمة المهارات بتحميل مهارات المراجعة والاختبار وطلب السحب دفعةً واحدة بأمر slash واحد:

# ~/.hermes/skill-bundles/backend-dev.yaml
name: backend-dev
description: Backend feature work - review, test, PR workflow.
skills:
  - github-code-review
  - test-driven-development
  - github-pr-workflow
instruction: |
  Always start by writing failing tests, then implement.

يُتيح نظام المهارات نفسه البدء بحالة نظيفة. hermes skills opt-out يوقف بذر مهارات الحزمة، وhermes skills opt-in --sync يُعيده. حقل platforms يُخفي المهارات على أنظمة التشغيل غير المتوافقة، والحقول الشرطية تكشف المهارة فقط حين تتوفر مجموعة أدوات بعينها.

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

فحصنا Hermes Agent المثبّت في بيئة ThakiCloud مباشرةً. الملف الثنائي في ~/.local/bin/hermes، ويعمل فعليًا عبر Python في ~/hermes-agent/venv.

$ ~/.local/bin/hermes --version
Hermes Agent v0.16.0 (2026.6.5) · upstream 40cea4d5
Python: 3.11.13
OpenAI SDK: 2.24.0

تتجمع جميع المهارات في ~/.hermes/skills/، وهو مصدر الحقيقة الوحيد. نظرًا للتوافق مع المعيار المفتوح agentskills.io، يمكن تهيئة أدوات متعددة لمسح مجلد مهارات مشترك. هذه التهيئة الخارجية هي صلب منظور المنصة الذي سنتناوله لاحقًا.

# ~/.hermes/config.yaml
skills:
  external_dirs:
    - ~/.agents/skills
    - /home/shared/team-skills
    - ${SKILLS_REPO}/skills

استخرجنا قائمة المهارات المثبّتة مباشرةً. يتضمن التثبيت الحالي 78 مهارة مصنّفة ضمن فئات مثل apple وautonomous-ai-agents وcreative وغيرها.

$ ~/.local/bin/hermes skills list
                                Installed Skills
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┓
┃ Name                ┃ Category             ┃ Source  ┃ Trust   ┃ Status  ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━┩
│ claude-code         │ autonomous-ai-agents │ builtin │ builtin │ enabled │
│ architecture-diagram│ creative             │ builtin │ builtin │ enabled │
│ humanizer           │ creative             │ builtin │ builtin │ enabled │
│ excalidraw          │ creative             │ builtin │ builtin │ enabled │
└─────────────────────┴──────────────────────┴─────────┴─────────┴─────────┘

كل مهارة مثبّتة تصبح تلقائيًا أمر slash. الاستدعاء بالاسم وحده كـ /excalidraw يُحمّل المهارة ويسأل الوكيل عمّا يمكنه مساعدتك به، والاستدعاء مع وسيطات كـ /plan design a rollout for migrating our auth provider يعالج الطلب فورًا. الأوامر الفرعية لإدارة المهارات وفيرة:

$ ~/.local/bin/hermes skills --help
{browse, search, install, inspect, list, check, update, audit,
 uninstall, reset, opt-out, opt-in, repair-official, publish,
 snapshot, tap, config}

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

$ ~/.local/bin/hermes curator --help
{status, run, pause, resume, pin, unpin, restore,
 list-archived, archive, prune, backup, rollback}

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

Level 0: skills_list()           → [{name, description, category}, ...]   (~3k رمزًا)
Level 1: skill_view(name)        → المحتوى الكامل + البيانات الوصفية
Level 2: skill_view(name, path)  → ملف مرجعي محدد

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

ثمة قيد يجب توثيقه بصدق هنا. النسخة المثبّتة لدى ThakiCloud هي v0.16.0 (2026.6.5)، وهي تسبق إصدار 24 يونيو 2026 الذي أضاف /learn. إذ يُبلّغ الملف الثنائي بأنه “محدَّث” بناءً على checkout git المحلي، فلم تنعكس الإصدارات الجديدة من المستودع الرئيسي تلقائيًا. لهذا لم نتمكن في هذا المقال من تشغيل /learn في بيئتنا والتقاط نتائج قابلة للقياس. قيد محاولة الاستنساخ: نسخة التثبيت تسبق إدخال /learn فالأمر غائب أصلًا.

في المقابل، تحققنا من كل ما كان ممكنًا بالقياس المباشر. الهيكل الذي يودع /learn نتائجه فيه - نظام المهارات - يعمل في بيئتنا كما هو متوقع. 78 مهارة مكشوفة كأوامر slash، ومسار التأليف الذاتي المعتمد على skill_manage، وبوابة الترحيل skills.write_approval، وتنظيف curator في الخلفية، وفهرسة الكشف التدريجي - كلها موجودة في النسخة المثبّتة. أي أن ما أضافه /learn هو نقطة دخول رفيعة تحوّل “أشر إلى مصدر فيُبنى موجّه معياري ويُمرر عبر مسار التأليف الموجود”، أما الجزء الثقيل الذي يقبع تحته فقد تحقق منه بالفعل.

سلوك /learn ذاته تحققنا منه عبر التوثيق الرسمي وتقرير MarkTechPost الصادر في 24 يونيو 2026. كلا المصدرين يُورد الحقائق ذاتها: أنواع المصادر الأربعة، وأدوات الجمع read_file/search_files/web_extract، وقيد الـ 60 حرفًا مع ترتيب الأقسام الثابت، والحفظ عبر skill_manage وبوابة write_approval. بدلًا من اختراع أرقام، نفصل بوضوح ما تحقق منه وما لم يتحقق.

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

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

ما يجعل /learn مثيرًا للاهتمام ليس الراحة وحدها، بل تقاطعه المباشر مع ثلاث مشكلات تواجهها منصة الوكلاء متعددة المستأجرين.

الأولى: تكلفة التقاط المعرفة الحقلية. لكل عميل كتاب نشر ومعايير API داخلية وإجراءات للاستجابة للحوادث مختلفة. نقلها يدويًا في كل مرة إلى SKILL.md يُبطئ التبني. /learn يحوّل “حوّل العمل الذي أنجزناه للتو إلى مهارة” جملةً واحدة تُحوّل الذاكرة الإجرائية فورًا إلى أصل قابل لإعادة الاستخدام. نشر staging أجراه مشغّل مرة واحدة يصبح أمرًا قابلًا للتكرار عبر CLI والدردشة معًا.

الثانية: الحوكمة. تتعامل ThakiCloud مع بيئات on-premises وself-hosting وبيئات تخضع لمتطلبات أمنية صارمة. قدرة الوكيل على كتابة مهاراته الخاصة قوية، لكنها في الوقت ذاته خطر تراكم إجراءات غير مراجَعة تلقائيًا. بنية ترحيل write_approval لكل عمليات كتابة المهارات إلى ~/.hermes/pending/skills/، مع استمرارها عبر عمليات إعادة التشغيل وإتاحة /skills diff للمراجعة البشرية الكاملة، مناسبة لهذه البيئات. إنها تصميم يفصل بين راحة التشغيل الآلي وضبط المراجعة البشرية.

الثالثة: مشاركة المهارات بين الأدوات. إعداد external_dirs في Hermes يسمح لأدوات AI متعددة بمشاركة مجلد المهارات ذاته. تُشغّل ThakiCloud بالفعل أكثر من 1,000 مهارة داخليًا وفق معيار agentskills.io نفسه. ربط Hermes بهذا الدليل المشترك يجعل المهارة المكتوبة في مكان واحد تعمل عبر Claude Code وCursor وHermes. هذا هو تجسيد مبدأ “Thin Harness, Fat Skills” - بناء القدرات في المهارات لا في الـ harness حتى تبقى الأصول قائمة حين يتغير الـ harness.

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

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

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

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

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

خلاصة القول: /learn تصميم يُزيل احتكاك كتابة المهارات ويُحوّل المرحلة المراجعة الطبيعية التي كان الاحتكاك يؤديها نحو بوابات وcurator. من منظور تشغيل منصة وكلاء متعددة المستأجرين، قراءته كتصميم حوكمة لا كميزة راحة أدق وأوفق.

المصادر (Sources)

• Hermes Agent official documentation, Skills System: https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
• MarkTechPost, “Nous Research Adds /learn to Hermes Agent’s Skills System” (2026-06-24): https://www.marktechpost.com/2026/06/24/nous-research-adds-learn-to-hermes-agents-skills-system-capturing-workflows-as-slash-commands-without-hand-writing-skill-md/
• NousResearch/hermes-agent (GitHub): https://github.com/NousResearch/hermes-agent
• Original tweet (demo video, tonbistudio): https://x.com/hjguyhan/status/2070135061429854577

Overview

This project is built on top of learning_research, a research primer published by Professor Pengsi Da (pengsida) of Zhejiang University in China. It reframes that paper-writing knowledge as an Agent Skill package. According to the repository description, the package focuses on ML, CV, and NLP paper writing, and was curated and structured specifically for Codex, Claude Code, and Gemini. The contribution is not a copy of the original text – it takes scattered advice, breaks it into work units, and turns each unit into a reusable capability that an agent can invoke.

Why is this format attracting attention now? As AI coding agents have become mainstream, people have started treating not the model itself but “what to ask the model and how” as a durable asset. Well-organized task knowledge, once created, replicates across tools and teams. Tasks with clear procedures and explicit quality criteria – paper writing being a prime example – are a natural fit for this format. ThakiCloud already organizes much of its internal operations around hundreds of Skills, so we read this trend as a structural shift in how agents are run, not a passing fad.

What is an Agent Skill

An Agent Skill is a package that tells an agent how to perform a specific task. It centers on a SKILL.md instruction file and optionally includes reference documents, scripts, and templates. It has three defining properties. First, it is version-controlled: stored in a repository and tracked over time, it accumulates as an asset rather than a one-off prompt. Second, it is loaded on demand: instead of stuffing all knowledge into the context every time, only the Skills relevant to the current task are loaded. Third, it is harness-independent: the same Skill can be used in Claude Code, Codex, and Gemini – that is the design goal.

The third property best explains the value of this project. Models keep changing, and CLI tools keep changing. But “how to write a strong introduction” as task knowledge outlasts both by a wide margin. Accumulating capability in the Skill rather than in the tool means that expertise does not have to be rebuilt every time the tool changes. Internally, we call this the “thin harness, fat Skills” principle: keep the model loop, permissions, and file I/O thin; pack domain knowledge, judgment, and failure cases thickly into the Skill.

The central point of the diagram is that there is exactly one Skill package in the middle. The three tools are not each carrying separate prompts – they share the same task knowledge. That is the fundamental difference from pasting a one-liner prompt into a chat window.

Research-Paper-Writing-Skills in Detail

The tasks this package covers map directly to the actual stages of writing a paper. Published usage examples show calling $research-paper-writing to refine an introduction, or invoking the Skill to rewrite an abstract and verify that claims and evidence are properly paired. Rather than a vague “write this better” request, the design separates the recurring sub-tasks of paper writing into distinct, callable capabilities. This matches the principle that one verb should produce one deliverable.

The multi-harness orientation is also notable. A user can activate the same capability by simply copying the package to the Skill directory recognized by whichever tool they use. This direction is not unique to this project – several recently published open-source efforts, including academic Skill collections centered on Codex and general-purpose AI research Skill libraries, share the same orientation. It is a signal that a simultaneous push is underway to move the entire research workflow into a Skill ecosystem.

One point worth being explicit about: this post is based on the public description and usage examples from the repository. Specific counts such as star ratings, or internal file structures, can change over time and are not stated as fixed facts here. If you are evaluating adoption, check the repository directly along with the license and attribution requirements for the original author’s notes.

Installation and Use

The installation model for Agent Skills is generally straightforward. Clone the package and place it in the Skill path recognized by the tool you use; the agent then loads the relevant Skill for each task. The general flow is:

# Clone the repository
git clone https://github.com/Master-cai/Research-Paper-Writing-Skills.git

# Copy to the Skill directory of your tool (check each tool's docs for the exact path)
# Example: place under .claude/skills/ in a Claude Code project
cp -r Research-Paper-Writing-Skills/<skill-dir> .claude/skills/

Once placed, invoke the Skill from an agent session to request work – ask in natural language to refine an introduction draft or check whether the abstract’s claims and evidence are consistent, and the procedures and criteria embedded in the Skill are applied. Because the Skill path and invocation convention differ slightly by tool, follow each tool’s documentation for the actual placement path. The key point is that a Skill placed once is reused across all sessions in that tool. The overhead of copying the same prompt repeatedly disappears.

Applying It on the ThakiCloud K8s AI/ML SaaS Platform

ThakiCloud’s AI platform runs agents and batch workloads for diverse customers on top of Kubernetes. Our internal operations are already organized around Skills, so the format this project demonstrates is familiar. What matters more is that the same pattern is spreading rapidly in the broader community.

First, there is direct value for data scientists and researchers. Teams working on the platform write papers and technical reports regularly. Attaching proven paper-writing Skills to the standard internal toolchain lets teams apply consistent standards to error-prone areas such as introduction structure and abstract claim-evidence alignment – raising average quality without upgrading the model tier.

Second, harness independence pairs well with multi-tenant operations. Different customers may prefer different agent environments, but encapsulating capability in a Skill allows the same task knowledge to be reused regardless of environment. Capability is not locked to any one vendor’s tool, which makes it straightforward to port the same asset into on-premises deployments where customers have strong self-hosting requirements. That aligns with our strategy around self-hosting and cost efficiency.

Third, this project reinforces the lesson that Skills need to be managed as operational assets with discipline. A Skill carries a per-session context cost from the moment it is indexed. We therefore apply a question to every new Skill: “would the agent make a mistake without this?” We also document failure cases explicitly. Applying the same gate to externally sourced Skills prevents a growing Skill library from degrading retrieval accuracy – a real risk when the corpus exceeds what a retriever can distinguish cleanly.

Limitations and Counterpoints

This approach has clear weaknesses. First, there are no published objective metrics for the quality of text the package produces. Paper writing is inherently a judgment-intensive task, and whether the Skill-generated draft meets a human reader’s standard ultimately requires human review. That is why this post includes no performance figures – fabricating numbers without empirical measurement is exactly what should be avoided.

Second, there is the question of provenance and derivative works. This package is a repackaging of someone else’s public notes. Even though the original author is credited, organizations adopting it bear the responsibility to verify the license terms and the scope of required attribution themselves – more so when embedding it in internal standards.

Third, writing assistance does not replace thinking. A strong introduction comes from strong research. A Skill helps with expression and checking; it cannot transform thin results into a substantive paper. Distinguishing clearly between what the tool can supply and what the researcher must own is the prerequisite for using this format in a healthy way.

Sources

• Research-Paper-Writing-Skills: https://github.com/Master-cai/Research-Paper-Writing-Skills
• Original research primer learning_research (pengsida): https://github.com/pengsida/learning_research

For teams trying to serve a frontier-class reasoning model on their own infrastructure, the first obstacle is almost always GPU memory. Loading 753B parameters at 16-bit requires close to 1.5 TB of memory, which translates directly to multiple GPU nodes. nvidia/GLM-5.2-NVFP4, released on Hugging Face on June 25, 2026, is NVIDIA’s attempt to lower that barrier by quantizing ZAI’s (zai-org) GLM-5.2 to 4-bit precision.

This post is not an introduction to GLM-5.2 as a model. How the model’s long reasoning token lengths change the economics of self-hosting is covered in the reasoning token economics post, and the 1-bit GGUF quantization for consumer hardware is covered in the Unsloth GGUF post. The focus here is the datacenter track: what architectural choices NVIDIA’s NVFP4 quantization makes, what hardware it targets, how serving is set up, and what it means for teams running multi-tenant inference.

All accuracy figures in this post are official measurements published by NVIDIA in the model card. Because the 753B model requires NVIDIA Blackwell with 8-way tensor parallelism, we were not able to reproduce results in ThakiCloud’s development environment. This post is therefore an analysis based on public information; no numbers have been fabricated. Values that could not be independently verified are marked [estimated].

Overview

nvidia/GLM-5.2-NVFP4 is a quantized version of ZAI’s zai-org/GLM-5.2, produced with NVIDIA Model Optimizer (ModelOpt). The base model is a Mixture-of-Experts (MoE) architecture designed for reasoning and coding. Of its 753B total parameters, only 40B are activated per token. The network architecture is GlmMoeDsaForCausalLM, and it supports contexts up to 1M tokens through sparse attention using an IndexShare indexer. The license is MIT, identical to the base model, allowing both commercial and non-commercial use.

The key idea in one sentence: MoE reduces compute, and selective NVFP4 quantization reduces memory, while deliberately excluding accuracy-sensitive components from quantization. The MoE structure ensures that despite 753B total parameters, inference cost per token is bounded by the 40B active experts. NVFP4 then reduces the memory footprint of the routing experts, which hold the vast majority of parameters, from 16-bit to 4-bit. The shared experts, however, remain in BF16, minimizing accuracy loss.

The timing also carries a signal. The trend of strong open-weight models being released under MIT, combined with NVIDIA immediately repackaging them into deployable form optimized for its own hardware, is becoming a pattern. For organizations thinking about model sovereignty, this is not an abstract policy question; it is a concrete architecture decision: which GPUs, which model, and how.

What this model is

GLM-5.2 is a MoE reasoning and coding model released by ZAI. Unlike conventional dense models, it places multiple expert networks inside each transformer block and activates only a subset per input token. GLM-5.2 has 753B total parameters, but when generating a single token, only 40B active parameters participate in the computation. In other words, the model’s knowledge capacity is at the 753B scale, but inference compute cost is closer to a 40B dense model.

In addition, GLM-5.2 uses sparse attention through an IndexShare indexer. The design supports a 1M-token context window while avoiding the quadratic cost of full attention over all token pairs. The model card labels this architecture glm_moe_dsa and requires transformers>=5.3.0. These two forms of sparsity, MoE sparsity and attention sparsity, combine to deliver frontier-level reasoning capability at comparatively contained compute.

NVFP4 is a 4-bit floating-point data type defined by NVIDIA. The key distinction from integer 4-bit is that it is floating-point. Specifically, it groups 16 small floating-point (E2M1) values into a block and attaches a per-block FP8 (E4M3) scale, a two-level block-scaling scheme. Because the dynamic range is tracked per block, tail values in the distribution are better preserved than with simple integer quantization. NVIDIA is explicit in the model card that this is a quantized third-party model rather than one NVIDIA trained from scratch, and that the open-source NVIDIA Model Optimizer was used for quantization.

The core design decision: selective quantization

Only the linear operators inside MoE routing experts are quantized to NVFP4; shared experts and attention remain in BF16.

The most important design decision in this model is what was left unquantized. Quoting the model card directly: “only the weights and activations of linear operators inside transformer blocks within MoE experts are quantized; shared experts are not quantized.” Concretely:

• Quantized to NVFP4 (4-bit): weights and activations of linear operators in MoE routing experts. This section accounts for the vast majority of the 753B parameters, so nearly all of the memory savings come from here.
• Preserved in BF16 (16-bit): shared experts and the IndexShare sparse attention path. Every token passes through these on every forward pass, so their accuracy impact is disproportionately large.

This strategy makes sense given how parameters are distributed in MoE models. Routing experts are numerous and collectively hold the overwhelming share of parameters, but each token only activates a fraction of them. Shared experts and attention, by contrast, hold a smaller share of parameters but are used by every token without exception. Quantizing aggressively where there are many parameters used sparsely, and conservatively where there are few parameters used always, is a reasonable tradeoff that buys memory savings without paying much in accuracy. The near-flat accuracy numbers in the benchmark table are a direct consequence of this selective approach.

Quantization calibration used NVIDIA’s Nemotron-family datasets. The model card lists Nemotron-SFT-Instruction-Following-Chat-v2, Nemotron-Science-v1, Nemotron-Competitive-Programming-v1, Nemotron-SFT-Agentic-v2, Nemotron-Math-v2, Nemotron-SFT-SWE-v2, and Nemotron-SFT-Multilingual-v1. The mix covers reasoning, science, coding, agentic tasks, math, and multilingual data, aligned in character with the evaluation benchmarks.

Public benchmarks: accuracy vs. FP8

Official measurements from the nvidia/GLM-5.2-NVFP4 model card. The baseline is GLM-5.2-FP8.

The accuracy comparison published in the model card is shown below. The baseline is not BF16 but the already-compressed GLM-5.2-FP8, making this a more demanding comparison: not “how much does 4-bit lose vs. the original” but “how much does 4-bit lose vs. 8-bit.”

Measurement conditions: temperature 1.0, top_p 0.95, max_new_tokens 100000 for GPQA Diamond, 64000 for the rest. AA-LCR was measured with SGLang; the remaining four with vLLM. The five benchmarks evaluate graduate-level scientific reasoning (GPQA Diamond, 448 questions), scientific coding (SciCode), instruction following (IFBench), long-context recall (AA-LCR), and agentic tool use (tau2-Bench Telecom).

GPQA drops by 0.13 and SciCode by 0.81, while IFBench (+0.86), AA-LCR (+0.75), and tau2-Bench Telecom (+0.35) actually come in higher for NVFP4. That a 4-bit model outperforms an 8-bit one on some tasks may seem counterintuitive, but differences at this scale are better interpreted as sampling variance noise than as quantization artifacts. The headline finding is: compressing FP8 a further step down to 4-bit leaves accuracy essentially flat, which is the direct payoff of the selective quantization strategy described above.

Deployment: vLLM and SGLang

This checkpoint officially supports SGLang and vLLM, and requires NVIDIA Blackwell hardware running Linux. NVFP4 tensor cores exist only in the Blackwell generation, so the 4-bit path cannot be used as-is on prior-generation GPUs. The SGLang serving command from the model card is:

pip install -U "transformers>=5.3.0" && \
python3 -m sglang.launch_server \
    --model nvidia/GLM-5.2-NVFP4 \
    --tensor-parallel-size 8 \
    --quantization modelopt_fp4 \
    --tool-call-parser glm47 \
    --reasoning-parser glm45 \
    --trust-remote-code \
    --chunked-prefill-size 131072 \
    --mem-fraction-static 0.80

Several signals are worth noting. --tensor-parallel-size 8 means the model assumes an 8-GPU node, not a single GPU. --quantization modelopt_fp4 tells the runtime to recognize the NVFP4 format produced by ModelOpt. --chunked-prefill-size 131072 splits the prefill phase when handling 1M-token contexts to prevent memory spikes, and is a stability-critical setting for long-context serving. --tool-call-parser glm47 and --reasoning-parser glm45 handle the GLM-family’s tool-call and reasoning-token formats, wiring directly into agentic workloads.

For a rough memory estimate: loading 753B at BF16 would require roughly 1.5 TB [estimated]. Because the routing experts hold most of the parameters and are quantized to 4-bit, actual weight memory drops to around one-third of that, putting it within range of a single 8-way tensor-parallel node (community NVFP4 mirror reports suggest roughly 1.37 TB to 459 GB, approximately a 3x reduction [estimated]). The model card does not publish exact GB figures before and after quantization, so these memory values carry the [estimated] label. What is unambiguous is that --tensor-parallel-size 8 signals: a single Blackwell 8-GPU node can serve this 753B reasoning model with a 1M-token context.

Implications for ThakiCloud’s Kubernetes AI/ML SaaS platform

ThakiCloud operates a multi-tenant platform that schedules GPUs with Kueue and serves models with vLLM on Kubernetes. In that environment, a pre-quantized frontier checkpoint like nvidia/GLM-5.2-NVFP4 is meaningful on three fronts.

First, the pool of self-hostable candidates grows. A 753B-scale reasoning model is normally ruled out of self-hosting consideration early, but if a 4-bit quantization brings weights and KV headroom within a single 8-GPU Blackwell node, on-premises serving becomes a realistic option. Using Kueue’s ResourceFlavor and ClusterQueue to carve out a dedicated Blackwell node pool for NVFP4 inference means the memory headroom gained through quantization translates directly into more concurrent tenants served. For customers who cannot send data to external APIs, particularly regulated sectors like government or finance where self-hosting and data sovereignty are requirements, providing frontier reasoning capability on-premises is itself a competitive differentiator.

Second, the quantization pipeline does not need to be run internally. Calibrating and quantizing a 753B model with ModelOpt is a substantial GPU-hours and engineering undertaking on its own. If a NVIDIA-validated checkpoint can be pulled and loaded directly into vLLM or SGLang, internal effort can shift from quantization validation to multi-tenant routing, autoscaling, and cost observability. That said, ThakiCloud’s skill system already has an internal workflow for quantizing Qwen3-MoE-family models to NVFP4, so the recipe NVIDIA used for GLM-5.2, “routing experts at 4-bit, shared experts and attention at BF16,” is now a general pattern we can apply when quantizing customer-domain models.

Third, selective quantization is worth encoding into our model intake criteria. The principle this model demonstrates, quantize aggressively where parameters are numerous and sparsely used, conservatively where they are few and always active, transfers directly to how we evaluate other MoE models. Rather than blanket 4-bit across the board, checking whether shared experts and attention are preserved can become a specific gate in the model intake review. That said, the Blackwell requirement is a hard constraint tied directly to our GPU pool composition. Any plan to use the NVFP4 path must explicitly list Blackwell node availability as a prerequisite in the adoption roadmap.

Limitations and counterpoints

The biggest limitation is hardware lock-in. The NVFP4 4-bit path requires Blackwell tensor cores, so environments with only prior-generation GPUs such as Hopper (H100/H200) cannot directly leverage this checkpoint’s advantages. The narrative of “cheap because it’s 4-bit” only holds if Blackwell nodes are already available or planned, and in many cases implies new capital expenditure.

Second, benchmark scope is narrow. The model card’s accuracy table covers five benchmarks, all oriented toward English-language reasoning, coding, and agentic tasks. Multilingual quality in real-world use (including Korean), and recall stability when the full 1M-token context is actually filled, cannot be assessed from the published table alone. Internal evaluation against domain-specific data, measuring regression relative to BF16 and FP8 baselines, is required before adoption.

Third, memory figures are uncertain. As noted above, the model card does not publish exact memory usage before and after quantization. The memory estimates in this post are back-calculated from parameter count and quantization scope. In production, adding KV cache and the 1M prefill buffer on top of weight memory means peak memory per node exceeds the weight-only estimate. Capacity planning must be based on peak memory, not weight memory alone.

Fourth, selective quantization is a tradeoff in both directions. Keeping shared experts and attention in BF16 preserves accuracy, but it also means memory savings are smaller than a full 4-bit approach. This model is “compress as far as accuracy allows,” not “compress as much as physically possible.” For extreme cost-constrained environments where loading onto a single workstation GPU is the goal, more aggressive options like 1-bit GGUF may be a better fit, at the cost of additional quality loss.

In summary, nvidia/GLM-5.2-NVFP4 is a concrete example of bringing a frontier 753B MoE reasoning model down to 4-bit without meaningful accuracy loss, making self-serving on a Blackwell 8-GPU node a viable choice. For ThakiCloud, it adds one more card to the hand for delivering frontier reasoning to customers with on-premises or data-sovereignty requirements, and it provides a general-purpose principle, selective quantization, that can be embedded directly into our model intake process. The door opens with a Blackwell key.

Sources

• nvidia/GLM-5.2-NVFP4 on Hugging Face
• Base model GLM-5.2 (ZAI) on Hugging Face
• NVIDIA Model Optimizer on GitHub
• Introducing NVFP4 for Efficient and Accurate Low-Precision Inference (NVIDIA Technical Blog)

Competition among open-weight coding models has moved beyond “what benchmark score did you hit?” toward “what training method produced that score?” Ornith-1.0, released by DeepReinforce on June 25, 2026, is a model where the methodology itself is the headline. The reinforcement learning design lets the model write the training scaffold that guides its own solutions at the same time it generates those solutions.

The benchmark numbers in this post are not results we reproduced ourselves. Running a 397B model through coding benchmarks requires multi-GPU nodes and hours of inference, which we did not do for this intraday analysis. Every score cited here is a figure stated in DeepReinforce’s public materials; values where sources differ are marked [estimated]. We have not fabricated any reproduction numbers.

Overview

Ornith-1.0 is not a single model but an open-source family specialized for coding. It spans four sizes: 9B dense, 31B dense, 35B Mixture-of-Experts (MoE), and the 397B MoE flagship. All four are MIT-licensed and immediately downloadable from the deepreinforce-ai namespace on Hugging Face. Quantized variants, including 9B and 35B GGUF and 35B and 397B FP8, are also available, signaling an intentional deployment spectrum from single-GPU edge to multi-node datacenter.

Two things stand out immediately from ThakiCloud’s perspective: the license and self-hosting viability. MIT imposes no copyleft infection, no non-commercial clause, and no legal friction for commercial or non-commercial use. For organizations that want to run a coding agent on their own infrastructure without sending proprietary code to an external API, MIT is the cleanest possible “yes, you can.”

The one-sentence summary: Ornith-1.0 does not just learn solutions during the RL phase; it also learns the per-task training scaffold that produces those solutions. Treating the scaffold as a learned variable rather than a fixed constant is the key divergence from other RL coding models.

The original announcement tweet described this as “the first open-source model from a US lab that codes at frontier level.” We were unable to independently verify DeepReinforce’s headquarters location from public sources, so this post focuses on the verifiable mechanism and public numbers rather than the geographic framing.

What This Model Is

Ornith-1.0 is built by applying post-training on top of pretrained base models. DeepReinforce stated it used Gemma 4 and Qwen 3.5 series as bases. This means the model was not pretrained from scratch; instead, the team applied their own RL post-training to strong open bases to sharpen coding capability. That structure mirrors the broader open ecosystem trend of “base as shared asset, differentiation through post-training,” similar to how NVIDIA redistributes third-party models after quantization.

The model itself is a reasoning model. By default it opens assistant responses with a <think> ... </think> block, working through its reasoning before producing a final answer. The published serving recipe activates a reasoning parser that routes this thinking process to a separate reasoning_content field, alongside a tool-call parser that exposes the model’s tool invocation blocks as OpenAI-style tool_calls. The design intent is clear: plug it straight into an existing agent loop. The maximum context length is 262,144 tokens, sized for long-horizon coding tasks that push a large repository into a single context window.

DeepReinforce is not new to RL work. Their 2025 CUDA-L1 project used reinforcement learning to auto-optimize CUDA kernels, reporting a mean 3.12x speedup and peak gains orders of magnitude higher on multiple GPU tasks. The consistent research thread of “use reinforcement learning to make code or kernels improve themselves” runs directly into this coding model.

The Core: Reinforcement Learning That Writes Its Own Scaffold

Most agentic RL training fixes the scaffold (prompt structure, tool-use conventions, task decomposition template) by hand and then trains the policy within it. A good scaffold raises scores; a bad one caps performance no matter how strong the policy becomes. The problem is that a different scaffold works best for each task type. Ornith-1.0 promotes the scaffold from a fixed constant to a learned variable.

According to DeepReinforce’s description, each RL step proceeds in two stages. First, the model proposes a refined scaffold conditioned on the given task. Second, it generates a solution rollout conditioned on that scaffold. The reward propagates back through both stages: “what scaffold did you build?” and “what did you solve on top of it?” are scored together and improved together. The scaffold co-evolves with the policy.

flowchart LR
    T["Task"] --> S1
    subgraph RLSTEP["RL step (2 stages)"]
      direction TB
      S1["Stage 1: Propose scaffold<br/>(conditioned on task)"] --> S2["Stage 2: Solution rollout<br/>(conditioned on scaffold)"]
    end
    S2 --> R["Reward"]
    R -. "propagate to scaffold" .-> S1
    R -. "propagate to policy" .-> S2
    S1 -. "Co-evolve" .- S2

This structure matters for two reasons. First, the bottleneck of humans hand-tuning scaffolds disappears. When the task distribution shifts, the model re-builds its scaffold on its own. Second, because the scaffold is exposed directly to the reward signal, the common failure mode of “the policy is fine but the scaffold is bad so the score never climbs” becomes correctable inside the training loop. This is in the same family as the Loop Engineering pattern that uses external tools (compilers, tests) as reward signals, but goes one step further by adding the scaffold itself to the set of things receiving that reward.

Public Benchmarks

The flagship numbers DeepReinforce published are as follows. All are from their own evaluation; none were reproduced in our environment.

DeepReinforce claims top-tier performance among open-source models of comparable size on Terminal-Bench 2.1, SWE-Bench, NL2Repo, and OpenClaw. Notably, the 35B MoE is reported to outperform some larger models, which reads as MoE sparsity combined with self-scaffolding post-training raising efficiency relative to active parameter count. That said, SWE-Bench variants (Verified, Pro, original) differ substantially in scoring, and comparing numbers without confirming which variant was used is risky. That is why the SWE-Bench Pro figure is marked [estimated].

More meaningful than the scores for anyone running these in production is that the source of the scores is a publicly described mechanism. Closed-model scores cannot be reproduced, but MIT-released weights and a published training description leave the door open for external verification.

Installation and Serving

Ornith-1.0 is packaged to run on standard inference stacks without modification. Starting with the smallest model before validating is the right discipline for self-hosting. The 9B is designed for a single GPU and is a reasonable starting point for pipeline integration testing.

# Download weights from Hugging Face (e.g., 9B)
huggingface-cli download deepreinforce-ai/Ornith-1.0-9B \
  --local-dir ./ornith-1.0-9b

Because this is both a reasoning model and a tool-calling model, serving it requires both the reasoning parser and the tool-call parser to be active so that the thinking process and tool invocations arrive as structured fields rather than raw text. A representative vLLM startup looks like this; confirm the exact parser names from each model card’s serving recipe.

# vLLM serving (representative form -- confirm parser names from model card)
vllm serve deepreinforce-ai/Ornith-1.0-9B \
  --max-model-len 262144 \
  --enable-auto-tool-choice \
  --tool-call-parser <see model card> \
  --reasoning-parser <see model card>

For the 397B MoE flagship, memory is the first wall. That is why the FP8 variant (Ornith-1.0-397B-FP8) ships alongside. It cuts weight memory roughly in half compared to BF16, reducing the node count and tensor parallel degree needed. The 35B MoE sits at the point where MoE’s advantage of “small active parameters, large knowledge capacity” is most balanced; it is a realistic candidate for single-node multi-GPU deployment.

# 397B: FP8 variant + tensor parallelism to lower the memory wall (skeleton example)
vllm serve deepreinforce-ai/Ornith-1.0-397B-FP8 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --enable-auto-tool-choice

Implications for the ThakiCloud K8s AI/ML SaaS Platform

ThakiCloud’s AI platform schedules GPU workloads with Kueue on Kubernetes, serves multi-tenant inference with vLLM, and operates multi-tenant agents. A model like Ornith-1.0 is relevant to this stack in three ways.

First, model sovereignty for in-house coding agents. Code is among the most sensitive assets an organization holds. The demand for running a coding agent on-premises or in a dedicated tenant, without routing internal code through a closed API, is especially strong in regulated environments such as finance, government, and defense. MIT license plus self-hostable weights answers that demand cleanly. The 262K context and OpenAI-style tool_calls output mean the base model can be swapped into an existing agent loop without changing the surrounding infrastructure.

Second, the size spectrum aligns with multi-tenant cost calculation. The 9B suits lightweight auxiliary tasks or a low-cost per-tenant tier. The 35B MoE, with its efficiency advantage in active parameters, works as the primary serving workhorse. The 397B fits a dedicated high-difficulty task pool. When GPU scheduling with Kueue determines which tenant gets which model at which priority, the unit economics are direct. Having a range of sizes within a single family means operational flexibility translates directly into cost savings.

Third, the self-scaffolding methodology is itself something we can borrow. ThakiCloud operates domain-specific agents across diverse customer environments. The cost of hand-carving per-task scaffolds grows linearly with the number of domains. The idea of “promote the scaffold to a learned variable” is a pattern we can adapt directly when designing internal pipelines that auto-improve an agent’s prompts and tool conventions through a reward signal, rather than requiring a human to tune them each time. Even if we do not adopt the model outright, the mechanism is transferable to our workflow engine.

Limitations and Counterarguments

The biggest limitation is asymmetric verification. The weights and training description are public, but the benchmark numbers are self-reported and were not reproduced in our environment. SWE-Bench variants differ substantially in score, and the same model can produce different results depending on harness configuration, temperature, and retry settings. Jumping from the reported numbers to “this has caught up to frontier” is premature. Any actual adoption decision requires internal evaluation against a sample of our own codebase.

The second concern is operational cost. The 397B MoE scores look attractive, but self-hosting at that scale means GPU memory and node count are a real constraint. The FP8 variant helps, but “open” does not mean “free” – it means we bear the infrastructure cost ourselves. The comparison between closed API token pricing and self-hosting node pricing only resolves in our favor at specific workload patterns, and that requires working through the numbers.

The third is generalization of self-scaffolding. The design is elegant, but there is no externally verified guarantee that scaffold quality holds up on unfamiliar tasks outside the training distribution. It is also plausible that the scaffold overfit to the reward signal and learned to build structures that perform well specifically on these benchmark formats. This question can only be settled when independent parties reproduce results with the public weights.

In summary, Ornith-1.0 is a model worth watching for its method more than its scores. The MIT open-weight release makes it a realistic candidate for self-hosted coding agents, and the self-scaffolding mechanism has ideas worth borrowing for agent training pipeline design regardless of whether you adopt the model itself. That said, all benchmark claims should be held as “announced figures” until validated through your own evaluation.

Sources

• DeepReinforce, “Ornith-1.0: Self-Scaffolding LLMs for Agentic Coding” (2026-06): https://deep-reinforce.com/ornith_1_0.html
• Hugging Face model cards: https://huggingface.co/deepreinforce-ai/Ornith-1.0-397B, https://huggingface.co/deepreinforce-ai/Ornith-1.0-9B
• GitHub: https://github.com/deepreinforce-ai/Ornith-1
• MarkTechPost, “DeepReinforce Releases Ornith-1.0” (2026-06-25): https://www.marktechpost.com/2026/06/25/deepreinforce-releases-ornith-1-0-an-open-source-coding-model-family-that-learns-its-own-rl-scaffolds/
• Tech Times (2026-06-26): https://www.techtimes.com/articles/319122/20260626/open-source-coding-model-ornith-10-writes-its-own-training-scaffold-reinforcement-learning.htm
• DeepReinforce, CUDA-L1 (prior research): https://deepreinforce-ai.github.io/cudal1_blog/

Overview

Anyone who has run LLM agents for any length of time will have hit the same wall. Agents handle one-shot question-answering well, but the moment you span tasks across days or context across multiple sessions, the agent forgets what it has done. That is where “agent memory” entered the picture, and at first it was little more than a RAG variant: store conversations in a vector store, retrieve on demand.

The arXiv paper Are We Ready For An Agent-Native Memory System?, published on June 23, 2026, reframes this entire trajectory in a single observation. Agent memory is no longer a retrieval-augmentation device; it has evolved into a full data-management system responsible for persistent storage, retrieval, updating, consolidation, and dynamic lifecycle management. This is the paper dair_ai summarized as “Agent memory is a data system now.”

The reframing matters because for a platform like ThakiCloud, which actually runs multi-tenant agents on Kubernetes, the moment memory becomes a “system to operate” rather than a “feature to enable,” cost, robustness, and architectural choices all follow. This post summarizes the core claims from the official abstract and the public code, and draws out what is actionable from the perspective of our platform.

📄 Full deep review (DOCX): Download the detailed peer review on Google Drive.

What This Research Does

The problem the paper identifies is simple but pointed. Most existing methods for evaluating agent memory stop at end-to-end task success metrics. Scores like F1 or BLEU answer the question “did it answer the question well?” while treating the memory system that produced the answer as a complete black box.

That framing hides exactly what an operator needs to know: how much operational cost does maintaining memory incur, what are the architectural trade-offs across different module combinations, and how robust is the system when knowledge keeps changing? A single aggregate score answers none of these.

The authors (Wei Zhou, Xuanhe Zhou, Guoliang Li, Zhiyu Li, Feiyu Xiong, and others, notably including database-systems researchers, which explains the paper’s character) therefore study memory systematically from a data-management perspective. The core of that study is an analytical framework that decomposes agent memory into four modules.

The four modules are as follows.

1. Representation & Storage: How memory is encoded and where it is kept. The choice among vectors, graphs, trees, plain text, and other representations directly determines representation fidelity.
2. Extraction: The step of selecting what to commit to memory from the agent’s execution trace. Not every token can be stored, so this stage separates signal from noise.
3. Retrieval & Routing: Finding the right memory at the right moment and returning it through the appropriate path. The metric here is retrieval precision.
4. Maintenance: Consolidating, updating, and pruning stale memories. Update correctness and long-horizon stability are determined here.

Anyone familiar with databases will recognize the correspondence: Representation & Storage maps to the storage engine, Extraction to the ingest pipeline, Retrieval & Routing to the query planner, and Maintenance to compaction and garbage collection. That mapping is precisely why the authors call their lens a “data-management perspective.”

Core Findings

On this framework, the paper evaluates 12 representative memory systems and 2 reference baselines across 5 benchmark workloads and 11 datasets. The weight of the contribution lies in measuring multiple systems against a common yardstick rather than optimizing a single model on a single dataset. Three conclusions can be drawn directly from the abstract.

First, there is no single architecture that dominates all settings. The answer to “which memory structure is best?” is “it depends.” More precisely, effectiveness is determined by how well a memory structure aligns with the workload bottleneck. The structure that is optimal for a retrieval-bottlenecked workload differs from the one that suits an update-bottlenecked workload. This is a direct rebuttal of simple prescriptions like “graph memory is always best” or “a vector store is sufficient.”

Second, decomposing at the module level separates accountability. The authors use granular ablation experiments to quantify each module’s individual contribution to representation fidelity, retrieval precision, update correctness, and long-horizon stability. This reveals what end-to-end scores collapse together: “which module breaks what.” From an operational standpoint, that is the real value. You can only fix a wrong answer if you can tell whether the failure was in the Extraction stage or the Retrieval stage.

Third, cost-performance trade-offs in Maintenance are clear. On realistic workloads, the paper finds that localized maintenance is more cost-efficient than global reorganization. Touching only what has changed costs less than periodically rebuilding the entire memory. This is the same intuition as incremental database compaction being cheaper than a full rebuild, and for cost-sensitive production deployments, this single finding can change architectural decisions.

In summary, the paper is less a prescription for “how to build better agent memory” and more a framework for “how to measure and compare agent memory as a system.” On that framework it shows there is no single right answer, but that workload alignment and maintenance cost are the real levers.

Implications for the ThakiCloud K8s AI/ML SaaS Platform

ThakiCloud’s AI platform runs multi-tenant agents across diverse customer environments on Kubernetes. Several points from this paper land directly on our platform.

Treating memory as a per-tenant data system. If agent memory is a data-management system, it follows that every tenant incurs distinct storage costs, retrieval latency, and update load as separate operational concerns. In a multi-tenant setting, ensuring that one tenant’s memory maintenance does not consume another tenant’s GPU or I/O is a problem of the same kind as isolating GPU workloads with Kueue. Memory must be treated not as a “feature” but as a “workload with a resource budget.”

Designing for pluggable rather than fixed memory architectures. The conclusion that no single architecture dominates implies that a platform should provide abstractions that allow memory structures to be swapped or composed by workload, rather than hard-coding a single memory backend. Depending on whether a customer’s agent is long-session conversational or rapid-knowledge-update oriented, the platform should support switching between retrieval-centric and maintenance-centric structures. The four-module decomposition provides natural boundaries for exactly that kind of pluggable abstraction.

An asset for on-premise and cost-sensitive deployments. The finding that localized maintenance is cheaper than global reorganization is especially relevant for customers who self-host on-premise. It provides a design principle for controlling memory-maintenance costs within a finite in-house GPU and storage budget, without depending on an externally managed memory service. For customer environments where regulations or data-sovereignty requirements preclude external API calls, the ability to say “memory maintenance costs are predictable and contained inside your own cluster” is a direct sales point.

Two concrete actions are available to us now. One is to use the 4-module decomposition and workload taxonomy from the public MemoryData code as a starting point for instrumenting tenant memory, observing it via per-module metrics (representation fidelity, retrieval precision, update correctness, long-horizon stability) rather than end-to-end scores. The other is to set the default maintenance policy to localized updates rather than global reorganization, baking a cost ceiling into the design from the start.

Limitations and Counterarguments

For balance, there are points to note before accepting the findings wholesale.

First, this paper is a measurement study, not a proposal for a new memory system. Readers expecting a blueprint for building better memory will be disappointed. What is offered is a comparative framework and diagnosis; “promising directions toward agent-native memory” are indicated, but implementation is left as future work.

Second, generalization limits of the benchmark. 5 workloads and 11 datasets is not trivial, but the domain space actual agents encounter is far broader. The conclusion that “optimal architecture varies by workload bottleneck” is also, somewhat paradoxically, a warning that if our customers’ real workloads differ from the benchmark distribution, the paper’s rankings may not transfer directly. Measurement in each deployment environment will still be necessary.

Third, potential perspective bias from the author composition. The database-systems research background makes the framing of “memory as data management” strong, but cognitive-science and reinforcement-learning perspectives on memory (episodic memory, policy-learned memory management, etc.) may receive comparatively less attention. Data management is a powerful lens, but not the only one.

Even so, the core message, “measure agent memory as a system,” is a hard-to-refute starting point for a platform that actually has to operate memory. The moment you start looking at memory through modules and costs rather than scores, what can be fixed becomes visible.

Sources

• Paper: Are We Ready For An Agent-Native Memory System? (arXiv 2606.24775)
• HF Papers: hf.co/papers/2606.24775
• Public code: github.com/OpenDataBox/MemoryData
• Original tweet context: dair_ai, “Agent memory is a data system now”

📄 Full deep review (DOCX): Download the detailed peer review on Google Drive.

Overview

The most common way to teach an agent a new capability has been to write a skill file by hand. A skill is ultimately just one Markdown document, but authoring it from scratch while respecting the required frontmatter and section order takes more effort than it sounds. That friction is especially real for things that live in your head but are tedious to write down - internal API usage, deployment runbooks, and repetitive procedures.

The /learn command that Nous Research added to its Hermes Agent framework on June 24, 2026, eliminates the hand-authoring step entirely. Point it at a directory, a URL, a conversation you just finished, or a pasted note, and the live agent collects the material directly using its own tools and authors a standard-compliant SKILL.md. The demo video shared on X by tonbistudio - showing multiple sources being combined into a skill - sparked a lot of attention, and since ThakiCloud already had Hermes Agent installed internally, we decided to verify it firsthand.

ThakiCloud runs multi-tenant agents on a Kubernetes-based AI/ML SaaS platform. The idea of an agent building its own procedural memory in a form that humans can gate and review maps directly onto the principle we call Thin Harness, Fat Skills: capabilities belong in skills, not in the harness. /learn lowers the barrier to creating those skills, which makes it more than a convenience feature.

What This Technology Is

/learn is not a separate ingestion engine. The key insight is that it constructs a standard-guided prompt and hands it to the agent as an ordinary single turn. Source collection therefore uses the tools the agent already has. Local directories are read with read_file and search_files; online documentation is fetched with web_extract; workflows carried out together in the current conversation are captured directly from conversation context.

The complete /learn path: starting from a source description, collecting via agent tools, authoring a standard SKILL.md, and passing through the write_approval gate and curator.

Four source types are accepted. The following examples are taken verbatim from the official documentation:

# Local SDK or documentation directory (read via read_file / search_files)
/learn the REST client in ~/projects/acme-sdk, focus on auth + pagination

# Online documentation page (fetched via web_extract)
/learn https://docs.example.com/api/quickstart

# A workflow you just completed with the agent in this conversation
/learn how I just deployed the staging server

# A pasted note or verbally described procedure
/learn filing an expense: open the portal, New > Expense, attach the receipt, submit

The agent organizes the collected material according to the “house authoring standard”: descriptions capped at 60 characters, a fixed section order, framing based on Hermes tools, and a rule against inventing commands that do not exist. The resulting SKILL.md consists of YAML frontmatter and fixed body sections:

---
name: my-skill
description: Brief description of what this skill does
version: 1.0.0
platforms: [macos, linux]
metadata:
  hermes:
    tags: [python, automation]
    category: devops
---

# Skill Title

## When to Use
Conditions that trigger this skill.

## Procedure
1. First step
2. Second step

## Pitfalls
- Known failure modes and solutions

## Verification
How to confirm the skill is working.

Storage is handled by the skill_manage tool. One important safety mechanism is attached here. When skills.write_approval is enabled, every skill write by the agent is staged to ~/.hermes/pending/skills/ instead of being applied immediately. A human can review pending changes with /skills pending, inspect the full diff with /skills diff <id>, and then approve or reject. This gate applies equally to skills created in a foreground turn and to skills proposed by the background self-improvement review.

Because there is no separate ingestion engine, /learn works identically across the CLI, the TUI, messaging gateways, and the dashboard. It does not matter whether the terminal backend is local, Docker, or remote. In the dashboard, a “Learn a skill” button appears on the Skills page and assembles a /learn request from a directory field, a URL field, and a free-text box.

The official documentation identifies three usage scenarios. First, internal API onboarding: run /learn against a private documentation URL and it produces a skill covering authentication, pagination, and common calls; new team members then invoke it as a slash command. Second, deployment runbook capture: step through a staging deployment with the agent, then run /learn how I just deployed the staging server and the procedure becomes repeatable across CLI and chat platforms. Third, bundling repetitive tasks: a skill bundle lets a single slash command load the review, test, and PR skills together.

# ~/.hermes/skill-bundles/backend-dev.yaml
name: backend-dev
description: Backend feature work - review, test, PR workflow.
skills:
  - github-code-review
  - test-driven-development
  - github-pr-workflow
instruction: |
  Always start by writing failing tests, then implement.

The skill system also offers an opt-out path if you want to start from a clean slate. hermes skills opt-out stops seeding bundle skills, and hermes skills opt-in --sync restores them. The platforms field hides incompatible skills on unsupported operating systems, and conditional fields expose a skill only when a specific toolset is present, giving fine-grained control over what surfaces in any given environment.

Installation and Integration

We verified the Hermes Agent installation in our ThakiCloud environment directly. The binary lives at ~/.local/bin/hermes and actually runs on Python from ~/hermes-agent/venv.

$ ~/.local/bin/hermes --version
Hermes Agent v0.16.0 (2026.6.5) · upstream 40cea4d5
Python: 3.11.13
OpenAI SDK: 2.24.0

All skills are stored in ~/.hermes/skills/, which is the single source of truth. Because Hermes is compatible with the agentskills.io open standard, you can configure multiple tools to share-scan the same skills folder:

# ~/.hermes/config.yaml
skills:
  external_dirs:
    - ~/.agents/skills
    - /home/shared/team-skills
    - ${SKILLS_REPO}/skills

That external_dirs setting is the crux of the platform perspective we cover later. We pulled the list of installed skills directly. 78 skills are currently installed, categorized under apple, autonomous-ai-agents, creative, and others:

$ ~/.local/bin/hermes skills list
                                Installed Skills
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┓
┃ Name                ┃ Category             ┃ Source  ┃ Trust   ┃ Status  ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━┩
│ claude-code         │ autonomous-ai-agents │ builtin │ builtin │ enabled │
│ architecture-diagram│ creative             │ builtin │ builtin │ enabled │
│ humanizer           │ creative             │ builtin │ builtin │ enabled │
│ excalidraw          │ creative             │ builtin │ builtin │ enabled │
└─────────────────────┴──────────────────────┴─────────┴─────────┴─────────┘

Every installed skill automatically becomes a slash command. Typing the name alone - /excalidraw - loads the skill and the agent asks how it can help; supplying an argument such as /plan design a rollout for migrating our auth provider processes the request immediately. The skill management subcommands are extensive:

$ ~/.local/bin/hermes skills --help
{browse, search, install, inspect, list, check, update, audit,
 uninstall, reset, opt-out, opt-in, repair-official, publish,
 snapshot, tap, config}

A mechanism to prevent unbounded skill accumulation is also built in. The curator runs a secondary model in the background on a schedule, reviewing agent-created skills to consolidate duplicates and archive stale ones. Bundle skills and hub-installed skills are never touched; archives are recoverable and there is no automatic deletion:

$ ~/.local/bin/hermes curator --help
{status, run, pause, resume, pin, unpin, restore,
 list-archived, archive, prune, backup, rollback}

Progressive disclosure for token cost management is confirmed as well. At level 0, an index of roughly 3,000 tokens containing only name and description loads first; the full content loads only when the work actually requires it:

Level 0: skills_list()           -> [{name, description, category}, ...]   (~3k tokens)
Level 1: skill_view(name)        -> Full content + metadata
Level 2: skill_view(name, path)  -> Specific reference file

What We Actually Tested

There is a limitation that must be stated honestly here. The version installed at ThakiCloud is v0.16.0 (2026.6.5), which predates the June 24, 2026 release that introduced /learn. Because the binary reports “Up to date” based on the local git checkout, upstream new releases are not applied automatically. We therefore could not run /learn in our environment and capture output metrics. The constraint encountered during reproduction attempts: the installed version predates /learn, so the command itself is absent.

What we could verify, we measured directly. The skill system skeleton that /learn writes into is fully operational in our environment. All 78 skills surface as slash commands, and the skill_manage-based agent self-authoring path, the skills.write_approval staging gate, the curator background cleanup, and progressive disclosure indexing are all present in the installed version. In other words, what /learn adds is a thin entry point that, given a source description, constructs a standard prompt and feeds it into the existing authoring pipeline. The heavy machinery underneath has already been verified.

The behavior of /learn itself was cross-verified against the official documentation and the June 24, 2026 MarkTechPost report. Both sources describe the same facts: four source types, read_file / search_files / web_extract as collection tools, a 60-character description cap with fixed section order, skill_manage storage, and the write_approval gate. Rather than fabricate numbers, we clearly delineate what has been verified and what has not.

Updating to the upstream release would allow us to run /learn directly and measure output quality. However, that update could affect the running multi-tenant environment, so the safe path is to verify first in an isolated profile before rolling it in. We plan to capture actual /learn output in a follow-up post.

Implications for ThakiCloud’s Kubernetes AI/ML SaaS Platform

/learn is interesting not simply because it is convenient, but because it directly addresses three problems that a multi-tenant agent platform has to solve.

The first is the cost of capturing domain knowledge. Every customer has different deployment runbooks, internal APIs, and incident response procedures. Having a human translate each of these into a SKILL.md slows onboarding. /learn turns “convert this work we just finished into a skill” into a single command that immediately converts procedural memory into a reusable asset. A staging deployment a operator walks through once becomes a repeatable command available across both CLI and chat.

The second is governance. ThakiCloud serves customers who require on-premises and self-hosted deployments, as well as environments that must meet National Intelligence Service security requirements. An agent that can write its own skills is powerful, but it also introduces the risk of unreviewed procedures accumulating automatically. The write_approval gate, which stages every skill write to ~/.hermes/pending/skills/, persists across restarts, and lets a human inspect the full diff via /skills diff before applying it, is well-suited to these environments. The design deliberately separates the benefits of automation from the control of human review.

The third is cross-tool skill sharing. Hermes’s external_dirs configuration allows multiple AI tools to share the same skills folder. ThakiCloud already operates more than 1,000 skills internally using the same agentskills.io standard. Connecting Hermes to that shared directory means a skill authored in one place works across Claude Code, Cursor, and Hermes without duplication. This is the practical implementation of Thin Harness, Fat Skills - the principle that capabilities accumulate in skills rather than in the harness - which is how you build assets that compound in value even as harnesses change.

The roughly 3,000-token progressive disclosure index also matters from a serving cost perspective. Even as the skill count grows into the hundreds, only the index enters the context on every turn; full content loads on demand. For a team running multi-tenant vLLM serving and managing per-token costs, the pattern of decoupling skill count from context cost is worth adopting directly.

Limitations and Counter-Arguments

The most significant limitation is that a human still has to review the output. /learn has a rule against inventing commands that do not exist, but the possibility that a small model misjudges what it has learned remains. The official documentation acknowledges this and recommends enabling write_approval when using a smaller model or in security-sensitive environments. In other words, /learn eliminates authoring cost but does not eliminate review cost. In fact, because skill creation becomes easier, the absence of a review gate and curator cleanup could accelerate the accumulation of low-quality skills.

Second, the trustworthiness of the source determines the trustworthiness of the output. If a document fetched with web_extract is inaccurate or outdated, the skill built on top of it inherits the same errors. The convenience of creating a skill from a single URL transfers the responsibility for source verification to the user.

Third, the clear gap in this verification is that our installed version predates /learn, so we could not measure actual output. The behavior is cross-verified through official documentation and press coverage, but metrics such as output quality, authoring time, and standard-compliance rate were not captured directly. We will obtain those numbers by running the upstream version in an isolated profile and publish them in a follow-up post.

In summary, /learn substantially reduces the friction of creating skills while moving the natural review step that friction used to provide into an explicit gate and a curator. For teams operating multi-tenant agent platforms, it reads more accurately as a governance design choice than as a convenience feature.

Sources

• Hermes Agent official documentation, Skills System: https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
• MarkTechPost, “Nous Research Adds /learn to Hermes Agent’s Skills System” (2026-06-24): https://www.marktechpost.com/2026/06/24/nous-research-adds-learn-to-hermes-agents-skills-system-capturing-workflows-as-slash-commands-without-hand-writing-skill-md/
• NousResearch/hermes-agent (GitHub): https://github.com/NousResearch/hermes-agent
• Original tweet (demo video, tonbistudio): https://x.com/hjguyhan/status/2070135061429854577