مهندسی کانتکست برای عامل‌های AI بلندافق

در مجموع، تحلیل Arize، مقالهٔ arXiv دربارهٔ سرریز پنجرهٔ کانتکست، توضیح تولیدی Redis، و مقایسهٔ مهندسی هارنس Atlan به یک تغییر عملی در طراحی عامل اشاره می‌کنند. عامل‌های طولانی‌اجرا کمتر با اندازهٔ پنجرهٔ کانتکست مدل سنجیده می‌شوند و بیشتر با لایهٔ کنترلی اطراف آن. Arize این تغییر را ملموس می‌کند. این تحلیل ابزارهای عامل و سیستم‌های حافظه/هارنسِ عرضه‌شده، از جمله Pi، OpenClaw، Claude Code و Letta را به‌عنوان نمونه‌هایی از مهندسی کانتکست در سطح هارنس نام می‌برد و یک شبیه‌ساز تعاملی را توصیف می‌کند که پر شدن یک پنجرهٔ 200K-token را نشان می‌دهد.

جزئیات عمومی موجود در منابع استنادشده یکدست نیستند. Arize برای Pi، OpenClaw، Claude Code و Letta عددهای اجرایی مشخص ارائه می‌کند. یک مقالهٔ پژوهشی دربارهٔ حل سرریز پنجرهٔ کانتکست در عامل‌های AI سازوکاری کلی‌تر برای مدیریت خروجی‌های ابزاری ارائه می‌کند که می‌توانند از هر پنجرهٔ عملی فراتر بروند. توضیح Redis دربارهٔ سرریز پنجرهٔ کانتکست نشانه‌های تولیدی را خلاصه می‌کند: خطاهای سخت API، افت کیفیت خاموش، انباشت خروجی ابزارها، و افزایش تأخیر با بزرگ‌تر شدن promptها. مقایسهٔ Atlan از مهندسی prompt، کانتکست و هارنس استعارهٔ مفید پشته را فراهم می‌کند: مهندسی prompt پیام را شکل می‌دهد، مهندسی کانتکست چیزی را که مدل می‌بیند شکل می‌دهد، و مهندسی هارنس کل محیط عامل را شکل می‌دهد.

خبر مهم این نیست که پنجره‌های کانتکست بیش از حد کوچک‌اند. سازندگان همین حالا هم این را می‌دانند. نکتهٔ مفیدتر این است که سیستم‌های عاملِ استنادشده دارند روی چهار سازوکار هارنس همگرا می‌شوند که بعد از آنکه transcript دیگر منبع امن حقیقت نیست، کار را زنده نگه می‌دارند.

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

راهی تمیزتر برای خواندن نخستین مجموعهٔ محدودیت‌ها این است:

• Pi: خواندن فایل در 2,000 خط یا 50KB، هرکدام زودتر برسد، متوقف می‌شود. محتوای برگشتی شامل یک راهنمای ادامه است که به مدل می‌گوید کدام بازهٔ خط نمایش داده شده و چگونه با offset و limit ادامه دهد. OpenClaw این رفتار را به ارث می‌برد، سپس سقف‌های جداگانه اضافه می‌کند: فایل‌های bootstrap به 12,000 نویسه برای هر فایل و 60,000 نویسه در مجموع محدود می‌شوند. نتایج ابزارها بودجهٔ دیگری می‌گیرند: 16,000 نویسه یا 30% از پنجرهٔ کانتکست، هرکدام کوچک‌تر باشد.

Claude Code از طراحی دو دروازه‌ای استفاده می‌کند. طبق Arize، پیش از باز کردن یک فایل سقف 256KB بایتی را بررسی می‌کند، سپس پس از خواندن، نتیجه را در برابر بودجهٔ 25,000-token با شمارش token می‌سنجد. حتی برای فایل‌هایی که زیر سقف‌اند، به‌صورت پیش‌فرض 2,000 خط از ابتدا را برمی‌گرداند و خط‌های طولانی‌تر از 2,000 نویسه را کوتاه می‌کند. اگر مدل همان بازهٔ فایل را دوباره بخواند و فایل تغییر نکرده باشد، Claude Code می‌تواند به‌جای تکرار محتوای کامل، یک stub برگرداند.

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

الگوی بعدی این است که با کانتکست مثل یک viewport رفتار کنید، نه فضای ذخیره‌سازی.

Pi و Claude Code صفحه‌بندی را از طریق offset و limit در دسترس می‌گذارند. OpenClaw در بعضی جاها کوتاه‌سازی head/tail را اضافه می‌کند و وقتی احتمال اهمیت بخش میانی کمتر است، ابتدا و انتها را نگه می‌دارد. Arize می‌گوید OpenClaw برای فایل‌های bootstrap بیش‌ازحد بزرگ از تقسیم 75% head / 25% tail استفاده می‌کند و ممکن است برای نتایج ابزار هم head و هم tail را نگه دارد، وقتی tail مهم به نظر می‌رسد؛ مثل خطاها، آکولادهای بسته‌شوندهٔ JSON یا کلیدواژه‌های شبیه خلاصه.

Letta با خارج نگه داشتن فایل‌ها از prompt یک قدم جلوتر می‌رود. فایل‌های آپلودشده parse، chunk و در یک vector store جاسازی می‌شوند و به عامل امکان مشاهدهٔ مستقیم، جست‌وجوی دقیق و جست‌وجوی معنایی می‌دهند. وقتی فایلی در کانتکست باز است، Letta یک نمای مدیریت‌شده نشان می‌دهد که اندازه‌اش با کانتکست مدل مقیاس می‌گیرد: 5,000 نویسه برای کانتکست 8K، 15,000 برای 32K، 25,000 برای 128K، و 40,000 برای 200K+. تعداد فایل‌های هم‌زمان باز هم مقیاس می‌گیرد؛ از 3 برای مدل‌های کوچک تا 15 برای مدل‌های بسیار بزرگ، با یک سیاست LRU که فایل‌هایی را که کمترین دسترسی اخیر داشته‌اند بیرون می‌اندازد.

این همان ایدهٔ طراحی پشت RAG تولیدی است: کل corpus را در prompt نریزید؛ بخشی را بازیابی کنید که اهمیت دارد. تفاوت این است که هارنس‌های عامل باید این کار را به‌طور پیوسته انجام دهند، در سراسر فایل‌ها، خروجی ابزارها، حافظه و برنامه‌های میانی. همین محدودیت برای سیستم‌های RAG هم برقرار است: بازیابی فقط دربارهٔ مرتبط بودن نیست، بلکه دربارهٔ حفظ بودجهٔ کافی کانتکست برای مرحلهٔ واقعی استدلال هم هست.

Redis نکتهٔ مرتبطی مطرح می‌کند: پنجره‌های کانتکست بزرگ‌تر نیاز به مدیریت کانتکست را حذف نمی‌کنند. promptهای سیستم، اسناد بازیابی‌شده، تاریخچهٔ گفتگو و خروجی ابزارها همگی برای همان فضای واحد رقابت می‌کنند. حتی پیش از رسیدن به یک حد سخت، وقتی اطلاعات مرتبط در ورودی‌های طولانی دفن می‌شود، مدل‌ها می‌توانند افت کنند.

سرریز شکست آشکار است. گم‌شدن هدف بی‌صداتر است. عامل هنوز جا برای پاسخ دادن دارد، اما هدف اصلی را فراموش می‌کند، یک محدودیت را از دست می‌دهد، یا شروع می‌کند به بهینه‌سازی یک زیروظیفهٔ محلی.

اینجاست که فشرده‌سازی اهمیت پیدا می‌کند. اگر بد انجام شود، خلاصه‌سازی یک تاریخچهٔ آشفته اما وفادار را با داستانی مرتب اما پُراتلاف جایگزین می‌کند. اگر خوب انجام شود، وضعیت وظیفه، کار اخیر، موارد معلق و یکپارچگی فراخوانی ابزار را حفظ می‌کند.

