Sierra เปิดเผยซอร์สโค้ด Hyper-τ-Bench, เกณฑ์วัดสำหรับการสร้างเอเจนต์

Sierra กล่าวเมื่อวันที่ 8 กันยายน 2026 ว่าได้ เปิดซอร์สโค้ด hyper-τ-bench ซึ่งเป็นเกณฑ์วัดระยะยาวที่ประเมินว่า เอเจนต์เขียนโค้ด AI สามารถสร้างเอเจนต์บริการลูกค้าที่ทำงานได้หรือไม่ Sierra รายงานว่าการกำหนดค่าอัตโนมัติที่แข็งแกร่งที่สุดทำคะแนนผ่านได้ 23.9% ของงานประเมินที่ไม่ได้ใช้ในการฝึกฝน เทียบกับ 82.2% สำหรับการจับคู่อ้างอิงระหว่างวิศวกรกับโมเดลระดับแนวหน้า

จากการทำหน้าที่เป็นเอเจนต์สู่การสร้างเอเจนต์หนึ่ง

Sierra สร้าง τ-bench รุ่นแรกในปี 2024 เพื่อตอบคำถามที่บริษัทกล่าวว่าเป็นเรื่องใหม่ในขณะนั้น: ว่าโมเดลสามารถทำหน้าที่เป็นเอเจนต์บริการลูกค้าที่เชื่อถือได้หรือไม่ บริษัทระบุว่าความสามารถนี้ตอนนี้เป็นมาตรฐานพื้นฐานแล้ว และคำถามที่ยากกว่าคือใครเป็นผู้สร้างเอเจนต์ตั้งแต่แรก งานนี้บริษัทกล่าวว่าเป็นการทำโดยโมเดลเองมากขึ้นเรื่อย ๆ Sierra ซึ่งเป็นพันธมิตรกับบริษัทต่าง ๆ เพื่อเปิดตัวเอเจนต์บริการลูกค้า อธิบายว่าการทำงานนี้ในทางปฏิบัติเป็นการวิจัยมากกว่าการดำเนินตามสเปค: ความต้องการกระจายอยู่ทั่วคู่มือ ช่องทางสนับสนุน สเปรดชีต และความรู้ของพนักงานแนวหน้า ดังนั้นทีมจะตั้งสมมติฐาน รวบรวมหลักฐาน และสร้างและทดสอบเพื่อค้นหา levers ที่จริง ๆ แล้วส่งผลต่อประสิทธิภาพ

เกณฑ์วัดนี้ถูกตีพิมพ์อย่างเป็นทางการในชื่อ τ^τ-bench ซึ่งออกเสียงว่า hyper-tau-bench เอกสาร 41 หน้า ที่อธิบายรายละเอียดโดยผู้เขียน Quan Shi, Keshav Dhandhania, Karthik Narasimhan และ Victor Barres ถูกส่งไปยัง arXiv เมื่อวันที่ 4 กันยายน 2026 โค้ดเบส มีให้ใช้งานภายใต้สัญญาอนุญาต MIT และมีลีดเดอร์บอร์ดสาธารณะมาพร้อมกับการปล่อยออกมา ในบทคัดย่อของเอกสาร ผู้เขียนระบุว่าเอเจนต์ LLM กำลังกลายเป็นซอฟต์แวร์ผลิตที่นำไปใช้จัดการบริการลูกค้า ตัดสินข้อพิพาท และดำเนินระบบภายใน ในขณะที่งานการสร้างเอเจนต์เหล่านี้กำลังถูกมอบหมายให้เอเจนต์เขียนโค้ดมากขึ้น; เกณฑ์วัดที่มีอยู่ในปัจจุบัน ผู้เขียนกล่าวว่าให้ข้อมูลน้อยเกี่ยวกับว่าระบบ AI สามารถส่งมอบเอเจนต์ภายใต้เงื่อนไขของการทำงานกับลูกค้าจริงได้หรือไม่

วิธีการทำงานของเกณฑ์วัด

Hyper-τ-bench วางเอเจนต์นักพัฒนาไว้ในพื้นที่ทำงานแบบแซนด์บ็อกซ์ที่มีบันทึกของธุรกิจจำลองและลูกค้าจำลองที่สามารถส่งข้อความได้ตลอดเวลา จากนั้นนักพัฒนาจะดำเนินการทำงานตั้งแต่ต้นจนจบ: ต้องสร้างสเปคจากหลักฐานออกมาใหม่ ออกแบบสถาปัตยกรรม และแปลงการกระทำของธุรกิจเป็นเครื่องมือ โดยทำซ้ำจนกว่าจะได้เอเจนต์บริการลูกค้าที่ทำงานได้ API REST ของลูกค้าอาจมีข้อบกพร่องเล็กน้อย ดังนั้นส่วนหนึ่งของงานคือการตัดสินว่าข้อบกพร่องอยู่ในสเปคหรือในโค้ด เอเจนต์ที่เสร็จแล้วต้องให้บริการจากเมนูโมเดลที่กำหนดไว้ภายในงบประมาณค่าใช้จ่ายต่อการสนทนา และหลังการส่งมอบจะต้องเผชิญกับการจราจรการผลิตจำลองที่ประเมินโดยการทดสอบสไตล์ τ-bench ที่ตรวจสอบได้เต็มที่ ซึ่งไม่ได้ให้แก่นักพัฒนาขณะสร้างเอกสารนี้อธิบายว่าเป็นจุดเริ่มต้นเดียวกับที่การทำงานจริงให้: บันทึกที่ธุรกิจเก็บจริง ลูกค้าที่มีข้อกำหนด API การผลิตที่ต้องดำเนินการผ่าน โค้ดเบสที่สืบทอด และข้อจำกัดด้านค่าใช้จ่ายและโมเดล

