Agent Substrate & Agent Sandbox: Xây Hạ Tầng AI Agent Chuẩn Kubernetes

Tóm tắt nhanh:

Agent Substrate là lớp orchestration chuyên cho AI agent, xây trên Kubernetes nhưng bỏ control-plane ra khỏi “critical path” để đạt độ trễ thấp và mật độ agent rất cao.

Kết hợp với GKE Agent Sandbox (gVisor), bạn có thể cho LLM/agent chạy code không tin cậy trong môi trường cô lập, kernel-level isolation, scale hàng trăm sandbox mỗi giây với latency dưới một giây.

Bài viết hướng dẫn luồng cài đặt cơ bản trên GKE/Kind, kết nối với kagent và gợi ý cách áp dụng vào workflow thực tế cho dev, MLOps, self-hosted AI agent.

Agent Substrate là một hệ thống chạy trên Kubernetes, được thiết kế riêng cho “agent-like workloads” – các agent gần như luôn ở trạng thái idle, nhưng cần bật dậy cực nhanh khi có yêu cầu.

Thay vì để mọi request đi qua Kubernetes control-plane như một Pod/Job truyền thống, Substrate đưa control-plane ra khỏi đường đi nóng, từ đó đạt được mật độ agent cao hơn và độ trễ thấp hơn cho hàng triệu tool-call ngắn.

Về bản chất, Agent Substrate là lớp runtime “trên” Kubernetes: nó vẫn tận dụng Pod, autoscaling, storage, nhưng định nghĩa API riêng (CRD, controller, worker pool, actor template…) để quản lý vòng đời actor/worker phục vụ AI agent.

Điều này phù hợp với xu hướng “Kubernetes trở thành agent runtime” mà Google Cloud đang theo đuổi với Agent Sandbox, Pod Snapshots và các primitive mới cho agent workloads.

Vì sao cần Agent Sandbox và Agent Substrate?

Khi để LLM tự sinh code hoặc gọi tool, bạn phải giả định rằng code đó có thể lỗi, bị prompt injection, hoặc làm những việc nguy hiểm như xóa dữ liệu, scan mạng nội bộ.

GKE Agent Sandbox giải quyết vấn đề này bằng sandbox kernel-level (gVisor), cho mỗi sandbox một kernel, network và filesystem riêng, hạn chế quyền truy cập và cô lập tác động của code không tin cậy.

Tuy nhiên, chỉ có sandbox chưa đủ nếu bạn muốn chạy hàng trăm nghìn hoặc hàng triệu agent: agent thường “burst” rất mạnh, sống ngắn, và pattern không giống web service truyền thống.

Agent Substrate xuất hiện như lớp orchestration chuyên để “nhồi” khối lượng agent đó vào cluster Kubernetes, hỗ trợ snapshotting, scheduling sub-second và bảo đảm agent có thể resume, survive outage, human-in-the-loop… ở quy mô lớn.

Kiến trúc tổng quan: GKE, Agent Sandbox, Agent Substrate

Trong kiến trúc điển hình:

GKE/Kind cluster: hạ tầng Kubernetes nền tảng (control-plane, worker node, autoscaler).
GKE Agent Sandbox: Kubernetes add-on định nghĩa các CRD như Sandbox, SandboxTemplate, SandboxClaim, cung cấp môi trường singleton, stateful, cô lập cho agent.
Agent Substrate: lớp orchestration actor/worker, dùng worker pool và snapshot để quản lý hàng loạt agent trên node Kubernetes.
Agent runtime (kagent, ADK, LangChain, v.v.): framework nơi bạn định nghĩa logic agent, tool, memory; runtime này nói chuyện với Substrate và/hoặc Agent Sandbox qua API/CRD.

Bạn có thể hình dung: Agent runtime là “não”, Agent Sandbox là “vỏ bọc an toàn để chạy tay chân”, còn Agent Substrate là “bộ xương hạ tầng” giúp bật, dừng, suspend/resume hàng loạt agent một cách hiệu quả.

Chuẩn bị môi trường Kubernetes

Để bắt đầu với Agent Substrate và Agent Sandbox, bạn nên chuẩn bị:

Một GKE cluster (khuyến nghị) hoặc Kind cluster khi muốn thử nghiệm local.
kubectl đã kết nối với cluster.
Quyền cài đặt CRD, controller (cluster-admin hoặc tương đương).

Với GKE, bạn cần bật Agent Sandbox add-on để có CRD Sandbox và controller tương ứng, sau đó mới dùng được các chế độ executor kiểu sandbox (ví dụ GKE Code Executor trong ADK).
Ở môi trường local, bạn có thể dùng Kind; Substrate hiện hỗ trợ GKE hoặc Kind do cần Pod Certificates cho phần snapshot và bảo mật.

Cài đặt Agent Substrate bước từng bước

Agent Substrate được phát hành mã nguồn mở; bạn có thể bắt đầu từ repo chính thức:

Agent Substrate: https://github.com/agent-substrate/substrate
Agent Sandbox: https://github.com/kubernetes-sigs/agent-sandbox

Một flow cài đặt điển hình (rút gọn từ tài liệu và các hướng dẫn thực tế):

Bước 1: Cài Substrate Controller và CRD

Clone repo Substrate và cài CRD + controller vào cluster:

git clone https://github.com/agent-substrate/substrate.git
cd substrate

# Ví dụ apply CRD và controller (tên file có thể thay đổi theo version)
kubectl apply -f config/crd/
kubectl apply -f config/controller/

Kiểm tra CRD đã có:

kubectl get crd actortemplates.ate.dev workerpools.ate.dev

Bước 2: Tạo WorkerPool cho Agent

WorkerPool là nơi Substrate quản lý tài nguyên worker thực thi actor/agent.
Bạn có thể apply một manifest mẫu:

apiVersion: ate.dev/v1alpha1
kind: WorkerPool
metadata:
  name: kagent-default
  namespace: kagent
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: worker
        image: ghcr.io/agent-substrate/worker:latest
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "1"
            memory: "2Gi"

Apply:

kubectl apply -f workerpool.yaml
kubectl get workerpool -n kagent

Bước 3: Deploy Demo/Actor Template

Nhiều demo Substrate cung cấp sẵn script hoặc manifest để tạo ActorTemplate và snapshot “vàng”.

Ví dụ (minh họa):

./hack/install-ate.sh --deploy-demo-counter

kubectl wait --for=condition=Ready actortemplate/counter \
  -n ate-demo-counter --timeout=5m

kubectl get workerpool,actortemplate -n ate-demo-counter

Kết nối với Kagent hoặc Runtime Agent khác

Khi đã có Substrate, bước tiếp theo là cho một agent runtime (ví dụ kagent) sử dụng Substrate như runtime backend:

Cài kagent lên cùng cluster (có thể dùng script get-kagent hoặc chart Helm theo tài liệu kagent).
Đảm bảo kagent đã có schema Substrate (CRD, OpenAPI schema) để hiểu runtime substrate.
Cấu hình AgentHarness sử dụng runtime Substrate và trỏ tới WorkerPool đã tạo.

Ví dụ manifest rút gọn từ hướng dẫn Solo.io:

apiVersion: kagent.dev/v1alpha2
kind: AgentHarness
metadata:
  name: openclaw-substrate-demo
  namespace: kagent
spec:
  backend: openclaw
  runtime: substrate
  description: OpenClaw harness running on Agent Substrate
  modelConfigRef: default-model-config
  substrate:
    workerPoolRef:
      name: kagent-default
    gatewayTokenSecretRef:
      name: my-substrate-gateway-token

Apply và kiểm tra:

kubectl apply -f agent-harness-substrate.yaml
kubectl get agentharness openclaw-substrate-demo -n kagent

Tại đây, từ UI hoặc API của kagent, bạn có thể chat với agent, trong khi Substrate chịu trách nhiệm provision actor/worker trên cluster và tối ưu cách chúng được schedule.

Tích hợp Agent Sandbox để chạy code an toàn

Agent Substrate giải quyết bài toán orchestration mật độ cao, nhưng phần chạy code untrusted vẫn nên giao cho Agent Sandbox.

Trên GKE, bạn có hai layer:

Agent Sandbox: cung cấp primitive Sandbox/SandboxClaim và controller để tạo sandbox pod cô lập, dùng gVisor cho kernel-level isolation.
ADK hoặc runtime: dùng thư viện client (ví dụ k8s-agent-sandbox Python) hoặc GKE Code Executor để yêu cầu sandbox, chạy code rồi thu kết quả.

Flow sandbox mode (GKE Code Executor):

Tạo SandboxClaim từ một SandboxTemplate (ví dụ python-sandbox-template).
Đợi sandbox sẵn sàng từ warm pool.
Gửi code Python vào sandbox và nhận stdout/stderr.
Xóa SandboxClaim, sandbox được dọn dẹp.

Mọi việc này diễn ra trong vài trăm mili-giây nhờ warm pool và Pod Snapshots, thay vì đợi Job/Pod cold start trong hàng chục giây.

Luồng chạy của một AI Agent trên Agent Substrate

Ghép lại, một request từ người dùng có thể đi theo luồng:

Người dùng gọi API của agent (qua kagent, ADK hoặc service self-hosted).
Agent runtime nhận prompt, sử dụng LLM để lập kế hoạch và quyết định cần gọi tool (ví dụ: “chạy đoạn Python này”, “gọi API Kubernetes”).
Với tool cần code execution:

Runtime gọi Agent Sandbox (qua SDK/CRD) để claim sandbox và chạy code.
Code chạy trong Pod sandbox cô lập, chỉ được phép truy cập tài nguyên được cấu hình.

