قاموس الذكاء الاصطناعي

علامة متغيرة، ليست تكنولوجيا. لا يسمى "الذكاء الاصطناعي" بشيء ثابت بالطريقة التي يفعلها الـmodel أو الـtoken - فهو يشير إلى كل ما يمكن للحواسيب فعله حديثاً وبشكل مذهل. في الوقت الحالي، يشير إلى النماذج اللغوية الكبيرة. لقد أشارت إلى أشياء مختلفة جداً من قبل:

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

لهذا السبب غالباً ما تتجاوز المحادثات حول الذكاء الاصطناعي بعضها البعض. ادعاء مثل "الذكاء الاصطناعي لا يمكنه التفكير" أو "الذكاء الاصطناعي مبالغ فيه" يحمل طابعاً زمنياً مخفياً - فقد يتعلق الأمر بالأنظمة الخبيرة، أو مصنفات الصور في العقد الثاني من القرن الحادي والعشرين، أو النموذج اللغوي الكبير للشهر الماضي، وكل مرجع يدعم استنتاجاً مختلفاً. عندما تتعثر مناقشة حول الذكاء الاصطناعي، عادة ما يكون الحل هو استبدال الكلمة بأي مصطلح دقيق مقصود بالفعل: النموذج، والـharness، والـagent، والـcontext الذي تم توفيره له.

تجنب: كلمة "الذكاء الاصطناعي" في أي ادعاء تقني - قم بتسمية الجزء الذي تعنيه بدلاً من ذلك. "البرمجة بالذكاء الاصطناعي" كعلامة لهذه الممارسة أمر مقبول؛ أما "الذكاء الاصطناعي يهذي" فليس كذلك.

الاستخدام:

"يريد مدير التكنولوجيا معرفة ما إذا كان الذكاء الاصطناعي يمكنه التعامل مع طابور الفرز."

"ترجم ذلك قبل تحديد نطاقه - فهو يقصد نموذجاً لغوياً كبيراً في إطار عمل مع إمكانية الوصول إلى نظام التذاكر. 'الذكاء الاصطناعي' بمفرده ليس مواصفات."

المعاملات. عديم الحالة، يجري التنبؤ بالرمز التالي ولا شيء غيره. «Claude Opus 4.x» و«GPT-5.x» نموذجان. لا يستطيع النموذج وحده القيام بعمل وكيل؛ بل يحتاج إلى إطار تشغيل.

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

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

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

الاستخدام:

«هل نبدّل النموذج من Sonnet إلى Opus في خطوة التخطيط؟»

«جرّب، لكن إطار التشغيل هو الذي ينجز معظم العمل في هذه المهمة. تبديل النموذج لن يفيد إن كانت مطالبة النظام والأدوات خاطئة».

الأعداد داخل النموذج، وغالبًا ما تكون بالمليارات، وتُضبط أثناء التدريب. كل ما «يعرفه» النموذج موجود فيها. يحددها التدريب، ويستخدمها الاستدلال من دون تغيير. وتُسمّى أيضًا الأوزان.

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

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

الاستخدام:

«هل يمكننا ضبطه بدقة على قاعدة شيفرتنا؟»

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

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

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

وتهم نتيجتان في العمل اليومي. ينتهي التدريب في نقطة زمنية، لذا يملك النموذج تاريخ انقطاع معرفة؛ فلم يرَ إصدار المكتبة الذي ترقيت إليه الشهر الماضي. والتدريب ليس شيئًا تستطيع أنت فعله: حين لا يعرف النموذج قاعدة شيفرتك أو أعرافك أو واجهات API الداخلية، لا يكون الحل أبدًا «تعليم النموذج»، بل وضع تلك المواد في السياق، وهو المدخل الوحيد الذي تتحكم فيه.

الاستخدام:

«هل يمكن جعله يعرف API الداخلية لدينا؟»

«ليس بالتدريب؛ فتلك عملية تستغرق أشهرًا يجريها مزوّد النموذج. حمّل وثائق API في السياق بدلًا من ذلك؛ هذه هي الوسيلة التي تملكها فعلًا».

تشغيل نموذج مدرب لإنتاج مخرجات — وهو ما يحدث في كل طلب لمزود النموذج. تظل المعلمات ثابتة؛ يقوم النموذج فقط بـ التنبؤ بالرمز التالي عبر السياق الذي يُمنح له. رخيص مقارنة بـ التدريب، ولكنه يُحاسَب لكل رمز وهو التكلفة المهيمنة لاستخدام النموذج.

تتذمر حياة النموذج إلى مرحلتين:

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

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

الاستخدام:

"لماذا يتدرج الفاتورة مع الاستخدام بدلاً من أن يكون ترخيصاً ثابتاً؟"

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

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

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

تعرض معظم الأطر الجهد كسلم صغير:

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

طابق الجهد مع المهمة، وليس الجلسة. ارفعه للجزء الصعب حقًا من الناحية المنطقية، وافضه للأعمال الروتينية من حوله.

الاستخدام:

"إنه يستمر في تفسخ إصلاح التزامن هذا — لقد أعدت شرحه ثلاث مرات."

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

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

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

وكقاعدة تقريبية، يعادل الرمز نحو ثلاثة أرباع كلمة إنجليزية، فتساوي ألف رمز نحو 750 كلمة. والشيفرة أقل قابلية للتنبؤ: تُجزّأ الكلمات المحجوزة والتعابير الشائعة بإيجاز، فيما تنقسم المعرّفات المولدة والتجزئات وكتل base64 والمخرجات المصغّرة إلى رموز كثيرة لكل «كلمة». والنمط هو أن النص الذي تكرر كثيرًا في مواد مصدر المُجزّئ يحصل على ترميز قصير وكفؤ، وما لم يتكرر يتفتت إلى أجزاء صغيرة كثيرة. فتجزئة مثل `a3f9c2e1` لم تظهر في أي مكان، لذا تنقسم إلى رموز كثيرة، بينما `function` رمز واحد. ولهذا قد يشغل ملف يبدو صغيرًا ومليئًا بسلاسل غير مألوفة حصة مفاجئة من نافذة السياق.

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

تجنّب: «كلمة»؛ فحدود الرموز لا تطابق حدود الكلمات، والرموز في الثانية والرموز لكل دولار هي الوحدات المهمة فعلًا.

الاستخدام:

«كم سيكون حجم هذه المطالبة؟»

«مررها عبر المُجزّئ؛ فالمخطط موجز، لكن مفاتيح JSON غريبة، لذا ستنقسم إلى رموز أكثر مما تظن».

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

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

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

الاستخدام:

«كيف يقرر الوكيل استدعاء أداة؟»

«لا يقرر؛ فالأمر كله تنبؤ بالرمز التالي. واستدعاء الأداة مجرد سلسلة منظمة يستخرجها إطار التشغيل من تدفق الخرج».

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

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

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

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

الاستخدام:

«كان Claude فظيعًا اليوم. هل أطلقوا نسخة أسوأ؟»

«على الأرجح لا؛ فمخرجات النموذج غير حتمية. ستكون لك أيام جيدة وأخرى سيئة في المهمة نفسها. جرّب مجددًا غدًا قبل أن تبدأ البحث عن سبب».

أي جهة تشغّل نموذجًا من أجل الاستدلال. عادةً خدمة بعيدة (Anthropic أوOpenAI أوGoogle)، لكنها قد تكون محلية أيضًا: Ollama أوLM Studio أوllama.cpp على جهازك. لا يشغّل إطار التشغيل النموذج بنفسه، بل يطلب من مزوّد تشغيله.

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

كما يحدد المزوّد الشروط التجارية: تسعير رموز الإدخال والإخراج، وخصومات ذاكرة البادئة المؤقتة، والنماذج المتاحة أصلًا. وقد يكون المزوّد وصانع النموذج شركتين مختلفتين؛ إذ تقدم Bedrock وVertex وOpenRouter نماذج الآخرين.

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

الاستخدام:

«هل نستطيع تشغيل هذا بلا اتصال لعميل الشبكة المعزولة؟»

«بدّل مزوّد النموذج إلى محلي، مثل Ollama أوllama.cpp على جهازهم. لا يهتم إطار التشغيل؛ إنه يتصل بنقطة نهاية مختلفة فحسب».

