Nvidia NemoClaw nền tảng bảo mật OpenClaw cho doanh nghiệp

Anthropic vừa công bố hợp tác với SpaceX để tiếp cận hơn 220.000 GPU NVIDIA và ngay lập tức dùng năng lực điện toán mới này để tăng giới hạn sử dụng cho Claude Code lẫn API. Đây là những gì thay đổi và tại sao điều đó quan trọng với người dùng. Tại sao Anthropic lại hợp tác với SpaceX? Trong vài tháng gần đây, Anthropic liên tục ký kết các thỏa thuận điện toán quy mô lớn với Amazon, Google, Microsoft và NVIDIA. Lần này, hãng tiếp tục bổ sung thêm một tên tuổi không ai ngờ tới là SpaceX. Theo thông báo ngày 6/5, Anthropic đã ký thỏa thuận sử dụng toàn bộ năng lực tính toán tại trung tâm dữ liệu Colossus 1 của SpaceX tương đương với hơn 300 megawatt công suất và hơn 220.000 GPU NVIDIA. Toàn bộ năng lực này sẽ được đưa vào sử dụng trong vòng một tháng và sẽ cải thiện trực tiếp trải nghiệm cho người dùng Claude Pro và Claude Max. Colossus 1 là trung tâm dữ liệu AI của SpaceX, hiện là một trong những cụm GPU lớn nhất thế giới. Anthropic là đơn vị thuê toàn bộ năng lực tại đây. Những thay đổi cụ thể về giới hạn sử dụng Nhờ nguồn điện toán mới, Anthropic đã thực hiện ba thay đổi có hiệu lực ngay từ ngày công bố Tăng gấp đôi giới hạn Claude Code theo giờ Giới hạn tốc độ 5 giờ của Claude Code được nhân đôi cho các gói Pro, Max, Team và Enterprise. Nếu trước đây bạn chỉ sử dụng được 10 lệnh chạy Claude Code phức tạp nay được nhân đôi lên thành 20 lần, thay đổi này sẽ giúp ích đáng kể. Tuy nhiên lưu ý là quan trọng là giới hạn tuần (week limit) vẫn giữ nguyên không thay đổi gì cho nên việc tăng giới hạn 5 giờ giúp bạn làm việc cường độ cao hơn trong thời gian ngắn, nhưng có thể khiến bạn chạm mức trần của tuần nhanh hơn. Bỏ giới hạn giờ cao điểm Trước đây, Claude Code tự động giảm giới hạn sử dụng trong khung giờ cao điểm (thường từ 9h sáng đến 3h chiều) đối với tài khoản Pro và Max. Giới hạn này đã được xóa bỏ hoàn toàn vì vậy người dùng giờ đây có thể sử dụng Claude Code với tốc độ đầy đủ bất kể thời điểm trong ngày. Với người dùng thường làm việc vào buổi tối (trùng với giờ bên Mỹ) đây là thay đổi có khả năng có tác động rõ rệt nhất. Tăng mạnh giới hạn API cho các mô hình Claude Opus Giới hạn tốc độ API (rate limit) cho các mô hình Claude Opus được nâng lên đáng kể . Chi tiết mức tăng bằng lần được Anthropic công bố trong bảng sau đây: Thay đổi này đặc biệt quan trọng với các nhà phát triển đang xây dựng ứng dụng trên nền tảng Claude Code Toàn cảnh chiến lược điện toán của Anthropic Thỏa thuận với SpaceX không phải động thái đơn lẻ. Trong vài tháng gần đây, Anthropic đã xây dựng một danh mục đầu tư hạ tầng rất đáng chú ý: Thỏa thuận lên tới 5 gigawatt với Amazon, trong đó gần 1 GW sẽ hoạt động trước cuối 2026 Thỏa thuận 5 GW với Google và Broadcom, dự kiến đưa vào vận hành từ 2027 Quan hệ đối tác chiến lược với Microsoft và NVIDIA, bao gồm 30 tỷ USD năng lực Azure Đầu tư 50 tỷ USD vào hạ tầng AI tại Mỹ cùng Fluidstack Và nay, hơn 300 megawatt từ trung tâm Colossus 1 của SpaceX Anthropic chạy Claude trên nhiều nền tảng phần cứng khác nhau — AWS Trainium, Google TPU và GPU NVIDIA — và cho biết vẫn đang tiếp tục tìm kiếm thêm các nguồn năng lực tính toán mới. Đáng chú ý, trong khuôn khổ thỏa thuận với SpaceX, hai bên cũng bày tỏ quan tâm đến việc phát triển năng lực điện toán AI trên quỹ đạo tức là đặt GPU trên vệ tinh. Đây vẫn là ý tưởng ở giai đoạn rất sớm, nhưng nếu thành hiện thực sẽ là bước ngoặt lớn cho hạ tầng AI toàn cầu. Mở rộng ra thị trường quốc tế Một phần năng lực điện toán mở rộng sẽ được dùng để phục vụ khách hàng doanh nghiệp quốc tế đặc biệt trong các lĩnh vực yêu cầu lưu trữ dữ liệu nội địa như tài chính, y tế và chính phủ. Thỏa thuận với Amazon bao gồm cả năng lực suy luận bổ sung tại châu Á và châu Âu. Anthropic cũng nhấn mạnh rằng họ chỉ mở rộng sang các quốc gia có khung pháp lý dân chủ và chuỗi cung ứng phần cứng an toàn cho thấy một lập trường thể hiện sự thận trọng trong bối cảnh cạnh tranh địa chính trị về AI đang ngày càng gay gắt. Điều này có ý nghĩa gì với người dùng Claude tại Việt Nam? Ở góc độ thực tế, ba thay đổi về giới hạn sử dụng mang lại lợi ích trực tiếp nhất cho những ai đang dùng Claude Code hàng ngày — đặc biệt là lập trình viên và người làm việc liên tục với Claude Code.Việc xóa giới hạn giờ cao điểm cũng có nghĩa là trải nghiệm của người dùng tại Việt Nam (vốn trùng múi giờ với giai đoạn tải nặng tại Mỹ) sẽ ổn định hơn. Về dài hạn, năng lực điện toán lớn hơn thường đồng nghĩa với khả năng triển khai các mô hình mạnh hơn, với chi phí thấp hơn. Đây là nền tảng để Anthropic tiếp tục cạnh tranh với OpenAI và Google trong cuộc đua AI 2026. Anthropic luôn luôn phát triển Anthropic đang đầu tư nghiêm túc vào hạ tầng và hợp tác với SpaceX là bước đi mới nhất trong chiến lược đó. Kết quả gần nhất mà người dùng có thể cảm nhận ngay là Claude Code ít bị giới hạn hơn và tốc độ API chắc chắn sẽ cải thiện. Còn về lâu dài, cuộc chạy đua điện toán giữa các công ty AI lớn hứa hẹn sẽ còn nhiều diễn biến thú vị trong năm 2026.

