Agent แบบ Serverless

การสร้าง Agent ไม่ใช่เรื่องง่าย

เมื่อปีที่แล้ว เราต้องจัดการ context และหน่วยความจำด้วยตัวเอง คิดถึง RAG และฐานข้อมูลเวกเตอร์ และต้องปรับความแม่นยำของการใช้เครื่องมืออย่างระมัดระวังมาก การมาของ Claude Code / Claude Agent SDK เปลี่ยนแปลงทุกอย่าง ตอนนี้มีทีมมากขึ้นเรื่อย ๆ ที่เริ่มสร้าง Agent โดยตรงด้วย Claude Agent SDK + VM แล้วปัญหามันง่ายขึ้นหรือยัง? คำตอบคือไม่

การรัน Claude Code ใน VM ก็ยังเป็นเรื่องที่ท้าทายมาก

1. ทุก session ของผู้ใช้ต้องการ VM แยกต่างหาก ในบางกรณี ความสามารถในการคงอยู่ของ VM มีประโยชน์ แต่ก็ทำให้ VM อัปเกรดและ orchestrate ได้ยาก ตัวอย่างเช่น จากมุมมองของผู้ใช้ พวกเขาหวังว่า software ที่ติดตั้งใน VM จะยังใช้งานได้อีกหลายเดือนต่อมา แต่ส่วนที่อยู่ใน VM ซึ่งสื่อสารกับ orchestration layer ก็ต้องสามารถอัปเกรดได้เช่นกัน

2. การสร้างและ orchestrate VM ในขนาดใหญ่ คลัสเตอร์ k8s เดียวรองรับ orchestration ได้ประมาณไม่กี่พัน pods ซึ่งเพียงพอสำหรับคลัสเตอร์บริการแอปพลิเคชัน แต่ยังไม่พอสำหรับกรณีที่ทุก session ต้องเริ่ม claude code pod

3. การใช้โซลูชัน k8s เผชิญกับความหน่วงที่เกิดจาก k8s ทำให้ยากที่จะได้ประสิทธิภาพภายใน 1 วินาที

4. การใช้โซลูชัน e2b ต้องทำ persistence เอง และการอัปโหลด/ดาวน์โหลดไฟล์ก็ช้ามาก

5. โซลูชัน e2b ไม่สามารถตอบโจทย์ข้อกำหนดของสภาพแวดล้อมเครือข่ายเฉพาะ และการติดตั้งแบบ private ก็ยุ่งยาก

เราจะแก้ปัญหาเหล่านี้อย่างไร? มาดูประวัติศาสตร์กัน เมื่อย้อนเวลากลับไปกว่าสิบปีก่อน ในปี 2012 ยังไม่มี serverless ไม่มี k8s และไม่มี docker วิศวกร backend ต้องดูแล process ของบริการบนเครื่องจริงด้วยตนเองเพื่อรันบริการ ในเวลานั้น ssh และ ansible เป็นเครื่องมือมาตรฐานของวิศวกรเซิร์ฟเวอร์ process ของบริการขึ้นอยู่กับสภาพแวดล้อมเครื่องมือบนเครื่องจริงอย่างมาก การตั้งค่าสภาพแวดล้อมเครื่องมือให้เหมือนกันทุกเครื่องเป็นเรื่องท้าทายมาก และการขยายขนาดในระดับใหญ่เป็นภารกิจใหญ่ที่ทีมต้องเตรียมตัวล่วงหน้า ผมยังจำได้ว่าเคยมีวิศวกรเปลี่ยนสภาพแวดล้อมของเครื่องหนึ่งแต่ลืม sync ไปยังเครื่องอื่น ๆ ทำให้เกิด bug ที่หาสาเหตุได้ยากมากใน production ช่วงเวลานั้นเป็นยุคที่เจ็บปวดมาก

ในปี 2012 docker ปรากฏขึ้น Docker รวมสภาพแวดล้อมเครื่องมือทั้งหมดไว้ใน image เดียว แก้ปัญหาความไม่สอดคล้องของสภาพแวดล้อมได้ ชุมชนเริ่มตระหนักว่า process ของบริการที่รันใน VM บนเครื่องจริงสามารถจัดการได้เหมือน process บนเครื่องจริง แต่การ orchestrate docker ก็ยังต้องให้ทีมวิศวกรสร้างระบบ orchestration ขึ้นมาเอง และเมื่อ process ของบริการใน docker ผูกกับ network หรือ file system ของเครื่องจริง การ orchestrate ก็จะกลายเป็นเรื่องเจ็บปวดมาก

