أسندت المهمة إلى وكيل ذكاء اصطناعي ولم يحدث شيء

أسندت WEB-214 إلى وكيل البرمجة لديك عند 09:12. الساعة الآن 11:40. ما زال اسم الوكيل على التذكرة، والعمود لم يتحرك، ولم يُكتب فيها حرف واحد منذ لحظة الحفظ.

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

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

إفصاح: أعمل على Taskfolk، وأحد أقسام هذا المقال عمّا نوفّره وما لا نوفّره. أما الحجة نفسها فليست لنا. سجّلت فرق عدة أجزاءً منها قبلنا، في مواصفات لا يقرؤها أحد جنبًا إلى جنب.

اللوحة لا تفرّق بين منتظِر ومنشغِل

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

ويوثّق Wei Wu الشكل نفسه في دراسة طولية على بيئة تشغيل واحدة لوكيل LLM في الإنتاج، ثمانية أسابيع و22 حادثة مع تقارير ما بعد الحادث (arXiv:2606.14589، قُدّمت في 12 يونيو 2026، تحقّقنا منها في 26 يوليو 2026). وأكبر فئة أعطال فيها ليست استدعاءً سيئًا لنموذج، بل الإغفال التشغيلي، وتعرّفه الورقة في جدولها بأنه «الحالة المعلَنة != الحالة الفعلية»، بصمت يمتد من أيام إلى ستين يومًا. والحادثة النموذجية مهمة مجدولة كُتبت واختُبرت وسُجّلت ونُشرت، ثم لم تعمل قط، لأن كتابة سطر crontab كانت بندًا في ذاكرة إنسان. ثم تأتي الجملة التي ينبغي أن تقلقك: «غياب المهمة لم يُنتج سجلًا يمكن تفحّصه».

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

بطاقة نشاط الوكيل بعد ثوانٍ من الإسناد: جلسة pending تحت اسم الوكيل، ولم يُبلَّغ عن أي عمل بعد.

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

كم كان عليك أن تنتظر؟

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

النظام	الحالة أثناء انتظار الاستلام	مهلة الخروج منها	إن لم يعد شيء
A2A protocol v1.0.0	TASK_STATE_SUBMITTED	لا شيء في المواصفة كلها	غير محدَّد
MCP Tasks extension	لا شيء، وأول حالة هي working	‏ttlMs على كل مقبض مهمة	ينتهي أجل المقبض
Linear agent sessions	‏pending، ومعها حالة stale حقيقية	10 ثوانٍ حتى أول نشاط	تُعلَّم الجلسة غير مستجيبة
Microsoft Planner agent	‏Queued، بمعنى منشغل بغيرها	لا شيء موثّق	غير موثّق
GitHub Copilot coding agent	‏Queued في الواجهة	لا شيء على الطابور، و59 دقيقة على التشغيل	تبقى حيث هي
Hermes subagent delegation	لا شيء، والعمل يبدأ فورًا	‏child_timeout_seconds، معطّل افتراضيًا	timeout_phase: before_first_llm_call
Taskfolk	جلسة pending	30 دقيقة حتى شارة «متوقفة»	تُلغى بعد 7 أيام

كل صف تحقّقنا منه في 26 يوليو 2026 من وثائق النظام نفسه. واقرأ الخط الصغير عند Microsoft: تعني Queued هناك أن العمل مُسند إلى الوكيل لكنه ينفّذ مهمة أخرى الآن، فالحالة تفيد على الأقل أن الوكيل حيّ. أما GitHub فأصرح: توثيقه يحدّ جلسة وكيل Copilot السحابي بـ59 دقيقة تنفيذًا ويسمّي ذلك حدًا صارمًا، بينما لا شيء يحدّ الطابور الذي يسبقها.

وقيمة T أقل أهمية بكثير من وجود قيمة يتولى النظام فحصها، لا أنت.

كل بروتوكول حلّ نصف المشكلة

تعرّف مواصفة A2A الحالة TASK_STATE_SUBMITTED بأنها «تشير إلى أن المهمة قُدِّمت بنجاح وأُقرّ باستلامها»، وتضعها قبل TASK_STATE_WORKING (المواصفة v1.0.0، تحقّقنا منها في 26 يوليو 2026). وهذه بالضبط الحالة التي يدور حولها هذا المقال، وقد اتفق عليها المزوّدون فيما بينهم. الآن ابحث في المواصفة عن مهلة أو TTL أو انتهاء صلاحية. لا وجود لشيء من ذلك. حالة بلا ساعة.

ويفعل امتداد MCP Tasks العكس (تحقّقنا منه في 26 يوليو 2026). جدول دورة الحياة عنده خمس حالات: working وinput_required وcompleted وfailed وcancelled. ولا وجود لحالة pending. فالحالة الأولى هي working، وهي ترميز حرفي للافتراض الذي تقوم عليه لوحتك. ومع ذلك يحمل كل مقبض مهمة (task handle) يعيده قيمة ttlMs وقيمة pollIntervalMs، وتنص المواصفة صراحةً على أن «المهمة تُنشأ بشكل دائم قبل إرسال الرد». ساعة وسجل دائم، بلا حالة إقرار بالاستلام تُعلَّق عليها.

خذ حالة الإقرار بالاستلام من A2A، وخذ الساعة من MCP، تنغلق الثغرة.

stateDiagram-v2
    [*] --> Delegated
    Delegated --> Acknowledged: agent claims the record
    Delegated --> Unacknowledged: no signal by T
    Unacknowledged --> Acknowledged: late claim
    Unacknowledged --> Expired: nobody ever claims it
    Acknowledged --> Working
    Working --> Review
    Working --> Failed
    Review --> Done
    Done --> [*]
    Failed --> [*]
    Expired --> [*]

لم يُسنَد إلى أحد أن ينتبه

نتيجة واحدة في تلك الورقة غيّرت طريقة قراءتي للوحات التحكم عندي. ففي الحوادث الـ22، رُصد نحو 70% من الأعطال الصامتة على يد إنسان ينظر إلى المنتج كمستخدم. أما الاختبارات والتدقيقات فلم ترصد شيئًا يُذكر، وكانت بيئة التشغيل تلك تحمل 4,286 اختبار وحدة و827 فحص حوكمة، كلها خضراء بينما الأعطال جارية. والقاعدة المترتبة على ذلك: يجب ألا يعتمد مسار التنبيه على الطرف المعطوب نفسه. تنبيه «البوابة معطّلة» عندهم مات مع البوابة.

فلا يصح أن يكون الوكيل هو من يخبرك أنه لم يبدأ. لو استطاع إرسال تلك الرسالة لكان يعمل.

وهذا شائع لا نادر. في مسألة multica رقم 4963 (فُتحت في 6 يوليو 2026، تحقّقنا منها في 26 يوليو 2026)، تُظهر لقطة من إحدى مساحات العمل وكيلَ مراجعة بلغت مهامه الملغاة 138 من 523، أي 26.4%، ووكيلَ بناء عند 229 من 794، أي 28.8%. ولم تُنتج تلك الإلغاءات شيئًا: لا إشارة في المنتج ولا تعافي تلقائي. أي أن تفويضًا من كل أربعة تقريبًا بدا تسليمًا ولم يكن كذلك.

ونقاش مجتمع GitHub رقم 188644 (فُتح في 4 مارس 2026، تحقّقنا منه في 26 يوليو 2026) يجمع ستة أشخاص فشل إرسال جلسات Copilot عندهم فبقيت مُعلَّمة Queued، بلا وسيلة لإلغائها. أحدهم يذكر جلسة بقيت في الطابور ثلاثة أشهر. وآخر يكتب أنه «قلق من فاتورة غير متوقعة أو من التهام حصصي حين أستيقظ يومًا ما». ولا ردّ رسمي في السلسلة. فالحالة التي بلا انتهاء صلاحية لا تبقى فارغة، بل تمتلئ بمهملات ما زالت تكلّف مالًا.

قائمة الوكلاء في المركز: صف وكيل يعرض عدد التفويضات المعلَّقة، مع تلميح بأنها أعمال لم يلتقطها بعد.

القاعدة في أربعة سطور

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

ويجب أن تُعرَض هذه الحالة بشكل مختلف عن حالة العمل الجاري. فكل كلفة هذا العطل أن المنتظِر والعامل يتشابهان.

وتسري على السجل مهلة أول إشارة T. فإن لم يصل شيء قبل انقضائها ينقلب السجل إلى «غير مؤكَّد الاستلام»، ويسمع إنسان بذلك من جهة غير الوكيل.

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

sequenceDiagram
    participant H as You
    participant B as Tracker
    participant A as Agent runtime
    H->>B: assign the issue to the agent
    B->>B: mint a pending record with owner and clock
    B->>A: push the assignment event
    Note over A: process is not running
    B->>B: T passes with no claim
    B->>H: flip the record to unacknowledged

ومراكز الاتصال تشغّل السطور الثلاثة الأولى منذ سنوات. فإعدادات التوجيه في Salesforce Omni-Channel تحمل Push Time-Out: كم يبقى عنصر عمل مُوجَّه في وحدة تحكم الموظف قبل أن يُسحب ويُرسل إلى غيره (تحقّقنا منه في 26 يوليو 2026). والنطاق ضيق وصريح في ضيقه. فهذا المؤقّت يحدّ نافذة عدم القبول ولا شيء بعدها.

ما يفعله Taskfolk، وأين يتوقف

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

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

تفويض لم يُستلم ومضى عليه أكثر من ثلاثين دقيقة يحمل شارة «متوقفة» البرتقالية، بجوار جلسة جارية سليمة ليظهر الفرق بينهما.

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

ويوفّر Linear النسخة الأشد من هذا كله. عشر ثوانٍ حتى أول نشاط وإلا عُلِّمت الجلسة غير مستجيبة، وstale واحدة من ست حالات جلسة من الدرجة الأولى، مفروضة عند الإرسال لا مشتقة بعد نصف ساعة.

وإلى أن يلحق منتجنا بذلك، اسأل السؤال بنفسك وفق جدول منتظم:

# needs the agents:read scope
curl -s "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?state=pending" \
  -H "Authorization: Bearer tfk_live_a1b2..."

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?state=pending",
  { headers: { Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}` } },
);
const { data } = await res.json();

import os, requests
r = requests.get(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
    params={"state": "pending"},
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
)

{
  "data": [
    {
      "id": "0198f0c2-7b41-7c0a-9a3e-2f6d8c11ab90",
      "agent_id": "0198e7a1-4d22-7b19-8f55-91c0aa77de31",
      "agent_name": "Claude Code",
      "state": "pending",
      "title": "Fix the theme flash on first paint",
      "issue_key": "WEB-214",
      "started_at": "2026-07-26T09:12:04.000Z",
      "last_activity_at": "2026-07-26T09:12:04.000Z"
    }
  ]
}

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

كيف تطبّق هذا يوم الاثنين، أيًّا كانت أداتك

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

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

ومع أكثر من وكيل، يحفظ الانضباط نفسه سلسلة التسليمات نظيفة، ويوضح تنسيق وكيل فرز ووكيل برمجة ترتيب الخطوات.

ما لا يعالجه هذا

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

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

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