Harness Engineering là gì và một harness gồm những gì?

Bạn giao cho AI một công việc lập trình kéo dài nhiều bước. Ban đầu, nó xử lý rất nhanh và có vẻ hiểu đúng yêu cầu. Nhưng càng làm lâu, kết quả càng dễ đi chệch hướng: yêu cầu ban đầu dần bị bỏ sót, những đoạn code vốn không có vấn đề cũng bị sửa, thậm chí AI còn báo test đã thành công dù các thay đổi quan trọng chưa thực sự được kiểm tra.

Đây không hẳn là vấn đề AI viết code kém, mà còn liên quan đến cách chúng ta thiết kế môi trường để AI làm việc. Đó là lúc harness engineering trở nên đáng chú ý.

Trong bài viết này, chúng ta sẽ tìm hiểu harness engineering là gì, một harness hoạt động như thế nào và khi nào bạn thực sự cần đến nó.

Harness là gì, khác gì với viết prompt?

Một agent viết code gồm hai phần: model và harness. Model là phần suy luận, nó đọc yêu cầu và nghĩ ra code. Harness là mọi thứ xung quanh model để nó làm việc được: công cụ để đọc file, chạy lệnh, sửa code; quy tắc nó phải tuân theo; và vòng kiểm tra để nó tự sửa sai. Công thức ngắn gọn mà nhiều người dùng là: Agent = Model + Harness.

Cách làm việc với AI đã đi qua ba giai đoạn. Giai đoạn đầu, 2022–2023, là prompt engineering: viết câu lệnh sao cho model trả lời tốt hơn. Giai đoạn hai, 2024–2025, là context engineering: đưa đúng thông tin vào cho model, gồm file liên quan, quy tắc của dự án và giới hạn kiến trúc. Giai đoạn ba, từ 2026, là harness engineering. Harness engineering là gì, nói gọn nhất? Là việc xây môi trường xung quanh model để nó làm việc tự chủ mà vẫn kiểm soát được.

Viết prompt là dặn model làm một việc. Xây harness là đặt ra hệ thống để model làm cả một chuỗi việc mà không lệch khỏi yêu cầu. Một câu lệnh hay giúp một câu trả lời tốt hơn; một harness tốt giúp cả một nhiệm vụ dài đi đến kết quả đáng tin.

Thực ra, bạn không cần xây dựng harness từ con số không. Một phần đã được tích hợp sẵn trong các công cụ AI coding. Chẳng hạn, Claude Code đã có khả năng đọc và ghi file, thực thi lệnh terminal, duy trì vòng lặp làm việc qua nhiều bước và yêu cầu người dùng xác nhận trước một số hành động nhạy cảm.

Tuy nhiên, những cơ chế đó mới chỉ là nền tảng. Bạn vẫn cần bổ sung các thành phần phù hợp với codebase của mình, chẳng hạn như quy tắc làm việc riêng, các bước kiểm tra tự động và nhật ký ghi lại quá trình thực thi. Đây chính là phần harness mà bạn chủ động thiết kế và xây dựng.

Một harness chạy ra sao

Một harness thường chạy theo bốn bước: lập kế hoạch, tạo, đánh giá, giao. Mỗi bước do một vai riêng đảm nhiệm, và bước sau chỉ chạy khi bước trước qua được cổng kiểm tra.

• Lập kế hoạch: agent lập kế hoạch biến yêu cầu thành bản đặc tả viết ra: mục tiêu, ràng buộc, cách làm, tiêu chí hoàn thành. Nó không viết code.
• Tạo: agent viết code làm theo bản đặc tả, sửa code, viết test. Nó không tự quyết định “xong” là gì, vì bản đặc tả đã định nghĩa điều đó.
• Đánh giá: agent kiểm tra đối chiếu kết quả với bản đặc tả, chạy test, soi trường hợp biên, rồi duyệt hoặc trả lại để sửa.
• Giao: agent vận hành tạo branch, commit và pull request (PR, đề xuất thay đổi code để người khác xem xét rồi mới đưa vào nhánh chính). Bước này chỉ chạy khi các cổng trước đã qua.

Hai điểm làm nên khác biệt. Thứ nhất, mỗi bước dùng một cửa sổ ngữ cảnh riêng và chỉ nhận đúng thứ nó cần: bản đặc tả, bản thay đổi code, kết quả test, báo cáo kiểm tra. Thứ hai, cổng kiểm tra được thực thi, không chỉ gợi ý:.

Một agent ôm cả việc từ đầu đến cuối thường lệch theo năm cách: quên ràng buộc ban đầu khi cuộc trò chuyện dài ra; sửa lan sang phần không yêu cầu; tự chấm code của mình quá dễ dãi; test qua nhưng không kiểm tra đúng thứ thay đổi; và ngữ cảnh bị lấp đầy bởi log và chi tiết triển khai đến mức quên mất mục tiêu. Harness chia việc thành các bước riêng để chặn đúng năm lỗi này.

Vòng kiểm chứng mới là phần quan trọng nhất

Kiểm chứng là vòng lặp tự động kiểm tra chất lượng trong lúc agent làm việc, không đợi đến cuối: chạy test, chạy linter (công cụ kiểm tra lỗi và quy ước code), tự phê bình sau từng bước. Lỗi bị bắt sớm thì không kịp lan thành lỗi lớn, và model không tốn thêm token (đơn vị mà nhà cung cấp dùng để tính phí) để đi tiếp trên một hướng sai.

Tháng 2/2026, đội LangChain đưa agent viết code của họ từ hạng 30 lên hạng 5 trên bảng Terminal Bench 2.0 (bảng xếp hạng các agent viết code) mà không đổi model. Toàn bộ cải thiện đến từ việc tối ưu harness, chủ yếu là vòng kiểm chứng.

Nhóm nghiên cứu của Anthropic chỉ ra ba lỗi cố hữu của model mà chỉ harness mới xử lý được: agent hay tuyên bố xong việc khi chưa kiểm chứng kết quả; khi cửa sổ ngữ cảnh đầy dần, nó vội vàng làm cho xong và cắt góc; và nó hay ôm cả vấn đề trong một lần, tạo ra một mớ thay đổi không có tài liệu.

Kiểm chứng cũng có giới hạn. Với hành vi của ứng dụng, tức là phần mềm có chạy đúng như người dùng cần không, cách phổ biến hiện nay là dựa vào bộ test do chính AI tạo ra rồi kiểm tra bằng tay. Martin Fowler nhận xét thẳng: cách đó đặt quá nhiều niềm tin vào test do AI sinh ra, và chưa đủ tốt.

Một harness gồm những gì

Để trả lời trọn vẹn câu hỏi harness engineering là gì, cần nhìn đủ năm lớp của một harness:

• Điều phối công cụ: quyết định agent chọn và nối các công cụ thế nào (đọc file, chạy lệnh, gọi API) và tự đổi hướng khi một công cụ lỗi.
• Vòng kiểm chứng: kiểm tra tự động trong lúc làm việc, để lỗi không lan thành lỗi lớn.
• Ngữ cảnh và bộ nhớ: giúp agent nhớ codebase và những lần làm trước, thay vì phải dặn lại từ đầu mỗi phiên.
• Giới hạn an toàn: ranh giới cứng như sandbox (môi trường cách ly), trần chi phí, và cổng duyệt của con người trước hành động nhạy cảm như sửa database production.
• Quan sát được: nhật ký và dấu vết thực thi để bạn xem được agent đã làm gì và vì sao, từ đó gỡ lỗi và đo xem thay đổi harness có giúp nó làm tốt hơn không.

Khi nào cần harness, khi nào không

Quy tắc thực hành mà Mitchell Hashimoto nêu ra là: mỗi khi agent mắc một lỗi, hãy bỏ công sửa hệ thống để nó không mắc lại lỗi đó nữa. Phần lớn thời gian, cách sửa đó chính là cải tiến harness.

Bạn cần harness khi giao cho agent những việc dài, cả một tính năng chứ không chỉ một đoạn code, hoặc khi cùng một loại lỗi lặp lại nhiều lần. Bạn cũng cần nó khi kết quả phải có người khác xem xét được, hoặc khi có yêu cầu tuân thủ và an toàn mà công cụ mặc định không lo được, như kiểm tra tuân thủ riêng hay nhật ký kiểm toán.

Bạn chưa cần harness khi việc chỉ là một lần, nhỏ và rõ ràng: sửa một lỗi vặt, viết một đoạn code mẫu. Lúc đó một câu lệnh tốt là đủ, và công xây harness tốn hơn lợi ích nó mang lại.

Có một điểm cần lưu ý: không phải codebase nào cũng dễ xây dựng harness như nhau. Với những dự án có kiểu dữ liệu rõ ràng, các module được phân chia hợp lý và ranh giới giữa chúng tương đối rõ ràng, agent sẽ có nhiều điểm để kiểm tra và đối chiếu kết quả trong quá trình làm việc.

Ngược lại, với những codebase cũ, cấu trúc thiếu nhất quán và các thành phần phụ thuộc chằng chịt, việc xây dựng harness lại khó khăn hơn nhiều. Trớ trêu là đây cũng thường là những dự án cần harness nhất, bởi agent càng khó hiểu cấu trúc và kiểm soát những thay đổi của codebase.

Hiểu nhầm thường gặp

Kết luận

Khi AI viết code, việc của bạn dịch chuyển từ viết từng dòng code sang xây hệ thống quanh model: dặn nó làm gì, kiểm tra nó làm đúng không, và sửa hệ thống mỗi khi nó sai. Đó là harness engineering. Bạn không cần xây một harness hoàn chỉnh ngay từ đầu. Bắt đầu từ một cổng kiểm tracho việc bạn giao thường xuyên nhất, rồi thêm dần khi thấy lỗi lặp lại.

Đọc thêm: Ứng dụng AI cho doanh nghiệp.

Nguồn tham khảo

• OpenAI, “Harness engineering: leveraging Codex in an agent-first world”, openai.com/index/harness-engineering, kiểm chứng 07/11/2026.
• Faros AI, “Harness Engineering: A Guide to AI Coding Agents”, faros.ai/blog/harness-engineering, kiểm chứng 07/11/2026.
• LogRocket Blog, “How to build an agent harness with Claude Code”, blog.logrocket.com/building-an-agent-harness-with-claude-code, kiểm chứng 07/11/2026.
• Martin Fowler, “Harness engineering for coding agent users”, martinfowler.com/articles/harness-engineering, kiểm chứng 07/11/2026.
• LangChain, “Improving Deep Agents with harness engineering”, langchain.com/blog/improving-deep-agents-with-harness-engineering, kiểm chứng 11/11/2026.