پروتکل Subsessions با محدود کردن حافظه عامل‌ها از متورم شدن پنجره متنی جلوگیری

اگر امروز از سامانه‌های چندعاملی برای کدنویسی استفاده می‌کنید، احتمالاً متوجه شده‌اید که پنجره متنی شما به‌سرعت با تاریخچه‌های تکراری و شکست‌خورده پر می‌شود. در ۴ سپتامبر ۲۰۲۶، رویکرد معماری جدیدی به نام Subsessions معرفی شد تا این چرخه را با اعمال یک قانون سخت‌گیرانه برای مدیریت حافظه بشکند و یک ناوردا (Invariant) حافظه از نوع O(report) را تحمیل کند.

پنجره زمینه (Context Window) — مثل میز کاری است که جا برای چند ورق کاغذ دارد، نه برای کل کتابخانه — گران‌بهاترین منبع یک عامل کدنویس است. طبق گزارش منتشر شده، اکثر سامانه‌های فعلی با بازگرداندن تمام متون (Transcripts) زیر-عامل‌ها به عامل مادر، این منبع را هدر می‌دهند. همان‌طور که در تحلیل قبلی ما درباره‌ی محدودیت‌های پنجره‌های متنی بزرگ اشاره کردیم، صرفاً افزایش اندازه حافظه نمی‌تواند عامل‌ها را واقعاً «قابل بازگشت» (Resumable) کند.

پروتکل Subsessions بر این فرض استوار است که برای یک برنامه‌ریز، تنها «نتیجه» یک وظیفه اهمیت دارد، نه جزئیات مسیر. در طراحی‌های سنتی، اگر یک عامل مادر سه فرزند برای بازسازی ماژول‌ها ایجاد کند، تمام تاریخچه فراخوانی ابزارها، تلاش‌های ناموفق و خواندن‌های کامل فایل‌ها را به ارث می‌برد. Subsessions این «تخلیه متنی» (Transcript Dump) را با یک لایه گزارش‌دهی ساختاریافته جایگزین می‌کند.

مرزهای ساختاری

هسته این طراحی، لایه‌ای از پروتکل است که روی نسخه‌ای تغییریافته (Fork) از DeepSeek Harness بنا شده است. این لایه، جلسه «مادر» (برنامه‌ریز) را از جلسات «کارگر» (مجری) جدا می‌کند. این رویکرد در واقع تکامل یافته‌ی همان فلسفه‌ای است که DeepSeek Harness با تبدیل اجزای عامل به پلاگین‌ها سعی در انعطاف‌پذیری معماری داشت. عامل مادر هرگز متون خام فرزندانش را نمی‌بیند و فقط به خلاصه‌ها و گزارش‌های نهایی دسترسی دارد.

این هدف از طریق چهار تغییر کلیدی در طراحی محقق شده است:

