تصور کنید هر بار که از یک دستیار هوش مصنوعی به دستیار دیگر می‌روید، مجبور باشید تمام جزئیات پروژه‌تان را از ابتدا تعریف کنید. این گسست حافظه، بزرگ‌ترین مانع در مسیر بهره‌وری از عامل‌های هوش مصنوعی است، مگر اینکه کنترل حافظه را از شرکت‌های سازنده بگیرید و به سرور شخصی خود منتقل کنید.
به گزارش وب‌سایت dev.to، یک توسعه‌دهنده تا ۶ سپتامبر ۲۰۲۶ ثابت کرد که یک پوشه ساده از فایل‌های Markdown می‌تواند به‌عنوان «مغز مشترک» برای عامل‌های مختلف عمل کند. در حال حاضر، اکثر کاربران با «جزیره‌های دانشی» (Knowledge Fiefdoms) دست‌وپنجه نرم می‌کنند؛ جایی که ابزارهایی مثل Claude (با قابلیت Projects)، Perplexity (با Spaces) و عامل‌های مختلف کدنویسی، تاریخچه‌های مجزایی دارند. این تکه‌تکه شدن باعث می‌شود کاربران مجبور شوند برای یک پروژه واحد، بارها و بارها بستر (Context) را در پلتفرم‌های مختلف بازسازی کنند و در ابتدای هر گفتگو، تاریخچه کارهای خود را دوباره توضیح دهند. این چالش دقیقاً همان دلیلی است که گردش‌کارهای مبتنی بر Markdown را برای پژوهش‌های ساختارمند، جایگزینی کارآمدتر برای تاریخچه‌های خطی چت می‌کند. راهکار این مشکل، تغییر رویکرد به سمت «پایداری وضعیت تحت مالکیت کاربر» است؛ یعنی انتقال حافظه از زیرساخت ارائه‌دهنده مدل به زیرساخت شخصی کاربر.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مالکیت داده‌ها کلید استقلال کاربر است. این راهکار جدید، حافظه را از زیرساخت ارائه‌دهنده مدل خارج کرده و به زیرساخت شخصی کاربر می‌برد.
جست‌وجو برای یک مغز دوم
این پروژه با الهام از یک همکار به نام «سیوا» (Siva) آغاز شد که یک «مغز دوم» روی Notion ساخته بود. سیستم سیوا به ابزارهای هوش مصنوعی او متصل بود و ثبت اطلاعات را به‌صورت خودکار انجام می‌داد، که به او اجازه می‌داد هر چیزی را که جمع‌آوری کرده بود، استعلام کند. اما نویسنده سه شرط سخت‌گیرانه داشت که پیاده‌سازی سیستمی شبیه به Notion را برای او غیرممکن می‌کرد.
اول، او حاضر نبود ابزار یادداشت‌برداری جدیدی را بپذیرد، زیرا پیش از این در محیط Obsidian مستقر شده بود و تمایلی به تجربه یک مهاجرت داده‌ای دیگر نداشت. دوم، او می‌خواست از پرداخت اشتراک‌های ابری جدید برای متصل کردن اجزای سیستم اجتناب کند. در نهایت، نویسنده اصرار داشت که کل پشته (Stack) نرم‌افزاری را روی یک سرور خانگی میزبانی کند و در این باره اشاره کرد که «میزبانی شخصی نیمی از لذت (یا شاید دردسر) این کار است».
بررسی جایگزین‌ها
قبل از ساخت این سیستم سفارشی، مسیرهای موجود دیگری بررسی شدند:
- پلتفرم‌های حافظه-محور: ابزارهایی مثل mem0، Supermemory و LangMem مورد بررسی قرار گرفتند. نویسنده نسخه آزمایشی mem0 را اجرا کرد، اما متوجه شد این پلتفرم‌ها به‌عنوان حافظه‌ای برای «عامل‌ها» طراحی شده‌اند (جایی که هوش مصنوعی می‌خواند و می‌نویسد)، نه به‌عنوان یک ویکی شخصی که انسان بتواند به‌راحتی در آن جست‌وجو کرده و یادداشت‌ها را ویرایش کند.
- سرورهای MCP برای Obsidian: این مسیر کوتاه‌ترین راه به نظر می‌رسید، اما گزینه‌های موجود بیش از حد شکننده بودند. این ابزارها یا نیاز داشتند برنامه دسکتاپ Obsidian از طریق پلاگین Local REST API در حال اجرا باشد، یا فقط از پروتکل stdio پشتیبانی می‌کردند و یا به یک پل ارتباطی (Proxy Bridge) نیاز داشتند. هدف نویسنده، داشتن یک سرور بدون رابط گرافیکی (Headless) بود که برای فعال ماندن، وابسته به اجرای یک برنامه دسکتاپ نباشد.
- پلتفرم‌های ابری: Notion و ابزارهای مشابه سریع‌ترین راه برای راه‌اندازی بودند، اما با محدودیت‌های اصلی نویسنده در مورد عدم پرداخت اشتراک‌های جدید و لزوم عدم مهاجرت از Obsidian در تضاد بودند.
معماری فنی سیستم
بر اساس مستندات این پروژه در dev.to، سیستم روی یک سرور خانگی و از طریق یک فایل Docker Compose با سه سرویس اصلی اجرا می‌شود:
- markdown-vault-mcp: یک سرور متن‌باز MCP که یک پوشه ساده از فایل‌های Markdown را به‌عنوان مخزن (Vault) می‌شناسد. این سرویس قابلیت جست‌وجوی کلیدواژه‌ای از طریق FTS5 و جست‌وجوی معنایی (Semantic Search) با استفاده از مدل‌های Embedding را اضافه می‌کند. نویسنده اشاره کرد که هزینه تبدیل کل مخزن به بردارهای معنایی تنها چند سنت بوده است.
- obsidian-headless: یک رابط خط فرمان (CLI) در یک کانتینر Node که فایل‌ها را با استفاده از اشتراک موجود Obsidian Sync بین دستگاه‌ها همگام می‌کند. این امر تضمین می‌کند هر چیزی که یک عامل هوش مصنوعی روی سرور می‌نویسد، به‌طور خودکار روی گوشی و لپ‌تاپ نویسنده ظاهر شود.
- cloudflared: یک کانکتور Cloudflare Tunnel که دسترسی امن و فقط-خروجی (Outbound-only) ایجاد می‌کند. این یعنی سرور به Cloudflare متصل می‌شود و نیازی به باز کردن پورت‌های ورودی یا مدیریت IP عمومی نیست؛ روشی که بسیار امن‌تر از باز گذاشتن یک پورت فوروارد شده به‌صورت «موقت» است.
برای مدیریت امنیت، نویسنده از OAuth از طریق Google Cloud Platform (GCP) استفاده کرد. این قابلیت اجازه می‌دهد ابزارهای جدید هوش مصنوعی به‌جای دریافت دستی کلیدهای API یا کپی کردن رمزهای محرمانه، از طریق یک ورود ساده با حساب گوگل متصل شوند.
یکپارچه‌سازی و عملکرد
این سیستم به چندین عامل برجسته از جمله Perplexity (که به اسب کاری اصلی تبدیل شد)، Grok، Antigravity، GitHub Copilot و Gemini Spark متصل شده است. نکته قابل توجه این است که نویسنده به‌طور عمدی ابزارهای مرتبط با کار مانند Claude و Claude Code را حذف کرد. این یک تصمیم آگاهانه بود تا «ماموریت‌های جانبی» شخصی از کارهای حرفه‌ای مشتریان جدا بماند و ریسک نشت مالکیت معنوی (IP) مشتریان، قراردادهای محرمانه (NDA) یا الزامات امنیتی شرکتی به پروژه‌های شخصی منتقل نشود.
دو تصمیم کلیدی در پایداری و ثبات سیستم نقش داشتند:
۱. دسترسی محدود (Scoped Access): سرور MCP تنها یک زیرپوشه از مخزن را مونت (Mount) می‌کند تا عامل‌ها نتوانند فایل‌های خارج از آن محدوده را ببینند یا خراب کنند، در حالی که سرویس همگام‌سازی به ریشه (Root) دسترسی دارد.
۲. دستورالعمل‌های جهانی: یک فایل به نام AGENTS.md در ریشه مخزن قرار دارد که در ترکیب با دستورالعمل‌هایی که سرور هنگام اتصال به هر کلاینت ارسال می‌کند، تضمین می‌کند قوانین یکسانی برای تمام عامل‌ها اجرا شود.
در ابتدا مشکلاتی در عملکرد مشاهده شد که پس از بررسی مشخص شد مربوط به کم بودن منابع ماشین مجازی Rancher Desktop است و نه تأخیر در شبکه. نویسنده ابتدا گمان می‌کرد اختلالی در Cloudflare رخ داده است، اما پس از افزایش منابع VM، تمام ناپایداری‌ها برطرف شد.
قدرت جست‌وجوی ترکیبی
مهم‌ترین یافته پس از یک ماه استفاده، کارایی جست‌وجوی ترکیبی (Hybrid Search) بود. نویسنده دریافت که این دو روش نقاط ضعف یکدیگر را پوشش می‌دهند:
- جست‌وجوی کلیدواژه‌ای: برای یافتن دقیق یک عبارت یا اصطلاحات خاص.
- جست‌وجوی معنایی: به کاربر اجازه می‌دهد مبهم صحبت کند و «بگذارد هوش مصنوعی موضوع را بفهمد»؛ یعنی به‌جای ذکر دقیق کلمات، توصیف کند که یادداشت درباره چیست.
این ترکیب باعث می‌شود عامل‌ها توکن‌های کمتری را برای استخراج داده‌های بی‌ربط مصرف کنند و مخزن بتواند به‌طور یکپارچه پروژه‌های شخصی و کارهای دانشی را پشتیبانی کند. نویسنده اشاره کرد که حالا بازگشت به پروژه‌ای که هفته‌ها رها شده، دیگر نیازی به گشتن در تاریخچه‌های طولانی و خسته‌کننده چت ندارد.
تحلیل: تغییر رویکرد به سمت وضعیت محلی (Local State)
این پروژه نشان‌دهنده یک حرکت گسترده‌تر به سمت حافظه «اول-محلی» (Local-first) در هوش مصنوعی است. با استفاده از Markdown — که زبانی جهانی و قابل خواندن برای انسان و ماشین است — کاربر از وابستگی به یک ارائه‌دهنده خاص (Vendor Lock-in) رها می‌شود. همان‌طور که نویسنده مشاهده کرد، هر ابزاری می‌تواند Markdown را بخواند و بنویسد و کاربر می‌تواند بدون نیاز به واسطه بودنِ یک عامل، هر یادداشتی را شخصاً باز کند.
برای کاربر عملی، این یعنی «هزینه» تغییر مدل هوش مصنوعی تقریباً به صفر می‌رسد. اگر فردا عامل بهتری معرفی شود، کاربر به‌سادگی آن را به سرور MCP خود متصل می‌کند و ابزار جدید فوراً به تمام تاریخچه پروژه‌ها، لیست‌های انجام‌کار (To-do lists) و «ایده‌های درخشان» او دسترسی خواهد داشت. هزینه مالی کل این راهکار، به‌جز سخت‌افزار و اشتراک‌های موجود، تنها «چند سنت» برای Embeddingها گزارش شده است.
برای بازسازی این سیستم، کاربران باید پیاده‌سازی متن‌باز markdown-vault-mcp را بررسی کنند و مطمئن شوند که یک روش همگام‌سازی بدون رابط گرافیکی (Headless Sync) برای ویرایشگر Markdown مورد علاقه‌شان دارند.
گام بعدی شما
- اگر از Obsidian استفاده می‌کنید، پیاده‌سازی
markdown-vault-mcpرا برای متصل کردن یادداشت‌هایتان به مدل‌های مختلف بررسی کنید. - برای جلوگیری از نشت داده‌ها، حتماً دسترسی عامل‌ها را به زیرپوشه‌های خاص (Scoped Access) محدود کنید.
- یک فایل
AGENTS.mdبسازید و استانداردهای پاسخ‌دهی مورد نظرتان را در آن بنویسید تا تمام مدل‌ها رفتار یکسانی داشته باشند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو