مجموعتي المحلية لأدوات البرمجة بالذكاء الاصطناعي: كيف أحافظ على سرعة الوكلاء وكفاءة استهلاك الرموز

عمار نجار · نُشر في 23 أغسطس 2026

productivitytoolsaiopencodeclaude-code

صورة منشأة بالذكاء الاصطناعي

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

ولكن مع زيادة الاعتماد على هذه الأدوات، ظهر نوع جديد من تحديات التحسين.

جودة النموذج مهمة بلا شك، ولكن البيئة المحيطة به لا تقل أهمية.

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

لذلك بدأت في تحسين البيئة التشغيلية المحيطة بالوكيل.

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

أدواتي الحالية

هكذا تتكامل الأدوات في سير العمل اليومي:

الهدف ليس كثرة الأدوات.

الأهم هو إسناد مسؤولية واضحة لكل أداة. يوضح بقية المقال سبب وجود كل أداة والمشكلة التي تعالجها.

المشكلة: الوكلاء يستغرقون موارد أكثر مما تظن

يقوم وكيل البرمجة بما هو أكثر بكثير من مجرد كتابة الكود.

عند إسناد أداة له مثل:

Find where this value is calculated, understand the implementation,
change the behavior, and verify the result.

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

كل عملية من هذه العمليات تضيف معلومات إلى سياق النموذج.

تأمل أمراً بسيطاً مثل:

git diff

في التغييرات الكبيرة، يمكن أن ينتج هذا الأمر آلاف الرموز. أو:

cat some-large-file.ts

عندما لا يحتاج الوكيل إلا إلى جزء صغير جداً من ذلك الملف.

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

أصبح هدفي بسيطاً:

تزويد الوكيل بأقل قدر ممكن من المعلومات الكافية لاتخاذ القرار الصحيح التالي.

هذا المبدأ هو ما شكل مجموعة الأدوات التي أستخدمها اليوم.

النواة: OpenCode و Claude Code

وكلاء البرمجة الأساسيون لدي هما OpenCode و Claude Code.

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

ينطبق المبدأ نفسه على كل ما يحيط بالوكيل.

كل أداة في الجدول أعلاه لها دور محدد. عند استكشاف الكود، أحدد أولاً نوع المعلومة المطلوبة:

Text             → rg
Code structure   → ast-grep
Code semantics   → Serena

لا أريد أن يجرب الوكيل الأدوات الثلاث بالتعاقب، بل أن يختار الأداة المناسبة مباشرة.

إدارة السياق والمخرجات

تعالج المجموعة الأولى السبب الرئيسي الذي دفعني لتطوير هذا الإعداد: تقليل هدر الرموز والسياق.

Headroom: التحكم في نمو السياق

يجرف وكلاء البرمجة باستمرار السياق من مخرجات الأوامر، الملفات، استدعاءات الأدوات، والتفاعلات السابقة.

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

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

أتعامل مع Headroom كأداة لإدارة السياق وليس كأداة برمجة إضافية.

هذا التمييز جوهري: لا يستبدل Headroom البحث في المستودع أو أدوات فهم الكود، بل يقلل كلفة الاحتفاظ بتلك المعلومات خلال الجلسة.

RTK: تقليل مخرجات الأوامر

تعالج أداة RTK (اختصار Rust Token Killer) مصدراً آخر لاستهلاك الرموز: مخرجات أسطر الأوامر.

بدلاً من:

git status

أوجه الوكيل لتنفيذ:

rtk git status

ينطبق المبدأ نفسه على عمليات البناء، السجلات، أوامر GitHub، Docker، Kubernetes، والعديد من أدوات السطر البرمجي:

rtk git diff
rtk gh pr view 123
rtk bun run build
rtk docker logs my-container

ظهر تمييز مهم أثناء ضبط هذا الإعداد: لا ينبغي لـ RTK أن يحدد الأداة المستخدمة.

يختار الوكيل الأداة الأنسب أولاً، ثم تُغلف RTK تلك الأداة عند الحاجة.

على سبيل المثال:

rtk rg "PaymentService" src/

بهذا نحتفظ بقدرات البحث الخاصة بـ ripgrep، بينما يتكفل RTK بتقليل حجم المخرجات المرجعة للوكيل.

المخطط بسيط:

اختر الأداة المناسبة
        ↓
نفذها عبر RTK
        ↓
أرجع المخرجات المفيدة فقط

Caveman: الحفاظ على اختصار إجابات الوكيل

لا يأتي استهلاك الرموز من الأدوات فقط.

يمكن للوكيل نفسه أن يولد مخرجات غير ضرورية.

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

تساعد أداة Caveman في الحفاظ على إجابات مختصرة ومباشرة.

تعالج هذه الأدوات الثلاث جوانب مختلفة من المشكلة نفسها:

