Runtime cho AI agent: Cloudflare Computer kết hợp isolate và container

TRẢ LỜI NHANH: Điều kiện kỹ thuật cho @cloudflare/computer

• Dùng gói npm runtime mã nguồn mở (bản preview) trong các workflow agent xây trên framework kiểu AI SDK.
• Cung cấp read, write, edit, ls và exec qua bề mặt công cụ tiêu chuẩn của runtime.
• Cung cấp dynamic Workers cho thực thi isolate được hỗ trợ và Cloudflare Containers cho công việc cần Linux, binary native, npm hoặc công cụ chuyên biệt.
• Dùng hệ thống tệp ảo chung dựa trên SQLite; đường container truy cập cùng workspace qua FUSE.
• Cung cấp đối số backend cho exec, đồng thời xác định chính sách, quyền, telemetry và điều kiện review cho việc chuyển sang container.

Runtime AI agent kết hợp isolate và container của Cloudflare mang đến cho các đội kỹ thuật và platform đang xây hệ thống đa agent một lựa chọn khác ngoài việc cấp riêng một container Linux cho agent của từng người dùng. Container riêng khởi động chậm và khó mở rộng một cách gọn gàng, cả về chi phí lẫn tài nguyên phần cứng. Đầu ra thực tế ở đây là một mô hình chi phí và một checklist kiến trúc để quyết định khi nào công việc của agent chạy trên isolate, khi nào cần Linux.

Tại Van Data Team, chúng tôi bắt đầu bằng cách lập bản đồ workflow, công cụ, dữ liệu, quyền, retry, cổng review và khôi phục sau lỗi. Cách làm đó biến thiết kế của Cloudflare Computer thành các quyết định vận hành cụ thể, thay vì chỉ là khẩu hiệu sản phẩm. Các đội xây workflow AI agent production có thể dùng worksheet bên dưới để kiểm tra chi phí sandbox, độ trễ, mức dùng token và hành vi chọn backend trước khi thay đổi kiến trúc.

Điểm chính cần nhớ

Cloudflare Computer cho phép lựa chọn môi trường điện toán qua một giao diện runtime chung, thay vì gán cố định một container cho mọi agent.

• @cloudflare/computer là preview mã nguồn mở mời nhà phát triển phản hồi, chưa phải bản phát hành rộng rãi.
• V8 isolate xử lý công việc phổ biến, còn Linux container có sẵn theo nhu cầu cho binary native, npm và công cụ chuyên biệt.
• Hệ thống tệp ảo dùng chung dựa trên SQLite giữ tệp đồng bộ trên cả hai đường thực thi.
• Đội ngũ nên ghi lại lựa chọn backend, lý do chọn, chi phí, độ trễ, mức dùng token, retry, thay đổi tệp và kết quả đánh giá.
• Quy tắc quyết định cốt lõi rất đơn giản: dùng môi trường ít tốn kém nhất vẫn hoàn thành tác vụ an toàn.

Cloudflare đã giới thiệu gì với Cloudflare Computer

@cloudflare/computer là một gói npm runtime mã nguồn mở cho phép agent chọn giữa isolate gọn nhẹ và container Linux đầy đủ, trong khi vẫn giữ một workspace dùng chung.

Ngày 3/8/2026, Matt Carey và Aron Carroll giới thiệu gói này là preview sớm. Cloudflare mở đầu Agents Week 2026 vào ngày 12/4/2026 với chủ đề xoay quanh hạ tầng cần thiết để vận hành agent ở quy mô production.

Thông tin được công bố. Gói cung cấp read, write, edit, ls và exec qua bề mặt công cụ tiêu chuẩn. Giao diện đó hoạt động với các framework theo kiểu AI SDK. Agent yêu cầu một thao tác công cụ và truyền đối số backend cho exec, còn phần mô tả công cụ sẽ định hướng cách chọn backend.

Đây là runtime agent, không phải mô hình một container cho mỗi agent. Khác biệt này quan trọng vì lựa chọn hạ tầng được đưa ra qua một bề mặt công cụ dùng chung. Agent không cần biết cách quản lý vòng đời container mới có thể thao tác tệp hoặc gọi các lệnh được hỗ trợ.

Bảng này phản ánh kiến trúc của bản preview, không phải cam kết về độ ổn định hay hiệu năng. Cloudflare chưa công bố giá của gói, số liệu sử dụng trong production hay mức tiết kiệm theo workload; repository của họ có benchmark hệ thống tệp, nhưng không có benchmark end-to-end cho runtime agent.

Vì sao mô hình mỗi agent một container làm méo chi phí runtime

Kiến trúc một container cho mỗi agent khiến môi trường thực thi đắt nhất tăng theo số người dùng, số agent, mức độ đồng thời và số lần retry, ngay cả khi phần lớn công việc không cần Linux.

Cloudflare nói thẳng về giới hạn tài nguyên vật lý trong công bố chính thức:

"Trên thế giới không có đủ năng lực điện toán để mọi công ty cấp cho agent của từng người dùng một môi trường điện toán container riêng."

Chênh lệch về tài nguyên giải thích mối lo ngại này. Phân tích độc lập của Build MVP Fast cho biết isolate có thể khởi động trong vài mili giây và dùng vài megabyte, trong khi container có thể mất hàng trăm mili giây và hàng trăm megabyte. Đây là các con số định hướng từ bên thứ ba, không phải benchmark chính thức của Cloudflare Computer.

Với nền tảng phục vụ N users x M agents, số người dùng và số agent mới chỉ là hệ số nhân đầu tiên. Đội ngũ còn phải tính tần suất tác vụ, mức thực thi đồng thời, retry, thời gian nhàn rỗi, lưu trữ, lưu lượng mạng, logging và review của con người. Dù tỷ lệ chọn container nhỏ, nó vẫn có thể chiếm phần lớn chi phí nếu tác vụ chạy trên container lâu hơn hoặc retry nhiều hơn.

Hãy xét một workflow giả định do Maya, một kỹ sư platform, phụ trách. Agent của cô kiểm tra tệp trong repository, chuyển đổi định dạng dữ liệu có cấu trúc và tóm tắt log. Một sandbox Linux cố định sẽ cấp tài nguyên dư thừa cho những tác vụ chủ yếu chỉ cần thao tác tệp và dữ liệu.

Với chính sách ưu tiên isolate, các thao tác phổ biến đó vẫn chạy trên đường gọn nhẹ. Container chỉ được dùng khi workflow của Maya gọi đến một dependency dòng lệnh native. Kết quả hữu ích không phải là một tỷ lệ tiết kiệm giả định, mà là tỷ lệ chọn container đo được, gắn với các loại tác vụ thực tế.

Phân tích của Van Data Team. Sai lầm chúng tôi thường gặp là chỉ nhóm chi phí theo dịch vụ hạ tầng. Chi phí điện toán của agent cần được truy ngược về workflow và năng lực mà tác vụ thực sự cần. Kỷ luật vận hành dùng để giảm chi phí cloud mà không làm chậm tiến độ triển khai cũng áp dụng được ở đây: xác định cái gì tạo ra chi phí và công việc có thực sự cần đến nó hay không.

Cloudflare Computer cung cấp lựa chọn điện toán như thế nào

Hình minh họa sau tóm tắt nguyên tắc: mặc định chạy gọn nhẹ, chỉ chuyển sang container khi cần Linux:

Cloudflare Computer cho agent chọn dynamic Workers cho công việc tệp và dữ liệu, và chọn Cloudflare Containers khi tác vụ cần môi trường Linux đầy đủ.

Thông tin được công bố. Trên đường isolate, just-bash chuyển lệnh shell thành JavaScript chạy trong dynamic Workers. V8 isolate gọn nhẹ khởi động gần như tức thì cho các thao tác tệp và xử lý dữ liệu được hỗ trợ. Agent vẫn dùng các thao tác kiểu shell quen thuộc mà không cần được cấp cố định một container Linux.

Khi tác vụ cần binary native, npm hoặc công cụ chuyên biệt, agent có thể chọn backend Cloudflare Containers. Runtime container mount hệ thống tệp dùng chung qua FUSE, chạy công việc phụ thuộc Linux và giữ các tệp kết quả sẵn sàng cho đường isolate.

Luồng thực thi rất đơn giản: agent yêu cầu một công cụ, truyền lựa chọn backend cho exec, backend được chọn sẽ chạy công việc và kết quả được trả về qua workspace dùng chung. Lựa chọn hạ tầng vẫn được thực hiện qua giao diện runtime chung.

