تصور کنید چندین دستیار هوشمند دارید که هر کدام در یک اتاق بسته هستند و نمی‌توانند با هم حرف بزنند؛ نتیجه‌ای جز هرج‌ومرج و تکرار اشتباهات نخواهد بود. این دقیقاً همان چالشی است که النا رِویچوا (Elena Revicheva) از مجموعه AIdeazz با تبدیل یک فایل متنی به «سیستم عصبی مرکزی»، آن را دور زد. او از مفهوم «سیستم فایل به عنوان یک گذرگاه حافظه مشترک» استفاده می‌کند تا نیاز به صف‌های پیام گران‌قیمت یا APIهای سفارشی را از بین ببرد. او برای این کار از یک فایل Markdown ساده به نام NOW.md استفاده می‌کند تا هماهنگی بین یک گروه پیچیده از عامل‌های هوش مصنوعی پراکنده را مدیریت کند.
بسیاری از عامل‌های هوش مصنوعی (AI Agents) — شبیه کارمندانی که فقط دستورات رئیس خود را می‌شنوند و از کارهای همکارانشان بی‌خبرند — امروزه در سیلوهای بسته عمل می‌کنند. شما ممکن است یک فرآیند را در Cursor Cloud و دیگری را در Claude Code اجرا کنید، اما این ابزارها نمی‌توانند تاریخچه چت یکدیگر را ببینند یا پیام‌های مستقیم رد و بدل کنند. این جدایی منجر به کارهای تکراری، بازنویسی خروجی‌ها و هرج‌ومرج سیستماتیک در هنگام مقیاس‌بندی جریان‌های کاری عامل‌محور می‌شود. این عدم هماهنگی می‌تواند منجر به رفتارهای پیش‌بینی‌ناپذیری شود، مشابه آنچه در بررسی‌های اخیر درباره رقابت مخرب عامل‌های هوش مصنوعی بر سر منابع مشاهده شده است.
زمینه و بستر گسست (Context of Fragmentation)
مشکل اصلی، انزوای کامل است. عامل‌های رِویچوا در محیطی پراکنده شامل Cursor Cloud، Cursor Desktop و Claude Code فعالیت می‌کنند. در این ساختار، هیچ گفتگوهای مشترکی وجود ندارد، هیچ گذرگاه پیام یکپارچه‌ای در دسترس نیست و پروتکل Claude MCP نیز در Cursor ادغام نشده است.
این گسست حتی در زیرساخت‌ها نیز دیده می‌شود. برخی عامل‌ها به‌صورت محلی و برخی دیگر در Oracle Cloud میزبانی می‌شوند. آن‌ها از ارائه‌دهندگان مختلف LLM و محیط‌های اجرای متفاوتی استفاده می‌کنند؛ برای مثال، برخی عامل‌ها از SDK شرکت آنتروپیک (@anthropic-ai/sdk) استفاده می‌کنند در حالی که برخی دیگر بر پایه OpenAI هستند. بدون یک زمین مشترک، عامل‌ها در انتظار ورودی‌هایی می‌ماندند که هرگز نمی‌رسید یا تلاش‌های خود را در پلتفرم‌های مختلف تکرار می‌کردند.
برای حل این مشکل، رِویچوا پروتکلی را پیاده کرد که در آن هر عامل، فایل مشخصی در مسیر /home/ubuntu/cto-aipa/docs/oracle/NOW.md را می‌خواند و در آن می‌نویسد. طبق گزارشی که در ۹ سپتامبر ۲۰۲۶ منتشر شد، این فایل به‌جای یک مستند ایستا، مانند یک «جلسه فعال» (Active Session) عمل می‌کند. این مکانیسم به عامل‌ها اجازه می‌دهد وظایف را به یکدیگر پاس دهند و وضعیت (State) را در محیط‌های مختلف اجرا حفظ کنند.
جزئیات پروتکل فنی (The Technical Protocol)
این سیستم هشت فرآیند مجزا را مدیریت می‌کند که توسط ابزار PM2 نظارت می‌شوند؛ از جمله فرآیندهایی مانند cto-aipa، algom-stream و dragontrade-main. از آنجایی که این عامل‌ها از ارائه‌دهندگان مختلفی استفاده می‌کنند، فایل Markdown تنها نقطه مشترک آن‌هاست. در متن این فایل صراحتاً ذکر شده است که این سند «جلسه مشترک بین Cursor و Claude Code» است و اشاره شده که تنها چیزهایی که همه عامل‌ها می‌توانند بخوانند، HubSpot و همین فایل هستند.
برای جلوگیری از فساد داده‌ها و تداخل، عامل‌ها از یک مجموعه قراردادهای سخت‌گیرانه اما غیررسمی پیروی می‌کنند:
- برچسب زمانی (Timestamping): هر ورودی دارای تاریخ و ساعت است تا عامل‌ها مطمئن شوند جدیدترین اطلاعات را اولویت می‌دهند و تازگی تصمیمات را درک می‌کنند.
- دستورات صریح (Clear Directives): دستورالعمل‌ها به‌صورت فرمان‌های مستقیم نوشته می‌شوند. برای مثال: «عامل X: لیدهای جدید HubSpot را برای تاریخ ۲۰۲۶-۰۹-۰۹ پردازش کن».
- به‌روزرسانی وضعیت (Status Updates): عامل‌ها پس از اتمام کار، گزارش تکمیل را ثبت می‌کنند تا دیگران همان وظیفه را دوباره شروع نکنند. مثلاً: «عامل Y: پردازش لیدهای ۲۰۲۶-۰۹-۰۹ تکمیل شد. ۰ لید جدید یافت شد».
- تکرارناپذیری (Idempotency): منطق سیستم به‌گونه‌ای طراحی شده که خواندن مجدد یک دستور، باعث اجرای دوباره آن نشود؛ این موضوع حیاتی است زیرا ممکن است چندین عامل به‌طور هم‌زمان فایل را بخوانند.
پایداری عملیاتی و اثرات (Operational Stability and Impact)
اثربخشی این راهکار «کم‌تکنولوژی» در میزان زمان فعال بودن (Uptime) سیستم مشهود است. محیط عملیاتی بسیار پویا و گاهی مستعد خطا است. برای مثال، فرآیند cto-aipa در یک روز ۱۴۲ بار ری‌استارت شده و algom-stream طی ۲۴ روز، ۵۵,۱۹۳ بار متوقف و مجدداً اجرا شده است.
با وجود این نوسانات شدید، سایر اجزای اصلی به دلیل پروتکل هماهنگی پایدار مانده‌اند. به‌طور مشخص، فرآیند algom-poll برای ۴۳ روز بدون هیچ ری‌استارتی فعال مانده و n8n نیز ۲۷ روز بدون شکست اجرا شده است.
این ثبات برای خط لوله فروش رِویچوا حیاتی است. در حال حاضر ۱۱۱ معامله در مرحله «آن‌ها پاسخ دادند» (They replied) قرار دارند، اما هنوز هیچ معامله‌ای به مرحله «بسته شده و برنده» (Closed Won) نرسیده است. هماهنگی بین عامل‌ها — مثلاً شناسایی یک لید در HubSpot توسط یک عامل و ثبت یادداشت در NOW.md برای اینکه عامل دیگری آن را پردازش کند — تنها راه پیشبرد این معاملات است.
چالش‌ها و نگهداری (Challenges and Maintenance)
این رویکرد، مکانیزم‌های رسمی قفل کردن (Locking) را فدای سادگی کرده است. رِویچوا اعتراف می‌کند که هیچ قفل رسمی برای نوشتن وجود ندارد؛ عامل‌ها یا از پنجره‌های زمانی غیرهم‌پوشان برای نوشتن استفاده می‌کنند یا از منطق «فقط افزودن» (Append-only). اگر دو عامل هم‌زمان بنویسند، آخرین تغییر پیروز می‌شود. عامل‌ها به‌گونه‌ای ساخته شده‌اند که بتوانند از داده‌های قدیمی یا ورودی‌های بدشکل بازیابی شوند.
برای حفظ یکپارچگی، سیستم به سه رکن متکی است:
۱. کنترل نسخه Git: فایل NOW.md بخشی از یک مخزن گیت است و تغییرات از طریق کامیت‌ها ردیابی می‌شوند. در ۴۸ ساعت گذشته، ۴ کامیت در aideazz و ۲ کامیت در VibeJobHunterAIPA_AIMCF ثبت شده است.
۲. بازبینی دستی: هر روز بازرسی‌های دستی روی NOW.md انجام می‌شود تا اطلاعات نادرستی که توسط عامل‌ها نوشته شده، شناسایی و اصلاح شود.
۳. خودآزمایی: فایل concierge-selftest.log عملکرد را رصد می‌کند که اخیراً گزارش داده است: «۴ بررسی، ۳۲۶۰ میلی‌ثانیه تا اولین کارت».
برای یک توسعه‌دهنده، این تجربه نشان می‌دهد که بزرگ‌ترین گلوگاه در هوش مصنوعی عامل‌محور، هوش مدل نیست، بلکه «پایداری وضعیت» (State Persistence) است. ما اغلب لایه‌های ارتباطی را با پایگاه‌داده‌های پیچیده بیش‌ازحد مهندسی می‌کنیم، در حالی که یک فایل متنی ساده با کنترل نسخه، برای عملیات‌های کوچک و متوسط کافی است.
این رویکرد برای کسب‌وکارهای بدون سرمایه‌گذار (Zero-VC) یک انتخاب عمل‌گرایانه است؛ ارزان است، زیرساخت اضافی نمی‌خواهد و در محیط‌های متنوع کار می‌کند. با حرکت صنعت به سمت تولیدات واقعی، احتمالاً متوجه خواهیم شد که این راهکارهای محدود و فایل‌محور، بسیار منعطف‌تر از میان‌افزارهای پیچیده هستند. چالش بعدی، پیاده‌سازی نظارت قوی‌تر و قفل‌های صریح بدون از بین بردن سادگی‌ای است که باعث موفقیت این سیستم شده است.
در آینده باید منتظر ظهور استانداردهای «فایل وضعیت» (State-file) باشیم که به IDEهای مختلف هوش مصنوعی اجازه دهد به‌طور بومی یک فایل جلسه مشترک مانند NOW.md را همگام‌سازی کنند.
گام بعدی شما
- اگر چندین ابزار AI مختلف (مثل Cursor و Claude) را هم‌زمان استفاده می‌کنید، یک فایل
STATE.mdبسازید و آن را به هر دو معرفی کنید تا حافظه مشترکی داشته باشند. - برای مدیریت عامل‌های خود، به‌جای APIهای پیچیده، از ساختار «دستور صریح + برچسب زمانی» در فایل‌های متنی استفاده کنید.
- از Git برای ردیابی تغییرات وضعیت عامل‌هایتان استفاده کنید تا در صورت بروز خطا، بتوانید به حالت پایدار برگردید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو