// سطح: helix-primary · سفارش 6
HelixMemory betaاجازهنامه: TBD
منبع
یک حافظهٔ مغزی برای عوامل AI — چهار موتور پیشرو، درهمآمیخته.
HelixMemory یک Go SDK است که چهار سیستم حافظهٔ پیشرو (Mem0، Cognee، Letta، Graphiti) را در یک موتور حافظهٔ شناختی واحد ادغام میکند که بهطور همزمان در آنها جستجو کرده و نتایج را تلفیق مینماید. این سامانه به برنامههای AI یک لایهٔ حافظهٔ پایدار، بدون تکرار و بازمرتبشده ارائه میدهد، بهجای چهار لایهٔ ناهماهنگ.
HelixMemory یک Go SDK است که Mem0، Cognee، Letta و Graphiti را در یک موتور حافظهٔ شناختی واحد برای برنامههای AI ادغام میکند. این سامانه دادهها را بهطور هوشمندانه مسیریابی میکند، در تمام پایگاههای پشتیبان بهطور موازی جستجو مینماید و نتایج را از طریق یک خط لولهٔ سهمرحلهای جمعآوری، حذف تکرار و بازمرتبسازی تلفیق میکند.
HelixMemory یک موتور حافظهٔ شناختی واحد برای برنامههای AI است که بهصورت یک Go SDK (ماژول digital.vasic.helixmemory، نسخهٔ Go ۱٫۲۵ به بالا) ارائه میشود. فرض بنیادین آن این است که هیچ پروژهٔ حافظهٔ واحدی هرگز در همهٔ زمینهها بهترین نخواهد بود — بنابراین بهجای پیادهسازی مجدد حافظه از صفر و به ارث بردن نقاط کور یک پروژه، چهار سیستم پیشرو را هماهنگ کرده و به هر یک اجازه میدهد در زمینهٔ تخصصی خود بدرخشد: Mem0 برای استخراج پویای حقایق و مدیریت ترجیحات، Cognee برای گرافهای دانش معنایی ساختهشده از طریق خطوط لولهٔ ECL، Letta برای محیط اجرایی عامل دارای حالت با بلوکهای حافظهٔ قابل ویرایش و محاسبات زمان خواب، و Graphiti برای گراف دانش دوبعدی زمانی که دربارهٔ چگونگی تغییر حقایق در گذر زمان استدلال میکند.
موتور تلفیق است که این چهار مخزن مستقل را به یک مغز واحد تبدیل میکند. در مسیر نوشتن، هر حافظهٔ ورودی بر اساس محتوا طبقهبندی شده و به پایگاه پشتیبان مناسبترین برای نگهداری آن هدایت میشود. در مسیر خواندن، یک پرسوجو بهطور همزمان در تمام پایگاههای پشتیبان پخش شده و نتایج خام وارد یک خط لولهٔ تلفیق سهمرحلهای میشوند — جمعآوری، حذف تکرار، سپس بازمرتبسازی بین منابع — بهگونهای که فراخواننده هرگز با چهار مجموعه نتیجه پراکنده و همپوشان مواجه نمیشود، بلکه تنها یک پاسخ مرتبشده و تمیز دریافت میکند. قطعکنندههای مدار هر پایگاه پشتیبان را احاطه کردهاند تا در صورت بروز مشکل، بهطور منظم از کار افتاده و سایر پایگاهها به ارائه خدمات ادامه دهند، بدون آنکه کل لایهٔ حافظه را با خود به پایین بکشند. از آنجا که این موتور یک رابط MemoryStore قابل جایگزینی را پیادهسازی میکند، بهعنوان جایگزین مستقیم یک ارائهدهندهٔ حافظهٔ ساده عمل کرده و نیازی به بازطراحی فراخواننده نیست — و معیارهای Prometheus جزئیات مسیریابی و تلفیق را برای مشاهدهپذیری کامل آشکار میسازند.
HelixMemory بهعنوان لایهٔ حافظه برای HelixAgent، مجموعهٔ گستردهتر Helix از برنامههای AI، ساخته شده و نظم آزمون ضدفریب این خانواده را به حوزهٔ حافظه گسترش میدهد: یک اجراگر چالش درونفرایندی مسیرهای کد واقعی تولید را — مسیریابی، تلفیق، مترجم، قطعکنندهٔ مدار — به کار میگیرد، در حالی که یک بستهبندی جهش جفتشده بهطور عمدی ثابتها را تغییر میدهد تا ثابت کند آزمونها واقعاً در صورت نقص منطق شکست میخورند، بنابراین یک مجموعه سبز معنای واقعی دارد.
محتوا
عاملهای AI به حافظهای بادوام و باکیفیت نیاز دارند، اما اکوسیستم حافظهها تکهتکه است — هر پروژه حافظه (Mem0، Cognee، Letta، Graphiti) در یک زمینه قوی و در زمینههای دیگر ضعیف عمل میکند. HelixMemory برای این ساخته شد که به HelixAgent یک سطح حافظه واحد بدهد که نقاط قوت همهٔ آنها را بدون اجبار به وابستگی به هیچکدام ترکیب کند.
این راهکار انتخاب اجباری را پایان میدهد. چهار سیستم حافظه که معمولاً برای تصاحب یک جایگاه با هم رقابت میکنند، پشت یک رابط واحد به مکملهایی برای یکدیگر تبدیل میشوند — به این ترتیب، یک برنامه میتواند همزمان از استخراج پویای حقایق، گرافهای دانش معنایی، حافظهٔ عاملهای دارای حالت و استدلال دو-زمانی بهرهمند شود، در حالی که حذف تکراریها و رتبهبندی مجدد منابع بهطور خودکار انجام میشود. آنچه پیش از این عملی نبود، این است که پرسش «کدام موتور حافظه را باید انتخاب کنیم؟» را یک دوراهی کاذب بدانیم: HelixMemory به شما امکان میدهد همزمان از همهٔ نقاط قوت آنها بهرهمند شوید، پشت یک MemoryStore یکپارچه و بدون به ارث بردن نقاط کور هیچ موتور یا تعهد به وابستگی به آن.
- ادغام چندپشتیبان (جمعآوری → حذف تکراریها → رتبهبندی مجدد منابع) که به جای محدود کردن فراخواننده به یک حافظهٔ واحد، یک مجموعه نتیجه رتبهبندیشده ارائه میدهد.
- مسیردهی هوشمند نوشتن که هر حافظه را بر اساس محتوا طبقهبندی کرده و به موتوری میفرستد که بهترین گزینه برای نگهداری آن است، تا دادههای مناسب در حافظهٔ مناسب قرار گیرند.
- تخریب تدریجی از طریق قطعکنندههای مدار برای هر پشتیبان — خرابی یک موتور جداسازی میشود و کشنده نیست، و بقیه به خدمترسانی ادامه میدهند.
- تلفیق محاسبات در زمان استراحت (از طریق Letta) که حافظه را در دورههای بیکاری بازسازی میکند، نه فقط در زمان پرسوجو.
- تأیید ضد-فریب: یک اجراگر چالش روی کد واقعی تولیدی، همراه با یک بستهکننده جهش که باید در صورت نقض یک ثابت شکست بخورد — اثبات اینکه دروازهٔ تست یک بررسی واقعی است، نه یک توتولوژی.
- تلفیق چهار پشتیبان ناهمگن در یک مجموعه نتیجه منسجم — هر موتور حافظه را به شکل خاص خود بازمیگرداند، و ادغام سادهٔ آنها منجر به تکراریها و رتبهبندیهای ناسازگار میشود. این مشکل با یک موتور تلفیق تایپشده حل شد که دادهها را از منابع مختلف جمعآوری میکند، همپوشانیها را حذف میکند و همه را بر اساس یک معیار مشترک رتبهبندی میکند، با ثابت تلفیقشده که در تستها تأیید میشود تا ادغام نتواند بهطور پنهانی نتایج را از دست بدهد یا دو بار شمارش کند.
- پایداری در برابر خرابی یک پشتیبان — عدم دسترسی به یک موتور حافظه نباید کل لایه را متوقف کند. این مشکل با قطعکنندههای مدار برای هر پشتیبان حل شد که بر اساس یک ماشین حالت بسته → باز (پس از آستانهٔ خرابی) → نیمهباز (پس از زمان انتظار) عمل میکنند، موتور معیوب را جداسازی کرده و تا زمان بازیابی آن، از پشتیبانهای سالم به خدمترسانی ادامه میدهند.
- اثبات کارکرد واقعی منطق حافظه، نه فقط کامپایل شدن آن — یک مجموعه تست سبز بیمعنی است اگر تستها نتوانند شکست بخورند. این مشکل با یک اجراگر چالش درونفرآیندی حل شد که کد واقعی تولیدی (مسیردهی، تلفیق، مترجم، قطعکننده مدار) را اجرا میکند و همراه با یک بستهکننده جهش که ثابتها را تغییر میدهد و انتظار شکست تستها را دارد، تا ثابت شود دروازه یک بررسی واقعی است، نه یک توتولوژی.
محتوا
- Go (نسخهٔ ۱٫۲۵ به بالا) — هستهٔ اصلی SDK و زماناجرا؛ انتخاب شده زیرا توزیع خوانش موازی در چهار بکاند یک مسئلهٔ همروندی است و گوروتینهای Go آن را کمهزینه میکنند، در حالی که انواع اینترفیس آن یک درز تمیز (
MemoryStore) برای کل سیستم فراهم میآورد که فراخوانندگان میتوانند به آن تکیه کنند. - Mem0 — بکاند استخراج پویای حقایق و مدیریت ترجیحات؛ برای بخش «کاربر واقعاً چه چیزی را ترجیح میدهد / چه حقایقی آشکار شدهاند» از حافظه استفاده میشود.
- Cognee — بکاند گراف دانش معنایی که بر پایهٔ پایپلاینهای ECL ساخته شده؛ برای نگهداری دانش ساختاریافته و مرتبط به جای حقایق مسطح استفاده میشود.
- Letta — بکاند زماناجرای عاملهای دارای حالت با بلوکهای حافظهٔ قابل ویرایش و محاسبات زمان خواب؛ در مواردی استفاده میشود که حافظه باید بهعنوان حالت زنده عامل باقی بماند و در دورههای بیکاری تثبیت شود.
- Graphiti — بکاند گراف دانش دو-زمانی؛ برای استدلال دربارهٔ چگونگی تغییر حقایق و روابط در طول زمان، نه فقط مقدار فعلی آنها، استفاده میشود.
- PostgreSQL + Neo4j + Redis — انبارههای دادهٔ واقعی که بکاندها بر روی آنها اجرا میشوند و برای تست یکپارچگی واقعی با دستور
make infra-startبرپا شدهاند تا مجموعه تستها زیرساخت زنده را به جای ماکتها آزمایش کند. - Prometheus — معیارها و قابلیت مشاهدهپذیری که از طریق پایپلاین تلفیق متصل شدهاند تا مسیریابی و رفتار تلفیق در محیط عملیاتی قابل اندازهگیری باشد، نه یک جعبهٔ سیاه.
- درز مترجم بینالمللی — سطح رشتههای نامگذاریشده (
helixmemory_) که در جای خود نگه داشته شده تا هر لایهٔ کاربرمحور آینده بتواند بدون تغییرات پسینی در هسته بومیسازی شود.
- وضعیت: بتا. SDK در حال کار است؛ بهعنوان لایهٔ حافظه برای HelixAgent ساخته شده است.
- مجوز: نامشخص. هیچ مجوزی از طریق GitHub API شناسایی نشد — تأیید نشده / اعلام نشده است.
- نام نمایشی «HelixMemory» به مخزن
memoryنگاشت میشود. ارقام دقت ذکرشده در فایل README ادعاهای فروشندگان بالادستی هستند، نه اندازهگیریهای HelixMemory، و در اینجا حذف شدهاند.
اولویت: Helix-اصلی.