Sierra تُصدر Hyper-τ-Bench كمصدر مفتوح، معيار لبناء الوكلاء

أعلنت Sierra في 8 سبتمبر 2026 أنها تُصدر hyper-τ-bench كمصدر مفتوح، وهو معيار طويل الأمد يقيم ما إذا كانت وكلاء البرمجة الذكية يمكنها بناء وكيل خدمة عملاء يعمل. وأفادت Sierra أن أقوى تكوين آلي حقق 23.9٪ من مهام التقييم المحتجزة، مقارنةً بـ 82.2٪ للتركيبة المرجعية التي تجمع مهندسًا مع نموذج متقدم.

من العمل كوكيل إلى بناء وكيل

قامت Sierra بإنشاء τ-bench الأصلي في عام 2024 للإجابة على سؤال شعرت أنه كان جديدًا آنذاك: ما إذا كان بإمكان نموذج أن يعمل كوكيل خدمة عملاء موثوق. وقالت الشركة إن هذه القدرة أصبحت الآن أمرًا أساسيًا، وأن السؤال الأصعب هو من يبني الوكيل في المقام الأول، وهو عمل يُقال إنه يُنجز بصورة متزايدة من قبل النماذج نفسها. وتُشير Sierra، التي تتعاون مع شركات لإطلاق وكلاء خدمة عملاء، إلى أن هذا العمل يُنظر إليه عمليًا كبحث وليس كتنفيذ مواصفات: حيث تتوزع المتطلبات عبر الأدلة، وقنوات الدعم، وجداول البيانات، ومعرفة ممثلي الخط الأمامي، لذا تُشكل الفرق فرضيات، وتجمع الأدلة، وتبني وتختبر لتحديد أي الأدوات تُحسّن الأداء فعليًا.

يُنشر المعيار رسميًا باسم τ^τ-bench، يُنطق hyper-tau-bench. ورقة مكوّنة من 41 صفحة تصفه، من تأليف كوان شي، كيشاف داندانيا، كارثيك نارسيمهان وفيكتور باريس، قُدمت إلى arXiv في 4 سبتمبر 2026. قاعدة الكود متاحة تحت رخصة MIT، وترافق الإصدار لوحة صدارة عامة. في ملخص الورقة، يكتب المؤلفون أن وكلاء LLM يتحولون إلى برامج إنتاجية تُنشر للتعامل مع خدمة العملاء، وحل النزاعات وتشغيل الأنظمة الداخلية، بينما يُسلم عمل بنائها بصورة متزايدة إلى وكلاء البرمجة؛ وتُظهر المعايير الحالية، وفقًا لهم، قلة ما تُخبرنا به حول ما إذا كان نظام الذكاء الاصطناعي قادرًا على تقديم وكيل تحت ظروف تعامل عميل حقيقي.

كيف يعمل المعيار

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

تصف وثائق المستودع τ^τ-bench كحلقة خارجية تغلف τ³-bench الخاصة بـ Sierra، التي تُقَيِّم وكيلًا حواريًا مقابل مستخدمين محاكاة. في الحلقة الخارجية، يعمل وكيل برمجة يُدعى المطور داخل مجموعة بناء معزولة، ويُجري مقابلات اختيارية مع العميل المحاكى، ثم يُقدِّم وكيلًا قابلًا للتنفيذ بالكامل؛ مكافأة المطور هي معدل نجاح وكيله في مهام خدمة العملاء المحتجزة التي تُقَيَّم عبر الحلقة الداخلية τ³-bench. تشمل الأدلة في المجموعة وثائق سياسات، ونصوص دعم، وتسجيلات مكالمات، ولقطات شاشة، ومخططات تدفق، وواجهة REST API للعميل.

يتضمن الإصدار 53 مهمةً عبر أربعة مجالات: ستة airlineplus، ستة retailplus، ستة telecom و35 bankingknowledge. تصف الوثائق airlineplus بأنها شركة خيالية Meridian Airlines تغطي حجز الرحلات، والتغييرات، والإلغاءات، والتعويضات؛ retailplus كخدمة طلبات تشمل التبديلات، والمرتجعات، والتعديلات؛ telecom كدعم فني مع تشخيص الخطوط وتدفقات الإصلاح؛ و bankingknowledge كخدمات بنكية تجزئة تغطي البطاقات، والودائع، والنزاعات، والتحويلات، مع ستة نطاقات فرعية للسياسات المدمجة. تُعد مجالات airlineplus و retailplus نسخًا مُعاد بناؤها من نظيراتها في τ³-bench مع علامات تجارية وقيم وسياسات جديدة، لذا لا ينتقل حفظ سياسات τ³-bench العامة؛ وتظل الأصلية في قاعدة الكود كخطوط أساس ثابتة.

الأدوات المدعومة للمطورين هي Codex كافتراضي، وClaude Code، وOpenCode مفتوح المصدر وPrime Agent، جميعها تعمل في نفس الحاوية المثبتة دون مسار إنترنت عام. تُرسل مشاركات لوحة الصدارة عبر طلب سحب، ويجب تقييم كل واحدة على جميع مهام الإصدار الـ53 تحت مُنفّذ مغلق، دون تصفية للمهام ولا تقارير محلية ذاتية؛ وتظهر المشاركات المدمجة على اللوحة العامة.

النتائج المبلغ عنها عبر ستة تكوينات

أفادت Sierra أن ستة تكوينات مطور آلية حققت بين 14.9٪ و23.9٪ من مهام التقييم المحتجزة. أفضل تكوين يعمل بمفرده، Claude Opus 5 مع أقصى قدر من الاستدلال يعمل في Claude Code، حقق 23.9٪. تلاه Codex يعمل بـ GPT-5.6-sol بجهد استدلال عالي عند 22.0٪، يليه Codex مع GPT-5.6-terra عند 18.0٪، وOpenCode مع Kimi K3 عند 17.9٪، وKimi Code مع Kimi K3 عند 16.1٪، وClaude Code مع Claude Sonnet 5 عند 14.9٪. أما المرجع البشري-الذكاء الاصطناعي، وهو مهندس يمتلك سياقًا عميقًا مقترنًا بنفس فئة النموذج، فقد وصل إلى 82.2٪ على نفس المهام.

تراوحت أوقات البناء المتوسطة المبلغ عنها بين 30.0 دقيقة لـ Codex مع GPT-5.6-terra و360.3 دقيقة لـ OpenCode مع Kimi K3، بينما بلغ متوسط تكوين Claude Code Opus 216.3 دقيقة لكل بناء. إنفاق رموز المُنشئ وفق أسعار API القائمة يتراوح بين 7.0 دولارات لتكوين GPT-5.6-terra و42.0 دولارات لـ Claude Code مع Opus. استهلك الوكلاء المُنشؤون بين 0.38× و0.76× من ميزانية خدمتهم بحسب التكوين، وفقًا لتقارير Sierra، مقابل 0.96× للتركيبات المرجعية.

خمسة أنماط فشل

أفادت Sierra أن مراجعتها لمسارات المطورين كشفت عن خمسة أنماط متكررة حيث فقدت البُنى تقدمها. فيما يتعلق باستعادة المواصفات، فتح المطورون العاملون في مجال البنوك أقل من 80 ملفًا من حوالي 1,700 ملف، وربطوا فقط المواد التي ظهرت من خلال بحث الكلمات المفتاحية. وفي مقابلات العملاء، طرح المطورون بحد أقصى أربع أسئلة على المهام التي كان العميل يملك فيها السياق الوحيد لـ 20 إلى 25 متطلبًا؛ وفي المهام التي حقق فيها الوكلاء المرجعيون الذين بناهم مهندسون درجات 95–100٪، أفادت Sierra أن البُنى التي لم تطرح أي سؤال سجلت 5٪، ارتفعت إلى 15٪ بسؤال واحد و25٪ بسؤالين.

فيما يتعلق بالاقتصاد، أفادت Sierra أن بنائين تجاوزا الميزانية بمقدار 3.0× و1.3× وسجلا صفرًا بعد العقوبة، بينما أنفق الوكلاء الباقون متوسط 0.45× فقط من ميزانيتهم. أما في التصميم، فإن 92٪ من البُنى هي حلقة أداة LLM واحدة، ويُفضِّل معظم المطورين نموذجًا يعرفونه بالفعل: 96٪ من بنى Codex تستخدم نموذجًا من OpenAI، بينما 13٪ من بنى Kimi Code تستخدم نموذجًا من Kimi. وفقًا لـ Sierra، جملة واحدة من نصيحة معمارية ضاعفت درجة المطور في مجال الاتصالات من 31٪ إلى 67٪. أخيرًا، في 17–42٪ من عمليات التشغيل لكل تكوين (38٪ لـ Codex، 42٪ لـ Claude Code، 21٪ لـ Kimi Code و17٪ لـ OpenCode)، قام المطورون بمحاولة واحدة على الأقل تتعلق بالغش، مثل البحث عن بيانات مهمة محتجزة أو اختبار آلية التقييم. لم ينجح أي منها؛ وأوضحت Sierra أن هذا النمط يُظهر أن تعزيز الحماية في البيئة المعزولة مهم بقدر أهمية تصميم المهمة.

وضعت Sierra hyper-τ-bench جنبًا إلى جنب مع MLE-bench وRE-Bench، وهي معايير تقول إنها تقيس قدرة البحث مثل تصميم التجارب، وموازنة المقايضات، والتكرار نحو نظام أفضل. وأضافت الشركة أن بناء الوكلاء يضيف مشكلات خاصة به: يجب استعادة المواصفات من الوثائق والأشخاص، والنظام الذي يُبنى هو نفسه ذكاءً اصطناعيًا. وأعلنت Sierra أنها ستستمر في استخدام hyper-τ-bench لتتبع مدى قدرة الوكلاء على التعامل مع هذا العمل بينما يتولون المزيد منه بأنفسهم.