تصور کنید در میانه یک پروژه پیچیده کدنویسی هستید و ناگهان دستیار هوش مصنوعی شما اعلام میکند که دیگر نمیتواند پیامهای جدید را بپذیرد چون حافظهاش پر شده است. این بنبست فنی، بزرگترین چالش فعلی برای توسعهدهندگانی است که از عاملهای کدنویسی (Coding Agents) استفاده میکنند.
در معماری ترنسفورمر (Transformer) — که شبیه به میز کاری است که فقط فضای محدودی برای باز کردن کاغذها دارد — مفهومی به نام پنجره زمینه (Context Window) وجود دارد. این پنجره در واقع محدودیت فیزیکی چیزی است که مدل هنگام تولید پاسخ میتواند «ببیند». برای ابزارهایی مثل Pi، Claude Code یا Codex، این پنجره یک گلوگاه حیاتی است. وقتی تاریخچه پیامها، فراخوانی ابزارها و پاسخها از این ظرفیت فراتر رود، مدل LLM بهسادگی درخواست را رد میکند و جریان بهرهوری در میانه راه متوقف میشود.
این مشکل در گردشکارهای عاملمحور (Agentic) یک مبارزه جهانی است. هرچه بیشتر کار میکنید، هر نتیجهای که از یک ابزار گرفته میشود و هر پاسخ دستیار، حجم پرامپت را گسترش میدهد. در نهایت، سیستم به سقفی میرسد که در آن دیگر نمیتواند ابتدای گفتگو را «ببیند» و خطای معروف «Request exceeds maximum size» ظاهر میشود. برای مدیریت بهینه این دسترسیها، استانداردسازی دسترسی امن عاملها به کدبیس گام مهمی در جهت بهبود تعامل مدل با محیط توسعه بوده است.
درک مفهوم «چرخه گفتگو» (Conversation Turn)
برای درک اینکه چرا این اتفاق میافتد، باید به ساختار یک درخواست در عاملهای کدنویسی نگاه کنیم. یک درخواست اولیه معمولاً شامل پرامپت سیستمی، فایلهای بارگذاریشده (مانند AGENTS.md)، تعاریف ابزارها و اولین پیام کاربر است: [system][tools][user].
اگر مدل LLM یک فراخوانی ابزار (Tool Call) برگرداند، برنامه عامل آن را اجرا کرده و درخواست جدیدی میفرستد که شامل کل تاریخچه گفتگو و نتایج ابزار است. یک چرخه تنها زمانی به پایان میرسد که دستیار خروجی نهایی خود را تکمیل کند. این توالی به این شکل است: [system][tools][user][assistant: tool call][tool result][assistant].
هر پیام بعدی کاربر، این زنجیره را گسترش میدهد. تا درخواست دوم، پرامپت بهطور قابل توجهی بزرگتر شده است: [system][tools][user][assistant: tool call][tool result][assistant][user].
به نقل از تحلیل فنی منتشر شده در ۱۳ اوت ۲۰۲۶ در وبسایت earendil.com، سامانه Pi برای حل این معضل از فرآیندی به نام «فشردهسازی» (Compaction) استفاده میکند. در لحظهای که سرریز زمینه (Context Overflow) رخ میدهد، دو راه وجود دارد: یا شروع یک گفتگوی جدید و خالی، یا ایجاد یک نمایش کوچکتر از زمینه. شروع مجدد باعث حذف تاریخچه و تصمیمات قبلی میشود، هرچند گاهی مفید است زیرا عملکرد مدلهای زبانی معمولاً با افزایش اندازه زمینه کاهش مییابد. اما Pi فشردهسازی را انتخاب کرده است تا گفتگو را تداوم بخشد.
سازوکار فشردهسازی در Pi
این فرآیند زمانی که ظرفیت پنجره متنی به سقف خود نزدیک شود بهطور خودکار فعال میشود، هرچند کاربران میتوانند با دستور /compact آن را دستی اجرا کنند. Pi پس از پایان هر چرخه، وضعیت فشردهسازی خودکار را بررسی میکند، اما اگر در میانه یک چرخه با خطای سرریز زمینه مواجه شود، ممکن است در همان لحظه عملیات فشردهسازی را انجام دهد.
منطق این سیستم بر سه محور است:
- بودجهبندی توکنها: Pi مقدار مشخصی از پیامهای اخیر را دستنخورده نگه میدارد — که در حال حاضر بهطور پیشفرض ۲۰,۰۰۰ توکن (Token) است. این مقدار معمولاً ۵ تا ۲۰ چرخه گفتگو را پوشش میدهد و این پیامهای اخیر بدون تغییر باقی میمانند.
- سریالسازی: تمام پیامهای قدیمیتر از این نقطه برش، استخراج شده و برای خلاصهسازی سریالسازی میشوند. ساختار از حالت
[system + tools][older turns][recent retained messages]به یک حالت فشرده تغییر میکند. - تغییر مدل: Pi تاریخچه را به یک درخواست مستقل با یک پرامپت سیستمی متفاوت میفرستد. در اینجا بهجای «دستیار خبره کدنویسی»، یک «دستیار خلاصهساز زمینه» فراخوانی میشود.
این پرامپت تخصصی درخواست میکند: «یک خلاصه ساختاریافته از این شاخه گفتگو برای استفاده به عنوان زمینه در بازگشتهای بعدی تهیه کن». این خلاصه به سه بخش مشخص تقسیم میشود: اهداف (Goals)، پیشرفتها (Progress) و تصمیمات کلیدی (Key Decisions). از آنجا که این یک درخواست مستقل است و از تاریخچه موجود گفتگو استفاده نمیکند، Pi میتواند از یک مدل LLM متفاوت و مقرونبهصرفهتر برای خلاصهسازی استفاده کند، بدون اینکه کیفیت گفتگو در جلسه اصلی تحت تأثیر قرار گیرد.
اثر بر عملکرد و هزینه
خلاصه تولید شده بهصورت متن ساده ذخیره شده و به جلسه اضافه میشود. ساختار جدید به این شکل است: [system][tools][summary][recent turns][new user message]. این ساختار باعث میشود زمینه فشردهشده «قابل انتقال» (Portable) باشد و کاربر بتواند مدل را در محیط Pi تغییر دهد در حالی که خلاصه تاریخچه دستنخورده باقی میماند. در همین راستا، پروتکل MCP در Segue نیز تلاش کرده است تا حافظه مشترک و انتقال زمینه را میان دستیارهای مختلف تسهیل کند.
با این حال، یک سبکسنگین کردن (Trade-off) در مورد حافظه پنهان پرامپت (Prompt Caching) وجود دارد. ارائهدهندگان مدلها از کشینگ برای کاهش هزینههای درخواستهای تکراری از طریق تطبیق پیشوندهای دقیق استفاده میکنند. در یک جلسه فعال، سیستم برای زمینهای که قبلاً توسط مدل تولید شده، هزینه کمتری پرداخت میکند.
چون فشردهسازی پیشوند گفتگو را تغییر میدهد، کش موجود را میشکند. چرخههای حفظشده حاوی همان توکنها هستند، اما اکنون بعد از یک پیشوند متفاوت (خلاصه) قرار دارند. بنابراین، وضعیت کششده قبلی آنها قابل استفاده نیست و هر توکن بعد از خلاصه جدید باید در اولین درخواست پس از فشردهسازی دوباره محاسبه شود.
برای توسعهدهنده، این یعنی یک تأخیر (Latency) کوتاه در پاسخ اولیه بعد از دستور /compact و سپس بازگشت فضای خالی برای هزاران توکن جدید. درخواستهای جدید پس از این نقطه دوباره از مزایای Prompt Caching بهرهمند خواهند شد.
این رویکرد، حافظه عامل را از یک «نسخه پیادهشده از گفتگو» به یک «گزارش مدیریتی» تبدیل میکند؛ شبیه به تحویل شیفت در یک محیط حرفهای که فقط وضعیت ضروری و کارهای حلنشده منتقل میشوند.
علاوه بر این، Pi با گسترشپذیر کردن پرامپت فشردهسازی، به کاربران اجازه میدهد افزونههای سفارشی بسازند تا نحوه خلاصهسازی تاریخچه جلسات خود را بازتعریف کنند. این قابلیت در واقع به کاربر اجازه میدهد حافظه بلندمدت عامل را مطابق نیاز خود تنظیم کند.
گام بعدی شما
- اگر از ابزارهای کدنویسی AI استفاده میکنید، دستورات مدیریت حافظه مثل
/compactرا در گردشکار خود بگنجانید تا از توقف ناگهانی جلسات جلوگیری کنید. - در طراحی عاملهای شخصی، از مدلهای ارزانتر برای خلاصهسازی تاریخچه (Summarization) استفاده کنید تا هزینه استنتاج را کاهش دهید.
- بررسی کنید که آیا ابزار شما امکان تعریف «قالب خلاصهسازی» را میدهد تا تصمیمات کلیدی پروژه شما حذف نشوند.
اما داستان سختافزاری این تحول و نحوه مدیریت KV Cache در مقیاس بزرگ حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو