Harness vs context engineering: harness engineering khác prompt và context engineering thế nào

Tóm tắt: ba cấp độ của cùng một bài toán

Prompt engineering trả lời câu hỏi «hỏi như thế nào», context engineering trả lời «mô hình cần biết gì ngay bây giờ», còn harness engineering trả lời «agent làm việc trong môi trường nào và làm sao nó biết mình đã sai». Đây không phải ba cách tiếp cận cạnh tranh, mà là các cấp lồng nhau: một prompt tốt là một phần của ngữ cảnh tốt, và ngữ cảnh được thiết kế kỹ là một trong các hệ thống con của harness.

Sự nhầm lẫn xuất hiện vì cả ba đều thay đổi hành vi của mô hình, nhưng đòn bẩy của chúng khác nhau. Nếu agent không thể chạy kiểm thử, không một cách diễn đạt prompt nào sửa được điều đó. Nếu agent quên các quyết định hôm qua, vấn đề không nằm ở câu chữ của yêu cầu mà ở chỗ trạng thái được lưu trữ. Hiểu rõ sự khác biệt giữa harness vs context engineering giúp bạn tiết kiệm nhiều tuần: bạn không còn viết lại hướng dẫn ở những chỗ mà môi trường mới là thứ bị hỏng.

Prompt engineering: cách diễn đạt một yêu cầu

Prompt engineering là công việc với văn bản của yêu cầu: vai trò, nhiệm vụ, định dạng đầu ra, ví dụ (few-shot), ràng buộc, thứ tự các bước. Đơn vị làm việc là một lần gọi mô hình. Kết quả được đánh giá qua câu trả lời: nó có đúng không, đúng định dạng không, mô hình có lạc hướng không.

Các kỹ thuật điển hình:

• mô tả rõ định dạng đầu ra (lược đồ JSON, bảng, danh sách);
• đưa 2–3 ví dụ «đầu vào → đầu ra đúng»;
• yêu cầu suy luận từng bước trước khi trả lời;
• tách chỉ dẫn và dữ liệu bằng dấu phân cách rõ ràng;
• liệt kê những việc không được làm.

Prompt engineering phát huy tốt với các tác vụ «một đầu vào — một đầu ra»: phân loại, trích xuất dữ liệu, dịch thuật, sinh văn bản theo mẫu. Giới hạn của nó lộ ra khi mô hình bắt đầu hành động: gọi công cụ, sửa tệp, làm hàng chục bước liên tiếp. Lúc đó chất lượng không còn phụ thuộc vào một câu lệnh, mà vào mọi thứ bao quanh mô hình.

Context engineering: thông tin nào đi vào cửa sổ mô hình

Context engineering là quản lý nội dung của cửa sổ ngữ cảnh ở từng bước. Cửa sổ có giới hạn, còn agent trong một phiên dài tích luỹ kết quả lệnh, nội dung tệp và lịch sử hội thoại. Nhiệm vụ là để ở mỗi thời điểm có đúng thứ cần thiết và không có thứ thừa.

Trong đó bao gồm:

• chọn lọc: nạp tệp, tài liệu và đoạn mã nào cho tác vụ (tìm kiếm, RAG, đọc theo yêu cầu);
• nén: tóm tắt lịch sử dài, cắt bớt kết quả lệnh, rút gọn phiên;
• cấu trúc: tệp hướng dẫn đóng vai mục lục, còn chi tiết nằm trong các tài liệu riêng mà agent mở khi cần;
• cách ly: đưa một tác vụ phụ cho subagent với ngữ cảnh riêng sạch sẽ, để luồng chính không bị làm bẩn.

Thước đo của context engineering là agent có tìm được đúng quy tắc hoặc thông tin vào đúng lúc hay không, và có bị chìm trong nhiễu hay không. Triệu chứng điển hình: quy tắc đã được viết trong CLAUDE.md nhưng agent vẫn vi phạm, vì tệp dài năm trang và quy tắc bị lạc giữa giọng văn và những thói quen yêu thích của trưởng nhóm.

Harness engineering: mọi thứ bao quanh mô hình

Harness («dây cương») là môi trường mà agent làm việc. Trong đó mô hình chỉ là một thành phần, vào vòng lặp một lần. Mọi thứ còn lại — hướng dẫn, công cụ, môi trường, trạng thái và phản hồi — do kỹ sư thiết kế. Harness engineering đảm bảo rằng agent không chỉ viết được mã mà còn chạy được nó, kiểm chứng, biết được lỗi và tiếp tục công việc ở phiên sau đúng từ chỗ đã dừng.

Có thể chia harness thành năm hệ thống con:

Trong sơ đồ này, context engineering nằm bên trong hai hệ thống con đầu: nó quyết định hướng dẫn và kết quả công cụ đi vào cửa sổ như thế nào. Còn harness bổ sung những thứ không thể nhét vào ngữ cảnh: lệnh kiểm chứng đang chạy, môi trường có thể tái lập, tệp trạng thái tồn tại qua các lần khởi động lại.

Bảng so sánh

Vì sao chỉ prompt và ngữ cảnh là không đủ

Câu chuyện kinh điển: nhóm thấy agent mắc lỗi và dành một tuần để viết AGENTS.md dài năm trang. Agent vẫn không chạy linter trước khi commit. Nguyên nhân không nằm ở văn bản: agent đơn giản là không có shell với quyền cần thiết, còn linter thì chưa được cài trong image. Đây là vấn đề của công cụ và môi trường, nhưng lại được chữa bằng hướng dẫn.

Câu chuyện thứ hai: agent sửa cùng một lỗi suốt ba phiên liên tiếp, vì sau mỗi lần khởi động lại nó không nhớ đã thử gì. Context engineering bên trong một phiên không giúp được gì ở đây: cửa sổ bị xoá. Cần một hệ thống con trạng thái — một tệp để agent ghi các lần thử và quyết định, cùng quy tắc đọc tệp đó khi bắt đầu làm việc.

Câu chuyện thứ ba là đắt giá nhất: agent viết «xong», unit test đều xanh, nhưng tính năng không hoạt động. Không có prompt «hãy kiểm tra cẩn thận» nào, cũng không có thêm tài liệu nào trong ngữ cảnh, có thể mang lại cho agent một kiểm chứng độc lập. Chỉ phản hồi từ máy móc mới làm được điều đó: kiểm thử đầu cuối, script xác minh, hoặc một người đánh giá riêng không có quyền truy cập lập luận của người thực thi.

Kết luận chung: prompt và ngữ cảnh ảnh hưởng đến việc mô hình nghĩ gì. Harness ảnh hưởng đến việc mô hình có thể làm gì và biết gì sau khi hành động.

Vì sao thay mô hình không giải quyết được

Phản ứng thường gặp khi agent bất ổn là chuyển sang một mô hình mạnh hơn. Thường cách này không chữa được gì: cùng một mô hình trong một repository được cấu hình tốt hoạt động như một senior tự tin, nhưng trong repository không có lệnh kiểm chứng và không có mô tả về stack thì lại lúng túng. Mô hình mạnh hơn không đoán được quy ước của nhóm bạn, không có quyền truy cập cơ sở dữ liệu mà nó không được cấp, và cũng không biết migration bị lỗi nếu không ai chạy nó.

Harness cũng không lỗi thời khi có mô hình mới. Hướng dẫn, môi trường tái lập và kiểm chứng đều cần thiết cho mọi mô hình. Thứ thay đổi là mức độ quản lý vi mô có thể bỏ đi: một mô hình mạnh chỉ cần các bất biến («dữ liệu được kiểm tra ở ranh giới miền»), chứ không cần hướng dẫn từng bước.

Làm sao biết nên sửa tầng nào

Chẩn đoán theo triệu chứng nhanh hơn mọi thử nghiệm:

Bắt đầu xây harness từ đâu

Nếu xây từ đầu, thứ tự thực tế là: phản hồi → hướng dẫn → trạng thái → môi trường → công cụ. Phản hồi đứng đầu vì nếu không có nó, không thể đo hiệu quả của các thay đổi khác. Khi chưa có lệnh nào trung thực trả lời «chạy được hay không», mọi cải tiến hướng dẫn đều chỉ được đánh giá bằng cảm tính.

Khởi đầu tối thiểu trông như sau:

# AGENTS.md (đoạn trích)
## Cách kiểm chứng
- make check   # lint, kiểu, unit test
- make e2e     # kịch bản đầu cuối
Tính năng chỉ được coi là xong khi cả hai lệnh kết thúc với mã 0.

## Quy tắc
- MUST: mọi truy vấn SQL đều tham số hoá
- MUST: trước khi commit chạy make check
- Chi tiết về thanh toán: docs/payments.md (đọc khi tác vụ liên quan đến thanh toán)

Hãy chú ý dòng cuối: đây chính là context engineering bên trong harness. Tệp đầu vào là bản đồ chứ không phải sách giáo khoa; chi tiết được nạp theo điều kiện «khi nào».

Cách đo đóng góp của từng phần

Harness có một chỉ số mà prompt không có: 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. Người ta gọi đó là verification gap. Lấy 10 tác vụ liên tiếp, sau mỗi tác vụ ghi lại: agent có báo «xong» không và kiểm chứng có thông qua không — bạn sẽ có một con số để so sánh các thay đổi.

Để hiểu hệ thống con nào đem lại hiệu quả, người ta dùng ablation: cố định mô hình và bộ tác vụ, sau đó tắt lần lượt từng phần của harness và xem mức sụt giảm. Cần nhớ hai điều. Đừng bắt đầu bằng ablation mà bằng nhật ký thất bại: việc gắn nhãn xem lỗi nằm ở tầng nào sẽ chỉ ra điểm nghẽn nhanh hơn. Và việc không sụt giảm không chứng minh thành phần đó vô dụng: có thể bộ tác vụ này không kích hoạt nó.

Những lỗi thường gặp

• Coi harness là một tệp prompt. Hướng dẫn chỉ là một trong năm hệ thống con. Một kệ đựng công thức chưa phải là bếp.
• Chữa việc thiếu công cụ bằng văn bản. «Luôn chạy kiểm thử» vô ích nếu kiểm thử không chạy được trong môi trường của agent.
• Thổi phồng hướng dẫn. Tệp đầu vào càng dài, khả năng quy tắc quan trọng không được đọc càng cao. Tốt hơn là biến quy tắc quan trọng thành kiểm chứng có thể chạy.
• Tin vào báo cáo tự đánh giá của agent. Mô hình tự đánh giá công việc của mình thường có xu hướng đánh giá cao. Người kiểm tra phải là script hoặc một agent riêng với ngữ cảnh sạch.
• Cấu hình harness một lần rồi thôi. Nó lỗi thời như mã nguồn: quy tắc lệch khỏi thực tế, lệnh thay đổi. Cần rà soát định kỳ.

Tóm lại

Prompt engineering cải thiện cách diễn đạt, context engineering quyết định thông tin nào vào cửa sổ mô hình, còn harness engineering xây dựng toàn bộ môi trường của agent, bao gồm công cụ, môi trường, trạng thái và kiểm chứng. Khi agent làm việc lâu và tự thay đổi mã, harness trở thành yếu tố quyết định: nó biến câu «agent nói xong» thành «hệ thống đã kiểm chứng rằng nó chạy được». Vì vậy trong cuộc tranh luận harness vs context engineering, không phải là chọn một trong hai: ngữ cảnh là một phần của harness, và cần sửa hệ thống con mà triệu chứng chỉ ra. Chủ đề này được trình bày qua thực hành trong khoá học harness engineering trên một dự án backend thanh toán thực tế.