Sau khi bài viết liên quan của AI Times về 'lập luận vô dụng hóa harness của các công ty công nghệ lớn' được đăng tải, nhiều nhà lãnh đạo công nghệ đã trao đổi ý kiến về vấn đề này. Theo báo cáo, sau Google, OpenAI cũng đã phát biểu theo hướng rằng mô hình thế hệ tiếp theo có thể hấp thụ một phần đáng kể của các chức năng harness hiện tại.
Bài viết này cũng là sự bổ sung vào cuộc thảo luận đó. Nói thẳng từ kết luận, tôi đồng ý với triển vọng rằng hầu hết các harness sẽ trở nên vô dụng. Tôi cũng đã viết trong bài đăng Giải thích đầy đủ về Harness Engineering — Nguồn gốc, khái niệm, khoảng cách và tương lai tất cả một lần rằng các harness phức tạp được tạo để bù đắp các điểm yếu của mô hình sẽ nhanh chóng bị thay thế khi mô hình cải thiện.
Tuy nhiên, nếu chúng ta mở rộng điều này để lập luận rằng toàn bộ harness sẽ sớm trở nên không cần thiết, thì chúng ta sẽ bỏ lỡ bản chất thực sự của harness. Vấn đề về mô hình hấp thụ chức năng khác với vấn đề về con người và tổ chức quản lý trách nhiệm khi giao việc cho AI.
Trước tiên, chúng ta cần xem xét cách các từ khóa công nghệ được lưu thông
Tuy nhiên, trước tiên, các từ khóa công nghệ trong nước đã được tiêu thụ theo những cách khác biệt so với quốc tế và có nghĩa khác nhau, vì vậy chúng tôi đã thực hiện xác minh trước tiên. Lần này, chúng ta cũng cần phân biệt giữa các phát biểu ban đầu, các thảo luận công nghệ thực tế và các khung hình được tạo ra trong nước.
Dưới đây là so sánh tiêu thụ từ khóa harness engineering giữa quốc tế và Hàn Quốc từ bài đăng Giải thích đầy đủ về Harness Engineering — Nguồn gốc, khái niệm, khoảng cách và tương lai tất cả một lần.
| Phân loại | Quốc tế | Hàn Quốc |
|---|---|---|
| Lãnh đạo thảo luận | Trung tâm của phân tích công khai từ các kỹ sư và thực hành viên. Các bài viết và trường hợp từ các thực hành viên như Hashimoto và Martin Fowler tạo thành trục. | Thảo luận nhanh chóng lan truyền từ các bài viết, tóm tắt và giải thích từ các nền tảng phương tiện truyền thông, giáo dục và một số influencer công nghệ. |
| Kênh chính | GitHub, blog công nghệ, X (Twitter), nghiên cứu trường hợp chính thức | YouTube, Brunch, blog, bài viết tin tức |
| Tài liệu nâng cao | Như các trường hợp nghiên cứu của OpenAI và phân tích của Martin Fowler, chúng ta xem xét cùng nhau tài liệu gốc, mã và kinh nghiệm vận hành. | Việc phân phối trọng tâm là dịch thuật và tóm tắt, và sản xuất trường hợp thứ nhất tương đối ít hơn. |
| Chia sẻ sử dụng thực tế | Các trường hợp xử lý hơn 1.000 PR mỗi tuần từ Stripe, các công ty như Salesforce công khai số liệu vận hành và kinh nghiệm thất bại. | Một số công ty tiên phong như Toss và Channel Talk chia sẻ kinh nghiệm sử dụng thực tế, nhưng vẫn còn quá sớm để tổng quát hóa thành các trường hợp phổ biến trong toàn ngành. |
Điểm cần cẩn trọng khi giải thích mở rộng lần này là, không có bằng chứng rõ ràng rằng "harness is dead" hoặc "harness is useless" là các khẩu hiệu được sử dụng rộng rãi trong cộng đồng nói tiếng Anh. Thảo luận gần hơn là về khả năng sử dụng công cụ của mô hình được cải thiện, một số giàn giáo được hấp thụ vào mô hình hoặc nền tảng, và vòng đời của các lớp điều phối phức tạp được xây dựng thủ công có thể được rút ngắn. Phát biểu của Phó Chủ tịch Noam Brown cũng không phải là điều tôi đã xác minh trực tiếp từ nguồn gốc, mà là những gì tôi tiếp xúc qua báo cáo quốc nội và quốc tế. Vì vậy, tôi sẽ xem xét chính khung hình 'lập luận vô dụng hóa harness' đã nhanh chóng được cố định trong nước.
Harness sẽ mất đi và harness cần được giữ lại là khác nhau
Harness sẽ mất đi là rõ ràng. Những cách mà các lời nhắc phải được chia nhỏ thành nhiều giai đoạn, các quy tắc tạm thời để buộc vòng qua các lỗi của một mô hình cụ thể, các quy trình công việc nông cạn nơi thứ tự gọi công cụ được cố định cứng nhắc bởi con người có thể được hấp thụ khi mô hình được cải thiện. Các harness như vậy sẽ biến mất là đúng.
Tuy nhiên, giống như chính xác hóa của Dong-Soo Lee, Giám đốc điều hành A2Sys, tôi không nghĩ rằng việc mở rộng điều này cho tất cả các harness là an toàn. Tóm lại, nó như sau:
- Harness luồng công việc và lời nhắc có thể được hấp thụ bởi mô hình. Tôi đồng ý với điều đó.
- Harness thực thi công cụ xử lý quyền, phê duyệt và phục hồi lỗi. Điều này thực sự là harness sẽ mất đi sao?
- Harness thời gian chạy, bộ nhớ và cơ sở hạ tầng xử lý ngữ cảnh, bộ đệm, định tuyến mô hình, chi phí, độ trễ và nhật ký kiểm toán. Tôi cũng cảm thấy khó để xem đây là harness sẽ biến mất.
Cốt lõi của harness mà tôi đã đề cập từ chương 7 đến 11 trong 『Harness Engineering: Re:Start from Zero - AI Software Engineering』 cũng nằm ở đây. Hợp đồng xác định phạm vi được phép, cấu trúc và cách ly thu hẹp phạm vi thay đổi, và khả năng truy vết cũng như xác minh liên kết mục tiêu gốc và kết quả thực tế. Đo lường và vận hành quản lý chi phí, quyền, sự cố và phục hồi. Harness engineering trong phạm vi này không phải là phần có thể được giải quyết bằng cách mô hình cải thiện.
Mặt khác, lập luận rằng harness, vòng lặp, và kỹ thuật lời nhắc đều là heuristic của con người cũng là đúng. Tất cả các phương pháp đều bắt đầu từ heuristic. Các loại, bài kiểm tra, CI, review mã, tách biệt quyền đều là các phương pháp được con người tạo ra để đối phó với các hệ thống phức tạp. Nhưng điều thực sự quan trọng ở đây là liệu chúng ta có thể giao tính minh bạch và trách nhiệm cho mô hình flagship không? Nếu chúng tôi giao việc cho AI, thì chính AI đó không thể tự kiểm chứng liệu nó có thực hiện công việc đúng theo ý định hay không, và không thể tự đảm bảo rằng nó không gây ra sự cố vượt quá phạm vi trách nhiệm. Tất nhiên, có thể có một AI giám sát và sửa chữa điều này, nhưng khi đó, điều đó sẽ trở thành một harness.
Tôi đã viết vị trí này như thế này trong một bình luận về bài đăng của Giáo sư Sang-ki Han.
Nó có vẻ phụ thuộc vào cách chúng ta xem harness engineering. Miễn là có ý định của tổ chức và nhà phát triển, thật khó để nó biến mất.
Khi mô hình trở nên thông minh hơn, khả năng AI làm những điều vô liên quan một cách tuyệt vời cũng tăng lên. Do đó, harness không phải là một thiết bị hiệu chỉnh điểm yếu của mô hình, mà là một thiết bị vận hành cố định hướng và trách nhiệm.
Trong vận hành thực tế, ranh giới trách nhiệm được đưa lên trước khả năng của mô hình
Nextain tiến hành công việc với các công ty nhận yêu cầu phát triển thông qua Discord. Và hôm nay, tôi đã đưa một agent của Claude Code, người đã giải quyết các vấn đề cụ thể, vào đây. Một agent Nextain tham gia channel Discord (thực ra là Claude Code được chạy trên máy chủ) đọc channel Discord và cung cấp câu trả lời.
Một nhân viên điều hành không phải nhà phát triển trong channel đó đã chuyển giao kết quả kiểm tra và những thiếu sót cũng như yêu cầu. Và khi xử lý những gì có thể được xử lý ở đây, nếu cần phải sửa đổi các triển khai quan trọng hoặc các tài nguyên không nên được chạm vào, nó sẽ yêu cầu sự phê duyệt của tôi để xem có được phép hay không.
Ngoài ra, ban đầu khi được đưa vào, tôi gặp phải tình trạng nhân viên đó chán nản vì nó nghe yêu cầu và ngay lập tức bắt đầu công việc, vì vậy tôi đã chỉ thị quy trình công việc. Nghe yêu cầu rồi xác nhận đã nhận, tiến hành phân tích, lập kế hoạch, sau đó báo cáo lại kế hoạch trên channel Discord và tiến hành công việc. Và cuối cùng, khi hoàn thành công việc, hãy nộp báo cáo cuối cùng, và nếu có vấn đề nào phát sinh giữa chừng, hãy gọi tôi (nhà lãnh đạo phát triển) để quyết định cần thiết là hỏi trên Discord.
Cốt lõi của harness này là quy trình phát triển của Nextain và quyền hạn của từng thành viên. Nếu đây là một mô hình flagship, liệu nó có tự làm công việc theo cách tốt nhất không? Phương pháp tốt nhất có thực sự chỉ là một cách không? Tính nhất quán của quy trình tổ chức và công việc cuối cùng là một harness. Ranh giới trách nhiệm này độc lập với khả năng của mô hình. Khi mô hình có thể làm được nhiều công việc hơn, phân biệt rõ ràng hơn giữa những gì được phép làm và nơi cần dừng lại.
Vấn đề hiện tại là drifting và chi phí
Các nhà phát triển sử dụng Codex và Claude trong công việc thực tế vẫn phải đối mặt với vấn đề drifting. Ngay cả khi thu hẹp mục tiêu, công việc vẫn chảy sang những hướng khác, thực hiện những thay đổi không được phép, thay đổi bài kiểm tra để nó vượt qua, và bỏ lỡ ranh giới quyền vận hành. Khi mô hình trở nên tinh tế hơn, vấn đề này có thể được ẩn giấu một cách mịn màng hơn.
Lúc này, câu trả lời "chỉ cần chạy nhiều lần hơn" là có thể cho các công ty công nghệ lớn. Chúng có thể tăng thời gian suy luận, tạo ra nhiều ứng cử viên hơn, loại bỏ các đường dẫn thất bại và thêm xác minh bên ngoài. Tuy nhiên, các nhà phát triển công việc thực tế và các startups nhỏ phải tiết kiệm từng đồng không thể làm được điều đó. Tình huống của các công ty Hàn Quốc cũng tương tự như vậy.
Trong bình luận với Giáo sư Sang-ki Han được liên kết ở trên, "hiệu suất chi phí tổng token" được nhắc đến bởi Ha Jung-woo, cựu Cố vấn Trưởng Ban lên kế hoạch tương lai AI, chính là tiêu chí này. Harness không phải là một thiết bị từ chối mô hình flagship. Đó là một thiết bị kiểm soát chi phí để chia riêng việc sử dụng mô hình đắt tiền thực sự chỉ khi cần thiết, và phân tách công việc lặp lại thành các mô hình nhỏ, công cụ cục bộ, tập lệnh và kiểm tra xác định luận.
Thành tích gần đây của OpenAI liên quan đến toán học cũng cần được chia thành hai thời điểm. Tôi đánh giá cao thành tích đầu tiên liên quan đến phản ví dụ của bài toán khoảng cách đơn vị Erdős plane là khả năng tìm thấy kết nối toán học khác với cách tiếp cận hiện tại. Đó là trường hợp cho thấy khả năng khám phá mới mà chỉ AI mới có thể tạo ra.
Mặt khác, máy tính thời gian kiểm tra được nhấn mạnh hơn sau đó là hướng đầu tư nhiều tính toán và tìm kiếm ứng cử viên, xác minh và lặp lại hơn tại thời điểm suy luận. Đây cũng là một công nghệ quan trọng. Tuy nhiên, nếu chúng ta chỉ nói về nó như một sự cải thiện trí thông minh thuần túy của một mô hình, thì cấu trúc chi phí sẽ biến mất. Nó là một công nghệ lượng lớn, nhưng nó đặc biệt thuận lợi cho các công ty công nghệ lớn.
Harness là một tuyến phòng chống chi phí và dữ liệu
"Mô hình sẽ nuốt chửng harness" là một tuyên bố kích thích. Tuy nhiên, câu hỏi về ai sử dụng mô hình đó và với chi phí bao nhiêu là một vấn đề riêng biệt. Khi mô hình hấp thụ nhiều chức năng hơn, mã của người dùng có thể trở nên đơn giản hơn. Đồng thời, nó cũng có thể trở nên phụ thuộc vào các lệnh gọi mô hình nặng hơn và đắt tiền hơn. Độ phức tạp không biến mất, thay vào đó nó được chuyển từ nơi làm việc của người dùng đến lớp tính phí của nhà cung cấp mô hình.
Dữ liệu cũng vậy. Để một agent thực sự trở nên hữu ích, nó cần phải xem tài liệu, mã, lịch, email, nhật ký vận hành, lịch sử sự cố, luồng phê duyệt và dữ liệu khách hàng. Khi agent trở thành nơi làm việc, toàn bộ công việc của người dùng trở thành đầu vào.
Một harness tốt chỉ gửi ngữ cảnh cần thiết đến mô hình bên ngoài và để lại phần còn lại trong nơi làm việc của người dùng. Nó định tuyến các mô hình, tái sử dụng bộ đệm, phân tách quyền và thêm xác minh có thể tái tạo. Đó là lý do tại sao harness là một tuyến phòng chống chi phí và một tuyến phòng chống dữ liệu.
Từ quan điểm này, cũng có khả năng các công ty mô hình toàn cầu có thể cảm thấy khó chịu với một harness phía người dùng mạnh. Nếu người dùng xử lý trước tiên với các mô hình nhỏ và công cụ cục bộ, và chỉ gọi flagship khi cần thiết, thì số lượng lệnh gọi và ngữ cảnh được truyền sẽ giảm. Đó không phải là suy luận, mà là một mối quan tâm về lợi ích mà chúng ta nên xem xét một cách tự nhiên trong cấu trúc công nghiệp nơi chi phí phát triển mô hình, suy luận, GPU và điện năng tăng lên.
OpenAI và Anthropic nằm ở tuyến đầu của cuộc cạnh tranh harness thông qua Codex và Claude Code. Mặt khác, Google vừa là một công ty mô hình vừa là một công ty dịch vụ đám mây. Không thể nói rằng mỗi công ty có chính xác cùng một tập hợp lợi ích, nhưng lý do tại sao cuộc tranh luận này rất khó nghe như một dự đoán công nghệ thuần túy là rõ ràng. Một harness tốt giảm bớt "mong muốn của các công ty công nghệ lớn muốn chuyển nơi làm việc đến mô hình và thu thập dữ liệu" và "giảm sự phụ thuộc vào việc sử dụng flagship".
Vòng lặp không phải là giá trị mặc định thế hệ tiếp theo
Vòng lặp cũng tương tự. Tôi đang sử dụng vòng lặp, nhưng tôi nghĩ rằng đối với hầu hết các nhiệm vụ, không sử dụng vòng lặp là lựa chọn đúng. Nếu đây là công việc mà có thể kỳ vọng kết quả thích hợp ngay cả khi giao cho một nhà phát triển bình thường, thì sử dụng một mô hình tốt một lần một cách chính xác có thể rẻ hơn và nhanh hơn. Một cách bất ngờ, vòng lặp chỉ hiệu quả trong những trường hợp hẹp.
Thứ nhất là nghiên cứu và phát triển. Đó là công việc không có câu trả lời đúng, giả thuyết thay đổi dựa trên kết quả thực nghiệm, và thử nghiệm tiếp theo phải thay đổi chủ động dựa trên kết quả thử nghiệm trước đó. Nghiên cứu âm thanh và ca hát được tiến hành bên trong là như vậy. Trong trường hợp này, kết quả thử nghiệm và toàn bộ dữ liệu được xem xét bởi nhiều AI, tính liên tục với các thử nghiệm hiện tại, liệu có drifting hay không, và sự cần thiết của chu kỳ tiếp theo được xác định. Tiêu chí hoàn thành không phải là kết quả hợp lý, mà là quyết định rằng chỉ số không tăng thêm nữa. Khi mục tiêu là hội tụ của sự khám phá, vòng lặp là đúng.
Thứ hai là khi sử dụng các mô hình nhỏ trong môi trường hạn chế. Các LLM nhỏ có xu hướng thu hẹp mục tiêu và dừng lại ở "mức độ này là đủ". Tuy nhiên, trong trường hợp này, những gì cần thiết là một thiết bị giúp khóa mục tiêu và điều kiện kết thúc hơn là một vòng lặp dài. Nó gần với chức năng goal của Claude Code hơn là một vòng lặp, nó là một harness. Nếu bạn tràn ngập vòng lặp trong các tác vụ hàng ngày của người dùng bình thường, nó sẽ lãng phí chi phí. Vòng lặp được sử dụng để hội tụ của sự khám phá, và harness được sử dụng để cố định mục tiêu và trách nhiệm. Hai cái không phải là mối quan hệ thay thế.
Naia muốn giữ nơi làm việc ở phía người dùng
Naia không từ chối các mô hình flagship. Chúng tôi có ý định sử dụng mô hình flagship đám mây một cách triệt để trong phát triển. Các mô hình tốt phải được sử dụng.
Tuy nhiên, chúng tôi không có ý định giao tất cả nơi làm việc và dữ liệu cho các nền tảng công ty công nghệ lớn. Những gì Naia hướng tới là sử dụng kết hợp các mô hình cục bộ, P2P, open-weight, các mô hình nhỏ, kiểm tra xác định luận, và harness quyền rõ ràng. Các mô hình flagship đắt tiền được sử dụng cho các quyết định cần thiết, nhưng nơi làm việc cơ bản cần được giữ ở tay người dùng.
Từ quan điểm này, sự phát triển của các mô hình open-weight như DeepSeek, Qwen, Kimi, và GLM là quan trọng. Có thể kết hợp các mô hình tùy theo mục đích, bảo vệ dữ liệu cục bộ, và gọi flagship đóng kín chỉ khi cần thiết. Trong Hàn Quốc, chiến lược mô hình độc lập của các công ty như Upstage và Naver cũng có ý nghĩa trong dòng chảy này. Thay vì theo dõi trực tiếp các flagship của các công ty công nghệ lớn toàn cầu, một con đường giúp kết hợp tốt hơn open-weight, các mô hình độc lập, harness chuyên biệt và bối cảnh công việc trong nước có thể thực tế hơn.
Các mô hình có thể được mượn. Tuy nhiên, không cần phải mượn cả nơi làm việc và dữ liệu.
Kết luận: Điều cần thiết hơn lập luận vô dụng hóa là thảo luận về mức độ kỹ thuật
Các harness sẽ biến mất sẽ biến mất. Các chức năng mà mô hình sẽ hấp thụ cũng sẽ tăng lên. Không có lý do để phủ nhận điểm này. Tuy nhiên, tôi không nghĩ rằng các chức năng được hấp thụ bởi mô hình, hệ thống thực thi cố định ý định tổ chức và trách nhiệm, và hệ thống vận hành giữ ranh giới chi phí và dữ liệu sẽ biến mất. Miễn là đối tượng giao việc cho AI là con người và đối tượng chịu trách nhiệm về kết quả cũng là con người, thì hợp đồng, cấu trúc, khả năng truy vết, xác minh và vận hành sẽ không biến mất.
Bây giờ, tôi hy vọng chúng ta có thể bỏ qua những cuộc tranh luận từ khóa như harness đã chết hay sống sót. Tôi hy vọng những thảo luận trung tâm về công nghệ thực sự tiếp theo như việc bao gồm gì vào mô hình, những gì để lại dưới sự kiểm soát của người dùng và tổ chức, cách xác minh và đảo ngược drifting, và ai sẽ chịu chi phí token và sự tiếp xúc dữ liệu sẽ được tiến hành.
Tham khảo và nguồn gốc
Bài viết và sách của tôi
- 『Harness Engineering: Re:Start from Zero - AI Software Engineering』
- 「Giải thích đầy đủ về Harness Engineering — Nguồn gốc, khái niệm, khoảng cách và tương lai tất cả một lần」
- 「Thông báo phát hành Harness Engineering」
Tính cơ bản trực tiếp của cuộc thảo luận này
- AI Times, "Sau Google, OpenAI cũng 'lập luận vô dụng hóa harness'... Các mô hình thế hệ tiếp theo sẽ hấp thụ chức năng"
- AI Times, "[25 tháng 6] 'Mô hình sẽ nuốt chửng harness'..."
- Bài đăng Facebook của Giáo sư Sang-ki Han và thảo luận bình luận
- Dong-Soo Lee, CEO A2Sys, "Lập luận vô dụng hóa Harness? Nó nửa đúng và nửa sai"
Tài liệu gốc và kỹ thuật
- OpenAI, "Learning to Reason with LLMs"
- OpenAI, "An OpenAI model has disproved a central conjecture in discrete geometry"
- OpenAI, "Introducing Codex"
- OpenAI, "Introducing OpenAI o3 and o4-mini"
- Google, "Gemini 2.0: our new AI model for the agentic era"
- "The Interplay of Harness Design and Post-Training in LLM Agents"
- "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
- "AutoHarness"