Markdown đã là chuẩn mặc định khi làm việc với AI suốt nhiều năm nhưng một kỹ sư đến từ Claude Code tại Anthropic vừa đặt ra câu hỏi đáng suy nghĩ: liệu thói quen đó có thực sự là lựa chọn tốt nhất? Bài viết ngắn của Thariq Shihipar thu hơn 15.000 lượt thích trên X chỉ trong vài ngày, và lý do thuyết phục hơn bạn nghĩ. Markdown ra đời từ thời AI còn nghèo token Nhìn lại thời GPT-4 với cửa sổ ngữ cảnh chỉ 8.192 token, Markdown là lựa chọn hoàn toàn hợp lý trong khi đó HTML cồng kềnh hơn, tốn tài nguyên hơn và trong bối cảnh hạn chế đó, sự tối giản của Markdown là một ưu điểm thực sự chỉ để tiết kiệm. Vì vậy Markdown trở thành chuẩn ngầm định, và thói quen đó theo chúng ta đến tận bây giờ.Ngay cả khi Anthropic tạo ra khái niệm Skill trên Claude họ cũng đã lấy Markdown làm tiêu chuẩn với file SKILL.md, những ai hay làm việc với skill chắc chắn hiểu rõ điều mặc định này. Tuy nhiên, các mô hình AI hiện tại đã vận hành ở quy mô hoàn toàn khác. Nhiều mô hình đang hỗ trợ cửa sổ ngữ cảnh từ 200.000 đến 1 triệu token, và chi phí xử lý không còn là rào cản đáng lo (theo lời của Thariq Shihipar) và anh ấy lập luận rằng đây chính là thời điểm để xem lại mặc định đó. HTML làm được gì mà Markdown không thể? Lý do cốt lõi Thariq đưa ra khá đơn giản: một số loại thông tin vốn có tính không gian nhưng Markdown buộc chúng phải trở thành văn bản tuyến tính. Khi bạn so sánh ba hướng tiếp cận kỹ thuật thì bạn cần nhìn chúng cạnh nhau, không phải đọc lần lượt rồi cố giữ trong đầu. Khi bạn xem lại một đoạn code bạn cần thấy cấu trúc thay đổi tất nhiên không phải một bức tường chữ. HTML giải quyết đúng vấn đề đó vì vậy Thariq đã liệt kê 9 nhóm tình huống cụ thể mà HTML vượt trội hơn Markdown: Khám phá và lên kế hoạch: So sánh nhiều hướng tiếp cận cạnh nhau thay vì đọc tuần tự, rồi chuyển thành kế hoạch triển khai có sơ đồ luồng và mốc thời gian. Xem lại mã nguồn và hiểu cấu trúc dự án: Phần thay đổi được chú thích trực tiếp bằng màu sắc theo mức độ nghiêm trọng, sơ đồ mô-đun dạng hộp và mũi tên — thay vì văn bản thuần túy. Thiết kế giao diện: Bảng màu hiển thị thực tế có thể sao chép ngay, các biến thể thành phần giao diện được dựng trực tiếp thay vì mô tả bằng chữ. Tạo nguyên mẫu nhanh: Bảng điều chỉnh hiệu ứng chuyển động có thanh kéo thông số, màn hình có thể nhấp thực sự, đây là thứ Markdown không thể biểu đạt. Sơ đồ và hình minh họa: Đồ họa véc-tơ nội tuyến cho phép vẽ lưu đồ thực sự, không phải ký tự ASCII ghép lại. Bộ trình chiếu: Vài thẻ <section> và 20 dòng mã JavaScript là một bộ slide điều hướng bằng phím mũi tên mà không cần phần mềm chuyên dụng hay bước xuất file. Nghiên cứu và học tập: Tài liệu có phần thu gọn, tab mã, bảng chú giải thuật ngữ — thay vì đổ toàn bộ nội dung theo một chiều dọc. Báo cáo định kỳ: Bản tóm tắt trạng thái hàng tuần với biểu đồ nhỏ và màu sắc phân biệt tiến độ khiến người đọc thực sự đọc, không chỉ lướt qua. Giao diện chỉnh sửa tùy chỉnh: Bảng phân loại nhiệm vụ kéo thả, trình chỉnh cờ tính năng có cảnh báo phụ thuộc đây là công cụ thực sự, không phải văn bản đọc rồi thôi. Thariq đã tập hợp 20 file minh họa tất cả các nhóm này tại thariqs.github.io/html-effectiveness mỗi file mở thẳng trên trình duyệt, không cần cài đặt gì thêm. Dùng HTML với AI như thế nào trong thực tế? Cách áp dụng không phức tạp mà chỉ cần thay đổi cách bạn viết prompt. Thay vì để mô hình tự chọn định dạng đầu ra, hãy chỉ định rõ HTML khi nội dung cần được xem xét, tương tác, hoặc chia sẻ với người khác. Ví dụ câu lệnh Thariq gợi ý để xem lại một đoạn mã: Giúp tôi xem xét PR này bằng cách tạo một tài liệu HTML mô tả nó. Tôi không quen lắm với logic streaming/backpressure nên hãy tập trung vào phần đó. Hiển thị diff thực tế với các chú thích lề nội tuyến, mã màu các phát hiện theo mức độ nghiêm trọng và bất cứ thứ gì khác cần thiết để diễn đạt khái niệm một cách rõ ràng. Tương tự, bạn có thể yêu cầu AI tạo kế hoạch triển khai dưới dạng HTML với mốc thời gian và sơ đồ luồng dữ liệu, hoặc bản báo cáo trạng thái hàng tuần với biểu đồ nhỏ và màu sắc phân biệt tiến độ. Simon Willison tác giả blog kỹ thuật nổi tiếng cũng đã thừa nhận bài viết này khiến ông nhìn lại thói quen dùng Markdown từ thời GPT-4 cho đến tận thời điểm hiện tại. Khi các mô hình AI hiện đại có thể nhúng đồ họa véc-tơ, tiện ích tương tác và điều hướng nội trang, Markdown không còn là lựa chọn mặc định hiển nhiên nữa. Markdown vẫn còn chỗ đứng tất nhiên không phải ở mọi nơi Thariq không nói luôn luôn sử dụng HTML mà anh ấy phân biệt khá rõ: Markdown phù hợp cho trò chuyện thông thường, đoạn mã ngắn, câu trả lời vài dòng, và bất cứ thứ gì thuần văn bản trong khi đó HTML phát huy sức mạnh khi đầu ra cần bố cục không gian, màu sắc, khả năng tương tác, hoặc cấu trúc phức tạp đó là khi nội dung đủ nhiều chiều để Markdown bắt đầu làm phẳng thông tin thay vì truyền tải nó. Cộng đồng đã phản ứng khá nhanh: một skil mang tên html-artifacts đã xuất hiện trên GitHub, giúp AI tự nhận biết khi nào nên tạo file HTML thay vì Markdown bao gồm 9 nhóm tình huống từ bài viết gốc của Thariq hoàn toàn có thể sử dụng với bất cứ model nào hỗ trợ đọc skill. Đặc biệt skill này phần loại trừ rõ ràng cho câu trả lời ngắn và đầu ra chỉ có mã code. Mọi người có thể tham khảo tại github.com/dogum/html-artifacts. Trong bài Thariq không nhắc đến JSON nhưng đây cũng là định dạng hay sử dụng với AI đặc biệt đối với những ai hay dùng n8n, Make hay Zapier. Mặc dù vậy mỗi định dạng mang đến một màu sắc riêng trong những tình huống riêng. Markdown, HTML và JSON phân chia sử dụng như thế nào Cuộc tranh luận thực ra không chỉ là Markdown hay HTML. JSON cũng là định dạng phổ biến khi làm việc với AI, đặc biệt trong các luồng xử lý dữ liệu và tích hợp hệ thống. Ba định dạng này phục vụ ba mục đích khác nhau, và hiểu rõ ranh giới đó giúp bạn chọn đúng công cụ cho từng tình huống. Markdown tốt nhất cho văn bản đọc trực tiếp trong chat: ghi chú, giải thích ngắn, đoạn mã, tài liệu đơn giản. Nhanh, nhẹ, không cần mở thêm gì. HTML tốt nhất khi đầu ra cần được nhìn, tương tác hoặc chia sẻ: báo cáo có bố cục, sơ đồ, bảng so sánh, bộ trình chiếu, giao diện tùy chỉnh. Mở bằng trình duyệt là xong. JSON tốt nhất khi đầu ra cần được máy đọc tiếp: lưu trữ dữ liệu có cấu trúc, truyền giữa các hệ thống, hoặc làm đầu vào cho bước xử lý tiếp theo. Con người đọc được nhưng không phải để đọc. Nói cách khác, JSON không cạnh tranh với HTML hay Markdown về mặt trình bày mà nó phục vụ một mục đích hoàn toàn khác. Vấn đề thực sự nằm ở chỗ nhiều người dùng AI mặc định nhận đầu ra dưới dạng Markdown ngay cả khi họ cần HTML để xem, hoặc cần JSON để xử lý tiếp. Chỉ cần chỉ định rõ trong câu lệnh, AI sẽ điều chỉnh theo. Quy tắc chọn nhanh: Đầu ra để đọc trong chat → Markdown. Đầu ra để xem trên trình duyệt → HTML. Đầu ra để máy xử lý tiếp → JSON. Điều này có làm thay đổi gì với người dùng AI thông thường? Nếu bạn dùng AI chủ yếu để hỏi đáp hoặc viết lách, thay đổi này ít tác động hơn. Nhưng nếu bạn đang dùng AI để làm nhiều việc hơn như phân tích dữ liệu, lên kế hoạch dự án, xem lại tài liệu, tổng hợp nghiên cứu, hay tạo báo cáo cho đồng nghiệp đây là điều chỉnh nhỏ trong cách prompt nhưng tạo ra khoảng cách rõ rệt về chất lượng đầu ra, dù bạn đang dùng công cụ AI nào. Bạn nên thử một lần: lần tới khi cần AI so sánh các lựa chọn hoặc tóm tắt một tài liệu phức tạp, thêm vào cuối câu lệnh "tạo dưới dạng file HTML ". Mở file đó trên trình duyệt và so sánh với cách bạn vẫn làm với Markdown hay JSON thì kết quả thường nói lên tất cả.

9 giây đó chính xác là thời gian trên Cursor mà AI agent lập trình chạy trên Claude Opus 4.6 cần để xóa sạch toàn bộ cơ sở dữ liệu production và toàn bộ bản sao lưu của PocketOS trên Railway. Sau đó agent viết thư thú nhận: "Tôi đã vi phạm mọi nguyên tắc được giao cho mình." Nhưng lời xin lỗi không phục hồi được ba tháng dữ liệu đặt xe của hàng trăm khách hàng. Chuyện gì xảy ra với PocketOS? PocketOS là nền tảng phần mềm quản lý vận hành cho các công ty cho thuê xe, được thành lập bởi Jer Crane. Khi Crane đang dùng Cursor chạy Claude Opus 4.6 để xử lý một tác vụ bình thường trong môi trường staging - tức là môi trường thử nghiệm riêng biệt, không phải hệ thống đang chạy thực tế (production). Agent gặp lỗi xác thực và thay vì dừng lại để báo cáo, nó tự quyết định sửa vấn đề bằng cách xóa một volume trên Railway (nhà cung cấp hạ tầng đám mây của PocketOS). Để thực hiện lệnh xóa, agent tìm kiếm trong các file không liên quan đến tác vụ đang làm và tìm thấy một API token được tạo ra chỉ để thêm và xóa tên miền tùy chỉnh qua Railway CLI. Token đó, trên thực tế, có toàn quyền kiểm soát toàn bộ hạ tầng đám mây thông qua Railway GraphQL API. Lệnh xóa không có bước xác nhận nào. Không có "gõ DELETE để xác nhận." Không có "volume này chứa dữ liệu production, bạn có chắc không?" Chín giây sau toàn bộ cơ sở dữ liệu production biến mất và Railway lại lưu bản sao lưu trong cùng volume với dữ liệu gốc nên nghĩa là xóa volume là cũng xóa luôn cả bản sao lưu do đó PocketOS mất cả hai thứ cùng một lúc. Agent xin lỗi, nhưng lời xin lỗi không phục hồi dữ liệu Phần gây chú ý nhất trong toàn bộ câu chuyện là những gì agent viết sau đó. Khi Crane hỏi Cursor chuyện gì xảy ra, agent tự phân tích và thú nhận: "Tôi đã vi phạm mọi nguyên tắc được giao cho mình. Tôi đoán thay vì xác minh. Tôi thực thi lệnh phá hủy mà không được yêu cầu. Tôi truy cập token từ file hoàn toàn không liên quan đến tác vụ của mình." Lời thú nhận đầy đủ, logic rõ ràng, không né tránh trách nhiệm. Nhưng lời thú nhận hoàn hảo đó không phục hồi được một bản ghi dữ liệu nào. PocketOS trải qua hơn 30 giờ ngừng hoạt động cuối tuần đó và đội ngũ phải bỏ cả cuối tuần dựng lại cơ sở dữ liệu thủ công từ lịch sử thanh toán Stripe và nhật ký email để giữ cho khách hàng tiếp tục vận hành được. Đây chính là điều khiến vụ việc này khó chịu hơn bất kỳ lỗi phần mềm thông thường nào: agent đủ thông minh để nhận ra mình đã làm sai, giải thích chi tiết tại sao sai, nhưng không đủ khôn ngoan để hỏi một câu trước khi thực hiện hành động phá hủy không thể đảo ngược. Ai chịu trách nhiệm ở đây Cursor, Claude hay Railway? Crane rất rõ ràng trong bài viết của mình: ông nhấn mạnh rằng đội ngũ đang dùng phiên bản Cursor tốt nhất có thể, chạy trên model tốt nhất ngành bán ra, được cấu hình với các quy tắc an toàn rõ ràng. Điều này đóng lại ngay lập tức lập luận phổ biến nhất của các nhà cung cấp AI khi sự cố xảy ra: "bạn nên dùng model tốt hơn." Tuy nhiên Crane đặt phần lớn trách nhiệm vào Railway hơn là vào Cursor hay Claude. API của Railway cho phép thực hiện hành động phá hủy mà không cần xác nhận, lưu bản sao lưu trong cùng volume với dữ liệu gốc và xóa volume là xóa tất cả bản sao lưu. Thêm vào đó, các token API không có Kiểm soát truy cập dựa trên vai trò (RBAC) tức là một token được tạo cho việc quản lý tên miền đơn giản lại có quyền xóa toàn bộ hạ tầng production. Nhưng cộng đồng cũng chỉ ra phần trách nhiệm của Crane: các AI agent không được trao quyền truy cập token đó, nhưng nó tìm thấy token trong một file không được bảo vệ đúng cách. Crane phản bác: "Tôi không trao quyền truy cập, nó tự tìm thấy." Điều đó đúng về mặt kỹ thuật nhưng không thay đổi được kết quả. Vòng lặp xin lỗi quen thuộc Nếu bạn đã làm việc với AI đủ lâu, bạn sẽ nhận ra một cách trả lời cực kì quen thuộc trong câu chuyện này, chỉ là ở quy mô lớn hơn nhiều. Phiên bản nhẹ nhàng hơn nghe như thế này: "Tôi thật sự xin lỗi đã làm bạn thất vọng vì đã xóa dữ liệu của bạn. Tôi sẽ phục hồi ngay nhưng xin lỗi tôi chỉ phục hồi được một nửa thôi, phần còn lại bạn tự làm nhé." Phiên bản thẳng thắn hơn trong môi trường thực tế nghe như thế này: agent tự tin thực hiện, tự tin xóa, tự tin thú nhận, rồi để lại cho bạn cái hậu quả. Sự tự tin không đi kèm thận trọng là thứ nguy hiểm nhất trong bất kỳ hệ thống tự động nào, dù là AI hay con người. Điều đáng nói là đây không phải lần đầu và sẽ không phải lần cuối. Khi agent ngày càng được trao nhiều quyền hơn để làm việc hiệu quả hơn, khoảng cách giữa "tiện lợi" và "thảm họa" có khi lại rất gần. Bốn bài học thực tế cho bất kỳ ai đang dùng AI agent Không bao giờ để token có quyền xóa, sửa, cập nhật trong file mà agent có thể truy cập Token API nên được phân quyền tối thiểu và lưu trong môi trường biến (environment variables) với quyền truy cập hạn chế, không nằm trong file trong thư mục dự án mà AI agent đang làm việc. Token quản lý tên miền không bao giờ nên có quyền xóa cơ sở dữ liệu. Đây là nguyên tắc tối thiểu phải có và vụ PocketOS cho thấy hậu quả khi nguyên tắc này bị bỏ qua dù vô tình. Bản sao lưu phải ở chỗ riêng biệt hoàn toàn Lưu bản sao lưu cùng chỗ với dữ liệu gốc là cực kì rủi ro. Bản sao lưu phải ở một hệ thống lưu trữ độc lập, tốt nhất là ở nhà cung cấp khác hoặc ít nhất là được bảo vệ bởi chính sách xóa riêng biệt mà AI agent không thể tự truy cập. Mọi hành động thay đổi dữ liệu quan trọng phải có bước xác nhận thủ công Bất kỳ lệnh nào liên quan đến xóa, ghi đè hoặc thay đổi không thể đảo ngược phải yêu cầu con người xác nhận, tuyệt đối không được để AI agent tự quyết định. Đây là nguyên tắc tương tự mà các hệ thống tài chính áp dụng từ hàng chục năm nay và không có lý do gì để bỏ qua khi dùng AI agent. Thiết lập môi trường thử nghiệm thực sự tách biệt Môi trường thử nghiệm (staging) phải hoàn toàn tách rời khỏi hệ thống đang hoạt động (production) về mặt credentials, token và quyền truy cập không chỉ mỗi mặt dữ liệu. Nếu agent đang làm việc trong staging có thể tìm thấy và sử dụng token của production, thì thử nghiệm và production đang không thực sự tách biệt. Câu hỏi thực sự mà vụ PocketOS đặt ra Câu hỏi không phải là "AI có nên được trao quyền làm việc tự động không?" mà là "Chúng ta đang xây dựng các quy tắc an toàn như thế nào khi trao quyền đó?" Crane chỉ ra rằng Railway đang tích cực khuyến khích khách hàng dùng AI coding agent trên nền tảng của họ trong khi kiến trúc bảo mật của họ chưa sẵn sàng cho điều đó, mặc dù họ đã sửa lỗi cập nhật API ngay sau đó. Đây là khoảng cách nguy hiểm nhất hiện tại: công cụ phát triển nhanh hơn nhiều so với các lớp bảo vệ xung quanh chúng. PocketOS cuối cùng đã phục hồi được phần lớn dữ liệu sau khi Railway can thiệp, nhưng quá trình đó mất hàng giờ giúp khách hàng dựng lại lịch đặt xe từ lịch sử thanh toán Stripe và tích hợp lịch. Điều đó không nên xảy ra với bất kỳ hệ thống đang hoạt động nào, dù agent thông minh đến đâu. Agent có thể xin lỗi rất hay nhưng khi thiết lập quy tắc an toàn tốt thì không cần đến lời xin lỗi.

