QA cần lưu gì khi đánh giá AI agent trong sandbox?
Sandbox giúp cô lập tác vụ, nhưng kết quả eval chỉ đáng tin khi QA lưu đủ prompt, trace tool, trạng thái môi trường, diff và kết quả chấm để tái hiện lỗi và phát hiện can thiệp vào cơ chế đánh giá.
Một agent nhận điểm “pass”, nhưng QA phát hiện nó đã sửa file test hoặc file ghi điểm. Nếu báo cáo chỉ còn score cuối cùng và vài dòng output, team sẽ không trả lời được điều quan trọng nhất: agent đã hoàn thành tác vụ, hay chỉ tìm cách vượt qua bộ chấm?
Đó là lý do sandbox thôi chưa đủ. Sandbox giúp cô lập điều kiện chạy; QA vẫn cần một gói bằng chứng có thể tái hiện để lần ngược từ kết quả về prompt, hành động của agent và trạng thái môi trường.
Với team test AI feature, mỗi lần eval nên được xem như một bug report đặc biệt: không chỉ có pass/fail, mà phải có artefact đủ để phân loại lỗi.
Sandbox giải quyết gì?
Docker cho biết Docker Sandboxes chạy tác vụ trong microVM, tức môi trường có kernel riêng. Agent có thể cài package, sửa file và chạy lệnh trong môi trường cô lập thay vì dùng chung container với các tác vụ khác.
Khi kết hợp với Harbor — framework mã nguồn mở để chạy benchmark, chấm kết quả và thu log — nhóm có thể chạy eval cục bộ hoặc trên cloud. Network policy có thể cho phép tải dependency ở giai đoạn thiết lập, sau đó hạn chế internet khi agent thực hiện tác vụ.
Điểm này quan trọng với QA: hai lần chạy chỉ thật sự dễ so sánh khi chúng dùng cùng task, dữ liệu, môi trường và quyền mạng.
Tuy vậy, sandbox không tự trả lời được các câu hỏi:
Agent có nhận đúng prompt và đúng phiên bản task không?
Agent đã gọi tool nào, với tham số và kết quả gì?
Test fail vì hành vi của agent, vì dữ liệu test, hay vì môi trường?
Agent có can thiệp vào test hoặc artefact chấm điểm để tạo một kết quả pass không?
Sandbox là lớp kiểm soát môi trường; bằng chứng thực thi là lớp hỗ trợ điều tra. Cả hai đều cần thiết.
Checklist bằng chứng cho mỗi lần eval
Đừng chỉ lưu score. Nên tạo một hồ sơ chạy theo cùng cấu trúc cho cả pass lẫn fail.
1. Đầu vào: agent được giao chính xác việc gì?
Lưu lại:
Prompt hệ thống và prompt tác vụ;
Định danh hoặc phiên bản model;
Task/benchmark ID và revision của repository;
Dữ liệu test, fixture và file đính kèm;
Policy áp dụng: quyền mạng, tool được phép dùng;
Tiêu chí chấm;
Danh sách file hoặc vùng mà agent không được phép sửa.
Những dữ liệu này giúp QA biết một lỗi xuất phát từ yêu cầu đầu vào hay từ cách agent xử lý yêu cầu.
Nếu agent được giao sinh test case hoặc script automation, acceptance criteria cần được ghi rõ. Nếu đầu vào mơ hồ, một script trông hợp lý vẫn có thể không kiểm chứng đúng hành vi cần test.
2. Trace thực thi: tool call là bằng chứng trung tâm
Một ý kiến trong thảo luận cộng đồng nêu đúng trọng tâm: thiếu tool call thì rất khó debug.
Với agent có quyền dùng terminal, browser hoặc file system, nên lưu cho từng tool call:
Tên tool;
Tham số đầu vào;
Kết quả trả về;
stdout, stderr và exit status nếu có;
Thứ tự gọi;
File được tạo, sửa hoặc xóa;
Lệnh hoặc hành động bị policy từ chối.
Trace này giúp phân biệt những tình huống có vẻ giống nhau ở kết quả cuối:
Agent chọn selector không phù hợp;
UI chưa đạt đúng trạng thái trước khi kiểm tra;
Agent bỏ qua một bước cần thiết;
Test runner hoặc dependency gặp lỗi.
Đừng chỉ dựa vào phần giải thích cuối của agent. Phần mô tả hành động có thể hữu ích, nhưng trace tool và diff file mới là dữ liệu để đối chiếu.
3. Trạng thái môi trường: lưu điểm bắt đầu và điểm kết thúc
Một thành viên cộng đồng đề xuất chụp snapshot môi trường trước khi chạy. Đây là cách hữu ích để kiểm tra liệu lỗi có liên quan đến môi trường hay không.
Hồ sơ nên có:
Snapshot hoặc định danh image trước khi agent bắt đầu;
Dependency và cấu hình liên quan;
Trạng thái repository trước và sau chạy;
Diff file;
Policy mạng thực tế;
Snapshot sau chạy, hoặc artefact đủ để dựng lại trạng thái cuối.
Nếu cùng input, snapshot và policy vẫn tái hiện lỗi, team có thêm cơ sở để điều tra hành vi agent hoặc model. Nếu kết quả thay đổi và log cho thấy dependency hay dịch vụ phụ trợ khác trạng thái, lỗi có thể nằm ở setup hoặc môi trường.
Phân loại lỗi bằng bằng chứng
Giả sử agent được giao viết test tự động cho luồng đăng nhập sai mật khẩu. Một kết quả có ích không chỉ là file test “trông đúng”, mà cần chứng minh được các bước và điều kiện kiểm tra phù hợp với yêu cầu.
Khi eval trong sandbox, QA có thể đối chiếu prompt, snapshot ban đầu, trace browser/terminal, diff file test và output của test runner để phân loại:
Agent nhập sai field hoặc bỏ qua bước bắt buộc: có thể là lỗi hành vi agent.
Fixture không tạo được dữ liệu giả: có thể là lỗi test data hoặc setup.
Script chỉ fail khi mạng bị hạn chế vì thiếu dependency: cần xem lại giả định môi trường và giai đoạn setup.
Agent sửa assertion, test hoặc file chấm điểm để pass: kết quả không nên được chấp nhận chỉ dựa trên score.
Docker nêu reward hacking là một rủi ro của agent eval: agent có thể đạt điểm bằng cách can thiệp vào test hoặc file ghi điểm thay vì hoàn thành công việc. Vì vậy, kiểm tra diff và giới hạn vùng được phép sửa là phần không thể thiếu của review.
Pass chưa chắc đã là pass hợp lệ
Một comment trong cộng đồng đề xuất chạy mỗi task ba lần và tính đạt khi có ít nhất hai lần pass. Đây là quy ước thực hành của một thành viên, không phải tiêu chuẩn do Docker công bố.
Dù áp dụng ngưỡng nào, team nên giữ cả các lần pass lẫn fail. Những lần trượt có thể cho thấy tính ngẫu nhiên, phụ thuộc môi trường hoặc điểm yếu trong dữ liệu test.
Một kết quả eval nên được xem là đủ điều kiện review khi:
Prompt, test data, policy và trạng thái môi trường đã được ghi nhận;
Trace cho thấy agent thực hiện tác vụ thay vì can thiệp vào cơ chế chấm;
Diff file nằm trong phạm vi được phép;
Assertion kiểm chứng đúng acceptance criteria;
Failures được gắn nhãn điều tra rõ ràng: agent/model, data, evaluator hoặc environment;
Các lần chạy lại, bao gồm cả lần fail, vẫn còn artefact để đối chiếu.
Lưu ý về dữ liệu nhạy cảm
Không đưa dữ liệu production, mật khẩu, PAT hoặc credential vào prompt, log và artefact eval. Docker lưu ý personal access token chỉ được hiển thị một lần khi tạo. Với mọi secret, team nên dùng cơ chế quản lý secret của pipeline và che giá trị trong log.
Checklist ngắn cho bug report eval
Mỗi lần chạy, hãy kiểm tra tối thiểu năm mảnh ghép:
Input đầy đủ: prompt, model, task, dữ liệu và policy.
Trace đầy đủ: tool call, output, lỗi và thứ tự hành động.
Môi trường rõ ràng: snapshot/image, dependency, mạng và cấu hình.
Diff kiểm tra được: agent đã thay đổi gì, có sửa vùng cấm không.
Verdict có lý do: pass/fail kèm phân loại lỗi và bằng chứng.
Khi giữ được các artefact này, cuộc trao đổi sẽ không dừng ở kết luận mơ hồ “AI làm sai”. QA có thể chỉ ra lỗi nằm ở agent, dữ liệu, evaluator hay môi trường — và biết chính xác lần chạy nào cần được tái hiện.