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

​
1. قاطع دائرة الإنفاق لكل تشغيل

cap_cost حكم قاعدة تؤلّفه بحقل إضافي واحد — cap_cost_cents، سقف إنفاق التشغيل بسنتات USD. عندما تطابق القاعدة استدعاء أداة، يقارن المحرك الإنفاق المتراكم لتشغيل الوكيل بذلك السقف:
  • تحت السقف ← يُسمح بالاستدعاء؛ يستمر التقييم.
  • فوق السقف ← يُرفض الاستدعاء، بسبب يسمّي إجمالي التشغيل مقابل السقف. تلك النتيجة النهائية، نتيجة قاطع الدائرة — لا يمكن للتشغيل إصدار استدعاء محكوم آخر حتى تشغيل جديد.
السقف مفتاحه تشغيل الوكيل، وليس طلباً واحداً. تشغيل طويل أحرق بالفعل معظم ميزانيته يُرفض على استدعائه التالي حتى عندما يكون ذلك الاستدعاء الواحد رخيصاً — يقفز القاطع على الإجمالي الجاري، وليس التكلفة الهامشية.
نطاق التشغيل، مع تراجع لكل طلب. عندما يحمل الطلب معرّف تشغيل وكيل، ينطبق السقف على الإنفاق المتراكم للتشغيل. استدعاء بلا ارتباط تشغيل (مثل إرسال MCP مجرّد بلا جلسة مُمرَّرة) يتراجع إلى مقارنة لكل طلب بدلاً من ذلك. في كلتا الحالتين، يقفز القاطع قبل إرسال الاستدعاء المتجاوز للميزانية.

​
2. مثال ملموس واحد

ضع سقفاً لأي تشغيل على مفتاح عند $5.00 من الإنفاق المتراكم. قاعدة حرف بدل واحدة تفعلها — cap_cost_cents هو 500 (سنتات): 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
ألّفها في محرر القواعد بـوحدة التحكم على سياسة أنشأتها (انظر إنشاء وربط سياسة). كتابة قاعدة إجراء Developer+. اربط السياسة بمفتاح عبر firewall_policy_id، أو اجعلها افتراضي مساحة العمل، وكل تشغيل يقوده ذلك المفتاح أصبح الآن محدوداً. يمكنك قصر السقف أضيق من “كل أداة”. ضيّق glob اسم الأداة فيُحسَب فقط عائلة استدعاءات مكلفة نحو القاطع — مثل cap_cost على *.search لتحديد تفريع البحث في الويب بينما تترك الأدوات المحلية الرخيصة غير محسوبة.
كدّس طبقة تحذير أرخص بالأولويات. قاعدة audit بسقف أدنى عند أولوية أعلى (رقم أدنى) تدعك تراقب تشغيلاً يقترب من ميزانيته في تغذية الأحداث قبل أن تقفز قاعدة cap_cost الفارضة. أول مطابقة تفوز، فرتّب المراقب أولاً.

​
3. أين يُطلق — وأين لا يمكنه

cap_cost لا معنى له إلا قبل إرسال استدعاء — تلك هي النقطة الوحيدة التي يمنع فيها إيقاف الاستدعاء الإنفاق فعلاً. فهو حي على سطحي ما قبل الإرسال ومرفوض على سطحي ما بعد الإرسال:
السطحcap_cost؟
inbound (الأدوات المُعلَن عنها)مفروض.
mcp (إرسال tools/call)مفروض.
response (الاستدعاءات المُصدَرة من النموذج)مرفوض عند الحفظ — لم يبق شيء لإيقافه.
egress (الوجهة الصادرة)مرفوض عند الحفظ — لم يبق شيء لإيقافه.
قاعدة cap_cost مثبّتة على response أو egress تُرفض وقت الحفظ، فلا يمكن أبداً أن تظهر قاعدة كحية بينما تعجز عن الرفض أبداً. اترك المرحلة فارغة لتغطية سطحي ما قبل الإرسال كليهما، أو ثبّتها على inbound / mcp.
cap_cost_cents مطلوب وغير سالب لقاعدة cap_cost. ترفض وحدة التحكم وAPI قاعدة cap_cost بلا سقف، فلا يمكن لسقف مساء الضبط أن يمرّر كل استدعاء صامتاً.

​
4. كيف يبدو القاطع حين يقفز

استدعاء متجاوز للميزانية هو deny جدار حماية عادي:
  • على inbound، يعيد الترحيل HTTP 400 برمز خطأ firewall_blocked. يُطلق الحجب قبل استدعاء النموذج الأعلى، فلا يكلّف أي رموز نموذج، ومعلّم بـ skip-retry — إعادة تشغيل نفس الاستدعاء ستقفز القاطع مجدداً فحسب.
  • على mcp، يعود كـ خطأ أداة فيرى النموذج الرفض ويمكنه التوقف أو سؤال المستخدم، بدلاً من الانهيار.
سبب deny يسمّي الأرقام، مثل cap_cost: estimated run cost $5.40 exceeds cap $5.00، فيرى مشغّل يقرأ تغذية الأحداث بالضبط لماذا قفز القاطع.
الأحداث لا تحمل أبداً cap_cost حرفياً. تؤلّف الحكم كـ cap_cost، لكن المحرك يحلّه إلى allow أو deny ملموس قبل تسجيل الحدث. تُظهر التغذية allow/deny الذي رآه الوكيل فعلاً — سقف تكلفة التشغيل هو السبب، وليس عنوان الحكم. هذا يعكس كيف تُحَل الأحكام.

​
5. اطرحها بأمان

لأن قاطعاً قافزاً يوقف تشغيلاً بصرامة، تحقّق منه قبل أن تفرض. فعّل وضع الظل على السياسة: لا تزال قاعدة cap_cost تُقيَّم ويُخفَّض deny محتمل إلى audit، مسبوقاً بـ [shadow] would …. راقب تغذية الأحداث لتأكيد أن السقف يقفز حيث تتوقع — وفقط حيث تتوقع — ثم أطفئ وضع الظل لتبدأ الفرض. يمكنك أيضاً إجراء سياسة تجريبياً مقابل استدعاء عينة في تبويب Test (صندوق رمل Developer+) لرؤية الحكم المُحَل والقاعدة المطابقة قبل أن يعتمد عليه أي شيء.

​
6. كيف يلائم بقية جدار الحماية

cap_cost حكم واحد من ستة. يقترن طبيعياً بعناصر التحكم الأخرى على نفس السياسة:

الأحكام

المجموعة الكاملة — allow، audit، deny، sanitize، pending_approval، وكيف يُحَل cap_cost.

احجب الأدوات الخطرة

ارفض shell المدمّر، والحذوفات، والاستدعاءات الأخرى عالية المخاطر صراحةً.

مرجع القواعد

لغة المطابقة الكاملة — globs، عبارات الوسائط، التسلسلات.

كشف الشذوذ

ارتفاعات التكلفة معلّمة مقابل خط أساس متعلّم لساعة الأسبوع.
سقف تكلفة التشغيل حاجز دعم ساكن وحتمي؛ يـتعلّم جدار الحماية أيضاً شكل التكلفة الطبيعي لكل مساحة عمل ويعلّم الارتفاعات مقابل خط أساس لساعة الأسبوع على 14 يوماً على تغذية شذوذ قابلة للقراءة من قبل Member. استخدم cap_cost للإيقاف الصارم، والشذوذات للإشارة المبكرة.
حدود الحصة على المفتاح نفسه (credit_limit_usd) تحدّ الإنفاق الإجمالي عبر كل التشغيلات؛ وcap_cost يحدّ تشغيلاً واحداً. يتركّبان — حلقة منفلتة تقفز قاطع كل تشغيل قبل وقت طويل من استنزافها لرصيد المفتاح مدى الحياة. انظر النطاق: المفاتيح، السياسات، مساحات العمل.

​
أين تذهب بعد ذلك

إنشاء وربط سياسة

أنشئ سياسة، اختر حكماً افتراضياً، اربطها بمفتاح.

وضع الظل

قِس سقفاً قبل أن يغيّر حركة المرور.
لتهديدات الوكيل المنفلت التي يدعمها سقف إنفاق، انظر الوكالة المفرطة و استدعاءات الأدوات الخطرة.