Bảng quyết định điện toán cho agent

Hãy dùng worksheet này trước khi chuyển một workflow sang mô hình thực thi ưu tiên isolate. Nó gộp việc định tuyến theo năng lực, bài toán kinh tế, quản trị và đánh giá vào một tài liệu review duy nhất.

Loại tác vụ nào nên mặc định chạy trên isolate

Mặc định ưu tiên isolate: Thao tác tệp được hỗ trợ, xử lý dữ liệu hoặc công việc kiểu shell được chuyển thành JavaScript.

Điều kiện chuyển sang container: Cần binary native, npm hoặc công cụ chuyên biệt.

Telemetry bắt buộc: Lớp tác vụ, loại lệnh, backend và kết quả.

Khi nào môi trường thực thi cần chuyển sang container

Mặc định ưu tiên isolate: Không có dependency cần Linux đầy đủ.

Điều kiện chuyển sang container: Workload cần hành vi đặc thù của Linux.

Telemetry bắt buộc: Dependency, năng lực được yêu cầu và lý do chuyển sang container.

Quyền nào cần áp dụng trước khi chuyển sang container

Mặc định ưu tiên isolate: Phạm vi tối thiểu cho hệ thống tệp, secret và mạng.

Điều kiện chuyển sang container: Quyền rộng hơn chỉ được cấp khi có chính sách cho phép rõ ràng.

Telemetry bắt buộc: Kết quả kiểm tra chính sách, phạm vi quyền được cấp và agent yêu cầu.

Làm sao duy trì tính liên tục của workspace

Mặc định ưu tiên isolate: Đọc và ghi qua workspace dùng chung.

Điều kiện chuyển sang container: Cần truy cập Linux mà không tạo thêm một nguồn dữ liệu gốc (source of truth) khác.

Telemetry bắt buộc: Phiên bản đầu vào, agent ghi, thay đổi và hash đầu ra.

Đánh giá hiệu quả kinh tế của việc chuyển sang container như thế nào

Mặc định ưu tiên isolate: Dùng thời gian chạy trên isolate và đơn giá đã đo.

Điều kiện chuyển sang container: Giá trị mà container mang lại đủ bù cho chi phí và độ trễ của nó.

Telemetry bắt buộc: Đơn giá, thời gian chạy, retry, độ trễ và ngân sách token.

Những cổng an toàn và chất lượng nào phải kiểm soát việc chuyển đổi

Mặc định ưu tiên isolate: Tiếp tục khi điều kiện dừng và ngưỡng đánh giá đều đạt.

Điều kiện chuyển sang container: Chặn hoặc yêu cầu review khi rủi ro vượt ngưỡng chính sách.

Telemetry bắt buộc: Kết quả đánh giá, lý do dừng, người review và quyết định xử lý.

Hãy tính mức độ phơi nhiễm chi phí (exposure) bằng dữ liệu workload thực tế, không dựa trên giả định của nhà cung cấp:

• Scale exposure = active users x active agents per user x tasks per agent x container escalation rate
• Runtime cost = isolate work x measured isolate unit cost + container work x measured container unit cost + storage + network + logging + evaluation
• Effective task cost = runtime cost + model token cost + retry overhead + human review overhead

CHỈ SỐ THEN CHỐT: TỶ LỆ CHUYỂN SANG CONTAINER

Chỉ số đo gì: Tần suất tác vụ agent chọn đường container thay vì đường ưu tiên isolate.

Vì sao quan trọng: Dù tỷ lệ chọn container nhỏ, nó vẫn có thể chiếm phần lớn chi phí nếu tác vụ chạy trên container lâu hơn hoặc retry nhiều hơn.

Phân đoạn thế nào: Theo dõi tỷ lệ này theo workflow, loại tác vụ và framework, cùng với chi phí, độ trễ, mức dùng token, retry và kết quả đánh giá.

Dữ liệu đầu vào bắt buộc gồm billing export, log chọn backend, thời gian chạy tác vụ, tỷ lệ retry, mức dùng token và mã lý do chuyển sang container. Hãy đo cả mức độ đồng thời. Khối lượng tác vụ trung bình có thể che giấu các đỉnh tải đột biến làm thay đổi nhu cầu tài nguyên.

