Home
Blog
لماذا يحرق وكلاء الذكاء الاصطناعي مثل OpenClaw الرموز وكيفية خفض التكاليف

لماذا يحرق وكلاء الذكاء الاصطناعي مثل OpenClaw الرموز وكيفية خفض التكاليف

Engineering

February 28, 2026

Min Yin

إذا كنت قد أمضيت أي وقت مع OpenClaw (المعروف سابقًا باسم Clawdbot وMoltbot)، فأنت تعرف بالفعل مدى جودة وكيل الذكاء الاصطناعي هذا. إنه سريع، ومحلي، ومرن، وقادر على تنفيذ تدفقات عمل معقدة بشكل مدهش عبر Slack، و Discord، وقاعدة التعليمات البرمجية الخاصة بك، وأي شيء آخر تربطه به. ولكن بمجرد أن تبدأ في استخدامه بجدية، يظهر نمط واحد بسرعة: يبدأ استخدامك للرمز المميز في الارتفاع.

هذا ليس خطأ OpenClaw على وجه التحديد - إنها الطريقة التي يتصرف بها معظم وكلاء الذكاء الاصطناعي اليوم. فهم يطلقون مكالمة LLM لكل شيء تقريبًا: البحث عن ملف، أو التخطيط لمهمة، أو كتابة ملاحظة، أو تنفيذ أداة، أو طرح سؤال متابعة. ولأن الرموز هي العملة العالمية لهذه المكالمات، فإن كل إجراء له تكلفة.

لفهم مصدر هذه التكلفة، نحتاج إلى النظر تحت الغطاء إلى مساهمين كبيرين:

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

كلتا المشكلتين تزيدان بصمت من التكاليف التشغيلية دون تحسين القدرة.

كيف يقوم وكلاء الذكاء الاصطناعي مثل OpenClaw بإجراء عمليات البحث فعلياً - ولماذا يحرق ذلك الرموز

عندما يحتاج الوكيل إلى معلومات من قاعدة التعليمات البرمجية أو مكتبة المستندات الخاصة بك، فإنه عادةً ما يقوم بما يعادل Ctrl + F على مستوى المشروع. يتم إرجاع كل سطر مطابق - غير مرتب وغير مصفى وغير مصنف. يطبّق كلود كود هذا من خلال أداة Grep مخصصة مبنية على ripgrep. لا يحتوي OpenClaw على أداة بحث مدمجة في قاعدة الشيفرات، لكن أداة التنفيذ الخاصة به تتيح للنموذج الأساسي تشغيل أي أمر، ويمكن للمهارات المحملة أن توجه الوكيل لاستخدام أدوات مثل rg. في كلتا الحالتين، يُرجع البحث في قاعدة الشيفرات الكلمات الرئيسية المطابقة للكلمات الرئيسية غير مرتبة وغير مصفاة.

يعمل نهج القوة الغاشمة هذا بشكل جيد في المشاريع الصغيرة. ولكن مع نمو المستودعات، يزداد الثمن. تتراكم المطابقات غير ذات الصلة في نافذة سياق LLM، مما يجبر النموذج على قراءة ومعالجة آلاف الرموز التي لا يحتاجها بالفعل. قد يؤدي بحث واحد غير محدد النطاق إلى سحب ملفات كاملة، أو كتل تعليقات ضخمة، أو سجلات تشترك في كلمة رئيسية ولكن ليس في القصد الأساسي. كرر هذا النمط عبر جلسة تصحيح أخطاء أو بحث طويلة، وسيتراكم هذا الكم الهائل بسرعة.

يحاول كل من OpenClaw و Claude Code إدارة هذا النمو. حيث يعمل OpenClaw على تنقيح مخرجات الأداة كبيرة الحجم وضغط تاريخ المحادثات الطويلة، بينما يحد Claude Code من إخراج الملفات المقروءة ويدعم ضغط السياق. تعمل عمليات التخفيف هذه - ولكن فقط بعد تنفيذ الاستعلام المتضخم بالفعل. لا تزال نتائج البحث غير المصنفة تستهلك الرموز، ولا تزال تدفع ثمنها. تساعد إدارة السياق في المنعطفات المستقبلية، وليس المكالمة الأصلية التي ولَّدت الهدر.

كيف تعمل ذاكرة عميل الذكاء الاصطناعي ولماذا تكلف الرموز أيضًا

البحث ليس المصدر الوحيد للنفقات الزائدة للرموز. يجب أيضًا تحميل كل جزء من السياق الذي يستدعيه الوكيل من الذاكرة في نافذة سياق LLM، وهذا يكلف الرموز أيضًا.

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

للتغلب على هذا الأمر، تقوم أطر عمل الوكيل بكتابة الملاحظات إلى ملفات على القرص وتحميل الملاحظات ذات الصلة مرة أخرى إلى نافذة السياق عندما يحتاجها الوكيل. على سبيل المثال، يقوم OpenClaw بتخزين الملاحظات المنسقة في MEMORY.md وإلحاق السجلات اليومية بملفات Markdown ذات الطابع الزمني، ثم فهرستها باستخدام BM25 الهجين والبحث المتجه حتى يتمكن الوكيل من استدعاء السياق ذي الصلة عند الطلب.

يعمل تصميم ذاكرة OpenClaw بشكل جيد، لكنه يتطلب نظام OpenClaw البيئي الكامل: عملية البوابة، واتصالات منصة المراسلة، وبقية المكدس. وينطبق الشيء نفسه على ذاكرة Claude Code، والتي ترتبط بـ CLI. إذا كنت تقوم ببناء وكيل مخصص خارج هذه المنصات، فأنت بحاجة إلى حل مستقل. يغطي القسم التالي الأدوات المتاحة لكلا المشكلتين.

كيفية إيقاف OpenClaw من حرق التوكنات

إذا كنت ترغب في تقليل عدد الرموز التي يستهلكها OpenClaw، فهناك رافعتان يمكنك استخدامهما.

الأولى هي استرجاع أفضل - استبدال تفريغ الكلمات المفتاحية بنمط grep بأدوات بحث مرتبة تعتمد على الصلة بالموضوع، بحيث لا يرى النموذج سوى المعلومات المهمة بالفعل.
والثاني هو تحسين الذاكرة - الانتقال من التخزين المبهم المعتمد على إطار العمل إلى شيء يمكنك فهمه وفحصه والتحكم فيه.

استبدال برنامج grep باسترجاع أفضل: Index1 و QMD و Milvus

يبحث العديد من وكلاء الترميز بالذكاء الاصطناعي في قواعد البرمجة باستخدام grep أو ripgrep. لدى Claude Code أداة Grep مخصصة مبنية على ripgrep. لا يحتوي OpenClaw على أداة بحث مدمجة في قاعدة الشيفرات، لكن أداة التنفيذ الخاصة به تتيح للنموذج الأساسي تشغيل أي أمر، ويمكن تحميل مهارات مثل ripgrep أو QMD لتوجيه كيفية بحث الوكيل. بدون مهارة تركز على الاسترجاع، يعود الوكيل إلى أي نهج يختاره النموذج الأساسي. المشكلة الأساسية هي نفسها في جميع الوكلاء: بدون استرجاع مرتب، تدخل مطابقات الكلمات المفتاحية إلى نافذة السياق دون تصفية.

يعمل هذا عندما يكون المشروع صغيرًا بما يكفي بحيث تتناسب كل مطابقة بشكل مريح مع نافذة السياق. تبدأ المشكلة عندما تنمو قاعدة التعليمات البرمجية أو مكتبة المستندات إلى الحد الذي تُظهر فيه الكلمة المفتاحية عشرات أو مئات النتائج ويتعين على الوكيل تحميلها جميعًا في المطالبة. في هذا النطاق، تحتاج إلى نتائج مرتبة حسب الصلة بالموضوع، وليس فقط تصفيتها حسب التطابق.

الحل القياسي هو البحث المختلط، الذي يجمع بين طريقتين متكاملتين للترتيب:

يقوم BM25 بتصنيف كل نتيجة حسب عدد مرات ظهور المصطلح في مستند معين ومدى تفرده. فالملف المركّز الذي يذكر كلمة "مصادقة" 15 مرة يحتل مرتبة أعلى من الملف المترامي الأطراف الذي يذكرها مرة واحدة.
يقوم البحث المتجه بتحويل النص إلى تمثيلات رقمية للمعنى، لذلك يمكن أن تتطابق كلمة "مصادقة" مع "تدفق تسجيل الدخول" أو "إدارة الجلسة" حتى عندما لا يشتركان في أي كلمات رئيسية.

لا تكفي أي من الطريقتين وحدهما: يفتقد BM25 المصطلحات المعاد صياغتها، ويفتقد البحث المتجه المصطلحات الدقيقة مثل رموز الخطأ. الجمع بين الاثنين ودمج القوائم المرتبة من خلال خوارزمية الدمج يغطي كلا الثغرتين.

تطبق الأدوات أدناه هذا النمط بمقاييس مختلفة. Grep هو خط الأساس الذي يبدأ به الجميع. يضيف كل من index1 وQMD وMilvus بحثًا هجينًا مع زيادة السعة.

index1: بحث هجين سريع على جهاز واحد

إنindex1 هو أداة CLI تقوم بحزم البحث الهجين في ملف قاعدة بيانات SQLite واحد. يتعامل FTS5 مع BM25، ويتعامل sqlite-vec مع تشابه المتجهات، ويدمج RRF القوائم المرتبة. يتم إنشاء التضمينات محليًا بواسطة Ollama، لذلك لا شيء يغادر جهازك.

يجزئ الفهرس1 الشيفرة حسب البنية، وليس حسب عدد الأسطر: يتم تقسيم ملفات ماركداون حسب العناوين، وملفات بايثون حسب AST، وجافا سكريبت وتايب سكريبت حسب أنماط الرجعيات. هذا يعني أن نتائج البحث ترجع وحدات متماسكة مثل دالة كاملة أو قسم توثيق كامل، وليس نطاقات أسطر عشوائية تقطع في منتصف الكتلة. يتراوح زمن الاستجابة من 40 إلى 180 مللي ثانية للاستعلامات المختلطة. بدون Ollama، يعود الأمر إلى BM25 فقط، والذي لا يزال يرتب النتائج بدلًا من تفريغ كل تطابق في نافذة السياق.

يتضمن index1 أيضًا وحدة ذاكرة عرضية لتخزين الدروس المستفادة والأسباب الجذرية للأخطاء والقرارات المعمارية. تعيش هذه الذكريات داخل نفس قاعدة بيانات SQLite مثل فهرس التعليمات البرمجية بدلاً من الملفات المستقلة.

ملاحظة: الفهرس 1 هو مشروع في مرحلة مبكرة (0 نجمة، 4 التزامات اعتبارًا من فبراير 2026). قم بتقييمه مقابل قاعدة التعليمات البرمجية الخاصة بك قبل الالتزام به.

الأفضل ل: المطورين المنفردين أو الفرق الصغيرة التي لديها قاعدة شفرات تتناسب مع جهاز واحد، وتبحث عن تحسين سريع مقارنةً ببرنامج grep.
قم بتطويره عندما: تحتاج إلى وصول متعدد المستخدمين إلى نفس الفهرس، أوعندما تتجاوز بياناتك ما يعالجه ملف SQLite واحد بشكل مريح.

QMD: دقة أعلى من خلال إعادة ترتيب LLM المحلية

تضيفQMD (مستندات ترميز الاستعلام)، التي أنشأها مؤسس Shopify توبي لوتكه، مرحلة ثالثة: إعادة ترتيب LLM. بعد أن يقوم كل من BM25 والبحث المتجه بإرجاع كل من المرشحين للنتائج، يقوم نموذج اللغة المحلي بإعادة قراءة أفضل النتائج وإعادة ترتيبها حسب الصلة الفعلية باستعلامك. هذا يلتقط الحالات التي تُرجع فيها كل من الكلمات المفتاحية والمطابقات الدلالية نتائج معقولة ولكن خاطئة.

يتم تشغيل QMD بالكامل على جهازك باستخدام ثلاثة نماذج GGUF يبلغ مجموعها حوالي 2 غيغابايت: نموذج التضمين (embeddinggemma-300M)، ونموذج إعادة ترتيب عبر برامج إعادة التشفير (Qwen3-Reranker-0.6B)، ونموذج توسيع الاستعلام (qmd-query-expansion-1.7B). يتم تنزيل الثلاثة تلقائيًا عند التشغيل الأول. لا توجد مكالمات واجهة برمجة التطبيقات السحابية، ولا مفاتيح واجهة برمجة التطبيقات.

المفاضلة هي وقت بدء التشغيل البارد: يستغرق تحميل النماذج الثلاثة من القرص ما يقرب من 15 إلى 16 ثانية. يدعم QMD وضع الخادم الدائم (qmd mcp) الذي يحتفظ بالنماذج في الذاكرة بين الطلبات، مما يلغي عقوبة البدء البارد للاستعلامات المتكررة.

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

ميلفوس: بحث هجين على مستوى الفريق والمؤسسة

تعمل أدوات الآلة الواحدة المذكورة أعلاه بشكل جيد للمطورين الأفراد، ولكنها تصل إلى حدود عندما يحتاج عدة أشخاص أو وكلاء إلى الوصول إلى نفس القاعدة المعرفية.

Milvus هي قاعدة بيانات متجهات مفتوحة المصدر مصممة لهذه المرحلة التالية: موزعة ومتعددة المستخدمين وقادرة على التعامل مع مليارات المتجهات.

الميزة الرئيسية لحالة الاستخدام هذه هي Sparse-BM25 المدمجة في قاعدة البيانات المتشعبة، وهي متوفرة منذ الإصدار 2.5 من Milvus وأسرع بكثير في الإصدار 2.6. أنت تقدم نصًا خامًا، ويقوم ميلفوس بترميزه داخليًا باستخدام محلل مبني على تانتيفي، ثم يحول النتيجة إلى متجهات متفرقة يتم حسابها مسبقًا وتخزينها في وقت الفهرس.

نظرًا لأن تمثيل BM25 مخزّن بالفعل، لا يحتاج الاسترجاع إلى إعادة حساب الدرجات أثناء التنقل. تعيش هذه المتجهات المتفرقة جنبًا إلى جنب مع المتجهات الكثيفة (التضمينات الدلالية) في نفس المجموعة. في وقت الاستعلام، تقوم بدمج كلتا الإشارتين مع مصنف مثل RRFRanker، والذي يوفره Milvus خارج الصندوق. نفس نمط البحث الهجين مثل Index1 وQMD، ولكن تعمل على بنية تحتية تتوسع أفقياً.

يوفر Milvus أيضًا إمكانات لا تستطيع أدوات الآلة الواحدة توفيرها: العزل متعدد المستأجرين (قواعد بيانات أو مجموعات منفصلة لكل فريق)، وتكرار البيانات مع تجاوز الفشل التلقائي، وطبقات البيانات الساخنة/الباردة للتخزين الفعال من حيث التكلفة. بالنسبة للوكلاء، هذا يعني أن العديد من المطورين أو مثيلات الوكلاء المتعددة يمكنهم الاستعلام عن نفس القاعدة المعرفية في نفس الوقت دون التعدي على بيانات بعضهم البعض.

الأفضل من أجل: العديد من المطورين أو الوكلاء الذين يتشاركون قاعدة معرفية، أو مجموعات مستندات كبيرة أو سريعة النمو، أو بيئات الإنتاج التي تحتاج إلى النسخ المتماثل، وتجاوز الفشل، والتحكم في الوصول.

خلاصة القول

الأداة	المرحلة	النشر	إشارة الترحيل
كلود جريب الأصلي	النماذج الأولية	مدمج، بدون إعداد	ارتفاع الفواتير أو تباطؤ الاستعلامات
فهرس1	جهاز واحد (سرعة)	SQLite محلي + أولاما	تحتاج إلى وصول متعدد المستخدمين أو أن البيانات تتجاوز جهازًا واحدًا
QMD	جهاز واحد (دقة)	ثلاثة نماذج GGUF محلية	تحتاج إلى فهارس مشتركة للفريق
ميلفوس	فريق أو إنتاج	مجموعة موزعة	مجموعات مستندات كبيرة أو متطلبات متعددة المستأجرين

