كيف تتبع العمل الذي ينجزه وكلاء البرمجة بالذكاء الاصطناعي

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

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

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

باختصار

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

ما الذي يعنيه تتبع العمل المكتمل

التتبع ليس سجلاً للنشاط. إنه القدرة على الإجابة عن ثلاثة أسئلة حول تشغيل منتهٍ دون هندسة عكسية له.

• ما الذي تغيّر. الفرق (diff)، والملفات المتأثرة، وسبب كل منها.
• هل هو صحيح. فحص الأنواع، والاختبارات، والبناء، وملخص لما تحقق منه الوكيل.
• أين استقر. الفرع، وطلب السحب، والمهمة التي ينتمي إليها، ومن يقبله.

الوكيل الذي ينتهي بصمت قد يكون أكمل عمله تقنيًا، لكنك لا تستطيع التصرف بناءً عليه. حالة الاكتمال التي تهمّك هي التي يستطيع إنسان فحصها وقبولها. لهذا السبب ليس «نجحت الاختبارات» هو نفسه «العمل متتبَّع».

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

الإعداد اليدوي خطوة بخطوة، وأين تنكسر كل خطوة

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

الخطوة 1: انظر ما الذي تغيّر. بعد التشغيل، تقرأ الفرق.

git log --oneline -10
git diff main...HEAD --stat

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

الخطوة 2: اعزل عمل كل وكيل. تمنح كل وكيل نسخة عمل git خاصة به حتى لا يتصادما.

git worktree add ../auth-refactor -b auth-refactor
git worktree list

تفشل عندما: تنمو القائمة بما يتجاوز ما يمكنك الاحتفاظ به في ذهنك. يخبرك git worktree list بالمسارات، لا بالوكيل الموجود في كل منها، ولا بالمهمة التي يخدمها، ولا بما إذا كان قد انتهى. راجع وثائق git-worktree الرسمية للتفاصيل التقنية؛ فهي تتوقف عند حدود المحاسبة.

الخطوة 3: تحقق من وصول النتائج إلى طلب سحب. تعتمد على GitHub.

gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup

تفشل عندما: يوجد طلب السحب لكن لم يكتب أحد السبب، أو تكون الفحوصات خضراء بينما التغيير خاطئ، أو لا يرتبط طلب السحب بالطلب الذي بدأه. يوضح مرجع gh pr list طلبات السحب المفتوحة، لا النية.

الخطوة 4: تذكّر ما طلبته. هذه الخطوة ليس لها أمر. المتطلب الأصلي يعيش في رسالة Slack، أو ملاحظة، أو ذاكرتك. عندما تراجع طلب السحب بعد ثلاثة أيام، تكون تخمّن معايير القبول.

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

حيث يتوقف الإعداد اليدوي عن التوسّع

الانكسار ليس لحظة. إنه منحدر، ويمكنك تسمية موقعك عليه.

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

ما الذي تضيفه لوحة المهام

الحل هو التوقف عن التعامل مع التشغيل المكتمل كفرق، والبدء بالتعامل معه كشيء يعود إلى مهمة.

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

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

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

يمكنك تنزيل Sharkly وتوصيل Computer واحد لتجربة هذا على مهمة حقيقية واحدة قبل التوسّع.

متى لا تحتاج إلى أي من هذا

كن صادقًا بشأن العتبة. إذا كنت تشغّل وكيل برمجة واحدًا، في مستودع واحد، وتقرأ كل فرق قبل دمجه، فإن git والطرفية يتتبعان عملك المكتمل بالفعل. ستضيف لوحة المهام طقوسًا لا تحتاجها. يغطي عرض المشروع المدمج في Claude Code قدرًا مدهشًا من الاحتياجات لسير عمل وكيل واحد.

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

قائمة تحقق يمكنك تنفيذها اليوم

قبل إضافة وكيل آخر، تأكد من أنك تستطيع الإجابة بنعم عن كل بند من هذه البنود للوكلاء الذين يعملون بالفعل:

• [ ] لأي تشغيل منتهٍ، هل يمكنك إيجاد الفرق في أقل من دقيقة دون فتح طرفية؟
• [ ] هل يحمل كل تشغيل مكتمل ملخصًا لما تحقق منه الوكيل، لا مجرد فحوصات خضراء؟
• [ ] هل يمكنك تتبع طلب سحب وصولاً إلى المتطلب الذي بدأه؟
• [ ] هل يوجد مكان واحد يعرض أي وكيل يعمل على ماذا، وما انتهى، وما يحتاج إلى مراجعة؟
• [ ] هل يحمل قبول العمل المكتمل اسم شخص ما؟
• [ ] عندما ينتهي وكيل، هل تأتي النتيجة إليك، أم يجب أن تذهب للبحث عنها؟

أي إجابة بـ «لا» هي وصلة ستتسع مع إضافة وكلاء. إصلاحها مبكرًا أرخص من إعادة تركيب أسبوع من التشغيلات غير المتتبَّعة لاحقًا.

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

كيف أتتبع ما غيّره وكيل البرمجة بالذكاء الاصطناعي؟ اقرأ الفرق، لا ملخص الوكيل له. لوكيل واحد، يكفي git diff وطلب السحب. لعدة وكلاء، أبقِ كل تشغيل في نسخة عمله الخاصة ووجّه الفرق مع ملخص التحقق إلى مهمة مشتركة حتى لا تعيد تركيبه من سجل التمرير.

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

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

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