فرض کنید دو نفر دقیقاً از یک مدل هوش مصنوعی استفاده میکنند. هر دو یک سؤال مشابه می‌پرسند، اما یکی پاسخی دقیق، مرتبط و کاربردی دریافت میکند و دیگری با خروجی عمومی یا حتی اشتباه روبه‌رو میشود.
تفاوت همیشه در مدل نیست.
گاهی تفاوت اصلی در اطلاعاتی است که قبل از پاسخ در اختیار مدل قرار گرفته است.
مدل چه چیزی درباره کاربر می‌داند؟ چه اسنادی را می‌بیند؟ تاریخچه مکالمه چقدر است؟ نتیجه ابزارهای قبلی چیست؟ چه قوانینی باید رعایت شود؟ کدام اطلاعات قدیمی هستند؟ چه چیزی باید از حافظه بازیابی شود و چه چیزی اصلاً نباید وارد Context شود؟
مدیریت همین مجموعه اطلاعات، ما را به یکی از مفاهیم مهم نسل جدید سیستم‌های هوش مصنوعی می‌رساند: Context Engineering یا مهندسی کانتکست.
Anthropic این مفهوم را ادامه طبیعی Prompt Engineering می‌داند. در Prompt Engineering تمرکز اصلی روی نحوه نوشتن دستور است، اما Context Engineering سؤال بزرگتری مطرح میکند:
در لحظه‌ای که مدل قرار است تصمیم بگیرد یا پاسخ تولید کند، دقیقاً چه اطلاعاتی باید در اختیارش قرار گیرد؟
این موضوع مخصوصاً با رشد AI Agentها اهمیت زیادی پیدا کرده است؛ زیرا یک Agent ممکن است در طول یک کار ده‌ها بار تصمیم بگیرد، Tool اجرا کند، اطلاعات جدید به دست آورد و وضعیتش تغییر کند. مدیریت این حجم اطلاعات دیگر با نوشتن یک Prompt خوب حل نمی‌شود.
در این مقاله بررسی می‌کنیم Context Engineering چیست، چه تفاوتی با Prompt Engineering دارد، Context Window چگونه کار میکند، RAG و Memory چه نقشی دارند و چگونه می‌توان زمینه مناسب را برای یک مدل یا AI Agent طراحی کرد.
Context در مدل‌های زبانی چیست؟
برای فهم Context Engineering ابتدا باید بدانیم Context چیست.
به زبان ساده، Context مجموعه اطلاعاتی است که مدل هنگام تولید پاسخ در اختیار دارد.
این اطلاعات میتواند شامل System Prompt، پیام فعلی کاربر، تاریخچه مکالمه، فایل‌ها و اسناد، نتایج جست‌وجو، خروجی Toolها، اطلاعات بازیابی‌شده از دیتابیس، Memory و حتی وضعیت فعلی یک Agent باشد.
مدل بر اساس همین اطلاعات تصمیم میگیرد چه پاسخی تولید کند.
اگر اطلاعات مهم در Context نباشد، مدل نمی‌تواند به شکل قابل اعتماد از آن استفاده کند.
و اگر Context پر از اطلاعات نامرتبط، قدیمی یا متناقض باشد، حتی یک مدل قوی هم ممکن است تصمیم ضعیف‌تری بگیرد.
بنابراین مسئله Context Engineering فقط این نیست که «اطلاعات بیشتری به مدل بدهیم». مسئله این است که:
اطلاعات درست، در زمان درست و به شکل درست در اختیار مدل قرار گیرد.
Context Window چیست؟
هر مدل زبانی مقدار مشخصی اطلاعات را میتواند در یک تعامل پردازش کند. به این محدوده Context Window گفته میشود.
می‌توان Context Window را تا حدی شبیه میز کار یک انسان تصور کرد.
شاید هزاران سند در آرشیو شرکت وجود داشته باشد، اما برای تصمیمی که همین حالا می‌خواهیم بگیریم فقط تعدادی از آن‌ها باید روی میز قرار بگیرند.
مدل‌های جدید Context Windowهای بسیار بزرگی دارند. برای مثال برخی مدل‌های Gemini قادرند بیش از یک میلیون Token را در Context دریافت کنند. Google این قابلیت را برای بررسی حجم بزرگی از کد، اسناد، ویدئو یا مکالمات طولانی مفید می‌داند.
اما یک اشتباه رایج این است که تصور کنیم:
Context Window بزرگ‌تر = هرچه اطلاعات بیشتری بفرستیم بهتر است.
در عمل همیشه چنین نیست.
چرا نباید همه اطلاعات را داخل Context بریزیم؟
فرض کنید مدیر یک شرکت از AI می‌پرسد:
چرا فروش محصول A این ماه کاهش پیدا کرده است؟
شرکت پنج سال اطلاعات فروش، هزاران فاکتور، اطلاعات انبار، کمپین‌های بازاریابی، تماس‌های CRM و صدها گزارش مدیریتی دارد.
می‌توانیم همه اطلاعات را وارد Context کنیم؟
حتی اگر از نظر تعداد Token ممکن باشد، الزاماً تصمیم خوبی نیست.
Anthropic در تجربه عملی ساخت Agentها به پدیده‌ای اشاره میکند که می‌توان آن را Context Rot یا افت کیفیت در Contextهای بسیار بزرگ دانست. با افزایش اطلاعات، مدل ممکن است تمرکز کمتری روی بخشهای مهم داشته باشد یا بازیابی دقیق اطلاعات سخت‌تر شود. به همین دلیل Anthropic Context را یک منبع محدود با «بودجه توجه» در نظر میگیرد.
یعنی مهندس Context به‌جای پرسیدن «چقدر اطلاعات می‌توانم داخل مدل بفرستم؟» باید بپرسد:
کمترین مجموعه اطلاعاتی که برای گرفتن تصمیم درست لازم است چیست؟
این تغییر نگاه اساس Context Engineering است.
تفاوت Prompt Engineering و Context Engineering چیست؟
Prompt Engineering بیشتر روی دستور تمرکز دارد. مثلاً:
این گزارش را تحلیل کن و سه مشکل اصلی را پیدا کن.
در Prompt Engineering بررسی می‌کنیم که آیا دستور واضح است، خروجی موردنظر مشخص شده و محدودیت‌های لازم تعریف شده‌اند یا نه.
اما Context Engineering سؤال‌های دیگری اضافه میکند:
بنابراین می‌توان تفاوت را این‌گونه خلاصه کرد:
Prompt Engineering
می‌پرسد: چه دستوری به مدل بدهیم؟
Context Engineering
می‌پرسد: مدل هنگام اجرای این دستور چه چیزهایی باید بداند؟
در سیستم‌های ساده، Prompt ممکن است بخش بزرگی از Context باشد. اما در Agentهای چندمرحله‌ای، Prompt فقط یکی از اجزای Context است. Anthropic دقیقاً به همین دلیل Context Engineering را تکامل طبیعی Prompt Engineering در سیستم‌های Agentic معرفی میکند.
مدل عملی تنسوا: پنج لایه Context
برای اینکه موضوع کاربردی‌تر شود، می‌توان Context یک سیستم هوش مصنوعی را در پنج لایه تصور کرد:
این یک چارچوب ساده برای تحلیل Context است.
هدف
مدل باید بداند قرار است به چه نتیجه‌ای برسد. برای مثال: «هدف تشخیص علت احتمالی افت فروش محصول A است.» این بسیار بهتر از درخواست مبهم «داده‌ها را تحلیل کن» است.
قوانین
مدل باید محدودیت‌های کار را بداند. مثلاً: «فقط براساس داده موجود نتیجه‌گیری کن و اگر شواهد کافی وجود ندارد علت قطعی اعلام نکن.» این بخش رفتار مدل را کنترل میکند.
شواهد
اطلاعات واقعی موردنیاز برای تصمیم وارد این لایه میشوند؛ مثلاً فروش سه ماه اخیر، موجودی محصول و اطلاعات کمپین. اما قرار نیست کل دیتابیس شرکت وارد Context شود.
وضعیت
در Agentهای چندمرحله‌ای باید بدانیم تا این لحظه چه اتفاقی افتاده است. مثلاً: «افت فروش شناسایی شده، موجودی بررسی شده و مشکلی وجود ندارد؛ مرحله بعد بررسی کانال‌های تبلیغاتی است.» این State به Agent کمک میکند کار قبلی را تکرار نکند.
ابزارها
مدل باید بداند چه قابلیت‌هایی در اختیار دارد؛ مثلاً get_sales، check_inventory و get_campaign_data. اما حتی در این بخش نیز هرچه Tools بیشتری بدون ضرورت به Agent بدهیم الزاماً بهتر نیست.
Context خوب باید فقط ابزارهایی را در دسترس قرار دهد که احتمال استفاده از آن‌ها در Task فعلی منطقی است.
این پنج لایه یک سؤال ساده ایجاد میکنند:
آیا چیزی که وارد Context کرده‌ایم به هدف، قانون، شواهد، وضعیت یا ابزار موردنیاز مدل کمک میکند؟
اگر نه، شاید اصلاً نیازی نیست آنجا باشد.
Context Engineering را در مسیر ساخت Agent تمرین کن
در بوت‌کمپ مهندسی ایجنت تنسوا، طراحی Context، Tool Calling و Evaluation را روی پروژه‌های واقعی یاد می‌گیری. برای تمرین Prompt هم می‌توانی از کتابخانه پرامپت استفاده کنی.
یک مثال واقعی از Context Engineering
فرض کنید یک Agent برای تحلیل فروش داریم. کاربر می‌پرسد: «چرا فروش این ماه کم شده؟»
یک طراحی ضعیف ممکن است تاریخچه کامل مکالمات، تمام محصولات، فروش پنج سال گذشته، فایل‌های CRM، موجودی همه انبارها و تمام ابزارهای سازمان را یکجا وارد Context کند.
مدل اطلاعات زیادی دارد، اما Signal اصلی میان Noise گم میشود.
یک Context Engineer میتواند مسیر متفاوتی طراحی کند.
- 1ابتدا Agent اطلاعات فروش این ماه و دوره مقایسه را میگیرد.
- 2متوجه میشود بیشترین افت مربوط به محصول A است. حالا فقط اطلاعات مرتبط با محصول A وارد مرحله بعد میشود.
- 3Agent موجودی آن را بررسی میکند. اگر موجودی طبیعی بود، سراغ کمپین‌های مرتبط می‌رود.
- 4اگر داده کمپین افت Traffic را نشان داد، همان Evidence وارد مرحله تحلیل نهایی میشود.
یعنی Context به شکل پویا و مرحله‌به‌مرحله ساخته شده است.
Anthropic این الگو را Just-in-Time Context می‌نامد: به‌جای بارگذاری تمام اطلاعات در ابتدای کار، Agent شناسه‌ها، مسیر فایل‌ها یا منابع را نگه می‌دارد و زمانی که به داده‌ای نیاز دارد آن را بازیابی میکند.
این رویکرد در Agentهای واقعی بسیار مهم است.
RAG چه ارتباطی با Context Engineering دارد؟
RAG یا Retrieval-Augmented Generation یکی از شناخته‌شده‌ترین روشهای ساخت Context است.
فرض کنید یک شرکت هزار سند داخلی دارد و کاربر سؤالی درباره سیاست مرخصی می‌پرسد. به‌جای قرار دادن هزار سند در Prompt، سیستم ابتدا بخشهای مرتبط را پیدا میکند و فقط همان اطلاعات را وارد Context میکند.
این همان ایده پایه RAG است. اما Context Engineering از RAG گسترده‌تر است.
RAG می‌پرسد
چه اطلاعاتی را بازیابی کنیم؟
Context Engineering علاوه بر آن می‌پرسد
- چه زمانی بازیابی کنیم؟
- چقدر اطلاعات بازیابی کنیم؟
- چگونه آن را خلاصه کنیم؟
- آیا نتیجه Tool قبلی هنوز لازم است؟
- کدام Memory باید اضافه شود؟
- چه چیزی باید حذف شود؟
یک Survey گسترده در سال ۲۰۲۵ که بیش از ۱۴۰۰ پژوهش را بررسی کرده بود، Context Engineering را حوزه‌ای شامل Context Retrieval، Generation، Processing و Management معرفی کرد و RAG، Memory، Tool-integrated Reasoning و Multi-Agent Systems را از پیاده‌سازی‌های مهم آن دانست.
پس RAG را می‌توان یکی از ابزارهای مهم Context Engineering دانست، نه تمام آن.
Memory با Context چه تفاوتی دارد؟
این دو اصطلاح گاهی به جای هم استفاده میشوند، اما یکسان نیستند.
Memory
اطلاعاتی است که سیستم میتواند برای استفاده بعدی نگه دارد.
Context
اطلاعاتی است که همین حالا در اختیار مدل قرار گرفته است.
فرض کنید سیستم می‌داند کاربر مدیر فروش یک شرکت است. این اطلاعات میتواند در Memory ذخیره شده باشد. اما فقط زمانی وارد Context میشود که برای پاسخ فعلی مفید باشد.
Memory شبیه انبار اطلاعات است و Context شبیه میز کار فعلی.
Context Engineering تصمیم میگیرد از انبار چه چیزی را روی میز بیاورد. همین تفاوت ساده در Agentهای طولانی‌مدت بسیار مهم است.
Compaction؛ وقتی Context بیش از حد بزرگ میشود
فرض کنید یک Coding Agent چند ساعت روی پروژه کار کرده است. ده‌ها فایل دیده، تست اجرا کرده، خطا گرفته و کد را تغییر داده است.
اگر همه این تعاملات برای همیشه در Context باقی بمانند، حجم اطلاعات به‌مرور زیاد میشود. یکی از راهکارهای عملی Compaction است.
در Compaction، اطلاعات مهم مکالمه یا فعالیت قبلی خلاصه میشود و Agent با نسخه فشرده‌شده وضعیت ادامه می‌دهد.
مثلاً به‌جای نگه داشتن ۳۰ هزار Token از تاریخچه Debugging، سیستم میتواند وضعیت را به چند نکته مهم تبدیل کند:
مشکل Authentication حل شد، فایل X تغییر کرد، تست Y هنوز Fail است و مرحله بعد بررسی Middleware است.
Anthropic، Compaction، یادداشت‌برداری ساختاریافته و استفاده از Sub-agentها را سه الگوی مهم برای مدیریت Taskهای طولانی معرفی میکند.
OpenAI نیز در معماری Agentهای جدید خود Context Management و Compaction را از مسائل عملی Agentهای طولانی‌مدت می‌داند. در Agents API جدید که سپتامبر ۲۰۲۶ معرفی شد، مدیریت Context، ابزارها و Sub-agentها بخشی از زیرساخت اجرای Agentهای طولانی است.
چرا فایل‌ها بهتر از Context خام هستند؟
یک الگوی جالب در Agentهای جدید این است که همه‌چیز را داخل Prompt نگه نداریم.
فرض کنید Agent روی یک فایل Excel با ۲۰۰ هزار ردیف کار میکند. قرار دادن تمام داده در Context نه‌تنها گران است بلکه احتمالاً ضروری هم نیست.
راه بهتر این است که فایل در محیط Agent باقی بماند و Agent با ابزار مناسب بخش موردنیاز را Query یا پردازش کند.
OpenAI در طراحی محیط کامپیوتری برای Agentها دقیقاً به این مسئله اشاره کرده است: به‌جای Paste کردن جدول‌های بزرگ در Prompt، Agent میتواند داده را در فایل یا محیط نگه دارد و هنگام نیاز به آن دسترسی پیدا کند.
هر اطلاعاتی که Agent میتواند در صورت نیاز دوباره پیدا کند، لازم نیست دائماً داخل ذهن فعال آن باشد.
این دقیقاً شبیه انسان است. ما محتوای تمام فایل‌های لپ‌تاپ خود را حفظ نمی‌کنیم؛ فقط می‌دانیم اطلاعات کجاست و هنگام نیاز آن را باز می‌کنیم.
Long Context همیشه دشمن RAG نیست
با رشد Context Window بعضی‌ها تصور کردند RAG دیگر لازم نیست.
اگر مدل یک میلیون Token می‌پذیرد، چرا کل اسناد را به آن ندهیم؟
واقعیت کمی پیچیده‌تر است.
Long Context برای مواردی مانند بررسی یک Codebase، تحلیل مجموعه اسناد یا ویدئوهای طولانی بسیار قدرتمند است. Google نیز کاربردهای گسترده‌ای برای Contextهای میلیون‌توکنی ارائه میکند.
اما حجم Context تنها مسئله نیست. هزینه، Latency، تازگی داده، Relevance و تمرکز مدل هم اهمیت دارند.
بنابراین انتخاب بین Long Context، RAG و Retrieval پویا بیشتر یک تصمیم معماری است تا رقابت «کدام فناوری برنده شد».
در بسیاری از سیستم‌های خوب، هر سه روش کنار هم استفاده میشوند.
Context Pollution؛ مشکل پنهان Agentها
فرض کنید Agent در مرحله اول یک فرض اشتباه ساخته است:
احتمالاً محصول به دلیل کمبود موجودی فروش نرفته.
بعداً مشخص میشود موجودی کافی بوده است.
اگر آن فرض اشتباه همچنان در Context باقی بماند، ممکن است روی تصمیم‌های بعدی اثر بگذارد. این نمونه‌ای از Context Pollution است.
داده‌ای که دیگر برای تصمیم فعلی معتبر نیست.
نتیجه‌ای که بعداً باطل شده ولی هنوز در Context مانده.
پاسخ ابزاری که خطا داشته یا منقضی شده است.
تاریخچه یا اسنادی که Signal اصلی را پنهان میکنند.
بنابراین Context Engineering فقط اضافه کردن اطلاعات نیست. گاهی مهم‌ترین کار حذف کردن اطلاعات است.
این یکی از تفاوت‌های مهم سیستم‌های آزمایشی و Agentهای Production است.
یک تست ساده برای بررسی Context
قبل از ارسال Context بزرگ به مدل، می‌توانیم برای هر بخش چهار سؤال بپرسیم:
۱. لازم است؟
آیا این اطلاعات برای تصمیم فعلی لازم است؟
۲. هنوز معتبر است؟
آیا اطلاعات هنوز معتبر و به‌روز است؟
۳. می‌توان خلاصه کرد؟
آیا می‌توان آن را خلاصه کرد بدون اینکه Signal مهم از بین برود؟
۴. دوباره پیدا میشود؟
آیا مدل میتواند در صورت نیاز خودش دوباره این اطلاعات را بازیابی کند؟
اگر پاسخ سؤال اول «نه» باشد، احتمالاً نباید اطلاعات را وارد Context کنیم.
اگر پاسخ سؤال چهارم «بله» باشد، شاید Just-in-Time Retrieval بهتر باشد.
این یک تمرین ساده اما بسیار مؤثر برای طراحی Agent است.
آیا Context Engineering فقط برای برنامه‌نویسان است؟
خیر.
حتی هنگام استفاده معمولی از ChatGPT نیز می‌توان Context Engineering را به شکل ساده انجام داد.
فرض کنید می‌خواهید AI یک پروپوزال فروش بنویسد. به‌جای گفتن:
یک پروپوزال فروش بنویس.
می‌توانید اطلاعات موردنیاز را انتخاب کنید:
این در واقع شکل ساده‌ای از Context Engineering است.
تفاوت زمانی جدی‌تر میشود که سیستم خودش مسئول جمع‌آوری این اطلاعات باشد. اینجاست که وارد طراحی RAG، Memory، Tools و Agent می‌شویم.
آینده Prompt Engineering یا Context Engineering؟
احتمالاً این دو جای یکدیگر را نمی‌گیرند.
Prompt Engineering همچنان برای طراحی Instructions مهم است. اما هرچه سیستم‌های AI از پاسخ‌های تک‌مرحله‌ای به سمت Agentهای چندمرحله‌ای حرکت کنند، نقش Context Engineering بزرگ‌تر میشود.
Agent ممکن است ده‌ها Tool Call انجام دهد، ساعت‌ها کار کند، فایل ایجاد کند، Sub-agent داشته باشد و اطلاعات جدید جمع‌آوری کند.
در چنین سیستمی نمی‌توان همه مشکل‌ها را با «Prompt بهتر» حل کرد. باید کل جریان اطلاعات طراحی شود.
این همان تغییری است که Anthropic آن را حرکت از تمرکز روی Prompt به سمت مدیریت کل Context State توصیف میکند.
جمع‌بندی
Context Engineering یا مهندسی کانتکست هنر و مهندسی آماده‌سازی اطلاعات مناسب برای مدل‌های زبانی است.
هدف آن پر کردن Context Window نیست.
هدف این است که مدل در هر لحظه کمترین حجم اطلاعات با بیشترین Signal را در اختیار داشته باشد.
Prompt، تاریخچه مکالمه، RAG، Memory، Tool Output، State و اسناد همگی می‌توانند بخشی از Context باشند.
در سیستم‌های ساده، کاربر خودش بخش زیادی از Context را می‌سازد. اما در AI Agentهای حرفهای، سیستم باید به‌صورت پویا تصمیم بگیرد چه چیزی را بازیابی کند، چه چیزی را خلاصه کند، چه چیزی را نگه دارد و چه چیزی را کنار بگذارد.
به همین دلیل Context Engineering را می‌توان یکی از مهارت‌های مهم نسل جدید AI Engineering و Agent Engineering دانست.
اگر بخواهیم کل مقاله را در یک اصل خلاصه کنیم:
مدل همیشه به اطلاعات بیشتر نیاز ندارد؛ به اطلاعات مرتبط‌تر نیاز دارد.
و شاید مهارت واقعی Context Engineer دقیقاً همین باشد: بداند چه چیزی باید وارد ذهن فعال مدل شود، چه زمانی وارد شود و چه زمانی از آن خارج شود.
سوالات متداول درباره Context Engineering
Context Engineering چیست؟+
Context Engineering مجموعه روشهایی برای انتخاب، سازماندهی، بازیابی، فشردهسازی و مدیریت اطلاعاتی است که هنگام تصمیمگیری یا تولید پاسخ در اختیار مدل زبانی قرار میگیرد.
تفاوت Context Engineering و Prompt Engineering چیست؟+
Prompt Engineering بیشتر روی نحوه نوشتن Instructions تمرکز دارد. Context Engineering علاوه بر Prompt، تاریخچه، اسناد، Memory، نتایج Toolها، State و سایر اطلاعات موجود در Context را مدیریت میکند.
آیا Context بیشتر باعث پاسخ بهتر میشود؟+
نه همیشه. اطلاعات نامرتبط یا بیشازحد میتواند Noise ایجاد کند و تمرکز مدل را کاهش دهد. هدف Context Engineering ارائه اطلاعات مرتبط و کافی است، نه حداکثر اطلاعات ممکن.
RAG همان Context Engineering است؟+
خیر. RAG یکی از روشهای تهیه Context است. Context Engineering حوزه بزرگتری است که Retrieval، Memory، Context Processing، Tool Output، State Management و روشهای دیگر را نیز شامل میشود.
Context Window چیست؟+
Context Window مقدار اطلاعاتی است که مدل میتواند در یک تعامل در نظر بگیرد. این اطلاعات معمولاً به صورت Token اندازهگیری میشوند و شامل Prompt، تاریخچه و سایر دادههای ورودی میشوند.
Context Engineering چه اهمیتی برای AI Agent دارد؟+
Agentها در چند مرحله کار میکنند و در طول کار اطلاعات زیادی تولید و دریافت میکنند. اگر این اطلاعات بهدرستی مدیریت نشوند، Context شلوغ یا آلوده میشود و کیفیت تصمیمگیری Agent کاهش پیدا میکند. به همین دلیل Context Engineering یکی از بخشهای مهم طراحی Agentهای حرفهای است.
می‌خواهی مسیر AI Agent Engineer را شروع کنی؟
در بوت‌کمپ مهندسی ایجنت تنسوا، از معماری و Tool Calling تا Context Engineering، MCP، Guardrail و Evaluation را پروژه‌محور یاد می‌گیری. پیش‌ثبت‌نام رایگان است.