Các mô hình AI cần một máy ảo

• Phần mềm AI cần những đặc tính mang tính hệ điều hành vượt xa việc chỉ gọi mô hình, như bảo mật, cô lập, khả năng mở rộng và tính di động; vì vậy khái niệm máy ảo chuyên dụng cho mô hình AI (MVM) được đề xuất
• Giống như Java Virtual Machine (JVM) đã mang lại an toàn bộ nhớ và khả năng “viết một lần, chạy mọi nơi”, AI VM cũng đảm bảo khả năng thay thế và tương tác liên thông bằng cách tách mô hình khỏi logic tích hợp
• VM định nghĩa một tập lệnh chuẩn cho các thao tác như gọi mô hình, gọi công cụ, lưu kết quả, nhận đầu vào người dùng, phân nhánh điều kiện, qua đó có thể ràng buộc và theo dõi hành vi mô hình một cách an toàn
• Nghiên cứu hiện có như structured tool calling của OpenAI, MCP của Anthropic, FIDES/AC4A của Microsoft, cùng các runtime mã nguồn mở, đã cho thấy định hướng chuẩn hóa
• Một AI VM được định nghĩa tốt có thể giúp tăng cường bảo mật và quyền riêng tư, giám sát hiệu năng, xác minh đầu ra, xây dựng hệ sinh thái đa nền tảng, và trở thành hạ tầng cốt lõi giúp các hệ thống AI đáng tin cậy và an toàn hơn

---

Giới thiệu

• Mô hình AI đang được dùng trong phần mềm cho nhiều mục đích như copilot ứng dụng, tích hợp IDE, và sử dụng công cụ thông qua giao thức MCP
  • Những tiến bộ này làm gia tăng nhu cầu đảm bảo quyền riêng tư, bảo mật và vận hành chính xác
• Bảo mật và quyền riêng tư cần được bảo đảm ngay từ giai đoạn thiết kế hệ thống, bổ sung sau là không đủ
• Lấy cảm hứng từ Java Virtual Machine (JVM), bài viết đề xuất tầm quan trọng của một máy ảo tiêu chuẩn hóa dành cho mô hình AI
  • JVM cung cấp môi trường thực thi đáng tin cậy thông qua an toàn bộ nhớ, kiểm soát truy cập và xác minh bytecode
  • Nhờ đó, có thể đạt được “viết một lần, chạy mọi nơi”

Vai trò của máy ảo mô hình AI (MVM)

• MVM hoạt động như phần mềm trung gian giữa mô hình AI và môi trường bên ngoài
  • Ví dụ: khi người dùng nhập prompt “đặt vé máy bay”, MVM sẽ chuyển nó cho mô hình (bao gồm cả việc thêm ngữ cảnh)
  • Nếu mô hình phản hồi “sử dụng công cụ đặt chỗ”, MVM sẽ kiểm tra danh sách công cụ được phép rồi quyết định có gọi công cụ hay không
  • Điều này bảo đảm mô hình không thực hiện các lời gọi chưa được phê duyệt
• Mọi hệ thống AI thương mại đều cần loại phần mềm điều khiển tương tự như vậy
• MVM định nghĩa tập lệnh, ví dụ gồm:
  • Xác thực, nạp, khởi tạo và gỡ nạp mô hình
  • Gọi mô hình kèm ngữ cảnh
  • Phân tích đầu ra của mô hình
  • Xác thực, nạp, gọi công cụ, phân tích kết quả và lưu vào bộ nhớ
  • Yêu cầu đầu vào người dùng, thêm bộ nhớ lịch sử, câu lệnh điều kiện và các cấu trúc điều khiển khác

Nghiên cứu hiện có và sự cần thiết

• Giao thức structured tool calling của OpenAI: cung cấp tích hợp công cụ rõ ràng thông qua API function calling dựa trên JSON và đặc tả OpenAPI
• MCP (2024) của Anthropic: một giao thức mở kết nối trợ lý AI với dữ liệu bên ngoài
  • Được ví như “cổng USB-C cho các ứng dụng AI”, cung cấp giao diện phổ quát
  • Đã có các ví dụ được chấp nhận nhanh chóng, bao gồm cả ở doanh nghiệp lớn
• Security orchestrator – FIDES & AC4A (2025):
  • FIDES (Microsoft Research): thực thi chính sách luồng thông tin, theo dõi nhãn bảo mật dữ liệu và thêm hành động “inspect”
  • AC4A: quản lý công cụ và dữ liệu theo cấu trúc phân cấp kiểu hệ điều hành, đồng thời ép buộc chế độ vận hành đặc quyền tối thiểu
  • Những dự án này cho thấy MVM có thể tích hợp sẵn bảo mật và kiểm soát truy cập
• Agent runtime mã nguồn mở: langchain, Semantic Kernel, llguidance cung cấp dịch vụ runtime để hỗ trợ phát triển ứng dụng AI ổn định
• Đặc tả MVM đòi hỏi dữ liệu huấn luyện mô hình phải phản ánh đặc tả giao diện, và cần có đồng tiến hóa giữa mô hình với MVM

Lợi ích của MVM

• Tách biệt mối quan tâm: tách logic mô hình và logic tích hợp để biến mô hình thành thành phần có thể thay thế
  • Vẫn giữ được khả năng tương tác liên thông khi thay bằng mô hình mới hoặc chuyển sang nền tảng khác
• An toàn và quản trị tích hợp sẵn: MVM bảo đảm an toàn thông qua kiểm tra quyền, nhật ký kiểm toán và các cơ chế bảo vệ
  • Giống AC4A, MVM đóng vai trò người gác cổng để kiềm chế hành vi ngoài dự kiến
• Theo dõi hiệu năng minh bạch: chẩn đoán runtime cung cấp thông tin về hiệu năng mô hình, mức tiêu thụ tài nguyên và mức độ truy cập dữ liệu
  • Có thể so sánh độ chính xác, tính hữu ích và độ phản hồi bằng benchmark
• Xác minh đầu ra mô hình: dùng các kỹ thuật như zero-knowledge proof để kiểm tra tính toàn vẹn của đầu ra, tăng cường độ tin cậy và trách nhiệm giải trình

Kết luận

• Máy ảo mô hình AI là cần thiết để giảm độ phức tạp của hệ thống AI và nâng cao khả năng tương tác liên thông
• Nó tăng cường bảo mật, quyền riêng tư, tính di động và độ tin cậy, đồng thời thúc đẩy tốc độ phát triển và khả năng mở rộng của hệ sinh thái
• Dựa trên nghiên cứu từ các công ty công nghệ, startup và giới học thuật, đặc tả MVM có thể cung cấp một tiêu chuẩn để các mô hình AI tương tác an toàn và trơn tru
• Mục tiêu là xây dựng đồng thuận cùng cộng đồng về sự cần thiết của đặc tả MVM và những thành phần nên được bao gồm

[GN⁺]

Ý kiến Hacker News

• Tôi thấy bài này thiếu giải thích cụ thể nên không rõ chính xác họ đang đề xuất điều gì. VM (Virtual Machine) dù sao cũng gắn với tập lệnh, luồng điều khiển, thanh ghi các kiểu, nhưng bài này lại chỉ tập trung vào authorization. Rốt cuộc có vẻ họ đang nói về một thứ gì đó giống sandbox, jail, container để cho phép mô hình tương tác với thế giới bên ngoài

  • Tôi cũng băn khoăn liệu họ có thực sự đang nói về một VM execution engine, hay Docker cho LLM hay không. Tổng thể thì giống một ý tưởng được đóng gói lại cho có vẻ hay. Tôi nghĩ nếu thiết kế hệ thống đóng gói kém thì sẽ thành thảm họa. Chỉ cần nhìn vào các trải nghiệm packaging khác nhau của Python là đủ thấy

  • Nhìn thấy từ VM là tôi lập tức cảm thấy nó khá gần với sandbox. Bài viết cũng nói về “cô lập”, nên tôi không thấy nó mơ hồ hay thiếu thông tin. Chỉ là lập luận của tác giả quá hiển nhiên, còn giải pháp thì chưa hoàn chỉnh. Dù có nhốt vào sandbox ở mức OS hay phần cứng đi nữa, nếu agent tìm thấy thứ như AWS CLI bị cấu hình IAM sai thì vẫn rất rắc rối. Ranh giới từ xa cũng phức tạp. Tôi không thấy có insight mới nào. Tôi nghĩ vấn đề không nằm ở cách chọn thuật ngữ

  • Nếu theo đúng định nghĩa trong bài, thì có thể nói các AI agent hiện tại cũng đã chạy trong VM rồi. Ví dụ trên MCP host có thể yêu cầu sự đồng ý của người dùng khi thực thi, hoặc đặt quy tắc tự động phê duyệt những mẫu lệnh nhất định như Claude code

• Tôi nghĩ vấn đề cốt lõi không phải là sẽ đưa cho LLM công cụ nào, mà là cho phép nó thực hiện những hành động nào. Ví dụ trong kịch bản đặt vé máy bay, tôi muốn LLM có thể so giá trên nhiều website và thanh toán luôn. Nhưng tôi không muốn nó chọn những vé vô nghĩa kiểu rẻ hơn 3 đô nhưng mất 37 giờ bay. Khi tra cứu thông tin phúc lợi cũng vậy, nó chỉ nên xem thông tin của chính tôi, không được xem của đồng nghiệp. Cùng một công cụ nhưng phạm vi quyền hạn lại khác nhau. Nhân sự thì đương nhiên có thể xem thông tin nhân viên mà họ quản lý, nhưng khi đó lại phát sinh các vấn đề như nhật ký kiểm toán. Nói cách khác, còn quan trọng hơn cả hành động là ý định (intent). Sẽ hợp lý hơn nếu xem LLM như đại diện của người dùng và đặt nó vào cùng một hộp quyền hạn tương ứng

  • Cuối cùng thì đây chính là capability security model. Phải truyền rõ ràng cho software agent những capability mà nó có thể truy cập, và về mặt vật lý phải khiến nó không thể làm các hành động ngoài danh sách đó. Nhưng trên thực tế không có OS mainstream nào triển khai mô hình này. Đã có khá nhiều nghiên cứu và thử nghiệm (ví dụ OS: EROS, Fuchsia, Sandstorm) nhưng không mấy thành công trên thị trường. Vì vậy cách gần nhất trong thực tế là dùng VM và chỉ đặt những công cụ cần thiết vào trong VM. Cách này không hoàn hảo, vì bản thân công cụ quá tổng quát so với capability thực sự. Phần mềm được xây theo nguyên tắc đặc quyền tối thiểu thường hay thất bại trên thị trường

  • Điều quan trọng không phải công cụ có thể thực hiện hành động nào, mà là tổ hợp giữa dữ liệu và hành động mà công cụ đó có thể truy cập. Vì không thể dự đoán hoàn toàn hành vi của LLM nên không nên tin nó. Ví dụ chỉ cho LLM truy cập website đặt vé máy bay, nhưng không đưa cho nó SSN hay thông tin tài khoản ngân hàng. Đây là vấn đề về provenance của dữ liệu và quyền hạn. Tác vụ càng nhạy cảm thì càng cần nhiều ràng buộc, còn ít nhạy cảm hơn thì có thể cho phép nhiều hành động hơn. Dữ liệu phải mang thông tin quyền hạn, và mediator phải giới hạn dữ liệu/hành động mà tác vụ mới được spawn có thể có. Ví dụ: nếu tác vụ lập kế hoạch du lịch spawn một tác vụ con để tìm vé máy bay, mediator chỉ nên truyền sang tác vụ con dữ liệu không nhạy cảm như một phần lịch trình, và chặn truy cập dữ liệu nhạy cảm

  • Có thể xem LLM agent như một user khác nhưng cùng cấp với người dùng. Nó có quyền khác nhau theo từng context. Ví dụ một thư mục mã nguồn thì có quyền đọc/ghi, còn thư mục khác chỉ được đọc. Quyền của LLM agent khác nhau theo từng dự án, và đó là giao hoặc tập con trong quyền của người dùng. Về cơ bản có ba loại quyền: Allow, Deny và Ask (yêu cầu cho phép), và khi cần thì hỏi người dùng có cho phép hay không. Vấn đề là quyền của OS hiện tại cũng như quyền của app/dữ liệu chưa đủ chi tiết. Ngay cả với git cũng nên được thiết kế để chỉ cho phép một số lệnh cụ thể thay vì toàn quyền truy cập. Hiện tại các ứng dụng đều tự bắt chước điều này trong user space và triển khai một cách vụng về. Workflow khá giống sudo. Nếu tôi khởi chạy app bằng user LLM Agent của mình thì quyền sẽ được cấp/giới hạn tùy theo context đó. Nó chỉ có thể hành động trong phạm vi tôi cho phép khi tôi yêu cầu. Nhưng hiện giờ mỗi app agentic đều phải tự triển khai quy trình này, nên cần biến nó thành dịch vụ OS có hệ thống. Tạm thời có thể lách bằng cách tạo/xóa tài khoản người dùng tạm cho từng agent context rồi chỉ giao tiếp qua IPC hoặc mạng

  • Tôi nghi ngờ mô hình này có thực sự hoạt động tốt không. Dù LLM có thể làm gì đó, các website có thể phát hiện ra và điều chỉnh giá hoặc làm hỏng cây quyết định. Nếu vậy thì tốt hơn là tất cả website chuyển hẳn sang API cho LLM, hoặc dùng rss + json. Chỉ cần đưa dữ liệu đơn giản và các lựa chọn như BBS hay hệ thống menu SMS thì lại là tối ưu cho LLM. Quảng cáo cũng vậy. Không cần cho LLM xem quảng cáo làm gì, mà ngược lại quảng cáo nhằm đánh lừa LLM còn hiệu quả hơn. Ví dụ khi tìm chuyến bay, quảng cáo có thể dụ LLM tin rằng sản phẩm của tôi là tốt nhất. AI hiện giờ vẫn còn đơn giản nên sẽ khá thú vị nếu xuất hiện quảng cáo chuyên cho AI

  • Nếu có thể định nghĩa và cưỡng chế được “phản hồi tốt” thì có khi chẳng cần tới bản thân LLM nữa. Với nhân sự thì còn có thể hỏi trực tiếp về ý định, nhưng LLM thì khó vì nó không có ý định theo nghĩa đó

• Trước đây tôi từng thấy bài HN nói John Carmack đã chỉ tốn thời gian và tiền bạc khi làm XROS ở Meta. Còn bài tôi đọc hôm nay thì ngược lại, nhấn mạnh mạnh mẽ sự cần thiết của “một OS mới”. VM không phải OS hoàn chỉnh, nhưng khác ở chỗ có thể tận dụng OS/codebase hiện có để làm nhẹ hơn

  • Hai bài đó là hai câu chuyện hoàn toàn khác nhau. Thực ra tôi cũng không thấy bài này đang mạnh mẽ lập luận cho VM hay cho sự cần thiết của một OS mới. Cuối cùng toàn bộ chỉ là câu chuyện access control

  • Với XR thì trọng tâm là performance và dev experience, còn phía LLM thì bản thân việc sandbox và đơn giản hóa truy cập tool/dữ liệu mới là cốt lõi. Có rất nhiều việc phải làm để LLM không phá hỏng môi trường thực thi hoặc làm hỏng dữ liệu, và nếu có chuẩn thì gánh nặng retraining sẽ giảm, người khác cũng dễ tận dụng mô hình hơn. Với XR thì nếu chỉ là SDK có thể giải quyết bằng huấn luyện, còn AI thì chi phí R&D và compute lớn hơn nhiều

  • WebAssembly vốn đã cung cấp sandbox, nên có thể xem như đã đi được một nửa. Phần còn lại là giao diện rõ ràng để chuyển dữ liệu/quyền hạn giữa các instance và cách để các instance tạo ra lẫn nhau

  • Tôi không nghĩ bài này là cơ sở để viết một OS mới. Việc xây môi trường thực thi cho AI và việc thiết kế từ con số 0 một OS tối ưu cho AI là hai chuyện hoàn toàn khác nhau

• Sau khi đọc kỹ bài viết và xem các liên kết tham khảo, tôi có cảm giác bài này đang chỉ ra một vấn đề còn nền tảng hơn cả chuyện đơn thuần là “VM cho AI”. Chỉ dùng VM là không đủ để đảm bảo an toàn cho workflow của LLM. Workflow cấp cao nhất phải truy cập các công việc và dữ liệu nhạy cảm như mạng, PII, credentials, trong khi LLM lại dễ bị prompt injection và vấn đề tính nhất quán. Chỉ nhốt LLM vào VM thì không giải quyết được. Cần “quản lý luồng thông tin” bằng cách phân vùng workflow, dữ liệu và phép tính theo từng đơn vị công việc, để chỉ những subtask tối thiểu mới được truy cập thông tin bị giới hạn. Chỉ tập con xử lý tác vụ nhạy cảm mới cần được tin cậy và kiểm chứng riêng. “Secure Orchestrators” mà bài viết nhắc tới, cùng bài báo FIDES, mới là điểm cốt lõi. “VM” rốt cuộc chỉ là chạy task trong một container được cấp quyền/dữ liệu hạn chế. Orchestrator phải tạo những container này, cấp quyền phù hợp và gắn nhãn độ nhạy cảm (taint-tracking) cho dữ liệu đầu ra. Nhìn tổng thể, tôi nghĩ nhấn mạnh “partitioning” hay “isolation”, cũng như các vấn đề dữ liệu, sẽ phù hợp hơn là cách gọi “VM for AI”

  • Nghe khá giống Microsoft Wassette

  • Mục tiêu nên là loại bỏ chính khái niệm workflow. Trong mô hình LLM+VM, việc cung cấp công cụ cho LLM bản thân nó đã là một workflow. Cách này hiện giờ đôi khi hoạt động tốt, nhưng có giới hạn với những ngoại lệ chưa được định nghĩa trước hoặc các tác vụ cần công cụ mới. Hơn nữa, cách tiếp cận dựa trên workflow gần như luôn bị giới hạn trong dạng tuyến tính (hoặc DAG, có thêm loop). Bước tiếp theo là không cung cấp công cụ sẵn nữa, mà để LLM tự tạo ra công cụ tại chỗ khi cần. Có những bài toán đòi hỏi cách tiếp cận kiểu brute-force