Claude Memory đã mở miễn phí cho tất cả người dùng tức là Claude có thể tự động nhớ tên bạn, nghề nghiệp và một số sở thích từ các cuộc trò chuyện trước. Nghe có vẻ đủ dùng, nhưng nếu bạn đang làm 3 dự án song song với 3 bộ tài liệu, 3 phong cách viết và 3 yêu cầu khác nhau, khi đó context sẽ lớn dần lên thì memory sẽ không giúp được gì nhiều. Đó là lúc Project trở thành thứ bạn thực sự cần. Memory và Project khác nhau như thế nào? Claude Memory hoạt động như bộ nhớ cá nhân của Claude về bạn, nghĩa là nó ghi lại những thông tin chung xuyên suốt mọi cuộc trò chuyện: bạn là ai, bạn làm nghề gì, bạn thích phong cách giao tiếp nào. Đây là lớp nhận biết danh tính, không phải ngữ cảnh công việc. Project là lớp ngữ cảnh chuyên biệt cho từng dự án cụ thể. Bạn có thể có một Memory duy nhất về bản thân nhưng có 10 Project khác nhau, trong đó mỗi Project chứa tài liệu riêng, hướng dẫn riêng và lịch sử hội thoại riêng, hoàn toàn độc lập với nhau. Hình dung thế này: Memory giống như thẻ căn cước của bạn giúp Claude luôn biết bạn là ai. Project giống như từng hồ sơ công việc riêng biệt và khi bạn mở Project nào, Claude biết đúng bối cảnh của dự án đó, không bị lẫn sang dự án khác. Ví dụ thực tế: Memory giúp Claude biết bạn là nhân viên marketing cho web, nhưng Project "Website khách hàng A" chứa tài liệu marketing, brief dự án và các quyết định kỹ thuật cụ thể, đây là thứ Memory không bao giờ lưu được vì nó không thuộc về bạn mà thuộc về dự án đó. Project trong Claude là gì? Project là không gian làm việc riêng biệt trong Claude, nơi bạn có thể lưu trữ tài liệu, viết hướng dẫn tùy chỉnh và giữ lịch sử hội thoại theo từng chủ đề hoặc dự án cụ thể. Thay vì mỗi cuộc trò chuyện là một tờ giấy trắng, Project cho phép Claude luôn có sẵn ngữ cảnh về công việc bạn đang làm trước khi bạn gõ câu đầu tiên. Nếu Memory là thứ Claude biết về bạn, thì Project là thứ Claude biết về công việc cụ thể bạn đang làm, và sự kết hợp của cả hai mới tạo ra trải nghiệm AI thực sự hiểu bạn. Giới hạn theo gói dịch vụ Tài khoản miễn phí có thể tạo tối đa 5 Project. Gói trả phí (Pro, Max, Team, Enterprise) được tạo không giới hạn Project và có thêm tính năng RAG, tức là khi bạn tải lên nhiều tài liệu đến mức vượt giới hạn context window, Claude tự động chuyển sang chế độ tìm kiếm thông minh để mở rộng dung lượng lên 10 lần mà không mất chất lượng phản hồi. Tài khoản Team và Enterprise có thêm tính năng chia sẻ Project và phân quyền thành viên. Cách thiết lập Project để Claude hiểu bạn hơn Bước 1: Viết hướng dẫn tùy chỉnh Đây là phần quan trọng nhất và cũng là phần nhiều người bỏ qua nhất. Hướng dẫn tùy chỉnh là đoạn văn bạn viết một lần và Claude sẽ đọc trước mỗi cuộc hội thoại trong Project đó. Một hướng dẫn tốt không phải là danh sách quy tắc dài mà là bức tranh ngắn gọn về bạn và kỳ vọng của bạn. Ví dụ hướng dẫn cho người làm content: Ví dụ hướng dẫn project content writing: Mình là content manager tại một website về AI. Phong cách viết: gần gũi, dùng nhiều tiếng Việt, tránh từ sáo rỗng và cấu trúc câu cụt. Đối tượng đọc là người quan tâm đến AI nhưng không nhất thiết có nền tảng kỹ thuật. Mọi bài viết cần có ví dụ thực tế, tránh lý thuyết chung chung. Khi mình nói "viết bài", mặc định là 1.000–1.200 từ dạng HTML với h2, h3, ul, li và p. Với hướng dẫn này, mỗi lần bạn yêu cầu "viết bài về Claude Opus 4.7", Claude không cần hỏi thêm về định dạng, độ dài hay phong cách vì nó đã biết tất cả. Ví dụ hướng dẫn cho lập trình viên: Ví dụ hướng dẫn Project lập trình: Mình đang xây dựng ứng dụng web với Next.js 15, TypeScript, Tailwind CSS và Firebase. Khi giải thích code, dùng tiếng Việt. Khi viết code, luôn dùng TypeScript và thêm comment tiếng Anh. Ưu tiên giải pháp đơn giản hơn giải pháp "đúng sách" nếu không cần thiết. Nếu có nhiều cách giải quyết, trình bày ngắn gọn trade-off trước khi đề xuất. Bước 2: Tải tài liệu vào knowledge base Project cho phép bạn tải lên tài liệu dưới dạng PDF, DOCX, CSV, TXT, HTML và nhiều định dạng khác, với dung lượng tối đa 30MB mỗi file. Claude sẽ đọc và tham chiếu những tài liệu này trong mọi cuộc hội thoại trong Project. Tài liệu nên đưa vào tùy theo mục đích sử dụng: Project viết lách: Phong cách viết của bạn, các bài viết mẫu bạn muốn Claude học phong cách, danh sách từ khóa SEO, thông tin sản phẩm hay dịch vụ bạn thường đề cập. Project nghiên cứu: Tài liệu tham khảo, báo cáo nền, danh sách nguồn tin uy tín, ghi chú từ các buổi đọc trước đó. Project lập trình: Tài liệu API bạn đang dùng, file README của dự án, các quyết định kiến trúc đã được ghi lại, danh sách lỗi đã gặp và cách giải quyết. Project cá nhân: Thông tin về bản thân bạn, bao gồm mục tiêu, lịch biểu, thói quen làm việc, những gì bạn đang tập trung để Claude có thể đưa ra lời khuyên phù hợp hơn. Có thể đưa Skill vào Project không? Câu trả lời là có và đây là cách nhiều người dùng nâng cao đang kết hợp hai tính năng này. Skill trong Claude là tập hợp hướng dẫn được đóng gói giúp Claude biết cách xử lý một loại tác vụ cụ thể như skill viết bài theo chuẩn SEO, skill phân tích code, hay skill tóm tắt tài liệu pháp lý. Khi bật Skill trong một Project, Claude có cả ngữ cảnh cụ thể về dự án của bạn (từ knowledge base và hướng dẫn tùy chỉnh) lẫn quy trình chuyên biệt (từ Skill). Hai lớp này bổ trợ nhau thay vì xung đột, trong đó Skill định nghĩa cách làm, Project định nghĩa bối cảnh. Ví dụ thực tế: nếu bạn có Skill viết bài theo chuẩn AIDA và bật nó trong Project content của mình, Claude sẽ tự động áp dụng phong cách và cấu trúc từ Skill đồng thời sử dụng style guide, danh sách từ khóa và các bài mẫu bạn đã tải vào Project mà không cần bạn giải thích lại bất kỳ điều gì. Ba cách dùng Project hiệu quả nhất Project hiểu về mình để dùng Claude như trợ lý cá nhân Đây là cách dùng ít người nghĩ đến nhưng lại có giá trị lớn. Tạo một Project tên “Giới thiệu về tôi” và điền vào đó những thông tin Claude cần để hỗ trợ bạn tốt hơn: công việc hiện tại, các dự án đang chạy, mục tiêu ngắn và dài hạn, những kỹ năng bạn đang học, thói quen làm việc và ngay cả những điểm yếu bạn muốn cải thiện. Sau khi có Project này, bạn có thể hỏi những câu rất cụ thể như "Với lịch biểu tuần này, mình nên ưu tiên học gì?" hay "Gợi ý cách cân bằng giữa dự án A và dự án B?" mà không cần giải thích từ đầu bạn là ai và đang trong hoàn cảnh nào. Project theo khách hàng hoặc dự án Nếu bạn làm việc với nhiều khách hàng hoặc dự án song song, mỗi Project là một không gian độc lập. Tải vào đó brief dự án, thông tin khách hàng, các cuộc trò chuyện quan trọng trước đó và yêu cầu cụ thể. Khi cần làm việc cho khách hàng đó, mở Project tương ứng và Claude hiểu ngay bối cảnh mà không cần bạn tóm tắt lại. Project học và nghiên cứu Khi học một chủ đề mới như AI agent, kinh tế học hành vi hay lập trình thì nên tạo một Project riêng cho chủ đề đó. Tải vào đó các tài liệu bạn đang đọc, ghi chú của bạn, danh sách câu hỏi chưa được trả lời. Claude trong Project này trở thành người hướng dẫn hiểu rõ bạn đang ở đâu trong hành trình học và có thể tiếp tục từ đúng điểm bạn dừng lại ở buổi trước. Các câu hỏi thường gặp về Project trong Claude Project trong Claude khác gì với Project trong Cowork? Đây là câu hỏi dễ gây nhầm nhất vì Anthropic dùng cùng từ "Project" cho hai thứ khác nhau. Project trong Claude.ai (trên trình duyệt) là không gian chat có bộ nhớ và knowledge base, bạn tải tài liệu lên, viết hướng dẫn, và Claude nhớ ngữ cảnh đó trong mọi cuộc trò chuyện bên trong. Nhưng nó chỉ là chat và Claude không thể tạo file thực sự, chạy code hay tự động hóa tác vụ. Project trong Cowork (ứng dụng desktop) là cấp độ tiếp theo: Claude không chỉ nhớ ngữ cảnh mà còn thực sự làm việc, bao gồm tạo file Word, Excel, PDF, chạy code, điều khiển trình duyệt, lên lịch tác vụ tự động. Nếu Claude.ai Project là "trợ lý nhớ tốt hơn", thì Cowork Project gần hơn với "nhân viên AI làm việc thay bạn". Ví dụ phân biệt thực tế: trong Claude.ai Project bạn có thể hỏi "phân tích báo cáo doanh thu tháng này" và Claude trả lời bằng văn bản. Trong Cowork Project, Claude đọc file Excel thực của bạn, tạo ra bảng phân tích mới và lưu thành file PDF mà không cần bạn copy paste gì cả. Nếu bạn chỉ cần tư vấn, viết lách và trò chuyện có ngữ cảnh sâu thì Project trên Claude là đủ. Nếu bạn muốn AI thực sự xử lý công việc và tạo ra sản phẩm đầu ra thì Cowork Project là lựa chọn đúng và đủ. Hướng dẫn tùy chỉnh nên dài bao nhiêu là đủ? 5 đến 8 câu thường là đủ và hiệu quả hơn một đoạn dài 500 từ. Claude đọc tốt nhất những hướng dẫn súc tích, rõ ý, không phải những bản mô tả quá chi tiết đến mức mâu thuẫn nhau. Ví dụ hướng dẫn ngắn gọn hiệu quả: "Mình là content manager cho website AI, viết cho người không chuyên kỹ thuật, dùng tiếng Việt gần gũi, mặc định bài 1.000–1.200 từ dạng HTML." Đặt tên Project như thế nào cho dễ quản lý? Tránh tên chung chung như "Dự án 1" hay "Công việc" vì khi số lượng Project tăng lên bạn sẽ không nhớ cái nào là cái nào. Nên đặt tên theo mục đích và thời gian để dễ tìm lại. Ví dụ tên tốt: "Content AIDA — tháng 4/2026", "Dự án web Next.js cho khách hàng ABC", "Nghiên cứu AI agent — Q2 2026". Khi nào nên xóa hoặc cập nhật tài liệu trong Project? Thông tin cũ hoặc không còn liên quan sẽ làm nhiễu phản hồi của Claude vì nó vẫn cố tham chiếu những gì đã lỗi thời. Nên xem lại knowledge base mỗi 4 đến 6 tuần, xóa những gì hết hạn và thêm vào tài liệu mới hơn, đặc biệt khi bối cảnh dự án thay đổi đáng kể. Ví dụ: nếu bạn muốn đổi hướng đi vì hướng đi cũ đã lỗi thời vì Claude đã cập nhật liên tục, vì vậy hãy xóa đi và tải tài liệu chuẩn mới vào cho phù hợp. Project có thực sự tốt hơn chat thông thường không? Điểm khác biệt thực sự không phải là tính năng kỹ thuật mà là sự tích lũy theo thời gian. Một chat mới là tờ giấy trắng, còn một Project được bổ sung đều đặn trong 3 tháng sẽ cho ra kết quả tốt hơn đáng kể vì mỗi tài liệu, mỗi hướng dẫn bạn thêm vào là một lớp ngữ cảnh giúp Claude hiểu bạn và công việc của bạn sâu hơn. Ví dụ: sau 3 tháng dùng Project nghiên cứu AI, Claude biết bạn đã đọc những tài liệu nào, bạn đang theo hướng nghiên cứu nào và bạn hay dùng tư duy gì, từ đó câu trả lời cụ thể và liên kết hơn hẳn so với hỏi trong chat trống, và còn tuyệt vời hơn nữa khi nó có thể tổng hợp những kiến thức bạn đã học và làm được trong 3 tháng qua.