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

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

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

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

الفكرة: اللوحة هي طابور الموافقة

لا تحتاج صندوق موافقة منفصلًا إن كان للوحتك أصلًا عمود يعني "بانتظار إنسان". فاصنع واحدًا.

على أيّ لوحة في Taskfolk، الحالات أعمدتك أنت، لا مجموعة ثابتة. يرتبط كل عمود بفئة (قائمة الانتظار، للتنفيذ، قيد التنفيذ، قيد المراجعة، منجزة، واثنتان طرفيّتان) تقود التقارير وعلامة المفتوح/المغلق، لكنّ الاسم واللون لك. أضِف عمودًا باسم "بحاجة لمراجعة". ذلك العمود هو طابور الموافقة. أيّ شيء جالس فيه هو شيء فعله الوكيل ولم يوقّع عليه إنسان بعد.

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

البوّابة في صورة واحدة:

flowchart TD
    A["Agent prepares the work"] -->|"the agent's last move"| NR["Needs review"]
    NR -->|"human: fine, do it"| IP["In progress"]
    NR -->|"human: not now"| B[Backlog]
    NR -->|"human: wrong call"| RJ["Rejected / Won't do"]

الخطوة الأولى: دع الوكيل يهبط في "بحاجة لمراجعة"، لا في تدفّقك الحيّ

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

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

طريقتان لتحقيق ذلك، واستخدام كلتيهما مقبول.

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

curl https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/statuses \
  -H "Authorization: Bearer tfk_live_a1b2..."

تُدرِج الاستجابة كل عمود على اللوحة، بالترتيب، بإعدادات سير عمله:

{
  "data": [
    {
      "id": "0197a3c2-8f1e-7c3a-b2d4-5e6f7a8b9c0d",
      "name": "Needs review",
      "category": "in_review",
      "allowed_transitions": null,
      "wip_limit": null
    }
  ]
}

ثم سجّل المهمّة بذلك الـ status_id، فتهبط في البوّابة ولا مكان سواها. إليك الإنشاء نفسه بـ curl وJavaScript وPython:

curl -X POST https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/issues \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{
    "type": "bug",
    "title": "Checkout 500 when the cart has a deleted SKU",
    "description_md": "Steps to reproduce: ...",
    "priority": "high",
    "status_id": "0197a3c2-8f1e-7c3a-b2d4-5e6f7a8b9c0d"
  }'

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/issues",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      type: "bug",
      title: "Checkout 500 when the cart has a deleted SKU",
      description_md: "Steps to reproduce: ...",
      priority: "high",
      status_id: needsReviewId,
    }),
  },
);
const { data: issue } = await res.json(); // 201, issue.key is e.g. WEB-142

import os
import requests

r = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/issues",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={
        "type": "bug",
        "title": "Checkout 500 when the cart has a deleted SKU",
        "description_md": "Steps to reproduce: ...",
        "priority": "high",
        "status_id": needs_review_id,
    },
)
r.raise_for_status()
issue = r.json()["data"]

بسيط، لكنه يعتمد على اتّباع الوكيل للتعليمات، وهو بالضبط الشيء الذي تحاول ألّا تثق به عمياءً.

الطريقة الموثوقة قاعدة أتمتة تفرض ذلك بغضّ النظر عمّا قصده الوكيل. تتّبع أتمتة Taskfolk شكلًا بسيطًا: عند إطلاق مُشغِّل، إن طابقت شروطٌ ما، فنفّذ إجراءاتٍ ما. المُشغِّلان المهمّان هنا issue.created وissue.status_changed. تبدو قاعدة الهبوط هكذا:

• عند إنشاء مهمّة
• إن كان المُبلِّغ هو الوكيل (طابق على المُسند إليه أو الوسم أو اصطلاح تسمية تتحكّم به)
• فاضبط حالتها إلى "بحاجة لمراجعة"

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

يمكنك أيضًا استخدام الأتمتة للقيام بالورق الذي سيلاحقه إنسان لولاها: أضِف وسم "needs-review"، وأسقط تعليقًا بقالب يقول ما غيّره الوكيل، وأسنِدها إلى من يتولّى الفرز ذلك الأسبوع. تدعم أجسام تعليقات الأتمتة العناصر النائبة {issue} و{assignee} و{actor}، فتستطيع الملاحظة تسمية الوكيل الذي تصرّف.

الخطوة الثانية: وافِق بنقل البطاقة

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

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

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

الخطوة الثالثة: امنع الوكيل من تخطّي البوّابة

التعليمات وقاعدة الهبوط تُوصلانك معظم الطريق. قواعد الانتقال تُغلق الفجوة الأخيرة.

يدعم Taskfolk انتقالات حالة على نمط Jira. افتراضيًا أيّ عمود يستطيع الانتقال إلى أيّ عمود آخر، وهو الافتراض المعقول لفريق صغير. لكن كل حالة تستطيع حمل قائمة allowed_transitions (تلك الـ null التي رأيتها في استجابة الحالات أعلاه، ومعناها "اسمح بالكلّ"): مجموعة الأعمدة المسموح للعمل بالانتقال إليها من هناك. اضبطها، فأيّ نقلة ليست في القائمة تُرفَض.

شاهدها تحدث. يحاول الوكيل قفز تذكرته مباشرةً إلى منجزة:

curl -X POST https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/issues/WEB-142/transition \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{"status": "done"}'

وتجيب الـ API بـ 400، لا ببطاقة منقولة:

{
  "error": {
    "code": "validation",
    "message": "Workflow blocks this transition: \"Needs review\" cannot move to \"Done\".",
    "details": {
      "code": "workflow_transition_blocked",
      "from": "Needs review",
      "to": "Done"
    }
  }
}

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

sequenceDiagram
    participant Agent
    participant API as Taskfolk API
    participant Human
    Agent->>API: create issue in Needs review
    API-->>Agent: 201 created
    Agent->>API: transition to Done
    API-->>Agent: 400 workflow blocks this transition
    Human->>API: drag card to In progress
    API-->>Human: move recorded in activity

اقرن ذلك بحدود WIP لكل عمود إن أردت سقفًا صارمًا لكم يستطيع الوكيل تكديسه بانتظار إنسان.

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

الخطوة الرابعة: احصر المفتاح فيصغر نطاق الضرر

الطبقة الأخيرة مفتاح API. لا تُسلّم وكيلًا مفتاحًا فضفاضًا أبدًا.

مفاتيح Taskfolk محصورة النطاق، والنطاقات تضيق فقط، ولا تتّسع أبدًا فوق دور من صكّ المفتاح. لوكيل فرز واقتراح، issues:write مع issues:read تكفي عادةً: يستطيع إنشاء المهام، وتعديل الحقول، ونقلها بين الأعمدة، لكنه لا يلمس إعدادات المشروع، ولا يدير الأعضاء، ولا يحذف مشروعًا.

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

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

أين الفواصل

هذا مُركَّب لا مُشترى، فله فواصل تستحقّ التسمية.

لا توجد لوحة تحكم واحدة لـ "الموافقات المعلَّقة" تتجاوز عرضًا محفوظًا لعمود "بحاجة لمراجعة". ذلك العرض يكفي بصدق لمعظم الفرق، لكنه لوحة مُرشَّحة، لا طابور مبنيّ لغرضه بموافقة جماعية.

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

والتنفيذ على اللوحة، لا على نيّة الفاعل. البوّابة تمنع نقلة سيّئة؛ لا تقرأ عقل الوكيل. تلك ميزة إن عاملت اللوحة مصدرًا للحقيقة، وينبغي أن تفعل.

لماذا تركّبها هكذا

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

النتيجة هي الانقسام الذي يظلّ يعمل بعد العرض التوضيحي: يقوم الوكيل بالـ 80 بالمئة المتكرّرة القابلة للفحص ويهبطها عند البوّابة. ويقضي شخصٌ ثلاثين ثانية في نقل بطاقة ويملك القرار الذي حمل المخاطرة.

إن أردت بناء هذا، ابدأ بعمود واحد وقاعدة أتمتة واحدة على issue.created، ووجّه مفتاحًا محصورًا إلى مشروع واحد، وراقب مسار "بحاجة لمراجعة" أسبوعًا قبل أن توسّع أيّ شيء. انظر مرجع الـ API لنقاط النهاية، أو اقرأ تشغيل مشروع بوكلاء الذكاء الاصطناعي للإعداد الأوسع الذي يندرج فيه هذا.