Yusuf Khalidd

Posted on Sep 1 Originally published at apidog.com

كيف توفر 99% من تكلفة توكنات وكيل الذكاء الاصطناعي

codebase-memory-mcp: ذاكرة محلية لقاعدة الكود تقلّل استهلاك وكلائك للرموز بنسبة 99.2%

يقوم codebase-memory-mcp بفهرسة مستودعك في رسم بياني معرفي دائم، بحيث يجيب وكيل البرمجة عن الأسئلة الهيكلية من الرسم البياني بدل البحث والقراءة ملفًا بعد ملف. في قياس المشروع، استهلكت خمس استعلامات هيكلية نحو 3,400 رمز مميز عبر الرسم البياني، مقابل نحو 412,000 رمز مميز بالاستكشاف التقليدي؛ أي تخفيض بنسبة 99.2%. الأداة مكتوبة بلغة C، وتأتي كثنائي أصلي واحد بلا وقت تشغيل أو مفتاح API، وتدعم أكثر من 160 لغة وتعمل بالكامل محليًا. بلغ المشروع 41,536 نجمة في 1 سبتمبر 2026، ومرخّص بترخيص MIT.

جرّب Apidog اليوم

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

المشكلة: الوكيل يقرأ أكثر مما ينبغي

عندما تسأل وكيلك: «أين تُستدعى هذه الدالة؟»، يبدأ غالبًا بالبحث، ثم يقرأ عدة ملفات، ويعيد البحث بنمط مختلف، ويقرأ ملفات أخرى. قد يصل إلى إجابة صحيحة، لكن بعد استهلاك عشرات الآلاف من الرموز المميزة لملء نافذة السياق بكود سينساه عند انتهاء الجلسة.

وعند طرح سؤال متابعة، تبدأ الدورة من جديد.

هذا يستهلك حد الاستخدام ويقلّل جودة الاستدلال؛ فكلما امتلأت نافذة السياق بمحتويات الملفات، تقل المساحة المتاحة للتفكير. يحاول codebase-memory-mcp حل المشكلتين بفهرسة المستودع مرة واحدة.

ماذا يفعل codebase-memory-mcp؟

يحلّل المستودع إلى رسم بياني معرفي دائم يضم:

الدوال والفئات.
سلاسل الاستدعاء.
مسارات HTTP.
الروابط بين الخدمات.
التأثيرات المحتملة لتغييرات الكود.
الكود غير المستخدم.
قرارات التصميم المسجلة في ADR.

يستخدم المشروع تحليل AST عبر tree-sitter لأكثر من 160 لغة، مع طبقة LSP هجينة تضيف التحليل الدلالي للأنواع لمجموعة أساسية يصفها README بأنها عشرة، منها:

Python.
TypeScript وJavaScript، بما في ذلك JSX وTSX.
PHP.
C#.
Go.
C وC++.
Java.
Kotlin.
Rust.
Perl.

الفرق مهم: يخبرك تحليل AST بوجود دالة اسمها save، بينما يخبرك تحليل النوع بالفئة التي تنتمي إليها.

يقدم المشروع 15 أداة MCP للبحث، وتتبع سلسلة الاستدعاءات، وتحليل البنية والتأثير، وفحص تغطية الفهرس، واستعلامات Cypher، واكتشاف الكود الميت، والربط بين خدمات HTTP، وإدارة ADR.

وبما أنه خادم بروتوكول سياق النموذج، يمكن لأي عميل MCP استخدامه. يسرد المشروع 45 سطح وكيل مدعومًا، منها Claude Code وCodex وCursor وWindsurf وOpenCode وGemini CLI وAider وKilocode.

الأرقام التي تهمك

قياس المشروع

استهلكت خمس استعلامات هيكلية نحو 3,400 رمز مميز عبر الرسم البياني، مقارنة بنحو 412,000 رمز مميز عند استخدام grep والاستكشاف ملفًا بعد ملف.

هذه نتيجة أفضل بنحو 120 مرة، أو تخفيض بنسبة 99.2%.

التقييم الأكاديمي

تقدم المسودة البحثية Codebase-Memory: رسوم بيانية معرفية قائمة على Tree-Sitter لاستكشاف كود LLM عبر MCP تقييمًا عبر 31 مستودعًا واقعيًا، وتذكر:

جودة إجابة تبلغ 83%.
استهلاك رموز أقل بعشر مرات.
استدعاءات أدوات أقل بمقدار 2.1 مرة مقارنة بالاستكشاف ملفًا بعد ملف.

الفجوة بين 120 مرة و10 مرات مهمة:

120 مرة تخص خمس استعلامات هيكلية، وهي أفضل حالة للرسم البياني.
10 مرات متوسط أوسع عبر 31 مستودعًا، وهو أقرب إلى الاستخدام اليومي.

استخدم 10 مرات كرقم تخطيطي، واعتبر أي تحسن إضافي مكسبًا.

السرعة

فهرسة نواة Linux، التي تضم 28 مليون سطر في 75,000 ملف، تستغرق ثلاث دقائق.
فهرسة مستودعات التطبيقات المتوسطة تستغرق أجزاء من الثانية.
تعود الاستعلامات الهيكلية في أقل من جزء من الثانية.

يعتمد خط الأنابيب على الذاكرة أولًا مع ضغط LZ4، وSQLite داخل الذاكرة، ومطابقة أنماط Aho-Corasick المدمجة، ثم يحرر الذاكرة بعد الفهرسة.

تفسر كتابة الأداة بلغة C هذه الأرقام، كما تفسر عدم حاجتها إلى وقت تشغيل إضافي.

التثبيت

macOS وLinux

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

Windows

يوصي المشروع بقراءة نص التثبيت قبل تشغيله:

Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1
notepad install.ps1        # read it first
Unblock-File .\install.ps1
.\install.ps1

يدعم المثبت الخيارات التالية:

--skip-config: تثبيت الثنائي فقط دون إعداد الوكيل.
--dir=<path>: اختيار موقع تثبيت مخصص.

يكتشف المثبت وكلاء البرمجة المثبتين تلقائيًا، ثم يضيف إعدادات MCP الموثقة، والتعليمات، والمهارات، وخطافات دورة الحياة عندما يدعمها العميل.

على macOS، يزيل المثبت سمات الحجر الصحي ويوقّع الثنائي مؤقتًا، لذلك لا تحتاج عادةً إلى تنفيذ xattr أو codesign يدويًا.

بعد التثبيت، أعد تشغيل وكيلك واطلب منه فهرسة المشروع.

إعدادات مفيدة من اليوم الأول

لفهرسة المشاريع الجديدة تلقائيًا عند أول اتصال:

# index new projects automatically on first connection
codebase-memory-mcp config set auto_index true
codebase-memory-mcp config set auto_index_limit 50000

لتشغيل واجهة الرسم البياني:

# graph visualization, built into the binary
codebase-memory-mcp --ui=true --port=9749

افتح http://localhost:9749 لرؤية الرسم البياني المعرفي ثلاثي الأبعاد. الواجهة مفيدة لاكتشاف البنى غير المعروفة، كما تساعدك على التأكد من أن الفهرس غطى ما تتوقعه.

إذا كنت تعمل على مستودعات متعددة:

codebase-memory-mcp config set auto_watch false
codebase-memory-mcp config set watcher_enabled false

يمنع auto_watch false الجلسة من تسجيل مشروعها في المراقبة الخلفية، بينما يوقف watcher_enabled false خيط الاستطلاع بالكامل. تتم قراءة الخيار الثاني عند بدء الخلفية، لذلك أعد تشغيل الخلفية بعد تغييره.

تحقق من هذين الأمرين قبل التشغيل

كلا الأمرين موثق من المشروع، وهذا جيد، لكن يستحق كل منهما بضع دقائق من المراجعة.

تحذير Microsoft Defender

قد يصنف Microsoft Defender بعض إصدارات الثنائي على أنها:

Trojan:Script/Wacatac.B!ml

يوثق المشروع ذلك باعتباره إيجابيًا كاذبًا معروفًا، ويذكر أن 61 محركًا من نحو 62 محركًا تعطي عادةً نتائج نظيفة. كما يشير إلى أن عائلة الكشف نفسها أصابت واجهة سطر أوامر GitHub وllama.cpp وGodot وسلسلة أدوات Go الخاصة بـ Microsoft.

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

الصلاحيات والاتصال

يقرأ البرنامج كودك ويكتب في ملفات إعدادات وكيلك. هذه هي وظيفته، والمشروع يوضح ذلك صراحة.

تشمل عوامل التخفيف:

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

الإجراء العملي المناسب:

اقرأ نص التثبيت قبل تمريره إلى bash.
راجع المصدر إذا كانت المعالجة المحلية مهمة بالنسبة لك.
لا تعتبر عدد النجوم تدقيقًا أمنيًا.

الأدوات التي ستستخدمها فعليًا

لن تحتاج إلى حفظ أسماء الأدوات الخمس عشرة؛ الوكيل يختارها. المهم هو معرفة الأسئلة التي أصبحت رخيصة:

تحليل التأثير

قبل تغيير توقيع دالة، اسأل:

ما الذي قد يتعطل إذا غيّرت هذا التوقيع؟

يتتبع الرسم البياني المستدعين عبر المستودع بسرعة كبيرة، بينما قد يفوّت البحث النصي الإرسال الديناميكي والعلاقات غير المباشرة.

تتبع سلسلة الاستدعاءات

يساعدك على معرفة كيف يصل التنفيذ فعليًا إلى جزء من الكود، خصوصًا في مستودع غير مألوف، بدل القراءة صعودًا عبر عدة ملفات.

نظرة عامة على البنية

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

اكتشاف الكود الميت

استخدمه قبل تنظيف مستعجل لمعرفة ما لا يستدعيه أي جزء آخر من المستودع.

الربط بين خدمات HTTP

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

استعلامات Cypher

تمثل مخرج الطوارئ: إذا لم تغطِّ الأدوات الجاهزة سؤالك، يمكنك الاستعلام عن الرسم البياني مباشرة.

غيّر أسئلتك

أسئلة كنت تتجنبها لأنها تكلف 50,000 رمز مميز ودقيقتين أصبحت شبه مجانية:

«ما الذي يستدعي هذه الدالة؟» قبل كل إعادة هيكلة.
«كيف يمر الطلب عبر نقطة النهاية هذه؟» قبل التصحيح.
«ما الذي سيتأثر إذا حذفت هذا الحقل؟» قبل التنظيف.

القيمة الأساسية ليست ميزة منفردة، بل تغيير اقتصاديات الفضول.

ما يعرفه الرسم البياني وما لا يعرفه

هذه أهم حدود الأداة.

يعرف الرسم البياني ما يمكن اشتقاقه من الكود:

وجود المسار /v1/invoices/{id}.
الدالة التي تخدم المسار.
سلسلة الاستدعاءات.
العلاقات بين الخدمات.
المستدعين المتأثرين بتغيير معين.

لكنه لا يعرف عقد API غير المكتوب في الكود، مثل:

أن نقطة النهاية تعيد 409 بغلاف خطأ مختلف عند إعادة استخدام مفتاح عدم التكرار.
أن الحقل status يقبل خمس قيم فقط.
أن المؤشر معتم وليس إزاحة.
أن حقلًا معينًا أصبح مهجورًا وسيُحذف في الربع القادم.

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

لماذا يتكامل Apidog مع الأداة؟

لا يتنافسان؛ كل منهما يجيب عن نوع مختلف من الأسئلة:

يجيب الرسم البياني عن «أين؟»: أي معالج، وأي سلسلة استدعاءات، وما الذي سيتعطل.
تجيب المواصفات عن «ماذا؟»: المخططات، ورموز الحالة، وأغلفة الأخطاء، والقيود الفعلية.
تُنشئ النماذج الوهمية من المواصفات، بما في ذلك فروع الأخطاء التي قد لا يفكر الوكيل في اختبارها.
تفشل اختبارات العقد في CI عندما يختلف التطبيق عن الاتفاق.

إذا كان وكلاؤك يكتبون عملاء API اعتمادًا على أشكال لم تُوثّق، نزّل Apidog. اقرأ أيضًا:

