Context Engineering یا مهندسی زمینه، تکامل طبیعی Prompt Engineering است. وقتی Andrej Karpathy در ژوئن ۲۰۲۵ توییت کرد «+1 برای Context Engineering بهجای Prompt Engineering»، صنعت بهسرعت پذیرفت. علتش این بود: در LLM appهای جدی، مدل نسبت به کل context پاسخ میدهد، نه فقط متن پرامپت. این مقاله توضیح میدهد چه چیزی عوض شد و چرا این مهارتی است که در ۱۴۰۵ باید یاد بگیرید.
Context Engineering چیست؟
Context Engineering (مهندسی زمینه) بهگفتهی Anthropic:
«مجموعهای از راهبردها برای انتخاب و نگهداری بهینهی توکنها (اطلاعات) در زمان inference مدل زبانی»
یا با تعریف سادهتر Philip Schmid (HuggingFace):
«نظم طراحی و ساخت سیستمهای پویا که اطلاعات و ابزار درست را، در قالب درست، در زمان درست به مدل میرسانند.»
یا تعریف شاعرانهتر Andrej Karpathy (همبنیانگذار OpenAI):
«هنر و علم ظریف پر کردن context window با اطلاعات درست برای هر گام بعدی.»
به زبان متین
تصور کن میخواهی به یه دستیار جدید یاد بدی برات یه ایمیل بنویسه. Prompt Engineering یعنی متن دستوری که مینویسی: «یه ایمیل رسمی به استاد X بفرست…». اما Context Engineering یعنی همه چیزی که دستیار قبل از نوشتن نیاز دارد بداند:
- سبک نوشتاری خودت (تاریخچه)
- کلمات کلیدی که نباید استفاده شود (دستورالعمل)
- قبلاً چی به این استاد گفتهای (حافظهی بلندمدت)
- ایمیل قبلی استاد چی بود (اطلاعات بازیابیشده)
- به کاربر بگو آیا میتوانی schedule meeting بسازی یا نه (ابزار)
- خروجی بهصورت subject + body (قالب)
یک متن پرامپت تنها هیچکدام از اینها را نمیدهد. یک سیستم Context Engineering همهی اینها را پویا جمع میکند و به مدل میدهد.
از کجا شروع شد؟ Karpathy، Lütke و Anthropic
این اصطلاح یک تاریخ مشخص دارد: ۱۹ ژوئن ۲۰۲۵ (۲۹ خرداد ۱۴۰۴).
گام ۱: Tobi Lütke اصطلاح را اختراع کرد
Tobi Lütke (مدیرعامل Shopify) در توییتر نوشت که اصطلاح Prompt Engineering دارد ناقص میشود. در LLM appهای واقعی، چالش اصلی نوشتن متن پرامپت نیست — چالش این است که چه چیزی در context window قرار بگیرد.
گام ۲: Karpathy آن را معروف کرد
چند روز بعد، Andrej Karpathy (همبنیانگذار OpenAI، مدیر سابق هوش مصنوعی Tesla) با این توییت موافقت کرد:
+1 for "context engineering" over "prompt engineering". People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step.
این توییت ویروسی شد و در عرض یک هفته اصطلاح Context Engineering در همهی محافل صنعتی AI رواج پیدا کرد.
گام ۳: Philip Schmid (HuggingFace) چارچوب رسمی داد
Philip Schmid، Technical Lead سابق HuggingFace، مقالهای منتشر کرد به نام «The New Skill in AI is Not Prompting, It's Context Engineering». در این مقاله، او ۷ جزء context را تعریف کرد (که بعداً به آنها میرسیم) و گفت تفاوت بین یک agent معمولی و یک agent جادویی، نه در مدل بلکه در کیفیت context است.
گام ۴: Anthropic رسمیت داد
Anthropic در بلاگ مهندسی رسمی خود مقالهای منتشر کرد به نام «Effective Context Engineering for AI Agents». در این مقاله، Anthropic سه الگوی پیشرفته (Compaction، Structured Note-taking، Sub-agent Architectures) معرفی کرد که بعداً توضیح میدهیم.
گام ۵: Elastic، DataCamp، InfoWorld و دیگران
تا اواخر ۲۰۲۵، Context Engineering تبدیل به یک حوزهی استاندارد شد. Elastic یک پلتفرم Agent Builder منتشر کرد. InfoWorld آن را «معماری جدید AI» نامید. دانشگاه Princeton مقالهی arXiv منتشر کرد به نام «Context Engineering 2.0».
چرا صنعت از Prompt به Context رفت؟
تصمیم صنعت برای عوض کردن اصطلاح، اتفاقی نبود. سه عامل اصلی پشت این جابهجایی است:
عامل ۱: ظهور AI Agentها
تا ۲۰۲۳، استفادهی اصلی LLM یکبار-تماس بود: متن میفرستی، جواب میگیری. در این مدل، Prompt Engineering همهچیز بود.
اما AI Agentها فرق دارند. یک agent ممکن است:
- چند ساعت پشت سر هم کار کند
- دهها ابزار را صدا کند
- اطلاعات از دیتابیس بکشد
- حافظهی گفتوگوی قبلی را نگه دارد
- تصمیم بگیرد چه چیزی را در context نگه دارد و چه چیزی را دور بریزد
این پیچیدگی فراتر از یک «پرامپت خوب» است. یک سیستم لازم است.
عامل ۲: context window خیلی بزرگ شد
در ۲۰۲۳، GPT-4 فقط ۸k توکن context داشت. در ۱۴۰۵:
| مدل | Context Window | معادل تقریبی |
|---|---|---|
| GPT-4 (2023) | 8K توکن | ~۶ صفحه |
| Claude 3 Opus | 200K توکن | ~۱۵۰ صفحه |
| Gemini 1.5 Pro | 1M-2M توکن | یک کتاب کامل |
| Claude 3.7 Sonnet | 200K توکن | ~۱۵۰ صفحه |
| GPT-5 (2025) | 400K توکن | ~۳۰۰ صفحه |
این یعنی بهجای «چند جمله»، میتوانیم «صدها صفحه» در context قرار دهیم. اما این آزادی، یک مشکل آورد: چه چیزی را نگه داریم و چه چیزی را دور بریزیم؟ این سؤال، قلب Context Engineering است.
عامل ۳: کشف «Lost in the Middle» و Context Rot
پژوهشها نشان دادند که context window بزرگ همیشه بهتر نیست:
- Lost in the Middle: اطلاعات وسط context را مدل خیلی کمتر یادآوری میکند تا اطلاعات اول و آخر
- Context Rot: هرچه context بزرگتر، توجه مدل به جزئیات کمتر
- Quadratic scaling: هزینه و تأخیر با مربع طول context رشد میکند (O(n²))
پس فقط «همه چیز را بریز توی context» جواب نمیدهد. باید هوشمندانه انتخاب کنیم. این هنر Context Engineering است.
اعداد واقعی شکست
طبق یک پژوهش observational روی ۲۰۰ تعامل واقعی با چهار ابزار AI:
| متغیر | بدون Context Engineering | با Context Engineering |
|---|---|---|
| میانگین iteration تا جواب درست | ۳.۸ بار | ۲.۰ بار |
| درصد پاسخ درست در اولین تلاش | ۳۲٪ | ۵۵٪ |
| درصد iterationها بهخاطر context ناقص | ۷۲٪ | — |
این یعنی Context Engineering نهفقط «کیفیت بهتر» میدهد — ۷۲٪ از مشکلات agentها بهخاطر context ناقص است، نه ضعف مدل. تو در صنعتی هستی که اگر یکی این موضوع را زودتر بفهمد، agentهای ۲ برابر سریعتر و دقیقتر میسازد.
۷ جزء context — فریمورک Schmid
این مهمترین بخش مقاله است. اگر فقط یک چیز از Context Engineering یاد بگیری، این ۷ جزء را یاد بگیر. هر فراخوانی LLM میتواند تا ۷ نوع اطلاعات داشته باشد:
| # | جزء | چیست | مثال فارسی |
|---|---|---|---|
| ۱ | Instructions / System Prompt | دستورالعمل رفتاری، نقش، قوانین | «تو یک مشاور تغذیهای فارسی هستی. هرگز توصیهی دارویی نکن.» |
| ۲ | User Prompt | سؤال فعلی کاربر | «برای کاهش وزن چه صبحانهای پیشنهاد میکنی؟» |
| ۳ | State / History | تاریخچهی گفتوگوی فعلی | «قبلاً گفتم گیاهخوارم و آلرژی به بادام دارم» |
| ۴ | Long-Term Memory | اطلاعات پایدار بین جلسات | «وزن کاربر ۷۲، قد ۱۷۵، هدف ۶۸ کیلو در ۳ ماه» |
| ۵ | Retrieved Info (RAG) | اطلاعات بازیابیشده از منابع | ۳ مقالهی تغذیهی فارسی درباره صبحانههای لاغری |
| ۶ | Available Tools | توابع قابلفراخوانی + schema | calculate_calories(food, weight)، search_recipes(query) |
| ۷ | Structured Output | قالب پاسخ خروجی | JSON با فیلدهای: breakfast، calories، prep_time، reason |
مثال زنده: «دستیار رزرو رستوران»
تفاوت بین یک agent معمولی و agent جادویی را در یک سناریوی واقعی ببینیم. کاربر میگوید: «برای فردا شب با همسرم رزرو کن.»
agent معمولی (فقط Prompt)
پاسخ: «عالی. در کدام رستوران؟ ساعت چند؟ چند نفر؟»
یعنی هیچ context ندارد، باید همهچیز را بپرسد.
agent جادویی (Context Engineering)
پاسخ: «بر اساس علاقهی شما به غذای ایتالیایی و رزروهای قبلی، رستوران Pavarotti فردا ساعت ۲۱ در دسترس است. آیا میز ۲ نفرهی کنار پنجره مثل دفعهی قبل میخواهید؟»
چه چیزی این agent را جادویی کرد؟ همان ۷ جزء context:
| جزء | چه چیزی در آن بود |
|---|---|
| System Prompt | «تو دستیار رزرو هستی. اگر اطلاعات کافی داری، خودت پیشنهاد بده، نپرس.» |
| User Prompt | «برای فردا شب با همسرم رزرو کن» |
| State/History | گفتوگوی این session — کاربر امروز ۳ بار درباره فردا حرف زده |
| Long-Term Memory | کاربر متأهل است، علاقهمند به ایتالیایی، معمولاً ۲۱ شب میرود |
| RAG | ۵ رزرو قبلی این کاربر، ۳ بار Pavarotti، همیشه میز کنار پنجره |
| Tools | check_availability()، create_reservation() |
| Output | پاسخ کوتاه + JSON با reservation_id برای backend |
Context Engineering در برابر Prompt Engineering
این مقایسهی critical است. خیلیها این دو را جایگزین هم میبینند. در واقعیت، Context Engineering یک سطح بالاتر است که Prompt Engineering جزئی از آن.
| معیار | Prompt Engineering | Context Engineering |
|---|---|---|
| دامنه | یک متن پرامپت | کل سیستم اطلاعاتی |
| تمرکز | چه بنویسم | چه چیزی در context قرار دهم |
| سطح | تاکتیکی | معماری/استراتژیک |
| دانش لازم | نوشتن، روانشناسی | Software Engineering + Data + LLM |
| خروجی | یک string | یک سیستم پویا |
| مقیاس | تا چند صد کلمه | تا میلیونها توکن داده |
| متناسب برای | چت تکتماس، صفحه ChatGPT | AI Agent، RAG، production app |
| وضعیت در ۱۴۰۵ | پایهی ضروری | تمایز رقابتی |
چه چیزی تغییر نکرده است
برخلاف ادعاهای کلیکبیتی، Prompt Engineering نمرده. مهارتهای اصلی هنوز ضروریاند:
- نوشتن System Prompt دقیق و عملمحور
- استفاده از Few-shot Learning برای تعریف الگو
- تکنیکهای Chain-of-Thought برای استدلال
- اجتناب از ۱۵ اشتباه رایج
چه چیزی اضافه شده: مهارت طراحی سیستمی که این پرامپت خوب را در محیط درست قرار میدهد.
۴ راهبرد مدیریت context (Elastic Framework)
وقتی context window بزرگ شد و اطلاعات زیاد، چالش این شد: چه چیزی را کجا بگذاریم؟ Elastic چهار راهبرد اصلی را تعریف کرد:
راهبرد ۱: Selection (انتخاب)
اصل: بهجای بارگذاری همهچیز، فقط اطلاعات مرتبط را «just-in-time» بازیابی کن.
تکنیکهای کلیدی:
- Hybrid Search: ترکیب جستجوی کلیدواژهای (BM25) با جستجوی معنایی (vector) — هر کدام نقاط ضعف دیگری را پوشش میدهد
- Reranking: یک مدل کوچکتر نتایج اولیه را دوباره مرتب میکند، مهمترینها بالا میآیند
- Dynamic Tool Discovery: بهجای دادن لیست همهی ۱۰۰ ابزار، فقط ۳-۵ ابزار مرتبط با task فعلی را نمایش بده
راهبرد ۲: Writing (نوشتن به حافظهی خارجی)
اصل: بهجای نگهداشتن همهچیز در context، اطلاعات را در «حافظهی خارجی» ذخیره کن.
پیادهسازیهای رایج:
- Scratchpad files: agent میتواند فایل
NOTES.mdبنویسد و بخواند - Vector database: اطلاعات بلندمدت در Pinecone، Chroma، Weaviate
- Key-value store: Redis برای حافظهی session
این الگو در Claude Code Anthropic دقیقاً همین است: agent بهجای نگهداشتن کل کدبیس در context، فقط file path و query نگه میدارد و وقت لازم فایل میخواند.
راهبرد ۳: Compression (فشردهسازی)
اصل: اطلاعات قدیمی یا کماهمیت را خلاصه کن، نه دور بریز.
تکنیکهای کلیدی:
- Conversation summarization: هر ۲۰ پیام، یک خلاصهی ۲ پاراگرافی بساز و پیامهای قدیمی را با خلاصه جایگزین کن
- Tool output trimming: اگر یک جستجو ۱۰ کیلوبایت JSON برگرداند، فقط بخشهای لازم را نگه دار
- Recursive summarization: برای متنهای خیلی بلند، اول chunkهای کوچک خلاصه کن، بعد خلاصهها را با هم
راهبرد ۴: Isolation (جداسازی با sub-agentها)
اصل: بهجای یک agent بزرگ با همهچیز، چند agent تخصصی با context محدود.
الگوی رایج:
- یک lead agent با context کلی
- چند sub-agent با context تمرکزی (یکی فقط برای search، یکی فقط برای کد، یکی فقط برای email)
- هر sub-agent کار خودش را میکند، فقط خلاصه را به lead برمیگرداند
این الگوست که در CrewAI، AutoGen و LangGraph implement شده. یک عدد جالب: sub-agentها معمولاً دهها هزار توکن داخلی استفاده میکنند ولی فقط ۱۰۰۰-۲۰۰۰ توکن خلاصه به lead برمیگردانند — یعنی ۹۰٪+ فشردهسازی.
سه الگوی Anthropic برای کار طولانیمدت
Anthropic در بلاگ رسمی، سه الگوی پیشرفته معرفی کرد که برای agentهایی است که روزها روی یک task کار میکنند. این الگوها در Claude Code و Computer Use استفاده میشوند:
الگوی ۱: Compaction (فشردهسازی)
چه میکند: وقتی context پر میشود، agent یک خلاصه از کل گفتوگو میسازد، context را reinitialize میکند با خلاصه، و کار را ادامه میدهد.
چه را نگه میدارد:
- تصمیمات معماری مهم (که نباید فراموش شود)
- محدودیتها و قوانین کاربر
- پیشرفت تابهحال (مرحله فعلی)
چه را دور میریزد:
- خروجیهای قدیمی tool که دیگر استفاده نمیشوند
- جزئیات code که در فایلها ذخیره شده
- تلاشهای ناموفق که درسشان گرفته شد
الگوی ۲: Structured Note-taking
چه میکند: agent یک فایل NOTES.md (یا چند فایل) در سیستم میسازد و بهمرور یادداشت میگذارد.
مثال واقعی (از Anthropic): در یک تست، agent بازی Pokémon را برای هزاران گام بازی کرد. اگر کل تاریخچه را در context میگذاشت، چند ساعت بعد overflow میشد. بهجایش، در فایل game_state.md چیزهایی مثل «قهرمان: Charizard، سطح ۴۲، در حال جستجو برای Mewtwo در غار ۳» مینوشت. context کوتاه میماند، state حفظ میشد.
کاربردهای واقعی:
- پروژههای coding چندروزه (مثل Claude Code)
- تحقیق علمی با چندین مقاله
- پیگیری customer service طولانی
الگوی ۳: Sub-agent Architectures
چه میکند: یک agent ارشد، task را به sub-taskهای تخصصی تقسیم میکند و به sub-agentهای جداگانه میدهد. هر sub-agent context تمرکزیتر و کوچکتر دارد.
مثال: برای نوشتن یک مقاله SEO فارسی:
- Lead Agent: برنامهریزی کلی، تصمیم درباره ساختار
- Research Sub-agent: فقط جستجو و گردآوری منابع (با ابزار جستجو)
- Writing Sub-agent: فقط نوشتن متن (با style guide)
- SEO Sub-agent: فقط بهینهسازی meta و schema (با ابزار SEO)
- Review Sub-agent: فقط بازبینی نهایی (با E-E-A-T checklist)
هر sub-agent در دهها هزار توکن داخلی کار میکند ولی فقط ۱۰۰۰-۲۰۰۰ توکن خلاصه به lead میفرستد. lead با ۵ خلاصهی فشرده، تصمیم نهایی میگیرد.
۶ شکست رایج Context Engineering + راهحل
این بخش جایی است که agent builderهای تازهکار وقت میسوزانند. این ۶ مورد را در پروژههای فارسی شخصاً دیدهام:
۱. Lost in the Middle
چه میشود: اطلاعات مهم را در میانهی یک context طولانی قرار میدهی. مدل آن را نادیده میگیرد و انگار اصلاً نبود.
راهحل:
- مهمترین اطلاعات را در ابتدا یا انتها قرار بده
- از reranking برای بازچینش نتایج RAG استفاده کن
- برای contextهای خیلی بزرگ، از sub-agent استفاده کن (هر sub با context کوچک)
۲. Context Poisoning
چه میشود: یک خطا یا اطلاعات غلط زود وارد context میشود (مثلاً یک tool output اشتباه)، و در iterationهای بعدی مدل آن را بهعنوان «حقیقت» میگیرد و خطاهای جدیدی روی آن میسازد.
راهحل:
- validation strict روی tool output قبل از append
- اگر مدل تشخیص داد اطلاعات قبلی غلط است، آن را بهصراحت «mark as wrong» کند
- compaction دورهای — خلاصه فقط نکات تأییدشده را نگه دارد
۳. Goal Drift
چه میشود: agent در یک گفتوگوی طولانی کمکم هدف اصلی را فراموش میکند چون context پر از جزئیات حاشیهای شده.
راهحل:
- یادآوری دورهای goal در system prompt («هدف اصلی همچنان X است»)
- structured note با فایل
GOAL.mdهمیشه در ابتدای context - برای taskهای پیچیده، plan را اول بنویس بعد یکییکی execute کن
۴. Capacity Overflow
چه میشود: context پر میشود از اطلاعات کماهمیت، و بخشهای حیاتی truncate میشوند.
راهحل:
- budget برای هر بخش context (مثلاً ۲۰٪ system، ۳۰٪ history، ۵۰٪ RAG)
- اولویتبندی هنگام truncation: اول tool outputهای قدیمی را دور بریز
- compression پویا وقتی به ۸۰٪ ظرفیت رسید
۵. Context Rot
چه میشود: هرچه context بزرگتر شد، توجه مدل به جزئیات کاهش مییابد. حتی اگر اطلاعات در context باشد، مدل آن را «نمیبیند».
راهحل:
- context را زیر ۵۰٪ ظرفیت مدل نگه دار (یعنی برای Claude 200K، زیر ۱۰۰K)
- اطلاعات مرتبط با task فعلی را explicit در پرامپت دوباره ذکر کن
- از مدلهایی با context window بزرگتر استفاده کن (Gemini 1M+) ولی با احتیاط
۶. Quadratic Cost Explosion
چه میشود: هزینه (time + token + dollar) با مربع طول context رشد میکند. یک agent با context ۱۰۰K هزار برابر گرانتر از agent با context ۱K است.
راهحل:
- برای planning از مدل ارزان (Haiku، GPT-4o-mini)، برای task مهم از Opus
- caching پاسخهای تکراری (Anthropic Prompt Caching تا ۹۰٪ ارزانتر)
- monitoring هزینه per request با ابزار LangSmith یا Langfuse
سه مثال فارسی عملی
این بخش جایی است که Context Engineering از تئوری به عمل میرسد. سه مورد واقعی که خودم پیاده کردهام:
مثال ۱: چتبات پشتیبانی فروشگاه اینستاگرام
قبل از Context Engineering: فقط یک پرامپت ساده «پاسخگوی مشتری باش». کاربر میپرسید: «سفارش X کی میرسد؟» بات جواب کلی میداد بدون اطلاعات واقعی.
بعد از Context Engineering:
| جزء | چه چیزی در آن قرار گرفت |
|---|---|
| System Prompt | «تو پشتیبانی فروشگاه نازنین هستی. لحن صمیمی، فارسی محاوره. هرگز قول بیپایه نده.» |
| State/History | پیامهای قبلی همین DM (مثلاً کاربر گفت آدرس عوض شده) |
| Long-Term Memory | کاربر قبلاً ۳ خرید داشته، VIP است، تاریخ تولدش ۲ هفته دیگر |
| RAG | FAQ فروشگاه، سیاست بازگشت، راهنمای استفاده محصولات |
| Tools | get_order_status(order_id)، refund(order_id, reason)، track_shipment(tracking_code) |
| Output | پاسخ کوتاه فارسی + (اختیاری) دکمههای suggested replies |
نتیجه: همان سؤال «سفارش X کی میرسد؟» پاسخ گرفت: «سفارش شما (#1234) دیروز با پست تیپاکس فرستاده شده، کد رهگیری 78901. طبق پیشبینی، پنجشنبه به دستتون میرسه.» — با اطلاعات واقعی، نه حدس.
مثال ۲: دستیار تحقیق دانشجویی
سناریو: دانشجوی کارشناسی ارشد میخواهد یک پایاننامه بنویسد. بهجای ChatGPT معمولی، میخواهد agentی که محدود به منابع علمی فارسی و انگلیسی واقعی باشد.
طراحی Context:
- RAG: پایگاه داده ۵۰۰۰ مقالهی فارسی از SID، Magiran، Civilica + ۱۰۰۰۰ مقالهی arXiv
- Tools:
search_papers(query, lang)،get_citation(paper_id)،summarize_paper(paper_id) - Long-Term Memory: موضوع پایاننامه، استاد راهنما، فصلهای نوشتهشده تا الان
- System Prompt: «هر ادعا باید با citation معتبر همراه باشد. اگر منبع نداری، صریحاً بگو.»
چرا با ChatGPT تنها کار نمیکرد: ChatGPT نمیتوانست مقالههای فارسی SID را بخواند، citationهای واقعی بدهد، یا با موضوع پایاننامه پایدار بماند.
مثال ۳: agent تولید محتوای SEO فارسی
سناریو: یک سایت میخواهد ۵۰ مقالهی SEO فارسی در ماه تولید کند. هر مقاله نیاز به: keyword research، تحلیل رقیب، نوشتن، schema، تصویر اختصاصی.
طراحی Multi-Agent:
- Lead Agent: دریافت موضوع، تقسیم کار، تأیید نهایی
- Research Agent: Google + Bing برای SERP analysis، رقبا، long-tailها
- Writer Agent: فقط نوشتن متن با style guide سایت (System Prompt اختصاصی)
- SEO Agent: Title، meta، schema (با چکلیست GEO)
- Image Agent: پرامپت برای Midjourney + اسکرینشات
هر agent context کوچک ولی تمرکزی دارد. Lead فقط ۵ خلاصه (هر کدام ۱۰۰۰ توکن) را با هم میبیند، نه ۵۰K توکن خام.
نتیجه: ۵۰ مقاله در ماه با کیفیت یکنواخت، هزینهی پایین (sub-agentها مدل ارزان، lead فقط Opus)، و قابلنگهداری.
ابزارها و frameworks Context Engineering
خبر خوب: لازم نیست از صفر بسازی. ۱۴۰۵ یک اکوسیستم کامل ابزار وجود دارد. این نقشهی کاربردی برای انتخاب است:
برای orchestration (هماهنگی agent)
| ابزار | قوت | ضعف | متناسب برای |
|---|---|---|---|
| LangChain | اکوسیستم بزرگ، یکپارچه با همه | پیچیده، over-engineered | پروژههای متوسط با چند ابزار |
| LangGraph | graph-based، انعطاف بالا | منحنی یادگیری | agentهای پیچیده با شاخهبندی |
| CrewAI | سادهترین multi-agent API | محدود در سفارشیسازی | تیمهای sub-agent |
| AutoGen (Microsoft) | قدرتمند، تحقیقاتی | کمتر developer-friendly | پروژههای پژوهشی |
| LlamaIndex | RAG-first، عالی برای داده | کمتر برای agent خام | سیستمهای جستجو و QA |
برای RAG و vector storage
- Pinecone: SaaS، گران ولی پایدار
- Chroma: open-source، embedded، عالی برای شروع
- Weaviate: open-source، با hybrid search built-in
- Qdrant: پایدار، سرعت بالا، self-host آسان
- pgvector: اگر Postgres داری، اضافه کردنش رایگانه
برای حافظهی بلندمدت
- Zep: اختصاصی برای memory + temporal knowledge graph
- Mem0: سبک، plug-and-play
- LangChain Memory: پایهای ولی کافی برای شروع
برای پروتکلهای اتصال
- MCP (Model Context Protocol): استاندارد Anthropic، تبدیل به استاندارد صنعت در حال شدن. مثل USB-C برای AI
- OpenAPI: برای اتصال REST APIها
- GraphQL: برای queryهای پیچیده
برای monitoring
- LangSmith: از تیم LangChain، بهترین برای debug
- Langfuse: open-source، خود-میزبان
- Helicone: proxy ساده برای OpenAI، با cache و log
مسیر یادگیری: از پرامپت تا Context Engineering
این مسیر بر اساس تجربهی شخصی من با شاگردانم طراحی شده. اگر صفر هستی، این ترتیب را دنبال کن:
هفته ۱-۲: پایهی Prompt Engineering
- مطالعه مهندسی پرامپت + پرامپتنویسی
- تمرین Few-shot Learning و System Prompt
- اجتناب از ۱۵ اشتباه رایج
هفته ۳-۴: تکنیکهای پیشرفته
- Chain-of-Thought و Tree of Thoughts
- ReAct Prompting و الگوی Thought-Action-Observation
- Persona Prompting برای نقشآفرینی
هفته ۵-۶: داده و حافظه
- Embeddings و vector search
- RAG برای بازیابی اطلاعات
- ساخت یک Chroma DB روی دادههای فارسی خودت
هفته ۷-۸: اتصال به دنیا
- Function Calling با OpenAI و Anthropic
- MCP (Model Context Protocol)
- ساخت اولین agent ساده با LangChain
هفته ۹-۱۰: Context Engineering در عمل
- پیادهسازی ۷ جزء context در یک پروژه واقعی
- ۴ راهبرد مدیریت context (Selection، Writing، Compression، Isolation)
- monitoring و debug با LangSmith
هفته ۱۱-۱۲: production و scale
- الگوهای Anthropic (Compaction، Note-taking، Sub-agent)
- caching و کاهش هزینه
- error handling و recovery
میخواهی از پرامپتنویسی به Context Engineering ارتقاء پیدا کنی؟
دوره جامع آکادمی متین لبخندق — هم اصول پرامپت، هم RAG، هم AI Agent، هم Context Management.
مشاهده سرفصلهای دورهسوالات متداول
Context Engineering چیست؟
تفاوت Context Engineering با Prompt Engineering چیست؟
چه کسی اصطلاح Context Engineering را ابداع کرد؟
هفت جزء context چیست؟
بزرگترین مشکل context window چیست؟
آیا Prompt Engineering مرده است؟
چهار راهبرد اصلی مدیریت context چیست؟
Context Engineering چه ربطی به MCP و RAG دارد؟
جمعبندی
نکات کلیدی این مقاله
- Context Engineering = طراحی سیستمی که context درست را در زمان درست به مدل میدهد
- اصطلاح را Tobi Lütke (Shopify) در ۱۹ ژوئن ۲۰۲۵ ابداع کرد و Karpathy معروف کرد
- ۷ جزء context: System Prompt، User Prompt، History، Memory، RAG، Tools، Output
- ۴ راهبرد مدیریت: Selection، Writing، Compression، Isolation
- ۷۲٪ از iterationهای ناموفق agent بهخاطر context ناقص است، نه ضعف مدل
- «Lost in the Middle» مهمترین تلهی context window بزرگ است
- Prompt Engineering همچنان ضروری است، Context Engineering یک سطح بالاتر
- در فارسی این حوزه تقریباً پنجرهی فرصت خالی است — فقط ۱ سال جلوتر باش
اگر یک کار از این مقاله برداری، این باشد: یک agent ساده با ۷ جزء context طراحی کن. حتی اگر سهتای آنها فعلاً empty باشند. این تمرین، ذهنیت تو را از «نوشتن یک پرامپت خوب» به «طراحی یک سیستم خوب» عوض میکند. این تفاوت بین کسی است که از AI استفاده میکند و کسی که با AI میسازد.
