«مهندسی زمینه» Context Engineering چیست؟

مهندسی زمینه در عامل‌های کدنویسی (Coding Agents)

مهندسی زمینه (Context Engineering) شاخه‌ای نسبتاً جدید در توسعه عامل‌های هوشمند مبتنی بر مدل‌های زبان بزرگ است که بر انتخاب و سامان‌دهی محتوایی متمرکز است که مدل در هر مرحله‌ی پردازش می‌بیند. به عبارت دیگر، هدف این است که مدل LLM را صرفاً با پرسش‌ها و پاسخ‌های دقیق (مهندسی پرامپت) راضی نکنیم، بلکه اطلاعات مرتبط بیرونی (مانند مستندات فنی، کدهای مرتبط، حافظه مکالمه و ابزارها) را هم به او بدهیم تا عملکرد بهتری ارائه دهد. در یک تعریف شناخته‌شده، شرکت Anthropic مهندسی زمینه را «مجموعه‌ای از راهبردها برای گزینش و نگهداری مجموعه‌ی بهینه‌ای از توکن‌ها (اطلاعات) در زمان استنتاج مدل» می‌داند. به عبارت دیگر، مهندسی زمینه هنر و دانش این است تا در هر لحظه تنها دقیقاً همان اطلاعات مهم را در پنجره‌ی زمینه‌ی محدود مدل قرار دهیم تا نتیجه‌ی مورد نظر ما حاصل شود.

مهندسی پرامپت معمولاً به نوشتن دقیق و ساختاربندی دستورات برای مدل می‌پردازد، در حالی که مهندسی زمینه مربوط به طراحی سامانه‌ای است که اطلاعات مناسب را در زمان مناسب به مدل می‌رساند. به عبارت دیگر، اگر مهندسی پرامپت مشخص می‌کند «چه چیزی را بپرسیم»، مهندسی زمینه تضمین می‌کند که مدل در کدام دنیای اطلاعاتی به پرسش پاسخ می‌دهد. در تصویر بالا می‌بینیم که در شیوه‌ی سنتی تنها پرامپت مطرح می‌شود، اما در رویکرد مهندسی زمینه مدل علاوه بر پرامپت، به «کتاب درسی» تکمیل‌کننده (مثلاً مستندات) و حافظه‌ی مکالمه و ابزارهای کمکی نیز دسترسی دارد. این تفاوت ساختاری باعث می‌شود پاسخ‌های مدل معنادارتر و دقیق‌تر باشد.

شبکه‌های اجتماعی رسانه هوش مصنوعی سیمرغ

نقش و اهمیت مهندسی زمینه

مدل‌های زبان بزرگ علی‌رغم قدرتمندی‌شان، توانایی توجه محدودی دارند؛ یعنی نمی‌توانند با دقت نامحدودی به تمام اطلاعاتی که در پنجره‌ی زمینه‌شان می‌گنجد توجه کنند. مطالعات نشان داده که با افزایش تعداد توکن‌های ورودی، توانایی مدل در بازیابی اطلاعات دقیق افت می‌کند (پدیده‌ای که به «افول زمینه» شناخته می‌شود). این موضوع شبیه محدودیت حافظه‌ی کاری انسان است: هر چه حجم اطلاعات بیشتر باشد، «بودجه توجه» کمتر در دسترس مدل قرار می‌گیرد. بنابراین پنجره‌ی زمینه یک منبع محدود به شمار می‌آید و ورود هر توکن جدید سهمی از آن بودجه توجه را می‌بلعد.

این محدودیت به شکل‌های مختلفی در کارایی عامل‌های کدنویسی تأثیر می‌گذارد. اگر اطلاعات غیرمرتبط یا بیش از حد در زمینه وارد شود، عامل ممکن است گمراه شود یا یادش رود که هدف اصلی چیست؛ همچنین هزینه‌ی محاسباتی زیاد (مانند تاخیر بیشتر و مصرف منابع) به بار می‌آید. به همین دلیل است که در مهندسی زمینه باید دقیقاً همان داده‌های با‌اهمیتی را نگه داریم که احتمالاً به پاسخ درست منتهی می‌شوند. به عنوان مثال، اسپاتیفای گزارش کرده که «طراحی دقیق زمینه برای عامل‌های کدنویسی ضروری است تا بتوانند درخواست‌های تغییر کد قابل اتکا و قابل ادغام تولید کنند». در واقع، تفاوت یک مدل نمایشی و یک سیستم کاربردی، در انتخاب، ساختاردهی و ارائه اطلاعات به مدل نهفته است. به عبارت دیگر، مهندسی زمینه یعنی شناختن محدودیت «پنجره‌ی زمینه»، و طراحی مکانیسم‌هایی همچون بازیابی اطلاعات، حافظه بلندمدت و ابزارهای خارجی که مدل را روی توکن‌های با‌اهمیت متمرکز کند.

انواع اطلاعات زمینه‌ای و روش‌های تأمین آن‌ها

اطلاعات زمینه‌ای متنوعی وجود دارد که می‌تواند به عامل کدنویسی داده شود. برخی از مهم‌ترین انواع آن عبارتند از:

• دستورالعمل‌ها و پرامپت‌های سیستم: این دسته شامل توضیح وظیفه، قوانین و الگوریتم‌های مد نظر است که مستقیماً به مدل گفته می‌شود چه کار کند یا از چه اصولی تبعیت کند. به عنوان مثال، می‌توان یک فایل کلی (مثل CLAUDE.md در Claude Code) داشت که قوانین و الگوهای کلی پروژه را شرح می‌دهد.
• فایل‌ها و کد پروژه: خواندن محتوای فایل‌های سورس، کتابخانه‌ها و مستندات پروژه منبع اصلی زمینه است. به گفته Fowler، «خواندن و جستجوی فایل‌های موجود در محیط کاری، بنیادی‌ترین و قدرتمندترین رابط‌های زمینه برای عامل‌های کدنویسی هستند». به عبارتی عامل باید امکان دسترسی به کد منبع و فایل‌های پروژه را داشته باشد تا بر اساس ساختار واقعی نرم‌افزار تصمیم بگیرد.
• ابزارها (Tools) و سرورها: ابزارهایی مانند اجرای دستورات خط فرمان، جستجوی کد (grep یا GPT-based search)، کامپایلر و غیره، واسط‌های زمینه‌ای مهمی هستند. علاوه بر این، سرورهای MCP (Model Context Protocol) امکان اجرای اسکریپت‌ها یا فراخوانی API‌های خارجی را برای عامل فراهم می‌کنند. به عنوان نمونه، می‌توان یک سرور ساده نوشت که از طریق MCP به پایگاه داده یا سرویس‌های خارجی وصل شود تا عامل اطلاعات خاصی را دریافت کند.
• مهارت‌ها (Skills): مهارت‌ها مجموعه‌ ای از منابع (راهنماها، اسکریپت‌ها، مستندات) هستند که مدل بر اساس نیاز کاری به صورت «تن‌درست» (lazy load) آن‌ها را بارگذاری می‌کند. برای مثال، می‌توان مهارتی تعریف کرد که در صورت نیاز مدل به نسخه‌برداری از داده، فایل SKILL.md مربوط به نحوه کار با ابزار JIRA را بارگذاری کند.
• حافظه مکالمه: تاریخچه گفتگوها و نتایج قبلی عامل در جلسه می‌تواند به صورت زمینه به کار رود. یعنی پیام‌های پیشین و نتیجه دستورهای قبلی در حافظه نگهداری و در صورت نیاز دوباره در ورودی گنجانده شود. این حافظه به هم‌پیوستگی و تداوم وظایف چند مرحله‌ای کمک می‌کند.
• بازیابی اطلاعات (Retrieval): سیستم‌های RAG (Retrieval-Augmented Generation) یا موتورهای جستجوی معنایی، برای یافتن کدها، مستندات و داده‌های مرتبط به کار می‌روند. به کمک جستجوی برداری (مانند Elasticsearch+embeddings) می‌توان فایل‌ها یا مثال‌های کد مرتبط با مسئله را به مدل ارائه داد. بدین ترتیب به جای ارسال کل پروژه، تنها بخش‌های مرتبط زمینه مدل می‌شود.

مدل در مرکز قرار دارد و اجزای مهم مانند مستندات، حافظه مکالمه و ابزارها با فلش‌های داده به آن متصل هستند. تصویر بالا چشم‌اندازی کلی از فرآیند مهندسی زمینه را نشان می‌دهد. در مرکز، مدل زبان بزرگ قرار گرفته و منابع مختلف (فایل‌های کد، مستندات، پایگاه‌داده حافظه و…) به آن متصل‌اند. فلش‌ها نحوه‌ی جریان داده‌ها به داخل پنجره‌ی زمینه‌ی مدل را نمایش می‌دهند؛ به عنوان مثال فایل‌های پروژه با اسکریپت‌های ابزار به مدل خوانده می‌شوند و از نتایج هر گام نیز در حافظه مکالمه نگهداری می‌شود.

مکانیزم‌های بارگذاری زمینه

از نظر نحوه‌ی بارگذاری اطلاعات زمینه، سه حالت کلی وجود دارد:

• تصمیم مدل (LLM): در این حالت خود مدل تشخیص می‌دهد که چه زمانی اطلاعات زمینه را بارگذاری کند. برای مثال در زبانکلاد (Claude Code) می‌توان مهارت‌هایی تعریف کرد که مدل هنگام لزوم آن‌ها را فراخوانی کند. این روش کاملاً خودکار عمل می‌کند و برای عامل‌های بدون نظارت مفید است، اما گاهی نتیجه‌ی بارگذاری کنترل‌ناپذیر و غیرقطعی خواهد بود.
• عمل کاربر (انسان): کاربر با دستورهای ویژه یا کنش‌های دستی، زمینه را وارد می‌کند. مثلاً ممکن است در یک محیط عامل‌نویس کامند /run-tests بنویسد تا فایل‌های مربوط به تست بارگذاری شوند. این روش اختیار بیشتری به توسعه‌دهنده می‌دهد اما از سوی دیگر انعطاف خودکار عامل را کاهش می‌دهد.
• نرم‌افزار عامل: خود عامل در نقاط از پیش تعریف‌شده و به صورت خودکار اقدام به بارگذاری می‌کند. مثلاً در ابزارهایی مانند Claude Code معمولاً در ابتدای جلسه یا وقتی فایل جدیدی باز می‌شود، قواعد کلی پروژه به مدل داده می‌شود. در این روش عامل می‌داند که در چه زمانی باید اطلاعات خاصی را وارد نماید و عملکرد آن تعیین‌شده است.

چالش‌ها

مهندسی زمینه با چند چالش مهم همراه است. نخست محدودیت اندازه‌ی پنجره زمینه است. هرچه اطلاعات بیشتری وارد این پنجره شود، علاوه بر هزینه‌ی محاسباتی بیشتر، مدل تمرکز خود را از دست می‌دهد. هم‌چنین در عمل مشکلاتی مانند زیر رخ می‌دهد:

• زمینه‌زایی یا آلودگی (Context Poisoning): اگر اطلاعات نادرست یا توهم‌آمیز وارد زمینه شود، عامل آن را بازتولید کرده و به اشتباهات پیشین ادامه می‌دهد.
• حواس‌پرتی (Context Distraction): افراط در ارائه داده‌های تاریخچه یا ابزارهای قبلی موجب می‌شود مدل بار اطلاعات قدیمی را تحمل کند و بر پاسخ تازه تمرکز نکند.
• تداخل یا ابهام (Context Confusion/Clash): وجود داده‌های ناهمخوان یا متضاد در زمینه، مدل را گیج می‌کند و ممکن است باعث برگشت به فرض‌های نادرست شود.
• شفافیت: بسیاری از سیستم‌ها ابزار کاملی برای نشان دادن میزان اشغال پنجره و محتوای دقیق آن ندارند. Fowler تأکید می‌کند که «شفاف بودن درباره‌ی این‌که چه چیزهایی در زمینه بارگذاری شده و چه‌قدر فضا اشغال می‌کند»، برای مدیریت این توازن بسیار حیاتی است.
• هزینه محاسباتی: استفاده از پنجره‌های بزرگ هزینه‌ی محاسبات (و در موارد ابری، هزینه مالی) را افزایش می‌دهد. همان‌طور که Fowler می‌گوید، «اثرگذاری عامل با دریافت زمینه‌ی زیاد کاهش می‌یابد، و بیش از حد بودن زمینه به‌طرز چشمگیری هزینه‌بر است».

بنابراین در طراحی سیستم، باید بین میزان زمینه‌ی مفید و هزینه‌های ناشی از آن تعادل برقرار کرد. هر راهکار و ابزار مهندسی زمینه باید توازنی میان دقت اطلاعات ورودی و حجم آن‌ها رعایت کند تا بیشترین بهره را از بودجه توجه مدل ببرد.

نکات عملی برای طراحی زمینه‌ی مؤثر

برای طراحی مؤثر زمینه در عامل‌های کدنویسی می‌توان به نکات زیر توجه کرد:

• وضوح و سادگی دستورالعمل‌ها: دستورالعمل‌های سیستم (system prompt) را تا حد ممکن واضح، کوتاه و دقیق بنویسید. اطلاعات اضافی یا پیچیده را در پرامپت اولیه نریزید؛ در عوض مفاهیم کلیدی را با زبان ساده بیان کنید تا عامل بداند دقیقاً چه انتظاری از آن می‌رود.
• ارائه مثال‌های واضح: هنگام تعریف وظیفه، چند مثال کد یا ورودی-خروجی ارائه کنید تا مدل بهتر بفهمد چه نتایجی مطلوب است. مثال‌های عملی و مشخص، بسیار مؤثرتر از توضیحات کلی هستند.
• هدف قابل سنجش تعیین کنید: به جای توصیف کلی (مثلاً «کد را بهتر کن»)، هدف را به شکل قابل آزمون بیان کنید؛ مثلاً با اضافه کردن دستور تولید تست که هنگام کامل شدن وظیفه صدق می‌کند. این کار به عامل اجازه می‌دهد نتایج خود را ارزیابی و تصحیح کند.
• یک کار در یک زمان: از پرس‌وجوهای بزرگ و چندمرحله‌ای پرهیز کنید. تلاش برای ادغام چند تغییر مرتبط در یک دستور طولانی، احتمال خطا را بالا برده و پنجره‌ی زمینه را سریع‌تر اشباع می‌کند. بهتر است هر تغییر را به صورت یک وظیفه جداگانه مطرح کنید.
• گرفتن بازخورد از عامل: بعد از اجرای یک دستور، از خود عامل بخواهید نظر یا خطاهای احتمالی را بازخورد بدهد. گاهی مدل می‌تواند بگوید در پرامپت چه چیزی کم یا نامشخص بوده و با توجه به آن می‌توان پرامپت را بهبود داد.
• توسعه تدریجی زمینه: به توصیه Fowler، به جای وارد کردن ناگهانی تمام اطلاعات، زمینه را کم‌کم بسازید. مثلاً ابتدا چند قانون کلی (مانند قواعد نام‌گذاری) را تعریف کنید و در ادامه مطالب اضافی را اضافه کنید تا از هدر رفت توکن‌های زمینه جلوگیری شود.
• استفاده از بازیابی اطلاعات: در صورت امکان، به جای ارسال کل کد و مستندات به مدل، از روش‌های بازیابی (مثل RAG) استفاده کنید. به عنوان مثال یک موتور جستجوی برداری می‌تواند فایل‌ها یا مثال‌های مرتبط را شناسایی کرده و تنها آن‌ها را به مدل بدهد. این کار کمک می‌کند زمینه‌ی دقیق‌تر و بهینه‌تری فراهم شود.
• بهره‌گیری از قابلیت‌های موجود: از امکانات خاص پلتفرم‌ها استفاده کنید. مثلاً در Claude Code می‌توانید مهارت بسازید یا دستورهای ویژه (Slash Command) تعریف کنید؛ در Copilot می‌توانید از Spaces برای جمع‌آوری مستندات پروژه استفاده نمایید. با شناخت ویژگی‌های ابزار می‌توان روند کار را بهینه‌تر کرد.

وضعیت فعلی در ابزارهای شاخص

ابزارهای کدنویسی هوش مصنوعی ویژگی‌های متفاوتی برای مهندسی زمینه ارائه می‌دهند. در جدول زیر چند نمونه‌ی شاخص و امکاناتشان خلاصه شده است:

چشم‌انداز آینده

روندهای پژوهشی و صنعتی نشان می‌دهد که مهندسی زمینه همچنان رو به تکامل است. یکی از پیشرفت‌های مهم، ادغام حافظه‌ی بلندمدت در معماری عامل‌ها است؛ به این معنی که اطلاعات مهم پروژه در پایگاه‌های داده‌ی خارجی ذخیره شده و در تعاملات بعدی بازیابی می‌شود (حافظه‌ای شبیه یک دفترچه یادداشت دائمی). همچنین تکنیک‌هایی مانند خلاصه‌سازی گفتگو (note-taking) و فشرده‌سازی زمینه برای نگه داشتن نکات کلیدی در تعاملات طولانی‌مدت مطرح هستند. علاوه بر این، معماری‌های چندعاملی (چندسهمی) محبوبیت یافته‌اند؛ به طوری که یک هدف بزرگ ممکن است توسط چند عامل کوچکتر به‌طور موازی حل شود.

همچنین Anthropic اشاره کرده که با پیشرفت مدل‌ها، نیاز به مهندسی صریح پرامپت کاهش می‌یابد اما زمینه همچنان یک منبع ارزشمند باقی می‌ماند. به تعبیر آن‌ها، «هرچند مدل‌های هوشمند آینده کمتر نیاز به مهندسی صریح دارند، ولی همواره باید زمینه را به عنوان منبعی ارزشمند مدیریت کرد». در کل، انتظار می‌رود عامل‌های کدنویسی آینده از خودکارسازی بیشتر (مانند یادگیری از بازخورد خود) و گسترش پنجره‌های زمینه با الگوریتم‌های هوشمند (مثلاً از طریق RAG و فشرده‌سازی داینامیک) بهره‌مند شوند، و هماهنگی با حافظه و زیرعامل‌ها (Subagents) از عناصر کلیدی معماری‌های نوین باشد.