تفويض العمل إلى الوكلاء
يشرح هذا الدليل كيف تسلّم العمل إلى وكيل، وماذا يحدث حين يمرّر الوكلاء العمل بينهم.
تسليم تذكرة إلى وكيل
قسم بعنوان “تسليم تذكرة إلى وكيل”- أنشئ التذكرة بعنوان ووصف دقيقين بما يكفي للعمل منهما.
- اضبط المُسنَد إليه على الوكيل، حتى تُسجَّل الملكية.
- افتح مساحة (أو أنشئ واحدة) وأشِر إلى ذلك الوكيل بـ @.
- أشر إلى التذكرة بعلامة
#في رسالتك — يُكمل حقل الكتابة الاسم تلقائيًا من تذاكر مساحة العمل — وقل ما تريد إنجازه.
يلتقط الوكيل العمل من المحادثة، ويتدفّق تقدّمه إلى تلك المساحة.
ما يتلقاه الوكيل
قسم بعنوان “ما يتلقاه الوكيل”- رسالتك، ومنها إشارة التذكرة التي وضعتها.
- المساحة التي يعمل فيها ويبلّغ.
- شجرة عمل معزولة من المستودعات المرتبطة بمساحة العمل.
- وضع المساحة، وهو ما يحكم سطح أدوات التشغيل.
الوضع خاصية للمساحة لا للتذكرة — لا وضع للتذكرة. لذلك قد يكون الوكيل نفسه في وضع chat في مساحة وفي وضع plan في أخرى. اختره من قائمة الوضع في حقل الكتابة («الوكيل» أو «تخطيط» أو «تنسيق»)؛ review تضبطه مساحات مراجعة طلبات السحب، ولا يُختار. انظر الأوضاع.
اشتراط نتيجة منظَّمة
قسم بعنوان “اشتراط نتيجة منظَّمة”يُعلَن عقد المخرجات على الإرسال لا على التذكرة: expected_output_schema مع output_contract_mode (صارم افتراضيًا). يستوفيه الوكيل باستدعاء submit_output، فيتحقق الاستدعاء من الحمولة وفق المخطط ويرفض ما لا يطابقه.
يُكتَب المخرج المقبول وأي رفض في سجل تشغيل الوكيل. حالة التذكرة نفسها لا تُمَس — فعقد فاشل لا يُفشل التذكرة.
مراقبة التقدّم
قسم بعنوان “مراقبة التقدّم”- المساحة — نشاط الوكيل الحي، وهو العرض الأساسي.
- التذكرة — حالتها، كما يضبطها من ينقلها.
- قابلية الملاحظة ← مباشر (
/workspaces/<workspace-id>/observability) — كشف الوكلاء الحي. - قابلية الملاحظة ← الرؤى — سجل التشغيل، مع التكلفة والمدة.
لا شاشة لوحة؛ عنوان مساحة العمل وحده يُعيد التوجيه إلى الوارد.
تفويض الوكلاء بعضهم إلى بعض
قسم بعنوان “تفويض الوكلاء بعضهم إلى بعض”الوكيل الذي يواجه مشكلة فرعية يفوّض بأداة MCP delegate_task. تنشئ الأداة تذكرة ابنًا مُسنَدة إلى وكيل آخر، و— حين تمرّر parent_ticket_id — تسجّل السلسلة حتى يراها الحراس.
يعمل حارسان بنيويان دائمًا عند نقطة اختناق التذاكر، لا بتعليمات المطالبة:
- سقف العمق — تُرفض سلسلة أعمق من 3 قفزات.
- كشف الدورات — تُرفض قفزة ترجع إلى وكيل موجود أصلًا في السلسلة.
حين تمرّر from_agent_id يعمل حارسان آخران (توصيلات الإنتاج توفّر منفذي الحل دائمًا):
- سقف الاستقلالية — يجب ألا يتجاوز المستوى الفعلي للمفوَّض إليه في المساحة مستوى المفوِّض.
- غلاف الميزانية — يُخصم التفويض من ميزانية الحد الصارم المتبقية لدى المفوِّض، ولا يستحدث ميزانية فوقها. إن غابت السياسة، أو كانت غير محدودة، يمرّ التفويض.
الرفض مسموع: تعيد الأداة سبب الحارس بنصه، فيرى الوكيل المفوِّض السبب كما هو. يسجّل الحقل delegatedByAgentId من فوّض، فتتكون شجرة تفويض.
سقف عمق التفويض هذا، وقدره 3، حد مختلف عن سقف تداخل الوكلاء الفرعيين في الإطار المضمّن، وقدره 2 — أحدهما يحدّ التذاكر بين الوكلاء، والآخر يحدّ الوكلاء الفرعيين داخل تشغيل واحد.
وضع عدة وكلاء على تذكرة واحدة
قسم بعنوان “وضع عدة وكلاء على تذكرة واحدة”أضفهم متعاونين على التذكرة (الأدوار: assignee أو collaborator أو reviewer). هذا كشف — سجل بمن هو معني — ولا يمنح شيئًا بذاته.
ولجمعهم فعلًا في المحادثة نفسها، أضفهم مشاركين من ترويسة المساحة. يستطيعون عندها الإشارة بعضهم إلى بعض بـ @ هناك. انظر استخدام المساحات.
إنشاء التذاكر آليًا
قسم بعنوان “إنشاء التذاكر آليًا”لا عقدة في لوحة خط الأنابيب تنشئ تذاكر، فلا يمكن لخط الأنابيب أن يوزّع العمل كتذاكر مُسنَدة.
المسار القائم فعلًا هو التنسيق: الموافقة على مقترح تنشئ مشروعًا وفريقًا، وتحوّل مخطط DAG للتذاكر الفرعية في المقترح إلى قالب خط أنابيب (خطوة promptAgent واحدة لكل تذكرة فرعية، لا صف Ticket لكل منها)، وتبدأ ذلك التشغيل. انظر تشغيل تنسيق.