تصور کنید چندین عامل هوش مصنوعی روی لپ‌تاپ شما در حال کدنویسی هستند و ناگهان سیستم به‌طور کامل یخ می‌زند. این اتفاق زمانی رخ می‌دهد که عامل‌ها بدون بررسی محدودیت‌های سخت‌افزاری، تست‌های موازی و بیلد‌های داکر را به‌صورت کورکورانه اجرا می‌کنند.
Resource Sentinel MCP که در ۱۸ ژوئیه ۲۰۲۶ عرضه شد، دقیقاً مانند یک چراغ راهنمایی برای منابع سیستم عمل می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدیریت منابع در مدل‌های محلی اشاره کردیم، مدل‌های زبانی بزرگ (LLM) — که مثل کتابخانه‌داری هستند و میلیاردها صفحه را خوانده‌اند تا جواب دهند — در شروع تکالیف مهارت دارند اما هیچ درکی از ظرفیت فیزیکی سخت‌افزار میزبان ندارند. این ابزار با ارائه یک لایه کنترلی، پذیرش حجم کاری را بر اساس داده‌های واقعی مدیریت می‌کند، نه حدسیات مدل. این رویکرد برای کنترل مصرف منابع سخت‌افزاری است، درست همان‌طور که لایه حفاظتی AI CostGuard برای جلوگیری از انفجار هزینه‌های مالی در عامل‌های خودمختار طراحی شده است.
به نقل از مستندات این پروژه در dev.to، این سامانه برای پایش میزبان‌های لینوکسی از تله‌متری مبتنی بر psutil استفاده می‌کند. سازوکارهای فنی کلیدی این ابزار عبارت‌اند از:
- اسلات‌های اجرا (Execution Slots): عامل‌ها باید با ارسال شناسه کاری، مقدار تخمینی رم (به مگابایت) و وزن CPU، درخواست اسلات اجرا دهند.
- اجاره‌های منقضی‌شونده (Expiring Leases): اسلات‌های اعطایی به صورت «اجاره» صادر می‌شوند. این اجاره‌ها برای فعال ماندن نیاز به ضربان قلب (Heartbeat) دارند تا اگر عاملی کرش کرد، منابع سریعاً بازپس گرفته شوند.
- پایداری داده‌ها: تمام بلیت‌ها و اجاره‌ها برای اطمینان از قابلیت اطمینان، در یک پایگاه‌داده SQLite WAL ذخیره می‌شوند.
- یکپارچگی با MCP: سیستم ابزارهای خود را از طریق پروتکل زمینهٔ مدل (MCP) ارائه می‌دهد و یک نمایش HTTP خواندنی برای داشبوردها فراهم می‌کند. این یکپارچگی با MCP مشابه تسهیل دسترسی مدل Claude به Redis و Kafka توسط Upstash است که قابلیت‌های مدل را از طریق این پروتکل گسترش می‌دهد.
طبق گزارش توسعه‌دهندگان، این تغییر رویکرد، مدیریت عامل‌های محلی را از حالت «امید به همکاری» به یک سیاست «بسته‌شدن در صورت شکست» (Fail-closed) منتقل می‌کند. توسعه‌دهندگان اکنون می‌توانند استک‌های پیچیده چندعاملی را بدون ریسک فریز شدن سیستم اجرا کنند. در واقع، میزبان از یک قربانی منفعل در برابر مقیاس عامل‌ها، به یک محیط مدیریت‌شده تبدیل می‌شود.
گام بعدی شما
- مخزن گیت‌هاب github.com/HappyMonkeyAI/Resource-Sentinel-MCP را بررسی کنید تا این لایه تله‌متری را به میزبان‌های خود اضافه کنید.
- اگر از ابزارهای MCP استفاده می‌کنید، بررسی کنید که آیا مدل شما می‌تواند مقادیر تخمینی رم را به‌درستی در درخواست‌های خود ارسال کند یا خیر.
- داشبورد HTTP این ابزار را برای شناسایی عامل‌های «پرخوره» در سیستم خود فعال کنید.
این تنها آغاز مدیریت منابع در لبه است؛ اثر این رویکرد بر بهره‌وری مدل‌های کوچک‌تر را در گزارش‌های بعدی بررسی خواهیم کرد.
گفتگو