Claude Opus 4.7 ra mắt mạnh hơn nhưng đốt token hơn

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.

Ba cái tên Sol, Terra và Luna khiến GPT-5.6 trông giống một hệ sản phẩm hơn là một model đơn lẻ. Cách đặt tên này cũng cho thấy điều OpenAI muốn thay đổi: người dùng không còn phải chọn giữa một model mạnh nhưng đắt và một model nhỏ nhưng yếu, thay vào đó họ có ba mức năng lực được thiết kế cho ba kiểu công việc khác nhau. Tuy nhiên, GPT-5.6 hiện mới ở giai đoạn preview giới hạn và OpenAI nói rõ rằng dòng model này chưa có trong ChatGPT trong thời gian preview.Ở phía đối diện, Claude Fable 5 được Anthropic định vị là model mạnh cho reasoning, lập trình, nghiên cứu khoa học và các tác vụ agentic kéo dài. Vì vậy, câu hỏi đáng quan tâm không chỉ là model nào thông minh hơn, mà là kiến trúc sản phẩm nào giúp người dùng hoàn thành công việc tốt hơn với chi phí có thể kiểm soát.GPT-5.6 thực sự là gì?Theo thông báo preview của OpenAI, GPT-5.6 gồm ba phiên bản Sol, Terra và Luna. Sol là model chủ lực có năng lực cao nhất, Terra là lựa chọn mạnh với chi phí thấp hơn, còn Luna là model nhanh và tiết kiệm nhất trong dòng sản phẩm.Điểm quan trọng nằm ở cách OpenAI chia nhu cầu thành ba tầng. Một nhóm nghiên cứu có thể dùng Sol để xử lý bài toán khó, một đội sản phẩm có thể dùng Terra cho phần lớn công việc hằng ngày, trong khi một hệ thống xử lý hàng nghìn yêu cầu ngắn có thể dùng Luna để giảm độ trễ. Cách tổ chức này gần với chiến lược hạ tầng hơn là cách ra mắt một chatbot mới.Lưu ý về phạm vi phát hành: OpenAI cho biết GPT-5.6 chưa có trong ChatGPT trong giai đoạn preview. Trải nghiệm trên API, công cụ dành cho developer hoặc nền tảng đối tác không nên được hiểu là trải nghiệm ChatGPT chính thức.Sol dành cho công việc khó và dàiSol được định vị là model mạnh nhất của GPT-5.6, phù hợp với nhiệm vụ cần reasoning sâu, lập trình nhiều bước và kiểm tra chéo kết quả. Ví dụ, một đội kỹ thuật có thể giao cho Sol việc đọc cấu trúc repository, tìm nguyên nhân lỗi, đề xuất bản vá và viết kiểm thử hồi quy. Giá trị của Sol không nằm ở việc trả lời nhanh một câu hỏi ngắn, mà ở khả năng giữ mục tiêu xuyên suốt một chuỗi hành động dài.OpenAI cũng nhấn mạnh mức cải thiện về năng lực cyber khi reasoning tăng. Điều này có ích cho kiểm tra bảo mật và phân tích lỗ hổng trong môi trường được cấp phép, nhưng đồng thời khiến việc kiểm soát quyền truy cập, ghi log và phê duyệt hành động trở nên quan trọng hơn.Terra là lựa chọn cân bằngTerra hướng đến phần việc rộng nhất: phân tích tài liệu, viết nội dung, lập trình ứng dụng, tổng hợp nghiên cứu và hỗ trợ vận hành. Nếu Sol giống một chuyên gia được gọi vào khi bài toán thật sự khó, Terra giống một thành viên mạnh có thể làm việc liên tục trong ngày mà không khiến chi phí tăng quá nhanh.Ví dụ, một nhóm marketing có thể dùng Terra để đọc báo cáo thị trường, trích xuất insight, xây dựng dàn ý và tạo nhiều phiên bản nội dung. Một đội phát triển có thể dùng Terra cho code review, viết test và xử lý ticket có phạm vi rõ ràng. Đây là tầng model có khả năng trở thành lựa chọn mặc định nếu chất lượng thực tế ổn định.Luna ưu tiên tốc độ và quy môLuna được thiết kế cho phản hồi nhanh và chi phí thấp. Các tác vụ như phân loại yêu cầu, tóm tắt đoạn hội thoại, trích xuất trường dữ liệu, tạo bản nháp hoặc định tuyến ticket thường không cần model mạnh nhất. Trong những trường hợp đó, độ trễ và tổng chi phí quan trọng hơn khả năng reasoning cực đại.Tuy nhiên, nhanh không đồng nghĩa với phù hợp cho mọi việc. Nếu nhiệm vụ yêu cầu kiểm chứng nguồn, lập kế hoạch nhiều bước hoặc chỉnh sửa code có ảnh hưởng lớn, người dùng nên chuyển sang Terra hoặc Sol thay vì cố ép Luna xử lý vượt quá vai trò của nó.Claude Fable 5 chọn một hướng khácAnthropic giới thiệu Claude Fable 5 như một model frontier dành cho reasoning, software engineering, vision, nghiên cứu khoa học và công việc agentic dài. Thay vì nhấn mạnh ba tầng sản phẩm trong cùng một thế hệ, Anthropic tập trung thông điệp vào năng lực của một model mạnh có thể xử lý các nhiệm vụ phức tạp trong hệ sinh thái Claude.Sự khác biệt này ảnh hưởng trực tiếp đến cách doanh nghiệp triển khai. Với GPT-5.6, đội kỹ thuật có thể xây bộ định tuyến để gửi từng yêu cầu đến Sol, Terra hoặc Luna. Với Fable 5, trọng tâm có thể nằm ở việc tối ưu prompt, công cụ và ngân sách reasoning cho một model chủ lực. Không có cách nào luôn tốt hơn, bởi quyết định phụ thuộc vào loại workload và khả năng vận hành của từng tổ chức.Cách so sánh thực tế: Đừng dùng một prompt duy nhất rồi kết luận. Hãy tạo bộ test gồm tác vụ ngắn, tác vụ reasoning dài, coding, trích xuất dữ liệu và xử lý lỗi. Sau đó đo độ chính xác, thời gian phản hồi, số lần phải sửa và chi phí hoàn thành.Khác biệt trong coding và agentic workCả GPT-5.6 Sol và Claude Fable 5 đều hướng đến công việc lập trình phức tạp, nhưng trải nghiệm thực tế phụ thuộc nhiều vào công cụ bao quanh model. Khả năng đọc repository, chạy lệnh, quan sát kết quả và tự sửa sai thường quan trọng ngang với điểm benchmark. Nếu bạn làm việc với workflow OpenAI, trang Codex là điểm bắt đầu phù hợp để hiểu cách model tham gia vào quy trình coding.Fable 5 có lợi thế khi người dùng đã quen với hệ sinh thái Claude và các quy trình agentic dài. Bạn có thể đọc thêm bài Anthropic ra mắt Claude Fable 5 để xem cách Anthropic định vị model này và những nhóm công việc mà hãng muốn nhắm tới.Trải nghiệm ban đầu từ các diễn đàn nói gì?Các cuộc thảo luận ban đầu trên Reddit và cộng đồng developer tập trung nhiều vào câu hỏi Sol, Terra và Luna khác nhau đến đâu trong công việc thật. Một số người mô tả Sol là lựa chọn phù hợp cho nhiệm vụ nhiều bước, Terra dễ dùng hơn cho công việc thường xuyên, còn Luna gây chú ý nhờ tốc độ. Những nhận xét này phù hợp với cách OpenAI định vị ba model, nhưng chưa đủ để chứng minh khoảng cách chất lượng cụ thể.Phản hồi diễn đàn có giá trị vì nó cho thấy vấn đề người dùng thật đang quan tâm, tuy nhiên đây là dữ liệu tự chọn. Người đăng có thể dùng prompt khác nhau, quyền truy cập khác nhau và môi trường tích hợp khác nhau. Một kết quả tốt trên công cụ dành cho developer không đảm bảo sẽ giống hệt khi model xuất hiện trong ChatGPT.Điểm cộng được nhắc đếnBa tier giúp người dùng hình dung rõ hơn model nào phù hợp với từng loại tác vụ.Luna tạo kỳ vọng về độ trễ thấp cho các quy trình cần xử lý số lượng lớn.Terra có tiềm năng trở thành lựa chọn mặc định nếu giữ được chất lượng ổn định với chi phí dễ chịu.Sol được kỳ vọng mạnh hơn ở coding, reasoning dài và nhiệm vụ cần nhiều vòng kiểm tra.Những câu hỏi vẫn chưa có đáp án đầy đủKhoảng cách chất lượng thực tế giữa Sol và Terra lớn đến đâu trên workload phổ biến.Chi phí toàn phần khi tính cả số lần sửa, retry và thời gian người dùng phải kiểm tra.Hiệu quả của Luna khi prompt dài hoặc yêu cầu có nhiều ràng buộc.Mức độ ổn định khi OpenAI mở rộng GPT-5.6 từ preview sang ChatGPT, Codex và API.Không nên dùng phản hồi diễn đàn như benchmark: Trải nghiệm cộng đồng là tín hiệu để chọn bài test, không phải bằng chứng đủ mạnh để chọn model cho production.So sánh GPT-5.6 và Fable 5 theo công việcViết và phân tích tài liệuTerra có vẻ là lựa chọn hợp lý cho phần lớn công việc tài liệu vì nó được định vị cân bằng giữa năng lực và chi phí. Fable 5 có thể phù hợp khi tài liệu dài, câu hỏi phức tạp và người dùng muốn model duy trì lập luận xuyên suốt. Khi thử nghiệm, nên chấm cả độ chính xác của trích dẫn, khả năng giữ cấu trúc và mức độ chỉnh sửa cần thiết trước khi xuất bản.Lập trình và sửa lỗiSol và Fable 5 đều là ứng viên cho nhiệm vụ coding khó. Một bài test tốt nên bao gồm đọc code hiện có, tìm nguyên nhân, sửa tối thiểu, viết test và giải thích rủi ro. Nếu chỉ yêu cầu tạo một hàm mới từ đầu, kết quả có thể không phản ánh khả năng làm việc trong repository thật.Tác vụ số lượng lớnLuna có lợi thế định vị rõ ràng trong phân khúc tốc độ và chi phí. Với hàng nghìn yêu cầu trích xuất hoặc phân loại mỗi ngày, chênh lệch nhỏ về giá và latency có thể tạo ra tác động lớn. Fable 5 không nhất thiết là lựa chọn kinh tế cho loại workload này nếu tổ chức chỉ cần câu trả lời ngắn và có cấu trúc.Nghiên cứu và reasoning dàiSol và Fable 5 nên được so sánh bằng nhiệm vụ có đáp án kiểm chứng được, thay vì câu hỏi mở dễ tạo cảm giác thuyết phục. Ví dụ, hãy giao cùng một tài liệu nghiên cứu, yêu cầu xác định giả định, tìm mâu thuẫn, đề xuất thí nghiệm và chỉ ra phần nào chưa đủ bằng chứng. Model tốt hơn là model giúp người dùng phát hiện lỗi nhanh hơn, không phải model viết dài hơn.Nên chọn Sol, Terra, Luna hay Fable 5?Nếu ưu tiên chất lượng cao nhất trong hệ sinh thái OpenAI, Sol là lựa chọn đáng thử đầu tiên. Nếu cần một model mạnh để dùng thường xuyên, Terra có vị trí hợp lý hơn. Nếu workload gồm nhiều tác vụ ngắn và lặp lại, Luna có thể giảm chi phí đáng kể. Trong khi đó, Fable 5 phù hợp với đội nhóm đã đầu tư vào hệ sinh thái Claude hoặc cần reasoning và agentic work dài.Do GPT-5.6 vẫn ở giai đoạn preview, lựa chọn an toàn là không chuyển toàn bộ workload ngay lập tức. Hãy chạy thử song song trên dữ liệu thật, che thông tin nhạy cảm, ghi lại lỗi và dùng cùng tiêu chí đánh giá cho mọi model.Bộ kiểm tra có thể áp dụng ngayChọn 20 tác vụ đại diện cho công việc thật, gồm cả trường hợp dễ và khó.Chạy từng tác vụ trên Sol, Terra, Luna và Fable 5 nếu có quyền truy cập.Chấm độ chính xác, thời gian phản hồi, chi phí và số lần cần con người sửa.Ghi lại lỗi nghiêm trọng thay vì chỉ tính điểm trung bình.Chọn model theo từng nhóm tác vụ, không nhất thiết dùng một model cho mọi việc.GPT-5.6 có đáng để chuyển sang ngay không?Điểm mới đáng chú ý nhất của GPT-5.6 không chỉ là năng lực của Sol, mà là cách OpenAI biến một thế hệ model thành ba tầng vận hành rõ ràng. Điều đó có thể giúp doanh nghiệp kiểm soát chi phí tốt hơn, nhưng cũng đòi hỏi họ biết phân loại workload và xây cơ chế chuyển model phù hợp.Hành động thiết thực nhất lúc này là tạo một bộ test nhỏ từ dữ liệu thật của bạn. Nếu Sol thắng ở tác vụ khó, Terra đủ tốt cho phần lớn công việc và Luna xử lý tốt tác vụ số lượng lớn, kiến trúc ba tầng sẽ có giá trị. Nếu Fable 5 cho kết quả ổn định hơn trên reasoning dài, bạn vẫn có lý do để duy trì hệ thống đa model thay vì đặt cược vào một nhà cung cấp.

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

Đang ở ngoài đường mà nhớ ra một chi tiết nhỏ trong dự án cần thay đổi, bạn không nhất thiết phải mở laptop hay remote desktop vào máy. Nếu đã thiết lập kết nối, ChatGPT app trên điện thoại có thể trở thành màn hình điều khiển cho Codex, còn máy tính ở nhà hoặc văn phòng vẫn là nơi chạy code thật. ChatGPT app không chạy Codex trên điện thoại Điểm dễ hiểu sai nhất là tưởng Codex đang chạy trực tiếp trong điện thoại. Thực tế ở đây điện thoại chỉ gửi prompt, câu trả lời, phê duyệt và tin nhắn tiếp theo, trong khi môi trường làm việc thật nằm trên máy Mac hoặc Windows đang chạy Codex. Nói cách khác, app ChatGPT là bộ điều khiển từ xa, còn máy host mới là nơi có repo, terminal, credentials, plugin, MCP server và các công cụ khác. Cách vận hành này rất hợp lý vì codebase thường nằm trên máy phát triển, không nằm trên điện thoại. Khi bạn nhắn yêu cầu như sửa lỗi TypeScript, chạy test hoặc xem diff, Codex xử lý trong project đã chọn trên host rồi gửi lại kết quả để bạn theo dõi. Nếu bạn muốn tìm hiểu nền tảng trước khi dùng remote, có thể đọc bài Codex là gì và cách sử dụng Codex để nắm vai trò của công cụ này trong workflow làm việc. Cần chuẩn bị gì trước khi kết nối ChatGPT app và Codex? Theo tài liệu cập nhật Codex hiện tại của OpenAI, ChatGPT app đã hỗ trợ điều khiển Codex trên cả macOS và Windows còn hiện tại thì chưa có hỗ trợ ở Linux và đặc biệt là tính năng này hỗ trợ tất cả các tài khoản ChatGPT kể cả Free và Go. Sau đó bạn chỉ chuẩn bị đăng nhập cùng một tài khoản hoặc workspace trên cả hai thiết bị: ChatGPT mobile (bản mới nhất trên iOS hoặc Android) và Codex (bản mới nhất trên máy host đang online). Máy host phải luôn bật và Codex phải đang chạy trong suốt thời gian bạn điều khiển từ xa. Nếu máy sleep, mất mạng hoặc Codex App bị đóng, kết nối từ điện thoại sẽ mất ngay lập tức và mọi tác vụ đang chạy có thể bị gián đoạn. Điểm đáng chú ý là toàn bộ quá trình thiết lập bắt đầu từ Codex App trên máy host và rất đơn giản chỉ cần quét QR code là xong . Tức là trong Codex App, bạn chọn mục thiết lập Codex mobile ở sidebar, sau đó quét mã QR bằng điện thoại, rồi hoàn tất xác nhận trong ChatGPT app. Riêng với workspace doanh nghiệp, quản trị viên có thể cần bật quyền Remote Control trước rồi bạn mới có thể kết nối được. Mã QR này là để điều khiển máy tính của bạn, vì vậy bạn hãy bảo mật QR này không được phép chia sẻ để đảm bảo không có điều đáng tiếc xảy ra với máy tính của bạn Vậy mình tổng hợp lại bước kết nối giữa ChatGPT app và Codex khá là đơn giản Máy tính host cần online và đang chạy Codex ChatGPT app và Codex cần đăng nhập cùng tài khoản hoặc workspace Thiết lập mã QR Codex trên host và hoàn tất trên điện thoại Các yêu cầu MFA, SSO hoặc passkey vẫn có thể áp dụng Sau khi kết nối, bạn có thể làm gì? Khi host đã xuất hiện trong Codex trên điện thoại, bạn có thể bắt đầu thread mới trong project trên host hoặc tiếp tục thread đang có. Đây là phần làm trải nghiệm trở nên đáng giá: bạn có thể gửi follow up, trả lời câu hỏi của Codex, duyệt command, xem output, xem diff, xem test result, thậm chí nhận thông báo khi task hoàn tất hoặc cần bạn chú ý. Ví dụ thực tế, bạn đang ngồi cà phê và nhớ ra form đăng nhập có lỗi validate. Bạn có thể mở ChatGPT app, chọn host đang kết nối, nhắn rằng hãy kiểm tra luồng auth, sửa lỗi validate email và chạy test liên quan. Codex sẽ thao tác trên repo ở máy host, còn bạn chỉ cần xem kết quả, approve hành động khi cần và quyết định có yêu cầu chỉnh tiếp hay không. Đây cũng là lý do mọi người bắt đầu xem Codex hay các IDE khác như một đồng nghiệp làm việc trong môi trường thật, chứ không phải chỉ là một công cụ code nữa. Sức mạnh của nó nằm ở việc đọc file, chạy lệnh, chỉnh sửa code và giữ mạch công việc qua nhiều vòng trao đổi. Giới hạn nào cần nhớ khi dùng từ điện thoại với ChatGPT app Điều khiển qua điện thoại tất nhiên phụ thuộc hoàn toàn vào máy host nếu máy tính sleep, mất mạng, đóng Codex hoặc không còn đăng nhập đúng workspace, điện thoại sẽ không còn môi trường để điều khiển. Tuy nhiên nếu Codex đang thực hiện dở tác vụ thì nó sẽ vẫn thực hiện tiếp trên máy host và sẽ được thông báo xong ngay khi điện thoại kết nối lại nên mọi người sẽ bớt lo khi điện thoại tự nhiên mất mạng khi đang chạy dở trên Codex. Một lưu ý nữa là trên Windows, các tác vụ dùng Computer Use còn yêu cầu phiên làm việc chạy ở nền trước phù hợp, vì vậy đây không phải phương án thay thế hoàn toàn cho việc ngồi trực tiếp trước máy . Bạn cũng nên phân biệt việc giao một tác vụ gọn với việc review thay đổi lớn. Điện thoại rất hợp cho bug nhỏ, chạy test, hỏi nhanh về một file, duyệt các tác vụ ngắn hoặc kiểm tra trạng thái task. Tuy nhiên, các tác vụ yêu cầu làm việc với mức độ cao vẫn nên được review trên màn hình lớn để tránh bỏ sót chi tiết. Cách dùng thực tế cho hiệu quả Cách dùng hiệu quả nhất là giao việc có phạm vi rõ ràng và kết quả cụ thể. Thay vì nhắn chung chung "hãy sửa đăng nhập"thì hãy mô tả rõ lỗi xảy ra ở đâu, sau khi sửa kỳ vọng hành vi như thế nào, test nào cần chạy và phần nào không được đụng vào. Codex xử lý tốt hơn khi biết rõ ranh giới công việc, đặc biệt vì điều khiển qua điện thoại khiến mỗi vòng phản hồi chậm hơn so với ngồi trực tiếp trước máy. Một nhịp làm việc thực tế có thể là: mô tả chi tiết công việc cần làm dù nhỏ hay vừa, yêu cầu Codex đọc các file liên quan, để nó đề xuất hướng giải quyết, chỉ approve khi cần thiết và chờ báo cáo kết quả. Làm quen với nhịp này, bạn sẽ thấy những khoảng thời gian vụn vặt bên ngoài hoàn toàn có thể xử lý được việc thật, trong khi vẫn giữ quyền quyết định cuối cùng trong tay mình. So sánh với Claude Code Remote và Telegram bot Hiện có rất nhiều cách phổ biến để điều khiển AI coding agent từ điện thoại tuy nhiên mình mới chỉ biết đến 3 cách và mỗi cách phục vụ một nhu cầu khác nhau. Tiêu chí ChatGPT app + Codex Claude Code Remote Telegram + Codex Chat tự nhiên ✅ Rất tốt ✅ Tốt ❌ Cần đúng cú pháp Kiểm soát chi tiết Trung bình Cao nhất Thấp Độ ổn định kết nối Ổn định Ổn định Hay mất kết nối UI trên mobile Tối ưu tốt Chưa tối ưu hoàn toàn Dùng app Telegram sẵn có Setup ban đầu Dễ, quét QR Dễ Cần tự cấu hình bot Yêu cầu máy tính bật ✅ Bắt buộc ✅ Bắt buộc ✅ Bắt buộc Claude Code Remote Control là lựa chọn mạnh nhất về mặt kiểm soát bạn xem được terminal output trực tiếp, can thiệp giữa chừng được và cảm giác sát với agent hơn. Tuy nhiên UI trên màn hình điện thoại nhỏ chưa được tối ưu hoàn toàn, một số thao tác vẫn khó có thể thực hiện khi không có bàn phím vật lý. Telegram bot là lựa chọn không cần app riêng và dễ tiếp cận ban đầu, nhưng trải nghiệm thực tế có nhiều hạn chế: hay bị chậm, thi thoảng mất kết nối giữa chừng mà không báo trước, và vì thiếu context AI thực sự nên những yêu cầu phức tạp hơn một chút là bot bắt đầu không hiểu ý, buộc bạn phải gõ lệnh chính xác thay vì mô tả tự nhiên. ChatGPT app + Codex nằm ở điểm cân bằng tốt nhất cho phần lớn người dùng — đủ mượt, đủ thông minh, setup nhanh bằng QR và không cần học thêm cú pháp mới để bắt đầu. ChatGPT app kết nối với Codex không biến điện thoại thành máy lập trình, mà biến nó thành cửa điều khiển cho một máy phát triển đang sẵn sàng làm việc. Nếu host được bật, quyền được thiết lập đúng và task đủ gọn, đây là cách thực dụng nhất hiện tại để xử lý công việc code khi không ngồi trước laptop.