Foreman เปลี่ยน LLM agents ให้กลายเป็น Kubernetes resources แบบ native ช่วยให้ทีมสามารถรันโค้ดที่สร้างโดย AI ในสภาพแวดล้อม production ได้ โดยที่ยังสามารถควบคุมค่าใช้จ่ายและความปลอดภัยได้อย่างเข้มงวด

แนวคิดนี้เข้ากับเวิร์กโฟลว์การพัฒนาในปัจจุบันอย่างไร

องค์กรต่าง ๆ เริ่มทดลองใช้ LLM ที่สามารถเขียนโค้ดได้ แต่การนำไปใช้งานส่วนใหญ่มักจะมองว่าโมเดลเป็น "กล่องดำ" (black box) ที่เชื่อถือได้ เพียงแค่สัญญาณ "เสร็จสิ้น" (done) ครั้งเดียวจากโมเดล ก็อาจทำให้การเปลี่ยนแปลงที่ยังไม่ได้ผ่านการทดสอบถูกผลักเข้าไปใน repository โดยตรง ซึ่งก่อให้เกิดความกังวลด้านความปลอดภัยและความน่าเชื่อถือ ในขณะเดียวกัน การรันบริการ AI บนคลาวด์อาจทำให้ค่าใช้จ่ายพุ่งสูงขึ้นอย่างรวดเร็ว โดยเฉพาะเมื่อมีการเรียกใช้โมเดลเดิมซ้ำ ๆ จาก CI pipelines

คำตอบของ Foreman คือการฝังวงจรการเขียนโค้ด (coding loop) ทั้งหมดไว้ภายใน Kubernetes cluster โดย Foreman จะทำงานในรูปแบบของ Kubernetes resources

วัตถุหลัก 4 อย่างที่ทำให้สิ่งนี้เกิดขึ้นได้

  • Agent – กำหนดตัวทำงาน (worker) โดยระบุชื่อ LLM ที่ต้องเรียกใช้ รายการเครื่องมือ (tools) ที่โมเดลสามารถเรียกใช้งานได้ (เช่น file-write หรือ git-push) และกำหนดงบประมาณ (budget) เพื่อจำกัดจำนวนการเรียกใช้โมเดล นอกจากนี้ยังสามารถกำหนดบทบาท (roles) ได้ที่นี่ เช่น coder agent สำหรับเขียนโค้ด และ verifier agent สำหรับตรวจสอบโค้ด
  • Workload – หน่วยงานที่ผู้ใช้กำหนดขึ้น โดยจะระบุความต้องการในระดับสูง (เช่น “add unit tests for module X”) อ้างอิงไปยัง repository เป้าหมาย และรายการของ agent ที่ควรจะจัดการงานนั้น
  • AgenticTask – งานที่เป็นรูปธรรมซึ่งถูกสร้างขึ้นโดย Workload เมื่อการทำงานดำเนินไป AgenticTask แต่ละรายการจะบันทึกการอัปเดตสถานะ ช่วยให้ผู้ดูแลระบบสามารถตรวจสอบ pipeline ได้แบบเรียลไทม์
  • FleetNode – Kubernetes node ที่ทำหน้าที่รันงานจริง ๆ โดย scheduler ที่ติดตั้งมาในตัวจะจับคู่ AgenticTasks ที่ค้างอยู่กับ FleetNodes ที่มีบทบาทและทรัพยากรที่ต้องการ

การตรวจสอบเข้ามาแทนที่ความเชื่อใจอย่างไร้เงื่อนไข

Foreman ไม่ได้สมมติว่าผลลัพธ์จากโมเดลนั้นถูกต้องเสมอไป เมื่อ coder agent ทำงานเสร็จ มันจะส่งคำขอ (request) แทนที่จะส่งผลลัพธ์สุดท้าย โดยจะมี verifier ซึ่งมักจะเป็นสคริปต์แบบ deterministic (ไม่ใช่ LLM อีกตัว) ทำหน้าที่รันโค้ดผ่าน linters, unit tests หรือการ build แบบเต็มรูปแบบ Foreman จะเขียน branch ใหม่กลับไปยัง repository ก็ต่อเมื่อการตรวจสอบเหล่านั้นผ่านเท่านั้น

