أهّل وكيل الذكاء الاصطناعي كما تؤهّل موظفًا جديدًا: هوية وصلاحيات ومهمة أولى

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

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

امنحه هوية، لا مجرد مفتاح

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

في Taskfolk، الوكيل عضو حقيقي في مساحة العمل. افتح Agent Hub، واضغط Connect agent، واختر مزوّدًا (Claude Code أو Codex أو Cursor أو Copilot أو Gemini وغيرها، أو مزوّدًا مخصصًا عامًا)، وأعطه اسمًا بين 2 و60 حرفًا. هذا هو مقابل البطاقة والمكتب.

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

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

امنحه الصلاحيات الصحيحة: قراءة واسعة وكتابة ضيقة

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

عند ربط وكيل، يُصدر Taskfolk مفتاح API يُعرض مرة واحدة فقط، بنطاق write على مستوى العضو. القراءة الواسعة والكتابة الضيقة هي الفلسفة كلها. نطاق write يمنح كتابة بمستوى العضو لا أكثر، أما admin الذي يمنح كل شيء فمعزول عمدًا عن write العادي حتى لا تسلّمه بالخطأ. وهناك نطاقات خاصة بالوكلاء أيضًا (agents:read وagents:write)، وإذا كان عميلك يفضّل ذلك، يعمل OAuth 2.0 مع PKCE والتسجيل الديناميكي للعملاء كذلك.

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

بعد ذلك يصل الوكيل إلى المنتج عبر الباب الذي يناسبه:

• خادم MCP رسمي على /api/mcp/v1، تُولَّد فيه أداة لكل عملية REST وتُرشَّح الأدوات حسب نطاقات المفتاح، فالمفتاح المقصور على القراءة لا يرى أدوات الكتابة أصلًا.
• REST API تحته، وهو الأنسب للسكربتات ومهام cron.
• مهارة وكيل لـ Claude Code أو Codex، تأتي بملف خاص بكل مساحة عمل يسرد مشاريعك وتسمياتك وأعضاءك وحقولك المخصصة، فيبدأ الوكيل على أرض صلبة بدل التخمين.

ربط Claude Code بخادم MCP أمر واحد:

claude mcp add taskfolk-product \
  https://taskfolk.ai/api/mcp/v1 \
  --header "Authorization: Bearer $TASKFOLK_API_KEY"

تثبيت المهارة بالشكل نفسه، أمر curl واحد. وهذه نسخة Codex:

mkdir -p ~/.codex/skills/taskfolk-product
curl -fsSL "https://taskfolk.ai/api/skill/taskfolk-product.skill.md?workspace=acme" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  -o ~/.codex/skills/taskfolk-product/SKILL.md

افتح الأبواب الثلاثة ودع كل وكيل يستخدم ما يناسبه.

قيّد ما يُسمح له بتغييره

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

ملف كل وكيل يحمل قائمة سماح بحقول المهمة التي يجوز لمفتاحه كتابتها: title وdescription وstatus وpriority وassignee وlabels وmilestone وsprint وrelease وestimate وspent وcompletion وstart_at وdue_at. اترك السياسة فارغة فيكتب الوكيل أي حقل، مثله مثل أي شخص. حدد مجموعة جزئية فتصبح كل ما يستطيع تغييره. تضبط ذلك من Agent Hub، لكل وكيل على حدة.

هذا التقييد ليس مجاملة في الواجهة. يجلس عند نقطة الاختناق الوحيدة للكتابة التي يمر بها كل طلب من وكيل: REST واستدعاءات أدوات MCP ونقاط نهاية الانتقالات وتتبع الوقت سواء بسواء، فلا باب خلفيًا. إذا حاول وكيل مقيّد بسياسة كتابة حقل خارج قائمته، يُرفض الطلب برد 403 يسمّي الحقل الممنوع. حدّان صريحان: السياسة على مستوى الحقل لا القيمة (تستطيع السماح بحقل "status" لكن لا تستطيع تثبيته على عمود واحد)، وهي تحكم الكتابة في حقول المهام القائمة لا إنشاء المهام أو حذفها، فهذان يبقيان تحت النطاقات والدور. وهي لا تنطبق إلا على الوكلاء؛ البشر لا تقيّدهم أبدًا.

امنحه السياق اللازم لإنجاز العمل

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

امنحه مهمة أولى صغيرة واحدة

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

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

curl -X POST "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Fix flaky login test",
    "issue_key": "WEB-12",
    "note": "picked up, reproducing locally"
  }'

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/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: "picked up, reproducing locally",
    }),
  },
);
const session = await res.json();

import os
import requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={
        "title": "Fix flaky login test",
        "issue_key": "WEB-12",
        "note": "picked up, reproducing locally",
    },
)
session = res.json()

للجلسة حالة: قيد التشغيل، أو بحاجة إلى مدخلات، أو قيد المراجعة، أو منجزة، أو فاشلة، أو ملغاة. وتحمل عنوانًا وملاحظة (سطر حالة بسيط مثل "متوقف بانتظار متغير بيئة") ورابطًا خارجيًا يكون عمليًا رابط طلب سحب في الغالب. ويمكن ربطها بمهمة محددة مثل WEB-12 ومشروعها، أو تشغيلها على مستوى مساحة العمل.

stateDiagram-v2
    [*] --> running
    running --> needs_input: agent asks
    needs_input --> running: human answers
    running --> review: work ready
    review --> done
    running --> failed
    running --> cancelled
    done --> [*]
    failed --> [*]
    cancelled --> [*]

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

curl -X PATCH "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions/$SESSION_ID" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "review",
    "external_url": "https://github.com/acme/web/pull/311"
  }'

تظهر تلك الجلسات في Agent Hub وعلى المهمة نفسها، فيبقى العمل مرئيًا حيث ينظر بقية الفريق أصلًا.

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

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

راجع العمل، فالسجل أمامك

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

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

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

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

الحلقة كاملة في صورة واحدة:

flowchart TD
    C["Connect: a named agent, a real member"] --> K["Scoped key: read broad, write narrow"]
    K --> T["One small, checkable task"]
    T --> R["Review the attributed trail"]
    R -->|"went well"| W["Widen the leash: next job, then a queue"]
    W --> T
    R -->|"not working out"| O["Disconnect: key revoked, history stays"]

حافظ على مسار خروج نظيف

كل عملية تأهيل جيدة لها خروج بالنظافة نفسها، وهنا يؤتي نموذج "الوكيل عضو حقيقي" ثماره مجددًا. عند فصل وكيل، يُلغى مفتاح API وتُزال عضويته. يفقد القدرة على التصرف فورًا.

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

ما يجب قوله بصراحة

لا شيء من هذا بلا احتكاك، والتظاهر بغير ذلك هو نسخة العرض الدعائي من الحقيقة. الحواف الخشنة اليوم:

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

هذه أمور حقيقية، وهي من النوع الذي تخطط حوله لا الذي تتمنى زواله.

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

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