Với tác vụ dài, nhiều bước, agent runtime dùng Agent Substrate để quản lý actor/worker, suspend/resume, lưu state bằng snapshot.
Kết quả được trả về cho LLM, tiếp tục vòng loop Observe–Think–Act cho đến khi hoàn thành mục tiêu.

Mô hình này rất phù hợp cho các hệ thống multi-agent, workflow phức tạp hoặc các “AI agent factory” nơi bạn cần scale rất nhiều agent ephemeral trên cùng một cluster.

Best practice tối ưu hiệu năng và chi phí

Một số lưu ý quan trọng nếu bạn muốn triển khai thực chiến:

Tận dụng warm pool và Pod Snapshots: giảm mạnh cold start, đặc biệt khi số lượng sandbox mỗi giây có thể lên tới hàng trăm với latency sub-second.
Giới hạn tài nguyên trên worker/sandbox: cấu hình requests/limits CPU, RAM để tránh agent “ăn” hết node; dùng autoscaler để scale worker pool.
Tách môi trường dev/stage/prod: với code untrusted, nên tách cluster hoặc tối thiểu tách namespace, dùng network policy hạn chế outbound.
RBAC chặt chẽ cho agent: chỉ cấp permission tối thiểu để tạo SandboxClaim, đọc log, hoặc gọi Substrate API; tránh cho agent quyền cluster-admin.
Quan sát và logging tốt: gắn tracing từ agent runtime xuống sandbox/Substrate để debug khi agent “hành” bất thường, nhất là trong môi trường nhiều tool.

Ứng dụng thực tế cho dev, MLOps và self‑hosted

Với tư cách dev/webmaster tự host như bạn, có một số kịch bản rất hợp lý:

Agent tạo code/infrastructure: cho phép agent sinh manifest Kubernetes, script migration, Terraform… rồi chạy thử trong Agent Sandbox trước khi bạn review và apply thật.
Ops agent cho cluster: dùng kagent + Substrate để tạo một “Kubernetes SRE agent” có thể trả lời câu hỏi về cluster, đọc log, chạy lệnh chẩn đoán trong sandbox, nhưng không đụng được vào tài nguyên nhạy cảm.
Workflow dữ liệu/SEO tự động: agent thu thập log, crawl nội bộ, phân tích với Python trong sandbox rồi đề xuất thay đổi SEO, nội dung cho các site như addrom.com, vnrom.net mà không phải cho nó quyền truy cập hệ thống chính.
Hệ thống multi-agent phục vụ nhiều site/khách hàng: Substrate cho phép đăng ký hàng triệu agent ở trạng thái “almost always idle”, chỉ bật lên khi có job, rất giống mô hình multi-tenant SaaS dành cho AI.

Khi kết hợp với pipeline hiện có (Docker, n8n, API server), bạn có thể xem GKE + Agent Substrate + Agent Sandbox như một “AI execution layer” phía sau, còn n8n/HTTP chỉ là entrypoint điều phối.

Câu hỏi thường gặp về Agent Substrate

Agent Substrate khác gì việc chỉ chạy agent trong Pod/Deployment bình thường?

Pod/Deployment chuẩn của Kubernetes được tối ưu cho service lâu dài, scale theo traffic HTTP, không tối ưu cho mô hình agent bursty, ephemeral, nhiều session nhưng idle phần lớn thời gian.
Agent Substrate cung cấp API level cao hơn (actor, worker pool, snapshot) để tối ưu nhu cầu riêng của agent, đồng thời giảm áp lực lên control-plane khi số lượng agent cực lớn.

Có bắt buộc dùng GKE không?

Substrate hiện hỗ trợ GKE và Kind do phụ thuộc vào Pod Certificates và một số integration cụ thể; về mặt lý thuyết, bất kỳ Kubernetes conformant cluster nào cũng có thể chạy nếu đáp ứng yêu cầu đó.
Tuy nhiên, nếu bạn muốn tận dụng Agent Sandbox, Pod Snapshots, Hypercluster… thì hệ sinh thái mạnh nhất hiện tại là trên GKE.

Tự host có phức tạp không?

So với việc tự build sandbox isolation, snapshot, scheduling từ đầu, dùng Agent Sandbox + Substrate giúp bạn đứng trên vai Kubernetes và các controller đã chuẩn hóa.
Dĩ nhiên vẫn cần kiến thức Kubernetes, CRD, RBAC, nhưng đó là trade-off hợp lý nếu bạn đã quen hạ tầng container và muốn nền tảng agent có thể mở rộng lên mức “hyperscale”.

Với Agent Substrate và Agent Sandbox, bạn có thể xây một “agent platform” chuẩn cloud-native, vẫn self-hosted, tận dụng hạ tầng hiện có nhưng nâng cấp rõ rệt về bảo mật, hiệu năng và khả năng scale của AI agent.

Duy Nghiện

Hãy làm khán giả, đừng làm nhân vật chính :)