Headroom → إدارة السياق
RTK      → مخرجات الأوامر
Caveman  → مخرجات الوكيل

تلك هي القاعدة الأساسية للإعداد.

استكشاف الكود وفهمه

التحدي التالي هو كيفية تنقل الوكيل داخل المستودع البرمجي.

قراءة الملفات غالباً ما تكون أعلى كلفة من العثور على المعلومة المحددة أولاً.

ripgrep: البحث النصي

للأبحاث النصية العادية، يُعد rg من أكثر الأدوات فائدة في بيئة العمل.

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

rtk rg "localizedUrl" src/

كما يمكن تحديد نطاق البحث:

rtk rg "localizedUrl" src/ --type ts

هذا أفضل بكثير من فتح المجلدات وقراءة الملفات حتى يظهر الكود المطلوب.

fd: البحث عن الملفات

تؤدي أداة fd مع مسارات الملفات الدور نفسه الذي تؤديه rg مع المحتوى.

إذا كان اسم الملف معروفاً بشكل تقريبي، يمكن للوكيل البدء بـ:

rtk fd cloudflare

أو:

rtk fd '\.astro$' src/

الهدف واضح: حدد الموقع أولاً، ثم اقرأ ثانياً.

ast-grep: البحث في بنية الكود

في كثير من الأحيان، العنصر المطلوب ليس مجرد نص، بل تركيبة برمجية.

قد تفي التعبيرات النمطية (Regex) بالغرض، لكنها قد تصبح ضعيفة لأن الكود المصدري يمتلك بناءً وهيئية محدودة.

وهنا يأتي دور ast-grep.

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

فهي تسد الفجوة بين البحث النصي العادي والتنقل الدلالي الكامل.

Serena: التنقل الدلالي في الكود

تتعامل Serena مع الحالات التي يكون فيها السؤال متعلقاً بنموذج الكود بدلاً من تمثيله النصي.

أمثلة على ذلك:

أين تم تعريف هذا الرمز؟

ما هو الكود الذي يشير إلى هذا الصنف (Class)؟

ما هي التنفيذات الموجودة لهذه الواجهة (Interface)؟

كيف ترتبط هذه الرموز ببعضها؟

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

تقدم Serena هذه المعلومات بشكل مباشر.

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

البيانات المهيكلة و GitHub

يمكن لبعض الأدوات الصغيرة المحددة أن تمنع حجماً كبيراً من استهلاك السياق.

jq و yq

يتفاعل الوكلاء بشكل متكرر مع ملفات JSON و YAML.

إعدادات حزم البرامج، استجابات API، ملفات Kubernetes، وسير عمل GitHub Actions تستخدم هذه التنسيقات.

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

بدلاً من ذلك:

rtk jq '.scripts' package.json

ولملفات YAML:

rtk yq '.jobs' .github/workflows/build.yml

المبدأ بسيط:

استخرج المعلومة المحددة بدلاً من قراءة المستندات بالكامل.

تزداد فائدة هذا المبدأ مع استجابات API الكبيرة.

gh: التعامل مع GitHub من أسطر الأوامر

تتيح أداة GitHub CLI للوكيل فحص طلبات السحب، المشكلات، تشغيل Workflows، ومعلومات المستودع دون الخروج من واجهة الأوامر:

rtk gh pr list
rtk gh pr view 123
rtk gh run list

وهنا أيضاً، الاستعلامات الموجهة هي الأساس.

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

استخدام gh مع jq يجعل هذه الاستعلامات دقيقة للغاية.

ليس كل أداة للمطور تصلح أن تكون أداة للوكيل

استخدام bat، delta، و fzf أظهر لي فارقاً هاماً:

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

يستفيد الوكلاء عموماً من الأوامر الحتمية، النتائج المهيكلة، والمخرجات المحدودة.

بينما يستفيد المطورون من العرض البصري الغني، التنقل التفاعلي، تمييز الكود، والتحديد الضبابي.

لهذا السبب أستخدم شخصياً:

• bat لمعاينة الملفات بشكل مريح مع تمييز المقاطع وأرقام الأسطر.
• delta لعرض فروقات Git بشكل واضح.
• fzf للترشيح التفاعلي للملفات، الفروع، السجلات، ونتائج البحث.

هذه أدوات ممتازة للمطورين، لكنني لا أفرض على الوكيل المستقل استخدامها لمجرد أنها مثبتة.

على سبيل المثال، تُعد fzf مفيدة جداً عندما أكون أمام الشاشة لاختيار ملف أو فرع معين. بينما يستفيد الوكيل المستقل بشكل أكبر من استعلام حتمي باستخدام fd أو rg أو jq.

غالباً ما يتم التغاضي عن هذا الحد الفاصل عند إعداد وكلاء البرمجة.

إعطاء الوكيل إمكانية الوصول إلى المزيد من الأدوات لا يجعله أكثر كفاءة تلقائياً.

