kgai: ثبت تصمیمات فنی تیم‌ها به‌جای حافظهٔ کلی هوش مصنوعی

تصور کنید تیمی هستید که سه ماه است با Claude Code کد می‌زند؛ حالا از عامل می‌خواهید قابلیت جست‌وجو را اضافه کند و او Elasticsearch را پیشنهاد می‌دهد، در حالی که تیم شما همین بهار این ابزار را به دلیل هزینه رد کرده بود. چون این تصمیم در یک رشته گفتگو (Thread) قدیمی دفن شده و کسی که تصمیم‌گیرنده بوده حالا در تیم دیگری است، عامل هوش مصنوعی راهی برای دانستن آن ندارد و شما مجبورید دوباره همان بحث تکراری را شروع کنید.

این شکاف در توسعه نرم‌افزار به این دلیل است که ابزارهای فعلی روی «سلیس نوشتن کد» تمرکز دارند، نه «به‌یاد آوردن دلیل وجود کد». عامل می‌تواند منطق را بنویسد، اما نمی‌داند تیم شما قبلاً چه مسیرهایی را امتحان کرده و چرا آن‌ها را کنار گذاشته است. این دانش معمولاً در ذهن افراد است و هر جلسه جدید با مدل، از نقطه صفر شروع می‌شود. صنعت تلاش کرده با افزودن لایه‌های حافظه این مشکل را حل کند، اما ابزارهای عمومی تفاوت‌های ظریف تاریخچه تصمیمات تیمی را درک نمی‌کنند. همان‌طور که در پوشش پیشین ما از Claude-Account دیدیم که مدیریت پروفایل‌های مجزا را برای کاربران لینوکس ممکن کرد، چالش فعلی برنامه‌نویسان گذار از مدیریت جلسات فردی به یک «هوش تیمی مشترک و پایدار» است.

شکست لایه‌های حافظه عمومی

لایه حافظه (Memory Layer) — شبیه دفترچه یادداشتی است که مدل برای هر کاربر نگه می‌دارد تا ترجیحات او را فراموش نکند — در ابزارهای عمومی برای ثبت حقایق متغیر طراحی شده است. ثبت حقایق درباره یک کاربر و ردیابی تغییر آن‌ها در طول زمان، یک مسئله واقعی و دشوار است و این ابزارها در این زمینه عملکرد خوبی دارند. با این حال، طبق یک تحلیل دقیق منتشر شده در dev.to، سه ابزار محبوب یعنی mem0، Graphiti و Cognee اگرچه مسائل مرتبطی را حل می‌کنند، اما در ثبت رکورد مشترک تصمیمات معماری تیم‌ها شکست می‌خورند.

mem0 از یک لایه حافظه بردار-محور با مجوز Apache-2.0 استفاده می‌کند. این ابزار یک پلتفرم میزبانی‌شده (Hosted) و یک ادغام تمیز برای Claude Code از طریق پروتکل MCP (Model Context Protocol) ارائه می‌دهد که حقایق را به‌طور خودکار استخراج و بازیابی می‌کند. اما mem0 حافظه را به‌عنوان حقایق در سطح کاربر (User-scoped) می‌بیند. وقتی یک حقیقت جدید با یک حقیقت قدیمی در تضاد باشد، mem0 با به‌روزرسانی یا حذف نسخه اصلی، آن‌ها را تطبیق می‌دهد. این مدل برای شخصی‌سازی عالی است، اما برای تاریخچه تصمیمات کاملاً اشتباه است؛ زیرا دقیقاً همان دلیلی که یک رویکرد (مثلاً رویکرد A) رد شد — یعنی همان چیزی که شما نیاز دارید حفظ کنید — حذف یا بازنویسی می‌شود.

Graphiti که توسط تیم Zep توسعه یافته، رویکرد «گراف-محور» دارد و یک گراف دانش زمانی (Temporal Knowledge Graph) می‌سازد. برخلاف mem0، این ابزار وقتی اطلاعاتی با یک حقیقت در تضاد است، یال‌های قدیمی را حذف نمی‌کند؛ بلکه آن‌ها را «نامعتبر» علامت می‌زند و مرزهای زمانی را حفظ می‌کند. این قابلیت به کاربران اجازه می‌دهد بپرسند «آن زمان چه چیزی درست بود در مقابل اینکه اکنون چه چیزی درست است». همچنین اجازه تعریف انواع سفارشی برای موجودات (Entities) و یال‌ها (Edges) را می‌دهد. اگرچه این مدل غیرتخریبی، ابزار اولیه‌ی درستی است، اما هزینه‌های عملیاتی بسیار بالایی دارد. کاربران باید یک پایگاه‌داده گرافی (مانند Neo4j، FalkorDB یا Neptune)، یک مدل زبانی بزرگ (LLM) و یک خط لوله بردار معنایی (Embedding Pipeline) را اجرا کنند تا داده‌ها را به‌عنوان «اپیزودهای ساختاریافته» جذب نمایند.

Cognee نیز یک موتور حافظه متن‌باز (تحت مجوز Apache-2.0) است که داده‌ها را به گراف دانش تبدیل می‌کند. این ابزار بسیار انعطاف‌پذیر است و می‌تواند روی هر محیطی، از یک نسخه تک‌نفره Postgres تا یک استک کامل گرافی-برداری، اجرا شود. Cognee شامل یک پلاگین برای Claude Code است و از هستی‌شناسی‌های (Ontologies) سفارشی پشتیبانی می‌کند. با این حال، این ابزار فاقد سیستم داخلی برای نسخه‌بندی یا جایگزینی حقایق (Supersession) است. اگر یک تصمیم جایگزین تصمیم قبلی شود و شما بخواهید نسخه اصلی را حفظ کنید، باید این منطق را خودتان به‌صورت دستی برنامه‌ریزی کنید.

دو شکاف حیاتی

صرف‌نظر از ابزار مورد استفاده، هنگام به‌کارگیری آن‌ها در گردش کار یک تیم کدنویسی، دو شکاف اصلی ظهور می‌کند:

• شکاف معنایی (Semantic Gap): هیچ‌کدام از این ابزارها «تصمیم» را به‌عنوان یک موجودیت درجه‌یک (First-class entity) نمی‌شناسند. هیچ مفهوم داخلی برای «تصمیم»، «منطق/دلیل تصمیم»، «گزینه‌های بررسی‌شده و رد شده» یا «لینک از یک تصمیم جدید به تصمیمی که جایگزین آن شده» وجود ندارد. درست است که Graphiti اجازه می‌دهد این موارد را از طریق هستی‌شناسی‌های سفارشی شبیه‌سازی کنید، اما در واقع شما مدل را از صفر می‌سازید، به‌جای اینکه از یک مدل موجود استفاده کنید.
• شکاف عملیاتی (Operational Gap): این‌ها لایه‌های حافظه برای «حقایق» هستند. برای اینکه یکی از این ابزارها برای کل تیم کار کند، باید یک بک‌اِند مشترک و چند-نویسنده‌ای (Multi-author) راه‌اندازی کنید که همه در آن بخوانند و بنویسند و شامل یک فرآیند بازبینی (Review) باشد. این کار مستلزم یک ذخیره‌گاه برداری، یک پایگاه‌داده گرافی یا هر دو، به‌علاوه یک LLM برای استخراج داده در هر بار نوشتن و یک سرویس برای مدیریت رابط کاربری است. در نتیجه، برای فرار از یک بحث تکراری، شما باید یک پروژه زیرساختی عظیم را مدیریت کنید.

جایگزین kgai

پروژه kgai که در جولای ۲۰۲۶ نسخه ۱.۰ خود را عرضه کرد، با تغییر مسیر از حافظه عمومی به تمرکز انحصاری بر «تصمیمات ساختاری کد»، این مشکل را حل کرد. kgai سعی نمی‌کند یک لایه حافظه عمومی باشد؛ بلکه تصمیمات را به‌صورت یک گراف تغییرناپذیر (Immutable Graph) ثبت می‌کند. در kgai، هر تصمیم همراه با دلیل (Rationale) خود ذخیره می‌شود تا حتی پس از خروج تصمیم‌گیرنده از تیم، «چرایی» آن تصمیم زنده بماند.

در kgai، وقتی یک تصمیم تغییر می‌کند، تصمیم جدید از طریق یک لینک صریح جایگزین تصمیم قدیمی می‌شود. «بن‌بست‌ها» به‌طور عمدی حفظ می‌شوند؛ چون رکورد اینکه «ما روش X را امتحان کردیم، یک روز وقت صرف شد و به این دلیل متوقف شد»، بسیار ارزشمندتر از حذف کامل آن است. سیستم بازیابی به‌گونه‌ای طراحی شده است که فقط تصمیمات «فعلی» را برمی‌گرداند تا عامل ابتدا تصویر کلی را بفهمد و سپس کد بزند، در حالی که تصمیمات جایگزین شده برای ممیزی (Auditing) در دسترس می‌مانند.

مدل عملیاتی kgai به‌صورت «محلی-محور» (Local-first) است. ذخیره‌گاه داده‌ها داخل پوشه پروژه قرار دارد و نیاز به سرورهای گرافی، پایگاه‌داده‌های برداری یا خط لوله‌های Embedding را کاملاً حذف می‌کند. این ابزار به‌عنوان یک پلاگین برای Claude Code با دو دستور ساده نصب می‌شود. ثبت تصمیمات در طول جلسه انجام می‌شود و یک قلاب (Hook) در پایان هر نوبت (Turn)، هر تصمیمی که مدل فراموش کرده ثبت کند را شکار کرده و ضبط می‌کند. گراف به‌صورت قطعی (Deterministic) از روی لاگ بازسازی می‌شود تا ثبات داده‌ها در تمام ماشین‌های هم‌تیمی‌ها تضمین شود.

همگام‌سازی تیمی در kgai اختیاری است و از طریق یک S3 Bucket که متعلق به خود شماست مدیریت می‌شود. این سیستم از یک مکانیزم «آگاه از تداخل» (Conflict-aware) استفاده می‌کند و برخلاف سیستم‌های ساده، منطق «آخرین نویسنده برنده است» را ندارد. اگرچه همگام‌سازی از طریق Git-remote پشتیبانی می‌شود، اما هنوز آزمایشی است و S3 مسیر توصیه‌شده است. از زمان انتشار نسخه ۱.۰، کاربران می‌توانند یک مقصد پیش‌فرض برای کل ماشین را با دستور kg remote --global تنظیم کنند تا پروژه‌های جدید بدون تنظیمات تکی هر پروژه، همگام‌سازی شوند. در بنچمارک‌های مربوط به یک میلیون تصمیم توسط ۳۰ نویسنده، زمان جست‌وجو به‌طور میانگین حدود ۱۰۰ میلی‌ثانیه بود.

تحلیل: دامنه در مقابل کاربرد

این تغییر رویکرد، نشان‌دهنده گذار از «به یاد آوردن همه چیز» به «به یاد آوردن چیزهای درست» است. لایه‌های حافظه عمومی برای تجربه‌های کاربر-محور طراحی شده‌اند، جایی که هدف، به‌یاد آوردن ترجیحات کاربر است. اما در مهندسی نرم‌افزار حرفه‌ای، ارزش در حقایق کلی نیست، بلکه در ریشه‌یابی بدهی‌های فنی (Technical Debt) و موازنه‌های معماری (Architectural Trade-offs) است.

با محدود کردن هدف، kgai سربارهای زیرساختی را که Graphiti و Cognee را برای بسیاری از تیم‌ها غیرعملی می‌کرد، حذف می‌کند. این ابزار با مجوز MIT منتشر شده است و از نسخه ۱.۰، قالب لاگ‌های روی دیسک، رابط CLI و ساختارهای خروجی JSON آن از سیستم نسخه‌بندی معنایی (Semver) پیروی می‌کنند. هرگونه تغییر شکست‌دهنده (Breaking Change) در این اجزا، مستلزم ارتقای نسخه اصلی (Major Version Bump) است.

بهای این رویکرد، محدودیت دامنه است: kgai نمی‌تواند ترجیحات کاربر، تاریخچه conversations تصادفی یا حقایق مربوط به محصولات مختلف را به یاد آورد. برای این نیازها، mem0، Graphiti و Cognee همچنان بهترین انتخاب‌ها هستند. با این حال، برای مسئله خاص «لغزش تصمیمات» (Decision Drift)، یک لاگ تغییرناپذیر و تخصصی بسیار ارزشمندتر از یک پایگاه‌داده انعطاف‌پذیر و قابل ویرایش است.

اگر به عاملی نیاز دارید که ترجیحات شخصی شما را مدیریت کند، لایه‌های عمومی قوی هستند. اما برای تیم‌هایی که ساعت‌ها وقتشان را تلف بحث‌های معماری تکراری می‌کنند، مدل گراف تغییرناپذیر و محلی kgai مسیری به سوی حافظه دائمی تیمی، بدون نیاز به کابوس‌های DevOps است. این پلاگین متن‌باز است، از نسخه v1.0.0 پایدار شده و با دو دستور نصب می‌شود. برای جزئیات بیشتر، بنچمارک‌ها و محدودیت‌های شناخته شده، به kgai.dev مراجعه کنید.

برای شروع ردیابی تاریخچه معماری پروژه خود، می‌توانید پلاگین را از طریق مارکت‌پلیس Claude نصب کنید:

claude plugin marketplace add kgaidev/kgai
claude plugin install kgai@kgai-marketplace

گام بعدی شما

• اگر از Claude Code استفاده می‌کنید، پلاگین kgai را برای ثبت تصمیمات معماری نصب کنید.
• برای همگام‌سازی تیمی، یک S3 Bucket اختصاصی تعریف کنید تا تاریخچه تصمیمات در تمام ماشین‌های تیم یکسان باشد.
• در پایان جلسات کدنویسی، بخش «تصمیمات اتخاذ شده» را در گراف چک کنید تا هیچ بن‌بست فنی بدون دلیل باقی نماند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.