Harness nổi bật — nhưng mọi người chưa hiểu rõ nó thực sự muốn nuốt chửng ai

Palo Alto sáng, cà phê vừa được mang lên, Alan Walker cúi đầu lướt qua bài viết về harness của Anthropic, ngẩng đầu chỉ nói một câu:

“Rất nhiều người nghĩ rằng đây là một bước tiến nhỏ của mô hình. Sai rồi, đây là quy trình bắt đầu phản bội con người.”

Bài viết này bề mặt nói về thiết kế kỹ thuật, nói về planner, generator, evaluator, nói về cách làm cho Claude chạy liên tục vài giờ, làm những sản phẩm phức tạp hơn.

Hầu hết mọi người đọc đến đây thì dừng lại. Họ sẽ cảm thấy:

Ồ, thì ra chỉ là agent phức tạp hơn, prompt dài hơn, workflow chi tiết hơn.

Nhưng Alan nói, điều thực sự đáng xem không bao giờ là chức năng bề mặt, mà là quyền lực đang chuyển dịch đến đâu.

Trong quá khứ, để hoàn thành một nhiệm vụ phức tạp, phải có người phân tích yêu cầu, người thực hiện, người kiểm tra, người làm lại, người đảm bảo.

Giờ đây, điều mà Anthropic đang làm không phải là làm cho mô hình giống như một nhân viên thông minh hơn, mà là để toàn bộ hệ thống bắt đầu tiếp quản quyền tổ chức, giám sát và thẩm định vốn thuộc về con người.

Harness không phải là phần mềm mở rộng. Harness là máy móc bắt đầu phát triển “tầng quản lý”.

Đó mới là điều thật sự đáng sợ.

01 Không phải công cụ, mà là “tầng quản lý công cụ”

Rất nhiều người khi thấy harness, phản ứng đầu tiên là: đây không phải là một framework agent khác sao?

Cách hiểu này quá nông cạn.

Bản chất của công cụ bình thường là nghe lệnh rồi thực hiện. Bạn nhấn một cái, nó làm một cái. Bạn không nói, nó không động.

Nhưng harness không còn là logic này nữa. Điều nó thực sự làm là số hóa cấu trúc phân công mà trước đây ẩn trong đội ngũ con người:

Ai sẽ hiểu yêu cầu, ai sẽ phân chia thành các giai đoạn, ai sẽ thực hiện, ai sẽ kiểm tra, ai có quyền trả lại khi phát hiện vấn đề.

Nói cách khác, Anthropic không phải đang tích lũy thêm chức năng, mà đang viết vào hệ thống “cách tổ chức công việc”.

Tại sao bước này quan trọng? Bởi vì điều khó nhất trong quá khứ không phải là khả năng đơn lẻ, mà là khả năng tổ chức.

Nhiều người biết viết mã.

Nhưng những người có thể tổ chức mười mấy người, mười mấy bước, mười mấy vòng làm lại để cuối cùng giao hàng ổn định thì rất ít.

Và điều mà harness chạm đến chính là thứ đắt giá nhất này.

Công cụ nâng cao hiệu suất, tổ chức quyết định sản lượng.

Mô hình đơn lẻ chỉ là lực lượng lao động, Harness bắt đầu chạm tới cấu trúc công ty.

Khi AI không chỉ biết làm việc, mà còn biết phân công, giao tiếp, và chịu trách nhiệm, nó đã không còn đơn giản là một “nâng cấp công cụ” nữa.

02 Không phải thông minh hơn, mà là không dễ bị bỏ dở

Điểm gây nhầm lẫn nhất của mô hình là nó luôn tỏ ra rất thông minh trong các nhiệm vụ ngắn.

Hỏi nó một câu, nó trả lời rất thuyết phục; yêu cầu nó viết một đoạn mã, nó cũng thường làm rất giống. Do đó, nhiều người nhầm tưởng: nếu nhiệm vụ ngắn đã làm được, thì nhiệm vụ dài chẳng phải chỉ cần chạy lâu hơn sao?

