اگر امروز برای اجرای عامل‌های هوش مصنوعی هزینه پرداخت می‌کنید، احتمالاً بخش بزرگی از بودجه شما صرف توکن‌های تکراری و بی‌فایده می‌شود. سیستم ALTK-Evolve این «مالیات توکنی» را با تبدیل حافظه از یک مقدار ثابت به یک متغیر قابل تنظیم، تا ۸۵٪ کاهش می‌دهد. در حالی که سیستم ACE تحویل حافظه را به عنوان یک مقدار ثابت در نظر می‌گیرد، ALTK-Evolve آن را مانند یک پیچ تنظیم می‌بیند که می‌توان آن را کم یا زیاد کرد. این رویکرد باعث می‌شود هزینه‌های استنتاج (Inference) به‌شدت کاهش یابد و آن فشار مالی که هنگام اجرای عامل‌های پیچیده AI احساس می‌شود — جایی که هزینه هر گام فارغ از اینکه مدل به یک دفترچه راهنمای کامل نیاز دارد یا فقط یک اشاره ساده، بالا می‌ماند — از بین برود.
بیشتر شکست‌های عامل‌ها ناشی از کمبود دانش نیست، بلکه به دلیل ناتوانی در به‌کارگیری درست آن است. تصور کنید یک عامل (Agent) — شبیه به کارآموزی که دستورالعمل‌ها را می‌داند اما در اجرای جزئیات گیج می‌شود — را برای تسک‌های چندمرحله‌ای واقعی مثل تقسیم صورت‌حساب، پیدا کردن یک آهنگ خاص، یا تطبیق سفارشات در ۹ اپلیکیشن شبیه‌سازی شده به کار بگیرید؛ او معمولاً نه به دلیل نبود API، بلکه به خاطر اشتباه در صفحه‌بندی (Pagination) درخواست‌ها، شناسایی فرد اشتباه یا بازگرداندن مقداری که اصلاً از او خواسته نشده بود، شکست می‌خورد. برای حل این مشکل، پژوهشگران در حال ساخت «حافظه عامل‌محور» هستند؛ سامانه‌هایی که مسیرهای پیموده شده در گذشته (Trajectories) را به درس‌های قابل استفاده تبدیل می‌کنند، بدون آنکه نیاز به تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — یا تکیه بر برچسب‌گذاری‌های انسانی باشد. این تلاش‌ها برای افزایش قابلیت اطمینان عامل‌ها در محیط‌های حساس، یادآور رویکردی است که در معماری Shippy برای جایگزینی تماس‌های API با رابط خط فرمان به کار گرفته شد تا خطاهای اجرایی کاهش یابد.
همان‌طور که در تحلیل قبلی ما درباره‌ی Mini-SWE-Agent اشاره کردیم، که آن هم بر کاهش سربار توکن‌ها در عین حفظ نرخ موفقیت بالا تمرکز داشت، صنعت اکنون به سمت مدیریت جراحی‌گونه‌ی زمینه (Context) حرکت می‌کند. هدف این است که به عامل‌ها یک «دفترچه راهنمای عملیاتی» (Playbook) از درس‌های سخت‌پس داده شده ارائه شود که بتوانند در لحظه به آن‌ها ارجاع دهند.
نبرد علیه فروپاشی زمینه
دو سیستم ACE (Agentic Context Engineering) و ALTK-Evolve هر دو سعی دارند این مشکل را حل کنند. هر دو بر این باورند که نمی‌توان درس‌های یک عامل را در یک خلاصه ساده و مرتب فشرده کرد؛ زیرا این کار منجر به «سوگیری ایجاز» (Brevity Bias) می‌شود — جایی که بهینه‌سازی به سمت دستورالعمل‌های کوتاه و کلی سوق می‌یابد — یا منجر به «فروپاشی زمینه» (Context Collapse) می‌گردد؛ وضعیتی که در آن از مدل خواسته می‌شود در هر گام کل زمینه خود را بازنویسی کند و در نتیجه، جزئیات حیاتی را در فرآیند خلاصه‌سازی حذف می‌کند.
به جای خلاصه، هر دو سیستم فهرستی آیتم‌بندی شده از درس‌ها را نگه می‌دارند. آن‌ها از شمارنده‌ها استفاده می‌کنند تا ردیابی کنند که هر حالت شکست خاص چند بار رخ داده است. در حالی که ACE از یک شمارنده «مفید/مضر» روی هر مورد استفاده می‌کند، ALTK-Evolve از «شمارش‌های حمایتی» (Support Counts) استفاده می‌کند تا ببیند چند اپیزود مستقل منجر به تولید یک دستورالعمل خاص شده‌اند. طبق مستندات فنی، درسی که در ۵ تسک مختلف کشف شده، به عنوان یک شیء ارزشمندتر از درسی تلقی می‌شود که تنها یک بار ظاهر شده است، هرچند هر دو ارزش نگهداری دارند.
معماری حافظه و تثبیت
تفاوت اصلی این دو در نحوه ساخت و تحویل حافظه است. ACE یک دفترچه راهنما را از طریق چرخه «تولیدکننده $\rightarrow$ بازتاب‌دهنده $\rightarrow$ کیوریتور» رشد می‌دهد و به‌صورت افزایشی به‌روزرسانی‌های دلتا (Delta Updates) را اعمال کرده و موارد تکراری را از طریق جاسازی (Embedding) حذف می‌کند. ACE درس‌های تقریباً مشابه را خوشه‌بندی کرده و آن‌ها را ادغام می‌کند، در حالی که شمارش‌های حمایتی را حفظ می‌کند تا مورد باقی‌مانده، مجموع شمارش‌های آن خوشه را به ارث ببرد.
اما ALTK-Evolve رویکردی بسیار جزئی‌تر به تثبیت و تحویل حافظه دارد:
- دستورالعمل‌های دسته‌بندی‌شده (Typed Guidelines): ما دسته‌های خاصی از دستورالعمل‌ها شامل «استراتژی»، «بازیابی» و «بهینه‌سازی» را استخراج می‌کنیم که دارای انتساب علی (Causal Attribution) و منشأ دقیق به مسیر منبع هستند.
- جزئیات در سطح زیر-تسک (Subtask Granularity): درس‌ها در سطح زیر-تسک ذخیره می‌شوند، که اجازه می‌دهد درسی که در یک اپلیکیشن آموخته شده، به اپلیکیشن دیگری منتقل شود.
- هسته ثابت (Fixed Core): مجموعه‌ای کوچک از دستورالعمل‌هایی که حمایت بالایی دارند، همیشه در پرامپت باقی می‌مانند.
- توسعه پویا (Dynamic Extension): تعداد کمی از دستورالعمل‌های خاص هر تسک از طریق شباهت کسینوسی یا هدایت LLM انتخاب می‌شوند و بر اساس اولویت تسک فعلی وزن‌دهی می‌گردند.
- مقیاس‌بندی متناسب با مدل (Model-Aware Scaling): سیستم تنها در صورتی مجموعه کامل تثبیت‌شده را می‌فرستد که مدل فضای کافی (Headroom) برای پردازش آن داشته باشد. برای مدل‌های ضعیف‌تر، زمینه زیاد به‌جای کمک، باعث غرق شدن و سردرگمی مدل می‌شود.
بنچمارک در AppWorld
در آزمایش‌های انجام شده روی محک AppWorld (با استفاده از test_normal و ۱۶۸ تسک)، تفاوت هزینه‌های توکنی تکان‌دهنده بود. در این تست‌ها از یک عامل کدنویسی ReAct استفاده شد که در هر گام کد پایتون می‌نویسد و محیط، خروجی را بازمی‌گرداند.
بر اساس گزارش پژوهشگران، در استفاده از مدل پایه DeepSeek-V3.2، سیستم ACE برای هر تسک ۶۳۴ هزار توکن مصرف کرد، در حالی که ALTK-Evolve تنها به ۲۶۳ هزار توکن نیاز داشت.
در مدل ضعیف‌تر gpt-oss-120b، این شکاف عمیق‌تر شد. ACE به ۷۷۷ هزار توکن نیاز داشت، اما ALTK-Evolve با تنها ۱۱۶ هزار توکن — یعنی تقریباً یک‌هفتم هزینه — عمل کرد. با این حال، صحت پاسخ‌ها ثابت ماند یا حتی بهبود یافت. در مدل DeepSeek-V3.2، سیستم ALTK-Evolve به امتیاز تکمیل هدف تسک (TGC) ۸۹.۳٪ و امتیاز تکمیل هدف سناریو (SGC) ۸۰.۴٪ رسید که به‌طور قابل‌توجهی از نتایج ACE (۸۰.۴٪ TGC و ۷۳.۲٪ SGC) بالاتر است.
عملکرد بر اساس سطح دشواری
داده‌ها نشان می‌دهند که روش تحویل حافظه بر تسک‌های با دشواری‌های مختلف تأثیر متفاوتی دارد. در مدل gpt-oss-120b، دفترچه راهنمای کامل ACE در واقع به تسک‌های آسان و متوسط کمک کرد (به ترتیب ۸۴.۲٪ و ۶۰.۴٪ TGC) زیرا مدل می‌توانست به دنبال کردن دستورالعمل‌های کلی تکیه کند.
اما در تسک‌های «سخت»، ALTK-Evolve با ۳۱.۸٪ در برابر ۲۳.۸٪ ACE پیروز decisively شد. در این سناریوها، مدل نیاز دارد دقیقاً درس درست را انتخاب کند، نه اینکه در کوهی از متن جست‌وجو کند. بازیابی کیوریت‌شده (Curated Retrieval) مانع از آن می‌شود که مدل توسط دستورالعمل‌های نامرتبط پرت شود؛ و همین سطح است که امتیاز کلی را تعیین می‌کند (۵۶.۰٪ برای ALTK-Evolve در مقابل ۵۴.۸٪ برای ACE).
در مدل قدرتمندتر DeepSeek-V3.2، داستان تغییر کرد. این مدل توانست دفترچه کامل را به‌اندازه‌ای خوب جذب کند که در تسک‌های متوسط کمی از ALTK-Evolve جلو بزند (۱۰۰.۰٪ در مقابل ۹۷.۹٪ TGC)، اما ALTK-Evolve در دسته‌های آسان، سخت و کلی برنده بود. با وجود ظرفیت بیشتر مدل، تحویل گزینشی درس‌ها مانع از این شد که دستورالعمل‌ها یکدیگر را خفه کنند یا فضای پردازشی را اشغال نمایند.
تحلیل دقیق معیارها
برای اطمینان از یک مقایسه کنترل‌شده، عامل ACE به‌صورت داخلی روی همان تقسیم‌بندی‌های AppWorld و مدل‌های پایه ALTK-Evolve اجرا شد. این کار ضروری بود زیرا مقاله اصلی ACE نتایج را روی DeepSeek-V3.1 گزارش کرده بود، در حالی که این تست‌ها از V3.2 و gpt-oss-120b استفاده کردند.
برای DeepSeek-V3.2، بهبود حاصل شده از خط پایه بدون حافظه (۷۹.۸ TGC) به ALTK-Evolve (۸۹.۳ TGC) به‌شدت توسط تسک‌های سخت هدایت شد که از ۶۶.۷٪ به ۷۷.۸٪ جهش کردند. بهبود ACE در همین سطح متواضع‌تر بود و از ۵۵.۶٪ به ۶۱.۹٪ رسید.
برای gpt-oss-120b، خط پایه ۳۹.۹٪ TGC بود. در حالی که ACE به ۵۴.۸٪ رسید، ALTK-Evolve توانست به ۵۶.۰٪ دست یابد. تفاوت حیاتی در سطح سخت بود: TGC مدل ALTK-Evolve با ۳۱.۸٪ تقریباً دو برابر خط پایه ۱۹.۱٪ شد، در حالی که ACE تنها به ۲۳.۸٪ رسید.
تحلیل مهندسی و موازنه
به نقل از گزارش فنی، تمرکز ACE بر ارزان کردن «ساخت» (Construction) زمینه است، اما ALTK-Evolve بر ارزان کردن «سرویس‌دهی» (Serving) آن تمرکز دارد. با بازیابی چند دستورالعمل به‌جای تزریق کل دفترچه در هر گام، هزاران توکن تکراری در هر نوبت حذف می‌شوند.
این تغییر نشان می‌دهد که گلوگاه هوش مصنوعی عامل‌محور از «چگونه درس درست را بیابیم» به «چگونه آن را بدون غرق کردن مدل ارائه دهیم» تغییر کرده است. برای توسعه‌دهندگان، این یعنی رویکرد «هرچه پنجره متنی بزرگ‌تر، بهتر» یک تله است. یک مدل ضعیف‌تر اغلب توسط یک پرامپت عظیم مختل می‌شود، نه اینکه به آن کمک شود. کالیبره کردن میزان راهنمایی با توانایی واقعی مدل، کلید بهره‌وری است. این بهینه‌سازی در سطح سرویس‌دهی، مکمل زیرساخت‌های مقیاس‌پذیر است؛ برای مثال، در معماری AgentENV از Firecracker MicroVMs برای تابه‌بندی مدل‌های عظیم استفاده شده تا محیط‌های اجرای عامل‌ها با کارایی بیشتری مدیریت شوند.
اگر در حال ساخت عامل‌هایی برای محیط عملیاتی (Production) هستید، گام بعدی ارزیابی سربار پرامپت‌های فعلی شماست. می‌توانید با پیاده‌سازی یک لایه بازیابی ساده برای لاگ «درس‌های آموخته شده» عامل خود شروع کنید تا ببینید آیا راهنمایی گزینشی نرخ موفقیت شما را در تسک‌های سخت بهبود می‌بخشد یا خیر.
گام بعدی شما
- سربار پرامپت‌های فعلی خود را ارزیابی کنید و توکن‌های تکراری در هر گام را شناسایی کنید.
- یک لایه بازیابی ساده برای «درس‌های آموخته شده» عامل خود پیاده کنید تا اثر راهنمایی گزینشی روی تسک‌های سخت بسنجید.
- اگر از مدل‌های کوچک‌تر استفاده می‌کنید، حجم زمینه را کاهش داده و روی دقت بازیابی تمرکز کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو