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

Đâ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 gần như chỉ dồn vào câu hỏi “mô hình AI nào thông minh hơn”. Người ta so sánh không ngừng xem GPT có viết code gọn hơn không, hay 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 được quyết định bởi harness bao quanh mô hình nhiều hơn là chính mô hình đó. Harness là khái niệm bao trùm mọi thứ ngoài mô hình, bao gồm 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 cơ chế kiểm tra tự động xen vào trong lúc thực thi (hook), không gian thực thi an toàn (sandbox), AI phụ trợ (sub-agent), vòng phản hồi, cho đến cả luồng khôi phục khi công việc bị tắc nghẽn. Viv Trivedy đã chính thức hóa khái niệm này bằng một dòng: “AI agent = model + harness”, và những người như đội ngũ kỹ thuật của Anthropic, HumanLayer, Simon Willison đang tiếp tục mài giũa hướng đi này. Osmani cho rằng giờ đây nó đã trở thành một lĩnh vực kỹ thuật thực thụ.

Nếu triển khai các ý chính, có thể tóm lại như sau.

• Harness là gì Chỉ với mô hình thì chưa thể tạo ra một AI hoàn thành công việc. Phải có thêm code và cấu hình để nó 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 nên làm, thì khi đó mới thành một “AI biết làm việc”. Các sản phẩm như Claude Code, Cursor, Codex, Aider, Cline đều là harness; và ngay cả khi mô hình bên trong giống nhau, hành vi mà người dùng cảm nhận được vẫn do harness quyết định. 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 dùng công cụ để đạt mục tiêu”, và năng lực cốt lõi nằm ở cách thiết kế các công cụ cùng cấu trúc lặp đó.

• Góc nhìn không đổ lỗi cho mô hình mà cho cấu hình Khi AI làm chuyện kỳ quặc, các kỹ sư thường đổ cho mô hình và kết luận rằng “hãy chờ phiên bản tiếp theo”. Harness engineering bác bỏ phản xạ đó. 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 đề cấu hình (skill issue)”. Có trường hợp dùng cùng mô hình Claude Opus 4.6: trong harness mặc định là Claude Code thì chỉ đứng nhóm thấp ở Terminal Bench 2.0, nhưng chuyển sang harness tự tinh chỉnh thì vọt lên nhóm đầu. Nhóm của Viv đã chỉ thay đổi harness mà kéo 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 sẵn có của mô hình nhiều khi bị chính harness làm hao hụt.

• Nguyên tắc “ratchet” biến sai lầm thành quy tắc Một lỗi mà AI từng mắc không được xem là tai nạn ngẫu nhiên, mà là tín hiệu cần được lưu giữ vĩnh viễn. Để lần sau lỗi đó không lặp lại, người ta siết dần 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 đặt một AI phụ trách rà soát. Ví dụ, nếu AI từng comment mất code test, thì ở phiên bản quy tắc tiếp theo 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ẽ bổ sung bộ dò tìm đúng mẫu đó. Điểm cốt lõi là mọi dòng trong một 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 chuyện bê nguyên một framework có sẵn vào dùng, mà gần hơn với một “kỷ luật” được nuôi lớn dựa trên lịch sử lỗi của chính codebase.

• 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 thứ tự: “muốn hành vi này → vậ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 dòng rằng một bộ phận tồn tại để phục vụ hành vi nào, thì tốt hơn nên bỏ nó đi. Cụ thể hơn, file system và Git dùng để lưu trữ lâu dài và khôi phục nội dung công việc; bash và khả năng chạy code là công cụ vạn năng để thử bất cứ điều gì; sandbox là không gian thực thi an toàn để nếu có làm hỏng cũng không ảnh hưởng đến hệ thống chính; file bộ nhớ cùng web search 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à các cơ chế 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 những công việc dài nhiều ngày đến khi hoàn tất.

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

• Các mẫu để kéo dài công việc dài hạn Một điểm yếu của các mô hình hiện nay là hay muốn kết thúc công việc quá sớm, không giỏi chia nhỏ vấn đề lớn, và dễ đứt mạch khi cửa sổ ngữ cảnh thay đổi. Harness phải bù vào những điểm yếu này. Ralph loop là một kỹ thuật đơn giản: mỗi khi mô hình định kết thúc việc, một hook sẽ chặn lại và bơm lại mục tiêu ban đầu vào cửa sổ ngữ cảnh mới để buộc nó 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ả của 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ộ phận sinh” và “bộ phận đánh giá” thành hai AI khác nhau, vì nếu để AI tự chấm sản phẩm của chính mình thì nó có xu hướng chấm quá tay. Ngoài ra, mẫu “sprint contract” — tức là thống nhất trước khi bắt đầu rằng “thế nào thì được xem là xong” — rất hiệu quả trong việc ngăn mục tiêu bị nới dần ra trong lúc làm.

• Vai trò của hook “Bảo AI làm như vậy” và “để hệ thống cưỡng chế nó làm như vậy” là hai chuyện khác nhau. Hook là cơ chế tự động lấp khoảng trống đó, bằng cách xen vào ở những 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 bắt đầu phiên làm việc. Ví dụ, mỗi lần sửa code thì tự động chạy kiểm tra cú pháp, lint, test; hoặc 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 sẽ không nghe gì cả; nếu thất bại, thông báo lỗi đó sẽ được bơm trở lại luồng làm việc để nó tự sửa. Đây là cấu trúc gần như không tốn chi phí thường ngày nhưng lại hỗ trợ rất chính xác đúng lúc xảy ra vấn đề.

• Tài liệu quy tắc và lựa chọn công cụ nên ngắn gọn, rõ ràng AGENTS.md đặt ở thư mục gốc dự án là file cấu hình có ảnh hưởng mạnh nhất, vì nó được đưa vào system prompt ở mọi lượt. HumanLayer khuyên nên giữ tài liệu này dưới 60 dòng. Càng dài thì trọng lượng của từng dòng càng nhạt đi, nên nó không nên là một cẩm nang ghi phong cách chung, mà phải chỉ giữ lại những 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ụ được nhét vào prompt ở mọi yêu cầu, nên 10 công cụ được gọt giũa kỹ sẽ tốt hơn 50 công cụ na ná nhau. HumanLayer cũng nhấn mạnh 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 đường tiêm lén những chỉ dẫn do người khác viết sẵn vào AI.

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. Nghĩa là thay vì chỉ mơ hồ chờ “mô hình tiếp theo”, ta có một vùng can thiệp cụ thể có thể bắt tay vào sửa ngay.
• Tạo cấu trúc để tích lũy know-how Nhờ cách ratchet biến lỗi thành quy tắc, một bài học chỉ cần học một lần nhưng sẽ ở lại như tài sản của cả nhóm. Dù con người thay đổi, tài liệu quy tắc và hook vẫn còn nguyên để bảo vệ người đến sau.
• Sự xuất hiện của harness dựng sẵn (HaaS) Hướng đi mà Viv gọi là “Harness-as-a-Service” đang nhanh chóng hình thành. Các sản phẩm như Claude Agent SDK, Codex SDK, OpenAI Agents SDK đang đóng 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 không phải xây tất cả từ đầu mà có thể tập trung hơn vào tri thức miền của riêng mình.

Nhưng cũng có những phần đáng ngại.

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

Những góc nhìn 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ì chờ một GPT thông minh hơn, bài viết đưa ra phương pháp kỹ thuật để kéo giới hạn của mô hình hiện có đi xa hơn. Chẩn đoán được đưa ra là khoảng cách giữa giới hạn AI ta thấy hôm nay và năng lực thực sự mà mô hình có phần lớn là khoảng cách do harness tạo ra.
• 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 nữa. Chẳng hạn Opus 4.6 gần như đã loại bỏ kiểu nóng vội phổ biến ở Claude Sonnet 4.5 như “ngữ cảnh sắp hết nên phải kết thúc nhanh”, và nhờ đó nhiều cơ chế phụ trợ để trấn an trước đây trở thành dead code. Tuy nhiên, ở những miền mới mà mô hình vươn tới lại xuất hiện những điểm yếu mới, và lại cần những harness mới để bù vào. 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 học giữa mô hình và harness Một dòng chảy khác mà Viv chỉ ra là vòng phản hồi giữa thiết kế harness và huấn luyện mô hình. Khi một mẫu hữu ích được tìm thấy trong harness, nó sẽ được chuẩn hóa; thế hệ mô hình tiếp theo học theo mẫu đó; rồi trên nền mô hình mới lại nảy sinh các mẫu harness mới. Vì vậy, kết luận là “một 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 để khớ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 harness của chúng ngày càng giống nhau. Việc mô hình thì khác mà harness lại ngày càng 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 đưa ra góc nhìn rằng 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 mô hình nhiều hơn là bởi việc chọn mô hình nào, và harness không phải một file cấu hình đặt xong là hết, mà là một hệ thống sống liên tục được cập nhật theo lịch sử thất bại. Việc mô hình tốt lên không làm harness biến mất; thay vào đó, tầng vấn đề được đẩy lên cao hơn một nấc và một harness mới sẽ lấp vào chỗ đó. Mượn cách nói 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 không có lặp lại”, nghĩa là rốt cuộc đây là cuộc đua xem ai bắt đầu sớm hơn và tinh chỉnh thường xuyên hơn. Cuối cùng, 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 dần trần năng lực mà mô hình có thể chạm tới.

[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.

[dongho42]

Nhưng khi trong prompt nói hãy làm A, đừng làm B, nếu AI thực sự hiểu rất tốt thì cách tiếp cận này có vẻ sẽ hiệu quả, nhưng trong trường hợp AI chỉ thực hiện prompt theo xác suất tùy vào trạng thái của server AI thì cách tiếp cận này có còn hiệu quả không?

[dongho42]

Ngày xưa, dù đã viết rất rõ trong prompt là hãy làm A, nhưng nó vẫn cứ có xác suất nhất định là không tuân theo, nên tôi đã thử đủ trò như nhấn mạnh bằng bold trong mrkdwn, viết lặp lại hai lần, viết bằng tiếng Anh, viết theo kiểu đối xứng đầu-cuối, viết bằng XML, mà rồi nó vẫn cứ có xác suất nhất định là phớt lờ prompt...

[kurthong]

Tôi cũng nhét đủ thứ tương tự như câu chuyện của Osmani
khi đang làm app thì chủ đề này được nhắc tới nên có hơi vội,
nhưng tôi nghĩ nếu Osmani đừng chỉ nói suông
mà tự đưa những điều mình nói vào Google Anti-Gravity thì có phải tốt hơn không.
Kapasi cũng vậy, giờ cứ không nghĩ đến chuyện tự tay làm mà chỉ ném ra vài bài viết rồi thôi thì tôi thấy cũng hơi...!

https://github.com/hang-in/tunaFlow

[tangokorea]

Thay vì lùi một bước khỏi góc nhìn xem giữa mô hình và harness cái nào tốt hơn, liệu có thể nhìn theo hướng với mô hình nào thì dùng harness nào sẽ phù hợp hơn không?

[jimmy2056]

Mô hình càng tốt thì gánh nặng thiết kế harness cũng càng giảm.

[akapwhd]

Có vẻ là ngay cả khi áp dụng mấy thứ này thì lúc code thực tế cũng không giúp được nhiều lắm... Chắc là vì độ khó phát triển chỉ ở mức đặt plan cho Codex rồi chạy agent thôi nhỉ haha

[blackfabric]

Tóm tắt 3 dòng

• Hệ thống (harness) quan trọng hơn mô hình trong việc quyết định thành bại: hiệu năng của AI không được quyết định bởi bản thân mô hình như GPT hay Claude, mà bị chi phối bởi thiết kế môi trường làm việc bao quanh nó, được gọi là "harness", gồm prompt, công cụ, sandbox, vòng lặp phản hồi, v.v.
• Nguyên tắc 'Ratchet' biến sai lầm thành quy tắc: không nên xem lỗi của AI chỉ là sự cố đơn lẻ, mà cần phản ánh ngay vào tài liệu quy tắc (như AGENTS.md) hoặc hook, để hệ thống ngày càng vững chắc hơn theo thời gian
• Vấn đề không nằm ở mô hình mà ở cấu hình (Skill): việc AI làm chưa tốt trong nhiều trường hợp xuất phát từ thiết kế harness kém hơn là do thiếu năng lực của mô hình, và cần một cách tiếp cận mang tính kỹ thuật, thiết kế ngược từ kết quả mong muốn để xác định các thành phần và ràng buộc cần thiết

[yungoun]

Nhưng đến tận tuần trước Harness còn được tung hô và bán rầm rộ, vậy mà từ tuần này lại im ắng hẳn.. Có phải vì Anthropic làm quá nhiều pha xử lý vụng về và Codex 5.5 quá xuất sắc không nhỉ........

[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 đã.

[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.