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

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

لماذا يعتبر الخلط بينهما هو الخلل الفعلي، وليس مجرد تفصيل

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

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

كيف تبدو كل وظيفة فعليًا في العمل اليومي

إذا كنت تحاول معرفة أيًا من هاتين الوظيفتين تقوم بها بالفعل، أو أيهما تريد أن تتجه نحو بنائها، فإن العمل اليومي يبدو مختلفًا بما يكفي للتمييز بينهما:

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

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

يمكنك أن ترى الصناعة تبدأ بفصل هذه الاهتمامات بنيويًا، وليس مفاهيميًا فقط. شرح Lenny's Newsletter لبناء أداة تصحيح أخطاء على Claude Agent SDK يعامل الأذونات، ومحوّلات الأدوات، و"الإطار" المحيط بها كسطح هندسي خاص بها منفصل عن الصياغة داخله - نفس الحدس، مطبق على فاصل مختلف. وميزات "الوكلاء المُدارين" الأحدث في Gemini API من Google - التنفيذ في الخلفية، وتجديد بيانات الاعتماد عبر التفاعلات - هي فعليًا اعتراف من مزوّد المنصة بأن الحالة المستمرة عبر الجلسات أصبحت الآن بنية تحتية يجب تصميمها، وليست أثرًا جانبيًا لنافذة سياق طويلة بما فيه الكفاية. يجب أن يمتلك أحدهم هذا التصميم. حاليًا، في كثير من الفرق، لا أحد يفعل ذلك صراحةً.

لماذا يهم هذا مسماك الوظيفي، وليس فقط شفرتك البرمجية

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

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

تحذير

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