كم عدد الأدوات التي يمكن لعميل AI التعامل معها؟ (بيانات 2026)

لا يوجد حد واحد ثابت، ولكن الإرشادات المنشورة تتراوح بين 20 و50 أداة: توثق Anthropic تدهور الأداء بعد 30-50 أداة، بينما توصي OpenAI بأقل من 20 أداة في كل دورة. كما قياس دراسة أجريت في يونيو 2026 على كتالوج يحتوي على 584 أداة، حيث انخفضت دقة التوجيه بمقدار 16-23 نقطة.

ملخص

• الموردون نشروا أرقاماً محددة. تذكر وثائق بحث الأدوات الخاصة بـ Anthropic أن "قدرة Claude على اختيار الأداة الصحيحة تتدهور بمجرد تجاوز 30-50 أداة متاحة".¹ أما دليل استدعاء الدوال (function calling) من OpenAI فينصح بالهدف من "توفير أقل من 20 دالة في بداية الدورة"، واصفاً ذلك بأنه اقتراح مرن.²
• الحدود القصوى لـ API أعلى بكثير من الحدود المفيدة عملياً. يقبل Gemini ما يصل إلى 128 تعريف دالة لكل طلب؛³ بينما يقبل بحث الأدوات في Anthropic ما يصل إلى 10,000 أداة مؤجلة لكل طلب.¹ ولا يخبرك أي من هذين الرقمين أين تبدأ الدقة في الانهيار.
• أحد القياسات استخدم كتالوج إنتاج حقيقي. قام باحثون في Superhuman, Inc. بتقييم ثلاثة نماذج رائدة مقابل كتالوج يضم 110 عملاء (agents) و584 أداة مستمدة من مساعد مؤسسي مُنشر، ووجدوا أن مقياس F1 للتوجيه في الطلبات غير المحددة بدقة انخفض بمقدار 16-23 نقطة مئوية مع توسع الكتالوج.⁴
• التحميل المؤجل يساعد، لكنه لا يسد الفجوة. وجدت الدراسة نفسها أنه حتى مع استرجاع مثالي، فإن سقف "الأوراكل" (oracle ceiling) انخفض بنحو 10 نقاط — وهي "فجوة ارتباك" لا يمكن للبحث الأفضل إصلاحها.⁴

ما ستتعلمه

• أرقام عدد الأدوات التي تنشرها Anthropic وOpenAI، ولماذا تعتبر هذه الادعاءات من أنواع مختلفة
• لماذا تؤدي زيادة الأدوات إلى تدهور أداء العميل الذكي من خلال آليتين منفصلتين، وليس آلية واحدة
• التكلفة الفعلية لتعريفات أدوات MCP من حيث الـ tokens، باستخدام تحليل Anthropic التفصيلي لكل خادم
• المنصات التي توثق فعلياً الحد الأقصى لعدد الأدوات — ولماذا أن رقم 128 المقتبس بكثرة عن OpenAI على وشك أن يتوقف عن كونه صحيحاً
• كيف يعمل بحث الأدوات و defer_loading، وتقليل الـ tokens الذي قيسته Anthropic
• لماذا يحسن بحث الأدوات من الدقة ولكنه لا يحل مشكلة دقة الاختيار — فجوة الارتباك
• متى يتفوق تقسيم الأدوات عبر عملاء فرعيين على عملية القائمة المختصرة، ومتى لا يفعل ذلك
• متى يكون تنفيذ الكود باستخدام MCP هو الحل الأفضل، والتكلفة الأمنية التي تصاحبه
• طريقة ملموسة لقياس دقة اختيار الأدوات في العميل الذكي الخاص بك بدلاً من التخمين

كم عدد الأدوات التي يمكن للعميل الذكي التعامل معها قبل أن تنخفض الدقة؟

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

