Quay lại trang tin tức

Tư duy CEO Y Combinator về 6 câu hỏi để bắt đầu dự án

Xuất bản vào 27 tháng 06, 2026
Tư duy CEO Y Combinator về 6 câu hỏi để bắt đầu dự án

Tóm tắt nhanh

Garry Tan, CEO của Y Combinator, vừa công bố gstack thu hút 116.000 sao trên GitHub. Bộ công cụ biến Claude Code thành đội ngũ 23 chuyên gia ảo, nhưng giá trị lớn nhất nằm ở 6 câu hỏi "ép buộc" trong quy trình /office-hours. Những câu hỏi này ép bạn xác định nỗi đau thực sự, chân dung người dùng cụ thể và giải pháp hẹp nhất có thể ship ngay, thay vì chạy theo tính năng. Phương pháp luận được đúc kết từ hàng nghìn startup tại YC, giúp Garry Tan đạt năng suất gấp 810 lần so với năm 2013.

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

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.

6 câu hỏi /office-hours trong gstack của Garry Tan CEO Y Combinator
6 câu hỏi /office-hours trong gstack của Garry Tan CEO Y Combinator

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ì.

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.

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.

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.

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ì.

Thảo luận (0)

Đăng nhập để tham gia thảo luận.

Chưa có bình luận nào. Hãy là người đầu tiên!

Các bài viết liên quan

Claude Opus 5 ra mắt với sức mạnh áp sát Fable 5

Anthropic vừa ra mắt Claude Opus 5 với mức giá giữ nguyên như Opus 4.8 nhưng chất lượng trả lời được nâng lên gần bằng Fable 5, model đắt gấp đôi. Nói cách khác, với mức giá bằng một nửa Fable 5 mà hiệu năng lại áp sát, phần lớn người dùng nhiều khả năng sẽ chọn Opus 5 làm model mặc định, chỉ giữ Fable 5 cho số ít tác vụ thật sự cần đến giới hạn cao nhất. Claude Opus 5 mang đến những nâng cấp nào? Theo thông báo ra mắt của Anthropic, Claude Opus 5 là model Opus mạnh nhất tính đến nay và là đại diện đầu tiên của dòng Opus thuộc thế hệ Claude 5. Anthropic mô tả đây là model chủ động, biết suy nghĩ sâu và tiến gần trí tuệ cấp cao nhất của Claude Fable 5 trong nhiều lĩnh vực, nhưng chỉ tốn một nửa chi phí token. Model có mã API claude-opus-5, context mặc định và tối đa 1 triệu token, tương tự Opus 4.8 và Fable 5, cùng giới hạn đầu ra 128.000 token và chế độ thinking được bật mặc định. Nó đã trở thành model mặc định trên Claude Max và là model mạnh nhất khả dụng trên Claude Pro, đồng thời có mặt trên Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry và cả GitHub Copilot. Vì sao nhiều người sẽ chọn Opus 5 thay vì Fable 5? Câu trả lời không chỉ nằm ở con số giá. Có bốn lý do khiến Opus 5 nhiều khả năng trở thành lựa chọn mặc định cho công việc hằng ngày, trong khi Fable 5 lùi về vai trò công cụ chuyên dụng cho số ít trường hợp đặc biệt. Thắng nhiều hơn thua trên các bài kiểm tra thực tế Trên Frontier-Bench v0.1, bài kiểm tra coding tự động của chính Anthropic, Opus 5 đạt 43,3% trong khi Fable 5 chỉ đạt 33,7%, một khoảng cách gần 10 điểm nghiêng hẳn về Opus 5. Trên CursorBench 3.2 ở mức effort tối đa, Opus 5 đạt khoảng 70,1%, thua Fable 5 chưa tới nửa điểm phần trăm nhưng chi phí chỉ bằng một nửa. Tính chung trên các bài kiểm tra mà cả hai model đều có số liệu, Opus 5 thắng nhiều hơn thua và phần thắng thường lớn hơn phần thua. Cách kiểm chứng nhanh nhất: chạy cùng một tác vụ trên cả hai model ở effort tương đương, rồi so sánh chất lượng đầu ra thay vì chỉ nhìn benchmark được công bố. Không bị ép giữ dữ liệu 30 ngày Fable 5 và Mythos 5 thuộc nhóm Covered Models, bắt buộc lưu giữ prompt và kết quả trong 30 ngày để phục vụ công tác an toàn, đồng thời không hỗ trợ zero data retention (ZDR) trên bất kỳ nền tảng nào, kể cả khi tổ chức đã có thỏa thuận ZDR từ trước. Ngược lại, Opus 5 vẫn vận hành được dưới ZDR như Opus 4.8. Với các đội ngũ xử lý dữ liệu pháp lý, y tế hoặc tài chính, riêng điểm này đã đủ để loại Fable 5 khỏi danh sách lựa chọn mà không cần so hiệu năng. Ít bị gián đoạn bởi bộ lọc an toàn Anthropic cho biết bộ phân loại an ninh mạng của Opus 5 can thiệp ít hơn khoảng 85% so với Fable 5. Với các coding agent chạy nhiều giờ hoặc qua đêm, việc bị chặn giữa chừng vì request chạm ngưỡng an toàn là rủi ro thực sự làm gián đoạn quy trình, và Opus 5 giảm đáng kể tần suất đó. Effort điều chỉnh được, ngân sách dễ đoán hơn Opus 5 hỗ trợ adaptive thinking với effort từ thấp đến tối đa. Mức thấp hoặc trung bình phù hợp cho phản hồi nhanh và khối lượng lớn, còn mức cao hoặc tối đa dành cho coding phức tạp, nghiên cứu sâu và quy trình nhiều bước. Vì phải trả tiền theo effort đã chọn thay vì bị khóa vào một mức giá cố định như Fable 5, đội ngũ có thể tối ưu ngân sách theo từng loại tác vụ thay vì trả giá cao nhất cho mọi request. Cảm nhận ban đầu sau khi dùng thử Opus 5 Sau khi dùng thử Opus 5 cho công việc viết lách và xử lý code hằng ngày, cảm nhận rõ nhất là model này thông minh hơn hẳn Opus 4.8, đặc biệt ở khả năng hiểu ý đồ ngay từ lần yêu cầu đầu tiên mà không cần giải thích lại nhiều lần. Với các tác vụ như tóm tắt tài liệu dài, viết code có logic rẽ nhánh phức tạp hoặc lên kế hoạch nhiều bước, Opus 5 xử lý mượt và ít khi đi lạc đề như bản cũ thường gặp. So với Fable 5 thì vẫn có khoảng cách, dù không lớn như tưởng tượng. Ở những tác vụ đòi hỏi suy luận sâu hoặc phải tự chủ qua nhiều bước liên tiếp mà không có ai can thiệp, Fable 5 vẫn xử lý chắc tay và ít sai sót hơn một chút. Nhưng với phần lớn công việc hằng ngày, mức chênh lệch đó khó nhận ra nếu không đặt hai model cạnh nhau để so sánh trực tiếp. Nếu bạn đang dùng Opus 4.8, đây là thời điểm hợp lý để nâng cấp. Còn nếu đang cân nhắc giữa Opus 5 và Fable 5 cho công việc thông thường, Opus 5 gần như đủ dùng mà không cần trả thêm tiền. Khi nào Fable 5 vẫn là lựa chọn đúng? Fable 5 vẫn giữ được lợi thế ở đúng những chỗ khó nhất. Trên SWE-bench Pro, bộ kiểm tra dùng vấn đề GitHub có thật và được xem là thước đo khắt khe nhất cho công việc coding thực tế, Fable 5 đạt khoảng 80% trong khi Opus 5 đạt khoảng 79%, một khoảng cách nhỏ nhưng vẫn nghiêng về Fable 5. Fable 5 cũng là model duy nhất Anthropic định vị ở cấp Mythos, tức năng lực tổng thể cao hơn Opus theo thiết kế, và điều này thể hiện rõ ở các lĩnh vực chuyên sâu như phân tích y tế chuyên môn hoặc nghiên cứu tự chủ kéo dài nhiều ngày mà không có người giám sát. Nói cách khác, phần thắng của Opus 5 tập trung ở công việc coding và xử lý tri thức hằng ngày, còn lợi thế của Fable 5 nằm ở những bài toán khó nhất và các lĩnh vực đòi hỏi độ tin cậy tuyệt đối. Với đa số người dùng và đội ngũ nhỏ, những bài toán đó chiếm tỷ trọng rất nhỏ trong công việc thường ngày, nên khoản chênh lệch giá gấp đôi khó biện minh được, trừ khi công việc của bạn rơi đúng vào nhóm này. So sánh nhanh Opus 5 và Fable 5 Tiêu chíClaude Opus 5Claude Fable 5 Giá đầu vào5 USD/triệu token10 USD/triệu token Giá đầu ra25 USD/triệu token50 USD/triệu token Context1 triệu token1 triệu token Đầu ra tối đa128.000 token128.000 token Frontier-Bench v0.1 (coding agent)43,3%33,7% SWE-bench Pro (coding thực tế)~79%~80% Lưu giữ dữ liệuHỗ trợ zero data retentionBắt buộc lưu giữ 30 ngày, không có ZDR Tần suất chặn bởi bộ lọc an toànThấp hơn khoảng 85%Cao hơn Phù hợp nhấtCông việc hằng ngày, coding agent, dữ liệu nhạy cảmNghiên cứu khó, dự án tự chủ dài ngày, phân tích y tế chuyên sâu Vậy Opus 5 có thật sự đọ được với GPT-5.6? Trên giấy tờ, câu trả lời là có, nhưng không phải toàn diện. Opus 5 dẫn trước GPT-5.6 Sol ở khả năng suy luận với tình huống mới, thao tác máy tính và phần lớn bài kiểm tra coding công khai, trong khi GPT-5.6 Sol vẫn nhỉnh hơn ở một số bài kiểm tra thao tác dòng lệnh và tìm kiếm thông tin. Không bên nào thắng tuyệt đối, nhưng lần đầu tiên một model tầm giá trung của Anthropic đứng ngang hàng, thậm chí nhỉnh hơn ở nhiều mặt so với model đầu bảng của OpenAI. Câu hỏi đáng quan tâm hơn không phải model nào mạnh hơn mà là model nào thực sự phù hợp với bạn. Nếu công việc hằng ngày xoay quanh code, tài liệu dài và tác vụ nhiều bước, Opus 5 đang là lựa chọn hợp lý cả về giá lẫn chất lượng. Còn nếu bạn đã quen với hệ sinh thái OpenAI hoặc cần đúng thế mạnh của GPT-5.6, chi phí chuyển đổi có thể không đáng để thay đổi. Cách trả lời chắc chắn nhất vẫn là tự chạy thử cùng một việc trên cả hai, vì bảng benchmark không phải lúc nào cũng phản ánh đúng trải nghiệm thật.

