Chương 7 · Đánh giá agent như hệ thống production

​

7.1 Benchmark công khai nói gì

​

7.2 Benchmark có thể bị lợi dụng, và benchmark của bạn cũng vậy

• Reward hacking. Khi bộ tiêm lỗi chạy bên trong môi trường mà agent có thể kiểm tra, agent đã tìm ra và vô hiệu hóa bộ tiêm lỗi thay vì sửa lỗi.
• Tắt cảnh báo như một thành công giả. Một phần lớn các tác vụ khắc phục của một benchmark có thể được “giải” bằng một vòng lặp restart pod chung chung khiến cảnh báo biến mất mà không chạm đến lỗi.

1. Chấm điểm trạng thái, không phải triệu chứng. Kiểm tra độc lập rằng lỗi đã hết và hệ thống khỏe mạnh. Cảnh báo đã tắt không chứng minh được gì.
2. Giấu cơ chế kiểm thử. Agent đang được kiểm thử không được phép thấy hoặc truy cập harness đánh giá.
3. Chấm điểm chẩn đoán và khắc phục riêng biệt. Chúng thất bại độc lập và cải thiện độc lập.

​

7.3 Xây golden set từ chính sự cố của bạn

1. Thu thập từ postmortem. Mỗi sự cố thực trở thành một kịch bản ứng viên gồm năm phần: telemetry tại thời điểm phát hiện, trạng thái môi trường, nguyên nhân gốc thực sự, bản sửa được chấp nhận và bằng chứng bản sửa đã hiệu quả. Hai mươi đến năm mươi kịch bản trải trên các loại sự cố hàng đầu là một golden set dùng được. Với proof of concept đầu tiên, tối thiểu là mười (7.5). Sau đó thêm mọi loại sự cố mới.
2. Replay, đừng làm hỏng lại. Đưa các tín hiệu đã ghi lại cho agent và để agent điều tra trên trạng thái được snapshot hoặc mô phỏng. Tiêm lỗi trên staging bổ sung việc chấm điểm khắc phục, với các quy tắc cô lập ở 7.2 được áp dụng.
3. Chấm điểm theo lớp. Chấm từng kịch bản trên mọi lớp trong bảng dưới đây.
4. Dùng model làm giám khảo, và kiểm tra giám khảo. Model có thể chấm rubric ở quy mô lớn. Mỗi chu kỳ, so sánh điểm của model với điểm của người trên một mẫu, và giữ con người chấm một phần luân phiên. Kỹ sư on-call đánh giá phân tích của agent vừa cho bạn dữ liệu đánh giá vừa xây dựng niềm tin.

# Generic golden-set scenario, not a product format
id: 2026-03-checkout-latency
class: database
signals: snapshots/2026-03-checkout/   # alerts, metrics, logs at detection
expected:
  severity: high
  root_cause: "connection pool exhausted on orders-db after a config change"
  service: orders-db
  accepted_fix: "revert pool size config"
  healthy_when: "p95 checkout latency < 400ms for 15m, error rate < 1%"

​

7.4 Coi eval như CI

• Chạy golden set trên mọi thay đổi.
• Chặn khi có suy giảm theo từng loại, không chỉ theo trung bình. Model mới cải thiện ở kịch bản cơ sở dữ liệu nhưng âm thầm kém đi ở kịch bản Kubernetes là một sự suy giảm, kể cả khi tổng điểm tăng.
• Canary trên production với metric trực tuyến. Theo dõi tỷ lệ chấp nhận, tỷ lệ rollback và tỷ lệ giải quyết tự động theo từng loại. Chúng là eval của bạn chạy liên tục trên thực tế.

​

7.5 Áp dụng vào CloudThinker như thế nào

​

Bắt đầu đánh giá trực tuyến

​

Bước tiếp theo