WordPress.com chính thức cho phép AI tự động hóa nội dung

Mình đã nghe rất nhiều về repo gstack của CEO Y Combinator thế là tò mò cài vào thử, thứ khiến mình bất ngờ nhất không phải các workflow xịn mà là tư duy thật sự khác biệt của vị CEO này. Đó là lệnh đầu tiên trong cả hệ thống: /office-hours với sáu câu hỏi bắt đầu nhưng lại không hỏi về code chỉ hỏi những thứ mà hầu hết mọi người chưa trả lời được trước khi bắt tay vào build. gstack là gì và tại sao Garry Tan tạo ra nó gstack là bộ công cụ mã nguồn mở của Garry Tan, CEO Y Combinator, chủ yếu được thiết kế ra dành cho Claude Code. Ý tưởng cốt lõi của repo là thay vì dùng AI như một người viết code đơn thuần, Garry Tan muốn biến Claude thành cả một nhóm AI agent làm việc thu nhỏ, mỗi thành viên phụ trách một vai trò khác nhau từ người định hướng sản phẩm, kiểm tra bảo mật, đến người kiểm thử và phát hành. Toàn bộ quy trình chạy theo vòng lặp có thứ tự: suy nghĩ → lên kế hoạch → xây dựng → kiểm tra → thử nghiệm → phát hành → đánh giá lại . Cụ thể hơn, gstack chia Claude Code thành 23 vai trò chuyên biệt tất nhiên trong workflow kết quả của bước trước tự động được chuyển sang bước tiếp theo mà không cần bạn làm thủ công. Một số lệnh nổi bật như sau: /office-hours 6 câu hỏi buộc bạn suy nghĩ lại tính năng trước khi viết dòng code đầu tiên /plan-ceo-review tìm xem bạn đang làm quá nhiều hay quá ít so với thực tế cần /review bắt lỗi nghiêm trọng mà các công cụ kiểm tra tự động thông thường không thấy /qa mở trình duyệt thật, thao tác thật, tìm lỗi thật /cso chạy kiểm tra bảo mật theo chuẩn quốc tế tự động /ship đồng bộ, kiểm tra, đẩy code và tạo pull request trong một lệnh duy nhất Kết quả gstack hoạt động thế nào? Garry Tan cho biết tốc độ làm việc của ông năm 2026 nhanh hơn khoảng 810 lần so với năm 2013 khi đo bằng dòng code hoàn chỉnh mỗi ngày (11.417 so với 14 dòng). Trong 60 ngày, ông ship 3 dịch vụ production và hơn 40 tính năng, tất cả trong khi vẫn điều hành Y Combinator toàn thời gian. Andrej Karpathy, đồng sáng lập OpenAI, cũng chia sẻ rằng ông không gõ một dòng code nào kể từ tháng 12/2025 nhờ các tác nhân AI. Nhưng trong tất cả các lệnh đó, /office-hours là thứ đáng chú ý nhất vì một lý do ngược lại với phần còn lại, nó không giúp bạn làm việc nhanh hơn mà nó giúp bạn không làm nhầm thứ ngay từ đầu. Tại sao /office-hours lại được xếp đầu tiên Garry Tan đặt /office-hours ở đầu workflow vì một quan sát đơn giản: hầu hết các sản phẩm thất bại không phải vì code kém mà vì làm sai thứ mọi người cần. Họ bỏ hàng tuần viết một tính năng không ai cần, hoặc xây dựng đúng tính năng nhưng lại sai đối tượng, hoặc giải quyết một vấn đề mà người dùng đã có cách giải quyết tốt hơn từ lâu. Lệnh này có hai chế độ: Startup mode dành cho founder và người build sản phẩm thật, và Builder mode dành cho side project, hackathon, open source. Bài này tập trung vào Startup mode, nơi 6 câu hỏi được áp dụng đúng nghĩa nhất. 6 câu hỏi của /office-hours và tại sao mỗi câu đều đáng giá Đây không phải 6 câu hỏi để trả lời qua loa rồi tiếp tục đến các phần sau. Chúng được thiết kế để bạn suy nghĩ thật, vì câu trả lời càng trung thực thì kết quả Claude tạo ra càng bám sát đúng thứ bạn thực sự cần và bạn sẽ tiết kiệm được rất nhiều thời gian về sau. Bạn có thể xem nội dung gốc đầy đủ 6 cau hỏi tại office-hours/SKILL.md.tmpl. Demand reality: Nhu cầu có thật không? Câu hỏi gốc: "Ai cụ thể đang gặp vấn đề này? Họ đang giải quyết tạm bằng cách nào?" Không phải người dùng nói chung hay team marketing mà tác giả muốn hướng đến một người thật, có tên(càng tốt) đang vật lộn với vấn đề cụ thể là gì. Nếu bạn không biết được một người như vậy, bạn sẽ chưa thực sự hiểu họ cần gì. Ví dụ cụ thể: Thay vì "người dùng muốn quản lý task tốt hơn", phải là "Minh, project manager tại công ty 20 người, đang copy-paste giữa Notion và Google Sheet mỗi sáng thứ Hai vì hai tool không sync được." Tất nhiên đây là ví dụ mọi người tự áp dụng vào trường hợp của mình. Status quo: Họ đang dùng gì thay thế? Câu hỏi gốc: "Giải pháp thay thế tạm thời hiện tại của họ là gì? Bạn cần tốt hơn bao nhiêu để họ chịu đổi sang dùng giải pháp của bạn?" Mọi người đều đang giải quyết vấn đề theo một cách nào đó, dù là Excel, sticky note, hay nhóm chat WhatsApp. Nếu giải pháp hiện tại của họ đủ tốt, họ chẳng có lý do gì để chuyển dữ liệu và phải học sử dụng lại một nền tảng hoàn toàn mới, vì vậy giải pháp của bạn phải làm thực sự tốt hơn để họ còn cân nhắc. Desperate specificity: Ai đang cần giải pháp này đủ nhiều? Câu hỏi gốc: "Ai đang cần giải pháp đến mức có thể dùng bản beta xấu xí của bạn ngay hôm nay?" Đây là câu phân biệt "nice-to-have" và "must-have". Nếu bạn không tìm được ai sẵn sàng dùng một bản chưa hoàn chỉnh, chưa có UI đẹp, còn nhiều lỗi, thì vấn đề bạn đang giải quyết chưa đủ cấp bách. Người dùng thật của giai đoạn đầu là người cần đến mức họ chịu đựng được cả sản phẩm chưa đẹp nhưng có sửa đổi và hướng đi phù hợp. Narrowest wedge: Phần nhỏ nhất là gì? Câu hỏi gốc: "Phần nhỏ nhất có thể ra mắt ngày mai là gì? Không phải toàn bộ sản phẩm mà là phần nhỏ nhất." Không phải phiên bản đầu tiên đầy đủ tính năng mà là phần nhỏ hơn nữa. Câu hỏi này thường cắt bỏ 80% những thứ bạn tự thêm vào vì nghĩ "làm luôn cho tiện". Đây là lỗi mà mình rất hay bị khiến cho mọi thứ vượt tầm kiểm soát, phần này giúp mọi người ra mắt phần nhỏ nhất trước, lắng nghe phản hồi từ người dùng thật rồi mới quyết định mở rộng tiếp. Lưu ý: Nhiều người hay nhầm "phần nhỏ nhất" với "phiên bản đầu tiên đầy đủ tính năng". Thực ra phần nhỏ nhất đúng nghĩa có thể chỉ là tính năng nhỏ giải quyết một vấn đề duy nhất, cho một nhóm người dùng duy nhất, không hơn không kém. Observation and surprise: Bạn đã xem người thật dùng chưa? Câu hỏi gốc: "Bạn đã ngồi xem người thật dùng sản phẩm chưa? Họ dùng theo cách bạn không ngờ không?" Câu hỏi này có lẽ nên để cho vòng lặp thứ hai trở đi, khi bạn đã có bản thử nghiệm trong tay. Thay vì hỏi cảm nhận qua tin nhắn hay khảo sát, hãy ngồi xem trực tiếp hoặc xem lại video ghi màn hình khi họ dùng. Những phát hiện đáng giá nhất thường không phải từ lời họ nói mà từ những thao tác họ làm mà bạn không thiết kế, hoặc những bước họ bỏ qua dù bạn nghĩ là quan trọng. Lưu ý: Nếu bạn đang ở vòng đầu tiên và chưa có sản phẩm nào, mình nghĩ có thể bỏ qua câu này và quay lại sau khi đã ra mắt phần nhỏ nhất ở bước 4. Future-fit: Tầm nhìn 2 đến 3 năm Câu hỏi gốc: "2-3 năm nữa, thứ bạn đang build có còn phù hợp không, hay trend đang đi ngược lại?" Không phải để dự đoán tương lai chính xác, mà để tránh build thứ đang chết dần. Nếu xu hướng đang làm cho vấn đề bạn giải quyết trở nên ít cấp bách hơn trong 2 năm tới, đó chắc chắn là tín hiệu cần xem xét lại từ đầu còn nếu bạn muốn đánh nhanh thắng nhanh để tránh big tech ra sản phẩm giống hệt bạn thì hãy bỏ qua câu hỏi này. Ví dụ thực tế: một ý tưởng tưởng đơn giản bị lật ngược hoàn toàn Trong tài liệu của gstack, Garry Tan lấy một ví dụ rất thực tế. Bạn mở /office-hours và nói: "Tôi muốn làm một app tóm tắt lịch làm việc hàng ngày." Claude không đồng ý ngay và bắt đầu làm theo. Thay vào đó, nó phản hồi: thứ bạn vừa mô tả không chỉ là app tóm tắt lịch mà thực chất là một trợ lý cá nhân AI toàn diện. Hai thứ này khác nhau hoàn toàn về quy mô, độ phức tạp kỹ thuật và kỳ vọng của người dùng. Chỉ từ một câu mô tả ban đầu, /office-hours giúp bạn nhìn ra: 5 tính năng bạn đang mô tả mà chưa nhận ra 4 giả định cần kiểm chứng trước khi bắt tay làm 3 hướng triển khai khác nhau với mức độ phức tạp khác nhau 1 gợi ý: ra mắt phần nhỏ nhất trước, phần còn lại để làm dần về sau Toàn bộ quá trình đó xảy ra rồi cho ra kết quả sẽ được lưu lại thành tài liệu để các bước tiếp theo trong quy trình tự động đọc và tiếp tục. Khả năng mở rộng của 6 câu hỏi này ra ngoài repo gstack 6 câu hỏi của /office-hours không phụ thuộc vào Claude Code, không cần cài gstack. Chúng là tư duy, cách YC partners ngồi đánh giá startup, và bạn có thể áp dụng ngay hôm nay bằng bất kỳ công cụ AI nào đang dùng. Sự khác biệt khi dùng qua gstack là khi Claude sẽ không để bạn trả lời qua loa. Nó giúp Claude hiểu yêu cầu cụ thể hơn và nó không tiếp tục cho đến khi câu trả lời đủ thực tế. Đó là lý do vì sao/office-hours là skill đáng sợ nhất trong cả repo, không phải vì nó khó dùng, mà vì nó hỏi đúng thứ bạn đang bỏ qua. Thử ngay hôm nay: Trước khi làm sản phẩm tiếp theo, paste 6 câu hỏi trên vào Claude, Gemini, hay ChatGPT cùng với mô tả ý tưởng của bạn. Yêu cầu nó hỏi từng câu một và không cho phép bạn bỏ qua. Kết quả thường bất ngờ hơn bạn nghĩ, kể cả với những ý tưởng bạn đã nghĩ rất kỹ. gstack hiện có hơn 117k lượt star trên GitHub và vẫn đang tăng. Với mình, phần đáng giá nhất không phải các lệnh kỹ thuật như /review hay /ship, mà chính là /office-hours vì đây là lệnh duy nhất trong cả bộ công cụ buộc bạn dừng lại và suy nghĩ trước khi làm bất cứ điều gì.