كل ما يحيط بـ model الذي يحوله إلى agent: tools، وsystem prompt، وcontext-window management، والأذونات، والخطافات. يعمل Claude.ai وClaude Code على نفس النموذج ولكن سلوكهما يختلف لأن الأغلفة (harnesses) الخاصة بهما مختلفة.

النموذج نفسه يقوم بشيء واحد فقط: إدخال نص وإخراج نص. لا يمكنه قراءة ملف، أو تشغيل أمر، أو تذكر الـ turn الأخير. الغلاف يوفر كل ذلك. فهو يجمع الـ context لكل model provider request، وينفذ استدعاءات الأدوات tool calls التي يطلبها النموذج، ويغذي نتائج الأدوات tool results مرة أخرى، ويخزن تاريخ الـ session، ويطلب منك الإذن قبل الإجراءات الخطرة، ويقرر متى يتم ضغط السياق compact. حلقة الوكيل — يقترح النموذج، يننفذ الغلاف، وتتكرر — يتم تشغيلها بواسطة الغلاف.

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

أمثلة: Claude Code، وCursor، وCodex CLI — وClaude.ai، وهو غلاف محادثة بدلاً من غلاف برمجي.

الاستخدام:

"نفس النموذج، فلماذا يقوم Claude Code بتعديل الملفات بينما يجيب Claude.ai على الأسئلة فقط؟"

"أغلفة مختلفة — لدى Claude Code أدوات filesystem، وموجه نظام مختلف، وطبقة أذونات. النموذج ليس هو المتغير هنا."

One round-trip from the harness to the model provider. The harness sends the current context; the provider returns one response (a tool call or a final answer). A single user message can spawn many model provider requests if the agent calls tools — each tool result triggers another request.

Each request carries everything: the system prompt, the full conversation so far, every tool result. The model is stateless, so the provider keeps nothing between requests — request forty re-sends what request thirty-nine sent, plus one more tool result. The prefix cache exists to make this repetition affordable.

The request is also the unit of billing. Input tokens, output tokens, and cache discounts are all counted per request, which is why an innocuous-looking question can cost a surprising amount: the cost isn't proportional to your message, it's proportional to the number of requests times the size of the context each one carries.

It's worth keeping the request distinct from the turn. A turn is one exchange with you, and a single turn — "fix the failing test" — plays out as a chain of requests:

Six requests for one turn — each one re-sending the whole context. When you wonder where the tokens went, count the requests, not the turns.

Usage

"One question burned forty thousand tokens?"

"Look at the tool calls — twelve grep, eight read, four edits. Each tool result spawns another model provider request, and the whole session prefix re-sends every time."

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

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

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

الاستخدام:

«الفاتورة مرتفعة، لكن الوكيل بالكاد يكتب شيئًا».

«إنها رموز الإدخال؛ فكل دور يعيد إرسال الجلسة كاملةً. ومن دون ذاكرة البادئة، تعيد دفع ثمن السجل في كل طلب».

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

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

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

الاستخدام:

«جلسة إعادة الهيكلة تلتهم الرصيد رغم صغر المدخلات».

«يعيد الوكيل كتابة ملفات كاملة بدل ترقيعها. تكلف رموز الإخراج نحو خمسة أضعاف سعر الإدخال؛ اجعله ينتج تعديلات وستنخفض الفاتورة».

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

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

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

الاستخدام:

«لماذا قفزت الفاتورة في منتصف الجلسة؟»

«بدأ إطار التشغيل يحقن الوقت الحالي في مطالبة النظام في كل دور. تنكسر ذاكرة البادئة عند أول رمز متغير، لذا احتُسب كل طلب بعد ذلك بالسعر الكامل».

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

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

يوضح مثال متى تُخزَّن الرموز ومتى لا تُخزَّن. يرمز كل حرف إلى كتلة من محتوى المحادثة؛ ويرسل كل طلب المحادثة حتى لحظته:

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

الاستخدام:

«كلفة الجلسات الطويلة قاسية؛ ثمانية دولارات لإعادة هيكلة».

«افحص رموز التخزين المؤقت. إذا كان الإطار يعيد ترتيب مطالبة النظام أو الملفات بين الأدوار، تنكسر البادئة وتدفع سعر الإدخال الكامل في كل طلب».

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

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

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

الاستخدام:

"لماذا ينسى الاصطلاح في كل مرة أقوم فيها بـ المسح؟"

"النموذج بدون حالة — تبدأ الجلسة الجديدة فارغة. إذا كنت تريد ترحيله، فاكتبه في AGENTS.md أو ملف ذاكرة يقوم التسخير بتحميله عند بدء الجلسة."

المعلومات ذات الصلة التي يستطيع الوكيل الوصول إليها الآن. الاسم المجرد، لا المدخل الخام الذي يراه النموذج (تلك نافذة السياق)، ولا السجل المتواصل (تلك الجلسة)، بل ما يعرفه الوكيل مما يتعلق بالمهمة. وتعني «إضافة شيء إلى السياق» جعله جزءًا من هذه المجموعة؛ و«هندسة السياق» هي تخصص انتقائها وتنظيمها.

تنفصل المصطلحات الثلاثة بوضوح:

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

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

الاستخدام:

«يواصل اختراع حقول غير موجودة في النوع».

«ملف النوع ليس في السياق؛ إنه يقرأ مواضع الاستدعاء ويخمن. اقرأ التعريف أولًا».

كل ما يراه الـ model في كل model provider request. محدود، وخاص بالنموذج، وهو السطح الوحيد الذي من خلاله يدرك النموذج أي شيء.

إنه تسلسل واحد من الـ tokens: الـ system prompt، والمحادثة حتى الآن، وكل tool result قام الـ harness بإرجاعها. إذا كان هناك شيء في هذا التسلسل، يمكن للنموذج استخدامه؛ وإذا لم يكن كذلك، فلا يعرف النموذج أنه موجود — ليس قاعدة بياناتك، ولا الملف الذي قمت بتعديله بالأمس، ولا التعليمات التي أعطيتها قبل ثلاث جلسات. أي شيء خارج النافذة يجب جلبه، عادة عبر tool call، قبل أن يؤثر على أي شيء.

المحدودية تعني أنها تملأ. يضيف كل دور المزيد — رسائلك، ردود النموذج، نتائج الأدوات — وسيصل الـ session الطويل في النهاية إلى الحد الأقصى، مما يجبر على الـ compaction أو الـ clearing. هذا يعني أيضاً أن كل شيء في النافذة يتنافس: كل رمز تحمله هو رمز واحد أقل متاح للباقي، والمحتوى الذي لم تقم بحاجته لا يزال يشغل attention النموذج. الموقف العملي هو التعامل مع النافذة كيزانية — حمل ما تحتاجه المهمة، واترك الباقي وراءك.

تجنب: "الذاكرة" — نافذة السياق هي حالة عمل ولا تستمر عبر الجلسات. Memory هو مفهوم منفصل مطبق في الأعلى.

الاستخدام:

"هل يمكنني فقط لصق المستودع بأكمله في الموجه؟"

"نافذة السياق هي 200 ألف رمز — وهذا ربما خمس المستودع. اختر الملفات التي تلمسها المهمة، واترك الباقي خلف استدعاء أداة."

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

حيث تكمن الحالة في كل طبقة:

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

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

الاستخدام:

"تذكر تفضيلاتي من الأمس - هل هذا يعني أن النموذج قد تعلمها؟"

"لا، الوكيل يحتفظ بالحالة لأن التسخير كتبها في ملف ذاكرة وأعاد تحميلها عند بدء الجلسة. ولم يرى النموذج نفسه شيئاً من الأمس."

نموذج مدعوم بـأدوات، وموجه نظام، ونافذة سياق، يأخذ أدواراً/تناوبات مع مستخدم. كلاود كود (Claude Code) هو وكيل. كيرسور (Cursor) هو وكيل. كلاود.إي (Claude.ai) هو وكيل. الوكيل هو ما تتحدث معه فعليًا — إنه النموذج قيد الحركة، والمُهَيَّأ لغرض معين.

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

هذه الفكرة أقدم من هذه الموجة من الذكاء الاصطناعي. وكلاء البرمجيات — البرامج التي تفوضها هدفًا والتي تتصرف نيابة عنك — كانت مفهومًا طالما وجد الذكاء الاصطناعي.

