جديد · يُطرح تدريجيًا لكل مساحة عمل.

حوكمة الذكاء الاصطناعي: التقييم الذاتي والموافقات

Flash يضع كل إجراء يبدأه الذكاء الاصطناعي خلف رمز لكل إجراء معدات الترخيص — auto, review أو forbidden — يتم تكوينها لكل مساحة عمل في وحدة تحكم أنشطة الذكاء الاصطناعي والموافقات. لعميل الذكاء الاصطناعي الذي يزيد عن MCP هذا يعني أمرين: يمكنك يكتشف الكائنات التجارية والإجراءات المسموح لك باتخاذها قبل التصرف، وإرجاع استدعاءات الكتابة الخاصة بك نتائج منظمة — يتم تنفيذها، بانتظار الموافقة البشرية، أو يتم رفضها مع ذكر سبب يمكن قراءته آلياً.

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

الاستبطان object للأعمال (النطاق `introspection:read`)

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

list_objectsقراءة

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

المعلمات: (none)

describe_objectقراءة

الشكل الكامل لـ object: سماته (بما في ذلك الحقول المخصصة لمساحة العمل) مع نوعها ومعناها التجاري، وعلاقاته بالكائنات الأخرى (مثل: الطلب يخص عضوًا؛ يمكن إصدار قسيمة خصم لعضو). تُعاد حقول المعلومات الشخصية كبيانات وصفية فقط - الاسم، والنوع، والدلالات، وعلامة المعلومات الشخصية - ولا تُعاد قيمها أبدًا.

المعلمات: object

list_actionsقراءة

الإجراءات التي يمكن لعميل الذكاء الاصطناعي اتخاذها، مع الشروط المسبقة لكل إجراء وآليات التفويض الحالية (تلقائي / مراجعة / ممنوع) كما تم تكوينها في مساحة العمل. قم بالتصفية حسب object لعرض الإجراءات المتعلقة به فقط. ما يتم عرضه هو بالضبط ما ستفرضه طبقة الحوكمة - استخدمه لتجنب اقتراح إجراءات سيتم رفضها.

المعلمات: object?

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

مثال: صف object، ثم حدد التروس

أمثلة توضيحية لشكل الطلب/الاستجابة (مختصرة - الاستجابات الحقيقية تُدرج كل حقل وإجراء):

// describe_object { "object": "member" }
{
  "object": "member",
  "label": "Member",
  "meaning": "A loyalty program member owned by this workspace.",
  "fields": [
    { "name": "email",            "type": "string",  "pii": true,
      "meaning": "Contact email. PII: metadata only — values are never returned here." },
    { "name": "tier",             "type": "string",  "pii": false,
      "meaning": "Current loyalty tier." },
    { "name": "membership_no",    "type": "string",  "pii": false, "custom": true,
      "meaning": "Workspace-defined custom field." }
  ],
  "relationships": [
    { "to": "order",  "kind": "has_many",  "meaning": "Orders placed by this member." },
    { "to": "coupon", "kind": "has_many",  "meaning": "Coupons issued to this member." },
    { "to": "tag",    "kind": "has_many",  "meaning": "Tags currently applied to this member." }
  ]
}

// list_actions { "object": "member" }
{
  "actions": [
    { "action": "issue_coupon",     "gear": "review",
      "preconditions": ["member has consent", "coupon pool has stock"] },
    { "action": "earn_points",      "gear": "auto",
      "preconditions": ["amount within the workspace cap"] },
    { "action": "assign_tag",       "gear": "auto",
      "preconditions": ["tag exists and is active"] },
    { "action": "add_member_note",  "gear": "auto",
      "preconditions": ["note passes server-side sanitation"] },
    { "action": "send_campaign",    "gear": "review", "locked": true,
      "preconditions": ["sending can never be auto — a human always approves"] }
  ]
}

إن gear الذي تراه هو الجهاز الذي سيتم تطبيقه - تقوم مساحة العمل بتهيئته لكل إجراء في وحدة التحكم، ويمكن لقاطع الدائرة لكل إجراء تخفيض مستوى الإجراء إلى review في أي وقت (يتم تخفيضه تلقائيًا فقط؛ ولا يمكن استعادته إلا بواسطة المستخدم). أعد التحقق باستخدام list_actions بدلاً من تخزين الأجهزة مؤقتًا للجلسات الطويلة.

أدوات الكتابة تحت علامة مراجعة: قيد الانتظار / مرفوض

عندما تستهدف أداة كتابة MCP إجراءً يكون مُعامله review، فإن الاستدعاء not لا يُنفذ التأثير الجانبي. بل يُعيد نتيجة مُهيكلة: إما أن الاقتراح قد وُضع في قائمة انتظار الموافقة البشرية (pending)، أو أنه رُفض رفضًا قاطعًا (refused) مع reason_code وsuggested_action قابلة للقراءة آليًا.

// proposed — waiting for a human
{
  "status": "pending",
  "proposal_id": "prop_9f2c…",
  "action": "issue_coupon",
  "expires_at": "2026-07-10T00:00:00Z",  // 7 days
  "message": "Queued for human approval in
              AI Activity & Approvals."
}

// refused — with a reason and a next step
{
  "status": "refused",
  "action": "issue_coupon",
  "reason_code": "recently_rejected",
  "suggested_action": "A human rejected this
    proposal recently. Do not re-propose;
    consider a different action or ask the
    operator."
}

reason_code	المعنى	ما يجب على وكيلك فعله
`gear_forbidden`	تم ضبط إعدادات الإجراء على "ممنوع" في مساحة العمل هذه (أو لا يمكن أن يكون الإجراء تلقائيًا - مثل الإرسال - وتم استدعاؤه بطريقة تتطلب التشغيل التلقائي). تم ضبط إعدادات الإجراء على "ممنوع" في مساحة العمل هذه (أو لا يمكن أن يكون الإجراء تلقائيًا أبدًا - على سبيل المثال، الإرسال - وتم استدعاؤه بطريقة تتطلب التشغيل التلقائي).	لا تحاول مرة أخرى. أظهر سبب الرفض؛ ثم اتبعه. suggested_action (عادةً ما يكون إجراءً بديلاً أو "اطلب من شخص ما تغيير التروس").
`recently_rejected`	رفض أحد الموظفين مؤخرًا نفس الاقتراح لنفس الهدف - ولن تعيد المنصة إدراجه.	احترم القرار البشري. لا تعيد طرحه أو صياغته؛ اتبعه. suggested_action.

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

دورة الموافقة

يُحلّ اقتراح pending بطريقة واحدة فقط: approved أو rejected أو expired. يتخذ المستخدمون الإجراءات اللازمة بشأنه في وحدة تحكم أنشطة وموافقات الذكاء الاصطناعي (إجراء فردي أو جماعي حسب نوع الإجراء)؛ ويُرسل بريد إلكتروني يومي مُلخّص يُظهر ما ينتظر.

الحالة	كيف يتم ذلك؟	ثم
`pending`	تم استدعاء أداة الكتابة أثناء مراجعة آلية الإجراء، وتم وضع الاقتراح في قائمة انتظار الموافقة البشرية.	موافق عليه · مرفوض · منتهي الصلاحية
`approved`	تمت الموافقة عليه من قِبل شخص. قبل التنفيذ، تُعيد المنصة التحقق من صحة منطق الذكاء الاصطناعي المُقدّم؛ إذا لم يعد هذا المنطق صحيحًا (على سبيل المثال، إذا قام العميل بإعادة الشراء)، فلن يتم تنفيذ الإجراء.	طرفية (يتم تسجيل النتيجة في سجل القرارات؛ قابلة للإلغاء بشكل فردي)
`rejected`	رفضها شخص ما، مع إمكانية إرفاق ملاحظة. ثم يتم رفض الاقتراح نفسه مع recently_rejected في حال إعادة التقديم.	طرفية
`expired`	في حال عدم اتخاذ قرار خلال 7 أيام، ينتهي العرض تلقائيًا ولا يتم تنفيذ أي شيء.	طرفية

ضمانات التكرار

