احتفظ بسجل تدقيق لكل ما يغيّره وكلاء الذكاء الاصطناعي

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

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

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

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

مشكلة الرمز المشترك

رمز API واحد مشترك بين الوكلاء هو الافتراضي لأنه الأسهل. تصدر مفتاحًا واحدًا، وتلصقه في كل سكربت وكل عميل MCP، فيعمل كل شيء. تمتلئ اللوحة، وتعمل قواعد الأتمتة، ويبدو العرض التوضيحي رائعًا.

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

flowchart TD
    A[Triage agent] --> T[One shared token]
    B[Spec agent] --> T
    C[Review agent] --> T
    T --> L[Activity log]
    L --> Q[Who did this]
    Q --> U[No way to tell]

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

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

امنح كل وكيل هويته الخاصة

في Taskfolk الوكيل عضو حقيقي في مساحة العمل، لا رمز. حين تربط وكيلًا من مركز الوكلاء، تسميه (من 2 إلى 60 حرفًا) وتختار مزوّده، Claude Code أو Codex أو Cursor أو Gemini وحفنة غيرها، أو وكيلًا مخصصًا عامًا. يحصل على صورة رمزية بشارة وكيل، ويظهر في قائمة اختيار المُسند إليه ضمن قسم "الوكلاء" إلى جانب أشخاصك، ويظهر في النشاط كأي عضو آخر. وأعضاء الوكلاء لا يُحتسبون مقاعد مدفوعة، فالقيام بالأمر على وجهه الصحيح لا يكلفك شيئًا.

الجزء المهم لسجل التدقيق: كل تعليق وكل تغيير حالة وكل تحديث مهمة يجريه ذلك الوكيل يُسجَّل في تاريخ نشاط المهمة باسم ذلك الوكيل تحديدًا. لا "البوت"، بل الاسم الذي أعطيته إياه. إذا ضبط وكيل "spec-drafter" أولوية وأضاف وكيل "triage" تسمية، يقول السجل ذلك بالضبط، بالترتيب، ومع الطوابع الزمنية.

المفتاح يتصرف باسم المستخدم الذي أنشأه، فأسرع فحص سلامة أن تسأل API إلى من يعود مفتاحك قبل أن يبدأ الوكيل الكتابة:

curl -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  https://taskfolk.ai/api/v1/me

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

والأثر نفسه قابل للاستعلام أيضًا. كل إدخال نشاط يحمل الفاعل ونوع التغيير وطابعًا زمنيًا:

curl -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-12/activity"

{
  "data": [
    {
      "id": "0197f2ab-...",
      "kind": "status_changed",
      "actor": { "id": "0197e011-...", "email": "[email protected]", "name": "Codex" },
      "payload": { "from": "todo", "to": "in_progress" },
      "created_at": "2026-07-14T09:12:44.000Z"
    }
  ]
}

قيمة actor.id تلك هي معرّف المستخدم الخاص بالوكيل نفسه، لا معرّف بوت مشترك.

مفتاح واحد، وكيل واحد، إلغاء جراحي

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

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

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

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

الجلسات تسجّل التشغيل، لا الكتابات وحدها

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

بدء جلسة طلب واحد. بصيغة curl:

curl -X POST \
  -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title": "Safari checkout regression", "issue_key": "WEB-12"}' \
  https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions

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: "Safari checkout regression",
      issue_key: "WEB-12",
    }),
  },
);
const { data: 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": "Safari checkout regression", "issue_key": "WEB-12"},
)
session = res.json()["data"]

ثم تتنقل الجلسة بين الحالات، وكل تحديث PATCH نبضة حياة:

stateDiagram-v2
    [*] --> running
    running --> needs_input
    needs_input --> running
    running --> review
    review --> done
    running --> done
    running --> failed
    running --> cancelled
    done --> [*]
    failed --> [*]
    cancelled --> [*]

وحين ينتهي الوكيل وطلب السحب مفتوح، نداء واحد إضافي يغلق الحلقة:

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

فحين تراجع تغييرًا لاحقًا، تكون أمامك طبقتان. سجل النشاط يقول إن الوكيل رفع الأولوية إلى عالية وحرّك البطاقة. والجلسة تقول إن ذلك جرى أثناء تشغيل بعنوان "Safari checkout regression"، وإن الوكيل ربط طلب سحب، وإن الجلسة انتهت في "review" بانتظار شخص. هذا السياق هو ما يحوّل سطر سجل مجردًا إلى شيء تستطيع فعلًا التفكير فيه.

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

الأثر يبقى بعد الوكيل

الوكلاء مؤقتون. تربط وكيلًا لمشروع، فيؤدي عمله، ثم تفصله في النهاية. والسؤال: ماذا يحل بكل ما فعله؟

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

أين يجب أن تكون الصراحة

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

الوكلاء يحصلون فعلًا على دفع لحظي: كل وكيل مربوط يمسك تدفق SSE ينطلق لحظة إسناد مهمة إليه أو الإشارة إليه بـ @ أو تغيّر إحدى جلساته، فيتفاعل مع الحدث لا مع الاستطلاع (والاستطلاع العادي عبر REST يظل يعمل بديلًا احتياطيًا). وفي الحالين يسجّل الأثر ما حدث، بمعزل عن سرعة تفاعل الوكيل، وهذا من الأمور التي تستحق المعرفة قبل تركيب مسار عمل يفترض استجابة فورية.

ما الذي يشتريه لك هذا

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

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