Lờ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ận định khác: thứ thực sự tạo ra khoảng cách năng suất gấp 10, 100 thậm chí 1000 lần không phải là bản thân mô hình, mà là toàn bộ hệ thống thiết kế được xây dựng xung quanh mô hình.
Tác giả Garry Tan, hiện là Chủ tịch kiêm CEO của Y Combinator, có nhiều năm đào sâu vào hệ sinh thái khởi nghiệp sớm và AI. Ông đề xuất khung "fat skills + thin harness" (kỹ năng dày + khung chạy mỏng), phân tách ứng dụng AI thành các thành phần chính: kỹ năng, khung chạy, định tuyến ngữ cảnh, phân chia nhiệm vụ và nén tri thức.
Trong hệ thống này, mô hình không còn là toàn bộ năng lực, mà chỉ là đơn vị thực thi trong hệ thống; thứ thực sự quyết định chất lượng đầu ra là cách bạn tổ chức ngữ cảnh, đóng gói quy trình và 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 ở khái niệm mà đã được kiểm chứng trong thực tế: Đối với nhiệm vụ xử lý và kết hợp dữ liệu của hàng nghìn nhà sáng lập, hệ thống thông qua vòng lặp "đọc - sắp xếp - đánh giá - ghi lại" đã đạt được năng lực gần như một nhà phân tích con người, và tự tối ưu hóa liên tục mà không cần viết lại mã. Loại "hệ thống biết học" này biến AI từ một công cụ một lần thành một cơ sở hạ tầng có hiệu ứng lãi 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 thời đại AI, khoảng cách hiệu suất không còn phụ thuộc vào việc bạn có sử dụng mô hình tiên tiến nhất hay không, mà ở việc bạn có xây dựng được một hệ thống có thể tích lũy năng lực liên tục và tự động tiến hóa hay không.
Dưới đây là nguyên văn:
Steve Yegge nói rằng, những người sử dụng đại lý lập trình AI, "có hiệu suất gấp 10 đến 100 lần những kỹ sư chỉ dùng Cursor và công cụ chat để viết code, và gấp khoảng 1000 lần kỹ sư Google năm 2005."
Đây không phải là nói quá. Tôi đã tận mắt chứng kiến và tự mình trải nghiệm. Nhưng khi nghe đến khoảng cách như vậy, mọi người thường quy kết sai hướng: mô hình mạnh hơn, Claude thông minh hơn, nhiều tham số hơn.
Thực tế, người tăng hiệu suất 2 lần và người tăng 100 lần dùng chung một bộ mô hình. Sự khác biệt không nằm ở "trí thông minh", mà ở "kiến trúc", và kiến trúc này đơn giản đến mức có thể viết trên một tấm card.
Harness (Khung chạy) mới chính là sản phẩm.
Ngày 31 tháng 3 năm 2026, một sự cố bất ngờ của Anthropic đã phát hành toàn bộ mã nguồn Claude Code lên npm — tổng cộng 512 nghìn dòng. Tôi đã đọc hết. Điều này xác nhận điều tôi vẫn luôn nói tại YC (Y Combinator): 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 lưu trữ mã thời gian thực, bộ nhớ đệm Prompt, công cụ được thiết kế cho nhiệm vụ cụ thể, nén ngữ cảnh dư thừa tối đa, bộ nhớ phiên có cấu trúc, các tiểu đại lý chạy song song — những thứ này không làm mô hình thông minh hơn. Nhưng chúng có thể cung cấp cho mô hình "ngữ cảnh đúng" vào "thời điểm đúng", đồng thời tránh bị nhấn chìm bởi thông tin không liên quan.
Lớp "bao bọc" này được gọi là harness (khung chạy). Và câu hỏi mà tất cả những người xây dựng AI thực sự nên đặt là: Những thứ gì nên đưa vào harness, những thứ gì nên để bên ngoài?
Câu hỏi này thực ra có một câu trả lời rất cụ thể — tôi gọi đó là: Khung mỏng (thin harness), Năng lực dày (fat skills).
Năm định nghĩa
Nút thắt chưa bao giờ nằm ở trí thông minh của mô hình. Mô hình thực ra đã biết cách suy luận, tổng hợp thông tin, viết mã từ lâu.
Lý do chúng thất bại là vì chúng không hiểu dữ liệu của bạn — lược đồ (schema) của bạn, quy ước của bạn, hình dạng cụ thể của vấn đề này của bạn là gì. Và năm định nghĩa dưới đây chính là để giải quyết vấn đề đó.
1. Skill file (Tệp kỹ năng)
Tệp 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 "cách làm một việc". Lưu ý, không phải nói cho nó biết "phải làm gì" — phần đó do người dùng cung cấp. Tệp kỹ năng cung cấp quy trình.
Điểm mấu chốt hầu hết mọi người bỏ qua là: Tệp kỹ năng thực chất 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, nhưng vì tham số truyền vào khác nhau, có thể thể hiện năng lực hoàn toàn khác biệt.
Ví dụ, có một kỹ năng tên là /investigate. Nó bao gồm bảy bước: xác định phạm vi dữ liệu, xây dựng dòng thời gian, diarize (ghi chép theo chủ đề) cho mỗi tài liệu, tổng hợp quy nạp, lập luận từ hai phía tích cực và tiêu cực, trích dẫn nguồn. Nó nhận ba tham số: TARGET, QUESTION và DATASET.
Nếu bạn hướng nó đến một nhà khoa học an ninh và 2.1 triệu email điều tra, nó sẽ trở thành một nhà phân tích nghiên cứu y khoa, để đánh giá xem một người tố cáo có bị đàn áp hay không.
Nếu bạn hướng nó đến một công ty vỏ bọc và các tệp khai báo của Ủy ban Bầu cử Liên bang Mỹ (FEC), nó lại trở thành một nhà điều tra pháp y, để theo dõi các khoản đóng góp chính trị có hành động phối hợp.
Vẫn là cùng một kỹ năng. Vẫn cùng bảy bước. Vẫn cùng một tệp markdown. Kỹ năng mô tả một quy trình đánh giá, và thứ thực sự đưa nó vào thế giới thực là các tham số được 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ỉ là ở đây dùng markdown làm 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 thực thi. Trên thực tế, markdown thậm chí còn phù hợp hơn mã nguồn cứng nhắc để đóng gói năng lực, vì nó mô tả quy trình, đánh giá và ngữ cảnh, và đây chính xác là ngôn ngữ mà mô hình "hiểu" nhất.
2. Harness (Khung chạy)
Harness, là chương trình lớp đó điều khiển LLM chạy. Nó chỉ làm bốn việc: cho mô hình chạy trong vòng lặp, đọc ghi tệp của bạn, quản lý ngữ cảnh và thực thi các ràng buộc bảo mật.
Chừng đó thôi. Đây là "thin (mỏng)".
Mẫu hình ngược lại là: harness béo, skills gầy.
Bạn hẳn đã thấy thứ này: hơn 40 định nghĩa công cụ, riêng phần mô tả đã ngốn mấ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 đến 5 giây; hoặc, gói từng endpoint REST API thành công cụ riêng lẻ. Kết quả là, lượng token tăng gấp ba, độ trễ tăng gấp ba, tỷ lệ thất bại cũng tăng gấp ba.
Cách làm lý tưởng thực sự, là sử dụng các công cụ có chức năng hẹp, nhanh và sinh ra vì mục đích cụ thể.
Ví dụ một Playwright CLI, mỗi thao tác trình duyệt chỉ mất 100 mili giây; thay vì một Chrome MCP, làm một lần screenshot → find → click → wait → read mất 15 giây. Cái trước nhanh hơn 75 lần.
Phần mềm bây giờ không cần thiết phải "được trau chuốt đến mức phình ra" nữa. Bạn nên làm là: chỉ xây dựng những thứ bạn thực sự cần, và chỉ vậy thôi.
3. Resolver (Bộ giải quyết / Định tuyến)
Resolver, về bản chất là một bảng định tuyến ngữ cảnh. Khi loại nhiệm vụ X xuất hiện, ưu tiên tải tài liệu Y. Skills nói cho mô hình biết "làm thế nào"; resolvers nói cho mô hình biết "khi nào nên tải cái gì".
Ví dụ, một nhà phát triển sửa một prompt nào đó. Không có resolver, anh ta có thể sửa xong và phát hành ngay. Có resolver, mô hình sẽ đi đọc docs/EVALS.md trước. Và trong tài liệu này ghi: chạy bộ đánh giá trước, so sánh điểm số trước sau; nếu độ chính xác giảm hơn 2%, thì lùi lại và kiểm tra nguyên nhân. Nhà phát triển này ban đầu thậm chí không biết có sự tồn tại của bộ đánh giá. Chính resolver đã tải ngữ cảnh đúng đắn vào đúng thời điểm.
Claude Code có sẵn một resolver. Mỗi skill đều có một trường description, mô hình sẽ tự động khớp ý định người dùng với mô tả của skill. Bạn thậm chí không cần nhớ kỹ năng /ship có tồn tại hay không — bản thân description đã là resolver.
Thành thật mà nói: CLAUDE.md trước đây của tôi có tới 20 nghìn dòng. Tất cả các điểm kỳ quặc, tất cả các mẫu hình, tất cả các bài học kinh nghiệm tôi từng gặp, nhét hết vào. Thật lố bịch. Chất lượng sự chú ý của mô hình giảm rõ rệt. Claude Code thậm chí còn trực tiếp bảo tôi cắt bỏ nó.
Giải pháp sửa chữa cuối cùng, chỉ khoảng 200 dòng — chỉ giữ lại một số con trỏ tài liệu. Thực sự cần tài liệu nào, thì để resolver tải tài liệu đó vào thời điểm then chốt. Bằng cách này, 20 nghìn dòng tri thức vẫn có thể sử dụng tùy ý, nhưng không làm ô nhiễm cửa sổ ngữ cảnh.
4. Latent và deterministic (Không gian tiềm ẩn và Tính xác định)
Trong hệ thống của bạn, mỗi bước không thuộc loại này thì thuộc loại kia. Và việc nhầm lẫn hai thứ này là lỗi phổ biến nhất trong thiết kế agent.
· Latent space (Không gian tiềm ẩn), là nơi trí thông minh tồn tại. Mô hình ở đây đọc, hiểu, đánh giá, ra quyết định. Ở đây xử lý: phán đoán, tổng hợp, nhận dạng mẫu.
· Deterministic (Tính xác định), là nơi tính đáng tin cậy tồn tại. Đầu vào giống nhau, luôn cho đầu ra giống nhau. Truy vấn SQL, mã đã biên dịch, phép tính số học, đều thuộc phía này.
Một LLM có thể giúp bạn sắp xếp chỗ ngồi bữa tối cho 8 người, đồng thời cân nhắc tính cách và mối quan hệ xã hội của mỗi người. Nhưng nếu bạn bảo nó xếp chỗ cho 800 người, nó sẽ nghiêm túc bịa ra một sơ đồ chỗ ngồi "trông có vẻ hợp lý, nhưng thực tế hoàn toàn sai" . Bởi vì đó không còn là vấn đề không gian tiềm ẩn nên xử lý nữa, mà là một vấn đề xác định bị nhét vào latent space — vấn đề tối ưu hóa tổ hợp.
Hệ thống tệ 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ẽ phân định ranh giới một cách rất lạnh lùng.
5. Diarization (Sắp xếp tài liệu / Hồ sơ chủ đề)
Bước diarization này, mới là chìa khóa thực sự tạo ra giá trị của AI đối với công việc tri thức trong thực tế.
Nó có nghĩa là: mô hình đọc tất cả tài liệu liên quan đến một chủ đề, sau đó viết ra một hồ sơ có cấu trúc. Trong một trang giấy, cô đọng các đánh giá từ hàng chục thậm chí hàng trăm tài liệu.
Đây không phải là thứ mà truy vấn SQL có thể tạo ra. Đây cũng không phải là thứ mà pipeline RAG có thể tạo ra. Mô hình phải thực sự đọc, đặt các thông tin mâu thuẫn nhau cùng trong đầu, chú ý những thứ đã thay đổi, khi nào thay đổi, sau đó tổng hợp những nội dung này thành intelligence có cấu trúc.
Đây chính là sự khác biệt giữa truy vấn cơ sở dữ liệu và báo cáo tóm tắt của nhà phân tích.
Kiến 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 ba tầng rất đơn giản.
· Tầng trên cùng là kỹ năng dày (fat skills): các quy trình được viết bằng markdown, chứa đựng phán đoán, phương pháp luận và tri thức lĩnh vực. 90% giá trị, nằm ở tầng này.
· Ở giữa là một lớp CLI harness mỏng: khoảng 200 dòng mã, đầu vào JSON, đầu ra văn bản, mặc định chỉ đọc.
· Tầng dưới cùng là hệ thống ứng dụng của bạn: QueryDB, ReadDoc, Search, Timeline — đây là những cơ sở hạ tầng xác định.
Nguyên tắc cốt lõi là có hướng: đẩy "trí thông minh" lên skills càng nhiều càng tốt; đè "thực thi" xuống các công cụ xác định càng nhiều càng tốt; giữ harness mỏng nhẹ.
Kết quả của việc này là: mỗi khi năng lực mô hình được nâng cấp, tất cả kỹ năng sẽ tự động mạnh lên; và hệ thống xác định ở tầng dưới, luôn ổn định đáng tin cậy.
Hệ thống biết học
Dưới đây tôi dùng một hệ thống thực tế chúng tôi đang xây dựng tại YC, để展示 năm định nghĩa này hoạt động cùng nhau như thế nào.
Tháng 7 năm 2026, Chase Center. Startup School có 6000 nhà sáng lập tham dự. Mỗi người đều có tài liệu đăng ký có cấu trúc, câu trả lời bảng hỏi, bản ghi chép cuộc trò chuyện 1:1 với cố vấn, và các tín hiệu công khai: bài đăng trên X, bản ghi commit GitHub, bản ghi sử dụng Claude Code (có thể thấy tốc độ phát triển của họ).
Cách làm truyền thống là: nhóm dự án 15 người đọc từng đơn đăng ký, đánh giá theo trực giác, sau đó cập nhật một bảng tính.
Phương pháp này vận hành được ở quy mô 200 người, nhưng ở 6000 người thì hoàn toàn thất bại. Không con người nào có thể đồng thời chứa nhiều hồ sơ như vậy trong đầu, và nhận ra: ba ứng viên xuất sắc nhất trong hướng cơ sở hạ tầng AI agent, lần lượt là nhà sáng lập công cụ phát triển ở Lagos, nhà khởi nghiệp tuân thủ ở Singapore, và nhà phát triển công cụ CLI ở Brooklyn — và trong các cuộc trò chuyện 1:1 khác nhau, họ đã mô tả cùng một điểm đau bằng cách diễn đạt hoàn toàn khác nhau.
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 tên là /enrich-founder, nó sẽ kéo tất cả nguồn dữ liệu, làm giàu 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ế làm".
Hệ thống xác định ở dưới đảm nhiệm: truy vấn SQL, dữ liệu GitHub, kiểm tra trình duyệt URL Demo, thu thập tín hiệu xã hội, truy vấn CrustData, v.v. Một tác vụ theo lịch chạy mỗi ngày một lần. 6000 hồ sơ nhà sáng lập luôn được cập nhật mới nhất.
Đầu ra của diarization, có thể nắm bắt thông tin mà tìm kiếm từ khóa hoàn toàn không thể phát hiện:
Sự khác biệt "lời nói vs hành vi thực tế" này, cần đồng thời đọc lịch sử commit GitHub, tài liệu đăng ký và bản ghi cuộc trò chuyện, và tích hợp trong đầu. Không có bất kỳ tìm kiếm độ tương tự embedding nào có thể làm được điều này, lọc từ khóa cũng không. Mô hình phải đọc đầy đủ, sau đó đưa ra đánh giá. (Đây chính xác là nhiệm vụ nên đặt trong latent space!)
Matching (Kết hợp)
Đây là nơi "kỹ năng = lời gọi phương thức" phát huy sức mạnh.
Cùng một kỹ năng kết hợp, gọi ba lần, có thể tạo ra 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 bổ xác định)
/match-lunch: Xử lý 600 người, kết hợp "ngẫu nhiên" xuyên lĩnh vực, mỗi bàn 8 người và không lặp lại — do LLM tạo chủ đề trước, sau đó thuật toán xác định sắp xếp chỗ ngồi
/match-live: Xử lý người tham gia thời gian thực tại chỗ, dựa trên embedding láng giềng gần nhất, hoàn thành kết hợp 1 đối 1 trong vòng 200ms, và loại trừ những người đã gặp
Và mô hình còn có thể đưa ra đánh giá mà thuật toán phân cụm truyền thống không thể hoàn thành:
"Santos và Oram đều thuộc cơ sở hạ tầng AI, nhưng không phải quan hệ cạnh tranh — Santos làm phân bổ chi phí, Oram làm điều phối. Nên xếp cùng nhóm."
"Kim khi đăng ký viết là công cụ nhà phát triển, nhưng cuộc trò chuyện 1:1 cho thấy anh ấy đ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, embedding hoàn toàn không nắm bắt được. Mô hình phải đọc toàn bộ hồ sơ.
Vòng lặp học tập (learning loop)
Sau khi sự kiện kết thúc, một kỹ năng /improve sẽ đọc kết quả khảo sát NPS, thực hiện diarization đối với những phản hồi "tạm được" — không phải đánh giá kém, mà là những cái "chỉ cần một chút nữa là tốt" — và trích xuất mẫu hình.
Sau đó, nó sẽ đề xuất quy tắc mới, và ghi lại vào kỹ năng kết hợp:
Khi người tham gia nói "AI infrastructure", nhưng 80% mã của họ trở lên là module tính cước:
→ Phân loại là FinTech, không phải AI Infra
Khi hai người trong nhóm đã quen biết nhau:
→ Giảm trọng số kết hợp
Ưu tiên giới thiệu mối quan hệ mới
Những quy tắc này sẽ được ghi lại vào tệp skill. Lần chạy tiếp theo tự động có hiệu lực. Kỹ năng đang "tự viết lại". Sự kiện tháng 7, đánh giá "tạm được" chiếm 12%; sự kiện tiếp theo giảm xuống 4%.
Tệp 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ó ai viết lại mã.
Mẫu hình này có thể di chuyển đến bất kỳ lĩnh vực nào:
Truy xuất → Đọc → diarize → Đếm → Tổng hợp
Sau đó: Nghiên cứu → Điều tra → diarize → Viết lại skill
Nếu bạn hỏi vòng lặp có giá trị nhất năm 2026 là gì, thì chính là bộ này. Nó có thể áp dụng cho hầu hết mọi cảnh làm việc tri thức.
Kỹ năng là nâng cấp vĩnh viễn
Gần đây tôi đã đăng một chỉ thị cho OpenClaw trên X, phản hồi lớn hơn dự kiến:
Nội dung này nhận được hàng nghìn lượt thích và hơn hai nghìn lượt lưu. Nhiều người nghĩ đây là kỹ thuật prompt engineering.
Thực ra không, đây chính là bộ kiến trúc đã nói ở trên. Mỗi skill bạn viết ra, đều là một bản nâng cấp vĩnh viễn cho hệ thống. Nó không thoái hóa, không quên. Nó sẽ tự động chạy lúc ba giờ sáng. Và khi thế hệ mô hình tiếp theo được phát hành, tất cả skill sẽ lập tức mạnh lên — phần latent khả năng đánh giá được nâng cấp, trong khi phần deterministic vẫn ổn định đáng tin cậy.
Đây chính là nguồn gốc hiệu suất 100 lần mà Yegge nói đến.
Không phải mô hình thông minh hơn, mà là: Kỹ năng dày, Khung chạy mỏng (Thin Harness, Fat Skills), và kỷ luật củng cố mọi thứ thành năng lực.
Hệ thống sẽ tăng trưởng lãi kép. Xây dựng một lần, chạy lâu dài.






