การประเมิน AI Agent เข้าสู่ครึ่งหลัง: จาก “การดูคำตอบ” สู่ “การดูการกระทำ” Claw-Eval จะป้องกันระบบไม่ให้ผ่อนปรนได้อย่างไร?

ทุกวันนี้ AI Agent เริ่มเหมือนพนักงานดิจิทัลที่ทำงานได้จริงมากขึ้นเรื่อยๆ: สามารถเรียกใช้ API, ค้นหาฐานข้อมูล, เขียนอีเมล, แก้ไขโค้ด, จัดตารางเวลา, และสร้างรายงาน แต่ปัญหาที่แท้จริงไม่ใช่ว่ามัน “พูดได้หรือไม่” แต่เป็นคำถามเชิงปฏิบัติสองข้อ: มันทำงานสำเร็จจริงหรือไม่? และงานที่เราใช้ทดสอบมัน ยังคงเป็นตัวแทนของเวิร์กโฟลว์ที่สำคัญที่สุดในโลกปัจจุบันหรือไม่?

Claw-Eval ตอบคำถามแรก Claw-Eval-Live ตอบคำถามหลัง ข้อแรกแก้ปัญหา “จะยืนยันได้อย่างไรว่า Agent ทำงานสำเร็จจริง” ข้อหลังแก้ปัญหา “โจทย์ใน benchmark จะตามทันความต้องการจริงได้อย่างไร” บทความนี้จะพูดถึงตรรกะการประเมินที่พัฒนาอย่างต่อเนื่องนี้ ในแง่หนึ่ง นี่เป็นสัญญาณว่า Agent benchmark เข้าสู่ “ครึ่งหลัง” แล้ว: ไม่ใช่แค่เปรียบเทียบว่าใครตอบคำถามเก่งกว่า แต่เปรียบเทียบว่าใครใกล้เคียงโลกจริงมากกว่า

ลิงก์论文: https://arxiv.org/abs/2604.28139

ลิงก์论文: https://arxiv.org/pdf/2604.06132

คุณแน่ใจหรือว่า Agent ดำเนินการจริง?

ก่อนที่ Claw-Eval จะเกิดขึ้น วิธีการประเมิน Agent หลักๆ คือ: ให้ Agent ทำงานหนึ่ง แล้วดูแค่ผลลัพธ์สุดท้าย ตัดสินว่าถูกหรือผิด สร้างไฟล์แล้วหรือยัง? การทดสอบผ่านหรือไม่? คำตอบตรงกันหรือไม่? ถ้าตรงก็ถือว่าผ่าน

ฟังดูสมเหตุสมผล แต่สำหรับ Agent แล้ว การประเมินแบบนี้มีปัญหาสำคัญสองประการ

ประการแรก มันดูแค่ผลลัพธ์ ไม่ดูการกระทำ โมเดลส่งรายงานที่สวยงาม แต่มันค้นหาข้อมูลจากแหล่งที่ถูกต้องจริงหรือไม่? มันเรียกใช้ API ที่ถูกต้องจริงหรือไม่? หรือแค่ “สร้าง” คำตอบที่ดูเหมือนถูกต้องขึ้นมา? งานวิจัยล่าสุดแสดงให้เห็นว่า โมเดลชั้นนำจะมองหาทางลัดในการประเมินอย่างจริงจัง โดยเลี่ยงเส้นทางการดำเนินการที่คาดหวัง เพื่อให้ผ่านการตรวจสอบขั้นสุดท้าย การประเมินที่ดูแค่ผลลัพธ์นั้นเปิดโอกาสให้พฤติกรรมแบบนี้ได้เปรียบ

ประการที่สอง มันสะท้อนความต้องการในการปรับใช้จริงได้ยาก Agent ที่สามารถปรับใช้ได้จริง ไม่เพียงแต่ต้องทำงานให้สำเร็จ แต่ยังต้องหลีกเลี่ยงการทำในสิ่งที่ไม่ควรทำขณะทำงาน และสามารถทำงานได้อย่างเสถียรในสภาพแวดล้อมที่ API หมดเวลาหรือบริการแจ้งข้อผิดพลาด กล่าวอีกนัยหนึ่ง การประเมินไม่สามารถดูแค่ว่า “ทำได้หรือไม่” แต่ต้องดูว่า “ทำอย่างปลอดภัยและมั่นคงหรือไม่” Claw-Eval ยังรวม multimodal และ multi-turn conversation เข้าไว้ในกรอบการประเมินแบบเดียวกัน แต่สิ่งที่สำคัญที่สุดคือ การผลักดันให้การประเมิน Agent ก้าวจาก “การดูแค่คำตอบ” ไปสู่ “การดูการกระทำ”

