Thắt chặt Harness, béo Skill: Nguồn gốc thực sự của năng suất AI gấp 100 lần

Tiêu đề gốc: Thin Harness, Fat Skills
Tác giả gốc: Garry Tan
Dịch: Peggy, BlockBeats

Tác giả gốc: Luật động BlockBeats

Nguồn gốc bài viết:

Chuyển ngữ: Mars Finance

Lời người biên tập: Khi “mô hình mạnh hơn” trở thành câu trả lời mặc định của ngành, bài viết này đưa ra một đánh giá khác: Không phải mô hình thực sự tạo ra sự khác biệt gấp 10, 100 hoặc thậm chí 1000 lần về năng suất, mà chính là toàn bộ hệ thống thiết kế xung quanh mô hình đó.

Tác giả bài viết Garry Tan, hiện là Chủ tịch kiêm CEO của Y Combinator, đã lâu năm nghiên cứu về AI và hệ sinh thái khởi nghiệp sơ khai. Ông đề xuất khung “fat skills + thin harness”, phân tích ứng dụng AI thành các thành phần then chốt như kỹ năng, khung vận hành, định tuyến ngữ cảnh, phân chia nhiệm vụ và nén kiến thức.

Trong hệ thống này, mô hình không còn là toàn bộ năng lực nữa, mà chỉ là đơn vị thực thi trong hệ thống; thực sự quyết định chất lượng đầu ra là cách bạn tổ chức ngữ cảnh, tích lũy quy trình, và cách phân định ranh giới giữa “đánh giá” và “tính toán”.

Quan trọng hơn, phương pháp này không chỉ dừng lại ở lý thuyết mà đã được chứng thực trong thực tế: đối mặt với hàng nghìn nhà sáng lập với các nhiệm vụ xử lý và phù hợp dữ liệu, hệ thống qua vòng “đọc—điều chỉnh—đánh giá—viết lại” đã đạt khả năng gần như phân tích viên con người, đồng thời liên tục tự tối ưu mà không cần viết lại mã. Hệ thống “học hỏi” này biến AI từ công cụ dùng một lần thành hạ tầng có khả năng cộng lợi nhuận kép.

Từ đó, lời nhắc nhở cốt lõi của bài viết cũng trở nên rõ ràng: Trong kỷ nguyên AI, chênh lệch về hiệu quả không còn phụ thuộc vào việc bạn có dùng mô hình tiên tiến nhất hay không, mà là bạn có xây dựng được hệ thống có thể liên tục tích lũy năng lực, tự tiến hóa hay không.

Dưới đây là nội dung bài viết gốc:

Steve Yegge nói rằng, người dùng AI để lập trình “hiệu quả gấp 10 đến 100 lần những kỹ sư viết mã chỉ bằng con trỏ và công cụ chat, khoảng gấp 1000 lần Google engineers năm 2005.”

Điều này không phải là nói quá. Tôi đã chứng kiến và trải nghiệm trực tiếp. Nhưng khi nghe về sự chênh lệch này, nhiều người thường quy cho hướng sai: mô hình mạnh hơn, Claude thông minh hơn, nhiều tham số hơn.

Thực tế, người nâng cao hiệu suất gấp 2 lần và gấp 100 lần đều dùng cùng một bộ mô hình. Sự khác biệt không nằm ở “trí tuệ”, mà ở “kiến trúc”, và kiến trúc này đơn giản đến mức có thể ghi trên một tấm thẻ.

Harness (khung vận hành) mới là sản phẩm thực sự.

Ngày 31 tháng 3 năm 2026, Anthropic bất ngờ phát hành toàn bộ mã nguồn của Claude Code lên npm—tổng cộng 512,000 dòng. Tôi đã đọc qua một lượt. Điều này xác nhận điều tôi luôn nói trong YC: bí mật thực sự không nằm ở mô hình, mà ở “lớp bao bọc mô hình đó”.

Ngữ cảnh kho mã nguồn thời gian thực, bộ đệm Prompt, công cụ thiết kế cho nhiệm vụ cụ thể, nén tối đa ngữ cảnh dư thừa, ghi nhớ theo cấu trúc, các sub-agent chạy song song—tất cả đều không làm mô hình trở nên thông minh hơn. Nhưng chúng có thể cung cấp “ngữ cảnh đúng” cho mô hình “đúng lúc”, đồng thời tránh bị nhiễu bởi thông tin không liên quan.

Lớp “bao bọc” này gọi là harness (khung vận hành). Và câu hỏi thực sự mà các nhà xây dựng AI nên đặt ra là: Những gì nên để vào harness, những gì nên để ra ngoài?

Câu hỏi này có câu trả lời rất cụ thể—tôi gọi đó là: thin harness (khung mỏng), fat skills (kỹ năng dày).

Năm định nghĩa

Bottleneck (điểm nghẽn) chưa bao giờ nằm ở trí tuệ của mô hình. Thực tế, mô hình đã biết cách suy luận, tổng hợp thông tin, viết mã từ lâu rồi.

Chúng thất bại vì không hiểu dữ liệu của bạn—schema của bạn, quy ước của bạn, hình dạng cụ thể của vấn đề. Và năm định nghĩa dưới đây chính là để giải quyết vấn đề này.

1. Skill file (tập tin kỹ năng)

Tập tin kỹ năng là một tài liệu markdown có thể tái sử dụng, dùng để dạy mô hình “làm thế nào để làm một việc”. Lưu ý, không phải là nói cho nó “cần làm gì”—phần đó do người dùng cung cấp. Tập tin kỹ năng cung cấp quy trình.

Điểm quan trọng mà nhiều người bỏ qua là: tập tin kỹ năng giống như một lần gọi phương thức. Nó có thể nhận tham số. Bạn có thể gọi nó với các tham số khác nhau. Cùng một quy trình, vì truyền tham số khác nhau, sẽ thể hiện khả năng khác biệt hoàn toàn.

Ví dụ, có một kỹ năng gọi là /investigate. Nó gồm bảy bước: xác định phạm vi dữ liệu, xây dựng dòng thời gian, phân biệt diarize từng tài liệu, tổng hợp, tranh luận hai chiều, trích dẫn nguồn. Nó nhận ba tham số: TARGET, QUESTION và DATASET.

Nếu bạn chỉ định nó cho một nhà khoa học an toàn và 2,1 triệu email chứng cứ, nó sẽ biến thành một nhà phân tích nghiên cứu y học, đánh giá xem một người tố giác có bị đàn áp hay không.

Nếu bạn chỉ định nó cho một công ty vỏ và hồ sơ báo cáo của FEC, nó sẽ trở thành một điều tra pháp lý, truy tìm các khoản đóng góp chính trị phối hợp.

Vẫn là cùng một kỹ năng. Vẫn bảy bước như cũ. Vẫn cùng một file markdown. Mô tả kỹ năng là một quy trình đánh giá, còn thực tế đưa vào thế giới thực là các tham số truyền vào khi gọi.

Đây không phải là prompt engineering, mà là thiết kế phần mềm: chỉ khác là dùng markdown như ngôn ngữ lập trình, dùng khả năng đánh giá của con người làm môi trường chạy. Thực tế, markdown còn phù hợp hơn mã nguồn cứng nhắc vì nó mô tả quy trình, đánh giá và ngữ cảnh—đúng là ngôn ngữ mà mô hình “hiểu” nhất.

2. Harness (khung vận hành)

Harness chính là lớp chương trình điều khiển hoạt động của LLM. Nó chỉ làm bốn việc: chạy vòng lặp cho mô hình, đọc ghi file của bạn, quản lý ngữ cảnh, và thực thi các ràng buộc an toàn.

Chỉ vậy thôi. Đó là “thin” (mỏng).

Mô hình đối lập là: harness dày, skills mỏng.

Bạn chắc chắn đã gặp kiểu này: hơn 40 công cụ định nghĩa, phần mô tả chiếm hết một nửa cửa sổ ngữ cảnh; một “God-tool” toàn năng, chạy một lượt MCP mất 2-5 giây; hoặc biến mỗi endpoint của REST API thành một công cụ riêng biệt. Kết quả là, token dùng gấp 3 lần, độ trễ gấp 3 lần, tỷ lệ thất bại gấp 3 lần.

Cách lý tưởng là dùng các công cụ sinh ra để phục vụ mục đích, nhanh chóng và có chức năng hẹp.