Arize گزارش می‌دهد که Pi وقتی tokenهای تخمینی کانتکست از پنجرهٔ کانتکست منهای tokenهای رزرو فراتر می‌روند، فشرده‌سازی را فعال می‌کند؛ با رزرو پیش‌فرض 16,384 token. حدود 20,000 token اخیر را نگه می‌دارد و محتوای قدیمی‌تر را در یک پیام کاربرِ مصنوعی خلاصه می‌کند که پیش از tail نگه‌داشته‌شده قرار می‌گیرد. همچنین از بریدن در میانهٔ جفت‌های فراخوانی ابزار/نتیجهٔ ابزار پرهیز می‌کند.

OpenClaw یک سیاست تاریخچهٔ تهاجمی‌تر اضافه می‌کند. وقتی تاریخچه از 50% پنجرهٔ کانتکست فراتر می‌رود، پیام‌ها را به chunkهای token با جرم برابر تقسیم می‌کند، قدیمی‌ترین chunk را حذف می‌کند، محتوای حذف‌شده را از طریق خلاصه‌سازی مرحله‌ای چندمرحله‌ای خلاصه می‌کند، و جفت‌سازی فراخوانی ابزار/نتیجه را ترمیم می‌کند. همچنین یک flush پیش از فشرده‌سازی انجام می‌دهد: یک نوبت agentic خاموش به عامل فرصت می‌دهد پیش از ناپدید شدن تاریخچه، وضعیت را در فایل‌های حافظه پایدار کند. جداگانه، نتایج ابزار را در حافظه با رفتار soft-trim و hard-clear روی TTL کش 5 دقیقه‌ای هرس می‌کند.

Claude Code نزدیک انتهای پنجره فشرده‌سازی می‌کند. Arize می‌گوید محرک آن پنجرهٔ کانتکست مؤثر منهای یک بافر 13,000-token است، که فشرده‌سازی را برای مدل 200K-context حدود 167K token قرار می‌دهد. prompt خلاصه‌سازی آن درخواست بخش‌های ساختاریافته‌ای می‌کند که درخواست اصلی، مفاهیم فنی، فایل‌ها و کد، خطاها و رفع‌ها، حل مسئله، پیام‌های کاربر، وظایف معلق، کار فعلی و قدم بعدی را پوشش دهند. پس از فشرده‌سازی، می‌تواند تا 5 فایل اخیراً خوانده‌شده را در محدودهٔ یک بودجهٔ token دوباره متصل کند.

الگو روشن است: فشرده‌سازی «خلاصه کردن چت» نیست. چک‌پوینت‌گذاری است. یک عامل طولانی‌اجرا به معادل یک فایل ذخیره نیاز دارد: هدف، محدودیت‌ها، تصمیم‌ها، handleهای باز، شواهد اخیر و اقدام بعدی.

بعضی خروجی‌ها اصلاً نباید وارد پنجرهٔ کانتکست شوند.

مقالهٔ arXiv این را با یک گردش‌کار علم مواد ملموس می‌کند. یک ابزار برای یک مولکول ساختار شبکه‌ای الکترونیکی تولید می‌کند: یک ماتریس 3D با ابعاد 128 × 128 × 128، در مجموع 2,097,152 عنصر float32. این خروجی بسیار فراتر از پنجرهٔ کانتکست LLMهای پرکاربرد است. اما ابزار بعدی به شبکه به‌عنوان ورودی نیاز دارد.

راه‌حل پیشنهادی این است که مقدارهای بزرگ بیرون از کانتکست مدل ذخیره شوند و شناسه‌های کوتاه، یا اشاره‌گرها، برگردانده شوند. wrapperهای ابزار ورودی‌ها را بررسی می‌کنند تا ببینند مقدار خام‌اند یا مسیرهای حافظه. خروجی‌هایی که بیش از حد بزرگ‌اند در حافظهٔ زمان اجرا زیر یک مسیر ذخیره می‌شوند و ابزارهای بعدی می‌توانند اشاره‌گر را دریافت و آن را درون خود resolve کنند. مدل referenceها را دستکاری می‌کند، در حالی که هارنس دادهٔ کامل را حفظ می‌کند. طبق مقاله، در یک آزمایش مقایسه‌ای که هر دو روش موفق بودند، رویکرد مبتنی بر اشاره‌گر تقریباً هفت برابر token کمتری نسبت به گردش‌کار سنتی مصرف کرد.

این تمیزترین جداسازی بین استدلال و انتقال داده است. مدل لازم نیست یک ماتریس 2 میلیون‌عنصری را «ببیند» تا آن را به ابزار دیگری پاس بدهد. باید بداند که ماتریس وجود دارد، چه چیزی را بازنمایی می‌کند، و کدام عملیات باید در مرحلهٔ بعد آن را مصرف کند.

همین منطق فراتر از آرایه‌های علمی هم کاربرد دارد. پاسخ‌های بزرگ JSON، PDFها، logها، embeddingها، فایل‌های رسانه‌ای و خروجی‌های export پایگاه داده اغلب جای‌شان در storage است، نه در prompt. برای سیستم‌هایی که حول ابزارهای MCP یا connectorهای سفارشی API ساخته شده‌اند، پاس دادن اشاره‌گر باید یک انتخاب طراحی درجه‌اول باشد، نه وصله‌ای بعد از نخستین سرریز.

یک پنجرهٔ کانتکست 200K-token بزرگ به نظر می‌رسد، تا وقتی که یک عامل شروع به عمل کردن کند. یک prompt سیستم، تعریف‌های ابزار، چند سند بازیابی‌شده، خواندن فایل‌ها، logها، ردپاهای خطا و خلاصه‌ها می‌توانند آن را سریع‌تر از انتظار مصرف کنند. قاب عملی این نیست که پنجره روی کاغذ چقدر بزرگ به نظر می‌رسد، بلکه این است که عامل‌ها در زمان اجرا چقدر سریع آن را خرج می‌کنند. راهنمای حافظهٔ عامل Redis به‌سمت حافظهٔ خارجی و پایدار برای وضعیتی اشاره می‌کند که باید بین فراخوانی‌ها زنده بماند، در حالی که قاب‌بندی مهندسی کانتکست Atlan promptهای بهتر را از مونتاژ بهتر کانتکست جدا می‌کند. کنار هم، آن‌ها با پنجرهٔ کانتکست کمتر مثل یک انبار و بیشتر مثل یک مجموعهٔ کاری محدود برخورد می‌کنند.

درس عمیق‌تر این است که پنجرهٔ کانتکست یک منبع کمیاب زمان اجراست. برخورد با آن به‌عنوان «حافظه» مفید است، اما فقط اگر هارنس مثل یک سیستم‌عامل رفتار کند: تخصیص بدهد، بیرون بیندازد، صفحه‌بندی کند، فشرده کند، موارد تکراری را حذف کند و پایدارسازی کند. تمایز لایه‌ای Atlan اینجا مفید است. مهندسی prompt نمی‌تواند file readerای را اصلاح کند که 80,000 token نامرتبط را در فراخوانی بعدی dump می‌کند. مهندسی کانتکست می‌تواند مجموعهٔ کاری را بهبود دهد. مهندسی هارنس تصمیم می‌گیرد که آیا آن مجموعهٔ کاری اساساً محافظت می‌شود یا نه.

این همچنین نحوهٔ ارزیابی عامل‌ها توسط تیم‌ها را تغییر می‌دهد. یک prompt نمایشی کافی نیست. ارزیابی بلندافق باید شامل transcriptهای رو‌به‌رشد، خواندن‌های تکراری فایل، خروجی‌های بزرگ ابزار، فراخوانی‌های ناموفق ابزار، ادامه دادن پس از فشرده‌سازی، و وظایفی باشد که در آن‌ها قدم بعدی درست به یک محدودیت اولیه وابسته است. راهنمای ما دربارهٔ مهندسی کانتکست برای عامل‌ها نسخهٔ سمت مدلِ این مسئله را پوشش می‌دهد؛ لایهٔ هارنس جایی است که این مسئله عملیاتی می‌شود.

اول، روی هر منبع کانتکست بودجه بگذارید. فایل‌ها، خروجی ابزارها، chunkهای بازیابی‌شده، درج‌های حافظه و تاریخچهٔ گفتگو هرکدام باید محدودیت‌های صریح داشته باشند. یک سقف token جهانیِ واحد بیش از حد کند و کلی است.