تقليل تكاليف الرمز المميز لوكيل الذكاء الاصطناعي من خلال منحهم ذاكرة ثابتة وقابلة للتحرير باستخدام memsearch

يقلل تحسين البحث من إهدار الرمز المميز لكل استعلام، ولكنه لا يساعد فيما يحتفظ به الوكيل بين الجلسات.

كل جزء من السياق الذي يستدعيه الوكيل من الذاكرة يجب تحميله في الموجهة، وهذا يكلف الرموز أيضًا. السؤال ليس ما إذا كان يجب تخزين الذاكرة أم لا، بل كيف. تحدد طريقة التخزين ما إذا كان بإمكانك رؤية ما يتذكره الوكيل، وإصلاحه عندما يكون خاطئًا، وأخذه معك إذا قمت بتبديل الأدوات.

تفشل معظم الأطر في جميع هذه الأمور الثلاثة. تخزّن Mem0 وZep كل شيء في قاعدة بيانات متجهة، والتي تعمل على الاسترجاع، ولكنها تجعل الذاكرة

مبهمة. لا يمكنك رؤية ما يتذكره الوكيل دون الاستعلام عن واجهة برمجة التطبيقات.
صعب التعديل. تصحيح الذاكرة أو إزالتها يعني استدعاء واجهة برمجة التطبيقات، وليس فتح ملف.
مقفل. تبديل الأطر يعني تصدير بياناتك وتحويلها وإعادة استيرادها.

يتخذ OpenClaw نهجًا مختلفًا. كل الذاكرة تعيش في ملفات Markdown عادية على القرص. يكتب الوكيل السجلات اليومية تلقائيًا، ويمكن للبشر فتح أي ملف ذاكرة وتحريره مباشرةً. هذا يحل جميع المشاكل الثلاث: الذاكرة قابلة للقراءة والتحرير والنقل حسب التصميم.

أما المفاضلة فتتمثل في نفقات النشر. إن تشغيل ذاكرة OpenClaw يعني تشغيل نظام OpenClaw البيئي الكامل: عملية البوابة، واتصالات منصة المراسلة، وبقية المكدس. بالنسبة للفرق التي تستخدم OpenClaw بالفعل، لا بأس بذلك. بالنسبة لأي شخص آخر، فإن الحاجز مرتفع للغاية. تم تصميم memsearch لسد هذه الفجوة: فهو يستخرج نمط ذاكرة OpenClaw من Markdown-first في مكتبة مستقلة تعمل مع أي وكيل.

يعاملmemsearch، الذي أنشأه Zilliz (الفريق الذي يقف وراء Milvus)، ملفات Markdown كمصدر وحيد للحقيقة. يحتفظ MEMORY.md بالحقائق والقرارات طويلة المدى التي تكتبها يدويًا. يتم إنشاء السجلات اليومية (2026-02-26.md) تلقائيًا من ملخصات الجلسات. الفهرس المتجه، المخزن في ميلفوس، هو طبقة مشتقة يمكن إعادة بنائها من Markdown في أي وقت.

من الناحية العملية، هذا يعني أنه يمكنك فتح أي ملف ذاكرة في محرر نصي وقراءة ما يعرفه الوكيل بالضبط وتغييره. احفظ الملف، وسيكتشف مراقب ملفات memsearch التغيير ويعيد الفهرسة تلقائيًا. يمكنك إدارة الذكريات باستخدام Git، ومراجعة الذكريات التي أنشأها الذكاء الاصطناعي من خلال طلبات السحب، أو الانتقال إلى جهاز جديد عن طريق نسخ مجلد. في حالة فقدان فهرس Milvus، يمكنك إعادة بنائه من الملفات. الملفات ليست في خطر أبدًا.

تحت الغطاء، يستخدم memsearch نفس نمط البحث الهجين الموصوف أعلاه: تقسيم الأجزاء حسب بنية العنوان وحدود الفقرات، واسترجاع BM25 + المتجه، وأمر مضغوط يعمل على LLM يلخص الذكريات القديمة عندما تكبر السجلات.