หาก verifier ไม่ผ่าน งานจะถูกทำเครื่องหมายว่าถูกปฏิเสธ (rejected) และการเปลี่ยนแปลงนั้นจะไม่ถูกนำไปใช้ การแยกส่วนแบบนี้ช่วยให้โมเดลสามารถสร้างสรรค์ผลงานได้อย่างเต็มที่ ในขณะที่ตาข่ายรองรับความปลอดภัย (safety net) ยังคงอยู่ภายใต้การควบคุมของมนุษย์อย่างสมบูรณ์

การติดตั้ง stack บน cluster

  1. ติดตั้ง LLMKube core chart ด้วย Helm
  2. ติดตั้ง Foreman chart ผ่าน Helm เช่นกัน
  3. เปลี่ยนโหมด agent เป็น “native” เพื่อให้วงจร request-response จริงเริ่มทำงาน
  4. กำหนดบทบาท (coder, verifier) ให้กับ FleetNodes ที่จะรองรับงาน

จำเป็นต้องใช้ชุดข้อมูลรับรอง (credentials) สองชุด ได้แก่ git credentials สำหรับการอ่าน issues และการ push branches และ model credentials สำหรับการเรียกใช้ไม่ว่าจะเป็น hosted API หรือบริการ inference ที่ติดตั้งเอง (self-hosted)

ปุ่มปรับแต่งค่าใช้จ่ายและความปลอดภัยที่คุณควบคุมได้จริง

Foreman ช่วยให้ผู้ดูแลระบบสามารถจำกัดอำนาจของโมเดลได้โดยการตัดเครื่องมือบางอย่างออกจากคำจำกัดความของ agent การลบ bash หรือ write_file ออก จะช่วยหยุดไม่ให้โมเดลรันคำสั่ง shell ตามอำเภอใจหรือเขียนไฟล์นอกพื้นที่ทำงานที่กำหนดไว้

การกำหนดขีดจำกัดการทำงาน (turn limit) จะช่วยจำกัดจำนวนการเรียกใช้โมเดลต่อหนึ่งงาน ซึ่งเป็นการควบคุมค่าใช้จ่ายโดยตรง การปรับขนาด context window (ปริมาณ prompt ที่โมเดลมองเห็น) จะช่วยลดการใช้ token ลงไปอีก และเมื่อโมเดลรันแบบ local บนฮาร์ดแวร์ในองค์กร (on-prem) ข้อมูลก็จะไม่หลุดออกจากองค์กร ซึ่งตอบโจทย์นโยบายความเป็นส่วนตัวของข้อมูลที่เข้มงวด

จุดเด่นของแพลตฟอร์ม และจุดที่ยังเป็นข้อจำกัด

Foreman ทำงานได้ดีเยี่ยมในงานที่เป็นเชิงกล (mechanical) และมีขอบเขตที่ชัดเจน:

  • การแก้ไข bug ที่มีการระบุไว้ในเอกสาร
  • การเพิ่ม test cases ที่ขาดหายไป
  • การอัปเดตเอกสารเพื่อให้ชัดเจนหรือตรงตามรูปแบบ (style)

งานเหล่านี้มีเกณฑ์ความสำเร็จที่ชัดเจนซึ่ง verifier สามารถตรวจสอบได้โดยอัตโนมัติ อย่างไรก็ตาม ระบบยังคงมีปัญหาในงานออกแบบสถาปัตยกรรมระดับสูง (architectural redesigns) หรือการพัฒนาฟีเจอร์ที่คลุมเครือ ซึ่ง "ความถูกต้อง" ต้องอาศัยการตัดสินใจของมนุษย์

บทสรุป

ด้วยการปฏิบัติกับ coder ที่ขับเคลื่อนด้วย LLM ในฐานะ Kubernetes resources ชั้นหนึ่ง (first-class resources) และการบังคับใช้ขั้นตอนการตรวจสอบแบบ deterministic Foreman จึงมอบแนวทางที่ใช้งานได้จริงสำหรับการสร้างโค้ดด้วย AI ในระดับ production ที่สามารถควบคุมค่าใช้จ่ายให้มองเห็นได้และรักษาความปลอดภัยให้อยู่ภายใต้การควบคุม แม้จะไม่ใช่ "กระสุนเงิน" (silver bullet) สำหรับงานพัฒนาทั้งหมด แต่สำหรับงานที่ทำซ้ำได้และทดสอบได้ Foreman มอบเวิร์กโฟลว์ที่ตรวจสอบได้ (auditable) ซึ่งเข้ากับปฏิบัติการ cloud-native ที่มีอยู่เดิมได้อย่างเป็นธรรมชาติ