«سیستمی بدون وضعیت»؛ راهکار رویچوا برای اتصال عامل‌های مجزای هوش مصنوعی

تصور کنید سیستمی دارید که هر چند ساعت یک‌بار می‌پاشد، اما هر بار که بلند می‌شود، دقیقاً می‌داند در چه نقطه‌ای بود و باید چه کند. این همان «بازیابی بی‌وقفه» (Relentless recovery) است که النا رِویچوا (Elena Revicheva) به عنوان اصل راهنما برای مدیریت عامل‌های هوش مصنوعی خود به کار گرفته است. او برخلاف رویکردهای سنتی، کرش‌های مکرر را نه به عنوان شکست، بلکه به عنوان علائمی از وضعیت سیستم می‌بیند.

این فلسفه در یک عملیات پیچیده هوش مصنوعی به چالش کشیده شد؛ جایی که یک فرآیند در عرض تنها ۴۸ ساعت، ۱۸۱ بار ری‌استارت شد. نکته کلیدی این است که کل وضعیت (State) این عملیات توسط یک سند مشترک ساده به نام NOW.md مدیریت می‌شد.

بسیاری از گردش‌های کاری در عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای دیجیتالی که می‌توانند به‌جای شما کارهای پیچیده را انجام دهند — به حافظه‌های گران‌قیمت و Stateful یا صف‌های پیام‌رسانی پیچیده متکی هستند تا ردپای وظایف را دنبال کنند. اما وقتی از ترکیبی از ابزارهای متفاوتی مثل Cursor Cloud، Cursor Desktop و Claude Code استفاده می‌کنید، این عامل‌ها نمی‌توانند مستقیماً با یکدیگر ارتباط برقرار کنند. آن‌ها هیچ تاریخچهٔ گفتگوهای مشترکی ندارند، در Cursor به Claude MCP دسترسی ندارند و هیچ راهی برای ارسال پیام به یکدیگر ندارند.

برای حل این مشکل، رِویچوا یک پروتکل حافظهٔ مشترک عمل‌گرایانه را پیاده کرد. او به‌جای ساخت یک زیرساخت پیچیده، از یک فایل متنی ساده در مسیر /home/ubuntu/cto-aipa/docs/oracle/NOW.md استفاده می‌کند. این فایل به عنوان تنها منبع حقیقت (Sole source of truth) و ژورنال عملیاتی برای هر عاملی که وارد مخزن (Repository) می‌شود، عمل می‌کند. این رویکرد یادآور پروتکل سه-فایلی است که برای کاهش خطاهای حافظه و جلوگیری از حلقه‌های فراموشی در عامل‌های هوش مصنوعی پیشنهاد شده بود.

محدودیت: عامل‌های گسسته

چالش اصلی یک محدودیت ساختاری بنیادین است: عامل‌ها ذاتاً از هم جدا هستند. در مستندات این پروژه صراحتاً ذکر شده است: «Cursor Cloud، Cursor Desktop و Claude Code همگی روی این مخزن کار می‌کنند اما هیچ‌کدام نمی‌توانند چت‌های دیگری را ببینند... تنها چیزهایی که همه آن‌ها می‌خوانند، HubSpot و این فایل است».

