الانتقال إلى المحتوى الرئيسي

واجهات الأدوات مشكلة مخطط: وسائط مُنمّطة قبل الأوامر الذكية

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

Vibrant backlit buttons on an electronic music controller for audio production.

الإخفاق يقع عادةً عند الحدّ

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

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

أين تفشل استدعاءات الأدوات فعلاً

ثلاثة أنماط تفسّر حصة غير متناسبة من استدعاءات الأدوات السيئة.

أسماء وسائط غامضة. حقل يُسمّى target أو value أو options يدعو النموذج إلى استنتاج المعنى من السياق. فينتج النموذج وسيطاً صحيحاً نحوياً وخاطئاً دلالياً. وتقبله الأداة. ويظهر الخطأ لاحقاً، غالباً كمشكلة بيانات في المصبّ لا كاستدعاء فاشل. أسماء مثل target_user_id وretention_days ليست مطوّلة؛ بل مُزيلة للغموض.

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

وسائط نصّية حرّة. وسيط نصّي بلا بنية يختزل القصد إلى نثر. والأداة لا تستطيع التحقق من النثر. والنموذج لا يمكن تصحيحه بالنثر. حقل يقبل "send the report to the team tomorrow morning" قد دفع منطق الجدولة إلى داخل رأس النموذج، حيث لا يكون قابلاً للفحص ولا للاختبار.

هذه ليست إخفاقات استدلال. بل إخفاقات تحديد تظهر في هيئة إخفاقات استدلال.

Interior view of a warehouse in Dar es Salaam with a shrink film machine and industrial equipment.

قواعد تصميم مخطط الأداة

ينبغي التعامل مع مخطط الأداة بالصرامة نفسها التي تُعامَل بها واجهة برمجية عامة، لأنه كذلك فعلاً.

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

الشروط المسبقة تُذكر في الوصف، لا تُفترض من السياق. إذا كانت الأداة تتطلب وجود مورد، أو نجاح استدعاء سابق، فذلك موضعه الوصف. النموذج لا يستنتج الشروط المسبقة من سجل المحادثة بشكل موثوق، ولا ينبغي أن يُطلب منه ذلك. وصف يقول "يتطلب معرّف جلسة نشطاً مُستحصلاً من open_session" هو تحديد. ووصف يقول "يفعل الشيء" هو أمنية.

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

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

لماذا لا تستطيع الأوامر التعويض

من المُغري كتابة أمر نظام أطول يشرح خصوصيات الأداة. لكن هذا لا يتوسّع، لثلاثة أسباب.

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

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

Detailed view of a retro arcade machine control panel with colorful buttons and joystick.

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

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

الترحيل والإصدارات

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

مقياسان يستحقان مكاناً في لوحة المتابعة الأساسية، إلى جانب زمن الاستجابة والتكلفة:

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

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

ما الذي يتغيّر عملياً

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

النقطة الأوسع أن موثوقية الوكيل في معظمها انضباط في الواجهة. فالنموذج الذي يستدلّ جيداً ضد واجهة غامضة سيظل ينتج استدعاءات غامضة. والنموذج الذي يستدلّ بشكل كافٍ ضد واجهة دقيقة سينتج استدعاءات يمكن فحصها ورفضها وتصحيحها. والنظام الثاني هو القابل للتشغيل.

مشاركةXLinkedInرابط دائم6 دقيقة قراءة

قراءات ذات صلة

الأسئلة التي يجيب عنها هذا

Why do agent tool calls fail even when the model reasons correctly?

Because the failure is often at the schema boundary, not in reasoning. Ambiguous parameter names, optional fields with no default, and free-text arguments all let the model produce plausible but wrong arguments that the tool accepts. The schema, not the prompt, decides whether those arguments can be validated.

Can a longer system prompt fix an unclear tool schema?

Not reliably. Instruction following degrades as context length and tool count grow, and prompt adherence is probabilistic. A schema is enforced on every call regardless of context, which makes it the more dependable place to encode the contract.

What metrics should track tool schema health?

Per-tool call success rate and argument-rejection rate, both broken down by tool rather than aggregated. A rising rejection rate points to an ambiguous schema or misleading description; a high success rate on calls that later produce wrong results points to validation that is too permissive.

How should tool schemas be versioned?

Like any API. Use versioned names, deprecation windows, and a period where old and new schemas both resolve, so agents and the evaluations built around them can migrate without breaking.