ForgeOS با نظارت بر تازگی لاگ‌ها نیاز به کوبرنتیز برای مدیریت عامل‌ها را حذف کرد

تصور کنید ۱۳ عامل هوش مصنوعی را مدیریت می‌کنید که یکی از آن‌ها در حال معامله در بازار پیش‌بینی Polymarket است و دیگری استراتژی‌های تجاری می‌سازد، اما ناگهان متوجه می‌شوید همه چیز متوقف شده در حالی که داشبورد شما هنوز وضعیت «سبز» را نشان می‌دهد. این کابوس «شکست‌های خاموش» است؛ جایی که پردازش‌ها زنده‌اند اما پیشرفتی ندارند و شما فقط زمانی متوجه فاجعه می‌شوید که اعداد روی صفحه دیگر تغییر نمی‌کنند. برای حل این بحران، توسعه‌دهنده پروژه ForgeOS را معرفی کرد؛ یک هسته (Kernel) سبک پایتونی که طراحی شده تا نیاز به استفاده از کوبرنتیز را در عملیات‌های کوچک‌مقیاسِ عامل‌های هوشمند حذف کند.

زمینه (Context)

طبق گزارش توسعه‌دهنده این پروژه، پیش از ForgeOS، ساختار مدیریتی او مجموعه‌ای «آشفته» از خطوط crontab، فایل‌های launchd plists و دستورات nohup … & بود. این فرآیندهای مستقل و خودمختار به‌تنهایی ساده بودند، اما در مجموع هیچ راهی برای بازرسی (Audit) دقیق آن‌ها وجود نداشت. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت لایه زیرساختی در مقیاس کوچک اغلب به ابزاری تبدیل می‌شود که بیش از خودِ پروژه، وقت برنامه‌نویس را می‌گیرد. در واقع، برای یک توسعه‌دهنده تنها، صفحه کنترل کوبرنتیز (Kubernetes) اغلب مانند یک پتک عمل می‌کند؛ ابزاری بیش از حد بزرگ که بار مدیریتی آن از سود حاصل از نظارت بر شغل‌های واقعی بیشتر است. هدف نهایی، ساخت کوچک‌ترین سیستمی بود که بتواند به یک پرسش صادقانه پاسخ دهد: آیا هر آنچه قرار است اجرا شود، واقعاً در حال اجراست و آیا واقعاً کار می‌کند؟

بسیاری از عامل‌های هوش مصنوعی (AI Agents) — که شبیه دستیارهای دیجیتالی هستند که می‌توانند به‌طور مستقل هدف را دنبال کنند — نه با کراش کردن و بسته شدن، بلکه با «گیر کردن» (Hanging) شکست می‌خورند. در این حالت، شناسه‌ی پردازش (PID) همچنان در جدول سیستم فعال است، اما مدل عملاً پیشرفتی ندارد و متوقف شده است. این شکاف میان «زنده بودن» (Liveness) و «پیشرفت کردن» (Progress)، جایی است که سیستم‌های نظارتی سنتی شکست می‌خورند و به کاربر می‌گویند پردازش سالم است، در حالی که در واقع منجمد شده است. این چالش‌های عملیاتی در مدیریت عامل‌ها، به‌ویژه زمانی که هدف رسیدن به درآمدزایی است، به شدت احساس می‌شود؛ چنان‌که پیش از این به دشواری‌های توزیع و جذب کاربر برای عامل‌های خودکار پرداخته‌ایم.

ForgeOS این مشکل را با تبدیل هر فرآیند به یک «موتور» تعریف‌شده در فایل YAML حل می‌کند. این سیستم که تنها از حدود ۱٬۹۰۰ خط کد پایتون تشکیل شده و فقط به کتابخانه pyyaml وابسته است، سه نوع موتور خاص را پشتیبانی می‌کند:

جزئیات (Details)

• Daemon: فرآیندهای دائمی و طولانی‌مدت. نمونه‌هایی از این دست شامل سرورهای API، اسکنرهای رمز (Secret-scanners)، شغل‌های مربوط به نگهداری دیتابیس (DB-retention) و ربات بازیابی کراش در Polymarket است.
• Cron: کارهای زمان‌بندی‌شده. یک نمونه عینی، یک اسکرپر (Scraper) هفته‌ای است که یک دایرکتوری شامل حدود ۱۴ هزار ورودی را مجدداً تولید و بازسازی می‌کند.
• Intelligence: فراخوانی‌های زمان‌بندی‌شده برای مدل‌های زبانی بزرگ (LLM) — مانند یک عامل Claude-CLI که برای شکار آسیب‌پذیری‌ها یا بررسی استراتژی‌ها استفاده می‌شود. توسعه‌دهنده استدلال می‌کند که یک موتور هوشمند، در واقع صرفاً یک کرون‌جاب است که اتفاقاً یک LLM را صدا می‌زند.