Bài đăng của Thariq Shihipar từ team Claude Code đã gây chú ý lớn trong cộng đồng sử dụng AI. Anh ấy tiết lộ Dynamic Workflows, tính năng cho phép Claude tự thiết kế quy trình làm việc thay vì chỉ chờ lệnh, và đây được coi là bản nâng cấp quan trọng nhất kể từ khi Claude Code có skills và subagents. Tính năng này là khái niệm harness làm bản chất để giải thích các yêu cầu kĩ thuật. Ba lỗi chí mạng nào khiến AI agent thất bại ở nhiệm vụ phức tạp Trước khi nói về giải pháp, Thariq chỉ ra một thực tế khó chịu: hầu hết AI agent hiện nay đều gặp vấn đề nghiêm trọng khi xử lý nhiệm vụ phức tạp, đa bước trong một cửa sổ ngữ cảnh duy nhất. Ông phân loại chúng thành ba dạng thất bại cốt lõi mà gần như mọi hệ thống agent đều mắc phải. Khi AI lười biếng bằng cách tự tuyên bố xong dù mới làm nửa việc Đây là hiện tượng Agentic Laziness, khi agent thực hiện một phần công việc rồi tự báo cáo là đã hoàn thành. Ví dụ cụ thể: bạn yêu cầu agent review 50 file code, nhưng nó chỉ xem qua 20 file rồi kết luận rằng mọi thứ ổn. Nguyên nhân nằm ở giới hạn cửa sổ ngữ cảnh, khi lượng thông tin quá lớn, agent có xu hướng đi tắt để hoàn thành nhanh hơn. Agent sẽ tự thiên vị bản thân nó đúng không Agent tự thiên thị nó gọi là Self-Preferential Bias, điều này xảy ra khi bạn yêu cầu agent kiểm tra lại kết quả của chính nó. Giống như nhờ một học sinh tự chấm bài thi, agent có xu hướng nghiêng về phía kết quả mà nó đã tạo ra, dẫn đến xác nhận thiếu phê phán và bỏ qua các lỗi tiềm ẩn. Điều này đặc biệt nguy hiểm trong các nhiệm vụ đòi hỏi độ chính xác cao. Làm sao để agent không mất dần ý định ban đầu qua mỗi bước Hiện tượng trôi mất mục tiêu (Goal Drift) là hiện tượng agent dần quên mục tiêu ban đầu sau nhiều bước xử lý hoặc sau quá trình nén ngữ cảnh (context compaction). Những ràng buộc cụ thể như "không làm X" hoặc các trường hợp quan trọng có thể bị loại bỏ khi bộ nhớ bị tóm tắt lại vì vậy kết quả cuối cùng lệch khỏi yêu cầu gốc mà agent không hề nhận ra. Dynamic Workflows giúp Claude tự viết bộ khung điều phối công việc Giải pháp của Anthropic không phải là làm model thông minh hơn, mà là thay đổi cách Claude tổ chức công việc. Dynamic Workflows biến Claude từ agent viết code thành agent thiết kế quy trình vận hành cho công việc phức tạp. Khái niệm cốt lõi ở đây là tự tổ chức (self-organization): Claude có thể tự phân tích mục tiêu, chọn chế độ làm việc phù hợp và tạo ra quy trình nội bộ trước khi bắt tay vào thực hiện. Harness tùy chỉnh thay vì quy trình cố định Thay vì hoạt động trong một môi trường cố định, Claude viết một bộ khung harness bằng JavaScript được thiết kế riêng cho từng nhiệm vụ. Harness này đóng vai trò như một quản lý dự án: nó chia nhỏ công việc, khởi tạo các sub-agent chuyên biệt cho từng phần, chỉ định công cụ phù hợp, định tuyến công việc đến các model khác nhau và thực hiện xác minh đối kháng (adversarial verification) để đảm bảo chất lượng. Harness hoạt động như thế nào? Để hiểu rõ hơn, hãy hình dung harness như một kịch bản sân khấu mà Claude tự soạn trước khi diễn. Khi nhận được một nhiệm vụ phức tạp, Claude không lao vào làm ngay mà dừng lại để viết một đoạn JavaScript mô tả toàn bộ quy trình: cần bao nhiêu sub-agent, mỗi agent làm gì, thứ tự thực hiện ra sao và kết quả từ agent này được chuyển cho agent kia như thế nào. Ví dụ cụ thể: nếu bạn yêu cầu Claude audit 1.000 tin nhắn Slack để tìm sự cố lặp lại, harness có thể trông như thế này về mặt logic: Agent 1 (phân loại): đọc toàn bộ tin nhắn và gán nhãn theo chủ đề Agent 2, 3, 4 (xử lý song song): mỗi agent phân tích sâu một nhóm chủ đề riêng Agent 5 (tổng hợp): gom kết quả từ ba agent trên, loại bỏ trùng lặp Agent 6 (kiểm tra chéo): đọc lại kết quả tổng hợp và phản biện độc lập Điểm quan trọng là Claude viết harness này dựa trên đặc điểm cụ thể của từng nhiệm vụ, không phải theo một khuôn mẫu cứng nhắc. Nhiệm vụ khác nhau sẽ cho ra harness khác nhau, và đó chính là lý do tính năng này được gọi là "dynamic". Harness được viết bằng JavaScript và chạy trong môi trường Claude Code. Bạn có thể kích hoạt Dynamic Workflows bằng cách nói “use a workflow” tuy nhiên từ này rất dễ bị nhầm với workflow thông thường vì vậy mọi người nên dùng từ khóa "ultracode" trong câu lệnh thì sẽ phân rõ workflow thông thường và Dynamic Workflow để tiết kiệm token hơn. Cô lập ngữ cảnh để ngăn sự suy thoái của ngữ cảnh Một trong những thiết kế thông minh nhất của Dynamic Workflows là tính năng Isolation. Mỗi sub-agent được cấp cửa sổ ngữ cảnh riêng biệt, hoàn toàn độc lập với các agent khác. Điều này ngăn chặn hiện tượng suy thoái ngữ cảnh (context rot) tức sự suy giảm chất lượng khi ngữ cảnh bị quá tải, đồng thời triệt tiêu cả Agentic Laziness lẫn Goal Drift vì mỗi agent chỉ tập trung vào phần việc nhỏ được giao. Sáu mẫu điều phối có thể tái sử dụng Claude có thể kết hợp sáu mẫu điều phối sẵn có để xử lý đa dạng tình huống: Phân loại và hành động: phân loại đầu vào rồi chọn hành động phù hợp Phân chi và tổng hợp: chia công việc ra nhiều nhánh song song rồi tổng hợp kết quả Kiểm tra chéo: dùng agent khác kiểm tra chéo kết quả Tạo và lọc: tạo nhiều phương án rồi lọc ra phương án tốt nhất Tạo ra giải đấu: cho các phương án "đấu đối khảng trực tiếp với nhau rồi loại dần Vòng lặp: lặp lại cho đến khi đạt tiêu chuẩn chất lượng Có thể tối ưu chi phí khi sử dụng Dynamic Workflows không Chạy nhiều sub-agent song song nghe có vẻ tốn kém, nhưng thực tế Dynamic Workflows được thiết kế để tối ưu chi phí theo một số cách cụ thể. Định tuyến thông minh đến model phù hợp Không phải mọi bước trong quy trình đều cần model mạnh nhất. Harness cho phép Claude định tuyến từng tác vụ đến model phù hợp với độ phức tạp của nó: các bước phân loại đơn giản có thể chạy trên model nhỏ hơn và rẻ hơn, trong khi chỉ những bước đòi hỏi suy luận sâu mới cần đến model lớn. Kết quả là tổng chi phí thường thấp hơn so với việc chạy toàn bộ quy trình trên một model duy nhất. Cô lập ngữ cảnh giúp giảm token tiêu thụ Vì mỗi sub-agent chỉ nhận đúng phần ngữ cảnh cần thiết cho công việc của mình, tổng lượng token tiêu thụ trên toàn bộ quy trình thường thấp hơn đáng kể so với cách tiếp cận truyền thống, khi toàn bộ lịch sử hội thoại được nhồi vào một cửa sổ ngữ cảnh duy nhất ngày càng phình to. Tránh làm lại công việc nhờ kiểm tra lại sớm Harness có thể cài các điểm kiểm tra chất lượng (checkpoint) giữa các bước. Nếu một bước cho ra kết quả không đạt yêu cầu, hệ thống dừng và xử lý lại đúng bước đó thay vì chạy tiếp toàn bộ quy trình rồi mới phát hiện lỗi ở cuối. Cách này tiết kiệm đáng kể chi phí cho các tác vụ dài nhiều bước. Nếu bạn lo ngại về chi phí, hãy bắt đầu với các tác vụ có khối lượng vừa phải để quan sát mức tiêu thụ token thực tế trước khi mở rộng quy mô. Ứng dụng thực tế của Dynamic Workflow như thế nào Điều khiến Thariq hào hứng nhất không phải là khả năng code, mà là việc Dynamic Workflows mở rộng Claude Code sang các nhiệm vụ phi kỹ thuật. Tính năng này có thể kích hoạt bằng ngôn ngữ tự nhiên (ví dụ: "use a workflow") hoặc từ khóa "ultracode." Các ứng dụng thực tế bao gồm: Audit hàng nghìn tin nhắn trên Slack để tìm sự cố lặp lại Xếp hạng và sàng lọc bộ hồ sơ ứng viên lớn một cách có hệ thống Chạy giải đấu loại trực tiếp tự động để chọn tên tốt nhất cho CLI tool Xử lý các nhiệm vụ vận hành đòi hỏi độ chính xác cao mà trước đây chỉ con người mới làm được Triết lý thiết kế là ràng buộc kiến trúc thay vì trí tuệ thô Điểm đáng chú ý nhất trong cách tiếp cận của Anthropic là triết lý thiết kế: thay vì cố gắng tăng trí thông minh thô của model, họ xây dựng các ràng buộc kiến trúc (architectural constraints) vào quy trình làm việc. Nói cách khác, thay vì hy vọng model tự biết cách tránh lỗi, họ thiết kế hệ thống sao cho lỗi khó xảy ra ngay từ đầu, và harness chính là công cụ thực thi triết lý đó. Dynamic Workflows cho thấy bước tiến tiếp theo của AI agent không nằm ở model thông minh hơn mà ở khả năng tự thiết kế quy trình. Giống cách một quản lý giỏi phân chia công việc cho đội ngũ thay vì tự làm tất cả, Claude giờ đây có thể tự tổ chức đội ngũ sub-agent của mình, và đây là tín hiệu rõ ràng rằng tương lai của AI coding không chỉ còn là viết code nhanh hơn mà là tổ chức công việc tốt hơn.

Rất nhiều người vẫn nghiên cứu theo cách thủ công: mở hàng chục tab, xem video, đọc bài viết, ghi chú rời rạc rồi mất thêm thời gian tự tổng hợp. Bài viết long-form của monokern trên X gợi ý một cách làm khác: dùng Claude Code để điều phối, NotebookLM để phân tích nguồn và Obsidian để lưu trí nhớ dài hạn. Khi kết hợp đúng, đây không còn là một lần tìm kiếm thông tin mà trở thành một workflow AI có khả năng tích lũy qua từng phiên làm việc. Ý tưởng cốt lõi khá thực dụng: Claude Code không cần tự làm mọi thứ trong một context đắt đỏ. Nó có thể gọi công cụ, chạy skill, tạo file và chuyển phần xử lý nặng sang NotebookLM. Sau đó toàn bộ kết quả được lưu về Obsidian dưới dạng markdown để lần nghiên cứu tiếp theo có ngữ cảnh tốt hơn. Theo tác giả, phần thiết lập ban đầu có thể hoàn thành trong khoảng dưới 30 phút nếu máy đã có các công cụ cần thiết. Vì sao bộ ba này hoạt động tốt với nhau? Điểm mạnh của workflow này nằm ở việc mỗi công cụ chỉ đảm nhiệm một lớp rõ ràng. Claude Code đóng vai trò execution engine: nhận yêu cầu bằng ngôn ngữ tự nhiên, gọi skill, chạy lệnh, quản lý file và điều phối toàn bộ pipeline. Thay vì bắt người dùng thao tác từng bước, Claude Code trở thành người vận hành hệ thống. NotebookLM là lớp phân tích. Công cụ của Google có thể đọc nguồn, tóm tắt, tạo phân tích, flashcard, mindmap, infographic hoặc audio overview. Khi Claude Code đẩy phần đọc nguồn sang NotebookLM, người dùng tận dụng hạ tầng xử lý của Google thay vì đốt toàn bộ token Claude cho việc nghiền dữ liệu dài. Obsidian là lớp trí nhớ. Mọi kết quả sau khi phân tích được lưu thành markdown trong vault cá nhân. Qua thời gian, vault này trở thành kho tri thức có cấu trúc gồm chủ đề, nguồn, nhận định, pattern và kết luận. Claude Code có thể đọc lại các file đó để hiểu người dùng quan tâm điều gì, thích format nào và thường đánh giá vấn đề theo hướng nào. Skill Creator biến workflow thành công cụ tái sử dụng Phần quan trọng đầu tiên trong hướng dẫn là cài Skill Creator trong Claude Code. Đây là lớp cho phép người dùng mô tả một kỹ năng bằng ngôn ngữ tự nhiên, sau đó Claude Code tạo cấu trúc skill, cài đặt và biến nó thành lệnh có thể gọi lại. Nói cách khác, thay vì mỗi lần nghiên cứu lại prompt từ đầu, người dùng đóng gói thao tác thành một skill riêng. Ví dụ đầu tiên trong bài là tạo skill tìm kiếm YouTube. Skill này dùng yt-dlp để tìm video theo truy vấn, lấy metadata như tiêu đề, kênh, lượt xem, thời lượng, ngày đăng, URL và tỷ lệ view trên subscriber. Với nghiên cứu thị trường nội dung, dữ liệu này quan trọng hơn danh sách link thông thường vì nó cho biết nguồn nào đang thật sự thu hút sự chú ý. NotebookLM là nơi xử lý phần phân tích nặng Bài viết đề xuất kết nối Claude Code với NotebookLM thông qua dự án notebooklm-py vì NotebookLM chưa có public API chính thức. Sau khi cài và xác thực tài khoản Google, Claude Code có thể dùng skill riêng để tạo notebook mới, thêm nguồn như URL YouTube, văn bản hoặc file, rồi yêu cầu NotebookLM sinh phân tích hoặc deliverable. Điểm đáng chú ý là NotebookLM không chỉ tóm tắt. Trong một pipeline nghiên cứu thực tế, nó có thể nhận 10 video liên quan đến một chủ đề, phân tích xem framework nào đang tăng trưởng, framework nào bị thổi phồng, đâu là điểm tranh luận trong cộng đồng và khoảng trống nội dung nào chưa được ai khai thác tốt. Phần xử lý này tốn thời gian, nhưng chủ yếu diễn ra ở phía NotebookLM. Pipeline hoàn chỉnh: một lệnh để nghiên cứu cả chủ đề Khi đã có skill YouTube search và skill NotebookLM, bước tiếp theo là tạo một pipeline skill kết hợp cả hai. Người dùng chỉ cần đưa chủ đề, ví dụ nghiên cứu các AI agent framework trong năm 2026, rồi pipeline sẽ tự tìm nguồn liên quan, tạo notebook, thêm nguồn, chạy phân tích và trả kết quả thành markdown. Trong ví dụ của monokern, pipeline tìm 10 nguồn video, đẩy sang NotebookLM, tạo phân tích, sinh infographic và lưu lại kết quả vào Obsidian. Tổng thời gian xử lý được mô tả khoảng 6 phút, trong đó phần lớn là thời gian NotebookLM xử lý nguồn. Giá trị thực tế nằm ở việc người dùng không phải tự mở từng tab, copy từng link hay tự tổng hợp metadata. Kết quả cuối cùng không chỉ là một đoạn trả lời trong chat. Nó gồm phân tích đầy đủ, danh sách nguồn, chỉ số tương tác, nhận định về xu hướng, deliverable trực quan và file markdown được lưu vào vault. Đây là điểm khiến workflow này khác với một chatbot hỏi đáp thông thường. Obsidian khiến hệ thống thông minh hơn theo thời gian Phần thú vị nhất là Obsidian. Nếu chỉ chạy một lần, workflow này đã tiết kiệm thời gian. Nhưng nếu chạy đều đặn, mỗi file markdown mới sẽ làm kho tri thức cá nhân dày hơn. Sau một tháng, Claude Code có thể nhìn thấy các chủ đề bạn quay lại nhiều lần, loại insight bạn đánh giá cao và cách bạn muốn dữ liệu được trình bày. Tác giả cũng nhấn mạnh vai trò của file claude.md trong vault. Đây có thể trở thành nơi mô tả quy ước làm việc, phong cách phân tích và format đầu ra mong muốn. Sau mỗi vài phiên nghiên cứu, người dùng có thể yêu cầu Claude Code đọc lại kết quả gần đây và cập nhật file này để phản ánh cách làm việc mới. Điểm mạnh thật sự là cấu trúc, không phải YouTube YouTube chỉ là nguồn dữ liệu trong ví dụ. Cấu trúc pipeline mới là phần có giá trị. Người dùng có thể thay YouTube bằng PDF học thuật, báo cáo ngành, tài liệu public, trang web, file local, transcript hoặc tài liệu Google Drive. Miễn là Claude Code có cách truy cập và đưa nguồn vào lớp phân tích, template vận hành vẫn giữ nguyên. Điều này mở ra nhiều ứng dụng thực tế: nghiên cứu một hệ sinh thái crypto bằng whitepaper và tài liệu public, phân tích một công nghệ mới qua talk hội nghị, tìm khoảng trống nội dung trong một niche, hoặc theo dõi động lực thị trường từ báo cáo công khai. Với mỗi trường hợp, pipeline vẫn gồm ba lớp: lấy nguồn, phân tích, lưu tri thức. Cần lưu ý gì trước khi áp dụng? Workflow này mạnh nhưng không phải dành cho mọi người. Nó yêu cầu người dùng quen với Claude Code, có Obsidian vault, biết cài công cụ CLI như yt-dlp và chấp nhận dùng một thư viện không chính thức để kết nối NotebookLM. Ngoài ra, vì NotebookLM và YouTube có thể thay đổi giao diện hoặc hạn chế truy cập, các skill nên được xem như công cụ cần bảo trì chứ không phải giải pháp cài một lần mãi mãi. Dù vậy, ý tưởng đằng sau rất đáng chú ý: thay vì dùng AI như một hộp chat rời rạc, hãy biến AI thành một hệ thống nghiên cứu có bộ nhớ, có pipeline và có khả năng học từ lịch sử làm việc của chính bạn. Với những người thường xuyên phân tích thị trường, công nghệ hoặc nội dung, đây là một hướng triển khai thực dụng hơn rất nhiều so với việc mở 10 tab rồi tự tổng hợp mọi thứ bằng tay.

Hãy tưởng tượng bạn có một trợ lý AI vô cùng thông minh nhưng lại rất nhanh quên và không tự kiểm tra được chất lượng công việc của mình. Để giải quyết vấn đề này, các nhà phát triển đã tạo ra một lớp bảo vệ và quản lý bao quanh mô hình AI mang tên agent harness. Đây chính là thứ giúp các trợ lý AI tự động hoàn thành những nhiệm vụ phức tạp mà không cần sự can thiệp liên tục từ con người. Agent harness là gì? Để dễ hình dung, hãy tưởng tượng mô hình AI giống như một nhân viên mới cực kỳ thông minh nhưng lại có trí nhớ rất ngắn hạn và hoàn toàn xa lạ với môi trường làm việc. Nhân viên này có thể giải quyết các bài toán phức tạp trong tích tắc nhưng lại dễ quên mình đang làm gì hoặc vô tình gửi nhầm tài liệu quan trọng cho khách hàng. Trong tình huống đó, agent harness đóng vai trò như một người quản lý giàu kinh nghiệm ngồi ngay bên cạnh để hướng dẫn và giám sát. Nói đơn giản hơn, agent harness là lớp phần mềm bao bọc bên ngoài mô hình AI, đảm nhận mọi công việc hành chính và hậu cần để AI chỉ cần tập trung vào việc suy nghĩ và đưa ra giải pháp. Lớp này kết nối AI với các công cụ bên ngoài, ghi chép lại toàn bộ lịch sử công việc qua nhiều ngày và kiểm tra chất lượng kết quả trước khi coi là xong. Về mặt thực tế, một agent harness thực hiện các nhiệm vụ sau: Kết nối mô hình AI với các công cụ bên ngoài như tìm kiếm web, hòm thư điện tử hay lịch làm việc Lưu trữ toàn bộ tiến trình công việc để AI không phải bắt đầu lại từ đầu ở phiên làm việc tiếp theo Lọc bớt thông tin dư thừa và chỉ cung cấp những dữ liệu cần thiết nhất cho AI tại mỗi bước Giám sát các hành động của AI nhằm ngăn chặn những sai sót nguy hiểm Ghi lại nhật ký hoạt động chi tiết để con người dễ dàng kiểm tra khi cần Nguồn gốc thuật ngữ: Khái niệm "agent harness" được chuyên gia công nghệ Mitchell Hashimoto chính thức đặt tên vào đầu năm 2026. Trước đó, nhiều nhóm phát triển đã xây dựng các hệ thống tương tự nhưng chưa có tên gọi chung cho lớp hạ tầng này. Vì sao AI hay thất bại khi làm việc dài hơi? Điểm yếu lớn nhất của các mô hình AI hiện nay là chúng hoàn toàn không có ký ức dài hạn. Khi bạn mở một cuộc trò chuyện mới, AI bắt đầu từ con số không và không nhớ bất kỳ thông tin nào từ các cuộc trò chuyện trước. Hãy tưởng tượng bạn thuê một nhân viên mà mỗi buổi sáng thức dậy đều quên sạch mọi thỏa thuận và tiến độ công việc từ hôm qua. Khi Anthropic thử nghiệm cho Claude xây dựng một ứng dụng web phức tạp mà không có harness hỗ trợ, kết quả rất đáng thất vọng. Hai lỗi liên tục xuất hiện: AI cố gắng làm tất cả cùng một lúc, bộ nhớ bị quá tải giữa chừng và bỏ dở dự án. Phiên tiếp theo lại tốn thời gian đoán xem đã làm được đến đâu. AI tự tuyên bố hoàn thành công việc mà không chạy thử xem kết quả có thực sự hoạt động hay không. Ngoài hai lỗi trên, việc thực hiện các dự án dài hạn còn khiến AI gặp thêm các vấn đề sau: Bộ nhớ làm việc bị tắc nghẽn: Hàng loạt thông tin phụ tích tụ theo thời gian khiến AI dần mất tập trung vào mục tiêu ban đầu Sử dụng công cụ sai cách: AI đôi khi tìm kiếm thông tin không tồn tại hoặc điền sai thông tin vào biểu mẫu, và nếu không có gì chặn lại sẽ lặp đi lặp lại cùng một lỗi Mất toàn bộ tiến trình khi gặp sự cố: Bất kỳ lỗi mạng hay sự cố hệ thống nào cũng xóa sạch những gì đang lưu trong bộ nhớ tạm Nghiên cứu của Stanford (2023): Các mô hình AI thường bỏ qua thông tin nằm ở giữa một văn bản dài, kể cả khi văn bản đó không quá dài. Đây là lý do vì sao việc nạp quá nhiều dữ liệu vào AI cùng lúc thường phản tác dụng nếu không có bộ lọc hỗ trợ. Agent harness hoạt động ra sao trong thực tế? Một agent harness hoạt động qua hai giai đoạn riêng biệt để đảm bảo công việc diễn ra liên tục và không bị gián đoạn. Giai đoạn chuẩn bị (chỉ diễn ra một lần) Harness thiết lập toàn bộ môi trường làm việc trước khi AI bắt đầu: lập danh sách các việc cần làm, chuẩn bị nơi lưu trữ dữ liệu và ghi lại điểm xuất phát. Giống như người quản lý lập kế hoạch chi tiết trước khi giao việc cho nhân viên, giai đoạn này chỉ cần thực hiện một lần duy nhất. Giai đoạn thực thi (lặp lại nhiều lần) Mỗi khi AI bắt đầu một phiên làm việc mới, harness tự động tải lại toàn bộ tiến độ đã lưu và chỉ giao đúng phần việc tiếp theo. Khi AI muốn thực hiện một hành động như tìm kiếm thông tin hay gửi thông báo, harness kiểm tra độ an toàn của yêu cầu đó trước khi thực hiện, làm sạch kết quả trả về rồi mới đưa lại cho AI xử lý tiếp. AI không bao giờ tương tác trực tiếp với hệ thống bên ngoài mà không qua lớp kiểm soát này. Bốn bộ phận quan trọng tạo nên một agent harness Để giúp AI hoạt động ổn định trong thời gian dài, một agent harness tiêu chuẩn cần có bốn thành phần cốt lõi: Cổng kết nối công cụ bên ngoài: Cho phép AI tương tác với thế giới thực như đọc tài liệu, tìm kiếm web hay gửi thông báo. Harness đóng vai trò trung gian, kiểm tra mỗi yêu cầu trước khi thực hiện và đảm bảo kết quả trả về sạch sẽ, dễ xử lý. Bộ quản lý ký ức nhiều tầng: Duy trì ba loại bộ nhớ phục vụ nhu cầu khác nhau gồm ký ức tạm thời trong phiên hiện tại, nhật ký công việc đang thực hiện và kho kiến thức tích lũy lâu dài qua nhiều dự án. Bộ lọc thông tin thông minh: Tóm tắt lịch sử hội thoại dài thành các ý chính và chỉ cung cấp đúng phần dữ liệu liên quan đến bước hiện tại thay vì nạp tất cả cùng lúc, giúp AI luôn tập trung vào đúng nhiệm vụ. Bộ kiểm tra an toàn và phê duyệt: Tự động xác nhận kết quả trước khi coi tác vụ là hoàn thành. Với các hành động nhạy cảm như xóa dữ liệu quan trọng hay gửi email hàng loạt, harness dừng lại và yêu cầu con người xác nhận trước khi tiếp tục. Lưu ý về dữ liệu tích lũy: Nếu kho ký ức của AI được lưu trữ hoàn toàn trên nền tảng đóng của bên thứ ba, bạn có nguy cơ mất toàn bộ kiến thức tích lũy khi muốn chuyển sang hệ thống khác. Đây là điều cần cân nhắc kỹ khi chọn giải pháp AI agent cho công việc lâu dài. Harness engineering và bí quyết tạo ra hàng triệu dòng code Harness engineering là cách tiếp cận xem mỗi thất bại của AI là một lỗi hệ thống cần khắc phục triệt để, không phải thứ cần thử lại hay bỏ qua. Theo Mitchell Hashimoto, nếu AI mắc lỗi, hãy thiết kế lại môi trường để về mặt vật lý nó không thể mắc lỗi đó nữa. Trong thực tế, khi OpenAI xây dựng các dự án phần mềm lớn với ba kỹ sư tạo ra 3,5 pull request mỗi người mỗi ngày mà không gõ một dòng code nào, họ đã thiết lập cơ chế kiểm tra tự động sau mỗi hành động của AI. Khi AI chạy sai, hệ thống trả về thông báo lỗi được viết theo cấu trúc đặc biệt để AI hiểu ngay mình cần sửa đổi gì ở bước tiếp theo. Mỗi thông báo lỗi trở thành ngữ cảnh học tập, không chỉ là cảnh báo. Một nghiên cứu tại hội thảo ICML năm 2025 cũng chứng minh rằng cùng một mô hình AI khi được trang bị harness luôn vượt trội so với chính nó khi chạy không có harness, kể cả khi không thay đổi gì về cách huấn luyện hay câu lệnh đầu vào. Điều này khẳng định môi trường xung quanh AI quan trọng không kém bản thân model. Góc nhìn thực tế: Claude Code của Anthropic hiện đã vượt 512.000 dòng lập trình và con số này tiếp tục tăng. Model ngày càng mạnh hơn không làm cho harness trở nên đơn giản hơn mà ngược lại, lớp hạ tầng này phát triển thêm để tận dụng tối đa những khả năng mới. Khi nào bạn thực sự cần đến agent harness? Với những việc đơn giản như tóm tắt một tài liệu hay trả lời câu hỏi cụ thể, dùng AI trực tiếp là đủ. Nhưng ngay khi công việc bắt đầu kéo dài hơn một cuộc trò chuyện, cần nhớ thông tin từ lần trước hoặc phải thực hiện nhiều bước theo thứ tự nhất định, đó là lúc harness trở nên cần thiết. Một điểm đáng để suy nghĩ: ngay cả tính năng tìm kiếm web tích hợp sẵn trong ChatGPT hay Gemini cũng chính là một dạng harness. Khi AI tự động tra cứu thông tin, có một lớp hạ tầng phía sau đang thực hiện lệnh gọi công cụ, xử lý kết quả và đưa thông tin sạch vào ngữ cảnh. Harness vô hình với người dùng nhưng không thể thiếu với hệ thống. Agent harness không phải xu hướng kỹ thuật ngắn hạn mà là giải pháp cho những giới hạn cốt lõi của AI: không có ký ức dài hạn, bộ nhớ làm việc có giới hạn và dễ mắc lỗi khi dùng công cụ bên ngoài. 4aivn cũng bất đầu áp dụng Harness vào trong công việc bên mình điều này không chỉ giúp AI hoàn thành tác vụ mà còn biến AI thành hệ thống có thể học từ thất bại và cải thiện theo thời gian.