نظرة عامة

ما إن تُدخِل منصّة ذكاء اصطناعي إلى مؤسسة حتى تجد نفسك أمام سؤال واحد: «إذًا، كم ساعدت فعلًا؟». حتى الآن، كان الجواب في الغالب مقاييس النظام: كم عدد استدعاءات الـ API، وكم مهمة عولِجت، وكم ملّي ثانية استغرقت الاستجابة. الأرقام نظيفة، لكنها لا تبلغ ما تريد الإدارة معرفته حقًّا: «ما الذي أنتجته منظمتنا فعليًّا بقدر أكبر؟».

لهذا فإن تقرير Economic Index «Cadences» الذي نشرته Anthropic في 26 يونيو 2026 جدير بالاهتمام. فهو ليس تحديثًا روتينيًّا لإحصاءات الاستخدام، بل يُعلن صراحةً أن طريقة قياس الأثر الاقتصادي للذكاء الاصطناعي نفسها قد تغيّرت. انطلاقًا من إدراك أن سجلّات المحادثة وحدها لا تكفي لتفسير أثر الذكاء الاصطناعي في العمل، يوسّع التقرير أساس القياس عبر ثلاثة مسارات.

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

ما هذا التقرير؟

حلّلت Anthropic استخدام Claude عبر Economic Index منذ 2023. واتّكأت كل التقارير السابقة على بيانات عيّنة من سبعة أيام: اقتطاع أسبوع وفحص أنماط الاستخدام داخله. قبل عام، كان معظم استخدام Claude محادثةً بين مستخدم ومساعد، فكانت هذه الطريقة تلتقط صورة معقولة.

لكن مع النمو السريع لـ Claude Code وCowork، تحوّلت حصّة كبيرة من الجلسات إلى مهام وكيلة طويلة الأمد. ولم تعد سجلّات المحادثة تلتقط بالكامل كيف يستخدم الناس الذكاء الاصطناعي. تقول Anthropic إنها أعادت تصميم خط بياناتها في ثلاثة اتجاهات لمواكبة ذلك: رفع معدّل أخذ العيّنات لرؤية الأنماط حتى مستوى الساعة، وإدخال مصنِّف جديد يُعنوِن مخرَج كل محادثة، وتفصيل نتائج المحادثات/Cowork وواجهة 1P API شهريًّا لمزيد من الدقّة.

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

المحور الأول: الإيقاعات بالساعة

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

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

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

المحور الثاني: مصنِّف المخرجات (Artifact)

التحوّل الثاني هو تصنيف مخرجات المحادثات. صنّفت Anthropic ما يُنتجه كل من محادثات الدردشة وCowork من مخرَج (artifact) ضمن أكثر من 30 فئة: مستند، شرح، مقطع شيفرة، ورقة أكاديمية، وهكذا، أي المخرَج الأساسي الذي أنتجه Claude في تلك المحادثة.

حكم المصنِّف بأن 93% من محادثات Claude تُنتج مخرَجًا. وأكثر الأنواع شيوعًا هي الشروحات (17%)، والمستندات والتقارير (15%)، والإرشادات (11%). وتمثّل المخرجات الحوارية كالشروحات أو الإرشادات والمخرجات المكتوبة كالمستندات أو العروض نحو الثلث لكلٍّ منها، بينما تمثّل مخرجات الشيفرة والتقنية كالتطبيقات أو السكربتات نحو السدس.

وتتبع ذلك نتيجة ثانية، هي درجة الاستقلالية (autonomy). تقيس Anthropic مقدار ما يُفوَّض إلى Claude من حُكم على مقياس من 1 إلى 5. فالمهام ذات الإجابات المحدّدة سلفًا، كالترجمة أو الحساب، استقلاليتها منخفضة، أما المهام التي تتطلّب الاختيار من بدائل كثيرة، كبناء التطبيقات أو الألعاب أو العروض، فاستقلاليتها مرتفعة.

ويُقاس المخرَج نفسه باستقلالية أعلى حين يُصنع عبر Claude Code. ففي 26 من أصل 31 مخرَجًا معروضًا كانت الاستقلالية أعلى على Claude Code منها على الدردشة أو Cowork، بفارق متوسّط قدره 0.37 نقطة. وفي السكربتات ومقاطع الشيفرة يتّسع الفارق إلى 0.53 نقطة. ونحو ثلثي هذا الفارق يأتي من تنفيذ المهام نفسها بتفويض أكبر. وتمثّل التدوينات مثالًا جيّدًا: المحادثة الوسيطة على الدردشة/Cowork لإنتاج تدوينة تمرّ بـ 13 جولة من الأخذ والردّ، بينما على Claude Code يفوّض الناس قدرًا أكبر من الحُكم. بعبارة أخرى، يمنح المستخدمون الذكاء الاصطناعي استقلالية أكبر.

المحور الثالث: استبيان الإدراك

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

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

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

دلالات لمنصّة ThakiCloud للذكاء الاصطناعي/التعلّم الآلي كخدمة على K8s

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

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

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

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

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

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

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

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

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

المصادر

• Anthropic، “Anthropic Economic Index report: Cadences” (2026-06-26)
• Anthropic، “Anthropic Economic Index Survey” (2026-04)

نظرة عامة

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

في يونيو 2026، أثارت مقالة Prakash Bhandari بعنوان “Claude Code Project Structure: The Complete Map” اهتمام مجتمع المطورين. ترسم المقالة خريطة وحيدة لخمسة أنظمة فرعية تتحكم فيها مجلدات .claude: التعليمات (CLAUDE.md وrules)، وتدفقات العمل (skills وcommands)، والخبراء (agents)، والصلاحيات (settings.json)، والذاكرة (memory). إذ تُشغّل ThakiCloud مئات المهارات وعشرات الوكلاء على هذه البنية بالفعل، لم نكتفِ بقراءة المقالة بل قسنا مستودعنا عليها مباشرةً.

هذا المقال هو سجلّ تلك المقارنة الميدانية. نُحدد حدود دور كل مكوّن، ونقيس الأرقام الفعلية لمكوّنات مستودع ai-platform-strategy، ثم نناقش لماذا تتخطى هذه البنية مجرد التنظيم حين يتعلق الأمر بتشغيل منصة SaaS متعددة المستأجرين لـ AI/ML على Kubernetes.

ما هي بنية مشروع Claude Code؟

الفكرة الجوهرية بسيطة. يقرأ Claude Code التكوين من موضعين: مجلد .claude في دليل المشروع، ومجلد ~/.claude في الدليل الرئيسي. يُودَع ملفات المشروع في git لمشاركتها بين أعضاء الفريق، بينما تنطبق ملفات الدليل الرئيسي على جميع المشاريع كإعدادات شخصية. يستقر كل مكوّن في موضعه وفق هذين المسارين.

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

flowchart TB
    ROOT["프로젝트 루트"]
    ROOT --> BRAIN["CLAUDE.md<br/>프로젝트 브레인<br/>(매 세션 자동 로드)"]
    ROOT --> LOCAL["CLAUDE.local.md<br/>개인 오버라이드<br/>(gitignore)"]
    ROOT --> IGNORE[".claudeignore<br/>컨텍스트 경계"]
    ROOT --> MCP[".mcp.json<br/>외부 도구 연결"]
    ROOT --> DOTC[".claude/"]
    DOTC --> SET["settings.json<br/>권한·훅·환경변수"]
    DOTC --> RULES["rules/<br/>상시 규칙<br/>(매 턴 로드)"]
    DOTC --> SKILLS["skills/<br/>온디맨드 전문지식<br/>(요청 시 로드)"]
    DOTC --> AGENTS["agents/<br/>서브에이전트 정의"]
    DOTC --> MEM["agent-memory/<br/>에이전트가 학습한 지식"]
    DOTC --> WT["worktrees/<br/>병렬 격리"]

