AI agent

Xây dựng tác nhân AI an toàn với kagent trên Kubernetes

Hướng dẫn kỹ thuật về cách chạy kagent cục bộ, sử dụng danh sách cho phép (allowlist) và phê duyệt có sự tham gia của con người để xây dựng các tác nhân AI an toàn.

Một khối kính đại diện cho cụm Kubernetes với các nút phát sáng và một bàn tay đang kiểm tra.
Minh họa được tạo riêng cho bài viết này

Được dịch tự động từ bản gốc tiếng Anh.

Các nhà phát triển hiện có thể chạy kagent, một dự án CNCF Sandbox, trên laptop cá nhân để xây dựng các tác nhân AI hoạt động như những tài nguyên Kubernetes. Được công bố vào ngày 12 tháng 10 năm 2026 bởi Antonio Berben và Felipe Vicens, hướng dẫn này minh họa cách tạo ra một trình xây dựng tác nhân (agent builder) có khả năng tạo ra các tác nhân khác một cách an toàn. Quy trình này dựa vào các rào chắn nghiêm ngặt thay vì tin tưởng hoàn toàn vào mô hình ngôn ngữ lớn.

Điều gì đã xảy ra

Bài viết chi tiết hóa một phòng thí nghiệm từng bước để thiết lập trình xây dựng tác nhân bằng kagent. Thay vì coi các tác nhân là những tiến trình độc lập, kagent định nghĩa chúng dưới dạng tài nguyên tùy chỉnh trong Kubernetes. Cách tiếp cận này cho phép một tác nhân hiện có tạo ra các tệp manifest YAML cho những tác nhân mới, thực chất biến nó thành một trình xây dựng tự phục vụ. Việc thiết lập sử dụng các công cụ mã nguồn mở bao gồm Docker, kind, kubectl, helm, jq và Ollama để giữ chi phí ở mức tối thiểu và tránh phụ thuộc vào đám mây.

Một phần quan trọng của việc thiết lập liên quan đến cấu hình máy chủ công cụ một cách bảo mật. Theo mặc định, các biểu đồ (charts) của kagent có thể cấp đặc quyền cluster-admin, điều này nguy hiểm ngay cả khi thử nghiệm cục bộ. Hướng dẫn chỉ dẫn người dùng hạn chế quyền hạn sao cho tác nhân xây dựng chỉ có thể tạo ra các loại tài nguyên cụ thể. Điều này đảm bảo rằng các tác nhân được tạo ra hoạt động trong phạm vi xác định, ngăn chặn truy cập trái phép vào các thành phần nhạy cảm của cụm như secrets hoặc deployments.

Buổi trình diễn hướng dẫn qua việc cài đặt cơ sở hạ tầng cần thiết, lựa chọn một mô hình cục bộ đủ mạnh và tương tác với trình xây dựng thông qua giao diện người dùng hoặc API. Mục tiêu là chứng minh rằng việc xây dựng các tác nhân không phải là phép màu mà là một nhiệm vụ kỹ thuật có cấu trúc. Bài viết nhấn mạnh rằng mặc dù việc thiết lập ban đầu khá đơn giản, nhưng thách thức thực sự nằm ở việc quản trị và bảo mật khi các tác nhân này mở rộng vượt ra ngoài môi trường một chiếc laptop.

Cơ chế hoạt động

Hệ thống dựa vào ba lớp bảo mật riêng biệt không chỉ phụ thuộc vào prompt. Thứ nhất, một danh sách cho phép (allowlist) hạn chế những công cụ mà mô hình có thể nhìn thấy. Trong số hai mươi hai công cụ khả dụng, trình xây dựng chỉ truy cập ba công cụ. Thứ hai, cơ chế human-in-the-loop yêu cầu sự phê duyệt của người dùng trước bất kỳ lệnh gọi công cụ nào làm thay đổi trạng thái. Khi tác nhân đề xuất một thay đổi, quá trình chạy sẽ tạm dừng, cho phép người dùng xem xét chính xác tệp manifest trước khi áp dụng. Thứ ba, Kiểm soát truy cập dựa trên vai trò (RBAC) ở cấp độ Kubernetes đảm bảo rằng ngay cả khi một manifest được phê duyệt, máy chủ API vẫn từ chối mọi hành động nằm ngoài quyền hạn của tài khoản dịch vụ.

Tác nhân xây dựng hoạt động bằng cách nhận một yêu cầu bằng ngôn ngữ tự nhiên, chẳng hạn như tạo một tác nhân cho nhóm hỗ trợ khách hàng. Sau đó, nó tạo ra một manifest Kubernetes cho một tài nguyên Agent mới. Manifest này bao gồm system prompt, cấu hình mô hình và một tập hợp hạn chế các công cụ chỉ đọc. Trình xây dựng không trực tiếp thực thi việc tạo ra; thay vào đó, nó xuất ra YAML để xem xét. Sau khi được phê duyệt, bộ điều khiển kagent áp dụng manifest, khởi động một pod mới giao tiếp bằng giao thức Agent-to-Agent (A2A).

