مخطط مدخل الأداة وناتجها يحددان طرفين مختلفين من العملية التي يستعين بها المساعد. قد يقبل فحص المدخل معرفا صحيح النوع، ثم يرجع ناتج لا يوافق الشكل المطلوب. نضع عقدين تعليميين ونراجع كل كائن أمام عقده، دون تشغيل خادم أو إثبات أن منصة تنفذ الفحص تلقائيا.
الخلاصة السريعة
لا؛ مطابقة المدخل لقواعده لا تفحص الناتج بقواعد أخرى. حدد شكل كل طرف ودليل الفحص الفعلي، ثم راجع المعنى بحسب المهمة.
- يفصل دليل أدوات Plugins بين مخطط المدخل الذي يحدد المعلمات وأنواعها وحدودها، ومخطط الناتج الذي يحدد الحقول المنظمة المستعملة لاحقا. [1]
- نطلب في مدخلنا card_id كنص، وفي ناتجنا status نصا من «جديد» أو «راجع»؛ القاعدتان معلنتان لتطبيقنا التعليمي.
- المدخل card_id بقيمة ق 8 يطابق قاعدة النوع، لكن status بقيمة 7 يفشل قاعدة الناتج؛ قبول المدخل لا يغير نوع هذه القيمة.
- حتى ناتج status بقيمة «راجع» لا يثبت حصول مراجعة حقيقية؛ وافق الشكل فقط، ويلزم دليل المعنى والفحص والتنفيذ المقصود.
ما الذي يصفه كل مخطط؟
يعرض دليل تعريف أدوات Plugins مخطط المدخل للمعلمات المطلوبة والاختيارية والأنواع والقيم والحدود، ومخطط الناتج للحقول المنظمة التي يمكن فحصها وإعادة استعمالها. [1]
نحصر الاستشهاد في فصل العقدين، ولا نقول إن كتابة مخطط في مستند تشغل التحقق منه. يجب أن يعرف من يراجع النظام أين يطبق كل فحص وما الذي تظهره النتيجة الخاصة به.
كلمة «الأداة صحيحة» واسعة لهذا السؤال؛ الأفضل تحديد هل المقصود شكل المدخل أم شكل الناتج أم صحة المعلومات التي حملها الناتج.
ما قاعدتا البطاقة في تمريننا؟
نؤلف أداة قراءة بطاقة. قاعدة المدخل لدينا: وجود card_id بقيمة نصية. وقاعدة الناتج لدينا: وجود status بقيمة نصية لا تقبل إلا «جديد» أو «راجع». هذه شروط المثال لا أسماء إلزامية لكل أداة أو خدمة.
نعرض المدخل card_id: «ق 8». يحقق شرط النص الذي اخترناه. لا نستنتج من ذلك أن البطاقة ق 8 موجودة في قاعدة بيانات، أو أن المستخدم يملك صلاحية قراءتها؛ لم يضع تمرين النوع هذه الشروط.
تفيد القاعدة المحددة في منع خلط أسئلة أخرى بها. عندما نقول «نجح المدخل»، نذكر الفحص الذي نجح فيه، ولا نمنحه صحة لا تغطيها قاعدته.
كيف ينجح المدخل ويفشل الناتج؟
نفترض أن بطاقة الناتج المعلنة تحمل status: 7، وهي قيمة عددية. حسب قاعدتنا للناتج تفشل من جهة النوع ومن جهة القائمة النصية المقبولة. لا يصلح الرقم لمجرد أن card_id كان نصا صحيحا.
نقارن كل بطاقة بعقدها: المدخل يراجع شرط معرفه، والناتج يراجع حقل حالته. لا نستعمل علامة نجاح الطرف الأول شهادة للطرف الثاني، ولا نحول 7 إلى «راجع» كي نجعل الورقة توافق المخطط.
ولم نختبر تطبيق هذه القواعد بخادم MCP أو عميل حقيقي. النتيجة هنا حكم يدوي على قيم كتبناها وقواعد أعلنّاها، وليست تقرير تحقق آلي نجح أو فشل.
ما الذي يبقى بعد مطابقة شكل الناتج؟
نغير الناتج في تمرين منفصل إلى status: «راجع». الآن يوافق قاعدة الشكل والقائمة، لكن الورقة لا تعرض من راجع البطاقة أو متى. قبول النص لا يكمل معلومات الحدث.
إذا احتاج الطلب إلى إثبات مراجعة، نطلب الدليل الملائم لها، بدلا من الاكتفاء بأن القيمة تقبلها القاعدة. كما لا نقول إن صدق محتوى البطاقة معلوم لأن اسم الأداة read_card يوحي بالقراءة.
احفظ المدخل والناتج والقواعد التي طبقت على كل منهما، ثم صف حدود ما تحقق فعلا. لا نغير العقد بعد الاطلاع على الناتج دون إعلان التعديل؛ وإلا فقد يختفي سبب فشله من المقارنة.
المصادر ومتابعة القراءة
- OpenAI: Define tools، عقود المدخل والناتج (يفتح في نافذة جديدة)developers.openai.com
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.