با قرار دادن NOW.md در جایگاه سیستم عصبی مرکزی، این فایل تبدیل به حافظهٔ کاری برای هر عاملی می‌شود که در آن لحظه در حال اجرا نیست. این سازوکار پروتکلی را تعریف می‌کند که از طریق آن، عامل‌های گسسته از تداخل در فعالیت‌های یکدیگر (stepping on each other's toes) جلوگیری می‌کنند و تضمین می‌کند که پیشرفت کار با وجود نبود یک پروتکل ارتباطی مستقیم بین عامل‌های هوش مصنوعی، ادامه یابد.

مکانیسم ناپایداری کنترل‌شده

فرآیند cto-aipa به‌گونه‌ای طراحی شده که بدون وضعیت (Stateless) باشد. وقتی فرآیند کرش می‌کند یا ری‌ست می‌شود، جای خود را گم نمی‌کند؛ زیرا بلافاصله پس از راه‌اندازی، فایل NOW.md را مجدداً می‌خواند. این قابلیت به عامل اجازه می‌دهد تا اقدام بعدی خود را بر اساس آخرین وضعیت ثبت‌شده ارزیابی کند. این یک انتخاب طراحی آگاهانه است تا از ساخت عامل‌های Stateful پیچیده که ممکن است در یک خطا گیر کنند یا پس از هر خطا نیاز به دخالت دستی داشته باشند، اجتناب شود. در واقع، این مدل نشان می‌دهد که اجرای پایدار و تاب‌آور در برابر خطاها، بسیار موثرتر از تکیه بر پرامپت‌های پیشرفته برای حفظ پایداری عامل‌هاست.

بر اساس گزارش‌های فنی، این طراحی الگویی خاص از «ناپایداری کنترل‌شده» ایجاد کرده است:

• حجم ری‌استارت: فرآیند cto-aipa طی دو روز ۱۸۱ بار ری‌استارت شده است.
• مقایسه با سیستم‌های پایدار: این رقم در تضاد کامل با فرآیندهای پایداری مثل n8n (صفر ری‌استارت در ۵۰ روز) یا algom-poll (صفر ری‌استارت در ۶۶ روز) است.
• نوسان شدید: در مقابل، فرآیند algom-stream در ۴۷ روز ۵۵,۱۹۳ بار ری‌استارت شده است، هرچند این موارد اغلب به دلیل نوسانات جریان داده‌های خارجی است و نه ری‌ست‌های مربوط به هماهنگی (Orchestration).
• مصرف منابع: با وجود این ری‌استارت‌های مکرر، فرآیند بسیار سبک باقی مانده و تنها ۱۷۲ مگابایت حافظه مصرف می‌کند. این مقدار کمتر از n8n (۴۹۲ مگابایت) و قابل مقایسه با dragontrade-main (۱۴۸ مگابایت) است.

جزئیات ادغام عملیاتی

این سیستم تنها به فایل Markdown متکی نیست، بلکه با HubSpot به عنوان دومین منبع دادهٔ مشترک ادغام شده است. محتوای NOW.md یک ژورنال عملیاتی پویا شامل دستورالعمل‌ها، مشاهدات و وضعیت فعلی وظایف است. برای مثال، آخرین ورودی آن با این عبارت آغاز می‌شود: «NOW — جلسه مشترک بین Cursor و Claude Code».

نتایج عملیاتی خاص از طریق لاگ‌ها ردیابی می‌شوند:

• ادغام با HubSpot: سیستم وظایفی با حجم بالا را مدیریت می‌کند، مانند ارسال ۱۳۸ معامله (Deal) به مرحلهٔ «They replied» (پاسخ دادند).
• لاگ apply-queue.log: این لاگ اقدامات موفق را ردیابی می‌کند و ورودی‌هایی مانند «✓ sent to Telegram (2 new)» را چندین بار ثبت کرده است.
• لاگ concierge-selftest.log: این فایل سلامت سیستم را گزارش می‌دهد، مانند: «✅ PASS — 4 checks, 4050ms to first card».

نظارت و نگهداری سیستم

برای حفظ این محیط، رِویچوا از تکنیک‌های نظارتی خاصی استفاده می‌کند تا مطمئن شود عامل‌ها بدون دخالت دستی از پروتکل پیروی می‌کنند:

• نظارت بر وضعیت: فایل NOW.md مستقیماً از طریق دستورات tail و git log برای ردیابی تغییرات اخیر بررسی می‌شود.
• ردیابی فعالیت: فعالیت عامل‌ها از طریق لاگ‌های مربوطه (apply-queue و concierge-selftest) و با مشاهده تغییرات لحظه‌ای در HubSpot تأیید می‌شود.
• جلوگیری از تداخل: برای جلوگیری از تداخل در ادغام (Merge Conflict)، فایل NOW.md عمدتاً توسط اپراتور انسانی نوشته می‌شود و عامل‌ها فقط آن را می‌خوانند. عامل‌ها به‌جای تغییر در فایل اصلی پروتکل به شکلی متضاد، اطلاعات را به لاگ‌ها اضافه می‌کنند یا فیلدهای HubSpot را به‌روزرسانی می‌کنند.

سرعت توسعه و موازنه ها

این معماری تکرار سریع (Rapid Iteration) را ممکن می‌کند. رِویچوا در ۴۸ ساعت پنج کامیت به مخزن aideazz زد، از جمله:

• کامیت 92b3a74: «ai-ops-wiki: refresh journal + AEO surfaces»
• کامیت a49193a: «feat(api): footer 'About' opens Elena's Professional Outlook deck (EN/ES)»

علاوه بر این، یک کامیت (2c317c8) به مخزن VibeJobHunterAIPA_AIMCF ارسال شد. چون عامل‌ها بدون وضعیت هستند و مکرراً ری‌استارت می‌شوند، کدهای جدید و دستورالعمل‌های به‌روز شده در NOW.md تقریباً فوراً و بدون نیاز به یک فرآیند استقرار (Redeployment) رسمی برای هر عامل، دریافت و اجرا می‌شوند. این رویکرد در راستای تلاش‌هایی است که برای ایجاد لایه‌های پاسخگویی و انتقال دقیق وضعیت در عامل‌های خودکار صورت می‌گیرد، مشابه آنچه در رویکرد جدید COGEXT برای پایان دادن به توهمات و دروغ‌های عامل‌های خودکار مشاهده شد.

تنها هزینهٔ اصلی این تاب‌آوری، «نویز لاگ» (Log noise) است. ری‌استارت‌های مکرر حجم عظیمی از داده‌های لاگ تولید می‌کند که می‌تواند عیب‌یابی را پیچیده کند. برای مثال، فرآیند algom-stream به دلیل ۵۵,۱۹۳ ری‌استارت، حجم بسیار زیادی از لاگ تولید می‌کند.

با این حال، رِویچوا استدلال می‌کند که برای پروژه‌ای بدون سرمایه‌گذاری خطرپذیر (VC)، این روش بسیار ترجیح داده می‌شود تا سربار زیرساختی یک سیستم پیام‌رسانی توزیع شده، که زمان توسعه و هزینه‌های زیرساختی در Oracle Cloud را افزایش می‌دهد. این رویکرد عمل‌گرایانه اجازه می‌دهد تا عامل‌های هوش مصنوعی تولیدی (Production) بدون نیاز به معماری پیچیده و Stateful پیام‌رسانی، عرضه شوند.

این تغییر در رویکرد نشان می‌دهد که برای توسعه‌دهندگان مستقل، سادگی و تاب‌آوری ارزشمندتر از «پایداری همیشگی» (Uptime) است. با پذیرش کرش‌ها، توسعه‌دهنده تضمین می‌کند که سیستم همیشه رو به جلو حرکت می‌کند، حتی اگر تک‌تک عامل‌ها مدام ری‌ست شوند.

گام بعدی شما

• اگر از چندین ابزار هوش مصنوعی مجزا استفاده می‌کنید که با هم ارتباط ندارند، یک «فایل وضعیت» (State File) ساده ایجاد کنید تا به عنوان پل ارتباطی دستی بین عامل‌هایتان عمل کند.
• به‌جای تلاش برای حذف کامل خطاها، سیستمی طراحی کنید که بتواند با هر ری‌استارت، وضعیت خود را از یک منبع متنی بازیابی کند.
• برای ردیابی پیشرفت عامل‌ها، به‌جای تکیه بر حافظهٔ داخلی مدل، از لاگ‌های خارجی و فیلدهای دیتابیس استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.