مخطط بنية مشروع Claude Code مُرتَّب وفق توقيت التحميل في السياق.

حدود دور كل مكوّن

القيمة الحقيقية للخريطة تتجلى في الإجابة عن: ما الذي يذهب إلى أين؟ فيما يلي ملخص مسؤولية كل مكوّن مقروناً بطريقة تطبيقنا الفعلي.

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

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

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

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

skills هي المعرفة المتخصصة عند الطلب. لا تُحمَّل إلا حين تُفعّلها طلبٌ ما. وصفات العمل المتخصصة وخطوط أنابيب المجالات والمهام المتكررة: هذا مكانها. السؤال الفاصل بين CLAUDE.md وskills: هل يُحتاج هذا دائماً أم أحياناً؟

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

agent-memory هي المعرفة التي اكتسبها الوكيل بنفسه. هنا يكمن الفرق الجوهري عن CLAUDE.md: الأخير يحتوي ما أخبرته أنت به، أما agent-memory فتحتوي ما تعلّمه الوكيل من التجربة. الوكلاء طويلو المدى يراكمون الأنماط المتكررة والأخطاء والاتفاقيات غير الموثّقة.

أين تضع المعرفة الجديدة؟

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

flowchart TB
    START["새 지식·규칙·워크플로 추가"]
    START --> Q1{"항상 적용 +<br/>전체 팀 공유?"}
    Q1 -->|예| CMD["CLAUDE.md (짧게)<br/>또는 .claude/rules/"]
    Q1 -->|아니오| Q2{"가끔만 필요한<br/>전문 워크플로?"}
    Q2 -->|예| SK[".claude/skills/"]
    Q2 -->|아니오| Q3{"독립 역할·<br/>도구 조합?"}
    Q3 -->|예| AG[".claude/agents/"]
    Q3 -->|아니오| Q4{"개인 환경<br/>특이사항?"}
    Q4 -->|예| LO["CLAUDE.local.md<br/>(gitignore)"]
    Q4 -->|아니오| Q5{"에이전트가<br/>경험으로 배운 것?"}
    Q5 -->|예| ME[".claude/agent-memory/"]
    Q5 -->|아니오| PL["plugins/<br/>(여러 프로젝트 배포)"]

شجرة القرار لتحديد موضع أي معرفة جديدة: هل تُحتاج دائماً؟ هل تُحتاج أحياناً؟ من صنعها؟

الأخطاء الشائعة واضحة أيضاً. حشو المعرفة التي “تُحتاج أحياناً” في CLAUDE.md يعني هدر توكن في كل جلسة. مستودع أحادي بلا .claudeignore يستنزف السياق. إيداع CLAUDE.local.md في git يكشف البيانات الشخصية والمسارات. تفعيل أكثر من 10 خوادم MCP دائماً يهدر نحو 10 آلاف توكن بلا استخدام.

قياس مستودع ThakiCloud على هذه الخريطة

بعد قراءة الخريطة، قسنا مستودعنا عليها فعلاً. هذه هي نتائج قياس مجلد .claude في مستودع ai-platform-strategy:

40 قاعدة و94 سطراً من CLAUDE.md هي تكلفة دائمة تدخل السياق مع كل دورة، بينما 1655 مهارة و54 وكيلاً أصول يدخلون السياق عند الطلب فحسب.

هذه الأرقام تُثبت جوهر الخريطة بنفسها. لو أُدرجت الـ 1655 مهارة كلها في CLAUDE.md أو في القواعد، لتجاوزت كل جلسة حدّ السياق فوراً. في الواقع، تُحمَّل هذه المهارات الـ 1655 عند الطلب فحسب، ويُضيّق موجّه مستقل المرشحين في كل دورة. في المقابل، تُضبط تكلفة الحضور الدائم إرادياً عند 40 قاعدة، وهو نتاج ضبط نظافة يستهدف أقل من 2KB لكل ملف قاعدة مع تخفيض أي ملف يتجاوز ذلك إلى مهارة.

اللافت أننا حين انتهينا من قراءة مصدر هذا المقال، استخلصناه مباشرةً في ملف قاعدة باسم claude-code-project-anatomy.md وأدرجناه في المستودع. أي أن “خريطة بنية المشروع” ذاتها اجتازت شجرة القرار لتستقر قاعدةً دائمة الحضور. الخريطة وضعت نفسها على الخريطة.

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

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

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

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

قيود وتحفظات

هذه الخريطة ليست حلاً مطلقاً. إليك تحفظات صريحة.

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

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

ثالثاً، هذه البنية مُخصصة لـ Claude Code. الانتقال إلى بيئة تنفيذ وكلاء أخرى يغيّر اتفاقيات الدليل وآليات التحميل. لذا من الأجدر صياغة المعرفة ذاتها بحيادية تجاه بيئة التنفيذ، مع إبقاء التوصيل بالبيئة رفيعاً قدر الإمكان.

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

المصادر

• Claude Code Project Structure Explained: The Complete 2026 Guide (Prakash Bhandari)
• Explore the .claude directory (التوثيق الرسمي لـ Claude Code)
• المستودع المقيس: مجلد .claude في مستودع ThakiCloud ai-platform-strategy (القياس بتاريخ 2026-06-27)

Overview

Once you bring an AI platform into an enterprise, you eventually face one question: “So how much did it actually help?” Until now, the answer has mostly been system metrics. How many API calls happened, how many tasks were processed, how many milliseconds the response took. The numbers are clean, but they never reach what executives really want to know: “What did our organization actually produce more of?”

That is why Anthropic’s Economic Index report “Cadences”, published on June 26, 2026, is interesting. It is not a routine usage-statistics update. It publicly declares that the way AI’s economic impact is measured has itself changed. Starting from the recognition that chat logs alone cannot explain how AI affects work, it broadens the basis of measurement along three tracks.

For a company like ThakiCloud, which actually operates a multi-tenant AI/ML platform on Kubernetes, this shift is not someone else’s story. The report shows, with data, the move in how we explain ROI to customers from “system metrics” toward “work outputs and worker perceptions.” This post organizes the three methodological shifts based on the report’s official material and considers what we can take from them as a platform.

What Is This Report?

Anthropic has analyzed Claude usage through the Economic Index since 2023. Every prior report leaned on seven-day sample data: slicing out one week and examining usage patterns within it. A year ago, most Claude usage was a conversation between a user and an assistant, so even this method captured a reasonable picture.

But as Claude Code and Cowork grew rapidly, a large share of sessions shifted to long-running agentic tasks. Chat transcripts no longer fully capture how people use AI. Anthropic says it reworked its data pipeline in three directions to keep pace: sampling at a higher rate to see patterns down to the hourly level, introducing a new classifier that labels the output of each conversation, and breaking out chat/Cowork and 1P API results at a monthly level for finer granularity.

One more track is added. Anthropic admits it has lacked visibility into impact outside user sessions, that is, how people perceive AI. So it presents initial results from the Economic Index Survey launched in April 2026. In short, the report is built on three axes: hourly cadences, artifact classification, and perception survey.

Axis 1: Hourly Cadences

The most striking change is the introduction of privacy-preserving telemetry. By continuously sampling a slice of conversations each day, it captures daily and hourly flows, unlike the prior seven-day snapshots. This data makes it possible, for the first time, to see how the rhythms of daily life are reflected in Claude usage.

The results are intuitive yet new. Claude usage tracks the weekday work pattern, while personal prompts rise on weekends. Going hour by hour, it gets sharper. People most often ask for sleep advice around 5 a.m., and ask for recipes around 6 p.m. News requests cluster in the morning. Patterns also react to specific dates: tax-related requests surged just before the US filing deadline of April 15.

Differences by the nature of work also appear. When people do turn to Claude for work on nights and weekends, those tasks skew toward higher-wage occupations, such as marketing managers or programmers, who are more likely to work outside traditional hours. By contrast, tasks in the bottom wage quartiles, like telemarketing or clerical work, fall to a smaller share on nights and weekends. Anthropic adds that the pattern holds even in a robustness check that removes computer and mathematical occupations. It is a signal that AI is functioning not as simple automation but as an assistive tool for high-skill work.

Axis 2: The Artifact Classifier

The second shift is classifying the outputs of conversations. Anthropic sorted what artifact each chat and Cowork conversation produces into more than 30 categories: a document, an explanation, a piece of code, an academic paper, and so on, meaning the primary output Claude produced in that conversation.

The classifier judged that 93% of Claude conversations produce an artifact. The most common types are explanations (17%), documents and reports (15%), and guidance (11%). Conversational outputs like explanations or guidance and written deliverables like documents or presentations each account for about a third, while code and technical outputs like apps or scripts account for about a sixth.

A second finding follows, the autonomy score. Anthropic measures how much judgment is delegated to Claude on a 1-to-5 scale. Tasks with largely fixed answers, like translation or calculation, have low autonomy, while tasks that require choosing among many options, like building apps, games, or presentations, have high autonomy.

The same artifact is measured as having higher autonomy when made with Claude Code. Across 26 of the 31 outputs shown, autonomy was higher on Claude Code than chat or Cowork, with an average gap of 0.37 points. For scripts and code snippets the gap widens to 0.53 points. About two thirds of this difference comes from the same tasks being executed with more delegation. Blog posts are a good example: the median chat/Cowork conversation producing one involves 13 rounds of back-and-forth, while on Claude Code people delegate more judgment. In other words, users are handing AI more autonomy.

Axis 3: The Perception Survey

The third axis is data drawn not from logs but by asking people directly. Anthropic launched the Economic Index Survey in April 2026, asking actual Claude users how much of their work AI can do. Survey responses are linked to usage data through privacy-preserving methods.

Respondents were asked what share of their work tasks AI can do entirely on its own today (reported exposure) and what share they expect it to handle in 12 months (anticipated exposure). Close to 6 in 10 respondents chose a higher band for next year, and over a third expect AI to be able to do most or nearly all of their work tasks next year.

The differences across groups are clear. Respondents in lower-income countries tended to feel AI could replace more of their work. Anthropic cites prior research showing such countries tend to use Claude in more automated ways. Differences by experience also appear: workers with at least 15 years of experience placed the share of tasks AI can do roughly 10 percentage points lower than those in their first year, with the interpretation that experienced workers have accumulated tacit, context-specific expertise that AI struggles to mimic. Respondents named judgment, contextual awareness, situational reasoning, and the relational dimensions of building trust and managing people as things AI cannot do. Worries about displacement were concentrated among early-career and low-wage workers.

Implications for ThakiCloud’s K8s AI/ML SaaS Platform

What this report offers ThakiCloud lies not in a feature but in a measurement framework. Anthropic’s approach starts from the premise that “logs alone cannot explain AI’s value,” and that is a perspective we can apply directly as an enterprise AI platform operator.

Until now, we too have centered ROI explanations on system metrics: call counts, throughput, response speed. But this report poses questions at a different layer. What was produced in that conversation? Was the output made during work hours or during overnight overtime? How much autonomy did the user delegate to AI? How much do users themselves feel AI replaces their work?

These questions are measurable on our stack. ThakiCloud handles Kubernetes- and Kueue-based GPU scheduling, vLLM serving, and multi-tenant agent operation in one place. Layering an artifact classifier on the telemetry from this stack lets us capture when, and in what form, a customer’s employees produce outputs together with AI. Then we can explain AI’s effect not as the abstract “improved efficiency” but in concrete output units. The finding that high-wage tasks rise on overnight shifts can become a gauge for whether AI is settling in as an assistive tool for high-skill work in our customers’ organizations too.

The way the survey and logs are linked is also worth borrowing. Measuring the gap between actual usage data and perceived capability reveals which groups benefit most after AI adoption and which feel anxious. That is an insight that feeds directly into a customer’s internal change management strategy. For domestic customers who must measure on-premise without sending data outside, privacy-preserving measurement design is a requirement, not an option, and our multi-tenant isolation and self-hosting structure fit that requirement precisely.

Ultimately, Anthropic’s direction is a commitment to keep refining how AI’s economic impact is measured. One of ThakiCloud’s strong differentiators is the role of a partner that goes beyond providing a platform to co-designing this measurement framework and interpreting the data. The ability to measure AI ROI not at the log level but at the level of work outputs and worker perception will be a core competitive edge in the enterprise AI platform market.

Limitations and Counterarguments

For balance, the report’s limits deserve mention. First, since the data comes from Claude users, there is sample bias. These are the usage patterns and perceptions of a group already using AI actively, so generalizing to the whole workforce is hard. Anthropic itself repeatedly notes it cannot conclusively identify occupations, and the by-occupation estimates over time are inferred backward from task characteristics, so causation cannot be asserted.

The survey data should be read even more carefully. The expectation that “AI will handle most of my work next year” is a perception, not a verified capability. The report itself confirms that perceived capability runs higher than observed occupational exposure. The gap between expectation and reality is itself the object of measurement, not grounds for treating expectation as the future.

Finally, refining a measurement method does not by itself enlarge the impact. Seeing more precisely and something happening more are different claims. The value of this report is not the conclusion that “AI has replaced this much work,” but that it rebuilds the question “how do we measure that impact more honestly” with a layered, mixed-method approach. What ThakiCloud should take is not the conclusion but the measurement attitude.

Sources

• Anthropic, “Anthropic Economic Index report: Cadences” (2026-06-26)
• Anthropic, “Anthropic Economic Index Survey” (2026-04)

Overview

Anyone who has worked with Claude Code for a while knows the feeling: the .claude folder quietly turns into a junk drawer. Content that belongs in rules ends up in CLAUDE.md. Specialized knowledge that is only needed occasionally gets hard-coded into always-loaded rules. Personal environment paths bleed into team-shared files. Once the boundaries blur around what each component is supposed to hold, you end up paying token costs every session for context that has nothing to do with the current task.

In June 2026, a post titled “Claude Code Project Structure: The Complete Map” by Prakash Bhandari started circulating among developers. It maps five subsystems that the .claude folder controls – instructions (CLAUDE.md and rules), workflows (skills and commands), specialists (agents), permissions (settings.json), and memory – into a single coherent diagram. Since ThakiCloud already runs hundreds of skills and dozens of agents on top of this structure, we did not stop at reading the article. We held our actual repo up against the map to see how well they matched.

This post is a record of that comparison. We cover the role boundary of each component, the measured component counts from our ai-platform-strategy repo, and why this structure matters beyond mere tidiness when you are operating a Kubernetes-based AI/ML SaaS platform.

What Claude Code Project Structure Actually Is

The core idea is straightforward. Claude Code reads configuration from two locations: the project directory’s .claude folder, and the home directory’s ~/.claude. Project files are committed to git and shared across the team; home directory files apply globally to every project as personal configuration. Every component finds its place relative to these two roots.

The real value of the map is the answer to one question: when does each component get loaded into context? Some things arrive automatically at the start of every session. Others only arrive when a specific request triggers them. That timing difference is a token cost difference, which means deciding where to put something is not a matter of preference – it is an operational cost decision.

