TL;DR
Nathan Wilbanks (@NathanWilbanks_) vừa công bố thống kê lifetime của AI agent cá nhân chạy 24/7 của anh: 127,743 workflow (2.71% lỗi), 605,292 tool execution (~0.85% lỗi). Bí quyết giữ tỉ lệ lỗi thấp: kiến trúc REPL loop để agent quan sát lỗi và tự sửa ngay trong vòng lặp tiếp theo — thay vì fail toàn bộ workflow.
Số liệu mới được công bố
Trong một bài tweet hiếm hoi chia sẻ thống kê từ agent production cá nhân, Nathan đưa ra 4 con số:
- 127,743 workflow đã chạy trên account của anh
- 3,465 workflow gặp lỗi → 2.71% tỉ lệ lỗi cấp workflow
- 605,292 tool execution tổng cộng
- 5,136 tool gặp lỗi → ~0.85% tỉ lệ lỗi cấp tool (tweet ghi 0.08% nhưng phép chia thực tế cho ra 0.848%, có vẻ là lệch dấu phẩy thập phân)
Trung bình mỗi workflow gọi khoảng 4.7 tool call — con số này quan trọng khi nhìn qua lăng kính "reliability compounding" ở phần sau.
Tại sao con số này đáng chú ý
Phần lớn benchmark agent công khai (AgentBench, SWE-Bench, τ-Bench) đo task-completion trong môi trường offline, single-run. Số liệu lifetime từ một agent production thực tế thì cực kỳ hiếm. Builder thường giấu nhẹm vì sợ con số xấu sẽ làm người ta nghi ngờ sản phẩm.
Nathan công khai vì 2 lý do thực tế:
- Cộng đồng đang hỏi liệu agent 24/7 có đủ tin cậy để giao việc thật không
- Anh tin rằng kiến trúc REPL loop là câu trả lời, và muốn dùng số liệu để chứng minh
Phân tích kỹ thuật: REPL loop hấp thụ lỗi như thế nào
Nếu nhìn naive, bạn sẽ nghĩ: 5,136 tool errors gây ra 5,136 workflow failures. Thực tế chỉ có 3,465 workflow lỗi — nghĩa là khoảng 1,671 tool error đã được agent tự sửa trong cùng workflow (~32%). REPL loop hoạt động đại khái:
- Agent gọi tool → tool trả lỗi (timeout, 4xx, schema mismatch...)
- Output lỗi đi vào context của vòng lặp tiếp theo
- Agent đọc lỗi, suy luận lý do, thử lại với tham số khác hoặc gọi tool thay thế
- Workflow chỉ được đánh dấu fail khi agent bỏ cuộc hoặc vượt ngân sách step
| Layer | Total runs | Errors | Error rate |
|---|---|---|---|
| Workflow | 127,743 | 3,465 | 2.71% |
| Tool execution | 605,292 | 5,136 | 0.85% |
| Tool calls per workflow (avg) | ~4.7 | ||
So sánh với industry baseline
Bài toán reliability compounding nói rằng nếu mỗi tool có 99% success rate, workflow 10 step chỉ còn ~90% success (0.9910). Áp dụng cho stack của Nathan:
| Per-tool success | Steps | Predicted workflow success | Thực tế của Nathan |
|---|---|---|---|
| 99.15% (Nathan) | 4.7 (avg) | ~96.1% | 97.29% |
| 99% (industry good) | 5 | 95.1% | — |
| 95% (industry typical) | 5 | 77.4% | — |
Stack của Nathan vượt cả prediction naive 1.2 điểm phần trăm — đó chính là phần REPL loop đóng góp: hấp thụ lỗi không cho propagate lên workflow. Tham khảo thêm phân tích reliability compounding của MindStudio.
Replit Agent 3 đang dùng pattern tương tự (test live trong browser → thấy lỗi → sửa) và một số case study production báo cáo ~94% lỗi tự resolve. Nathan hấp thụ ~32% — thấp hơn nhưng anh đo trên một thước đo khác (per-tool-error vs per-workflow-error).
Ai nên quan tâm
- Solo builder / indie hacker đang chạy agent 24/7 cho ops, content, comms: con số này cho bạn một benchmark thực tế để so sánh.
- Team thiết kế agent loop: nếu bạn còn đang dùng pipeline tuyến tính "step-by-step or fail", đây là lý do để chuyển sang observe-fix loop.
- Người chọn vendor agent: hãy hỏi vendor về lifetime stats — benchmark đẹp trên slide thường che giấu reality production.
- Marketing / content automation: 0.85% lỗi tool nghe nhỏ, nhưng trên 600K execution là 5,136 lỗi. Cần loop hấp thụ, không phải retry naive.
Hạn chế & điều cần thận trọng
- Đây là số liệu của một account — không phải benchmark có kiểm soát.
- Không có breakdown theo tool: tool nào lỗi nhiều nhất? API external hay tool internal?
- Định nghĩa "error" chưa rõ — uncaught exception, non-2xx, hay semantic failure?
- Không có dữ liệu về latency, cost-per-task, hay tỉ lệ lỗi user-facing.
- Tweet ghi tool error rate là 0.08% nhưng tính lại từ raw counts ra 0.848%. Khả năng cao là lệch dấu phẩy thập phân; bài này dùng raw counts để tránh nhân rộng sai số.
- Stack không open source — pattern có thể tái hiện nhưng không thể replicate exact.
Bước tiếp theo cộng đồng nên đẩy
Số liệu của Nathan là khởi đầu cho một xu hướng "agent ops transparency" mà cộng đồng đang cần. Nấc tiếp theo:
- Per-tool error breakdown (heatmap tool nào không tin cậy)
- Latency p50/p95/p99 cho workflow và tool
- Cost-per-successful-task — chỉ số duy nhất quan trọng cho production
- Tỉ lệ lỗi user-facing vs silently-retried — phân biệt giữa "agent ổn" và "agent đang gồng"
Nguồn: tweet gốc của Nathan Wilbanks, MindStudio — Reliability Compounding Problem, Anthropic — Demystifying evals for AI agents.