موافقة واحدة، تنفيذ واحد. الموافقة على اقتراح تُنفذ الإجراء مرة واحدة فقط؛ أما الموافقة المتكررة فتعيد تنفيذ النتيجة المخزنة دون أي آثار جانبية أخرى.
إعادة الإرسال لا تُكرر البيانات. استدعاء أداة الكتابة مرة أخرى لنفس الاقتراح أثناء انتظاره يُعيد نفس النتيجة pending و proposal_id - لا يتم وضع بطاقة ثانية في قائمة الانتظار.
إعادة التحقق من الموافقة، والتنفيذ مشروط. عند وقت الموافقة، تعيد المنصة التحقق مما إذا كان منطق الذكاء الاصطناعي لا يزال قائماً؛ إذا لم يعد كذلك (على سبيل المثال، قام العميل بإعادة الشراء بالفعل)، فلن يتم تنفيذ أي شيء - يتم تسجيل النتيجة بدلاً من الإجراء.
كل شيء يخضع للتدقيق وقابل للإلغاء بشكل فردي. يتم تسجيل الاقتراح والقرار ومسار التفويض (auto أو شخص مُعيّن) والتنفيذ والنتيجة في سجل القرارات، حيث يمكن التراجع عن أي إدخال.

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

عناصر الشفافية ونموذج المخزون ذو الصندوق الزجاجي

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

التحسين التلقائي لحركة المرور باستخدام اختبار A/B: سجل القرارات

يمكن للحملات المتكررة (الأتمتة ومسارات العملاء) تفعيل ميزة تحسين حركة المرور تلقائيًا بمرور الوقت، والتي تعيد توزيع أوزان التسليم بين متغيرات التجربة بناءً على أداء النقرات المُلاحَظ. كل عملية إعادة توزيع قابلة للتدقيق:

سجل قرارات الإضافة فقط. كل إعادة حساب تُسجل سجلًا واحدًا بالأوزان المطبقة وشرح منطقي واضح. لا تُعاد كتابة السجلات أبدًا - السجل هو التاريخ الكامل لأسباب ظهور حركة المرور بالشكل الحالي.
لا يتم تغيير التقسيم المُعدّ مسبقًا. يبقى التقسيم المُعدّ مسبقًا لتجربتك كما هو كخط أساس؛ ويتم حساب الأوزان المُحسّنة وتسجيلها بجانبه.
الحد الأدنى للاستكشاف: 10%. لا ينخفض وزن أي منتج بديل عن 10%، لذا يستمر كل منتج في تلقي الزيارات، ويبقى أي تراجع قابلاً للكشف.
توزيع متساوٍ حتى يتم تسليم ≥100 لكل متغير. تبقى الأوزان عند التوزيع المُكوّن حتى يحصل كل متغير على 100 تسليم على الأقل - لا إعادة تخصيص للبيانات المحدودة، ولا يتم إعلان "فائز" إحصائيًا بواسطة هذه الآلية. ...

إخفاء معلومات التعريف الشخصية (PII) عند نقطة اتصال مزود الخدمة

قبل أن ينتقل أي طلب من Flash إلى مزود خدمة إدارة التعلم الإلكتروني الخارجي، يتم إخفاء بيانات تعريف الأعضاء الشخصية - يتم تطبيق ذلك عند نقطة اتصال المزود، بحيث تمر جميع ميزات الذكاء الاصطناعي من خلالها:

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

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

نموذج المخزون ذو الصندوق الزجاجي

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

