عندما توجد عشرات MCP Tools، الوكيل يعتمد على الاسم والوصف و schema لاختيار الأداة. وصف مثل manage_browser أو do_action لا يكفي. Discovery الجيد يشبه API documentation مختصرة: فعل واحد، متى تستخدمه، ما لا يفعله، وما النتيجة المتوقعة.
استخدم اسمًا فعليًا محددًا
get_tab_url أفضل من tab_info إذا كان الناتج URL فقط، و close_tab أوضح من manage_tab. الاسم ليس مكانًا لكل التفاصيل لكنه يجب أن يزيل أكبر قدر من الغموض.
اكتب وصفًا يذكر الحدود
قل إن الأداة تقرأ current tab فقط أو تحتاج profile ID أو لا تنتظر اكتمال navigation. جملة ما لا تفعله قد تكون أهم من تكرار الاسم.
خطوات عملية
- ابدأ بالفعل.
- اذكر scope.
- اذكر side effect.
- أضف شرط استخدام مميز.
اجعل schema نفسها توجّه القرار
استخدم enums و required fields و descriptions لكل argument. تجنب object واسع باسم options يحوي أي شيء. المدخلات الضيقة تقلل التخمين.
أعد نتائج منظمة
Result يجب أن تحمل status و IDs وحقولًا قابلة لإعادة الاستخدام. إذا كانت الأداة asynchronous، أعد taskId بدل نص راجع لاحقًا. error codes جزء من discovery لأن Agent يتعلم متى يعيد المحاولة.
قائمة مراجعة
- stable IDs.
- status enum.
- error code.
- next-action hints عند الحاجة.
اختبر discovery بدون أمثلة مخفية
اعرض catalog على Agent في سيناريوهات متعددة وسجل tool selection. إذا يخلط بين أداتين، أصلح الاسم والوصف قبل إضافة Prompt خاص لكل حالة.
اختبر جودة ال ـCatalog بمهمة لا تعرف أدواتها مسبقًا
أنشئ benchmark من مهام مثل اقرأ عنوان التبويب أو التقط screenshot أو احفظ ملفًا، وقدّم لل Agent catalog فقط بدون أمثلة خاصة بكل Tool. سجل top choice وأي Tool بديلة حاولها. إذا احتاج prompt إضافيًا ليختار دائمًا، فالمشكلة غالبًا في الوصف أو overlap بين الأدوات. قارن قبل وبعد إعادة التسمية. هذا يحول تحسين Tool Discovery إلى قياس ويمكنه كشف أن إضافة أدوات جديدة خفضت دقة الاختيار بسبب تشابه descriptions.
قائمة مراجعة
- مهمة عمياء عن أسماء الأدوات.
- قياس first-choice accuracy.
- تحليل confusions بين Tools.
- إعادة الاختبار بعد تغير catalog.
قلل التداخل بين Tools بدل تحسين الوصف بلا نهاية
إذا كانت أداتان تفعلان 80% من الشيء نفسه، حتى وصف ممتاز لن يمنع الخلط دائمًا. راجع catalog دوريًا وابحث عن overlap: get_page و read_page و inspect_page مثلًا. ادمج الأدوات عندما يكون الفرق implementation detail، أو اجعل الفرق في الاسم والمدخلات حاسمًا إذا كانت semantics مختلفة. قياس confusion matrix من benchmark يحدد الأزواج المرشحة. Catalog أصغر وواضح غالبًا أفضل من عشرات wrappers الدقيقة التي تجبر Agent على فهم بنية داخلية لا تهم المهمة.
اختبار التحكم قبل منح الصلاحية
في «Tool Discovery في MCP: كيف تجعل الوكيل يفهم الأداة من الوصف فقط» اختبر النظام بأداة قراءة أولًا ثم أداة تغيير منخفضة المخاطر، مع تسجيل المدخل والقرار والنتيجة دون أسرار. افصل بين ما يستطيع النموذج اقتراحه وما يستطيع تنفيذه، وضع approval أو policy على الأفعال الحساسة. جرّب مدخلًا غامضًا ومدخلًا يحتوي تعليمات متعارضة، وتأكد أن حدود الصلاحيات لا تتغير بسبب صياغة المستخدم. القيمة هنا ليست في عدد الأدوات التي يستطيع ال ـAgent استدعاءها، بل في أن كل استدعاء يمكن تفسيره ومراجعته وإيقافه عند فشل شرط الأمان أو عدم اكتمال السياق.
قائمة مراجعة
- صلاحية دنيا لكل أداة.
- Approval للأفعال الحساسة.
- تسجيل القرار والنتيجة.
- اختبار تعليمات متعارضة.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…