• تایپ‌گذاری نقش‌ها (Role-Typing): عامل‌ها بر اساس نقش ایجاد می‌شوند، نه شناسه مدل. یک جدول نقش‌ها وجود دارد که نقش‌ها را به سطوح (Tiers) و سقف‌های عمق دسترسی متصل می‌کند. نقشی که depthCap: 0 داشته باشد، یک «برگ» است. سیستم در سطح فیلتر ابزارها، دسترسی به subsession_spawn را برای این نقش‌ها می‌بندد تا اطمینان حاصل شود یک کارگر هرگز نمی‌تواند تبدیل به مادر شود. این موضوع در زمان تعریف نقش بررسی می‌شود و به حسن نیت پرامپت‌ها واگذار نمی‌شود.
• مقداردهی اولیه دستورالعمل (Brief-Initialization): هر فرزند با یک دستورالعمل نسخه‌بندی شده (briefVersion: 1) شروع می‌کند. این دستورالعمل شامل ماموریت، الگوهای فایل‌های تحت مالکیت (File Globs)، سقف توکن، اجازه عمق و یک «قرارداد گزارش» (شامل بخش‌های الزامی و حداکثر توکن‌های گزارش) است. همچنین ممکن است شامل یک لیست تایید اختیاری و فیلد continues: <predecessorId> باشد. تمام این فیلدها پیش از شروع به‌صورت تک‌به‌تک اعتبارسنجی می‌شوند و هرگونه رد شدن، دقیقاً فیلد خطا را نام می‌برد.
• ارتباطات گزارش‌محور (Report-Communication): فرزندان تنها از طریق یک ابزار خاص ارتباط می‌گیرند. گزارش‌های پیشرفت مانند ضربان قلب عمل می‌کنند؛ یعنی به‌صورت بی‌صدا ارسال شده و باعث بیدار شدن (Wake) مادر نمی‌شوند. گزارش نهایی گره را برای همیشه می‌بندد و باید قرارداد گزارش را برآورده کند. پیش از اعتبارسنجی ساختاری، یک گیت اندازه (Size Gate) اجرا می‌شود: اگر گزارش از سقف تعیین‌شده بیشتر باشد، حتی اگر ساختار آن هم غلط باشد، خطای REPORT_TOO_LARGE می‌دهد تا هرگز ثبات اندازه حافظه فدای پیام‌های خطای دقیق‌تر نشود. گزارش‌ها فقط به‌صورت الحاقی (Append-only) هستند و به ۵۰ مورد آخر محدود می‌شوند.
• قابلیت تداوم (Continuability): فرزندان نقاط بازرسی (Checkpoints) را در یک ژورنال JSONL ثبت می‌کنند که شامل فاز، وضعیت، تصمیمات و گام‌های بعدی است. رجیستری تنها یک اشاره‌گر (workspaceFile:<path>#<line>) را نگه می‌دارد. اگر عاملی کشته یا مسدود شود، فرزند جدیدی با continues: <predId> ایجاد می‌شود و متن اولیه (Seed Text) حاوی ارجاع به نقطه بازرسی است. پیش‌نیازان هرگز حذف نمی‌شوند.

خط لوله ایجاد و ایمنی

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

۱. validateBrief (اعتبارسنجی دستورالعمل)
۲. بررسی وجود نقش
۳. ایمنی نقش
۴. بررسی عمق
۵. فیلتر ابزارها
۶. هم‌پوشانی محدوده در برابر خواهر-برادرهای فعال
۷. بودجه درخت
۸. سقف‌های هم‌زمانی
۹. شروع فرزند دقیقاً یک‌بار $\rightarrow$ ثبت در رجیستری

هم‌پوشانی محدوده (Scope Overlap) بسیار حیاتی است؛ سیستم یک بررسی محافظه‌کارانه روی الگوهای فایل (Glob check) انجام می‌دهد تا مطمئن شود دو فرزند به‌طور مخفیانه مالک فایل‌های یکسانی نیستند. در صورت تداخل، خطای SCOPE_OVERLAP (با ذکر نام sibling و مسیرها) صادر می‌شود، مگر اینکه allowOverlap: true ثبت شده باشد. «بودجه درخت» به‌صورت محاسبات ریاضی مدیریت می‌شود: مجموع سقف‌های فرزندان فعال به‌اضافه سقف فرزند جدید باید در بودجه اعلام‌شده مادر بگنجد. این یک محاسبه ریاضی است، نه اندازه‌گیری لحظه‌ای.

جداسازی هسته تصمیم‌گیر از زمان اجرا

این معماری پروتکل را به دو بخش «هسته‌های تصمیم‌گیر» (Decision Cores) و «سیم‌کشی زمان اجرا» (Runtime Wiring) تقسیم می‌کند. هسته‌های تصمیم‌گیر توابع خالصی هستند که روی رجیستری و طرحواره‌ها (Schemas) عمل می‌کنند؛ آن‌ها هیچ ورودی/خروجی (I/O)، ساعت، ایمپورت از Harness یا وابستگی به ctx ندارند. توابعی مانند planAndStartSpawn (که یک شیء SpawnPorts شامل جدول نقش‌ها، تنظیمات، پروب identifyMother() و هدف startChild می‌گیرد)، acceptChildReport ،sweepQuiescence ،buildSuccessionBrief و handoverOf همگی این ساختار را دارند.

این جداسازی به تیم اجازه داد تا منطق پروتکل و ترتیب اجرا را با استفاده از جاسوس‌ها (Spies) پیش از وجود زمان اجرای واقعی تست کنند. سیم‌کشی زمان اجرا یک پلاگین میزبان نازک است که این هسته‌ها را به سرویس‌های واقعی مانند ctx.subagents.startContinuable ،defineTool و الحاق فایل‌ها متصل می‌کند. با تزریق ساعت از طریق Wrapper، تیم تضمین کرد که محاسبات سکون (Quiescence) در تست‌ها قطعی (Deterministic) باقی بماند.

یک محدودیت مستند شده این است که رجیستری تنظیمات تداوم، در سطح سراسری (Global) فرآیند است. رجیستری و ژورنال تک‌نمونه‌های (Singletons) سطح ماژول هستند. اگر چندین نمونه نصب شده وجود داشته باشد، ابزارهای فرزند دو بار ثبت شده و خطا رخ می‌دهد؛ اما اشتراک‌گذاری این تک‌نمونه‌ها باعث می‌شود هر نمونه‌ای که پیروز شود، رفتاری یکسان داشته باشد زیرا شناسه‌های گره، شناسه‌های جهانی جلسه هستند.

حل گلوگاه حضور انسان در چرخه

یکی از مهم‌ترین تغییرات، نحوه مدیریت مجوزهاست. در اکثر چارچوب‌ها، وقتی عامل فرزند منتظر تایید انسان است، در حالت «پارک» می‌ماند یا معلق می‌شود و یک جایگاه (Slot) و بخشی از حافظه را اشغال می‌کند.

Subsessions این کار را ممنوع کرده است. سخت‌گیرانه‌ترین قانون غیرقابل مذاکره در این مشخصات این است که فرزندان هرگز نمی‌توانند برای تایید انسان پارک شوند و مادر هرگز نمی‌تواند ارتقای دسترسی یک نواده را تایید کند. زمان اجرا، فرزندان را پیش از اعزام روی approvalPolicy: 'never' تنظیم می‌کند؛ حتی تستی وجود دارد که در هر اجرا، سورس‌های پلاگین را برای عبارات approvalPolicy و user-approval جستجو (Grep) می‌کند.

وقتی عاملی به دیوار مجوز برخورد می‌کند، وضعیت خود را ثبت (Checkpoint) کرده و سپس گزارشی نهایی با outcome: 'blocked' و blockers: ["approval-required: fs write"] ارسال می‌کند. صف انسان، در واقع یک نمای (View) روی این گزارش‌های نهایی مسدود شده در مرورگر است، نه یک وضعیت در زمان اجرا. فرزند به‌طور تمیز بسته می‌شود، جایگاهش آزاد می‌گردد و انسان تصمیم می‌گیرد آیا جانشینی با مجوزهای لازم ایجاد کند یا خیر. این کار، «درخواست ارتقای دسترسی» را از یک فرآیند معلق به یک ساختار داده تبدیل می‌کند.

رابط کاربری مرورگر

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

• درخت کامل سازمان در هر عمق.
• مصرف توکن زنده برای هر گره (در صورت در دسترس بودن پیش‌بینی)؛ فرزندان غیرفعال فقط سقف‌های اعلام‌شده را نشان می‌دهند و هرگز اعداد جعلی نمایش نمی‌دهند.
• نشان‌های نقطه بازرسی روی گره‌های متوقف شده (پیش‌نیازان پس از مرگ همچنان قابل مرور هستند).
• صف موارد مسدود شده با دکمه «تحویل» (Handover) که ماموریت، موانع و خلاصه نقطه بازرسی را در کلیپ‌بورد کپی می‌کند.

برای حفظ پایداری زمان اجرا، داده‌های RPC از گسترش‌های شرطی (...(x !== undefined ? { x } : {})) استفاده می‌کنند، زیرا مقدار key: undefined باعث شکست اسنپ‌شات‌های مقادیر در زمان اجرا می‌شود.

مکانیزم جانشینی

وقتی عاملی شکست می‌خورد، بازنشسته می‌شود یا در حالت مسدود به پایان می‌رسد، دستور subsession_succeed یک جانشین ایجاد می‌کند. این یک رستاخیز نیست، بلکه شبیه «استخدام نیروی جدید با یک نامه تحویل» است. جانشین، دستورالعمل پیش‌نیازان را (با تغییرات اختیاری) به ارث می‌برد، continues: <predecessorId> را تثبیت می‌کند و کل خط لوله ایجاد را دوباره در برابر درخت فعلی اجرا می‌کند. یک ادعای محدوده قدیمی ممکن است به‌طور قانونی با خطای SCOPE_OVERLAP شکست بخورد اگر از زمان شروع پیش‌نیازان، عاملی دیگر به آن محدوده وارد شده باشد.

نامه تحویل، قانون O(report) را ملموس می‌کند. این نامه حاوی یک اشاره‌گر، یک فاز و چند خط خلاصه است (مثلاً: predecessor handover: need permission یا predecessor blockers: approval-required: fs write). این نامه هرگز حاوی تاریخچه متنی (Transcript) نیست.

برای جلوگیری از نشت حافظه، سیستم در هنگام ورود به مرحله جانشینی، یک «جاروب سکون» (Quiescence Sweep) اجرا می‌کند. هر عاملی که آخرین نشانه حیاتش (بیشترین مقدار بین heartbeat یا claim-stamp) قدیمی‌تر از retireTimeoutMs باشد، مرده فرض می‌شود. وضعیت آن به «شکست خورده» تغییر می‌کند، نوادگانش یتیم می‌شوند و جایگاهش آزاد می‌گردد. برچسب‌های ادعا (Claim-stamps) در گیت ایجاد زده می‌شوند تا اطمینان حاصل شود سکون از لحظه واقعی ایجاد اندازه‌گیری می‌شود.

تاییدیه و محک‌ها

این پیاده‌سازی در چهار فاز گیت‌دار تایید شد، با این قانون که هیچ ادعای پاس شدنی بدون شواهد ماشینی (junit XML، کدهای خروجی tsc، تعداد lint) پذیرفته نمی‌شود:

• P1 پلاگین میزبان: طرحواره‌ها، نقش‌ها، رجیستری، بودجه، محدوده، ژورنال، خط لوله‌ها (۱۳۲/۱۳۲ تست، tsc 0).
• P2 رابط کاربری کلاینت: درخت سازمان، صف مسدود شده، میزبان Handover (۱۴۱/۱۴۱ میزبان، ۵/۵ کلاینت، باندل تایید شده).
• P3 جانشینی: دستور جانشینی، جاروب سکون، برچسب‌های ادعا (۱۵۵/۱۵۵ میزبان در ۱۴ مجموعه تست، lint 0).
• P4 مستندات: فقط README بسته.

سه لایه تست بار اصلی را به دوش می‌کشند: تست‌های پروتکل روی هسته‌های خالص (پوشش مرزهای بودجه، تداخل محدوده و آبشارهای یتیم شدن)، تست‌های یکپارچه‌سازی که هسته‌ها را از طریق پورت‌ها با جاسوس‌ها هدایت می‌کنند (شامل چرخه کشتن در میان کار $\rightarrow$ نقطه بازرسی $\rightarrow$ بازسازی)، و یک مجموعه درایور روی زمان اجرای واقعی. این تست‌ها باگ‌های بحرانی را شناسایی کردند، مانند شکست در انتقال (Transport failure) که اسنپ‌شات‌های UI را پاک می‌کرد، شکاف در فیلتر ابزارها که در آن subsession_succeed و subsession_checkpoint از گارد deny-strip جا افتاده بودند، و انحراف مالکیت ساعت که در آن claimedAt هرگز مهر نمی‌شد و سکون را از زمان صفر (Epoch zero) اندازه‌گیری می‌کرد.

مقایسه با چارچوب‌های موجود

این رویکرد با دیگر تلاش‌های صنعتی برای حل هماهنگی عامل‌ها متفاوت است:

• Claude Code: نسخه ۲.۱.۰ قابلیت زمینه‌های فورک شده زیر-عامل را از طریق context: fork در متادیتای SKILL.md اضافه کرد. این قابلیت اجازه می‌دهد agent: <name> مهارت‌ها را به زیر-عامل‌های نام‌گذاری شده با مدل‌ها و ابزارهای پیش‌تایید شده ارسال کند. با این حال، Subsessions مرز را به‌صورت ساختاری از طریق گیت‌های ایجاد و محدودیت‌های اندازه تثبیت می‌کند، نه از طریق قراردادهای متنی (Frontmatter).
• Cognition: این شرکت به دلیل تصمیمات متضاد، علیه سامانه‌های چندعاملی است و قانون «خواندن موازی/نوشتن متوالی» را پیشنهاد می‌دهد. Subsessions این مشکل را با محدود کردن شدید بازگشت داده‌ها به مادر از طریق گزارش‌ها حل می‌کند.
• پژوهش‌های Anthropic: نشان می‌دهد سامانه‌های چندعاملی می‌توانند حدود ۱۵ برابر بیشتر از چت‌های معمولی توکن مصرف کنند و مصرف توکن ۸۰٪ از واریانس عملکرد در BrowseComp را توضیح می‌دهد.
• MAST: تحلیل بیش از ۱۶۰۰ اثر در ۷ چارچوب، ۱۴ حالت شکست (مشخصات بد، عدم هم‌راستایی، تایید شکست خورده) را یافت. ChatDev تنها ۳۳.۳۳٪ صحت در بنچمارک ProgramDev کسب کرد، که نشان می‌دهد دستاوردهای چندعاملی اغلب حداقلی هستند. این یافته‌ها با چهار مسیر شکست که مانع استقرار تجاری عامل‌ها می‌شوند هم‌راستا است و بر اهمیت ساختارهای سخت‌گیرانه تأکید می‌کند.
• ReWOO: مانند ReWOO، سیستم Subsessions استدلال را از مشاهدات جدا می‌کند، اما این کار را در سطح «جلسه» انجام می‌دهد، نه در سطح «پرامپت».

تحلیل: تغییر پارادایم عامل‌ها

برای توسعه‌دهندگانی که عامل‌های در سطح تولید (Production-grade) می‌سازند، این یک تغییر از «هماهنگی مبتنی بر پرامپت» به «هماهنگی مبتنی بر پروتکل» است. با تبدیل تعاملات عامل‌ها به یک API رسمی با گیت‌های اندازه و مجوزهای مبتنی بر نقش، سیستم غیرقابل پیش‌بینی بودن تفویض اختیار توسط LLM را حذف می‌کند.

مهم‌ترین نتیجه، نحوه برخورد با تایید انسانی است. با تبدیل وضعیت انتظار به یک شیء داده‌ای «مسدود شده»، سیستم بهره‌وری محاسباتی را به حداکثر می‌رساند. شما دیگر برای نشستن یک عامل در حالت بیکار هزینه نمی‌پردازید؛ بلکه برای گزارشی هزینه می‌کنید که به شما می‌گوید چرا متوقف شده است.

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

برای مشاهده عملکرد این سیستم در بارهای کاری واقعی، باید گزارش اندازه‌گیری همراه با عنوان «اندازه‌گیری مالیات فورک در چند-عاملی» (Measuring the Multi-Agent Fork Tax) را بررسی کنید که سربار این معماری فورک شده را کمی‌سازی می‌کند.