‏از Obsidian تا «مغز شرکت» با ایجنت‌ها و گراف تایپ‌دار

نویسنده سال‌هاست از Obsidian به‌عنوان second brain (یعنی یه شبکه از یادداشت‌های به هم لینک‌شده برای نگه‌داشتن دانش) استفاده می‌کنه و حتی CRM کسب‌وکار یه‌نفره‌ش رو هم همونجا مدیریت می‌کنه. سؤالش اینه که همین روش تو یه شرکت بزرگ، که چند نفر هم‌زمان می‌نویسن و داده باید همیشه به‌روز بمونه، چطور کار می‌کنه. به گفتهٔ اون، LLM Wiki معروف Andrej Karpathy برای استفادهٔ شخصی خوبه، ولی تو مقیاس سازمانی جواب نمی‌ده و versioning یا فرایند بررسی نداره.

به گفتهٔ نویسنده، فایل‌های Markdown برای کار چندکاربره ساخته نشدن و گراف یادداشت‌ها هیچ typeی نداره. یعنی متن آزاده و رابطه‌ها معنای مشخصی ندارن. وقتی به‌جای هزاران یادداشت با میلیون‌ها رکورد و انواع داده مثل CSV، JSON و API سروکار داری، به index، embedding و یه سیستم مقیاس‌پذیر نیاز داری.

راه‌حل اولش branch هست. هر ایجنت یه branch و یه کپی خصوصی داره، روی اون می‌نویسه و بعد تغییراتش دقیقاً مثل یه pull request تو GitHub به main ادغام می‌شه. آدم‌ها می‌تونن merge رو رد کنن یا بعداً revert کنن و تاریخچهٔ کامل تغییرات هم می‌مونه. نویسنده میگه بدون این کار، مغزی که ایجنت‌ها پُرش می‌کنن با یه شماره‌تلفن اشتباه یا وضعیت ساختگی یه معامله، تو چند هفته غیرقابل‌اعتماد می‌شه.

برای ذخیره‌سازی، object storage مثل S3 یا R2 رو پیشنهاد می‌ده: ارزونه، سرور دیتابیس نمی‌خواد و با فرمت‌های باز مثل Parquet همه می‌تونن داده رو بخونن. قطعهٔ سوم typed graph هست، یعنی گرافی که هر node و edgeش یه شکل از قبل تعریف‌شده داره؛ مثلاً یه Person حتماً باید name داشته باشه. به گفتهٔ نویسنده، این typeها مثل data contract برای ایجنت‌ها عمل می‌کنن تا دادهٔ بی‌ربط یا ناسازگار ننویسن.

برای نمونه، نویسنده CRM شخصیش رو با OmniGraph بازسازی کرده. OmniGraph از Lance به‌عنوان فرمت ستونی باز روی object storage و از DataFusion به‌عنوان query engine استفاده می‌کنه و branchهای شبیه git رو روش می‌سازه. هر فیلد frontmatter تو Obsidian حالا type داره؛ مثلاً Hotness: 5-Cold شده یه enum که ایجنت نمی‌تونه مقدار دیگه‌ای توش بنویسه:

node Company {
    slug: String @key
    name: String @index
    hotness: enum(hot, warm, cold)? @index
}

edge WorksAt: Person -> Company { role: String? }

کل CRM سه فایله که تو git کامیت می‌شن: schema.pg با ۴ نوع node و ۷ نوع edge، queries/crm.gq با queryهای ذخیره‌شده مثل sales_funnel و warm_intro، و seed.jsonl برای داده‌ها. با دو دستور make init و make seed یه CRM با ۹۸ node و ۱۲۳ edge روی دیسک ساخته می‌شه و با عوض کردن مسیر به یه باکت S3 همون روند روی object storage اجرا می‌شه. یعنی لایهٔ context هم مثل بقیهٔ زیرساخت versioned و قابل بازتولیده.

نکات کلیدی:

• هر ایجنت روی branch خودش می‌نویسه و تغییراتش مثل pull request قبل از ادغام به main بررسی می‌شه
• داده‌ها روی object storage مثل S3 یا R2 با فرمت باز ذخیره می‌شن و سرور دیتابیس لازم نیست
• typed graph مثل data contract جلوی نوشتن دادهٔ ناسازگار توسط ایجنت‌ها رو می‌گیره
• OmniGraph از Lance برای ذخیره‌سازی و DataFusion به‌عنوان query engine استفاده می‌کنه
• دموی company-brain-crm یه CRM با ۹۸ node و ۱۲۳ edge می‌سازه