تصور کنید یک برنامه‌نویس ابزاری را طراحی کرده که باید طی دو ساعت و ۲۰۰ مرحله، یک پروژه پیچیده را پیش ببرد، اما مدل در میانه راه فراموش می‌کند اصلاً هدف نهایی چه بود. این شکستِ پیش‌بینی‌پذیر، همان مشکلی است که AWS آن را «عامل‌های کم‌عمق» (Shallow Agents) می‌نامد؛ وضعیتی که در آن عامل‌ها به‌دلیل سرریز پنجرهٔ زمینه (Context Window) — شبیه میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — دچار «از دست دادن هدف» (Goal Loss) می‌شوند و در نهایت هدف اصلی خود را با رشد طولانی شدن نشست فراموش می‌کنند.
بسیاری از توسعه‌دهندگان تصور می‌کنند بزرگ‌تر کردن پنجرهٔ زمینه راهکار است، اما واقعیت متفاوت است. طبق گزارش Chroma که ۱۸ مدل زبانی از جمله GPT-4.1، Claude 4، Gemini 2.5 و Qwen3 را ارزیابی کرده، با افزایش طول ورودی، عملکرد مدل‌ها حتی در بازیابی‌های ساده غیرقابل‌اعتماد می‌شود. دلیل این اتفاق ساختار توجه (Attention) است که برای n توکن، روابط دوطرفه n² ایجاد می‌کند. این یعنی هر توکن جدید به‌جای اینکه صرفاً فضایی را پر کند، بخشی از یک «بودجهٔ توجه» محدود را مصرف می‌کند.
برای یک عامل، این موضوع حیاتی است. Manus گزارش می‌دهد که وظایف معمولی به حدود ۵۰ فراخوانی ابزار نیاز دارند و نسبت توکن‌های ورودی به خروجی در آن‌ها ۱۰۰ به ۱ است. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت داده‌های ورودی کلید پایداری است. در اینجا نیز وقتی مشاهدات زیاد می‌شوند، دستورالعمل‌های اولیه به وسط پنجرهٔ زمینه رانده می‌شوند؛ دقیقاً همان ناحیه‌ای که قدرت یادآوری مدل به‌شدت افت می‌کند. از دست دادن هدف تنها یک باگ در مدل نیست، بلکه نتیجهٔ مورد انتظارِ یک زمینهٔ مدیریت‌نشده در وظایف طولانی است. این چالش‌ها در واقع بخشی از یک مشکل بزرگ‌تر هستند؛ چرا که بسیاری از تغییرات مهندسی در عامل‌ها لزوماً به تعمیم‌پذیری آن‌ها در محیط‌های جدید منجر نمی‌شود و پایداری مدل در شرایط متغیر همچنان یک چالش است.
مکانیزم ۱: بودجه‌بندی و تخلیه زمینه
اولین خط دفاعی، تصمیم‌گیری درباره این است که چه داده‌ای هرگز نباید وارد پنجرهٔ زمینه شود. هارنس (Harness) تمام بخش‌ها به‌جز خودِ مدل را مدیریت می‌کند تا یک حلقهٔ کم‌عمق را به یک عامل عمیق تبدیل کند. LangChain Deep Agents دو قانون سخت‌گیرانه برای تخلیه داده‌ها (Offloading) اجرا می‌کند:
- محدودیت پاسخ ابزار: وقتی پاسخ یک ابزار از ۲۰,۰۰۰ توکن بیشتر شود، به‌جای ارسال به مدل، در سیستم فایل (Filesystem) ذخیره شده و تنها مسیر فایل و پیش‌نمایشی از ۱۰ خط اول آن در زمینه باقی می‌ماند.
- آستانه نشست (Session): وقتی زمینه به ۸۵٪ ظرفیت پنجرهٔ مدل می‌رسد، فراخوانی‌های قدیمی ابزارهای نوشتن و ویرایش — که محتوای کامل آن‌ها پیش‌تر روی دیسک ذخیره شده است — به اشاره‌گرهای (Pointers) کوتاه تبدیل می‌شوند.
تنها زمانی که این قوانین تخلیه دیگر جایی برای مانور نگذارند، هارنس به سراغ خلاصه‌سازی می‌رود. Claude Code نیز از بودجه‌بندی مشابهی برای بارگذاری‌های اولیه استفاده می‌کند و حافظه خودکار را به ۲۰۰ خط اول یا ۲۵ کیلوبایت محدود می‌کند. همچنین، طرح‌های ابزار MCP (پروتکل زمینهٔ مدل) به‌صورت پیش‌فرض به تعویق می‌افتند و تنها نام ابزارها لیست می‌شود؛ طرح‌های کامل تنها در صورت نیاز و از طریق جستجوی ابزار بارگذاری می‌گردند. هر فایلی که مجدداً خوانده شود و بیش از ۵,۰۰۰ توکن باشد، به‌جای محتوای کامل، به‌عنوان یک ارجاع به مسیر فایل بازگردانده می‌شود.
در سطح معماری، استفاده از زیر-عامل‌ها (Sub-agents) راهکار دیگری است. طبق راهنمای Anthropic، الگویی وجود دارد که در آن یک زیر-عامل پژوهشی ممکن است ده‌ها هزار توکن را برای بررسی یک وظیفه مصرف کند، اما در نهایت تنها یک خلاصه پالایش‌شده بین ۱,۰۰۰ تا ۲,۰۰۰ توکن را به عامل مادر برمی‌گرداند. مستندات Claude Code این موضوع را با شبیه‌سازی‌ای نشان می‌دهد که در آن یک زیر-عامل ۶,۱۰۰ توکن از فایل‌ها را می‌خواند اما نتیجه‌ای ۴۲۰ توکنی بازمی‌گرداند.
Amazon Bedrock AgentCore این الگو را با استفاده از یک هماهنگ‌کننده (Coordinator) که سه زیر-عامل مرورگر را به‌صورت موازی در MicroVMهای مجزا اجرا می‌کند، بهینه کرده است. سپس یک زیر-عامل تحلیل‌گر تنها یافته‌های ساختاریافته آن‌ها را دریافت می‌کند. AWS گزارش می‌دهد که زمان اجرای مورد انتظار برای این الگو ۴ تا ۶ دقیقه است و اشاره می‌کند که پردازش متوالی می‌توانست تا ۳ برابر بیشتر زمان ببرد.
مکانیزم ۲: فشرده‌سازی (Compaction)
وقتی تخلیه داده‌ها کافی نیست، هارنس باید محتوا را خلاصه کند. فشرده‌سازی شامل گرفتن یک گفتگو که به حد نصاب رسیده، خلاصه‌سازی آن و آغاز مجدد یک زمینه جدید است. اما خلاصه‌سازی‌های ناقص (Lossy) اغلب محدودیت‌های حیاتی را حذف می‌کنند و منجر به از دست دادن هدف می‌شوند.
Claude Code برای کاهش این اثر، تصمیمات معماری، باگ‌های حل‌نشده و جزئیات پیاده‌سازی را حفظ کرده و خروجی‌های تکراری ابزارها را حذف می‌کند. بلافاصله پس از فشرده‌سازی، موارد زیر را مجدداً تزریق می‌کند:
- حداکثر ۵ فایل از آخرین تغییرات.
- قوانینی که با آن فایل‌های خاص مطابقت دارند.
- بدنه مهارت‌های فراخوانی‌شده، با سقف ۵,۰۰۰ توکن برای هر مهارت و مجموعاً ۲۵,۰۰۰ توکن.
برای جلوگیری از حذف دستورات اولیه، این ابزار به یک فایل CLAUDE.md در ریشه پروژه متکی است که همواره از دیسک بازخوانی و تزریق می‌شود. کاربران می‌توانند با دستور /compact focus on [topic] این فرآیند را هدایت کنند یا با /autocompact نقطه تحریک فشرده‌سازی را تغییر دهند.
Deep Agents حفظ هدف را یک الزام ساختاری می‌بیند. خلاصه‌های آن اسنادی ساختاریافته با فیلدهای اختصاصی برای «قصد نشست» (Session Intent)، «آثار ایجاد شده» (Artifacts) و «گام‌های بعدی» هستند. تیم LangChain این فیلدها را پس از آزمایش‌های خلاصه‌سازی اجباری اضافه کرد، زیرا نشان دادند که عملکرد را بهبود می‌بخشند. برای اطمینان از اینکه هیچ داده‌ای به‌طور دائمی حذف نشود، متن کامل و اصلی گفتگو در سیستم فایل نوشته می‌شود تا حقایق را بتوان بعداً از طریق read_file بازیابی کرد.
این منطق اکنون به لایه API منتقل شده است. OpenAI در Responses API قابلیت فشرده‌سازی سمت سرور را از طریق context_management با یک compact_threshold و همچنین یک نقطه انتهایی (Endpoint) به نام /responses/compact ارائه داده است. این نقطه انتهایی یک پنجره فشرده‌شده حاوی یک آیتم فشرده‌سازی رمزگذاری‌شده و مبهم (Opaque) برمی‌گرداند که توسعه‌دهندگان باید آن را بدون تغییر در فراخوانی بعدی ارسال کنند. OpenAI بیان می‌کند که مدل Codex برای تداوم وظایف طولانی کدنویسی به همین مکانیزم متکی است.
به همین ترتیب، پلتفرم توسعه‌دهندگان Claude ویرایش compact_20260112 را برای مدیریت زمینه فراهم کرده است. این قابلیت اجازه می‌دهد دستورات سفارشی و گزینه pause_after_compaction برای درج محتوا پیش از ادامه کار مدل استفاده شود. از آنجایی که دستورات سفارشی جایگزین کامل پرامپت پیش‌فرض می‌شوند، پرامپتِ فشرده‌سازی به یک اثر مهندسی واقعی تبدیل می‌شود.
مکانیزم ۳: وضعیتِ «کارهای در دست انجام» و بازگویی
در حالی که فشرده‌سازی از هدف در زمان بازنشانی (Reset) محافظت می‌کند، «وضعیتِ Todo» (Todo-state) در هر نوبت از اجرای مدل این کار را می‌کند. Manus این کار را با ایجاد یک فایل todo.md پیاده می‌کند که عامل آن را گام‌به‌گام بازنویسی کرده و موارد انجام‌شده را تیک می‌زند. با بازنویسی این لیست، عامل اهداف خود را در انتهای زمینه بازگویی می‌کند و برنامه کلی را در محدوده توجه اخیر مدل نگه می‌دارد تا از انحراف «گم‌شده در میانه» جلوگیری کند.
این الگو با هدف به‌مثابه یک اثر تغییرپذیر (Mutable Artifact) برخورد می‌کند، نه صرفاً پیامی در تاریخچه. Anthropic الگوی «یادداشت‌برداری ساختاریافته» را معرفی کرده که در آن عامل‌ها می‌توانند شمارش‌ها یا وضعیت‌ها را در یک فایل NOTES.md یا فایل TODO خارج از پنجره زمینه نگه دارند. در یک مثال، یک عامل Claude توانست هزاران مرحله بازی Pokémon را تنها با خواندن یادداشت‌های خود پس از هر بازنشانی زمینه، مدیریت کند تا توالی‌های چندساعته را از سر بگیرد.
با این حال، این یک پیروزی جهانی نیست. LangChain در ژوئیه ۲۰۲۶ پس از ارزیابی‌ها در سه دسته از وظایف، قابلیت TodoListMiddleware را به حالت اختیاری (Opt-in) تغییر داد، زیرا مشخص شد غیرفعال کردن Todoها در برخی موارد هزینه‌ها را کاهش و پاداش‌ها را به‌طور جزئی بهبود بخشیده است. با این حال، آن‌ها همچنان این روش را برای مدل‌های با توانایی کمتر، وظایف پیچیده چندمرحله‌ای یا رابط‌های کاربری که نیاز به نمایش پیشرفت دارند، توصیه می‌کنند.
مکانیزم ۴: حافظه میان-نشستی
لایه نهایی، پایداری داده‌ها پس از پایان وظیفه است. AgentCore Memory رویدادها را ذخیره کرده و استراتژی‌های استخراج پس‌زمینه را اجرا می‌کند تا در اجرای بعدی، یک هماهنگ‌کننده بتواند به‌جای پژوهش مجدد، از یک ابزار Recall (یادآوری) استفاده کند. AWS هشدار می‌دهد که بدون پیکربندی حداقل یک استراتژی استخراج، رویدادهای خام ذخیره می‌شوند اما هیچ چیزی برای بازیابی استخراج نمی‌شود. ابزار حافظه مبتنی بر فایل Anthropic در پلتفرم Claude هدف مشابهی را دنبال می‌کند.
البته این پایداری هزینه‌ای دارد. مطالعه‌ای از ETH Zurich در فوریه نشان داد که فایل‌های زمینه مخزن مانند AGENTS.md لزوماً نرخ موفقیت را بالا نمی‌برند، اما هزینه استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره‌ی آموزش آشپز — را افزایش می‌دهند. فایل‌های تولید شده توسط LLM هزینه‌ها را در دو بنچمارک ۲۰٪ و ۲۳٪ افزایش دادند، در حالی که فایل‌های ثبت شده توسط توسعه‌دهنده هزینه‌ها را تا ۱۹٪ بالا بردند. این موضوع یک «مالیات دائمی» بر بودجه توجه مدل ایجاد می‌کند. در همین راستا، برای مدیریت این هزینه‌های رو به رشد، برخی مدل‌های قیمت‌گذاری جدید مانند Oxlo.ai تلاش کرده‌اند هزینه استنتاج را از تعداد توکن‌ها جدا کنند تا بهره‌وری اقتصادی در وظایف طولانی افزایش یابد.
برای بهینه‌سازی این مورد، Claude Code پیشنهاد می‌کند فایل CLAUDE.md زیر ۲۰۰ خط نگه داشته شود و مطالب مرجع به بخش مهارت‌ها یا قوانین محدود به مسیر (Path-scoped rules) منتقل شوند تا تنها در صورت نیاز بارگذاری گردند.
آزمایش هارنس
برای تأیید کارکرد این مکانیزم‌ها، LangChain از ارزیابی‌های هدفمندی استفاده می‌کند که فشرده‌سازی را در ۱۰٪ تا ۲۰٪ ظرفیت پنجره (به‌جای ۸۵٪ پیش‌فرض) تحریک می‌کنند. آن‌ها از یک محرک ۲۵٪ با مدل Claude Sonnet 4.5 روی بنچمارک terminal-bench-2 برای مطالعه این اثر استفاده کردند. آن‌ها به‌طور خاص به دنبال «انحراف هدف» (Goal Drift) هستند؛ وضعیتی که عامل بلافاصله پس از خلاصه‌سازی، به‌اشتباه درخواست شفاف‌سازی می‌کند یا وظیفه را تمام‌شده اعلام می‌کند. آن‌ها همچنین موارد «سوزن در انبار کاه» (Needle-in-a-haystack) را تست می‌کنند، جایی که یک حقیقت در اثر خلاصه‌سازی حذف شده و باید از طریق جستجوی سیستم فایل بازیابی شود.
AgentCore Evaluations یک ارزیاب نرخ موفقیت هدف را برای امتیازدهی به این ردپاها (Traces) فراهم می‌کند. درس اصلی مهندسی این است: اگر در زمان تست، فشرده‌سازی را به‌صورت اجباری اجرا نکرده‌اید، نمی‌دانید پرامپتِ خلاصه‌ساز شما چه اطلاعات حیاتی را حذف می‌کند.
این تغییر تمرکز نشان می‌دهد که آیندهٔ قابلیت اطمینان عامل‌ها در مدل‌های بزرگ‌تر نیست، بلکه در «هارنس» نرم‌افزاری است که آن‌ها را مدیریت می‌کند. با برخورد با زمینه به‌مثابه منبعی که باید بودجه‌بندی شود (به‌جای سطل‌ای که باید پر شود)، توسعه‌دهندگان می‌توانند عامل‌هایی بسازند که ساعت‌ها کار خودمختار را بدون گم کردن مسیرشان تحمل کنند.
گام بعدی شما
- اگر از عامل‌های خودکار استفاده می‌کنید، یک فایل
TODO.mdیاNOTES.mdخارجی ایجاد کنید تا مدل در هر مرحله اهدافش را بازنویسی کند. - برای کاهش هزینه استنتاج، پاسخ‌های ابزارهای حجیم را به‌جای تزریق کامل به مدل، در فایل ذخیره کرده و تنها مسیر فایل را ارسال کنید.
- در محیط تست، آستانه فشرده‌سازی (Compaction Threshold) را به‌طور عمدی پایین بیاورید تا نقاط شکست خلاصه‌ساز را شناسایی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو