Claude Code يتوقف عن حرق الرموز على حالات الوكلاء الفرعيين: التحديث أقل تكلفة بنسبة 99%

تخيل أنك توظف مساعدا لفحص الشيفرة، لكنه يعيد قراءة محادثة العمل كاملة من البداية كل نصف دقيقة، فقط ليقول لك: «ما زلت أعمل». هكذا تقريبا كانت تتصرف الوكلاء الفرعية التي تعمل في الخلفية داخل Claude Code. أصلحت Anthropic المشكلة، وهذا خبر مهم لكل من يدفع مقابل الرموز.

ما الذي كان يحدث بصورة خاطئة

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

ينمو السياق بسرعة في مثل هذه الجلسات، ولذلك كان من الممكن أن تصبح تكلفة سطر واحد مثل «الاختبارات قيد التشغيل، اكتمل 40% منها» غير متناسبة على الإطلاق. وقد حسب مستخدمون على الإنترنت أن هذه التقارير التقنية كانت تستهلك ما يصل إلى 16% من ميزانية الرموز. وأكدت Anthropic أن الآلية كانت تعمل فعلا بهذه الطريقة.

كيف جرى إصلاح المشكلة

باتت الحالة الآن تُنشأ بطريقة مختلفة. يحتفظ الوكيل بملاحظات قصيرة حول تقدمه، ويكتب نموذج Haiku 5.5 نص الحالة استنادا إليها. وهو نموذج خفيف ومنخفض التكلفة ولا يحتاج إلى السياق الكامل. إذ تكفي بضعة أسطر لتلخيص «ما يحدث الآن».

وفقا لتقديرات Anthropic، تبدو الأرقام كالتالي:

• انخفضت تكلفة تحديث الحالة الواحد بنحو 99%؛
• يبلغ إجمالي التوفير عند العمل مع الوكلاء في الخلفية نحو 5%؛
• يعادل ذلك نحو 6% من الطلبات الإضافية ضمن الحد نفسه.

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

ما الذي ينبغي فعله عمليا

أولا، حدّث Claude Code إلى الإصدار v2.1.316 أو إصدار أحدث. لن يعمل الإصلاح من تلقاء نفسه ما دمت تستخدم إصدارا قديما. ثانيا، تذكر القيد القائم: يعمل التحسين في واجهة سطر الأوامر فقط، ولم يحصل عليه تطبيق سطح المكتب. إذا كنت تشغّل مهام طويلة في الخلفية عبر إصدار سطح المكتب، فلن تستفيد من هذا التوفير حتى الآن.

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

ما الذي لا يزال خارج الصورة

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

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