Vào tháng 2 năm 2026, một nhóm nhỏ tại OpenAI đã đưa vào vận hành 1 triệu dòng code sản xuất.
Họ không viết một dòng nào bằng tay.
Các AI agent đã viết nó.
Con người đã thiết kế hệ thống giúp các agent hoạt động đáng tin cậy.
Hệ thống đó đã có một cái tên.
Kỹ thuật Harness (Harness Engineering).
Trong vòng vài tuần, Anthropic đã xuất bản 3 bài báo về nó.
ThoughtWorks đã chính thức hóa một khuôn khổ.
Philipp Schmid tại Hugging Face gọi nó là "ngành học quan trọng nhất của năm 2026".
Một ngành kỹ thuật mới đã hình thành trong 90 ngày.
Và hầu như không ai bên ngoài các nhóm hạ tầng AI thực sự hiểu nó.
Bài viết này giải thích tất cả.
Không lan man. Không thuật ngữ hàn lâm. Chỉ là những mô hình tư duy bạn cần để thực sự sử dụng nó.
Hãy lưu lại. Bạn sẽ đọc nó hai lần.
PHẦN 1: HARNET THỰC SỰ LÀ GÌ (Khái niệm thay đổi cách bạn nghĩ về AI)
1. Định nghĩa về Harness
Định nghĩa đơn giản nhất đến từ ThoughtWorks:
→ Agent = Mô hình + Harness
Harness là tất cả mọi thứ không phải là mô hình.
Các ràng buộc giúp agent đi đúng hướng. Các vòng phản hồi bắt lỗi. Các tài liệu cho agent biết nó đang ở đâu. Các công cụ nó được phép sử dụng.
Loại bỏ harness → mô hình ngôn ngữ thô đang phỏng đoán đường đi qua codebase của bạn.
Thêm harness phù hợp → hệ thống có thể đưa vào sản xuất code.
Tên gọi bắt nguồn từ bộ yên cương ngựa.
Một cái harness là dây cương, yên ngựa và hàm thiếc, dẫn hướng một con vật mạnh mẽ nhưng khó đoán theo một hướng hữu ích.
Bạn không làm cho con ngựa thông minh hơn. Bạn thiết kế trang bị làm cho sức mạnh của nó trở nên hữu ích.
2. Phép tương tự với Hệ điều hành
Philipp Schmid đã đưa ra cách diễn giải kỹ thuật hay nhất:
Hãy nghĩ về nó như một chiếc máy tính.
→ Mô hình = CPU (sức mạnh xử lý thô)
→ Cửa sổ ngữ cảnh = RAM (bộ nhớ làm việc hạn chế, dễ bay hơi)
→ Harness = Hệ điều hành (quản lý những gì CPU thấy và khi nào)
→ Agent = Ứng dụng chạy bên trên
Mô hình của bạn rất mạnh mẽ.
Nhưng nếu không có HĐH quản lý bộ nhớ, lên lịch tác vụ và thực thi các quy tắc — nó chỉ là một khối silicon.
Hầu hết mọi người đang chạy ứng dụng mà không có hệ điều hành.
Đó là lý do tại sao agent của họ thất bại trong sản xuất.
3. Điều gì đã thay đổi vào năm 2026
LangChain đã chạy cùng một mô hình trên Terminal Bench 2.0 hai lần.
Cùng một mô hình. Harness khác nhau.
→ Harness cũ: 52.8% điểm
→ Harness mới: 66.5% điểm
Vercel đi theo hướng ngược lại.
Họ đã loại bỏ 80% công cụ của agent.
Kết quả? Hiệu suất tốt hơn.
Không phải tệ hơn.
Sự thật khó chịu của năm 2026:
→ Agent chưa bao giờ là phần khó.
→ Harness mới là phần khó.
Nếu năm 2025 là năm AI agent chứng minh chúng có thể viết code…
Thì năm 2026 là năm chúng ta khám phá ra rằng môi trường quan trọng hơn mô hình.
PHẦN 2: 5 TÁC PHẨM HARNET (Harness thực sự trông như thế nào trong thực tế)
4. Tệp AGENT.md / CLAUDE.md
Tác phẩm harness phổ biến nhất.
Các tệp Markdown được phân phối khắp codebase của bạn.
Agent đọc chúng khi bắt đầu mỗi phiên — giống như tài liệu hướng dẫn cho một kỹ sư mới gia nhập nhóm.
Nội dung bên trong:
→ Bối cảnh dự án
→ Quy ước code
→ Các quyết định kiến trúc
→ Hướng dẫn "Cách chúng tôi làm việc ở đây"
→ Những gì đang được tiến hành
OpenAI gọi chúng là AGENT.md.
Anthropic gọi chúng là CLAUDE.md.
Cursor sử dụng .cursorrules.
Tên gọi khác nhau. Cùng một nguyên tắc.
Một tệp cho mỗi mô-đun chính. Được cập nhật khi dự án phát triển.
Không có chúng: agent bắt đầu mỗi phiên trong trạng thái mù mờ. Có chúng: agent bắt đầu mỗi phiên với đầy đủ thông tin.
5. Danh sách Tính năng dạng JSON (Trình theo dõi tiến độ)
Khi một agent xây dựng toàn bộ ứng dụng qua nhiều phiên, nó bắt đầu mỗi phiên với một cửa sổ ngữ cảnh trống rỗng.
Làm sao nó biết những gì đã hoàn thành?
Một tệp JSON.
Mỗi mục nhập xác định:
→ Một tính năng
→ Cách xác minh nó hoạt động
→ Trạng thái Đạt / Không đạt
Agent đọc tệp này khi bắt đầu phiên. Chọn tính năng không đạt có mức độ ưu tiên cao nhất. Triển khai nó. Đánh dấu nó là đạt. Commit. Lặp lại.
Tại sao là JSON mà không phải Markdown?
Anthropic phát hiện ra rằng agent ít có khả năng vô tình ghi đè lên JSON hơn là Markdown.
Chi tiết nhỏ. Rất quan trọng trong các lần chạy tự động kéo dài 6 giờ.
6. Quy trình Khởi tạo Phiên
Mỗi phiên đều bắt đầu theo cùng một cách.
Từng. Lần. Một.
Trình tự khởi động 7 bước của Anthropic:
- Xác nhận thư mục làm việc
- Đọc nhật ký git và các tệp tiến độ
- Kiểm tra danh sách tính năng để tìm mục chưa hoàn thành có mức ưu tiên cao nhất
- Khởi động máy chủ dev
- Chạy xác minh cơ bản từ đầu đến cuối
- Triển khai một tính năng
- Commit với thông điệp mô tả + cập nhật tiến độ
Không có điều này:
Agent lãng phí 20 phút đầu tiên để tìm hiểu những gì đã tồn tại.
Mỗi phiên đều là phát minh lại bánh xe.
Có nó:
Agent bắt đầu ngay lập tức với đầy đủ thông tin và chuyển thẳng sang công việc.
7. Hợp đồng Sprint
Trước khi agent viết một dòng code nào:
Hai agent đàm phán.
Agent tạo sinh (Generator) đề xuất:
→ Nó sẽ xây dựng cái gì
→ Thành công sẽ được xác minh như thế nào
Agent đánh giá (Evaluator) xem xét:
→ Đề xuất có hoàn chỉnh không?
→ Các tiêu chí thành công có rõ ràng không?
Chỉ sau khi cả hai đồng ý, việc triển khai mới bắt đầu.
Đó là một cuộc đánh giá thiết kế.
Ngoại trừ cả hai người tham gia đều là AI.
Tại sao điều này lại quan trọng?
Các agent lên kế hoạch và thực thi trong cùng một lượt tạo ra đầu ra không đáng tin cậy.
Bước lập kế hoạch — ngay cả khi do AI thực hiện — cải thiện đáng kể chất lượng đầu ra.
8. Mẫu Nhiệm vụ có Cấu trúc
Trước bất kỳ việc code nào:
Harness phân tích codebase thực tế.
Nó tạo ra một bản đồ tác động có căn cứ:
→ Đường dẫn tệp thực tế (không phải đường dẫn ảo giác)
→ Tên ký hiệu thực tế thực sự tồn tại
→ Các mẫu hiện có cần tuân theo
→ Tiêu chí chấp nhận cụ thể
Sau đó việc triển khai bắt đầu.
Điều này nghe có vẻ hiển nhiên.
Nhưng hầu hết các đội đều bỏ qua nó.
Agent đoán cấu trúc tệp. Phát minh ra các điểm cuối API không tồn tại. Xây dựng thứ không phù hợp với codebase.
Ngữ cảnh có căn cứ trước khi thực thi → đầu ra tốt hơn đáng kể.
PHẦN 3: BA TRƯỜNG PHÁI (Ba đội chạm cùng một bức tường — và xây ba cái thang khác nhau)
9. OpenAI: Môi trường là trên hết
Nhóm Codex của OpenAI có một vấn đề phi lý.
1 triệu dòng code sản xuất. Không một dòng nào viết bằng tay.
Ở quy mô đó, bạn không thể review code từng dòng.
Vì vậy, họ đã không làm thế.
Thay vào đó:
Họ thiết kế môi trường một cách kỹ lưỡng đến nỗi các agent tự tạo ra đầu ra có thể review được.
Cách tiếp cận của họ:
→ Luồng phụ thuộc chặt chẽ (Types → Config → Repo → Service → Runtime → UI)
→ Các tệp AGENT.md khắp codebase
→ Các agent được kết nối trực tiếp vào các pipeline CI/CD
Triết lý: Thiết kế môi trường. Sau đó thả agent ra.
Bằng chứng: Ứng dụng Android Sora. 4 kỹ sư. 28 ngày. #1 trên Play Store. 99.9% không crash.
Codex xử lý 70% các pull request nội bộ hàng tuần.
10. Anthropic: Tách Người thực hiện khỏi Người đánh giá
Anthropic có một vấn đề khác.
Khi họ yêu cầu agent tự đánh giá đầu ra của chính nó:
Nó tự tin khen ngợi tác phẩm.
Ngay cả khi, đối với một người quan sát, chất lượng rõ ràng là tầm thường.
Tự đánh giá không hiệu quả.
Agent vừa là học sinh vừa là giáo viên.
Và nó đang tự cho mình điểm A tuyệt đối.
Giải pháp của họ: Ba agent chuyên biệt.
→ Người lập kế hoạch (Planner) — biến một lời nhắc 2 câu thành bản spec sản phẩm hoàn chỉnh
→ Người tạo sinh (Generator) — triển khai các tính năng từng sprint một
→ Người đánh giá (Evaluator) — sử dụng tự động hóa trình duyệt để kiểm tra ứng dụng đang chạy như một người dùng thực
Hiểu biết sâu sắc: việc tạo ra một người đánh giá độc lập có tính hoài nghi dễ dàng hơn nhiều so với việc bắt người tạo sinh phải tự phê bình công việc của chính nó.
Kết quả: Agent đơn độc (không harness): $9, 20 phút
→ ứng dụng bị lỗi Harness đầy đủ: $200, 6 giờ
→ phần mềm hoạt động với giao diện người dùng trau chuốt
11. ThoughtWorks: Khuôn khổ 2×2
ThoughtWorks đến từ một góc nhìn khác.
Họ không xây dựng một sản phẩm.
Họ đang theo dõi hơn 50 đội kỹ thuật thất bại ở những điều giống nhau.
Hiểu biết sâu sắc của họ: phân loại mọi biện pháp kiểm soát harness theo hai trục.
Trục 1: Nó chạy khi nào?
→ Feedforward = trước khi agent hành động (hướng dẫn)
→ Feedback = sau khi agent hành động (cảm biến)
Trục 2: Nó hoạt động như thế nào?
→ Tính toán (Computational) = xác định, mili giây (linters, trình kiểm tra kiểu, bộ kiểm thử)
→ Suy luận (Inferential) = sử dụng LLM, vài giây (agent review code, phân tích ngữ nghĩa)
Ma trận 2×2:
→ Feedforward Tính toán: hệ thống kiểu, linters, quy tắc kiến trúc
→ Feedback Tính toán: bộ kiểm thử, phân tích độ phủ, kiểm thử đột biến
→ Feedforward Suy luận: tài liệu spec, mô tả ràng buộc
→ Feedback Suy luận: người review code LLM, trình xác thực hành vi
Chỉ riêng feedforward hay feedback đều không hiệu quả.
Bạn cần cả hai.
PHẦN 4: 5 NGUYÊN TẮC MÀ MỌI TRƯỜNG PHÁI ĐỀU ĐỒNG Ý (Ba đội chưa bao giờ phối hợp. Họ đã đi đến đây một cách độc lập.)
12. Nguyên tắc 1: Ngữ cảnh quan trọng hơn Chỉ dẫn
OpenAI: "Hãy đưa ra một bản đồ, không phải một cuốn sách hướng dẫn 1.000 trang."
Anthropic: Danh sách tính năng JSON và tệp tiến độ để agent luôn biết mình đang ở đâu.
Red Hat: Phân tích codebase thực tế trước khi tạo bất kỳ nhiệm vụ nào.
ThoughtWorks: "Feedforward."
Từ ngữ khác nhau. Cùng một khám phá.
Việc cho agent thấy trạng thái hiện tại của thế giới luôn mang lại hiệu quả tốt hơn so với việc bảo nó làm gì một cách trừu tượng.
→ Có căn cứ trong các đường dẫn tệp thực tế
→ code phù hợp với codebase
→ Làm việc từ một mô tả mơ hồ
→ các đường dẫn tệp bị ảo giác và các API được phát minh
Bài học: Trước khi agent gõ bất cứ thứ gì, hãy đảm bảo nó biết chính xác nó đang ở đâu.
13. Nguyên tắc 2: Lập kế hoạch và Thực thi phải được Tách biệt
OpenAI: con người thiết kế môi trường, agent thực thi.
Anthropic: agent Lập kế hoạch chuyên dụng chạy trước khi Người tạo sinh chạm vào bất kỳ code nào.
ThoughtWorks: điểm kiểm tra đánh giá bắt buộc của con người giữa lập kế hoạch và triển khai.
Red Hat: Giai đoạn 1 (bản đồ tác động) và Giai đoạn 2 (triển khai) với một cổng cứng ở giữa.
Mọi trường phái đều phát hiện ra điều này một cách độc lập:
Để agent lập kế hoạch và thực thi trong cùng một lượt tạo ra đầu ra không đáng tin cậy.
Bước lập kế hoạch không nhất thiết phải do con người thực hiện.
Nhưng nó phải là một bước riêng biệt, với đầu ra của nó được đánh giá trước khi bắt đầu triển khai.
14. Nguyên tắc 3: Vòng phản hồi là bắt buộc
OpenAI: các agent được kết nối vào hệ thống CI/CD và quan sát.
Anthropic: agent Đánh giá chuyên dụng sử dụng tự động hóa trình duyệt.
ThoughtWorks: chính thức hóa thành "cảm biến." Cảnh báo rằng các phương pháp chỉ dùng feedforward không bao giờ xác nhận liệu các hướng dẫn có thực sự hiệu quả hay không.
Ba cách tiếp cận cho cùng một nguyên tắc:
→ OpenAI sử dụng các bài kiểm tra tự động và CI
→ Anthropic sử dụng một LLM khác
→ ThoughtWorks nói hãy sử dụng cả hai, theo lớp
Họ không đồng ý về việc ai cung cấp phản hồi.
Họ không bất đồng về việc bạn có cần nó hay không.
Một harness không có phản hồi chỉ là một prompt với các bước thừa.
15. Nguyên tắc 4: Mỗi lần một việc
OpenAI: chia mục tiêu thành các khối xây dựng nhỏ hơn, làm việc theo chiều sâu trước.
Anthropic: thực thi một-tính-năng-mỗi-sprint với một commit sau mỗi tính năng.
ThoughtWorks: vòng đời theo giai đoạn (tiền tích hợp → hậu tích hợp → giám sát liên tục).
Các agent cố gắng làm quá nhiều cùng một lúc:
→ Hết ngữ cảnh
→ Mất mạch lạc
→ Âm thầm bỏ qua các yêu cầu
Quy trình của Anthropic:
Đọc tiến độ → Chọn MỘT tính năng → Triển khai → Commit → Lặp lại
Tính gia tăng bắt buộc là phổ biến trong mọi harness thành công.
16. Nguyên tắc 5: Codebase CHÍNH LÀ Tài liệu
OpenAI: nhúng các tệp AGENT.md vào repo.
Anthropic: lưu trữ danh sách tính năng, tệp tiến độ và lịch sử git như cơ chế liên tục của agent.
ThoughtWorks: đo lường "khả năng harness" — codebase dễ đọc đối với agent như thế nào.
Không ai duy trì một cơ sở kiến thức riêng biệt cho agent.
Repo là nguồn sự thật duy nhất.
Nếu một quy ước, ràng buộc hoặc quyết định kiến trúc không có trong codebase — agent sẽ không biết về nó.
Hàm ý thực tế:
→ Các đội đầu tư vào tổ chức code sẽ nhận được hiệu suất agent tốt hơn miễn phí.
→ Repo lộn xộn + AI agent = hỗn loạn, nhưng ở quy mô lớn.
PHẦN 5: NGHỊCH LÝ — XÂY DỰNG ĐỂ XÓA BỎ (Sự thật phản trực giác nhất trong kỹ thuật harness)
17. Sự suy giảm của Harness là Có thật
Khi Anthropic nâng cấp từ Opus 4.5 lên Opus 4.6:
Phân rã sprint — vốn rất cần thiết — đã trở thành gánh nặng chết.
Khả năng lập kế hoạch được cải thiện của mô hình đã làm cho nó trở nên dư thừa.
Một thành phần harness chịu tải trọng vào tháng 3 đã trở thành chi phí phụ vào tháng 4.
Sau đó Opus 4.7 ra mắt.
Mô hình bắt đầu tự xác minh đầu ra của chính nó.
Mô tả công việc của agent Đánh giá bắt đầu thu hẹp lại.
Đây là sự suy giảm của harness.
Mỗi thành phần trong một harness mã hóa một giả định về những gì mô hình không thể làm.
Khi các mô hình cải thiện → những giả định đó hết hạn → thành phần trở thành chi phí phụ.
Opus 4.5: phân rã sprint + đánh giá theo từng sprint
Opus 4.6: không phân rã sprint + đánh giá một lượt (tiết kiệm 38% chi phí)
Opus 4.7: mô hình bắt đầu tự xác minh → vai trò người đánh giá thu hẹp hơn nữa
18. Xây dựng để Xóa bỏ
Lời khuyên của Philipp Schmid:
"Hãy xây dựng để xóa bỏ."
Thiết kế mọi thành phần harness để có thể loại bỏ được.
Kiểm tra từng thành phần định kỳ bằng cách tắt nó đi và đo lường xem chất lượng đầu ra có thay đổi không.
Nếu nó không thay đổi: hãy xóa nó.
Manus đã tái cấu trúc harness của họ 5 lần trong 6 tháng. LangChain tái cấu trúc 3 lần trong 1 năm. Vercel loại bỏ 80% công cụ → đạt hiệu suất tốt hơn.
Đây không phải là dấu hiệu của kỹ thuật tồi.
Chúng là hệ quả tự nhiên của việc xây dựng trên các mô hình đang cải thiện nhanh chóng.
Mang các thành phần harness chết tốn token trong mỗi lần chạy. Không có thêm chất lượng. Hoàn toàn lãng phí.
19. Thực tế về Chi phí
Con số trung thực từ thử nghiệm A/B của Anthropic:
→ Agent đơn độc (không harness): $9, 20 phút
→ giao diện hoạt động, chức năng cốt lõi bị hỏng
→ Harness đầy đủ (Opus 4.5): $200, 6 giờ
→ phần mềm hoạt động, giao diện người dùng trau chuốt, vật lý chính xác
Đó là mức tăng chi phí gấp 22 lần.
Để có một sản phẩm hoạt động so với một bản demo chỉ trông đẹp trong ảnh chụp màn hình.
Việc đó là đắt hay rẻ hoàn toàn phụ thuộc vào việc một bản phát hành bị lỗi sẽ tốn kém bao nhiêu cho đội của bạn.
Nhưng đây là điều không ai nói đến:
Sự kết hợp harness + mô hình phát triển.
Harness trị giá $200 đã trở thành $124 chỉ với một lần nâng cấp mô hình.
Đường xu hướng:
→ Mô hình tốt hơn = harness đơn giản hơn = chạy rẻ hơn = đầu ra nhanh hơn
Các kỹ sư chiến thắng vào năm 2026 không phải là người viết code tốt nhất.
Họ là người thiết kế các ràng buộc tốt nhất.
Và sau đó sẵn sàng vứt bỏ những ràng buộc đó ngay khi chúng không còn xứng đáng với chi phí bỏ ra.
KẾT LUẬN
Tất cả những gì bạn vừa học được:
Harness là gì:
→ 1. Agent = Mô hình + Harness
→ 2. Mô hình = CPU. Harness = Hệ điều hành.
→ 3. Cùng một mô hình, harness tốt hơn = +13% hiệu suất
5 tác phẩm harness:
→ 4. CLAUDE.md / AGENT.md — tài liệu hướng dẫn cho agent
→ 5. Danh sách tính năng JSON — trình theo dõi tiến độ + bộ kiểm thử trong một
→ 6. Quy trình khởi tạo phiên — 7 bước khởi động giống nhau mỗi lần
→ 7. Hợp đồng sprint — agent đàm phán trước khi code
→ 8. Mẫu nhiệm vụ có cấu trúc — đường dẫn tệp thực tế, các mẫu thực tế
Ba trường phái:
→ 9. OpenAI: thiết kế môi trường, thả agent ra
→ 10. Anthropic: tách người thực hiện khỏi người đánh giá
→ 11. ThoughtWorks: khuôn khổ feedforward/feedback 2×2
5 nguyên tắc phổ quát:
→ 12. Ngữ cảnh quan trọng hơn chỉ dẫn
→ 13. Lập kế hoạch và thực thi phải được tách biệt
→ 14. Vòng phản hồi là bắt buộc
→ 15. Mỗi lần một việc
→ 16. Codebase là tài liệu
Nghịch lý:
→ 17. Sự suy giảm của harness — thứ hiệu quả tháng trước có thể gây hại tháng này
→ 18. Xây dựng để xóa bỏ — kiểm tra và loại bỏ các thành phần chết
→ 19. Thực tế về chi phí — mô hình tốt hơn = harness đơn giản hơn = chạy rẻ hơn
Các kỹ sư chiến thắng vào năm 2026 không phải là người viết code tốt nhất.
Họ là người thiết kế các ràng buộc tốt nhất.
Và sẵn sàng vứt bỏ những ràng buộc đó ngay khi chúng không còn xứng đáng với chi phí bỏ ra.
Nếu điều này hữu ích:
→ Hãy chia sẻ lại để tiếp cận những người xây dựng trong mạng lưới của bạn
→ Theo dõi @sairahul1 để biết thêm nhiều nội dung như thế này hàng tuần
→ Đánh dấu trang này — bạn sẽ tham khảo nó khi các agent của bạn bắt đầu hoạt động sai
Tôi viết về AI, xây dựng sản phẩm và những gì thực sự hiệu quả trong năm 2026.