Nam
25 thg 7, 2026
Gemini 3.6 Flash ra mắt nhưng thực chiến gây thất vọng

Google công bố Gemini 3.6 Flash ngày 21/7/2026 với hàng loạt điểm benchmark tăng vọt so với 3.5 Flash: DeepSWE từ 37% lên 49%, MLE Bench từ 49,7% lên 63,9% và OSWorld Verified đạt 83%. Nhưng trải nghiệm sử dụng thực tế của 4AIVN lại kể một câu chuyện khác hẳn: model xử lý việc nhỏ khá ổn, còn khi được giao một kế hoạch nhiều bước thì lại quên mục tiêu, bỏ sót bước và đi lệch hướng giữa chừng. Benchmark tăng mạnh nhưng không phản ánh đúng việc dùng thật Theo thông báo chính thức của Google, Gemini 3.6 Flash dùng ít hơn 17% token đầu ra so với 3.5 Flash trên Artificial Analysis Index; một số bài test như DeepSWE ghi nhận mức giảm token tới 65%. Cửa sổ đầu vào của model đạt 1.048.576 token và giới hạn đầu ra là 65.536 token, những con số nghe rất ấn tượng trên giấy. Vấn đề nằm ở chỗ tất cả những con số này đều đến từ các bài test được thiết kế sẵn, có mục tiêu cố định ngay từ đầu và chạy trong một phiên ngắn. Đó không phải cách một plan thực tế vận hành, vì công việc thật luôn cần điều chỉnh liên tục theo phản hồi, chứ không phải hoàn thành xong một lượt là kết thúc. Bám plan dài là điểm yếu chí mạng Trong trải nghiệm sử dụng thực tế, Gemini 3.6 Flash thể hiện quá kém ngay khi bước ra khỏi phạm vi một task đơn lẻ. Giao việc nhỏ, có bước kiểm tra rõ ràng thì model làm tốt và ít vòng lặp thừa. Nhưng khi được giao một kế hoạch nhiều bước, model bắt đầu quên mục tiêu ban đầu, bỏ sót các bước đã thống nhất từ trước hoặc tự ý đi lệch hướng sau vài lượt trao đổi. Khi được nhắc lại, model đôi khi chỉ xin lỗi rồi lặp lại đúng lỗi cũ thay vì thực sự sửa. Cửa sổ 1 triệu token mô tả sức chứa đầu vào, không phải khả năng ghi nhớ. Model có thể “nhìn thấy” toàn bộ context nhưng vẫn bỏ sót chi tiết khi thực hiện; chỉ cần một điểm nhỏ không được chú ý là kế hoạch có thể lệch hướng ngay. Đây không phải lỗi ngẫu nhiên hiếm gặp mà là điểm yếu lặp lại đủ nhiều để không thể bỏ qua. Nói cách khác, Gemini 3.6 Flash mạnh ở việc làm nhanh một tác vụ, nhưng chưa đáng tin khi phải thực hiện đúng một chuỗi tác vụ, và đó chính là khoảng cách mà benchmark không đo được. Giá giảm 17% nhưng chất lượng chưa chắc tương xứng Giá niêm yết của Gemini 3.6 Flash là 1,50 USD cho một triệu token đầu vào và 7,50 USD cho một triệu token đầu ra, giảm khoảng 17% so với mức 9 USD của 3.5 Flash. Nghe qua, đây là một bước tiến hợp lý: rẻ hơn mà benchmark lại cao hơn. Nhưng nếu chất lượng thực thi trên các tác vụ dài lại kém, phần tiết kiệm chi phí trên giấy có thể bị nuốt gọn bởi số lần phải nhắc lại, sửa lại hoặc chạy lại toàn bộ kế hoạch từ đầu. Gemini 3.5 Flash Lite còn rẻ hơn, với giá 0,30 USD cho một triệu token đầu vào và 2,50 USD cho đầu ra, nhưng đó là lựa chọn dành cho phân loại và chuyển đổi dữ liệu đơn giản, những việc không đòi hỏi model phải nhớ một kế hoạch dài. Được gì, mất gì khi dùng Gemini 3.6 Flash? Nhìn một cách khách quan, đây không phải là một bản nâng cấp thất bại. Google có lẽ đã tính toán rất kỹ để tối ưu giữa chất lượng đầu ra, tốc độ và chi phí, dù kết quả thực tế chưa hẳn đáp ứng kỳ vọng cao dành cho đội ngũ kỹ sư của họ. Những cải thiện này hoàn toàn rõ ràng chứ không chỉ dừng lại trên lý thuyết: tốc độ phản hồi nhanh hơn, chi phí đầu ra giảm đáng kể và với các tác vụ ngắn, phạm vi hẹp như phân loại nội dung, viết một hàm code đơn lẻ hoặc giải quyết một câu hỏi cụ thể, model xử lý rất gọn gàng, hạn chế các vòng lặp thừa. Nhưng cái giá phải trả lộ ra ngay khi công việc kéo dài quá một vài bước. Model càng phải giữ nhiều ràng buộc và nhớ nhiều quyết định đã thống nhất trước đó thì tỷ lệ đi lệch càng tăng. Với coding agent hoặc quy trình dài đang chạy ổn định trên Claude Fable 5 hoặc GPT 5.6, chưa có lý do đủ thuyết phục để đổi sang Gemini 3.6 Flash chỉ vì benchmark hoặc giá thấp hơn. Vẫn phải chờ Gemini 3.5 Pro Google cho biết Gemini 3.5 Pro vẫn đang được thử nghiệm cùng các đối tác và sẽ được phát hành rộng rãi khi sẵn sàng. Vì vậy, câu chuyện cốt lõi của đợt phát hành này nằm ở khoảng cách khá xa giữa benchmark và thực tế công việc. Với những ai đang tìm kiếm một agent đủ tin cậy cho các quy trình dài hạn, có lẽ họ vẫn phải kiên nhẫn chờ xem 3.5 Pro có tạo nên bước ngoặt mới hay không. Nếu các phiên bản tiếp theo tiếp tục thể hiện mờ nhạt trong thực chiến, Google có nguy cơ tự tay nhường lợi thế cho các đối thủ như Anthropic, OpenAI và Meta.