ذاكرة الكود ليست ذاكرة العمل

يعيش الفهرس في دليل ذاكرة تخزين مؤقت على جهاز واحد وتحت حساب واحد. يمكن مشاركته بين جلسات Claude Code وCodex وOpenCode المحلية عبر خادم تنسيق، لكنه يظل محدودًا بذلك الجهاز.

والأهم أن الرسم البياني يمثل ذاكرة قاعدة الكود، لا ذاكرة العمل.

يمكنه إخبارك بأن مساعد إعادة المحاولة يستدعي عميل المدفوعات، لكنه لا يعرف:

لماذا تغير سلوك التراجع في يوليو.
من اتخذ القرار.
ما البديل الذي رُفض.
هل راجع أحد هذا القرار.

هذه المعلومات كانت غالبًا في جلسة طرفية انتهت.

يغطي Sharkly هذا النصف بجعل المهمة سجلًا دائمًا بدل أن تكون مطالبة مؤقتة:

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

المزيج الأقوى هو:

ذاكرة الكود: تمنح الوكيل استدعاءً سريعًا ودقيقًا للمستودع.
ذاكرة العمل: تمنح الفريق سجلًا دائمًا لما فعله الوكلاء ولماذا.

الأسئلة الشائعة

هل يعمل مع Cursor وCodex وOpenCode أم مع Claude Code فقط؟

إنه خادم MCP، لذلك يعمل مع أي عميل MCP متوافق. يسرد المشروع 45 سطح وكيل مدعومًا، ويكتشف المثبت تلقائيًا ما هو مثبت لديك. لمقارنة عملاء الوكلاء لبناء API، راجع نظرتنا إلى عملاء API في Cursor وCopilot.

هل يغادر الكود جهازك؟

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

هل تخفيض الرموز بنسبة 99% واقعي لمستودعي؟

الرقم 99.2% يخص خمس استعلامات هيكلية، وهي أفضل حالة للرسم البياني. الرقم الأوسع، الذي قيس عبر 31 مستودعًا، هو 10 مرات رموز أقل و2.1 مرة استدعاءات أدوات أقل. خطط على أساس 10 مرات، وتوقع فائدة أكبر عندما تكون أسئلتك هيكلية بكثافة.

ما حجم المستودع الذي يمكنه التعامل معه؟

الحالة القصوى المعلنة هي نواة Linux بحجم 28 مليون سطر و75,000 ملف خلال ثلاث دقائق. الحد الافتراضي للفهرسة التلقائية قابل للتكوين عند 50,000 ملف. أما مستودعات التطبيقات المعتادة فتُفهرس خلال أجزاء من الثانية.

لماذا يضع Defender علامة عليه؟

إنه إيجابي كاذب معروف ناتج عن التعلم الآلي تجاه الثنائيات الأصلية الصغيرة غير الموقعة. يوثق المشروع المشكلة، ويذكر أن 61 من نحو 62 محركًا تعطي نتائج نظيفة، ويربط نتائج VirusTotal بكل إصدار. وقد أصابت عائلة الكشف نفسها واجهة سطر أوامر GitHub وسصفات فعلية؛ لا يكفي الرسم البياني ولا قراءة المصدر وحدها.

الخلاصة

يُعد codebase-memory-mcp من أقل أدوات موجة وكلاء 2026 بريقًا وأكثرها عائدًا:

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

ثبّت الأداة، وفهرس مشروعك، فعّل auto_index، وافتح عارض الرسم البياني مرة واحدة لفهم ما بناه.

لكن احتفظ بالحدود واضحة:

يعرف الرسم البياني أين يوجد الكود، لا ما الذي تعد به API.
تسد Apidog فجوة العقد عبر المواصفات والنماذج الوهمية واختبارات العقد.
يتذكر الرسم البياني قاعدة الكود، لا القرارات وسياق العمل.
تسد Sharkly هذه الفجوة بجعل المهمة سجلًا دائمًا بدل مطالبة عابرة.

الاستدعاء المثالي للكود أساس قوي، لكنه ليس بديلًا عن معرفة ما هو صحيح أو لماذا اتُّخذ القرار.

DEV Community