كيف تحدد نطاق أول مهمة لوكيل الذكاء الاصطناعي كي لا تموت التجربة

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

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

الطرق الثلاث التي يقتل بها النطاق التجربة

النطاق السيئ يفشل بواحدة من ثلاث طرق، ومن المفيد أن تسمي الطريقة التي أنت على وشك الوقوع فيها.

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

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

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

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

كيف تبدو المهمة الأولى الجيدة

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

ضيقة. مهمة واحدة، لا سير عمل كامل. تستطيع وصفها في جملة واحدة من دون حرف العطف "و".

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

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

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

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

البوابات الخمس، بترتيب تطبيقها:

flowchart TD
    J["A candidate first job"] --> N{"Narrow: one task, no 'and'?"}
    N -->|yes| R{"Repetitive enough to build evidence?"}
    R -->|yes| C{"Checkable at a glance?"}
    C -->|yes| V{"Reversible in seconds?"}
    V -->|yes| DC{"Clear done-condition?"}
    DC -->|yes| G["Run the pilot"]
    N -->|no| K["Keep looking"]
    R -->|no| K
    C -->|no| K
    V -->|no| K
    DC -->|no| K

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

ثلاث مهام تنطبق عليها الشروط

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

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

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

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

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

تثبيت النطاق داخل Taskfolk

بعد اختيار المهمة، يصبح معظم ضبط نطاقها عملًا آليًا. إليك كيف تقع القطع في مكانها داخل Taskfolk تحديدًا.

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

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

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

راقبه عبر جلسته. حين يعمل وكيل Taskfolk، يبلّغ عن جلسة لها حالة: قيد التشغيل، بحاجة إلى مدخلات، مراجعة، منجزة. تظهر تلك الجلسة على Agent Hub وعلى المهمة نفسها، فمراقبة التجربة ليست مشروع مراقبة منفصلًا، بل مجرد نظرة إلى اللوحة.

دورة الحياة الكاملة، بما فيها مخارج الفشل:

stateDiagram-v2
    [*] --> pending: created by delegation
    [*] --> running: agent starts a session
    pending --> running: agent claims the work
    running --> needs_input: waiting on a human
    needs_input --> running: unblocked
    running --> review: output ready to check
    review --> done
    running --> failed
    running --> cancelled
    done --> [*]
    failed --> [*]
    cancelled --> [*]

إن كنت توصّل الوكيل بنفسك، فالإبلاغ عن جلسة هو نداء واحد إلى واجهة API العامة. يبدؤها الوكيل حين يلتقط العمل:

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": "Triage new bug reports", "issue_key": "WEB-12"}'

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: "Triage new bug reports", issue_key: "WEB-12" }),
});
const { data: session } = await res.json();

import requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
    headers={"Authorization": f"Bearer {TASKFOLK_API_KEY}"},
    json={"title": "Triage new bug reports", "issue_key": "WEB-12"},
)
session = res.json()["data"]

وحين تصبح المخرجات جاهزة لعين بشرية، يحدّث الوكيل الجلسة نفسها. وكل تحديث يعمل أيضًا كنبضة حياة:

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", "note": "Labeled and routed. Ready for a look."}'

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

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

الجزء الصريح

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

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

إن أردت أن تجرب، اربط وكيلًا من Agent Hub، أعطه مفتاحًا قراءته أوسع من كتابته، وصوّبه نحو عمود واحد أو نوع مهام واحد مع تعريف محدد لكلمة "انتهى". اختر أضيق مهمة تحتملها، راقب جلساتها أسبوعًا أو أسبوعين، ولا توسّع النطاق إلا بعد أن تتوقف عن التحقق من عملها.