Quy tắc quyết định là ưu tiên môi trường rẻ nhất mà vẫn đủ năng lực, không phải môi trường mạnh nhất đang có sẵn. Isolate không nên chạy công việc nó không thể hỗ trợ an toàn. Container không nên khởi động chỉ vì nó có sẵn.

Nếu danh mục workload chưa đầy đủ, trước hết hãy biến bản mô tả vận hành thành phạm vi tự động hóa có thể triển khai. Một buổi review hữu ích cần tạo ra bản đồ tác vụ, danh sách dependency, chính sách chuyển sang container, schema telemetry, kế hoạch đánh giá và phạm vi triển khai theo giai đoạn.

Hệ thống tệp dùng chung là nền tảng ổn định

Hệ thống tệp dùng chung là một workspace bền vững, cho phép agent đổi backend thực thi mà không phải tạo các bản sao riêng của trạng thái đang làm việc.

Thông tin được công bố. Cloudflare Computer duy trì hệ thống tệp ảo dựa trên SQLite được đồng bộ giữa isolate và container. Workspace có thể được khởi tạo từ git repository hoặc cloud storage. Khi dùng container, FUSE mount chính workspace đó vào môi trường Linux.

Phân tích của Van Data Team. Hãy xem backend thực thi là thứ có thể thay thế, còn provenance của workspace là thứ phải giữ lâu dài. Mọi artifact quan trọng cần lưu phiên bản nguồn, trạng thái độ mới, agent đã ghi, lịch sử biến đổi, backend đã chọn và hash đầu ra.

Hệ thống tệp đồng bộ đảm bảo tính liên tục. Nhưng nó không chứng minh được dữ liệu đầu vào còn mới, đã được phê duyệt hay được tái tạo chính xác. Workflow production vẫn cần bản ghi lineage và data SLA.

Hãy xét một workflow giả định khác. Agent nghiên cứu của Arun chuẩn hóa tệp trong isolate, còn agent build chuyển sang Linux để gọi dependency native. Sau đó agent báo cáo xuất bản kết quả từ workspace dùng chung.

Về mặt kỹ thuật, tệp cuối cùng có thể sẵn sàng cho mọi agent. Tuy nhiên, nếu thiếu provenance, Arun không thể xác định phiên bản nguồn nào đã được dùng hoặc backend nào đã thay đổi artifact. Lưu trữ dùng chung giúp các bản sao không bị lệch nhau, còn lineage giúp lấp khoảng trống khi audit.

Đây là điểm giao nhau giữa kiến trúc agent và data engineering. Pipeline lưu lại mọi file nguồn và nạp dữ liệu an toàn khi chạy lại mang lại đầu vào đáng tin cho agent. Sự linh hoạt của runtime không thể bù đắp cho dữ liệu cũ hoặc không truy vết được.

Quản trị, observability và đánh giá trước khi chuyển sang container

Chuyển sang container một cách an toàn đòi hỏi quyền theo nguyên tắc tối thiểu, chính sách năng lực rõ ràng, telemetry đầy đủ, điều kiện dừng và đánh giá riêng cho từng tác vụ.

Bắt đầu với quyền hẹp cho hệ thống tệp, secret, package và mạng. Việc cần tài nguyên điện toán mạnh hơn không có nghĩa là tự động được cấp quyền truy cập dữ liệu rộng hơn. Hãy xác định một capability allowlist nêu rõ workflow nào được phép chuyển sang container và được gọi những dependency nào.

Ghi lại lựa chọn backend, lý do chuyển sang container, thời gian thực thi, chi phí, độ trễ, ngân sách token, số lần retry và kết quả đánh giá của mỗi agent. Thay đổi tệp cần chỉ ra phiên bản đầu vào, agent ghi, loại lệnh và quyết định cuối.

Điều kiện dừng cần chặn được các trường hợp công cụ lỗi lặp lại, vòng lặp lập kế hoạch không giới hạn, chi phí tăng vọt, thực thi trên dữ liệu cũ và đánh giá không đạt. Lệnh tác động cao hoặc đầu ra có độ tin cậy thấp cần tạm dừng để con người review trước khi tiếp tục.

