Google chia sẻ kỹ thuật Harness: Cách đánh giá, cải tiến và kiểm soát AI lập trình

9 THÁNG 9, 2026

Khi các lập trình viên bắt đầu xây dựng hệ thống kỹ thuật (harness engineering) cho các hệ thống mã hóa tác nhân (agentic coding systems), họ thường rơi vào cùng một cái bẫy: họ chạy các bộ tiêu chuẩn đánh giá (benchmark) đầu-cuối (end-to-end) phổ biến như Terminal-Bench và DeepSWE, quan sát điểm số tổng hợp thay đổi vài phần trăm, nhưng lại hoàn toàn không hiểu tại sao nó lại thay đổi.

Các bộ tiêu chuẩn đánh giá đầu-cuối là tiêu chuẩn thực tế để đánh giá hiệu suất mô hình và xác định những gì cần điều tra sâu hơn, nhưng thách thức nằm ở chỗ những cuộc điều tra đó đòi hỏi chi phí rất cao.

Đánh giá hành vi (behavioral evaluations) thường là thước đo tin cậy hơn để biết liệu các hành vi bạn mong đợi có thực sự xảy ra hay không và liệu bạn có đang đi đúng hướng thay vì thụt lùi khi gặp các lỗi hồi quy (regressions) hoặc thay đổi mô hình mới. Chúng có thể đóng vai trò là đối tác lặp lại (iteration partner) và giúp cung cấp thông tin chi tiết về lý do tại sao một số thay đổi nhất định lại tạo ra tác động theo hướng này hay hướng khác.

Dưới đây là quan điểm của chúng tôi về đánh giá hành vi, bao gồm các phương pháp đã giúp chúng tôi duy trì sự ổn định cho các hệ thống tác nhân khi các mô hình phát triển.

Sự thay đổi mô hình: Phiếu điểm so với các cột mốc hành vi

Hầu hết các đội ngũ đánh giá các tác nhân AI giống như cách họ đánh giá một học sinh làm bài thi. Họ đưa cho tác nhân một cơ sở mã (codebase) lớn, đặt giới hạn thời gian và đo lường sự thành công dựa trên số lượng bài kiểm tra đạt hoặc trượt.

Khi điểm số đó giảm xuống, điều gì đã xảy ra?

Các bộ tiêu chuẩn đánh giá đầu-cuối thường không trả lời trực tiếp những câu hỏi này.

Đánh giá hành vi hoạt động giống như các bài kiểm tra tích hợp (integration tests) để cải thiện hoạt động của hệ thống tác nhân. Khi bạn có một bộ đánh giá hành vi đủ phong phú, bạn sẽ có một đường cơ sở (baseline) cho hành vi mà bạn đang nhắm tới từ tác nhân của mình, và bạn có thể lặp lại việc cải thiện câu lệnh (prompt) để đạt được mục tiêu đó.

Thay vì đo lường xem tác nhân có giải quyết được toàn bộ quá trình tái cấu trúc (refactor) nhiều tệp hay không, đánh giá hành vi đo lường các hành động rời rạc, có thể quan sát được:

Khi nào nên đánh giá: Tiền lệ "dogfooding" (tự sử dụng sản phẩm của chính mình)

Thay vì thiết lập một hệ thống đánh giá phức tạp ngay từ ngày đầu, hãy tận dụng thời gian này để làm theo trực giác và chạy các thử nghiệm.

Khi khởi tạo một tác nhân từ đầu, bạn bắt đầu bằng bản năng của lập trình viên và việc "dogfooding". Cho đến khi bạn xây dựng được một tác nhân có khả năng tự sử dụng cơ sở mã của chính nó, xử lý các đoạn mã mẫu (boilerplate), tự viết trình hiển thị markdown và thực hiện các tác vụ lập trình thông thường, thì việc chạy các đánh giá là chưa hợp lý.

Các đánh giá thuộc về giai đoạn thứ hai của quá trình phát triển: đảm bảo tiến độ đi lên và bảo vệ chống lại các lỗi hồi quy.

Mục đích chính của một bộ đánh giá không phải là để ăn mừng khi bạn làm cho tác nhân tốt hơn 2%; mà là để mang lại cho bạn sự tự tin vững chắc rằng một thay đổi nhỏ trong câu lệnh, thay đổi lược đồ công cụ (tool schema) hoặc nâng cấp mô hình không làm cho tác nhân trở nên tệ hơn một cách tổng thể.

Kiến trúc của một đánh giá hành vi hoạt động như thế nào

Một khung đánh giá hệ thống mạnh mẽ sẽ tách các khẳng định hành vi thành các kiểm tra kiểu đơn vị (unit-style) nhanh, có tính xác định và chạy cục bộ.

Chuyển trọng tâm sang các hành động nhỏ hơn, có thể quan sát được này sẽ tạo ra một mạng lưới an toàn đáng tin cậy. Bạn có thể tự tin lặp lại các câu lệnh hệ thống (system prompts) hoặc chuyển sang một mô hình khác, vì bạn sẽ biết ngay lập tức nếu vô tình làm hỏng một hành vi cốt lõi.

Viết một đánh giá hành vi

Các đánh giá hành vi khẳng định trên các bước thực thi trung gian, như các lệnh gọi công cụ cụ thể hoặc sửa đổi tệp, thay vì so sánh chuỗi cuối cùng:

Python

Đã sao chép

Ví dụ được viết cho Antigravity SDK. Khám phá toàn bộ kho lưu trữ.

Với một bộ đánh giá hành vi phong phú, bạn có thể tự động hóa kỹ thuật câu lệnh (prompt engineering). Ví dụ, bạn có thể thiết lập một vòng lặp nơi LLM tự điều chỉnh câu lệnh hệ thống của chính nó, lặp lại cho đến khi một bài kiểm tra thất bại cuối cùng vượt qua, trong khi phần còn lại của bộ kiểm tra hoạt động tương tự như một rào chắn kiểu CI/CD. Điều này giúp bạn đảm bảo rằng các thay đổi không làm hỏng bất kỳ tính năng hiện có nào.

Những điều cần cân nhắc khi xây dựng một bộ đánh giá hành vi

Có một vài điều bạn có thể làm ngay từ đầu để giúp quy trình này có thể lặp lại. Tôi đề nghị bạn bắt đầu nhỏ với vòng lặp kiểm tra hành vi ba bước:

Shell

Đã sao chép

Tác nhân của bạn không cần điểm benchmark cao hơn để bắt đầu. Nó cần một hệ thống đánh giá giúp nó hoạt động trung thực.

Để xây dựng một hệ thống ổn định và linh hoạt, bạn phải ngừng coi mô hình của mình như một "hộp đen" vượt qua bài kiểm tra cuối kỳ, và bắt đầu coi hệ thống của mình như phần mềm tiêu chuẩn đòi hỏi phải kiểm thử đơn vị (unit testing) và kiểm thử tích hợp (integration testing).

Suy nghĩ cuối cùng

Mặc dù đánh giá hành vi là trụ cột cốt lõi của kỹ thuật hệ thống, chúng không thay thế cho các bộ đánh giá đầu-cuối lớn hơn. Chúng thực sự bổ sung cho nhau. Các benchmark vĩ mô xác minh đích đến cuối cùng và các đánh giá hành vi vi mô đóng vai trò là đối tác cho phép lặp lại nhanh chóng và an toàn. Khi áp dụng cả hai, bạn sẽ có mức độ tự tin cao hơn khi lặp lại, chẳng hạn như khi thực hiện thay đổi câu lệnh, xây dựng tính năng mới hoặc thậm chí triển khai các mô hình hoàn toàn mới.

Trước

Tiếp theo