كيف يفحص OrcaRouter كل طلب

تجلس البوابة بين وكيلك وكل نموذج يستدعيه. هذا يجعلها النقطة الوحيدة التي ترى كل استدعاء بصرف النظر عن المزود — كل مطالبة واستجابة واستدعاء أداة وكل طلب خارجي يوجّهه وكيلك من خلالها — بغض النظر عن أي SDK أصدر الاستدعاء. نقطة الاختناق هذه هي مكان الفحص والتطبيق. (ما لا تستطيع رؤيته — أداة تعمل بالكامل داخل عمليتك ولا تعبر البوابة قط — مغطى في §4.) تشرح هذه الصفحة بالضبط ما يمكن للبوابة رؤيته وما لا تستطيعه، وكيف يعمل الكشف، وكيفية سد الثغرات.

​

1. لماذا البوابة هي نقطة الفحص الصحيحة

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

• حواجز الحماية تفحص النص — المطالبة التي يُرسلها وكيلك والاستجابة التي يُعيدها النموذج. guardrail_blocked يُعيد HTTP 400 guardrail_blocked ولا يكلّف رصيداً.
• جدار الحماية يحكم الإجراءات — الأدوات التي يستدعيها الوكيل وخوادم MCP التي يصل إليها والوجهات الشبكية التي يُبلّغ عنها. الرفض يُعيد HTTP 400 firewall_blocked على سطح inbound، أو خطأ أداة على سطح MCP، حتى يرى النموذج الرفض ويتمكن من التفكير فيه.

كلا الطبقتين تُضبطان مرة واحدة في مساحة عملك وتُربطان بمفتاح API. لا إعادة نشر. لا تغيير SDK. يستمر وكيلك في استدعاء https://api.orcarouter.ai/v1 تماماً كما كان.

​

2. أسطح التطبيق الأربعة

يُقيَّم جدار الحماية كل استدعاء أداة مقابل سطح واحد بالضبط — النقطة في دورة حياة الاستدعاء التي تراه فيها البوابة. تُضيف حواجز الحماية مرحلتَي نص إضافيتَين تتطبّقان فوق الأسطح أعلاه: input (مطالبة الطلب والرسائل) وoutput (نص استجابة النموذج). طلب واحد يمكن أن يمر عبر جميعها.

​

3. الكشف عند الاستخدام الأول

هذا يعني أن أداة جديدة تهبط في عرض Discovered tools في اللحظة التي تظهر في طلب، حتى لو لم تسمّها أي قاعدة. فعّل وضع observe لتسجيل كل استدعاء أداة لا تطابقه قاعدة كثغرة تغطية — هذا العرض يقود تأليف السياسة من حركة المرور الحقيقية.

​

4. ما لا تستطيع البوابة رؤيته

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

​

5. التبويب حسب الدور على بيانات الفحص

الوصول إلى أسطح الفحص يخضع للنطاق حسب الدور داخل مساحة عملك:

​

6. إلى أين تذهب بعد ذلك

البوابة هي نقطة الفحص الوحيدة لكل استدعاء يعبرها — اضبط سياساتك مرة واحدة وكل مزود وكل وكيل وكل استدعاء أداة تكون مغطى.