يواجه كل نظام وكيل نفس المفاضلة الصعبة. أنت تريد قاعدة معرفية عميقة ومنظمة جيداً تصمد أمام

تواجه كل أنظمة الوكلاء (agent systems) نفس المفاضلة غير المريحة. فأنت تريد قاعدة معرفية عميقة ومنظمة جيداً تصمد أمام مراجعات الكود وسجل git. ولكنك تحتاج أيضاً إلى أن يعمل وقت التشغيل (runtime) بسرعة ويظل مركزاً. هاتان الحاجتان تعملان ضد بعضهما البعض؛ فكلما زادت التعليمات التي تحتفظ بها، زادت الرغبة في إلقاء جميعها في الـ prompt والأمل في الحصول على أفضل نتيجة. وهذا الأمل مكلف.

في منظومة Agent Project Context، ينقسم هذا التوتر بوضوح عبر طبقتين: يتولى APC مسؤولية الديمومة، بينما يتولى APX مسؤولية السرعة. إن فهم كيفية تفاعلهما — ولماذا يرفض APX تحميل كل تعريف للمهارات مسبقاً — يكشف عن حقائق حول هندسة الـ prompt أكثر مما قد تخبرك به معظم أدلة التحسين.

الأرشيف والمحرك

وظيفة APC هي الديمومة. فهو يقوم بتخزين ملفات المهارات القابلة لإعادة الاستخدام تحت المسار .apc/skills/ كوثائق Markdown بسيطة. ولأن هذه الملفات تعيش داخل مستودعك (repository)، فهي تتبع نظام التحكم في الإصدارات. يمكنك تقديم طلب سحب (pull request) يغير إجراءات النشر، ويمكنك إجراء مقارنة (diff) لعملية تراجع عن سياسة أمنية تمت قبل ستة أسابيع، ويمكنك تدقيق ما كان من المفترض أن يعرفه الوكيل ومتى. هذه القابلية للمراجعة تكتسب أهمية قصوى عندما يتم نشر إصدار سيئ أو عندما يبدأ مدقق الامتثال في طرح الأسئلة.

أما APX، من ناحية أخرى، فيعيش اللحظة. فهو يدير المحادثة الفعلية بينك وبين النموذج. وهدفه ليس أرشفة المعرفة بل استخدامها بدقة. عندما يعامل APX المهارات كأعباء دائمة، يتباطأ النظام بأكمله، وتمتلئ نافذة السياق (context window)، وترتفع تكاليف الـ tokens. والأسوأ من ذلك، يتشتت انتباه النموذج عبر تعليمات لا علاقة لها بالطلب الحالي.

هذا هو السبب في تحميل محتوى المهارات عند الطلب.

التكلفة الحقيقية للـ prompt المتضخم

تدرك معظم الفرق أن الـ tokens تكلف مالاً، لكن فرقاً أقل تدرك أن الـ tokens غير ذات الصلة تكلف الدقة.

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

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

كيف يعمل التحميل عند الطلب

الآلية بسيطة ولكنها مدروسة. يستمر APC في الاحتفاظ بالحقيقة المطلقة (ground truth)، حيث تظل تعريفات مهاراتك حيث تنتمي: في .apc/skills/<name>.md.

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

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

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

من ينتصر عندما تتصادم المهارات

يفرض APX أيضاً ترتيب أولويات واضحاً عندما يقوم بتحميل المهارات. فليست كل البيئات متشابهة، ولا ينبغي أبداً للنصائح العامة أن تطغى على المعرفة المحلية.

تحظى مهارات المشروع بالأولوية القصوى. توجد هذه الملفات في مستودعك الحالي تحت المسار .apc/skills/. وهي توثق الاصطلاحات الخاصة بفريقك، والأغلفة المخصصة (custom wrappers)، ومعايير التسمية القديمة، وسلسلة الأدوات (toolchain) الخاصة بك. إذا حدد مشروعك طريقته الخاصة في التعامل مع عمليات ترحيل قواعد البيانات (database migrations)، فإن هذا التعريف هو الذي يُعتمد.

تأتي المهارات العامة في المرتبة التالية. وهي تغطي الأنماط المطبقة على مستوى المؤسسة والتي تُطبق عندما يظل المشروع نفسه صامتاً بشأنها. وهي تعمل بمثابة مكتبة قياسية.

وتأتي مهارات وقت التشغيل المدمجة (Built-in runtime skills) في الأسفل كخيار احتياطي. وهي تتعامل مع القدرات العامة التي يجب أن يفهمها كل وكيل (agent)، ولكن لم يقم أي مشروع محدد بإعادة تعريفها.

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

كيف يبدو هذا في الممارسة العملية

تخيل مهمة صيانة نموذجية. يقوم أحد الزملاء بلصق سجل أخطاء (error log) في الدردشة. يشير تتبع الخطأ (traceback) إلى مرجع فارغ (null reference) واحد في وحدة برمجية مساعدة. ومن المرجح أن يكون الإصلاح عبارة عن سطرين من البرمجة الدفاعية (defensive coding).

في نظام لا يعتمد التحميل عند الطلب، سيقوم APX بحشو السياق بكل مهارة يعرفها. سيصبح لدى النموذج الآن أربعون صفحة من النصوص للنظر فيها قبل لمس هذين السطرين. سيرى قائمة مراجعة الإصدار ويتساءل عما إذا كان يجب عليه ترقية الإصدار. سيرى دليل الأمان ويفكر في التحقق من صحة المدخلات في دالة تحتاج فقط إلى فحص القيمة الفارغة (null check). سيرى دليل تشغيل النشر ويبدأ في التفكير في بيئات الاختبار (staging environments). هنا يتشتت النموذج، وتستغرق الاستجابة وقتاً أطول، ويتزايد استهلاك الرموز (tokens) بسرعة.

أما مع تصميم APX القائم على الطلب، فلا يرى النموذج سوى الأسماء. هو يعلم أن [release-checklist] و [security-guide] و [deployment-runbook] و [error-handling] موجودة، لكنه يتجاهل الثلاثة الأولى. وقد يقوم بتحميل [error-handling] إذا كانت اصطلاحات مشروعك بشأن سلامة القيم الفارغة (null safety) محددة. فيقوم بإصلاح الخطأ. لم تدخل المهارات غير ذات الصلة أبداً في نافذة السياق، وظل النموذج مركزاً لأن المطالبة (prompt) ظلت نظيفة.

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

انضباط الأوامر (Prompt Discipline) كبنية تحتية

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

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

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