AGENTS.md: تنظيم عمل الأدوات معاً

تثبيت هذه الأدوات هو الجزء الأسهل.

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

أحتفظ بملف AGENTS.md يصف البيئة، اتفاقيات المشروع، قواعد اختيار الأدوات، متطلبات التحقق، ومبادئ كفاءة الرموز.

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

المهم ليس مجرد إخبار الوكيل:

You have rg.
You have ast-grep.
You have Serena.

بل تحديد المسؤوليات والقيود.

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

هذا يمنع نمط الفشل الشائع: تكرار البحث عن المشكلة نفسها باستخدام أدوات مختلفة لمجرد أن تلك الأدوات متوفرة.

إدارة الجلسات: استراتيجيات تتجاوز الأدوات الفردية

تساعد أدوات مثل Headroom، RTK، و Caveman على تقليل هدر الرموز خلال الجلسة. لكن بعض أكبر وفرات الاستهلاك تأتي من طريقة إدارة الجلسات نفسها.

الضغط (Compacting)

يدعم كل من OpenCode و Claude Code ميزة ضغط الجلسة. عندما يطول الحوار، يمكن ضغط السجل لتلخيص التاريخ وتفريغ مساحة في السياق.

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

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

جلسات جديدة للمهام الجديدة

عندما أنتقل إلى مهمة مختلفة تماماً، أبدأ جلسة جديدة بدلاً من الاستمرار في الجلسة السابقة.

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

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

تقسيم المهام (Task Decomposition)

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

التمييز بسيط:

عمل مرتبط ذو سياق مشترك مفيد
← واصل الجلسة

مهمة جديدة أو مختلفة جوهرياً
← ابدأ جلسة جديدة

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

تحديد صياغة الأوامر (Prompt Specificity)

تؤثر طريقة صياغة الطلب على مقدار البحث والتكرار الذي يحتاجه الوكيل.

أمر عام مثل:

Fix the login issue

يجبر الوكيل على الاستكشاف الواسع، قراءة ملفات متعددة، ووضع افتراضات.

بينما أمر محدد مثل:

Investigate the OAuth token refresh failure in src/auth/.
Identify the cause, make the smallest necessary change,
and verify the build.

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

هذه واحدة من أبسط طرق التحسين ومن السهل نسيانها.

أداة قيد المتابعة: Context Mode

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

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

الإعداد الحالي:
Headroom + RTK + Serena + Caveman

البديل:
Context Mode + RTK + Serena + Caveman

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

تُعد Context Mode أداة واعدة للاختبار، لكنني أراها كبديل محتمل لجزء من إعدادي الحالي أكثر من كونها طبقة إضافية فوقه.

القاعدة الأهم: اعرف متى تتوقف

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

يحتاج الوكلاء أيضاً إلى معرفة متى لا يستخدمون أداة أخرى.

لذلك يحتوي ملف AGENTS.md لدي على قواعد توقف صريحة:

Stop searching once enough evidence exists.

Do not inspect additional files merely for completeness.

Do not repeat a successful search using another tool.

Do not continue repository exploration after finding the relevant implementation.

After successful verification, stop unless additional verification is justified.

قد تكون هذه إحدى أكثر طرق تحسين استهلاك الرموز فاعلية في الإعداد بأكمله.

فالوكيل الذي يمتلك عشر أدوات ممتازة يمكنه هدر كميات هائلة من السياق إذا استمر في استخدامها دون حاجة.

الخلاصة

كان انطباعي الأول هو الاستمرار في إضافة الأدوات. لكن النهج الأفضل تبين أنه وضع الحدود.

قد تظهر بعض الأدوات متداخلة، لكنها تعمل على مستويات مختلفة. وأدوات أخرى ذات قيمة عالية للمطور في أسطر الأوامر لا تضيف الكثير للوكيل المستقل. المهم ليس زيادة الإمكانيات، بل التحكم في تدفق المعلومات.

يمكن تلخيص نهجي الحالي في خمس قواعد:

1. اختر الأداة بناءً على نوع المعلومة المطلوبة.
2. ابحث أو حدد الموقع قبل القراءة.
3. أرجع أقل قدر ممكن من المعلومات المفيدة.
4. اضغط مخرجات الأوامر المليئة بالضوضاء.
5. توقف عن الاستكشاف فور توفر الأدلة الكافية للعمل.

قد تتغير الأدوات الفردية مع الوقت، لكن المبدأ الأساسي أكثر ثباتاً:

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

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

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

مقالات ذات صلة

• الذكاء الاصطناعي المحلي على جهاز MacBook Pro بذاكرة 16 جيجابايت: ما الذي يعمل فعلياً
• أدوات التطوير الأساسية: إعداد ملف Brewfile الخاص بي

العودة إلى الأعلى