// tier: helix-primary · order 6

HelixMemory betalicense: TBD

GoMem0CogneeLettaGraphitiPostgreSQLNeo4jRedisPrometheus

Source

HelixMemory — four engines, fused AI Application MemoryStore interface Mem0 fact extraction Cognee semantic graph (ECL) Letta stateful runtime Graphiti bi-temporal graph Fusion Router classify + route Collect Deduplicate Cross-source Re-rank Unified Result one ranked memory Circuit breakers closed→open→half-open
// architecture

دماغ ذاكرة واحد لوكلاء 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 الإصدار 1.25+). يقوم رهانه التأسيسي على أن أي مشروع ذاكرة واحد لن يكون الأفضل في كل شيء — لذا بدلاً من إعادة تنفيذ الذاكرة من الصفر وتوريث نقاط الضعف لمشروع واحد، يقوم بتنسيق أربعة أنظمة رائدة ويتيح لكل منها اللعب على نقاط قوته: Mem0 لاستخراج الحقائق الديناميكية وإدارة التفضيلات، Cognee لبناء مخططات المعرفة الدلالية عبر مسارات ECL، Letta لتشغيل وكلاء ذو حالة مع كتل ذاكرة قابلة للتعديل وحوسبة أثناء النوم، وGraphiti لمخطط معرفة ثنائي الزمن يمكنه التفكير في كيفية تغير الحقائق عبر الزمن.

إن محرك الدمج هو ما يحول تلك المخازن الأربعة المستقلة إلى عقل واحد. في مسار الكتابة، يتم تصنيف كل ذاكرة واردة حسب المحتوى وتوجيهها إلى الخلفية الأنسب لحفظها. في مسار القراءة، يتم نشر الاستعلام عبر جميع الخلفيات بشكل متوازٍ، وتتدفق النتائج الأولية إلى خط أنابيب دمج ثلاثي المراحل — الجمع، إزالة التكرار، ثم إعادة الترتيب عبر المصادر — بحيث لا يرى المتصل أربعة مجموعات نتائج مشوشة ومتداخلة، بل إجابة واحدة نظيفة ومرتبة. تُغلّف قواطع الدوائر كل خلفية لتدهور الأداء بشكل رشيق: عندما يتعطل محرك واحد، ينفتح قاطعه وتبقى الخلفيات المتبقية تعمل بدلاً من سحب طبقة الذاكرة بأكملها معها. ولأن المحرك ينفذ واجهة MemoryStore القابلة للإسقاط، فإنه يحل محل مزوّد ذاكرة بسيط مباشرة — دون الحاجة لإعادة هندسة المتصل — وتعرض مقاييس Prometheus تفاصيل التوجيه والدمج لتحقيق قابلية المراقبة الكاملة.

تم بناء HelixMemory كطبقة ذاكرة لـHelixAgent، المجموعة الأوسع من وكلاء AI Helix، ويحمل معه منهج العائلة في اختبار مكافحة الخداع إلى مجال الذاكرة: يقوم مشغل التحدي المدمج بتشغيل مسارات الكود الإنتاجية الحقيقية — التوجيه، الدمج، المترجم، قاطع الدائرة — بينما يقوم غلاف الطفرات المزدوج بقلب الثوابت عمداً لإثبات أن الاختبارات تفشل بالفعل عندما يكون المنطق معطوباً، بحيث تعني المجموعة الخضراء شيئاً حقيقياً.

المحتوى

يحتاج عملاء AI إلى ذاكرة طويلة الأمد وعالية الجودة، لكن النظام البيئي الحالي متشرذم — فكل مشروع ذاكرة (Mem0، Cognee، Letta، Graphiti) يتفوق في جانب ويخفق في جوانب أخرى. بُني HelixMemory لمنح HelixAgent سطح ذاكرة موحد يجمع نقاط القوة دون إجباره على الارتباط بأي منها بشكل حصري.

إنه ينهي الاختيار القسري. أربعة أنظمة ذاكرة كانت تتنافس عادةً على نفس الفتحة أصبحت الآن خلفيات تكميلية خلف واجهة واحدة — وبذلك تحصل التطبيقات على استخراج الحقائق الديناميكي، ورسومات المعرفة الدلالية، وذاكرة العملاء ذات الحالة، والاستدلال ثنائي الزمن *بالتزامن*، مع معالجة التكرارات وإعادة الترتيب عبر المصادر تلقائياً. ما لم يكن ممكناً من قبل هو اعتبار سؤال "أي محرك ذاكرة نتبنى؟" معضلة زائفة: يتيح HelixMemory الاستفادة من جميع نقاط القوة معاً خلف واجهة واحدة قابلة للتضمين MemoryStore، دون وراثة نقاط الضعف لأي محرك أو الالتزام بحصرية واحدة.

  • الدمج متعدد الخلفيات (جمع → إزالة التكرارات → إعادة ترتيب عبر المصادر) الذي يعيد مجموعة نتائج مرتبة واحدة، بدلاً من ربط المتصل بمخزن واحد.
  • التوجيه الذكي للكتابة الذي يصنف كل ذاكرة حسب المحتوى ويرسلها إلى المحرك الأنسب لحفظها، بحيث تصل البيانات الصحيحة إلى المخزن المناسب.
  • التدهور الرشيق عبر قواطع دوائر لكل خلفية — فشل المحرك يُعزل ولا يكون مميتاً، ويستمر الباقي في الخدمة.
  • الحوسبة الموحدة أثناء فترات السكون (عبر Letta) التي تعيد تنظيم الذاكرة خلال فترات الخمول بدلاً من الاعتماد على وقت الاستعلام فقط.
  • التحقق من عدم التلاعب: مشغل تحديات يعمل على كود الإنتاج الفعلي، مقترناً بمغلّف تحوير يجب أن يفشل عند قلب الثابت — مما يثبت أن بوابة الاختبار ليست مجرد تحصيل حاصل.

  • مواءمة أربعة خلفيات غير متجانسة في مجموعة نتائج متماسكة — كل محرك يعيد الذاكرة بشكل مختلف، ودمجها بشكل سطحي ينتج عنه تكرارات وترتيبات غير قابلة للمقارنة. تم حل المشكلة بمحرك دمج مُنَظَّم يجمع البيانات من المصادر المختلفة، يزيل التكرارات، ويعيد ترتيبها على أساس مشترك، مع تأكيد الثابت المدمج في الاختبارات لضمان عدم فقدان النتائج أو احتسابها مرتين بشكل صامت.
  • البقاء قيد التشغيل عند تعطل خلفية ما — يجب ألا يتوقف النظام بأكمله بسبب محرك ذاكرة يتعذر الوصول إليه. تم حل المشكلة بقواطع دوائر لكل خلفية تتبع آلية حالة مغلقة → مفتوحة (بعد تجاوز عتبة الفشل) → نصف مفتوحة (بعد انتهاء المهلة)، لعزل الخلفية المعطلة والاستمرار في الخدمة من الخلفيات السليمة حتى تعافيها.
  • إثبات فعالية منطق الذاكرة وليس مجرد تجميعها — مجموعة اختبارات خضراء لا معنى لها إذا لم تكن الاختبارات قادرة على الفشل. تم حل المشكلة بمشغل تحديات داخلي يشغل كود الإنتاج الفعلي (التوجيه، الدمج، المترجم، قاطع الدائرة) ومغلّف تحوير مزدوج يقلب الثوابت ويتطلب فشل الاختبارات، لضمان أن البوابة ليست تحصيلاً حاصلاً.

المحتوى

  • Go (الإصدار 1.25 فما فوق) — نواة 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-أساسية.