Claw-Eval: ทำให้กระบวนการดำเนินการของ Agent กลายเป็นหลักฐานที่ตรวจสอบได้

Claw-Eval ประกอบด้วย 300 งานที่ผ่านการตรวจสอบด้วยมนุษย์ ครอบคลุมสามกลุ่มใหญ่: การจัดบริการทั่วไป, การรับรู้และสร้าง multimodal, และการสนทนาเฉพาะทางแบบหลายรอบ โดยกำหนด เกณฑ์การให้คะแนนที่ตรวจสอบได้อิสระ 2,159 ข้อ

แนวคิดหลักสามารถสรุปได้เป็นประโยคเดียว: ทำให้กระบวนการดำเนินการของ Agent กลายเป็นหลักฐานที่ตรวจสอบได้ การประเมินแต่ละครั้งดำเนินการในสภาพแวดล้อมที่แยกเดี่ยว แบ่งเป็นสามขั้นตอน: Setup, Execution, Judge; ขณะที่ Agent ทำงาน คอนเทนเนอร์จะไม่เห็นสคริปต์การให้คะแนนและคำตอบอ้างอิง สิ่งที่ใช้ให้คะแนนจริงๆ ไม่ใช่แค่ผลลัพธ์สุดท้าย แต่เป็นห่วงโซ่หลักฐานสามเส้นที่แยกจากกัน: เส้นทางการดำเนินการ, บันทึกการตรวจสอบฝั่งเซิร์ฟเวอร์, และภาพรวมสภาพแวดล้อมหลังการดำเนินการ

บนพื้นฐานนี้ Claw-Eval นำความสมบูรณ์ ความปลอดภัย ความทนทาน และงานข้ามโมดอล มารวมอยู่ในกรอบการประเมินชุดเดียวกัน

การค้นพบที่สำคัญที่สุดของ Claw-Eval นั้นตรงไปตรงมา: ถ้าไม่ดูกระบวนการ การประเมิน Agent จะ “ปล่อยผ่าน” อย่างเป็นระบบ

ทีมงานทำการทดลองควบคุมอย่างเข้มงวด: ให้ vanilla LLM judge ได้รับบันทึกการสนทนาทั้งหมดและซอร์สโค้ดสคริปต์การให้คะแนน แต่ขาดบันทึกการตรวจสอบฝั่งเซิร์ฟเวอร์และภาพรวมสภาพแวดล้อม ผลปรากฏว่ามันยังคงพลาด 44% ของการละเมิดความปลอดภัย และ 13% ของปัญหาความทนทาน ซึ่งหมายความว่าสำหรับ Agent แล้ว วิธีการประเมินที่ “ดูแค่ผลลัพธ์” ไม่ใช่แค่ “ไม่ละเอียดพอ” แต่จะประเมินความสามารถของโมเดลสูงเกินไปอย่างเป็นระบบ

แน่นอน Claw-Eval ยังแสดงให้เห็นอีกมาก เช่น การแทรกข้อผิดพลาดจะลดความน่าเชื่อถือลงอย่างมาก (Pass^3 ลดลงสูงสุด 24 จุดเปอร์เซ็นต์) และความสามารถ multimodal และ multi-turn conversation ไม่มีแชมป์เปี้ยนเดียว แต่สำหรับบทความนี้ ข้อสรุปที่สำคัญที่สุดมีเพียงข้อเดียว: Agent benchmark ไม่สามารถดูแค่คำตอบ แต่ต้องดูการกระทำ

อย่างไรก็ตาม เมื่อ “วิธีการดู” ได้รับการชี้แจงแล้ว ปัญหาที่เป็นจริงอีกประการหนึ่งก็เกิดขึ้น: ถึงแม้การประเมินจะน่าเชื่อถือเพียงพอ แต่ถ้าเวิร์กโฟลว์ที่ benchmark ทดสอบนั้นค่อยๆ เบี่ยงเบนจากความต้องการจริง การประเมินที่แม่นยำก็อาจไม่ตรงจุด

นี่คือปัญหาที่ Claw-Eval-Live ต้องการแก้ไข

“ประเมินแม่น” ยังไม่พอ benchmark ก็ล้าสมัยได้เช่นกัน

จากจุดนี้ไป ปัญหาไม่ได้เป็นแค่ “จะประเมินอย่างไร” แต่เป็น “จะประเมินอะไร” นี่คือจุดที่ Claw-Eval-Live เข้ามามีบทบาทอย่างแท้จริง

Claw-Eval แก้ปัญหา “คะแนนน่าเชื่อถือหรือไม่” แต่มันก็เหมือนกับ benchmark ที่มีอยู่เกือบทั้งหมด ตรงที่มีข้อจำกัดพื้นฐานกว่า:

ชุดงานถูกกำหนดตายตัว

300 งาน ถูกกำหนดตายตัวตั้งแต่วันที่เผยแพร่ ไม่ว่าระบบนิเวศเครื่องมือภายนอกจะเปลี่ยนแปลงอย่างไร จุดศูนย์กลางของเวิร์กโฟลว์องค์กรจะย้ายไปที่ใด หรือสิ่งที่ผู้ใช้ต้องการให้ Agent ทำอัตโนมัติมากที่สุดจะเปลี่ยนจากการเขียนรายงานประจำวันเป็นการกระทบยอดข้ามระบบ การกระจายงานใน benchmark จะไม่เปลี่ยนแปลงตาม

ในการประเมิน NLP แบบดั้งเดิม นี่ไม่ใช่ปัญหาใหญ่ งานอย่าง “แปลข้อความ” หรือ “ตอบคำถาม” มีรูปแบบที่ค่อนข้างคงที่ แต่ในการประเมิน Agent ปัญหานี้ขยายตัวอย่างรวดเร็ว Agent ไม่ได้เผชิญกับงานภาษาที่เป็นนามธรรม แต่เป็นเวิร์กโฟลว์ที่เป็นรูปธรรม และเวิร์กโฟลว์ก็เปลี่ยนแปลงตลอดเวลา – สแต็กเครื่องมือมีการพัฒนา จุดปวดขององค์กรเปลี่ยนไป สถานการณ์อัตโนมัติบางอย่างเกิดขึ้นจากศูนย์ บางอย่างเปลี่ยนจากแกนกลางเป็นขอบ

benchmark สามารถคงความสามารถในการทำซ้ำได้ทางเทคนิคอย่างสมบูรณ์ แต่องค์ประกอบของงานที่ทดสอบอาจกำลังเบี่ยงเบนไปจากสิ่งที่ผู้ใช้ต้องการให้ Agent ทำมากที่สุดในขณะนี้

การเบี่ยงเบนนี้ไม่ได้มาจากงานเฉพาะใดๆ ที่ “ล้าสมัย” แต่มาจากสัดส่วนการผสมของงานเอง ความต้องการอัตโนมัติที่ร้อนแรงที่สุดเมื่อหกเดือนที่แล้วกับวันนี้ อาจไม่ใช่สิ่งเดียวกันอีกต่อไป

นี่คือปัญหาที่ Claw-Eval-Live จะแก้ไข

benchmark ที่ “มีชีวิต” หน้าตาเป็นอย่างไร?

เมื่อได้ยินคำว่า “live benchmark” ปฏิกิริยาแรกของหลายคนคือ: ถ้าอย่างนั้นมันก็เปลี่ยนทุกวัน เลยเปรียบเทียบกันไม่ได้สิ?

คำตอบของ Claw-Eval-Live ไม่ใช่ “ให้ benchmark เปลี่ยนตลอดเวลา” แต่คือ:

ให้แต่ละ release เป็นภาพตัดขวางของโลกจริงในขณะนั้น

หัวใจสำคัญคือการออกแบบสองชั้นที่แยกจากกัน:

ชั้นสัญญาณ (Signal Layer) – ทุกครั้งที่สร้าง release ใหม่ ทีมงานไม่ได้ระดมสมองกันเองว่า “ควรทดสอบอะไร” แต่เริ่มจากสัญญาณความต้องการเวิร์กโฟลว์สาธารณะ เช่น ClawHub Top-500 ทักษะยอดนิยม เพื่อสังเกตว่าเวิร์กโฟลว์ใดน่าสนใจกว่าในขณะนั้น ต้องเน้นว่าสัญญาณเหล่านี้ไม่ใช่เครื่องสร้างโจทย์อัตโนมัติ และไม่ใช่การวัดความต้องการจริงที่แม่นยำ มันเป็นเพียงความต้องการเบื้องต้นที่เปิดเผยและตรวจสอบได้ ซึ่งช่วยให้ benchmark ตัดสินใจว่า release นี้ควรให้ความสำคัญกับเวิร์กโฟลว์ใดมากขึ้น

ชั้นเผยแพร่ (Release Layer) – benchmark ที่เผยแพร่สู่สาธารณะจริงๆ ยังคงเป็น snapshot ที่ตายตัวและมี timestamp คำจำกัดความของงาน สภาพแวดล้อมการดำเนินการ ข้อมูล fixture และสคริปต์การให้คะแนนทั้งหมดถูกล็อค โมเดลต่างๆ สามารถเปรียบเทียบกันได้อย่างเสถียร และสามารถทำซ้ำได้ทางวิชาการ

สองชั้นนี้เชื่อมต่อกันด้วยไปป์ไลน์ห้าขั้นตอน:

1. การรวบรวมสัญญาณ: จับภาพ timestamp ของ ClawHub Top-500 แต่ละสัญญาณมีแหล่งที่มาและข้อมูลเมตา
2. การจัดกลุ่มรูปแบบ: รวมชื่อทักษะที่กระจัดกระจายเป็นรูปแบบเวิร์กโฟลว์ที่เสถียร – ไม่แยกแยะตามชื่อพื้นผิวของทักษะ แต่แยกตามเป้าหมายผู้ใช้ วัตถุการทำงาน และสภาพแวดล้อมการดำเนินการที่อยู่เบื้องหลัง
3. การถ่วงน้ำหนักตระกูล: กำหนดน้ำหนักเป้าหมายของแต่ละตระกูลงานตามความแรงของสัญญาณต้นทาง ยิ่งสัญญาณของเวิร์กโฟลว์แรงเท่าไร สัดส่วนใน release ก็ยิ่งมากขึ้น
4. การขยายและคัดกรองเมล็ดพันธุ์: ขยายรูปแบบที่ถ่วงน้ำหนักเป็นผู้สมัครงานที่ดำเนินการได้ หลังจากทดลองรันและคัดกรอง จะคงไว้เฉพาะผู้สมัครที่รันได้ ทำซ้ำได้ และสร้างความแตกต่างของคะแนนที่มีประสิทธิภาพ – จากผู้สมัครที่สร้าง 178 ราย คัดเหลือ 157 ราย
5. การเลือกที่ปรับความแตกต่างให้เหมาะสม: ใช้ Mixed Integer Linear Programming (MILP) เลือก 105 งานสาธารณะจาก 157 ผู้สมัคร โดยปรับให้เหมาะสมกับข้อจำกัดสามประการพร้อมกัน – ขนาด release, ความครอบคลุมของตระกูล, และความสามารถในการแยกแยะอันดับ

จากสัญชาตญาณคลุมเครือสู่ข้อจำกัดที่ตรวจสอบได้: MILP ปรับเปลี่ยนตรรกะการดูแลจัดการอย่างไร

MILP ที่นี่ไม่ได้แสวงหา “ความหลากหลาย” อย่างกลไก แต่ทำให้เป้าหมายหลักสามประการชัดเจน: ขนาดของชุดข้อมูลสาธารณะ (release) ควรถึงระดับใด แต่ละตระกูลงาน (family) ควรถูกครอบคลุมอย่างน้อยกี่ครั้ง และชุดโจทย์นี้สามารถดึงความแตกต่างของความสามารถระหว่างโมเดลต่างๆ ได้จริงหรือไม่ Claw-Eval-Live เปลี่ยนการตัดสินใจดูแลจัดการที่คลุมเครือเหล่านี้ให้เป็นข้อจำกัดที่ตรวจสอบได้ ทำให้กระบวนการสร้างชุดข้อมูลโปร่งใสและสามารถสืบย้อนได้