نوآوری اصلی در مکانیزم log_max_age_min نهفته است. ForgeOS به‌جای اینکه فقط بپرسد «آیا پردازش در جدول سیستم وجود دارد؟»، بررسی می‌کند که آیا فایل لاگ در یک بازه‌ی زمانی مشخص به‌روز شده است یا خیر. برای مثال، در پیکربندی ربات بازیابی کراش، مقدار log_max_age_min: 20 تعیین شده است؛ این یعنی لاگ باید در ۲۰ دقیقه گذشته نوشته شده باشد. اگر لاگ کهنه شود (Stale) یا یک دیمون بمیرد، هسته به‌طور خودکار موتور را ری‌استارت کرده و این رویداد را ثبت می‌کند.

مکانیزم‌های سیستم

هسته سیستم از طریق یک حلقه (Loop) عمل می‌کند که سیگنال‌های سلامتی اعلام شده را چک می‌کند. یک پیکربندی YAML نمونه برای یک ربات معاملاتی به این شکل است:

• نام: crash-bot
• نوع: daemon
• دستور اجرا: ["python3", "pm_crash_monitor.py"]
• سلامت (Health): process: pm_crash_monitor (باید در جدول پردازش‌ها باشد) و log_max_age_min: 20
• مسیر لاگ: /tmp/pm_crash_monitor.log
• شرط توقف (Kill Condition): "daily_loss > $10 OR cash < $20"
• متغیرهای محیطی: LIVE_TRADING: "true"

به نقل از مستندات پروژه، مدیریت سیستم با مجموعه‌ای از دستورات ساده انجام می‌شود: forge init برای ایجاد دایرکتوری پیکربندی، forge start برای شروع تمام دیمون‌ها، forge daemon برای اجرای حلقه‌های نظارت و زمان‌بندی هسته، forge brief برای دریافت گزارش وضعیت در یک صفحه، و forge health برای دریافت پاسخ نهایی درباره وضعیت سیستم. این روند جایگزین اجرای دستی و خسته‌کننده‌ی ps aux | grep از طریق SSH شده است.

علاوه بر نظارت، ForgeOS منطق ایمنی را از کد منبع خارج کرده و به تنظیمات منتقل کرده است. برای نمونه، ربات معاملاتی دارای یک kill_condition است که به صورت daily_loss > $10 OR cash < $20 تعریف شده است. انتقال این محدودیت‌ها از اعماق ۴۰۰ خط کد به یک فایل YAML قابل مشاهده، لایه‌ای از اعتماد ایجاد می‌کند؛ چرا که محدودیت‌های مالی که در یک نگاه دیده نشوند، قابل اعتماد نیستند و می‌توانند منجر به از دست رفتن سرمایه در پردازش‌های بدون نظارت شوند.

این رویکرد، وضعیت «خاص بودن» یا «برفی بودن» (Special Snowflake) عامل‌های هوش مصنوعی را از بین می‌برد. یک عامل مبتنی بر LLM اکنون صرفاً به عنوان یک کرون‌جاب استاندارد با یک دستور گران‌قیمت مدل‌سازی می‌شود؛ غیرقطعیت (Non-determinism) مدل در داخل خودِ دستور مدیریت می‌شود و لایه‌ی نظارت بر آن، خسته‌کننده و پیش‌بینی‌پذیر باقی می‌ماند.

با این حال، تازگی لاگ‌ها فقط تایید می‌کند که یک پردازش «اجرا» شده است، نه اینکه «درست و با کیفیت» اجرا شده باشد. توسعه‌دهنده پذیرفته است که به‌دلیل غیرقطعیت خروجی‌های LLM، بازرسی کیفی هنوز باید از طریق یک دروازه انسانی (Human Gate) انجام شود. در همین راستا، تلاش‌های پژوهشی متعددی برای کاهش خطاهای مدل‌ها در حال انجام است، مانند پروژه Autopilot که توانست نرخ توهمات در عامل‌های هوشمند را به‌طور چشمگیری کاهش دهد. او اشاره می‌کند که خودکارسازی این مرحله از طریق حلقه‌ی «LLM داور برای LLM»، هنوز برای محیط عملیاتی (Production) قابل اعتماد نیست و این موضوع همچنان «لبه‌ی باز» (Open Edge) یا نقطه تکمیل‌نشده‌ی این طراحی است.

ForgeOS در حال حاضر در نسخه‌ی پیش‌انتشار (v0.1.0) است و به‌جای انتشار در PyPI، از طریق سورس‌کد (با دستور pip install -e . از ریشه پروژه) قابل نصب است. این پروژه نقشه‌ای است برای توسعه‌کنندگانی که به یک پاسخ صادقانه نیاز دارند: آیا هر آنچه باید در حال اجرا باشد، واقعاً کار می‌کند؟

گام بعدی شما

• اگر از طریق nohup یا cron عامل‌های متعددی را مدیریت می‌کنید، استراتژی «تازگی لاگ» را برای تشخیص توقف‌های خاموش پیاده کنید.
• منطق‌های ایمنی و مالی (مانند حد ضرر) را از کد برنامه خارج کرده و در فایل‌های پیکربندی متمرکز کنید تا نظارت بر آن‌ها سریع‌تر شود.
• برای مدیریت سبک فرآیندهای پایتونی، ساختار YAML-based ForgeOS را به‌عنوان جایگزینی برای زیرساخت‌های سنگین بررسی کنید.

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