Ba tháng trước mình cãi nhau với một security reviewer về Cloud Agents của Cursor. Không hẳn cãi nhau, chỉ là mấy tin nhắn Slack, khá lịch sự, nhưng cái vướng là thật: policy compliance của khách yêu cầu mọi thứ chạy code, kể cả sandbox của AI agent, phải nằm trong VPC của họ. Cloud agent của Cursor thì chạy trên máy của Cursor. Hết. Cuối cùng mình phải tắt tính năng đó cho khách này, bảo team quay lại dùng local agent, trải nghiệm tệ hơn hẳn và ai cũng biết.

Ngày 3/9/2026, Cursor sửa đúng cái đó, trễ sáu tháng so với cái mình muốn, nằm trong một dòng changelog của Vercel mà chắc nhiều người lướt qua: “Cursor Cloud Agents giờ chạy được trên Vercel Sandbox.” Đọc lướt thì tưởng chỉ là tích hợp nhỏ. Đọc kiến trúc bên dưới thì đây là Cursor tự nói toạc ra phần nào của sản phẩm họ thật sự sở hữu.

Cái gì đã ra mắt

Nước đi chính tên là Self-Hosted Machines. Cursor giữ lại agent harness — vòng lặp quyết định đọc gì, sửa gì, chạy test khi nào, dừng khi nào — và để bạn tự cung cấp môi trường thực thi, nơi vòng lặp đó thật sự làm việc: clone repo, ghi file, chạy test suite. Môi trường thực thi đó trước giờ là fleet của riêng Cursor. Giờ có thể là một trong tám backend: Vercel, Cloudflare, Daytona, E2B, Modal, Coder, Namespace, hoặc Lambda, tất cả đi qua chung một worker pool.

Mình xem kỹ phần triển khai của Vercel vì team đang chạy hạ tầng ở đó sẵn. Mỗi request của agent được cấp một Firecracker microVM riêng, tạo theo yêu cầu. Vercel Functions và Vercel Workflows đóng vai control plane: nhận job agent đang xếp hàng, spin up worker, theo dõi session, rồi dọn dẹp khi xong. Không có fleet VM sống lâu nằm chờ sẵn ai đó bấm nút chạy task. Scale-to-zero, isolation riêng cho từng request, credential ngắn hạn chỉ dùng cho đúng job đó.

Pattern này không mới nếu bạn từng build CI runner serverless. Cùng dạng với ephemeral runner của GitHub Actions, hay cách CodeBuild spin container dùng-rồi-bỏ. Cái mới là áp dụng nó cho một vòng lặp agent có thể chạy hai mươi phút, đụng bốn mươi file, và cần retry bền vững nếu worker bên dưới chết giữa chừng — vì khác CI job, bạn không muốn fail rồi restart từ đầu, bạn muốn resume đúng tiến độ agent đã làm.

Vì sao chuyện này quan trọng hơn vẻ ngoài

Chi tiết mình phải đọc lại lần hai mới thấm: Self-Hosted Machines chỉ dành cho gói Cursor Enterprise. Đó chính là điểm mấu chốt. Cursor không cho không sự linh hoạt hạ tầng vì tốt bụng — họ đang vạch ranh giới giữa “bộ não agent, cái này chúng tôi bán” và “compute chạy nó, cái này chúng tôi không nhất thiết phải bán nữa.” Đây là một công ty thành thật về khả năng phòng thủ thật sự của mình. Giá trị không nằm ở sandbox. Ai cũng dựng được một Firecracker VM. Giá trị nằm ở harness: phần quyết định thế nào là “xong” cho một task code, retry thông minh, và không đốt token budget đọc lại file đã đọc rồi.

So với cách OpenAI thiết kế Agents API một tuần trước đó (10/9) với chín đối tác sandbox riêng — Vercel, Cloudflare, Daytona, E2B, Modal, DigitalOcean, Oracle, Runloop, Blaxel. Khác công ty, danh sách gần như trùng, cùng một sự thừa nhận bên dưới. Cả hai đang hội tụ về một điểm: harness mới là sản phẩm, sandbox chỉ là hàng hoá cắm vào. Hai đối thủ độc lập ra cùng một kiến trúc trong vòng một tuần, đó không phải trùng hợp, đó là hình dạng thật của bài toán.

Cái mình thật sự sẽ kiểm tra trước khi dùng

Mình thử deploy nhanh reference implementation của Vercel Sandbox lên tài khoản cá nhân, chủ yếu để xem failure mode trước khi dám giao cho việc của khách:

# Reference deployment của Vercel cho sandbox worker của Cursor
git clone https://github.com/vercel/cursor-sandbox-worker
cd cursor-sandbox-worker
vercel link
vercel env pull .env.local
vercel deploy --prod

Deploy mất khoảng chín mươi giây. Nối nó vào settings Self-Hosted Machines của Cursor và chạy thử một agent thì chạy ngay lần đầu, thật ra khá bất ngờ — hầu hết tích hợp kiểu “mang hạ tầng của bạn” không sống sót được lần chạm đầu tiên.

Cái mình không kiểm chứng được từ docs, và cái mình sẽ hỏi thẳng trước khi bật lại Cloud Agents cho khách nhạy compliance: chính xác telemetry nào đi ngược từ sandbox về harness của Cursor. Việc thực thi diễn ra trong môi trường gần-VPC của bạn, đúng, nhưng harness ra quyết định vẫn nằm ở Cursor, mà ra quyết định thì cần context — tức nội dung file, diff, output lệnh. “Hạ tầng của bạn” không tự động đồng nghĩa “dữ liệu không bao giờ rời khỏi bạn.” Đó là câu hỏi cho đội sale enterprise của Cursor, không phải thứ suy ra được từ một bài changelog, và mình sẽ cần câu trả lời bằng văn bản trước khi bật lại tính năng này cho khách đó.

Bài học thật sự cho ai đang xây agent tooling

Nếu bạn đang thiết kế hạ tầng agent nội bộ — vài team mình biết đang làm vậy, vì không phải ai cũng muốn giao coding agent cho bên thứ ba — bài học không phải “dùng Firecracker” hay “copy kiến trúc Cursor.” Bài học là hai thứ người ta hay gộp làm một, vòng lặp suy luận và sandbox thực thi, thật ra tách được, và tách ra chính là thứ cho phép bạn bán được cho khách hàng có yêu cầu cứng mà bạn không thuyết phục nổi họ bỏ qua. Team mình mất hai tháng làm workaround cho một giới hạn hoá ra là quyết định sản phẩm, không phải kỹ thuật. Cursor đổi quyết định. Phần kỹ thuật để support nó — isolation bằng Firecracker, credential ngắn hạn, control plane bền vững — vốn đã nằm sẵn đó chờ cắm vào, phần lớn vì Vercel đã xây Sandbox từ trước cho mục đích khác hoàn toàn.

Lần tới có vendor nào nói “kiến trúc nó vốn phải vậy,” hỏi lại xem đó có thật sự là ràng buộc kỹ thuật, hay chỉ là quyết định kinh doanh khoác áo kỹ thuật.