الموافقة البشرية على منشورات الوكلاء: أين تضع البوابة؟

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

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

لماذا لا توافق على كل خطوة يخطوها الوكيل؟

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

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

مرّر جانبيًا لرؤية المخطط كاملًا

أين يجب أن تقع البوابة بالضبط؟

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

الخطوة	قابلة للتراجع؟	تحتاج إلى إنسان؟
الاستعلام عن مساحات العمل والمجموعات والقنوات	لا شيء يتغير	لا
رفع وسائط من رابط	خاصة بمساحة العمل	لا
إنشاء مسودة منشور	خاصة، قابلة للتعديل والحذف	لا
جدولة منشور	قابلة للتراجع حتى موعد الإرسال	نعم
النشر	علني، يُرى فورًا	نعم، والقرار اتُّخذ مسبقًا

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

كيف تفرض النطاقات البوابة؟

تحمل مفاتيح API في Shager نطاقات: read وwrite وpublish. المفتاح الذي يحمل read وwrite يستطيع تنفيذ كل خطوة فوق خط البوابة ولا شيء تحته. إذا حاول الوكيل schedule_post، يفشل الاستدعاء.

يمنحك ذلك ثلاثة إعدادات عملية:

1. وكيل يكتب المسودات، وإنسان يجدول. مفتاح الوكيل يحمل read وwrite. يراجع شخص المسودات في لوحة التحكم ويجدولها. من هنا يجب أن يبدأ كل فريق.
2. وكيل يكتب المسودات، والعميل يوافق، والوكيل يجدول. مفتاح الوكيل يحمل publish أيضًا، لكن مهارتك توجّهه إلى ألا يجدول إلا المنشورات التي عادت موافقتها إيجابية. هذا إعداد فعّال، لكنه يعتمد على اتباع التعليمات، فأبقِ سجل التدقيق تحت المراجعة.
3. مفتاحان. مفتاح للمسودات دون publish يستخدمه وكيل المحتوى، وخطوة جدولة منفصلة، ينفذها شخص أو وكيل ذو تعليمات ضيقة، تحمل مفتاح النشر. هذا أنظف فصل للوكالات الأكبر.

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

أين تدخل موافقة العميل؟

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

تسلسل نموذجي:

create_post         caption, group_ids, media_ids, per_channel[...], no schedule_at
request_approval    post id, returns an approval link for the client
get_post            later: read the approval status
schedule_post       only if approved; schedule_at "2026-09-03T09:00:00+02:00"

وتعليمات مطابقة للوكيل، مكتوبة في مهارته:

Never call schedule_post on a post unless get_post shows it was approved.
If a post is rejected, do not schedule it. Report the rejection to the
account lead, wait for revision notes, then create a revised draft with
create_post and request approval again.

أما العملية الأوسع، بما فيها كيف تمنع تعطل الموافقات لأيام، ففي مقالنا عن مسار موافقة العميل للوكالات.

مرّر جانبيًا لرؤية المخطط كاملًا

ما الذي يجب أن يفحصه المراجِع فعلًا؟

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

1. الادعاءات. الأسعار والتواريخ والعروض والتصريحات الصحية أو المالية. قارنها بالموجز. هنا يقع الضرر الحقيقي.
2. الروابط. افتح رابط التعليق الأول في نسختين أو ثلاث. تأكد من أنه يقود إلى الصفحة المقصودة الصحيحة.
3. تفاصيل كل حساب. تحقق عشوائيًا من أن نسخة الإسكندرية تذكر الإسكندرية ونسخة المنصورة تذكر المنصورة. عدم تطابق التفاصيل المحلية هو أكثر أخطاء الوكلاء شيوعًا في النصوص المحلية.
4. التنويع. مرّ على النسخ جنبًا إلى جنب. إذا بدت الجملة نفسها مع تبديل كلمة واحدة، فاطلب نسخًا أكثر تمايزًا.
5. الصيغة. للريل وShorts متطلبات في الطول ونسبة الأبعاد. يتحقق Shager من الوسائط وفق قواعد الشبكات قبل الإرسال، لكن على المراجِع أن يتأكد مع ذلك من أن الصيغة المختارة تناسب المادة الإبداعية.

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

متى يمكنك تخفيف البوابة؟

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

الأسئلة الشائعة

هل يستطيع العميل الموافقة على المنشورات دون حساب في Shager؟

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

ماذا يحدث إذا حاول الوكيل النشر دون النطاق publish؟

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

هل ينبغي أن تتخطى منشورات الحسابات الخاصة بالوكالة نفسها الموافقة؟

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

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