Lời biên tập: Khi AI Agent tiến từ việc sử dụng Prompt một lần và vibe coding, bước vào giai đoạn quy trình làm việc phức tạp hơn, vấn đề thực sự quan trọng không còn là "mô hình có thể hoàn thành nhiệm vụ không" nữa, mà là "có thể kết tủa khả năng AI thành tài sản quy trình có thể tái sử dụng, có thể tích lũy được hay không".
Bài viết này xuất phát từ GBrain của Garry Tan, tổng kết năm mô hình lõi mà nhiều người đang dần hội tụ khi sử dụng các công cụ Agent như Codex, Claude Code, Hermes: Kỹ năng (Skills) có thể tham số hóa, khung thực thi nhẹ (Thin Harness), công cụ định tuyến (Resolvers), tầng thực thi phân biệt phán đoán mô hình và mã code xác định, cùng với Bộ nhớ (Memory) dùng để tích lũy ngữ cảnh lâu dài.
Sự kết hợp của các mô-đun này hướng tới một loại "năng lực quá trình" mới: viết kinh nghiệm thành quy trình, trừu tượng hóa nhiệm vụ thành tham số, giao quy tắc ổn định cho mã code, giao việc phán đoán và tổng hợp cho mô hình, rồi thông qua tầng bộ nhớ để tích lũy liên tục. So với các ứng dụng hoặc lời nhắc (prompt) được tạo ra một lần, hệ thống kiểu này khó sao chép hơn, và cũng có nhiều khả năng trở thành nền tảng giúp cá nhân, nhóm nhỏ hay công ty hình thành lợi thế cạnh tranh lâu dài trong thời đại AI.
Dưới đây là bài viết gốc:
Tôi đã dành một chút thời gian nghiên cứu GBrain của Garry Tan. Là một người không có nền tảng kỹ thuật, cũng không làm việc trong ngành đầu tư mạo hiểm, tôi muốn đúc kết một số cấu trúc hình thái phổ biến mà tôi thấy ở đây, cùng với điểm thực sự thú vị của nó.
Tôi cho rằng, nhiều người đang dần hội tụ về cùng một nhóm cấu trúc lõi. Chúng có thể được tóm tắt thành khoảng 5 hình thái, và cũng đại diện cho hướng phát triển tự nhiên trong cách sử dụng các công cụ AI dạng Agent như Codex, Claude Code, Hermes, OpenClaw.
Bài liên quan: "Thin Harness, Fat Skill: Nguồn gốc thực sự của năng suất AI gấp 100 lần"
Skills: Từ SOP đến "Lệnh gọi phương thức"
Skills gần như là điểm khởi đầu tự nhiên nhất của mọi người. Ngay cả khi không có ai nhắc nhở, người dùng cũng sẽ vô thức xây dựng nó, vì hình thái của nó rất quen thuộc. Ban đầu, tôi hiểu nó như một loại SOP, tức là quy trình vận hành tiêu chuẩn để hoàn thành một việc nào đó. Người dùng cung cấp "việc cần làm", Skill cung cấp "cách làm".
Cách hiểu của Tan là, Skill giống một "lệnh gọi phương thức" hơn. Trong lập trình, lệnh gọi phương thức đề cập đến việc sử dụng các tham số để gọi một quy trình chương trình. Cùng một đoạn mã sẽ chạy mỗi lần, thay đổi là các tham số: dữ liệu gì, vấn đề gì, mục tiêu gì. Ví dụ, cùng một hàm process_invoice có thể xử lý mọi hóa đơn trong hệ thống, không chỉ riêng hóa đơn ban đầu nó được viết ra để xử lý.
Skill cũng có cấu trúc tương tự. Một Skill có tên /investigate có thể chứa bảy bước cố định, và bảy bước này không thay đổi. Cái thay đổi là các tham số: TARGET (đối tượng điều tra là ai hoặc là gì), QUESTION (bạn muốn làm rõ điều gì), DATASET (tìm thông tin ở đâu). Chỉ nó đến một vụ việc tố cáo trong ngành y tế, nó hoạt động như một nhà nghiên cứu phân tích; chỉ nó đến các tài liệu đăng ký SEC, nó hoạt động như một điều tra viên pháp lý. Cùng một tệp, cùng bảy bước, sự khác biệt do thế giới bên ngoài cung cấp.
Điều này khác với SOP truyền thống. Hầu hết SOP được viết cho một vị trí hoặc nhiệm vụ cụ thể, như "xử lý khoản phải trả". Mỗi tình huống sử dụng ứng với một bộ quy trình. Trong khi đó, Skill có mức độ trừu tượng cao hơn, cùng một bộ quy trình có thể xử lý một loại vấn đề. Một Skill được thiết kế tốt có thể hoàn thành công việc của hàng chục SOP, vì thông tin của trường hợp cụ thể được tách ra khỏi tài liệu, chuyển sang các tham số. Cụ thể trong sử dụng thực tế, một số Skill gần với SOP hơn, một số khác thì gần với lệnh gọi phương thức hơn.
Thin Harness: Mô hình là trí thông minh, Harness là tay chân
Mô hình, như Opus, GPT-5.5, là trí thông minh thô; Harness, như Claude Code, Codex CLI, Hermes, OpenClaw, là khung thực thi thực sự giúp mô hình "có tay có chân". Chúng chịu trách nhiệm thực thi vòng lặp, đọc ghi tệp, quản lý ngữ cảnh, thực thi ràng buộc bảo mật. Mã lõi của chúng chỉ khoảng 200 dòng.
Garry đề cập, một sai lầm mà hầu hết mọi người mắc phải là không ngừng nhồi nhét thêm thứ vào Harness, bản thân tôi cũng vậy. Cuối cùng tôi tích lũy được 100 định nghĩa công cụ, cùng một loạt máy chủ MCP. Kết quả là, cửa sổ ngữ cảnh bị chiếm đầy bởi các mô tả công cụ mà nhiệm vụ hiện tại không cần. Mô hình bắt đầu nhầm lẫn nên dùng công cụ nào, độ trễ tăng, độ chính xác giảm, cuối cùng hình thành cái gọi là "suy thoái ngữ cảnh".
Resolvers: Dùng bảng định tuyến giải quyết suy thoái ngữ cảnh
Phương pháp giải quyết suy thoái ngữ cảnh là thiết lập một bảng định tuyến. Tác dụng của Resolver là ánh xạ rõ ràng "loại nhiệm vụ X vừa mới vào" tới "nên gọi Skill Y". Khi bạn chỉ có 5 Skill, bạn không cần Resolver; nhưng khi bạn có 100 Skill, các mô tả sẽ trở nên mơ hồ, mô hình rất dễ không thể gọi đúng Skill vào đúng thời điểm. Resolver dùng quy tắc rõ ràng thay thế cho việc khớp mẫu mơ hồ.
Tan cũng chạy một cơ chế tương tự Resolver cho tệp: một bảng định tuyến độc lập, dùng để quyết định đầu ra của một Skill nào đó nên được đặt vào vị trí nào trong hệ thống tệp. Đây là cùng một cấu trúc "kiểm tra - định tuyến", được áp dụng cho một vấn đề khác. Bằng cách này, đầu ra sẽ ổn định đi vào đúng thư mục, thay vì được đặt vào vị trí mô hình đoán tạm thời.
Skillify là một ý tưởng hỗ trợ khác của anh ấy: đó là một vòng lặp chất lượng, dùng để biến Skill dùng một lần thành cơ sở hạ tầng có thể tái sử dụng lâu dài. Quy trình 10 bước mà Tan mô tả bao gồm: định nghĩa hợp đồng, sử dụng mã code xác định ở nơi phù hợp, kiểm thử đơn vị, kiểm thử tích hợp, đánh giá LLM-as-judge, mục Resolver, script kiểm tra, kiểm tra những Skill nào không có đường dẫn gọi, và kiểm thử khói đầu cuối. Tiêu chuẩn kiểm tra rất đơn giản: nếu bạn phải hỏi mô hình cùng một câu hỏi hai lần, đó là thất bại.
Tiềm ẩn vs. Xác định: Giao phán đoán cho mô hình, giao nhiệm vụ xác định cho mã code
Cần phân biệt cẩn thận công việc nào nên giao cho LLM, công việc nào nên giao cho hệ thống xác định. LLM giỏi phán đoán, tổng hợp, nhận diện mẫu và đọc hiểu hàm ý; nhưng nó không giỏi tính toán số học, tối ưu hóa tổ hợp, cũng không phù hợp xử lý bất kỳ nhiệm vụ nào cần đưa ra cùng một câu trả lời mỗi lần. Về bản chất, LLM mang tính xác suất, khi giải pháp xác định có thể giải quyết vấn đề, thì không nên dùng LLM.
Hầu hết những người không có nền tảng kỹ thuật thường đánh giá thấp giá trị của tầng xác định. Phản ứng mặc định của mọi người là ném mọi thứ cho mô hình. Nhưng nếu một việc có thể hoàn thành bằng cách xác định, thì gần như nên làm như vậy. Và bạn không cần phải là lập trình viên, vì mô hình có thể viết mã code thay bạn. Điều thực sự cần rèn luyện là một kỷ luật: mỗi lần đều tự hỏi, việc này có thể hoàn thành một cách ổn định, chi phí thấp bằng mã code không? Nếu câu trả lời là có, hãy để mô hình viết đoạn mã đó ra.
Memory: Khiến hệ thống thực sự có thể tích lũy
Để hệ thống trở nên hữu ích, nó phải có một dạng bộ nhớ nào đó. Tôi chưa chắc hình thái chính xác nhất là gì, hiện nay nhiều người cũng đang xây dựng bằng các cách khác nhau: embedding vector, độ tương tự ngữ nghĩa, đồ thị tri thức, lưu trữ hỗn hợp... Cách làm của Tan giống tôi: chỉ là một thư mục markdown.
Cấu trúc của anh ấy là: mỗi người một trang, mỗi công ty một trang, mỗi khái niệm một trang. Mỗi trang, phần trên cùng là "Kết luận đáng tin cậy hiện tại", tức là phán đoán tổng hợp được viết lại và cập nhật liên tục cùng với bằng chứng mới; phần dưới cùng là một dòng thời gian chỉ ghi thêm, không ghi đè.
Lựa chọn markdown mang lại một vài kết quả. Thứ nhất, bản thân tệp chính là bản ghi chính của hệ thống, chứ không phải là một kết quả xuất ra nào đó. Bạn có thể mở nó trong VS Code, chỉnh sửa thủ công, Agent sẽ tự động đọc những thay đổi này. Thứ hai, các quan hệ có kiểu, như works_at, invested_in, founded, attended, advises, sẽ được tự động trích xuất thông qua biểu thức chính quy mỗi lần ghi, do đó đồ thị tri thức có thể tự kết nối mà không tiêu hao token. Lược đồ cụ thể này rất phù hợp với công việc của anh ấy, nhưng đối với người khác, có thể cần tùy chỉnh lại dựa trên nghề nghiệp và bối cảnh kinh doanh của mình.
Ngoài ra, còn có một máy dò tín hiệu chạy ở chế độ nền. Một người được đề cập một lần, sẽ tạo ra một trang stub; nếu anh ta được đề cập ba lần trong nhiều nguồn, sẽ kích hoạt việc bổ sung thông tin trang web; sau khi một cuộc họp kết thúc, sẽ chạy quy trình đầy đủ. Vòng lặp "dream cycle" ban đêm sẽ quét các cuộc trò chuyện, bổ sung thông tin thực thể lỗi thời, và sửa các tham chiếu bị hỏng. Tầng cơ sở là văn bản, tất cả mọi thứ trên đó đều rẻ, có thể kết hợp.
Tất nhiên ở tầng dưới còn có nhiều chi tiết hơn, nhưng tôi cho rằng, đây chính là những nét phác thảo quan trọng nhất trong đó, và chúng có tính phổ biến khá lớn.
Bản thân tôi thực ra đã xây dựng được khoảng một nửa kiến trúc như vậy. Trước đây chưa đạt đến quy mô phải giới thiệu Resolver thực sự, nhưng bây giờ đã đến giai đoạn đó, nên tôi vừa thực hiện một đợt tái cấu trúc nhỏ, khiến hệ thống của mình trở nên độc lập với mô hình, và tích hợp sẵn Resolver. Hiện tại phần then chốt tôi chưa xây dựng, là máy dò tín hiệu chạy tự động nền và vòng lặp dream cycle ban đêm, tức là cơ chế tự động bổ sung và tổ chức thông tin, đây là phần tôi muốn thử thêm vào tiếp theo.
Tôi nghi ngờ, việc những người xây dựng khác nhau đang hội tụ về cấu trúc tương tự, bản thân nó đã là một tín hiệu: hình thái này mặc dù chưa chắc áp dụng cho tất cả mọi người, nhưng nhìn chung có khả năng hữu ích. Ngay cả khi chi tiết triển khai cụ thể sẽ có sự khác biệt quan trọng, nhưng cấu trúc tổng thể này, đang được ngày càng nhiều người tự mình mò mẫm ra một cách độc lập.
Câu hỏi tôi vẫn luôn tự hỏi gần đây là: Làm thế nào để dùng AI thiết lập lợi thế cạnh tranh bền vững?
Mọi người đều rất hào hứng với các ứng dụng vibe-coded và prompt dùng một lần, điều đó tất nhiên rất tuyệt. Bản thân tôi ban đầu cũng bắt đầu bằng cách chơi như vậy, và vì thế mà đam mê. Nhưng bất cứ thứ gì có thể xây dựng thông qua prompt một lần, giá cân bằng cuối cùng của nó sẽ giảm xuống đến chi phí token cần thiết để xây dựng nó, tức là vài xu.
Ví dụ, ai đó sao chép MyFitnessPal, bán với một nửa giá và kiếm được 1 triệu USD, điều đó tất nhiên rất ấn tượng. Nhưng chẳng mấy chốc sẽ có người khác sao chép nó, và bán với giá thấp hơn. Vòng lặp này sẽ tiếp tục mãi, cho đến khi không gian lợi nhuận bị nén hoàn toàn.
Thứ thực sự bền vững, là một loại "năng lực quy trình". Dùng khuôn khổ "7 Powers" của Hamilton Helmer, kiến trúc trên ngầm ẩn chứa chính là sức mạnh quy trình (process power).
"7 Powers" đề xuất, lý do doanh nghiệp có thể duy trì tỷ suất lợi nhuận cao hơn mức trung bình thị trường trong thời gian dài, là vì nó sở hữu một trong bảy loại sức mạnh cấu trúc này. Bất kỳ lợi thế nào không bắt rễ từ những sức mạnh này, cuối cùng đều sẽ bị cạnh tranh xói mòn.
Đối với các doanh nghiệp vừa và nhỏ cùng công ty giai đoạn đầu, trong bảy sức mạnh của Helmer, có năm loại cơ bản là những cánh cửa đóng kín. Kinh tế theo quy mô cần quy mô; hiệu ứng mạng và chi phí chuyển đổi có thể xây dựng, nhưng cần tích lũy cơ sở người dùng khổng lồ trước; tài nguyên độc quyền thường có nghĩa là bằng sáng chế hoặc tài sản tương tự, đây không phải thứ mà đa số công ty có thể sở hữu; thương hiệu thường cần mười năm tích lũy, không thể đi tắt.
Hai loại còn lại, là định vị ngược (counter-positioning) và năng lực quy trình.
Định vị ngược chỉ một mô hình kinh doanh mà các gã khổng lồ hiện có không thể bắt chước, vì một khi bắt chước, sẽ làm tổn thương chính hoạt động kinh doanh vốn có của họ. Cơ hội này đôi khi tồn tại, nhưng không phải lúc nào cũng có được.
Như vậy, con đường thực tế nhất còn lại là năng lực quy trình. Và một hệ thống AI được thiết kế tốt, chính là công cụ có thể tạo ra năng lực quy trình.
Điều này về bản chất cùng một loại công việc với việc thiết lập SOP chất lượng cao hoặc phát triển phần mềm độc quyền nội bộ: quy trình được mã hóa, trường hợp được tham số hóa, hệ thống xác định tầng dưới nhanh chóng và đáng tin cậy, tầng bộ nhớ thì liên tục tiếp nhận những điều đã học được trong quá khứ. Nó khiến "dịch vụ hóa sản phẩm" được khuếch đại thêm: bạn có thể cung cấp một loại dịch vụ hoặc sản phẩm nào đó với chi phí thấp hơn hoặc chất lượng cao hơn, vì toàn bộ công việc đã được cấu trúc hóa.
Hãy tưởng tượng một kế toán viên xây dựng một hệ thống như vậy. Tầng bộ nhớ là một thư mục, mỗi khách hàng có một tệp markdown, bên trong bao gồm kết luận đáng tin cậy hiện tại, như cấu trúc pháp nhân, lập trường thuế hàng năm, cuộc kiểm toán đang tiến hành, cùng một dòng thời gian, ghi lại các cuộc họp, quyết định và những thay đổi xảy ra.
Cô ấy có một số Skill, như /year-end-review, /quarterly-estimate, /audit-prep. Cùng một bộ quy trình có thể được thực thi tham số hóa cho các khách hàng khác nhau.
Cô ấy còn có một tầng xác định, bao gồm biểu mẫu thuế, bảng khấu hao, tài liệu IRS, biểu mẫu thuế lịch sử của khách hàng...
Cộng thêm một cơ chế tương tự như tổ chức nhật ký hoặc dream cycle. Ví dụ, hệ thống tự động phát hiện vào ban đêm rằng phân bổ K-1 của một đối tác nào đó giảm 40% mà không có thay đổi chiến lược; hoặc nhận thấy cấu trúc khấu trừ văn phòng gia đình của một khách hàng nào đó, có thể di chuyển sang một khách hàng khác, cấu trúc có thể tái sử dụng, nhưng danh tính và quyền riêng tư vẫn ở nguyên chỗ cũ.
Bằng cách này, cô ấy có thể thu một khoản phí bảo hiểm nhỏ, phục vụ nhiều khách hàng hơn mỗi năm, trong khi đối thủ cạnh tranh khó sao chép, vì cấu trúc này không phải xuất hiện từ trên trời rơi xuống sau khi cô ấy thành công, mà đã tích lũy liên tục ngay từ đầu.
Nhìn bề ngoài, công cụ này chỉ là một thư mục markdown. Nhưng mỗi dòng trong mỗi tệp, đằng sau đều đến từ rất nhiều thử nghiệm, xây dựng và lặp lại có ý thức. Thứ thực sự tạo thành rào cản cạnh tranh, không phải bản thân các tệp, mà là năng lực quy trình mà những tệp này mang theo.
