Kỹ sư Harness đang thành nghề thật – Đây là công việc thực sự

Trong hai năm qua, những lời khuyên nghề nghiệp xoay quanh AI agent chủ yếu xoay quanh việc học cách prompt chúng cho tốt. Đó không còn là kỹ năng khan hiếm nữa. Kỹ năng khan hiếm bây giờ là xây dựng bộ khung mà một agent hoạt động bên trong — thứ ngày càng được gọi là harness (bộ khung vận hành) — và nó đủ cụ thể, đủ khó, đến mức đang trở thành một chức danh công việc riêng thay vì chỉ là một trách nhiệm phụ của "người phụ trách AI" trong đội nhóm.

Bài phân tích công khai rõ ràng nhất về việc này thực sự bao gồm những gì đến từ Lenny's Newsletter, ghi lại cách công cụ quản lý sản phẩm ChatPRD xây dựng một harness để tự động gỡ lỗi các bug trên Sentry. Bài viết đáng đọc trọn vẹn nếu bạn đang cân nhắc chuyên sâu vào lĩnh vực này, vì nó nêu ra một điểm dễ bị bỏ qua: mô hình chưa bao giờ là nút thắt cổ chai. Đội ngũ đã dùng Claude Agent SDK làm nền tảng, rồi dành phần lớn công sức kỹ thuật vào một giao diện terminal tùy chỉnh và một tập hợp các adapter kết nối agent với Sentry, Linear, GitHub và Vercel. Đó chính là công việc, thu nhỏ lại. Bốn hệ thống, bốn cơ chế xác thực khác nhau, bốn dạng dữ liệu khác nhau, và một giao diện cho phép con người theo dõi và can thiệp mà không phải giám sát từng bước một.

"Harness" thực chất bao gồm những gì

Nếu bạn đang cố xác định xem đây có phải là bộ kỹ năng đáng để xây dựng hay không, sẽ hữu ích nếu tách nó ra thành các phần được tuyển dụng riêng biệt, hoặc ít nhất được đánh giá riêng biệt trong một buổi phỏng vấn:

• Thiết kế quyền hạn. Quyết định những gì một agent được phép làm khi không có người giám sát (đọc một ticket, soạn một PR) so với những gì cần có con người tham gia (merge, deploy, xóa, chi tiền) — và mã hóa điều đó thành chính sách thực sự trong code, chứ không phải một chỉ dẫn prompt mà mô hình có thể bỏ qua khi bị áp lực. Việc này gần với kỹ thuật kiểm soát truy cập hơn là viết prompt.
• Adapter công cụ. Các lớp bọc mỏng, được kiểm thử kỹ càng quanh mỗi hệ thống bên ngoài (Sentry, Linear, GitHub, Vercel, hay bất cứ ngăn xếp nào công ty bạn dùng) chuyển ý định của agent thành một lệnh gọi API an toàn, đã được xác thực, và chuyển phản hồi ngược lại thành thứ mà mô hình có thể suy luận được. Đây là kỹ thuật phần mềm thông thường — xử lý lỗi, thử lại, kiểm tra schema — áp dụng cho một đối tượng tiêu thụ mới.
• Giao diện terminal hoặc console. Một cách để con người thấy được agent đang làm gì, phê duyệt hoặc từ chối các hành động, và can thiệp khi nó bị kẹt. ChatPRD đã xây một giao diện tùy chỉnh; nhiều đội nhóm khác sẽ dùng các console agent có sẵn thay vì tự xây, nhưng vẫn phải có người quyết định cái gì được hiển thị, cái gì bị ẩn, và cái gì cần một cú click trước khi thực thi.
• Lựa chọn công cụ ở quy mô lớn. Một bài viết từ Machine Learning Mastery chỉ ra điều đáng biết nếu bạn xây dựng bất cứ thứ gì vượt ra ngoài một bản demo: độ chính xác của agent khi gọi công cụ có xu hướng giảm sút một khi danh mục công cụ vượt quá khoảng một tá lựa chọn — mô hình bắt đầu gọi sai công cụ, bịa ra tham số, hoặc bị kẹt ở những lệnh gọi lỗi. Các biện pháp giảm thiểu mà bài viết liệt kê (giới hạn công cụ nào được hiển thị trong một ngữ cảnh nhất định, tra cứu công cụ dựa trên truy xuất, định tuyến tới các sub-agent chuyên biệt, các bước lập kế hoạch rõ ràng, logic dự phòng, và các bộ harness benchmark để bắt lỗi thoái lui) tự bản thân chúng là một danh sách kiểm tra những thứ mà một kỹ sư harness cần biết cách triển khai, chứ không chỉ biết về chúng.
• Kỹ thuật ngữ cảnh và bộ nhớ. Cùng nguồn đó đưa ra một sự phân biệt đáng ghi nhớ: kỹ thuật ngữ cảnh (context engineering — những gì được đưa vào một lần gọi suy luận đơn lẻ, và đưa vào đâu) và kỹ thuật bộ nhớ (memory engineering — những gì tồn tại qua các phiên làm việc, được lưu trữ như thế nào, được truy xuất ra sao) là hai lĩnh vực khác nhau với các kiểu lỗi khác nhau. Luận điểm của bài viết là hầu hết các sự cố ở các agent chạy dài, đa phiên đều bắt nguồn từ việc gộp lẫn hai thứ này — coi bộ nhớ phiên như thể chỉ là thêm ngữ cảnh, hoặc ngược lại — đặc biệt là ở thời điểm hệ thống quyết định truy xuất cái gì.

Bằng chứng cho thấy đây là một vai trò thực sự, có thể được tài trợ — không chỉ là một ngách dành cho người nghiệp dư

Những người hoài nghi sẽ hợp lý khi đặt câu hỏi liệu "kỹ sư harness" có phải là một công việc hay chỉ là một tác vụ nằm trong công việc của ai đó khác. Hai dữ liệu từ bản tổng hợp gợi ý rằng nó đang tiến dần về vế đầu. Thứ nhất, đội Aspire của Microsoft — một nhóm 10 người — đã dùng Agentic Workflows của GitHub để tự động hóa các PR tài liệu xuyên nhiều repo, và qua hai đợt phát hành đã merge 82 PR với thời gian trung vị là 44,8 giờ sau khi PR sản phẩm tương ứng được phát hành, mà không cần tuyển thêm người hay đào tạo lại quy trình. Đó là một đội nhỏ đạt được đòn bẩy vượt trội chính vì có ai đó đầu tư vào bộ khung (các định nghĩa workflow, định tuyến review, logic kích hoạt) thay vì để các kỹ sư tự tay viết PR tài liệu. Thứ hai, dự án SkillOpt của Microsoft Research coi các tệp "kỹ năng" của agent — những chỉ dẫn và ràng buộc định hình cách agent hành xử trong harness của nó — là thứ cần được tối ưu hóa một cách có hệ thống thay vì chỉnh sửa thủ công, và báo cáo rằng nó tốt nhất hoặc đồng hạng tốt nhất trên toàn bộ 52 ô của một lưới benchmark (sáu benchmark, bảy mô hình, ba chế độ thực thi), với các kỹ năng đã tối ưu có thể chuyển giao qua các mô hình và harness khác nhau. Cho dù công cụ cụ thể đó có trở thành chuẩn mực hay không, nó vẫn cho thấy ngành đang bắt đầu coi việc cấu hình harness như một sản phẩm kỹ thuật có công cụ và benchmark riêng — cùng quỹ đạo đã biến "DevOps" từ một tập hợp các script tùy tiện thành một chuyên ngành.

Hiện cũng đã có hạ tầng được xây dựng riêng cho lớp này. Các tính năng "Managed Agents" mới được Google công bố trong Gemini API — thực thi nền và bất đồng bộ, tích hợp máy chủ MCP từ xa, gọi hàm tùy chỉnh, làm mới thông tin xác thực xuyên các lần tương tác — về cơ bản là hệ thống ống dẫn dựng sẵn cho chính xác những vấn đề mà đội ChatPRD đã tự tay giải quyết. Đó là một khuôn mẫu bình thường: những gì một đội tự xây dựng riêng biệt năm nay, một nhà cung cấp nền tảng sẽ đóng gói thành sản phẩm vào năm sau. Điều này không xóa bỏ vai trò kỹ sư harness; nó nâng mặt sàn lên và chuyển trọng tâm công việc sang tích hợp và cấu hình các thành phần được quản lý sẵn thay vì tự viết từng adapter từ đầu, tương tự như cách hạ tầng đám mây không xóa bỏ các kỹ sư vận hành, mà thay đổi cách họ dành thời gian.

Điều này có ý nghĩa gì nếu bạn đang nhắm đến vai trò này

Có vài thứ cụ thể, có thể kiểm chứng được, để đưa vào portfolio hoặc CV nếu bạn muốn có độ tin cậy cho công việc này: xây dựng một adapter hoàn chỉnh từ đầu đến cuối với một API thực tế mà bạn không kiểm soát được (bao gồm cả xác thực, xử lý lỗi, giới hạn tốc độ, chứ không phải chỉ một bản demo theo kịch bản suôn sẻ); thiết kế và tài liệu hóa một mô hình quyền hạn cho agent phân biệt rõ các hành động đọc/đề xuất/thực thi và giải thích tại sao mỗi ranh giới lại nằm ở vị trí đó; và xây dựng hoặc cấu hình một giao diện review nơi con người phê duyệt các hành động của agent trước khi chúng được thực thi, vì đây là phần mà hầu hết các công ty sẽ khăng khăng yêu cầu trước khi cho phép agent chạm vào môi trường sản xuất. Nếu bạn đang đánh giá một lời mời làm việc kỹ sư harness hoặc đang xác định phạm vi trách nhiệm của chính mình, hãy hỏi cụ thể ai sở hữu mô hình quyền hạn, ai sở hữu các adapter, và ai sở hữu bề mặt review của con người — ở nhiều đội nhóm hiện nay, ba thứ đó không có chủ sở hữu rõ ràng, và đó chính xác là khoảng trống mà vai trò này đang hình thành để lấp đầy.

Có một lưu ý đáng nói thẳng: không nguồn nào ở trên xác lập được một con số thị trường tuyển dụng cho chức danh cụ thể này, và "kỹ sư harness" chưa phải là một chức danh bạn sẽ thấy trong các tin tuyển dụng — nó đang xuất hiện bên trong các chức danh như "kỹ sư hạ tầng AI", "kỹ sư nền tảng agent", hay đơn giản là "kỹ sư backend cấp cao, hệ thống AI". Hãy coi đây là một bộ kỹ năng cần xây dựng và mô tả chính xác, chứ không phải một chức danh để tìm kiếm trên LinkedIn.