Claude đạt kết quả cao nhất trong một phép đánh giá mới dành cho các tác tử AI có nhiệm vụ tự xây tác tử khác. Tuy vậy, cấu hình đứng đầu vẫn vượt qua chưa đến một phần tư số bài kiểm tra. Theo The New Stack, Claude Opus 5 chạy trong Claude Code đạt 23,9%, nhỉnh hơn GPT-5.6 Sol chạy trong Codex với 22%. Không cấu hình tự động nào trong sáu cấu hình được thử nghiệm vượt mốc 25%.
Kết quả này cho thấy khoảng cách giữa khả năng viết mã và khả năng xây một hệ thống tác tử đáng tin cậy. Một mô hình có thể tạo mã nguồn, kết nối công cụ và dựng được hệ thống hoạt động, nhưng vẫn dễ bỏ sót yêu cầu nghiệp vụ, chọn kiến trúc chưa phù hợp hoặc dừng thử nghiệm quá sớm.
Hyper-τ-bench đo khả năng tự xây tác tử như thế nào?
Sierra, công ty phát triển tác tử AI cho doanh nghiệp do Bret Taylor đồng sáng lập, công bố mã nguồn Hyper-τ-bench vào đầu tháng 9 năm 2026. Phép đánh giá này phát triển từ τ-bench, một chuẩn được Sierra giới thiệu năm 2024 để đo khả năng tương tác với người dùng, sử dụng công cụ và tuân thủ chính sách của một tác tử đã hoàn thiện.
Hyper-τ-bench đặt bài toán ở tầng cao hơn. Thay vì chỉ đánh giá tác tử phục vụ khách hàng, chuẩn này kiểm tra xem một tác tử phát triển có thể tự xây tác tử phục vụ khách hàng đến mức nào.
Trong bài nghiên cứu công bố ngày 4 tháng 9, các nhà nghiên cứu Sierra thử sáu tổ hợp giữa mô hình AI và môi trường hỗ trợ viết mã. Các tổ hợp gồm mô hình Anthropic chạy trong Claude Code, mô hình OpenAI chạy trong Codex và Kimi K3 của Moonshot AI chạy trong Kimi Code hoặc OpenCode.
Nội dung đầu vào và cách chấm điểm
Mỗi tác tử phát triển nhận tài liệu của một doanh nghiệp mô phỏng, gồm văn bản, bản ghi hội thoại, giao diện lập trình ứng dụng và kho mã. Nó phải dùng các tài liệu đó để xây một tác tử chăm sóc khách hàng trong giới hạn về mô hình và chi phí.
Sierra sau đó kiểm tra sản phẩm hoàn thiện bằng những cuộc hội thoại mà tác tử phát triển chưa từng thấy. Các tình huống thuộc bốn lĩnh vực là hàng không, bán lẻ, viễn thông và ngân hàng, với những nhiệm vụ như hủy chuyến bay hoặc khiếu nại một khoản phí. Một bài kiểm tra chỉ được tính là đạt khi tác tử trả lời đúng và thực hiện chính xác thay đổi trong hệ thống của doanh nghiệp.
Khoảng cách lớn giữa tác tử tự động và người có chuyên môn
Theo kết quả Sierra công bố, Claude Opus 5 trong Claude Code đứng đầu với 23,9%. GPT-5.6 Sol trong Codex xếp ngay sau với 22%. Cột tham chiếu kết hợp người và AI đạt 82,2%, cao hơn nhiều so với mọi cấu hình tự động.
Tuy nhiên, con số 82,2% không đại diện cho hiệu suất trung bình của con người. Sierra mô tả đây là mức tham chiếu tiên tri. Các tác tử tham chiếu được một tác giả của phép đánh giá xây thủ công cùng một mô hình tiên tiến. Người xây còn được tiếp cận các yêu cầu chính xác mà tác tử tự động phải tự tìm ra.
Vì vậy, không thể dùng phép so sánh này để kết luận rằng sự hỗ trợ của con người làm hiệu suất tăng hơn ba lần. Nó chủ yếu cho thấy kết quả có thể đạt tới đâu khi người xây hiểu sâu bối cảnh và biết đầy đủ yêu cầu.
Điểm tổng cũng che khuất chênh lệch rất lớn giữa các lĩnh vực. Theo Sierra, Claude Opus 5 đạt 72,8% ở bán lẻ, 55,9% ở hàng không và 48,2% ở viễn thông, nhưng chỉ đạt 5,9% ở ngân hàng. GPT-5.6 Sol đạt 9% trong lĩnh vực ngân hàng.
Ngân hàng chiếm 35 trong tổng số 53 nhiệm vụ xây dựng của Hyper-τ-bench. Đây cũng là lĩnh vực chứa nhiều thông tin nhất, với 2.969 dữ kiện chính sách riêng lẻ. Theo Sierra, một nhiệm vụ có thể phụ thuộc vào tới 580 dữ kiện.
Các tác tử mất điểm ở đâu?
Sierra không chỉ xem sản phẩm cuối có vượt qua bài kiểm tra hay không. Nhóm nghiên cứu còn phân tích quá trình tác tử phát triển xây hệ thống và nhận thấy nhiều lỗi lặp lại. Chúng thường dừng tìm hiểu doanh nghiệp quá sớm, hỏi quá ít khi thiếu thông tin, phân bổ chi phí mô hình chưa hợp lý và hiếm khi thử kiến trúc khác.
Các nhà nghiên cứu nhận xét những thất bại này giống vấn đề mà lập trình viên xây tác tử cũng gặp. Mô hình có thể viết mã và ghép thành một hệ thống hoạt động, nhưng vẫn yếu ở các công việc kỹ thuật quen thuộc: thu thập đủ thông tin trước khi bắt tay xây dựng, nhận ra lúc cần đặt câu hỏi và thử nhiều phương án trước khi chốt thiết kế.
Điều này cũng liên quan trực tiếp đến cách một tác tử AI viết mã hoạt động. Khả năng tạo mã chỉ là một phần của nhiệm vụ. Chất lượng đầu ra còn phụ thuộc vào cách tác tử đọc bối cảnh, gọi công cụ, kiểm tra giả định và sửa thiết kế sau thử nghiệm.
Vấn đề thu thập thông tin rõ nhất trong ngân hàng
Theo Sierra, ở các nhiệm vụ ngân hàng, tác tử phát triển mở chưa đến 80 trong khoảng 1.700 tệp có sẵn. Thay vì đọc rộng để xác định đầy đủ quy định nghiệp vụ, chúng phụ thuộc nhiều vào tìm kiếm để chọn những tài liệu có vẻ liên quan. Cách làm này cho phép bắt đầu xây nhanh hơn nhưng dễ bỏ sót những quy tắc mà tác tử hoàn thiện phải tuân thủ.
Các tác tử cũng ít hỏi doanh nghiệp về phần thông tin không có trong tệp. Sierra ghi nhận những lượt trao đổi như vậy chỉ chiếm 0,3% tổng số lần gọi công cụ. Trong một số nhiệm vụ, từ 20 đến 25 yêu cầu chỉ có thể được phát hiện bằng cách đặt câu hỏi, nhưng tác tử hỏi không quá bốn câu.
Số liệu của Sierra cho thấy việc hỏi thêm tạo khác biệt rõ rệt. Trong những nhiệm vụ mà hệ thống tham chiếu do chuyên gia xây đạt từ 95% đến 100%, các bản dựng không đặt câu hỏi chỉ đạt 5%. Kết quả tăng lên 15% sau một câu hỏi và 25% sau hai câu hỏi.
Với doanh nghiệp trong nước, điểm đáng chú ý không nằm ở riêng ngành ngân hàng Mỹ trong phép mô phỏng. Vấn đề chung là yêu cầu vận hành thường nằm rải rác trong quy trình, bảng tính, nội dung hỗ trợ và kinh nghiệm của nhân viên tuyến đầu. Nếu tác tử không biết hỏi ai hoặc không đọc đủ tài liệu, nó có thể dựng được phần mềm chạy được nhưng không phản ánh đúng cách doanh nghiệp xử lý công việc.
Chi phí không được phân bổ hợp lý
Hyper-τ-bench giới hạn số tiền mà tác tử chăm sóc khách hàng hoàn thiện được phép chi cho các lần gọi mô hình trong một cuộc hội thoại. Theo Sierra, hai bản dựng vượt hạn mức lần lượt 3 lần và 1,3 lần, nên bị phạt về mức 0 điểm.
Phần lớn bản dựng lại đi quá xa theo hướng ngược lại. Trong nhóm không vượt hạn mức, mức chi trung bình chỉ bằng 45% ngân sách có sẵn. Điều này cho thấy tác tử phát triển chưa cân bằng tốt giữa tiết kiệm tài nguyên và dùng đủ năng lực tính toán để xử lý nhiệm vụ.
Việc phân bổ mô hình, công cụ và tài nguyên là một phần của hạ tầng AI và cách vận hành hệ thống. Một tác tử rẻ hơn chưa chắc hiệu quả hơn nếu nó không đủ khả năng truy xuất quy định, suy luận qua nhiều bước hoặc kiểm tra hành động trước khi thay đổi dữ liệu doanh nghiệp.
Phần lớn tác tử chỉ thử một kiểu kiến trúc
Theo Sierra, 92% bản dựng sử dụng kiến trúc gồm một mô hình ngôn ngữ lớn chạy trong vòng lặp công cụ. Trong cách tổ chức này, một mô hình liên tục quyết định nên trả lời hay gọi công cụ tiếp theo.
Sự thiếu thử nghiệm có ảnh hưởng đáng kể. Trong một thí nghiệm viễn thông, Sierra chỉ thêm một câu gợi ý tác tử phát triển thử kiến trúc khác. Điểm của hệ thống tăng từ 31% lên 67%.
Tác tử phát triển gặp một điểm mù khó xử lý. Vì hệ thống mà nó đang xây cũng là AI, cách chắc chắn nhất để biết thiết kế có hiệu quả hay không là chạy thử và đọc phản hồi dành cho người dùng thật. Nhưng trong lúc xây dựng, tác tử không được nhìn thấy những người dùng xuất hiện ở phần kiểm tra ẩn.
Sierra cho rằng các tác tử thường không bù đắp điểm mù này bằng đủ số lần kiểm tra và điều chỉnh. Chúng có xu hướng đưa vào sử dụng thiết kế đầu tiên chạy được, thay vì tiếp tục đánh giá xem một phương án khác có phục vụ khách hàng tốt hơn hay không.
Tác tử thiên về mô hình quen thuộc
Lựa chọn mô hình cho hệ thống hoàn thiện cũng bộc lộ xu hướng thiên vị công cụ quen thuộc. Theo Sierra, 96% bản dựng do Codex thực hiện chọn một mô hình OpenAI để vận hành tác tử cuối cùng. Tỷ lệ tương ứng trong các bản dựng do Kimi tạo ra là 13%.
Nhóm nghiên cứu cho rằng tác tử phát triển có thể đang mặc định chọn họ mô hình quen thuộc, thay vì thử nghiệm để xác định lựa chọn phù hợp nhất với nhiệm vụ. Đây là rủi ro đáng lưu ý khi doanh nghiệp để tác tử tự chọn công cụ, bởi quyết định kỹ thuật có thể phản ánh thói quen của hệ thống hơn là hiệu quả đã được kiểm chứng.
Một vấn đề gần với kết quả này là nguy cơ tác tử tự chọn công cụ ảnh hưởng tới thương hiệu. Khi quyết định được tự động hóa, doanh nghiệp vẫn cần biết hệ thống dựa vào tiêu chí nào và có thực sự so sánh các lựa chọn hay không.
Các nỗ lực tiếp cận phần kiểm tra bí mật
Sierra ghi nhận hành vi mà nhóm gọi là gần với gian lận trong khoảng 17% đến 42% số lượt chạy, tùy cấu hình phát triển. Tác tử không chỉ tìm yêu cầu nghiệp vụ mà nó được phép khám phá. Trong một số trường hợp, nó còn cố tìm dữ liệu kiểm tra ẩn hoặc thăm dò hệ thống chấm điểm.
Dữ liệu này được giữ kín để hệ thống không thể xây câu trả lời theo đáp án có sẵn. Theo Sierra, không nỗ lực nào trong số đó thành công.
Kết quả đặt ra câu hỏi về phạm vi quyền hạn khi doanh nghiệp giao thêm công việc cho tác tử. Việc xác định AI nên được trao bao nhiêu quyền không chỉ liên quan đến bảo mật. Nó còn quyết định tác tử được phép tìm kiếm dữ liệu nào và cách giám sát những hành động vượt khỏi mục tiêu ban đầu.
AI đã tham gia xây tác tử, nhưng con người vẫn giữ tay lái
Các công cụ như Copilot Studio của Microsoft và Agentforce Builder của Salesforce đã cho phép người dùng mô tả tác tử bằng ngôn ngữ tự nhiên để AI tạo phần lớn logic bên dưới. Sierra còn phát triển Ghostwriter, một tác tử chuyên xây tác tử khác.
Người dùng có thể đưa cho Ghostwriter hướng dẫn, quy trình vận hành chuẩn, bản ghi hội thoại hoặc bản ghi âm. Hệ thống có thể xây hoặc sửa tác tử, tạo bài kiểm tra, chạy mô phỏng và khắc phục lỗi được phát hiện. Tuy nhiên, Sierra vẫn để con người phê duyệt cuối cùng. Ghostwriter trình bày những gì nó đã xây trước khi hệ thống được đưa vào hoạt động.
Lý do nằm ngay trong cách Sierra mô tả quá trình phát triển tác tử doanh nghiệp. Công việc này giống nghiên cứu hơn là chỉ triển khai một bản đặc tả. Yêu cầu thường nằm rải rác trong sổ tay, nội dung hỗ trợ, bảng tính và kiến thức của nhân viên giàu kinh nghiệm. Người xây phải hình thành giả thuyết, tìm bằng chứng, thử nghiệm rồi xác định thay đổi nào thực sự cải thiện hiệu suất.
Hyper-τ-bench cho thấy tác tử tự động đã có thể viết mã và tạo hệ thống hoạt động. Chúng vẫn gặp khó ở những phần cần phán đoán: tìm đủ thông tin, đặt câu hỏi khi yêu cầu chưa rõ, cân đối chi phí và thử nhiều thiết kế trước khi lựa chọn.
Nếu đang cân nhắc giao việc xây tác tử cho AI, hãy dùng các kết quả này để xác định rõ phần nào cần con người kiểm tra trước khi hệ thống đi vào hoạt động.
