اگر دستورالعمل‌های عامل هوشمند شما مانند یک لیست خرید بی‌پایان رشد می‌کند، احتمالاً در حال تجربهٔ «رانش زمینه» هستید. این وضعیت زمانی رخ می‌دهد که حجم داده‌های ورودی به قدری زیاد شود که مدل دیگر نتواند اولویت‌ها را تشخیص دهد.
Rulestack — یک خط لولهٔ نشر خودکار که به عامل خود اجازه می‌دهد قوانین عملیاتی‌اش را در فایلی به نام CLAUDE.md مدیریت کند — با این چالش روبرو شد. این رویکرد در راستای بهینه‌سازی تعامل با مدل‌های زبانی است، مشابه آنچه در بررسی قابلیت‌های Claude Code برای خودکارسازی کارهای نگهداری کد مشاهده کردیم. طبق گزارشی که در ۲۷ اوت ۲۰۲۶ منتشر شد، این تیم دریافت که یک فایل دستورالعمل با حجم ۵۴۸ کیلوبایت برای یک عامل (Agent) — شبیه دستیاری که دستورات زیادی را هم‌زمان در ذهن دارد و گیج می‌شود — بیش از حد بزرگ است و باعث می‌شود مدل نتواند قوانین را به‌طور قابل‌اعتماد اجرا کند.
بسیاری از توسعه‌دهندگان با دستورالعمل‌ها مانند یک چک‌لیست برخورد می‌کنند؛ هر زمان مشکلی پیش می‌آید، قانونی جدید به انتهای فایل اضافه می‌کنند و هرگاه انسانی اصلاحی ارائه می‌دهد، یادداشت دیگری الحاق می‌شود. این رویکرد «فقط افزودنی» (append-only) در ابتدا منطقی به نظر می‌رسد، اما در نهایت یک ویکی منسوخ ایجاد می‌کند که هوش مصنوعی آن را نادیده می‌گیرد. در مورد Rulestack، این فایل در نسخه ۳.۱۴۴ به ۵۴۸ کیلوبایت رسید؛ یعنی عامل در هر جلسه باید بیش از نیم مگابایت متن را در ابتدای هر نشست بارگذاری می‌کرد که منجر به ایجاد یک بار زمینهٔ عظیم می‌شد.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدیریت حافظه در مدل‌های زبانی اشاره کردیم، اشباع شدن پنجرهٔ زمینه (Context Window) — مثل میز کاری که از شدت شلوغی دیگر جای تکان خوردن نیست — منجر به نادیده گرفتن دستورات کلیدی می‌شود. برای مدیریت بهینه این فایل‌ها، می‌توان از الگوهای استاندارد CLAUDE.md برای جلوگیری از تخریب کدهای مشترک بهره برد تا ساختار دستورالعمل‌ها از ابتدا منظم باشد.
برای حل این مشکل و جلوگیری از رانش زمینه، تیم Rulestack سه محدودیت مکانیکی را اجرا کرد:
۱. دروازهٔ اندازه (Size Gate)
آن‌ها یک سقف سخت ۴۵ کیلوبایتی را در مجموعه تست‌های خود ادغام کردند. اگر یک کامیت (Commit) حجم فایل را از این حد بگذارد، تست شکست می‌خورد و کامیت مسدود می‌شود. همچنین یک سیستم بررسی سلامت (Health Check) در حجم ۴۵ کیلوبایت به تیم هشدار می‌دهد و در حجم ۶۰ کیلوبایت وضعیت را به حالت هشدار قرمز درمی‌آورد تا اطمینان حاصل شود که فایل سبک باقی می‌ماند. تا اواخر اوت، حجم این فایل در سطح ۴۴,۰۰۶ بایت نگه داشته شده است.
۲. تفکیک بر اساس محرک (Trigger-Based Splitting)
به‌جای یک فایل غول‌پیکر، دستورالعمل‌ها بر اساس نحوه فعال شدن تقسیم شدند:
- فایل اصلی: فقط قوانینی که در هر جلسه لازم هستند.
- فایل‌های مهارت: ۹ فایل مجزا که فقط هنگام تطابق یک وظیفه خاص بارگذاری می‌شوند.
- فایل قوانین: استانداردهای کدنویسی که فقط هنگام تغییر مسیرهای خاص فایل فعال می‌شوند.
- پوشه مستندات (Docs/): منابع استاتیک و مرجع که هرگز تغییر نمی‌کنند.
۳. حذف اجباری
آن‌ها به‌روزرسانی‌های «فقط افزودنی» را ممنوع کردند. طبق مستندات این تیم، هرگاه یک سیاست جایگزین شود، متن قدیمی و متضاد باید در همان کامیت حذف شود. تاریخچه تغییرات — یعنی «چه زمانی و چرا» — به یک فایل مجزای changelog منتقل شده است. اکنون فایل اصلی فقط نسخه فعلی و دو مورد قبلی را نگه می‌دارد.
این تغییر، فرض بنیادی درباره حافظه عامل را دگرگون می‌کند. به‌جای تکیه بر توانایی مدل زبانی بزرگ (LLM) برای اولویت‌بندی آخرین دستور در یک لیست طولانی، توسعه‌دهنده یک «وضعیت سبک» (Lean State) را تحمیل می‌کند. این استراتژی کاهش حجم داده‌ها با رویکردهای فشرده‌سازی توکن‌ها در Claude Code برای کاهش هزینه‌های API هم‌سو است که هر دو بر بهینه‌سازی مصرف منابع تمرکز دارند. این کار بار حافظه را از دوش مدل — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — برداشته و به معماری سیستم منتقل می‌کند.
برای تیم‌هایی با چندین مشارکت‌کننده، این روش مانع از آن می‌شود که ترجیحات شخصی افراد به قوانین دائمی و سخت تبدیل شوند. با اجبار به حذف در ازای هر افزودن، تیم تضمین می‌کند که فقط منطق به‌روز و مورد توافق در زمینه فعال باقی می‌ماند.
توسعه‌دهندگان باید اکنون ارزیابی کنند که آیا فایل‌های دستورالعمل عامل‌هایشان به‌صورت خطی با رشد پروژه بزرگ می‌شود یا خیر. می‌توانید با حساب کردن تعداد توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک — در لحظه بارگذاری، متوجه شوید که آیا در حال نزدیک شدن به آستانه مشابهی از رانش هستید یا نه.
گام بعدی شما
- حجم فایل‌های
.mdیا دستورالعمل‌های سیستمی عامل‌های خود را بررسی کنید. - دستورالعمل‌های عمومی را از دستورالعمل‌های وظیفه‌محور (Task-specific) جدا کنید.
- یک قانون «یک حذف در ازای یک افزودن» برای به‌روزرسانی پرامپت‌ها وضع کنید.
اما مدیریت این حجم از داده‌ها در مقیاس سازمانی نیازمند ابزارهای پیشرفته‌تری است؛ برای درک بهتر این موضوع به تحلیل ما درباره پروتکل MCP مراجعه کنید.
گفتگو