Foreman biến các agent mô hình ngôn ngữ lớn (LLM) thành các tài nguyên Kubernetes gốc, cho phép các nhóm chạy mã do AI tạo ra trong môi trường production trong khi vẫn kiểm soát chặt chẽ chi phí và tính an toàn.

Ý tưởng này phù hợp như thế nào với quy trình phát triển hiện nay

Các doanh nghiệp đã và đang thử nghiệm với các LLM có khả năng viết mã, nhưng hầu hết các triển khai đều coi mô hình như một "hộp đen" đáng tin cậy. Một tín hiệu "hoàn thành" duy nhất từ mô hình có thể đẩy các thay đổi chưa được kiểm thử trực tiếp vào một repository, gây ra những lo ngại về bảo mật và độ tin cậy. Đồng thời, việc chạy các dịch vụ AI trên đám mây có thể nhanh chóng trở nên đắt đỏ, đặc biệt là khi cùng một mô hình được gọi lặp đi lặp lại từ các pipeline CI.

Câu trả lời của Foreman là nhúng toàn bộ vòng lặp lập trình vào bên trong một cụm Kubernetes. Foreman chạy dưới dạng các tài nguyên Kubernetes.

Bốn đối tượng cốt lõi tạo nên cơ chế này

  • Agent – Định nghĩa một worker. Nó chỉ định LLM cần gọi, liệt kê các công cụ mà mô hình có thể sử dụng (ví dụ: file-write hoặc git-push), và thiết lập một ngân sách để giới hạn số lần gọi mô hình. Các vai trò (roles) được gắn tại đây; một coder agent sẽ viết mã, còn một verifier agent sẽ kiểm tra mã đó.
  • Workload – Đơn vị công việc do người dùng soạn thảo. Nó chứa ý định cấp cao (ví dụ: "thêm unit test cho module X"), một tham chiếu đến repository mục tiêu và danh sách các agent sẽ xử lý công việc đó.
  • AgenticTask – Nhiệm vụ cụ thể mà một Workload tạo ra. Khi công việc tiến triển, mỗi AgenticTask sẽ ghi lại các cập nhật trạng thái, cho phép người vận hành giám sát pipeline trong thời gian thực.
  • FleetNode – Một node Kubernetes thực sự chạy các tác vụ. Bộ lập lịch (scheduler) tích hợp sẵn sẽ khớp các AgenticTask đang chờ với các FleetNode có vai trò và tài nguyên yêu cầu.

Xác minh thay thế cho sự tin tưởng mù quáng

Foreman không mặc định rằng đầu ra của mô hình là chính xác. Khi một coder agent hoàn thành công việc, nó sẽ gửi một yêu cầu thay vì một kết quả cuối cùng. Một verifier — thường là một script có tính xác định (deterministic script), không phải một LLM khác — sẽ chạy mã qua các công cụ linter, unit test hoặc thực hiện build toàn bộ. Chỉ khi các bước kiểm tra này vượt qua, Foreman mới ghi nhánh (branch) mới trở lại repository.

Nếu verifier thất bại, tác vụ sẽ bị đánh dấu là bị từ chối và các thay đổi sẽ không bao giờ được áp dụng. Sự tách biệt này cho phép mô hình tạo ra mã một cách sáng tạo trong khi lưới an toàn vẫn hoàn toàn nằm dưới sự kiểm soát của con người.

Cài đặt stack trên một cụm (cluster)

  1. Triển khai LLMKube core chart bằng Helm.
  2. Triển khai Foreman chart, cũng thông qua Helm.
  3. Chuyển chế độ agent sang “native” để vòng lặp request-response thực sự được kích hoạt.
  4. Gán các vai trò (coder, verifier) cho các FleetNode sẽ đảm nhận công việc.

Cần có hai bộ thông tin xác thực: thông tin xác thực git để đọc các issue và push các branch, và thông tin xác thực mô hình để gọi một API được lưu trữ (hosted API) hoặc một dịch vụ suy luận tự lưu trữ (self-hosted inference service).

Các nút điều chỉnh chi phí và bảo mật mà bạn thực sự có thể can thiệp

Foreman cho phép người vận hành giới hạn quyền hạn của mô hình bằng cách loại bỏ các công cụ khỏi định nghĩa agent. Việc loại bỏ “bash” hoặc “write_file” sẽ ngăn mô hình thực thi các lệnh shell tùy ý hoặc ghi dữ liệu bên ngoài không gian làm việc được chỉ định.

Một giới hạn số lượt (turn limit) sẽ khống chế số lần gọi mô hình cho mỗi tác vụ, giúp kiểm soát chi phí trực tiếp. Việc điều chỉnh cửa sổ ngữ cảnh (context window) — lượng prompt mà mô hình nhìn thấy — sẽ giúp cắt giảm thêm việc sử dụng token. Khi mô hình chạy cục bộ trên phần cứng tại chỗ (on-prem), không có dữ liệu nào rời khỏi tổ chức, đáp ứng các chính sách bảo mật dữ liệu nghiêm ngặt.

Nơi nền tảng tỏa sáng và nơi nó vẫn còn vấp ngã

Foreman vượt trội trong các công việc mang tính máy móc và có phạm vi rõ ràng:

  • Sửa một lỗi (bug) đã được ghi nhận.
  • Thêm các trường hợp kiểm thử (test cases) còn thiếu.
  • Cập nhật tài liệu để rõ ràng hơn hoặc theo đúng phong cách.

Những tác vụ này có tiêu chí thành công rõ ràng mà một verifier có thể kiểm tra tự động. Hệ thống vẫn còn gặp khó khăn với các thiết kế lại kiến trúc cấp cao hoặc các công việc tính năng mơ hồ, nơi mà “tính chính xác” phụ thuộc vào sự phán đoán của con người.

Kết luận

Bằng cách coi các coder điều khiển bởi LLM là các tài nguyên Kubernetes hạng nhất (first-class resources) và thực thi một bước xác minh có tính xác định, Foreman cung cấp một lộ trình thực tế để tạo mã AI trong môi trường production, giúp chi phí luôn minh bạch và bảo mật luôn được kiểm soát. Đây không phải là "viên đạn bạc" cho mọi công việc phát triển, nhưng đối với các tác vụ có thể lặp lại và có thể kiểm thử, nó cung cấp một quy trình làm việc có thể kiểm chứng, phù hợp một cách tự nhiên vào các hoạt động cloud-native hiện có.