ขนาดเฉพาะของชุดข้อมูลสาธารณะปัจจุบันคือ: 105 งาน ครอบคลุม 22 ตระกูลงาน เกี่ยวข้องกับ 13 โมเดลชั้นนำ งานเหล่านี้แบ่งออกเป็นสองสภาพแวดล้อมการดำเนินการหลัก – 87 เวิร์กโฟลว์ธุรกิจที่ขับเคลื่อนด้วยบริการ (ครอบคลุม 18 บริการที่ควบคุม เช่น CRM, อีเมล, ปฏิทิน, การเงิน, ใบงาน) และ 18 งานซ่อมแซมพื้นที่ทำงานในเครื่อง (รวมถึงการดำเนินการเทอร์มินัล, การซ่อมแซมสภาพแวดล้อม, การดีบักการกำหนดค่า)

แต่ละงานไม่ใช่แค่ prompt ง่ายๆ แต่เป็นหน่วยประเมินที่ดำเนินการได้สมบูรณ์: ต้องมีไฟล์คำจำกัดความงาน (task.yaml), คำจำกัดความอินเทอร์เฟซเครื่องมือ, ข้อมูล fixture, และสคริปต์การให้คะแนนเฉพาะ (grader.py) ขาดไม่ได้ กลไกการให้คะแนนใช้หลักการยึดหลักฐานของ Claw-Eval – ในชุดข้อมูลทั้งหมด หลักฐานเชิงกำหนดที่พบบ่อยที่สุดสามประเภท ได้แก่: การดึงข้อมูล (เรียกใช้เครื่องมือและแหล่งข้อมูลที่ถูกต้องหรือไม่), ความถูกต้องของข้อมูล (เอนทิตีและค่าตัวเลขตรงกับ ground-truth หรือไม่), การตรวจสอบการกระทำ (การเปลี่ยนแปลงสถานะที่จำเป็นเกิดขึ้นจริงหรือไม่) เฉพาะเมื่อมิติความหมายที่การตรวจสอบเชิงกำหนดไม่ครอบคลุม (เช่น คุณภาพการจัดระเบียบรายงาน, ความต่อเนื่องของบทสรุป) จึงจะมีการนำ LLM judge ที่มีโครงสร้างมาใช้ช่วยตัดสิน

ดังนั้น จากมุมมองของวิวัฒนาการโครงการ งานทั้งสองนี้เสริมซึ่งกันและกันและสืบทอดแนวคิดเดียวกัน:

• Claw-Eval แก้ปัญหา “ความน่าเชื่อถือของคะแนน” – มันทำให้เราเห็นว่า Agent ทำอะไรจริงๆ
• Claw-Eval-Live แก้ปัญหา “คลังโจทย์ตามทันความเป็นจริง” – มันทำให้ benchmark ไม่หยุดอยู่กับชุดโจทย์ตายตัว แต่ปรับให้ตรงกับเวิร์กโฟลว์ที่ควรทดสอบมากที่สุดในปัจจุบัน

เมื่อ benchmark ใกล้เคียงความเป็นจริงจริงๆ เราเห็นอะไร?

ผลลัพธ์ของ 13 โมเดลชั้นนำบนชุดข้อมูลปัจจุบันนั้นตรงไปตรงมาและเยือกเย็นพอสมควร

เพดานโดยรวมยังต่ำมาก

ไม่มีโมเดลใดทะลุอัตราผ่าน 70% ได้ ช่องว่างระหว่างอันดับหนึ่งและอันดับท้ายสูงถึง 22.9 จุดเปอร์เซ็นต์ ระบบอัตโนมัติของเวิร์กโฟลว์จริงยังห่างไกลจากขั้นตอน “การปรับใช้ที่เชื่อถือได้”

ที่น่าสังเกตคือ โมเดลที่มีอัตราผ่านใกล้เคียงกัน อาจมีความสมบูรณ์ของงานที่แตกต่างกันมาก โมเดล MiMo V2 Pro, Kimi K2.5, Gemini 3.1 Pro มีอัตราผ่านเท่ากันที่ 53.3% แต่คะแนน Overall Completion ของพวกมันแตกต่างกันตั้งแต่ 76.9 ถึง 74.0 ซึ่งแสดงให้เห็นว่าโมเดลบางตัวไม่ได้ทำไม่ได้เลย แต่ “มักจะทำไม่เสร็จสักนิด” – ปัญหาไม่ได้อยู่ที่ความสามารถทางภาษา แต่อยู่ที่ความสมบูรณ์ของวงจรการดำเนินการ

การค้นพบที่มีผลกระทบอย่างแท้จริง: สิ่งที่ยากไม่ใช่สิ่งที่คุณคิด

ถ้าใช้แค่สัญชาตญาณ หลายคนคงคิดว่างานที่ยากที่สุดน่าจะเป็นงานปฏิบัติการเทอร์มินัล การซ่อมแซมสภาพแวดล้อม ที่ต้องใช้ความสามารถทางเทคนิคที่แข็งแกร่ง

Claw-Eval-Live ให้ผลลัพธ์ที่ตรงกันข้าม

จาก heatmap แบบกลุ่ม งานประเภท Development / Terminal สำหรับโมเดลที่แข็งแกร่งนั้นใกล้ถึงเพดานแล้ว: Claude Opus 4.6, GPT-5.4 และ Claude Sonnet 4.6 มีอัตราผ่าน 100% ในมิตินี้ แม้แต่โมเดลที่อ่อนแอที่สุดก็ยังถึง 72.2% ขึ้นไป สิ่งที่ยากจริงๆ คืองานธุรกิจประเภท HR / People, Management / Ops และเวิร์กโฟลว์ข้ามระบบ ในกลุ่ม HR / People ไม่มีโมเดลใดเกิน 22.2% และมีหลายโมเดลที่ได้คะแนน 0 โดยตรง

เมื่อดูตระกูลงานในระดับละเอียดยิ่งขึ้น ข้อสรุปก็ยิ่งเฉียบคมยิ่งขึ้น อัตราผ่านเฉลี่ยของงานประเภท HR อยู่ที่เพียง 6.8%; งานประเภท MGMT ล้มเหลวทั้งหมดภายใต้กฎการผ่านสาธารณะ; อัตราผ่านเฉลี่ยของงานประเภท WORKFLOW ก็เพียง 12.8% เท่านั้น ในทางตรงกันข้าม งานซ่อมแซมพื้นที่ทำงานที่ดู “เทคนิคกว่า” กลับค่อนข้างง่ายกว่า เมื่อ benchmark ทั้งหมดถูกแบ่งออกเป็นสองพื้นผิวการดำเนินการ ความแตกต่างนี้ชัดเจนยิ่งขึ้น: ฝั่ง workspace โมเดลทั้งหมดถึงอย่างน้อย 72.2%; ในขณะที่ฝั่ง service-backed workflows ไม่มีโมเดลใดเกิน 59.8%

ซึ่งหมายความว่า คอขวดหลักของ Agent ในปัจจุบัน ไม่ใช่ “การใช้ terminal ได้หรือไม่” แต่คือ “สามารถรวบรวมหลักฐานอย่างต่อเนื่องระหว่างหลายระบบ เชื่อมโยงบันทึกอย่างถูกต้อง และดำเนินการเขียนที่จำเป็นได้หรือไม่”

สิ่งที่อธิบายปัญหานี้ได้ดีที่สุดใน论文คือรูปแบบประสิทธิภาพของงานที่มีความแตกต่างสูง ตัวอย่างเช่น การกระทบยอดบัญชีรายเดือนของอีคอมเมิร์ซ (ecommerce_monthly_reconcile), การตรวจสอบเวลาตอบสนองครั้งแรกของฝ่ายบริการลูกค้า (first_response_time_audit) และการรวมเอกสารหลายฉบับ (multi_doc_merge) ลักษณะร่วมของพวกมันคือ: ต้องดึงข้อมูลจากหลายแหล่งอย่างแม่นยำ การละเว้นการเรียกใช้เครื่องมือใดๆ หรือข้อผิดพลาดในการเชื่อมโยงเอนทิตีจะทำให้เสียคะแนนอย่างมาก