flowchart TB
    ROOT["프로젝트 루트"]
    ROOT --> BRAIN["CLAUDE.md<br/>프로젝트 브레인<br/>(매 세션 자동 로드)"]
    ROOT --> LOCAL["CLAUDE.local.md<br/>개인 오버라이드<br/>(gitignore)"]
    ROOT --> IGNORE[".claudeignore<br/>컨텍스트 경계"]
    ROOT --> MCP[".mcp.json<br/>외부 도구 연결"]
    ROOT --> DOTC[".claude/"]
    DOTC --> SET["settings.json<br/>권한·훅·환경변수"]
    DOTC --> RULES["rules/<br/>상시 규칙<br/>(매 턴 로드)"]
    DOTC --> SKILLS["skills/<br/>온디맨드 전문지식<br/>(요청 시 로드)"]
    DOTC --> AGENTS["agents/<br/>서브에이전트 정의"]
    DOTC --> MEM["agent-memory/<br/>에이전트가 학습한 지식"]
    DOTC --> WT["worktrees/<br/>병렬 격리"]

Claude Code project components organized by load timing. Click to enlarge.

Role Boundaries for Each Component

Where the map earns its keep is in defining what belongs where. Here is how each component’s responsibility maps to how we actually run things.

CLAUDE.md is the project brain. It loads automatically every session and serves as the standing brief shared across the entire team. Think of it as the onboarding document you hand a new contractor on day one. What are we building, what stack does it run on, what conventions do we follow, what are the workflow rules. The principle is to answer exactly those four questions and nothing else. Every line pays rent. A bloated CLAUDE.md is wasted context.

CLAUDE.local.md is personal override. Same format, but it never goes into git. Local environment paths, debugging shortcuts, personal preferences, anything specific to your machine lives here. Team members can have completely different versions, and that is the point – it keeps the shared CLAUDE.md clean.

.claudeignore is the context boundary. It uses the same syntax as .gitignore and limits what Claude can read. Without it, node_modules, generated migrations, vendor dependencies, and large fixtures consume your context budget. On a large monorepo it is practically mandatory.

rules are always-on constraints. They load automatically on every turn, so only genuinely invariant rules belong here – the things that apply to every task in every session. If you put a 200-line architecture document into a rules file, that content consumes context even in sessions where it is completely irrelevant. Documents should stay dormant until a skill explicitly reads them.

skills are on-demand expertise. They load only when a request triggers them. Specialized workflows that are not always needed, domain-specific pipelines, repeatable task recipes – these belong in skills. The dividing line between CLAUDE.md and skills is the phrase “only sometimes needed.”

agents are subagent definitions. Each agent is a specialist with its own role, tool set, and model tier, summoned when needed. The routing logic assigns cheaper models to exploration, balanced models to implementation, and the most capable models to architecture decisions.

agent-memory is what agents have learned. This is where agent-memory and CLAUDE.md fundamentally differ. CLAUDE.md holds what a person explicitly told the system. Agent-memory holds what an agent accumulated through experience – repeated patterns, bugs, undocumented conventions that a long-running agent has encountered.

Deciding Where New Knowledge Goes

You can have the map memorized and still hesitate when it is time to add a new rule or workflow. The placement decision tree from the article simplifies that judgment.

flowchart TB
    START["새 지식·규칙·워크플로 추가"]
    START --> Q1{"항상 적용 +<br/>전체 팀 공유?"}
    Q1 -->|예| CMD["CLAUDE.md (짧게)<br/>또는 .claude/rules/"]
    Q1 -->|아니오| Q2{"가끔만 필요한<br/>전문 워크플로?"}
    Q2 -->|예| SK[".claude/skills/"]
    Q2 -->|아니오| Q3{"독립 역할·<br/>도구 조합?"}
    Q3 -->|예| AG[".claude/agents/"]
    Q3 -->|아니오| Q4{"개인 환경<br/>특이사항?"}
    Q4 -->|예| LO["CLAUDE.local.md<br/>(gitignore)"]
    Q4 -->|아니오| Q5{"에이전트가<br/>경험으로 배운 것?"}
    Q5 -->|예| ME[".claude/agent-memory/"]
    Q5 -->|아니오| PL["plugins/<br/>(여러 프로젝트 배포)"]

Placement decision tree for new knowledge. The questions run in order: is this always needed, is it occasional expertise, does it define an independent role, is it personal, or is it something an agent learned?

The most common mistakes are equally clear. Dumping “only sometimes needed” knowledge into CLAUDE.md wastes tokens every session. A monorepo without .claudeignore bleeds context. Committing CLAUDE.local.md to git exposes personal information and local paths. Keeping more than ten MCP servers active at once burns roughly 10,000 tokens per session whether you use those servers or not.

Measuring the ThakiCloud Repo Against the Map

With the map in hand, we measured the .claude directory of our ai-platform-strategy repo directly.

The 40 rules and 94-line CLAUDE.md are fixed overhead that arrives every turn. The 1,655 skills and 54 agents are on-demand assets that only appear when needed.

These numbers prove the map’s central point. If all 1,655 skills had been packed into CLAUDE.md or rules files, the context limit would blow on the very first session. In practice, those 1,655 skills load on-demand only, and a separate router narrows the candidate set on every turn before any skill is loaded. The always-on side of the ledger – rules – is intentionally kept at 40 files. That number is the result of a hygiene rule: keep each rules file under 2 KB, and demote anything larger to a skill.

One detail worth noting: after reading the source article, we immediately distilled it into a rules file named claude-code-project-anatomy.md and committed it to the repo. In other words, “the project structure map” itself passed through the placement decision tree once and ended up as an always-on rule that is referenced every turn. The map placed itself on the map.

Implications for the ThakiCloud K8s AI/ML SaaS Platform

This structure matters beyond tidiness because context cost is operational cost. ThakiCloud runs multi-tenant agents on Kubernetes, schedules GPU resources through Kueue, and serves models through vLLM. Every agent session consumes tokens, and those tokens translate directly to inference cost. Reducing always-loaded context affects unit economics, not just accuracy.

The map’s emphasis on placement by load timing aligns precisely with two principles we had already formalized separately. The first is that capability belongs in skills, not in the harness – keeping the harness thin so the same skill works across multiple execution environments. The second is token hygiene: minimize what loads every turn, defer what is occasionally needed to on-demand. The placement decision tree converts those two principles into a practical judgment call at the moment of adding any new component.

There are also product-level implications. In a multi-tenant environment where different tenants require different rules and skills, having a clear boundary between what lives in always-on context and what stays on-demand makes tenant-to-tenant context isolation and cost attribution much cleaner. Keeping the channel where agents accumulate learned knowledge – agent-memory – separate from the channel where humans explicitly specify things – CLAUDE.md – also lines up with our approach to running self-learning agents safely.

Caveats and Counterarguments

This map is not a complete solution. A few honest limitations.

First, component boundaries are recommendations, not enforcement. Claude Code itself will not stop you from putting skill-level content into a rules file. Maintaining the boundaries requires team discipline, and in our case it requires token hygiene rules and router gates in code. Reading the map and expecting things to stay organized by themselves does not work.

Second, 1,655 skills is not a number to brag about – it cuts both ways. More candidates mean more noise risk: the router has more opportunities to surface the wrong skill. On-demand loading avoids always-on token cost, but retrieval accuracy becomes a different kind of cost. “On-demand means free” is too simple a conclusion.

Third, this structure is specific to Claude Code. Moving to a different agent execution environment changes the directory conventions and the load mechanism. That is why knowledge should be written as environment-agnostic as possible, with only the environment-specific wiring kept thin.

Finally, some figures in the source article – such as roughly 1,000 tokens per MCP server – are approximations that vary with environment and version. Rather than treating them as absolutes, the right takeaway is the direction: anything that loads every turn has a cost, and that cost compounds.

Sources

• Claude Code Project Structure Explained: The Complete 2026 Guide (Prakash Bhandari)
• Explore the .claude directory (Claude Code official documentation)
• Measured against: ThakiCloud ai-platform-strategy repo .claude directory (measured 2026-06-27)

개요

엔터프라이즈에 AI 플랫폼을 들여놓고 나면, 결국 한 가지 질문 앞에 서게 됩니다. “그래서 이게 얼마나 도움이 됐는가.” 지금까지 이 질문에 대한 답은 대체로 시스템 지표였습니다. API 호출이 몇 번 일어났고, 태스크를 몇 건 처리했고, 응답이 몇 밀리초 만에 돌아왔는지. 숫자는 깔끔하지만, 정작 경영진이 알고 싶은 “우리 조직이 실제로 무엇을 더 만들어냈는가”에는 닿지 못합니다.

Anthropic이 2026년 6월 26일 공개한 Economic Index 보고서 ‘Cadences’가 흥미로운 이유가 여기 있습니다. 이 보고서는 단순한 사용 통계 업데이트가 아니라, AI의 경제적 영향을 측정하는 방식 자체를 바꿨다고 공개적으로 선언합니다. 채팅 로그만으로는 AI가 일에 미치는 영향을 설명할 수 없다는 인식에서 출발해, 측정의 기반을 세 갈래로 넓혔습니다.

ThakiCloud처럼 쿠버네티스 위에서 멀티테넌트 AI/ML 플랫폼을 실제로 운영하는 입장에서 이 전환은 남의 이야기가 아닙니다. 고객사에 ROI를 설명하는 언어가 “시스템 지표”에서 “업무 산출물과 구성원 인식”으로 옮겨가는 흐름을, 이 보고서가 데이터로 보여주기 때문입니다. 이 글은 보고서의 공식 자료를 근거로 세 가지 방법론 전환을 정리하고, 우리 플랫폼 관점에서 무엇을 가져갈 수 있는지를 짚습니다.

이 보고서는 무엇인가

Anthropic은 2023년부터 Economic Index를 통해 Claude 사용 양상을 분석해 왔습니다. 그동안의 보고서는 모두 7일치 샘플 데이터에 기댔습니다. 일주일을 잘라내 그 안에서 사용 패턴을 들여다보는 방식입니다. 1년 전만 해도 Claude 사용의 대부분이 사용자와 어시스턴트 사이의 대화였기 때문에, 이 방식으로도 그림이 어느 정도 잡혔습니다.

그런데 Claude Code와 Cowork가 빠르게 성장하면서, 세션의 상당수가 길게 이어지는 에이전트 작업으로 바뀌었습니다. 채팅 기록만으로는 사람들이 AI를 어떻게 쓰는지 더 이상 온전히 담기지 않게 된 것입니다. Anthropic은 이 변화를 따라잡기 위해 데이터 파이프라인을 세 가지 방향으로 손봤다고 밝힙니다. 샘플링 비율을 높여 시간 단위까지 패턴을 보고, 대화의 산출물을 분류하는 분류기를 새로 도입하고, 채팅/Cowork와 1P API 결과를 월 단위로 나눠 더 세분화해 공개합니다.

여기에 한 축이 더 붙습니다. 그동안 Anthropic은 사용자 세션 바깥의 영향, 즉 사람들이 AI를 어떻게 체감하는지에 대한 가시성이 부족했다고 인정합니다. 그래서 2026년 4월에 시작한 경제지수 설문(Economic Index Survey)의 초기 결과를 함께 내놓습니다. 정리하면 이 보고서는 세 개의 축, 즉 시간 단위 케이던스, 산출물 분류, 인식 설문으로 짜여 있습니다.

첫 번째 축: 시간 단위 케이던스

가장 눈에 띄는 변화는 프라이버시 보존형 텔레메트리의 도입입니다. 매일 일정 비율의 대화를 연속적으로 샘플링하는 방식으로, 기존의 7일 스냅샷과 달리 일·시간 단위의 흐름을 잡아냅니다. 이 데이터로 처음으로 일상의 리듬이 Claude 사용에 어떻게 반영되는지를 볼 수 있게 됐습니다.

결과는 직관에 부합하면서도 새롭습니다. Claude 사용은 주중 근무 패턴을 그대로 따라가고, 개인적인 질문은 주말에 늘어납니다. 시간대별로 들어가면 더 선명합니다. 사람들은 새벽 5시 무렵에 수면 관련 조언을 가장 많이 구하고, 저녁 6시 무렵에는 레시피를 묻습니다. 아침에는 뉴스 요청이 몰립니다. 특정 날짜에 반응하는 패턴도 보입니다. 미국 세금 신고 마감일인 4월 15일 직전에는 세금 관련 요청이 급증했습니다.

업무 성격에 따른 차이도 드러납니다. 야간과 주말처럼 정규 시간이 아닐 때 사람들이 일 때문에 Claude를 찾으면, 그 태스크는 고임금 직군 쪽으로 쏠립니다. 마케팅 매니저나 프로그래머처럼 전통적 근무 시간 밖에서 일하는 비중이 높은 직군이 여기 해당합니다. 반대로 텔레마케팅이나 사무 보조처럼 하위 임금 분위의 태스크는 야간·주말에 비중이 줄어듭니다. Anthropic은 컴퓨터·수학 직군을 분석에서 빼는 강건성 검증을 해도 이 경향이 유지된다고 덧붙입니다. 단순 자동화가 아니라 고숙련 업무의 보조 도구로 AI가 기능하고 있다는 신호로 읽을 수 있는 대목입니다.

두 번째 축: 산출물(Artifact) 분류기

두 번째 전환은 대화의 결과물을 분류하는 일입니다. Anthropic은 채팅과 Cowork 대화 각각이 어떤 산출물(artifact)을 만들어내는지를 30개가 넘는 범주로 분류했습니다. 문서, 설명, 코드 한 조각, 학술 논문처럼 그 대화에서 Claude가 만들어낸 주된 결과물을 뜻합니다.

분류기는 Claude 대화의 93%가 어떤 산출물을 생성한다고 판정했습니다. 가장 흔한 유형은 설명(17%), 문서 및 보고서(15%), 가이던스(11%) 순입니다. 설명이나 가이던스 같은 대화형 결과물과 문서나 프레젠테이션 같은 작성형 결과물이 각각 전체의 약 3분의 1을 차지하고, 앱이나 스크립트 같은 코드·기술 결과물이 약 6분의 1을 차지합니다.

여기서 흥미로운 두 번째 발견이 나옵니다. 자율성(autonomy) 점수입니다. Anthropic은 Claude에게 얼마나 많은 판단을 위임하는지를 1에서 5까지의 척도로 측정합니다. 번역이나 계산처럼 답이 거의 정해진 작업은 자율성이 낮고, 앱이나 게임, 프레젠테이션을 만드는 일처럼 여러 선택지 중에서 골라야 하는 작업은 자율성이 높습니다.

같은 산출물이라도 Claude Code에서 만들 때 자율성이 더 높게 측정됩니다. 보여준 31개 산출물 중 26개에서 Claude Code 쪽 자율성이 챗·Cowork보다 높았고, 전체 평균으로는 0.37점 차이가 났습니다. 스크립트나 코드 조각의 경우 그 격차가 0.53점까지 벌어집니다. 이 차이의 약 3분의 2는 같은 작업을 더 많이 위임해서 처리하기 때문이라고 설명합니다. 블로그 글이 좋은 예입니다. 챗·Cowork에서 블로그 글을 만드는 대화는 중앙값 기준 13번의 주고받기를 거치지만, Claude Code에서는 사용자가 더 많은 판단을 맡깁니다. 사용자가 AI에게 더 많은 자율성을 넘기고 있다는 뜻입니다.

세 번째 축: 인식 설문

세 번째 축은 로그가 아니라 사람에게 직접 묻는 데이터입니다. Anthropic은 2026년 4월 경제지수 설문을 시작해, 실제 Claude 이용자에게 AI가 자신의 업무를 어느 정도 수행할 수 있는지를 직접 물었습니다. 설문 응답은 프라이버시 보존 방법으로 사용 데이터와 연결됩니다.

응답자에게 오늘 기준으로 AI가 스스로 처리할 수 있는 업무 비중(reported exposure)과 12개월 뒤에 처리할 것으로 기대하는 비중(anticipated exposure)을 물었습니다. 10명 중 6명에 가까운 응답자가 내년에 더 높은 구간을 선택했고, 3분의 1 이상이 내년에는 AI가 자기 업무의 대부분 또는 거의 전부를 처리할 수 있을 것으로 기대한다고 답했습니다.

층위별 차이도 또렷합니다. 소득 수준이 낮은 국가의 응답자일수록 AI가 더 많은 업무를 대체할 수 있다고 느끼는 경향이 강했습니다. Anthropic은 이런 국가일수록 AI를 보강이 아니라 자동화에 쓰는 경향이 있다는 이전 연구를 함께 인용합니다. 경력에 따른 차이도 나타났습니다. 15년 이상 경력자는 AI가 할 수 있는 업무 비중을 첫해 근무자보다 약 10퍼센트포인트 낮게 봤습니다. 오래 일한 사람일수록 AI가 흉내내기 어려운 암묵적·맥락적 전문성을 쌓았기 때문이라는 해석입니다. 응답자들은 AI가 끝내 할 수 없는 일로 판단, 맥락 인식, 상황 추론, 그리고 신뢰 구축과 사람 관리 같은 관계적 차원을 꼽았습니다. 대체에 대한 우려는 경력 초년생과 저임금 직군에 집중됐습니다.

ThakiCloud K8s AI/ML SaaS 플랫폼 적용 및 시사점

이 보고서가 ThakiCloud에 주는 함의는 기능이 아니라 측정 프레임워크에 있습니다. Anthropic이 택한 접근은 “로그만으로는 AI 가치를 설명할 수 없다”는 전제에서 출발하는데, 이는 엔터프라이즈 AI 플랫폼을 운영하는 우리에게 그대로 적용 가능한 관점입니다.

지금까지 고객사에 ROI를 설명할 때 우리도 시스템 지표를 중심에 뒀습니다. 호출 횟수, 처리량, 응답 속도. 그런데 이 보고서는 다른 층위의 질문을 던집니다. 그 대화에서 무엇이 생성됐는가. 그 산출물은 업무 시간 안에 만들어졌는가, 야간 초과근무 중에 만들어졌는가. 사용자는 AI에게 얼마나 많은 자율성을 위임했는가. 사용자 스스로는 AI가 자기 업무를 얼마나 대체한다고 느끼는가.

이 질문들은 우리 스택 위에서 충분히 측정 가능합니다. ThakiCloud는 쿠버네티스와 Kueue 기반 GPU 스케줄링, vLLM 서빙, 멀티테넌트 에이전트 운용을 한곳에서 다룹니다. 여기서 나오는 텔레메트리에 산출물 분류기를 한 겹 얹으면, 고객사 직원들이 언제 어떤 유형의 결과물을 AI와 함께 만드는지를 잡아낼 수 있습니다. 그러면 AI 도입 효과를 “업무 효율 향상”이라는 추상적 표현이 아니라 구체적 산출물 단위로 설명하게 됩니다. 야근 시간대에 고임금 직군 태스크 비중이 높아진다는 발견은, 우리 고객사에서도 AI가 단순 자동화가 아니라 고숙련 업무의 보조 도구로 자리잡고 있는지를 가늠하는 지표가 될 수 있습니다.

설문과 로그를 연계하는 방식도 참고할 만합니다. 실제 사용 데이터와 체감 인식 사이의 괴리를 측정하면, AI 도입 후 어떤 계층이 가장 효과를 보고 어떤 계층이 불안을 느끼는지를 파악할 수 있습니다. 이는 고객사의 내부 변화 관리(Change Management) 전략 수립에 곧바로 쓰이는 인사이트입니다. 특히 온프렘 환경에서 데이터를 외부로 내보내지 않고 측정해야 하는 국내 고객사라면, 프라이버시 보존형 측정 설계는 선택이 아니라 요구 사항입니다. 우리의 멀티테넌트 격리와 self-hosting 구조는 이 요구에 정확히 맞물립니다.

결국 Anthropic이 보여주는 방향은 AI가 경제에 미치는 영향을 측정하는 기준을 계속 고도화하겠다는 의지입니다. ThakiCloud가 고객사에 줄 수 있는 강력한 차별점 하나는, 단순한 플랫폼 제공을 넘어 이런 측정 프레임워크를 함께 설계하고 데이터를 해석해주는 파트너 역할입니다. AI 도입 ROI를 로그 수준이 아니라 업무 산출물과 구성원 인식 수준에서 측정하는 능력이, 앞으로 엔터프라이즈 AI 플랫폼 시장의 핵심 경쟁력이 될 것이라고 봅니다.

한계 및 반론

균형을 위해 이 보고서의 한계도 짚어야 합니다. 먼저 데이터의 출처가 Claude 사용자라는 점에서 표본 편향이 있습니다. AI를 이미 적극적으로 쓰는 집단의 사용 패턴과 인식이므로, 전체 노동 인구로 일반화하기는 어렵습니다. Anthropic 자신도 직업을 확정적으로 식별할 수 없다고 여러 차례 밝힙니다. 시간대별 직군 추정 역시 태스크 성격에서 역으로 추론한 것이라 인과를 단정하기 어렵습니다.

설문 데이터는 더 조심스럽게 읽어야 합니다. “내년에 AI가 내 업무 대부분을 처리할 것”이라는 기대는 체감이지 검증된 역량이 아닙니다. 보고서 안에서도 실제 직업별 노출 지표보다 체감 역량이 더 높게 나타난다는 점이 확인됩니다. 기대와 현실 사이의 이 간극 자체가 측정 대상이지, 기대치를 곧 미래로 받아들일 근거는 아닙니다.

마지막으로, 측정 방법론의 고도화가 곧 영향의 크기를 키우는 것은 아닙니다. 더 정교하게 본다는 것과 더 크게 일어난다는 것은 다른 이야기입니다. 이 보고서의 가치는 “AI가 일을 얼마나 대체했다”는 결론이 아니라, “그 영향을 어떻게 더 정직하게 측정할 것인가”라는 질문을 다층 혼합 방법론으로 다시 세운 데 있습니다. ThakiCloud가 가져갈 것도 결론이 아니라 그 측정의 태도입니다.

출처

• Anthropic, “Anthropic Economic Index report: Cadences” (2026-06-26)
• Anthropic, “Anthropic Economic Index Survey” (2026-04)

개요

Claude Code로 일을 하다 보면 .claude 폴더가 어느 순간 잡동사니가 됩니다. 규칙을 넣어야 할 내용이 CLAUDE.md로 가고, 가끔만 필요한 전문 지식이 항상 로드되는 규칙으로 박히며, 개인 환경 경로가 팀 공유 파일에 섞입니다. 각 구성요소가 “무엇을 담아야 하는가”의 경계가 흐려지면, 매 세션마다 쓰지도 않는 컨텍스트를 토큰으로 지불하게 됩니다.

2026년 6월, Prakash Bhandari가 정리한 “Claude Code Project Structure: The Complete Map”라는 글이 개발자 커뮤니티에서 화제가 됐습니다. .claude 폴더가 통제하는 다섯 개의 하위 시스템, 즉 지시(CLAUDE.md와 rules), 워크플로(skills와 commands), 전문가(agents), 권한(settings.json), 기억(memory)을 한 장의 지도로 그린 글입니다. ThakiCloud는 이미 이 구조 위에서 수백 개의 스킬과 수십 개의 에이전트를 운용하고 있어서, 글을 읽는 데 그치지 않고 우리 레포를 그 지도에 직접 비춰봤습니다.

이 글은 그 비교 실측의 기록입니다. 각 구성요소의 역할 경계를 정리하고, 우리 레포(ai-platform-strategy)의 실제 구성요소 수를 측정해 지도와 대조한 뒤, 쿠버네티스 기반 AI/ML SaaS 플랫폼을 운영하는 관점에서 이 구조가 왜 단순한 정리정돈 이상의 의미를 갖는지 정리했습니다.

Claude Code 프로젝트 구조란 무엇인가

핵심 발상은 단순합니다. Claude Code는 두 곳에서 설정을 읽습니다. 프로젝트 디렉터리의 .claude와 홈 디렉터리의 ~/.claude입니다. 프로젝트 파일은 git에 커밋해 팀과 공유하고, 홈 디렉터리 파일은 모든 프로젝트에 적용되는 개인 설정입니다. 이 두 갈래를 기준으로 모든 구성요소가 자리를 잡습니다.

지도의 본질은 “각 구성요소가 언제 컨텍스트에 로드되는가”입니다. 어떤 것은 매 세션 자동으로 들어오고, 어떤 것은 요청이 트리거할 때만 들어옵니다. 이 로드 타이밍의 차이가 곧 토큰 비용의 차이이고, 그래서 무엇을 어디에 두느냐가 단순한 취향이 아니라 운영 비용 문제가 됩니다.

flowchart TB
    ROOT["프로젝트 루트"]
    ROOT --> BRAIN["CLAUDE.md<br/>프로젝트 브레인<br/>(매 세션 자동 로드)"]
    ROOT --> LOCAL["CLAUDE.local.md<br/>개인 오버라이드<br/>(gitignore)"]
    ROOT --> IGNORE[".claudeignore<br/>컨텍스트 경계"]
    ROOT --> MCP[".mcp.json<br/>외부 도구 연결"]
    ROOT --> DOTC[".claude/"]
    DOTC --> SET["settings.json<br/>권한·훅·환경변수"]
    DOTC --> RULES["rules/<br/>상시 규칙<br/>(매 턴 로드)"]
    DOTC --> SKILLS["skills/<br/>온디맨드 전문지식<br/>(요청 시 로드)"]
    DOTC --> AGENTS["agents/<br/>서브에이전트 정의"]
    DOTC --> MEM["agent-memory/<br/>에이전트가 학습한 지식"]
    DOTC --> WT["worktrees/<br/>병렬 격리"]

Claude Code 프로젝트의 구성요소를 로드 타이밍 기준으로 정리한 구조도. 클릭하면 확대됩니다.

구성요소별 역할 경계

지도가 진짜 가치를 갖는 지점은 “무엇을 어디에 담는가”의 경계입니다. 글이 정리한 각 구성요소의 책임을 우리가 실제로 운용하는 방식과 함께 정리하면 다음과 같습니다.

CLAUDE.md는 프로젝트 브레인입니다. 매 세션 자동으로 로드되며 팀 전체가 공유하는 표준 브리프입니다. 신규 계약자에게 첫날 건네는 안내서라고 생각하면 정확합니다. 무엇을 만들고 있는가, 어떤 스택 위에서 도는가, 어떤 컨벤션을 따르는가, 워크플로 규칙은 무엇인가. 이 네 가지 질문에만 답하는 것이 원칙입니다. 모든 줄이 임대료를 낸다는 점이 중요합니다. 뚱뚱한 CLAUDE.md는 곧 컨텍스트 낭비입니다.

CLAUDE.local.md는 개인 오버라이드입니다. 같은 포맷이지만 git에 절대 들어가지 않습니다. 로컬 환경 경로, 디버깅 단축키, 개인 선호, 내 머신의 특이사항이 여기 들어갑니다. 팀원끼리 달라도 되고, 공유 CLAUDE.md를 깔끔하게 유지하는 안전판 역할을 합니다.

.claudeignore는 컨텍스트 경계입니다. .gitignore와 같은 문법으로 Claude의 읽기 범위를 제한합니다. 이것이 없으면 node_modules, 생성된 마이그레이션, 벤더 의존성, 대용량 픽스처가 컨텍스트를 소진합니다. 대형 모노레포에서는 사실상 필수입니다.

rules는 상시 규칙입니다. 매 턴 자동으로 로드되므로 모든 작업에 적용되는 불변 규칙만 들어가야 합니다. 200줄짜리 아키텍처 문서를 규칙 파일에 넣으면, 그 내용이 무관한 세션에서도 매번 컨텍스트를 먹습니다. 그래서 문서는 스킬이 명시적으로 읽을 때까지 잠들어 있어야 합니다.

skills는 온디맨드 전문지식입니다. 요청이 트리거할 때만 로드됩니다. 항상 필요하지는 않은 전문 워크플로, 도메인별 파이프라인, 반복 작업 레시피가 여기 들어갑니다. “때때로만 필요한 것”이라는 기준이 CLAUDE.md와 skills를 가르는 선입니다.

agents는 서브에이전트 정의입니다. 독립적인 역할, 도구 조합, 모델 티어를 가진 전문가로, 필요할 때 소환됩니다. 탐색에는 저렴한 모델을, 구현에는 균형 잡힌 모델을, 아키텍처 결정에는 가장 비싼 모델을 배정하는 식으로 작업 성격에 따라 모델을 라우팅합니다.

agent-memory는 에이전트가 학습한 지식입니다. CLAUDE.md와의 핵심 차이가 여기 있습니다. CLAUDE.md는 사람이 알려준 것이고, agent-memory는 에이전트가 경험으로 배운 것입니다. 장기 실행 에이전트가 반복 패턴, 버그, 문서화되지 않은 컨벤션을 누적합니다.

새 지식은 어디에 두는가

지도를 외워도 막상 새 규칙이나 워크플로를 추가할 때 어디에 둘지 헷갈립니다. 글이 제시한 배치 결정 트리는 이 판단을 단순화합니다.

flowchart TB
    START["새 지식·규칙·워크플로 추가"]
    START --> Q1{"항상 적용 +<br/>전체 팀 공유?"}
    Q1 -->|예| CMD["CLAUDE.md (짧게)<br/>또는 .claude/rules/"]
    Q1 -->|아니오| Q2{"가끔만 필요한<br/>전문 워크플로?"}
    Q2 -->|예| SK[".claude/skills/"]
    Q2 -->|아니오| Q3{"독립 역할·<br/>도구 조합?"}
    Q3 -->|예| AG[".claude/agents/"]
    Q3 -->|아니오| Q4{"개인 환경<br/>특이사항?"}
    Q4 -->|예| LO["CLAUDE.local.md<br/>(gitignore)"]
    Q4 -->|아니오| Q5{"에이전트가<br/>경험으로 배운 것?"}
    Q5 -->|예| ME[".claude/agent-memory/"]
    Q5 -->|아니오| PL["plugins/<br/>(여러 프로젝트 배포)"]

