Agent không máy chủ

Xây dựng một Agent không hề dễ dàng.

Một năm trước, chúng ta phải tự quản lý ngữ cảnh và bộ nhớ, cân nhắc về RAG và cơ sở dữ liệu vector, đồng thời điều chỉnh độ chính xác sử dụng công cụ một cách rất cẩn thận. Sự xuất hiện của Claude Code / Claude Agent SDK đã thay đổi tất cả điều này. Giờ đây, ngày càng nhiều nhóm bắt đầu xây dựng Agent trực tiếp bằng Claude Agent SDK + VM. Vậy vấn đề đã trở nên đơn giản hơn chưa? Chưa.

Chạy Claude Code trên VM vẫn là một việc rất thách thức.

1. Mỗi phiên người dùng cần một VM độc lập. Trong một số trường hợp, khả năng lưu trữ của VM có thể hữu ích, nhưng nó cũng khiến VM khó nâng cấp và điều phối. Ví dụ, từ góc nhìn người dùng, họ mong phần mềm cài trên VM vẫn dùng được sau nhiều tháng. Nhưng các thành phần trên VM giao tiếp với lớp điều phối cũng cần có khả năng cập nhật.

2. Tạo và điều phối VM ở quy mô lớn. Một cụm k8s đơn lẻ chỉ điều phối được khoảng vài nghìn pod, đủ cho các cụm dịch vụ ứng dụng. Nhưng chưa đủ cho các trường hợp mỗi phiên cần khởi động một pod claude code.

3. Sử dụng giải pháp k8s gặp phải độ trễ do k8s gây ra, khiến khó đạt hiệu năng trong vòng 1 giây.

4. Dùng giải pháp e2b thì phải tự xử lý lưu trữ, và việc tải lên/tải xuống file đều rất chậm.

5. Giải pháp e2b không đáp ứng được yêu cầu môi trường mạng riêng biệt, và triển khai nội bộ rất rườm rà.

Chúng ta giải quyết các vấn đề này như thế nào? Hãy học từ lịch sử. Khi quay lại hơn một thập kỷ trước, vào năm 2012, thế giới chưa có serverless, chưa có k8s, chưa có docker. Kỹ sư backend phải tự duy trì tiến trình dịch vụ trên máy vật lý để chạy dịch vụ. Khi đó, ssh và ansible là công cụ tiêu chuẩn của kỹ sư máy chủ. Tiến trình dịch vụ phụ thuộc nặng vào môi trường công cụ trên máy vật lý. Đảm bảo cấu hình môi trường công cụ nhất quán giữa các máy vật lý là một thách thức lớn, và mở rộng quy mô lớn là việc mà các nhóm phải chuẩn bị từ rất sớm. Tôi vẫn nhớ có lần một kỹ sư thay đổi môi trường trên một máy mà quên đồng bộ sang các máy khác, gây ra một lỗi ma rất khó truy vết trong môi trường sản xuất. Đó là một thời kỳ rất đau đớn.

Đến năm 2012, docker xuất hiện. Docker đóng gói toàn bộ môi trường công cụ vào một image duy nhất, giải quyết vấn đề không nhất quán môi trường. Cộng đồng dần nhận ra rằng một tiến trình dịch vụ chạy trong máy ảo trên máy vật lý có thể được quản lý như một tiến trình trên máy vật lý. Nhưng điều phối docker vẫn đòi hỏi đội ngũ kỹ thuật xây dựng hệ thống điều phối. Và khi tiến trình dịch vụ trong docker bị phụ thuộc vào mạng và hệ thống file của máy vật lý, việc điều phối trở nên rất đau đầu.

Đến năm 2014, dịch vụ không trạng thái bắt đầu trở thành xu hướng chủ đạo. Năm đó chứng kiến sự ra đời của Kubernetes và AWS Lambda. Mỗi nền tảng mô tả tương lai của dịch vụ không trạng thái từ các góc nhìn khác nhau. Dịch vụ không trạng thái nghĩa là logic dịch vụ tránh phụ thuộc vào địa chỉ mạng và không còn phụ thuộc vào hệ thống file lưu trữ cục bộ.

Sau đó là những năm 10 của cloud native, làn sóng dịch vụ không trạng thái đã sinh ra hàng loạt hạ tầng cloud native như:

• Cổng dịch vụ Istio/Linkerd/Envoy/Treafik
• Nền tảng CI/CD Argo CD / Flux
• Nền tảng quan sát Prometheus/Grafana/ELK Stack
• Phân tích chuỗi gọi Jaeger/Zipkin/OpenTelemetry
• Lưu trữ Rook/MinIO/JuiceFS

Và giờ chúng ta đang ở một khởi đầu mới. Mười năm trước, một đơn vị tính toán là tiến trình dịch vụ api java/python. Bắt đầu từ năm nay, đơn vị tính toán này đã trở thành một agent lập trình.

ACFS giống như thời kỳ phải tự duy trì tiến trình dịch vụ trên máy vật lý. E2B giống như Docker. Nếu không có nền tảng điều phối tác vụ, nền tảng quan sát và khả năng lưu trữ trạng thái phân tán, việc mở rộng quy mô cho agent lập trình vẫn rất khó. Và hạ tầng Agent không máy chủ mà tôi kỳ vọng cần có các khả năng sau:

1. Có thể lưu trữ hợp lý phiên và thư mục làm việc của agent lập trình mà không mất ngữ cảnh.
2. Siêu nhanh, có thể khởi động agent lập trình trong vòng 100ms.
3. Có Logging / Metric / Tracing cho hành vi Agent dễ hiểu với con người, giúp con người dễ hiểu và điều chỉnh hành vi Agent.
4. Lập trình viên không còn phải quan tâm đến chi tiết như máy ảo, container và các vấn đề vận hành khác, giúp điều phối quy mô lớn trở nên rất dễ dàng.

Tôi nghĩ mọi hạ tầng đáp ứng được các khả năng này đều đã sẵn sàng, ví dụ firecracker đã chứng minh hiệu năng và độ ổn định của microVM, và cũng có nhiều lựa chọn cho nền tảng quan sát phân tán và hệ thống lưu trữ file. Nhưng với tư cách là lập trình viên từng trải nghiệm dùng e2b đóng gói claude code, việc tích hợp tất cả lại vẫn rất khó. Ví dụ, khi claude code trong E2B bị ngắt đột ngột do OOM, kỹ sư rất khó giám sát, và càng khó hơn để lấy lại bối cảnh và log lúc đó.

Tôi hy vọng các lập trình viên sinh ra sau 2026 sẽ không phải trải qua quá trình đau đớn như vậy, giống như hầu hết kỹ sư ở 2026 không còn phải dùng ssh để khởi tạo máy vật lý thủ công nữa.

Đây là giấc mơ của VM0. Tôi hy vọng một ngày nào đó mình có thể điều khiển agent lập trình qua một API thân thiện, như:

cosnt agent = vm0.run({
	framework: 'claude-code',
	prompt: 'buy me a coffee'
})