اسأل وكيل البرمجة لديك عن مكان استدعاء دالة وراقب ما سيحدث. يبدأ بالبحث عبر grep، ثم يقرأ ثلاثة ملفات، ثم يعيد البحث بنمط مختلف، ثم يقرأ أربعة ملفات أخرى، وفي النهاية يجيب إجابة صحيحة، بعد أن ملأ سياقه بشيفرة مصدرية سينساها بمجرد انتهاء الجلسة. ثم اطرح سؤالاً متابعاً، فيعيد العملية كلها من البداية.
أداة codebase-memory-mcp تُلغي هذه الحلقة المفرغة. وبـ41,536 نجمة، وترخيص MIT، وكتابتها بلغة C، فهي الأداة الأفضل مردوداً في موجة أدوات الوكلاء لهذا العام، بأقل تغيير ممكن في طريقة عملك. إنها تمنح الوكيل ذاكرة بشيفرتك. لكنها لا تمنح فريقك ذاكرة بالعمل، وهما مشكلتان مختلفتان.
باختصار
هذا واحد من خمس تحليلات معمّقة من قائمتنا المجمّعة حول الأدوات مفتوحة المصدر التي توسّع وكلاء البرمجة.
تفهرس codebase-memory-mcp المستودع في رسم بياني معرفي دائم يضم الدوال والأصناف وسلاسل الاستدعاء والمسارات، ثم تجيب عن الأسئلة البنيوية من الرسم البياني بدلاً من البحث عبر grep. وتقيس الأداة خمسة استعلامات بنيوية بنحو 3,400 توكن عبر الرسم البياني، مقابل نحو 412,000 توكن عند القراءة ملفاً بملف. وهي ملف تنفيذي أصلي واحد، لا يحتاج إلى بيئة تشغيل ولا مفتاح API، ويعمل محلياً بالكامل، ويتوافق مع أي عميل MCP. ثبّتها أولاً. ثم قرّر على حدة أين سيعيش سجل ما فعله وكلاؤك.
ما الذي تفعله
يجري التحليل عبر tree-sitter لأكثر من 160 لغة، مع طبقة إضافية لاستنتاج الأنواع الدلالية لمجموعة أساسية تشمل Python، وعائلة TypeScript وJavaScript، وGo، وJava، وRust، وC#، وC++. وتُعرض النتيجة عبر 15 أداة MCP تغطي البحث، وتتبع سلاسل الاستدعاء، ونظرة عامة على المعمارية، وتحليل الأثر، واكتشاف الشيفرة الميتة، واستعلامات الرسم البياني، والربط بين الخدمات عبر HTTP. ويمكن لأي عميل يتحدث Model Context Protocol أن يستخدمها، ويذكر المشروع 45 واجهة وكيل مدعومة.
| المقياس | القيمة المُعلنة |
|---|---|
| خمسة استعلامات بنيوية | ~3,400 توكن مقابل ~412,000 ملفاً بملف |
| مقارنة مُحكَّمة | توكنات أقل بعشر مرات، واستدعاءات أدوات أقل بـ2.1 مرة، وجودة إجابات 83% |
| فهرسة نواة Linux | 28 مليون سطر، و75 ألف ملف، في 3 دقائق |
| زمن استجابة الاستعلام البنيوي | أقل من 1 مللي ثانية |
اقرأ رقمي التوكن معاً. انخفاض 99% يخص خمسة استعلامات بنيوية، وهي أفضل حالة للرسم البياني. أما الرقم الوارد في الدراسة الأولية عبر 31 مستودعاً فهو 10 أضعاف. لذا خطّط على أساس 10 أضعاف، واعتبر أي نتيجة أفضل مكسباً إضافياً.
تثبيتها
curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash
تتوفر على Windows أداة تثبيت بـPowerShell، ويوصي المشروع بقراءتها قبل تشغيلها. تكتشف أداة التثبيت وكلاء البرمجة لديك وتكتب إعدادات MCP الخاصة بهم. أعد تشغيل الوكيل واطلب منه فهرسة المشروع.
إعدادان يستحقان التطبيق من اليوم الأول:
codebase-memory-mcp config set auto_index true
codebase-memory-mcp --ui=true --port=9749
عارض الرسم البياني مدمج في الملف التنفيذي، وهو فحص سريع مفيد للتأكد من أن الفهرس غطى ما توقعته.
وثّق المشروع تحذيرين بنفسه، وكلاهما يستحق ثلاثين ثانية من وقتك. قد يصنّف Microsoft Defender أحد إصدارات الملف التنفيذي كإيجابية كاذبة، ويشير المشروع إلى أن 61 من أصل 62 محركاً تقريباً تُرجع نتيجة سليمة عادةً، وأن عائلة الكشف نفسها تطال GitHub CLI وسلسلة أدوات Go الخاصة بمايكروسوفت. كما أن الأداة تقرأ شيفرتك وتكتب في ملفات إعداد الوكيل، وهذا هو عملها، بصراحة. اقرأ سكربت التثبيت قبل تمريره إلى shell.
لماذا هذه أولاً
كل ما عداها في موجة الأدوات الحالية يطلب منك تغيير طريقة عملك. مكتبات الأدوار تغيّر طريقة صياغتك للأوامر. وأشجار العمل المتوازية تغيّر طريقة تنظيمك. والوصول إلى الويب يغيّر ما تطلبه.
هذه لا تغيّر شيئاً وتجعل كل جلسة أقل كلفة. لا عادة جديدة تتعلمها.
أثر الجودة هو النصف الأقل تقديراً. الوكيل الذي ينفق 400,000 توكن في قراءة الملفات يتبقى لديه مجال أقل بكثير للتفكير في مشكلتك، كما تتدهور قدرته على استرجاع ما قرأه في البداية مع طول الجلسة. أما الإجابة من الرسم البياني فتُبقي السياق متاحاً.
يظهر هذا التحوّل في نوعية أسئلتك. فالأسئلة التي كنت تتجنبها لأنها تكلف 50,000 توكن ودقيقتين أصبحت الآن شبه مجانية. وتحليل الأثر قبل تغيير توقيع دالة يحوّل «أظن أن هذا آمن» إلى قائمة واضحة. كما أن تتبع سلسلة الاستدعاء في مستودع غير مألوف أفضل من القراءة صعوداً عبر خمسة ملفات أملاً في العثور على نقطة الدخول.
ذاكرة الشيفرة ليست ذاكرة العمل
إليك الحد الفاصل، وهو حدّ حاد.
الرسم البياني مبني من شيفرتك، لذا يعرف ما هي شيفرتك. يستطيع أن يخبرك أن دالة إعادة المحاولة تستدعي عميل المدفوعات. لكنه لا يستطيع أن يخبرك لماذا تغيّر التأخير التراكمي في يوليو، ولا من قرر ذلك، ولا ما كان البديل، ولا ما إذا راجعه أحد. ذلك التاريخ كان موجوداً في جلسة طرفية لم يعد لها وجود.
يلمس الفرق هذا كتناقض غريب: الوكيل يتذكر قاعدة الشيفرة أفضل من أي إنسان في الفريق، بينما لا يتذكر إطلاقاً القرارات التي أنتجتها.
كما أن الفهرس خاص بكل جهاز على حدة. فهو يعيش في مجلد ذاكرة تخزين مؤقت تحت حساب واحد، ويُشارَك بين جلساتك المحلية عبر خدمة تنسيق (daemon)، ويتوقف عند حدود ذلك الجهاز.
أين يعيش سجل العمل
المهمة (Task) هي وحدة العمل الأساسية في Sharkly. فهي تحمل الطلب، والسياق، والتنفيذ، والعوائق، والنتيجة في مكان واحد مشترك، بدلاً من توزيعها على أوامر خاصة وجلسات طرفية متفرقة.
لكل جزء مهمة واحدة. فالوكيل (Agent) يحدد كيف ينبغي التعامل مع العمل. والكمبيوتر (Computer) يوفر المضيف والموارد المحلية. وبيئة التشغيل (Runtime) تنفذ جلسة الوكيل الفعلية باستخدام أداة البرمجة المثبتة هناك أصلاً. أما المهمة فتبقى السجل المشترك.
هذا الفصل يجعل الاقتران ملموساً. الفهرس مورد محلي على الكمبيوتر، لذا فإن الكمبيوتر الذي يحتفظ بمستودع مفهرس هو الجهاز الذي يوجد عليه رسم بياني جاهز، بدلاً من بداية باردة تستغرق ثلاث دقائق. والوكيل إعداد محفوظ، لذا فإن الإعداد الذي يمتلك فيه وكيلك الفهرس والصلاحيات المناسبة يُعاد استخدامه بدلاً من إعادة بنائه على كل جهاز. أما التنفيذ والعوائق والنتائج والنقاش اللاحق فتعود إلى الجدول الزمني للمهمة، وهو المكان الذي يبقى فيه التفكير الكامن وراء التغيير.
Sharkly ليس بديلاً عن Claude Code أو Codex أو codebase-memory-mcp. إنه يضيف طبقة المهمة المشتركة والكمبيوتر والسياق والتحكم والمراجعة حولها. ويستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المهيأة في تلك الأدوات.
ذاكرة الشيفرة زائد ذاكرة العمل هي التركيبة المطلوبة. إحداهما تمنح الوكيل تذكّراً للمستودع، والأخرى تمنح الفريق تذكّراً لما فعله الوكلاء فيه.
متى تحتاج إلى كل منهما
ثبّت codebase-memory-mcp الآن، أيّاً كان حجم فريقك. فهي محلية، ولا تتطلب أي تغيير في سير العمل، ويطبَّق خفض الكلفة على مطوّر واحد كما على عشرين.
أضف نظام عمل مشتركاً عندما يجب أن يعيش التفكير أطول من الجلسة: عندما تجري المراجعة قبل الإطلاق، أو عندما يلمس أكثر من شخص المستودع نفسه، أو عندما سيسأل أحدهم بعد ثلاثة أشهر عن سبب إجراء تغيير ما. الرسم البياني سيجيب عن ماذا تفعل الشيفرة. لكنه لن يجيب أبداً عن لماذا.
الوكلاء يبحثون وينفذون ويختبرون ويقدمون التقارير. أما البشر فيحددون الاتجاه، ويمنحون الصلاحية، ويقبلون النتيجة.
الأسئلة الشائعة
هل تعمل مع وكلاء غير Claude Code؟ نعم. إنها خادم MCP، لذا يعمل معها أي عميل MCP، ويذكر المشروع 45 واجهة وكيل مدعومة من بينها Cursor وCodex وWindsurf وOpenCode وAider.
هل تخرج شيفرتي من جهازي؟ لا. تجري المعالجة محلياً بالكامل، ويؤكد المشروع أنها لا ترسل أي طلب شبكة من تلقاء نفسها ولا تتحقق من التحديثات في الخلفية. والمصدر متاح إن أردت التحقق بدلاً من الثقة.
هل انخفاض التوكنات بنسبة 99% رقم واقعي؟ هذا الرقم يخص خمسة استعلامات بنيوية، أي أفضل حالة. أما الرقم المُحكَّم عبر 31 مستودعاً فهو توكنات أقل بعشر مرات، واستدعاءات أدوات أقل بـ2.1 مرة. فخطّط على أساس 10 أضعاف.
ما أكبر مستودع يمكنها التعامل معه؟ أقصى حالة مذكورة هي نواة Linux بـ28 مليون سطر في ثلاث دقائق. أما مستودعات التطبيقات العادية فتُفهرس في أجزاء من الثانية.
هل تفيد عندما يعمل عدة وكلاء في الوقت نفسه؟ نعم، وبأكثر من المعتاد. فخمسة وكلاء يبحثون بـgrep في المستودع نفسه يعني هدراً مضاعفاً خمس مرات. ومع ذلك تحصل كل مهمة على شجرة عمل معزولة خاصة بها، بينما يُشارَك الفهرس البنيوي على الكمبيوتر.
النسخة المختصرة
هذه أقل الأدوات ظهوراً في موجة 2026، وأفضلها مردوداً. ملف تنفيذي أصلي واحد، بلا أي تغيير في سير العمل، مع خفض مُقاس بمقدار رتبة كاملة في التوكنات التي ينفقها الوكيل للإجابة عن أسئلة كان يجدر ألا يبحث عنها بـgrep أصلاً. ثبّتها، وفهرس مشروعك، وافتح عارض الرسم البياني مرة واحدة لترى ما بنته.
ثم كن واضحاً بشأن الحدود. فهي تتذكر المستودع لا العمل، والقرارات الكامنة وراء أي تغيير تموت مع الجلسة ما لم يحتفظ بها شيء ما. وSharkly يحتفظ بها: فالمهمة هي السجل المشترك، والتنفيذ يجري على أجهزة Computers تتصل بها عبر بيئات التشغيل التي تدفع ثمنها بالفعل، وتعود النتائج إلى مكان يستطيع فيه إنسان مراجعتها وقبولها.
