تصوير تجريدي للتفكير الماركوفي: تقسيم الاستدلال الطويل إلى كتل ثابتة الحجم وتمرير حالة قصيرة فقط إلى الأمام.

لماذا يستحق هذا المقال القراءة

كُتب هذا المقال للمهندس الذي يخدم أو يدرّب نماذج الاستدلال الطويل باستخدام التعلّم المعزّز (RL)، ولمسؤول المنصة المسؤول عن كلفة الاستدلال تلك. القرار الذي تواجهه هو التالي: تريد أن يفكر النموذج لمدة أطول، لكن كيف تستوعب الحوسبة والذاكرة اللتين تقفزان تربيعياً مع ذلك الطول؟ يجيب التفكير الماركوفي (arXiv:2510.06557، McGill-NLP) بفصل طول التفكير عن حجم السياق (context size). باختصار، إذا قسّمت الاستدلال إلى كتل ثابتة الحجم وأبقيت على حالة نصية قصيرة فقط لنقلها عبر كل حدّ كتلة، فمهما طال التفكير تنمو الكلفة خطياً فقط وتبقى الذاكرة ثابتة.

نظرة عامة

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

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

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

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

يوضّح المخطط أدناه هذا التدفق.

flowchart TB
    A[بداية الكتلة: التهيئة بحالة ترحيل قصيرة] --> B[التفكير بحرية داخل الكتلة كالمعتاد]
    B --> C{هل بُلغ حدّ الكتلة؟}
    C -->|لا| B
    C -->|نعم| D[كتابة حالة نصية عند نهاية الكتلة]
    D --> E[البيئة تعيد ضبط السياق]
    E --> F[الكتلة التالية: ترحيل الحالة القصيرة فقط<br/>بدل التاريخ الكامل]
    F --> A
    D -.RL يكافئ كتابة حالة جيدة.-> D

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

ما الذي تقرّره الورقة البحثية

تُظهر الأرقام التي تبلّغ عنها الورقة أن الفكرة تنجح فعلاً. فنموذج R1-Distill 1.5B المُدرَّب في Delethink بكتل من 8K رمز يفكر حتى 24K رمز ويضاهي أو يتفوق على نموذج LongCoT-RL مُدرَّب بميزانية 24K. لقد أدار استدلالاً أطول بثلاث مرات من نافذة 8K التي يراها دفعةً واحدة.

ويتّسع فارق الكلفة مع الحجم. تُبلغ الورقة أنه عند متوسط طول تفكير يبلغ 96K، تكلّف LongCoT-RL 27 H100-شهر من التدريب مقابل 7 لـ Delethink. هذا هو الفارق الذي يصنعه الخطي مقابل التربيعي.

ويُظهر التوسّع وقت الاختبار فارقاً أيضاً. فحين تدفع بالتفكير إلى الأطول عند الاستدلال، يواصل Delethink التحسّن حيث يثبت LongCoT. وثمة ملاحظة مثيرة أخرى من التحليل عند تهيئة RL: كثيراً ما تعاين نماذج الاستدلال الجاهزة من 1.5B إلى 120B مسارات ماركوفية دون تدريب مسبق عبر معايير متنوعة. هذه العيّنات الإيجابية الطبيعية هي ما يجعل RL فعّالاً على نطاق واسع.

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

ماذا يعني هذا لـ ThakiCloud

يمتد الأثر العملي للتفكير الماركوفي إلى كلا منتجَي ThakiCloud.

زاوية ai-platform مباشرة على نحو خاص. فما يرفع فعلاً كلفة خدمة الاستدلال الطويل هو ذاكرة KV (KV cache) وحوسبة الانتباه اللتان تنموان مع إطالة التفكير. فإذا نما السياق بلا حدود، انخفض عدد الطلبات المتزامنة التي يمكن وضعها على وحدة H200 واحدة، واشتدّ ضغط ذاكرة GPU في بيئة متعددة المستأجرين. وتحديد المقدار المُحمَّل في السياق عند حجم الكتلة، كما في التفكير الماركوفي، يُبقي بصمة ذاكرة KV ثابتة بغضّ النظر عن طول التفكير. وهذا يعني استيعاب مزيد من الاستدلال المتزامن على العتاد نفسه في ظل جدولة GPU القائمة على Kueue، حتى لأحمال تتطلب تفكيراً أطول. وكلما ضاقت ميزانية GPU، كما في النشر داخل المؤسسة والنشر السيادي (sovereign)، كبر مردود الكلفة الخطية.

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

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

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

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

الخلاصة

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

المصدر: The Markovian Thinker: Architecture-Agnostic Linear Scaling of Reasoning (arXiv:2510.06557) · مستودع الشيفرة (McGill-NLP/the-markovian-thinker)

تصوير تجريدي لحلقة SEED ذاتية التطور: استخراج المهارات من المسارات المكتملة وتغذيتها عائدةً إلى السياسة (policy) نفسها.

لماذا يستحق هذا المقال القراءة

كُتب هذا المقال للمهندس الذي يجري التدريب اللاحق (post-training) للوكلاء باستخدام التعلّم المعزّز، ولمسؤول المنصة الذي يصمم البنية التحتية للتدريب من تحته. أنت أمام قرار واحد: كيف تدفع بإشراف إضافي إلى خط أنابيب RL يكافئ حالياً النتيجة فقط؟ يجيب SEED (Self-Evolving On-Policy Distillation، arXiv:2607.14777) بمسار لا يستخدم نموذج معلّم قوياً منفصلاً ولا نموذج مكافأة بشري الصنع، بل السياسة نفسها بوصفها معلّمة لذاتها. باختصار، إن حلقة تحليل المسار، واستخراج مهارات قابلة لإعادة الاستخدام، واستخدام مقدار ما تحدثه تلك المهارات من إزاحة في احتمالات الأفعال بوصفه إشارة التدريب، تصنع إشرافاً على القرارات الوسيطة دون أي تسميات (labels) إضافية.

نظرة عامة

قادت السنوات القليلة الماضية من تدريب نماذج الاستدلال التعلّمُ المعزّز القائم على النتيجة، أي عائلة RLVR التي تستخدم مكافآت قابلة للتحقق. تمنح مكافأة على مستوى المسار مثل 1 للصحيح و0 للخطأ وتدفع السياسة إلى الأعلى. في مسائل الرياضيات أو البرمجة ذات الاستجابة الواحدة، ينجح هذا جيداً. المشكلة هي الوكلاء. في مسار طويل يستدعي الأدوات مراراً، ويتلقى ملاحظات، ثم يتصرف مجدداً، لا يخبرك نجاح الإجابة النهائية بشيء يُذكر عن جودة كل قرار من عشرات القرارات الوسيطة بينهما. تنفتح فجوة إشراف (supervision gap) بين النتيجة على مستوى الحلقة (episode) والتعلّم على مستوى الرمز. تلك الفجوة هي العائق الجوهري الذي يقضم كفاءة العيّنة في agentic RL.

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

ما هو SEED

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

أولاً، يُضبط النموذج بدقة (fine-tuned) ليحلل المسارات المكتملة ويولّد مهارات باللغة الطبيعية. تلتقط هذه المهارات سير العمل القابل لإعادة الاستخدام، أو الملاحظات الحاسمة، أو قواعد تجنّب الفشل. فبدلاً من أن يحقن إنسانٌ القواعد عبر موجّه (prompt)، يستخرج النموذج القواعد من تجربته الخاصة ويصوغها لغةً.

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

ثالثاً، وهنا الأداة الجوهرية في SEED، يعيد تسجيل درجات الأفعال المُعاينة (sampled actions) ضمن سياقين. أحدهما سياق عادي دون مهارات، والآخر سياق مُعزَّز بالمهارات المستخرجة. مقدار ارتفاع أو انخفاض احتمال فعل معيّن عند إرفاق المهارة، تلك الإزاحة في الاحتمال، يصبح إشارة تقطير كثيفة على مستوى الرمز وعلى السياسة (on-policy). ثم تُحسَّن هذه الإشارة بالاشتراك مع RL القائم على النتيجة. إنها تدفع السياسة نحو الأفعال التي كانت ستختارها باحتمال أعلى لو كانت المهارة حاضرة، والأهم أن هذا الإشراف المساعد يبقى متوائماً مع توزيع المسارات الحالي.

يوضّح المخطط أدناه الحلقة.

flowchart TB
    A[السياسة الحالية] -->|التفاعل مع البيئة| B[جمع المسارات المكتملة]
    B --> C[السياسة نفسها تتحول إلى محلّل]
    C -->|سير عمل قابل لإعادة الاستخدام<br/>ملاحظات حاسمة<br/>قواعد تجنّب الفشل| D[مهارات معرفة لاحقة باللغة الطبيعية]
    D --> E{إعادة تسجيل درجات الأفعال}
    E -->|سياق بلا مهارات| F[الاحتمال الأساسي]
    E -->|سياق مع المهارات| G[احتمال مدرك للمهارة]
    F --> H[إزاحة الاحتمال = إشارة تقطير على مستوى الرمز]
    G --> H
    H -->|تحسين مشترك مع RL القائم على النتيجة| A

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

ما الذي تقرّره الورقة البحثية

تُبلغ الورقة عن تجارب واسعة على مهام الوكلاء النصية والبصرية معاً. اتجاه النتائج متسق. حسّن SEED كلاً من الأداء وكفاءة العيّنة، وكان تعميمه على سيناريوهات لم تُرَ أثناء التدريب متيناً. ومقارنةً بطرائق أساس قوية، حقق أقوى متوسط أداء عبر ثلاثة معايير قياس (benchmarks) تمثيلية للوكلاء، وهو الادعاء المركزي للورقة.

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

ماذا يعني هذا لـ ThakiCloud

تمسّ الفكرة التي يطرحها SEED كلا المنتجين اللذين تشغّلهما ThakiCloud.

زاوية Paxis مباشرة على نحو خاص. Paxis هي سحابة ThakiCloud الأصيلة للوكلاء (Agent-Native Cloud)، وتعامل المهارات والأدوات والسياسات وسجلات التدقيق (audit logs) بوصفها موارد من الدرجة الأولى. وفي داخلها طبقة مهارات ذاتية التطور يستخرج فيها الوكلاء المهارات من التجربة ويتحسّنون من تلقاء أنفسهم. ما أثبته SEED أكاديمياً هو هذه الفكرة بالضبط: أن حلقةً تجعل المسارات المكتملة صريحة على هيئة مهارات باللغة الطبيعية وتغذيها عائدةً إلى السلوك تُحسّن السياسة فعلاً. وإذا كان مُسخّر المهارات (skill harness) في Paxis يختار من أكثر من 960 مهارة عبر BM25، وينفّذها في صناديق رمل (sandboxes) معزولة، ويمرّر كل فعل عبر بوابات السياسة وسجلات التدقيق، فإن SEED يقدم السند النظري في زمن التدريب لكيفية ولادة تلك المهارات من التجربة وصقلها. والمهارات المعبّر عنها باللغة الطبيعية يمكن للبشر قراءتها وتدقيقها، وهو ما يتلاءم جيداً مع فلسفة تصميم Paxis التي تُعلي شأن بوابات السياسة وسجلات التدقيق.

وثمة زاوية ai-platform أيضاً. إن تشغيل طريقة مثل SEED فعلياً يتطلب خط أنابيب تدريب لاحق يحسّن بالاشتراك RL القائم على النتيجة وإشارة تقطير، وهذا يستهلك موارد GPU كبيرة. تُشغّل منصة ai-platform لدى ThakiCloud تدريباً لاحقاً مثل SFT وDPO وGRPO فوق جدولة GPU القائمة على Kueue والخدمة متعددة المستأجرين (multi-tenant serving). ويتحول تحسين كفاءة العيّنة الذي يؤكده SEED مباشرةً إلى تكلفة على هذه البنية التحتية. فبلوغ جودة الوكيل نفسها بعدد أقل من المسارات يعني استيعاب مزيد من مهام التدريب على مجمع GPU مشترك، أو التدريب بعمق أكبر ضمن الميزانية نفسها.

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

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

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

الخلاصة

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

المصدر: SEED: Self-Evolving On-Policy Distillation for Agentic Reinforcement Learning (arXiv:2607.14777)

An abstract rendering of Markovian Thinking: breaking long reasoning into fixed-size chunks and passing only a short state forward.

Why This Is Worth Reading

This post is written for the engineer who serves or trains long-reasoning models with reinforcement learning, and for the platform owner accountable for that inference cost. The decision you face is this: you want the model to think longer, but how do you absorb the compute and memory that jump quadratically with that length? Markovian Thinking (arXiv:2510.06557, McGill-NLP) answers by decoupling thinking length from context size. In short, if you break reasoning into fixed-size chunks and keep only a short textual state to carry across each chunk boundary, then no matter how long the thinking gets, cost grows only linearly and memory stays constant.

Overview

Over the last few years, reasoning-model performance has climbed by lengthening the chain of thought. The premise is that thinking longer lets you solve harder problems. But this lengthening thinking carries a hidden price. In the standard RL thinking environment, the state is defined as the prompt plus every reasoning token generated so far. As the model keeps thinking, the state keeps swelling, and an attention-based policy has to re-read that growing state each time, so compute scales with the square of thinking length. Memory grows alongside it. Double the thinking, and cost quadruples.

Markovian Thinking revisits that premise itself. Instead of letting the state grow without bound, it makes the policy advance reasoning while conditioning only on a fixed-size state. It cuts the link that tied thinking length to context size, so that as thinking lengthens, compute stays linear and memory stays constant. Just as in a Markov process the next state depends only on the immediately preceding fixed state, the next piece of thinking depends only on the fixed state just handed over, not on all prior tokens.

What the Technique Is

The concrete instantiation of Markovian Thinking is a reinforcement-learning environment called Delethink. Delethink structures reasoning into fixed-size chunks. Within each chunk the model thinks freely as usual. When it reaches a chunk boundary, the environment resets the context and reinitializes the prompt with a short carryover. The key is what the policy learns through RL. Near the end of each chunk, the policy learns to write for itself a textual state sufficient to continue reasoning seamlessly after the reset. The next chunk inherits only this short state, not the entire preceding chunk.

The diagram below shows the flow.

flowchart TB
    A[Chunk start: initialize with short carryover state] --> B[Think freely within the chunk as usual]
    B --> C{Chunk boundary reached?}
    C -->|no| B
    C -->|yes| D[Write a textual state at the chunk's end]
    D --> E[Environment resets the context]
    E --> F[Next chunk: carry only the short state<br/>instead of the full history]
    F --> A
    D -.RL rewards writing a good state.-> D

The difference from the standard long chain-of-thought approach (LongCoT) is exactly here. LongCoT keeps piling every generated token into the context, so the state grows without bound. Delethink empties the context at each chunk and passes only a short state, so the state size stays fixed. You lengthen the thinking by stitching more chunks together, but the amount loaded into the context at any one time is capped at a single chunk.

What the Paper Reports

The numbers the paper reports show that the idea actually works. An R1-Distill 1.5B model trained in Delethink with 8K-token chunks thinks up to 24K tokens and matches or surpasses a LongCoT-RL model trained with a 24K budget. It managed reasoning three times longer than the 8K window it ever sees at once.

The cost difference widens with scale. The paper reports that at an average thinking length of 96K, LongCoT-RL costs 27 H100-months of training versus 7 for Delethink. That is the gap linear-versus-quadratic makes.

Test-time scaling shows a difference too. When you push thinking longer at inference, Delethink keeps improving where LongCoT plateaus. Another intriguing observation comes from analysis at RL initialization: off-the-shelf reasoning models from 1.5B to 120B often sample Markovian traces zero-shot across diverse benchmarks. These naturally occurring positive samples are what make RL effective at scale.

An honest note here as well. All the figures above are values the paper reports, not something we reproduced and measured ourselves. We encourage you to check the specific experimental conditions directly in the source and the public code repository.

What It Means for ThakiCloud

The practical implication of Markovian Thinking reaches both of ThakiCloud’s products.

The ai-platform angle is especially direct. What actually drives up the cost of serving long reasoning is the KV cache and attention compute that grow as thinking lengthens. If the context grows without bound, the number of concurrent requests you can fit on a single H200 drops, and GPU memory pressure worsens in a multi-tenant setting. Capping the amount loaded into the context at chunk size, as in Markovian Thinking, keeps the KV cache footprint constant regardless of thinking length. That means absorbing more concurrent inference on the same hardware under Kueue-based GPU scheduling, even for workloads that demand longer thinking. The tighter the GPU budget, as in on-premises and sovereign deployments, the larger the payoff of linear cost.

There is a Paxis angle too. Paxis is ThakiCloud’s Agent-Native Cloud, running workflows in isolated sandboxes where agents reason at length across many steps and call tools. As an agent’s reasoning lengthens, the context swells and cost and latency rise together; the fixed-state carryover of Markovian Thinking offers a way to keep long agent loops at constant memory. When the skill harness chains several skills together for a long task, a design in which each step inherits only a compressed state rather than the full history improves agent economics directly.

Limits and Counterarguments

The biggest question is information loss. Resetting the context at a chunk boundary and passing only a short state means that any detail of the preceding chunk not captured in that short state is gone for good. The policy must genuinely learn to compress what matters into the state, and getting the state size and chunk size wrong can hurt performance on problems that demand long-range dependencies. Not every kind of reasoning chunks cleanly into a Markovian form.

The approach also only works once RL has trained the state-writing habit. Apply it as-is to a model that has not yet learned to write states and the chunks break apart. That said, the paper’s observation that off-the-shelf models already sample Markovian traces to some degree eases this bootstrap burden. Finally, the reported gains are for the paper’s experimental setup and benchmarks, and whether they transfer intact to real production inference in very different domains needs separate verification.

Wrapping Up

Before trying to solve the cost of long reasoning by scaling the model, Markovian Thinking says to change the definition of the problem itself: do not let the state grow without bound, fix it. If you serve or train long reasoning, the one thing to take away today is clear. Lengthening the thinking and growing the context without bound are not the same thing, and separating the two opens room to get the same performance for far less cost. Letting the policy learn for itself what to keep and what to discard at a chunk boundary is a cheap lever worth examining first, in a serving reality where inference cost is business cost.

Source: The Markovian Thinker: Architecture-Agnostic Linear Scaling of Reasoning (arXiv:2510.06557) · Code repository (McGill-NLP/the-markovian-thinker)

An abstract rendering of SEED’s self-evolving loop: mining skills from completed trajectories and feeding them back into the same policy.

Why This Is Worth Reading

This post is written for the engineer who post-trains agents with reinforcement learning and for the platform owner who designs the training infrastructure underneath. You face a single decision: how do you push additional supervision into an RL pipeline that currently rewards only the outcome? SEED (Self-Evolving On-Policy Distillation, arXiv:2607.14777) answers with a path that uses neither a separate strong teacher model nor a human-built reward model, but the policy itself as its own teacher. In short, the loop of analyzing a trajectory, extracting reusable skills, and using how much those skills shift the policy’s action probabilities as the training signal manufactures supervision over intermediate decisions without any extra labels.

Overview

The last few years of reasoning-model training have been led by outcome-based reinforcement learning, the RLVR family that uses verifiable rewards. You hand out a trajectory-level reward such as 1 for correct and 0 for wrong and push the policy upward. For single-response math or coding problems this works well. Agents are the problem. In a long trajectory that calls tools repeatedly, receives observations, and acts again, whether the final answer succeeded tells you almost nothing about whether each of the dozens of intermediate decisions in between was good or bad. A supervision gap opens up between the episode-level outcome and token-level learning. That gap is the fundamental bottleneck eating into the sample efficiency of agentic RL.

SEED proposes a way to close it. The core idea is that a completed trajectory already contains what there is to learn. A successful trajectory holds a reusable workflow; a failed one holds a trap to avoid. SEED makes this hindsight explicit as natural-language skills, then distills those skills back into the policy. And the analyst that extracts these skills is not an external model but the current policy itself. It is a self-evolving structure in which the policy both collects trajectories and mines skills from them.

What SEED Is

In one sentence, SEED is a self-evolving framework that converts completed on-policy trajectories into training-time hindsight skills and distills their behavioral effect back into the policy model. Break it into three steps and the structure becomes clear.

First, the policy is fine-tuned to analyze completed trajectories and generate natural-language skills. These skills capture reusable workflows, decisive observations, or failure-avoidance rules. Rather than a human injecting rules through a prompt, the model extracts rules from its own experience and states them in language.

Second, during RL the current policy plays two roles at once. One is to interact with the environment and collect trajectories as usual; the other is to serve as the analyst that extracts hindsight skills from those trajectories. Because there is no separate teacher, no teacher-student distribution mismatch arises, and the skills stay aligned with the trajectory distribution the policy is actually walking right now.

Third, and this is SEED’s core device, it re-scores the sampled actions under two contexts. One is an ordinary context without skills, the other is a context augmented with the extracted skills. How much the probability of a given action rises or falls when the skill is attached, that probability shift, becomes a dense per-token on-policy distillation signal. This signal is then optimized jointly with outcome-based RL. It nudges the policy toward the actions it would have chosen with higher probability had the skill been present, and crucially this auxiliary supervision stays aligned with the current trajectory distribution.

The diagram below shows the loop.

flowchart TB
    A[Current policy] -->|interact with environment| B[Collect completed trajectories]
    B --> C[Same policy switches to analyst]
    C -->|reusable workflows<br/>decisive observations<br/>failure-avoidance rules| D[Natural-language hindsight skills]
    D --> E{Re-score actions}
    E -->|context without skills| F[Base probability]
    E -->|context with skills| G[Skill-aware probability]
    F --> H[Probability shift = per-token distillation signal]
    G --> H
    H -->|jointly optimized with outcome RL| A

The contrast with prior approaches is clear. Distilling from a strong external teacher requires finding that teacher, and if the teacher and student distributions drift apart the signal is contaminated. Building a human reward model is label-expensive. SEED avoids both. The teacher is the policy itself, the labels are extracted automatically from trajectories, and the signal is aligned with the current policy at every step.

What the Paper Reports

The paper reports extensive experiments on both text-based and vision-based agentic tasks. The direction of the results is consistent. SEED improved both performance and sample efficiency, and its generalization to scenarios not seen during training was robust. Compared with powerful baseline methods, it achieved the strongest average performance across three representative agentic benchmarks, which is the paper’s central claim.

An honest note belongs here. This post is written on the basis of the paper’s abstract and public summary, and we encourage you to check the per-benchmark numbers directly in the source. These are not values we measured through a separate reproduction, so rather than quote absolute figures we focused on conveying the structure and direction of the results. Even the direction alone carries a clear implication. Higher sample efficiency means reaching the same performance with fewer trajectories, which is to say fewer GPU-hours, and that maps directly onto saving the most expensive resource for anyone actually running agentic RL.

What It Means for ThakiCloud

The idea SEED puts forward touches both products ThakiCloud operates.

The Paxis angle is especially direct. Paxis is ThakiCloud’s Agent-Native Cloud, treating skills, tools, policies, and audit logs as first-class resources. Within it lives a self-evolving skill layer where agents mine skills from experience and improve on their own. What SEED demonstrated academically is exactly this idea, that a loop which makes completed trajectories explicit as natural-language skills and feeds them back into behavior genuinely improves the policy. If the Paxis skill harness selects from more than 960 skills via BM25, executes them in isolated sandboxes, and passes every action through policy gates and audit logs, SEED offers the training-time theoretical backing for how those skills are born from experience and refined. Skills expressed in natural language can be read and audited by humans, which fits well with the Paxis design philosophy that prizes policy gates and audit logs.

There is an ai-platform angle too. Actually running a method like SEED requires a post-training pipeline that jointly optimizes outcome-based RL and a distillation signal, and that consumes substantial GPU resources. ThakiCloud’s ai-platform operates post-training such as SFT, DPO, and GRPO on top of Kueue-based GPU scheduling and multi-tenant serving. The sample-efficiency improvement SEED emphasizes translates straight into cost on this infrastructure. Reaching the same agent quality with fewer trajectories means absorbing more training jobs on a shared GPU pool, or training more deeply on the same budget.

Limits and Counterarguments

SEED’s self-evolving structure is powerful, but the fact that the policy doubles as the analyst is a double-edged sword. In the early stage when the policy is still weak, the quality of the skills it extracts is necessarily low too, and a distillation signal built from low-quality skills risks pushing learning in the wrong direction. The price of not using a strong external teacher is that securing signal quality during the early bootstrap phase becomes the practical crux.

Extracting skills and re-scoring actions under two contexts also adds computation over pure outcome-based RL. The trade-off between the gain of fewer trajectories from better sample efficiency and the cost of adding analysis and re-scoring per trajectory will depend on the task and scale. Finally, the results this post rests on are for the three benchmarks the paper selected, and whether the gain transfers intact to other domains, especially real production agents with very different tool ecosystems, needs separate verification.

Wrapping Up

Diagnosing the bottleneck of agentic reinforcement learning as a supervision gap rather than a lack of model capability points to a direction: before scaling the model, make the signal denser. SEED shows a path to that denser signal that does not buy it from outside but mines it, in the form of natural-language skills, from trajectories the agent has already produced and feeds back into itself. If you operate an agentic RL pipeline, the one thing to take away today is clear. If you are rewarding only the outcome, do not throw the trajectory away; check first whether there is room to extract hindsight skills and recycle them as per-token supervision. That may be the cheaper lever to try before a bigger model or a stronger teacher.

Source: SEED: Self-Evolving On-Policy Distillation for Agentic Reinforcement Learning (arXiv:2607.14777)

완료율 격차라는 문제

무인 에이전트 루프, 즉 밤새 스케줄대로 돌거나 사람이 매 단계를 지켜보지 않는 자동화는 시도한 작업 수와 실제로 끝낸 작업 수가 일치할 때만 신뢰할 수 있습니다. 현실에서는 이 둘 사이에 큰 틈이 생깁니다. 에이전트가 아직 끝나지 않은 일을 끝났다고 스스로 선언해버리거나, 이전 진행 상황을 조용히 되돌려버리거나, 같은 행동만 반복하며 전혀 앞으로 나아가지 못하는 경우가 그렇습니다. 이 논문은 시도한 작업 수와 검증된 성공 작업 수의 차이를 완료율 격차라고 부르고, 어떤 하네스 메커니즘이 이 격차를 실제로 얼마나 좁히는지를 핵심 질문으로 삼습니다.

루프 엔지니어링 분야는 이미 표준적인 답을 몇 가지 내놓았습니다. 자기보고를 그대로 믿지 않고 독립적인 검증을 거쳐야만 완료를 인정하는 검증 게이트, 조용한 퇴행을 감지해 직전 정상 상태로 되돌리는 체크포인트 롤백, 진전 없이 같은 자리를 맴도는 상태를 감지해 전략을 바꾸는 정체 에스컬레이션이 그 세 가지입니다. 문제는 이 메커니즘들의 가치가 대개 설계 의도에서 나온 주장으로만 제시되고, “루프를 닫아라”는 슬로건 수준을 벗어나 실제로 측정된 적은 드물다는 점입니다. 세 메커니즘을 한꺼번에 넣고 루프가 좋아졌다고 해서, 셋 다 기여했는지 하나가 결과를 견인했는지 둘이 상호작용했는지는 결과만 봐서는 알 수 없습니다. 이 연구는 ThakiCloud가 실제로 운영하는 하네스, 즉 verify_gate.py의 검증 게이트, hermes-checkpoint-rollback의 롤백, loop-trigger-gate의 정체 정의를 그대로 가져와 이 질문에 통제 실험으로 답합니다.

측정 방법: 실측이 아닌 통제된 시뮬레이션

실제 LLM 기반 프로덕션 루프(pge-loop, Goal Mode의 daemon_tick)를 여덟 가지 메커니즘 조합으로 수천 번씩 재실행해 통계적으로 안정된 추정치를 얻는 것은 비용상 불가능합니다. 그래서 이 연구는 실제 프로덕션 코드의 판단 로직을 그대로 부호화한 CPU 전용 이산사건 시뮬레이션을 만들어 실제로 실행했습니다. 시뮬레이션이 주입하는 세 가지 결함은 각 메커니즘이 원래 막으려는 바로 그 실패 양상입니다. 조용한 퇴행, 성급하게 환각된 완료 자기보고, 진전 없는 정체가 그것입니다.

여기서 정직하게 짚어야 할 지점이 있습니다. 이 실험은 진짜 LLM이 도는 프로덕션 루프를 다시 실행한 것이 아니라, 그 하네스의 코드 의미론을 충실히 옮긴 합성 결함 주입 시뮬레이션입니다. 실제 LLM의 확률적 행동과 실제 작업의 의미론을 포기하는 대신, 여덟 개 구성을 CRN(공통 난수) 기법으로 분산을 줄여 통계적으로 안정된 추정치를 얻는 쪽을 택한 것입니다. 시드 30개, 시드마다 작업 300개씩을 검증(V), 롤백(R), 정체 에스컬레이션(S) 세 스위치의 온오프 여덟 조합에 모두 동일한 난수로 흘려보내, 조합 간 결과 차이가 순전히 메커니즘 로직에서 나오도록 설계했습니다. 각 작업은 5에서 20 사이의 진짜 난이도(진짜 완료에 필요한 진행 증가분 수)를 부여받고, 매 반복마다 55%의 진행, 15%의 퇴행, 30%의 정체 확률로 결과가 갈립니다. 정체가 세 번 연속되면 에스컬레이션이 켜져 있을 때 진행 확률이 85%까지 오르는 부스트 상태로 전환됩니다. 검증 게이트가 꺼져 있을 때는 매 반복마다 5%의 확률로 완료를 성급하게 자기보고하는 환각이 섞여 들어가고, 게이트가 켜져 있으면 이 성급한 주장은 결정론적으로 거부됩니다.

검증 게이트의 압도적 효과와 그 함정

여덟 개 조합 전체를 놓고 보면, 세 메커니즘을 모두 끈 기준선의 실제 성공률은 26.22퍼센트에 그칩니다. 세 메커니즘을 모두 켰을 때는 97.59퍼센트까지 올라가, 완료율 격차 71.37퍼센트포인트가 닫힙니다.

여덟 개 메커니즘 조합별 실제 성공률입니다. 세 메커니즘을 모두 켰을 때만 90퍼센트대에 도달하고, 검증 게이트가 꺼진 조합은 아무리 롤백과 에스컬레이션을 더해도 30퍼센트대를 넘지 못합니다. ThakiCloud AI Platform Demo 클러스터의 CPU 전용 잡으로 30개 시드, 시드당 300개 작업을 CRN 시뮬레이션으로 측정한 결과입니다.

두 지점 근사 섀플리 값으로 각 메커니즘의 기여를 나눠보면 검증 게이트가 55.3퍼센트포인트, 체크포인트 롤백이 15.2퍼센트포인트, 정체 에스컬레이션이 0.64퍼센트포인트를 차지합니다. 검증 게이트는 켜져 있는 모든 조합에서 거짓 성공률을 정확히 0으로 만드는 유일한 메커니즘이기도 합니다. 성급한 완료 주장을 구조적으로 거부하기 때문에 환각된 “완료” 상태가 아예 발생할 수 없는 것입니다.

그런데 이 압도적인 효과에는 대가가 따릅니다. 검증 게이트만 켜고 롤백과 에스컬레이션은 끈 조합에서는 평균 반복 횟수가 13.4회에서 23.7회로 거의 두 배가 되고, 반복 한도를 소진해 아무 결론도 내지 못하는 비율이 3.2퍼센트에서 24.1퍼센트로 치솟습니다. 예전 같으면 (틀리게) 완료를 선언하고 끝났을 작업들이 이제는 계속 반복을 강요받는데, 회복 수단이 없으니 그중 4분의 1가량이 그냥 반복 한도에 걸려 미완으로 남는 것입니다. 검증만 추가하고 멈춘 팀은 거짓 성공은 사라졌다고 안심하겠지만, 실은 실패의 모양만 바뀐 셈입니다.

체크포인트 롤백의 시너지와 의외로 약한 정체 감지

체크포인트 롤백을 단독으로 켰을 때의 효과는 10.1퍼센트포인트에 그치지만, 전체 구성에서 롤백만 빼봤을 때 떨어지는 폭은 20.3퍼센트포인트로 거의 두 배입니다. 두 메커니즘이 서로 독립적이지 않고 강하게 맞물려 있다는 뜻입니다. 이 시너지는 반복 한도 소진율에서 가장 선명하게 드러납니다. 검증 게이트가 거짓 완료라는 탈출구를 막아버리면 작업들이 반복 한도 앞에 쌓이는데(게이트만 켰을 때 24.1퍼센트 소진), 체크포인트 롤백이 바로 그 쌓인 작업들을 되찾아옵니다. 검증과 롤백을 함께 켜면 소진율이 3.0퍼센트로 떨어집니다. 롤백은 게이트가 혼자 만들어낸 반복 소진 비용을 완료된 작업으로 되돌리는 셈이고, 그 대가는 작업당 약 3.4회의 되돌려진 반복뿐입니다.

세 메커니즘이 닫은 71.4퍼센트포인트의 격차 중 검증 게이트가 55.3, 체크포인트 롤백이 15.2, 정체 에스컬레이션이 0.6퍼센트포인트를 차지합니다. 롤백의 단독 효과(10.1)보다 다른 메커니즘이 있을 때 빠지면 생기는 손실(20.3)이 두 배 큰 것이 초가산적 시너지를 보여줍니다. 실측이 아니라 두 지점 섀플리 근사에 기반한 해석적 모형입니다.

검증 게이트가 없을 때 롤백은 작업당 약 1.9회의 반복을 되돌리지만, 게이트가 있을 때는 약 3.3에서 3.4회를 되돌립니다. 게이트가 만들어낸 반복 소진 비용을 롤백이 그만큼 더 많이 회수하고 있다는 뜻입니다. 게이트가 켜진 구성은 실측값이고, 롤백이 꺼진 구성 일부는 해석적 모형값입니다.

반면 정체 에스컬레이션의 기여는 0.64퍼센트포인트에 그쳤습니다. 이는 이 논문에서 기존 통념과 가장 상반되는 결과입니다. 정체와 무한루프 감지는 루프 엔지니어링 커뮤니티가 오랫동안 무겁게 다뤄온 주제인데, 이번 실험에서 만든 결함 조합에서는 지배적인 실패 원인이 환각된 완료와 조용한 퇴행이지 문자 그대로의 무한 정체가 아니었기 때문에 에스컬레이션이 거의 효과를 내지 못했습니다. 이것을 정체 감지가 쓸모없다는 보편적 주장으로 읽으면 안 됩니다. 만성적인 정체 비율이 훨씬 높은 다른 결함 분포에서는 에스컬레이션이 훨씬 중요해질 수 있고, 이 실험 방법론이 바로 그런 질문에 답하도록 설계되어 있습니다. 즉 이번 결과는 이 특정 결함 조합에서의 범위 한정적 결론입니다.

회사, 사회, 과학에 남기는 의미

ThakiCloud 입장에서 이 결과는 자사의 쿠버네티스·에이전트 플랫폼에서 하네스 투자를 어디부터 강화해야 하는지에 대한 측정 기반 순위표입니다. 신념이 아니라 실측으로 검증 게이트를 먼저, 체크포인트 롤백을 다음으로 강화하고, 정체 에스컬레이션은 결함 분포가 실제로 정체 중심일 때만 우선순위에 올리라는 구체적 지침을 얻은 것입니다. 이는 jarvis와 pge-loop 하네스를 다음에 어디부터 손볼지 결정하는 데 바로 쓰입니다.

더 넓게 보면, 조용히 정체되거나 환각으로 표류하는 무인 루프를 실제로 멈추게 하는 메커니즘이 무엇인지 가려낼수록 낭비되는 GPU·컴퓨트 자원과 사람의 감시 부담이 줄어들어, 무인 자동화를 대규모로 배치하는 일이 더 안전해집니다. 그리고 과학적으로는 “검증으로 루프를 닫아라”는 식의 포지션 페이퍼 주장 대신, 각 메커니즘의 개별 기여와 상호작용 기여를 통제된 애블레이션으로 분리해 반증 가능한 근거로 대체했다는 점이 이 연구의 방법론적 기여입니다.

한계

가장 중요한 한계는 이 실험이 실제 LLM이 도는 프로덕션 루프를 라이브로 재실행한 것이 아니라, 그 코드 의미론에 충실한 합성 결함 주입 시뮬레이션이라는 점입니다. 메커니즘의 판단 로직은 실제 프로덕션 코드에 충실하지만, 결과는 언어 모델이 실제 작업을 수행한 결과가 아니라 파라미터화된 확률분포에서 뽑힌 값입니다.

또한 진행·퇴행·정체 확률과 환각 확률은 실측 트레이스에 맞춰 적합된 값이 아니라 손으로 정한 값입니다. 정체 에스컬레이션이 약하다는 결론이 바로 이 결함 분포에 종속적이라고 명시한 만큼, 실제 실행 로그로부터 확률을 적합시키면 정량적 귀속, 특히 정체 에스컬레이션의 거의 0에 가까운 기여도가 바뀔 수 있습니다. 실제 pge-loop·daemon_tick 실행 로그로부터 이 확률들을 적합시키는 것이 향후 연구의 핵심 방향입니다.

세 메커니즘은 ThakiCloud 자체 하네스(verify_gate.py, hermes-checkpoint-rollback, loop-trigger-gate)의 판단 로직을 그대로 옮긴 것이라, 결정론적 게이트가 아니라 확률적 게이트를 쓰거나 되돌리기가 아니라 분기 기반으로 롤백을 구현하는 다른 하네스에는 방법론은 그대로 옮겨가도 구체적인 수치는 재측정이 필요합니다. 마지막으로 이 연구는 완료 여부, 거짓 성공, 소진, 반복 횟수, 낭비된 반복만을 측정 대상으로 삼았고, 실제 소요 시간이나 토큰 비용, 이진 완료를 넘어선 작업 품질의 단계적 차이는 다루지 않았습니다.

논문 상세 페이지는 Hugging Face 데이터셋에서 확인할 수 있습니다.

긴 사고를 고정 크기 청크로 끊고 짧은 상태만 다음으로 넘기는 마르코프 사고를 형상화했습니다.

왜 읽어야 하나

이 글은 긴 추론 모델을 서빙하거나 강화학습으로 훈련하는 엔지니어와, 그 추론 비용을 책임지는 플랫폼 담당자를 위한 것입니다. 여러분이 마주한 결정은 이것입니다. 모델이 더 길게 생각하게 하고 싶은데, 그 길이에 비례해 제곱으로 뛰는 계산량과 메모리를 어떻게 감당할 것인가입니다. 마르코프 사고(arXiv:2510.06557, McGill-NLP)는 사고 길이를 문맥 크기에서 분리하는 방식으로 답합니다. 결론부터 말하면, 추론을 고정 크기 청크로 끊고 청크 경계에서 다음 청크로 넘길 짧은 텍스트 상태만 남기게 하면, 사고가 아무리 길어져도 비용은 선형으로만 늘고 메모리는 상수로 유지됩니다.

개요

지난 몇 년간 추론 모델의 성능은 사고연쇄를 길게 늘이는 방향으로 올랐습니다. 더 오래 생각할수록 더 어려운 문제를 풀 수 있다는 것이 이 흐름의 전제입니다. 그런데 이 길어지는 사고에는 잘 드러나지 않는 대가가 붙어 있습니다. 표준적인 강화학습 사고 환경에서 상태는 프롬프트에 그때까지 생성한 모든 추론 토큰을 더한 것으로 정의됩니다. 즉 모델이 생각을 이어 갈수록 상태가 계속 부풀고, 어텐션 기반 정책은 그 커지는 상태를 매번 다시 훑어야 하므로 계산량이 사고 길이의 제곱으로 늘어납니다. 메모리도 함께 자랍니다. 생각을 두 배로 길게 하면 비용은 네 배가 되는 셈입니다.

마르코프 사고는 이 전제 자체를 다시 봅니다. 상태를 무한정 키우는 대신, 정책이 항상 고정된 크기의 상태만 보고 추론을 진행하게 만듭니다. 사고 길이가 문맥 크기와 묶여 있던 고리를 끊어, 사고가 길어져도 계산은 선형으로, 메모리는 상수로 유지되게 하는 것입니다. 마치 마르코프 과정에서 다음 상태가 바로 앞의 고정 상태에만 의존하듯, 다음 사고 조각이 앞선 모든 토큰이 아니라 방금 넘겨받은 고정 상태에만 의존하게 만든다는 뜻입니다.

이 기술은 무엇인가

마르코프 사고를 실제로 구현한 것이 Delethink라는 강화학습 환경입니다. Delethink는 추론을 고정 크기 청크로 구조화합니다. 각 청크 안에서 모델은 평소처럼 자유롭게 생각합니다. 그러다 청크 경계에 이르면, 환경이 문맥을 리셋하고 프롬프트를 짧은 이월분(carryover)으로 다시 초기화합니다. 여기서 핵심은 강화학습을 통해 정책이 배우는 것입니다. 정책은 각 청크가 끝나갈 무렵, 리셋 이후에도 추론을 매끄럽게 이어 가기에 충분한 텍스트 상태를 스스로 써 두는 법을 학습합니다. 다음 청크는 앞선 청크 전체가 아니라 이 짧은 상태만 물려받아 시작합니다.

아래 도표가 이 흐름을 보여 줍니다.

flowchart TB
    A[청크 시작: 짧은 이월 상태로 초기화] --> B[청크 안에서 평소처럼 자유롭게 사고]
    B --> C{청크 경계 도달?}
    C -->|아니오| B
    C -->|예| D[청크 끝에서 텍스트 상태를 스스로 기록]
    D --> E[환경이 문맥을 리셋]
    E --> F[다음 청크: 전체 이력 대신<br/>짧은 상태만 이월]
    F --> A
    D -.강화학습이 좋은 상태 기록을 보상.-> D

기존의 긴 사고연쇄 방식(LongCoT)과의 차이가 여기서 갈립니다. LongCoT은 생성한 모든 토큰을 문맥에 계속 쌓아 두므로 상태가 무한정 커집니다. Delethink는 청크마다 문맥을 비우고 짧은 상태만 넘기므로 상태 크기가 고정됩니다. 사고의 길이는 청크를 몇 번 이어 붙이느냐로 늘리되, 한 번에 문맥에 올라가는 양은 청크 하나 크기로 묶어 두는 것입니다.

논문이 보고한 실험 결과

논문이 보고한 수치는 이 발상이 실제로 통한다는 것을 보여 줍니다. R1-Distill 1.5B 모델을 Delethink 환경에서 8K 토큰 청크로 훈련했더니, 이 모델은 최대 24K 토큰까지 사고하면서 24K 예산으로 훈련한 기존 LongCoT-RL과 맞먹거나 그것을 앞섰습니다. 8K짜리 창만 보면서도 그보다 세 배 긴 추론을 해낸 것입니다.

비용 차이는 규모가 커질수록 벌어집니다. 논문은 평균 사고 길이 96K 지점에서 LongCoT-RL의 훈련 비용이 27 H100-월인 데 비해 Delethink는 7 H100-월이라고 보고합니다. 선형 대 제곱의 차이가 만드는 격차입니다.

테스트타임 스케일링에서도 차이가 납니다. 추론 시점에 사고를 더 늘렸을 때, LongCoT이 정체되는 지점에서 Delethink는 계속 개선됩니다. 또 하나 흥미로운 관찰은 강화학습 초기화 시점 분석에서 나옵니다. 1.5B부터 120B까지 시중의 여러 추론 모델이 다양한 벤치마크에서 마르코프적 궤적을 별도 훈련 없이도 곧잘 샘플링하더라는 것입니다. 이 자연 발생하는 긍정 샘플들이 강화학습을 규모에서도 효과적으로 만들어 주는 밑거름이 됩니다.

여기서도 정직하게 짚겠습니다. 위 수치는 모두 논문이 보고한 값이며, 저희가 별도로 재현해 측정한 것이 아닙니다. 구체적 실험 조건은 원문과 공개된 코드 저장소에서 직접 확인하시기를 권합니다.

ThakiCloud 제품 적용 시사점

마르코프 사고가 던지는 실무적 함의는 ThakiCloud의 두 제품 모두에 닿습니다.

ai-platform 관점이 특히 직접적입니다. 긴 추론을 서빙할 때 비용을 실제로 밀어 올리는 것은 사고가 길어질수록 커지는 KV 캐시와 어텐션 계산입니다. 문맥이 무한정 자라면 H200 한 장에 올릴 수 있는 동시 요청 수가 줄고, 멀티테넌트 환경에서 GPU 메모리 압박이 심해집니다. 마르코프 사고처럼 한 번에 문맥에 올라가는 양을 청크 크기로 고정하면, KV 캐시 발자국이 사고 길이와 무관하게 상수로 유지됩니다. 이는 Kueue 기반 GPU 스케줄링 위에서 같은 하드웨어로 더 많은 동시 추론을, 그것도 더 긴 사고를 요구하는 워크로드로 소화할 수 있다는 뜻입니다. 온프레미스와 소버린 배포처럼 GPU 예산이 빡빡한 환경일수록 선형 비용의 이점은 커집니다.

Paxis 관점도 있습니다. Paxis는 ThakiCloud의 Agent-Native Cloud로, 에이전트가 여러 단계에 걸쳐 길게 추론하고 도구를 호출하는 워크플로를 격리 샌드박스에서 실행합니다. 에이전트의 추론이 길어질수록 문맥이 부풀어 비용과 지연이 함께 오르는데, 마르코프 사고의 고정 상태 이월은 긴 에이전트 루프를 상수 메모리로 유지하는 길을 제시합니다. 스킬 하네스가 여러 스킬을 이어 붙여 긴 작업을 수행할 때, 각 단계가 전체 이력이 아니라 압축된 상태만 물려받게 하는 설계는 에이전트 경제성을 직접 개선합니다.

한계 및 반론

가장 큰 물음은 정보 손실입니다. 청크 경계에서 문맥을 리셋하고 짧은 상태만 넘긴다는 것은, 앞선 청크의 세부가 그 짧은 상태에 담기지 못하면 영영 사라진다는 뜻입니다. 정책이 정말 중요한 것을 상태에 잘 압축해 넣도록 학습해야 하며, 상태 크기와 청크 크기를 잘못 잡으면 긴 의존성을 요구하는 문제에서 성능이 떨어질 수 있습니다. 모든 추론이 마르코프적으로 잘 쪼개지는 것은 아닙니다.

또한 이 방식은 강화학습으로 상태 기록 습관을 길들여야 비로소 작동합니다. 상태를 쓰는 법을 아직 배우지 못한 모델에 그냥 적용하면 청크 사이가 끊깁니다. 다만 논문이 관찰한 대로 시중 모델들이 마르코프적 궤적을 어느 정도 자연히 샘플링한다는 점은 이 부트스트랩 부담을 덜어 줍니다. 마지막으로 보고된 이득은 논문의 실험 설정과 벤치마크에 대한 것이며, 도메인이 크게 다른 실제 프로덕션 추론으로 그대로 이전될지는 별도의 검증이 필요합니다.

정리

긴 추론의 비용 문제를 모델을 더 키우는 것으로 풀려 하기 전에, 마르코프 사고는 문제의 정의 자체를 바꾸라고 말합니다. 상태를 무한정 키우지 말고 고정하라는 것입니다. 여러분이 긴 추론을 서빙하거나 훈련한다면 오늘 가져갈 한 가지는 분명합니다. 사고를 길게 늘리는 것과 문맥을 무한정 키우는 것은 같은 일이 아니며, 둘을 분리하면 같은 성능을 훨씬 적은 비용으로 얻을 여지가 생긴다는 것입니다. 청크 경계에서 무엇을 남기고 무엇을 버릴지를 정책이 스스로 배우게 하는 이 설계는, 추론 비용이 곧 사업 비용인 서빙 현장에서 먼저 살펴볼 값싼 레버입니다.

출처: The Markovian Thinker: Architecture-Agnostic Linear Scaling of Reasoning (arXiv:2510.06557) · 코드 저장소(McGill-NLP/the-markovian-thinker)

완료된 궤적에서 스킬을 캐내 다시 자기에게 되먹이는 SEED의 자기진화 루프를 형상화했습니다.

왜 읽어야 하나

이 글은 에이전트를 강화학습으로 후처리 훈련하는 엔지니어와, 그 훈련 인프라를 설계하는 플랫폼 담당자를 위한 것입니다. 여러분이 내려야 할 결정은 하나입니다. 결과 하나로만 보상을 주는 지금의 RL 파이프라인에, 어떻게 추가 감독 신호를 더 밀어 넣을 것인가입니다. SEED(Self-Evolving On-Policy Distillation, arXiv:2607.14777)는 그 답으로 별도의 강한 교사 모델도, 사람이 만든 보상 모델도 아닌 정책 자기 자신을 교사로 쓰는 길을 제시합니다. 결론부터 말하면, 궤적을 분석해 재사용 가능한 스킬을 뽑아내고 그 스킬이 정책의 행동 확률을 얼마나 바꾸는지를 신호로 삼는 이 자기진화 루프는, 추가 라벨 없이도 중간 결정에 대한 감독을 만들어 냅니다.

개요

지난 몇 년의 추론 모델 훈련은 결과 기반 강화학습, 즉 검증 가능한 보상을 쓰는 RLVR 계열이 이끌었습니다. 정답이면 1, 오답이면 0 같은 궤적 수준 보상을 주고 정책을 밀어 올리는 방식입니다. 단일 응답을 뱉는 수학이나 코딩 문제에서는 이 방식이 잘 통합니다. 문제는 에이전트입니다. 도구를 여러 번 호출하고, 관찰을 받고, 다시 행동하는 긴 궤적에서는 마지막 성공 여부 하나가 그 사이에 있었던 수십 개의 중간 결정 각각이 좋았는지 나빴는지를 거의 알려 주지 못합니다. 에피소드 수준의 결과와 토큰 수준의 학습 사이에 감독의 공백이 생기는 것입니다. 이 공백이 에이전트 RL의 샘플 효율을 갉아먹는 근본 병목입니다.

SEED는 이 공백을 메우는 방법을 제안합니다. 핵심 발상은 완료된 궤적 안에 이미 배울 것이 들어 있다는 것입니다. 성공한 궤적에는 재사용할 만한 작업 흐름이 있고, 실패한 궤적에는 피해야 할 함정이 있습니다. SEED는 이 사후 지식(hindsight)을 자연어 스킬로 명시화한 다음, 그 스킬을 다시 정책에게 증류해 넣습니다. 그리고 이 스킬을 뽑는 분석가 역할을 외부 모델이 아니라 현재 정책 자신이 맡습니다. 정책이 궤적도 모으고, 그 궤적에서 스킬도 뽑는 자기진화 구조입니다.

SEED는 무엇인가

SEED를 한 문장으로 요약하면, 완료된 온폴리시 궤적을 훈련 시점의 사후 스킬로 바꾸고 그 스킬의 행동적 효과를 정책 모델에 다시 증류하는 자기진화 프레임워크입니다. 세 단계로 나눠 보면 구조가 분명해집니다.

첫째, 정책을 미세조정해 완료된 궤적을 분석하고 자연어 스킬을 생성하게 만듭니다. 이 스킬은 재사용 가능한 작업 흐름, 결정적이었던 관찰, 실패를 피하는 규칙 같은 것을 담습니다. 사람이 프롬프트로 규칙을 주입하는 것이 아니라, 모델이 자기 경험에서 규칙을 언어로 뽑아내는 것입니다.

둘째, RL이 도는 동안 현재 정책이 두 가지 역할을 동시에 맡습니다. 하나는 늘 하던 대로 환경과 상호작용하며 궤적을 수집하는 역할이고, 다른 하나는 그 궤적을 분석해 사후 스킬을 뽑아내는 분석가 역할입니다. 교사가 따로 없으니 교사와 학생 사이의 분포 어긋남이 생기지 않고, 스킬은 언제나 지금 정책이 실제로 밟고 있는 궤적 분포에 맞춰져 있습니다.

셋째, 여기가 SEED의 핵심 장치입니다. SEED는 샘플링된 행동을 두 가지 맥락에서 다시 채점합니다. 하나는 스킬이 없는 평범한 맥락이고, 다른 하나는 뽑아낸 스킬을 덧붙인 맥락입니다. 스킬을 붙였을 때 특정 행동의 확률이 얼마나 올라가거나 내려가는지, 그 확률 변화를 토큰 단위의 촘촘한 온폴리시 증류 신호로 바꿉니다. 그리고 이 신호를 결과 기반 RL과 함께 최적화합니다. 스킬이 있었으면 더 높은 확률로 택했을 행동 쪽으로 정책을 미는 것인데, 이 보조 감독이 언제나 현재 궤적 분포에 정렬되어 있다는 점이 중요합니다.

아래 도표가 이 루프를 보여 줍니다.

flowchart TB
    A[현재 정책] -->|환경과 상호작용| B[완료된 궤적 수집]
    B --> C[같은 정책이 분석가로 전환]
    C -->|재사용 워크플로<br/>결정적 관찰<br/>실패 회피 규칙| D[자연어 사후 스킬]
    D --> E{행동 재채점}
    E -->|스킬 없는 맥락| F[기본 확률]
    E -->|스킬 붙인 맥락| G[스킬 반영 확률]
    F --> H[확률 변화 = 토큰 단위 증류 신호]
    G --> H
    H -->|결과 RL과 공동 최적화| A

기존 접근과의 차이는 분명합니다. 강한 외부 모델을 교사로 두고 증류하는 방식은 교사를 구해야 하고, 교사와 학생의 분포가 어긋나면 신호가 오염됩니다. 사람이 보상 모델을 만드는 방식은 라벨 비용이 큽니다. SEED는 둘 다 피합니다. 교사는 정책 자신이고, 라벨은 궤적에서 자동으로 추출되며, 신호는 매 순간 현재 정책에 맞춰집니다.

논문이 보고한 실험 결과

논문은 텍스트 기반과 비전 기반 에이전트 과제 양쪽에서 광범위한 실험을 수행했다고 보고합니다. 결과의 방향은 일관됩니다. SEED는 성능과 샘플 효율을 함께 개선했고, 훈련에서 보지 못한 시나리오로의 일반화도 견고했다고 합니다. 강력한 베이스라인 방법들과 비교했을 때 세 개의 대표적인 에이전트 벤치마크에서 가장 높은 평균 성능을 기록했다는 것이 논문의 핵심 주장입니다.

여기서 정직하게 짚을 것이 있습니다. 이 글은 논문의 초록과 공개된 요약을 근거로 작성했으며, 벤치마크별 구체적 수치는 원문에서 직접 확인하시기를 권합니다. 저희가 별도로 재현 실험을 돌려 측정한 값이 아니므로, 절대 수치를 인용하기보다 결과의 구조와 방향을 전달하는 데 집중했습니다. 다만 방향성만으로도 시사점은 분명합니다. 샘플 효율이 올랐다는 것은 같은 성능에 도달하는 데 더 적은 궤적, 곧 더 적은 GPU 시간이 든다는 뜻이고, 이는 에이전트 RL을 실제로 운용하는 쪽에서 가장 비싼 자원을 아끼는 것과 직결됩니다.

ThakiCloud 제품 적용 시사점

SEED가 던지는 발상은 ThakiCloud가 운용하는 두 제품 모두와 맞닿아 있습니다.

Paxis 관점이 특히 직접적입니다. Paxis는 ThakiCloud의 Agent-Native Cloud로, 스킬과 도구, 정책, 감사 로그를 일급 리소스로 다룹니다. 그 안에는 에이전트가 경험에서 스킬을 뽑아내 스스로 진화하는 자가진화 스킬 계층이 있습니다. SEED가 학술적으로 보여 준 것은 바로 이 발상, 즉 완료된 궤적을 자연어 스킬로 명시화하고 그것을 다시 행동에 되먹이는 루프가 실제로 정책을 개선한다는 점입니다. Paxis의 스킬 하네스가 960개가 넘는 스킬을 BM25로 선택해 격리 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시키는 구조라면, SEED는 그 스킬들이 어떻게 경험에서 태어나 다듬어지는지에 대한 훈련 시점의 이론적 뒷받침을 제공합니다. 자연어로 표현된 스킬은 사람이 읽고 감사할 수 있다는 점에서, 정책 게이트와 감사 로그를 중시하는 Paxis의 설계 철학과도 잘 맞습니다.

ai-platform 관점도 있습니다. SEED 같은 방법을 실제로 돌리려면 결과 기반 RL과 증류 신호를 함께 최적화하는 후처리 훈련 파이프라인이 필요하고, 이는 GPU 자원을 상당히 먹습니다. ThakiCloud의 ai-platform은 Kueue 기반 GPU 스케줄링과 멀티테넌트 서빙 위에서 SFT, DPO, GRPO 같은 후처리 훈련을 운용합니다. SEED가 강조하는 샘플 효율 개선은 이 인프라에서 곧바로 비용으로 환산됩니다. 같은 에이전트 품질에 더 적은 궤적으로 도달한다면, 공유 GPU 풀에서 더 많은 훈련 잡을 소화하거나 같은 예산으로 더 깊이 훈련할 수 있습니다.

한계 및 반론

SEED의 자기진화 구조는 강력하지만, 정책 자신이 분석가를 겸한다는 점은 양날의 검입니다. 정책이 아직 약한 초기 단계에서는 그 정책이 뽑아내는 스킬의 질도 낮을 수밖에 없고, 낮은 질의 스킬로 만든 증류 신호가 학습을 잘못된 방향으로 밀 위험이 있습니다. 강한 외부 교사를 쓰지 않는 대가로, 초기 부트스트랩 구간의 신호 품질을 어떻게 확보하느냐가 실전에서의 관건이 됩니다.

또한 스킬을 뽑고 행동을 두 맥락에서 재채점하는 과정은 순수한 결과 기반 RL보다 계산량이 늘어납니다. 샘플 효율이 좋아져 궤적 수가 줄어드는 이득과, 궤적마다 분석과 재채점을 추가하는 비용 사이의 손익은 과제와 규모에 따라 달라질 것입니다. 마지막으로 이 글이 근거한 결과는 논문이 선정한 세 개 벤치마크에 대한 것이며, 그 밖의 도메인, 특히 도구 생태계가 크게 다른 실제 프로덕션 에이전트로 이 이득이 그대로 이전될지는 별도의 검증이 필요합니다.

정리

에이전트 강화학습의 병목이 모델 능력이 아니라 감독의 공백이라는 진단은, 모델을 더 키우기 전에 신호를 더 촘촘하게 만들라는 방향을 가리킵니다. SEED는 그 촘촘한 신호를 외부에서 사 오지 않고, 에이전트가 이미 만들어 낸 궤적 안에서 자연어 스킬의 형태로 캐내 자기 자신에게 되먹이는 길을 보여 줍니다. 여러분이 에이전트 RL 파이프라인을 운용한다면 오늘 가져갈 한 가지는 분명합니다. 결과 하나로만 보상을 주고 있다면, 그 궤적을 버리지 말고 사후 스킬을 뽑아 토큰 단위 감독으로 재활용할 여지가 있는지 먼저 점검해 보십시오. 그것이 더 큰 모델이나 더 강한 교사보다 먼저 시도할 값싼 레버일 수 있습니다.

출처: SEED: Self-Evolving On-Policy Distillation for Agentic Reinforcement Learning (arXiv:2607.14777)

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

نفس اليوم، من الطرف المقابل تماما

يمثل Laguna S 2.1 من Poolside ورقة رد أقرب ما تكون إلى الجبهة الغربية. جاء هذا الإعلان في سياق التيار الذي كانت تتصدره نماذج مفتوحة الأوزان من أصل صيني مثل DeepSeek وQwen في مجال وكلاء البرمجة. وصفته وسائل إعلام أجنبية بأنه الخيار الأكثر موثوقية بين النماذج الغربية مفتوحة الأوزان خلال العام الماضي لغرض البرمجة الوكيلية المستضافة ذاتيا. واللافت هنا ليس الأداء بل الحجم. فبنية منخفضة التنشيط تضم ثمانية مليارات معامل نشط استطاعت مجاراة منافسين أكبر بأضعاف في مقاييس الأداء، وهذا يعني أن الرسالة الحقيقية هي خفض تكلفة الاستدلال وعبء التشغيل على المنشأة في آن واحد. والقدرة على تشغيله على جهاز واحد بمستوى DGX Spark تعني أنه يمكن الآن تشغيل وكيل برمجة مخصص حتى على تقسيمات GPU صغيرة.

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

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

النقطة التي غيرت فيها الأوزان المفتوحة قواعد التدقيق

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

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

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

الفجوة التي لا يسدها لا التوليد ولا التدقيق

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

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

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

سيادة العتاد وحدها لا تغلق الفجوة

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

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

المطابقة تتم في طبقة التنفيذ

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

flowchart TB
    G1["Agent that writes code<br/>Laguna S 2.1"]
    A1["Agent that finds vulnerabilities<br/>Antares"]
    GAP["The unanswered question<br/>on whose resources<br/>with what authority<br/>logging what, does it run"]
    subgraph PAXIS["ThakiCloud Paxis · Execution Layer"]
        P1["Policy gate<br/>L0-L3 autonomy governance"]
        P2["Isolated sandbox execution"]
        P3["Audit logs"]
        P4["CostRouter · Sovereign Kubernetes"]
    end
    G1 --> GAP
    A1 --> GAP
    GAP --> P1
    P1 --> P2
    P2 --> P3
    P1 --> P4

منصة Paxis من ThakiCloud تتناول بالضبط هذه الطبقة الغائبة. Paxis منتج فعلي يمثل سحابة مخصصة للوكلاء، يعامل المهارات والأدوات والسياسات وسجلات التدقيق كموارد أساسية من الدرجة الأولى. سواء وصلت وكيل برمجة مثل Laguna S 2.1 بالخلفية، أو وصلت نموذج تدقيق مثل Antares في مقدمة عملية الفحص، فإن ذلك الوكيل يمر في النهاية عبر بوابة سياسة ويُنفذ داخل صندوق رملي معزول، وتُسجَّل كل تصرفاته في سجل تدقيق. وإذا بدا التراجع التلقائي بلا موافقة في حالة Imweb مثيرا للقلق، فإن حوكمة الاستقلالية في Paxis الممتدة من المستوى L0 إلى L3 هي الوجه المقابل لذلك القلق، إذ يمكن الإعلان بالسياسة لا بالكود عن الحد الفاصل بين المهام التي تُترك للاستقلالية الكاملة والمهام التي تُلزَم بموافقة بشرية.

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

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

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

المصادر

هذا المقال يجمع بين التغطية الإخبارية التالية:

• 글로벌경제، 엔비디아, 차세대 AI플랫폼 ‘베라루빈’ 본격 공급 통해 “선두 수성”
• 머니투데이، LGU+·LS일렉트릭, AI 데이터센터 800V DC 공동 개발 나선다
• 글로벌이코노믹، HPE, 슈퍼컴퓨팅 개발환경 통합…소버린 AI 인프라 간소화
• 뉴스웍스، [#클라우드 월드] 삼성SDS-퓨리오사AI ‘NPUaaS’ 출시·LG CNS ‘AI 캠퍼스’…
• 지디넷코리아، “SKT, AI팩토리에 가장 적극적인 통신사…풀스택AI·전국망 경쟁력”
• 약업신문، BMS‧엔비디아, 생명공학 최강 AI 팩토리 구축
• 글로벌이코노믹، 미국 데이터센터 전력 수요 급증… 호남 반도체 허브, 전력망·용수가 …
• 디지털투데이، 풀사이드, 코딩 에이전트용 오픈웨이트 모델 ‘라구나 S 2.1’ 공개
• 이투데이، 키미 쇼크에 ‘AI 2강’ 험로…’특화 AI’ 키우고, 경량화 모델로 차별화…
• 디지털투데이، 포티투마루, 예금보험공사 데이터 관리체계 고도화·생성형 AI 서비스 구…
• 뉴스투데이، 밖에선 AI 인재 찾고 안에선 업무 혁신…NHN의 AX ‘승부수’
• 바이라인네트워크، “4년 걸린 일을 3개월에”…아임웹이 안팎으로 AI 쓰는 법
• IT조선، 내년 지원 불투명한데…정부 ‘모두의 AI’ 출시 서두르나
• EBN، 이재용·최태원·이해진, 美서 젠슨 황 만난다…AI 공급망 동맹 재가동
• 디지털투데이، 시스코, 코드 취약점 탐지 특화 오픈웨이트 소형 모델 ‘안타레스’ 공개
• 뉴스저널리즘، AI가 바꾼 보안 공식…에스원 ‘현장 데이터’로 승부

لماذا تقرأ هذا

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

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

نظرة عامة

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

Archify، الذي حظي مؤخرًا باهتمام واسع في مجتمع المطورين الصيني، يستهدف هذه النقطة تحديدًا. أعطِ Claude Code أو Codex جملة عادية مثل “اقرأ هذه المستودعات وارسم لي مخططًا مقارنًا لبنياتها”، فتحصل على مخطط HTML ذاتي الاكتفاء يُفتح مباشرة في المتصفح. يمكنك التبديل بين السمتين الداكنة والفاتحة، وتصديره إلى PNG أو SVG.

حتى هذه النقطة، يبدو الكلام كعبارات تسويقية معتادة. لذلك، بدل تصديق العبارات، ثبّتناها فعليًا وشغّلناها، ورسمنا بها بنية ai-platform الخاصة بـ ThakiCloud. كشفت هذه العملية لماذا تختلف هذه الأداة عن “مولّد رسوم بالذكاء الاصطناعي” بسيط. هذا المقال سجل لتلك التجربة، وفي الوقت نفسه محاولة لفهم كيف تتصل بفلسفة تصميم Paxis، منصة الوكلاء التي تبنيها ThakiCloud.

ما هذه الأداة

Archify مهارة وكيل مفتوحة المصدر أصدرها tt-a1i برخصة MIT. عند وقت تجربتنا كان الإصدار 2.11.0، وهي نسخة أُعيدت كتابتها كفرع (fork) من architecture-diagram-generator v1.0 لشركة Cocoon AI، وتنسب لغتها البصرية الأصلية إلى Cocoon AI. تُثبَّت على عدة أوقات تشغيل للوكلاء منها Claude وCodex CLI وopencode.

فهم البنية الجوهرية يوضّح سبب تميّز هذه الأداة. لا يرسم Archify الصورة مباشرة. بدلًا من ذلك، يصف المخطط بصيغة JSON-IR (تمثيل وسيط)، ويحوّل مُصيّر مخصص لكل نوع ذلك JSON إلى HTML. هناك خمسة مُصيّرات: architecture وworkflow وsequence وdataflow وlifecycle. بعبارة أخرى، “ماذا نرسم” يعيش في JSON مُهيكَل، و”كيف نرسمه” تملكه شيفرة مُتحقَّق منها.

تتولى المُصيّرات الخمسة كل نوع مختلف من الرسوم. architecture يغطي مكونات النظام وحدوده، وworkflow يغطي إجراءات مثل سلاسل الموافقة أو CI/CD، وsequence يغطي دورة حياة الطلب أو ترتيب استدعاءات API، وdataflow يغطي حركة البيانات مثل خطوط ETL وتدفقات الأحداث، وlifecycle يغطي انتقالات الحالة مثل عمليات النشر أو تنفيذ الوكيل. بمجرد تحديد ما تريد رسمه، يُفعَّل المُصيّر والمخطط (schema) المناظران، وذلك المخطط يفرض شكل JSON المُدخَل.

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

التدفّق العام كالتالي.

flowchart TB
    A["طلب بلغة طبيعية<br/>(اقرأ هذا المستودع وارسم البنية)"] --> B["وكيل<br/>Claude Code / Codex"]
    B --> C["كتابة JSON-IR<br/>components · connections · boundaries"]
    C --> D["مُصيّر حسب النوع<br/>architecture / workflow / sequence / dataflow / lifecycle"]
    D --> E{"التحقق من التخطيط<br/>تقاطع خط-عقدة · تداخل التسميات"}
    E -.فشل التحقق + اقتراح إصلاح.-> C
    E -->|نجاح| F["HTML ذاتي الاكتفاء<br/>سمة داكنة/فاتحة · تصدير PNG/SVG"]

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

التثبيت أمر npx واحد. التثبيت الشامل (العالمي) كالتالي.

# تثبيت شامل ثم اختيار وكيل
npx skills add tt-a1i/archify -g

# تجربة لمرة واحدة دون تثبيت دائم
npx skills use tt-a1i/archify@archify --agent codex

يمكنك أيضًا استنساخ المستودع مباشرة والتحقق منه عبر CLI لاستخراج الأمثلة. هذه هي الأوامر الفعلية التي شغّلناها ومخرجاتها. كانت بيئة تجربتنا Node.js v24.1.0، ويتطلب Archify Node 18 فأعلى، ولا توجد له فعليًا تبعيات تشغيل (تبعية تطوير واحدة فقط هي ajv، تُستخدم للتحقق من المخطط).

git clone --depth 1 https://github.com/tt-a1i/archify.git
cd archify/archify

# فحص حالة التثبيت
node bin/archify.mjs doctor

هذا هو المخرج الفعلي لأمر doctor. تأكّدت جميع المُصيّرات الخمسة والمدقّقات (schema validators) على أنها سليمة.

Archify doctor

[ok] Node.js v24.1.0 (requires >=18)
[ok] Core template
[ok] Standalone schema validators
[ok] architecture renderer, schema, and example
[ok] workflow renderer, schema, and example
[ok] sequence renderer, schema, and example
[ok] dataflow renderer, schema, and example
[ok] lifecycle renderer, schema, and example

Archify is ready.

سحب أحد الأمثلة المدمجة ينتج ملف HTML ذاتي الاكتفاء واحدًا بحجم 508 كيلوبايت، يُفتح مباشرة في المتصفح دون أي خادم خارجي.

node bin/archify.mjs demo ./out
# Demo ready: ./out/archify-demo.html   (نحو 508 كيلوبايت، HTML واحد)

ما وجدناه حين شغّلناها فعليًا

قراءة الوثائق وحدها تجعل الأمر يبدو أن هذا كل شيء. لذلك، بدل استخدام مثال شخص آخر، كتبنا بنية ai-platform الفعلية لـ ThakiCloud كـ JSON-IR بأيدينا ورسمناها. أدرجنا تسعة مكونات: جدولة GPU عبر Kueue، تقديم النماذج عبر vLLM، مصادقة متعددة المستأجرين عبر Keycloak، الحالة والأحداث عبر PostgreSQL وNATS، ونشر GitOps عبر ArgoCD.

لم يكن JSON-IR صعب القراءة أو الكتابة على إنسان. المكوّن كائن له نوع وتسمية وموضع وحجم، والاتصال يحمل مصدرًا ووجهة وتسمية. على سبيل المثال، وصفنا البوابة وجزء تقديم GPU كالتالي.

{
  "components": [
    { "id": "gateway", "type": "backend", "label": "API Gateway",
      "sublabel": "Go Fiber :8080", "pos": [280, 300], "size": [140, 60] },
    { "id": "vllm", "type": "backend", "label": "vLLM Server",
      "sublabel": "OpenAI API", "pos": [540, 300], "size": [140, 60] }
  ],
  "connections": [
    { "id": "gw-to-vllm", "from": "gateway", "to": "vllm", "label": "route inference" },
    { "id": "vllm-gpu", "from": "vllm", "to": "gpupool", "label": "CUDA", "variant": "emphasis" }
  ]
}

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

Error: Architecture layout validation failed:
- [clean-flow/edge-through-node] connection "kueue-gpu" (kueue -> gpupool)
  crosses component "vllm" (unrelated to this relationship)
- [clean-flow/edge-through-node] connection "kueue-gpu" (kueue -> gpupool)
  crosses component "argocd" (unrelated to this relationship)
- Label "publish" overlaps component "gateway"
  Suggested fix: labelDy +24 (below); or labelAt [350, 374]

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

اتّبعنا الاقتراح، وأضفنا نقطة توجيه (via) للاتصال وعدّلنا موضع التسمية، ثم أعدنا الرسم. نجح هذه المرة. هذه هي القياسات الفعلية.

خلاصة القول، الرسم نفسه يستغرق 73 ميلي ثانية، أي فوري فعليًا. المخرج ملف HTML ذاتي الاكتفاء لا يعتمد على خادم صور أو CDN، ومرجعه الخارجي الوحيد خط ويب واحد للكود، لذا يُفتح دون كسر حتى دون اتصال، متراجعًا إلى خط النظام. السمتان الداكنة والفاتحة ليستا زخرفة، بل مُنفَّذتان فعليًا عبر متغيرات CSS حقيقية وprefers-color-scheme.

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

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

تصميم هذه الأداة يتقاطع بدقة مع مبدأ تلتزم به ThakiCloud عبر منتجين.

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

عبر عدسة ai-platform (البنية التحتية والتوثيق). HTML ذاتي الاكتفاء مفيد بشكل خاص في البيئات المحلية (on-premise) والسيادية. لعميل لا يستطيع رفع بنيته الداخلية إلى SaaS خارجي للرسم، يصبح الرسم محليًا والحصول على ملف واحد قابل للنقل مخرجًا قابلًا للاستخدام مباشرة. وبما أن JSON-IR نص عادي، فهو خاضع لإدارة الإصدارات في Git وقابل للمقارنة (diff). تمامًا كما تدير ArgoCD ملفات manifest، يمكنك إدارة مخططات المعمارية كشيفرة أيضًا، وتتبّع كل تغيير ومراجعته. بدل إعادة رسم وثائق التأهيل أو مخططات النشر للعملاء يدويًا في كل مرة، يكفي تعديل JSON عند تغيّر البنية وإعادة الرسم.

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

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

بالطبع، Archify ليست أداة سحرية. لها بعض نقاط الضعف الواضحة.

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

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

ثالثًا، لم تُوزَّع كمكتبة. يُعلَّم package.json بـ private: true، أي أنك تستهلكها كمهارة/CLI من المستودع لا كحزمة npm. ربطها في خط أنابيب كمكتبة يتطلب تفكيرًا إضافيًا.

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

الخلاصة

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

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

المصادر

• مستودع Archify: github.com/tt-a1i/archify (MIT، الإصدار 2.11.0)
• التغريدة الأصلية: @alin_zone via @hjguyhan
• سجل التجربة: الأوامر والمخرجات والقياسات في هذا المقال جُمعت من تشغيل محلي في 2026-07-22 (Node v24.1.0).

لماذا تستحق هذه المقالة القراءة

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

نظرة عامة

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

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

في ThakiCloud، ونحن نبني سحابة أصيلة للوكلاء (agent-native cloud)، نصطدم باستمرار بسؤال “كيف يراقب الوكيل نتيجة فعله ويقرر خطوته التالية؟”. ولأن هذه الميزة تمثّل إجابة ملموسة جدًا على هذا السؤال، سنتناولها هنا من منظور تصميم الحلقة، لا كمجرد عرض لميزة جديدة.

ما هو تكامل محاكي iOS

الفكرة الأساسية بسيطة. عندما تفتح مشروع iOS في Claude Code لسطح المكتب وتطلب منه بناء التطبيق وتشغيله، تظهر لوحة المحاكي بجانب المحادثة ويجعل Claude من تلك الشاشة موضوع مراقبته. يُفتح محاكٍ مستقل لكل جلسة، بحيث يمكن تنفيذ عدة مهام في آنٍ واحد دون أن تتداخل شاشات كل منها مع الأخرى. وتعمل هذه اللوحة في الجلسات المحلية فقط، لأن المحاكي نفسه برنامج لا يعمل إلا على macOS.

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

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

flowchart TB
    A[فتح مشروع iOS في<br/>Claude Code لسطح المكتب] --> B[طلب بناء التطبيق وتشغيله]
    B --> C[Claude ينفّذ عملية البناء]
    C --> D{هل نجح البناء؟}
    D -->|فشل| E[مراقبة سجلّ الأخطاء]
    E --> B
    D -->|نجح| F[تشغيل التطبيق في<br/>لوحة المحاكي]
    F --> G[Claude يراقب الشاشة<br/>قيد التشغيل]
    G --> H[التفاعل مع الواجهة<br/>واختبارها]
    H --> I{هل يعمل كما هو مقصود؟}
    I -->|لا| J[تعديل الكود]
    J --> B
    I -->|نعم| K[إنهاء الحلقة]

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

كيفية تفعيلها واستخدامها

لا تتطلب هذه الميزة إعدادًا معقدًا. لكن شروطها المسبقة واضحة تمامًا. أولًا، يجب أن يكون النظام macOS، إذ لا يعمل محاكي iOS خارج منظومة Apple، وبالتالي لا يمكن استخدام هذه اللوحة على Windows أو Linux. ثانيًا، يجب توفّر Xcode مع تثبيت منصة iOS، لأن البنية التحتية التي يستخدمها Claude فعليًا لتنفيذ البناء وتشغيل المحاكي هي في النهاية أدوات بناء Xcode والمحاكي نفسه. أما من ناحية الاشتراك، فيمكن لمستخدمي خطط Pro وMax وTeam استخدام هذه الميزة.

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

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

ما تمنحه الحلقة المغلقة لوكيل البرمجة

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

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

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

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

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

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

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

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

لتجنّب المبالغة في تقدير هذه الميزة، لا بدّ من تحديد حدودها بوضوح أيضًا. أولًا، المنصّة مقيّدة بـ macOS. هذا قيد لا مفرّ منه بما أن محاكي iOS لا يعمل خارج منظومة Apple، وهذا يعني أن هذه الحلقة متاحة لمستخدمي Mac فقط. كما أن تثبيت Xcode شرط أساسي، ولا يمكن استخدامها إلا في خطط Pro وMax وTeam، واللوحة تقتصر على الجلسات المحلية. أما توقّع الحصول على التجربة نفسها في الجلسات البعيدة أو بيئات المشاركة الجماعية، فلا يزال أمرًا سابقًا لأوانه.

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

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

خلاصة

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

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

المصادر

• الوثائق الرسمية لـ Claude Code: Test iOS apps in the simulator
• منشور ClaudeDevs (X)
• 9to5Mac: Claude Code brings live iOS app testing into its Mac app
• MacRumors: Claude Code Can Now Build and Test iOS Apps in Apple’s Simulator