نظرة عامة

حتى الآن، كانت سير عمل البرمجة متعددة الوكلاء تجري غالباً ضمن مورد واحد فقط. ففي Claude Code مثلاً، يقود Opus العمل بينما تعمل Sonnet أو Haiku كوكلاء فرعيين. والنقطة اللافتة في fable-advisor هي أنها تبني هذا التقسيم عبر حدود الموردين. حيث يتولى Fable 5 من Anthropic طبقة التنسيق، بينما يتولى Grok 4.5 من xAI طبقة التنفيذ.

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

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

fable-advisor هي إضافة تُركَّب فوق Claude Code، وتفرض فصلاً بين ثلاثة أدوار.

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

ثانياً، المُنفِّذ (Grok 4.5) يتولى الكتابة الفعلية وحده. يستقبل المواصفات التي يسلّمها الموجّه، ويكتب Grok 4.5 الشيفرة عبر Grok CLI. وإذا تفحصنا تاريخ المستودع، نجد أنه اعتباراً من الإصدار v3 تم استبدال وكلاء التنفيذ السابقين المعتمدين على Sonnet/Opus بـ grok-implementer، ليصبح Grok 4.5 مسار الكتابة الافتراضي. بعبارة أخرى، لم تكن هذه الإضافة متعددة الموردين منذ البداية، بل هي نتاج تطور تدريجي نحو نقل مسار التنفيذ إلى نموذج منخفض التكلفة وعالي الإنتاجية.

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

إذا نظرنا إلى سير العمل الكامل بشكل تخطيطي، يكون كما يلي.

flowchart TB
    U[طلب المستخدم] --> F[موجّه Fable 5<br/>كتابة المواصفات ومراجعة diff]
    F -->|تحليل مواصفات مستقلة| S1[مواصفة A]
    F -->|تحليل مواصفات مستقلة| S2[مواصفة B]
    S1 -.Grok CLI.-> G1[منفّذ Grok 4.5 A]
    S2 -.Grok CLI.-> G2[منفّذ Grok 4.5 B]
    G1 -->|diff| F
    G2 -->|diff| F
    F --> R[نتيجة الدمج والمراجعة]

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

تثبيت الإضافة يتم بسطر واحد فقط. يكفي إضافة المستودع إلى سوق إضافات Claude Code.

claude plugin marketplace add DannyMac180/fable-advisor

يتطلب Grok CLI، المسؤول عن مسار التنفيذ، مصادقة منفصلة. فعند تسجيل الدخول عبر grok login، يعمل النظام بمصادقة OAuth قائمة على اشتراك SuperGrok أو X Premium+، وبحسب وصف المستودع، يتيح هذا المسار تشغيل وكيل التنفيذ بالاشتراك فقط ودون رسوم API لكل رمز (token). وهذه النقطة هي جوهر بنية التكلفة. فالموجّه يقوم بعدد قليل فقط من الاستدعاءات التي تتطلب حكماً، بينما تُعالَج الكمية الكبيرة من كتابة الشيفرة ضمن خطة الاشتراك، مما يقلّل إلى أدنى حد الجزء الخاضع للرسوم حسب الاستخدام.

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

كيف يعمل هذا التصميم فعلياً

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

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

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

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

تعميم نمط الموجّه والعامل

إذا نظرنا إلى fable-advisor ليس كإضافة منفردة بل كنمط تصميم، يتضح سياق أوسع. جوهر هذا النمط هو “الجلسة الرئيسية تقود فقط، والمهام الثقيلة تُفوَّض”. وكون العمل عابراً للموردين ليس سوى صورة واحدة من صور هذا النمط، إذ يصح فعلياً حتى داخل مورد واحد. فمثلاً في Claude Code، يُستخدم على نطاق واسع بالفعل تكوين يجعل Fable 5 موجّهاً، بينما يُوكَل الاستكشاف إلى Haiku، والتنفيذ إلى Sonnet، والاستدلال المعقد إلى وكلاء فرعيين من Opus. وما فعلته fable-advisor هو توسيع نطاق النماذج المستهدفة بهذا التفويض إلى ما وراء حدود المورد الواحد.

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

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

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

يتقاطع هذا التصميم بشكل لافت مع الطريقة التي تُشغّل بها ThakiCloud وكلاءها.

من منظور Paxis، يكون الارتباط الأوثق مباشرةً. فـ Paxis هو مستوى التحكم الخاص بـ ThakiCloud للسحابة القائمة على الوكلاء (Agent-Native Cloud)، ويتعامل مع تنفيذ الوكلاء المتعددين على شكل DAG كقدرة أساسية. البنية التي تُظهرها fable-advisor — “كتابة المواصفات ← تنفيذ موزّع ← مراجعة متقاطعة” — تحمل نفس الهيكل الذي يعتمده حزام أدوات المهارات (skill harness) في Paxis، حيث يُحلَّل العمل إلى مهام فرعية، وتُنفَّذ بشكل متوازٍ داخل صناديق رملية معزولة، ثم تُغلَق عبر مرحلة تحقق. وعلى وجه الخصوص، فإن المبدأ القائل بأن الموجّه لا يكتب الشيفرة مباشرة بل يركّز على الحكم وتعريف العقود، يتطابق تماماً مع فلسفة التصميم لدينا التي تستمد القدرة من بنية العقد المحيطة لا من درجة النموذج. كما أن التدفق الذي يُعيد فيه الموجّه مراجعة نتائج نماذج مختلفة، يتقاطع أيضاً مع مبدأنا التشغيلي القاضي بإغلاق توسّع الوكلاء المتعددين (fan-out) عبر مرحلة تحقق لمنع تراكم الهلوسة.

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

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

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

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

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

ومع ذلك، فإن الرسالة التي تطرحها fable-advisor واضحة. مستقبل وكلاء البرمجة لا يكمن في نموذج واحد شامل، بل في تنسيق يجمع بين النماذج الأنسب لكل طبقة. وهذا يشير بالضبط إلى نفس الوجهة التي تسلكها ThakiCloud في تعاملها مع الوكلاء المتعددين وتوجيه النماذج كمورد أساسي من الدرجة الأولى.

المصادر

• fable-advisor (GitHub)
• Grok CLI (x.ai/cli)

نظرة عامة

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

يسلك personal-monorepo-template اتجاهًا معاكسًا تمامًا. يعيد تعريف الذاكرة لا كمشكلة بحث، بل كمشكلة بنية ملفات. يوضع الأشخاص في مجلد people/، والمشاريع كحزم مشاريع، وأنماط العمل المتكررة كمهارات داخل المستودع نفسه. ويحمّل العامل هذه البنية باستمرار عبر AGENTS.md في بداية كل جلسة. فبدلًا من التطابق التقريبي للبحث المتجهي، يصل العامل إلى الذاكرة عبر عنوان دقيق هو مسار المجلد.

خلفية صاحب المشروع تضفي ثقلًا على هذا التصميم. jxnl هو صانع مكتبة الإخراج المهيكل (structured output) المسماة Instructor، والتي تُحمَّل ملايين المرات شهريًا، ويُقال إن OpenAI استشهدت بها كمصدر إلهام لميزة الإخراج المهيكل الخاصة بها. وهو حاليًا مهندس تجربة المطوّرين (Developer Experience) في فريق OpenAI Codex، ما يجعل قيمة هذا المرجع كبيرة كونه أداة صنعها شخص يشغّل عوامل البرمجة يوميًا في الميدان لحل مشكلته الخاصة.

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

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

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

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

المحور الثالث هو التسجيل التلقائي (check-in). صُمم المستودع لتشغيل تسجيل تلقائي في التاسعة صباحًا والرابعة مساءً يوميًا، حيث يلخّص حالة المشاريع والسياق المتعلق بالأشخاص لذلك اليوم ويقترح التحديثات. هذه حلقة يحدّث فيها العامل ذاكرته من تلقاء نفسه في أوقات محددة، بدلًا من انتظار استدعاء يدوي.

يوضّح المخطط التالي التدفق الكامل.

flowchart TB
    SRC[سلاك · البريد الإلكتروني · التقويم · GitHub] -->|فحص| SCAN[نص برمجي للتسجيل التلقائي]
    SCAN --> PEOPLE[اقتراح ملف people]
    SCAN --> PKT[اقتراح حزمة مشروع]
    SCAN --> AGD[اقتراح تحديث AGENTS.md]
    AGD -.تحميل مستمر عند بدء الجلسة.-> AGENT[العامل البرمجي]
    PEOPLE -.استعلام عبر مسار المجلد.-> AGENT
    SKILL[مهارات محلية داخل المستودع<br/>بما فيها write-like-me] -.تحميل تلقائي.-> AGENT
    CRON[تسجيل تلقائي يوميًا الساعة 09:00 و16:00] --> SCAN

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

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

هذا المستودع قالب (template) كما يوحي اسمه. يُدمج بنسخه إلى حساب GitHub الخاص بالمستخدم، ثم بضبط عامل البرمجة (Codex أو واجهة سطر أوامر مشابهة) ليتخذ جذر المستودع دليل عمل له. نقطة الدخول الأساسية هي ملف AGENTS.md في جذر المستودع، حيث يقرأه العامل عند بدء الجلسة ليتعرف على بنية المجلدات، وسياق الأشخاص والمشاريع، وقائمة المهارات الواجب تحميلها.

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

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

كيف يعمل هذا التصميم فعليًا

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

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

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

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

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

يتقاطع هذا التصميم مع محورَي تشغيل العوامل في ThakiCloud كليهما.

من منظور Paxis يبدو التقاطع الأكثر مباشرة. Paxis هو مستوى تحكم السحابة الأصلية للعوامل (Agent-Native Cloud) في ThakiCloud، ويتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. النمط الذي يعرضه personal-monorepo-template، أي “مهارات محلية داخل المستودع + عقد محمَّل باستمرار (AGENTS.md)”، يتطابق تمامًا مع اتجاه تصميم حاضنة المهارات في Paxis. يختار Paxis بالفعل عددًا من المهارات عبر BM25 وينفّذها في بيئة معزولة (sandbox)، ونهج هذا المستودع يجيب بوضوح، عبر بنية المجلدات، على سؤال أسبق وهو “أي معرفة توضع باستمرار في سياق الجلسة”. وبشكل خاص، إبقاء الذاكرة كملفات قابلة للقراءة البشرية وجعل كل تحديث قابلًا للتدقيق ينسجم مع نفس فلسفة Paxis التي تُمرّر كل سلوك للعامل عبر بوابات السياسات وسجلات التدقيق. فكرة استخلاص قدرة العامل من البنية المحيطة لا من درجة النموذج نفسها تتطابق شكليًا مع تصميمنا الذي يتعامل مع المهارات كموارد من الدرجة الأولى.

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

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

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

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

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

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

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

المصادر

• jxnl/personal-monorepo-template (GitHub)
• Codex-maxxing (jxnl.co)

جاء serve-sim، الذي طوره Evan Bacon من فريق نواة Expo، ليواجه هذا الحائط مباشرة. وقد ذاع صيت هذه الأداة فعلياً عندما قدّمها المطور المستقل levelsio قائلاً إنها “تتيح رؤية تطبيق iOS الذي بناه Claude Code على Mac Mini في السحابة مباشرة عبر المتصفح في الوقت الفعلي”. وشعار serve-sim بسيط: “أمر npx serve الخاص بمحاكيات آبل”.

نظرة عامة

ما يجعل serve-sim مثيراً للاهتمام هو أنه ليس مجرد أداة لعكس الشاشة. فهذه الأداة تفتح قناتين في آن واحد: الأولى هي تدفق فيديو يرسل شاشة المحاكي إلى المتصفح، والثانية قناة تحكم تتيح للمتصفح أو للوكيل التفاعل مع المحاكي. بعبارة أخرى، تجعل “المشاهدة” و”التحكم” ممكنتين عن بُعد في آن معاً.

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

تصوير لبنية تحوّل شاشة المحاكي على خادم بدون واجهة رسومية إلى تدفق يصل إلى متصفح بعيد.

ما هو serve-sim

آلية عمل serve-sim أبسط وأذكى مما قد يبدو للوهلة الأولى. لا حاجة لتثبيت إضافة (plugin) خاصة في Xcode ولا لزرع كود قياس داخل التطبيق. بدلاً من ذلك، يشغّل serve-sim عملية مساعدة صغيرة مكتوبة بلغة Swift تلتقط الإطارات المرئية لمحاكي iOS المُقلع مسبقاً عبر واجهة simctl io التي توفرها آبل.

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

flowchart TB
    A[محاكي iOS مُقلَع] --> B[عملية مساعدة بلغة Swift]
    B --> C[التقاط الإطارات المرئية<br/>عبر simctl io]
    C --> D[تدفق فيديو MJPEG<br/>حتى 60 FPS]
    C --> E[قناة تحكم عبر WebSocket]
    D --> F[واجهة معاينة React في المتصفح]
    E --> F
    E --> G[سطر أوامر الوكيل<br/>نقر، إيماءات، دوران، كاميرا]
    F -.تحكم بشري.-> E
    G -.تحكم الوكيل.-> E

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

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

عتبة الدخول إلى serve-sim منخفضة. يكفي سطر واحد على جهاز Mac يحتوي على Node.js.

npx serve-sim

بعد التشغيل، يمكن مشاهدة المعاينة محلياً على http://localhost:3200. تدعم الأداة ثلاثة أنماط استخدام: محلياً، أو عبر الشبكة المحلية (LAN) من جهاز آخر على نفس الشبكة، أو على جهاز Mac بعيد مع نفق (tunnel) يتيح الوصول من أي مكان. حالة levelsio هي النمط الثالث تحديداً، حيث يعمل serve-sim على Mac Mini سحابي بدون واجهة رسومية بينما تجري المشاهدة عبر متصفح بعيد.

يُقدَّم دمج الوكلاء عبر مهارة وكيل (Agent Skill) منفصلة. هذه المهارة، الموجودة في skills/serve-sim ضمن المستودع، تعلّم Claude Code وCursor وCodex CLI وGemini CLI وأي مضيف آخر يطبّق معيار Agent Skills المفتوح كيفية التحكم في المحاكي عبر سطر الأوامر. وتشمل هذه القدرات النقر والإيماءات وأزرار الأجهزة الفعلية ودوران الشاشة وحقن مدخلات الكاميرا، إضافة إلى تمرير التدفق إلى نافذة المعاينة الخاصة بالمضيف.

ملاحظة حول إعادة الإنتاج

بيئة التنفيذ التي كُتب فيها هذا المقال هي جلسة معالجة دفعية بدون واجهة رسومية، حيث تشغيل Node.js محظور بموجب السياسة المتبعة، لذا لم يتسنَّ تشغيل npx serve-sim مباشرة والتقاط الشاشة فعلياً. وعليه، فإن الأوامر ووصف السلوك في هذا المقال مستندة إلى ما ورد في ملف README الخاص بالمستودع والمواد التعريفية الرسمية، دون اختلاق أي أرقام قياس أداء. يُنصح بالتحقق من مشهد بث المحاكي الفعلي وزمن الاستجابة الحقيقي عبر تشغيل الأمر أعلاه مباشرة في بيئة macOS مع محاكي Xcode مُقلَع.

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

يبدو serve-sim للوهلة الأولى أداة موجهة لمطوري iOS، لكن خلفها يكمن تيار أوسع هو التطوير المصمم أصلاً للوكلاء (agent-native development).

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

عدسة ai-platform (بنية التنفيذ بدون واجهة رسومية). تكمن الجاذبية الحقيقية لـ serve-sim في عمله على جهاز Mac بعيد بدون واجهة رسومية. وفكرة البناء والبث على خادم بدون واجهة رسومية تشبه فلسفياً الطريقة التي تجدول بها منصة ai-platform من ThakiCloud أعباء العمل وتنفذها على Kubernetes دون الحاجة إلى واجهة رسومية. وأي خط أنابيب (pipeline) يُلحق فيه مشغّل macOS المطلوب لبناء تطبيقات iOS عند الطلب، يبني الوكيل عليه ويختبر تلقائياً، ثم يُبث النتيجة فقط إلى المستخدم البشري، يمكن أن يمتد إلى ما هو أبعد من التكامل المستمر (CI) نحو “ضمان جودة يقوده الوكيل”. وهذه بنية تجعل فيها البنية التحتية للتنفيذ بدون واجهة رسومية منخفضة التكلفة (ai-platform) ركيزة تدعم جدوى أتمتة الوكلاء اقتصادياً (Paxis).

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

هناك عدة نقاط ينبغي تناولها بموضوعية.

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

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

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

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

المصادر

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio، تغريدة تعريفية بـ serve-sim. https://x.com/levelsio/status/2075328941317886210

نظرة عامة

إذا سبق لك تشغيل نموذج لغوي كبير محليا، فمن المرجح أنك رأيت تسميات مثل Q4_K_M وQ5_K_M وQ8_0. يتوقف معظم الناس عند فهم مفاده أن “Q4 يعني 4 بت، إذن لا بد أنه الأصغر والأسرع”، ثم يقومون بتحميل الملف وتشغيله مباشرة. لكن هذه التسمية تخفي أكثر مما تظهر. قلة قليلة من الناس فتحوا فعليا ملفا موسوما بـ Q4_K_M وتحققوا، مصفوفة تلو الأخرى، مما إذا كان ممتلئا حقا ببيانات ذات 4 بت.

هذا المقال موجه لقادة الهندسة، والممارسين المسؤولين عن تكلفة الاستدلال، والفرق التي تسعى لتقديم النماذج محليا (on-premises). قمنا بتحميل ملف GGUF لنموذج Qwen2.5-0.5B-Instruct على عدة مستويات تكميم، وقسنا أحجام الملفات الفعلية، وقمنا بتشريح ملف واحد من نوع Q4_K_M بشكل كامل مصفوفة تلو الأخرى. جاءت النتيجة مختلفة تماما عن الحدس. نوضح لماذا يهم فهم هذه الفجوة لتكلفة الخدمة وجودتها، وماذا يعني ذلك بالنسبة لبنية الاستدلال التحتية لدى ThakiCloud.

ولنذكر الخلاصة أولا: في ملف Q4_K_M الخاص بهذا النموذج، لم تشكل المصفوفات التي هي فعلا تكميم K رباعي البت (Q4_K) سوى 6.1 بالمئة من إجمالي سعة الأوزان، وكان عرض البت الفعلي للملف ليس 4 بل 6.16 بت. أي أن التسمية كانت أقرب إلى كذبة تقريبا.

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

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

تنقسم أنواع التكميم في llama.cpp إلى فئتين رئيسيتين. الأولى هي الفئة القديمة (legacy) (Q4_0، Q5_0، Q8_0) التي تجمع 32 وزنا في كتلة واحدة. والثانية هي فئة تكميم K (Q4_K، Q5_K، Q6_K) التي تجمع 256 وزنا في كتلة فائقة واحدة (superblock). ولأن تكميم K يقسم المقياس (scale) والحد الأدنى داخل الكتلة الفائقة بشكل أدق، فإنه يقدم جودة أفضل من الفئة القديمة عند نفس عرض البت. الحرف K في Q4_K_M يشير إلى تكميم K هذا، بينما M يعني الإعداد المسبق “المتوسط” الذي يرفع بعض المصفوفات الحساسة إلى دقة أعلى (Q6_K).

بالنظر عن قرب إلى بنية الكتلة الفائقة، يتضح سبب كفاءة تكميم K الأعلى. على سبيل المثال، يخزن Q4_K 256 وزنا في 144 بايت. من ذلك، تشغل القيم النقية ذات 4 بت مساحة 256 × 4 بت = 128 بايت، أما البايتات الـ16 المتبقية فهي بيانات وصفية تقسم الكتلة الفائقة إلى 8 كتل فرعية وتعيد تكميم مقياس كل منها وحدها الأدنى بـ6 بت. بعبارة أخرى، القيم نفسها ذات 4 بت، لكن الاحتفاظ بمقاييس دقيقة لإعادة بنائها يقلل من الخطأ. وهذا يتباين مع Q4_0 القديم الذي يحتفظ بمقياس واحد فقط لكل 32 وزنا. لذا فإن عرض البت الفعلي لـ Q4_K هو 144 × 8 ÷ 256 = 4.5 بت، أكبر قليلا من 4 بت النقية، لكن الجودة أكثر استقرارا بكثير.

هناك قيد حاسم واحد هنا. لا يمكن استخدام تكميم K إلا عندما يكون عدد أعمدة المصفوفة (ne[0] بمصطلحات ggml) قابلا للقسمة على 256. والسبب أن الكتلة الفائقة تعمل بوحدات من 256. وإذا لم يتحقق هذا الشرط، فإن llama.cpp يعود بصمت إلى الفئة القديمة (غالبا Q5_0). هذه القاعدة الواحدة تفسر نتيجة تجربة اليوم بأكملها.

flowchart TB
    A["ملف GGUF (Q4_K_M)"] --> B["تحديد النوع لكل مصفوفة<br/>llama_tensor_get_type()"]
    B --> C{"هل عدد الأعمدة ne[0]<br/>قابل للقسمة على 256؟"}
    C -->|"نعم"| D["استخدام تكميم K<br/>Q4_K / Q6_K (كتلة فائقة 256)"]
    C -->|"لا"| E["العودة إلى الفئة القديمة<br/>Q5_0 (كتلة 32)"]
    B --> F["رفع الدقة للمصفوفات الحساسة"]
    F --> G["output.weight -> Q8_0<br/>attn_v.weight -> Q8_0<br/>ffn_down.weight -> Q6_K"]
    D --> H["تجميع عرض البت الفعلي"]
    E --> H
    G --> H
    H --> I["عرض البت الفعلي لكامل الملف = 6.16<br/>(التسمية 'Q4' = 4.0)"]

الإعداد والتكامل

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

# 1) تثبيت أداة القراءة والتحميل
pip install gguf huggingface_hub

# 2) تحميل ملف واحد فقط من نوع Q4_K_M (أقل من 500 ميجابايت لأنه نموذج 0.5B)
hf download Qwen/Qwen2.5-0.5B-Instruct-GGUF \
  qwen2.5-0.5b-instruct-q4_k_m.gguf --local-dir ./gguf

فيما يلي الشيفرة الخاصة بفتح أنواع مصفوفات الملف المحمل. يحتوي رأس (header) ملف GGUF على اسم كل مصفوفة وأبعادها ورقم نوع ggml مباشرة، لذا فإن مجرد تجميع هذه القيم يكشف بالضبط ما الذي يملأ الملف فعليا.

from collections import Counter
from gguf import GGUFReader

r = GGUFReader("gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf")
hist = Counter()
for t in r.tensors:
    hist[t.tensor_type.name] += 1
    # التحقق من النوع الفعلي لبعض المصفوفات التمثيلية
    if t.name in ("token_embd.weight", "output.weight",
                  "blk.0.attn_v.weight", "blk.0.ffn_down.weight",
                  "blk.0.attn_q.weight"):
        print(f"{t.name:26s} {t.shape} -> {t.tensor_type.name}")
print(dict(hist))

عدد البايتات لكل كتلة يأتي مباشرة من تعريفات ggml. فمثلا، يخزن Q4_K 256 وزنا في 144 بايت أي 4.5 بت لكل وزن، ويخزن Q6_K 256 وزنا في 210 بايت أي 6.5625 بت لكل وزن، بينما يخزن Q5_0 القديم 32 وزنا في 22 بايت أي 5.5 بت لكل وزن. وبجمع (عدد العناصر ÷ حجم الكتلة) × بايتات الكتلة لكل مصفوفة، يمكن حساب عرض البت الفعلي للملف بدقة.

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

أولا، أحجام الملفات. هذه هي القيم المقاسة فعليا لنفس النموذج بعد تحميله على 7 مستويات تكميم، مقارنة بالأصل بصيغة fp16 (1266 ميجابايت).

هناك ما يثير الغرابة بالفعل هنا. الفرق بين Q2_K (415 ميجابايت) و Q4_0 (429 ميجابايت) هو 14 ميجابايت فقط. خفضنا عدد البتات إلى النصف، لكن حجم الملف لم ينخفض تقريبا. بل إن Q4_K_M (491 ميجابايت) أكبر فعليا من Q4_0 (429 ميجابايت) ذي 4 بت النقية. بالنظر إلى الأسماء وحدها، هذه النتيجة غير مفهومة.

يتضح السبب الحقيقي عند فتح ملف Q4_K_M مصفوفة تلو الأخرى. فيما يلي توزيع الأنواع عبر 291 مصفوفة فيه.

على الرغم من تسمية Q4_K_M، لم يشكل تكميم K الحقيقي رباعي البت (Q4_K) سوى 6.1 بالمئة من إجمالي سعة الأوزان. وبدلا من ذلك، استحوذ النوع القديم Q5_0 ذو 5.5 بت على أكثر من النصف (54.9 بالمئة)، واستهلك Q8_0 ذو 8.5 بت نسبة 30 بالمئة. وعند حساب عرض البت الفعلي لكامل الملف، نحصل على 6.16 بت، أي أكثر من 1.5 ضعف الـ4 بت التي توحي بها التسمية.

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

• token_embd.weight (896 × 151936) -> Q5_0
• output.weight (896 × 151936) -> Q8_0
• blk.0.ffn_down.weight (4864 × 896) -> Q6_K
• blk.0.attn_v.weight (896 × 128) -> Q8_0
• blk.0.attn_q.weight (896 × 896) -> Q5_0

هل تلاحظ النمط؟ لم تظهر المصفوفات التي تحمل تكميم K (Q4_K، Q6_K) إلا حيث كان عدد الأعمدة ne[0] يساوي 4864، كما في ffn_down. والرقم 4864 قابل للقسمة على 256 (19 × 256). أما معظم المصفوفات الأخرى فعدد أعمدتها ne[0] يساوي 896، والرقم 896 غير قابل للقسمة على 256 (3.5 × 256). لذلك لم تتمكن هذه المصفوفات من استخدام تكميم K إطلاقا وعادت جميعها إلى الفئة القديمة Q5_0. وإذا أضفنا إلى ذلك رفع الدقة (Q5_0، Q8_0) للمصفوفات الحساسة للجودة مثل التضمين (embedding) والمخرجات وقيمة الانتباه (attention value)، نحصل على ملف موسوم بـ Q4_K_M لكن جوهره الفعلي كتل تتراوح بين 5.5 و8.5 بت.

هذا بالضبط مصدر عرض البت الفعلي البالغ 6.16. يحتوي هذا الملف على ما مجموعه 630 مليون وزن خاضع للتكميم، مخزنة في نحو 485 ميجابايت من البايتات. 485,452,288 بايت × 8 ÷ 630,167,424 وزنا = 6.16 بت لكل وزن. وبإضافة نحو 6 ميجابايت من البيانات الوصفية للملف وحشو المحاذاة (alignment padding)، تتطابق النتيجة تماما مع حجم الملف الفعلي البالغ 491 ميجابايت. وتطابق الحساب مع حجم الملف هو أيضا دليل على دقة قراءة أنواع المصفوفات.

هذا يفسر أيضا النقطتين الغريبتين في جدول أحجام الملفات. السبب في أن Q2_K (415 ميجابايت) أصغر بالكاد من Q4_0 (429 ميجابايت) هو أن مصفوفات التضمين والمخرجات في هذا النموذج الصغير تشكل حصة كبيرة من إجمالي الأوزان، وهي تبقى بدقة عالية عند أي مستوى تكميم. مهما خفضت عدد البتات، تبقى تكلفة ثابتة في القاع لا تنخفض. أما سبب كون Q4_K_M أكبر من Q4_0 النقي ذي 4 بت، فهو أن الإعداد المسبق M دفع ثمن رفع المصفوفات الحساسة إلى Q6_K وQ8_0 على شكل زيادة في حجم الملف. رقم التسمية أقل، لكن عرض البت الفعلي أعلى في الواقع.

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

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

اقتصرت هذه التجربة على تشريح نموذج صغير واحد، لكن دروسها تنتقل مباشرة إلى بنية الخدمة الإنتاجية التحتية. تقدم منصة ai-platform التابعة لـ ThakiCloud النماذج لبيئات عملاء متنوعة فوق Kubernetes وجدولة موارد GPU القائمة على Kueue. وفي هذا السياق، فإن “أي تكميم نختار” ليس مسألة ذوق، بل قرار يحدد تخصيص ذاكرة GPU، وحجم الدُفعة (batch)، وفي النهاية التكلفة لكل رمز (token).

الثقة بالتسمية كما هي تخل بتخطيط السعة. إذا افترضت أن Q4_K_M يعني “4 بت، إذن ربع الحجم الأصلي” وخصصت ذاكرة GPU على هذا الأساس، فستجد، كما في التجربة أعلاه، أنه يستهلك فعليا نحو 40 بالمئة من الأصل، وتنفد فتحات الدُفعات أسرع مما هو متوقع. يهم هذا الأمر بشكل خاص في الخدمة متعددة المستأجرين (multi-tenant)، حيث يجب حشر العديد من النماذج الصغيرة بكثافة على عقدة واحدة. وهناك، فإن الفرق بين قياس عرض البت الفعلي فعليا والاكتفاء بالثقة بالتسمية ينعكس مباشرة على عدد النماذج التي يمكن للعقدة استيعابها. لهذا السبب بالتحديد نتحقق من ملفات GGUF مصفوفة تلو الأخرى عند بناء صور الخدمة (serving images). وبالنسبة للعملاء الذين يتطلبون استضافة ذاتية أو نشرا محليا أو سياديا على وجه الخصوص، تتحول عادة القياس هذه بدلا من الافتراض إلى ميزة تنافسية حقيقية من حيث التكلفة.

جعل هذا التحقق نفسه مهمة قابلة للتكرار هو دور Paxis. وPaxis هي منصة التحكم الخاصة بـ ThakiCloud للسحابة الأصلية للوكلاء (Agent-Native Cloud) التي تعمل فوق ai-platform، وتتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. فإذا تم تسجيل تجربة اليوم، أي تحميل ملف GGUF وتجميع أنواع المصفوفات وإطلاق تحذير عند تجاوز عرض البت الفعلي حدا معينا، كمهارة واحدة، فإنها تعمل في بيئة معزولة (sandbox) وتمر جميع النتائج عبر بوابات السياسات وسجلات التدقيق. وبدلا من أن يفتح شخص الملف يدويا في كل مرة يصل فيها نموذج جديد إلى السجل، يعمل هيكل معتمد (validated skeleton) تلقائيا. هكذا يترابط الاقتصاد الذي تخلقه الخدمة منخفضة التكلفة (ai-platform) مع التنسيق (Paxis) الذي يجعل تلك الخدمة قابلة للتكرار بأمان.

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

هناك بعض النقاط التي يجب توضيحها بشكل صريح.

أولا، هذه النتائج تقترب من حالة قصوى خاصة بنموذج Qwen2.5-0.5B الذي يبلغ حجمه المخفي 896. أما في النماذج الأكبر التي يكون فيها الحجم المخفي من مضاعفات 256 (مثل 4096 أو 8192)، فإن تكميم K يُطبق بشكل طبيعي، ويقترب عرض البت الفعلي لـ Q4_K_M كثيرا من التسمية، عند نحو 4.8 بت.

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

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

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

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

المصادر

• مستودع نموذج Qwen2.5-0.5B-Instruct-GGUF: huggingface.co/Qwen/Qwen2.5-0.5B-Instruct-GGUF
• وثائق التكميم في llama.cpp: github.com/ggml-org/llama.cpp
• تم قياس أحجام الملفات وتوزيعات أنواع المصفوفات وعروض البت الفعلية مباشرة من ملفات فعلية تم تحميلها من المستودع أعلاه.

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

نظرة عامة

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

أجابت ذاكرة الوكلاء حتى الآن على هذا السؤال في الغالب بمعايير وصفية: هل هذا مرتبط بالموضوع؟ هل هو بارز؟ هل يُلخَّص بشكل جيد؟ تجادل هذه الورقة، “Remember the Decision, Not the Description” (arXiv 2605.10870)، التي شارك في تأليفها باحث من Meta AI، بأن هذا المعيار نفسه خاطئ. هذا المقال موجّه للمهندسين والباحثين الذين يصممون وكلاء الذكاء الاصطناعي، وللفرق التي تحتاج إلى وضع ذاكرة طويلة المدى في الإنتاج. نلخّص هنا إعادة الصياغة الجوهرية للورقة والنتائج التجريبية الداعمة لها، ونستعرض كيف ينطبق هذا المبدأ على Paxis، منصة الوكلاء لدى ThakiCloud.

أين تكمن المشكلة

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

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

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

الفكرة الجوهرية: rate-distortion محوره القرار

ينقل المؤلفون هذه المشكلة إلى إطار نظرية المعلومات الخاص بـ rate-distortion. تتناول نظرية rate-distortion أصلاً مقدار التشويه (distortion) الناتج عن قدر معين من الضغط (rate)، والخطوة المحورية هنا هي إعادة تعريف التشويه نفسه. بدلاً من أن يكون التشويه خطأ إعادة بناء الإشارة، يُعرَّف كـ الخسارة في جودة القرار القابلة للتحقيق نتيجة الضغط (decision loss).

flowchart TB
    A["تاريخ تفاعل طويل<br/>(ميزانية ذاكرة ثابتة)"] --> B{"هل ندمج الموقفين؟"}
    B --> C["معيار محوره الوصف<br/>الصلة، البروز، جودة التلخيص"]
    B --> D["معيار محوره القرار<br/>هل تسبب الحالة المشتركة تعارضاً في القرار"]
    C --> E["الدمج إذا بدا الموقفان متشابهَين<br/>-> دمج سلوكَين متعارضَين في واحد"]
    E --> F["أخطاء قرار مستمرة"]
    D --> G["الفصل فقط عند إثبات تعارض القرار<br/>certified refinement"]
    G --> H["حدّ نسيان دقيق (exact forgetting boundary)<br/>+ حدود memory-distortion frontier"]
    H --> I["جودة قرار أفضل عند نفس الميزانية"]

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

يترتب على هذا التعريف أمران. أولاً، حد النسيان الدقيق (exact forgetting boundary)، الذي يحدد بدقة حدود ما يمكن نسيانه بأمان دون الإضرار بجودة القرار. ثانياً، حدود memory-distortion frontier، التي تصف منحنى المفاضلة الأمثل بين ميزانية الذاكرة وجودة القرار. بعبارة أخرى، تضع الورقة نظرياً حداً أدنى مفاده: “إذا خفّضت الميزانية بهذا القدر، فستنخفض جودة القرار حتماً بمقدار لا يقل عن كذا”.

DeMem: تحويل النظرية إلى خوارزمية

DeMem هي التي تنقل هذه النظرية إلى ذاكرة وكيل فعلية قائمة على الخانات (slots). DeMem خوارزمية تعلّم ذاكرة عبر الإنترنت (online)، وتعمل وفق مبدأ واحد: لا تُقسِّم قسمة الذاكرة (partition) إلا عندما تُثبت البيانات (certify) أن حالة مشتركة تسبب تعارضاً في القرار.

كلمة “تُثبت” هنا مهمة. لا يُفصل الموقفان بمجرد أن يبدوا مختلفَين، بل يُفصلان فقط بعد أن تتراكم أدلة فعلية على أن نفس حالة الذاكرة تتطلب قرارَين مختلفَين. وعلى العكس، إذا لم تتوفر مثل هذه الأدلة، يُبقى على الدمج توفيراً للميزانية. هذا التحفظ هو جوهر الطريقة. الفصل المتسرع يهدر الميزانية ولا يترك مكاناً للتمييزات المهمة فعلاً، بينما الدمج المتسرع يطمس سلوكيات متعارضة. certified refinement هو الانضباط الذي ينتظر، بين هذين الحدين، حتى تتحدث البيانات. يثبت المؤلفون أن هذا الإجراء يحقق ضماناً من نوع near-minimax regret، أي أن الندم (regret) بالمقارنة مع الأمثل يظل، حتى في أسوأ الحالات، مقيداً قريباً من الحد النظري.

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

نتائج التجارب

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

استمرت النتائج في معايير القياس الفعلية أيضاً. فيما يلي القيم المقاسة للدرجة الإجمالية على LoCoMo (بنموذج GPT-4.1-mini الأساسي).

حقق DeMem أفضل درجة إجمالية، وكان قوياً بشكل خاص في فئات Temporal وOpen-Domain وMulti-Hop، حيث يكون الحفاظ على التمييز بين تفاعلات بعيدة زمنياً أمراً حاسماً. أما في فئة Single-Hop، التي تتعلق باسترجاع حقيقة واحدة، فقد تفوّق Mnemis (0.940) على DeMem (0.935) بفارق ضئيل، وهو ما يتفق مع تفسير أن فائدة الفصل المحوري بالقرار تكون أصغر في الاسترجاع أحادي الخطوة. وفي LongMemEval أيضاً، حقق DeMem أفضل متوسط درجات على كلا النموذجَين الأساسيَين، وكانت أكبر المكاسب في الفئات التي تتطلب دمجاً عبر جلسات متعددة. والأهم أن الأفضلية استمرت حتى على النموذج مفتوح الأوزان Llama-3.1-70B، مما يدل على أن هذه الميزة ليست مرتبطة بنموذج تجاري معين.

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

تلتقي رؤية هذه الورقة تماماً مع تصميم الذاكرة في Paxis، مستوى التحكم لمنصة Agent-Native Cloud لدى ThakiCloud. Paxis هو مستوى تحكم يعمل فوق ai-platform ويتعامل مع المهارات (skills) والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى، وضمن ذلك يحدد محرك المعرفة وطبقة الذاكرة يومياً ما الذي يُدمج وما الذي يُفصل.

أولاً، يمكن نقل معيار الدمج في محرك معرفة HKE Wiki ليصبح محورياً بالقرار. إذا دُمجت العناصر المتشابهة بمجرد التشابه النصي، فهناك خطر أن تُدمج حالتان تتطلبان إجراءَين متعارضَين في واحدة. وضع بوابة قبل الدمج مباشرة تسأل “هل يسبب هذان الأمران سلوكَين مختلفَين؟” هو نقل مباشر لمبدأ certified refinement في هذه الورقة.

ثانياً، يمنح هذا أساساً نظرياً لإدارة ميزانية الذاكرة الساخنة المقيمة في الجلسة (session-resident hot memory). الذاكرة الساخنة تفرض بالفعل ميزانيتها بحد أقصى من الأحرف، ومحاذاة معيار ما يُبقى وما يُحذف مع مبدأ “الحفاظ على التمييزات المؤثرة في القرار” يرفع جودة التقليم (pruning). أي إعطاء الأولوية للعناصر التي تفرّق بين القرارات، لا العناصر التي تُلخَّص بسلاسة.

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

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

لا بد من توضيح بعض النقاط.

أولاً، الإثبات (certify) له تكلفة. إثبات تعارض القرار من البيانات يتطلب تراكم ملاحظات، وفي بيئات البداية الباردة (cold start) أو التفاعل النادر، يتأخر الفصل، ولذلك يصعب الحكم من نص الورقة وحده على مصير جودة القرار في المراحل المبكرة.

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

ثالثاً، يتضمن الملحق إثباتاً لصعوبة حسابية (computational hardness)، وهو ما يعني أن إيجاد القسمة (partition) المثلى صعب بشكل عام. DeMem هو تقريب عملي لذلك، وتلزم حدود إضافية حول الشروط التي ينهار عندها هذا التقريب.

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

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

المصادر

• الورقة: Remember the Decision, Not the Description: A Rate-Distortion Framework for Agent Memory (arXiv 2605.10870)
• معايير القياس: LoCoMo، LongMemEval / النماذج الأساسية: GPT-4o-mini، GPT-4.1-mini، Qwen2.5-14B-Instruct، Llama-3.1-70B
• الأرقام في الجدول مقتبسة من الجدول 1 (LoCoMo، GPT-4.1-mini) في الورقة.

تتناول الورقة البحثية “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning” (arXiv 2607.07508)، التي نشرها باحثون من جامعة تسينغهوا وشركة Z AI في 8 يوليو 2026، هذه النقطة مباشرة. والخلاصة أن الباحثين تخلّوا عن “أخذ العينات الجماعي” (group sampling)، وهو جوهر GRPO الشائع الاستخدام. ولم يقتصر الأمر على تجربة هذا الأسلوب في تجارب الورقة فحسب، بل طبّقوه فعلياً في خط أنابيب حقيقي لتدريب النموذج المفتوح GLM-5.2 البالغ حجمه 750B.

نظرة عامة

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

تُشغّل ThakiCloud أيضاً خمس تقنيات لما بعد التدريب، هي SFT وCPT وDPO وGRPO وGKD، ضمن نظام تدريب نماذج اللغة الكبيرة المبني على kubeflow. لذلك فإن الثمن الذي يدفعه أخذ العينات الجماعي في GRPO عند التعامل مع rollouts طويلة، والمخاطر الجديدة التي قد يجلبها أي بديل يُزيل هذا الثمن، ليست قضية بعيدة عنا. يستعرض هذا المقال ما غيّرته SAO، وما تعنيه هذه التغييرات لمؤسسة مثلنا تسعى لتدريب وكلاء على عناقيد GPU متعددة المستأجرين (multi-tenant).

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

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

يجمع اسم SAO، كما هو، بين مفهومين: “rollout واحد” (single-rollout) و”التحسين غير المتزامن” (asynchronous optimization).

كانت خطوط أنابيب التعلّم المعزز التقليدية متزامنة (synchronous). تُحدَّد دفعة من الطلبات، ويُولَّد لكل طلب عدد من الـ rollouts، وعندما تكتمل جميعها تُحسَب المكافأة ويُنفَّذ تحديث واحد للسياسة. نجح هذا الأسلوب جيداً في المهام التي تُنتج إجابات قصيرة، لأن أطوال الـ rollouts كانت متقاربة.

لكن المشكلة تظهر في مهام الوكلاء. فمهمة برمجية واحدة قد تنتهي خلال 3 جولات فقط، بينما تستمر مهمة مجاورة في استدعاء الأدوات عبر 40 جولة. وفي خط الأنابيب المتزامن، تبقى بقية وحدات GPU عاطلة حتى ينتهي أبطأ rollout في الدفعة. ظهر التعلّم المعزز غير المتزامن أصلاً لإزالة هذا الهدر: يُحدَّث النموذج فور اكتمال كل rollout، بينما يستمر المولّد (generator) دون توقف في إنتاج الـ rollout التالي.

flowchart TB
    subgraph SYNC[GRPO المتزامن]
        A1[دفعة من الطلبات] --> A2[توليد G من الـ rollouts<br/>لكل طلب كمجموعة]
        A2 --> A3[الانتظار حتى اكتمال<br/>أبطأ rollout]
        A3 --> A4[حساب المكافأة النسبية للمجموعة<br/>تحديث واحد للسياسة]
        A4 -.توقف GPU.-> A2
    end
    subgraph SAO[SAO غير المتزامن]
        B1[توليد rollout واحد<br/>لكل طلب] --> B2[وصول فوري<br/>عند الاكتمال]
        B2 --> B3[كبح تحديثات off-policy<br/>عبر تقليم الرموز ثنائي الاتجاه]
        B3 --> B4[تحديث مستمر للسياسة]
        B4 --> B1
    end
    SYNC -->|إزالة حاجز المجموعة| SAO

هنا ينشأ التعارض الجوهري. فاسم GRPO (Group Relative Policy Optimization) يحمل معنى “النسبية الجماعية” منذ البداية. تُجمَع عدة rollouts لطلب واحد في مجموعة واحدة، وتُقارَن داخل هذه المجموعة الـ rollouts الأفضل نسبياً بالأسوأ لحساب الأفضلية (advantage). وميزة GRPO، التي هي في الوقت نفسه قيدها، أنها تُنتج إشارة التدريب من المقارنة داخل المجموعة فقط دون الحاجة إلى دالة قيمة (critic) منفصلة. فإن لم تكتمل المجموعة، يستحيل حساب الأفضلية. وهكذا يتعارض جوهرياً البناء غير المتزامن الذي يتعلّم فور وصول كل rollout مع GRPO الذي يفرض الانتظار حتى تكتمل المجموعة.

لماذا لا يتناسب GRPO مع التعلّم غير المتزامن؟

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

الأول هو الانتظار على مستوى المجموعة، وحينها تتلاشى ميزة اللاتزامن، وينتهي الأمر بالعودة فعلياً إلى النمط المتزامن الذي ينتظر أبطأ rollout.

والثاني هو توليد rollouts المجموعة الواحدة بسياسات (policies) مختلفة زمنياً. فإذا أنتجت سياسة قديمة بعض rollouts المجموعة، وأنتجت سياسة مُحدَّثة بعد بضع خطوات rollouts أخرى ضمن المجموعة نفسها، فإن تجميعها ومقارنتها نسبياً كمجموعة واحدة يصبح ملوّثاً إحصائياً من الأساس. فحين تتفاوت درجة off-policy من rollout إلى آخر، لكنها تُعامَل كأنها baseline واحد متجانس، يصبح التدريب غير مستقر.

إجابة SAO بسيطة: إلغاء المجموعة تماماً. يُولَّد rollout واحد فقط لكل طلب، وحالما يصل يُستخدَم مباشرة في التدريب. وبزوال حاجز المجموعة، لا يضطر المولّد إلى الانتظار إطلاقاً، فيتقلّص وقت خمول GPU بشكل كبير.

ركيزتا SAO: rollout واحد وتقليم الرموز ثنائي الاتجاه

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

تتصدى SAO لمشكلة الاستقرار هذه عبر “تقليم صارم ثنائي الاتجاه على مستوى الرمز” (strict double-side token-level clipping). فالتقليم (clipping) الذي كانت تستخدمه عائلة PPO أصلاً هو آلية تقصّ التدرّج (gradient) عندما تخرج نسبة الأهمية (importance ratio) عن نطاق محدد. وتُطبّق SAO هذا التقليم على مستوى كل رمز (token) على حدة، وبصرامة في الاتجاهين الأعلى والأسفل معاً. فعند الرموز التي تباعدت فيها rollout السياسة القديمة كثيراً عن السياسة الحالية، يُكبَح التحديث بقوة، مما يمنع الإشارات ذات الفجوة الزمنية الكبيرة من إفساد التدريب.

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

النتائج الفعلية والتحقق

قارنت الورقة SAO بـ GRPO ومتغيراتها، وأفادت بتفوّقها باستمرار في معايير قياس الترميز والاستدلال الخاصة بالوكلاء. والمعايير المذكورة هي SWE-Bench Verified (حل مشكلات GitHub الحقيقية)، وBeyondAIME (رياضيات عالية الصعوبة)، وIMOAnswerBench (رياضيات بمستوى الأولمبياد). وتشترك المعايير الثلاثة في كونها مهام متعددة الخطوات وطويلة النَفَس، وليست إجابات قصيرة مباشرة، وهو بالضبط المجال الذي تستهدفه SAO.

أما التحقق الأكثر إقناعاً فليس في جداول المعايير، بل في واقعة النشر ذاتها. فقد استُخدِمت SAO في خط أنابيب فعلي للتعلّم المعزز للوكلاء لتدريب النموذج المفتوح GLM-5.2 (نموذج MoE بحجم إجمالي 750B وحجم فعّال 40B من المعاملات النشطة، 750B-A40B). وكون طريقة بحثية لم تبقَ حبيسة الورقة العلمية، بل استُخدِمت في تدريب إنتاجي لنموذج بحجم مئات المليارات، إشارة قوية على أن هذه الطريقة تصمد عند المقياس الحقيقي، لا في إعدادات تجريبية صغيرة فقط.

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

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

لا يقتصر درس SAO على كونه ورقة خوارزمية واحدة، بل يمسّ مباشرة طريقة تشغيل عناقيد GPU.

عدسة ai-platform (البنية التحتية لتدريب GPU). تجدول منصة ai-platform التابعة لـ ThakiCloud تدريب GPU متعدد المستأجرين فوق Kubernetes وKueue. ونظام تدريب نماذج اللغة الكبيرة المبني على kubeflow يدعم بالفعل GRPO كأحد تقنيات ما بعد التدريب. والسؤال الذي تطرحه SAO واضح: كم يتراجع معدل استغلال GPU في مهام تدريبنا بسبب التفاوت في أطوال الـ rollouts؟ ففي المهام المتفاوتة الطول كـ rollouts الوكلاء، يتحوّل انتظار المجموعة المتزامن إلى تكلفة مباشرة. وفصل توليد الـ rollouts غير المتزامن عن التدريب يتيح استخلاص خطوات تدريب فعّالة أكثر من العدد نفسه من وحدات GPU، وهو ما يشكّل رافعة مباشرة لخفض تكلفة التدريب لكل مستأجر في بيئة متعددة المستأجرين. كما أن التحقق مما إذا كانت جدولة gang scheduling وإدارة الطوابير في Kueue تفرض نمط “الانتظار حتى تكتمل المجموعة” يُعدّ نقطة تحسين عملية أخرى.

عدسة Paxis (نتاج تدريب الوكلاء). Paxis، وهي منصة Agent-Native Cloud التابعة لـ ThakiCloud، مستوى تحكّم يُشغّل المهارات (skills) في صناديق رملية معزولة (sandbox) ويمرّر كل سلوك عبر بوابات سياسات وسجلات تدقيق. والوكيل الذي تسعى SAO لتدريبه جيداً، أي وكيل يستدعي الأدوات عبر جولات متعددة ويُصلح قواعد الأكواد، هو بالضبط عبء العمل الذي تُشغّله Paxis. بل إن آثار الوكلاء (agent traces) الفعلية التي تُولّدها Paxis داخل الصناديق الرملية المعزولة يمكن أن تكون بحدّ ذاتها مصدر rollouts للتعلّم المعزز غير المتزامن على غرار SAO. وبذلك تكتمل حلقة: تُنتج ai-platform الـ rollouts وتدرّب عليها بتكلفة منخفضة، وتُشغّل Paxis الوكيل الناتج بأمان، لتُولّد بدورها بيانات تدريب جديدة. إنها بنية تقوم فيها بنية التدريب منخفضة التكلفة (ai-platform) بدعم جدوى الوكلاء الاقتصادية (Paxis).

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

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

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

ثانياً، التحقق عبر تدريب نموذج بحجم 750B مثير للإعجاب، لكن نجاحه عند هذا المقياس لا يعني أنه الأمثل بالضرورة في إعدادات المؤسسات الصغيرة. فخط الأنابيب غير المتزامن يتطلّب تعقيداً إضافياً في البنية التحتية لفصل المولّد عن المدرّب. وبالنسبة للفرق التي تُجري ضبطاً دقيقاً قصيراً بعدد محدود من الـ rollouts، قد يكون GRPO المتزامن أبسط وكافياً.

ثالثاً، توجد مقاربات نشطة في الاتجاه المعاكس أيضاً. فقد ظهرت في الفترة نفسها دراسة تتناول العلاقة بين staleness ومعدل التعلّم في RLHF غير المتزامن عبر قوانين تحجيم (scaling laws) (arXiv 2607.01083)، كما ظهرت مقاربات تُثبّت التدريب غير المتزامن عبر محاذاة التدرّجات (gradient alignment). ولذلك فالأدق أن نعتبر مبدأ SAO القائم على “إلغاء المجموعة وكبح ذلك بالتقليم” واحداً من عدة إجابات قوية محتملة على مسألة مفتوحة هي التعلّم المعزز غير المتزامن للوكلاء، لا الإجابة الوحيدة الصحيحة.

ومع ذلك، فإن إسهام SAO واضح. فقد حدّدت المشكلة بدقة (عدم كفاءة أخذ العينات الجماعي عند طول الـ rollouts)، وتحقّقت من الحل (rollout واحد مع تقليم ثنائي الاتجاه) عبر تدريب إنتاجي فعلي بمقياس مئات المليارات من المعاملات. وأي مؤسسة يمثّل فيها معدل استغلال GPU تكلفة التدريب مباشرة، لديها سبب وجيه لحساب المبلغ الذي يُهدَر في خط أنابيبها بسبب “انتظار المجموعة”.

المصادر

• Zhenyu Hou, Yujiang Li, Jie Tang, Yuxiao Dong. “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning.” arXiv 2607.07508 (2026-07-08). https://arxiv.org/abs/2607.07508
• ذو صلة: “Staleness-Learning Rate Scaling Laws for Asynchronous RLHF.” arXiv 2607.01083. https://arxiv.org/abs/2607.01083

Overview

Until now, multi-agent coding workflows have largely stayed within a single vendor. In Claude Code, Opus conducts while Sonnet or Haiku runs as subagents. What makes fable-advisor interesting is that it structures this division of labor across vendor boundaries. Anthropic’s Fable 5 handles the orchestration layer, while xAI’s Grok 4.5 handles the implementation layer.

The core insight of this design is straightforward. Conducting and implementing demand different capabilities, and they have different cost structures. Spec writing and diff review are matters of judgment and reasoning, so they require a model suited to conducting, whereas bulk code typing is where throughput and cost efficiency matter most. fable-advisor places each of these two roles on models from different vendors, letting each layer use whichever model fits it best. The fact that it is free and open source, with routing logic that can be customized directly, also lowers the barrier to real-world adoption.

What This Technology Is

fable-advisor is a plugin layered on top of Claude Code that enforces a three-way separation of roles.

First, the conductor (Fable 5) writes specs and reviews outcomes. It takes the user’s request, breaks it down into an implementation spec, and reviews the resulting diff once implementation is done. The important point is that the conductor never writes code directly. It focuses entirely on judgment and contract definition.

Second, the implementer (Grok 4.5) handles all the actual typing. It receives the spec passed down by the conductor and writes code through the Grok CLI, powered by Grok 4.5. Looking at the repository’s history, starting with v3 the existing Sonnet/Opus implementation agent was replaced by grok-implementer, making Grok 4.5 the default typing lane. In other words, this plugin was not cross-vendor from the start; it is the result of an evolution that moved the implementation lane toward a lower-cost, higher-throughput model.

Third, there is parallel execution. Independent specs are run simultaneously as parallel agents. When the conductor breaks work down into units that do not depend on each other, each unit proceeds concurrently as a separate implementation agent. This is not simple sequential delegation but closer to a division of labor shaped like a DAG (directed acyclic graph).

The overall flow looks like this in diagram form.

flowchart TB
    U[User request] --> F[Fable 5 conductor<br/>spec writing & diff review]
    F -->|split into independent specs| S1[Spec A]
    F -->|split into independent specs| S2[Spec B]
    S1 -.Grok CLI.-> G1[Grok 4.5 implementer A]
    S2 -.Grok CLI.-> G2[Grok 4.5 implementer B]
    G1 -->|diff| F
    G2 -->|diff| F
    F --> R[Integration & review result]

Installation and Integration

Installing the plugin takes one line. You add the repository to Claude Code’s plugin marketplace.

claude plugin marketplace add DannyMac180/fable-advisor

The Grok CLI, which handles the implementation lane, requires separate authentication. Logging in with grok login sets up OAuth authentication based on a SuperGrok or X Premium+ subscription, and according to the repository description, this path lets you run the implementation agent without per-token API charges, purely through your subscription. This is the crux of the cost structure. The conductor makes only a small number of judgment-heavy calls, while the bulk of code typing happens within the subscription plan, minimizing exposure to usage-based billing.

From an integration standpoint, it is worth noting that the routing logic is open. You can adjust directly which task goes to which model and under what conditions work gets parallelized, so a team can reconfigure the lanes to fit its budget and quality requirements.

How This Design Actually Performs

fable-advisor is not a tool that touts benchmark numbers but a workflow pattern, so instead of reproducible performance figures, this section covers the structural effects the design produces. Since the repository does not present quantitative metrics, this post also avoids inventing numbers and sticks to structural benefits.

The biggest effect is the separation of cost and quality. When orchestration that requires judgment goes to the conductor and implementation that requires throughput goes to a low-cost implementer, the overall workflow’s unit cost drops while judgment quality is preserved. The arrangement “call the conductor sparingly and cheaply, call the implementer often but not expensively” falls into place naturally.

The second effect is cross-verification. The fact that the implementer and the reviewer are models from different vendors produces an interesting side effect. When the same model reviews its own code, it tends to overlook the same mistakes it made in the first place, but when a model from a different lineage reviews the diff, there is more room for it to catch the other’s blind spots. The conductor-worker split becomes more than a simple division of labor; it functions as a kind of mutual verification mechanism.

The third effect is reduced latency through parallelization. When independent specs are implemented at the same time, total working time converges not to the sequential sum but to the length of the single longest chain. The better the conductor breaks work down, the larger this benefit becomes.

Generalizing the Conductor-Worker Pattern

If we look at fable-advisor not as an individual plugin but as a design pattern, a broader context comes into view. The essence of this pattern is “the main session only conducts, and heavy work gets delegated.” Crossing vendors is just one variant of this pattern; it also holds within a single vendor. For example, a setup where Claude Code uses Fable 5 as the conductor, routes exploration to Haiku, implementation to Sonnet, and complex reasoning to an Opus subagent is already widely used. What fable-advisor did was extend the target models of this delegation beyond the vendor boundary.

Seen from this angle, the selection criteria for the conductor model become clear. Since the conductor is responsible for judgment, branching, and aggregation, accuracy and reasoning quality matter, but call frequency is relatively low. The implementer, by contrast, cares about throughput and unit cost. Good orchestration, then, is not “put the most expensive model in the conductor seat and route everything through it,” but rather “place at each layer the model whose characteristics that layer actually requires.” The v3 evolution that moved fable-advisor’s implementation lane to a low-cost subscription model is exactly the result of following this principle.

One thing worth watching is that this pattern only works if the boundaries of delegation are clear. If the conductor hands off an ambiguous spec, the implementer fills in the gaps by guessing, and the resulting review burden actually grows. The gains of delegation are realized only when the spec is sufficiently concrete. This is no different from division of labor in human organizations. The clearer the specification, the better delegation works.

Implications for ThakiCloud’s Products

This design overlaps strikingly with how ThakiCloud operates its own agents.

It is most directly relevant from a Paxis perspective. Paxis is ThakiCloud’s Agent-Native Cloud control plane, and it treats DAG-shaped multi-agent execution as a core capability. The “spec writing to distributed implementation to cross review” structure that fable-advisor demonstrates shares the same skeleton as Paxis’s skill harness, which breaks work into subtasks, runs them in parallel inside isolated sandboxes, and closes the loop with a verification stage. In particular, the principle that the conductor focuses on judgment and contract definition rather than writing code directly matches exactly with our own design philosophy of drawing capability from surrounding contract structures rather than model tier. The flow where the conductor reviews results produced by a different model also lines up with our own operating principle of closing multi-agent fan-out with a verification stage, so that hallucinations do not accumulate unchecked.

It also holds up from an ai-platform perspective, particularly around cost structure. ThakiCloud’s ai-platform schedules GPU workloads on K8s and Kueue, serving the inference and training workloads of its customers. The idea behind fable-advisor of delegating the implementation lane to a low-cost model to bring down overall workflow unit cost is a pattern that GPU cloud customers can apply directly when designing their own workloads. When the small number of judgment steps that need heavy inference and the larger number of execution steps that need throughput are placed on resource tiers matched to each, the same result can be obtained at lower cost. Since low-cost serving is what makes agent economics work in the first place, ai-platform’s cost efficiency and Paxis’s agent orchestration complement each other.

Limitations and Counterarguments

This design comes with clear trade-offs. The first is operational complexity. Weaving two vendors’ models into a single workflow means managing two authentication systems, two pricing plans, and two points of failure. If one vendor’s CLI changes or its authentication expires, the entire workflow can stop. This is a trade against the simplicity of a single-vendor workflow, and whether the benefit justifies the complexity may differ from team to team.

The second is the risk of delegating quality. Delegating implementation to a low-cost model means that if the conductor’s spec and review are not tight enough, low-quality implementation can pass through unchecked. The quality of this workflow ultimately depends on how strict the conductor’s review gate is. If the review is a formality, the cross-verification benefit of cross-vendor division of labor disappears, and what remains is a low-quality pipeline that merely saved on cost.

The third is the constraint of subscription-based authentication. The fact that the Grok CLI runs on subscription-based OAuth is a cost advantage for individuals or small teams, but for large-scale automation or unattended pipelines, subscription limits and authentication renewal can become bottlenecks. The advantage of having no usage-based billing is, flipped around, also a statement that scaling stops the moment usage exceeds the plan’s limit.

Even so, the message fable-advisor sends is clear. The future of coding agents lies not in one all-purpose model but in orchestration that combines the model best suited to each layer. This points to exactly the same direction as ThakiCloud’s approach of treating multi-agent systems and model routing as first-class resources.

Sources

• fable-advisor (GitHub)
• Grok CLI (x.ai/cli)

Overview

The common approach to an agent’s memory problem is a vector database: embed conversations and documents, store them, and retrieve them via semantic search when needed. It is powerful, but the operational burden is significant. You have to manage an embedding pipeline, a vector index, and a reindexing schedule, which is a lot of infrastructure for an individual to bolt onto their own workflow.

personal-monorepo-template takes the opposite direction. It reframes memory not as a search problem but as a file-structure problem. People live in a people/ folder, projects live as project packets, and recurring ways of working live as skills inside the repository itself. The agent loads this entire structure persistently through AGENTS.md every time a session starts. Instead of the approximate matching of vector search, memory is accessed through the exact address of a folder path.

The background of the person who built this adds weight to the design. jxnl is the creator of Instructor, a structured-output library downloaded millions of times a month, reportedly cited by OpenAI as an inspiration for its own structured output feature. He currently works as a Developer Experience engineer on the OpenAI Codex team, which makes this a tool built by someone who runs coding agents in daily production use to solve their own problem, giving it real reference value.

What This Technology Is

The core idea is simple. Represent an agent’s memory as plain folders and markdown inside a monorepo, and load it automatically every session. It breaks down into three parts.

The first is a record of people and projects. The repository scans Slack, email, calendar, and GitHub to generate people files and project packets, and proposes updates to the persistently loaded AGENTS.md. Mention a particular colleague’s name, and the agent reads that person’s file and instantly restores the context. Without any vector database, it locates “who this person is” through an exact folder path.

The second is repository-local skills. Recurring ways of working are placed as skills inside the repository, loaded automatically every session so the agent follows those procedures. A notable example is the built-in write-like-me skill, which learns from a user’s sent emails and Slack messages to write in that person’s own voice. The user’s past output becomes the training data for the skill itself.

The third is automatic check-ins. The repository is designed to run automatic check-ins at 9am and 4pm every day, summarizing that day’s project status and people-related context and proposing updates. Rather than waiting for a manual invocation, this is a loop where the agent refreshes its own memory on a fixed schedule.

The overall flow looks like this in diagram form.

flowchart TB
    SRC[Slack, Email, Calendar, GitHub] -->|scan| SCAN[Check-in script]
    SCAN --> PEOPLE[Propose people files]
    SCAN --> PKT[Propose project packets]
    SCAN --> AGD[Propose AGENTS.md updates]
    AGD -.loaded persistently at session start.-> AGENT[Coding agent]
    PEOPLE -.looked up by folder path.-> AGENT
    SKILL[Repository-local skills<br/>including write-like-me] -.loaded automatically.-> AGENT
    CRON[Automatic check-in at 9am and 4pm daily] --> SCAN

This design is interesting precisely because it connects to the “Codex-maxxing” philosophy the repo’s author laid out in a separate post. Rather than bolting a better model onto the agent, the direction is to build up the surrounding structure so the agent never starts from a blank slate.

Installation and Integration

This repository is exactly what its name says: a template. You integrate it by cloning it into your own GitHub account and configuring your coding agent (Codex or a similar CLI) to use the repository root as its working directory. The core entry point is AGENTS.md at the repository root, which the agent reads at the start of every session to understand the folder structure, the people and project context, and the list of skills it should load.

The key integration point here is that AGENTS.md is not a plain document but a persistently loaded contract. Because this file lands at the front of the context every session, what you write in it defines the agent’s default behavior. Since the folder structure is fixed, the agent accesses memory deterministically, in the sense of “if I need context on colleague A, I read people/A.md.” Unlike the probabilistic approximation of vector search, a file path always points to the same place.

Automatic check-ins are integrated by hooking the check-in script to a scheduler (a cron-style job) so it runs at a fixed time every day. This mechanism keeps the agent’s memory current without requiring a human to invoke it each time, and it is also an important design decision from a cost standpoint. Because it runs a finite number of times a day rather than polling continuously, it does not burn tokens in an infinite loop.

How This Design Actually Plays Out

This repository is not a tool that leads with benchmark numbers; it is a workflow pattern, so here we examine the structural effects it produces in practice. The repository does not offer reproducible performance figures, and the author himself points to improvements in day-to-day workflow rather than quantitative metrics as the justification. So this post does not invent numbers either and sticks to the structural advantages.

The biggest effect is eliminating the cost of context restoration. A vector database lookup runs an embedding computation and a similarity search on every query, while a folder-path lookup is a single file read. When a person says “that project from last time,” the agent reads the corresponding project packet directly and restores the exact context, with no false positives from approximate search. The precision of memory now depends on the quality of the folder design rather than the quality of retrieval.

The second effect is auditability. Because all memory is stored as human-readable markdown, a developer can open it directly to check, and correct, what the agent knows. Vector embeddings are hard for a human to verify by eye, but people/A.md is just a text file. Being able to fix the agent’s memory on the spot when it is wrong makes a real difference in practice.

The third effect is portability. Because it isn’t tied to any specific vector database vendor or embedding model, the repository itself is a complete, self-contained memory. Move it to a different machine or a different agent and the folders and markdown still work as-is. This lack of infrastructure lock-in connects directly to the on-premise and sovereign-cloud angle discussed below.

Implications for ThakiCloud Products

This design touches both of the axes on which ThakiCloud operates agents.

The most direct connection is to Paxis. Paxis is ThakiCloud’s Agent-Native Cloud control plane, which treats Skills, Tools, Policies, and Audit Logs as first-class resources. The pattern personal-monorepo-template demonstrates, “repository-local skills plus a persistently loaded contract (AGENTS.md),” maps precisely onto the direction of Paxis’s skill-harness design. Paxis already selects among many skills via BM25 and runs them in an isolated sandbox, and this repository’s approach answers a step upstream of that, “what knowledge should sit persistently in the session context,” with a clean answer expressed as folder structure. In particular, keeping memory as human-readable files with every update auditable is the same philosophy as Paxis’s principle of routing every agent action through a policy gate and an audit log. The very idea of drawing an agent’s capability from its surrounding structure rather than its model tier is isomorphic to our own design of treating skills as first-class resources.

From the ai-platform angle, the infrastructure-burden perspective is what stands out. ThakiCloud’s ai-platform is K8s-based AI/ML infrastructure that serves workloads for on-premise and sovereign-AI customers. For these customers, a memory architecture that requires running a vector database at all times represents extra infrastructure surface and management cost. A memory expressed as folders and markdown, by contrast, runs on the filesystem alone with no separate state store, which is a much lighter operational burden in regulated environments or air-gapped networks. The angle of “minimizing memory infrastructure while still giving the agent persistence” could be a genuine selling point for customers who require sovereign AI.

Limitations and Counterarguments

This design is not a silver bullet. The clearest limitation is scale. Folder-path access is powerful when the person or the agent already knows the address of the memory. But when you need to find information “you don’t know the location of” among tens of thousands of documents, semantic vector search is still superior. This repository assumes a relatively small, clearly structured memory space consisting of one person’s people, projects, and experiences. Scale it up to a team’s entire, sprawling knowledge base, and folder structure alone starts to hit its limits.

The second counterargument is the privacy of the scanning process. Scanning Slack, email, and calendar to build people files also means that sensitive conversations get stored as plain-text markdown. That’s convenient for personal use, but bringing it into an organization requires access control and retention policy without question. Auditability is a strength, but with no control over who can access those files, it becomes a liability just as easily.

The third is the reliability of automatic updates. If a twice-daily automatic check-in writes a wrong summary into a person file, that error keeps getting injected into every subsequent session. This is exactly why the repository frames updates as “proposals” that assume a human will confirm them. Push all the way to full automation and memory can quietly get corrupted, so leaving a human review gate in place is the safer approach.

Finally, this approach is pitched as “a free alternative to a human assistant’s salary,” but actually sustaining this level of workflow requires substantial engineering skill to design and refine the repository structure yourself. The tool being free and the cost of operating it well being free are two different things.

Even so, the core message this repository sends is clear. An agent’s memory does not have to be heavy infrastructure, and a good folder structure paired with a persistently loaded contract can deliver a surprising amount of persistence. That points in exactly the same direction as ThakiCloud’s own approach of treating skills and knowledge as first-class resources.

Sources

• jxnl/personal-monorepo-template (GitHub)
• Codex-maxxing (jxnl.co)

Source: RT @hangoo_kang: “TRACE: Capability-Targeted Agentic Training” got Spotlight @ ICML AIWILD 🎉 · twitter

What this means for ThakiCloud

This lines up neatly with what ThakiCloud has been building. Paxis conducts the agents; Metis retrains the ones that come up short. TRACE says: diagnose your failures and retrain just the weak spot. But those failure logs are among the most sensitive things a company owns. Ship them to someone else’s cloud to train on, and both the weakness and the fix leak out with them. That is the case for on-prem and for sovereignty: keeping your models, data, and infrastructure under your own roof. Fix your flaws at home and they stay home. For what it is worth, this very blog runs on a self-improvement loop that reviews its own misses and resharpens.

An auto-generated comic riffing on this week’s industry news.

serve-sim, built by Evan Bacon of the Expo core team, aims straight at that wall. It became widely known after indie developer levelsio showed it off, saying it let him “watch, in a browser, in real time, an iOS app that Claude Code built on a cloud Mac Mini.” Its slogan is simple: “npx serve for Apple Simulators.”

Overview

What makes serve-sim interesting is that it is not just a screen-mirroring tool. It opens two things at once: a video stream that sends the simulator screen to a browser, and a control channel that lets a browser or an agent operate the simulator. In other words, it makes both “watching” and “operating” possible remotely.

That combination matters because it completes the development loop for AI coding agents. An agent can fix code, build it, run it, look at the resulting screen, tap a button to move to the next step, and cycle through all of that without a human in the loop. This lines up exactly with what ThakiCloud’s Agent-Native Cloud, Paxis, is aiming for: agents doing real work inside isolated environments. That makes it worth a closer look at how one open-source tool implements that workflow.

A visualization of a headless server’s simulator screen becoming a stream that flows into a remote browser.

What serve-sim Is

The way serve-sim works is simpler and more clever than it sounds. There is no separate Xcode plugin to install, and no instrumentation code to embed in the app. Instead it spins up a small Swift helper process that captures the framebuffer of an already-booted iOS Simulator through Apple’s own simctl io interface.

The captured screen is exposed in two ways. First, it sends the video to the browser as an MJPEG stream at up to 60 FPS. Second, it opens a WebSocket control channel alongside it, so input from the browser side, taps and gestures, can be sent back to the simulator. On top of that sits a React-based preview UI, so a person can operate the app in the browser as if it were a real device.

flowchart TB
    A[Booted iOS Simulator] --> B[Swift helper process]
    B --> C[Captures framebuffer<br/>via simctl io]
    C --> D[MJPEG video stream<br/>up to 60 FPS]
    C --> E[WebSocket control channel]
    D --> F[Browser React preview UI]
    E --> F
    E --> G[Agent CLI<br/>tap, gesture, rotate, camera]
    F -.human operates.-> E
    G -.agent operates.-> E

The key point is that it targets “any booted simulator.” Since it requires no modification to the app, it can be attached to an existing project as-is. It can also forward simulator logs to the browser, so browser-use style MCP tools can read those logs to judge state. There is even a convenience feature where dragging a video or image into the browser window adds it as a file on the simulator device.

Installation and Use

The barrier to entry for serve-sim is low. On a Mac with Node.js, one line is enough.

npx serve-sim

Once running, you can view the preview at http://localhost:3200 locally. It supports three modes: using it locally, connecting from another device on the same LAN, or hosting it on a remote Mac and reaching it from anywhere through a tunnel. levelsio’s case is the third mode: running it on a headless Mac Mini in the cloud and viewing it through a remote browser.

Agent integration is provided as a separate Agent Skill. This skill, packaged at skills/serve-sim in the repository, teaches any host that implements the open Agent Skills standard, including Claude Code, Cursor, Codex CLI, and Gemini CLI, how to operate the simulator through the CLI. That includes taps, gestures, hardware buttons, screen rotation, injecting camera input, and handing the stream off to the host’s own preview window.

A Note on Reproduction

This post was written in a headless batch session with no GUI, where running Node.js is blocked by policy, so we were not able to run npx serve-sim directly ourselves and capture the screen. The commands and behavior described in this post are therefore based on facts confirmed in the repository README and the official announcement material, and we have not fabricated any benchmark numbers. Please verify the actual simulator streaming screen and latency yourself, on a macOS machine with a booted Xcode Simulator, using the commands above.

Implications for ThakiCloud Products

On the surface, serve-sim is a tool for iOS developers, but underneath it sits a much bigger trend: agent-native development.

Paxis lens (agent-native development). ThakiCloud’s Paxis is an Agent-Native Cloud control plane that runs skills in isolated sandboxes and passes every action through policy gates and audit logs. The open Agent Skills standard that serve-sim adopts is the same kind of contract model that Paxis’s skill harness handles. The idea that a single skill can give “tap, rotate, and read the screen of a simulator” capability to multiple agent hosts points in exactly the same direction as Paxis’s structure of selecting from 960-plus skills via BM25 and running them in isolation. In particular, workloads where an agent operates a real UI, like serve-sim’s control channel, need those operations to pass through policy gates and be recorded in audit logs before they can safely go into production. If serve-sim provides the “capability,” Paxis provides the layer that “safely governs” that capability.

ai-platform lens (headless execution infrastructure). What really makes serve-sim compelling is that it runs on a headless, remote Mac. The idea of building and streaming from a GUI-less server shares its philosophy with how ThakiCloud’s ai-platform schedules and runs workloads on Kubernetes without a GUI. A pipeline that attaches macOS runners on demand for iOS builds, lets an agent automatically build and test on top of them, and streams only the results back to a human, could extend beyond CI into “agent-driven QA.” It is a structure where low-cost headless execution infrastructure (ai-platform) underpins the economics of agent automation (Paxis).

Limits and Counterarguments

A few things deserve a sober look.

First, serve-sim targets the simulator. Because it is a simulator and not a physical device, issues that only surface on real hardware, camera, sensors, performance characteristics, still go uncaught. The old limitation that passing on the simulator does not guarantee passing on a real device remains unchanged.

Second, MJPEG streaming is simple and compatible but not very efficient at compression. Continuously streaming a 60 FPS, high-quality feed over a remote tunnel can turn bandwidth and latency into a bottleneck. For gesture testing where responsiveness matters, network round-trip delay translates directly into input lag.

Third, an agent being able to “see and operate” the screen is a separate matter from that judgment being correct. It remains entirely possible for an agent to misread the stream and tap the wrong button, and this is exactly why policy gates and human review are needed. The more capability a tool opens up, the more important the layer that governs that capability becomes.

Even so, serve-sim’s direction is clear. It has built a real bridge needed to move from “the agent only writes code” to “the agent builds, runs, and verifies by directly operating the screen.” If you are a team trying to develop mobile apps with agents from a headless cloud, you can open that world right now with a single line: npx serve-sim.

Sources

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio, tweet introducing serve-sim. https://x.com/levelsio/status/2075328941317886210