Hai cha đẻ Kubernetes muốn kéo agent khỏi laptop lên cloud

“Một monolith nhét vào container thì vẫn là một monolith.” Craig McLuckie, đồng sáng lập Kubernetes, viết câu đó trên blog CNCF hôm 28/9. Nhưng lần này ông không nói về microservice. Ông nói về agent harness — cái vòng lặp đang chạy trên laptop của bạn.

Hôm 7/10, McLuckie cùng Joe Beda, người đồng sáng lập Kubernetes và hiện cùng ông xây dựng Stacklok, lên podcast Latent.Space để giải thích ý đồ: chuyển trọng tâm giá trị của agent từ desktop lên cloud. Với ai từng sống qua làn sóng container, kịch bản này nghe rất quen.

Với FDE, đây không phải chuyện lý thuyết. Bạn mang một agent chạy ngon trên máy mình đến khách hàng, rồi phát hiện câu hỏi đầu tiên không phải “model nào” mà là “ai được chạy nó, ở đâu, với quyền gì”. Hai cha đẻ Kubernetes cho rằng phần lớn harness hiện nay chưa có câu trả lời.

Harness hôm nay là phần mềm một người dùng

Chẩn đoán của Beda rất cụ thể: các harness đang có đều được thiết kế để chạy trên desktop, trong đó vòng lặp agent, phần thực thi và trạng thái phiên làm việc gắn chặt vào nhau. McLuckie diễn giải cùng ý trên CNCF: hầu hết harness giả định một người, một máy, một filesystem cục bộ và một tiến trình tương tác.

Giả định đó không sai khi bạn dùng agent để sửa code của chính mình. Thử hình dung doanh nghiệp muốn hàng trăm người dùng chung một agent, chạy qua đêm, có log để kiểm toán — mọi giả định trên đổ vỡ cùng lúc.

Đây là chỗ McLuckie cảnh báo cái bẫy quen thuộc: đóng gói harness kiểu desktop vào container không giải quyết được vấn đề kiến trúc. Theo ông, một harness cho giai đoạn sắp tới phải được thiết kế như một ứng dụng phân tán ngay từ đầu.

Stacklok đặt cược vào đâu

Câu trả lời của Stacklok là Mecatl, harness mã nguồn mở viết bằng Go. Tài liệu package mô tả nó giữ vòng lặp agent độc lập với client và môi trường thực thi; cùng một vòng lặp chạy trong terminal, chạy như một service, hay chạy trên Kubernetes mà không cần thay thế. Nhờ tách rời như vậy, Mecatl scale ngang qua nhiều replica Kubernetes mà vẫn giữ nguyên vòng lặp.

Mảnh ghép thứ hai là ToolHive, nền tảng MCP mã nguồn mở của Stacklok. ToolHive chạy từng MCP server trong container riêng — local qua Docker hoặc Podman, hoặc trên cluster qua một Kubernetes operator — với một file quyền tối thiểu và không gắn credential cục bộ nào. Công cụ của agent, vì thế, đã đi được từ laptop lên cluster trước cả vòng lặp.

Phần Stacklok bán là một control plane cho doanh nghiệp, nối các dự án mở lại và lo identity, authorization, policy và audit.

Đừng đợi Mecatl trưởng thành

Bạn không cần chờ xem Stacklok có thắng hay không để dùng được khung nhìn của họ: tách vòng lặp, thực thi và trạng thái phiên thành ba thứ có thể sống ở ba nơi khác nhau. Hãy lấy agent bạn đã viết, vẽ ba hộp đó ra và hỏi hộp nào đang biết quá nhiều về hai hộp kia.

Khi đọc JD cho vị trí FDE, để ý bốn từ identity, authorization, policy, audit — đúng danh sách việc mà Stacklok dành cả control plane thương mại để giải quyết. Nếu bạn từng tự tay thêm một trong bốn lớp đó vào một agent, dù chỉ là audit log cho các lần gọi tool, hãy ghi rõ trong CV thay vì gói chung vào “xây dựng AI agent”.

McLuckie nhắc ngành này bài học từ Kubernetes: monolith trong container vẫn là monolith. Lần tới khi ai đó đề nghị “cứ docker hoá agent rồi deploy cho khách”, bạn đã có sẵn câu trả lời.