از مغز دوم شخصی تا مغز دوم تیمی
خلاصهٔ کاملتر
ایدهی اصلی مقاله سادهست: برای اینکه «مغز دوم» هوش مصنوعی از حالت شخصی به تیمی برسه، لازم نیست یه ایجنت غولپیکر مشترک برای کل تیم بسازی. به گفتهی نویسنده، باید دو چیز رو از هم جدا کنی: ایجنت شخصی که میدونه تو چطور کار میکنی، و پایگاه دانشی که ازش میخونه. ایجنت شخصی میمونه، دانش مشترک میشه. ایجنت مشترک، شخصیت و حافظهی همه رو یکدست میکنه و کل فایدهی سیستم شخصی رو از بین میبره.
چرا سیستم شخصی به تیم نمیرسه؟ یه vault سادهی Obsidian پر از فایل Markdown برای یه نفر عالی کار میکنه، چون یه نفره و به همهچی دسترسی داره. تو تیم اما اطلاعات از Slack، GitHub، داکیومنت داخلی و ویکی میاد و آدمها سطح دسترسی متفاوت دارن. یه پوشهی فایل نه مفهوم permission داره، نه راهی که جلوی دیدن بحثهای محرمانه رو بگیره، نه جستوجوی درستحسابی روی حجم بالا.
معماری پیشنهادی چهار لایه داره. لایهی شخصی: ایجنت خود فرد با شخصیت و حافظهی خودش، تو هر رابطی که الان استفاده میکنه. لایهی مشترک: یه دیتابیس مرکزی که همهچی رو تو یه schema واحد نگه میداره، معمولاً یه جدول documents با فیلدهایی مثل title، text، url، author و برچسب دامنه، نه جدول جدا برای هر منبع.
دو لایهی بعدی چسب این ماجرا هستن. لایهی connector: برای هر منبع یه اتصال که تنها کارش اینه داده رو بکشه بیرون و به همون قالب استاندارد تبدیل کنه. لایهی MCP: یه سرور سبک MCP که بین ایجنتهای شخصی و دیتابیس مشترک میشینه و چند ابزار ساده میده: تأیید هویت، جستوجوی سند، گرفتن کامل سند و پیدا کردن اینکه چه کسی روی یه موضوع صاحبنظره.
سیستم مجوزدهی دو مرحله داره. اول موقع ingestion هر سند یه برچسب دامنه میگیره، مثل ops یا marketing، و یه سند میتونه چند برچسب با هم داشته باشه. دوم، یه جدول principal توکن دسترسی هر آدم رو به دامنههایی که مجازه وصل میکنه. موقع query، دیتابیس هویت رو از توکن درمیاره و نتیجه رو در سطح ردیف فیلتر میکنه. اگه دسترسی نباشه، سند یا کلاً نامرئی میشه یا وجودش اعلام میشه بدون محتوا، با اشاره به آدمی که باید ازش پرسید.
نکتهی امنیتی مهم مقاله اینه که این بررسی حتماً باید داخل خود دیتابیس انجام بشه، نه تو ایجنت شخصی؛ چون اگه سمت کاربر باشه، با دستکاری کانفیگ ایجنت یا prompt injection میشه دورش زد. نویسنده میگه هزینهی این معماری فقط زمان راهاندازی اولیهست: ساختن connectorها، تعریف برچسبها، صدور توکن و بالا آوردن سرور MCP. مثال مقاله با Oracle AI database پیاده شده ولی خودش تأکید میکنه معماری به دیتابیس خاصی گره نخورده.
نکات کلیدی:
- ایجنت شخصی هر نفر دستنخورده میمونه؛ فقط پایگاه دانش مشترک میشه
- همهی منابع مثل Slack و GitHub و ویکی به یه schema واحد مثل جدول documents نرمال میشن
- هر سند موقع ingestion برچسب دامنه میگیره و میتونه چند برچسب داشته باشه
- جدول principal توکن هر کاربر رو به دامنههای مجازش وصل میکنه
- فیلتر دسترسی در سطح ردیف و داخل دیتابیس انجام میشه، نه تو ایجنت شخصی
- معماری به دیتابیس خاصی گره نخورده؛ مثال مقاله با Oracle AI database بوده




