Spotify Xirp: مركز تحكم لوكلاء البرمجة

إذا كانت لديك جلسة برمجة واحدة فقط مفتوحة في مستودع واحد، فلن تحتاج إلى مركز تحكم جديد. غالبًا ما تكفي نافذة طرفية ووكيل واحد وفرع Git مرتب.

يصبح المشهد مربكًا عندما يطوّر Codex ميزة، ويحلل Claude Code خطأ، ويختبر Gemini فكرة ثانية بالتوازي. أي وكيل ينتظر الموافقة؟ في أي فرع توجد التغييرات؟ أي جلسة تتبع أي مشروع؟ وكيف نمنع وكيلين من تعديل checkout نفسه في الوقت ذاته؟

هذه هي المشكلة التي يريد Xirp حلها. الاسم يأتي من Spotify، لكنه لا يرتبط بالموسيقى أو قوائم التشغيل أو تطبيق Spotify. Xirp تطبيق macOS للعمل مع وكلاء البرمجة المعتمدين على الذكاء الاصطناعي. فهو يجمع المشاريع والنوافذ الطرفية الدائمة وGit worktree والملفات والقواعد وskills في واجهة واحدة.

قد يبدو للوهلة الأولى كأنه بيئة تطوير أخرى مدعومة بالذكاء الاصطناعي، لكن هذا الوصف غير كافٍ. لا يحتوي Xirp على نموذج لغوي خاص به، ولا يستبدل Codex أو Claude Code أو Gemini. بل ينظم الوكلاء المثبتين والمهيئين مسبقًا على جهاز Mac.

ما هو Xirp فعليًا؟

تصف Spotify تطبيق Xirp بأنه agentic development environment. وبصياغة أبسط، هو لوحة تحكم رسومية لعدة جلسات محلية لوكلاء البرمجة.

الجلسة هي نافذة طرفية دائمة يعمل فيها وكيل. يمكن ربطها بمشروع محلي وGit worktree مستقل، أو تشغيلها دون سياق مشروع. عند إنشائها، تختار Codex أو Claude Code أو Gemini، وتصف الهدف، ثم تقرر ما إذا كان الوكيل سيعمل في checkout الحالي أو worktree جديد.

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

لا يزال Xirp في مرحلة تجريبية، ويعمل حاليًا على macOS فقط. وهو برنامج مغلق المصدر ومملوك لـSpotify. يتطلب التسجيل عنوان بريد إلكتروني للعمل، ووفقًا للأسئلة الشائعة لا تُقبل العناوين الشخصية من Gmail أو Yahoo أو Outlook.com.

ما الذي يستطيع Xirp فعله؟

لا تأتي فائدته من زر واحد لافت، بل من جمع عدة مهام متفرقة اليوم في مكان واحد.

المشاريع والجلسات الدائمة

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

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

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

Git worktree بدلًا من عدة وكلاء في checkout واحد

يمكن لـXirp إنشاء Git worktree مخصص لجلسة جديدة، مع فرع ودليل عمل مستقلين. وبهذا يستطيع عدة وكلاء العمل على المستودع نفسه من دون إعادة كتابة الملفات نفسها في checkout واحد بالتزامن.

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

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

الطرفية والملفات وGit وعدة وكلاء في عرض واحد

عرض الجلسة نافذة طرفية تفاعلية. يمكنك الرد والموافقة على الأذونات واستخدام أوامر الوكيل كما في CLI الأصلية. ويمكن أيضًا البحث في الملفات وتحريرها، وفحص diff والفروع وcommits، وفتح محرر أو طرفية خارجية داخل worktree الصحيح.

يعرض Grid view عدة نوافذ طرفية نشطة جنبًا إلى جنب. وهو مفيد عندما تعمل جلستان وتنتظر الثالثة قرارًا. كما يمكن إنشاء fork للمحادثة لتجربة مسار آخر مع الحفاظ على المسار الأصلي.

وفقًا للوثائق، يمكن التبديل إلى وكيل آخر مثبت أثناء الجلسة. يبقى دليل العمل وحالة المشروع متاحين. لكن Xirp لا يحوّل الإعدادات الخاصة بين الوكلاء. لذلك لا يعني الانتقال من Claude Code إلى Codex أن كل تفاصيل التهيئة ستعمل بالطريقة نفسها تلقائيًا.

القواعد وskills القابلة لإعادة الاستخدام

يعرض Xirp ملفات التعليمات العامة والخاصة بالمشروع، مثل AGENTS.md وCLAUDE.md، ويكتشف skills القابلة لإعادة الاستخدام في المجلدات المدعومة. يمكن أن تصف skill فحص إصدار أو عملية ترحيل أو إجراء تحقق ثابتًا.

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

سير عمل واقعي

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

• يحدّث Codex التبعية في worktree مستقل ويشغّل الاختبارات.
• يحلل Claude Code الخطأ في فرع ثانٍ.
• يراجع Gemini الوثائق أو يستكشف حلًا بديلًا.

تبقى النوافذ الطرفية الثلاث مرئية في Grid view. ويبين عرض Git الملفات التي غيّرها كل فرع. إذا كان وكيل ينتظر الموافقة، فلن تحتاج إلى البحث بين النوافذ. بعد ذلك يمكن مراجعة النتائج واختبارها ودمجها كل على حدة.

هنا يظهر الاستخدام المناسب لـXirp. فهو لا يساعد أساسًا مع الوكيل الأول، بل مع مسار العمل الثالث أو الخامس أو العاشر. تشير Spotify في مقالها إلى أكثر من 50 جلسة متوازية وأكثر من 36,000 جلسة داخلية. هذه أرقام من الشركة في بيئة Spotify، وليست دراسة مستقلة للإنتاجية.

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

ما الذي يضيفه Spotify Portal؟

يعمل Xirp دون Spotify Portal. فالنوافذ الطرفية الدائمة والمشاريع المحلية وworktrees وGrid view والملفات وGit وskills والقواعد جزء من التطبيق المستقل.

يضيف Portal الطبقة التنظيمية. فهو يحتفظ بكتالوج برمجي يتضمن الخدمات والتبعيات والملكية وبيانات وصفية أخرى. ويمكن لـWorkspaces جمع صفحات wiki والقرارات التقنية والروابط والمهام والأعضاء والجلسات السابقة. يستطيع Xirp بدء جلسة من عنصر في الكتالوج أو Workspace وتقديم السياق عبر MCP.

الهدف هو حل مشكلة معروفة في المؤسسات الكبيرة: يرى الوكيل المستودع، لكنه لا يعرف تلقائيًا من يملك خدمة upstream، أو سبب قرار معماري، أو القيود التي وثقها فريق آخر.

يمكن لـPortal تقديم هذا السياق عند الحاجة بدلًا من وضع كل وثيقة في prompt الأول. وبعد الجلسة يمكن رفع سجلها يدويًا إلى Workspace، ليستفيد منه الزملاء والوكلاء اللاحقون.

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

قد يكون Portal بنية زائدة لفريق صغير. أما المؤسسة التي تملك مستودعات كثيرة ومسؤوليات متغيرة وعملًا مكررًا، فقد تستفيد فعليًا من طبقة سياق مشتركة.

الأمان: محلي لا يعني غير متصل

توضح Spotify أن تسجيل مشروع محلي لا يرفع ملفاته إلى Portal. يعمل Xirp مع المجلد على Mac، ويجب بدء رفع الجلسة يدويًا.

لكن ذلك لا يعني أن سير البرمجة كله يبقى غير متصل. يواصل الوكيل المختار التواصل مع OpenAI أو Anthropic أو Google أو مزود آخر وفق إعداداته. تعتمد prompts ومقاطع الكود ونتائج الأدوات المرسلة على التهيئة الأصلية للوكيل. لا تغير إدارة Xirp المحلية تدفقات البيانات هذه.

رفع الجلسة يتضمن أكثر من المحادثة

بحسب Spotify، يشارك الرفع المحادثة الكاملة واستدعاءات الأدوات وتغييرات الملفات وreasoning الخاص بالوكيل ومسارات الملفات. وقد يحتوي على مقاطع كود وأي معلومات عالجها الوكيل خلال الجلسة.

والأهم أن Xirp لا يزيل secrets أو بيانات الاعتماد أو البيانات الشخصية أو المحتوى السري قبل الرفع. يجب على المستخدم مراجعة السجل وعدم رفع الجلسات الحساسة.

للاستخدام الإنتاجي، سأضع على الأقل القواعد التالية:

• تشغيل الوكلاء بالأذونات اللازمة للمهمة المحددة فقط.
• استخدام الأوضاع المستقلة وpermission bypass داخل بيئات محدودة بوضوح فقط.
• استخدام worktree منفصل وقابل للحذف للمهام الخطرة.
• فحص transcripts بحثًا عن secrets وبيانات العملاء قبل كل رفع إلى Portal.
• الإبقاء على حماية الفروع والاختبارات وcode review وsecret scanning مستقلًا عن Xirp.

تحمي worktrees من التداخل غير المقصود في checkout نفسه، لكنها ليست حدًا أمنيًا لأوامر shell أو وصول الشبكة أو أذونات Mac. تبقى هذه مسؤولية sandbox وآليات الموافقة الخاصة بكل وكيل.

البيانات المحلية والقياس عن بعد

يحفظ Xirp حالته المحلية افتراضيًا في ~/.xirp. تصف Spotify القياس الاختياري بأنه مستعار الهوية، وتقول إنه لا يتضمن prompts أو الكود أو مسارات الملفات أو النص الحر. يمكن تعطيله من الإعدادات أو عبر XIRP_TELEMETRY=0.

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

لمن يناسب Xirp؟

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

الفاصل بسيط: إذا كانت نوافذ الطرفية وأسماء الفروع وقائمة المهام العادية كافية، فـXirp مجرد طبقة إضافية. إذا كان عدة وكلاء يعملون في worktrees منفصلة وتضيع الصورة العامة، فإن التطبيق يعالج مشكلة حقيقية.

البدء والحدود الحالية

تقدم Spotify تنزيلات Xirp لأجهزة Mac بمعالجات Apple silicon وIntel، إضافة إلى سكربت تثبيت للطرفية. وكما مع أي مثبت curl | sh، ينبغي فحص السكربت قبل تشغيله أو استخدام تنزيل التطبيق المباشر.

الخطوات الرئيسية بعد التثبيت واضحة:

1. إنشاء حساب Spotify Technology ببريد عمل.
2. تثبيت CLI للوكلاء المطلوبين وتسجيل الدخول وضبط الأذونات بشكل منفصل.
3. تسجيل مشروع محلي في Xirp.
4. استخدام worktree جديد بدلًا من checkout الرئيسي لأول مهمة فعلية.
5. وصف الهدف ومعايير الإكمال بوضوح.
6. مراجعة التغييرات وtranscript قبل الدمج أو الرفع إلى Portal.

لا تزال للنسخة التجريبية حدود واضحة. لا يعمل Xirp على Windows أو Linux، ولا يوجد وضع خادم أو استضافة جلسات بعيدة عبر SSH. لا يدعم رفع transcripts تلقائيًا، بل تُشارك جلسات Workspace المؤهلة يدويًا. وقد تتغير الواجهة والسلوك بسرعة.

تعرض صفحة المنتج وصولًا تجريبيًا وتجربة مجانية لـPortal. لا يشكل ذلك وعدًا بمنتج مجاني دائمًا ولا معلومات عن أسعار الفرق مستقبلًا. يجب حساب اشتراكات النماذج وترخيص Portal والإدارة والمراجعة والتعامل مع الجلسات المحفوظة.

أساس المقال وحدوده

لم أختبر Xirp في بيئة إنتاج متعددة الوكلاء. تعتمد الوظائف ومعلومات الأمان على الوثائق الرسمية وFAQ وصفحة المنتج ومقال Spotify، وقد راجعتها في 25 أغسطس 2026.

لذلك لا يمكنني تقديم تقييم موثوق للاستقرار أو استهلاك الموارد أو السرعة أو توفير الوقت. وخلال المرحلة التجريبية قد تتغير الواجهة والوكلاء المدعومون ووظائف Portal سريعًا.

خلاصة رأيي

يعالج Xirp مشكلة لا تظهر إلا عندما لا يعود استخدام وكلاء البرمجة فرديًا، بل يصبح متوازيًا. النوافذ الطرفية الدائمة وGit worktree ومؤشرات الحالة وdiff وGrid view ليست أفكارًا ثورية منفردة، لكن جمعها في واجهة مخصصة للوكلاء يمكن أن ينظم العمل اليومي بوضوح.

الطموح الأكبر يكمن في الاتصال بـSpotify Portal. إذا جرى تحديث الخدمات والملكية والقرارات المعمارية والجلسات السابقة فعليًا، وكانت متاحة عند الحاجة، فلن يبدأ الوكيل من الصفر كل مرة. وهذا أهم من إضافة محدد نماذج آخر.

تكمن المخاطر أيضًا في هذا الاتصال. قد يكشف transcript كاملًا أكثر بكثير من commit. ولا يمنع worktree أوامر shell خطرة. كما لا يوضح المشروع المحلي البيانات التي يرسلها الوكيل إلى مزود النموذج.

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

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

يحاول كثير من المزودين ومشاريع open source حل مشكلة التنسيق الجديدة هذه. Xirp نهج، وBuzz نهج آخر يهدف إلى جمع الأشخاص وعدة مشاريع وعدة وكلاء في مساحة واحدة. كتبت مؤخرًا بمزيد من التفصيل عن فكرة Buzz ومساحة العمل المشتركة.

بالنسبة إلى مطور فردي بجلسة واحدة، تظل CLI الأصلية غالبًا الطريق الأبسط. أما من ينسق عدة وكلاء وفروع ومشاريع بالتوازي على Mac، فعليه مراقبة Xirp. ليس لأن Spotify بنى وكيلًا أفضل، بل لأن تنسيق الوكلاء الحاليين أصبح مشكلة أدوات مستقلة.

إلى اللقاء في المرة القادمة،
Joe

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