Claude Code, NotebookLM và Obsidian cho nghiên cứu thông minh hơn

Có ai đang dùng song song cả Codex lẫn Claude Code không? Mình mới phát hiện plugin Codex cho Claude Code do chính OpenAI phát hành. Nói thật là đến giờ mới biết nên cũng có cảm giác như người tối cổ. Điểm hay nhất là từ nay có thể gọi Codex ngay trong phiên Claude Code hiện tại để review code, phản biện hướng triển khai hoặc nhận riêng một tác vụ, không phải chuyển qua lại giữa nhiều tab và session như trước. Plugin Codex cho Claude Code có gì đáng chú ý? Plugin openai/codex-plugin-cc được thiết kế cho người đã quen làm việc trong Claude Code nhưng muốn tận dụng thêm Codex. Thay vì để hai agent cùng nhảy vào chỉnh một file, bạn có thể phân vai rõ ràng: Claude Code triển khai, Codex kiểm tra; hoặc Claude Code giữ luồng chính còn Codex xử lý một vấn đề độc lập ở chế độ nền. Theo tài liệu chính thức, plugin cung cấp ba nhóm khả năng. Nhóm review gồm /codex:review và /codex:adversarial-review. Nhóm giao việc có /codex:rescue. Nhóm quản lý phiên và tác vụ nền gồm /codex:transfer, /codex:status, /codex:result và /codex:cancel. Nhờ vậy, Codex trở thành một cộng sự nằm ngay trong workflow Claude Code thay vì là một cửa sổ tách rời. Không phải một Codex runtime tách biệt Plugin không tạo thêm một hệ thống Codex mới. Nó sử dụng Codex CLI và Codex app server đang cài trên máy, đồng thời dùng lại trạng thái đăng nhập, repository hiện tại và cấu hình trong config.toml. Điều này giúp việc tích hợp gọn hơn, nhưng cũng có nghĩa mọi lượt gọi vẫn được tính vào giới hạn sử dụng Codex của tài khoản. Điều kiện trước khi cài Bạn cần Node.js 18.18 trở lên và một tài khoản ChatGPT, kể cả gói Free, hoặc OpenAI API key. Nếu Codex CLI chưa có trên máy, lệnh /codex:setup có thể hướng dẫn cài; cách thủ công là chạy npm install -g @openai/codex. Nếu chưa đăng nhập, dùng !codex login ngay trong Claude Code. Cách cài Codex plugin trong Claude Code Quy trình cài đặt khá ngắn. Trong Claude Code, lần lượt chạy các lệnh sau: /plugin marketplace add openai/codex-plugin-cc /plugin install codex@openai-codex /reload-plugins /codex:setup Lệnh cuối kiểm tra Codex đã được cài và xác thực hay chưa. Sau khi hoàn tất, danh sách slash command của Codex sẽ xuất hiện trong Claude Code, đồng thời agent codex:codex-rescue cũng có mặt trong mục /agents. Chạy thử ở chế độ nền Một bài thử ít rủi ro là yêu cầu Codex review thay đổi hiện tại bằng /codex:review --background, sau đó dùng /codex:status để xem tiến độ và /codex:result để lấy kết quả. Review nhiều file có thể mất thời gian, vì vậy chạy nền sẽ không chặn luồng làm việc chính của Claude Code. Ba cách phối hợp Codex và Claude Code hiệu quả Giá trị của plugin không nằm ở việc có thêm một AI, mà ở cách phân vai. Nếu cả hai cùng sửa một khu vực mà không có ranh giới, bạn dễ gặp xung đột code, lặp phân tích và tốn context. Ba luồng dưới đây rõ trách nhiệm hơn. Claude viết, Codex review Đây là cách dễ áp dụng nhất. Sau khi Claude Code hoàn thành một tính năng, chạy /codex:review để Codex thực hiện review chỉ đọc. Lệnh này có thể kiểm tra thay đổi chưa commit hoặc so sánh branch với nhánh gốc bằng /codex:review --base main. Codex không sửa file trong chế độ này, nên bạn vẫn giữ quyền quyết định cuối cùng. Ví dụ, Claude vừa thêm luồng thanh toán qua ba module. Thay vì yêu cầu Claude tự đánh giá lại phần việc của chính mình, hãy để Codex rà lỗi logic, trường hợp biên và tác dụng phụ giữa các file. Sau đó Claude Code có thể đọc nhận xét, chọn điểm hợp lý và sửa trong cùng phiên. Giao hẳn một task cho Codex Với một bài toán có thể tách độc lập, dùng /codex:rescue. Chẳng hạn: /codex:rescue --background điều tra nguyên nhân kiểm thử tích hợp không ổn định. Claude Code tiếp tục xử lý UI hoặc tài liệu, trong khi Codex điều tra test ở nền. Lệnh này hỗ trợ --background, --wait, --resume và --fresh, nên có thể tiếp tục một task trước đó hoặc buộc mở một lượt mới. Điểm quan trọng là mô tả đầu ra và phạm vi file rõ ràng. Giao “sửa mọi thứ đang lỗi” cho Codex trong khi Claude cũng đang chỉnh toàn repository vẫn có nguy cơ đụng nhau. Một task tốt nên có mục tiêu cụ thể, tiêu chí hoàn thành và vùng code sở hữu riêng. Dùng adversarial review để chất vấn hướng phát triển dự án /codex:adversarial-review phù hợp khi bạn không chỉ muốn bắt bug mà còn muốn chất vấn quyết định thiết kế. Có thể thêm trọng tâm, ví dụ: /codex:adversarial-review --base main challenge the caching and retry design. Codex sẽ soi giả định ẩn, trade-off, phương án thay thế và các rủi ro như mất dữ liệu, race condition, rollback hoặc độ tin cậy. Nói vui thì đây là lúc hai ông có thể “cãi nhau ỏm tỏi”, nhưng tranh luận chỉ hữu ích khi có người cầm trịch. Hãy đặt câu hỏi hẹp, yêu cầu bằng chứng và chốt tiêu chí ra quyết định; nếu không, phiên phản biện rất dễ biến thành chuỗi ý kiến nối tiếp mà không tạo ra thay đổi thực tế. Chuyển phiên và quản lý tác vụ nền Plugin còn giải quyết một vấn đề quen thuộc: đã thảo luận dài trong Claude Code nhưng muốn chuyển nguyên mạch công việc sang Codex. /codex:transfer tạo một Codex thread bền vững từ phiên Claude Code hiện tại và trả về lệnh codex resume <session-id>. Nhờ đó, bạn không phải viết lại toàn bộ bối cảnh bằng tay. Khi nào nên dùng transfer Hãy dùng transfer khi task đã vượt khỏi một lần review ngắn và bạn muốn tiếp tục trực tiếp trong Codex App hoặc TUI. Ví dụ, Claude Code đã cùng bạn điều tra kiến trúc trong một phiên dài, nhưng giai đoạn tiếp theo cần Codex thực hiện nhiều vòng chỉnh sửa. Việc chuyển phiên giữ lại lịch sử có cấu trúc và giảm rủi ro mất các quyết định đã thống nhất. Theo dõi, lấy kết quả và hủy tác vụ Với task chạy nền, /codex:status cho biết tiến độ, /codex:result trả kết quả cuối cùng và session ID, còn /codex:cancel dừng job đang chạy. Ba lệnh này nghe đơn giản nhưng rất cần thiết để workflow nhiều agent không trở thành một hộp đen. Nếu task đi sai hướng, hủy sớm thường tiết kiệm limit hơn chờ kết quả rồi làm lại. Cẩn thận vòng lặp review và giới hạn sử dụng Lưu ý quan trọng: OpenAI cảnh báo rõ rằng review gate có thể tạo vòng lặp Claude/Codex kéo dài và tiêu hao giới hạn sử dụng nhanh. Khi bật bằng /codex:setup --enable-review-gate, plugin dùng Stop hook, tức cơ chế tự động kích hoạt khi Claude chuẩn bị kết thúc câu trả lời, để gọi một lượt review có mục tiêu. Nếu Codex tìm thấy vấn đề, phản hồi của Claude bị chặn để Claude xử lý trước. Cơ chế này hữu ích trước khi ship, nhưng không nên bật rồi bỏ mặc. Review gate mạnh nhưng cần giám sát Kịch bản dễ gặp là Codex nêu vấn đề, Claude sửa, Codex review lại và phát hiện một điểm mới; chu kỳ tiếp tục vì tiêu chí “đủ tốt” chưa được định nghĩa. Đây chính là phiên bản tự động của việc để hai agent review qua lại liên tục. Chi phí không chỉ là limit mà còn là thời gian và nguy cơ thay đổi quá mức một bản vá vốn đã ổn. Một bộ nguyên tắc vận hành an toàn Phân vai trước khi chạy: một agent triển khai, một agent review hoặc một agent sở hữu một task độc lập. Giới hạn phạm vi: nêu rõ branch, file, loại rủi ro và tiêu chí hoàn thành. Ưu tiên chạy nền cho review nhiều file, nhưng kiểm tra trạng thái định kỳ. Chỉ bật review gate khi đang chủ động theo dõi và tắt bằng /codex:setup --disable-review-gate sau khi hoàn tất. Không yêu cầu Claude review lại toàn bộ kết quả Codex rồi tiếp tục yêu cầu Codex review toàn bộ phần sửa của Claude nếu chưa có điểm dừng rõ ràng. Dùng /codex:cancel khi task lệch hướng thay vì cố cứu một vòng chạy tốn kém. Làm sao kết hợp Codex và Claude Code hiệu quả? Trước đây mình thường mở Codex và Claude Code song song, đôi lúc còn để cả hai cùng nhảy vào một file để tiết kiệm thời gian. Plugin chính chủ của OpenAI tạo ra cách làm gọn hơn: Claude Code giữ vai trò điều phối, Codex vào review, phản biện hoặc nhận task riêng mà không cần chuyển tab liên tục. Bắt đầu tốt nhất là cài plugin, chạy một lượt /codex:review --background trên dự án nhỏ và quan sát cách ba lệnh status, result, cancel hoạt động. Khi đã quen mới thử rescue, transfer và review gate. Hai AI có thể bổ trợ nhau rất tốt, miễn là con người vẫn đặt ranh giới, ngân sách và điểm dừng.

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