تجنب استخدام: "الذكاء الاصطناعي"، "البوت" (فهي غامضة للغاية — إذ تخفي ما إذا كنت تعني المعلمات أم الشيء المهيكل).

الاستخدام:

"أي وكيل تستخدمه للهجرة؟"

"كلاود كود محلياً، وكيرسور لعمل واجهة المستخدم — نفس النموذج في الجوهر، وهياكل مختلفة."

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

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

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

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

الاستخدام:

«إطارا تشغيل بالنموذج نفسه، وسلوك مختلف تمامًا للمطالبة نفسها».

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

تشغيل تفاعلي واحد ومحدد مع agent. يبدأ فارغاً، ويجمع الرسائل، وtool results، والملفات المقروءة، وينتهي عند cleared، أو إغلاقه، أو compacted في جلسة جديدة. الجلسة هي ما يملأ context window: إذا كانت نافذة السياق هي الصندوق، فالجلسة هي الأشياء التي تملؤها ببطء. يجب تقسيم العمل الأكبر من نافذة سياق واحدة عبر جلسات متعددة.

تاريخ رسائل الجلسة هو ذاكرة عمل الوكيل. model هو stateless، لذا فإن كل ما يبدو أنه يتذكره - ما طلبته، وما قالته الاختبارات، وما قرره قبل ثلاث دورات - موجود في تاريخ الرسائل، ويتم إعادة إرساله مع كل model provider request. كل ما ليس في الجلسة غير موجود بالنسبة للوكيل.

تنتهي تلك الذاكرة بنهاية الجلسة. تبدأ جلسة جديدة من الصفر: الوكيل الذي كان يعرف قاعدة بياناتك البرمجية جيداً في نهاية جلسة الأمس لا يعرف شيئاً منها هذا الصباح. ما يبقى هو filesystem - الملفات التي تمت كتابتها خلال جلسة واحدة يمكن قراءتها بواسطة الجلسة التالية، وهو ما تعتمد عليه handoffs، وmemory systems، وAGENTS.md.

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

الاستخدام:

"ما المدة التي يمكن أن تستغرقها جلسة واحدة قبل أن تنهار؟"

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

One user message plus everything the agent does in response, up until it yields back to the user. Contains one or more model provider requests — many, if the agent calls tools. A clarifying question closes the turn; your reply opens the next one. The hierarchy is session > Turn > Model provider request.

What makes the turn worth naming is that its length is the agent's decision, not yours. You hand over one message; the agent decides how many tool calls to chain before yielding. A turn can be a one-sentence answer or twenty minutes of reading, editing, and running tests. That's the same property from two angles: long turns are what make AFK work possible, and long turns are also where things go wrong unsupervised — by the time the agent yields, it may have drifted a long way from what you meant.

The turn is also the natural unit for steering. Everything inside a turn happens without you; the gaps between turns are where you redirect. Most harnesses soften this: you can interrupt mid-turn to stop the agent and redirect it, or type a message while it works, which gets read once the turn completes. If you find yourself repeatedly unhappy with where turns end up, the fix is usually to ask for smaller ones — a plan first, one step at a time — trading autonomy for more frequent gaps to steer in.

Usage

"One turn took two minutes?"

"It made fourteen tool calls inside that turn — each one is a separate model provider request. Latency stacks up before the agent finally yields back to you."

العالم الذي يتصرف فيه الوكيل: كل ما يقع خارج إطار التشغيل ويدركه الوكيل عبر نتائج الأدوات ويغيّره عبر استدعاءاتها. إطار التشغيل يشغّل الوكيل؛ والبيئة هي ما يعمل فيه الوكيل. يوجد ملف مثل `AGENTS.md` في البيئة؛ وإطار التشغيل هو ما يحمّله إلى نافذة السياق. ونظام الملفات أشهر أنواع البيئات، لكنه ليس الوحيد؛ فقاعدة بيانات أو API بعيدة أو جلسة متصفح قد تكون كلها بيئات.

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

والبيئة أيضًا هي الطبقة التي تدوم، والوحيدة التي تكون دائمًا ذات حالة. يختفي سياق الجلسة بانتهائها، لكن الملفات المكتوبة في البيئة تبقى لتقرأها الجلسة التالية؛ وهذا ما تعتمد عليه أنظمة الذاكرة ومستندات التسليم و`AGENTS.md`. وكل ما ينبغي أن يظل الوكيل يعرفه غدًا يجب أن ينتهي في البيئة.

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

تجنّب: استخدام «البيئة» للدلالة على بيئة التشغيل أو إطار التشغيل نفسه؛ فالإطار هو الغلاف، والبيئة هي مساحة العمل.

الاستخدام:

«لا يستطيع الوكيل رؤية مخطط قاعدة بيانات الاختبار المرحلي».

«اربطها بالبيئة؛ امنحه أداة `psql` بصلاحية قراءة فقط على الاختبار المرحلي. إطار التشغيل سليم، لكنه لا يجد ما يتصرف فيه».

شجرة من الملفات والأدلة يقرأ منها الوكيل، ويكتب فيها، وينفذ من خلالها — النوع الافتراضي من البيئة لوكيل البرمجة. AGENTS.md، والمهارات، وشفرة المصدر، ونصوص البناء، وتكوينات الأدوات كلها تعيش في نظام الملفات. عندما يبدأ الحزام (harness) "في مشروعك"، فإنه يوجه الوكيل إلى نظام ملفات.

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

وهو مشترك معك. الملفات التي يعدلها الوكيل هي نفس الملفات التي تفتحها في محرر النصوص الخاص بك وتجري مقارنة (diff) لها في git — نظام الملفات هو مساحة العمل المشتركة حيث تراجع ما فعله الوكيل.

الاستخدام:

"لماذا لا يلتقط ملف AGENTS.md الخاص بي؟"

"إنه يعمل مقابل نظام ملفات مختلف — قامت منطقة الحماية (sandbox) بتحميل المجلد الأب وليس جذر المشروع. أعد توجيه الحزام."

دالة يوفرها المسؤول لـ الوكيل لاستدعائها — Read وWrite وBash وSearch. الأدوات هي الوسيلة التي يدرك بها الوكيل البيئة ويتفاعل معها: لا يمكنه رؤية البيئة إلا من خلال نتائج الأدوات، ولا يمكنه تغييرها إلا من خلال استدعاءات الأدوات. كل استدعاء أداة يكلف طلب مزود نموذج إضافيًا، حيث يجب إرجاع النتيجة إلى النموذج قبل أن يتمكن من تحديد ما يجب فعله بعد ذلك.

الأدوات التي تأتي معها معظم وكلاء البرمجة:

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

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

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

الاستخدام:

"هل يمكن للوكيل الاستعلام عن مرحلة التجربة مباشرة؟"

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

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

دورة حياة استدعاء الأداة:

عادةً ما يتكون دور واحد من عمل الوكيل من كثير من رحلات الذهاب والإياب هذه مترابطةً.

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

الاستخدام:

«قال إنه شغّل الاختبارات، لكن الطوابع الزمنية للملفات لم تتغير».

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

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

دورة حياة نتيجة الأداة:

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

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

الاستخدام:

«إنه يستدل بشأن الملف كأنه فارغ».

«عادت نتيجة الأداة برفض صلاحية، لا بالمحتويات. لم يرَ النموذج سوى سلسلة الخطأ؛ وليس له سبيل آخر إلى رؤية الملف».

بروتوكول سياق النموذج (Model Context Protocol). بروتوكول لربط خوادم الأدوات الخارجية بـ harness — وهي الطريقة التي يحصل بها agent على tools تتجاوز ما يأتي مع الحزمة الأساسية. الوكيل لا "ينادي MCP" أبداً؛ بل ينادي أداة، ويصادف أن الحزمة حصلت على تلك الأداة من خادم MCP. كما يعرض موارد (بيانات للقراءة فقط) ونماذج (قوالب قابلة لإعادة الاستخدام)، ولكن توفير الأدوات هو الاستخدام الأساسي.