النموذج	القدرات	بوابات النزاهة
نموذجان للتحسين (نموذجان لوجستيان محددان)	SoClaw تصنيف قائمة استعادة العملاء - القيمة المعرضة للخطر × الزيادة، تم التدريب عليها باستخدام تجربة عشوائية مضبوطة مستمرة خاصة بالبرنامج	يتم التفعيل فقط بعد ≥200 صف مُعالَج ناضج، و≥50 صفًا مُختَفَّفًا، و≥20 تحويلًا، مع تقارب كلا المعيارين - أقل من ذلك، يعود الترتيب إلى القيمة المُعرَّضة للخطر فقط. الأعضاء ذوو التحسين السلبي (عدم الإزعاج) يتراجعون؛ كل مهمة تخزن لقطة من نتيجتها.
جاما الشراء بين الأعضاء لكل عضو (طريقة اللحظات)	تاريخ الشراء المتوقع التالي في الملف الشخصي + شرط "الأيام المتبقية حتى الشراء المتوقع التالي" (قيمة سالبة = متأخر).	يتطلب الأمر ≥3 فجوات مُلاحظة (أي ≥4 عمليات شراء) وبوابة معامل تباين (≤1.5) على انتظام الإيقاع - يحصل المشتري غير المنتظم على قيمة فارغة، ولا يحصل أبدًا على تاريخ مُختلق. يُصدر تاريخ مُتوقع سابق كإشارة صادقة على التأخير.
الانحدار اللوجستي المُنتظم من الدرجة الثانية لكل فريق	معدل النقر (من 0 إلى 100)، يُعاد ضبطه يوميًا بناءً على آخر 90 يومًا من عمليات الإرسال الخاصة بالفريق.	علامة النقرات فقط (لا تُفتح أبدًا - Apple MPP تُضخّمها)؛ ميزة النقر المسبق المحمية من التسريب؛ هبوط تدرج كامل الدفعة حتمي وفقًا لجدول زمني ثابت. بوابات ملائمة ≥500 إرسال / ≥30 نقرة / ≥50 عضوًا؛ يحتاج العضو إلى ≥3 إرسالات حديثة ليتم احتساب نقاطه.
خوارزمية أقرب جار (kNN) للعناصر المُعَدَّلة باستخدام دالة جيب التمام	ربط المنتجات بقائمة "اشترى أيضًا" عبر منصات التوصيات	co_count / √(buyers(A) × buyers(B)) يصحح تحيز الشعبية؛ تحتاج الأزواج إلى ≥2 مشترين مشتركين لتتحقق؛ يتم تخزين عدد عمليات الشراء المشتركة الخام جنبًا إلى جنب مع النتيجة كدليل قابل للفحص.
قواعد الربط (الدعم / الثقة / التحسين)	اقتراحات البيع المتبادل، يتم استخراجها يوميًا من طلبات التاجر	يتطلب كل شرط 3 طلبات متزامنة على الأقل ومستوى ثقة 5% على الأقل؛ حيث يخزن كل شرط عدد الطلبات الأولية التي يستند إليها، مما يسمح بإعادة حساب أي رقم يدويًا. يستثني ملف تعريف العضو المنتجات المملوكة مسبقًا، ويعرض فقط للمشترين النشطين.
القيمة الشاذة للإحصائيات القوية (الوسيط / متوسط الانحراف المطلق)	ال behavior_outlier كاشف الاحتيال في النقاط	Robust z ≥ 6 بالإضافة إلى الحدود الدنيا المطلقة (≥10 معاملات ربح؛ يتم تخطي الفرق التي يقل عدد أعضائها النشطين عن 50)؛ إلغاء التكرارات الشهرية لكل عضو؛ التجميد فقط - يفتح مراجعة ولا يلغي نفسه أبدًا.
كابلان-ماير + كوكس للمخاطر النسبية (احتمالية نيلدر-ميد الجزئية)	الاحتفاظ بالعملاء حسب مجموعة التسجيلات الشهرية + لوحة "ما يرتبط به الاحتفاظ بالعملاء"	التعريف المطبوع في العرض: التسرب = 90 يومًا بدون شراء، مع استبعاد العملاء الذين لم يشتروا أبدًا، وإخفاء المجموعات التي يقل عدد أعضائها عن 30 عضوًا والإفصاح عنها. يتطلب نموذج كوكس ≥30 حالة تسرب مُلاحظة، ويقتصر على 3 متغيرات مشتركة؛ وتُسمى الارتباطات بالارتباط، وليس بالسببية.
هولت-وينترز (موسمية أسبوعية، ثوابت ثابتة)	توقعات الإيرادات للأربعة عشر يومًا القادمة على لوحة التحكم	ثوابت تنعيم ثابتة - لا يوجد سطح ضبط لكل فريق؛ يقرأ نفس مقياس الإيرادات المعتمد مثل كل شاشة أخرى؛ خط متقطع + نطاق خطأ مع أساسه بالدولار مطبوع؛ مخفي بالكامل تحت 4 أسابيع من التاريخ؛ مصنف على أنه توقع، وليس التزامًا.

لا يعمل أيٌّ من هذه النماذج بشكلٍ مستقلّ: فهي تُصنّف وتُقيّم وتُعلّم، وكلّ ما يتعلّق بتحويل الأموال أو التواصل مع الأعضاء يخضع لإجراءات الرقابة المذكورة أعلاه.

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

نظرة عامة على حوكمة الذكاء الاصطناعي والموافقات MCP دليل التكامل SoClaw تكامل استعادة العملاء العودة إلى مركز المطورين

إنشاء مفتاح API