قياس عمل الوكلاء: نموذج عملي لمنع تسرب التوكنات وارتفاع التكاليف

The Boundary That Leaks

منصات الوكلاء تعرف مقدار ما فوتره المزود، لكنها لا تعرف ما العمل المنجز فعلاً. تلك الفجوة هي موضع تسرب التوكنات، وارتفاع التكاليف، وتسرب البيانات.

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

تؤكد هذه المقالة على ضرورة وجود طبقة قياس وتليمترية معيارية وقابلة للتنفيذ عند حد الوكيل–التنسيق. أوقفوا الفوترة والتدقيق بناءً على عدادات توكن غامضة. ابدؤوا بقياس وحدات عمل منفصلة: compute وI/O وprovenance. مع وجود هذه الوحدات، يمكننا منع تسرب التوكنات، وكبح ارتفاع التكاليف، وتقوية الخصوصية، من دون تجميد سرعة التطوير. الهدف ممل لكنه مهم: فواتير متوقعة، استخدام قابل للشرح، ووكلاء يستحقون الحق في التشغيل.

Bill the Work, Not the Tokens

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

أساس أفضل هو قياس العمل نفسه. ثلاث وحدات كافية للبدء:

• Compute: كل استدعاء نموذج كوحدة ذات مكانة أولى، مصنفة حسب عائلة النموذج والتكوين. أضف وزنًا معدلًا (مثلاً حسب فئة النموذج أو شريحة الحجم) لمقارنة العمل عبر النماذج من دون افتراض معادلة واحد-إلى-واحد. تضمّن أعلامًا تؤثر على التكلفة—temperature، معلمات sampling، وضع function-calling، وفئة system prompt—لأنها تشكل السلوك والإنفاق اللاحق.
• I/O: البايتات الداخلة والخارجة عبر واجهات الأدوات. يشمل ذلك خروج HTTP بحسب المضيف، قراءة وكتابة قواعد البيانات بحسب الحجم وعدد السجلات، واستعلامات فهرس المتجهات بحسب حجم مجموعة النتائج. إذا استطاع الوكيل نقل معلومات، فاعتبر تلك الحركات أحداثًا قابلة للفوترة.
• Provenance: سلسلة من الأحداث الموقّعة وغير القابلة للتغيير تشرح كيف كون الوكيل نتيجة. ليست محتوى chain-of-thought. هي بنية. أي الأدوات شغّلت، وبأي معلمات وبواسطـة هاشات المحتوى، وتحت أي سياسة.

“قياس الوكلاء” يعني أن المنسّق يستطيع تخصيص ميزانية، وتدقيق، وتسوية هذه الثلاث وحدات لكل مهمة. يمكن أن تبقى عدادات التوكنات جانبية، لكن لا ينبغي لها أن تحمل الحوكمة على ظهرها.

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

The Metering Contract: A Small, Enforceable Layer

نموذج الوحدات يحتاج كائن حدّ فاصل—خفيف، عام، وقابل للتنفيذ. فكر فيه كـ “عقد قياس” يلف كل إجراء وكيل. يلتقط النية، يطبق السياسة، يمرر الاستدعاء، ويصدر إيصالًا موثّقًا.

عقد عملي له خمسة أجزاء:

1. ظرف النية. يعلن الوكيل الإجراء الذي يريد اتخاذه: استدعاء نموذج، طلب URL، استعلام مخزن. يذكر الظرف التكلفة المتوقعة بوحدات العمل—كم وحدة compute، كم بايت خروج، كم صفوف أو embeddings. ويحمل أيضًا تسميات حساسية للبيانات المتنقلة. الوكيل لا ينفذ بعد؛ بل يطلب.

2. فحص الميزانية. يقارن المنسق (أو sidecar) النية المعلنة بميزانية محددة بالسياسة لهذا الطلب أو المستخدم أو المستأجر أو سير العمل. الميزانيات يمكن أن تكون مرنة (تحذير واستمرار) أو صارمة (رفض أو اقتطاع). والأهم، تُعبر الميزانيات بوحدات عمل، لا توكنات. “حتى استدعائين لنموذج من الفئة M، 200 kB خروج إلى النطاق A، 50 kB إلى النطاق B، 10 مستندات مسترجعة.”

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

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

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

التنفيذ ليس قابلًا للتفاوض. طبقة تليمترية تكتفي بـ”المراقبة” تبقى صامتة عندما تحتاجها أكثر. يجب أن يكون العقد البوابة التي تمر عبرها كل استدعاء نموذج وI/O أداة. في الكود، يمكن أن يشبه هذا غلاف مكتبة. في البنية التحتية، يمكن أن يكون sidecar أو بروكسي. في الحالتين، عليه أن يكون المسار الافتراضي.

Design Patterns That Prevent Leaks and Spikes

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

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

تقييد حجم النتيجة والاقتطاع. عندما يسحب أداة استرجاع مستندات للسياق، قِس كلًا من عدد العناصر وحجمها بالبايت. حد إجمالي حجم السياق الممرّر إلى النموذج. إذا أعاد الفهرس كمية كبيرة، فضّل مرشحات على الجانب الخادم يمكن عدها—top-k مع k صارم، أو عوامل تصفية صريحة للسمات—على التقطيع في العميل بعد الواقع. عندما تضطر للاقتطاع، اجعله حتميًا وسجّل الاقتطاع في البيان حتى يكون للأجوبة الخاطئة أثر تتبعي. هذا النمط الوحيد يمنع التضخم الكلاسيكي للـ prompt.

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

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

هاشات المحتوى بدل الحمولات الكاملة. لأجل provenance، تجنّب تخزين prompts والنصوص المسترجعة بصيغتها الصريحة. احسب هاشات المحتوى (مثلاً تجزئات آمنة للنص الموحد) وأرفقها بالإيصالات. عندما يسأل أحد ما إذا استُخدم المستند X، يمكنك التحقق من سلسلة الهاشات من دون الاحتفاظ بالمحتوى الحساس في التليمترية. الحذف والهاش يمنعان تحول سجلات موسعة إلى مستودع بيانات موازٍ عن غير قصد.

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

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

أغلفة أدوات مع تحقق من المخطط للمعاملات. عامل كل استدعاء أداة كأنه عام: تحقق من المعلمات، فرض حدود الحجم، والاعتماد على اقتطاع آمن. ابنِ مكتبات غلاف حتى يصرّ مؤلفو الأدوات على إعلان مخططات الإدخال والإخراج مع تلميحات الحجم. يمكن للحد حينها أن يختبر وحدات I/O المتوقعة قبل التنفيذ.

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

البث مع وضع علامات مائية. للاستجابات المتدفقة، فَرِض علامات مائية: اصدر إيصالات وسيطة عند عتبات بايت واقطع البث عندما تتجاوز العلامة المائية التالية الميزانية. هكذا تمنع استجابة متدفقة من المرور بهدوء عبر الحواجز.

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

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

prompts تفشل بسرعة. قبل نشر قالب prompt إلى الإنتاج، شغّل فحص ميزانية ثابت وديناميكي. الثابت: قدّر وحدات compute وحدود I/O من القالب والأدوات المعلنة. الديناميكي: نفّذ القالب ببيانات تركيبية تحت ميزانية قصوى وتأكد من أنه لا يتجاوز الوحدات. هذا يمنع المفاجآت عندما يضاعف system prompt الجديد حجم السياق.

لا يتطلب أي من هذه الأنماط أدوات غريبة. لكنها تتطلب عادة واحدة: لا يجوز لأي إجراء وكيل تجاوز العقد. هذا هو الخط الذي تحافظ عليه.

Fit for Enterprise and Open Source

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

للبنى المؤسسية:

• ضع الحد عند حافة كل منطقة ثقة. يمكن أن يكون sidecar لواجهات API عديمة الحالة، وبروكسي للخروج، وغلاف مكتبة داخل SDKs للأدوات. كل شيء يمر عبر نفس السياسة.
• عبر عن الميزانيات كـ policy-as-code، مُسجَّلة ومرتبطة بالمستأجر، وسير العمل، وفئة البيانات. تصبح تغييرات السياسة commits مع diffs، لا تبديلات تنجرف.
• اصدر إيصالات موقعة إلى مخزن قابل للإلحاق فقط. هذا يصبح مسار تدقيقك وركيزة للفوترة الداخلية. إذا أرادت وحدة تجارية معرفة ما دفعت مقابله، تسلّمها بيانات تجمع compute وI/O وprovenance، لا لقطات شاشة لفواتير البائع.
• اجعل الحذف وإخفاء الهوية من الدرجة الأولى. قواعد سيادة وإقامة البيانات تجعل هذا غير اختياري. في الخليج، تتوقع مجموعات كيانات متعددة والمنظمون فواصل نظيفة بحسب الكيان القانوني وفئة البيانات. الحدّ هو المكان الذي تفرض فيه تلك الفواصل دون إعادة بناء كل وكيل.

لـ stacks مفتوحة المصدر:

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

هنا حيث يساعد معيار مشترك. إذا استُخدم نفس مخطط العقد في بروكسي شركة ومكتبة OSS، يمكن للفرق تبديل المكونات دون كسر التدقيق.

Objections, Answered Honestly

“التوكنات هي ما يفوّته البائعون. لماذا نقاوم ذلك؟” لأن البائعين والنماذج تتغير. إذا كانت وحدتك الوحيدة التوكنات، فأنت معرض لكل تغيير في التجزئة وآليات نافذة السياق. وحدات العمل ترتكز إلى ما تتحكم به: الاستدعاءات التي قمت بها، البايتات التي أرسلتها، والمسار الذي اتخذته للوصول إلى إجابة. احتفظ بالتوكنات في العرض، لكن لا توازن ميزانيتك عليها.

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

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

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

“Provenance يبدو كأنه تسجيل chain-of-thought.” ليس بالضرورة. عامل provenance كبنية، لا أفكار: أي الأدوات شغلت، بأي معلمات وبواسطـة هاشات المحتوى، وتحت أي سياسة. يمكنك إثبات كيف أُنتجت نتيجة دون تخزين prompts أو المخرجات الحساسة حرفيًا.

A Minimal Standard We Can All Implement

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

• رأس المهمة: مستأجر، سير العمل، اسم مستخدم مستعار، معرف الطلب، فئة حساسية البيانات، نسخة السياسة، وأوقات البدء/الانتهاء.
• الإيصالات: قائمة مرتبة من إيصالات الإجراءات. كل إيصال يحتوي على:
  • Intent: نوع الإجراء (model_call, http_request, db_query, vector_search, file_io)، ميزانيات معلنة بوحدات compute وبايت/عناصر I/O، ونمط الحذف الذي يطبق.
  • قرار السياسة: سماح/رفض، ميزانيات معدّلة، والسبب (كود قابل للقراءة مثل POLICY_LIMIT_HOST_A_EGRESS_KB).
  • الفعليات: وحدات compute المستخدمة (مشتقة من فئة النموذج وشكل الاستدعاء)، البايت الفعلية المرسلة/المستقبلة، العناصر المسترجعة، حجم الاستجابة، المدة، وما إذا حدث اقتطاع.
  • هاشات المحتوى: تجزئات ثابتة للمدخلات والمخرجات حيث يُسمح.
  • بيانات الاعتماد: مرجع لمعرفات بيانات الاعتماد المؤقتة المستخدمة، مقيدة زمنياً ومجالياً.
  • الأخطاء: رموز مُهيكلة، لا تتبعات الستاك.
  • التوقيع: توقيع يبين العبث من عملية الحد.
• الملخص: إجماليات بحسب الوحدة والمضيف/النموذج، أي تشغيلات قاطع دائرية، وملاحظة مصالحة استخدام المزود (ما أبلغه المزود، للمقارنة).

مع ذلك يمكنك أداء ثلاثة وظائف مهمة:

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

هذا ليس تجربة فكرية فقط. أنماط البنية التحتية الحالية تناسب. يمكن للـ sidecars فرض خروج وإرفاق إيصالات. يمكن لأغلفة المكتبات ختم النوايا قبل التنفيذ. يمكن للبروكسيات العكسية وسم التدفقات. يمكن لمحرك سياسة بسيط مقارنة الميزانيات وإخراج الأسباب. لا يتطلب أي من هذا وصلات ملكية.

What Good Looks Like in Production

في الحالة الثابتة، نظام إنتاجي بهذا الحد يبدو هادئًا. المفاجآت نادرة لأن الميزانيات تمتص التباين. وعندما تحدث المفاجآت، تأتي مع إيصالات.

خذ وكيلًا نموذجيًا يمزج الاسترجاع، التلخيص، والإثراء:

• يصل الطلب موسومًا بالمستأجر وسير العمل. السياسة تضع ميزانية: وحدتا compute لنموذج من الفئة المتوسطة، 120 kB خروج إلى مضيفات معتمدة، حتى ثمانية مستندات مسترجعة بحد 24 kB إجمالي، ولا كتابات.
• يطلب الوكيل استرجاع مرشحين. يفحص الحد النية، يطبق السقف، وينفذ. يعيد الفهرس اثني عشر مستندًا بمجموع 40 kB. يقتطع الحد إلى أفضل ثمانية ويجزئ المحتوى إلى 24 kB. يسجل الإيصال الاقتطاع وهاشات المحتوى.
• يطلب الوكيل استدعاء نموذج بالسياق المسترجَع. يوافق الحد. الفعلية: وحدة compute واحدة، المخرجات 6 kB.
• يقترح الوكيل استدعاء إثراء إلى API طرف ثالث. المضيف مسموح، لكن تبقّى 20 kB ميزانية. يريد الوكيل إرسال 50 kB. يرفض الحد مع رمز واضح. يلجأ الوكيل إلى إثراء محلي، أبطأ لكنه ضمن الميزانية.
• الختام. تتجمع البيانات. تُظهر الفوترة ثلاث وحدات compute مستهلكة عبر اليوم لهذا المسار، الخروج محصور في مضيفين، ولا أعلام خصوصية.

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

Why This Matters Now

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

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

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

ويمكنك فعل ذلك بمعيار صغير يناسب كلا من البنى المؤسسية والمفتوحة المصدر.

A Sharp Take to End On

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