دوم، کوتاه‌سازی را قابل اقدام کنید. اگر هارنس محتوا را می‌بُرد، مدل باید بداند چه بازه‌ای را دیده و چطور می‌تواند بیشتر درخواست کند. کوتاه‌سازی خاموش از رد کردن بدتر است، چون روی دادهٔ ناقص کارِ مطمئن تولید می‌کند.

سوم، فشرده‌سازی را حول وضعیت انجام دهید، نه نثر. خلاصه‌ها باید هدف کاربر، محدودیت‌ها، تصمیم‌ها، وظایف معلق، فایل‌های دست‌خورده، نتایج ابزارهای مهم و قدم فوری بعدی را حفظ کنند. جفت‌های فراخوانی ابزار باید دست‌نخورده بمانند.

چهارم، مقدارهای بزرگ را از prompt بیرون ببرید. آن‌ها را ذخیره کنید، نام‌گذاری کنید و اشاره‌گرها را از طریق ابزارها پاس بدهید. این کار به‌ویژه برای عامل‌هایی مهم است که APIها را فراخوانی می‌کنند، اسناد را پردازش می‌کنند، یا سیستم‌های چندعاملی را هماهنگ می‌کنند.

در نهایت، گم‌شدن هدف را جدا از سرریز آزمایش کنید. یک عامل می‌تواند زیر پنجرهٔ سخت بماند و باز هم منحرف شود. پرسش درست فقط این نیست: «آیا API prompt را پذیرفت؟» بلکه این است: «آیا اقدام بعدی هنوز در خدمت وظیفهٔ اصلی است؟»

خلاصهٔ زیر این الگوها را پیش از FAQ به یک چک‌لیست سریع تبدیل می‌کند.

• عامل‌های بلندافق هم از طریق سرریز کانتکست شکست می‌خورند و هم از طریق گم‌شدن هدف، بنابراین هارنس باید چیزی بیش از طول prompt را مدیریت کند.
• سیستم‌های عامل تولیدی پیش از رسیدن دادهٔ خام به مدل، روی فایل‌ها، خروجی ابزارها و تاریخچه بودجه‌های سخت اعمال می‌کنند.
• صفحه‌بندی، جست‌وجو و نماهای مدیریت‌شده با کانتکست مثل یک viewport محدود برخورد می‌کنند، نه ذخیره‌سازی دائمی.
• فشرده‌سازی وقتی بهترین کارکرد را دارد که چک‌پوینت‌گذاری باشد: هدف‌ها، محدودیت‌ها، تصمیم‌ها، کارهای معلق و یکپارچگی فراخوانی ابزار را حفظ می‌کند.
• خروجی‌های بزرگ ابزار اغلب باید در storage خارجی باشند و به‌جای مقدارهای کامل در prompt، اشاره‌گرهای کوتاه بین ابزارها پاس داده شوند.

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

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

گم‌شدن هدف زمانی رخ می‌دهد که وظیفهٔ اصلی هنوز جایی در transcript حضور دارد، اما دیگر اقدام بعدی عامل را هدایت نمی‌کند؛ اغلب پس از تاریخچه‌های طولانی یا خلاصه‌سازی ضعیف.

آن‌ها برای هر منبع بودجه تعیین می‌کنند، خواندن فایل‌ها را صفحه‌بندی می‌کنند، فقط نماهای مرتبط را بازیابی می‌کنند، تاریخچه را حول وضعیت فشرده می‌کنند، خواندن‌های تکراری را deduplicate می‌کنند و خروجی‌های بزرگ را بیرون از prompt ذخیره می‌کنند.

اشاره‌گرها به مدل اجازه می‌دهند به مقدارهای بزرگی که در حافظهٔ زمان اجرا ذخیره شده‌اند، مثل ماتریس‌ها، logها یا PDFها، ارجاع بدهد، در حالی که ابزارهای پایین‌دستی دادهٔ کامل را بدون قرار دادن آن در پنجرهٔ کانتکست resolve می‌کنند.

نه. پنجره‌های بزرگ‌تر کمک می‌کنند، اما promptهای سیستم، تعریف‌های ابزار، اسناد بازیابی‌شده، logها و تاریخچه همچنان برای فضا رقابت می‌کنند، و اطلاعات مرتبط می‌تواند پیش از رسیدن به یک حد سخت دفن شود.