새 지식을 어디에 배치할지 결정하는 트리. 항상 필요한지, 가끔 필요한지, 누가 만든 지식인지를 순서대로 묻습니다.

가장 흔한 실수도 명확합니다. “가끔만 필요한” 지식을 CLAUDE.md에 다 때려넣으면 매 세션 토큰을 낭비합니다. .claudeignore가 없는 모노레포는 컨텍스트가 소진됩니다. CLAUDE.local.md를 git에 커밋하면 개인 정보와 경로가 노출됩니다. MCP 서버를 10개 이상 상시 활성화하면 사용하지 않아도 매번 약 1만 토큰을 낭비합니다.

ThakiCloud 레포를 이 지도에 비춰보기

지도를 읽었으니 우리 레포를 거기에 비춰봤습니다. ai-platform-strategy 레포의 .claude 디렉터리를 실제로 측정한 결과는 다음과 같습니다.

규칙 40개와 CLAUDE.md 94줄은 매 턴 들어오는 상시 비용이고, 스킬 1655개와 에이전트 54개는 필요할 때만 들어오는 온디맨드 자산입니다.

이 숫자가 말해주는 것이 지도의 핵심을 그대로 증명합니다. 스킬 1655개를 전부 CLAUDE.md나 규칙에 넣었다면 매 세션이 즉시 컨텍스트 한계를 넘었을 것입니다. 실제로 이 1655개는 온디맨드로만 로드되고, 어떤 스킬을 띄울지는 별도의 라우터가 매 턴 후보를 좁혀 결정합니다. 반대로 상시 비용 영역인 규칙은 40개로 의도적으로 억제하고 있습니다. 규칙 파일당 2KB 이하를 목표로 하고, 그 이상이 되면 스킬로 강등하는 위생 규칙을 둔 결과입니다.

흥미로운 지점은 우리가 이 글의 출처를 읽고 곧바로 claude-code-project-anatomy.md라는 규칙 파일로 증류해 레포에 넣었다는 사실입니다. 즉 “프로젝트 구조 지도”라는 지식 자체가 배치 결정 트리를 한 번 통과해, 매 턴 참조되는 상시 규칙으로 자리 잡았습니다. 지도가 스스로를 지도 위에 배치한 셈입니다.

ThakiCloud K8s AI/ML SaaS 플랫폼 적용 시사점

이 구조가 단순한 정리정돈을 넘어서는 이유는 컨텍스트 비용이 곧 운영 비용이기 때문입니다. ThakiCloud는 쿠버네티스 위에서 멀티테넌트 에이전트를 운용하고, GPU 자원은 Kueue로 스케줄링하며, 모델은 vLLM으로 서빙합니다. 이 환경에서 에이전트 세션 하나하나가 토큰을 소비하고, 그 토큰은 곧 추론 비용입니다. 상시 로드되는 컨텍스트를 줄이는 것은 정확도뿐 아니라 단가에 직접 영향을 줍니다.

지도가 강조하는 “로드 타이밍에 따른 배치”는 우리가 이미 별도로 정리해 온 두 가지 원칙과 정확히 맞물립니다. 첫째는 능력을 harness가 아니라 스킬에 쌓는다는 원칙으로, 동일한 스킬이 여러 실행 환경을 가로질러 작동하도록 harness는 얇게 유지합니다. 둘째는 매 턴 들어오는 것은 최소로, 가끔 필요한 것은 온디맨드로 미룬다는 토큰 위생 원칙입니다. 글의 배치 결정 트리는 이 두 원칙을 신규 구성요소를 추가하는 순간의 실무 판단으로 바꿔줍니다.

플랫폼 제품 관점에서도 함의가 있습니다. 멀티테넌트 환경에서 테넌트별로 다른 규칙과 스킬을 주입해야 할 때, 무엇을 상시 컨텍스트로 둘지와 무엇을 온디맨드로 둘지의 경계가 명확하면 테넌트 간 컨텍스트 격리와 비용 배분이 깔끔해집니다. agent-memory처럼 에이전트가 학습한 지식을 사람이 검토하는 채널과, 사람이 처음부터 지정하는 CLAUDE.md 채널을 분리해 두는 것도, 자가 학습하는 에이전트를 안전하게 운용하려는 우리 방향과 동일합니다.

한계 및 반론

이 지도가 만능은 아닙니다. 몇 가지 한계를 정직하게 짚습니다.

첫째, 구성요소 경계는 권고이지 강제가 아닙니다. Claude Code 자체가 “이 내용은 규칙이 아니라 스킬로 가야 한다”고 막아주지 않습니다. 경계를 지키는 것은 결국 팀의 규율이고, 우리처럼 토큰 위생 규칙과 라우터 게이트를 코드로 둬야 실제로 강제됩니다. 지도만 외운다고 자동으로 깔끔해지지 않습니다.

둘째, 스킬 1655개라는 숫자는 자랑이 아니라 양날의 검입니다. 후보가 많을수록 라우터가 잘못된 스킬을 띄울 노이즈 위험이 커집니다. 온디맨드라서 상시 토큰은 안 먹지만, 검색 정확도라는 다른 비용이 발생합니다. “온디맨드면 공짜”라는 단순한 결론은 위험합니다.

셋째, 이 구조는 Claude Code에 특화돼 있습니다. 다른 에이전트 실행 환경으로 옮기면 디렉터리 규약과 로드 메커니즘이 달라집니다. 그래서 지식 자체는 가능한 한 실행 환경 중립적으로 기술하고, 환경별 배선은 얇게 유지하는 편이 장기적으로 안전합니다.

마지막으로, 출처 글의 일부 수치(예: MCP 서버당 약 1천 토큰)는 환경과 버전에 따라 달라질 수 있는 근사치입니다. 절대값으로 받기보다 “상시 로드되는 것은 모두 비용이다”라는 방향성으로 읽는 것이 맞습니다.

출처

• Claude Code Project Structure Explained: The Complete 2026 Guide (Prakash Bhandari)
• Explore the .claude directory (Claude Code 공식 문서)
• 실측 대상: ThakiCloud ai-platform-strategy 레포 .claude 디렉터리 (2026-06-27 측정)

نظرة عامة

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

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

ما هو Agent Skill؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المصادر

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

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

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

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

نظرة عامة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

النشر: vLLM وSGLang

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المصادر

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

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

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

نظرة عامة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المصادر

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

نظرة عامة

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

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

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

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

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

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

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

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

flowchart TB
    AE[تنفيذ الوكيل<br/>Agent Execution]
    EX[الاستخراج<br/>Extraction]
    RS["التمثيل والتخزين<br/>Representation & Storage"]
    RR["الاسترجاع والتوجيه<br/>Retrieval & Routing"]
    MA[الصيانة<br/>Maintenance]
    RF[دقة التمثيل<br/>Representation Fidelity]
    RP[دقة الاسترجاع<br/>Retrieval Precision]
    UC[دقة التحديث<br/>Update Correctness]
    LS[الاستقرار طويل الأمد<br/>Long-horizon Stability]

    AE -->|كتابة| EX
    EX --> RS
    RS -->|قراءة| RR
    RR --> AE
    RS -.دمج.-> MA
    MA --> RS
    RS --> RF
    RR --> RP
    MA --> UC
    MA --> LS

البنية المعمارية للوحدات الأربع لنظام الذاكرة الأصيل للوكيل وتدفقات بياناتها. انقر المخطط لتكبيره.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المصادر

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

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