Kiến trúc này coi các prompt là yêu cầu chứ không phải cam kết chắc chắn. Việc thực thi thực tế đến từ cơ sở hạ tầng. Ví dụ: nếu mô hình ảo giác tên công cụ hoặc cố gắng tạo một deployment thay vì một agent, allowlist hoặc chính sách RBAC sẽ chặn hành động đó. Sự tách biệt mối quan tâm này đảm bảo rằng lỗi trong đầu ra của mô hình không dẫn đến vi phạm bảo mật hoặc thay đổi cụm ngoài ý muốn.

Chi tiết chính

  • Mô hình cục bộ được khuyến nghị là qwen3-coder:30b-a3b, vì các mô hình nhỏ hơn thường thất bại trong việc tạo ra các manifest Kubernetes hợp lệ.
  • Trình xây dựng sử dụng allowlist gồm ba công cụ trong số hai mươi hai công cụ khả dụng trên máy chủ để giới hạn khả năng của nó.
  • Phê duyệt của con người là bắt buộc đối với bất kỳ lệnh gọi công cụ nào thay đổi trạng thái, cung cấp một điểm kiểm tra trước khi thực thi.
  • Chính sách RBAC hạn chế tài khoản dịch vụ của trình xây dựng chỉ tạo ra các tài nguyên Agent, chặn quyền truy cập vào secrets hoặc deployments.
  • Việc thiết lập sử dụng kind cho cụm Kubernetes và Ollama cho suy luận mô hình cục bộ để giảm thiểu chi phí.
  • Giao diện người dùng chạy trên localhost thông qua kubectl port-forward, đảm bảo nó không bị lộ ra internet công cộng trong quá trình thử nghiệm.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và trưởng nhóm kỹ thuật, cách tiếp cận này chuyển trọng tâm từ kỹ thuật prompt sang thiết kế cơ sở hạ tầng. Chỉ dựa vào prompt để đảm bảo an toàn là không đủ vì các mô hình có thể hiểu sai chỉ dẫn hoặc ảo giác tên công cụ. Bằng cách nhúng bảo mật vào lớp Kubernetes, các đội ngũ có thể xây dựng các tác nhân chống chịu tốt với lỗi mô hình. Phương pháp này cung cấp một dấu vết kiểm toán rõ ràng và các ranh giới có thể thực thi, những yếu tố thiết yếu cho môi trường sản xuất.

Bài viết cũng nêu bật khoảng cách giữa thử nghiệm cục bộ và quản trị doanh nghiệp. Trên một chiếc laptop, tất cả hành động dường như đều đến từ cùng một người dùng, khiến việc theo dõi chi phí hoặc quyền sở hữu trở nên khó khăn. Trong môi trường doanh nghiệp, nhiều tác nhân và framework có thể cùng tồn tại, mỗi cái có tư thế bảo mật khác nhau. Sự phức tạp này biện minh cho một lớp quản trị tập trung đóng vai trò proxy lưu lượng, xử lý xác thực và cung cấp khả năng quan sát xuyên suốt mọi tương tác của tác nhân.

Hiểu rõ các cơ chế này giúp các nhà phát triển vượt ra khỏi những demo đơn giản để xây dựng các hệ thống đáng tin cậy. Nó chứng minh rằng các tác nhân AI có thể tích hợp vào quy trình DevOps hiện có bằng cách sử dụng các công cụ quen thuộc như YAML và kubectl. Điều này hạ thấp rào cản gia nhập cho các đội ngũ đã đầu tư vào Kubernetes, cho phép họ tận dụng AI mà không cần áp dụng hoàn toàn các mô hình vận hành mới.

Bạn có thể làm gì

  • Cài đặt Docker, kind, kubectl, helm, jq và Ollama để chuẩn bị môi trường cục bộ cho phòng thí nghiệm.
  • Tải mô hình qwen3-coder:30b-a3b bằng Ollama để đảm bảo việc tạo manifest đáng tin cậy.
  • Tạo một cụm kind có tên kagent-builder và cài đặt kagent với chính sách RBAC hạn chế.
  • Sử dụng kubectl port-forward để truy cập giao diện người dùng kagent tại localhost:8080 và thử nghiệm trình xây dựng tác nhân.
  • Xem xét kỹ lưỡng các manifest được tạo ra trước khi phê duyệt để hiểu rõ những gì sẽ được áp dụng.
  • Khám phá agentbuilder như một lớp quản trị tiềm năng để quản lý xác thực và khả năng quan sát trong các thiết lập lớn hơn.

Công cụ từ cửa hàng Bytechap

Đọc tiếp

AI agent

Xây dựng agent giọng nói cục bộ bằng Rust với Voxlocal

Voxlocal là một agent giọng nói mã nguồn mở, tối giản được viết bằng Rust và chạy cục bộ trên macOS. Dự án minh họa cách kết hợp nhận dạng giọng nói, tìm kiếm vector và các mô hình ngôn ngữ nhỏ để đạt độ trễ thấp.

AI agent

Ngừng cấp quyền root cho các tác nhân AI trên hệ thống production

Đại sứ CNCF Mauro Morales phản đối việc cấp đặc quyền root cho các tác nhân AI, đề xuất cơ sở hạ tầng bất biến (immutable infrastructure) và nhà máy phần mềm (software factories) như những giải pháp an toàn hơn cho việc quản lý hệ thống tự động.

Tất cả bài viết