Ví dụ, một CLI của Playwright, mỗi thao tác trình duyệt chỉ mất 100ms; còn một MCP Chrome, chụp màn hình → tìm kiếm → nhấp → chờ → đọc mất 15 giây. Cái trước nhanh gấp 75 lần.

Phần mềm hiện nay không cần phải “tinh xảo đến mức cồng kềnh” nữa. Bạn chỉ cần xây dựng đúng những gì thực sự cần, và chỉ thế thôi.

3. Resolver (bộ định tuyến)

Resolver, về bản chất, là một bảng định tuyến ngữ cảnh. Khi xuất hiện loại nhiệm vụ X, ưu tiên tải tài liệu Y. Skills nói cho mô hình “làm thế nào”; resolvers nói cho mô hình “khi nào nên tải gì”.

Ví dụ, một nhà phát triển sửa một prompt. Không có resolver, anh ta có thể sửa xong rồi phát hành luôn. Có resolver, mô hình sẽ đọc trước docs/EVALS.md. Trong đó ghi rõ: chạy bộ đánh giá, so sánh điểm số trước sau; nếu độ chính xác giảm hơn 2%, thì rollback và điều tra nguyên nhân. Người phát triển ban đầu thậm chí còn không biết có bộ đánh giá này. Chính resolver đã đúng lúc tải đúng ngữ cảnh vào.

Claude Code tích hợp sẵn resolver. Mỗi skill có trường description, mô hình sẽ tự động ghép ý định người dùng với mô tả của skill. Bạn thậm chí không cần nhớ skill /ship có tồn tại hay không—description chính là resolver.

Thành thật mà nói: tôi từng có file CLAUDE.md dài tới 20.000 dòng. Tất cả các lỗi, mẫu, kinh nghiệm tôi gặp đều bỏ vào đó. Thật là quá lố. Chất lượng chú ý của mô hình rõ ràng giảm sút. Claude Code còn khiến tôi phải bỏ luôn nó đi.

Giải pháp cuối cùng chỉ còn khoảng 200 dòng—chỉ giữ lại một số chỉ dẫn tài liệu. Khi cần, resolver sẽ tải đúng tài liệu đó vào đúng thời điểm. Như vậy, 20.000 dòng kiến thức vẫn có thể lấy ra dùng ngay lập tức, mà không làm ô nhiễm ngữ cảnh.

4. Latent và deterministic (khu vực tiềm ẩn và xác định)

Trong hệ thống của bạn, mỗi bước đều thuộc về một trong hai loại. Và việc nhầm lẫn hai thứ này là sai lầm phổ biến nhất trong thiết kế agent.

·Latent space (khu vực tiềm ẩn), là nơi trí tuệ tồn tại. Mô hình đọc hiểu, đánh giá, quyết định ở đây. Nơi xử lý: đánh giá, tổng hợp, nhận dạng mẫu.

·Deterministic (xác định), là nơi độ tin cậy nằm. Cùng đầu vào, luôn cho ra kết quả giống nhau. Truy vấn SQL, mã biên dịch, phép tính số học đều thuộc phần này.

Một LLM có thể giúp bạn sắp xếp chỗ ngồi tối đa 8 người, cân nhắc tính cách và mối quan hệ xã hội của từng người. Nhưng nếu bạn yêu cầu nó sắp xếp 800 người, nó sẽ bịa ra một danh sách chỗ ngồi “hợp lý về mặt lý thuyết, nhưng hoàn toàn sai lệch thực tế”. Bởi vì đó không còn là vấn đề của latent nữa, mà là một bài toán tối ưu tổ hợp đã bị nhét vào khu vực xác định—một dạng tối ưu hóa tổ hợp.

Hệ thống tồi nhất luôn đặt công việc sai chỗ ở hai bên ranh giới này. Hệ thống tốt nhất sẽ rõ ràng phân định ranh giới một cách lạnh lùng.

5. Diarization (phân loại tài liệu / hình ảnh chủ đề)

Bước diarization mới là yếu tố quyết định giá trị thực của AI trong công việc kiến thức.

Nó nghĩa là: mô hình đọc tất cả tài liệu liên quan đến một chủ đề, rồi viết ra một bức tranh cấu trúc. Tóm tắt trong một trang, các đánh giá trong hàng chục hoặc hàng trăm tài liệu được cô đọng lại.

Điều này không thể làm bởi SQL query. Cũng không thể bởi pipeline RAG. Mô hình phải thực sự đọc, giữ các thông tin mâu thuẫn trong đầu cùng lúc, nhận biết những thay đổi, và tổng hợp thành một trí tuệ cấu trúc.

Đây là sự khác biệt giữa truy vấn cơ sở dữ liệu và báo cáo của nhà phân tích.

Cấu trúc này

Năm khái niệm này có thể kết hợp thành một kiến trúc rất đơn giản gồm ba tầng:

·Tầng trên cùng là fat skills: quy trình viết bằng markdown, chứa đánh giá, phương pháp luận và kiến thức lĩnh vực. 90% giá trị nằm ở tầng này.
·Tầng trung là harness mỏng: khoảng 200 dòng code, đầu vào là JSON, đầu ra là văn bản, mặc định chỉ đọc.
·Tầng dưới là hệ thống ứng dụng của bạn: QueryDB, ReadDoc, Search, Timeline—đây là hạ tầng dựa trên xác định.

Nguyên tắc cốt lõi là có hướng: đẩy “trí tuệ” lên trên hết có thể; đẩy “thực thi” xuống các công cụ xác định; giữ harness nhẹ nhàng.

Kết quả của cách làm này là: mỗi khi năng lực mô hình nâng cao, tất cả kỹ năng đều tự nhiên mạnh hơn; còn hệ thống xác định phía dưới luôn ổn định và đáng tin cậy.

Hệ thống học hỏi

Dưới đây tôi sẽ dùng một hệ thống thực tế mà chúng tôi đang xây dựng trong YC để minh họa cách năm định nghĩa này phối hợp hoạt động.

Tháng 7 năm 2026, Chase Center. Startup School có 6000 nhà sáng lập tham gia. Mỗi người có hồ sơ ứng tuyển cấu trúc, câu trả lời khảo sát, bản ghi đối thoại 1:1 với mentor, và các tín hiệu công khai: bài đăng trên X, commit GitHub, ghi chú sử dụng Claude Code (có thể thấy tốc độ phát triển của họ).

Phương pháp truyền thống là: 15 người trong nhóm dự án đọc từng hồ sơ, dựa vào trực giác đánh giá, rồi cập nhật bảng dữ liệu.

Phương pháp này còn hoạt động khi quy mô 200 người, nhưng đến 6000 người thì hoàn toàn thất bại. Không ai có thể đồng thời chứa trong đầu nhiều hồ sơ như vậy, và nhận ra rằng: ba ứng viên tiềm năng hàng đầu trong hạ tầng AI, lần lượt là nhà sáng lập công cụ phát triển ở Lagos, nhà sáng lập tuân thủ quy định ở Singapore, và nhà phát triển công cụ CLI ở Brooklyn—và họ mô tả cùng một điểm đau theo cách hoàn toàn khác nhau trong các cuộc đối thoại 1:1.

Mô hình có thể làm được. Phương pháp như sau:

Enrichment (tăng cường thông tin)

Có một kỹ năng gọi là /enrich-founder, sẽ lấy tất cả dữ liệu, thực hiện tăng cường thông tin, diarization, và đánh dấu sự khác biệt giữa “nhà sáng lập nói” và “thực tế đang làm”.

Hạ tầng hệ thống xác định đảm nhiệm: truy vấn SQL, dữ liệu GitHub, kiểm thử trình duyệt Demo URL, thu thập tín hiệu xã hội, truy vấn CrustData, v.v. Một tác vụ định kỳ chạy mỗi ngày. Hồ sơ của 6000 nhà sáng lập luôn cập nhật mới nhất.

Kết quả diarization có thể phát hiện ra các thông tin mà tìm kiếm từ khóa hoàn toàn không thể:

Sự “khác biệt giữa cách nói và hành động thực tế” này cần đọc toàn bộ lịch sử commit GitHub, hồ sơ ứng tuyển và bản ghi đối thoại, rồi tổng hợp trong đầu. Không có embedding nào có thể làm được điều này, cũng không thể lọc qua từ khóa. Mô hình phải đọc toàn bộ rồi mới đánh giá. (Đây chính là nhiệm vụ nên để trong latent space!)

Matching (phù hợp)

Đây là nơi “kỹ năng = phương thức gọi” phát huy tác dụng.

Cùng một kỹ năng phù hợp, gọi ba lần có thể tạo ra các chiến lược hoàn toàn khác nhau:

/match-breakout: xử lý 1200 người, phân cụm theo lĩnh vực, mỗi nhóm 30 người (embedding + phân phối xác định)

/match-lunch: xử lý 600 người, ghép ngẫu nhiên theo lĩnh vực, mỗi bàn 8 người không trùng lặp—LLM tạo chủ đề trước, sau đó thuật toán xác định sắp xếp chỗ

/match-live: xử lý người tham gia trực tiếp, dựa trên embedding lân cận nhất, hoàn thành trong vòng 200ms 1:1, loại trừ người đã gặp

Và mô hình còn có thể đưa ra các đánh giá mà các thuật toán phân cụm truyền thống không thể:

" Santos và Oram đều thuộc hạ tầng AI, nhưng không cạnh tranh—Santos làm phân bổ chi phí, Oram làm phối hợp. Nên để chúng trong cùng một nhóm."
“Kim viết đơn xin là công cụ phát triển, nhưng qua đối thoại 1:1 lại thể hiện đang làm tự động hóa tuân thủ SOC2. Nên phân loại lại vào FinTech / RegTech.”

Việc phân loại lại này không thể làm bằng embedding. Mô hình phải đọc toàn bộ hồ sơ.

Vòng lặp học hỏi (learning loop)

Sau hoạt động, một kỹ năng /improve sẽ đọc kết quả khảo sát NPS, diarize các phản hồi “tạm được”—không phải phản hồi tiêu cực, mà là “gần đạt”—và trích xuất mẫu.

Sau đó, nó đề xuất quy tắc mới, viết lại vào kỹ năng phù hợp:

Khi người tham gia nói “hạ tầng AI”, nhưng mã của họ hơn 80% là các module tính phí: → phân loại là FinTech, không phải AI Infra

Khi hai người trong cùng nhóm đã quen biết: → giảm trọng số phù hợp, ưu tiên thêm mối quan hệ mới

Các quy tắc này sẽ được ghi vào tập tin skill. Lần chạy tiếp theo sẽ tự động áp dụng. Kỹ năng tự “tự sửa”. Trong hoạt động tháng 7, điểm “tạm được” chiếm 12%; sau đó giảm còn 4%.

Tập tin skill đã học được “tạm được” nghĩa là gì, và hệ thống trở nên tốt hơn mà không cần ai đó viết lại mã.

Mô hình này có thể chuyển đổi sang bất kỳ lĩnh vực nào:

Tìm kiếm → Đọc → diarize → đếm → tổng hợp

Rồi: khảo sát → điều tra → diarize → viết lại skill

Nếu bạn hỏi năm 2026, vòng lặp có giá trị nhất là gì, thì chính là bộ này. Nó có thể áp dụng vào hầu hết các công việc kiến thức.

Kỹ năng luôn được nâng cấp vĩnh viễn

Gần đây tôi đã đăng một lệnh cho OpenClaw trên X, nhận phản hồi lớn hơn mong đợi:

Bài đăng này nhận hơn nghìn lượt thích và hơn hai nghìn lưu trữ. Nhiều người nghĩ đây là kỹ thuật prompt engineering.

Thực ra không phải, đó chính là hệ thống tôi đã đề cập phía trên. Mỗi kỹ năng bạn viết ra đều là một nâng cấp vĩnh viễn cho hệ thống. Nó không bị thoái hóa, không bị quên. Nó tự động chạy vào lúc 3 giờ sáng. Và khi mô hình thế hệ tiếp theo ra đời, tất cả kỹ năng sẽ lập tức mạnh hơn—khả năng đánh giá trong latent tăng lên, còn phần deterministic vẫn ổn định và đáng tin cậy.

Đây chính là nguồn gốc của hiệu suất gấp 100 lần mà Yegge đề cập.

Không phải là mô hình thông minh hơn, mà là: kỹ năng dày, khung mỏng (Thin Harness, Fat Skills), và kỷ luật biến mọi thứ thành năng lực.

Hệ thống sẽ tăng trưởng theo lãi kép. Xây dựng một lần, vận hành lâu dài.