تصور کنید یک عامل هوش مصنوعی دارید که به محض پایان هر جلسه، تمام آموخته‌هایش را فراموش می‌کند و هر بار باید از نقطه صفر شروع کند. اونیجنیو گلبور (Eugeniu Ghelbur) با انتشار obsidian-second-brain — یک مخزن با مجوز MIT — این شکاف حافظه را پر کرد تا یادداشت‌های ایستا تبدیل به حافظه‌ای زنده برای مدل‌ها شوند. این پروژه تا همین حالا ۴.۷ هزار ستاره در گیت‌هاب کسب کرده است.
بسیاری از ما از Obsidian فقط به عنوان یک بایگانی غیرفعال استفاده می‌کنیم؛ شبیه به انباری از پوشه‌ها که سال‌ها دست‌نخورده می‌مانند و به ندرت بازخوانی می‌شوند. اما این چارچوب، دینامیک بازی را عوض می‌کند و با مخزن یادداشت‌ها مانند منبع اصلی حقیقت برخورد می‌کند که هوش مصنوعی فعالانه آن را مدیریت و به‌روزرسانی می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی نحوه تولید سیگنال‌های متنی توسط مدل‌های زبانی برای بازارهای کریپتو اشاره کردیم، این رویکرد از بازیابی ساده (Retrieval) فراتر رفته و به نوعی «متابولیسم دانش» تبدیل شده است.
الگوی کارپاتی
این سیستم تکامل‌یافته‌ای از الگوی Karpathy LLM Wiki است. در ایده اولیه، یک پایگاه دانش در قالب ویکی توسط یک مدل زبانی بزرگ (LLM) مدیریت می‌شود؛ به گونه‌ای که مدل صفحات جدید می‌سازد، آن‌ها را به هم لینک می‌کند و در صورت درخواست، الگوها را استخراج می‌کند. اما آن نسخه غیرفعال بود؛ به این معنا که تضادهای اطلاعاتی در یادداشت‌ها باقی می‌ماندند تا زمانی که یک انسان آن‌ها را شناسایی و حل کند.
حافظه فعال
این پروژه الگوی مذکور را به حالت فعال درآورده است. طبق مستندات پروژه، این سیستم یک عامل CLI ارائه می‌دهد که با ابزارهایی مثل Claude Code، Codex، Gemini CLI و چهار ابزار دیگر سازگار است. این قابلیت‌ها در راستای استراتژی‌های جدید برای خودکارسازی حافظه در Claude Code قرار می‌گیرند تا مدیریت تغییرات در حافظه عامل‌ها به شکلی پویا صورت گیرد. این عامل دارای مجموعه‌ای از ۴۷ عملیات تخصصی است تا بتواند مستقیماً روی مخزن یادداشت‌ها اثر بگذارد.
قابلیت‌های کلیدی
- عملیات اجرایی (۳۰ دستور): شامل
/obsidian-reconcileبرای حل تضادهای اطلاعاتی،/obsidian-healthبرای بررسی سلامت و Lint کردن مخزن و/obsidian-architectبرای مستندسازی کدها در قالب یادداشت است. این ابزار می‌تواند URLها، PDFها، فایل‌های صوتی و حتی اسکرین‌شات‌ها را جذب کرده و به یادداشت‌های استاندارد تبدیل کند. - ابزارهای تفکر (۹ دستور): دستور
/obsidian-challengeمدل را مجبور می‌کند بر اساس تاریخچه خود کاربر، با او بحث کند و دیدگاه‌های متناقض ارائه دهد. دستور/obsidian-emergeبه دنبال الگوهای نام‌گذاری نشده در یادداشت‌ها می‌گردد و/obsidian-connectپل‌هایی میان دامنه‌های مختلف دانش ایجاد می‌کند. - مدیریت زمینه (۱ دستور): دستور
/obsidian-worldهویت و وضعیت مدل را با استفاده از بودجه‌های توکنی بارگذاری می‌کند که از سطح سبک L0 تا سطح کامل L3 متغیر است. - پژوهش (۷ دستور): دستور
/research-deepابتدا یادداشت‌های داخلی را می‌کاود و فقط در صورتی که شکاف‌های اطلاعاتی باقی بماند، به جستجوی وب مراجعه می‌کند. - اتوماسیون: چهار عامل زمان‌بندی‌شده برای بررسی‌های صبحگاهی، شبانه، بررسی‌های جمعه (Friday Review) و چک‌آپ‌های سلامت یکشنبه تعریف شده‌اند. هدف طراحی این است که مخزن یادداشت‌ها حتی بدون حضور شما، زنده بماند و رشد کند.
از نظر مهندسی، این پروژه برای جلوگیری از تلهٔ «اتصال ساده GPT به یادداشت‌ها»، دو قانون سخت‌گیرانه دارد. اول، استفاده از «متابولیسم باز دانش» (Open Knowledge Metabolism)؛ هر حقیقت باید یا بی‌زمان (Timeless) باشد، یا تاریخ‌دار یا یک اشاره‌گر (Pointer). دانش‌های کند-تغییر در یادداشت می‌مانند و حقایق سریع-تغییر به منبع زنده لینک می‌شوند و یک تاریخ «تا این لحظه» (as of) می‌گیرند که توسط یک مشخصه (Spec) و یک Linter اجبار می‌شود.
دوم، استفاده از حقایق دو-زمانی (bi-temporal) است که هم زمانِ درست بودن یک حقیقت در دنیای واقعی و هم زمانِ یادگیری آن توسط سیستم را ثبت می‌کند. این قابلیت به مدل اجازه می‌دهد به پرسش‌های حیاتی مثل «این موضوع از چه زمانی دیگر درست نیست؟» پاسخ دهد.
برای جلوگیری از پر شدن پنجرهٔ زمینه (Context Window) — که مثل میز کاری است که فقط جای چند ورق دارد، نه کل کتابخانه — سیستم از یک قلاب (hook) برای بازیابی محدود استفاده می‌کند. این چالش مدیریت حافظه در سطح زیرساختی، یادآور بحث‌های تخصصی پیرامون حافظه مجازی در برابر تخصیص ایستا در مدیریت KV-Cache است که برای رفع گلوگاه‌های حافظه در مدل‌های زبانی پیشنهاد شده است. هر پرامپت حداکثر به چهار یادداشت با طول تقریبی ۹۰۰ کاراکتر محدود می‌شود. این رویکرد زیرساخت‌محور با ۷۶۳ تست در CI و هشت بیلد اختصاصی برای پلتفرم‌های مختلف پشتیبانی می‌شود.
این تغییر، طراحی اسناد را وارونه می‌کند. دهه‌ها انسان اسناد را برای ماشین‌ها بهینه کرد؛ اما اینجا اسناد دقیقاً برای خواندن توسط عامل‌ها نوشته می‌شوند و از Frontmatter، نشانگرهای تازگی (Recency Markers) و منابع عین‌به‌عین (Verbatim) استفاده می‌کنند. نتیجه سیستمی است که در آن مخزن یادداشت‌ها از ابزار CLI طولانی‌تر عمر می‌کند. چون مدل‌ها هر ۶ ماه عوض می‌شوند، ذخیره دانش در قالب Markdown تضمین می‌کند که مالکیت داده با کاربر است، نه ابزار.
این الگو اکنون در مقیاس تجاری نیز در حال گسترش است. برخی CRMهای تولیدی از همین معماری برای ردیابی مشتریان، معاملات، وظایف، صورت‌حساب‌ها، زیرساخت‌ها و مکاتبات استفاده می‌کنند. برای مثال، وظیفه‌ای که برچسب «فوری» و «مهم» داشته باشد، به‌طور خودکار در ربع مناسب ماتریس آیزنهاور در داشبورد قرار می‌گیرد:
title: "Connect payment webhook to the CRM"
urgent: true
important: true
hours: 3
در این محیط‌های تجاری، مخزن مانند یک دفترچه یادداشت مشترک است که نقش‌های مختلف AI (به عنوان یک «هیئت مدیره») در آن فعالیت می‌کنند؛ مثلاً یک AI در نقش مدیرعامل (CEO) برنامه هفتگی را نگه می‌دارد، یک AI در نقش مدیر مالی (CFO) جریان وجوه نقد و کف قیمت‌ها را مدیریت می‌کند و یک مدیر تجاری مسئول وصول‌هاست. در این ساختار، همگی در فایل‌های یکسانی می‌خوانند و می‌نویسند. حتی یک داشبورد ارتقاء می‌تواند معناشناسی، پوشش محتوا، ترافیک و داده‌های پنج شبکه اجتماعی را در یک فایل JSON جمع کند که هم توسط عامل و هم توسط مالک خوانده می‌شود.
با این حال، استقرار تجاری نیازمند انضباط بیشتری است. یک یادداشت غلط در مخزن شخصی مزاحم است، اما خطای پرداخت یا نشت داده‌های شخصی در یک CRM هزینه مالی و ضربه به اعتبار دارد. بنابراین نسخه‌های تجاری باید تایید انسانی برای اقدامات حساس، رمزنگاری داده‌های شخصی (از طریق مخزنی که خودکار قفل می‌شود) و ثبت دقیق لاگ تصمیمات (که نشان دهد چه کسی، چه کاری و چرا انجام داده) را اولویت قرار دهند. همچنین شرکت باید به عنوان یک اپراتور ثبت‌شده داده‌های شخصی فعالیت کند.
اگر شما یک مخزن Obsidian دارید، این مخزن کد کوتاه‌ترین مسیر برای دادن حافظه دائمی و تکامل‌یافته به عامل‌هایتان است. هدف، سیستمی است که حتی وقتی با آن تعامل ندارید، زنده بماند و رشد کند.
گام بعدی شما
- مخزن obsidian-second-brain را از گیت‌هاب کلون کرده و با یکی از CLIهای سازگار (مثل Claude Code) تست کنید.
- یادداشت‌های فعلی خود را با استفاده از دستور
/obsidian-healthبررسی کنید تا متوجه شوید مدل کجاها دچار سردرگمی می‌شود. - یک گردش‌کار اتوماسیون برای بررسی‌های هفتگی (Friday Review) تعریف کنید تا مدل الگوهای جدید را در یادداشت‌هایتان کشف کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو