Bạn đã bao giờ gặp tình huống này chưa?
Cùng một Claude, cùng một GPT-4o—một người dùng nó để viết 1 triệu dòng code trong 5 tháng, trong khi người khác thậm chí không thể chạy nó ổn định trong hai giờ.
Các mô hình giống hệt nhau, nhưng kết quả lại khác xa nhau.
Vấn đề nằm ở đâu?
Gần đây tôi đã đọc một loạt bài viết từ OpenAI, Anthropic, Martin Fowler và Phil Schmid, và tôi nhận ra họ đều đang nói về cùng một thứ.
Họ gọi nó là Kỹ thuật Harness (Harness Engineering).
Nói một cách đơn giản, đó là xây dựng một "hệ điều hành" cho Agent của bạn.
Đầu tiên, Hãy Hiểu Harness Là Gì
Phil Schmid đã đưa ra một phép so sánh tuyệt vời trong một bài đăng trên blog HuggingFace.
Hãy nghĩ về một hệ thống Agent như một chiếc máy tính.
Mô hình là CPU, cung cấp sức mạnh tính toán thô. Cửa sổ ngữ cảnh là RAM, lưu trữ mọi thứ tạm thời. Agent là ứng dụng chạy bên trên.
Vậy, hệ điều hành là gì?
Harness chính là hệ điều hành.
Không có hệ điều hành, ngay cả CPU mạnh nhất cũng chỉ là một con chip. Bạn không thể gõ chữ trên một con chip.
Tương tự, không có Harness, ngay cả mô hình thông minh nhất cũng chỉ là một hộp chat. Nếu bạn để nó chạy một tác vụ phức tạp trong một giờ, điều gì sẽ xảy ra nếu nó quên mất ngữ cảnh? Ai sẽ ngăn nó viết code rác? Điều gì xảy ra nếu nó mắc lỗi và thậm chí không biết mình sai?
Đây không phải là những vấn đề bạn giải quyết bằng cách "chuyển sang một mô hình thông minh hơn."
Martin Fowler đã nói một điều khiến tôi suy nghĩ: Harness có thể trở thành "các mẫu dịch vụ" trong tương lai. Cũng giống như hôm nay bạn bắt đầu một dự án mới với một mẫu dịch vụ, bạn sẽ bắt đầu một Agent mới với một mẫu Harness.
Tôi nghĩ dự đoán này rất có khả năng trở thành hiện thực.
Tại Sao Nó Bỗng Nhiên Bùng Nổ Vào Năm 2026?
Bởi vì các mô hình giờ đã đủ mạnh.
Năm 2024, mọi người đều cạnh tranh xem mô hình của ai thông minh hơn. Đến năm 2026, khoảng cách giữa các mô hình hàng đầu đã trở nên rất nhỏ. Nếu bạn đưa cho Claude và GPT cùng một vấn đề, điểm số của chúng chỉ chênh lệch vài điểm.
Nhưng nếu bạn để chúng làm việc liên tục trong 8 giờ, khoảng cách sẽ xuất hiện.
Khoảng cách này không nằm ở bản thân mô hình; nó nằm ở "harness" bao quanh nó.
Nhóm Codex của OpenAI có một thống kê đáng kinh ngạc. Họ đã sử dụng Codex để xây dựng một sản phẩm hoàn chỉnh—5 tháng, 1 triệu dòng code, không một dòng nào viết tay. Trong suốt quá trình, họ nhận thấy nút thắt cổ chai không còn là "liệu mô hình có thể viết code hay không."
Nút thắt cổ chai là liệu con người có thể review code đủ nhanh hay không.
Tốc độ đầu ra của mô hình đã vượt quá tốc độ review của con người. Tại thời điểm này, việc tối ưu hóa mô hình còn có ích gì? Bạn nên tối ưu hóa quy trình review, kiểm soát chất lượng và các ràng buộc kiến trúc.
Đó là những gì Harness làm.
Ba Trụ Cột
Vậy, một Harness thực sự chứa những gì?
Sau khi đọc những bài viết này, tôi thấy rằng mặc dù thuật ngữ có khác nhau, nhưng có ba trụ cột cốt lõi.
1. Vòng Lặp Đánh Giá (Evaluation Closed-Loop)
Đây là điều Anthropic nhấn mạnh nhất.
Ý tưởng cốt lõi rất đơn giản: Một Agent không thể tự chấm điểm cho mình.
Hãy nghĩ mà xem: nếu một thực tập sinh hoàn thành một báo cáo và bạn hỏi họ làm thế nào, họ sẽ nói "cũng ổn." Bạn cần một người độc lập để đánh giá.
Anthropic gọi đây là "Phát triển Dựa trên Đánh giá (Evaluation-Driven Development)." Đầu tiên, xác định "làm tốt" trông như thế nào, sau đó để Agent thực hiện, và cuối cùng có một người đánh giá độc lập chấm điểm.
Phát triển Dựa trên Đánh giá là phiên bản dành cho Agent của TDD. Viết bài kiểm tra trước, sau đó viết code. Chỉ khác là ở đây, "bài kiểm tra" là dành cho Agent.
Người đánh giá không chỉ nhìn vào code. Họ thực sự vận hành sản phẩm—sử dụng Playwright để nhấp nút, điền biểu mẫu và chạy thử nghiệm—sau đó đánh giá dựa trên các tiêu chuẩn rõ ràng.
Có một trường hợp rất thú vị ở đây.
Opus 4.5 của Anthropic đã tìm ra một lỗ hổng trong chính sách đặt vé trong một bài kiểm tra đặt chuyến bay, tìm ra một giải pháp tốt hơn cả đáp án chuẩn.
Nhưng người đánh giá đã đánh dấu nó là "thất bại."
Tại sao? Bởi vì người đánh giá không mong đợi một giải pháp sáng tạo như vậy. Chỉ có một đáp án chuẩn duy nhất, và vì Agent tìm ra một giải pháp tốt hơn, nó đã bị phạt.
Câu chuyện này cho thấy hai điều: thứ nhất, Agent đủ thông minh để tìm ra các giải pháp mà con người chưa nghĩ tới. Thứ hai, vòng lặp đánh giá không chỉ kiểm tra Agent; nó cũng kiểm tra chính việc đánh giá. Nếu người đánh giá của bạn quá cứng nhắc, nó sẽ trở thành nút thắt cổ chai.
Một dữ liệu khác: Opus 4.5 ban đầu đạt 42% trên CORE-Bench. Sau khi họ sửa lỗi chấm điểm và nới lỏng các ràng buộc scaffold, điểm số đã nhảy vọt lên 95%.
Thường thì, không phải mô hình không đủ tốt; mà là Harness của bạn có vấn đề.
Sử dụng phương pháp này, Anthropic đã có một Agent xây dựng một trò chơi hoàn chỉnh trong 6 giờ với chi phí 200 đô la.
2. Ràng Buộc Kiến Trúc (Architectural Constraints)
Đây là thế mạnh của nhóm OpenAI Codex.
Bạn nói với một thực tập sinh "code cần phải có分层," họ gật đầu, sau đó ngay lập tức viết logic UI vào tầng cơ sở dữ liệu.
Nói suông là vô ích.
Cách tiếp cận của OpenAI là thực thi nó một cách cơ học thông qua linter và CI. Code vi phạm các quy tắc kiến trúc sẽ bị từ chối ngay lập tức, thậm chí không được review.
Sự phân tầng code của họ trông như thế này: Types → Config → Service → UI. Mỗi tầng chỉ có thể phụ thuộc vào tầng bên trên nó, không bao giờ được phép ngược lại. Quy tắc này không chỉ được viết trong một tài liệu; nó được viết trong một linter để tự động kiểm tra.
Thậm chí tốt hơn, những linter này tự chúng được tạo ra bởi Codex.
Agent tự viết các quy tắc của riêng mình và sau đó tuân theo chúng.
Martin Fowler đã nói sau khi đọc bài báo của OpenAI:
"Tăng cường sự tin cậy và độ tin cậy đòi hỏi phải thu hẹp không gian giải pháp. Điều này có nghĩa là từ bỏ một phần sự linh hoạt để 'tạo ra bất cứ thứ gì.'"
Càng nhiều ràng buộc, càng đáng tin cậy.
Nghe có vẻ phản trực giác, nhưng dữ liệu đã nói lên điều đó. LangChain đã làm một thí nghiệm: không thay đổi mô hình, chỉ thay đổi Harness, và tỷ lệ vượt qua Terminal Bench 2.0 đã tăng từ 52,8% lên 66,5%. Vercel đi xa hơn, xóa 80% công cụ Agent, dẫn đến ít bước hơn, tốc độ nhanh hơn và kết quả tốt hơn.
Ít công cụ hơn thường dẫn đến hiệu suất tốt hơn—kết luận này đã được xác nhận nhiều lần trong lĩnh vực Agent.
3. Quản Lý Bộ Nhớ (Memory Governance)
Trụ cột này ít được thảo luận hơn, nhưng tôi nghĩ nó quan trọng nhất về lâu dài.
PrismerCloud đã làm việc chuyên sâu theo hướng này.
Vấn đề là: khi nhiều Agent chia sẻ một cơ sở kiến thức, Agent A viết một kinh nghiệm, và Agent B đọc nó như một sự thật. Nhưng điều gì sẽ xảy ra nếu Agent A đã sai?
Sự ảo giác của một Agent có thể làm ô nhiễm tất cả các Agent khác thông qua cơ sở kiến thức chung.
Cách tiếp cận của PrismerCloud là xây dựng một "Công cụ Tiến hóa (Evolution Engine)." Mỗi kinh nghiệm của Agent trước tiên được ghi lại như một "tín hiệu." Sau khi được xác minh, các tín hiệu được chưng cất thành "gen," và liên tục được tối ưu hóa dựa trên kết quả thực tế.
Nói một cách đơn giản, gen là kiến thức đã được xác minh, hiệu quả. Nếu chưa được xác minh, nó không được tính.
Có một thống kê thú vị: 3 dòng prompt cộng với một hệ thống bộ nhớ hoạt động tốt gần như tương đương với 200 dòng prompt chuyên gia được xây dựng cẩn thận. Hơn nữa, cái trước tiến hóa, trong khi cái sau là tĩnh.
Điều này có nghĩa là nếu hệ thống bộ nhớ của bạn tốt, bạn không cần các prompt phức tạp. Agent sẽ tự nhiên cải thiện theo thời gian.
Phần thưởng: Chống Lại Sự Suy Thoái (Entropy Resistance)
Đây không phải là một trụ cột độc lập nhưng đáng được đề cập.
Các hệ thống Agent tự nhiên suy thoái theo thời gian. Tài liệu hết hạn, kiến trúc bị phá vỡ, và cơ sở kiến thức chứa đầy thông tin lỗi thời.
Cách tiếp cận của OpenAI là định kỳ chạy một "Agent Tái Cấu Trúc (Refactoring Agent)" để quét tìm sự không nhất quán trong tài liệu và vi phạm kiến trúc. Họ đã nói rất đúng:
"Khi một Agent gặp khó khăn, chúng tôi coi đó là một tín hiệu: tìm ra những gì còn thiếu, đưa nó trở lại codebase, và luôn để Codex viết bản sửa lỗi."
Khi một Agent gặp vấn đề, đừng chỉ sửa Agent—hãy sửa Harness. Tư duy này là chìa khóa.
Ai Đang Làm Điều Này?
Lĩnh vực này được chia thành hai hướng: các dự án mã nguồn mở bạn có thể sử dụng ngay hôm nay, và các thực tiễn nội bộ của các công ty thương mại mà bạn chỉ có thể học hỏi phương pháp luận.
Dự Án Mã Nguồn Mở: Sẵn Sàng Sử Dụng
LangChain DeepAgents: Có lẽ là dự án mã nguồn mở gần nhất với một "Claude Code phổ quát." Lập kế hoạch, thao tác tệp, ủy quyền sub-agent, nén ngữ cảnh tự động—sẵn sàng sử dụng ngay. 115k sao trên GitHub.
DeerFlow 2.0: Từ ByteDance. Được mã nguồn mở vào tháng 3, nó đã đạt 39k sao trong một tháng. Nó tự gọi mình là "SuperAgent Harness." Đây là một bản viết lại hoàn toàn từ v1 với thực thi sandbox, bộ nhớ liên tục và hệ thống kỹ năng dựa trên LangGraph.
OpenHands: Chuyên biệt cho các Agent viết code. Nó đạt 77,6% trên SWE-bench Verified. Nó không phụ thuộc vào mô hình và sử dụng Laminar để quan sát, theo dõi mọi hành động của Agent.
SWE-agent: Từ Princeton và Stanford. Nó tập trung vào việc hoàn thiện phát triển "dựa trên đánh giá."
Goose: Được mã nguồn mở bởi Block (Square/Cash App). Một Agent trên máy tổng quát có thể cài đặt phụ thuộc, chạy thử nghiệm và quản lý tệp.
PrismerCloud: Tập trung vào quản lý bộ nhớ và công cụ tiến hóa. Đây là giải pháp trưởng thành nhất để ngăn chặn sự ô nhiễm ảo giác trong các hệ thống đa Agent.
Cognee: Một công cụ bộ nhớ dựa trên đồ thị tri thức cho Agent giúp thiết lập các kết nối ngữ nghĩa giữa dữ liệu.
Thực Tiễn Thương Mại: Học Phương Pháp Luận
Claude Code + Agent SDK: Điểm chuẩn của Anthropic cho một Harness tổng quát. Nó không chỉ dành cho việc viết code; họ sử dụng nó cho nghiên cứu, tạo video và ghi chú.
OpenAI Codex: Thực tiễn tối thượng về các ràng buộc kiến trúc. 1 triệu dòng code không viết tay, dựa vào các linter tự động tạo và đánh giá đồng cấp Agent.
Một Bài Học Khiến Tôi Suy Nghĩ
Rich Sutton đã viết một bài báo kinh điển có tên "The Bitter Lesson." Nội dung chính là các phương pháp tổng quát tận dụng sức mạnh tính toán sẽ luôn đánh bại các phương pháp cụ thể do con người thiết kế về lâu dài.
Bài học này đang được chứng minh một lần nữa trong lĩnh vực Agent.
Manus đã tái cấu trúc Harness của mình 5 lần trong 6 tháng. LangChain đã tái kiến trúc 3 lần trong một năm. Vercel đã xóa 80% công cụ của mình.
Xây Dựng Để Xóa Bỏ.
"Logic thông minh" bạn viết hôm nay có thể trở nên lỗi thời vào ngày mai khi mô hình được nâng cấp. Kiến trúc của bạn phải có tính mô-đun và sẵn sàng bị loại bỏ.
Phil Schmid đã nói một điều đáng ghi nhớ:
"Lợi thế cạnh tranh không còn là prompt; đó là các quỹ đạo (trajectories) được Harness của bạn thu thập. Mọi thành công và thất bại đều là dữ liệu để đào tạo thế hệ tiếp theo."
Harness của bạn chạy càng lâu và tích lũy càng nhiều quỹ đạo, Agent của bạn càng trở nên mạnh mẽ. Bạn không thể bắt kịp chỉ bằng cách chuyển đổi mô hình.
Ba Giai Đoạn
Hãy nghĩ về vị trí của Harness trong kỹ thuật AI như thế này.
Kỹ thuật Prompt (Prompt Engineering) giải quyết "nói gì." Một tương tác đơn lẻ.
Kỹ thuật Ngữ cảnh (Context Engineering) giải quyết "biết gì." Cung cấp tài liệu tham khảo và lịch sử.
Kỹ thuật Harness (Harness Engineering) giải quyết "làm việc liên tục, ổn định và ở quy mô lớn như thế nào." Vòng lặp đánh giá đảm bảo chất lượng, ràng buộc kiến trúc đảm bảo quy tắc, và quản lý bộ nhớ đảm bảo tích lũy kinh nghiệm.
Không có Harness, một Agent có thể nhớ mọi thứ nhưng không có sự giám sát, dẫn đến hỗn loạn. Khi cả ba lớp đều có mặt, bạn có một nhân vật có thể thực sự làm việc lâu dài.
OpenAI, Anthropic và LangChain đã và đang làm điều này.
Nguồn: OpenAI Harness Engineering, Anthropic Demystifying Evals, Phil Schmid (HuggingFace) The Importance of Agent Harness in 2026, Martin Fowler Harness Engineering, LangChain Agent Frameworks.
