يجب تقييم وكيل الذكاء الاصطناعي الذي يستخدم أدوات MCP كمسار تنفيذ كامل، لا من خلال آخر جملة فقط. الاختبار الإنتاجي يتحقق من الأداة التي اختارها، وصحة Arguments وTenant Scope، وطلب الموافقة قبل الإجراء الحساس، ونتيجة الأداة الفعلية، وعدم تكرار الأثر عند Retry، وصدق الجواب النهائي في نقل النتيجة. يناسب هذا الأسلوب المساعدات التي تقرأ بيانات العمل أو تنفذ إجراءات؛ ولا يلزم Workflow حتميًا تستطيع برمجته بأمان أكبر من دون Agent.
هذا دليل هندسي عملي مبني على مواصفة Model Context Protocol ووثائق OpenAI وAnthropic الرسمية التي راجعتها في ٥ أكتوبر ٢٠٢٦، وليس إعلانًا عن نموذج جديد. عقد التقييم وبنية Dataset وبوابات الإصدار أدناه توصيات معمارية داخل التطبيق مبنية على سلوك البروتوكول والتقييم الموثق.
عامل التشغيل كمسار مكتوب الأنواع
تعرّف مواصفة MCP الأداة القابلة للاكتشاف بالاسم والوصف و`inputSchema`، ويمكن إضافة `outputSchema`. قد يقرر النموذج أي أداة يستدعي، لكن Host يبقى مسؤولًا عن Access Control والتحقق والمهلات والسجلات وموافقة المستخدم على العمليات الحساسة. لذلك فإن «الإجابة تبدو صحيحة» تراقب آخر عقدة فقط من نظام أكبر.
مثل التشغيل كسلسلة أحداث مرتبة: طلب المستخدم، وسياسة الصلاحية، ومجموعة الأدوات المتاحة، وقرار النموذج، واسم الأداة، وArguments، وقرار الموافقة، ونتيجة الخادم، وإعادة المحاولة أو Handoff، والجواب النهائي. اربط معرّفات ثابتة للتشغيل والعميل والمستخدم ونسخة الأداة والعملية. لا تحفظ الأسرار أو البيانات الشخصية بلا حدود داخل Trace؛ استخدم مدخلات منقحة أو Hash عندما يحتاج المقيم دليلًا من دون القيمة الأصلية.
تصف إرشادات OpenAI لتقييم الوكلاء Trace بأنه سجل End-to-end لاستدعاءات النموذج والأدوات وGuardrails وHandoffs. يفيد Trace Grading أثناء تشخيص السلوك، ثم تجعل Datasets وEval Runs المقارنة قابلة للتكرار. القرار الأهم ليس أي Dashboard يحفظ السجل، بل أن كل إصدار يستطيع تفسير لماذا ظهرت الأداة واختيرت وتمت الموافقة عليها وقبول نتيجتها.
ابن الحالات حول القرارات لا حول Prompts
قائمة Prompts ليست Agent Eval بعد. تحتاج كل حالة إلى حالة أولية وهوية موثقة وأدوات مسموحة ونقاط قرار متوقعة ومسارات بديلة مقبولة وآثار ممنوعة وAssertion على الحالة النهائية. طلب «ألغِ الطلب 481» يختلف عندما يكون الطلب لعميل آخر، أو جرى شحنه، أو يحتاج موافقة، أو سبق إلغاؤه بمحاولة قديمة.
أنشئ خمس فئات. Happy paths تثبت أقصر مسار آمن. Boundary cases تغطي الحقول الناقصة والهوية الغامضة وPagination. Authorization cases تطلب موردًا لتاجر آخر أو أداة خارج Role. Adversarial cases تضع تعليمات داخل مستند مسترجع أو نتيجة أداة. Recovery cases تحقن Timeout وفشلًا جزئيًا وCallback مكررًا واستئناف Session.
استخدم توزيع الإنتاج بعد إزالة البيانات الحساسة، ثم أضف الحالات النادرة التي لا تمثلها السجلات جيدًا. ضع نسخة ثابتة لـFixture والنتيجة المتوقعة. الحالة التي تتغير قاعدتها بين تشغيلين لا تميز Regression في النموذج عن Drift في الاختبار. توصي OpenAI بتقييمات خاصة بالمهمة، واختبار مبكر ومتكرر، وحالات مشتقة من الإنتاج، وتقييم مستمر، ومعايرة النتائج الآلية بعلامات بشرية.
قيّم اكتشاف الأداة واختيارها كلًا على حدة
اسأل أولًا هل كانت القدرة الصحيحة ظاهرة. لا يستطيع نموذج مثالي اختيار أداة غير موجودة في Discovery، والسياسة الآمنة يجب أن تخفي الأدوات التي لا يملك المستخدم صلاحيتها. يدعم MCP طلب `tools/list`، وعلى العميل التعامل مع Pagination وإشعار تغير القائمة عندما يعلنه الخادم. لا تخزن الاكتشاف في Cache بلا قاعدة إبطال واضحة.
بعد ذلك قيّم الاختيار. عرّف لكل حالة الأدوات المطلوبة والبدائل المسموحة والممنوعة. «اقرأ الطلب ثم لخّصه» قد يسمح بـ`orders.get` ولا يسمح بأي Mutation. أما «ألغ الطلب بعد الموافقة» فقد يحتاج قراءة قبل `orders.cancel`. لا تفرض تسلسلًا حرفيًا عندما يوجد مساران متكافئان؛ قيّم Invariant مثل «لا Mutation قبل تحقق الملكية».
اعرض أصغر Tool Surface مناسب. تذكر وثائق OpenAI أن `allowed_tools` يقلل التكلفة والكمون عندما يعرض خادم MCP أدوات كثيرة. وهو حد Policy مفيد، لكنه لا يستبدل Authorization داخل الخادم. قس محاولات الأدوات غير المتاحة والاستدعاءات غير الضرورية ودقة اختيار الأداة حسب Intent.
اختبر الوصف وSchema كواجهة منتج
أسماء الأدوات وأوصافها تعليمات يستهلكها Planner احتمالي. تشدد وثائق Anthropic على الوصف المفصل: ما الذي تفعله الأداة، ومتى تستخدم، ومتى لا تستخدم، ومعنى كل Parameter وحدود النتيجة. عامل تغيير الوصف كتغيير في التوجيه، وشغل Suite الاختيار قبل نشره.
تحقق من Arguments مرتين. يجب أن يرفض العميل أو الخادم أي قيمة لا تطابق `inputSchema`، ثم يفرض Business Code الحقائق التي لا يعبر عنها JSON Schema، مثل ملكية Tenant وحالة المورد وحد الإنفاق والانتقال المسموح. لا تسمح للنموذج بإرسال Tenant ID الرسمي عندما تحدده Session الموثقة أصلًا.
استخدم `outputSchema` للنتائج المنظمة الثابتة. تنص مواصفة MCP على التزام الخادم به عند الإعلان عنه، وتوصي بتحقق العميل من Structured Result. اختبر الحقول المفقودة وEnum غير المتوقع والحمولة الضخمة ونصًا عاديًا عندما ينتظر العميل بيانات منظمة. Tool Annotations تلميحات وليست سياسة موثوقة إلا إذا كان الخادم نفسه موثوقًا.
type ToolEvalCase = {
identity: { tenantId: string; roles: string[] };
request: string;
allowedTools: string[];
expected: {
requiredCalls?: string[];
forbiddenCalls?: string[];
approvalBefore?: string[];
finalState: Record<string, unknown>;
};
faults?: Array<'timeout' | 'duplicate-result' | 'stale-read'>;
};
const result = await runAgentWithRecordedTools(testCase);
assertSchemaValid(result.toolCalls);
assertNoForbiddenCalls(result.trace, testCase.expected);
assertApprovalOrder(result.trace, testCase.expected);
assertAuthoritativeState(result.state, testCase.expected.finalState);يوضح المثال شكل Harness ولا يمثل Vendor SDK. الـAssertion الحاسم هو الحالة الرسمية النهائية، لا وجود كلمة داخل جواب النموذج.
قيّم Arguments لا اسم الأداة فقط
قد يختار Agent الأداة الصحيحة وينتج نتيجة خاطئة. قس الحقول المطلوبة والقيم المطبعة والـDefaults المحذوفة والحقول المشتقة من السياسة. في Search تحقق من Filters وLimit وTenant Scope. في Payment تحقق من العملة والمبلغ والمستفيد وIdempotency Key. وفي إجراء مدمر تحقق من المورد الدقيق ونسخته المتوقعة.
استخدم فحوصًا حتمية للحقول المنظمة. JSON Schema Validator وOwnership Assertion واستعلام قاعدة البيانات أدق من سؤال نموذج آخر إن كانت القيمة «منطقية». استخدم LLM Grader عندما تعتمد الصحة على تكافؤ دلالي، مثل هل يصف التبرير نتيجة الأداة فعلًا. عاير المقيم بعلامات بشرية وسجل نقاط الخلاف.
افصل البدائل الصحيحة عن الأخطاء. يمكن تطبيع الوقت إلى UTC أو حفظه مع Offset إذا سمح العقد بكليهما. عبّر عن ذلك في المقيم بدل فرض String واحدة. وفي المقابل، لا تقبل موردًا مختلفًا لأن النص النهائي مقنع.
اجعل الموافقة انتقال حالة قابلًا للاختبار
تطلب تكاملات MCP في OpenAI الموافقة افتراضيًا قبل مشاركة البيانات مع خادم Remote، وتكشف Approval Request وResponse كعناصر واضحة. كما توصي مواصفة MCP ببقاء الإنسان قادرًا على رفض العمليات الحساسة وإظهار الأداة المستدعاة. في تطبيقك صنف العمليات إلى قراءة أو فعل ظاهر خارجيًا أو أثر مالي أو إجراء مدمر، ثم اربطها بسياسة موافقة.
اختبر ترتيب الأحداث: يرى المستخدم اسم الأداة وArguments المهمة والنتيجة المتوقعة قبل الاستدعاء؛ الرفض لا ينتج أي أثر؛ القبول يستخدم القيم التي راجعها؛ وRetry لاحق لا يتجاوز الموافقة بقيم متغيرة. اربط القرار بـDigest لاسم الأداة والحقول والعميل ووقت الانتهاء. إذا تغير حقل جوهري، اطلب قرارًا جديدًا.
لا تطلب تأكيدًا لكل قراءة بسيطة. كثرة النوافذ منخفضة القيمة تدرب المستخدم على القبول بلا قراءة. يجب أن يقيس Eval الموافقة المفقودة والموافقة غير الضرورية معًا، لأن كليهما يضر المنتج.
تحقق من الأثر خارج Trace النموذج
نتيجة أداة تقول «نجح» ادعاء وليست دليلًا. بعد Mutation اقرأ النظام الرسمي أو حدثه الدائم. تأكد أن أثرًا واحدًا مقصودًا حدث، ولم يتغير حقل ممنوع. يكشف ذلك خادمًا رد بالنجاح قبل Commit، أو Timeout بعد Commit، أو Retry أنشأ نسخة ثانية.
امنح كل Mutation قابل للإعادة Operation ID مولدًا من التطبيق. يجب أن يحفظه الخادم مع الأثر ويعيد النتيجة السابقة عند Replay. في Harness احقن Timeout بعد Commit، واستأنف Agent، وتحقق أن الحالة بقيت واحدة. اختبر Tool Execution Error وProtocol Error وRate Limit ونتيجة تالفة؛ يفرق MCP بين أخطاء البروتوكول والتنفيذ، ولا ينبغي للوكيل عرضها كرسالة واحدة عامة.
استخدم Record and Replay بحذر. تجعل الأدوات المسجلة مقارنة النماذج سريعة وقابلة للتكرار، لكنها لا تثبت عقد الخادم الحالي أو سياسة Authorization. احتفظ بـReplay Suite حتمي للتخطيط وLive Sandbox Suite أصغر للآثار End-to-end. لا توجه اختبارًا مدمرًا آليًا إلى حساب إنتاج.
قيّم الجواب النهائي مقابل الدليل
بعد سلامة المسار، قيّم التواصل. يجب أن يصرح الجواب بما حدث فعلًا، ويميز المحاولة من الإتمام، ويظهر الحاجة إلى موافقة أو استعادة، ولا يخترع حقولًا غائبة عن Tool Output. إذا فشل الاستدعاء، فإن «أُلغي الطلب» جواب خاطئ حتى لو كان اختيار الأداة وArguments صحيحين.
اربط الادعاءات بدليل Trace: نتيجة الاستدعاء أو القراءة الرسمية أو قرار السياسة. قس الدعم الواقعي والاكتمال وعدم اليقين وهل كرر الجواب قيمة حساسة بلا حاجة. Agent ينفذ المهمة لكنه يسرب معرف عميل آخر يفشل التشغيل.
افصل نتيجة المنتج عن صحة Workflow. قد يكون المسار صحيحًا بينما يبقى هدف المستخدم غير محلول بسبب غياب المخزون أو منع السياسة. اعرض المؤشرين: Safe Execution Rate وTask Resolution Rate. دمجهما في رقم واحد يجعل Authorization صارمًا يبدو كRegression جودة.
ابن Scorecard طبقيًا وبوابة إصدار
استخدم Hard Gates لانتهاكات الأمان والعقود الحتمية: وصول عبر Tenant، واستدعاء أداة ممنوعة، وغياب موافقة مطلوبة، وتكرار أثر مالي، وOutput Schema تالف، وادعاء نجاح بلا دليل. حالة واحدة قد تمنع الإصدار. واستخدم معدلات للسلوك الألين: اختيار الأداة الصحيح، والاستدعاءات الزائدة، ودقة Arguments، ونجاح الاستعادة، ودعم الجواب، والكمون، والتكلفة.
قسّم النتائج حسب Intent والأداة وTier واللغة والنموذج ونسخة Prompt ونوع الفشل. قد يخفي المتوسط أن الأسئلة العربية تختار أداة الشحن الخطأ أو أن خادم MCP واحدًا يستهلك معظم الكمون. اعرض مجال الثقة عند العينات الصغيرة، واحتفظ Holdout ثابتًا حتى لا يتحول Benchmark إلى بيانات تدريب من كثرة الضبط.
شغل Contract Tests الحتمية عند كل تغيير أداة أو Policy، ثم Agent Suite محدودة عند تغيير Prompt أو Model أو Tool Surface. أضف عينات Production Trace بعد استيفاء التنقيح والموافقة. توصي OpenAI بالتقييم المستمر وتوسيع Dataset عند ظهور حالات عدم حتمية؛ التطبيق المفيد هو Release Gate بمالك وحدود Rollback، لا Dashboard لا يراجعها أحد.
اعرف متى لا تستخدم Agent أو MCP
استخدم Agent متصلًا بـMCP عندما تكون المهمة متغيرة فعلًا: يعبر المستخدم عن هدف باللغة الطبيعية، وقد تناسبه أدوات متعددة، ويضيف التخطيط قيمة مع قدرة التطبيق على ضبط الخطر. استخدم الكود العادي عندما يكون المسار معروفًا: تحقق من المدخل، ثم استدع API A ثم B وأعد نتيجة محددة. State Machine حتمية أسهل في الاختبار والتشغيل والأمان.
يوحد MCP الاكتشاف والاستدعاء؛ لكنه لا يمنح الثقة لخادم، ولا يحول API غير آمن إلى آمن، ولا يضمن الاختيار الصحيح. لا تعرض أدوات Admin واسعة لمجرد أن البروتوكول يستطيع وصفها. ضع Authorization وInvariants داخل تنفيذ الأداة، وضيّق السطح المتاح، واطلب الموافقة عندما تبرر النتيجة ذلك.
عقد الإنتاج طبقي: الأداة الصحيحة ظاهرة، والوكيل يختارها للسبب الصحيح، وArguments تطابق Schema والسياسة، والموافقة تسبق الأثر الحساس، والخادم يعيد نتيجة صالحة، وإعادة المحاولة Idempotent، والحالة الرسمية تطابق الهدف، والجواب النهائي Grounded في Trace. قيّم كل طبقة منفصلة، ثم قرر هل المسار كاملًا آمن للإطلاق. اقرأ أيضًا عقد تقييم AI قابل للنقل وتنفيذ الوكلاء الدائم وخدمات تكامل الذكاء الاصطناعي.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