Nam
23 thg 7, 2026
Hermes Agent và MCP: Tự động hóa workflow thực tế

Một AI agent có thể lập kế hoạch rất tốt nhưng vẫn không thể cập nhật Notion, đọc issue GitHub hay lấy báo cáo từ Google Drive nếu không có đường kết nối phù hợp. Khi kết hợp Hermes Agent với MCP, người dùng có thể biến một cuộc trò chuyện thành workflow thực tế, đồng thời kiểm soát rõ công cụ và quyền mà agent được phép sử dụng. Nếu bạn chưa quen với khả năng ghi nhớ và tự tạo skill của Hermes, bài Hermes Agent là gì? sẽ cung cấp phần nền tảng cần thiết. Trong bài này, trọng tâm là cách MCP mở rộng Hermes ra ngoài terminal để làm việc với dữ liệu và dịch vụ đang được sử dụng hằng ngày. MCP bổ sung điều gì cho Hermes Agent? MCP là một chuẩn kết nối giữa ứng dụng AI và server cung cấp công cụ hoặc dữ liệu. Có thể hình dung MCP như một lớp chuyển đổi: Hermes vẫn là agent chịu trách nhiệm hiểu mục tiêu và quyết định bước tiếp theo, còn từng MCP server cung cấp các thao tác cụ thể như tìm trang Notion, đọc pull request, tạo issue hoặc truy vấn tệp. Theo tài liệu MCP của Hermes Agent, Hermes hỗ trợ cả server chạy cục bộ qua stdio và server từ xa qua HTTP. Khi khởi động hoặc tải lại cấu hình, Hermes tự khám phá công cụ mà server cung cấp rồi đăng ký chúng vào hệ thống tool thông thường. Vì vậy, người dùng không cần viết một công cụ Hermes riêng cho mọi dịch vụ đã có MCP server phù hợp. Điểm quan trọng là MCP không tự động làm workflow an toàn. Mỗi server có thể cung cấp nhiều công cụ đọc, ghi, tạo và xóa dữ liệu. Hermes cho phép lọc theo từng server, nên người dùng có thể chỉ bật nhóm thao tác cần thiết thay vì đưa toàn bộ quyền cho model. Cách kết nối MCP mà không mở quá nhiều quyền Bản cài Hermes tiêu chuẩn đã bao gồm hỗ trợ MCP. Người dùng có thể mở trình chọn bằng lệnh hermes mcp, xem danh mục bằng hermes mcp catalog và kiểm tra một kết nối bằng hermes mcp test. Danh mục tích hợp của Hermes được Nous Research xem xét trước khi đưa vào repository, nhưng chính tài liệu cũng khuyến nghị đọc manifest, nguồn mã và lệnh cài đặt trước khi sử dụng. Với server ngoài danh mục, người dùng có thể thêm kết nối HTTP hoặc một lệnh stdio vào config.yaml. Sau khi hoàn tất OAuth hoặc cấu hình biến môi trường cần thiết, hãy tải lại MCP và yêu cầu Hermes liệt kê các công cụ đang có. Đây là bước kiểm tra đơn giản để phát hiện server chưa kết nối hoặc công cụ bị lọc nhầm. Bắt đầu bằng quyền đọc Cách thiết lập an toàn nhất là kết nối một server, chỉ bật công cụ đọc và thử trên dữ liệu không nhạy cảm. Khi kết quả ổn định, bạn mới thêm quyền tạo hoặc cập nhật. Quyền xóa, thay đổi chia sẻ và gửi nội dung ra ngoài nên cần bước phê duyệt của con người. Notion chỉ cần quyền tìm kiếm và đọc trang trong giai đoạn đầu. GitHub có thể giới hạn ở đọc repository, issue và pull request. Google Drive nên giới hạn thư mục, tài khoản và phạm vi OAuth cần thiết. Ba workflow thực tế với Notion, GitHub và Google Drive Biến tài liệu Notion thành trung tâm tri thức Notion MCP chính thức cho phép agent tìm kiếm, đọc và cập nhật nội dung trong workspace theo quyền của tài khoản đã xác thực. Một workflow hữu ích là để Hermes thu thập ghi chú họp, tìm các quyết định liên quan rồi tạo bản tổng hợp vào trang dự án. Người dùng có thể yêu cầu Hermes chỉ tạo bản nháp, sau đó kiểm tra trước khi cập nhật trạng thái hoặc giao việc. Notion MCP dùng OAuth theo người dùng, vì vậy không phù hợp với mọi tác vụ chạy hoàn toàn không có người giám sát. Nếu muốn chạy tự động theo lịch, hãy kiểm tra cách server duy trì phiên xác thực và tránh thiết kế workflow phụ thuộc vào thao tác mà OAuth không hỗ trợ ở chế độ headless. Đồng bộ công việc phát triển qua GitHub GitHub MCP Server do GitHub cung cấp và duy trì, cho phép công cụ AI làm việc với dữ liệu phát triển phần mềm theo quyền tài khoản. Hermes có thể đọc issue mới, đối chiếu với thay đổi trong repository và soạn báo cáo tiến độ. Ở bước tiếp theo, agent có thể chuẩn bị nội dung issue hoặc release note nhưng chờ người phụ trách xác nhận trước khi ghi. Workflow này hiệu quả hơn khi tiêu chí được mô tả rõ. Chẳng hạn, Hermes chỉ tổng hợp pull request đã merge trong bảy ngày, nhóm theo nhãn và liên kết từng thay đổi với issue liên quan. Kết quả có thể được chuyển tiếp sang Notion thông qua MCP thứ hai để tạo báo cáo tuần. Tổng hợp tệp và báo cáo từ Google Drive Với một MCP server tương thích Google Workspace, Hermes có thể tìm tệp trong Drive, đọc nội dung được cấp quyền và đưa dữ liệu vào quy trình tổng hợp. Ví dụ, agent tìm báo cáo bán hàng trong một thư mục cố định, trích các chỉ số cần thiết rồi tạo bản tóm tắt để lưu vào Notion hoặc đính kèm vào issue GitHub. Google đã tập hợp các dự án MCP chính thức tại repository Google MCP, trong đó có hướng tích hợp Google Workspace. Tuy nhiên, Drive từng có nhiều server cộng đồng với mức bảo trì khác nhau. Vì vậy, hãy kiểm tra nguồn, lịch sử cập nhật và phạm vi OAuth của server cụ thể thay vì cài theo tên gọi. Ghép nhiều MCP server thành một workflow có kiểm soát Một workflow hoàn chỉnh có thể bắt đầu từ GitHub, dùng Drive làm nguồn dữ liệu và kết thúc ở Notion. Hermes đọc issue được gắn nhãn báo cáo, tìm bảng tính tương ứng trong Drive, tạo phần tóm tắt rồi cập nhật trang dự án. Mỗi bước sử dụng một nhóm công cụ MCP khác nhau, còn Hermes giữ vai trò lập kế hoạch và chuyển kết quả giữa các bước. Không nên bật thực thi song song chỉ vì server hỗ trợ. Tài liệu Hermes cho phép khai báo khả năng gọi tool song song, nhưng cảnh báo rằng các thao tác cùng đọc và ghi trạng thái có thể tạo xung đột. Các bước chỉ đọc độc lập có thể chạy đồng thời, trong khi cập nhật Notion, tạo issue hoặc thay đổi tệp nên diễn ra tuần tự. Lưu ý: MCP server là phần mềm có thể chạy lệnh và nhận thông tin xác thực. Chỉ cài server từ nguồn đáng tin, không đặt token trong prompt, lọc bỏ công cụ nguy hiểm và luôn giữ bước phê duyệt cho hành động xóa, chia sẻ hoặc xuất bản dữ liệu. Nên bắt đầu workflow đầu tiên như thế nào? Đừng kết nối Notion, GitHub và Google Drive trong cùng ngày rồi giao ngay một quy trình quan trọng. Hãy chọn một đầu vào, một đầu ra và một tiêu chí hoàn thành dễ kiểm tra. Ví dụ đầu tiên có thể là đọc các issue GitHub đã đóng rồi tạo bản nháp báo cáo trong Notion, không có quyền xóa hoặc xuất bản. Sau vài lần chạy ổn định, bạn có thể biến quy trình thành skill để Hermes tái sử dụng và thêm lịch chạy tự động. Giá trị thực của MCP không nằm ở số lượng server đã kết nối, mà ở việc Hermes có thể hoàn thành một workflow lặp lại với phạm vi quyền nhỏ, kết quả dễ kiểm tra và đường đi dữ liệu rõ ràng.

Nam
16 thg 7, 2026
So sánh Hermes Agent, OpenClaw và Claude Cowork

Hermes Agent, OpenClaw và Claude Cowork đều được gọi là AI agent vì chúng không chỉ trả lời câu hỏi. Chúng có thể chia mục tiêu thành nhiều bước, gọi công cụ, đọc dữ liệu và tạo ra kết quả hoàn chỉnh. Tuy nhiên, đặt ba sản phẩm cạnh nhau chỉ bằng một bảng tính năng rất dễ dẫn tới lựa chọn sai. Hermes Agent hướng tới một agent có thể học thêm cách làm việc. OpenClaw hướng tới một trợ lý cá nhân luôn sẵn sàng qua các kênh nhắn tin còn Claude Cowork hướng tới người dùng muốn giao việc văn phòng bằng ngôn ngữ tự nhiên trong một môi trường được Anthropic quản lý. Vì vậy, câu hỏi quan trọng không phải công cụ nào mạnh nhất, mà là bạn muốn tự quản bao nhiêu và muốn agent xuất hiện ở đâu trong quy trình hằng ngày. Ba sản phẩm với thiết kế khác nhau Sự khác biệt của 3 công cụ AI Agent không chỉ nằm ở model thực thi mà còn ở bộ khung bao quanh model để quản lý công cụ, bộ nhớ, quyền truy cập và vòng lặp thực thi. Khái niệm này được giải thích chi tiết trong bài Agent Harness là gì?, qua đó người đọc có thể hiểu vì sao cùng được gọi là AI agent nhưng ba sản phẩm lại hành xử rất khác nhau. Hermes Agent ưu tiên vòng lặp học và môi trường thực thi Điểm đáng chú ý của Hermes là skills không chỉ là danh sách các skills đã được cài sẵn. Khi hoàn thành một công việc, agent có thể rút ra quy trình hữu ích, lưu lại và cải thiện ở lần sau. Bài Hermes Agent là gì? giải thích riêng cơ chế tự học này. Giá trị của cơ chế tích lũy tăng dần theo thời gian nếu người dùng có nhiều nhiệm vụ lặp lại như phân tích dự án, theo dõi nguồn tin, chuẩn hóa báo cáo hoặc vận hành một chuỗi công cụ nội bộ. Hermes cũng hỗ trợ nhiều kiểu sandbox như chạy cục bộ, Docker, SSH, Singularity hoặc Modal. Sandbox là môi trường cô lập nơi agent thực thi lệnh và thao tác tệp. Sự linh hoạt này giúp người dùng chọn giữa tốc độ, khả năng kiểm soát và mức độ cách ly, nhưng đồng thời đòi hỏi hiểu biết về hạ tầng, quyền truy cập và cách xử lý khóa bí mật. OpenClaw lấy Gateway làm trung tâm điều phối Trong OpenClaw, Gateway là lớp điều khiển đứng giữa agent, thiết bị và các kênh giao tiếp. Một tin nhắn có thể trở thành yêu cầu để agent đọc lịch, xử lý tệp, gọi dịch vụ hoặc phản hồi về đúng cuộc trò chuyện. Cách tiếp cận này rất tự nhiên với người muốn nhắn cho trợ lý từ điện thoại mà không cần nhớ máy chủ đang chạy ở đâu. OpenClaw phù hợp nhất khi agent cần phản ứng ngay khi có việc cần đến, không cần người dùng mở máy tính hay vào một ứng dụng riêng. Thay vì chờ bạn khởi động một phiên làm việc, nó ngồi sẵn trong các kênh nhắn tin bạn đang dùng và bắt đầu xử lý ngay khi có tin nhắn hoặc sự kiện kích hoạt sẵn. Claude Cowork cung cấp không gian làm việc được quản lý Cowork giảm phần việc hạ tầng mà người dùng phải tự lo. Trong ứng dụng desktop, người dùng có thể cấp quyền cho thư mục cục bộ rồi yêu cầu Claude đọc, sắp xếp hoặc tạo tệp. Với phiên làm việc từ xa, công việc diễn ra trong môi trường cô lập trên máy chủ của Anthropic, phù hợp với những tác vụ dài không cần giữ máy cá nhân hoạt động liên tục. Đổi lại, phạm vi tùy biến và quyền kiểm soát tầng thực thi không rộng như một dự án tự host. Cowork phù hợp hơn với người muốn kết quả nhanh trong hệ sinh thái Claude, không muốn duy trì máy chủ hoặc tự thiết kế một Gateway. Bộ nhớ của ba công cụ hoạt động khác nhau như thế nào Bộ nhớ trong agent không nên được hiểu đơn giản là lưu toàn bộ hội thoại. Một hệ thống hữu ích phải biết thông tin nào đáng giữ, thông tin nào chỉ có giá trị trong phiên hiện tại và khi nào cần lấy lại dữ liệu cũ. Nếu lưu quá ít, agent sẽ phải hỏi những câu hỏi lặp lại còn nếu lưu quá nhiều, chi phí chắc chắn sẽ tăng và dữ liệu nhạy cảm rất dễ bị dùng sai chỗ. Hermes lại nổi bật nhờ kết hợp bộ nhớ bền vững với skill có thể cải thiện. Bộ nhớ giúp ghi nhận sở thích và bối cảnh, còn skill ghi lại cách hoàn thành một loại nhiệm vụ. Hai lớp này tạo ra cảm giác agent ngày càng hiểu người dùng, nhưng chất lượng vẫn phụ thuộc vào việc người dùng xem lại những gì được lưu và loại bỏ quy trình không phù hợp. OpenClaw chạy trên nhiều kênh cùng lúc và đó lại chính là điểm phức tạp nhất của nó. Nhớ nội dung hội thoại chỉ là một phần, vấn đề khó hơn là phân biệt được ai đang nói chuyện ở kênh nào và việc đó thuộc phạm vi nào. Một lệnh gửi trong nhóm Slack của công ty không nên tự động kéo theo ngữ cảnh riêng tư bạn từng trao đổi qua Telegram. Nếu cấu hình phiên và chính sách định danh nên được thiết lập rõ ràng ngay từ đầu, chất lượng model tốt đến đâu cũng không cứu được nếu mọi thứ mù mờ. Cowork giới hạn ngữ cảnh trong từng phiên làm việc, chỉ đọc những tệp bạn cấp quyền và kết nối nào bạn cho phép. Với người không quen dựng hệ thống, cách này dễ kiểm soát hơn vì ranh giới của mỗi tác vụ khá rõ ràng nhưng rõ ràng không có nghĩa là tự động hiểu, bạn vẫn cần nói rõ mình muốn gì, hoàn thành trông như thế nào và dữ liệu lấy từ đâu. Cowork không tự suy ra bối cảnh công ty của bạn nếu bạn không chủ động đưa vào. Mỗi công cụ tự động hóa tốt nhất loại việc nào Hermes có công cụ web, terminal, MCP, lịch chạy tự động và subagent. MCP là chuẩn kết nối giúp agent giao tiếp với nguồn dữ liệu hoặc ứng dụng bên ngoài qua một giao diện thống nhất. Khi kết hợp MCP với skill, người dùng có thể biến một thử nghiệm thành quy trình lặp lại, chẳng hạn mỗi sáng thu thập dữ liệu, phân tích thay đổi và gửi bản tóm tắt. OpenClaw mạnh ở các workflow bắt đầu từ tin nhắn hoặc sự kiện. Ví dụ, người dùng gửi hóa đơn vào kênh riêng, agent trích xuất thông tin rồi cập nhật hệ thống lưu trữ. Một ví dụ khác là nhận cảnh báo dịch vụ, hỏi thêm dữ liệu chẩn đoán và trả về bản tóm tắt ngay trong nhóm vận hành. Giá trị nằm ở việc giảm khoảng cách giữa lúc phát sinh nhu cầu và lúc agent bắt đầu hành động. Cowork phù hợp với đầu ra văn phòng có cấu trúc. Nó có thể nghiên cứu một chủ đề, tổng hợp dữ liệu, tạo tài liệu và tiếp tục chỉnh sửa theo phản hồi. Các tác vụ dài hoặc được lên lịch giúp Cowork vượt khỏi kiểu hỏi đáp ngắn. Tuy vậy, doanh nghiệp cần kiểm tra kỹ từng connector và quyền truy cập trước khi để agent thao tác trên kho dữ liệu thật. Nếu cần tích hợp sâu với hạ tầng riêng, Hermes và OpenClaw thường cho nhiều không gian hơn. Nếu ưu tiên thời gian đi từ yêu cầu tới tài liệu hoàn chỉnh, Cowork thường có lợi thế. Đây là khác biệt giữa nền tảng để lắp ghép và sản phẩm đã đóng gói. Bảo mật của ba AI agent này như thế nào Câu hỏi dùng cái nào an toàn hơn không có câu trả lời đơn giản, vì rủi ro bảo mật của từng công cụ đến từ những điểm hoàn toàn khác nhau. Hermes Agent: Tự host không đồng nghĩa là tự động an toàn. Rủi ro lớn nhất đến từ các skill tự sinh ra vì về bản chất đây là đoạn mã được agent tự viết rồi tự chạy. Nếu không xem lại trước khi cho chạy định kỳ, một skill có quyền terminal hoặc quyền gửi dữ liệu ra ngoài có thể làm những việc bạn không hề hay biết. Ngoài ra, khóa API và thư mục nhạy cảm không nên xuất hiện trong prompt hay được gắn trực tiếp vào sandbox nếu skill đó không thực sự cần đến. OpenClaw: Kết nối càng nhiều kênh thì bề mặt tấn công càng rộng. Điểm dễ bị bỏ qua nhất là xác thực người gửi, vì nếu Gateway chỉ tin vào tên hiển thị hoặc một kênh chưa được bảo vệ đúng cách, một tài khoản nhắn tin bị chiếm quyền là đủ để ai đó ra lệnh cho agent của bạn. Danh sách người được phép gửi lệnh và quyền của từng bot cần được xem xét lại mỗi khi bạn thêm một kênh mới. Claude Cowork: Rủi ro đáng lo nhất là prompt injection, tức khi agent đọc một tài liệu hoặc trang web có chứa chỉ dẫn ẩn nhằm khiến nó làm lệch yêu cầu ban đầu của bạn. Anthropic có cơ chế bảo vệ và yêu cầu xác nhận cho các hành động nhạy cảm, nhưng điều đó không thay thế được việc bạn tự kiểm tra kết quả và không cấp quyền rộng hơn mức công việc thực sự cần. Lưu ý: Với bất kỳ agent nào, đừng cấp quyền xóa tệp hay gửi tin nhắn ra ngoài hay thực hiện giao dịch nhạy cảm. Vậy hãy bắt đầu với chế độ chỉ đọc, bật ghi nhật ký đầy đủ và giữ quyền phê duyệt cho những hành động cần đến con người. Nên chọn Hermes Agent, OpenClaw hay Claude Cowork? Mội công cụ có một điểm mạnh điểm yếu riêng vì vậy muốn chọn được công cụ phù hợp nhất còn tùy thuộc vào người sử dụng và công việc cần sử dụng. Chọn Hermes Agent khi muốn agent ngày càng hiểu cách bạn làm việc Hermes phù hợp với nhà phát triển, người nghiên cứu hoặc nhóm kỹ thuật muốn agent học quy trình riêng và chạy trên hạ tầng linh hoạt. Nó đặc biệt đáng cân nhắc khi nhiệm vụ lặp lại đủ nhiều để skill tạo ra lợi ích tích lũy. Bạn cần sẵn sàng đọc log, kiểm tra skill và quản lý môi trường thực thi. Phù hợp nhất khi: Bạn muốn agent nhớ và cải thiện quy trình làm việc qua từng lần dùng. Bạn có thể tự quản lý sandbox, chọn model và kiểm soát quyền truy cập. Chọn OpenClaw khi công việc cần giao tiếp liên tục từ tin nhắn OpenClaw phù hợp khi trợ lý cần có mặt trên Telegram, WhatsApp, Slack, Zalo hoặc các kênh tương tự. Nó hữu ích cho cảnh báo, thu thập yêu cầu nhanh và tự động hóa có điểm bắt đầu từ hội thoại. Đổi lại, bạn phải quản lý danh tính, quyền kênh và độ ổn định của Gateway. Phù hợp nhất khi: Yêu cầu thường đến dưới dạng tin nhắn hoặc cảnh báo tự động. Bạn cần một điểm điều phối duy nhất cho nhiều kênh giao tiếp khác nhau. Chọn Claude Cowork khi cần kết quả nhanh mà không muốn dựng hệ thống Cowork phù hợp với người làm nội dung, phân tích hoặc quản lý cần tài liệu, bảng tính và slide hoàn chỉnh mà không muốn nghĩ đến server hay Gateway. Bù lại, bạn nên hiểu rõ giới hạn của gói đang dùng, dữ liệu đi qua đâu, kết nối nào đang được bật trước khi đưa công việc thật vào. Phù hợp nhất khi: Bạn muốn mô tả kết quả cần đạt bằng ngôn ngữ tự nhiên và nhận lại đầu ra hoàn chỉnh. Bạn ưu tiên sự tiện lợi của một dịch vụ được quản lý hơn là toàn quyền kiểm soát hạ tầng.

Nam
14 thg 7, 2026