Đánh giá phải kiểm tra nhiều hơn câu trả lời cuối. Nó cần kiểm tra xem agent có chọn đúng backend, có ở trong phạm vi quyền, có giữ đúng các tệp mong đợi và có dừng khi chính sách yêu cầu hay không. Kiểm thử khôi phục cần xác nhận công việc container bị gián đoạn hoặc thất bại không làm hỏng workspace dùng chung.

Theo dõi tỷ lệ chọn container theo workflow, loại tác vụ và framework. Mức trung bình toàn cục có thể che giấu một planner chọn công cụ đắt đỏ một cách không cần thiết. Số lần dùng container tăng bất thường có thể là dấu hiệu của dependency native ẩn, định tuyến tác vụ kém hoặc agent đang lấy Linux làm lối thoát mặc định.

Playbook vận hành agent production và escalation cho con người của Van Data Team đưa ra mô hình thực tế cho cổng review và khôi phục sau lỗi. Một đợt đánh giá runtime cần tạo ra ma trận escalation, yêu cầu về dashboard, chính sách dừng, bộ eval và runbook xử lý sự cố.

Vai trò của framework agent và MCP

Framework agent quyết định cần yêu cầu hành động nào, còn runtime kiểm soát hành động đó chạy ở đâu, áp dụng quyền nào và trạng thái nào được giữ lại.

LangGraph, LangChain, CrewAI và các mẫu Plan-and-Execute tổ chức việc lập kế hoạch, trạng thái, phân công và workflow nhiều bước. Function calling native kết nối đầu ra của mô hình với các hàm ứng dụng có kiểu dữ liệu rõ ràng. MCP đưa ra một cách chuẩn hóa để cung cấp công cụ và ngữ cảnh cho agent.

Các lớp này nằm cạnh runtime, không thay thế runtime. Một node LangGraph có thể yêu cầu thao tác shell, nhưng chính sách runtime cần quyết định isolate có xử lý được không. Một worker CrewAI có thể yêu cầu công cụ chuyên biệt, nhưng việc chọn container vẫn cần quyền và đánh giá.

Mối liên kết này phải quan sát được. Hãy so sánh chi phí, độ trễ, ngân sách token, lựa chọn backend, retry và kết quả eval giữa các workflow và các mẫu orchestration. Một planner tốt hơn có thể giảm lãng phí, nhưng không xóa bỏ nhu cầu về giới hạn tài nguyên, dữ liệu đáng tin hay cơ chế khôi phục.

Đánh giá ở cấp framework trả lời câu hỏi agent có chọn hành động hữu ích hay không. Đánh giá runtime trả lời câu hỏi hành động đó có chạy đúng môi trường, đúng chính sách hay không. Đội vận hành production cần cả hai.

Kết luận: kiểm thử áp lực cho runtime, không chỉ cho mô hình

Mặc định phù hợp cho production là ưu tiên isolate, chứ không phải loại bỏ container. Container vẫn có giá trị khi agent thực sự cần Linux, binary native, npm hoặc công cụ chuyên biệt. Nhưng chúng không nên trở thành cấu hình cố định cho agent của mọi người dùng.

Cloudflare Computer cho thấy runtime AI agent có thể kết hợp thực thi gọn nhẹ với quyền truy cập container khi cần. Workspace dùng chung cũng giúp backend thực thi trở nên có thể thay thế, miễn là đội ngũ duy trì được kiểm soát về độ mới, lineage, quyền và khôi phục.

Hãy bắt đầu từ worksheet. Đo các loại tác vụ hiện tại, thời gian chạy sandbox, tỷ lệ chọn container, độ trễ, mức dùng token, retry và kết quả eval. Sau đó so sánh mô hình thu được với chi phí sandbox hiện tại.

Với các đội muốn có một buổi review đủ cụ thể để triển khai ngay, Van Data Team có thể cung cấp bản đồ workflow, mô hình chi phí, chính sách chuyển sang container, đặc tả telemetry, kế hoạch eval và phạm vi triển khai theo giai đoạn. Cách tiếp cận do nhà sáng lập trực tiếp dẫn dắt của chúng tôi giữ khảo sát, kiến trúc và triển khai trong cùng một vòng trách nhiệm thống nhất.