AWS: أداة واحدة خفّضت التوكنات لكل سكربت بنسبة 95%، والمهارات عند الطلب قلّصت موجّه النظام بنسبة 97%

تخيّل أنك تطلب من وكيل ذكاء اصطناعي: «حلّل بيانات المبيعات وأعدّ تقريرًا بصيغة DOCX». يحمّل الوكيل البيانات، ويحسب النتائج حسب الفئات، ويرسم خمسة رسوم بيانية، ويراجع الإحصاءات، ثم يكتب المستند. تستغرق هذه العملية نحو 15 دقيقة وأكثر من 150 ألف توكن، بينما تبلغ نافذة السياق (الذاكرة العاملة للنموذج) في Claude Sonnet 4.

5 على Amazon Bedrock نحو 200 ألف توكن. وإذا استقرّ كل سكربت مكتوب وكل نتيجة في هذه الذاكرة، فإنها تنفد بسرعة. عندها قد ينهار الوكيل في منتصف المهمة، أو تتراجع دقته، أو تتضخم تكلفته، لأن التوكنات مدفوعة.

عرض فريق AWS على مشروع Deep Insight المفتوح كيف يمكن تفادي ذلك. وهناك رقمان رئيسيان: أداة واحدة بدلًا من أداتين تخفّض التوكنات التي يضيفها كل سكربت بنحو 95%، وتحميل المهارات عند الطلب يقلّص موجّه النظام بنحو 97%. بالنسبة إلى مطوّر الوكلاء، هذه طريقة مباشرة لجعلهم أرخص وأكثر موثوقية.

لماذا يمثّل السياق المتضخم مشكلة؟

المشكلة لا تقتصر على احتمال نفاد النافذة. تصف Anthropic ظاهرة context rot (تدهور السياق): كلما زاد عدد التوكنات في السياق، ضعفت قدرة النموذج على استحضار المعلومة المطلوبة. كما تشوّش البيانات القديمة على النموذج، وأي خطأ يفرض إعادة تشغيل خط المعالجة بأكمله. لذلك جمعت AWS أساليب من المقالات الهندسية لدى Anthropic وإمكانات Strands Agents SDK في أربع طبقات من «هندسة السياق». هذا هو الجزء الثاني من السلسلة. وDeep Insight حلّ متعدد الوكلاء لتحليل البيانات مبني على Strands Agents SDK وAmazon Bedrock AgentCore، وعليه تُعرض جميع الأمثلة.

الطبقتان 1 و2: فصل الوكلاء وتقييد ردودهم

الطبقة الأولى معمارية. لكل وكيل متخصص نافذته الخاصة، ولا يصل إلى المنسّق إلا ملخص مضغوط. التسلسل الهرمي في Deep Insight كالتالي: Coordinator وPlanner وPlan Reviewer وSupervisor، إضافة إلى الوكلاء العاملين Coder وValidator وReporter وTracker وAuditor. الحالة المشتركة هي قاموس shared_state من أربعة حقول فقط: آخر رسالة من الوكيل السابق، وملاحظات clues المضغوطة، وقائمة مهام الخطة، وسجل موجز. بفضل ذلك يبقى حتى Coder، أكثر الوكلاء «شراهة»، ضمن 25 ألف توكن.

الطبقة الثانية هي الموجّهات (prompts). العزل وحده لا يكفي: إذا أجاب الوكيل بإسهاب، يتضخم سياق Supervisor رغم ذلك. لهذا تحدد الموجّهات ميزانيات للردود: Coder من 1000 إلى 1500 توكن، وValidator نحو 800، وReporter نحو 1000. والصيغة واحدة للجميع: الحالة، والمهام المنجزة، والاستنتاجات الأساسية مع الأرقام، وقائمة الملفات. وهناك قاعدة غير بديهية: كل سكربت مكتفٍ بذاته، أي يتضمن استيراداته ويحمّل البيانات بنفسه من الذاكرة المؤقتة. لا تُحفظ المتغيرات بين عمليات التشغيل، لكن يمكن بالمقابل التخلص من الشيفرة القديمة في السياق دون قلق.

الطبقة 3: الروابط فقط في السياق، والبيانات في الملفات

هنا يتحقق أبرز توفير. عادةً يملك الوكيل أداتين: «كتابة ملف» و«تشغيل». عندها يدخل كل سكربت من 100 سطر بالكامل في سجل المحادثة، وبعد عدة تحليلات يتجاوز ما فيه ألف سطر من الشيفرة. أما في Deep Insight فتنفّذ أداة واحدة هي write_and_execute_tool الخطوتين معًا وتعيد ملخصًا قصيرًا: «كُتب 105 أسطر، ونُفّذ بنجاح، واكتمل تحليل خمس فئات». تبقى الشيفرة على القرص، ويحتل السياق نحو ثلاثة أسطر فقط. وبحسب تقدير AWS في هذا المثال، يبلغ التوفير نحو 95% من التوكنات لكل سكربت.

وتعمل أساليب أخرى من النوع نفسه:

• يُنشأ الملف المشترك coder_analysis_utils.py مرة واحدة، وتُستدعى دوالّه بسطرين بدلًا من 20–30 سطرًا كان الوكيل سيكتبها من جديد في كل مرة.
• يعمل الملف all_results.txt بمثابة دفتر ملاحظات: يضيف إليه Coder التفاصيل، فتصل إلى Supervisor رسالة بنحو 30 توكنًا.
• تحلّ الملفات محل نقل البيانات بين الوكلاء: calculation_metadata.json من Coder إلى Validator، وcitations.json من Validator إلى Reporter، وaudit_findings.json من Auditor إلى Reporter.
• تُحمَّل المهارات (Skills) عند الطلب. يحتوي موجّه النظام على فهرس بنحو 500 توكن، ولا يفتح الوكيل الدليل الكامل SKILL.md (نحو 3 آلاف توكن) إلا عند الحاجة إليه. أما إدراج جميع الأدلة دفعة واحدة فيعني أكثر من 20 ألف توكن في كل استدعاء. ومن هنا يأتي التوفير البالغ نحو 97%، كما يمكن إضافة مهارة جديدة دون إعادة نشر.

تحفظات وما يجب فعله عمليًا

الأرقام مأخوذة من التنفيذ المرجعي لدى AWS نفسها ومن مثال توضيحي واحد بسكربت من 105 أسطر، وليست من اختبار مرجعي مستقل. وسيختلف الأثر في مهمتك: كلما طالت السكربتات وزادت الخطوات، ظهر الأثر بوضوح أكبر. الطبقة الرابعة هي التحقق بوكلاء مستقلين (Validator وAuditor) مع ضوابط حماية من امتلاء السياق. وفي المشروع تمثّل هذه الطبقة خط الدفاع الأخير إذا فاتت الطبقات الثلاث الأولى أمرٌ ما.

والترتيب العملي كالتالي: وزّع السياقات بين الأدوار، وحدّد ميزانيات الردود في الموجّهات، وانقل كل ما هو ثقيل، كالشيفرة والجداول والنتائج، إلى ملفات، ومرّره عبر الروابط. وأرخص خطوة أولى هي دمج «الكتابة» و«التشغيل» في أداة واحدة. ويوفّر نمط agents-as-tools في Strands Agents SDK عزلًا على مستوى الإطار، ولذلك لن تحتاج إلى إعادة كتابة التنسيق (orchestration) من الصفر.