Câu hỏi phỏng vấn harness engineering: 22 câu hỏi kèm đáp án cho kỹ sư AI

Cách chuẩn bị

Các câu hỏi phỏng vấn về harness engineering thường đi từ tổng quát đến chi tiết: harness là gì, nó gồm những gì, bạn chẩn đoán vấn đề như thế nào, bạn đo hiệu quả ra sao. Người phỏng vấn tìm kiếm tư duy kỹ thuật: khả năng phân biệt vấn đề của mô hình với vấn đề của môi trường và đề xuất một giải pháp có thể kiểm chứng. Dưới đây là 22 câu hỏi kèm đáp án, được nhóm theo chủ đề.

Kiến thức nền

1. Harness của agent là gì?

Harness là toàn bộ môi trường mà AI agent làm việc, ngoài chính mô hình: hướng dẫn, công cụ, môi trường thực thi, lưu trữ trạng thái và vòng phản hồi. Mô hình đưa ra quyết định, còn harness xác định nó biết gì, có thể làm gì và biết kết quả bằng cách nào. Cùng một mô hình trong các harness khác nhau cho chất lượng rất khác nhau.

2. Harness engineering khác prompt engineering và context engineering ở điểm nào?

Prompt engineering làm việc với cách diễn đạt một yêu cầu, context engineering làm việc với những gì vào cửa sổ mô hình ở mỗi bước. Harness engineering bao gồm cả hai và bổ sung những thứ không giải quyết được bằng văn bản: quyền truy cập công cụ, môi trường có thể tái lập, trạng thái giữa các phiên và kiểm chứng kết quả bằng máy.

3. Kể tên năm hệ thống con của harness.

Hướng dẫn (AGENTS.md, CLAUDE.md, skills, tài liệu), công cụ (shell, kiểm thử, linter, trình duyệt, MCP), môi trường (phụ thuộc, runtime, Docker, worktree), trạng thái (PROGRESS.md, danh sách tính năng, quyết định) và phản hồi (make check, E2E, hook, người đánh giá). Thiếu bất kỳ hệ thống con nào không gây ra «kém đi một chút», mà tạo ra cả một lớp lỗi có tính hệ thống.

4. Vì sao thay mô hình bằng một mô hình mạnh hơn thường không giúp ích?

Vì nhiều lỗi không liên quan đến trí tuệ của mô hình. Mô hình mạnh không thể truy cập công cụ mà nó không được cấp, không nhớ phiên hôm qua nếu không có tệp trạng thái, và không biết migration bị lỗi nếu không ai chạy nó. Quy ước riêng của một nhóm cụ thể cũng không thể đoán được.

Chẩn đoán

5. Agent vi phạm một quy tắc được ghi trong CLAUDE.md. Bạn làm gì?

Trước hết kiểm tra xem agent có tìm thấy quy tắc đó không: một tệp dài với hàng chục điểm làm loãng những điều quan trọng. Rút gọn tệp đầu vào thành mục lục, chuyển chi tiết sang tài liệu nạp theo điều kiện. Nếu quy tắc là quan trọng, biến nó thành kiểm chứng có thể chạy — linter, test, guard kiểu grep hoặc hook — khi đó vi phạm sẽ được máy phát hiện, chứ không phụ thuộc vào việc mô hình có chú ý hay không.

6. Làm sao từ triệu chứng xác định hệ thống con nào bị hỏng?

Vi phạm các quy ước đã biết là hướng dẫn. Agent «muốn nhưng không làm được» là công cụ. Mỗi phiên bắt đầu bằng việc sửa môi trường là môi trường. Phiên mới không biết đã dừng ở đâu là trạng thái. «Xong» không khớp với thực tế là phản hồi.

7. Nên bắt đầu xây harness từ hệ thống con nào, và vì sao?

Từ phản hồi. Khi chưa có lệnh nào máy móc trả lời «chạy được hay không», không thể đo hiệu quả của bất kỳ thay đổi nào khác. Thông thường tiếp theo là hướng dẫn, trạng thái, môi trường và công cụ, nhưng thứ tự này mang tính kinh nghiệm và phụ thuộc vào phần nào đang hỏng nặng nhất.

8. Làm sao đo đóng góp của một thành phần harness riêng lẻ?

Bằng ablation: cố định mô hình và bộ tác vụ, tắt lần lượt từng hệ thống con và xem mức sụt giảm. Nhưng tốt hơn là bắt đầu từ nhật ký thất bại có gắn nhãn theo tầng — cách này chỉ ra điểm nghẽn nhanh hơn. Không sụt giảm không có nghĩa thành phần đó vô dụng: có thể các tác vụ này không kích hoạt nó, hoặc nó chỉ là phần dự phòng.

Hướng dẫn và ngữ cảnh

9. Một AGENTS.md tốt được tổ chức như thế nào?

Như một bộ định tuyến chứ không phải sách giáo khoa: dự án là gì, chạy như thế nào, kiểm chứng ra sao, Definition of Done và danh sách ngắn các ràng buộc bắt buộc. Chi tiết nằm trong các tài liệu riêng, có liên kết kiểu «đọc khi tác vụ liên quan đến thanh toán». Tệp đặt ra các bất biến («dữ liệu được kiểm tra ở ranh giới»), chứ không ra lệnh cách triển khai hay thư viện từng dòng.

10. Subagent dùng để làm gì?

Để cách ly ngữ cảnh. Một tác vụ phụ — tìm kiếm trong codebase, review, kiểm tra — được thực hiện trong ngữ cảnh riêng và chỉ trả về kết quả. Luồng chính không bị làm bẩn, và subagent kiểm tra không thừa hưởng lập luận của người thực thi, điều này quan trọng để đánh giá công bằng.

11. «Nợ harness» là gì?

Là độ lệch tích luỹ giữa harness và thực tế: quy tắc đã lỗi thời, lệnh không còn chạy được, tài liệu về các module không còn tồn tại. Nó hoạt động như nợ kỹ thuật: tích luỹ âm thầm và được trả bằng những sự cố của agent. Harness cần được rà soát định kỳ, chứ không chỉ cấu hình một lần.

Trạng thái và phiên làm việc

12. Làm sao chống lại tình trạng agent «mất trí nhớ» giữa các phiên?

Lưu trạng thái trong repository: PROGRESS.md (tình trạng, việc đã làm, điểm nghẽn, các bước tiếp theo), DECISIONS.md (quyết định, lý do, các phương án bị loại), danh sách tính năng có trạng thái và các commit thường xuyên. Trong hướng dẫn, cố định thứ tự khởi động: đọc tiến độ, chạy script kiểm tra môi trường, lấy tính năng đang hoạt động.

13. Quy tắc WIP=1 để làm gì?

Khi agent bắt đầu nhiều tính năng cùng lúc, trạng thái bị phân tán: không có tính năng nào được hoàn thành, các thay đổi lẫn lộn và khó hoàn tác. Một tính năng đang hoạt động cho một điểm kiểm chứng rõ ràng, các commit sạch và cách khôi phục đơn giản sau sự cố.

14. Kiểm tra khởi động nguội (cold start) là gì?

Là kiểm tra xem một phiên mới có thể trả lời các câu hỏi cơ bản mà không cần người gợi ý hay không: đây là dự án gì, đã dừng ở đâu, tính năng nào đang hoạt động, làm sao kiểm chứng mọi thứ ổn. Nếu agent trả lời dựa trên tệp mà không phải đoán, hệ thống con trạng thái đang hoạt động.

Kiểm chứng

15. Vì sao unit test xanh không chứng minh tính năng hoạt động?

Unit test cô lập module và mock các phụ thuộc nên không nhìn thấy các điểm nối: interface không khớp, lan truyền trạng thái (schema đã đổi nhưng cache vẫn cũ), rò rỉ tài nguyên, vấn đề cấu hình và môi trường. Các lỗi mà unit test bắt được là tập con của những lỗi mà test tích hợp bắt được, và tập này lại là tập con của những lỗi E2E bắt được.

16. Verification gap là gì và đo thế nào?

Là tỷ lệ các tác vụ mà agent khai là xong nhưng kiểm chứng độc lập không xác nhận. Lấy 10 tác vụ liên tiếp và ghi nhận cả hai thông tin cho từng tác vụ. Chỉ số này cho một đường cơ sở: sau khi thay đổi harness, tính lại trên một bộ tác vụ tương tự.

17. Viết Definition of Done cho agent như thế nào?

Trong AGENTS.md, dưới dạng danh sách các mục kiểm chứng được: các lệnh kiểm chứng kết thúc với mã 0, có E2E cho kịch bản, migration được áp dụng, tiến độ đã được cập nhật. Nên liệt kê rõ những gì không được coi là xong: «trông có vẻ đúng», «unit test đều xanh», «trên máy tôi chạy được».

18. Vì sao agent không được tự đặt trạng thái «xong»?

Mô hình có xu hướng đánh giá cao công việc của chính mình, và tự đánh giá diễn ra trong cùng ngữ cảnh đã đưa ra quyết định. Trạng thái passing phải do script kiểm chứng đặt dựa trên kết quả chạy, và ghi kèm mã băm commit làm bằng chứng.

19. Làm sao thiết lập một người đánh giá độc lập?

Là một agent hoặc phiên riêng, chỉ thấy yêu cầu, diff và kết quả chạy, không thấy lập luận của người thực thi. Nó đánh giá theo rubric (tính đúng đắn, kiến trúc, test, xử lý lỗi), và mỗi đánh giá phải dẫn chiếu đến tệp, dòng hoặc log. Nên dùng một mô hình khác để không trùng điểm mù.

20. Làm sao biến một quy tắc kiến trúc thành thứ có thể thực thi?

Ba cấp độ: guard kiểu grep (nhanh, theo mẫu), quy tắc linter có hiểu đồ thị import (import-linter, dependency-cruiser) và kiểm thử kiến trúc trong CI. Tất cả được tích hợp vào make check, thất bại với mã khác 0 và in ra WHY và FIX để agent tự sửa vi phạm. Điều kích hoạt một kiểm chứng mới là lần thứ hai cùng một nhận xét xuất hiện khi review.

Làm việc tự động

21. Cần những gì để thả agent làm việc hàng giờ?

Một mục tiêu rõ ràng, một chỉ số tiến độ đơn điệu (ví dụ số tính năng ở trạng thái passing), ngân sách theo thời gian và số lần thử cho mỗi tính năng, hoàn tác tự động khi có hồi quy, và danh sách những việc cần con người: migration, hạ tầng, tiền bạc. Thêm vào đó là cách ly: sandbox hoặc git worktree riêng, để lỗi không ảnh hưởng đến môi trường làm việc.

22. Khi nào một vòng lặp agent là không đủ, và cách thiết kế đồ thị vai trò?

Khi người thực thi bắt đầu tự kiểm tra chính mình và bị kẹt. Lúc đó công việc được chia thành các vai trò: triển khai, review, kiểm thử, merge. Review nhận ngữ cảnh sạch và rubric, merge do mã thực hiện khi review == pass. Nếu review thất bại, tính năng quay lại triển khai, và sau một số lần thất bại liên tiếp nó được khởi động lại với ngữ cảnh sạch — điều đó cho thấy vấn đề nằm ở cách hiểu nhiệm vụ, chứ không phải ở mã.

Tóm lại

Trong phỏng vấn harness engineering, câu trả lời thuyết phục nhất là câu trả lời nói về những thứ kiểm chứng được: file nào, lệnh nào, chỉ số nào. Hãy ghi nhớ năm hệ thống con, verification gap và quy tắc «trạng thái do script đặt». Toàn bộ các chủ đề này được tổng hợp thành một harness thống nhất trên một dự án thực tế trong khoá học harness engineering.