يحل البروتوكول مشكلة تكامل. بدون معيار موحد، ستحتاج كل حزمة إلى تكاملها الخاص مع Linear، وتكاملها الخاص مع Slack، وتكاملها الخاص مع قاعدة البيانات — بحيث يتم كتابتها وصيانتها بشكل منفصل لكل منها. ومع استخدام MCP، يتم كتابة التكامل مرة واحدة كخادم، ويمكن لأي حزمة متوافقة مع MCP استخدامه. تتصل الحزمة بالخادم، ويعلن الخادم عن الأدوات التي يقدمها، وتصبح تلك الأدوات متاحة للوكيل جنباً إلى جنب مع الأدوات المدمجة.

التكلفة تُدفع في context (السياق). كل أداة يعلن عنها الخادم تأتي كتعريف — الاسم، الوصف، مخطط المعلمات — وmodel لا يمكنه استدعاء سوى الأدوات التي يعرفها. النهج الساذج يحمل كل تعريف إلى context window مسبقاً: قم بتثبيت عدد قليل من الخوادم السخية وتبدأ session بآلاف من tokens (الرموز) لمخططات الأدوات قبل أن تكتب أي شيء، مما يصرف attention budget (ميزانية الانتباه) على أدوات لن تستخدمها المهمة أبداً.

تعمل العديد من الحزم الآن على تخفيف هذه المشكلة باستخدام بحث الأدوات: بدلاً من التعريفات الكاملة، يحتفظ السياق بـ context pointer (مؤشر السياق) للأدوات المتاحة — يبحث الوكيل عن أداة بالاسم أو الغرض ويحمل تعريفها فقط عندما يحتاج إليها. إذا كانت حزمتك لا تفعل ذلك، فإن التكلفة الأولية تظل سارية، ومن الأجدر تمكين الخوادم التي يحتاجها المشروع بالفعل فقط.

الاستخدام:

"يحتاج الوكيل إلى قراءة التذاكر من Linear."

"قم بتكوين الحزمة لاستخدام خادم Linear MCP — فهو يعرض واجهة برمجة تطبيقات Linear كأدوات يمكن للوكيل استدعاؤها. يوفر عليك كتابة أغلفة أدوات مخصصة."

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

دورة حياة طلب الصلاحية:

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

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

الاستخدام:

«إنه عالق في طلب صلاحية منذ عشر دقائق؛ كنت في اجتماع».

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

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

تقدم أطر التشغيل سلمًا من هذه الأوضاع:

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

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

الاستخدام:

«توقف عند كل grep؛ أفسد التشغيل بعيدًا عن لوحة المفاتيح تمامًا».

«خفف وضع الصلاحيات لأدوات القراءة فقط، وأبقِ السؤال قبل الكتابة وأوامر الصدفة. معظم طلبات الصلاحية في جلسة بحث مجرد ضجيج».

إعداد مسبق يحدد كيفية عمل الـagent أثناء وقت التشغيل — يدمج permission mode مع تعليمات سلوكية يتم حقنها في الـsystem prompt. أمثلة: الوضع الافتراضي الذي يطالب عند المكالمات المحفوفة بالمخاطر، ووضع التخطيط (plan mode) الذي يحظّر التعديلات ويوجه الوكيل نحو البحث، ووضع قبول التعديلات (accept-edits) الذي يوافق تلقائياً على التعديلات، ووضع تجاوز الأذونات (bypass permissions) (الذي يُعرف اصطلاحاً بـوضع YOLO) الذي يوافق تلقائياً على كل شيء. يمكنه تغيير الوضع mid-session.

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

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

مصطلحات البائعين: تسمي Claude Code هذه الأوضاع بـ "أوضاع الأذونات"، وتسميها Codex بـ "أوضاع الموافقة" — وكلاهما يسبق الدمج السلوكي.

الاستخدام:

"يستمر في تعديل الملفات عندما أريد خطة فقط."

"التحول إلى وضع التخطيط — سيقوم بحظر عمليات الكتابة والبقاء في البحث."

"ماذا عن تشغيل AFK لاحقاً؟"

"وضع التجاوز، ولكن فقط داخل بيئة المعالجة المعزولة."

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

تحل بيئة الحماية (الـ sandbox) وpermission mode المشكلة نفسها من اتجاهين متعاكسين. تطلب الأذونات الإذن قبل تنفيذ الإجراء؛ بينما تحد بيئة الحماية مما يمكن أن يصله الإجراء إذا تم تنفيذه بالفعل. تتطلب الأذونات أن تكون in the loop — فكل مطالبة تعتبر مقاطعة — والجلسة التي تسأل باستمرار بالكاد تكون مستقلة. تنفق بيئة الحماية البنية التحتية بدلاً من الانتباه: كلما كان العزل أقوى، كلما قل عدد الأسئلة التي تحتاج إلى طرح.

يأتي العزل بدرجات:

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

الاستخدام:

"أريد السماح له بالتشغيل bypass-permissions طوال الليل لكنني لست مستعداً لذلك بعد."

"ضعه في بيئة حماية — حاوية جديدة، بلا بيانات اعتماد مثبتة، وبلا اتصال بش الشبكة للخارج. أسوأ الاحتمالات أنه سيدمر نظام ملفاته الخاص وتتخلص أنت من الحاوية."

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

تظهر على شكل:

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

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

الإصلاح: إخفاء تفضيلاتك. صغ التوجيهات بشكل حيادي - "راجع هذا الكود" وليس "هل هذا الكود جيد؟".

تجنب: استخدام "التملق" لأي إجابة خاطئة تصدف أن ترضيك. بدون اختبار التشخيص، ليس للمصطلح قيمة أكثر من "خطأ."

الاستخدام:

"قال إن خطة إعادة الهيكلة الخاصة بي تبدو رائعة، ثم سألت 'هل أنت متأكد؟' فتراجع عن الأمر برمته."

"تملق كلاسيكي - وافق أولاً لأنك تبدُ واثقًا، ثم تراجع لأنك تبدُ متشككًا. لم تتغير جودة الخطة، بل تغيرت نبرتك. Clear وأعد السؤال دون إبداء إشارة في أي من الاتجاهين."

نموذج model خاطئ بثقة. نوعان لهما أسباب وعلاجات مختلفة:

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

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

تجنب: كلمة "الهلوسة" كمرادف مجرد لـ "خطأ" — بدون تسمية النوع، لا قيمة تشخيصية للمصطلح.

الاستخدام:

"لقد هلوس بـ طريقة `parseAsync` على المخطط."

"الدقة أم الأمانة؟"

"الطريقة موجودة في المستندات التي لصقتها — لقد توقف عن قراءتها بعد دور الأربعين."

"إذن فهي الأمانة. قم بالضغط وإعادة التحميل، ولا تهتم بإضافة المزيد من المستندات."

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

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

وتتقادم المعرفة المعاملية أيضًا. تتوقف المعاملات عن التغير عند تاريخ انقطاع المعرفة، فلا توجد فيها مكتبة أُطلقت أو أُعيدت تسميتها بعد ذلك، وتُتذكَّر API المتغيرة بصيغتها القديمة.

وللفجوتين، الندرة والحداثة، العلاج نفسه: لا يمكن إضافة المعرفة إلى المعاملات، لذا يجب تقديمها كمعرفة سياقية بدلًا من ذلك.

الاستخدام:

«يكتب React بإتقان، لكنه يخترع أساليب في SDK الداخلية لدينا».

«React كثيفة في المعرفة المعاملية، بملايين أمثلة التدريب. أما SDK لديك فليست كذلك، فيملأ النموذج الفراغ بأشكال تبدو معقولة. حمّل وثائق SDK في السياق».

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

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

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

الاستخدام:

«يواصل كتابة صياغة SDK بالإصدار v3، ونحن نستخدم v5».

«صدر v5 بعد تاريخ انقطاع المعرفة. حمّل سجل تغييرات v5 بوصفه معرفة سياقية، وإلا سيواصل الاختلاق انطلاقًا من النسخة المعاملية الأقدم».

الحقائق التي يمكن لـ الوكيل قراءتها مباشرة من السياق الآن — مهمة المستخدم، الملفات التي قرأها الوكيل، نتائج الأداة، محتوى AGENTS.md الذي تم تحميله عند بدء الجلسة. المقابل لـ المعرفة البارامترية: المعرفة البارامترية يتم استرجاعها من البارامترات؛ أما السياقية فيتم قراءتها من النافذة. الهلوسات تكون أقل بكثير عندما يعمل الوكيل بناءً على المعرفة السياقية — فالإجابة ماثلة أمامه مباشرة، وليست مستخرجة من ذاكرة ضبابية.

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

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

على عكس المعرفة البارامترية، فإن المعرفة السياقية تكلف شيئاً لاستخدامها. كل ما يتم تحميله في النافذة يستهلك رموزاً (Tokens) ويتنافس على ميزانية انتباه النموذج، لذا فإن تحميل المزيد ليس أفضل تلقائياً — فالهدف هو الحقائق ذات الصلة في النافذة، وليس كل الحقائق.

التمس هذا المصطلح فقط عند المقارنة مع المعرفة البارامترية؛ وإلا قل ببساطة السياق.

تجنب: "الذاكرة العاملة" — المعرفة السياقية هي ما يوجد في النافذة الآن؛ أما نظام الذاكرة فهو ما يجلب المحتوى عبر الجلسات إليها. نطاقات مختلفة، فلا تدمجهما.

الاستخدام:

"لماذا يُتقن واجهة برمجة التطبيقات (API) عندما ألصق المستندات ويختلقها عندما لا أفعل؟"

"مع إدخال المستندات، تصبح معرفة سياقية — القراءة من الصفحة. وبدونها، تصبح بارامترية وتتلاشى النقاط الطرفية النادرة."

عند التنبؤ بكل رمز، يأخذ النموذج كل رمز آخر في السياق بالحسبان؛ بعضه بقوة وبعضه بالكاد. والاقتران بين رمزين هو علاقة انتباه، وتؤثر الأزواج ذات المعنى («her» مع «Sarah»، أو استدعاء `getUser()` مع تعريف `function getUser`) في بعضها أكثر من الأزواج غير المرتبطة. ولسياق من N رمز ما يقارب N² من العلاقات.

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

ويستحق رقم N² التأمل، لأنه ينمو أسرع مما يوحي الحدس:

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

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

الاستخدام:

«يواصل الخلط بين رمزَي `user` عبر الفرق؛ يبدو أننا في المنطقة الغبية».

«نعم، علاقة الانتباه بين كل موضع استدعاء وتصريحه تنافس الأخرى؛ شكل الرمز نفسه، وارتباطان مختلفان. أعد تسمية أحدهما فتتضح الاقترانات».

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

اعتبرها إشارة وضوضاء. إرشادك هو إشارة بحجم ثابت؛ كل رمز آخر في نافذة السياق هو صوت منافس. الإرشادات لا تصبح أهدأ أبدًا — فهي لا تزال موجودة، حرفًا بحرف — ولكن مع نمو السياق، تصبح الغرفة أعلى صوتًا حولها، وتنخفض نسبة الإشارة إلى الضوضاء. الإرشادات التي كانت أعلى شيء عند سياق 10 آلاف رمز أصبحت همسًا في الخلفية عند 150 ألفًا. هذه هي الآلية وراء تدهور الانتباه: النموذج لا ينسى؛ الإشارة تضيع في الضوضاء.

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

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

الاستخدام:

"لماذا يستمر في تجاهل المخطط الذي لصقته في الأعلى؟"

"نحن في عمق منطقة الغباء — ميزانية انتباه كل رمز ثابتة، لكن السياق استمر في النمو. أصبحت إشارة المخطط تتنافس الآن مع آلاف الرموز الأحدث."

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

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

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

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

الاستخدام:

"إنه عميق في منطقة الغباء — يخترع أنواعاً عامة غير موجودة في ملف الأنواع."

"تدهور الانتباه. تعريفات الأنواع لا تزال في السياق، لكن الإشارة عليها مدفونة تحت كل ما أضفناه منذ ذلك الحين. امسح وأعد التحميل."

في وقت مبكر من أي session ، يكون agent في "منطقة ذكية" — حاد، مركز، والذاكرة جيدة. وكلما امتدت الجلسة، تنحرف إلى "منطقة غبية": أكثر إهمالاً، وأكثر نسياناً، وأكثر أخطاءً — وأكثر وفاءً hallucinations]. نفس model]، ونفس harness ] — ببساطة المزيد من context]. إنه التأثير المحسوس لـ attention degradation]. في النماذج الرائدة، تبدأ المنطقة الغبية عادةً حول 125 ألف إلى 150 ألف tokens ] — على الرغم من أن هذا محل نقاش. قم بـ Clear ] أو compact ] عندما تتضخم الجلسة؛ لا تضغط وتستمر.

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

لا تتتبع المناطق حد context window ]. يمكن أن تكون الجلسة عميقة في المنطقة الغبية مع بقاء معظم النافذة خالية: الحد هو حيث يرفض الحزام الاستمرار، لكن الجودة تتراجع قبل ذلك بكثير حول المنطقة الذكية، وليس النافذة — الميزانية العملية للمهمة هي الرموز التي يعمل الوكيل بشكل جيد ضمنها، وليس الرموز التي يمكنه الاحتفاظ بها تقنياً.

المنطقة الذكية هي ميزانية، والعمل غير المرتبط ينفقها. كل مهمة يتم إنجازها في الجلسة تستهلك الرموز، لذا فإن بدء مهمة ثانية في نفس الجلسة يعني بدءها أقرب إلى المنطقة الغبية. القيام بمهمة واحدة لكل جلسة يمنح كل مهمة الجزء الأكثر حدة من الجلسة. عندما تكون مهمة واحدة أكبر من منطقة ذكية واحدة، قم بتقسيمها: hand off ] أو اضغط عند حد طبيعي، واجعل جلسة جديدة تقوم بالقطعة التالية.

الاستخدام:

"لقد أتقن المكونات الثلاثة الأولى وشوه الرابعة تماماً."

"أنت خارج المنطقة الذكية — نفس النموذج، فقط عميق في المنطقة الغبية الآن. اضغط وأعد تحميل الخطة، وسيهبط المكون التالي."

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

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

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

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

الاستخدام:

"إنه عالق في حلقة على الاختبار الفاشل."

"قم بتفريغه فقط — ابدأ جلسة جديدة مع وثيقة الخطة وملف الاختبار. لا فائدة من محاربة السياق الحالي."

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

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

الإخفاق الظاهر للتسليم السيئ هو إعادة الجدل: تفتح الجلسة الجديدة قرارات حسمتها القديمة، لأن المنقول سجل ما تقرر ولم يسجل السبب. قيّم التسليم بحسب ما تستطيع جلسة بلا سياق أن تفعله به.

الاستخدام:

«أصبحت جلسة التخطيط ثقيلة؛ هل أواصل ببساطة؟»

«أجرِ تسليمًا. اكتب القرارات في مستند، وامسح الجلسة، وابدأ التنفيذ في جلسة جديدة تقرأ منه».

مصدر الحقيقة في شكله الأصلي — الشفرة (الكود)، نص المحادثة، السجل الخام، واستجابة واجهة برمجة التطبيقات الفعلية. ليس سرداً للشيء؛ بل هو الشيء نفسه. يقابل المصدر الثانوي.

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

التكلفة هي ما يمنع المصدر الأساسي من أن يكون الخيار الافتراضي. تحميل مصدر أساسي في نافذة السياق يُعد أمراً مكلفاً — الملف كاملاً، النص الكامل، وكل رمز (token) يتم فوترته كـ إخال (input) ويتنافس على ميزانية الانتباه. ما تحصل عليه مقابل هذه التكلفة هو الشمولية: لا شيء تمت تصفيته مسبقاً بناءً على تقدير شخص آخر لما كان مهماً. الملخص الذي كتبناه الشهر الماضي لا يمكنه احتواء التفاصيل التي ثبتت أهميتها اليوم؛ بينما المصدر الأساسي يظل محتفظاً بها.

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

الاستخدام:

"يقول الوكيل إن منطق إعادة المحاولة يتراجع بشكل أسي، لكنني أراه يقصف نقطة النهاية (endpoint) باستمرار."

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

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

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

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

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

الاستخدام:

"يقول مستند التسليم إن المصادقة قد انتهت، لكن الجلسة الجديدة تواصل العثور على تحديث رمز مميز معطل."