تصف وثائق بحث الأدوات الخاصة بـ Anthropic نقطة فشل ملحوظة: "قدرة Claude على اختيار الأداة الصحيحة تتدهور بمجرد تجاوز 30-50 أداة متاحة."¹ أما دليل استدعاء الدوال من OpenAI فيقدم توصية بدلاً من قياس محدد — حيث يدرج "الحفاظ على عدد صغير من الدوال المتاحة في البداية لتحقيق دقة أعلى" كأفضل ممارسة، ويقترح استهداف "أقل من 20 دالة متاحة في بداية كل دورة في أي وقت، رغم أن هذا مجرد اقتراح مرن."² لا تعرض أي من الصفحتين التقييم الذي استُخرج منه هذا الرقم، لذا من الأفضل قراءتهما كقواعد تقريبية من الموردين بدلاً من نتائج قابلة للتكرار.

الفجوة بين الرقمين ليست بالضرورة خلافاً. إحدى القراءات المنطقية — وهذا تفسير وليس شيئاً صرح به أي من الموردين — هي أن العدد الخام هو وحدة قياس ضعيفة في المقام الأول، لأن مدى "قابلية الخلط" بين أدواتك يهم أكثر من عددها. تلمح Anthropic إلى ذلك عندما تسمي نمط الفشل مباشرة، مستشهدة بأسماء أدوات متشابهة مثل notification-send-user مقابل notification-send-channel كمصدر شائع لاختيار الأداة الخاطئة.⁵

لذا فإن الإجابة العملية على عدد الأدوات التي يمكن لوكيل الذكاء الاصطناعي التعامل معها هي: اعتبر النطاق من 20-50 هو المدى الذي يجب أن تبدأ فيه القياس، وليس النقطة التي تنهار عندها الأمور فجأة.

لماذا تجعل زيادة الأدوات وكيل الذكاء الاصطناعي أسوأ؟

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

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

الآلية الثانية هي الجزء الأكثر إثارة للاهتمام، ومن السهل إغفالها لأنها تظل قائمة رغم كل تحسينات السياق التي تقوم بها. قامت دراسة Superhuman في يونيو 2026 بتحليل التدهور باستخدام تحليل "الأوراكل" (oracle analysis): فصل فجوة "الاسترجاع" (النموذج لا يرى الأداة الصحيحة أبداً) عن فجوة "الارتباك" (النموذج يرى الأداة الصحيحة ومع ذلك يختار أداة أخرى). حتى عندما كان من المضمون وجود الأداة الصحيحة في مجموعة المرشحين، انخفض سقف الأوراكل بنحو 10 نقاط مئوية مع نمو الكتالوج.⁴ تشير الورقة إلى أن فجوة الارتباك العملية من المرجح أن تكون أكبر، لأن المسترجع الحقيقي يظهر مشتتات "متشابهة دلالياً"، والتي يصعب التمييز بينها أكثر من المشتتات العشوائية المستخدمة في إعدادات الأوراكل.⁴

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

كم عدد الرموز (tokens) التي تستهلكها تعريفات أدوات MCP فعلياً؟

حوالي 55,000 توكن لإعداد واقعي يتكون من خمسة خوادم — على الرغم من أن تكلفة كل أداة تختلف بشكل كبير. نشرت Anthropic تفصيلاً لكل خادم:⁵

تستهلك ثمانٍ وخمسون أداة حوالي 55 ألف توكن قبل حتى أن تبدأ المحادثة.⁵ تستخدم وثائق Anthropic نفس الإعداد ونفس الرقم التقريبي 55 ألف.¹ أضف Jira — حوالي 17 ألف توكن بمفرده — وسترتفع التكاليف الإضافية نحو ستة أرقام.⁵ أسوأ حالة داخلية لدى Anthropic: "لقد رأينا تعريفات الأدوات تستهلك 134 ألف توكن قبل التحسين."⁵

لاحظ التفاوت داخل هذا الجدول: يساهم Slack بحوالي 21 ألف توكن من 11 أداة (حوالي 1,900 لكل منها) بينما يساهم Sentry بحوالي 3 آلاف من 5 أدوات (حوالي 600 لكل منها). لا تشرح Anthropic هذا الاختلاف، ولكن أياً كان السبب — حجم المخطط (schema)، عدد المعاملات، أو طول الوصف — فإن النتيجة العملية واحدة: تكلفة التوكن لكل أداة تختلف بأكثر من 3 أضعاف عبر الخوادم الحقيقية، لذا فإن مجرد عد الأدوات لا يخبرك بالكثير عن التكلفة الفعلية لتعريفاتك. قم بقياس التوكنز.

تعريفات الأدوات هي مجرد نصف القصة فيما يتعلق بالسياق — فنتائج الأدوات الوسيطة تتراكم أيضاً. مثال Anthropic لنص اجتماع مدته ساعتان يمر عبر السياق مرتين يضيف 50,000 توكن إضافية لسير عمل واحد.⁶ إذا كنت تدير ميزانية سياق العميل (agent) بشكل أوسع، فإن شرحنا لـ أداة ذاكرة Claude وواجهات برمجة تطبيقات تحرير السياق (context-editing APIs) يغطي جانب النتائج في هذه المعادلة.

ما هو الحد الأقصى لعدد الأدوات التي يسمح بها كل API؟

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

هناك ملاحظتان على هذا الجدول. صف OpenAI هو الأكثر اقتباساً كـ "حد OpenAI البالغ 128 أداة"، ولكنه يخص Assistants API، والتي قامت OpenAI بإلغائها — حيث تنص وثائقها الخاصة على أن API "سيتوقف عن العمل في 26 أغسطس 2026"، أي بعد حوالي خمسة أسابيع من هذا المنشور.⁷ ولا ينشر دليل استدعاء الدوال الحالي من OpenAI حداً أقصى مماثلاً؛ بل يقدم توصية بأقل من 20 أداة بدلاً من ذلك.² إذا كنت تقرأ مقالاً من حقبة 2024 يستشهد بـ 128 كحد أدوات OpenAI، فتحقق من أي API يقصده.

الملاحظة الثانية أكثر أهمية. الفجوة بين أي من هذه الحدود ونطاق الدقة (20-50) هي جوهر الموضوع. الطلب الذي يحتوي على 128 تعريف دالة هو استدعاء API صالح تماماً سيتم قبوله، ومحاسبته، والإجابة عليه — ومع ذلك قد يتم توجيهه إلى الأداة الخطأ. اجتياز التحقق من المخطط (schema validation) ليس هو نفسه أن يكون الاستخدام عملياً.

يأتي حد الـ 10,000 أداة من Anthropic مع متطلب هيكلي يستحق المعرفة: يجب أن تكون أداة واحدة على الأقل مضبوطة على defer_loading: false، وعادة ما تكون أداة بحث الأدوات نفسها. الطلب الذي تكون فيه جميع الأدوات مؤجلة يعيد خطأ 400.¹

ما هو بحث الأدوات، وبكم يقلل من عدد التوكنز (tokens)؟

يقوم بحث الأدوات بتأجيل معظم تعريفات الأدوات خارج السياق الأولي ويحمل فقط ما يحتاجه طلب معين — وقد قيست Anthropic انخفاضاً في التوكنز بنسبة 85%. بدلاً من حقن جميع التعريفات مسبقاً، تقوم بإرسال الكتالوج الكامل إلى API ولكنك تحدد معظم الإدخالات كـ defer_loading: true. يرى Claude فقط أداة البحث بالإضافة إلى أدواتك غير المؤجلة، ثم يبحث عندما يحتاج إلى المزيد.¹

{
  "tools": [
    { "type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex" },
    {
      "name": "github_create_pull_request",
      "description": "Create a pull request in a GitHub repository",
      "input_schema": { "type": "object", "properties": { "repo": { "type": "string" } } },
      "defer_loading": true
    }
  ]
}

توزيع Anthropic المنشور لإعداد MCP يحتوي على أكثر من 50 أداة: النهج التقليدي يستهلك حوالي 77 ألف توكن من السياق قبل بدء أي عمل، بينما مع بحث الأدوات تكلف أداة البحث حوالي 500 توكن والأدوات الـ 3-5 التي يتم اكتشافها عند الطلب تكلف حوالي 3 آلاف، بإجمالي حوالي 8.7 ألف — وهو ما تقول Anthropic إنه يحافظ على 95% من نافذة السياق.⁵ وتصف Anthropic بشكل منفصل هذا التوفير بأنه "انخفاض بنسبة 85% في استخدام التوكنز"،⁵ وتكرر وثائقها هذا الرقم: بحث الأدوات "يقلل عادةً من هذا بنسبة تزيد عن 85 بالمائة، حيث يتم تحميل الأدوات الـ 3-5 التي يحتاجها Claude فقط لطلب معين".¹ (الصياغتان لا تتطابقان تماماً — 8.7 ألف مقابل 77 ألف تقترب من 89% — لذا تعامل مع نسبة 85% كعنوان تحفظي من المورد بدلاً من رقم مشتق من هذين الرقمين.)

تحسنت الدقة أيضاً في تقييمات MCP الداخلية لشركة Anthropic: حيث ارتفع Opus 4 من 49% إلى 74%، وOpus 4.5 من 79.5% إلى 88.1%، مع تفعيل خاصية البحث عن الأدوات (tool search).⁵

هناك تفصيلان حول الحالة من السهل الخلط بينهما. تم إطلاق البحث عن الأدوات في النسخة التجريبية (beta) في 24 نوفمبر 2025 خلف ترويسة advanced-tool-use-2025-11-20؛⁵ وتصف وثائق Anthropic الآن هذه الميزة بأنها متاحة بشكل عام على Claude API.¹ وهذه ليست فكرة حصرية لمزود واحد — حيث توفر OpenAI خاصية tool_search الخاصة بها، والمدعومة في gpt-5.4 والموديلات الأحدث.² أما النسخة الأكاديمية فكانت تسبق كليهما: حيث اقترحت ورقة RAG-MCP البحثية، المنشورة في 6 مايو 2025، استرجاع الأدوات ذات الصلة قبل استدعاء الموديل، وأفادت بتقليل توكنات المطالبة (prompt tokens) بنسبة تزيد عن 50% مع مضاعفة دقة اختيار الأدوات أكثر من ثلاث مرات، من خط أساس 13.62% إلى 43.13%.⁸

بالنسبة لخوادم MCP تحديداً، يمكنك ضبط التأجيل (deferral) مرة واحدة على مجموعة الأدوات بدلاً من ضبطها لكل أداة على حدة:

{
  "type": "mcp_toolset",
  "mcp_server_name": "google-drive",
  "default_config": { "defer_loading": true },
  "configs": { "search_files": { "defer_loading": false } }
}

توصي Anthropic بإبقاء أكثر 3-5 أدوات استخداماً غير مؤجلة حتى لا تضطر العمليات الشائعة إلى دفع تكلفة رحلة بحث ذهاباً وإياباً في البداية.¹ كما يتم استبعاد الأدوات المؤجلة من بادئة مطالبة النظام (system-prompt prefix)، وبذلك يظل تخزين المطالبات مؤقتاً (prompt caching) فعالاً — ومع ذلك، فإن الأداة التي تحمل علامة defer_loading: true لا يمكنها أيضاً حمل cache_control، وهو ما يؤدي إلى إرجاع خطأ 400.¹

هل يحل البحث عن الأدوات مشكلة دقة اختيار الأدوات؟

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

قارنت دراسة Superhuman بين أربعة مناهج عبر 51-584 أداة، باستخدام GPT-5.4 وGPT-5.1 وClaude Sonnet 4.5 كموديلات توجيه (routing models). عند النطاق الكامل، ومع توجيه GPT-5.4، وصلت القائمة المختصرة للتضمينات على مستوى الأداة (tool-level embedding shortlisting) إلى 52.5%، ووصل البحث عن أدوات المنصة إلى 50.3%، بينما وصل التوجيه المسطح (flat routing) بدون قائمة مختصرة إلى 42.1%.⁴ ومن الواضح أن القوائم المختصرة هي المتفوقة.

لكن السقف الذي تتفوق عليه لا يزال بعيداً جداً عن نقطة البداية. فقد انخفض التوجيه المسطح من 58.2% (F1) عند 51 أداة إلى 42.1% عند 584 أداة، وكان هذا الانخفاض مدفوعاً بالاستدعاء (recall): حيث انزلقت الدقة (precision) من 68% إلى 60% بينما انخفض الاستدعاء بسرعة تزيد عن الضعف، من 55% إلى 37%.⁴

ولاستبعاد احتمالية أن يكون مزيج الاستعلامات هو التفسير، أعاد المؤلفون تقييم مجموعة ثابتة من 731 استعلاماً موجودة في كل نقطة نطاق. تدهورت تلك المجموعة بمقدار 14.9 نقطة تقريباً (من 58.2% إلى 43.3%)، وهو ما اعتبرته الورقة تأكيداً على أن التدهور يتتبع نمو الكتالوج وليس تغير تكوين الاستعلامات.⁴

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

هناك نتيجة تستحق اهتماماً خاصاً لأنها تتعارض مع خيار تكوين بديهي. في نفس الدراسة، أدى نظام تصفية BM25 أداءً أسوأ من عدم استخدام التصفية على الإطلاق — 32.8% مقابل 42.1% عند 584 أداة، وكان أقل من التوجيه المسطح (flat routing) عند كل نقطة مقياس تم اختبارها. والسبب المذكور هو أن أدوات الإنتاجية في الشركات تتشارك في المفردات عبر الوكلاء، مما يجعل المطابقة المعجمية غير فعالة.⁴

كن حذراً في مدى تعميم هذه النتيجة. نظام BM25 الذي اختبرته الورقة كان تنفيذ التصفية الخاص بها عند k=20، وتم تقييمه كحالة منفصلة عن صف "بحث أدوات المنصة" — لذا فهذا دليل على الاسترجاع المعجمي كتقنية، وليس معياراً لأي نسخة بحث محددة من مورد معين. توفر Anthropic نسخة بحث أدوات BM25 إلى جانب نسخة regex الخاصة بها،¹ وتعطيك الورقة سبباً لتقييم الخيار المعجمي بدلاً من افتراض نجاحه، خاصة في الكتالوجات التي تصف فيها العديد من الأدوات إجراءات متشابهة على كائنات مختلفة. دراسة واحدة، مجال واحد — قم بقياس ذلك مقابل أدواتك الخاصة قبل الاعتماد النهائي.

يشير تقييم سابق إلى نفس الاتجاه بشأن كون الاسترجاع هو عنق الزجاجة. LiveMCPBench، الذي نُشر في أغسطس 2025، اختبر 95 مهمة واقعية عبر 70 خادماً و 527 أداة ووجد أن "أخطاء الاسترجاع تمثل ما يقرب من نصف جميع حالات الفشل".⁹ في ذلك المعيار، حقق Claude Sonnet 4 نسبة نجاح في المهام بلغت 78.95% بينما استقرت معظم النماذج الـ 12 المختبرة عند 30-50%.⁹ لقد تطورت مجموعة النماذج منذ ذلك الحين، ولكن توزيع الفشل — الاسترجاع، وليس التفكير — هو النتيجة المستمرة.

هل يجب عليك تقسيم الأدوات عبر وكلاء متعددين بدلاً من ذلك؟