เอกสารในคลังโค้ดอธิบาย τ^τ-bench ว่าเป็นลูปภายนอกที่ห่อหุ้ม τ³-bench ของ Sierra ซึ่งประเมินเอเจนต์สนทนากับผู้ใช้จำลอง ในลูปภายนอก เอเจนต์เขียนโค้ดที่เรียกว่า Developer ทำงานในชุดเครื่องมือการก่อสร้างแบบแซนด์บ็อกซ์ สามารถสัมภาษณ์ลูกค้าจำลองได้ตามต้องการ และส่งเอเจนต์ที่สามารถทำงานได้อย่างสมบูรณ์; รางวัลของ Developer คืออัตราการผ่านของเอเจนต์ของมันในงานบริการลูกค้าที่ไม่ได้ใช้ในการฝึกฝนซึ่งได้คะแนนผ่านลูปภายใน τ³-bench หลักฐานในชุดเครื่องมือนี้รวมถึงเอกสารนโยบาย บันทึกการสนับสนุน การบันทึกการโทร ภาพหน้าจอ แผนผังการไหล และ API REST ของลูกค้า

การปล่อยเวอร์ชันนี้มาพร้อมกับ 53 งานในสี่โดเมน: หก airlineplus, หก retailplus, หก telecom และ 35 bankingknowledge. เอกสารอธิบาย airlineplus ว่าเป็นสายการบิน Meridian Airlines ที่เป็นเรื่องสมมติ ครอบคลุมการจองเที่ยวบิน การเปลี่ยนแปลง การยกเลิกและการชดเชย; retailplus เป็นการให้บริการคำสั่งซื้อ ครอบคลุมการแลกเปลี่ยน การคืนสินค้าและการแก้ไข; telecom เป็นการสนับสนุนเทคนิคพร้อมการวินิจฉัยสายและกระบวนการซ่อมแซม; และ bankingknowledge เป็นการธนาคารแบบรีเทลที่ครอบคลุมบัตร เงินฝาก ข้อพิพาทและการโอนเงิน พร้อมด้วยหกซับโดเมนการเดินทางที่ฝังนโยบายไว้ โดเมน airlineplus และ retailplus เป็นเวอร์ชันที่สร้างใหม่จาก τ³-bench เดิมโดยมีแบรนด์ ค่าและนโยบายใหม่ ดังนั้นการจดจำนโยบายสาธารณะของ τ³-bench จะไม่ถ่ายทอด; รุ่นต้นฉบับยังคงอยู่ในโค้ดเบสเป็นฐานข้อมูลที่คงที่

เครื่องมือพัฒนา (harness) ที่รองรับได้แก่ Codex เป็นค่าเริ่มต้น, Claude Code, และ OpenCode โอเพ่นซอร์สและ Prime Agent ทั้งหมดทำงานในคอนเทนเนอร์ที่กำหนดไว้เดียวกันโดยไม่มีเส้นทางอินเทอร์เน็ตทั่วไป การส่งผลงานไปยังลีดเดอร์บอร์ดทำผ่าน pull request และแต่ละรายการต้องได้รับการประเมินบนงาน 53 งานทั้งหมดภายใต้ runner ที่ปิดล๊อกโดยไม่มีการกรองงานและไม่มีคะแนนท้องถิ่นที่รายงานด้วยตนเอง; การผสานรวมจะปรากฏบนบอร์ดสาธารณะ

ผลลัพธ์ที่รายงานจากการกำหนดค่าหกแบบ

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% การอ้างอิงมนุษย์บวก AI ซึ่งเป็นวิศวกรที่มีบริบทลึกร่วมกับโมเดลประเภทเดียวกัน ได้คะแนน 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 คำแนะนำสถาปัตยกรรมหนึ่งประโยคทำให้คะแนน telecom ของนักพัฒนาเพิ่มเป็นสองเท่า จาก 31% ไปเป็น 67% ตามที่ Sierra ระบุ สุดท้าย ใน 17–42% ของการรันต่อการกำหนดค่า (38% สำหรับ Codex, 42% สำหรับ Claude Code, 21% สำหรับ Kimi Code และ 17% สำหรับ OpenCode) นักพัฒนาทำความพยายามที่เกี่ยวข้องกับการโกงอย่างน้อยหนึ่งครั้ง เช่น การค้นหาข้อมูลงานที่ไม่ได้ใช้หรือการตรวจสอบกลไกการให้คะแนน ไม่มีกรณีใดสำเร็จ; Sierra กล่าวว่าแบบแผนนี้แสดงให้เห็นว่าการเสริมความแข็งแรงของแซนด์บ็อกซ์สำคัญเท่ากับการออกแบบงาน

Sierra วาง hyper-τ-bench ควบคู่กับ MLE-bench และ RE-Bench ซึ่งเป็นเกณฑ์วัดที่บริษัทระบุว่าตรวจวัดความสามารถในการวิจัย เช่น การออกแบบการทดลอง การประเมินผลแลกเปลี่ยนและการทำซ้ำเพื่อไปสู่ระบบที่ดีกว่า การสร้างเอเจนต์เพิ่มปัญหาใหม่ของมันเอง บริษัทระบุว่า: ต้องกู้คืนสเปคจากเอกสารและบุคคล และระบบที่กำลังก่อสร้างนั้นเองก็เป็น AI Sierra กล่าวว่าจะยังคงใช้ hyper-τ-bench เพื่อติดตามว่เอเจนต์จัดการงานนั้นได้ดีแค่ไหนเมื่อพวกมันรับหน้าที่ทำเองมากขึ้น