سياق أدوات الوكيل ميزانية منتج، لا حشو Prompt

يمكن لوكيل AI أن يصبح أقل فائدة كلما زادت قدراته. أضف Connector جديدًا وSchema أخرى وصفحة إضافية من تعليمات الأدوات، وقد يبدأ الوكيل أبطأ، أو يختار إجراءً خاطئًا أكثر، أو يستهلك السياق القابل للاستخدام قبل بلوغ هدف المستخدم. يعالج الفريق العرض بوصفه مشكلة Prompt، بينما المشكلة الحقيقية معمارية منتج: يتنافس كل تعريف أداة وكل Tool Result على ميزانية محدودة من الانتباه والكمون والكلفة.

لذلك يجب إدارة Tool Context كسياسة منتج ذات إصدار. تحدد السياسة القدرات الظاهرة دائمًا، وما يُكتشف عند الحاجة، وأي نتائج وسيطة يمكن اختصارها، وأي دليل يجب أن يبقى حتى التحقق من نتيجة المنتج. الهدف ليس أصغر Prompt؛ بل أسرع مسار آمن إلى مهمة مستخدم ناجحة.

ابدأ بنتيجة المستخدم لا بسقف Tokens

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

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

يمنع هذا المنظور خطأ تحسين شائعًا. قد يقلل حذف أوصاف الأدوات Input Tokens لكنه يرفع استدعاءات الأداة الخاطئة. وقد يقلل تحميل كل التكاملات احتمال فقدان أداة، لكنه يرفع الكمون ويشتت النموذج. الميزانية الصحيحة محفظة مقايضات وليست رقمًا عالميًا واحدًا.

احصر مستهلكي السياق الخمسة

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

يمكن غالبًا Cache للتعليمات الثابتة. ويمكن تأجيل Tool Definitions. وقد يحتاج تاريخ المحادثة إلى ملخص دائم مع أحدث الأدوار. ويجب أن تحفظ الأدلة المسترجعة Citations وقرارات الوصول. أما Tool Results فكثيرًا ما تحمل الهدر الأكبر: Payloads ضخمة كانت لازمة لخطوة واحدة ولم تعد تستحق المرور في كل خطوة لاحقة.

توضح إرشادات Function Calling من OpenAI أن تعريفات الدوال تُحقن في سياق النموذج وتستهلك من Context Limit وتُحاسب كـInput Tokens. وتميز إرشادات Anthropic لإدارة سياق الأدوات تشغيليًا بين التعريفات وTool Result Blocks المتراكمة. لذلك لا تكون قائمة 100 أداة مجانية لأن المستخدم استدعى واحدة فقط.

سجّل عدد Tokens المعروض لكل فئة قبل التشغيل وبعده. تقبل واجهة Token Counting من Anthropic الرسائل والأدوات والصور وPDF، فتقدر الطلب قبل التوليد. ومع أي مزود، سجّل أيضًا Usage الناتج عن الاستدعاء الحقيقي لأن العد والـCaching عمليتان مختلفتان.

اقسم الكتالوج إلى ثلاثة مسارات

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

ضع الذيل الطويل خلف Tool Search. تصف وثائق Tool Search من OpenAI تعريفات مؤجلة لا تُحمّل إلا عند الحاجة، بينما توفر وثائق أدوات Anthropic خاصية defer_loading كي يبقى التعريف خارج Prompt الأولي حتى اكتشافه. يقلل ذلك السياق الأساسي، لكنه يضيف مخاطرة منتج: قد يفوّت الاكتشاف قدرة مناسبة. قس معدل الفقد ووفر Fallback آمنًا مثل التوضيح أو بحث أوسع أو التحويل إلى إنسان.

استخدم تنفيذًا برمجيًا أو Batch لسلاسل الأدوات المتكررة عندما لا تفيد الحمولة الوسيطة النموذج. تشرح إرشادات Anthropic أن Programmatic Tool Calling يستطيع إبقاء النتائج الوسيطة خارج تاريخ المحادثة. والمبدأ مستقل عن المزود: نفّذ التصفية أو الربط أو Pagination في الكود، ثم أعد أصغر نتيجة موثقة تدعم القرار التالي.

لا تخفِ Authorization داخل الاكتشاف. يجب أن يحسب التطبيق الأهلية قبل إتاحة الأداة للاستدعاء. قد تخبر نتيجة البحث بأن أداة Refund موجودة؛ ولا يعني ذلك أن هذا المستخدم أو المتجر أو الطلب مخول لاستخدامها.

اجعل السياسة صريحة وذات إصدار

يجب أن تكون سياسة السياق قابلة للمراجعة مثل Feature Configuration. يوضح المثال الافتراضي الشكل، لا Thresholds عالمية:

{
  "policy_version": "agent-tools-2026-11-v3",
  "outcome": "resolve-order-block",
  "core_tools": ["get_order", "search_policy", "ask_user"],
  "deferred_domains": ["shipping", "payments", "returns"],
  "result_rules": {
    "max_inline_bytes": 12000,
    "preserve": ["record_id", "version", "decision", "source_url"],
    "externalize": ["raw_html", "full_history", "binary_attachment"]
  },
  "stop_rules": {
    "max_tool_rounds": 8,
    "require_approval_for": ["refund", "cancel_order"]
  }
}

خزّن Policy Version مع كل تشغيل. عند ظهور فشل يجب أن يميز الفريق بين Model Regression وتغيير الكتالوج وتوسيع Schema وقاعدة اختصار عدوانية أو Tool Search Miss. من دون الهوية لا يمكن تشخيص عبارة «أصبح الوكيل أسوأ».

احتفظ بالدليل عند اختصار الحمولة

Context Editing ليس حذفًا بلا عواقب. احتفظ بالحقائق التي تدعم الجواب النهائي وبالحالة اللازمة للتعافي: Record IDs ثابتة، وإصدارات المصادر، وTimestamps، وقرارات التخويل، ونتائج Tool Calls، وروابط Artifacts ثابتة. انقل Payloads الكبيرة إلى Evidence Store وأعد Projection صغيرة وTyped.

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

يجب أن تعلن الملخصات ما تستبعده. قد تمحو جملة حرة مثل «الشحنة متأخرة» هل تسبب الناقل أم التاجر في التأخر. استخدم Schema تتضمن المصدر والحالة المرصودة والثقة والتعارض غير المحلول وRetrieval Handle. وعند اختلاف نظامين احتفظ بادعاء كليهما حتى تحسم خطوة مطابقة مخولة المصدر الصحيح.

صمّم Caching حول Prefix ثابتة

يقلل Caching كلفة المعالجة المتكررة والكمون، لكنه لا يصغر سياقًا متضخمًا. تشرح وثائق Prompt Caching من OpenAI أن Rendered Prefix تشمل التعليمات وتعريفات الأدوات وتاريخ المحادثة، وأن تغيير الأسماء أو الأوصاف أو Schemas أو الترتيب قد يبطل إعادة الاستخدام. وبالمثل تضع إرشادات Anthropic لـTool Caching تعريفات الأدوات قبل System Prompt والرسائل، بينما تُلحق الأدوات المؤجلة لاحقًا ليبقى Prefix قابلًا لإعادة الاستخدام.

حافظ على استقرار Core Definitions، وضع بيانات المستخدم والمهمة الديناميكية بعد الجزء القابل للـCache، وألحق الأدوات المكتشفة بدل إعادة بناء أول الطلب. راقب Cached Input Tokens وCache Writes وإعادة الاستخدام الفعلية والكلفة الناتجة. قد يكون Cache Hit الاسمي مرتفعًا لكنه غير اقتصادي إذا كان المنتج يكتب Prefixes ضخمة نادرًا ما تُقرأ ثانية.

تعامل مع Cache Keys كحد عزل لا كتلميح أداء فقط. لا تنشئ مفاتيح مشتركة تجعل سلوك العملاء صعب التفسير أو التدقيق. ويجب أن يستطيع التطبيق حساب استخدام كل Workspace للـCache من دون وضع محتوى خاص في Telemetry.

راقب مسار القرار كاملًا

اربط مهمة المستخدم عبر الأهلية واكتشاف الأدوات وModel Calls وتنفيذ الأداة والتحقق والنتيجة النهائية. تمثل إرشادات OpenTelemetry لمراقبة GenAI Agent Span لها Child Spans لاستدعاءات النموذج وتنفيذ الأدوات. استخدم هذا التسلسل، لكن لا تضع Prompts أو النتائج الخام في Attributes ما لم تسمح سياسة الخصوصية صراحة.

تشمل الحقول المفيدة: Policy Version، وCatalog Version، وفئة Tool Search Query، وعدد الأدوات المكتشفة، والأداة المختارة، وإصدار Schema، وفئات Input Tokens، وCached Tokens، وحجم النتيجة قبل Projection وبعدها، وTool Latency، ونتيجة التحقق، وفئة النتيجة النهائية. استخدم قيمًا منخفضة Cardinality، وضع Payloads الحساسة في مخزن أدلة محمي لا في Metric Labels.

يجب أن تجيب Product Dashboard: كم مرة وصل المستخدم إلى حالة مفيدة متحقق منها؟ وكم استغرقت؟ وكم جلسة فشلت لأن الأداة غائبة أو اكتُشفت متأخرة أو اختيرت خطأ أو رفضها التخويل أو انتهت مهلتها أو أعادت بيانات زائدة؟ وما كلفة Tokens والمال لكل نجاح؟ تنتج هذه التصنيفات عملًا هندسيًا قابلًا للتنفيذ.

أطلق تغييرات السياق كتغييرات منتج

ابنِ حالات Offline تمثل الرحلات الحقيقية والظروف الحدية. اختبر Tool Selection وانتقال الحالة النهائي معًا. تفشل سياسة تختار الأداة الصحيحة ثم تحذف الدليل اللازم للتحقق.

شغّل السياسة المرشحة في Shadow Mode على مهام مسجلة أو منسوخة من دون السماح بأدوات تغير البيانات. قارن الأدوات المكتشفة والأفعال المختارة والكمون وTokens والنتيجة المقترحة النهائية بالسياسة النشطة. ثم طبق Canary على شريحة مؤهلة صغيرة خلف Routing Rule قابلة للتراجع. أبقِ النموذج والسياسة والكتالوج وإصدارات Result Projection حزمة واحدة حتى يعيد Rollback إعدادًا اختُبر فعلًا.

حدد شروط الإيقاف قبل الإطلاق: ارتفاع Tool Search Misses أو Authorization Rejections أو Abandonment أو Cost per Success أو أخطاء Context Overflow أو تعارضات الحالة غير المحلولة. لا يكون الطلب الأرخص نجاحًا إذا كرره المستخدم أو اضطر الدعم إلى إصلاح النتيجة.

مثال افتراضي: مساعد دعم للتاجر

تخيل مساعدًا افتراضيًا يساعد التاجر في فحص تعطل Fulfillment. يحتوي Core Catalog على قراءة الطلب والبحث في السياسة والتوضيح. وتؤجل أدوات شركات الشحن والمخزون والمدفوعات. يصنف الوكيل مجال العطل أولًا، ويكتشف أدوات ذلك المجال فقط، ثم يستقبل Projection صغيرة من كل استدعاء.

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

يقيس الفريق زمن الوصول إلى تفسير متحقق منه، واكتشاف المجال الصحيح، ومعدل فقد الأداة، وانسحاب المستخدم، وتكرار السؤال، والكلفة لكل حالة محلولة، ونسبة التصعيد بسبب تعارض الدليل. يختبر سياسة السياق الجديدة في Shadow Mode، ثم يعرضها لشريحة تجار صغيرة. يعيد Rollback الكتالوج والملخصات وقاعدة التوجيه السابقة معًا.

تعامل مع السياق كسطح منتج

درس هندسة المنتجات عملي: Tool Context ليست كيس Schemas ملحقًا بـPrompt، بل Control Plane للقدرات والكلفة والكمون والأمان والتعافي. أبقِ Core صغيرة وثابتة، واكتشف الذيل الطويل، واختصر الحمولة الوسيطة من دون تدمير الدليل، وصمّم Prefixes قابلة للـCache، وقس الطريق إلى نتيجة المستخدم المتحقق منها.

أفضل ميزانية سياق ليست صاحبة أقل Tokens؛ بل التي تجعل الفعل الصحيح الآمن سهل الاختيار ورخيص التنفيذ وقابلًا للمراقبة والتشخيص والتراجع.

إعداد: Noor Yasser