إدارة مشروع بوكلاء الذكاء الاصطناعي دون أن تفلت منك الخيوط

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

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

المشروع

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

سنمنح وكيل برمجة (Claude Code في حالتنا) دورًا مقيّدًا على WIDGET وننفّذ الميزة معه، لا من حوله.

الخطوة 1: اربط الوكيل عضوًا حقيقيًا

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

تربط الوكيل من مركز الوكلاء، وهناك يُسك مفتاحه. قاعدتان تضبطهما في هذه المرحلة:

• مفتاح واحد لكل وكيل، وليس تسجيل دخول بشريًا مشتركًا أبدًا. يبقى سجل التغييرات صادقًا، وتستطيع إبطال هذا المفتاح وحده دون إقفال الباب على أحد آخر.
• قائمة سماح للكتابة في الحقول. يتيح لك Taskfolk تحديد حقول المهمة التي يجوز للوكيل الكتابة فيها، لكل وكيل على حدة. دع وكيل WIDGET يضبط الحالة ويضيف الوسوم ويحرّر الأوصاف؛ وامنعه عن المُسند إليه والأولوية إن أردت إبقاءهما قرارًا بشريًا. تُفرض قائمة السماح عند مسار الكتابة الوحيد في الـ API، فتصمد سواء استخدم الوكيل REST أو أدوات MCP.

القاعدة الثانية هي الهادئة التي تمنع وكيلًا قديرًا من الشرود. قراءة على المشروع كله، وكتابة حيث قصدتَ فقط.

الخطوة 2: فوّض أول مهمة مقيّدة النطاق

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

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

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

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

curl -X POST "https://taskfolk.ai/api/v1/workspaces/acme/projects/WIDGET/issues" \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{
    "type": "bug",
    "title": "Form POST returns 500 on empty message",
    "priority": "high",
    "labels": ["widget"]
  }'

import requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/acme/projects/WIDGET/issues",
    headers={"Authorization": "Bearer tfk_live_a1b2..."},
    json={
        "type": "bug",
        "title": "Form POST returns 500 on empty message",
        "priority": "high",
        "labels": ["widget"],
    },
)
issue = res.json()

الرمز في تلك الترويسة هو رمز الوكيل، ولا يحمل إلا النطاقات التي تحتاجها المهمة. أرسل قيمة حقل غير صالحة ويجيب الـ API بخطأ 4xx يستطيع الوكيل قراءته وتصحيحه، بدل أن يكتب سجلًا خاطئًا بصمت.

الخطوة 3: مرّر العمل الأصعب عبر مسار عمل

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

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

flowchart LR
    N[New bug] --> T["Agent: triage + label"]
    T --> C{Regression?}
    C -->|yes| A["Agent: fix on a branch"]
    C -->|no| H[Human prioritizes]
    A --> R[Review]

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

الخطوة 4: راجع بإشارة التحقق

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

حين تقول جلسة إنها قيد المراجعة أو منجزة، ينظر Taskfolk هل ترك الوكيل فعلًا نشاطًا منسوبًا إليه أو تعليقًا على تلك المهمة. فإن ادّعى الإنجاز ولم تُظهر المهمة أي أثر لعمله، حصلت الجلسة على شارة غير موثّقة. تلك الشارة هي طابور مراجعتك: هي الفرق بين «الوكيل يقول إنه أنجز» و«السجل يُظهر أنه فعل شيئًا». ما زلت تقرأ الفروقات، لكنك تقرأ المعلَّمة أولًا.

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

الخطوة 5: الميزة كلها تُقرأ من سجل النشاط

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

ما الذي ينكسر فعلًا

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

التكرارات. يسجّل الوكيل الخطأ نفسه ثلاث مرات حين يعجز عن إيجاد الموجود، فجودة البحث تتحكم مباشرة في كمية الضجيج على اللوحة. السياق المفقود. أعطه آخر تعليقين بدل المهمة كاملة فيجيب عن السؤال الخطأ بثقة تامة؛ أعطه المهمة كاملة وروابطها. القيم المخترعة. سيختلق قيمة حقل ما لم يرفضها الـ API، ولهذا فالتحقق عند الكتابة مع رسالة خطأ واضحة أهم مما يبدو.

أين ينتهي هذا

إدارة مشروع بالوكلاء ليست أتمتة بلا رقيب. هي حلقة WIDGET مكررة: اربط الوكيل عضوًا حقيقيًا، فوّض شريحة واحدة مقيّدة، مرّر المسارات المتكررة عبر مسار عمل، راجع العمل المعلَّم أولًا، واقرأ كل شيء من سجل نشاط واحد. الوكيل يؤدي الـ 80 بالمئة حسنة التعريف. والإنسان يحتفظ بأحكام التقدير وبالالتزامات التي يؤلم الخطأ فيها.

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