NotebookLM đã chính thức mang tên Gemini Notebook từ ngày 16/7/2026. Tên mới đánh dấu bước chuyển từ công cụ hỏi đáp tài liệu sang không gian nghiên cứu AI có thể chạy code, phân tích dữ liệu, tạo báo cáo đa định dạng và theo người dùng sang Gemini cũng như Google Search. Bài viết này giải thích điều gì thực sự thay đổi, tính năng nào được giữ lại và ai có thể sử dụng các nâng cấp mới. Gemini Notebook vẫn là NotebookLM quen thuộc Google khẳng định Gemini Notebook vẫn là một sản phẩm độc lập, tập trung vào nghiên cứu và học tập. Người dùng hiện tại không phải chuyển dữ liệu sang dịch vụ khác. Notebook, nguồn, ghi chú và nội dung đã tạo vẫn nằm trong cùng trải nghiệm, trong khi tên mới cho thấy sản phẩm đang trở thành một phần rõ ràng hơn của hệ sinh thái Gemini. Cốt lõi của công cụ cũng không đổi. Người dùng tập hợp PDF, website, video YouTube, tệp âm thanh, Google Docs hoặc Google Slides vào từng notebook. Khi đặt câu hỏi, Gemini Notebook trả lời dựa trên những nguồn đã chọn và đưa ra trích dẫn để người đọc mở đúng đoạn tài liệu liên quan. Cách làm này đặc biệt hữu ích khi cần kiểm chứng một nhận định thay vì chỉ nhận câu trả lời trôi nổi từ chatbot. Việc đổi tên đến sau hành trình bắt đầu với Project Tailwind tại Google I/O 2023. Theo Google, sản phẩm đã có hơn 30 triệu người dùng và hơn 600.000 tổ chức sử dụng. Tên Gemini Notebook vì thế phản ánh giai đoạn trưởng thành mới, khi một notebook không còn chỉ là nơi đọc tài liệu mà trở thành không gian để nghiên cứu, phân tích và tạo đầu ra hoàn chỉnh. Gemini Notebook chạy code như thế nào? Thay đổi kỹ thuật đáng chú ý nhất là mỗi notebook có thể được trang bị một máy tính đám mây bảo mật. Hiểu đơn giản, Gemini Notebook có một môi trường riêng để viết và chạy code phục vụ nhiệm vụ nghiên cứu. Công cụ có thể làm sạch dữ liệu, tính toán, so sánh nhiều bảng số liệu, dựng biểu đồ hoặc kiểm tra một giả thuyết thay vì chỉ tóm tắt văn bản. Từ hỏi đáp tài liệu đến phân tích có hành động Trước đây, giá trị nổi bật của NotebookLM nằm ở khả năng đọc nhiều nguồn và trả lời có trích dẫn. Với môi trường chạy code, Gemini Notebook tiến thêm một bước: nó có thể thao tác trên dữ liệu để tạo ra kết quả mới. Một nhà phân tích có thể nhập dữ liệu từ nhiều quốc gia với định dạng khác nhau, yêu cầu công cụ chuẩn hóa chúng, chạy phép tính rồi tạo biểu đồ và báo cáo. Google cho biết hệ thống còn có hơn 100 kỹ năng phần mềm được tuyển chọn. Tuy vậy, đây vẫn là AI có thể mắc lỗi. Người dùng nên kiểm tra code, phép tính, dữ liệu đầu vào và kết luận, nhất là khi kết quả được dùng cho tài chính, pháp lý, y tế hoặc quyết định kinh doanh. Lưu ý: Khả năng agent và chạy code chưa mở đồng loạt cho mọi tài khoản. Google AI Ultra cùng một số gói Workspace được hỗ trợ trước; Google cho biết tính năng sẽ tiếp tục được triển khai cho người dùng Pro trên web. Gemini Notebook tạo được những định dạng đầu ra nào? Gemini Notebook không còn giới hạn ở báo cáo dạng chữ. Từ dữ liệu và tài liệu trong notebook, người dùng có thể yêu cầu tạo biểu đồ PNG hoặc SVG, báo cáo PDF, tệp Word, Markdown, văn bản, CSV, JSON, Excel và PowerPoint. Hệ thống cũng hỗ trợ hình ảnh, bảng dữ liệu, infographic và slide, đồng thời cho phép chỉnh sửa phiên bản sau khi tạo. Một nguồn, nhiều cách trình bày Cùng một bộ tài liệu đào tạo có thể được chuyển thành báo cáo cho quản lý, slide cho buổi thuyết trình, bảng tính cho nhóm vận hành và Audio Overview cho người muốn nghe. Học sinh có thể tạo thẻ ghi nhớ, câu đố, sơ đồ tư duy hoặc Video Overview. Nhóm nội dung có thể dựng bảng so sánh và infographic mà không phải sao chép dữ liệu qua quá nhiều công cụ. Nghiên cứu: tìm nguồn, đọc chéo tài liệu, trích dẫn và tạo báo cáo có biểu đồ. Phân tích dữ liệu: chuẩn hóa bảng, chạy code, xuất CSV hoặc XLSX và trực quan hóa kết quả. Học tập: tạo hướng dẫn ôn tập, flashcard, quiz, audio, video và sơ đồ tư duy. Làm việc nhóm: xây kho kiến thức, chia sẻ quyền xem hoặc chỉnh sửa và theo dõi mức sử dụng. Điểm đáng giá không nằm ở số lượng định dạng, mà ở việc chúng được tạo từ cùng một tập nguồn. Khi muốn thay đổi góc nhìn hoặc đối tượng người đọc, người dùng có thể điều chỉnh yêu cầu mà không phải dựng lại toàn bộ ngữ cảnh. Gemini Notebook xuất hiện ở đâu trong hệ sinh thái Google? Gemini Notebook đã bắt đầu xuất hiện trong ứng dụng Gemini. Notebook tạo ở sản phẩm độc lập có thể hiển thị trong phần điều hướng của Gemini; việc đổi tên notebook, thêm nguồn hoặc cập nhật hướng dẫn tùy chỉnh được đồng bộ giữa các ứng dụng. Người dùng vì thế có thể tiếp tục trò chuyện với kho kiến thức mà không phải luôn quay về một tab riêng. Google cũng dự kiến đưa notebook vào AI Mode trong Search. Khi hoàn thiện, hướng đi này có thể biến notebook thành lớp ngữ cảnh cá nhân đi cùng người dùng từ nghiên cứu trên web đến trò chuyện với Gemini. Dù vậy, notebook được chia sẻ và hội thoại trong Gemini có quy tắc hiển thị, chia sẻ và lưu giữ dữ liệu riêng; người dùng tổ chức nên đọc chính sách của gói Workspace đang sử dụng. Cách bắt đầu với tên gọi mới Mở Gemini Notebook bằng tài khoản Google và tạo một notebook cho một mục tiêu cụ thể. Thêm các nguồn đáng tin cậy, sau đó kiểm tra cách công cụ phân loại và trích dẫn chúng. Đặt câu hỏi hẹp trước, rồi mới yêu cầu nghiên cứu sâu, phân tích dữ liệu hoặc tạo tệp đầu ra. Kiểm tra trích dẫn, phép tính và phiên bản cuối trước khi chia sẻ. Người dùng cũ có thể tiếp tục truy cập địa chỉ NotebookLM quen thuộc trong giai đoạn chuyển đổi. Slug công cụ trên 4AIVN cũng được giữ nguyên để các liên kết cũ không bị đứt, trong khi tên và nội dung đã được cập nhật thành Gemini Notebook. Đổi tên có làm Gemini Notebook hữu ích hơn không? Bản thân cái tên không thay đổi chất lượng nghiên cứu. Điều làm lần đổi tên này đáng chú ý là Google đang ghép ba lớp năng lực vào một sản phẩm: nguồn có trích dẫn, môi trường chạy code và khả năng đưa notebook sang Gemini cũng như Search. Nếu được triển khai ổn định, Gemini Notebook có thể rút ngắn quãng đường từ đọc tài liệu đến phân tích và giao sản phẩm hoàn chỉnh. Tuy nhiên, không phải tính năng nào cũng có sẵn cho mọi người ngay lập tức, và đầu ra do AI tạo vẫn cần kiểm tra. Cách dùng hiệu quả nhất vẫn là chọn nguồn tốt, chia notebook theo mục tiêu rõ ràng, yêu cầu đầu ra cụ thể và giữ con người ở bước phê duyệt cuối.

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.