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

ميزانيات الخروج للوكيل: المعدل ليس هو المدى

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

صورة مقرّبة لكابلات ألياف بصرية بخيوط مضيئة على خلفية داكنة

النمط في المجموعة

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

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

لماذا تفوّت ميزانيات المعدل ذلك

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

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

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

الفشل ليس في الحجم. إنه في مجموعة الوجهات القابلة للوصول، والقدرات التي يحملها الوكيل عند كل منها.

Woman using a laptop in a server room with blue-lit server racks

تصميم ميزانية مدى

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

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

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

جلب للقراءة فقط
كتابة موثّقة
إرسال نموذج
نقل ملفات (وارد)
نقل ملفات (صادر)

يجب أن تكون المفردات مغلقة حتى يمكن مقارنة الميزانيات وفرقها آليًا. سلسلة قدرات مفتوحة النهاية تدعو إلى الانحراف.

خاصيتان تجعلان الميزانية قابلة للاستخدام عمليًا.

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

ثانيًا، تُعلن الميزانية قبل بدء التشغيل، لا تُستنتج من السلوك الملاحَظ. الميزانية المستمدة مما فعله Aerial view of a rooftop solar panel array capturing sunlight for renewable energy](/media/circuit-board-macro-5a0c33-e1886b.jpg)

نقاط الفرض

الميزانية لا تكون أفضل من النقطة التي تُفرض عندها. ثلاث نقاط فرض تحمل معظم الثقل.

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

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

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

مقايضة صادقة

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

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

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

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

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

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

Why is a rate limit not sufficient to control an agent's network reach?

A rate limit caps requests per unit time, which is a capacity control. A single well-formed request to an unintended host is within any sane rate budget, so the limit never engages. The failure is not volume; it is the set of reachable destinations and the capabilities held at each.

Where should an agent's reach budget be declared?

In the run specification, not the tool definition. Declaring reach on the tool means every run that loads the tool inherits the tool's full reach. Declaring it on the run lets the same tool operate under a narrow read-only budget for one task and a wider budget for another.

Why enforce reach at an egress proxy rather than inside the agent framework?

Framework-level enforcement is coupled to the framework's tool-calling path and version, so a framework swap silently removes the control. An egress proxy between the runtime and the network resolves the destination and checks it against the run budget regardless of which framework produced the request.

What should happen when an agent's observed destinations diverge from its declared budget?

Treat divergence as a defect. Reconcile the observed destination set against the declared budget after each run, and triage any undeclared destination or ungranted capability with a root cause and a fix, rather than noting it as a curiosity.