الأفضل لـ: الفرق التي تريد رؤية كاملة لما يتذكره الوكيل، أو تحتاج إلى التحكم في الإصدار على الذاكرة، أو تريد نظام ذاكرة غير مقيد بأي إطار عمل وكيل واحد.

باختصار

القدرة	ميم0 / زب	ميمسارش
مصدر الحقيقة	قاعدة بيانات المتجهات (مصدر البيانات الوحيد)	ملفات تخفيض السعر (أساسي) + ميلفوس (فهرس)
الشفافية	صندوق أسود، يتطلب واجهة برمجة التطبيقات للفحص	فتح أي ملف .md لقراءته
قابلية التعديل	التعديل عبر مكالمات واجهة برمجة التطبيقات	التعديل مباشرةً في أي محرر نصي، إعادة الفهرسة التلقائية
التحكم في الإصدار	يتطلب تسجيل تدقيق منفصل للتدقيق	يعمل Git بشكل أصلي
تكلفة الترحيل	التصدير → تحويل التنسيق → إعادة الاستيراد	نسخ مجلد تخفيض السعر
التعاون بين الإنسان والذكاء الاصطناعي	الذكاء الاصطناعي يكتب، والبشر يراقبون	يمكن للبشر التحرير والاستكمال والمراجعة

أي إعداد يناسب مقياسك

السيناريو	البحث	الذاكرة	متى تنتقل
نموذج أولي مبكر	جريب (مدمج)	-	ارتفاع الفواتير أو تباطؤ الاستعلامات
مطور واحد، البحث فقط	الفهرس1 (السرعة) أو QMD (الدقة)	-	الحاجة إلى وصول متعدد المستخدمين أو أن البيانات تتجاوز جهاز واحد
مطور واحد، كلاهما	فهرس1	ميمسارش	تحتاج إلى وصول متعدد المستخدمين أو أن البيانات تتجاوز جهازًا واحدًا
فريق أو إنتاج، كلاهما	ميلفوس	ميمسارش	-
تكامل سريع، ذاكرة فقط	-	ميم0 أو زب	الحاجة إلى فحص الذكريات أو تحريرها أو ترحيلها

الخلاصة

إن التكاليف الرمزية التي تأتي مع وكلاء الذكاء الاصطناعي دائمي التشغيل ليست حتمية. غطى هذا الدليل مجالين حيث يمكن للأدوات الأفضل أن تقلل من الهدر: البحث والذاكرة.

يعمل Grep على نطاق صغير، ولكن مع نمو قواعد الرموز، فإن مطابقات الكلمات المفتاحية غير المصنفة تغمر نافذة السياق بمحتوى لا يحتاجه النموذج أبدًا. فهرس1 و QMD يحل هذا الأمر على جهاز واحد من خلال الجمع بين تسجيل الكلمات المفتاحية BM25 مع البحث المتجه وإرجاع النتائج الأكثر صلة فقط. بالنسبة للفرق أو الإعدادات متعددة الوكلاء أو أعباء عمل الإنتاج، يوفر Milvus نفس نمط البحث الهجين على البنية التحتية التي تتوسع أفقياً.

بالنسبة للذاكرة، تقوم معظم الأطر بتخزين كل شيء في قاعدة بيانات متجهة: مبهمة ويصعب تحريرها يدويًا ومغلقة على الإطار الذي أنشأها. تعيش الذاكرة في ملفات Markdown عادية يمكنك قراءتها وتحريرها والتحكم في الإصدار باستخدام Git. يعمل ميلفوس كفهرس مشتق يمكن إعادة بنائه من تلك الملفات في أي وقت. تظل متحكمًا فيما يعرفه الوكيل.

كل من memsearch و Milvus مفتوح المصدر. نحن نعمل بنشاط على تطوير memsearch ونود الحصول على تعليقات من أي شخص يقوم بتشغيله في الإنتاج. افتح مشكلة، أو أرسل لنا تقرير علاقات عامة، أو أخبرنا فقط ما الذي يعمل وما الذي لا يعمل.

المشاريع المذكورة في هذا الدليل: