وقتی با مدلهای زبانی کار میکنید، معمولاً اولین سؤال این است: «Prompt را چطور بنویسم؟» اما در سیستمهای واقعی—بهویژه در ایجنت هوش مصنوعی—سؤال مهمتری مطرح میشود: در این لحظه، مدل دقیقاً به چه اطلاعاتی نیاز دارد؟
فرض کنید Agent پشتیبانی باید وضعیت سفارش را بررسی کند. اگر کل تاریخچه مشتری، تمام قوانین مرجوعی، و لاگ کامل انبار را یکجا به مدل بدهید، ممکن است پاسخ طولانی و پراکنده بگیرد. اگر هیچ Contextی ندهید، حدس میزند. راهحل درست معمولاً بین این دو است.
Context Engineering یعنی طراحی محیط اطلاعاتی مدل؛ نه فقط نوشتن یک دستورالعمل زیبا.
در این مقاله میبینیم Context Engineering چیست، چرا از Prompt Engineering فراتر میرود، لایههای آن کداماند، در Agent چگونه اعمال میشود و چه اشتباهات رایجی کیفیت سیستم را خراب میکنند.
Context Engineering چیست؟
Context Engineering مهارت انتخاب، سازماندهی و تحویل اطلاعات درست به مدل در زمان درست است.
Context Window ظرفیت محدودی دارد. هر چیزی که داخل آن میگذارید—System Prompt، تاریخچه مکالمه، نتایج Tool، اسناد بازیابیشده، قوانین کسبوکار—برای توجه مدل رقابت میکند.
بنابراین Context Engineering فقط «جمع کردن داده» نیست؛ یک طراحی مهندسی است:
این نگاه در مسیر مهندسی ایجنت بهاندازه Tool Calling و Evaluation اهمیت دارد؛ چون Agent بدون Context مناسب، حتی با ابزارهای خوب هم تصمیم ضعیف میگیرد.
چرا Context Engineering مهم است؟
بسیاری از شکستهای ظاهری «مدل بد است» در واقع مشکل Context هستند: اطلاعات ناقص، اطلاعات زیاد، شواهد قدیمی، یا قوانین متناقض.
کیفیت تصمیم
مدل فقط از چیزی که میبیند تصمیم میگیرد. اگر شواهد کلیدی غایب باشد، حدس جایگزین تحلیل میشود.
هزینه و سرعت
Context بلند یعنی توکن بیشتر، Latency بالاتر و هزینه بیشتر—بدون تضمین کیفیت بهتر.
پایداری رفتار
اگر در هر مرحله Context نامنظم عوض شود، رفتار Agent غیرقابل پیشبینی میشود.
در عمل، تیمهایی که روی Context کار میکنند معمولاً زودتر به سیستم قابل اعتماد میرسند تا تیمهایی که فقط Prompt را طولانیتر میکنند.
تفاوت با Prompt Engineering
این دو مهارت رقیب هم نیستند؛ لایههای مکملاند.
- • نقش و هدف مدل را مشخص میکند
- • قالب خروجی و محدودیتها را تعریف میکند
- • مثالها و سبک پاسخ را تنظیم میکند
- • منابع اطلاعات را انتخاب و فیلتر میکند
- • خلاصه، State و Memory را مدیریت میکند
- • زمان ورود اطلاعات به Context را طراحی میکند
Prompt میگوید «چه کار کن»؛ Context مشخص میکند «با چه شواهدی تصمیم بگیر».
اگر فقط Prompt را بهتر کنید ولی اسناد اشتباه یا ناقص بدهید، خروجی همچنان ضعیف میماند. اگر Context عالی باشد ولی دستورالعمل مبهم باشد، مدل مسیر را گم میکند. سیستم خوب هر دو را با هم طراحی میکند.
لایههای Context
برای طراحی عملی، Context را میتوان به چند لایه تفکیک کرد:
۱) Instructions ثابت
نقش، قوانین ایمنی، سبک پاسخ و محدودیتهای همیشگی. این لایه باید کوتاه، شفاف و پایدار باشد.
۲) Task Context
هدف همین درخواست: شماره سفارش، محصول موردنظر، بازه زمانی تحلیل، یا معیار موفقیت.
۳) Retrieved Evidence
اسناد، رکوردهای CRM، نتایج جستجو یا قطعههای دانش که فقط برای این تصمیم لازماند.
۴) Tool / Observation
خروجی ابزارها در حلقه Agent. باید تمیز، ساختیافته و بدون نویز اضافی به مدل برگردد.
۵) Working State
وضعیت میانی Task: چه مراحلی انجام شده، چه فرضیاتی تأیید شده، چه سؤالهایی باز مانده.
۶) Long-term Memory (در صورت نیاز)
ترجیحات پایدار یا خلاصه تعاملات قبلی—نه کل تاریخچه خام.
اتصال استاندارد به ابزارها و منابع—مثل آنچه در مقاله MCP بررسی میشود—کمک میکند لایه Tool و Evidence قابلاتکاتر و قابلنگهداریتر شود.
Context Engineering را در مسیر ساخت Agent تمرین کن
در بوتکمپ مهندسی ایجنت تنسوا، طراحی Context، Tool Calling و Evaluation را روی پروژههای واقعی یاد میگیری. برای تمرین Prompt هم میتوانی از کتابخانه پرامپت استفاده کنی.
Context در معماری Agent
در یک AI Agent، Context ایستا نیست. بعد از هر مشاهده (Observation) باید بازطراحی شود.
مثال عملی: Agent تحلیل فروش میپرسد «چرا فروش هفته گذشته افت کرده؟»
- 1ابتدا فقط هدف، بازه زمانی و تعریف «افت غیرعادی» را در Context میگذارد.
- 2Tool فروش را صدا میزند و فقط خلاصه مقایسه هفتگی را نگه میدارد—نه کل CSV خام.
- 3اگر افت در یک دسته محصول باشد، فقط اسناد همان دسته و کمپینهای مرتبط را بازیابی میکند.
- 4فرضیههای ردشده را کوتاه ثبت میکند تا مدل دوباره همان مسیر را تکرار نکند.
- 5در گزارش نهایی فقط شواهد تأییدشده و محدودیتهای داده را نگه میدارد.
این همان تفاوت Demo و سیستم مهندسیشده است: Context بهصورت هدفمند و مرحلهای ساخته میشود، نه یکبار برای همیشه.
اشتباهات رایج
فرستادن کل دیتابیس دانش یا کل تاریخچه مکالمه معمولاً نویز ایجاد میکند.
اگر قوانین ایمنی و شواهد کلیدی در انتهای Context دفن شوند، احتمال نادیده گرفتنشان بیشتر میشود.
نگهداشتن نتایج Tool قدیمی بدون برچسب زمان باعث تصمیم بر اساس داده منسوخ میشود.
اگر اعداد، شرطها یا نقلقولهای حیاتی حذف شوند، مدل روی خلاصه ناقص استدلال میکند.
چند نسخه مختلف از قوانین در لایههای مختلف، رفتار ناپایدار میسازد.
بدون سناریوهای ناقص/متضاد، نمیفهمید سیستم کجا گیج میشود.
بسیاری از این خطاها فقط با مشاهده دستی پیدا نمیشوند؛ باید در چارچوب Agent Evaluation سناریو بسازید و ببینید مدل با Contextهای مختلف چه تصمیمی میگیرد.
چارچوب عملی برای شروع
اگر میخواهید Context Engineering را در پروژه واقعی پیاده کنید، این چکلیست ساده را دنبال کنید:
۱. هدف را بنویسید
مدل در این مرحله دقیقاً چه تصمیمی باید بگیرد؟ موفقیت چه شکلی است؟
۲. حداقل شواهد لازم
لیست کنید چه فیلدها/اسنادی بدون آنها تصمیم غیرممکن است. بقیه را موقتاً حذف کنید.
۳. قالب ساختیافته
شواهد را با برچسب منبع، زمان و سطح اطمینان وارد کنید—نه پاراگرافهای درهم.
۴. حلقه بهروزرسانی
بعد از هر Tool، مشخص کنید چه چیزی اضافه، خلاصه یا حذف شود.
قانون طلایی: هر توکن Context باید برای تصمیم فعلی «کار» کند؛ وگرنه هزینه است نه سرمایه.
برای تمرین اولیه میتوانید از قالبهای کتابخانه پرامپت تنسوا شروع کنید، سپس همان منطق را به سیستم Agent و بازیابی اسناد گسترش دهید.
جمعبندی
Context Engineering حلقه اتصال بین Prompt خوب و سیستم قابل اعتماد است. بهجای پرسیدن «چطور Prompt طولانیتری بنویسم؟» بپرسید: «مدل در این لحظه به چه سیگنالی نیاز دارد و چه نویزی را باید حذف کنم؟»
اگر مسیرتان ساخت سیستمهای Agentic است، Context را همراه Tool Design، MCP و Evaluation یاد بگیرید—نه بهصورت جدا و نظری.
سوالات متداول
Context Engineering چیست؟+
Context Engineering هنر و مهارت طراحی این است که در هر مرحله از کار مدل، چه اطلاعاتی، با چه اولویت و چه فرمتی در اختیارش قرار بگیرد؛ نه فقط نوشتن یک Prompt اولیه.
تفاوت Context Engineering و Prompt Engineering چیست؟+
Prompt Engineering بیشتر روی دستورالعمل و قالب ورودی تمرکز دارد. Context Engineering علاوه بر آن، انتخاب، فیلتر، خلاصهسازی و زمانبندی اطلاعات را هم طراحی میکند تا Context Window بهینه استفاده شود.
آیا Context بیشتر همیشه بهتر است؟+
خیر. اطلاعات زیاد و کمسیگنال میتواند مدل را گیج کند، هزینه و Latency را بالا ببرد و کیفیت تصمیم را پایین بیاورد. هدف Context باکیفیت و مرتبط است، نه حجم حداکثری.
Context Engineering در Agent چه نقشی دارد؟+
در Agentهای چندمرحلهای، مدل در هر گام به اطلاعات متفاوتی نیاز دارد. Context Engineering مشخص میکند چه چیزی از State، Memory، Tool Output یا دانش سازمانی باید در همان لحظه وارد Context شود.
از کجا Context Engineering را تمرین کنیم؟+
با یک مسئله واقعی شروع کنید: اسناد مرتبط را جدا کنید، خلاصه مرحلهای بسازید، فقط شواهد لازم را به مدل بدهید و خروجی را با سناریوهای ناقص/متضاد تست کنید. سپس این الگو را در مسیر Agent Engineering گسترش دهید.
میخواهی Context Engineering را در Agent واقعی پیاده کنی؟
در بوتکمپ مهندسی ایجنت تنسوا، طراحی Context، Tool Calling، MCP و Evaluation را پروژهمحور یاد میگیری. پیشثبتنام رایگان است.
میخواهی پرامپتنویسی را اصولی یاد بگیری؟
دوره رایگان مهندسی پرامپت در حال ضبط است. شماره بگذار تا هنگام انتشار خبرت کنیم؛ یا همین حالا از کتابخانه پرامپتهای آماده شروع کن.