Làm sao để AI agent đáng tin cậy: lộ trình từng bước từ đo lường đến làm việc tự động

Vì sao agent không đáng tin cậy dù mô hình mạnh

Độ tin cậy của agent là thuộc tính của toàn bộ hệ thống, không phải của riêng mô hình. Một tác vụ dài gồm hàng chục bước, và lỗi tích luỹ dần: nếu mỗi bước đúng 95%, chuỗi mười bước không có lỗi nào chỉ đạt khoảng 60% (0.95^10 ≈ 0.60), còn chuỗi năm mươi bước thì dưới 10%. Bạn không thể nâng độ chính xác của mô hình, nhưng bạn có thể bắt lỗi ngay ở bước đó và làm cho nó rẻ. Đó chính là việc của harness: hướng dẫn, công cụ, môi trường, trạng thái và phản hồi bao quanh mô hình.

Dưới đây là lộ trình đi từ «cảm giác» đến độ tin cậy có thể đo được và tiến tới làm việc tự động. Các bước được sắp theo mức độ hiệu quả: mỗi bước sau dựa trên bước trước.

Bước 1. Đừng đánh giá «theo cảm giác»

Một kỹ sư tin rằng prompt mới đã thay đổi mọi thứ, người khác không thấy khác biệt gì, còn không ai đo lường cả. Hãy bắt đầu bằng nhật ký thất bại: mỗi lần agent bị kẹt, làm hỏng gì đó hoặc báo cáo xong một tính năng không chạy, hãy ghi một dòng.

| ngày  | tác vụ           | chuyện gì đã xảy ra            | hệ thống con   |
|-------|------------------|--------------------------------|----------------|
| 10/10 | chiết khấu giỏ   | «xong», nhưng không chạy e2e   | phản hồi       |
| 10/10 | webhook thanh toán | không khởi động được DB      | môi trường     |
| 11/10 | tái cấu trúc API | lặp lại giải pháp đã bị loại   | trạng thái     |

Cột «hệ thống con» là quan trọng nhất. Sau một tuần, bạn sẽ thấy điểm nghẽn ở đâu và sửa đúng chỗ đó, thay vì sửa tất cả. Đo độ tin cậy bằng số lần chạy thành công là sai lầm: chính nhật ký các lần vấp mới cho biết agent ngã ở đâu.

Bước 2. Đưa vào hai chỉ số: MTBF và MTTR

Độ tin cậy gồm hai con số. MTBF (thời gian trung bình giữa các lần hỏng) đối với agent là số bước nó đi được trước khi vấp. MTTR (thời gian trung bình để khôi phục) là khoảng thời gian cần để đưa agent về trạng thái làm việc sau khi có sự cố. Tính khả dụng tăng lên nhờ chỉ số thứ nhất tăng và chỉ số thứ hai giảm.

Cuộc đua để có một agent không bao giờ mắc lỗi là vô tận. Giảm MTTR thường làm được trong một ngày. Vì vậy hãy bắt đầu với con số thứ hai.

Bước 3. Làm cho lỗi trở nên rẻ

Việc để agent làm việc tự động chỉ chấp nhận được khi chi phí của một lỗi giảm gần bằng không, chứ không phải khi agent không còn mắc lỗi. Muốn vậy cần ba điều:

• Commit nhỏ và sạch — hoàn tác bất kỳ thay đổi nào chỉ bằng một lệnh.
• Cách ly — agent làm việc trong nhánh hoặc bản sao làm việc riêng, ví dụ qua git worktree, và trong sandbox không có quyền truy cập production.
• Script đặt lại môi trường — cơ sở dữ liệu, phụ thuộc và dịch vụ được đưa về trạng thái ban đầu bằng một lệnh.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # tạo lại DB, áp dụng migration, nạp fixtures

Hãy bấm đồng hồ xem toàn bộ quá trình đưa về trạng thái làm việc mất bao lâu. Đó chính là MTTR của bạn. Đồng thời hãy giới hạn bán kính thiệt hại: đặt ngưỡng kích thước diff cho mỗi tác vụ và cấm sửa các tệp nằm ngoài phạm vi của nó.

Bước 4. Khép kín vòng phản hồi

Không có kiểm chứng, agent là thẩm phán duy nhất của chính mình và sẽ thật lòng cho rằng công việc đã xong. Hãy cung cấp cho nó các lệnh để tự kiểm tra và làm cho chúng bắt buộc.

• Fail-fast: kiểm chứng dừng ngay ở lỗi đầu tiên với thông báo rõ ràng, thay vì in ra hàng trăm dòng nhiễu.
• Kiểm tra nhanh sau mỗi lần sửa: linter và kiểm tra kiểu qua hook của agent.
• Dự phòng: một kiểm chứng độc lập thứ hai cho cùng một thuộc tính — kịch bản E2E bên trên unit test. Unit test xanh không chứng minh rằng tính năng hoạt động với người dùng.

Tiêu chí «xong» hãy viết dưới dạng điều kiện kiểm chứng được: «kịch bản E2E đặt hàng với mã khuyến mãi chạy thành công», chứ không phải «đã triển khai chiết khấu».

Bước 5. Chuyển bộ nhớ vào tệp

Agent không nhớ phiên trước. Mọi thứ cần để tiếp tục công việc phải nằm trong repository: mục tiêu, những việc đã làm và cách kiểm chứng, các quyết định kèm lý do, ngõ cụt, bước tiếp theo. Dấu hiệu tốt là phiên mới, chỉ nhận repository và chữ «tiếp tục», liền bắt đầu làm việc hữu ích.

Một lịch sử hội thoại dài đã nén tạo cảm giác liên tục, nhưng làm mất thứ quý giá nhất — lý do của các phương án đã bị loại. Chủ động kết thúc phiên và có trạng thái viết đầy đủ thường rẻ hơn.

Bước 6. Mỗi lần một tác vụ

Định luật Little: số tác vụ đang thực hiện bằng cường độ tiếp nhận nhân với thời gian mỗi tác vụ nằm trong hệ thống. Với năng lực xử lý cố định, làm nhiều tác vụ song song không làm nhanh hơn, chỉ kéo dài từng tác vụ. Với agent điều này còn gay gắt hơn: ba tính năng là ba mô hình miền khác nhau trong cùng một cửa sổ ngữ cảnh.

• Giữ WIP=1: một tính năng cho đến khi có kết quả đã được kiểm chứng.
• Chia tác vụ nhỏ: một khả năng người dùng có thể kiểm chứng, 1–3 tệp, kiểm chứng nhanh hơn một phút.
• Tạo BACKLOG.md làm van xả cho những việc «tiện thể». Phát hiện một khuyết điểm lân cận thì ghi một dòng vào backlog, đừng tự ý sửa.

Bước 7. Tách người thực thi và người kiểm tra

Việc agent tự đánh giá chính mình là một hãm phanh yếu: cùng một phiên viết mã thường có xu hướng cho rằng mã đó đúng. Hãy để một subagent hoặc một phiên riêng đánh giá kết quả, chỉ nhận yêu cầu, diff và kết quả kiểm chứng — không nhận lập luận của người thực thi. Kết luận của người đánh giá phải dựa trên kiểm chứng bằng máy, chứ không phải «trông có vẻ ổn».

Bước 8. Thả agent vào vòng lặp tự động

Harness làm cho một lần chạy đáng tin cậy, vòng lặp làm cho chuỗi lần chạy tự động. Vòng lặp đặt trên harness kém chỉ làm lỗi nhân lên nhanh hơn, vì vậy bước này đến cuối cùng. Vòng lặp đơn giản nhất được mô tả trong ba dòng:

Mục tiêu:    kịch bản e2e thanh toán với mã khuyến mãi chạy thành công
Kiểm chứng: make lint && make test && make e2e
Dừng:       đạt mục tiêu HOẶC 15 lần thử HOẶC 2 giờ → gọi người

Chọn loại vòng lặp theo tác vụ. Nếu công việc có đích đến rõ ràng, cần vòng lặp theo mục tiêu: bộ nhớ về tiến độ, người đánh giá độc lập và ngân sách số bước. Nếu không có điểm kết thúc (kiểm tra CI buổi sáng, phân tích lỗi mới), dùng vòng lặp theo lịch. Lỗi thường gặp là chạy theo lịch một tác vụ có điểm kết thúc: mỗi lần chạy lại bắt đầu từ đầu.

Quy tắc tự động hoá an toàn

• Điều kiện dừng chỉ được là điều máy kiểm chứng được, cộng với giới hạn số lần thử và ngân sách.
• Leo thang: liệt kê trước những việc không được giao cho vòng lặp (migration production, tiền, xoá dữ liệu).
• Nếu tác vụ bị kẹt và tiến độ không thực sự tăng, đó là tín hiệu chuyển cho con người, đừng tiếp tục quay vòng.
• Hãy đọc diff. Tốc độ vòng lặp không được vượt quá tốc độ bạn đọc, nếu không bạn sẽ không còn hiểu codebase của chính mình.

Lỗi thường gặp trên con đường này

Bắt đầu bằng việc viết lại hướng dẫn

Phản ứng phổ biến nhất khi agent gặp sự cố là thêm một quy tắc vào AGENTS.md. Vài tháng sau, tệp phình ra hàng trăm dòng và các quy tắc quan trọng bị chìm. Nếu nhật ký thất bại cho thấy agent không chạy kiểm chứng, thì phải sửa phản hồi: đưa lệnh kiểm chứng và hook vào, đừng thêm một đoạn văn bản nữa.

Sửa tất cả cùng lúc

Năm hệ thống con của harness đều muốn cải thiện cùng lúc. Nhưng khi đó không rõ điều gì đã thực sự giúp ích. Hãy chấm từng hệ thống con theo thang 1 đến 5, dành nửa giờ cho hệ thống yếu nhất và chạy cùng một bộ năm tác vụ điển hình trước và sau. Sự khác biệt trong nhật ký thất bại sẽ cho thấy có tác dụng hay không.

Nhầm lẫn «unit test xanh» với «tính năng hoạt động»

Agent có thể viết một test kiểm tra chính cách triển khai của nó chứ không phải yêu cầu. Test như vậy luôn xanh. Biện pháp bảo vệ là kiểm chứng ở mức người dùng (kịch bản E2E), được viết trước khi triển khai hoặc bởi người kiểm tra độc lập, cùng quy tắc agent không được sửa test để nó qua.

Tắt kiểm chứng để cho nhanh

Kiểm chứng chậm dễ khiến người ta bỏ qua «lần này thôi». Tốt hơn là tách chúng: linter và kiểm tra kiểu nhanh sau mỗi lần sửa, bộ kiểm thử đầy đủ và E2E trước khi nói «xong». Nhờ vậy vòng phản hồi vẫn ngắn và không cản trở công việc.

Coi ablation là bước đầu tiên

Có thể lần lượt tắt từng hệ thống con của harness và xem chất lượng giảm bao nhiêu. Đây là kiểm tra hữu ích, nhưng tốn kém và không nên làm đầu tiên: trước hết nhật ký thất bại chỉ ra điểm nghẽn, còn ablation chỉ xác nhận giả thuyết. Việc không sụt giảm khi tắt một thành phần không có nghĩa là nó vô dụng — có thể bộ tác vụ đã chọn không kích hoạt nó.

Thang trưởng thành

Tóm lại

Để làm cho AI agent đáng tin cậy: đo lường, tìm hệ thống con yếu qua nhật ký thất bại, làm cho lỗi rẻ, khép kín vòng phản hồi, chuyển bộ nhớ vào tệp, giữ một tác vụ mỗi lần và tách người thực thi khỏi người kiểm tra. Chỉ sau đó vòng lặp tự động với điều kiện dừng bằng máy mới trở nên an toàn. Mỗi bước trong lộ trình này được trình bày qua thực hành trong khoá học harness engineering.