مطوّر يُسكن وكلاء Claude Code وCodex في نتوء MacBook مقابل 0.5% من المعالج

تحوّل ثلاث أو أربع جلسات متوازية من Claude Code وCodex يوم العمل بسرعة إلى تنقل مستمر بين النوافذ: وكيل أنهى مهمته، وآخر ينتظر التأكيد، وثالث توقف عن الاستجابة. قرر صاحب التحليل المنشور على Habr حل هذه المشكلة بتطبيق صغير لنظام macOS. يعرض التطبيق حالات جميع الوكلاء في نتوء MacBook، ويضيء النتوء عندما يحتاج أحدهم إلى تدخل بشري. ويرسم التطبيق كل جلسة على هيئة شخصية صغيرة في مكتب بكسلي. ووفق كلام المؤلف، يستهلك التوهج نحو 0.5% من المعالج.

المشكلة: وكلاء كثيرون ولا توجد لوحة تحكم

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

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

كيف يعمل التطبيق

يعتمد المؤلف مع Claude Code على الخطافات (hooks). وهي آلية تشغّل أوامرك عند أحداث دورة حياة الجلسة، مثل التوقف أو طلب الانتباه. يتلقى التطبيق الإشارة لحظة وقوع الحدث، ولا يستعلم عن العمليات في حلقة متكررة.

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

يتكون الجانب البصري من طبقتين:

• المكتب البكسلي مرسوم باستخدام SpriteKit، وتقابل كل جلسة شخصية صغيرة واحدة؛
• توهج النتوء منفّذ باستخدام Core Animation، وليس عبر إعادة رسم المشهد باستمرار.

ويفسّر البند الثاني رقم 0.5% من CPU. فالرسوم المتحركة التي يديرها نظام التركيب (composition) أرخص من العرض إطاراً بإطار. وهذا مبدأي لتطبيق يبقى مفتوحاً طوال اليوم. فأداة المؤشر يجب ألا تستنزف بنفسها موارد الوكلاء وبيئة التطوير IDE.

المعاملات الرئيسية

• المنصة: macOS، ومنطقة نتوء MacBook.
• Claude Code: تصل الحالات عبر الخطافات (hooks).
• Codex: قراءة السجلات، دون API.
• التصور المرئي: مكتب بكسلي على SpriteKit.
• إشارة الانتظار: توهج على Core Animation، بنحو 0.5% من CPU.
• الإحصاءات: يقول المؤلف إنه يجمعها دون أي عدّاد داخل التطبيق. ويكشف التفاصيل في المقال الكامل.

ما الذي يمكن الاستفادة منه عملياً

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

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

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

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