إدارة مهام وكلاء الذكاء الاصطناعي: حلقة الحجز عقدٌ لا موجّه

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

نحن من يصنع Weft. والمعلومات عن المنتجات الأخرى مأخوذة من صفحاتها الرسمية، وقد راجعناها في 27 أكتوبر 2026.

لماذا تتوقف قائمة المهام الملصوقة في المحادثة عن العمل؟

لصق المهام في محادثة أول ما يجرّبه الجميع، وهو ينجح لعصر يوم واحد. ثم تنتهي المحادثة، وتنتهي الحالة معها. كان الوكيل يعرف أي بند أنهاه، وأيها تخلّى عنه، وما الذي لم يكن متأكدًا منه. والآن لا أحد يعرف.

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

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

كيف تبدو حلقة الحجز بوصفها عقدًا؟

في Weft للحلقة خمس خطوات، وكل واحدة أداة منفصلة على نقطة نهاية MCP واحدة، https://letsweft.com/api/mcp. ويحفظ الخادم الحالة بينها، فتعيش الحلقة بعد انتهاء أي محادثة.

1. get_my_work: اسأل قبل أن تختار. يغطي الجواب ما يحمله هذا العميل أصلًا، وما ينتظر الشخص، وما تأخّر أو اقترب موعده، وهل هناك متسع لبدء أي شيء أصلًا.
2. start_task: الحجز بعقد إيجار. يدوم الحجز 20 دقيقة وينقل المهمة إلى Doing. وتحمل الاستجابة runId وleaseToken وrenewEverySeconds: 300. والعميل الثاني الذي يحاول المهمة نفسها يتلقّى already_claimed وتلميحًا بألا يكرّر العمل.
3. report_progress: النبضة. كل استدعاء بمعرّف التشغيل ورمز العقد يجدّد العقد. وإن مات الوكيل توقفت النبضات، وبعد 20 دقيقة يُعلَّم التشغيل بأنه خامد وتعود المهمة غير مسندة ليأخذها أيٌّ كان. والعقد المفقود يجيب بـ lease_lost، فيعرف الوكيل أنه لم يعد يملك العمل.
4. request_input: للقرارات التي تخص الشخص فقط. سؤال حتى 500 حرف، مع ما يصل إلى 10 خيارات. ويبقى الحجز قائمًا ريثما ينتظر الوكيل.
5. complete_task: الإنهاء بإيصال. outcome وartifacts (أدلة مثل رابط أو إيداع أو بصمة ملف) وnotDone وunknowns وnextStep.

لماذا عقد إيجار لا حالة؟ لأن الصمت هو الإشارة الوحيدة التي يستطيع وكيل متعطّل إرسالها. فالبطاقة في Doing تقول إن أحدًا كان يعمل عليها ذات مرة. أما عقد الإيجار فيقول إن أحدًا يعمل عليها الآن، ويكفّ عن قول ذلك من تلقاء نفسه حين لا يعود صحيحًا.

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

متى ينبغي أن يستدعي الوكيل request_input؟

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

وهذا التحفّظ مهم لأن السؤال يكلّف الشخص الانتباه نفسه الذي تكلّفه مهمة منجزة، وفي Weft يُحسب ضمن الحد نفسه. يصل السؤال إلى صندوق الوارد، مع إشعار على الهاتف، ومع تذكير بالبريد الإلكتروني للبنود التي تنتظر 20 دقيقة أو أكثر. ولا يتصل Weft بالوكيل أبدًا: يصله الجواب عند استدعائه التالي لـ start_task أو get_my_work. وما دام السؤال مفتوحًا يحتفظ الوكيل بالمهمة 60 دقيقة؛ وبعدها يسقط العقد لكن السؤال يبقى.

ماذا يدخل في استدعاء complete_task؟

نتيجة قصيرة، وأدلة، وعرض صادق للحواف. إليك حمولة واقعية لإصلاح علّة:

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

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

