Mọi demo agent mình từng xem — kể cả demo của chính mình — đều có cùng một lỗi cấu trúc: chạy một lần, nó chạy được, và cả phòng cập nhật niềm tin về độ tin cậy của agent dựa trên cỡ mẫu bằng một. Benchmark mã nguồn mở mới của Microsoft, ThinkingBox, sinh ra chính là để giết thói quen đó, và những con số nó tạo ra khó chịu đủ để đáng dừng lại suy ngẫm.

Chấm điểm database, không chấm điểm transcript

Phần lớn eval cho agent — kể cả nhiều cái mình từng xây — chấm điểm agent bằng cách đọc transcript của chính nó: nó có nói là đã gọi đúng tool không, nó có claim ticket đã resolved không, tin nhắn cuối có nghe hợp lý không. ThinkingBox bỏ hẳn cách đó. Đây là một sandbox cho tương tác tool-agent-user với các phiên tool cô lập, tương thích MCP, và thay vì tin vào lời kể của agent, nó chạy các assertion thực thi được lên trạng thái backend thật — các dòng dữ liệu trong database — sau khi task hoàn tất.

Sự khác biệt này quan trọng hơn nghe có vẻ. Một agent có thể đưa ra tin nhắn kết thúc hoàn toàn hợp lý (“Tôi đã cập nhật địa chỉ khách hàng và xác nhận thay đổi”) trong khi âm thầm không commit được write, retry nhầm record, hoặc chỉ áp dụng một phần cập nhật rồi dừng lại. Chấm điểm dựa trên transcript bỏ sót cả ba kiểu lỗi này vì nó đang chấm lời kể của agent, không phải hiệu ứng thật của nó. Chấm điểm dựa trên trạng thái bắt được các lỗi này ngay từ thiết kế.

Benchmark: 507 task, năm domain, 20 lần chạy mỗi task

ThinkingBox-bench chạy 507 workflow có điều kiện chính sách (policy-conditioned) trải trên năm domain nghiệp vụ — bán lẻ, khách sạn, bảo hiểm ô tô, IT nội bộ ngân hàng số, và hỗ trợ IT/HR tư vấn. Đây không phải task đồ chơi; đây là kiểu workflow nhiều bước, có trạng thái, bị ràng buộc chính sách — đúng loại việc mà công cụ nội bộ thật sự tự động hóa: xử lý hoàn trả theo một chính sách refund cụ thể, cấp tài khoản trong giới hạn compliance, giải quyết ticket support chạm vào ba hệ thống backend.

Phần phương pháp luận mình sẽ “học lỏm” ngay cả khi không bao giờ đụng tới tool cụ thể của Microsoft: mỗi task trong 507 task được chạy 20 lần riêng biệt cho mỗi model, và Microsoft báo cáo cả pass@1 (thành công ở lần đầu) lẫn pass^20 (thành công ở tất cả 20 lần). Con số thứ hai mới là con số quan trọng với bất cứ thứ gì chạm vào trạng thái production, vì một agent support đúng 65% thời gian khi chạy lần đầu không phải là agent bạn có thể để chạy không giám sát — bạn cần nó đúng gần 100%, nhất quán, qua nhiều lần chạy lặp lại của một task gần giống hệt nhau.

Kết quả mới là điểm mấu chốt

Trên 12 model độc quyền và open-weight, model tốt nhất đạt 65,36% pass@1 — tỷ lệ thành công lần đầu khoảng hai phần ba trên các task nghiệp vụ thực tế. Cùng model đó rơi xuống chỉ còn 25,25% pass^20. Nói cách khác: chạy cùng một task hai mươi lần, model tốt nhất hiện có chỉ đúng ở tất cả các lần thử khoảng một phần tư số trường hợp.

Kiểu lỗi mà Microsoft xác định là phổ biến nhất không phải crash hay throw error — mà là agent “âm thầm làm sai, hoặc làm đúng một phần rồi dừng lại”. Đây là kiểu lỗi khó bắt nhất trong demo và dễ bỏ sót nhất khi review transcript agent, vì không có gì ồn ào để nhận ra. Agent không hoảng loạn; nó chỉ âm thầm ghi sai giá trị rồi tiếp tục.

Học pattern mà không cần dùng tool

Bạn không cần chính ThinkingBox để áp dụng ý tưởng này. Pattern là:

def run_reliability_eval(agent, task, n_trials=20):
    successes = 0
    for i in range(n_trials):
        reset_backend_state(task.fixture)              # reset sạch mỗi lần
        agent.run(task.prompt)                          # để agent hành động
        actual = query_backend_state(task.entity_id)    # kiểm tra system of record
        if assertions_pass(actual, task.expected_state):
            successes += 1
    return {
        "pass_at_1": successes >= 1,
        "pass_hat_n": successes == n_trials,   # tất cả các lần đều thành công
        "success_rate": successes / n_trials,
    }

Hai thay đổi thực sự quan trọng, không phụ thuộc vào tool: assert lên system of record thay vì lời tự báo cáo của agent, và chạy cùng task đủ nhiều lần để thấy tỷ lệ lỗi thay vì một giai thoại đơn lẻ. Một CI eval suite chỉ kiểm tra “agent có gọi đúng tool không” là cần thiết nhưng còn xa mới đủ — nó sẽ vui vẻ pass một agent gọi đúng tool với sai tham số và âm thầm làm hỏng một record.

Góc nhìn của mình

Mình từng viết về việc instrument agent để observability trong production — đây là phần bổ sung ở giai đoạn trước khi lên production. Nếu bạn sắp để một agent chạm vào bất cứ thứ gì giống system of record (billing, inventory, trạng thái tài khoản, trạng thái ticket), pass@1 trên vài lần chạy thủ công gần như không nói lên điều gì. Chạy nó hai mươi lần với cùng kịch bản, assert lên dữ liệu thật, và nhìn vào pass^20 trước khi tin tưởng nó không giám sát. Khoảng cách giữa hai con số đó, trong chính kết quả của Microsoft, là khoảng cách giữa “chạy được trong demo” và “an toàn để ship”.

Paper & benchmark: arxiv.org/abs/2608.19741 · Code: github.com/microsoft/thinkingbox