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

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

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

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

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

تأتي تاليًا سبعة ضوابط. كل ضابط وُلد من فشل محدد، وكلها تواجه الاختبار نفسه: هل تفرضه الأداة، أم يعيش في الموجّه (prompt) فقط؟ وحيث كتبنا مقالًا كاملًا عن ضابط ما، يتعمق الرابط ويبقى القسم هنا قصيرًا.

1. الهوية: كل وكيل عضو مسمّى

امنح كل وكيل هويته الخاصة في أداة التتبع: اسم، وملف تعريف، وبيانات اعتماد خاصة به. لا حساب "bot" مشترك أبدًا، ولا تسجيل دخول مستعار من إنسان.

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

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

2. وصول محدود النطاق: مفتاح لكل وكيل بحجم مهمته

يحمل كل وكيل مفتاح API خاصًا به، محدودًا بأدنى وصول تحتاجه مهمته، وقابلًا للإلغاء وحده.

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

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

curl -X DELETE "https://taskfolk.ai/api/v1/workspaces/acme/api-keys/KEY_ID" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY"

{ "data": { "id": "KEY_ID", "revoked": true } }

القاعدة العملية: اقرأ بسخاء، واكتب بضيق. المهمة التي تضع التسميات وتعلّق تحصل على مفتاح يضع التسميات ويعلّق.

3. حقوق القرار: الوكلاء يتخذون القرارات الرخيصة، والبشر يتخذون المكلفة

حدّد، صراحةً ومسبقًا، أي الخطوات يجوز للوكيل إتمامها وحده وأيها يتطلب إنسانًا. الصيغة النظيفة سؤالان:

• هل يمكن التراجع عن هذا بسهولة؟
• إذا ساء الأمر، كم يؤلم؟

القابل للتراجع ومنخفض الكلفة من نصيب الوكيل، وغير القابل للتراجع أو عالي الكلفة من نصيب الإنسان.

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

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

4. بوابات مراجعة يفرضها سير العمل نفسه

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

flowchart LR
  A[In progress] --> B[Needs review]
  B --> C{Human checks}
  C -->|approve| D[Done]
  C -->|send back| A
  A -. refused by workflow rules .-> D

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

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

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

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-42/transition",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ status: "done" }),
  },
);

import os, requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-42/transition",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={"status": "done"},
)

إذا كان سير عمل المشروع يقول إن "منجزة" لا تُبلغ إلا عبر "بحاجة إلى مراجعة"، فهذا النداء لا ينجح مصحوبًا بتحذير، بل يفشل:

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

الكتابة تُرفض، لا يُنهى عنها فحسب. الوصفة الكاملة (عمود المراجعة، أتمتة الهبوط فيه، قواعد الانتقال، المفتاح محدود النطاق) في مقال موافقة الإنسان في الحلقة.

5. المراقبة: اعرف ماذا يفعل وكلاؤك الآن

تحتاج إلى رؤية حية لحالة كل وكيل: أيهم يعمل، وأيهم ينتظر إنسانًا، وأيهم سكت.

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

آلية Taskfolk هنا هي الجلسة. كل تشغيل للوكيل يبلّغ عن حالة وملاحظة قصيرة وغالبًا رابط طلب سحب، مثبتة كلها على المهمة المعنية. الحالات تشكّل دورة حياة صغيرة:

stateDiagram-v2
  [*] --> pending: issue assigned
  pending --> running: agent claims it
  running --> needs_input: blocked on a human
  needs_input --> running
  running --> review: PR ready
  review --> done
  running --> failed
  running --> cancelled
  done --> [*]
  failed --> [*]
  cancelled --> [*]

يبقي الوكيل جلسته صادقة بنداء واحد. أي 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", "note": "opened PR #42", "external_url": "https://github.com/acme/web/pull/42"}'

الجلسة العاملة التي تمضي 30 دقيقة بلا نبضة تُعلَّم متوقفة، وهو ما يحوّل الصمت غير المرئي إلى إشارة مرئية تدعوك إلى النظر.

قراءة هذه الإشارات مشروحة في مقال الوكيل العالق؛ وممارستها عبر عدة وكلاء في آن واحد انضباط قائم بذاته.

6. التدقيق: سجل يبقى بعد رحيل الوكيل

كل تغيير يجريه وكيل ينبغي أن يُسجَّل، ويُنسب إلى ذلك الوكيل تحديدًا، ويُحفظ، حتى بعد فصل الوكيل.

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

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

7. دورة الحياة: أدخِل الوكيل بتروٍّ وأخرِجه بالكامل

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

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

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

ما لا تحله حوكمة الأدوات

خطة العمل التي تدّعي الاكتمال لا تستحق الثقة، لذا هذا ما لا تغطيه هذه الضوابط.

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

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

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

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

خط الأساس ليوم الاثنين بعد الظهر

لفريق من خمسة أشخاص، هذا هو الحد الأدنى الذي يصمد، وينجز في عصر يوم واحد.

1. أحل حساب البوت المشترك على التقاعد، واربط كل وكيل عضوًا مسمّى بدلًا منه.
2. أصدر مفتاحًا لكل وكيل بنطاق write دون admin، ودوّن أين يعيش كل مفتاح.
3. أضف عمود "بحاجة إلى مراجعة"، واضبط قواعد الانتقال بحيث لا تُبلغ "منجزة" إلا عبره.
4. اكتب فصل حقوق القرار في صفحة واحدة. السؤالان (قابل للتراجع؟ كم يمكن أن يؤلم؟) يغطيان معظم الحالات.
5. أعط كل وكيل مهمة ضيقة واحدة، محددة النطاق كتجربة أولى، واقرأ سجل النشاط نهاية كل أسبوع خلال الشهر الأول.

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

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