تضع نسخة Armor التجريبية من OpenRouter مصنّفًا للقواعد بين استدعاء الأداة الذي يقترحه النموذج والتطبيق الذي قد ينفذه. والتفصيل الحاسم لمطوّر الوكلاء هو الموضع الذي يوقف فيه الحكم التنفيذ فعليًا. ففي Chat Completions وResponses يستطيع Armor حجب استدعاء معلَّم. أما في وضع التوافق مع Claude Code ضمن واجهة Messages، فيبقى tool_use المعلَّم في الاستجابة، ويجب على العميل رفض تنفيذه.

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

التغيير الكبير

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

تتبّع الاستدعاء من الاقتراح إلى الحكم

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

تجيب مستويات القواعد عن أسئلة مختلفة. فالمطابقة مع hard_deny تمنع الاستدعاء بغض النظر عن قاعدة السماح أو طلب المستخدم. ويمكن إلغاء أثر المطابقة مع soft_deny بمطابقة مع allow أو بطلب المستخدم في المحادثة تنفيذ العملية نفسها بالضبط على الهدف نفسه بالضبط. وقاعدة allow لا تمنع استدعاءً بمفردها أبدًا. وتوثّق OpenRouter أيضًا منعًا مرنًا مدمجًا لحدّ وضعه المستخدم ولم يرفعه. ويقدّم المطوّرون حقائق، مثل مستودع موثوق أو هدف نشر، في environment؛ وقد تجعل الحقائق القديمة القاعدة أقل دقة. وتعرض كائنات القواعد المسماة معرّفًا واسمًا في الأحكام. وتبلغ القيم الافتراضية للعتبات الاختيارية 0.6 لقواعد المنع و0.7 لقواعد السماح.

يمنح مثال Responses الموثّق أداة bash قاعدة منع صارم لعملية git push. ومع output_mode: "custom_item"، يُستبدل بالدفع المعلَّم عنصر openrouter:armor_blocked يحتوي على الاستدعاء والسبب، تتبعه استجابة النموذج. ويعرض المثال ما تقول الوثائق إن الخدمة تعيده، وليس اختبارًا أجرته BIG CHANGE.

اختر عقد المخرجات قبل تنفيذ الأدوات

في Chat Completions وResponses، يزيل النمط الافتراضي text الاستدعاء المحظور ويضع علامة <openrouter_armor_blocked> في نص المساعد. وتدعم واجهة Responses أيضًا custom_item، الذي يعيد عنصرًا محظورًا ذا نوع محدد في الموضع الذي كان سيظهر فيه function_call. وتقول الوثائق إنه يجب إعادة إرسال ذلك العنصر من دون تغيير ضمن إدخال Responses التالي، وعدم إنشاء function_call_output منفصل له. ويسجّل safeguard_results الأحكام بحسب معرّف الاستدعاء.

يختلف السلوك الافتراضي لواجهة Messages اختلافًا جوهريًا عندما يتضمن الطلب safeguards: إذ يُبقي claude_code_compatibility على tool_use المعلَّم داخل content[]، ويضيف نتيجته flagged إلى safeguard_results. يجب على التطبيق قراءة هذه النتيجة ورفض تنفيذ الاستدعاء. وتحذّر OpenRouter صراحة من أن عميل Messages الذي يتجاهل الحكم سينفذ استخدام الأداة المعلَّم. ويمكن للمطوّر الذي لا يملك التحكم في العميل طلب output_mode: "text" على Messages، كي تحجب OpenRouter الاستدعاء. ويؤدي طلب نمط مخرجات لا تستطيع الواجهة تمثيله إلى استجابة 400.

يستخدم الوضع التلقائي في Claude Code عبر إطار Ori metaharness من OpenRouter عقد Messages من دون إدخال إضافي لإضافة Armor. وتقول الوثائق إن Claude Code يرفض الاستدعاءات المعلَّمة، ويكتب نتيجة خطأ في سجل المحادثة، ويسمح للنموذج بالمتابعة. وتقول أيضًا إن نقطة نهاية Anthropic التي تدعم مصنّفها تستطيع توفير حكم يُمرر مباشرة، بينما يتولى Armor التقييم على نقاط النهاية الأخرى. وهذا هو سلوك التكامل الموثّق، وليس ادعاءً بأن كل عميل تابع لطرف ثالث يطبقه بصورة صحيحة.

اضبط مجموعة قواعد ضيقة النطاق وافحصها

بالنسبة إلى وكيل مخصص، يضع دليل Armor إدخال armor في plugins، مع classifier_context ذي إصدار محدد (v: 1)، وقواعد auto_mode وحقائق اختيارية عن البيئة. ابدأ بالفعل والمورد المحمي اللذين ينبغي للقاعدة التعرف إليهما، ثم اختر المنع الصارم لحظر يجب أن يبقى رغم موافقة المستخدم، أو المنع المرن حين تستطيع موافقة محددة أو قاعدة سماح مسماة رفعه بصورة مشروعة. وتنصح الوثائق بوصف الفعل بدلًا من طريقة واحدة لكتابة أمر، وبإبقاء حقائق البيئة محدثة.

يعمل النمط الافتراضي enforce بناءً على الأحكام. ويبلّغ audit الأحكام نفسها، لكنه يمرر كل الاستدعاءات، بما فيها المعلَّمة. وهذه وسيلة لفحص حركة استخدام حقيقية وتعديل القواعد قبل إنفاذها، وليست نمط حماية. ولا يمكن الجمع بين التدقيق و claude_code_compatibility. وفي كلا النمطين، اقرأ safeguard_results: فالقيمة not_flagged تعني السماح، و flagged تحدد قاعدة مطابقة، و unavailable تعني فشل التقييم، و skipped تحدد أداة أصلية لدى المزوّد لم تخضع للتقييم. وعند البث، يصل كائن الحكم في نهاية الاستجابة، لذا يجب على عميل Messages انتظاره قبل تنفيذ استخدام أداة.

تحدد OpenRouter on_error: "block" بوصفه الخيار الافتراضي عندما تنتهي مهلة المصنّف أو يقع خطأ أو يعجز عن معالجة طلب أكبر من اللازم؛ أما on_error: "log" فيمرر الاستدعاء. وفي وضع التوافق مع Claude Code، يُمرر استدعاء unavailable مع إظهار الحكم. وتُتخطى أدوات الخادم الأصلية لدى المزوّد افتراضيًا، إلا إذا أجبرها evaluate_native_tools على الخروج من المسار الأصلي للتقييم. وينبغي أن تشمل مراجعة التكامل لدى الفريق هذه الإعدادات والمسار الفعلي للأداة؛ فوجود إدخال Armor وحده لا يثبت تقييم كل أداة.

تكلفة النسخة التجريبية وسرعتها وحدود تغطيتها

تفيد OpenRouter بأن التقييم أضاف 279 ملي ثانية عند الوسيط و334 ملي ثانية عند المئين التسعين مع تحميل مجموعة قواعدها المتوافقة مع Claude Code. وهذه قياسات أبلغ عنها المزوّد في ذلك الشرط المحدد، وليست اختبارًا معياريًا لوكيل معين أو لكل مجموعة قواعد. ويُقيَّم كل استدعاء مرة واحدة قبل تمريره أو منعه. ولا تُفرض رسوم على التقييم خلال النسخة التجريبية؛ وتقول OpenRouter إنها ستعلن الأسعار قبل الإتاحة العامة. ولا تحدد الوثائق تعرفة مستقبلية.

قد ينتج نموذج القرار إنذارات كاذبة وحالات يفوت رصدها، لأنه يقارن قواعد مكتوبة بلغة عادية بوسائط مكتوبة بلغة عادية. وتنصح الوثائق باستخدام أحكام التدقيق على حركة استخدام فعلية وضبط عتبات القواعد الفردية. ولا يُدعم تقييم Armor بعد لطلبات HIPAA أو Zero Data Retention أو الطلبات المقيدة بمنطقة بيانات. ويحصل طلب تُفعّل فيه الإضافة ضمن أحد هذه السياقات على 403؛ أما طلب Claude Code فيمرر الاستدعاء بوصفه unavailable، ثم يعود Claude Code إلى التقييم المحلي للوضع التلقائي. ويشمل تحذير النسخة التجريبية أيضًا تغييرات حقول الإعداد، و safeguard_results ونوع العنصر openrouter:armor_blocked.

يفحص Armor الاستدعاءات المقترحة عند تسليمها من النموذج إلى التطبيق. وهذا يجعله آلية مختلفة عن احتواء الأوامر MXC من Microsoft و ضوابط التشغيل OpenShell وSentry من NVIDIA، التي تفرض القيود حول عبء العمل أو إمكانية وصوله. وبالنسبة إلى Armor، فإن قرار التطبيق المباشر هو ما إذا كانت صيغة الاستجابة المختارة تحجب استدعاءً معلَّمًا أم تتطلب من العميل إيقافه.

المصادر وقراءات إضافية

  • وثائق OpenRouter Armor، جرى الاطلاع عليها في 17 أكتوبر 2026. مصدر أولي لحالة النسخة التجريبية، وتسلسل المصنّف، وأولوية القواعد، وعقود استجابة الواجهة، وسلوك الأخطاء، واستثناءات سياقات الخصوصية، وزمن الاستجابة المُبلغ عنه، ورسوم النسخة التجريبية. وهذه ادعاءات موثّقة من OpenRouter؛ ولم تشغّل BIG CHANGE الإضافة.
  • مقال BIG CHANGE عن Microsoft MXC يشرح الاحتواء القائم على السياسات للأوامر التي يولّدها الوكلاء. وهو يصف طبقة إنفاذ منفصلة، وليس مرحلة سابقة من Armor.
  • مقال BIG CHANGE عن NVIDIA OpenShell وSentry يصف ضوابط الوصول البرمجية وتصميمًا اختياريًا للمراقبة بالعتاد. وهو سياق ذو صلة، وليس استمرارًا مباشرًا لهذه الميزة من OpenRouter.