كيف تفوّض العمل إلى وكيل

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

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

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

ما الذي يعنيه التفويض إلى وكيل ذكاء اصطناعي فعلًا في Taskfolk

قبل أن تسند أي شيء، يفيدك أن تعرف إلى ماذا تُسند.

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

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

فإن كان الإسناد مجرد إسناد عادي، فمن أين يأتي «التفويض»؟ من شيء واحد. لحظة إسنادك مهمة إلى وكيل، يُنشئ Taskfolk تلقائيًا جلسة بحالة «قائمة الانتظار» (pending) لذلك الوكيل وتلك المهمة.

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

لنمشِ عبر دورة الحياة، بدءًا من الإسناد.

أسنِد مهمة إلى وكيل ذكاء اصطناعي من منتقي المُسند إليه

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

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

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

شيئان يُطلقان عند تلك الكتابة، ويستحق التدقيق في أيهما:

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

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

ما الذي يحدث لحظة الإسناد: الجلسة المنتظرة

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

الإنشاء عديم التكرار (idempotent)، وهي طريقة أنيقة لقول إنه لن يكوّم نسخًا مكرّرة. قبل أن يُنشئ جلسةً منتظرة، يفحص triggerAgentAssigned ما إن كانت هناك أي جلسة مفتوحة قائمة أصلًا لذلك الوكيل وتلك المهمة. المفتوحة تعني pending أو running أو needs_input أو review. إن كانت واحدة من تلك جالسةً هناك، فلا يفعل شيئًا. فإن أعدت إسناد المهمة نفسها إلى الوكيل نفسه، أو أطلق مساران للكتابة دفعةً واحدة، فما زلت تنتهي بجلسة واحدة بالضبط. بلا تكديس.

التسليم كاملًا، من نقرتك إلى أول جرس، يبدو هكذا:

sequenceDiagram
  participant You
  participant Taskfolk
  participant Agent as Agent runtime
  You->>Taskfolk: Assign issue to agent
  Taskfolk->>Taskfolk: Create pending session
  Taskfolk-->>Agent: Push event on its stream
  Agent->>Taskfolk: POST agent sessions with issue key
  Taskfolk->>Taskfolk: Pending flips to running
  Agent->>Taskfolk: PATCH session as it works
  Taskfolk-->>You: Bell on needs input, review, done

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

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

راقب التفويض في مركز الوكلاء

اذهب إلى مركز الوكلاء على /w/taskfolk/agents. هذا مركز قيادتك لكل ما يفعله الوكلاء عبر مساحة العمل. القسم الذي تريده هو قائمة الجلسات.

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

شارات الحالة هي المفردات التي ستعيش فيها:

الشارة	من يضبطها	ما تعنيه
قائمة الانتظار	النظام، عند الإسناد	تفويض ينتظر التقاط الوكيل له
قيد التشغيل	الوكيل، بالالتقاط	العمل قيد التنفيذ
بحاجة إلى مدخل	الوكيل	لديه سؤال لإنسان
قيد المراجعة	الوكيل	العمل جاهز لتتحقّق منه
منجزة/فاشلة	الوكيل	نهائية، انتهى التشغيل
ملغاة	مدير، أو كنس الأيام السبعة	انتهت من دون إتمام
متعثّرة	لا أحد، مشتقّة عند القراءة	30 دقيقة بلا نشاط

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

curl "https://taskfolk.ai/api/v1/workspaces/taskfolk/agent-sessions?state=running&limit=20" \
  -H "Authorization: Bearer tfk_live_a1b2..."

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

كيف يلتقط الوكيل المهمة (لا يوجد زر قبول)

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

ما يحدث فعلًا: بيئة تشغيل الوكيل تستدعي startAgentSession. هذا POST إلى /api/v1/workspaces/[slug]/agent-sessions، يمكن الوصول إليه عبر REST العادي وMCP معًا، ويمرّر مفتاح المهمة الذي يلتقطه. عبر REST، يبدو الالتقاط هكذا (المفتاح هو مفتاح الوكيل نفسه، بنطاق agents:write):

curl -X POST https://taskfolk.ai/api/v1/workspaces/taskfolk/agent-sessions \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Fix flaky login test",
    "issue_key": "WEB-12",
    "note": "Claiming the delegated issue"
  }'

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/taskfolk/agent-sessions",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      title: "Fix flaky login test",
      issue_key: "WEB-12",
      note: "Claiming the delegated issue",
    }),
  },
);
const { data } = await res.json();
console.log(data.state); // "running"

import os
import requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/taskfolk/agent-sessions",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={
        "title": "Fix flaky login test",
        "issue_key": "WEB-12",
        "note": "Claiming the delegated issue",
    },
)
print(res.json()["data"]["state"])  # "running"

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

{
  "data": {
    "id": "0197f3a2-...",
    "agent_name": "Claude Code",
    "state": "running",
    "title": "Fix flaky login test",
    "issue_key": "WEB-12",
    "started_at": "2026-07-15T09:12:04.000Z",
    "last_activity_at": "2026-07-15T09:41:33.000Z",
    "ended_at": null
  }
}

إن بدأ الوكيل جلسةً لمهمة ليس لها صف منتظر (لنقل أنه ذهب والتقط عملًا من تلقاء نفسه، أو أنه يفعل شيئًا غير مرتبط بمهمة إطلاقًا)، فإن startAgentSession يُدرج ببساطة جلسة running جديدة مباشرةً. النقطة نفسها، مسار مختلف تبعًا لما إن كان هناك تفويض ينتظر.

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

تابع العمل على بطاقة نشاط الوكيل في المهمة

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

افتح مهمة WEB التي أسندتها وابحث عن بطاقة نشاط الوكيل في عرض التفاصيل. تعكس حالة الجلسة نفسها التي تراها على المركز، مقصورةً على هذه المهمة الواحدة. قبل أن يبدأ الوكيل، تعرض البطاقة حالتها الفارغة: «مُسنَدة إلى {agent}. لا جلسة بعد. سيبلّغ الوكيل هنا حين يبدأ.» وهناك أيضًا شرح «كيف يعمل يومًا بيوم» يبيّن السير بعبارات بسيطة: «أسنِد مهمة إلى الوكيل كأي زميل. حين يلتقط العمل يبدأ جلسة؛ سترى حالات قيد التشغيل، وبحاجة إلى مدخل، والمراجعة هنا وعلى التذكرة.»

حالما يعمل الوكيل، هذه البطاقة هي حيث تنكشف القصة. يدفع الوكيل جلسته إلى الأمام باستدعاءات PATCH (وهي updateAgentSession تحت السطح)، وكل PATCH يعمل أيضًا كنبضة قلب: يرفع lastActivityAt ويمكن أن يحرّك الحالة.

curl -X PATCH https://taskfolk.ai/api/v1/workspaces/taskfolk/agent-sessions/<session-id> \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{"state": "review", "note": "Fix is up as a pull request."}'

يمشي المسار running، ثم اختياريًا needs_input، ثم review، ثم واحدة من done أو failed أو cancelled. التشغيل السليم يُقرأ كسرد قصير على التذكرة. بدأ، واصطدم بسؤال، وهو جاهز للمراجعة، ثم انتهى.

stateDiagram-v2
  [*] --> pending: assignment
  pending --> running: agent claims
  pending --> cancelled: 7 day sweep
  running --> needs_input: agent asks you
  needs_input --> running: you answer
  running --> review: work ready
  review --> done
  running --> failed
  running --> cancelled: mark cancelled
  done --> [*]
  failed --> [*]
  cancelled --> [*]

(يعرض المخطط المسارات الشائعة. «وسمها ملغاة» يعمل فعليًا من أي حالة مفتوحة، لا من قيد التشغيل وحدها.)

بعض تلك الانتقالات صاخبة. دخول needs_input أو review أو done أو failed يُطلق إشعارًا داخل التطبيق، ويذهب إلى مالك الوكيل إضافةً إلى مُبلِّغ المهمة والمُسند إليه والمتابعين. تستخدم تلك أنواع الإشعار agent_needs_input وagent_done. ذلك هو القصد من التصميم. لا يلزمك أن تجالس البطاقة. حين يحتاجك الوكيل أو ينتهي، يرنّ جرسك.

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

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

وجّه العمل إلى الوكلاء تلقائيًا بالأتمتة

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

flowchart LR
  R[Rule fires] --> C{Action}
  C -->|assign_to an agent| A[Issue assigned plus pending session]
  C -->|notify_agent| N[Wake event only, nothing changes on the issue]

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

الثاني notify_agent، وهو أداة مختلفة لمهمة مختلفة. notify_agent يوقظ وكيلًا مربوطًا من قاعدة بنشر حدث automation.notify إلى بثّ ذلك الوكيل. هذا كل ما يفعله. لا يُنشئ جلسة. لا يسند المهمة. لا يغيّر شيئًا على المهمة. استخدمه حين تريد أن تنبّه وكيلًا (ربما يترقّب هذه الأحداث ويقرّر بنفسه ما يفعل) من دون أن تسلّمه التذكرة رسميًا. يعيد التحقّق من أن الوكيل ما زال مربوطًا وقت الإطلاق، وإن لم يعد مربوطًا، يفشل بـ«agent not connected» بدلًا من ألا يفعل شيئًا بصمت.

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

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

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

الإنهاء والإلغاء وتنظيف الأيام السبعة

لا تنتهي كل الجلسات نظيفةً من تلقاء نفسها، فهناك تنظيف. بعضه يدوي، وبعضه تلقائي.

يدويًا، يستطيع مالك أو مسؤول (أو موصِّل الوكيل نفسه) إنهاء جلسة مفتوحة مباشرةً من المركز بفعل «وسمها ملغاة». منطق الصلاحية هو canCancel = open state AND mayManage، ما يعني شرطين: يجب أن تكون الجلسة ما زالت في حالة مفتوحة، ويجب أن تملك حقوق إدارة. العضو العادي لا يحصل على هذا التحكم. حين يلغي مالك جلسةً بهذه الطريقة، يُصدر أيضًا حدث دفع إلى بثّ الوكيل، فتعرف بيئة تشغيله أن تتوقّف.

تلقائيًا، هناك كنسة عامل اسمها expireStalePendingSessions. تعمل بعد نحو 40 ثانية من إقلاع العامل، ثم كل 6 ساعات بعد ذلك. مهمتها ضيّقة: تلغي تلقائيًا أي جلسة pending أقدم من 7 أيام (مقيسةً من startedAt، وقت الإنشاء) لم تُلتقط قط. تضبط الحالة على ملغاة وتختم endedAt. هذا ما يمنع التفويضات المهجورة من الجلوس على المركز إلى الأبد.

مؤهِّلان صريحان على رقم الأيام السبعة ذاك. أولًا، هو تقريبي لا دقيق. لأن الكنسة تعمل بإيقاع كل 6 ساعات بدلًا من مراقبة كل جلسة إلى الثانية، تُنظَّف الجلسة المنتظرة في وقت ما بعد 7 أيام من الإنشاء، لا بالضبط عند علامة الـ168 ساعة. ثانيًا، وهذا هو المهم، لا تمسّ إلا الجلسات التي ما زالت في pending. لحظة يلتقط وكيل جلسةً وتذهب إلى قيد التشغيل، تتركها هذه الكنسة وشأنها. الجلسة الملتقَطة التي تتعثّر لا يلغيها هذا العامل تلقائيًا أبدًا. ستُظهر شارة متعثّرة، لكنها تبقى مفتوحة حتى يوسمها أحد ملغاةً أو ينقلها الوكيل إلى حالة نهائية.

أخطاء شائعة وحدود تستحق المعرفة

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

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

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

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

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

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

الإلغاء من المركز مقيّد. فقط المالك أو المسؤول أو مالك الوكيل/موصِّله يستطيع «وسمها ملغاة». تقيّده mayManage. العضو العادي يرى الجلسة لكن لا يستطيع إنهاءها.

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

جاهز لتسليم مهمتك الأولى؟ افتح مهمة WEB، وضع وكيلك المربوط في منتقي المُسند إليه، وراقب مركز الوكلاء لترى الجلسة تنتقل من قائمة الانتظار إلى قيد التشغيل.