OpenComputer

Cơ sở hạ tầng máy ảo đám mây liên tục cho tác tử AI — mỗi tác tử có PC đám mây không bao giờ hết hạn

Báo cáo chuyên sâu

  • OpenComputer là một sản phẩm máy ảo đám mây ổn định do nhóm cơ sở hạ tầng Digger tạo ra và được thiết kế đặc biệt cho Đại lý AI. Về cơ bản, nó thoát khỏi khuôn khổ "đốt sau khi sử dụng" hộp cát truyền thống và cung cấp cho mỗi Tác nhân một máy tính đám mây thực sự, bền bỉ, có thể phục hồi khi ngủ đông. Nó được ra mắt trên Product Hunt vào ngày 25 tháng 7 năm 2026 và nhận được 221 phiếu bầu, xếp thứ 4 và đã tích lũy được 441 sao trên GitHub. Đối với các nền tảng B2B đang xây dựng các sản phẩm Đại lý như Devin, Bolt và Lovable, OpenComputer cung cấp đường dẫn nâng cấp từ "hộp cát tạm thời" lên "môi trường điện toán liên tục".

  • Công ty mẹ của OpenComputer là Digger, một công ty khởi nghiệp khởi đầu là một công cụ điều phối cơ sở hạ tầng. Sản phẩm chủ lực của Digger là công cụ điều phối IaC nguồn mở (~4.900 sao trên GitHub) phục vụ quy trình làm việc CI/CD của hơn 600 tổ chức. Công ty có một đội ngũ từ 2-10 người và đã nhận được 3,6 triệu USD trong vòng tài trợ hạt giống. Các thành viên cốt lõi của nhóm bao gồm CTO Mohamed Habib, trưởng bộ phận kỹ thuật Igor Zalutski và nhà xuất bản sản phẩm Utpal Nadiger. Nhóm này đã chuyển từ điều phối cơ sở hạ tầng sang cơ sở hạ tầng Tác nhân AI, về cơ bản là sử dụng lại sự tích lũy của họ về "sự cô lập và kiên trì ở cấp độ sản xuất là gì". Kho GitHub của OpenComputer được xây dựng vào tháng 12 năm 2025 và được phát triển bằng ngôn ngữ Go và được cấp phép theo giấy phép Apache 2.0. Tính đến cuối tháng 7 năm 2026, hơn 1.700 cam kết đã được thực hiện đối với phiên bản v0.6.0.23 và quá trình phát triển khá tích cực. Bối cảnh ra đời của sản phẩm này là do Đại lý AI đang phát triển nhanh chóng từ “các công cụ thực hiện một nhiệm vụ” thành “điều hành liên tục các nhân viên kỹ thuật số”. Các vấn đề như mất trạng thái, cài đặt lại phần phụ thuộc, gián đoạn hết thời gian chờ, v.v. do việc phá hủy và xây dựng lại hộp cát vùng chứa truyền thống mỗi lần gây ra đã trở thành những nút thắt nghiêm trọng trong các tình huống Tác nhân rất phức tạp. Giải pháp mà OpenComputer đưa ra là: không container, không micro VM, chỉ sử dụng máy ảo KVM.

  • Cốt lõi của OpenComputer là một máy ảo “sẽ không chết”. Mỗi VM có một hệ thống tệp Linux hoàn chỉnh, các đặc quyền gốc đầy đủ và trạng thái đĩa liên tục. Vòng suy luận của Tác nhân chạy trực tiếp bên trong VM thay vì thông qua các lệnh gọi API bên ngoài - điều này có nghĩa là việc đọc và ghi tệp sử dụng I/O cục bộ chứ không phải các chuyến đi khứ hồi mạng. Tính bền bỉ là điểm khác biệt cơ bản nhất giữa nó và hộp cát truyền thống. Các hộp cát truyền thống (chẳng hạn như micro VM Firecracker của E2B) hỗ trợ tối đa 24 giờ, sau đó tất cả trạng thái sẽ bị mất. VM của OpenComputer có thể ngủ và thức dậy và trạng thái hoàn toàn giống nhau. Bạn đã cài đặt node_modules, định cấu hình các biến môi trường và viết mã trong phiên trước đó trong một thời gian dài. Tất cả sẽ ở đó vào lần tới khi bạn quay lại. Tính năng Checkpoint là một điểm nổi bật khác. Bạn có thể chụp ảnh nhanh bất kỳ lúc nào và tạo ra một bản sao mới của VM - điều này rất hữu ích trong các tình huống thử nghiệm và gỡ lỗi. Bị hỏng à? Quay lại trong một giây. Tính toán đàn hồi cho phép điều chỉnh nóng CPU và bộ nhớ trong thời gian chạy mà không cần khởi động lại VM. Việc kéo từ 4GB xuống 16GB hoặc quay trở lại được thực hiện trong một phần nghìn giây. Ở cấp độ ảo hóa, OpenComputer hỗ trợ cả động cơ kép Firecracker và QEMU, đồng thời lớp bên dưới quản lý vòng đời VM thông qua opensandbox được triển khai trong Go. Hệ điều hành mặc định là Ubuntu, được cài đặt sẵn Node 22 và môi trường dòng lệnh không đầu thuần túy. SDK cung cấp cả TypeScript và Python. Ngoài ra còn có một số tính năng nhỏ đáng chú ý: URL xem trước cho phép Đại lý xây dựng ứng dụng web xem trực tiếp kết quả; Kiểm soát gói ở cấp độ đối tượng thuê cho phép quản lý và chuyển đổi nóng các phiên bản phần mềm trong các máy ảo đang chạy. So với các sản phẩm cạnh tranh, đây là sự lựa chọn có sự khác biệt lớn nhất về mặt kiến ​​trúc. E2B sử dụng Firecracker micro VM (cách ly tốt nhưng độ bền yếu), Modal sử dụng gVisor (nhẹ nhưng không trạng thái) và Fly.io Sprites sử dụng Firecracker cộng với tính toán nhàn rỗi. OpenComputer chọn sử dụng phương pháp ảo hóa nặng nhất để có được sự bền bỉ triệt để nhất, điều này không chỉ mang lại những lợi thế thiết yếu mà còn phải trả giá bằng tốc độ khởi động chậm và mật độ tài nguyên thấp.

  • OpenComputer áp dụng mô hình trả tiền thuần túy khi sử dụng và chỉ tính phí theo thời gian chạy. Cấu hình cơ bản (bộ nhớ 4GB + 1 vCPU) có giá 0,004 USD/phút, tương đương 0,24 USD/giờ và hoạt động liên tục hàng tháng là khoảng 168,72 USD. Bộ nhớ có thể được điều chỉnh linh hoạt từ 1GB đến 16GB. Mỗi VM chứa 20 GB ổ đĩa và mọi khoản vượt quá sẽ được tính phí ở mức 0,0000001 USD/GB-giây (khoảng 0,26 USD/GB-tháng) - lưu ý rằng giá trị này được tính bất kể VM đang chạy hay ngủ đông. Khách hàng mục tiêu rất rõ ràng: Nền tảng đại lý B2B—các nhóm phát triển xây dựng các sản phẩm như Devin, Bolt và Lovable. Đây không phải là sản phẩm dành cho các nhà phát triển cá nhân chạy một tập lệnh duy nhất. Mô hình kinh tế của nó có hiệu quả nhất về mặt chi phí khi tải Đại lý hoạt động liên tục. Đối với khách hàng quy mô lớn, OpenComputer cung cấp cấu hình tùy chỉnh và chiết khấu theo số lượng, đồng thời yêu cầu cuộc hẹn với nhóm sáng lập để phỏng vấn. Điều đáng chú ý là đây là một sản phẩm hoàn toàn thương mại. Trong khi lớp VM và SDK là nguồn mở trong Apache 2.0 thì Postgres lưu trữ và hệ thống thanh toán là SaaS nguồn đóng. Việc triển khai tự lưu trữ yêu cầu phải tự mình xây dựng cơ sở hạ tầng Postgres + Redis + S3 + KVM hoàn chỉnh và ngưỡng không thấp.

  • OpenComputer có 16 đánh giá về Product Hunt, với đánh giá tổng thể là tích cực. Nhà xuất bản Utpal Nadiger nhấn mạnh trong phần mô tả sản phẩm rằng đây là "cách dễ nhất để triển khai một tác nhân phụ trợ được quản lý hoàn toàn". Tác giả CSDN Yiming đã đưa ra phân tích toàn diện nhất về tiếng Trung trong bài đánh giá chuyên sâu của mình vào ngày 15 tháng 7 năm 2026. Ông tin rằng "cơ chế ngủ/tiếp tục" của OpenComputer là điểm khác biệt cơ bản, không kéo dài thời gian chờ. Việc Tác nhân được tích hợp vào VM để loại bỏ độ trễ I/O mạng là "sự khác biệt cơ bản nhất về kiến ​​trúc". Đồng thời, các vấn đề như tốc độ khởi động chậm, mật độ tài nguyên thấp và hệ sinh thái nhỏ cũng được chỉ ra. Trong bài đánh giá của Dir2AI, OpenComputer được đánh giá là “một sản phẩm thú vị giải quyết được một vấn đề thực sự trong lĩnh vực AI Agent” và mức giá “hợp lý”, nhưng nhấn mạnh rằng nó “không dành cho những nhà phát triển cá nhân chỉ muốn chạy một tập lệnh duy nhất”. Một số người dùng cũng chỉ ra rằng sản phẩm vẫn đang ở giai đoạn đầu - báo cáo kỹ thuật của Clawputer cho điểm toàn diện 7,0/10 từ 5 khía cạnh là dễ sử dụng, đổi mới, độ tin cậy, bảo mật và sinh thái, trong đó độ tin cậy chỉ 6 điểm và bảo mật cũng là 6 điểm.

  • Sự chú ý của giới truyền thông trong ngành đối với OpenComputer tập trung vào hai khía cạnh: sự khác biệt trong lựa chọn công nghệ và khả năng di chuyển từ điều phối cơ sở hạ tầng sang lớp Tác nhân AI. Báo cáo của RuntimeWire tập trung phân tích chức năng tích hợp Slack của OpenComputer, nhận xét rằng "Ưu điểm của OpenComputer là sản phẩm bắt đầu từ lớp cơ sở hạ tầng, thay vì từ giao diện trò chuyện". Điều này có nghĩa là một khi được đưa vào quy trình sản xuất Đại lý, chi phí thay thế sẽ khá cao. Trong một bài viết vào ngày 26 tháng 7 năm 2026, TekMag đã so sánh OpenComputer, Nebius và Anthropic, lập luận rằng cả ba đều đang xây dựng lớp cơ sở hạ tầng được quản lý giống như Vercel cho Đại lý. Bài báo cũng chỉ ra ba rủi ro lớn: khóa nhà cung cấp, sự cố bảo mật hộp cát và chi phí ngoài tầm kiểm soát khi Đại lý không được giám sát. Phân tích của Agent-Wars vào tháng 3 năm 2026 là phân tích sâu sắc nhất. Bài báo thừa nhận rằng OpenComputer "đã xác định chính xác vấn đề" - những sai sót tồn tại dai dẳng của sandbox hiện tại thực sự là một nút thắt quan trọng trong quá trình phát triển Tác nhân AI. Nhưng vẫn có sự hoài nghi về việc liệu công ty có thể giải quyết vấn đề này trên quy mô lớn hay không: "Liệu có thể giải quyết vấn đề này trên quy mô lớn hay không, công ty vẫn chưa cung cấp cho bất kỳ ai công cụ họ cần để giải quyết nó." Bài viết CSDN định vị OpenComputer là "lớp hệ điều hành của Tác nhân AI" - giữa nhà cung cấp đám mây (AWS/Azure) và khung Tác nhân (LangChain/Claude Agent SDK). Tác giả sử dụng sự tương tự của Docker: "Docker nói rằng ứng dụng của bạn cần một môi trường chạy được tiêu chuẩn hóa và OpenComputer nói rằng Tác nhân của bạn cần một môi trường điện toán được tiêu chuẩn hóa." Ở cấp độ kiến ​​trúc kỹ thuật, OpenComputer đã đạt được khả năng mở rộng từ hạn chế một vùng đến quy mô megaton nhiều đám mây. Theo blog công nghệ chính thức, thông qua kiến ​​trúc dựa trên tế bào và cơ quan đăng ký toàn cầu của Cloudflare Workers + D1, hệ thống có thể hoàn thành việc phân bổ hộp cát trong chưa đầy một giây và triển khai thống nhất trên AWS, Azure, GCP và OCI.

  • Những nghi ngờ lớn nhất mà OpenComputer phải đối mặt đến từ ba hướng. Đầu tiên là thiếu GPU. Theo xu hướng các kịch bản Tác nhân ngày càng đòi hỏi sự hiểu biết trực quan, hỗ trợ tạo mã và tương tác đa phương thức, việc thiếu hỗ trợ GPU là một thiếu sót rõ ràng. Modal và Northflank đều thống trị ở khía cạnh này. Thứ hai là BYOC (Bring Your Own Cloud) không được hỗ trợ. Đây là một nhược điểm đối với khách hàng doanh nghiệp có yêu cầu cao về nơi lưu trữ dữ liệu. Việc không thể triển khai trên đám mây của chính khách hàng tương đương với việc chặn một nhóm khách hàng có giá trị cao. Thứ ba là vấn đề đáo hạn sớm. 14 Vấn đề mở, 441 Sao và quy mô nhóm từ 2-10 người trên GitHub đều cho thấy đây vẫn là một sản phẩm còn rất sớm. Những nghi ngờ của Agent-Wars không phải là không có lý - khối lượng công việc của Đặc vụ ở cấp sản xuất quy mô lớn không chỉ yêu cầu bằng chứng về khái niệm mà còn phải có hệ thống hỗ trợ và độ tin cậy đã được chứng minh. Ngoài ra, tốc độ khởi động của KVM chậm hơn rất nhiều so với container và mật độ VM trên cùng một máy vật lý thấp hơn nhiều so với container. Đây đều là những chi phí không thể khắc phục được do các lựa chọn kiến ​​trúc cốt lõi mang lại. Xét về sản phẩm cạnh tranh, đường đua vốn đã rất đông đúc. E2B có hệ sinh thái nhà phát triển mạnh mẽ hơn, Modal có hỗ trợ GPU, Fly.io Sprites có lợi thế triển khai biên, Northflank hỗ trợ BYOC - mọi tuyến đường đều đã được sử dụng.

  • Khách hàng phù hợp nhất cho OpenComputer là các nhóm phát triển B2B đang xây dựng nền tảng Tác nhân - sản phẩm của bạn cần cung cấp cho người dùng môi trường chạy Tác nhân liên tục. Sau khi người dùng cài đặt các phần phụ thuộc, họ hy vọng nó sẽ luôn ở đó. Các tình huống không phù hợp bao gồm: các tác vụ đơn giản chỉ cần chạy tập lệnh một lần (hộp cát truyền thống là đủ), khối lượng công việc của Tác nhân yêu cầu tăng tốc GPU (nên xem Modal hoặc Northflank) và các doanh nghiệp lớn có yêu cầu tuân thủ nơi lưu trữ dữ liệu cực cao (chờ hỗ trợ BYOC). Đối với các lựa chọn thay thế, nếu bạn cần sự kiên trì nhẹ nhàng hơn, hộp cát 24 giờ của E2B có thể có sẵn; nếu bạn cần GPU, Modal là lựa chọn tốt hơn; nếu bạn muốn tự lưu trữ hoàn toàn, bạn có thể cân nhắc việc tự mình xây dựng nó trực tiếp bằng Firecracker hoặc Kata Container. Đối với các nhà phát triển muốn dùng thử, OpenComputer có chi phí học tập thấp. Bạn có thể triển khai Tác nhân bằng ba dòng lệnh: "kỹ năng npx thêm diggerhq/opencomputer" để cài đặt các kỹ năng CLI, sau đó mô tả trực tiếp những gì bạn muốn bằng ngôn ngữ tự nhiên.

  • OpenComputer đi xa hơn bất kỳ ai theo một hướng - nó chọn cách tiếp cận ảo hóa mạnh mẽ nhất để theo đuổi sự bền bỉ triệt để nhất, thay vì mày mò ở các biên giới với các thùng chứa và máy ảo vi mô. Đối với các nhóm xây dựng sản phẩm Đại lý, có thêm một lựa chọn đáng để đánh giá cẩn thận. Thiếu GPU, thiếu BYOC và hệ sinh thái vẫn đang ở giai đoạn đầu. Những thiếu sót này là đủ rõ ràng. Tuy nhiên, do định hướng rõ ràng và kiến ​​trúc đã được kết nối với quy mô megaton nhiều đám mây nên nếu nhóm có thể tiếp tục lặp lại, nó có cơ hội trở thành một thành phần cơ sở hạ tầng quan trọng của lớp cơ sở hạ tầng Đại lý.

Đánh giá của người dùng

  • ảnh đại diện
    AmberChavez_Max
    Việc triển khai thực sự đơn giản và có thể được thực hiện chỉ bằng một lệnh, nhưng trang định giá không đủ minh bạch và chi phí để chạy nó trong một ngày từng phút hơi đáng sợ.

  • ảnh đại diện
    DanielBennett
    Tôi đã thử và triển khai Tác nhân bằng cách dán một từ nhắc nhở trong vòng chưa đầy một phút. VM bền vững thực sự tốt hơn nhiều so với E2B bị phá hủy sau khi sử dụng.

  • ảnh đại diện
    Jordan_Ross168286
    Tôi đã mở VM 4GB và chạy Claude Agent. Sau khi ngủ một đêm và thức dậy, node_modules vẫn ở đó và không cần phải cài đặt lại.

  • ảnh đại diện
    David386
    Tôi đã tạo ra một Clawputer và chơi đùa với nó. Tôi đã triển khai ba lệnh để triển khai Đại lý Telegram vĩnh viễn. Nó có thể chạy trong 20 giây và có chức năng bộ nhớ. Trải nghiệm này thực sự tốt.

  • ảnh đại diện
    JThompson369
    Nó xếp thứ tư ngay sau khi được phát hành, điều này cho thấy thực sự có nhu cầu về ca khúc này. Cá nhân tôi cảm thấy chức năng ngủ đông liên tục là điểm bán hàng lớn nhất và tiết kiệm tiền.

  • ảnh đại diện
    ChainWave_btc
    Tôi khá bất ngờ khi nhìn thấy nó trên Product Hunt, nhưng nếu nghĩ kỹ thì phải chăng máy ảo KVM có Agent SDK? Tốc độ khởi động chậm hơn nhiều so với container.

  • ảnh đại diện
    STurner520
    Nhược điểm của việc không có GPU là quá lớn. Đặc vụ của ai ngày nay không có khả năng hiểu thị giác? Làm thế nào để xem qua Modal trước? Rốt cuộc họ có GPU.

  • ảnh đại diện
    Alan_Peterson_Pro
    Tôi hơi lo lắng về sự an toàn. Tất cả dữ liệu Tác nhân chạy trên máy ảo của Digger. Nếu chúng bị xâm phạm, bộ nhớ Tác nhân của tôi có bị lộ trực tiếp không?

  • ảnh đại diện
    BarbaraLewis_77230
    Chức năng điểm kiểm tra này thực sự rất tuyệt. Tôi đã xây dựng một bản demo đáng yêu. Mỗi lần tôi thay đổi kiến ​​trúc, tôi đều chụp ảnh nhanh. Nó bị hỏng và quay lại sau một giây, nhanh hơn git stash.

  • ảnh đại diện
    ArbitrumAceSchroeder
    Trưởng thành hơn tôi nghĩ. Dù chỉ có hơn 400 Sao nhưng bản thân nhóm Digger cũng có nền tảng IaC và hiểu biết về cơ sở hạ tầng. Chọn KVM thay vì container về mặt kiến ​​trúc là một nửa điều đúng đắn.

  • ảnh đại diện
    Alan_WoodSr8
    Nếu bạn đang xây dựng nền tảng B2B Agent thì có thể tham khảo giải pháp này. Nó giúp bạn tránh được rất nhiều rắc rối so với việc tự mình thiết lập một cụm KVM, mặc dù chi phí dài hạn có thể đắt hơn so với việc xây dựng một cụm trên AWS.

  • ảnh đại diện
    VaultV_iper350
    Bài đánh giá chuyên sâu về CSDN của Yi Ming rất trung thực. Tính bền bỉ thực sự là điểm khác biệt cơ bản, nhưng việc thiếu GPU và thiếu hỗ trợ BYOC cũng là những sai sót thực sự.

  • ảnh đại diện
    JEcla
    Vấn đề khóa chặt này cần được xem xét cẩn thận. Một khi bạn bắt đầu sử dụng Agent Session API của họ, sau này khi cố gắng di chuyển bạn mới nhận ra rằng tất cả trạng thái đều bị ràng buộc vào nó.

  • ảnh đại diện
    redlion382
    Đội chỉ có 2-10 người. Nếu một ngày nó sập, Agent của chúng tôi sẽ chạy ở đâu? Tôi không thể gắn cơ sở hạ tầng kinh doanh cốt lõi vào một đội nhỏ ở vòng hạt giống.

  • ảnh đại diện
    crazydog338
    Tôi thử tự lưu trữ, thiết lập Postgres+Redis+S3+KVM. Suýt khóc. Managed Cloud thì yên tâm hơn, dù đắt.

  • ảnh đại diện
    Janet.AlvarezSr85
    Đêm qua tôi đã chạy một tác vụ Agent suốt đêm. Không bị gián đoạn hay timeout. Sáng nay tôi kiểm tra log và mọi thứ đều bình thường. Nếu dùng E2B thì đã bị giết giữa chừng rồi.

  • ảnh đại diện
    Stephen_Russell520
    Tính năng Preview URL rất hữu ích. Sau khi triển khai, bạn nhận được ngay một liên kết có thể truy cập từ bên ngoài và có thể tích hợp trực tiếp vào quy trình CI/CD.

  • ảnh đại diện
    MadisonButler
    Thành thật mà nói, hơi đắt. Chạy một VM 4GB tốn $168 một tháng, trong khi cấu hình tương tự trên AWS Lightsail chỉ khoảng $10-$20. Nhưng nếu Agent cần tính bền vững và ngủ đông, thì công cụ này thực sự tiết kiệm tiền.

  • ảnh đại diện
    JenniferNielsen
    CI/CD và cơ sở hạ tầng Agent không giống nhau. Digger mạnh về điều phối IaC, nhưng điều đó không có nghĩa là họ có thể xây dựng Agent VM tốt. Hãy chờ xem.

  • ảnh đại diện
    MrEdanurOttenhoff
    Nhóm đã chọn sử dụng động cơ kép Firecracker, kết hợp sự ổn định của QEMU với tính nhẹ của Firecracker. Cách tiếp cận thiết kế kiến trúc này thực sự xứng đáng với nền tảng IaC của họ.

  • ảnh đại diện
    CDavisK444
    Tôi đã chạy một Telegram Bot trên nó, và sau hai tuần sử dụng, trải nghiệm vượt quá mong đợi. Chế độ ngủ đông của Agent đã tiết kiệm rất nhiều tiền, và tốc độ đánh thức khá nhanh.

  • ảnh đại diện
    GeorgeGutierrez
    Không hỗ trợ BYOC thực sự là một thiếu sót chết người. Đối với các công ty fintech như chúng tôi, dữ liệu phải nằm trên đám mây của riêng mình. Không thể dùng được.

  • ảnh đại diện
    Melissa.JonesX67
    Với OpenComputer, cuối cùng tôi không còn phải lo lắng mỗi tối về việc tác vụ Agent bị timeout giữa chừng. Thật tuyệt khi có thể tan làm với tâm trạng thoải mái.

  • ảnh đại diện
    ovhk1
    So với E2B, mỗi bên đều có ưu điểm riêng. E2B có hệ sinh thái lớn hơn, cộng đồng sôi động; OpenComputer có tính bền vững mạnh hơn, nhưng chuỗi công cụ chưa hoàn thiện.

  • ảnh đại diện
    NicoleMendozaII
    Mô hình tính phí theo phút rất phù hợp cho giai đoạn phát triển và gỡ lỗi. Ban ngày tôi viết Agent, sửa code, chạy kiểm thử, ban đêm thì ngủ đông. Chi phí rẻ hơn nhiều so với gói tháng.