Hoàn toàn không phải.

Điều thực sự khó khăn trong nhiệm vụ dài không bao giờ là bước nào đó không thực hiện được, mà là sau hàng chục bước liên tiếp vẫn không mất kiểm soát, không bị lừa dối bản thân.

Con người khi thực hiện dự án cũng vậy. Điều đáng sợ nhất không phải là không biết làm, mà là khi đến giai đoạn sau lại bắt đầu lộn xộn:

Yêu cầu không nhớ rõ,

Mục tiêu bắt đầu trôi nổi,

Logic trước sau không nhất quán,

Cuối cùng, điều mà họ làm tốt nhất không phải là hoàn thành công việc, mà là viết một bản tóm tắt trông như đã hoàn thành.

Vấn đề cốt lõi mà bài viết của Anthropic đề cập về cơ bản chính là điều này:

Mô hình trong các nhiệm vụ dài sẽ dần mất phương hướng. Ngữ cảnh càng dài, trạng thái càng lộn xộn, càng dễ rơi vào ảo giác tâm lý “cũng tạm được rồi”.

Giá trị của Harness không phải là làm cho nó nhanh nhẹn hơn, mà là làm cho nó không bị phân tán, không bị ảo tưởng, không dễ dàng qua loa.

Phân chia giai đoạn, thực hiện chuyển giao, định hợp đồng, đánh giá độc lập, quay lại khi thất bại, những điều này nhìn có vẻ như chi tiết quy trình, thực tế đều đang giải quyết cùng một vấn đề cơ bản:

Trí tuệ có thể không ổn định, nhưng giao hàng không thể phụ thuộc vào may mắn.

Vì vậy, nếu bạn thực sự muốn hiểu rõ harness, bạn phải hiểu một điều:

Điều thực sự có giá trị trong tương lai không phải là ai đôi khi có thể tạo ra một demo ấn tượng.

Mà là ai có thể để hệ thống trong vài giờ, vài ngày, hoặc thậm chí lâu hơn, liên tục đẩy công việc tiến lên mà không bị bỏ dở.

Biết viết không có gì đặc biệt.

Viết đến cuối mà không sụp đổ mới là đặc biệt.

Sự chợt lóe không có giá trị, giao hàng ổn định mới là giá trị.

Alan nói, điều lạnh lùng nhất trong bài viết của Anthropic không phải là planner, cũng không phải là generator, mà là evaluator.

Tại sao?

Bởi vì mô hình lớn có một nhược điểm cực kỳ giống với con người: những gì nó tự làm, luôn cảm thấy vẫn ổn.

Chỉ cần không có ràng buộc bên ngoài, nó rất dễ đưa ra một đánh giá “tổng thể ổn”, “cơ bản hoàn thành”, “chức năng cốt lõi đã đủ”.

Vấn đề là, đánh giá này nhiều khi không phải là dối trá, mà là một sự tự khoan dung có hệ thống.

Trong các công ty con người, tại sao nhiều dự án cuối cùng lại thất bại?

Bởi vì những người làm việc thường là người giỏi nhất trong việc tìm lý do cho bản thân.

Người làm nói đã gần xong,

Người nghiệm thu lười biếng không xem sâu,

Vì vậy, một thứ “gần như” đã được cho phép đi qua, cuối cùng đến tay người dùng thì phát nổ.

Điểm mạnh của Anthropic là trực tiếp tách rời điều này:

Người làm việc là một vai trò,

Người phát hiện lỗi là một vai trò khác.

Người trước chịu trách nhiệm thúc đẩy, người sau chịu trách nhiệm nghi ngờ.

Logic đằng sau điều này rất sâu sắc:

Một khi quyền sản xuất và quyền đánh giá tách rời, hệ thống bắt đầu hình thành vòng khép kín thực sự.

