تشغيل وكيل Codex واحد أمر بسيط. تفتح طرفية، وتصف مهمة، وتراقبه وهو يعمل. لكن المتاعب تبدأ عند ثلاثة. وكيل يعيد هيكلة وحدة المصادقة، وآخر يصلح اختبارًا متذبذبًا، وثالث يصوغ عملية ترحيل، وكل واحد منها في تبويب طرفية خاص به وبسجل تمريره الخاص. وبعد عشر دقائق لا تستطيع تذكّر أي تبويب يحمل أي مهمة، ولا ما إذا كانت عملية الترحيل قد انتهت، ولا على أي فرع استقر إصلاح الاختبار. الوكلاء بخير. ما انهار هو قدرتك على تتبعهم.
هذه هي المشكلة الحقيقية وراء "إدارة عدة وكلاء Codex". ليست المسألة التزامن؛ فـ Codex سيعمل بسرور على التوازي عبر أدلة عمل منفصلة. المشكلة أن حالة ذلك العمل، ما يفعله كل وكيل، وما انتهى، وما فشل، وما يحتاج إلى مراجعتك، تنتهي متناثرة بين تبويبات الطرفية ومجلدات أشجار العمل وذاكرتك أنت. أفقد أحدها فتفقد الخيط.
وُجدت Sharkly تحديدًا لسدّ هذه الفجوة. أنت تملك بالفعل وكلاء برمجة؛ وSharkly تحوّلهم إلى فريق بمنح كل تشغيل وكيل سجلاً مشتركًا واحدًا. تستعرض هذه المقالة الإعداد اليدوي أولاً، لأنك ينبغي أن تفهم ما تقوم بأتمتته، ثم تُبيّن أين تستحق لوحة المهام مكانها. وستنتهي بقائمة تحقق يمكنك تنفيذها اليوم.
ما الذي يعنيه "فقدان القدرة على التتبع" فعلاً
فقدان التتبع ليس أمرًا غامضًا. إنه فشل محدد: حالة عملك بلا موطن واحد. فعندما تشغّل عدة جلسات Codex يدويًا، تتوزع حقيقة كل مهمة على أربعة أماكن في آن واحد. التعليمة تسكن الطرفية التي كتبتها فيها، والتغييرات تسكن دليل عمل Git، والحالة تسكن رأسك، والنتيجة تسكن طلب سحب لم تفتحه بعد. ولا شيء يبقي هذه الأربعة متزامنة. أغلق الطرفية فتختفي التعليمة. بدّل التبويب فتصبح الحالة مجرد تخمين. وكلما أضفت وكلاء، زادت نسخ "ما يجري" التي تحتفظ بها، وأصبحت أنت نقطة التكامل الوحيدة التي تحملها معًا.
إذن هدف إدارة عدة وكلاء Codex ضيّق ويستحق التصريح به بوضوح: إبقاء مهمة كل وكيل وتقدمه وتغييراته وحالة مراجعته في مكان واحد بدلاً من توزيعها على جلسات طرفية خاصة. وكل ما يأتي أدناه يُقاس مقابل هذا الاختبار الواحد.
الخطوة 1: اعزل كل وكيل باستخدام شجرة عمل (worktree)
أول نمط فشل هو التصادم. وجّه وكيلَي Codex إلى المجلد نفسه فيطمس كل منهما تعديلات الآخر، ويهيّئ ملفاته في منطقة التجهيز، وينتج فرقًا لا يستطيع أحد قراءته. أما أشجار عمل Git فتحل هذا بشكل نظيف بمنح كل وكيل نسخته الخاصة من المستودع نفسه، على فرعه الخاص.
# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
الآن ابدأ جلسة Codex واحدة داخل كل دليل. يرى كل وكيل ملفاته فقط، ويرسل التزاماته إلى فرعه فقط، ولا يمكنه أن يطأ على الآخرين.
cd ../repo-auth && codex # agent 1, auth refactor
cd ../repo-flaky && codex # agent 2, flaky test
نمط الفشل الذي يجب تسميته هنا: تحل أشجار العمل تصادمات الملفات، لا مشكلة التتبع. أصبح لديك الآن ثلاثة مجلدات بأسماء شبه متطابقة ولا سجل يذكر أي مهمة يحمل كل منها. اعتمد اصطلاح تسمية يشفّر المهمة (agent/<task>)، لأن repo-2 وrepo-3 لن يعنيا شيئًا بعد أسبوع. وإن أردت التفاصيل التقنية الأعمق، فراجع أشجار عمل Git لوكلاء البرمجة بالذكاء الاصطناعي والنمط الأوسع في تشغيل مهام Codex متعددة في آن واحد.
الخطوة 2: أبقِ الجلسات في مرمى نظرك
ثلاثة وكلاء في ثلاثة تبويبات يعني أنك تفصلك ضغطة Cmd+W بالخطأ عن إنهاء مهمة جارية وفقدان سجل تمريرها. ويعمل مُضاعِف الطرفية مثل tmux على إبقاء كل جلسة حية في نوافذ مسماة يمكنك فصل نفسك عنها وإعادة الالتحاق بها لاحقًا.
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
النوافذ المسماة (auth وflaky وmigration) تعيد الوسم الذي يضيّعه التبويب الخام. افصل بـ Ctrl-b d، وأغلق حاسوبك المحمول، ثم أعد الالتحاق في الصباح، وستجد الجلسات ما زالت هناك.
نمط الفشل الذي يجب تسميته هنا: تُبقي tmux الجلسات عاملة، لكنها لا تخبرك أيها يحتاج إليك. فالوكيل الذي أنهى عمله قبل عشرين دقيقة والوكيل الذي وقع في خطأ يبدوان من الخارج متطابقين: جزء صامت من الشاشة. وما زال عليك زيارة كل نافذة وقراءة آخر مئة سطر لتعرف حالتها. وتنمو كلفة هذا الاستقصاء الدوري مع كل وكيل تضيفه، وهي الضريبة التي تجعل الإعداد اليدوي يبدو أثقل مع مرور الوقت.
الخطوة 3: سجّل الحالة والمراجعة في مكان دائم
الخطوة اليدوية الأخيرة هي التي يتخطاها الناس: تدوين ما أنتجه كل وكيل وما إذا كنت قد قبلته. فسجل تمرير الطرفية ليس سجلاً. إنه يختفي، ولا يمكن البحث فيه عبر المهام، ولا يستطيع زميل قراءته. والنسخة الخفيفة منه قائمة تحقق بسيطة تحدّثها يدويًا.
TASK BRANCH STATUS REVIEW
auth refactor agent/auth-refactor done needs review
flaky test agent/flaky-test running -
db migration agent/db-migration failed: perm not reviewed
هذا هو العمل كله مصغّرًا: مكان دائم يبقى فيه التقدم والعوائق والنتائج والمراجعة البشرية ظاهرة من الطلب حتى الإصدار. حافظ عليه بأمانة وستستطيع إدارة عدة وكلاء من طرفية واحدة لمدة طويلة. لكن المحصلة أن أنت محرّك التزامن، تحدّثه يدويًا كلما تغيّر أي شيء. ولمزيد عن جعل مخرجات الوكلاء قابلة للتدقيق، راجع كيف تتتبع العمل الذي أنجزه وكلاء البرمجة بالذكاء الاصطناعي.
أين يتوقف الإعداد اليدوي عن التوسع
كن صريحًا بشأن اللحظة التي يكفي فيها النهج اليدوي. فمع وكيل أو وكيلَي Codex في مهام محددة النطاق جيدًا، تكون أشجار العمل مع اصطلاح تسمية وملف حالة يُحدّث يدويًا كافية حقًا. لا تضف أدوات لا تحتاجها؛ فالأجزاء المتحركة تقارب الصفر، والأمر كله يتسع في رأسك.
لكن المعادلة تتغير عند نقطة يمكن توقعها. وتشعر بها عندما:
- تشغّل ثلاثة وكلاء أو أكثر، فتأكل كلفة الاستقصاء الدوري (زيارة كل جزء، وقراءة نهايته، وتذكّر الحالة) وقتًا أكثر مما يوفره الوكلاء.
- يمتد العمل على أكثر من مستودع واحد، فتتوقف أشجار العمل وحدها عن تقديم صورة واحدة نظيفة.
- يسألك شخص آخر: "ماذا يفعل الوكلاء الآن؟" فيكون الجواب الصادق الوحيد موجودًا في طرفيتك وذاكرتك.
كل واحد من هذه هو السبب الجذري نفسه الوارد في مستهل المقال: حالة عمل بلا موطن مشترك. ويُبقيها الإعداد اليدوي في المكان الوحيد الذي لا يتوسع، وهو أنت. وتصل الفرق إلى هذا الحائط أسرع من غيرها، ولهذا تتفق أفضل أدوات إدارة وكلاء البرمجة المتوازية بالذكاء الاصطناعي كلها على الخطوة نفسها: منح العمل موطنًا خارج الطرفية.
ما الذي تضيفه لوحة المهام
تغيّر لوحة المهام وحدة الإدارة من "جلسة طرفية" إلى "مهمة". في Sharkly، توصل Computer الذي تشغّل عليه Codex بالفعل، ثم تسند مهمة إلى وكيل Codex بدل الكتابة في جزء طرفية. يعمل الوكيل في شجرة عمله المعزولة، ويعود التنفيذ والتقدم والعوائق والنتائج إلى المهمة. فتتوقف عن الاستقصاء الدوري؛ لأن اللوحة تعرف بالفعل ما انتهى وما فشل.
تقسيم العمل مقصود، ويستحق أن يُذكر كحد فاصل: Sharkly ليست بديلاً عن Codex. فـ Codex ينفّذ، وSharkly تضيف المهمة المشتركة وComputer والسياق وطبقة المراجعة حوله. يبحث الوكلاء وينفذون ويختبرون ويقدّمون تقاريرهم؛ ويحدد البشر الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. وتتوقف الأتمتة حيث يلزم حكمك، أي عند بوابة المراجعة، لا عند الكود.
هذا ما كان ملف الحالة اليدوي يطمح إليه، لكنه صار دائمًا ومشتركًا. وتنتج عنه ثلاثة أشياء لا تستطيع الطرفية منحك إياها:
- حالة بلا استقصاء دوري. تُظهر كل مهمة ما إذا كانت قيد التشغيل أو منتهية أو معطلة أو بحاجة إلى مراجعة، دون أن تزور أي جزء طرفية.
- صورة واحدة عبر المستودعات. تجتمع المهام من مستودعات كثيرة ووكلاء كثيرين في Space واحد، فلا يعني مزيد من الوكلاء مزيدًا من الطرفيات التي ترعى عليها. وهذا هو السبب نفسه الذي يجعل الفرق تشغّل Claude Code وCodex معًا من مكان واحد.
- خطوة مراجعة صامدة. تنتظر النتائج عند بوابة تدخّل بشري في الحلقة مع ملخص التغيير والأدلة المرفقة، فلا يندمج شيء لأنك نسيت أنه معلّق.
يمكنك بناء كل هذا يدويًا بأشجار العمل والانضباط، أو استخدام Sharkly لإدارة سير العمل عندما يرتفع عدد الوكلاء. يبقى Codex كما هو تمامًا؛ وتنتقل الإدارة عن كتفيك. وإن كنت تشغّل بالفعل عدة وكلاء Codex، فهذه هي المشكلة التي صُمّمت Sharkly من أجلها.
قائمة التحقق التي يمكنك تنفيذها اليوم
سواء بقيت يدويًا أو انتقلت إلى لوحة، فهذا هو الحد الأدنى الذي يمنعك من فقدان الخيط:
- [ ] شجرة عمل معزولة واحدة لكل وكيل، على فرع مسمّى بالمهمة، ولا وكيلَين في مجلد واحد أبدًا.
- [ ] اصطلاح تسمية يشفّر المهمة، فيكون
agent/auth-refactorأفضل منrepo-3. - [ ] جلسات طويلة العمر (tmux أو لوحة) تستطيع فصل نفسك عنها وإعادة الالتحاق بها دون إنهاء العمل.
- [ ] سجل حالة دائم خارج سجل تمرير الطرفية: المهمة، الفرع، الحالة، حالة المراجعة.
- [ ] بوابة مراجعة صريحة؛ لا يندمج أي فرع حتى يقبله إنسان.
- [ ] فحص للعدد: عند ثلاثة وكلاء أو أكثر، أو مستودعين أو أكثر، أخرج الحالة من رأسك.
شغّل النسخة اليدوية حتى تصبح ضريبة الاستقصاء مؤلمة. وعندما تصبح كذلك، شغّل وكلاء البرمجة الحاليين لديك عبر Sharkly ليكون التتبع مهمة اللوحة، لا مهمتك.
الأسئلة الشائعة
كم وكيل Codex يمكنني تشغيله فعليًا في آن واحد؟ بقدر ما تسمح به آلتك وحدود المعدل؛ والسقف الذي تصل إليه أولاً بشري عادة، لا تقني. وتتبع ثلاثة أو أكثر يدويًا هو النقطة التي يفقد فيها معظم الناس الخيط. راجع الخيوط المتزامنة والوكلاء الفرعيين في Codex لحدود جانب التنفيذ.
هل تحل لوحة المهام محل Codex؟ لا. فـ Codex ينفّذ؛ واللوحة تدير الإسناد والعزل والسياق والمراجعة حوله. وهما يكملان بعضهما.