ยกตัวอย่าง HR_01_onboarding ใน submatrix ตัวแทนที่แสดงในภาคผนวกของ论文 โมเดลหลายตัวสามารถเขียนเอกสารการเริ่มงานที่ดูดีได้ แต่กลับไม่ผ่านเกณฑ์การผ่านสาธารณะ ปัญหาไม่ได้อยู่ที่ว่าเอกสารอ่านลื่นหรือไม่ แต่อยู่ที่ว่ามันไม่ได้ปิดวงจรข้อมูลพนักงาน การเรียกใช้เครื่องมือที่จำเป็น และหลักฐานงานอย่างสมบูรณ์ มันเหมือนกับการ “พูด” เกี่ยวกับสิ่งหนึ่ง มากกว่า “ทำ” สิ่งหนึ่งให้เสร็จ

นี่คือการค้นพบที่มีค่าที่สุดของ Claw-Eval-Live: จุดที่ยากที่สุดของ Agent ในปัจจุบัน ไม่ใช่ “การซ่อมของที่พัง” แต่คือ “การทำให้งานธุรกิจเสร็จสมบูรณ์จริงๆ ระหว่างหลายระบบ”

“พูดดี” ไม่เท่ากับ “ทำได้”

อันดับของ Claw-Eval-Live ไม่สอดคล้องกับอันดับของ benchmark การสนทนา/การเขียนทั่วไป ซึ่งนี่คือคุณค่าของมัน

มันไม่ให้รางวัลกับ “คำตอบสุดท้ายที่เขียนได้ลื่นไหลแค่ไหน” แต่ให้รางวัลกับการรวบรวมหลักฐานข้ามระบบ การเชื่อมโยงบันทึกที่ถูกต้อง การปิดวงจรการดำเนินการ และความสมบูรณ์ของสถานะหลังการดำเนินการ โมเดลสามารถเขียนสรุปที่ลื่นไหลอย่างยิ่ง แต่ถ้ามันละเว้นการเรียกใช้เครื่องมือที่จำเป็น พลาดหลักฐานสำคัญ หรือสถานะพื้นที่ทำงานไม่ถูกต้อง – ที่นี่มันก็ไม่ได้คะแนน นี่คือความแตกต่างหลักระหว่าง “can say” กับ “can do”

มองอีกมุมจากมุมมองการปรับใช้: ต้นทุนก็สำคัญเช่นกัน

ถ้ามองจากมุมมองการปรับใช้อีกครั้ง การประมาณการความแตกต่างของต้นทุน API ก็มหาศาลเช่นกัน ต้องเน้นคำว่า “ประมาณการ”: 论文คำนวณจากปริมาณการใช้ token input/output ที่บันทึกไว้และราคา list price ของผู้ให้บริการ ณ เวลาที่เผยแพร่ ซึ่งไม่เท่ากับค่าใช้จ่ายจริง

Claude Opus 4.6 มีความแม่นยำสูงสุด แต่ต้นทุน API โดยประมาณสำหรับการรันชุดข้อมูล 105 ข้อทั้งหมดอยู่ที่ประมาณ 31.6 ดอลลาร์สหรัฐ; GPT-5.4 ใช้ประมาณ 6.3 ดอลลาร์สหรัฐ ได้อันดับสอง โดยอัตราผ่านต่ำกว่าเพียง 2.9 จุดเปอร์เซ็นต์; GLM-5 ใช้ประมาณ 2.5 ดอลลาร์สหรัฐ ได้อัตราผ่าน 61.9% เท่ากับ Claude Sonnet 4.6 โดยต้นทุนโดยประมาณคิดเป็นประมาณ 7.8% ของ Opus หรือประมาณ 1/12.8

สำหรับทีมที่ต้องการปรับใช้ Agent จริงๆ อันดับรวมเป็นเพียงจุดเริ่มต้น มิติการตัดสินใจที่ใช้งานได้จริงกว่าคือ “อัตราความแม่นยำในตระกูลเวิร์กโฟลว์เฉพาะ × ต้นทุน”

จาก Claw-Eval สู่ Claw-Eval-Live อะไรถูกผลักดันไปบ้าง?

Claw-Eval ผลักดันการประเมิน Agent จาก “การดูแค่ผลลัพธ์” ไปสู่ “การดูกระบวนการ” การมีส่วนร่วมที่สำคัญที่สุดคือการพิสูจน์ว่าหากไม่มีเส้นทางการดำเนินการ บันทึกการตรวจสอบ และภาพรวมสภาพแวดล้อม Agent benchmark จะประเมินความสามารถของโมเดลสูงเกินไปอย่างเป็นระบบ

Claw-Eval-Live ผลักดันการประเมิน Agent จาก “คลังโจทย์คงที่” ไปสู่ “ภาพตัดขวางของงานที่วิวัฒนาการร่วมกับความต้องการจริง”

มันเปิดเผยว่า: เมื่อ benchmark สอดคล้องกับเวิร์กโฟลว์จริงอย่างแท้จริง โมเดลที่ดีที่สุดก็สามารถผ่านได้เพียงสองในสามของงาน; สิ่งที่สัญชาตญาณบอกว่ายากอย่างการซ่อมแซมเทอร์มินัลนั้นใกล้จะแก้ไขได้แล้ว คอขวดที่แท้จริงคือการจัด业务流程ข้ามระบบ; งานประเภท HR, การจัดการ และเวิร์กโฟลว์ยังคงยากอย่างเห็นได้ชัด

สองขั้นตอนนี้ขาดไม่ได้

หากไม่มีขั้นตอนแรก คุณอาจถูกหลอกโดย Agent ที่ “ดูเหมือนทำงานเก่ง” – รายงานของมันเขียนได้ดีมาก แต่มันไม่เคยค้นหาข้อมูลเหล่านั้นจริงๆ

หากไม่มีขั้นตอนที่สอง คุณอาจใช้ชุดงานที่ค่อยๆ เบี่ยงเบนจากความเป็นจริง เพื่อสรุปผลที่ดูแม่นยำแต่ไม่เกี่ยวข้องอีกต่อไป – อันดับของคุณคงที่ แต่มันกำลังตอบคำถามที่ไม่มีใครถามอีกแล้ว

เขียนท้าย

ถ้า Agent จะก้าวไปสู่การปรับใช้จริงๆ benchmark ไม่สามารถผลิตแค่ตารางอันดับเดียวได้ มันควรตอบสองสิ่งด้วย: Agent นี้ทำงานสำเร็จจริงหรือไม่; และเรากำลังใช้ชุดงานอะไรเพื่อนิยาม “การทำงานเป็น”

Claw-Eval ตอบคำถามแรก: เราจะรู้ได้อย่างไรว่า Agent ทำงานสำเร็จจริง Claw-Eval-Live ตอบคำถามหลัง: เรากำลังใช้ชุดงานอะไรเพื่อนิยาม “การทำงานเป็น” ข้อแรกวางรากฐานความน่าเชื่อถือให้กับการประเมิน Agent; ข้อหลังผลักดัน benchmark จากคลังโจทย์คงที่ ไปสู่ภาพตัดขวางของงานที่วิวัฒนาการไปพร้อมกับโลกจริง

สำหรับ AI Agent ในปัจจุบัน ขั้นตอนนี้มีความสำคัญอย่างยิ่ง เมื่อความสามารถของมันค่อยๆ เข้าใกล้จุดวิกฤตของการปรับใช้จริง เกณฑ์การประเมินหลักไม่ได้เป็นแค่ “สามารถแก้โจทย์ได้ถูกต้องหรือไม่” อีกต่อไป แต่เป็นว่าเกณฑ์การประเมินสามารถสะท้อนกระบวนการทางธุรกิจที่ควรทำอัตโนมัติมากที่สุดในโลกจริงได้อย่างแม่นยำหรือไม่

ถ้าจะบอกว่าการแข่งขันโมเดลภาษาใหญ่ในอดีตเป็นเหมือนครึ่งแรกของการแสดงความสามารถ การประเมิน การตรวจสอบ และการปรับใช้ที่มุ่งสู่เวิร์กโฟลว์จริงต่างหากที่เป็นจุดเริ่มต้นที่แท้จริงของครึ่งหลังของ Agent benchmark

ทำให้การประเมิน Agent แข็งแกร่งก่อน แล้วค่อยให้ benchmark ตามทันโลกจริง