Tại sao bạn phải học Kỹ thuật Cơ khí Harness? Phân tích toàn diện 5 sản phẩm, 3 trường phái, 5 nguyên tắc phổ quát

Hệ thống phân tích Harness Engineering 5 sản phẩm, 3 trường phái (OpenAI / Anthropic / ThoughtWorks), 5 nguyên tắc phổ quát, và tại sao "Suy thoái Harness" bắt buộc bạn phải cắt giảm một nửa thiết kế mỗi 6 tháng. Bài viết này xuất phát từ bài viết của @sairahul1 trên X, do Động Quân tổng hợp và biên dịch.
(Trước đó: Giới thiệu về Harness Engineering (Kỹ thuật điều khiển AI): Tiêu chuẩn lập trình mới nhất của OpenAI, giúp bạn dễ dàng đạt Lv.1)
(Bổ sung nền: CEO YC chia sẻ bí quyết AI: Tương lai thuộc về người xây dựng hệ thống lãi kép thông tin)

Mục lục bài viết

Toggle

    1. Định nghĩa về Harness
    1. So sánh như OS
    1. Thay đổi gì vào năm 2026
    1. Tập tin AGENT.md / CLAUDE.md
    1. Danh sách tính năng JSON (Trình theo dõi tiến trình)
    • Tại sao là JSON chứ không phải Markdown?
    1. Quy trình khởi tạo Session
    1. Hợp đồng Sprint (Sprint Contracts)
    • Tại sao quan trọng
    1. Mẫu nhiệm vụ có cấu trúc (Structured Task Templates)
    1. Trường phái của OpenAI: Ưu tiên môi trường
    • Cách họ làm
    • Bằng chứng
    1. Trường phái của Anthropic: Chia "làm" và "xét" ra riêng
    • Giải pháp của họ: 3 agent chuyên trách
    • Kết quả (Thử nghiệm A/B)
    1. Trường phái của ThoughtWorks: Khung 2×2
    • Nhận thức của họ: Phân loại kiểm soát harness qua 2 trục
    • Ma trận 2×2
    1. Nguyên tắc 1: Context thắng Instruction
    1. Nguyên tắc 2: Lập kế hoạch và thực thi phải tách biệt
    1. Nguyên tắc 3: Vòng phản hồi không thể thỏa hiệp
    1. Nguyên tắc 4: Chỉ làm một việc tại một thời điểm
    1. Nguyên tắc 5: Codebase chính là tài liệu
    • Ý nghĩa thực tiễn
    1. Suy thoái Harness (Harness Decay) là có thật
    • Đó chính là Suy thoái Harness
    1. Xây dựng để xóa (Build to Delete)
    1. Thực tế về chi phí
    • Nhưng phần này ít ai đề cập
  • Toàn văn cô đọng
    • Harness là gì
    • 5 sản phẩm harness
    • 3 trường phái
    • 5 nguyên tắc phổ quát
    • Điều kỳ quặc

Tháng 2 năm 2026, OpenAI một nhóm nhỏ đã tạo ra 1 triệu dòng mã sản xuất.

Họ không viết một dòng nào cả.

Là agent AI viết.

Người thiết kế là hệ thống giúp agent đáng tin cậy.

Hệ thống này giờ đã có tên gọi — Harness Engineering.

Trong vài tuần, Anthropic đã phát hành 3 bài báo liên quan. ThoughtWorks tổng hợp thành khung. Philipp Schmid của Hugging Face gọi đó là "Ngành học quan trọng nhất năm 2026".

Trong vòng 90 ngày, một ngành kỹ thuật mới đã hình thành. Và ngoài nhóm hạ tầng AI, hầu như không ai hiểu rõ.

Bài viết này sẽ làm rõ điều đó. Không vòng vo, không thuật ngữ học thuật, chỉ là mô hình tư duy thực sự cần thiết để bạn dùng.