بماذا يختلف هذا عن نقل بطاقة ونشر تعليق؟

دليل Hypertask عن الحلقة نفسها (احجز، حدّث، أبلغ، أغلق) وصف جيد للعادة. ونسخته من الحجز عبر MCP هي تحميل المهمة، ونقلها إلى قسم العمل، ونشر تعليق حجز، بتوجيه من موجّه يكتبه الفريق في تعليمات الوكيل. إليك الحلقة نفسها خطوة خطوة:

وإنصافًا لـ Hypertask: لديه عقود إيجار حقيقية. فوثائقه تسرد نقاطًا لحجز العقد والنبضة والتحرير، وجدول القيود المعروفة لديه يقول إن عقود إيجار المهام والأدلة والتصعيد نقاط REST فقط، عن قصد (نظرة عامة على MCP في Hypertask). ولا يضم مرجع أدواته أداة عقد إيجار بين أدوات MCP الـ21 (مرجع الأدوات). وتستطيع CLI لديه الحجز أيضًا، بأمر اختياري (سجل التغييرات، مرجع CLI). فالوكيل المكتوب كسكربت على Hypertask يستطيع حمل عقد إيجار؛ أما الوكيل الذي يعمل عبر MCP في Claude Code أو Cursor فيحصل على نسخة البطاقة والتعليق ما لم يوصل أحدٌ استدعاءات REST.

وإن كان وكلاؤك يعملون سكربتاتٍ ومهامَّ CI، فإن CLI وREST API لدى Hypertask ميزة حقيقية، وليس لدى Weft أيٌّ منهما: لا CLI، ولا REST API عامة، ولا webhooks. ‏Weft للوكلاء الذين يعيشون داخل عميل MCP ويحتاجون إلى أن تصمد الحلقة هناك.

ماذا يرى الشخص؟

في معظم الأحيان، بطاقة في Done: فافتراضيًا تذهب المهمة المنجزة إلى هناك مباشرة مرفقةً بنتيجتها وأدلتها.

وتتوقف المهمة في صندوق الوارد لدى الشخص حين تكون معلَّمة بأنها تحتاج إلى مراجعة، أو حين يفشل فحص تحقّق. وهناك يختار الشخص أحد أربعة أجوبة:

• قبول: العمل معتمد. وإن مرّر الوكيل nextStep، يراها الشخص فوق الزر («إن قبلت، فسيقوم الوكيل بـ …»)، والقبول يوافق على تلك الخطوة بالضبط، لا أكثر. وتظل الموافقة صالحة 72 ساعة وتعود إلى الوكيل عبر get_my_work أو start_task.
• إعادة: أرجعها، مع ملاحظة تقول ما الخطأ.
• لاحقًا: ليس الآن. إسقاط: أوقف العمل عليها.

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

لماذا يُرفض الوكيل بدل أن يبدأ مزيدًا من العمل؟

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

يعدّ Weft ما ينتظر الناس: المهام التي تنتظر المراجعة إضافة إلى الأسئلة المفتوحة. وحين يبلغ ذلك 5 عناصر في مساحة عمل لشخص واحد، أو 10 في الفريق، أو نحو 45 دقيقة من وقت المراجعة المقدّر، أيها يأتي أولًا، ترفض start_task بـ attention_queue_full. ويتوقف الحد على عدد الأشخاص في مساحة العمل، لا على الخطة.

والرفض تعليمة، لا طريق مسدود. فهو يبلّغ عن حجم الطابور، وعمر أقدم بند، والاستدعاءات التي ما زالت مسموحة: report_progress وget_my_work وget_board_state وsearch. والخطوة التي وافق عليها الشخص أصلًا على تلك البطاقة مستثناة، فلا يحجب الطابورُ «دمج PR #418» المقبول.

كيف أُعدّ هذا؟

صِل عميلك وسجّل الدخول عبر المتصفح؛ لا مفتاح تنسخه. ويُصدر Weft رموز تحديث، فيجدّد العميل تسجيل الدخول بنفسه. في Claude Code يكفي أمر واحد، claude mcp add --transport http weft https://letsweft.com/api/mcp (صفحة الإعداد). ولدى Cursor تثبيت بنقرة واحدة (Cursor)، ويحتاج Codex إلى إدخال في الإعداد مع codex mcp login weft (Codex)، ولدى ChatGPT تطبيق Weft منشور على كل الخطط بما فيها المجانية (ChatGPT). والخادم نفسه يصف الحلقة للوكيل، فلا حاجة إلى موجّه لدورة الحياة.

لشرح عملي مع Claude Code انظر لوحة مهام لـ Claude Code. ولعدة وكلاء على لوحة واحدة، حيث تهمّ عقود الإيجار وalready_claimed أكثر من أي شيء، انظر عدة وكلاء ذكاء اصطناعي ولوحة واحدة. والبروتوكول نفسه موثّق على modelcontextprotocol.io، ولوحات MCP الأخرى مقارنة في مديري المهام عبر MCP.

ما الذي لا يفعله Weft هنا؟

• لا CLI ولا REST API عامة ولا webhooks، فلا تستطيع مهام cron وخطوط CI تشغيل الحلقة خارج عميل MCP.
• لا تكامل مع GitHub أو Slack. فالأدلة هي ما يربطه الوكيل في artifacts.
• لا ذكاء اصطناعي مدمج. فالتفكير يجري في عميل الذكاء الاصطناعي الخاص بك، ولهذا أيضًا لا يحتاج Weft إلى أرصدة ذكاء اصطناعي.

تغطي الخطة المجانية 50 مهمة و200 استدعاء للذكاء الاصطناعي شهريًا. وPro بسعر $7 للمقعد شهريًا أو $60 للمقعد سنويًا (الأسعار).

أليس الموجّه الجيد كافيًا ليتبع الوكلاء الحلقة؟

الموجّه يصف الحلقة؛ لكنه لا يستطيع فرضها. فهو لا يمنع وكيلين من حجز المهمة نفسها، ولا يستطيع تحرير مهمة يحملها وكيل تعطّل. في Weft الحجز عقد إيجار يملكه الخادم، فتُعالَج هذه الحالات سواء تذكّر الوكيل تعليماته أم لا.

ماذا يحدث إن تعطّل وكيلي في منتصف الطريق؟

تتوقف نبضاته. وبعد عشرين دقيقة من آخر report_progress يُعلَّم التشغيل بأنه خامد، ويُمسح رمز العقد، وتعود المهمة غير مسندة، فيستطيع وكيل آخر أو شخص أخذها. ولا تبقى البطاقة في Doing أسبوعًا.

هل تنتظر كل مهمة منجزة أن أراجعها؟

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

لماذا قد أريد أن يُرفض العمل لوكيلي؟

لأنه بخلاف ذلك يواصل إنتاج أشياء لا وقت لديك للتحقق منها. فحين ينتظر الناسَ 5 عناصر (10 للفريق) أو نحو 45 دقيقة من المراجعة، تُعيد start_task ‏attention_queue_full وتوجّه الوكيل إلى ما يستطيع فعله بعد. وإفراغ الطابور يرفع الحجب.

لدى Hypertask عقود إيجار أيضًا. فلماذا يهم MCP؟

عقود الإيجار في Hypertask نقاط REST، بحسب وثائقه نفسها (نظرة عامة على MCP)، وتستطيع CLI لديه الحجز كذلك. وهذا يناسب الوكلاء المكتوبين كسكربتات. أما الوكيل الذي يعمل عبر أدوات MCP في محرّر أو محادثة فلا يحصل عليها هناك، وفي Weft يحصل عليها: فـ start_task وreport_progress وcomplete_task أدوات MCP.