MemMux: Runtime Verification and Honest Resource Attribution for Fleets of Parallel Coding Agents

مسئله

توسعه‌دهندگان بیش از پیش چند ایجنت کدنویسی را هم‌زمان روی یک ایستگاه کاری اجرا می‌کنند. ابزارهایی مثل tmux و مدیرهای ایجنت برای چیدن پنجره‌ها ساخته شده‌اند نه مدیریت حافظه. وقتی ده ایجنت هرکدام سرور زبان، اجراکننده‌ی تست و مرورگر راه می‌اندازند، هیچ ابزار استانداردی نمی‌گوید چه مقدار حافظه مال کدام ایجنت است، تأیید نمی‌کند فرزندان یک ایجنت خاتمه‌یافته از بین رفته‌اند، و جلوی سقوط ماشین به حافظه‌ی مبادله را نمی‌گیرد، جایی که کشتن یک فرایند می‌تواند کار ثبت‌نشده را بی‌صدا از بین ببرد.

روش

نویسنده این‌ها را مسئله‌ی پایش زمان اجرا می‌بیند: بستر میزبان ایجنت باید پیوسته سیگنال‌های قابل بررسی بدهد. زمان اجرای محلی MemMux مدیریت منابع را به سیگنال‌های قابل بررسی تبدیل می‌کند: اسناد حافظه به هر ایجنت، بازپس‌گیری کامل، دیده شدن فرایندهای فراری، ردپای محدود زیر بیش‌تخصیص و سربار پایش. با tmux، یک مدیر ایجنت تخصصی و یک پایه‌ی فرایند خام روی بار کاری یکسان مقایسه شد.

یافته‌ها

• با بودجه‌ی حافظه‌ی الزامی روی یک میزبان لینوکس، ناوگان را زیر بودجه‌ی ۷٫۵ گیبی‌بایت و بدون حافظه‌ی مبادله نگه داشت، در حالی که ابزارهای بی‌مدیریت ماشین را به سقف حافظه، دو برابر بودجه، رساندند و حدود ۲ گیبی‌بایت به حافظه‌ی مبادله ریختند.
• صددرصد زیردرخت فرایند یک ایجنت خاتمه‌یافته را بازپس گرفت، در حالی که پایه‌ی خام نیمی از آن را جا گذاشت، و تنها ابزاری بود که فرزندان فراری را نشان داد، ۱۰ از ۱۰ مورد.
• هزینه‌ی پویش اسناد یک‌بار در ثانیه با یک ایجنت حدود ۰٫۶ درصد و با ده ایجنت ۲٫۷ درصد پردازنده بود، بالاتر از هدف ۲ درصدی؛ روی جلسه‌های واقعی Claude Code هم اسناد صددرصد و سربار پایین حفظ شد.

محدودیت‌ها

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