Và điều đáng sợ hơn là, Anthropic không chỉ để evaluator nói vài câu “tôi nghĩ chỗ này không ổn”. Nó đang cố gắng cấu trúc hóa “tìm lỗi”:

Chức năng phải kiểm tra, trang phải nhấp, giao diện phải kiểm tra, trạng thái cơ sở dữ liệu phải xem, chất lượng thiết kế cũng được tách thành các tiêu chí có thể đánh giá.

Điều này có nghĩa là gì?

Có nghĩa là nhiều quyền phán đoán trước đây được con người thần thánh hóa, đang dần được tách thành quy trình, tiêu chuẩn và ngưỡng.

Điều đầu tiên được tự động hóa thường không phải là sức lực, mà là tìm lỗi.

Một khi “cái này có hoạt động không” được quy trình hóa, nhiều kinh nghiệm của con người sẽ bắt đầu bị rò rỉ.

Trước đây nhiều vị trí thực sự có giá trị không phải vì có khả năng sản xuất, mà vì có quyền nói “cái này có đạt yêu cầu không”.

Giờ đây, quyền lực này bắt đầu rời khỏi tay con người.

03 Đòn chí mạng nhất, là không cho nó tự khen mình

Alan nói, điều lạnh lùng nhất trong bài viết của Anthropic không phải là planner, cũng không phải là generator, mà là evaluator.

Tại sao?

Bởi vì mô hình lớn có một nhược điểm cực kỳ giống với con người: những gì nó tự làm, luôn cảm thấy vẫn ổn.

Chỉ cần không có ràng buộc bên ngoài, nó rất dễ đưa ra một đánh giá “tổng thể ổn”, “cơ bản hoàn thành”, “chức năng cốt lõi đã đủ”.

Vấn đề là, đánh giá này nhiều khi không phải là dối trá, mà là một sự tự khoan dung có hệ thống.

Trong các công ty con người, tại sao nhiều dự án cuối cùng lại thất bại?

Bởi vì những người làm việc thường là người giỏi nhất trong việc tìm lý do cho bản thân.

Người làm nói đã gần xong,

Người nghiệm thu lười biếng không xem sâu,

Vì vậy, một thứ “gần như” đã được cho phép đi qua, cuối cùng đến tay người dùng thì phát nổ.

Điểm mạnh của Anthropic là trực tiếp tách rời điều này:

Người làm việc là một vai trò,

Người phát hiện lỗi là một vai trò khác.

Người trước chịu trách nhiệm thúc đẩy, người sau chịu trách nhiệm nghi ngờ.

Logic đằng sau điều này rất sâu sắc:

Một khi quyền sản xuất và quyền đánh giá tách rời, hệ thống bắt đầu hình thành vòng khép kín thực sự.

Và điều đáng sợ hơn là, Anthropic không chỉ để evaluator nói vài câu “tôi nghĩ chỗ này không ổn”. Nó đang cố gắng cấu trúc hóa “tìm lỗi”:

Chức năng phải kiểm tra, trang phải nhấp, giao diện phải kiểm tra, trạng thái cơ sở dữ liệu phải xem, chất lượng thiết kế cũng được tách thành các tiêu chí có thể đánh giá.

Điều này có nghĩa là gì?

Có nghĩa là nhiều quyền phán đoán trước đây được con người thần thánh hóa, đang dần được tách thành quy trình, tiêu chuẩn và ngưỡng.

Điều đầu tiên được tự động hóa thường không phải là sức lực, mà là tìm lỗi.

Một khi “cái này có hoạt động không” được quy trình hóa, nhiều kinh nghiệm của con người sẽ bắt đầu bị rò rỉ.

Trước đây nhiều vị trí thực sự có giá trị không phải vì có khả năng sản xuất, mà vì có quyền nói “cái này có đạt yêu cầu không”.

Giờ đây, quyền lực này bắt đầu rời khỏi tay con người.

04 Người đầu tiên bị ăn mất không phải là lập trình viên, mà là “đủ tốt là được”

Mỗi khi thấy những bài viết như vậy, nhiều người phản ứng ngay bằng câu hỏi: lập trình viên có phải sẽ hết thời không?

Alan nói, cách hỏi này quá nông cạn và cũng quá lười biếng.

Đợt ăn mất đầu tiên của Harness không phải một tên nghề nào đó.

Điều đầu tiên nó ăn mất là một cách sống tồn tại lâu dài, và rất phổ biến trong hầu hết các công việc tri thức:

Yêu cầu không rõ ràng, làm trước đã;

Giữa chừng làm sai, sau đó sửa lại;

Kết quả bình thường, nhưng có thể chạy;

Tài liệu không viết rõ, nhưng trong đội ngũ ai cũng hiểu;

Lên sóng trước, vấn đề về sau sửa.

Nói thẳng ra, đó là một bộ quy trình làm việc dựa trên không gian mơ hồ và sự linh hoạt của con người.

Nhiều dự án vẫn có thể tiến lên không phải vì quy trình thực sự rõ ràng, mà là vì giữa chừng luôn có người dựa vào kinh nghiệm, vị trí tạm thời, hoặc phán đoán tức thời để lấp đầy khoảng trống.

Điều mà Harness đang làm lại hoàn toàn ngược lại.

Nó đang thu hẹp không gian mơ hồ.

Nó đang thu hẹp không gian đổ lỗi.

Nó đang thu hẹp không gian “tôi nghĩ”, “gần như”, “nên có thể”.

Đầu tiên định nghĩa điều gì là hoàn thành trong vòng này, rồi mới cho phép bắt đầu;

Nếu không đạt yêu cầu, thì trả lại;

Nếu không được nghiệm thu, thì tiếp tục;

Đừng cảm giác, hãy có chứng cứ.

Khi logic này được đẩy lên, điều nguy hiểm nhất không bao giờ là những người viết mã giỏi nhất, mà là những người phụ thuộc vào vùng xám để sống.

Harness không ăn mất lập trình viên, mà đầu tiên ăn mất sự mơ hồ.

Không phải ai cũng sẽ bị thay thế, nhưng mọi vị trí sống dựa vào sự không rõ ràng sẽ sớm bị hạ giá.

Trước đây nhiều vị trí sống dựa vào sự chênh lệch thông tin, nhưng sau này nhiều vị trí sẽ chết trong sự chênh lệch tiêu chuẩn.

05 Tại sao nó lại nổi lên vào thời điểm này

Nhiều người sẽ hỏi, những thứ theo dạng quy trình như thế này trước đây cũng có người làm, tại sao lần này mọi người lại bắt đầu nghiêm túc?

Bởi vì trước đây nền tảng mô hình không đủ mạnh.

Nói thẳng ra:

Trước đây, nhiều framework kiểu này trông rất đẹp, chạy thì nặng nề, nhưng cuối cùng lại không đủ mạnh.

Bạn xây dựng một đống quy trình, một đống vai trò, viết một đống quy tắc, cuối cùng chỉ là đóng gói một mô hình không đáng tin cậy thành một hệ thống phức tạp hơn nhưng vẫn không đáng tin cậy.

Vì vậy, trong quá khứ, nhiều người đã mất kiên nhẫn với agent, workflow, scaffold cũng là điều bình thường.

Không phải là hướng sai, mà là nền tảng chưa đạt đến giai đoạn đó.

Giờ đây thì khác.

Khi mô hình vượt qua một ngưỡng nào đó, nhiều quy trình trước đây giống như trang trí bắt đầu lần đầu tiên phát huy giá trị thực.

Bởi vì khi mô hình đủ mạnh, quy trình không còn là hỗ trợ cho một thứ vô dụng, mà là khuếch đại một hệ thống đã có thể làm việc liên tục.

Đó là lý do tại sao harness giờ đây đột nhiên có vẻ “thực sự” hơn.

Không phải là ý tưởng của nó mới xuất hiện hôm nay, mà là mô hình cuối cùng đủ mạnh để thu hoạch lợi ích từ quy trình.

Alan đã nói rất chính xác:

Khả năng của mô hình là động cơ, Harness là hộp số.

Trước đây không có động cơ tốt, ngay cả hộp số tốt cũng chỉ là đồ trang trí.

Nhưng khi động cơ đã đủ mạnh, hộp số mới bắt đầu quyết định ai có thể chạy nhanh, ai vẫn đứng yên đạp ga.

Vì vậy, đây không chỉ là một sự phổ biến công nghệ đơn thuần, mà là ngành công nghiệp đang phát ra một tín hiệu sâu sắc hơn:

Cạnh tranh trong tương lai không chỉ là ai có mô hình mạnh hơn, mà là ai sớm hơn trong việc tích hợp mô hình vào hệ thống sản xuất.

06 “Con người mặc định đứng ở giữa”

Cuối cùng, Alan để ly xuống và nói câu lạnh lùng nhất ngày hôm đó:

“Trước đây con người theo dõi phần mềm làm việc, sau này phần mềm theo dõi phần mềm làm việc.”

Tại sao câu này lại đâm vào lòng người?

Bởi vì nó chỉ ra rằng điều harness thực sự thay đổi không phải là một vị trí nào đó, mà là một tiền đề sâu hơn, trước đây gần như không ai nghi ngờ:

Trong lao động số, mặc định phải có một con người đứng ở giữa.

Người đó sẽ phân chia nhiệm vụ,

Người đó sẽ theo dõi tiến độ,

Người đó sẽ đánh giá chất lượng,

Người đó sẽ điều phối việc làm lại,

Người đó sẽ đảm bảo cuối cùng.

Người “mặc định đứng ở giữa” này, có thể gọi là lập trình viên, có thể gọi là PM, có thể gọi là TL, có thể gọi là người phụ trách thiết kế, có thể gọi là QA, cũng có thể gọi là quản lý dự án.

Tên gọi không quan trọng.

Quan trọng là, toàn bộ hệ thống sản xuất số trước đây mặc định không thể thiếu một trung tâm con người như vậy.

Điều mà Harness thực sự tác động đến chính là vị trí trung tâm này.

Nó không phải nói rằng hôm nay lập tức đuổi con người đi, mà đang từng chút chứng minh:

Thực ra một số phân tích có thể được thực hiện theo hệ thống,

Thực ra một số giám sát có thể được thực hiện theo hệ thống,

Thực ra một số nghiệm thu có thể được thực hiện theo hệ thống,

Thực ra một số quay lại và thử lại cũng có thể không cần con người phát hiện trước rồi xử lý.

Khi điều này được chứng minh ngày càng nhiều, vị trí của con người sẽ không ngay lập tức biến mất, nhưng sẽ bắt đầu lùi sâu.

Từ trung tâm mặc định, trở thành can thiệp ngoại lệ;

Từ theo dõi toàn bộ quá trình, trở thành chỉ xử lý các vấn đề bên lề;

Từ chủ sở hữu quy trình, trở thành quan sát viên quy trình.

Đó mới là điều harness thực sự ăn mất.

Không phải lập trình viên.

Không phải quản lý sản phẩm.

Không phải QA.

Mà là giả định sâu hơn đứng sau những vai trò này:

Con người mặc định là trung tâm của quy trình.

Và một khi tiền đề này bắt đầu lỏng lẻo, câu chuyện phía sau sẽ hoàn toàn khác.

Thời đại công cụ, ai sử dụng công cụ giỏi hơn là người chiến thắng.

Thời đại Harness, ai sớm chấp nhận:

Mình không còn tự nhiên đứng ở chính giữa của hệ thống nữa.