أحياناً — ولكن الميزة المقاسة مقارنة بالتصفية المسطحة أصغر مما توحي به تكلفة البنية التحتية. تقسيم كتالوج كبير إلى وكلاء فرعيين متخصصين خلف موجه (router) هو الحل البديهي، وتجعل أطر عمل التنسيق (orchestration frameworks) من السهل اللجوء إليه.

بيانات Superhuman تعقد هذا الحدس. عند 584 أداة، تقاربت النهج على مستوى الحزم (pack-level) بشكل وثيق: وصل بحث أدوات المنصة إلى 50.3%، وتضمين مستوى الحزمة (pack-level embedding) إلى 49.1%، والتوجيه الهرمي LLM إلى 47.9% — جميعها في نطاق 2.4 نقطة من بعضها البعض.⁴ وفي الوقت نفسه، تفوق الاسترجاع على مستوى الأدوات باستمرار على كل نهج على مستوى الحزم، بما في ذلك التوجيه الهرمي LLM.⁴ تجميع الأدوات في وكلاء والتوجيه بين الوكلاء لم يتفوق على مجرد استرجاع الأدوات الفردية الصحيحة.

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

من الجدير بالذكر كيف نما النظام البيئي المحيط، حيث إنه يشكل ما يظهر في كتالوجك: أظهر تحليل لـ 177,436 أداة عميل (agent tools) تم نشرها في مستودعات خوادم MCP العامة بين نوفمبر 2024 وفبراير 2026 أن تطوير البرمجيات يمثل 67% من جميع أدوات العملاء و90% من عمليات تحميل خوادم MCP، مع ارتفاع حصة أدوات "الإجراءات" (action tools) من 27% إلى 65% من الاستخدام خلال فترة العينة.¹⁰ هذه أرقام على مستوى النظام البيئي ككل وليست قياسات لأي عميل واحد، ولكن الاتجاه مهم عندما تقرر ما الذي ستقوم بربطه: الأدوات المتاحة للإضافة هي بشكل متزايد أدوات تنفذ أشياء بدلاً من مجرد قراءتها، مما يرفع تكلفة استدعاء أداة خاطئة.

متى يكون تنفيذ الكود باستخدام MCP هو الحل الأفضل؟

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

تشير Anthropic إلى أن تقديم خوادم MCP كـ API كود على نظام ملفات — مما يسمح للعميل بقراءة ملفات الأدوات التي يحتاجها فقط — خفض استهلاك أحد سير العمل من 150,000 توكن إلى 2,000 توكن، وهو توفير بنسبة 98.7%.⁶ بالنسبة لـ Programmatic Tool Calling، وهي ميزة على مستوى API مبنية على نفس الفكرة، تفيد الاختبارات الداخلية لشركة Anthropic بأن متوسط استخدام التوكنز انخفض من 43,588 إلى 27,297 في مهام البحث المعقدة (انخفاض بنسبة 37%) وارتفع أداء معيار GAIA من 46.5% إلى 51.2%.⁵ كل هذه الأرقام هي بيانات أبلغ عنها المورد من تقييمات Anthropic الخاصة، وليست عمليات تكرار مستقلة.

المقايضة الأمنية حقيقية وتأتي من كلا الاتجاهين. يحذر منشور Anthropic نفسه من أن "تشغيل الكود الذي يولده العميل يتطلب بيئة تنفيذ آمنة مع عزل مناسب للموارد، وقيود على الموارد، ومراقبة".⁶ وكانت دراسة أكاديمية في فبراير 2026 حول خيارات تصميم MCP أكثر صراحة: حيث أكدت أن MCP الخاص بتنفيذ الكود "يقلل بشكل كبير من استخدام التوكنز وزمن استجابة التنفيذ" ولكنه "يؤدي إلى توسيع سطح الهجوم بشكل كبير"، وحددت ستة عشر فئة من الهجمات عبر خمس مراحل تنفيذ — بما في ذلك حقن الكود عبر الاستثناءات وتوليف القدرات غير الآمنة — واقترحت العزل في حاويات (containerized sandboxing) بالإضافة إلى البوابات الدلالية (semantic gating) كحلول للتخفيف.¹¹

لذا فإن قاعدة القرار ليست "تنفيذ الكود أفضل". بل هي: إذا كانت تعريفات الأدوات هي مشكلة التوكنز لديك، فقم بتأجيلها؛ وإذا كانت نتائج الأدوات هي مشكلة التوكنز، فقم بالتنفيذ في الكود واقبل بأنك الآن مسؤول عن إدارة بيئة معزولة. وبالنظر إلى مدى تغير السطح الأمني لـ MCP مؤخرًا — انظر تحليلنا لـ تطوير بروتوكول MCP عديم الحالة وتفويض المؤسسات — فإن الخيار الثاني يمثل التزامًا حقيقيًا في البنية التحتية، وليس مجرد مفتاح إعدادات.

كيف تقيس دقة اختيار الأدوات في العميل الخاص بك؟

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

تعتبر منهجية Superhuman نموذجاً جيداً لأنها قابلة للتكرار على نطاق صغير. لقد قاموا بالتقييم عند نقاط نطاق ثابتة — 10، 20، 30، 40، 60، 80، 100، و110 عملاء (agents)، تغطي من 51 إلى 584 أداة — بحيث يمكن إرجاع التدهور في الأداء إلى حجم الكتالوج بدلاً من صعوبة المهمة، وتم التحقق من النتائج الاصطناعية مقابل 1,435 عبارة إنتاجية مصنفة بشرياً وقام بتقييمها ثلاثة مدققين. وفي حركة المرور الحقيقية، تكرر استرداد القائمة المختصرة (shortlisting recovery) بزيادة +10–17 نقطة، رغم أن الأداء المطلق كان أقل بـ 10–15 نقطة مما كان عليه في الإعداد الاصطناعي.⁴

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

يبدو الهيكل الأدنى (minimal harness) على النحو التالي:

# tool_routing_eval.py — score tool selection as the catalog grows
CASES = [
    {"utterance": "file a bug about the login 500s", "expected_tool": "jira_create_issue"},
    {"utterance": "who's on call right now?",        "expected_tool": "pagerduty_get_oncall"},
    # ...at least a few dozen, weighted toward under-specified phrasing
]

def score(catalog_size: int) -> float:
    hits = 0
    for case in CASES:
        called = run_agent(case["utterance"], tools=catalog[:catalog_size])
        hits += int(called == case["expected_tool"])
    return hits / len(CASES)

for n in (10, 25, 50, 100, len(catalog)):
    print(f"{n:>4} tools -> {score(n):.1%}")

قم بتسجيل الإجابات الخاطئة}، وليس النتيجة فقط. إذا كانت الإخفاقات تتجمع حول أزواج من الأدوات ذات الأسماء المتشابهة، فلديك مشكلة ارتباك ولن ينقذك نظام القائمة المختصرة — بدلاً من ذلك، قم بتغيير الأسماء والدمج. أما إذا كانت الإخفاقات في حالات لم تدخل فيها الأداة الصحيحة أبداً في مجموعة المرشحين، فلديك مشكلة استرجاع (retrieval)، ويكون التحميل المؤجل أو القائمة المختصرة القائمة على التضمين (embedding shortlisting) هو الحل الصحيح. تفعيل هذا الأمر أسهل بكثير إذا كان العميل الخاص بك يصدر بالفعل spans لكل استدعاء أداة؛ يغطي دليلنا حول تتبع استدعاءات أدوات Claude agent باستخدام OpenTelemetry هذه التوصيلات. وإذا كنت ترغب في بناء نظام القائمة المختصرة القائم على التضمين الذي حقق أعلى نتيجة في مقارنة Superhuman، فإن مخزن متجهات مدعوم بـ Postgres باستخدام pgvector هو مكان مناسب للبدء.