Agen serverless

Membangun sebuah Agen tidaklah mudah.

Setahun lalu, kami harus mengelola konteks dan memori sendiri, memikirkan RAG dan basis data vektor, serta menyetel akurasi penggunaan tool dengan sangat hati-hati. Kemunculan Claude Code / Claude Agent SDK mengubah semua ini. Kini semakin banyak tim mulai langsung membangun Agen menggunakan Claude Agent SDK + VM. Jadi apakah masalahnya menjadi lebih sederhana? Tidak.

Menjalankan Claude Code di dalam VM tetap merupakan hal yang sangat menantang.

1. Setiap sesi pengguna membutuhkan VM yang independen. Dalam beberapa skenario, kemampuan persistensi VM bisa berguna, tetapi itu juga membuat VM sulit di-upgrade dan diorkestrasi. Misalnya, dari sudut pandang pengguna, mereka berharap perangkat lunak yang dipasang di VM akan tetap tersedia berbulan-bulan kemudian. Tetapi bagian-bagian di VM yang berkomunikasi dengan lapisan orkestrasi juga perlu mampu meluncurkan upgrade.

2. Membuat dan mengorkestrasi VM dalam skala besar. Satu klaster k8s mendukung orkestrasi untuk sekitar beberapa ribu pod, yang cukup untuk klaster layanan aplikasi. Tetapi itu tidak cukup untuk skenario di mana setiap sesi perlu memulai sebuah pod claude code.

3. Menggunakan solusi k8s menghadapi latensi yang dibawa oleh k8s, sehingga sulit mencapai performa dalam waktu 1 detik.

4. Menggunakan solusi e2b mengharuskan Anda melakukan persistensi sendiri, dan mengunggah file / mengunduh file keduanya sangat lambat.

5. Solusi e2b tidak bisa memenuhi kebutuhan lingkungan jaringan tertentu, dan deployment privat menjadi merepotkan.

Bagaimana kami memecahkan masalah ini? Mari belajar dari sejarah. Ketika kalender berbalik ke lebih dari satu dekade lalu, pada 2012, belum ada serverless di dunia, belum ada k8s, dan belum ada docker. Engineer backend harus secara manual memelihara sebuah proses layanan di mesin fisik untuk menjalankan sebuah layanan. Saat itu, ssh dan ansible adalah alat standar bagi engineer server. Proses layanan sangat bergantung pada berbagai lingkungan tool di mesin fisik. Mencapai konfigurasi lingkungan tool yang konsisten di seluruh mesin fisik sangatlah menantang, dan penskalaan dalam skala besar adalah pekerjaan besar yang perlu dipersiapkan tim jauh-jauh hari. Saya masih ingat ketika seorang engineer mengubah lingkungan satu mesin dan lupa menyinkronkannya ke lingkungan mesin lain, menyebabkan sebuah bug hantu yang sangat sulit dilacak di produksi. Periode itu adalah masa lama yang sangat menyakitkan.

Pada 2012, docker muncul. Docker mengemas semua lingkungan tool ke dalam satu image tunggal, memecahkan masalah ketidakkonsistenan lingkungan. Komunitas perlahan menyadari bahwa sebuah proses layanan yang berjalan di mesin virtual di atas mesin fisik bisa dikelola seperti sebuah proses di mesin fisik. Tetapi orkestrasi docker masih mengharuskan tim rekayasa membangun sebuah sistem orkestrasi. Dan begitu proses layanan di dalam docker menjadi terpasangkan dengan jaringan dan sistem file mesin fisik, orkestrasi menjadi hal yang sangat menyakitkan.

Pada 2014, layanan stateless mulai menjadi tren arus utama. Tahun itu menyaksikan kelahiran Kubernetes dan AWS Lambda. Keduanya menggambarkan masa depan layanan stateless dari sudut yang berbeda. Layanan stateless berarti logika layanan menghindari keterpasangan dengan alamat jaringan dan tidak lagi bergantung secara lokal pada sistem file yang persisten.

Lalu datanglah 10 tahun cloud native, gelombang layanan stateless melahirkan sekumpulan besar infrastruktur cloud native, seperti:

• Service gateway Istio/Linkerd/Envoy/Treafik
• Platform CI/CD Argo CD / Flux
• Platform observabilitas Prometheus/Grafana/ELK Stack
• Analisis rantai panggilan Jaeger/Zipkin/OpenTelemetry
• Penyimpanan Rook/MinIO/JuiceFS

Dan kini kami berada di sebuah permulaan baru. Sepuluh tahun lalu, sebuah unit komputasi adalah sebuah proses layanan api java/python. Mulai tahun ini, unit komputasi itu telah menjadi sebuah coding agent.

ACFS bagaikan era memelihara proses layanan secara manual di mesin fisik. E2B bagaikan Docker. Tanpa platform orkestrasi tugas, platform observabilitas, dan kemampuan penyimpanan persistensi state terdistribusi, skalabilitas masih merupakan hal yang sulit bagi coding agent. Dan Serverless Agent Infra yang saya harapkan memiliki kemampuan-kemampuan ini:

1. Mampu mempersisten sesi dan direktori kerja coding agent secara tepat tanpa kehilangan konteks.
2. Sangat cepat, mampu membuat sebuah coding agent bekerja dalam 100ms.
3. Memiliki Logging / Metric / Tracing untuk perilaku Agen yang mudah dipahami manusia, sehingga lebih mudah bagi manusia untuk memahami dan menyesuaikan pola perilaku Agen.
4. Developer tidak perlu lagi memikirkan detail seperti mesin virtual, container, dan detail ops lainnya, sehingga orkestrasi skala besar menjadi sangat mudah.

Saya rasa semua infrastruktur yang bisa memenuhi kemampuan-kemampuan ini sudah siap, misalnya firecracker telah memvalidasi performa dan stabilitas microVM, dan ada pula banyak pilihan untuk platform observabilitas terdistribusi dan sistem penyimpanan file. Tetapi sebagai seorang developer yang telah berpengalaman menggunakan e2b untuk membungkus claude code, mengintegrasikan semua ini menjadi satu tetaplah sangat sulit. Misalnya, ketika claude code di E2B tiba-tiba terinterupsi oleh OOM, sulit bagi engineer untuk memantaunya, dan bahkan lebih sulit lagi untuk mendapatkan kondisi dan log pada saat itu.

Saya berharap para developer setelah 2026 tidak perlu melalui proses yang menyakitkan seperti itu, sebagaimana kebanyakan engineer pada 2026 tidak lagi perlu menggunakan ssh untuk menginisialisasi mesin fisik secara manual.

Inilah impian VM0. Saya berharap suatu hari saya bisa menggerakkan sebuah coding agent melalui API yang ergonomis, seperti:

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