ในปี 2014 บริการแบบ stateless เริ่มกลายเป็นกระแสหลัก ปีนั้น Kubernetes และ AWS Lambda ถือกำเนิดขึ้น ทั้งสองอธิบายอนาคตของบริการแบบ stateless จากมุมที่ต่างกัน บริการแบบ stateless หมายถึง logic ของบริการหลีกเลี่ยงการผูกกับ network address และไม่ต้องพึ่งพา file system แบบ persistent ในเครื่อง

จากนั้นก็เข้าสู่ยุค cloud native 10 กระแสของบริการแบบ stateless ได้ให้กำเนิดโครงสร้างพื้นฐาน cloud native จำนวนมาก เช่น:

• Service gateway Istio/Linkerd/Envoy/Treafik
• แพลตฟอร์ม CI/CD Argo CD / Flux
• แพลตฟอร์ม observability Prometheus/Grafana/ELK Stack
• การวิเคราะห์ call chain Jaeger/Zipkin/OpenTelemetry
• Storage Rook/MinIO/JuiceFS

และตอนนี้เรากำลังอยู่ในจุดเริ่มต้นใหม่ เมื่อสิบปีก่อน หน่วยประมวลผลคือ process บริการ java/python api ตั้งแต่ปีนี้ หน่วยประมวลผลนี้ได้กลายเป็น coding agent

ACFS ก็เหมือนยุคที่ต้องดูแล process บริการบนเครื่องจริงด้วยมือ E2B ก็เหมือน Docker หากไม่มีแพลตฟอร์ม orchestration, แพลตฟอร์ม observability และความสามารถในการจัดเก็บ state แบบ distributed การขยายขนาดสำหรับ coding agent ก็ยังเป็นเรื่องยาก และ Serverless Agent Infra ที่ผมคาดหวังควรมีความสามารถเหล่านี้:

1. สามารถเก็บ session และ working directory ของ coding agent ได้อย่างเหมาะสมโดยไม่สูญเสีย context
2. เร็วมาก สามารถให้ coding agent ทำงานได้ภายใน 100ms
3. มี Logging / Metric / Tracing สำหรับพฤติกรรมของ Agent ที่มนุษย์เข้าใจง่าย ทำให้ปรับเปลี่ยนพฤติกรรม Agent ได้ง่ายขึ้น
4. นักพัฒนาไม่ต้องสนใจรายละเอียดอย่าง VM, container หรือ ops อื่น ๆ อีกต่อไป ทำให้ orchestrate ขนาดใหญ่เป็นเรื่องง่ายมาก

ผมคิดว่าโครงสร้างพื้นฐานที่ตอบโจทย์เหล่านี้มีพร้อมแล้ว เช่น firecracker ได้พิสูจน์ประสิทธิภาพและเสถียรภาพของ microVMs และยังมีตัวเลือกมากมายสำหรับแพลตฟอร์ม observability และระบบจัดเก็บไฟล์แบบ distributed แต่ในฐานะนักพัฒนาที่เคยใช้ e2b ห่อหุ้ม claude code การรวมทุกอย่างเข้าด้วยกันก็ยังยากมาก เช่น เมื่อ claude code ใน E2B ถูกขัดจังหวะโดย OOM อย่างไม่คาดคิด วิศวกรก็ตรวจสอบได้ยาก และยิ่งยากที่จะได้ scene และ log ในขณะนั้น

ผมหวังว่านักพัฒนาหลังปี 2026 จะไม่ต้องเจอประสบการณ์เจ็บปวดแบบนี้อีก เหมือนที่วิศวกรส่วนใหญ่ในปี 2026 ไม่ต้องใช้ ssh เพื่อ initialize เครื่องจริงด้วยตนเองอีกต่อไป

นี่คือความฝันของ VM0 ผมหวังว่าสักวันหนึ่งจะสามารถควบคุม coding agent ได้ผ่าน API ที่ใช้งานง่าย เช่น:

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