في عالم تطوير البرمجيات المعاصر، أصبح الاعتماد على وكلاء ترميز الذكاء الاصطناعي أمراً شائعاً. لكن هل كل مهمة تتطلب قوة نماذج الذكاء الاصطناعي باهظة الثمن؟ غالبًا ما يستهلك وكلاء الذكاء الاصطناعي آلاف الرموز المميزة (tokens) لأداء مهام بسيطة مثل قراءة الملفات، إنشاء ملفات اختبار boilerplate، أو تحديث الوثائق. هذه المهام التي لا تتطلب تفكيرًا عميقًا تستنزف ميزانيات الرموز المميزة بشكل غير مبرر، موجهةً موارد قيمة نحو أعمال إدخال/إخراج روتينية. فماذا لو كان بالإمكان تحويل هذه المهام الروتينية إلى حلول أقل تكلفة، مع توفير النماذج الأكثر تطورًا للمشكلات المعقدة التي تتطلب حقًا قدراتها الفائقة؟
هذه المشكلة ليست فردية، بل هي تحدٍ عالمي متزايد. تشير التوقعات إلى أن تكاليف ترميز الذكاء الاصطناعي قد تتجاوز متوسط رواتب المطورين بحلول عام 2028. حاليًا، ينفق ربع قادة الهندسة ما بين 200 إلى 500 دولار شهريًا لكل مطور على الرموز المميزة، وتصل هذه التكاليف في بعض الحالات إلى أكثر من 2000 دولار. في حين أن أدوات الذكاء الاصطناعي يمكن أن تكون مجدية اقتصاديًا، إلا أن فعاليتها مرهونة بوقف الهدر في استهلاك الرموز المميزة للمهام التي لا تستدعيها.
المثير في الأمر أن هذا التحدي يمكن معالجته دون الحاجة إلى فرق عمل أساسية أو اشتراكات جديدة. الحل يكمن في مفهوم بسيط وفعّال: وضعين فقط.
أوضاع AiKA: الكفاءة بتكلفة رمزية معدومة
تُعد أوضاع AiKA في Portal by Spotify حلًا مثاليًا لهذه المشكلة. الوضع هو عبارة عن وكيل تعريفي (declarative agent) يعمل في بيئة تنفيذ سريعة الزوال (ephemeral runtime)، مشابهة لخدمة AWS Lambda ولكن مصممة خصيصًا للوكلاء. تتيح هذه الأوضاع للمطورين تحديد التعليمات، اختيار النموذج، تعيين المعلمات مثل درجة الحرارة، وربط أدوات MCP بكل سهولة. يتولى Portal إدارة البنية التحتية بالكامل، مما يلغي الحاجة إلى مفاتيح API أو خوادم طويلة الأمد. يمكن استدعاء أوضاع AiKA عبر Portal CLI أو API، ويمكن أن تكون عامة (مشتركة على مستوى الشركة) أو خاصة.
لتفعيل هذا التوجيه الذكي، تم إنشاء وضعين رئيسيين. يستخدم كلاهما نموذج Gemini 2.5 Flash كنموذج عامل في الأمثلة المقدمة، ولكن حقل النموذج مرن ويقبل أي نموذج تم تهيئته في مثيل Portal الخاص بك، مما يمنحك حرية الاختيار الأمثل لاحتياجاتك.
الوضع الأول: القارئ الشامل (Bulk Reader)
صُمم هذا الوضع خصيصًا لمعالجة الحالات التي كان فيها Claude يستهلك رموزًا مميزة كثيرة لمجرد قراءة عدة ملفات كبيرة للإجابة على سؤال بسيط.
الوضع الثاني: كاتب التعليمات البرمجية (Code Writer)
يُستخدم هذا الوضع لإنشاء التعليمات البرمجية المتكررة أو القابلة للتنبؤ بها، مثل ملفات الاختبار، هياكل التكوين، أو أكواد البدء (boilerplate code)، حيث يمكن استنتاج النمط المطلوب من الملفات الموجودة.
تعتبر التعليمات output only the code حاسمة للغاية هنا. فبدونها، سيقوم النموذج بتغليف الكود بسياج Markdown ونصوص توضيحية، مما يفرض على Claude تحليل هذه الإضافات غير الضرورية.
آلية التوجيه الذكي (Routing Mechanism)
في البداية، كانت آلية التوجيه تعتمد على مجموعة من القواعد المحددة في ملف CLAUDE.md. على الرغم من أنها كانت تعمل بشكل ما – حيث كان Claude يقرأ التعليمات ويوجه نفسه إلى Portal – إلا أنها كانت تعاني من قيود. كانت هذه القواعد استشارية وغير قابلة للتنفيذ بشكل صارم، مما سمح لـ Claude بتجاهلها. بالإضافة إلى ذلك، كان كل مشروع يتطلب نسخته الخاصة من التعليمات، مما زاد التعقيد.
الإصدار الحالي يعتمد على مكون إضافي يُسمى Claude Code Shunt. يمر التفويض الآن عبر سجل إجراءات Portal CLI، مما يتيح للمكون الإضافي العمل بكفاءة مع أي مثيل لـ Portal مُفعّل فيه مكون AiKA الإضافي.
الطبقة الأولى: الخطافات (Hooks)
تُطلق خطافات Claude Code قبل كل استدعاء للأداة. يقوم مكون Shunt الإضافي بتسجيل خطافي PreToolUse رئيسيين:
- التحقق من حجم الملف: يتم تشغيله عند كل عملية قراءة. إذا تجاوز الملف حدًا معينًا لعدد الأسطر (الافتراضي: 350)، يقوم الخطاف بحظر القراءة ويوجه Claude لاستخدام مهارة /bulk-reader بدلاً من ذلك. يتم السماح بعمليات القراءة المستهدفة، حيث يعرف Claude بالفعل القسم المطلوب.
- التحقق من قراءة Bash: يلتقط أوامر cat وhead وtail وless وmore عند التعامل مع الملفات الكبيرة. يتم السماح للأوامر الموجهة مثل cat file | grep بالمرور لأنها تُعتبر قراءات مستهدفة.
يمكن ضبط هذه العتبة القابلة للتكوين عبر متغير البيئة SHUNT_MIN_LINES. يمكنك تعيينها في ملف تعريف Shell الخاص بك أو في ملف .claude/settings.json:
الطبقة الثانية: البرامج النصية (Scripts)
يوجد برنامجان نصيان من نوع Bash يقومان بتغليف استدعاءات Portal CLI. يستدعي Claude هذه البرامج النصية باستخدام وسائط مسمّاة. تتولى البرامج النصية معالجة جميع العمليات داخليًا: بدء الطلب، استدعاء الإجراءات، فك تغليف الأخطاء، والإبلاغ عن استهلاك الرموز المميزة إلى stderr.
تُعالج الأوضاع بالاسم ويتم حلها بواسطة Portal بطريقة غير حساسة لحالة الأحرف، مع إعطاء الأولوية لوضعك الخاص أولاً، ثم وضع فريقك، وأخيرًا الوضع العام. على سبيل المثال، إذا قمت بإنشاء نسخة مخصصة من القارئ الشامل العام، فسيتم منح إصدارك الأولوية تلقائيًا دون الحاجة إلى أي تهيئة إضافية.
برنامج قراءة بالجملة (Bulk Read): يقوم هذا البرنامج النصي بتغليف كل ملف بعلامات XML لتحديد حدوده بوضوح، ثم يرسلها إلى وضع القارئ الشامل مع السؤال المطروح.
كل عملية تفويض هي عملية مستقلة (one-shot). تكون الاستدعاءات سريعة الزوال، أي لا يتم تخزين أي بيانات على جانب الخادم. إعادة إرسال الملفات للمتابعة تكون مجانية ومهمة، لأن البيانات تنتقل مباشرة إلى النموذج العامل ولا تدخل أبدًا في سياق Claude، مما يوفر في استهلاك الرموز.
برنامج كتابة التعليمات البرمجية (Code Write): يرسل هذا البرنامج النصي المواصفات وملفًا مرجعيًا إلى وضع كاتب التعليمات البرمجية. يقوم بإزالة أسوار Markdown من المخرجات ويمكنه الكتابة مباشرة إلى القرص. لا يرى Claude أبدًا الكود الذي تم إنشاؤه. يُعد الملف المرجعي ضروريًا؛ فبدون ملف لمطابقة الأنماط، سيقوم النموذج بإنشاء تعليمات برمجية تفتقر إلى السياق ولن تتناسب مع مشروعك.
الطبقة الثالثة: المهارات (Skills)
يحدد ملفا المهارات لـ Claude متى وكيف يتم استدعاء البرامج النصية. المهارات هي ملفات Markdown تحتوي على وصف وأمثلة للاستخدام. عندما يقوم الخطاف بحظر عملية قراءة، فإن رسالة الحظر توجه Claude إلى مهارة /bulk-reader، والتي توضح له بناء الجملة الدقيق للاستدعاء.
تضمن هذه الطبقات أن النظام يتدهور بأمان. فحتى إذا لم يقرأ Claude وصف المهارة، فإن الخطاف سيظل يمنع القراءات المكلفة. المهارة هنا تجعل عملية إعادة التوجيه أكثر سلاسة وكفاءة.
نتائج الأداء وتوفير التكاليف (Benchmarks)
لتقييم فعالية هذا النظام، تم إجراء اختبارات شاملة على مستودع Java أحادي (monorepo) عبر أربعة سيناريوهات مختلفة. تم قياس الرموز المميزة التي يستهلكها Claude عند قراءة الملفات مباشرة، مقارنةً بالاستهلاك عند استخدام القارئ الشامل أو كاتب التعليمات البرمجية. وقد أظهرت النتائج أن متوسط التوفير في استهلاك الرموز المميزة لعمليات القراءة الشاملة بلغ 90%.
أما بالنسبة لسيناريو كتابة التعليمات البرمجية، فيصعب قياس التوفير بالرموز المميزة مباشرة. فبدون آلية التحويل (shunt)، يقرأ Claude الملفات المرجعية ويولد المخرجات كرموز إخراج مكلفة. بينما باستخدام آلية التحويل، يتم كتابة الكود مباشرة إلى القرص دون أن يراه Claude أبدًا، مما يلغي تمامًا استهلاك الرموز في هذه المرحلة.
حدود ومحاذير الاستخدام (Limitations)
- لا يمكنك تفويض التحرير: لا تتضمن ملخصات نموذج العامل أرقام أسطر موثوقة. إذا احتاج Claude إلى إجراء تعديلات بناءً على التحليل، فعليه قراءة القسم المحدد مباشرة. تسمح الخطافات بالقراءة المستهدفة (مع الإزاحة/الحد) لهذا السبب بالتحديد، لذا يحفظ التفويض الرموز المميزة عند الفهم.
- لا يمكنك تفويض المنطق: يتعرف النموذج العامل على الأنماط على مستوى السطح، ولكنه قد يرتكب أخطاء دقيقة تتعلق بسلامة الخيط (thread safety)، كما حدث في أحد الاختبارات. اكتشف Claude هذا الخطأ في ثوانٍ بمجرد تزويده بالسياق الصحيح. يستثني التوجيه بشكل صريح مهام تصحيح الأخطاء، القرارات المعمارية، والتعليمات البرمجية الحساسة للسلامة.
- الكمون (Latency) يتراكم: كل عملية تفويض تمثل رحلة ذهابًا وإيابًا عبر الشبكة: من Claude Code إلى الواجهة الخلفية لـ Portal ثم إلى النموذج العامل والعودة. تستغرق الاستجابات عادةً من 10 إلى 30 ثانية، ويحدد Portal استدعاءً واحدًا كل 30 ثانية. لذا، يجب تقسيم عمليات التوليد الكبيرة جدًا إلى استدعاءات أصغر. هذا مقبول للقراءات الكبيرة، ولكنه قد يكون غير فعال للقراءات الصغيرة. لهذا السبب، يوجد حد لعدد الأسطر، حيث يتجاوز مقدار التفويض التوفير إذا كانت القراءة أقل من هذا الحد.
توفير الرموز المميزة: مجرد بداية الإمكانات
على الرغم من أن المكون الإضافي Shunt يُعد جزءًا أساسيًا من تكامل Claude Code، إلا أن الفكرة الجوهرية تكمن في توجيه النموذج المدعوم بـ أوضاع AiKA. هذه الأوضاع هي العنصر الحاسم الذي يحمل القوة الحقيقية:
- قابلة لإعادة الاستخدام: تعمل نفس أوضاع القارئ الشامل وكاتب التعليمات البرمجية عبر جميع المشاريع وأي أداة يمكن إرسالها إلى Portal CLI.
- قابلة للمشاركة: كلا الوضعين متاحان للعامة في AiKA، مما يتيح لأي شخص استخدامهما اليوم دون الحاجة إلى إنشاء أدواته الخاصة.
- قابلة للتأليف: يمكنك إنشاء أوضاع جديدة بسهولة، مثل وضع كاتب المستندات للتوثيق، ووضع المراجع لملخصات مراجعة التعليمات البرمجية، ووضع المترجم للتعريب (i18n). كل ذلك على بعد بضع نقرات.
- يفصلون قرار التوجيه عن العامل: يقرر المكون الإضافي متى يتم التفويض، بينما يقرر الوضع كيف يتم الرد. يمكنك استبدال Gemini Flash بنموذج أرخص، أو تغيير موجه النظام، أو إضافة أدوات MCP، دون أن يتأثر المكون الإضافي.
هذه هي القوة الحقيقية لأوضاع AiKA: إنها تحول عملية توجيه النموذج من مشكلة هندسة أنظمة معقدة إلى مجرد مسألة تهيئة بسيطة. لم تعد بحاجة لبناء البنية التحتية، بل تصف فقط ما تريده وتسميه.
كيف تبدأ (Get Started)
لتجربة هذه الحلول بنفسك، اتبع الخطوات التالية:
أولاً، قم بتثبيت كلا المكونين الإضافيين من سوق spotify/portal-ai-plugins باستخدام الأوامر التالية:
يوفر المكون الإضافي Portal واجهة سطر الأوامر (CLI) الخاصة بـ Portal، والتي تُستخدم لتوجيه عمليات التفويض.
بعد ذلك، في جلسة Claude Code جديدة، قم بتشغيل الأمر /portal:setup لإعداد ومصادقة Portal CLI مقابل مثيل Portal الخاص بك.
أنت الآن جاهز للبدء! ما عليك سوى طرح سؤال يتضمن عدة ملفات لمشاهدة الفرق.
يتوفر وضعا القارئ الشامل وكاتب التعليمات البرمجية بالفعل للاستخدام العام، مما يعني أنك لست بحاجة إلى إنشاء أي شيء من البداية. وإذا رغبت في تخصيصهما – باستخدام نموذج عامل مختلف أو تعليمات مغايرة – يمكنك بسهولة تفرعهما (fork) داخل Portal، وسيحظى إصدارك بالأسبقية تلقائيًا.
باختصار، توفر أوضاع AiKA قابلية عالية لإعادة الاستخدام عبر المشاريع والمشاركة ضمن فريقك. بينما يفرض المكون الإضافي Shunt آلية توجيه ذكية، مما يحررك من التفكير في تعقيدات إدارة الرموز المميزة. هذا النهج المبتكر من Spotify لا يقلل التكاليف فحسب، بل يعزز أيضًا كفاءة ومرونة سير عمل تطوير البرمجيات باستخدام الذكاء الاصطناعي.