"الوثيقة هي مصدر ثانوي — الجلسة الأخيرة كتبت ما آمنت به، وليس ما هو صحيح. اجعل الجلسة الجديدة تشغيل اختبارات المصادقة وثق بالمصدر الأساسي."

وثيقة تستخدمآلية نقل لـ تسليم — تتم كتابتها في البيئة بواسطة جلسة واحدة ليتم قراءتها بواسطة جلسة أخرى. المواصفات، والتذاكر، ومستندات الخطط كلها عناصر تسليم.

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

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

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

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

الاستخدام:

"كيف أقسّم هذا بين وكيل التخطيط ووكيل التنفيذ؟"

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

عنصر تسليم](#handoff-artifact) يصف عملاً متعدد الجلسات — ما يتم بناؤه، وليس كيف تؤدي كل جلسة نصيبها. يتغير مع تقدم العمل. يتكون من تذاكر.

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

تأتي المواصفات بأسلوب معروف، موروث غالباً من كيفية كتابة الفرق للأشياء مسبقاً. تميل وثيقة متطلبات المنتج`plan.md` نحو ما يواجه المستخدم ولماذا — الميزات، السلوك، معايير القبول. تميل مستندات التصميم أو RFC نحو الجانب التقني — النهج المختار، والبدائل المرفوضة، والمقايضات. في الحد الأدنى، تؤدي الأداة العادية التي تحتوي على قائمة تحقق من التذاكر نفس الوظيفة لميزة متعددة الجلسات. يقل الاهتمام بالأسلوب مقارنة بالدور: بالنسبة لـ [الوكيل، كل من هذه هو نفس الشيء — بيان النية المتين الذي يقرأه في بداية كل جلسة.

الاستخدام:

"هل يجب أن يكون هذا كله جلسة واحدة؟"

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

عنصر تسليم](#handoff-artifact) يحدد نطاق جلسة واحدة من العمل. يعمل بمفرده أو يعتمد على مواصفات كأحد فرعياتها. يمكن للتذاكر أن تعيق تذاكر شقيقة أو تتأثر بها، بحيث ينتج ترتيب العمل من مخطط التبعيات الخاص بها بدلاً من خطة خطية.

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

تتم كتابة التذكرة الجيدة بحيث فهمها قارئ ليس لديه أي سياق آخر. الهدف، ومعايير القبول، ومؤشرات السياق للملفات والقرارات ذات الصلة — بشكل كافٍ يتيح للجلسة بدء العمل دون الحاجة لإعادة استنتاج ما عرفته الجلسة السابقة.

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

الاستخدام:

"من أين أبدأ في مواصفات الهجرة؟"

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

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

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

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

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

الاستخدام:

"السياق أصبح ثقيلاً وما زالت لدي اختبارات يجب تنفيذها."

"اضغط قبل أن تبدأ — اكتب ما يجب أن يبقى في توجيه الملخص لكي تحتفظ الجلسة بقرارات المخطط وتتخلص من الاستكشاف."

ضغط سياق يطلقه إطار التشغيل تلقائيًا حين تقترب نافذة السياق من الامتلاء.

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

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

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

الاستخدام:

«يبدو أنه لا يتذكر ما قررناه سابقًا بشأن المخطط».

«انطلق الضغط التلقائي بين الأدوار؛ لُخّصت القرارات المبكرة ولا بد أننا فقدنا شيئًا. أعد تحميل مستند الخطة، أو اضغط يدويًا في المرة المقبلة لتتحكم فيما يُحفَظ».

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

نظام الذاكرة له نصفان. مسار الكتابة: أثناء الجلسة، يسجل الوكيل ما تعلمه — تفضيل ذكرته، حقيقة حول المشروع — كملفات في البيئة. مسار القراءة: في بداية الجلسة، يقوم الحزام (harness) بتحميل تلك الملفات، أو فهرس لها، مرة أخرى في نافذة السياق. العديد من الحزم تأتي مع نظام الذاكرة الخاص بها — مثل `/memory` في Claude Code — ولكن يمكنك أيضاً بناء نظام خاص بك: دليل للملاحظات بالإضافة إلى تعليمات في ملف AGENTS.md لاستشارته.

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

الاستخدام:

"أستمر في الاضطرار إلى إعادة إخباره بأنني أستخدم Postgres وليس MySQL."

"قم بربط نظام الذاكرة — اكتب ما يتعلمه في نظام الملفات في المنعطف (turn) الأول، وأعد تحميله في بداية الجلسة. النموذج نفسه عديم الحالة (stateless)؛ وطبقة الذاكرة تحاكي الاستمرارية."

ملف في البيئة يقوم المسؤول بتحميله في نافذة السياق عند بدء الجلسة — الإحاطة الدائمة للمشروع لـ الوكيل. اصطلاح معتمد عبر أنظمة التشغيل؛ بعض الأنظمة تمتلك أيضًا متغيرها الخاص (مثل CLAUDE.md الخاص بـ Claude Code).

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

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

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

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

الاستخدام:

"لماذا تبدأ كل جلسة وقد حُرِقَت 4 آلاف رمز بالفعل؟"

"تحقق من AGENTS.md — لقد قام شخص ما لصق دليل النمط بأكمله هناك بدلاً من وضعه خلف مهارة."

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

توجد هذه التقنية لأن السياق يمثل تكلفة مضاعفة. يتم فوترة كل رمز (token) يتم تحميله مقدمًا كـ رموز إدخال في كل دورة (turn) ، ويستهلك كل رمز ميزانية انتباه بغض النظر عما إذا كان الوكيل بحاجة إليه أم لا. إن ملف AGENTS.md المحشو بدليل النمط الكامل، ودليل التشغيل الفوري للنشر، وقواعد قاعدة البيانات يجعل الوكيل أسوأ في التعامل معها جميعًا — فالتعليمات التي تهم المهمة الحالية تذوب وسط تلك التي لا تهمها. العلامة الدالة هي وكيل يتجاهل القواعد التي تعلم أنها موجودة في سياقه: فهي موجودة هناك، لكنها مدفونة.

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

الاستخدام:

"هل يجب عليّ تفريغ دليل النمط بأكمله في ملف AGENTS.md؟"

"لا — الإفصاح التدريجي. قم بالإشارة إلى دليل النمط كمهارة يقوم الوكيل بتحميلها عندما يحتاج بالفعل إلى كتابة مكون. يدفع ملف AGENTS.md تكلفة الرموز في كل دورة."

إشارة في مستند واحد تشير إلى مستند آخر، لكي يتمكن الـagent من سحبه إلى الـcontext window فقط عندما تقتضي التهمة ذلك. الوحدة التي تُبنى منها الـprogressive disclosure.

السبب وراء استخدام مؤشر (بدلاً من دمج المحتوى داخلياً) هو التكلفة. المؤشر هو سطر واحد في نافذة السياق. قد يحتوي المستند الذي خلفه على آلاف من الـtokens، لكن تلك الـ tokens لا تكلف شيئاً حتى يتبع الوكيل المؤشر فعلياً. قم بتضمين دليل تشغيل (runbook) مكون من 2000 token في ملف الـAGENTS.md وسيدفع كل session ثمنه؛ استبدله بـ "عملية النشر: انظر `internal/deploy.md`" ولن تقوم سوى الجلسات التي تقوم بالنشر بتحميله أبداً. يتبع الوكيل المؤشر باستخدام tool call عندما تتطابق المهمة.

يحتاج المؤشر إلى جزأين ليعمل: مسار مستقر، ووصف كافٍ ليعمل الوكيل متى يستحق الأمر اتباعه. المسار الخالي هو مؤشر ليس لدى الوكيل سبب لمتابعته؛ "انظر `internal/deploy.md`" بدون أي تلميح لما يوجد بالداخل سيتم تخطيه بواسطة جلسة كانت بحاجة إليه. اكتب السطر ليتوافق مع طريقة ظهور المهام: "إصدار، نشر، أو التراجع — اقرأ `internal/deploy.md` أولاً".

المؤشرات موجودة في كل مكان بمجرد أن تبحث: أسطر في AGENTS.md، أوصاف skill (تقوم الأداة المساعدة بتحميل الوصف؛ بينما ينتظر جسم المهارة خلفه)، أسماء الملفات في قائمة الدليل، الروابط بين المستندات.

يمكن للمؤشر أيضاً ربط secondary source بـprimary source الذي تم اشتقاقه منه — ملخص الضغط الذي يسمي النص الأصلي، والمستند الذي يسمي ملف المصدر الذي يصفه. هذا يجعل فقدان البيانات في المصدر الثانوي قابلاً للاسترداد: عندما يتبين أن الملخص غير كافٍ، يتبع الوكيل المؤشر ويقرأ الأصلي، بدلاً من العمل من أي شيء احتفظ به الملخص.

تجنب: "مرجع" — جاف جداً؛ لا يوضح أن متابعته تجلب المزيد من السياق. "بوابة (Portal)" — مزخرفة للغاية.

الاستخدام:

"ملف AGENTS.md يزداد ضخامة."

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

قدرة قابلة للتعليم مجمعة كوحدة واحدة — تعليمات وموارد لأداء مهمة واحدة بشكل جيد، تُحفظ في البيئة حتى يقوم مؤشر السياق بسحبها إلى نافذة السياق لتنفيذ المهمة الحالية. وحدة الإفصاح التدريجي في الحزام (harness).

المهارات هي معيار مفتوح، محدد على agentskills.io — تم تطويرها في الأصل بواسطة Anthropic ومنذ ذلك الحين تبنتها معظم الحزم الرئيسية، لذا فإن المهارة المكتوبة مرة واحدة تعمل عبرها جميعاً. التنسيق هو مجلد يحتوي على:

• ملف `SKILL.md` — بيانات تعريفية (اسم ووصف، كحد أدنى) بالإضافة إلى التعليمات نفسها
• اختياريًا، نصوص برمجية يمكن لـ الوكيل تشغيلها
• اختياريًا، قوالب ومواد مرجعية تشير إليها التعليمات

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

هذا يُميز المهارات عن AGENTS.md، الذي يتم تحميله في كل جلسة بغض النظر عن المهمة. تتم قراءة المهارة عندما يظهر نوع معين من العمل — الإصدار، أو إنشاء بنية أساسية لخدمة جديدة، أو كتابة ترحيل (migration) — ويتم تجاهلها في بقية الوقت.

تجنب استخدام: "أداة (tool)" — الأداة هي ما يناديه الوكيل؛ أما المهارة فهي تعليمات يقرؤها.

الاستخدام:

"أين يجب أن أضع دليل النشر (runbook)؟"

"كـ مهارة — يقوم الوكيل بتحميلها فقط عندما تتضمن المهمة عمليات نشر. في AGENTS.md ستستهلك الرموز في كل منعطف (turn) لشيء نستخدمه أسبوعياً."

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

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

يعمل الوكلاء الفرعيون أيضاً في نفس الوقت — يمكن للأصل نشر عدة وكلاء في وقت واحد على قطع عمل مستقلة.

الاستخدام:

"نتائج grep تؤدي إلى تضخيم سياقي."

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

نموذج عمل يتعاون فيه إنسان واحد أو أكثر مع agent أثناء session — حيث تتم المراجعة أو إعادة التوجيه أو التعاون في الوقت الفعلي. يكون الإنسان حاضراً ومشاركاً، وليس مجرد مُحكّم للخطوات الفردية.

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

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

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

البقاء ضمن الحلقة يكلفك انتباهك، وهو المورد النادر. وجزء من التحسن في التعامل مع الوكلاء هو نقل المزيد من العمل بأمان إلى خارج الحلقة — عبر الخطط، والautomated checks، وhuman review في النهاية بدلاً من الإشراف طوال الوقت. يأخذ software factory هذا إلى أبعد من ذلك من خلال بدء الجلسات بناءً على مشغلات، بحيث حتى إطلاق العمل لا يحتاج إليك.

الاستخدام:

"هل أشغل هذا طوال الليل دون مراقبة؟"

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

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

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

بما أنه لا يمكنك إدخال مدخلات أثناء التشغيل، امنحها قبل وبعد بدلاً من ذلك. قبل التشغيل: حل الغموض مقدماً — جلسة استجواب، مواصفات مكتوبة — بحيث يكون هناك فجوات أقل ليملأها الوكيل بمفرده. خلال التشغيل: الفحوصات الآلية والمراجعة الآلية تحل محل الاهتمام الذي لا تقدمه، وتفشل بسرعة فيما يمكن رصده ميكانيكياً. بعد التشغيل: ينتهي التشغيل بشيء قابل للمراجعة — طلب سحب (PR)، وليس تغييرات مُدمجة بالفعل. وضع AFK لا يلغي مراجعة البشر؛ بل يؤجلها كلها حتى النهاية، وهذا هو سبب وجوب أن يكون ما يصل في النهاية جديراً بالمراجعة. هذا هو السبب أيضاً في أهمية AX أكثر في تشغيلات AFK — مع عدم وجود أحد يراقب، تكون البيئة هي الدعم الوحيد الذي يحصل عليه الوكيل.

تجنب: "وكيل في الخلفية" — يركز على الآلة ("تعمل في الخلفية") بدلاً من نمط الإنسان ("المستخدم قد ابتعد"). يسمى AFK بالحقن الذي يهم حقاً: المستخدم لا يشاهد.

الاستخدام:

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

"تجاوز الأذونات؟"

"نعم، نظام ملفات للقراءة فقط، بدون شبكة."

تحقق حتمي يعمل في البيئة — الاختبارات، وفحوصات الأنواع، والتدقيق اللغوي، والبناء، وخطافات ما قبل الالتزام (pre-commit hooks). نجاح/فشل، بلا أحكام. الإشارة التي يمكن لـوكيل التصحيح الذاتي بناءً عليها دون إشراك أي شخص آخر. الاختبار غير المستقر هو تحقق معطل، وليس عدم تحقق؛ الفحوصات الآلية هي حتمية بحكم التصميم.

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

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

تجنب: "حلقة الملاحظات" / "الضغط العكسي" — فكلاهما يدمج الفحوصات مع المراجعة. تجنب: "الاختبار" — الاختبارات هي فحوصات آلية، ولكن ليست كل الفحوصات الآلية اختبارات.

الاستخدام:

"يستمر الوكيل في نشر كود معطل في عمليات تشغيل وضع AFK."

"ما هي الفحوصات الآلية المرتبطة بـصندوق الحماية؟"

"فقط اختبارات الوحدة."

"أضف التحقق من الأنواع والتدقيق اللغوي — سيقوم بالتصحيح الذاتي بناءً عليها قبل وصول طلب السحب (PR) على الإطلاق."

وكيل ](#agent) يراجع عمل وكيل آخر، غالباً باستخدام نموذج مختلف أو موجه نظام مختلف. غير حتمي: فهو يشكل حكماً. يعمل في أي مكان — قبل الدمج في طلب سحب (PR)، أو بعدي على تاريخ الالتزام، أو في منتصف الجلسة كـ وكيل فرعي. يعتبر نموذج اللغة كحكم في التكامل المستمر (CI) مراجعة آلية، وليس فحصاً آلياً؛ فما يفعلة التأكيد يحدد الفئة، وليس المكان الذي يعمل فيه.

إن الفصل عن الوكيل العامل هو ما يجعله يعمل. طلب الوكيل الذي كتب الكود لمراجعة عمله لا يمنحك سوى القليل جداً — فالجلسة ](#session) التي أنتجت الخطأ تحتوي أيضاً على الاستدلال الذي أنتجه، ويقرأ الوكيل استنتاجاته الخاصة كتأكيد. المراجع الذي يتمتع بـ نافذة سياق جديدة ليس لديه أي من هذا التعلق: فهو يرى الفرق بالطريقة التي يراه بها الغريب، وهذا ما تعتمد عليه المراجعة. نموذج مختلف أو موجه نظام خاص بالمراجعة يزيد من شحذ ذلك — نقاط عمياء مختلفة، وموجه نظام محدد بما تهتم به حقاً (الأمان، وعقود واجهات برمجة التطبيقات، والأداء) بدلاً من "البحث عن المشكلات" بشكل غامض.

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

تجنب: "مراجعة الذكاء الاصطناعي" / "مراجعة الوكيل" — غامضة للغاية بحيث لا يمكن تمييزها عن الوكيل العامل نفسه.

الاستخدام:

"نحصل على الكثير من طلبات السحب السيئة من عمليات تشغيل AFK."

"أضف خطوة مراجعة آلية قبل الدمج — نموذج مختلف، وموجه نظام منفصل، ومخصص للتغيرات الأمنية والتعاقدية."

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

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

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

تجنّب: «مراجعة الشيفرة» وحدها؛ فهي ملتبسة بين البشرية والآلية.

الاستخدام:

«راجعت بشريًا مخرجات التشغيل بعيدًا عن لوحة المفاتيح».

«قرأت الفرق أم الملخص فقط؟»

«الفرق. قال الملخص إنه حذف شيفرة ميتة، لكن اتضح أن الدالة تُستدعى من ملف مولّد».

نموذج عمل يتقبل فيه المستخدم كود agent بدون human review. يتم التعامل مع ملف الاختلافات (diff) كصندوق أسود — وما يهم هو ما إذا كان البرنامج يعمل، وليس ما بداخله. قد تستمر Automated review وautomated checks في العمل؛ بينما تتجاهل البرمجة بالحدس (vibe coding) كليهما.

يأتي المصطلح من أندريه كارباتي (Andrej Karpathy)، الذي coined it in early 2025: حيث "تستسلم تماماً للحدس" و"تنسى وجود الكود أصلاً" — تصف ما تريد، وتقبل ما يعود، وتحكم عليه من خلال تشغيله.

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

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

تجنب استخدام:

"البرمجة بالحدس" كمرادف لـ "البرمجة بالذكاء الاصطناعي منخفضة الجودة" — فهذا المصطلح يُسمّي منهجية المراجعة، وليس الكود الناتج.

الاستخدام:

"هل قرأت ما غيره في مسار المصادقة؟"

"برمجته بالحدس — تسجيل الدخول ما زال يعمل، هذا كل ما تحقق منه."

"اقرأ ملف الاختلافات قبل الدفع (push)، فالاعتماد على الحدس في المصادقة هو سبب تسرب كلمات السر إلى السجلات."

الفهم المشترك لما يجري بناؤه بين المستخدم والوكيل، والمنفصل عن أي أصل. وهو مصطلح Brooks (The Design of Design): المحادثة ومستندات التسليم والشيفرة كلها أصول تحاول توثيق مفهوم التصميم أو بلوغه، لكن لا شيء منها هو المفهوم نفسه. وتُلمس جودة مفهوم التصميم من جودة المحادثة التي كوّنته.

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

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

الاستخدام:

«إنه يكتب ما طلبته بالضبط، ومع ذلك فالنتيجة خاطئة».

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

تقنية لتطوير مفهوم تصميم مع وكيل: يقوم الوكيل بمقابلة المستخدم على طريقة سقراط، قراراً تلو الآخر، مقترحاً إجابة موصى بها لكل منها. يبطئ التسرع نحو خطة جاهزة — لا يتم كتابة أي عنصر تسليم (handoff artifact) حتى يستقر المفهوم.

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

إنها تقنية تعتمد على وجود إنسان في الحلقة (human-in-the-loop): إجاباتك هي المدخلات. عندما تعذر الإجابة على سؤال في المحادثة — حيث سيتعين عليك رؤية الشيء — انتقل إلى النماذج الأولية (prototyping).

الاستخدام:

"ذهب مباشرة إلى كتابة المواصفات وأخطأ في منطق الإلغاء."

"استجوبه أولاً — اجعله يسألك عن عمليات الإلغاء الجزئية، والاسترداد، والتوقيت قبل أن يلتزم بأي شيء في المستند. حل المشكلة في المحادثة أرخص من حلها في الشفرة."

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

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

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

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

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

الاستخدام:

"لقد أمضينا نصف ساعة نتجادل حول ما إذا كان المعالج يجب أن يكون صفحة واحدة أو ثلاث خطوات."

"الكلمات لن تحسم الأمر — اجعل الوكيل يصنع نموذجين أوليين لكليهما. سننقر عليهما ونعرف في خمس دقائق."

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

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

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

التداخل يعني أن الاستثمار في DX غالباً ما يحسن AX مجاناً — الأنواع الصارمة، والاختبارات السريعة، والهيكل القابل للتنبؤ تساعد كلياً. التباعد يعني أنه لا يفعل ذلك دائماً: وثيقة تأهيل رائعة تساعد إنساناً لمدة أسبوع ولا تساعد وكيلاً على الإطلاق ما لم تكن قابلة للوصول من AGENTS.md.

الاستخدام:

"تجربة المطورين لدينا جيدة — الموظفون الجدد يصبحون منتجين في غضون أسبوع."

"منتجون لأن شخصاً ما يجلس معهم طوال ذلك الأسبوع. الوكيل لا يحصل على ذلك الأسبوع؛ تحقق من AX بشكل منفصل."

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

تتميز AX الجيدة بثلاثة أبعاد رئيسية:

تتداخل AX وDX — تساعد الفحوصات الجيدة والبنية النظيفة كلا الجمهورين — لكنهما تتباعدان. يتحمل البشر المعرفة القبلية، وبطء التكامل المستمر (CI)، و"اسأل سارة عن وحدة الفوترة"؛ بينما لا يستطيع الوكلاء ذلك. لا يستفيد الوكلاء من تلميحات أدوات واجهة برمجة التطبيقات (IDE) أو لوحات المعلومات الجميلة؛ إنهم بحاجة إلى الاخفاقات كنص في نتيجة الأداة. يمكن أن تحتوي قاعدة التعليمات البرمجية على DX جيدة وAX ضعيفة.

تجنب: معاملة AX مرادفًا لـ DX — يحتاج الجمهور إلى استثمارات مختلفة.

الاستخدام:

"يكتب الوكيل تعليمات برمجية رائعة في مستودع واجهة برمجة التطبيقات (API) وقمامة في الواجهة الأمامية."

"يحتوي مستودع واجهة برمجة التطبيقات (API) على أنواع صارمة ومجموعة اختبارات سريعة؛ بينما لا تحتوي الواجهة الأمامية على أي منهما وأربعين مهارة محملة دائمًا. هذه فجوة AX، وليست مشكلة نموذج."

نظام عمل تبدأ فيه جلسات الوكيل بواسطة مشغلات (triggers) — مثل إنشاء مشكلة (issue)، أو جدول زمني، أو فشل في التكامل المستمر (CI)، أو انتهاء جلسة أخرى — بدلاً من التدخل البشري، بحيث يتم تشغيل المزيد من العمل بشكل مستقل (AFK) ويُصرف انتباه الإنسان على القرارات التي تتطلب وجود إنسان في الحلقة (human-in-the-loop) والتي تظل قائمة.

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

المشغلات الشائعة والجلسات التي تبدأها:

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

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

الاستخدام:

"من قام بإصلاح جميع مخالفات `no-floating-promises`؟"

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

قاعدة بيانات برمجية، أو جزء منها، حيث يكتب مصنع البرمجيات الكود دون أن يقرأه أي بشر. لا يوجد مراجعة بشرية. لا يزال بإمكان البشر كتابة المشكلات التي تبدأ العمل. لكن لا أحد يقرأ الكود الناتج. يأتي الاسم من مصنع "Lights-out" التي تصنع الأشياء دون وجود عمال على أرضية المصنع.

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

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

الفحوصات الآلية والمراجعة الآلية هما البوابتان الوحيدتان. إذا لم تجد مشكلة، تدخل المشكلة في الكود.

تجنب: تسمية قاعدة الكود بأنها "مظلمة" فقط لأن مصنعها يعمل دون أن يراقبها أحد. إذا كانت جلسات الوكيل تعمل بدون حضور (AFK) وقام بشر بمراجعة طلبات السحب الخاصة بهم، فهذا مصنع برمجيات. وليس مصنعاً مظلماً.

الاستخدام:

"من قام بتغيير منطق إعادة المحاولة في خدمة الفوترة؟ لا أحد في الفريق يتذكر ذلك."

"خدمة الفوترة هي مصنع مظلم. يقوم الوكلاء بدمج جميع التغييرات التي تجتاز التكامل المستمر (CI). لم يقرأ أحد هذا التغيير."