Harness Engineering là gì? Lớp kỹ thuật biến một LLM thành AI Agent thực sự
- #harness-engineering
- #ai-agent
- #llm
- #prompt-engineering
- #agent-platform
Trả lời nhanh: Harness Engineering là kỷ luật thiết kế lớp bọc quanh một LLM (Large Language Model): chọn tool, nạp context, chạy vòng lặp, kiểm tra kết quả và quyết định khi nào dừng. Model chỉ sinh chữ. Harness (lớp điều khiển hành vi agent) mới cho phép hệ thống hành động, nhớ tiến độ, tự kiểm và dừng khi đạt mục tiêu hoặc chạm giới hạn. LangChain viết tắt: agent bằng model cộng harness. Thiếu lớp đó, bạn đang có một chatbot hoặc một lần gọi model, dù nhãn sản phẩm viết AI Agent.
Nếu bạn đang xem sản phẩm gắn nhãn AI Agent, phần lớn bài chỉ khoe model. Model này mới ra, model kia điểm cao hơn. Mở ra thì nó trả lời lịch sự rồi đứng: không tra được đơn hàng, không nhớ đã kiểm tới đâu, không biết lúc nào phải gọi người thật.
Chỗ đó dễ tưởng do model chưa đủ. Thường là hệ thống chưa được bọc để hành động, nhớ tiến độ, và biết lúc dừng. Mình viết cho người không làm kỹ thuật, nên không có đoạn cấu hình coding agent. Cùng mình tìm hiểu tiếp nhé.
Bài này là cách mình đọc tài liệu công khai tới ngày 17/8/2026, không phải kết quả đo từ hệ thống mình tự vận hành.

Harness Engineering là gì, và harness khác model ở chỗ nào?
Harness Engineering (kỷ luật thiết kế lớp điều khiển hành vi quanh model) là phần bao quanh model, không phải bản thân model. LangChain định nghĩa harness là toàn bộ code, cấu hình và logic thực thi không thuộc về model. Cũng theo bài đó, một model trần chưa phải agent; nó thành agent khi harness cấp cho nó state, khả năng thực thi tool, vòng phản hồi để thấy kết quả thật, và những giới hạn có thể cưỡng chế được. Cách viết tắt bài đó dùng, được nhắc lại nhiều trong năm 2026: agent bằng model cộng harness.
Một chỗ dễ nhầm tên: harness ở đây chỉ bộ khung điều khiển, không liên quan tới Harness.io, sản phẩm cùng tên trong lĩnh vực triển khai code.
Cái tên còn mới. Ngày 5/2/2026, Mitchell Hashimoto viết rằng anh gọi thói quen của mình là harness engineering: mỗi lần agent làm sai, anh sửa luôn môi trường quanh nó để lỗi khó lặp lại. Hai dạng anh kể là viết lại file hướng dẫn cho agent, ví dụ AGENTS.md, và làm sẵn tool để agent tự biết mình sai. Anh nói thẳng là chưa rõ ngành đã có thuật ngữ thống nhất chưa. Trang Wikipedia về agent harness ghi nhận việc ai đặt ra cụm từ này vẫn còn tranh luận, và các kỹ thuật tương tự đã có trước cái tên.
Bỏ hết từ kỹ thuật thì thế này. Model là một bạn thực tập rất nhanh, viết gì cũng trôi chảy. Harness là bản mô tả việc, bộ chìa khóa bạn ấy được phép dùng, checklist phải chạy trước khi báo xong, và quy định rằng bạn ấy không được tự chuyển tiền hoàn cho khách nếu chưa có người duyệt. Thực tập giỏi hơn thì tốt, nhưng thiếu mấy thứ đó thì không ai dám giao việc thật.

Vì sao một LLM chưa phải là AI Agent?
Vì model không với tới thế giới bên ngoài: nó nhận chữ và ảnh, rồi trả về chữ. Vẫn theo bài của LangChain, một model tự nó không giữ được state bền (tiến độ đã lưu), không thực thi code và không truy cập được thông tin đang thay đổi ngoài kia. Ba việc đó nằm ở lớp bọc.

Còn agent, tức chương trình tự gọi tool và lặp bước để hoàn thành một việc, thì phải làm được. IBM định nghĩa AI agent là hệ thống tự động thực hiện tác vụ bằng cách tự thiết kế workflow với các tool sẵn có. Hướng dẫn thực hành của OpenAI tách một agent thành ba thành phần: model, tools và instructions. Model nằm trong trọng số; tools và phần lớn vòng chạy quanh instructions nằm trong harness.
Mình đã viết riêng một bài về ranh giới này: chatbot dừng ở câu trả lời, còn agent tiếp tục tới khi đạt mục tiêu hoặc chạm giới hạn. Phần tiếp tục đó do harness tạo ra, không phải do model thông minh thêm.
Nhịp phổ biến nhất của phần tiếp tục là ReAct (Reasoning and Acting), công bố năm 2022: nghĩ, hành động, quan sát, rồi nghĩ tiếp. Model đề xuất hành động; harness thực thi rồi đưa kết quả quan sát ngược lại. ReAct là một pattern phổ biến, không phải kiến trúc duy nhất.
Giả sử bạn hỏi: đơn này có được hoàn tiền không? Một model sẽ viết đoạn văn lịch sự, nghe hợp lý, dựa trên chính sách nó đoán là của bạn. Một agent thì phải mở đơn hàng đó ra, đối chiếu chính sách thật, rồi mới trả lời hoặc hành động. Phần mở đơn và phần hành động là việc của harness.
Harness làm những việc gì quanh model?
Năm mục dưới đây là các việc của lớp bọc, không phải năm sản phẩm bạn phải mua. Mình liệt kê để bạn nhận ra hệ thống hụt ở đâu khi chạy nửa vời rồi đứng.

Cho phép hành động, không chỉ trả lời
Model không tự gọi API (Application Programming Interface). Nó chỉ nói ra muốn dùng tool nào với tham số nào, còn ứng dụng của bạn mới là bên thực thi: đó là function calling, tức cơ chế model yêu cầu ứng dụng gọi một hàm hoặc API. Nhưng có tool chưa đủ: IBM nói rõ riêng khả năng gọi tool không biến một LLM thành agent, vì hệ thống còn phải tự quyết định dùng tool nào, khi nào và kết hợp ra sao để đạt mục tiêu. Chỗ quyết định đó nằm trong harness.
Nhớ đúng thứ, đúng lúc
Context window (cửa sổ ngữ cảnh) không phải memory: nó là lượng thông tin nhét được vào một lần gọi model. Memory (bộ nhớ) là các quyết định: lưu gì, lấy lại lúc nào, cho ai, giữ bao lâu. Databricks mô tả đây là việc của lớp bọc: harness có thể ghi tiến độ ra file hoặc một kho riêng để model không phải đọc lại toàn bộ đoạn hội thoại ở mỗi lượt, một đoạn chỉ dài thêm và càng dài càng dễ trôi mất chi tiết.

Lặp bước và biết lúc dừng
Vòng lặp cần đi kèm điểm dừng: số bước tối đa, thời gian tối đa, điều kiện được coi là xong. Cloudflare mô tả chính harness là nơi quyết định agent nên chạy tiếp hay dừng. Ngày 26/11/2025, Anthropic viết về harness cho tác vụ chạy dài: những việc kéo dài qua nhiều context window, và thiếu lớp bọc tử tế thì agent hay mắc hai lỗi, làm quá nhiều thứ cùng lúc và tuyên bố xong quá sớm. Cách họ xử lý gợi hình ảnh ca trước để lại giấy nhắn tiến độ cho ca sau.
Kiểm tra trước khi tuyên bố xong
Ngày 2/4/2026, Birgitta Böckeler viết trên trang của Martin Fowler về hai loại cơ chế: loại định hướng trước khi agent hành động, và loại quan sát sau đó để nó tự sửa. Kiểm tra có thể do máy làm (chạy test, chạy công cụ soát lỗi) hoặc do một model khác đánh giá. Điểm cần nhớ: một dòng dặn trong prompt rằng hãy cẩn thận không phải bước kiểm tra; bước kiểm tra là thứ hệ thống thật sự chạy, và có thể kết luận là chưa đạt. Hashimoto nói cùng ý: hãy cho agent những tool nhanh để nó tự biết mình sai.
LangChain kể một thí nghiệm khá thẳng thắn: với coding agent của họ, điểm trên bộ bài kiểm tra Terminal Bench 2.0 gồm 89 tác vụ đi từ 52,8 lên 66,5 trong khi model giữ nguyên là gpt-5.2-codex, và họ nói phần duy nhất thay đổi là harness. Phạm vi con số rất hẹp: một nhà cung cấp, một agent viết code, một bộ bài kiểm tra. Thứ đáng mang đi là kiểu lỗi họ gặp: agent đọc lại việc của chính nó, thấy ổn, rồi dừng. Chỉ một bước kiểm tra độc lập trong harness mới cắt được vòng tự khen đó.
Chặn việc không được phép
Guardrail (hàng rào an toàn) khác hẳn một lời dặn. Prompt có thể xin model đừng làm gì đó; harness phải có khả năng từ chối. Những hành động khó hoàn tác, ví dụ gửi tin cho khách, hoàn tiền, xóa dữ liệu, thường cần cổng phê duyệt của người thật, hoặc bị giới hạn cứng ở lớp tool và phân quyền. Mình viết kỹ hơn trong bài về platform cho AI Agent.
Prompt engineering, context engineering và Harness Engineering khác nhau chỗ nào?
Chúng lồng vào nhau, không thay thế nhau. Databricks xếp ba lớp theo phạm vi mở rộng dần: prompt engineering (kỹ thuật tối ưu câu lệnh gửi vào model) lo câu chữ một lượt; context engineering (kỹ thuật chọn thông tin model được nhìn thấy) lo model nhìn thấy gì; Harness Engineering lo cả môi trường quanh model.

| Kỷ luật | Tối ưu cái gì | Artifact chính |
|---|---|---|
| prompt engineering | Cách viết một lượt gửi vào model | Một prompt tốt |
| context engineering | Model được nhìn thấy thông tin nào, khi nào | Retrieval, memory, cách chọn ngữ cảnh |
| Harness Engineering | Cả môi trường quanh model: tool, vòng lặp, kiểm tra, điểm dừng | Bản thân harness |
Hai lớp trong không mất giá trị vì có harness; cả hai nằm bên trong harness. Thứ dịch chuyển là chỗ đặt chú ý: từ cách viết một câu, sang thứ model được nhìn thấy, rồi sang cả hệ thống quanh nó. Đó là cách nhiều người làm nghề mô tả, không phải mốc chuẩn do tổ chức nào công bố.
Harness khác runtime và platform thế nào?
Mình lấy cách tách của tài liệu Cloudflare Agents: hai lớp, harness và runtime. Đây là phân lớp của một nhà cung cấp, không phải chuẩn phổ quát.
Harness là vòng lặp hành vi quanh model: dựng prompt, nạp memory, chọn tool, xử lý kết quả, và quyết định chạy tiếp hay dừng. Runtime (môi trường chạy bền) là hạ tầng: agent chạy ở đâu, state sống sót qua sự cố thế nào, lịch chạy, và observability (khả năng quan sát hệ thống). Cloudflare nói gọn: runtime trả lời agent sống ở đâu; harness trả lời agent làm gì ở mỗi lượt.
Prompt không đứng ngang hàng harness trên tài liệu đó. Dựng prompt là việc của harness.

- Harness: Dựng prompt, nạp context, cho phép tool nào, vòng lặp chạy ra sao, khi nào dừng.
- Runtime: Agent chạy ở đâu, state sống sót qua sự cố thế nào, quan sát bằng gì.
Còn platform, theo nghĩa mình dùng trên site này, là tập hợp năng lực dùng chung để agent tồn tại được bên ngoài một lần gọi model; harness là lớp hành vi ngồi trên đó. Muốn xem một runtime cụ thể, GoClaw là ví dụ để đọc.
Làm sao nhận ra sản phẩm gắn nhãn AI Agent có harness thật?
Bạn không cần đọc code mới đoán được. Năm câu hỏi dưới đây đủ cho phần lớn trường hợp, kể cả agent bạn tự dựng.
- Nó gọi được hệ thống thật nào, hay chỉ trả về văn bản?
- Nó nhớ tiến độ qua nhiều bước, hay mỗi lượt bắt đầu như chưa từng làm gì?
- Việc nguy hiểm có cổng duyệt hoặc chặn cứng, hay chỉ có câu dặn trong prompt?
- Khi nó báo xong, có bước kiểm tra độc lập không?
- Bạn xem lại được nó đã làm gì không, hay chỉ thấy câu trả lời cuối?
Nếu phần lớn câu trả lời là không, thứ bạn đang có là một chatbot. Nói vậy không phải để dìm: chatbot tốt vẫn tiết kiệm nhiều thời gian, và ranh giới giữa hai loại nằm ở việc hệ thống được phép làm gì, không nằm ở nhãn dán. Chỉ nên tránh giao cho nó phần việc bạn đang tưởng nó tự làm xong.
Khi nào chưa cần Harness Engineering?
Khi việc chỉ gọn trong một lượt, chỉ đọc chứ không ghi, và luôn có người xem trước khi bất cứ điều gì xảy ra. Lúc đó thêm vòng lặp và bước kiểm tra chỉ làm chậm hơn. Anthropic khuyên bắt đầu từ giải pháp đơn giản nhất và chỉ tăng độ phức tạp khi thật cần. Microsoft xếp cùng ý tưởng thành một thang và nêu nguyên tắc chọn mức thấp nhất còn chạy được: nếu prompt engineering đã giải quyết xong bài toán thì bạn chưa cần agent. Nhiều nhu cầu nghe như cần agent thực ra chỉ cần một workflow có đường đi biết trước.
Câu hỏi thường gặp
Năm câu dưới đây hay xuất hiện khi bạn đã nghe AI Agent nhưng chưa chắc đang thiếu lớp nào. Mỗi câu trả lời theo cơ chế, không theo nhãn sản phẩm.
Harness trong bài này có phải phần mềm Harness.io không?
Không. Harness ở đây là lớp bọc quanh model: tool, nhớ, vòng lặp, kiểm tra và điểm dừng. Harness.io là sản phẩm khác, dùng trong triển khai code. Trùng tên, không cùng việc.
Chỉ cần model mạnh hơn thì đã có AI Agent chưa?
Chưa. Model giỏi hơn thì chữ hay hơn, đoán khéo hơn. Nó vẫn không tự mở đơn hàng, không giữ tiến độ qua nhiều bước, và không tự dừng đúng lúc trừ khi lớp bọc quanh nó làm những việc đó. LangChain viết một model trần chưa phải agent.
Gắn thêm tool vào chatbot đã thành agent chưa?
Chưa chắc. IBM nói rõ khả năng gọi tool tự nó không biến một LLM thành agent. Còn thiếu chỗ hệ thống tự chọn tool nào, gọi khi nào, kết hợp ra sao, và theo đuổi mục tiêu qua nhiều bước thay vì chờ bạn ra lệnh từng lượt.
Harness Engineering có thay prompt engineering không?
Không. Chúng lồng nhau. Prompt engineering lo câu chữ một lượt gửi vào model. Context engineering lo model được nhìn thấy thông tin nào. Harness Engineering lo cả môi trường quanh model. Databricks xếp ba lớp theo phạm vi mở rộng dần, không phải ba thứ thay thế nhau.
Harness khác runtime chỗ nào?
Theo tài liệu Cloudflare Agents, harness lo hành vi từng lượt, kể cả dựng prompt; runtime lo chỗ agent chạy và state sống sót thế nào. Đây là cách tách của một nhà cung cấp, không phải chuẩn phổ quát. Prompt không đứng thành lớp ngang hàng harness trên tài liệu đó.
Kết luận: nhìn lớp bọc, không chỉ nhìn model
Cách đọc gọn nhất: bỏ qua tên model trên banner, hỏi hệ thống có chạm được dữ liệu thật không, có nhớ đã làm tới đâu không, khi báo xong có bước kiểm không, và ai được quyền dừng. Thiếu mấy thứ đó thì bạn đang có chatbot. Chatbot tốt vẫn đáng dùng; chỉ đừng giao cho nó phần việc bạn tưởng nó tự làm xong.
Nếu bạn định thử một agent cho việc của mình, câu hỏi đầu tiên theo mình không phải chọn model nào, mà là ai có quyền dừng nó lại. Muốn đi tiếp thì đọc ranh giới chatbot và AI Agent, chỗ nhãn sản phẩm sai nhiều nhất, rồi phần platform, nơi harness và runtime nằm cạnh nhau.