1. Định nghĩa về Harness

Định nghĩa đơn giản nhất của ThoughtWorks:

Agent = Model + Harness

Harness chính là tất cả mọi thứ ngoài mô hình.

  • Ràng buộc agent đi đúng hướng
  • Vòng phản hồi bắt lỗi
  • Tài liệu chỉ rõ agent đang ở đâu
  • Công cụ mà agent có quyền sử dụng

Bỏ harness → một mô hình ngẫu nhiên trong codebase của bạn.

Thêm harness đúng cách → một hệ thống có thể sinh ra mã sản xuất.

Tên gọi này xuất phát từ yên ngựa. Harness là dây cương, yên, hàm thiếc — hướng dẫn một con vật mạnh mẽ nhưng khó đoán theo hướng có ích.

Bạn không biến con ngựa trở nên thông minh hơn, bạn thiết kế bộ trang bị để biến sức mạnh của nó thành hữu dụng.

2. So sánh như OS

Philipp Schmid đưa ra phép so sánh hay nhất: Hãy nghĩ nó như một máy tính.

| Vai trò | | --- | | Tương ứng | | --- | --- | | Model | CPU (tính toán nguyên thủy) | | Context window | RAM (nhớ tạm thời, dễ mất) | | Harness | Hệ điều hành (quản lý CPU, hiển thị gì, khi nào hiển thị) | | Agent | Ứng dụng chạy trên đó |

Mô hình của bạn rất mạnh. Nhưng không có OS quản lý bộ nhớ, lập lịch, thực thi quy tắc — nó chỉ là một mảnh silicon.

Hầu hết mọi người đều chạy ứng dụng "không có hệ điều hành". Vì vậy, agent của họ khi ra đời đã hỏng.

3. Thay đổi gì vào năm 2026

LangChain dùng cùng một mô hình, chạy trên Terminal Bench 2.0 hai lần:

| Harness | | --- | Điểm số | | --- | --- | | Harness cũ | 52.8% | | Harness mới | 66.5% |

Cùng một mô hình. Khác nhau về harness. Chênh lệch 13.7 điểm phần trăm.

Vercel làm ngược lại — cắt giảm 80% công cụ của agent. Kết quả? Tốt hơn, chứ không tệ hơn.

Thực tế đáng khó chịu nhất năm 2026:

  • Agent chưa bao giờ là phần khó nhất
  • Harness mới là phần khó nhất

Nếu năm 2025 là năm chứng minh agent AI có thể viết code, 2026 là năm phát hiện "môi trường" còn quan trọng hơn "mô hình".

4. Tập tin AGENT.md / CLAUDE.md

Sản phẩm harness phổ biến nhất.

Là các file markdown rải rác trong codebase. Agent mỗi lần bắt đầu session sẽ đọc — giống như tài liệu onboarding của nhân viên mới.

Chứa những gì?

  • Context dự án
  • Quy ước lập trình
  • Quyết định kiến trúc
  • Hướng dẫn "chúng tôi làm thế này"
  • Các công việc đang thực hiện

OpenAI gọi nó là AGENT.md. Anthropic gọi là CLAUDE.md. Cursor dùng .cursorrules.

Tên khác, nguyên tắc giống nhau. Mỗi module chính một file. Cập nhật theo tiến trình dự án.

Không có nó: agent mỗi session như mở máy trong bóng tối. Có nó: agent mỗi lần bắt đầu đều mang theo thông tin.

5. Danh sách tính năng JSON (Trình theo dõi tiến trình)

Khi agent làm việc qua nhiều session để xây dựng một ứng dụng, mỗi session đều có context window trống. Nó làm sao biết đã xong phần nào?

Một file JSON.

Mỗi mục ghi:

  • Một tính năng
  • Cách kiểm tra xem đã qua hay chưa
  • Trạng thái Pass / Fail

Session của agent bắt đầu đọc nó — chọn mục Fail ưu tiên cao nhất → thực hiện → đánh dấu Pass → commit → lặp lại.

Tại sao là JSON chứ không phải Markdown?

Anthropic phát hiện: khả năng ghi đè JSON của agent thấp hơn so với Markdown.

Chi tiết nhỏ, nhưng trong cảnh tự vận hành 6 giờ, lại cực kỳ quan trọng.

6. Quy trình khởi tạo Session

Mỗi lần session đều khởi động theo cùng quy trình. Mỗi lần.

7 bước khởi động của Anthropic:

  1. Xác nhận thư mục làm việc
  2. Đọc git log và file tiến trình
  3. Lấy mục cao nhất trong danh sách tính năng chưa hoàn thành
  4. Khởi động server phát triển
  5. Chạy kiểm tra E2E cơ bản
  6. Thực hiện một tính năng
  7. Commit với mô tả rõ ràng, cập nhật tiến trình

Không có quy trình này: agent 20 phút đầu loay hoay xác định trạng thái hiện tại, lặp lại công việc cũ. Có quy trình này: agent bắt đầu đã biết rõ thông tin, làm luôn.

7. Hợp đồng Sprint (Sprint Contracts)

Trước khi viết bất kỳ dòng code nào — hai agent sẽ đàm phán.

Agent đề xuất:

  • Cần làm gì
  • Làm thế nào để xác nhận thành công

Agent xét duyệt:

  • Đề xuất có đầy đủ không?
  • Tiêu chuẩn thành công rõ ràng chưa?

Hai bên đồng ý, mới bắt đầu thực thi.

Là bước duyệt thiết kế. Chỉ khác là cả hai đều là AI.

Tại sao quan trọng

Trong cùng một vòng, agent vừa lập kế hoạch vừa thực thi sẽ cho ra kết quả không đáng tin cậy. "Lập kế hoạch" — dù là AI làm — sẽ nâng cao chất lượng đầu ra rõ rệt.

8. Mẫu nhiệm vụ có cấu trúc (Structured Task Templates)

Trước khi viết code, harness sẽ phân tích codebase thật sự.

Nó tạo ra một bản đồ tác động dựa trên thực tế:

  • Đường dẫn file chính xác (không ảo)
  • Tên symbol tồn tại thực sự
  • Các pattern có thể theo
  • Tiêu chuẩn chấp nhận cụ thể

Sau đó mới bắt đầu thực thi.

Nghe có vẻ hiển nhiên. Nhưng đa số nhóm đều bỏ qua bước này.

Agent đoán cấu trúc thư mục, phát minh API không tồn tại, làm ra thứ không phù hợp với codebase.

Có context thực tế trước rồi mới thực thi → chất lượng output sẽ cao hơn rất nhiều.

9. Trường phái của OpenAI: Ưu tiên môi trường

Đội Codex của OpenAI có vấn đề ngớ ngẩn:

1 triệu dòng mã sản xuất, không viết một dòng nào thủ công.

Trong quy mô đó, không thể review từng dòng mã. Vì vậy họ không làm.

Thay vào đó — họ thiết kế môi trường đến mức để agent từ đầu ra ra "kết quả có thể xét duyệt".

Cách họ làm

  • Quản lý dependency chặt chẽ (Types → Config → Repo → Service → Runtime → UI)
  • Toàn bộ codebase phân tán thành các file AGENT.md
  • Agent trực tiếp tích hợp vào pipeline CI/CD

Triết lý: Thiết kế môi trường. Sau đó để agent chạy.

Bằng chứng

Ứng dụng Sora Android. 4 kỹ sư. 28 ngày. Top 1 trên Play Store. 99.9% không crash.

Codex mỗi tuần xử lý 70% PR nội bộ.

10. Trường phái của Anthropic: Chia "làm" và "xét" riêng

Anthropic gặp vấn đề khác:

Khi họ yêu cầu agent tự đánh giá output của chính mình, nó sẽ tự tin khen ngợi tác phẩm của mình — dù chất lượng rõ ràng trung bình hoặc kém.

Tự đánh giá không thể tin cậy. Agent vừa là học sinh, vừa là thầy, rồi tự cho điểm A toàn tập.

Giải pháp của họ: 3 agent chuyên trách

| Agent | | --- | | Planner | Chuyển prompt 2 câu thành đặc tả sản phẩm đầy đủ | | Generator | Thực thi từng sprint một | | Evaluator | Tự động kiểm thử qua trình duyệt, như người dùng thật thao tác |

Nhận thức: Để "Evaluator độc lập" trở nên kén chọn, dễ hơn nhiều so với khiến "Generator" tự khen chính mình.

Kết quả (Thử nghiệm A/B)

| Cài đặt | | --- | | Chi phí | | Thời gian | | Kết quả | | --- | --- | --- | --- | | Một agent (không harness) | $9 | 20 phút | Ứng dụng lỗi | | Full harness | $200 | 6 giờ | Phần mềm hoạt động + UI tinh xảo |

11. Trường phái của ThoughtWorks: Khung 2×2

ThoughtWorks tiếp cận từ góc độ khác — họ không làm sản phẩm, mà xem 50+ nhóm kỹ thuật thất bại ở cùng điểm nào.

Nhận thức của họ: Phân loại harness qua 2 trục

Trục 1: Khi nào hoạt động?

  • Feedforward = Trước hành động của agent (chỉ dẫn)
  • Feedback = Sau hành động của agent (cảm biến)

Trục 2: Cách hoạt động?

  • Tính toán = Định tính, mili giây (linter, type checker, test suite)
  • Suy luận = Dùng LLM, giây (code review agent, phân tích ý nghĩa)

Ma trận 2×2

| | | --- | | Feedforward (Chỉ dẫn) | | Feedback (Cảm biến) | | --- | --- | --- | | Tính toán | Hệ thống kiểu, linter, quy tắc kiến trúc | Test suite, coverage, mutation test | | Suy luận | Tài liệu spec, mô tả ràng buộc | LLM code reviewer, bộ xác thực hành vi |

Feedforward và feedback không thể dùng riêng lẻ. Cần cả hai.

12. Nguyên tắc 1: Context thắng Instruction

Các nhóm khác nhau, cùng một phát hiện:

  • OpenAI: cung cấp bản đồ, không phải 1,000 trang hướng dẫn
  • Anthropic: danh sách tính năng JSON + file tiến trình, giúp agent luôn biết vị trí
  • Red Hat: trước khi làm nhiệm vụ, phân tích codebase thực tế
  • ThoughtWorks: gọi là "Feedforward"

Hãy đặt agent trong "trạng thái hiện tại của thế giới", liên tục vượt qua việc cung cấp hướng dẫn trừu tượng.

Đặt trong thực tế: dựa vào file thực tế → phù hợp codebase. Từ mô tả mơ hồ → ảo tưởng về API và đường dẫn.

Trước khi agent gõ, hãy đảm bảo nó biết mình đang ở đâu.

13. Nguyên tắc 2: Lập kế hoạch và thực thi phải tách biệt

  • OpenAI: con người thiết kế môi trường, agent thực thi
  • Anthropic: agent Planner chuyên trách chạy trước khi Generator bắt đầu
  • ThoughtWorks: bắt buộc con người duyệt checkpoint giữa quy hoạch và thực thi
  • Red Hat: Giai đoạn 1 (bản đồ tác động) và Giai đoạn 2 (thực thi) có rào cản cứng

Mỗi nhóm đều nhận ra: để agent vừa lập kế hoạch vừa thực thi trong cùng một vòng, kết quả sẽ không đáng tin cậy.

Quá trình lập kế hoạch không nhất thiết do con người làm, nhưng phải là bước riêng biệt, và kết quả phải được duyệt trước khi bắt đầu.

14. Nguyên tắc 3: Vòng phản hồi không thể thỏa hiệp

  • OpenAI: agent tích hợp CI/CD và observability
  • Anthropic: agent Đánh giá chuyên trách + tự động hóa trình duyệt
  • ThoughtWorks: hình thành như "cảm biến", cảnh báo rằng chỉ dựa vào feedforward mãi mãi không thể xác nhận hướng dẫn có hiệu quả hay không

Ba trường phái cùng một nguyên tắc, ba cách làm:

| Trường phái | | --- | | Nguồn feedback | | --- | --- | | OpenAI | Kiểm thử tự động + CI | | Anthropic | LLM khác | | ThoughtWorks | Kết hợp cả hai |

Họ khác nhau về "ai" cung cấp feedback. Nhưng không có ai tranh cãi về việc "cần" feedback.

Không harness nào không có feedback, chỉ là prompt cộng thêm bước kiểm tra.

15. Nguyên tắc 4: Chỉ làm một việc tại một thời điểm

  • OpenAI: phân nhỏ mục tiêu thành các phần nhỏ hơn, ưu tiên sâu
  • Anthropic: bắt buộc "mỗi sprint chỉ làm một feature", xong rồi commit
  • ThoughtWorks: theo chu kỳ sống theo giai đoạn (pre-integration → post-integration → continuous monitoring)

Làm quá nhiều agent cùng lúc sẽ gây ra:

  • Hết context
  • Mất tính liên tục
  • Đành bỏ yêu cầu một cách im lặng

Quy trình của Anthropic: đọc tiến trình → chọn 1 feature → thực thi → commit → lặp lại.

"Chủ nghĩa tiến bộ bắt buộc" là điểm chung của mọi harness thành công.

16. Nguyên tắc 5: Codebase chính là tài liệu

  • OpenAI: AGENT.md tích hợp trong repo
  • Anthropic: danh sách tính năng, file tiến trình, lịch sử git là cơ chế liên tục của agent
  • ThoughtWorks: đánh giá "harnessability" — khả năng đọc hiểu code của hệ thống

Chẳng ai sẽ duy trì một kho kiến thức riêng cho agent. Repo chính là sự thật duy nhất.

Nếu một quy ước, ràng buộc, quyết định kiến trúc không nằm trong codebase → agent sẽ không biết.

Ý nghĩa thực tiễn

  • Nhóm sẵn sàng đầu tư vào tổ chức code, miễn phí nhận được hiệu suất agent tốt hơn
  • Repo bẩn + AI agent = hỗn loạn quy mô lớn

17. Suy thoái Harness (Harness Decay) là có thật

Khi Anthropic nâng cấp từ Opus 4.5 lên 4.6 — Phân chia sprint (đã từng cần thiết) trở thành gánh nặng.

Khả năng lập kế hoạch của mô hình tiến bộ, khiến phần này trở nên thừa.

Trong tháng 3, các thành phần harness còn đang gánh nặng, đến tháng 4 đã thành overhead.

Sau đó, Opus 4.7 ra mắt — mô hình bắt đầu tự xác nhận output của chính nó, vai trò của agent Đánh giá thu hẹp lại.

Đó chính là Suy thoái Harness

Các thành phần trong harness đều giả định "mô hình không thể làm được gì". Khi mô hình tiến bộ → những giả định đó trở nên lỗi thời → các thành phần trở thành overhead.

| Phiên bản mô hình | | --- | | Tình trạng harness | | --- | --- | | Opus 4.5 | Phân chia sprint + đánh giá mỗi sprint | | Opus 4.6 | Không phân chia sprint + đánh giá đơn lẻ (tiết kiệm 38% chi phí) | | Opus 4.7 | Mô hình tự xác nhận → vai trò evaluator thu hẹp lại |

18. Xây dựng để xóa (Build to Delete)

Philipp Schmid đề xuất: "Xây dựng để xóa."

Khi thiết kế từng thành phần harness, hãy thiết kế để có thể loại bỏ.

Thường xuyên kiểm tra từng thành phần — tắt nó đi, xem chất lượng output có thay đổi không. Không thay đổi → xóa bỏ.

| Nhóm | | --- | | Trong vòng 6 tháng tái cấu trúc | | --- | --- | | Manus | Tái cấu trúc harness 5 lần | | LangChain | Tái cấu trúc 3 lần trong 1 năm | | Vercel | Cắt bỏ 80% công cụ → hiệu suất tốt hơn |

Đây không phải dấu hiệu của dự án xấu. Mà là hệ quả tự nhiên của việc "xây dựng trên mô hình tiến bộ nhanh".

Các thành phần harness chết đi mỗi lần chạy đều tiêu tốn token, không đóng góp chất lượng — hoàn toàn lãng phí.

19. Thực tế về chi phí

Số liệu trung thực từ thử nghiệm A/B của Anthropic:

| Cài đặt | | --- | | Chi phí | | Thời gian | | Kết quả | | --- | --- | --- | --- | | Một agent (không harness) | $9 | 20 phút | Ứng dụng lỗi, core hỏng | | Full harness (Opus 4.5) | $200 | 6 giờ | Phần mềm hoạt động, UI tinh xảo, đúng chức năng |

22 lần chi phí — để ra một sản phẩm thực sự chạy được, chứ không phải demo chỉ chụp màn hình.

Có đáng không? Tùy vào mức độ thiệt hại của bản release lỗi đối với đội của bạn.

Nhưng phần này ít ai đề cập

Hệ thống harness + mô hình là một quá trình tiến hóa.

$200 harness, nâng cấp mô hình lên phiên bản mới, sẽ giảm còn $124.

| Đường xu hướng | | --- | | Mô hình tốt hơn = harness đơn giản hơn = chạy nhanh hơn = ra kết quả nhanh hơn |

Người chiến thắng 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ỏ chúng khi chúng không còn sinh lợi.

Tóm tắt toàn bài

Harness là gì

  1. Agent = Model + Harness
  2. Model = CPU, Harness = OS
  3. Cùng mô hình, harness tốt hơn → +13% hiệu suất

5 sản phẩm harness

  1. CLAUDE.md / AGENT.md — tài liệu onboarding của agent
  2. Danh sách tính năng JSON — theo dõi tiến trình + bộ kiểm thử tích hợp
  3. Quy trình khởi động Session — 7 bước giống nhau
  4. Hợp đồng Sprint — đàm phán trước khi agent viết code
  5. Mẫu nhiệm vụ có cấu trúc — đường dẫn thực tế, pattern thực tế

3 trường phái

  1. OpenAI: thiết kế môi trường, để agent chạy
  2. Anthropic: chia "làm" và "xét" riêng
  3. ThoughtWorks: khung 2×2 feedforward/feedback

5 nguyên tắc phổ quát

  1. Context thắng instruction
  2. Lập kế hoạch và thực thi phải tách biệt
  3. Vòng phản hồi không thể thỏa hiệp
  4. Chỉ làm một việc tại một thời điểm
  5. Codebase chính là tài liệu

Điều kỳ quặc

  1. Suy thoái Harness — cái còn hiệu quả tháng trước, tháng này đã giảm
  2. Xây dựng để xóa — kiểm tra và loại bỏ thành phần chết
  3. Thực tế chi phí — mô hình tốt hơn = harness đơn giản hơn = chi phí thấp hơn

Người chiến thắng 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ỏ khi không còn lợi nhuận.

Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • Bình luận
  • Đăng lại
  • Retweed
Bình luận
Thêm một bình luận
Thêm một bình luận
Không có bình luận
  • Đã ghim