• Khi đọc bài này tôi lại có cảm giác nhiều bài viết gần đây như thể do AI viết ra. Từ góc nhìn hosting thì chỉ riêng việc chạy AI agent ổn định trong bất kỳ môi trường nào cũng đã là thách thức lớn. Với tư cách developer, tôi đang dùng rootless docker devcontainer của wsl; dù một số malware có thể xuyên qua, tôi vẫn cảm thấy cách này an toàn hơn hướng tiếp cận VM. Ngoài ra còn có ưu điểm về tính tái lập, tách biệt môi trường, v.v., và nếu AI làm hỏng môi trường của tôi thì tôi chỉ cần dựng lại container nên đỡ áp lực hơn

• Nếu nhìn vào cách triển khai mô hình thương mại tiên tiến nhất, thì gần như mọi đặc tính bài viết nhắc tới như cô lập đã được triển khai rồi. Không đến mức là bản thân OS, nhưng chức năng thì tương tự. Tuy nhiên chừng đó vẫn chưa đủ. Để agent thực sự làm việc được, nó phải có quyền truy cập vào những tài nguyên quan trọng, và cấp đúng vừa đủ các quyền đó còn khó hơn nhiều so với việc cô lập chính LLM. Mô hình chính xác cho bảo mật LLM là untrusted userspace. Không cần thiết kế lại cả OS

  • Tôi cũng thấy khái niệm untrusted userspace là chính xác. Có thể các cách này sẽ giúp đôi chút về mặt bảo mật, nhưng tôi không đồng ý với phần tác giả thổi phồng kiểu như chúng “đảm bảo” được điều gì đó. Họ ví truy cập công cụ với quyền truy cập tệp, nhưng thực tế track record của quyền tệp trong OS cũng chẳng mấy tốt đẹp. Nếu phải kiểm tra xem có được phép dùng công cụ đặt chỗ hay không, thì suy cho cùng đó vẫn là một trình duyệt web. Trình duyệt vừa là công cụ đa dụng, vừa có thể bị tấn công kiểu jailbreak. Điều quan trọng là ngay cả dưới các ràng buộc kiểu máy ảo này, vẫn cần biện pháp bảo mật mới để ngăn mô hình AI hành xử phản nghịch. Rốt cuộc bài học giản dị là cuối cùng vẫn phải giải được vấn đề alignment

• Tôi đồng ý với ý kiến rằng việc cô lập LLM phải được làm triệt để ở cấp thiết kế VM. Lý do cũng giống hệt vì sao OS truyền thống áp dụng nghiêm ngặt kiểu này. Gần đây tôi có tổng hợp một số ý tưởng trong blog này. Tôi tiếp cận bằng cách so sánh cách LLM hoạt động với process/task trong OS truyền thống, và các abstraction chính không khó triển khai — có thể hợp nhất chat/tool interface của 8 backend LLM để quản lý tập trung việc phê duyệt tool. Tôi chưa triển khai capability model, nhưng theo kinh nghiệm với OS trước đây (VSTa) thì đây là hướng rất tự nhiên. Một LLM phải có thể ủy quyền một tập con quyền mà nó có cho LLM khác, và tôi cũng đã làm xong công cụ delegation

• Tôi nghĩ việc tạo ra một abstract machine mới như VM chỉ làm mọi thứ phức tạp thêm. Chúng ta vốn đã có tài khoản, quyền đọc/ghi/thực thi tệp, và quyền truy cập tạm thời hoặc từ xa thì access token là đủ. Tôi tin mọi capability model đều có thể được triển khai đủ tốt bằng các khái niệm này. Tôi thấy tốt hơn là đơn giản hóa các công cụ sẵn có. Dù hiện nay mọi người đều thử nghiệm cái mới và kỳ vọng vào thay đổi căn bản trong toàn bộ phần mềm, tôi nghĩ nên xem đây là giai đoạn cắt giảm sự phức tạp vô ích và làm mọi thứ đơn giản hơn. Ví dụ, chỉ mất 10 phút là có thể biến một MCP server thành công cụ CLI đơn giản với Claude. Tôi cảm thấy như vậy là đã đủ hữu ích

  • Mô hình bảo mật của desktop OS hiện đại quá thiếu thốn so với thời đại này. Việc trao toàn bộ quyền mà gần như không có cảnh báo hay xác nhận nào cho người dùng là gần như điên rồ. Nếu người dùng thực sự muốn môi trường không bị ràng buộc thì nên cho họ quyền lựa chọn, nhưng mặc định phải là đặc quyền tối thiểu. Nên chỉ cấp quyền theo miền cho từng chương trình. Ví dụ công cụ trực quan hóa dung lượng đĩa có thể cần quyền truy cập toàn bộ filesystem, nhưng lại không cần truy cập mạng cục bộ hay Internet

  • Điểm mạnh lớn nhất của VM là giới hạn phạm vi thiệt hại. Một agent giỏi có thể lợi dụng zero-day để rất dễ dàng phá hệ thống. Chỉ với quyền người dùng thôi cũng đã đủ nguy hiểm, trong khi việc giới hạn tri thức của agent bằng tường lửa là cực kỳ khó và có vô số cách lách từ Internet. Những hệ thống này sẽ trở nên rất giỏi trong việc bẻ khóa hệ thống, nên cần các cơ chế bảo mật cực kỳ chắc chắn

  • Trong môi trường LLM, khái niệm “temporary read” không thực sự tồn tại. Một khi dữ liệu đã vào context, phải coi như nó có thể bị rò rỉ sang mọi nơi được kết nối cho tới khi agent chết và context bị xóa. Dù có VM hay không cũng vậy, và chỉ VM thôi không thể là giải pháp bảo mật

  • Tôi đồng ý phần lớn. Nhiều rủi ro bảo mật sẽ xảy ra bất kể có VM hay không. Sắp tới defense in depth sẽ càng quan trọng hơn, nhưng hiện giờ đã có quá nhiều cách dễ dàng để kẻ tấn công dùng AI agent làm hại người dùng

  • Chỉ cần cho phép công cụ chỉnh sửa tệp là coi như mất gần hết bảo mật rồi

• Tôi nghĩ Fuchsia có thể là một OS thực tế để kiểm soát hành vi của mô hình AI. Vì nó là object capability OS, mỗi component (process) chỉ có thể truy cập các capability được cấp rõ ràng

  • Tôi đồng ý với thiết kế của Fuchsia và cũng thích nó, nhưng không nghĩ nó sẽ thực sự thành công. Thay vì tạo ra OS mới, có lẽ hướng khả thi hơn là mô hình giống Fuchsia dựa trên WASM/WASI component, có thể được host từ cloud tới mobile ở khắp nơi

• Khi ChatGPT thực thi mã (ví dụ yêu cầu xử lý CSV), có vẻ nó chạy trong một VM chỉ được truy cập một số công cụ và thư viện nhất định, với ổ đĩa sandbox và không có Internet. Rốt cuộc chúng ta đã đang đi theo cấu trúc khá giống như vậy rồi

  • Devin, OpenHands cũng tương tự. Trong dự án pilot AI tôi làm vài tháng trước, “chạy agent trong VM (mặc định)” cũng là yếu tố cốt lõi

  • Đó là Kubernetes trên nền AKS (Azure Kubernetes), có gvisor và Jupyter chạy bên trên

  • Không hẳn vậy. Ví dụ nếu giả sử chạy hai AI (như ChatGPT chẳng hạn) trên cùng một máy, thì hoàn toàn chưa có tiêu chuẩn hay khả năng tương tác nào cho chuyện cộng tác hay phối hợp giữa chúng cả.