«مهندس پرامپت» هیچوقت عنوان شغلی دقیقی نبود، اما برای مدتی نیازی هم به دقیقبودن نداشت. اگر کل کارتان گرفتن یک پاسخ خوب از یک فراخوانی استنتاج بود، یک مجموعه مهارت برایش کافی بود: دستورالعمل را خوب بنویسید، چند مثال بدهید، شاید کمی متن بازیابیشده اضافه کنید، تمام. آن مجموعه مهارت هنوز هم اهمیت دارد. اما دیگر چیزی را که «ساختن یک ایجنت» در میانهی سال ۲۰۲۶ معنا میدهد پوشش نمیدهد، و این شکاف خودش را در قالب یک الگوی شکست مشخص و قابلشناسایی نشان میدهد: ایجنتهایی که در دمو عالی کار میکنند و بعد بهآرامی افت میکنند، با خودشان تناقض پیدا میکنند، یا چیزی را که کاربر دو نشست پیش گفته بود فراموش میکنند.
مقالهای که اخیراً از Machine Learning Mastery منتشر شده مستقیماً این شکاف را نام میبرد، و ارزش دارد کمی رویش مکث کنیم چون دقیقاً منطبق است بر دو شغل متفاوتی که واقعاً ممکن است برای انجامشان استخدام شوید. مهندسی زمینه (context engineering) چیزی است که درون یک فراخوانی استنتاج رخ میدهد: تصمیمگیری دربارهی اینکه چه چیزی وارد پنجرهی زمینه میشود، از نظر ساختاری کجا قرار میگیرد، و چه چیزی فشرده یا حذف میشود تا مدل در توکنهای نامربوط غرق نشود. مهندسی حافظه (memory engineering) مسئلهی دیگری است که تنها در گسترهی چند فراخوانی وجود دارد: چه چیزی بعد از پایان یک نشست ثبت میشود، کجا ذخیره میشود، دفعهی بعد چگونه بازیابی میشود، و چگونه نگهداری میشود (بهروزرسانی، حذف موارد تکراری، منقضیکردن) تا فاسد نشود. طبق آن مقاله، شکستهایی که در گردشکارهای ایجنتی طولانی و چندنشستی رخ میدهند اغلب ریشه در خلط این دو کار دارند، یا در نادیدهگرفتن یکی از آنها — بهویژه در چیزی که آنها آن را «مرز بازیابی» مینامند، یعنی لحظهای که یک ایجنت باید تصمیم بگیرد آیا چیزی که به آن نیاز دارد پیشرویش هست یا باید از حافظهی ذخیرهسازی واکشی شود.
چرا خلط این دو، خودِ اشکال است، نه یک جزئیات فرعی
به این فکر کنید که هر رشته دقیقاً در پی بهینهسازی چه چیزی است. مهندسی زمینه در پی بهینهسازی یک پنجرهی مشخص، محدود و یکبارمصرف است — قرار دادن درستترین تکهی اطلاعات پیشروی مدل، همین حالا، برای همین یک تبادل، و بعد دورریختن بقیه. مهندسی حافظه در پی بهینهسازی یک مخزن پایدار است که باید در طول چند نشست دوام بیاورد، با ورود اطلاعات جدید سازگار بماند، و به سؤالی بسیار سختتر پاسخ دهد: نه «چه چیزی به این پرامپت مربوط است» بلکه «اصلاً چه چیزی ارزش نگهداشتن دارد، و برای چه مدت».
اینها مسائل طراحی متفاوتی هستند با الگوهای شکست متفاوت. اشتباه در مهندسی زمینه یک پاسخ را بدتر میکند. اشتباه در مهندسی حافظه انباشته میشود — نوشتههای نادرست روی هم جمع میشوند، حقایق کهنه طوری بازیابی میشوند که انگار همچنان معتبرند، و هیچکس متوجه نمیشود تا وقتی که ایجنت با اطمینان کامل چیزی را تکرار کند که سه نشست پیش اصلاح شده بود. اگر یک نفر (یا یک قالب پرامپت) بیآنکه تفاوتی میان این دو کار قائل شود در سکوت هر دو را انجام دهد، لایهی حافظه تمایل دارد عادتهای مهندسی زمینه را به ارث ببرد که نباید: پر کردن بیشازحد فضای ذخیرهسازی همانطور که پنجره را پر میکنید، یا رفتار با بازیابی بهعنوان مسئلهی رتبهبندی ارتباط در حالی که در واقع مسئلهی گردآوری و نگهداری است. این همان خلطی است که آن مقالهی پژوهشی به آن اشاره میکند، و با چیزی همخوانی دارد که کارورزان پیشتر بهصورت تجربی توصیف کردهاند: ایجنتهایی که در یک نشست چشمگیرند و تا نشست پنجم غیرقابلاعتماد میشوند.
هر کدام از این دو کار در عمل روزانه چه شکلی دارند
اگر میخواهید بفهمید کدامیک از اینها را همین حالا انجام میدهید، یا به سمت کدامیک میخواهید حرکت کنید، کار روزانهشان آنقدر متفاوت است که بشود تشخیصشان داد:
مهندسی زمینه، در عمل: تصمیمگیری دربارهی اینکه کدام زیرمجموعه از اطلاعات موجود (اسناد، خروجی ابزارها، نوبتهای قبلی) واقعاً به این فراخوانی تعلق دارد؛ انتخاب اینکه در کجای پرامپت قرار بگیرد، چون جایگاه بر میزان وزنی که مدل به آن میدهد اثر میگذارد؛ نوشتن مراحل فشردهسازی یا خلاصهسازی تا یک ردِ ابزار طولانی کل بودجه را نبلعد؛ و تنظیم دقیق این موارد برای هر وظیفه، چون یک ایجنت اشکالزدا و یک ایجنت نویسنده حتی روی یک مدل زیرین یکسان، شکل زمینهی متفاوتی میخواهند.
مهندسی حافظه، در عمل: تعریف یک سیاست نوشتن (چه چیزی بعد از یک نشست ارزش ماندگارشدن دارد — نه همهچیز)؛ انتخاب یک لایهی ذخیرهسازی (یک پایگاه برداری، یک پایگاهدادهی ساختیافته، فایلهای ساده، یا ترکیبی از اینها) و صادقبودن دربارهی بدهبستانهای هرکدام؛ ساختن استراتژی بازیابی که تعیین میکند چه چیزی و چه زمانی بازمیگردد؛ و نگهداری مستمر — هرسکردن، ادغام حقایق تکراری، و مدیریت تناقضها وقتی کاربر نظرش عوض میشود. آن بخش آخر، یعنی نگهداری، همان بخشی است که مردم بیشتر از همه نادیدهاش میگیرند، چون تا وقتی ایجنت هفتهها اجرا نشده باشد قابلمشاهده نیست.
میشود دید که این صنعت دارد این دو دغدغه را نه فقط بهصورت مفهومی، بلکه بهصورت ساختاری از هم جدا میکند. مرور گامبهگام Lenny's Newsletter از ساختن یک ابزار اشکالزدایی روی Claude Agent SDK، مجوزها، آداپتورهای ابزار، و «هارنس» پیرامونی را بهعنوان سطح مهندسی مستقلی از پرامپتنویسی درون آن در نظر میگیرد — همان غریزه، اما در درزی متفاوت بهکار رفته. و ویژگیهای جدیدتر «Managed Agents» در Gemini API گوگل — اجرای پسزمینه، تازهسازی اعتبارنامه در طول تعاملات — عملاً پذیرفتن این نکته توسط فروشندهی پلتفرم است که وضعیت پایدار در طول نشستها اکنون زیرساخت است و باید طراحی شود، نه محصول جانبی یک پنجرهی زمینهی بهاندازهی کافی بزرگ. کسی باید مالک این طراحی باشد. در حال حاضر، در بسیاری از تیمها، صراحتاً هیچکس این نقش را ندارد.
چرا این موضوع نه فقط برای کدتان، بلکه برای عنوان شغلیتان هم اهمیت دارد
اگر در ابتدای مسیر شغلی یا در میانهی آن هستید و «مهندس پرامپت» یا «مهندس هوش مصنوعی» روی رزومهتان نوشته شده، ارزش دارد از خودتان بپرسید کدامیک از این دو شغل را واقعاً میتوانید با شواهد نشان دهید که انجام دادهاید — چون نقشهای عامگرای ایجنت هوش مصنوعی دارند شروع میکنند به تفکیکشدن به نقشهای خاصتر، همانطور که «webmaster» سرانجام به فرانتاند، بکاند و DevOps تقسیم شد. این یک احتیاط است، نه یک تیتر: تا امروز دادهی استخدامی محکمی ندیدهام که «مهندس حافظه» را بهعنوان یک عنوان مستقل تأیید کند، پس این را برداشتی از جهتی که کار به آن سمت میرود بدانید، نه ادعایی مبنی بر اینکه سایتهای کاریابی همین حالا اینطور دستهبندی شدهاند. اما فشار زیربنایی واقعی است و قابل ردیابی تا همان مقالهای که پیشتر اشاره شد: تیمهای ایجنت به یک شکست مشخص و قابلنامگذاری برخوردهاند (افت عملکرد در چند نشست) که علتی مشخص و قابلنامگذاری دارد (خلط دو رشته)، و این ترکیب معمولاً همان چیزی است که یک نقش مبهم را به دو نقش شفاف تبدیل میکند.
حرکت عملی این نیست که برای خودتان عنوانی اختراع کنید. این است که بتوانید بهطور مشخص پاسخ دهید کدام مسئله را واقعاً حل کردهاید. آیا چیزی را ساخته و عرضه کردهاید که در آن یک سیاست نوشتن طراحی کردهاید — قاعدهای برای اینکه یک ایجنت چه چیزی را به حافظه میسپارد و چه چیزی را دور میریزد؟ آیا یک شکست در مرز بازیابی را اشکالزدایی کردهاید، جایی که یک ایجنت به چیزی از حافظهی ذخیرهسازی نیاز داشت و یا آن را واکشی نکرد یا نسخهی اشتباهش را واکشی کرد؟ اینها ادعاهایی قابلبررسیاند که میتوانید در یک مصاحبه مطرح کنید، با پشتوانهی یک مخزن کد یا یک گزارش پس از رخداد، و چیزی میگویند که یک «من پرامپتهای خوب مینویسم» عمومی نمیگوید: اینکه شما تفاوت میان بهترکردن یک پاسخ و قابلاعتماد نگهداشتن یک ایجنت در طول زمان را میفهمید.
یک هشدار
صرفاً به این دلیل که یکبار یک پایگاهدادهی برداری به یک پروژه اضافه کردهاید، خودتان را «مهندس حافظه» ننامید. رشتهای که این پژوهش به آن اشاره میکند نیمهی بیجلوهاش را هم شامل میشود — نگهداری، انقضا، مدیریت تناقض — و این همان نیمهای است که واقعاً از الگوی شکست توصیفشده در بالا جلوگیری میکند. اگر نمونهکار شما سیستمی است که در حافظه مینویسد اما هرگز چیزی هرس یا اصلاح نمیشود، شما فقط نیمی از کار یک مهندس حافظه را انجام دادهاید، و مسئلهی شکستخوردن بعد از نشست سوم همچنان در نیمهی دیگر منتظرتان است.