Kỷ nguyên thiết kế môi trường làm việc quan trọng hơn cả mô hình: Harness Engineering

Đây là bài phân tích về “Harness Engineering” do Addy Osmani tổng hợp. Ông cho rằng trong 2 năm qua, sự chú ý của ngành đã quá tập trung vào câu hỏi “mô hình AI nào thông minh hơn”. Người ta liên tục so sánh xem GPT có viết mã gọn gàng hơn không, Claude có ít bị ảo giác hơn không, nhưng lập luận của ông là hiệu quả thực tế của AI lập trình lại được quyết định nhiều hơn bởi harness bao quanh mô hình, chứ không phải bản thân mô hình. Harness là khái niệm bao trùm mọi thứ ngoài mô hình: system prompt dùng để giao việc cho AI, các công cụ và máy chủ bên ngoài mà nó có thể dùng, chính sách quản lý ngữ cảnh, các thiết bị kiểm tra tự động can thiệp trong khi chạy (hook), không gian thực thi an toàn (sandbox), AI hỗ trợ (sub-agent), vòng lặp phản hồi, cho đến cả luồng khôi phục khi công việc bị tắc. Viv Trivedy đã chính thức hóa khái niệm này bằng một câu: “AI agent = model + harness”, và những người như đội ngũ kỹ thuật Anthropic, HumanLayer, Simon Willison đang tiếp tục mài giũa xu hướng này. Osmani cho rằng nay nó đã trở thành một lĩnh vực kỹ thuật riêng.

Nếu triển khai các ý chính, nội dung như sau.

• Harness là gì Chỉ với mô hình thì AI chưa thể trở thành một tác nhân hoàn thành công việc. Nó phải có thêm mã và cấu hình để nhớ tiến độ, chạy công cụ, xem kết quả rồi đánh giá lại, đồng thời ngăn những việc không được phép làm, khi đó mới trở thành “AI làm việc”. Các sản phẩm như Claude Code, Cursor, Codex, Aider, Cline đều là harness, và ngay cả khi dùng cùng một mô hình bên trong, hành vi mà chúng ta cảm nhận được vẫn do harness chi phối. Mượn cách diễn đạt của Simon Willison, AI agent là “một hệ thống lặp đi lặp lại việc sử dụng công cụ để đạt mục tiêu”, và bản chất năng lực nằm ở cách thiết kế bộ công cụ cùng cấu trúc lặp đó.

• Góc nhìn: không phải lỗi mô hình mà là lỗi cấu hình Khi AI làm điều ngớ ngẩn, các kỹ sư thường đổ lỗi cho mô hình và kết luận rằng “hãy chờ bản tiếp theo”. Harness Engineering bác bỏ phản ứng đó. Mượn cách nói của HumanLayer, “đây không phải vấn đề của mô hình mà là vấn đề kỹ năng/cấu hình (skill issue)”. Có trường hợp cùng dùng mô hình Claude Opus 4.6, nhưng trong harness mặc định là Claude Code thì chỉ ở nhóm dưới của Terminal Bench 2.0, còn khi chuyển sang harness tự tinh chỉnh thì vọt lên nhóm đầu. Đội của Viv đã chỉ thay harness mà đưa cùng một mô hình từ khoảng hạng 30 lên khoảng hạng 5. Điều đó cho thấy tiềm năng vốn có của mô hình thường bị harness làm giảm đi.

• Nguyên tắc “ratchet”: biến sai lầm thành quy tắc Một khi AI đã từng mắc lỗi, không coi đó là tai nạn ngẫu nhiên mà xem như tín hiệu cần được lưu lại vĩnh viễn. Để lần sau lỗi đó không lặp lại, người ta siết hệ thống từng nấc: thêm một dòng vào tài liệu quy tắc, gắn bộ chặn tự động, hoặc bổ sung AI phụ trách kiểm tra. Ví dụ, nếu AI từng comment hóa mã kiểm thử, thì ở phiên bản tiếp theo tài liệu quy tắc sẽ có thêm dòng “không được comment test; hãy xóa hoặc sửa”, và ở bước kiểm tra trước khi commit sẽ thêm trình kiểm tra bắt đúng mẫu đó. Điểm cốt lõi là mọi dòng trong tài liệu quy tắc tốt đều phải gắn với một thất bại cụ thể đã từng xảy ra. Vì vậy Harness Engineering không phải là bê nguyên một framework có sẵn về dùng, mà gần hơn với một “kỷ luật” được nuôi lớn theo lịch sử lỗi của chính codebase của bạn.

• Thiết kế ngược từ hành vi mong muốn Cách tư duy hữu ích nhất mà Viv đề xuất là thiết kế ngược theo trình tự “muốn có hành vi này → cần những bộ phận harness nào để tạo ra hành vi đó”. Nếu không thể giải thích bằng một câu rằng một bộ phận tồn tại để tạo ra hành vi gì, thì tốt hơn nên bỏ nó đi. Cụ thể, file system và Git dùng để lưu giữ lâu dài và khôi phục nội dung công việc; bash và khả năng thực thi mã là công cụ vạn năng để thử bất cứ điều gì; sandbox là không gian chạy an toàn để dù có làm hỏng cũng không ảnh hưởng hệ thống chính; file bộ nhớ, tìm kiếm web và công cụ MCP là kênh tích lũy tri thức mới; nén tóm tắt, tách đầu ra công cụ và tính năng skill là thiết bị mở rộng giới hạn trí nhớ của AI; còn Ralph loop cùng cấu trúc tách planner/evaluator là cách kéo các công việc dài nhiều ngày đến tận cùng.

• Vấn đề context rot AI có giới hạn về lượng văn bản có thể đọc trong một lần, và khi tiến gần giới hạn đó, khả năng phán đoán giảm đi thấy rõ. Vì vậy harness cũng là tập hợp cơ chế để dùng tốt không gian ngữ cảnh hữu hạn. Thứ nhất, khi gần chạm ngưỡng, nó sẽ thông minh tóm tắt và nén lại nội dung cũ. Thứ hai, với đầu ra lớn như log 2.000 dòng, nó chỉ giữ phần đầu và phần cuối trong ngữ cảnh, còn phần thân thì tách ra file và chỉ đọc lại khi cần. Thứ ba, thay vì đưa toàn bộ công cụ và chỉ thị ngay từ đầu, nó dùng cách “công bố dần”, chỉ lôi ra đúng lúc công việc thực sự cần. Với các tác vụ thật sự dài, đôi khi người ta còn khởi động lại từ đầu trong một cửa sổ mới chỉ với tài liệu bàn giao. Anthropic chỉ ra rằng “với công việc dài, chỉ nén tóm tắt là chưa đủ; có lúc phải khởi động lại bằng một tài liệu bàn giao có cấu trúc”. Nếu so với con người, điều này giống như chuẩn bị tài liệu gọn gàng khi chuyển việc cho nhân sự mới.

• Các mẫu để kéo dài công việc Một điểm yếu của mô hình ngày nay là muốn kết thúc công việc quá sớm, không giỏi chia nhỏ vấn đề lớn, và khi cửa sổ ngữ cảnh thay đổi thì dễ mất mạch. Harness phải bù cho các điểm yếu đó. Ralph loop là kỹ thuật đơn giản trong đó mỗi khi mô hình định kết thúc công việc, hook sẽ chặn lại, bơm lại mục tiêu ban đầu vào cửa sổ ngữ cảnh mới và buộc công việc tiếp tục. Mỗi vòng lặp bắt đầu trong trạng thái sạch, nhưng kết quả vòng trước vẫn được nối tiếp qua file system. Trong khi đó, Anthropic nhấn mạnh rằng phải tách “bên sinh kết quả” và “bên đánh giá” thành hai AI khác nhau, vì nếu AI tự chấm kết quả của chính mình thì thường quá dễ dãi. Ngoài ra, mẫu “sprint contract” — thống nhất trước khi bắt đầu rằng trạng thái nào mới được coi là hoàn thành — rất hiệu quả để ngăn mục tiêu bị nở dần trong lúc làm.

• Vai trò của hook “Dặn AI làm như vậy” khác với “hệ thống buộc nó phải làm như vậy”. Hook là cơ chế tự động lấp khoảng trống đó, can thiệp vào các thời điểm như trước khi dùng công cụ, sau khi sửa file, trước khi commit, hoặc khi phiên làm việc bắt đầu. Ví dụ, mỗi lần sửa mã thì tự động chạy kiểm tra cú pháp, lint, test; chặn các lệnh nguy hiểm như rm -rf hay git push --force; hoặc buộc phải có phê duyệt của con người trước khi mở PR. Nguyên tắc là “thành công thì im lặng, thất bại thì ồn ào”. Nếu kiểm tra qua, AI không nhận bất kỳ tín hiệu nào; nếu thất bại, thông báo lỗi sẽ được bơm thẳng vào luồng để nó tự sửa. Đây là cấu trúc gần như không tốn chi phí lúc bình thường nhưng hỗ trợ cực chính xác khi có sự cố.

• Tài liệu quy tắc và lựa chọn công cụ phải ngắn, rõ AGENTS.md đặt ở thư mục gốc dự án là file cấu hình có ảnh hưởng lớn nhất vì nó đi vào system prompt ở mọi lượt. HumanLayer khuyến nghị giữ tài liệu này dưới 60 dòng. Càng dài, trọng lượng của từng dòng càng loãng đi, nên thay vì viết như cẩm nang phong cách chung chung, hãy chỉ giữ các mục thật sự thiết yếu như checklist của phi công. Với công cụ cũng vậy: vì tên, mô tả và schema của công cụ đều được ghim vào prompt ở mỗi yêu cầu, nên 10 công cụ được mài giũa tốt sẽ tốt hơn 50 công cụ na ná nhau. HumanLayer cũng nhắc đến khía cạnh bảo mật. Vì mô tả công cụ chính là văn bản mà AI đọc, nên việc gắn một máy chủ MCP bên ngoài chưa được kiểm chứng có thể trở thành con đường lén tiêm chỉ dẫn do người khác viết sẵn vào AI.

Đây là những điểm có thể xem là ưu thế.

• Xác định rõ nơi nên đầu tư công sức Dữ liệu benchmark cho thấy harness là nơi có thể cải thiện mạnh hành vi mà không cần đổi mô hình. Thay vì chỉ hy vọng mơ hồ rằng “chờ mô hình kế tiếp”, giờ đã có một vùng can thiệp cụ thể có thể chỉnh ngay.
• Cấu trúc giúp tích lũy know-how Nhờ cách ratchet biến sai lầm thành quy tắc, bài học học được một lần sẽ ở lại như tài sản của đội ngũ. Dù con người thay đổi, tài liệu quy tắc và hook vẫn còn đó để bảo vệ người tiếp theo.
• Sự xuất hiện của harness dựng sẵn (HaaS) Xu hướng mà Viv gọi là “Harness-as-a-Service” đang định hình rất nhanh. Những sản phẩm như Claude Agent SDK, Codex SDK, OpenAI Agents SDK đã gói sẵn vòng lặp công việc, công cụ, quản lý ngữ cảnh, hook và sandbox, giúp người dùng tập trung vào tri thức miền của mình thay vì phải xây mọi thứ từ đầu.

Cũng có những phần đáng lo.

• Phạm vi phải tự quản rất rộng Từ chỉ thị, công cụ, không gian thực thi an toàn, kiểm tra tự động đến quan sát log đều phải tự chịu trách nhiệm. Điểm cốt lõi là đây không phải phần mà nhà cung cấp mô hình sẽ tự lo cho bạn.
• Rủi ro gắn chặt giữa mô hình và harness Các mô hình hiện nay được hậu huấn luyện trong một số harness cụ thể, nên khi chuyển sang harness khác, hiệu năng có thể tụt đột ngột. Chỉ cần đổi tên công cụ hoặc đổi định dạng tham số là kết quả đã có thể dao động. Nếu là mô hình thật sự tổng quát, nó lẽ ra không nên bị ảnh hưởng bởi tên công cụ, nhưng do cơ chế huấn luyện đồng thời nên đã sinh ra một dạng overfitting.
• Rủi ro bảo mật từ công cụ bên ngoài Với máy chủ MCP, mô tả công cụ được đọc nguyên xi bởi AI, nên từ khoảnh khắc bạn gắn một công cụ chưa được kiểm chứng, văn bản bên ngoài đã bắt đầu ảnh hưởng đến AI ngay cả trước khi người dùng gõ một chữ nào.

Đây là góc nhìn tạo khác biệt.

• Giữ khoảng cách với diễn ngôn lấy mô hình làm trung tâm Thay vì không khí chờ đợi một GPT thông minh hơn, bài viết đưa ra phương pháp kỹ thuật để đẩy giới hạn của mô hình hiện có lên mức tối đa. Chẩn đoán ở đây là khoảng cách giữa giới hạn AI hiện đang thể hiện và năng lực thực sự của mô hình phần lớn là khoảng cách của harness.
• Harness không biến mất mà chỉ đổi chỗ Khi mô hình tốt hơn, một số bộ phận harness sẽ không còn cần thiết. Chẳng hạn Opus 4.6 gần như xóa bỏ kiểu nôn nóng từng phổ biến ở Claude Sonnet 4.5 như “ngữ cảnh sắp hết rồi, phải kết thúc nhanh thôi”, khiến nhiều cơ chế phụ trợ để trấn an trước đây trở thành dead code. Nhưng ở những vùng năng lực mới mà mô hình chạm tới sẽ lại xuất hiện điểm yếu mới, và harness mới lại cần được tạo ra để lấp chỗ đó. Câu của Anthropic rất hợp ở đây: “Mọi bộ phận của harness đều chứa một giả định về việc mô hình không thể tự làm được điều gì”.
• Vòng phản hồi giữa học mô hình và thiết kế harness Một xu hướng khác mà Viv chỉ ra là vòng phản hồi giữa thiết kế harness và quá trình huấn luyện mô hình. Khi một mẫu hữu ích được phát hiện trong harness, nó sẽ được chuẩn hóa; thế hệ mô hình tiếp theo lại được huấn luyện dựa trên mẫu đó; rồi trên chính mô hình mới ấy, các mẫu harness mới lại được tạo ra. Vì vậy kết luận là “harness tốt” không phải harness mà mô hình đã được huấn luyện cùng, mà là harness được mài lại để phù hợp với chính công việc của bạn.
• Ngành đang hội tụ về cùng một hình dạng Các AI lập trình như Claude Code, Cursor, Codex, Aider, Cline dùng những mô hình khác nhau bên trong, nhưng hình dạng của harness thì ngày càng giống nhau. Sự thật rằng mô hình khác nhau nhưng harness lại tương tự là một tín hiệu cho thấy lĩnh vực này đang dần ổn định ở đâu.

Bài viết của Osmani cho thấy năng lực cạnh tranh của AI lập trình bị chi phối bởi thiết kế harness xung quanh nó nhiều hơn là lựa chọn mô hình, và harness không phải file cấu hình thiết lập một lần là xong mà là một hệ thống sống được cập nhật liên tục theo lịch sử thất bại. Mô hình có tốt hơn cũng không khiến harness biến mất; thay vào đó, tầng vấn đề được xử lý sẽ dịch lên cao hơn một nấc và harness mới sẽ lấp vào vị trí đó. Như câu của Viv mà ông trích dẫn: “Xây một agent tốt là nghệ thuật của sự lặp lại, và nếu không có phiên bản đầu tiên thì cũng sẽ không có lặp lại”, điều đó có thể đọc như một cuộc đua xem ai bắt đầu nhanh hơn và tinh chỉnh thường xuyên hơn. Rốt cuộc, nơi kỹ sư nên đổ thời gian vào không phải là thay mô hình đang hot hết lần này đến lần khác, mà là liên tục chỉnh sửa harness cho phù hợp với công việc của mình để nâng trần năng lực mà mô hình có thể chạm tới lên từng nấc.

[click]

Mấy thứ như SDD thì hype đã chết từ lâu rồi, giờ chắc là đến lượt harness. Điểm hơi thú vị ở harness là rõ ràng không có trong dữ liệu huấn luyện, vậy mà model lại hiểu khái niệm harness rất nhanh. Không biết có phải vì nó dùng nguyên nghĩa của một từ vốn đã tồn tại hay không, nhưng dù mình còn chưa nhắc tới thì nó đã tự nói kiểu như cập nhật harness trước đã.

[kimjoin2]

Càng ngày càng có cảm giác chỉ toàn xuất hiện thêm rất nhiều thuật ngữ marketing.

[kurthong]

Đây là nội dung thậm chí còn phân tích cả bài viết của một lập trình viên cấp cao, người nói chuyện nghe có vẻ thuyết phục nhưng thực ra chẳng có mấy giá trị cốt lõi nào cả (xin lỗi, cá nhân tôi vốn không thích Google). Tất nhiên, tôi vẫn cho rằng cách tiếp cận nhằm hiểu hiện tượng này là một nỗ lực đáng ghi nhận.