شرح موافقات أدوات MCP: من طلب معلق إلى قرار بشري محدد النطاق

لا تكون بوابة "الإنسان في الحلقة" مفيدة إلا عندما يحافظ النظام على ما تم اقتراحه، وما تمت الموافقة عليه، ومدة سريان المنحة، وما تم تنفيذه فعلياً.

الموافقة هي انتقال حالة، وليست مربع حوار

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

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

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

كيف تعمل سياسات الموافقة على MCP في TrueFoundry

توثق TrueFoundry سياسات الموافقة لاستدعاءات أدوات MCP الموجهة عبر بوابة MCP. تطابق السياسة نطاق الخادم والأداة. عند وصول استدعاء أداة مقيد، تنشئ البوابة طلباً معلقاً لنفس الأداة ومقدم الطلب أو تعيد استخدامه، ولا تنفذ الأداة، وتخطر المعتمدين المعينين. يتلقى المتصل نتيجة JSON-RPC تشير بياناتها الوصفية إلى أن الموافقة معلقة.

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

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

النطاق والصلاحية بعدان مختلفان

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

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

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

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

تصميم نموذج للموافقة

حالة "قيد الانتظار" ليست فشلاً، وليست نجاحاً

أثناء انتظار الموافقة، تُرجع بوابة MCP نموذج JSON-RPC ناجحاً يحتوي على نص يوجه المتصل بالانتظار، مع ضبط isError على false، وتعيين بيانات الموافقة الوصفية على "قيد الانتظار". هذا النجاح على مستوى النقل يعني أن البوابة تعاملت مع الطلب، لكنه لا يعني أن الأداة قد تم تنفيذها.

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

بعد الموافقة، تمر النتيجة مع بيانات وصفية تفيد بالاعتماد. ينبغي للتطبيق ربط هذه النتيجة بالاقتراح الأصلي والعملية اللاحقة. تجيب أدلة الموافقة على سؤال: "هل تم تسجيل قرار هذا الشخص بموجب سياسة البوابة هذه؟"، بينما يجيب نظام السجلات على سؤال: "ما هو الأثر الذي تم تنفيذه؟"

موافقات البوابة ونقاط التحقق في TrueForge مترابطة، لكنها ليست متطابقة

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

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

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

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

مثال عملي: تغيير في قاعدة بيانات الإنتاج

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

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

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

سهولة المراجعة جزء من الأمان

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

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

اختبارات الفشل لأنظمة الموافقة

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

تعريف استهلاك المنح والتصعيد

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

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

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

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

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

القاعدة التشغيلية

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

توفر بوابة TrueFoundry MCP سطح موافقة مشتركاً للأدوات الموجهة، بينما يمكن لـ TrueForge إيقاف سير عمل الوكيل مؤقتاً ومتابعته حول مقترح معين. معاً، يمكنهما جعل القرارات قابلة للفحص. إنهما لا يحولان الموافقة إلى تفويض تجاري أو تنفيذ لمرة واحدة بالضبط، والقول بذلك بوضوح يجعل البنية أقوى.

المراجع

1. TrueFoundry — موافقات أدوات MCP.
2. TrueFoundry — نظرة عامة على بوابة MCP.
3. TrueForge — استخدام وكيل.
4. TrueForge — مفاهيم حزمة تطوير البرمجيات (SDK).

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

‍