AI agents ใน production คืออะไร และทำไมถึง “พัง” แบบไม่เหมือนเว็บแอป
AI agents ใน production deployment คือระบบซอฟต์แวร์ที่ใช้โมเดลภาษาและเครื่องมือหลายชนิดในการตัดสินใจและลงมือทำงานอย่างอัตโนมัติ โดยไม่ต้องมีการเรียกจากผู้ใช้ทุกครั้ง ตัว agent สามารถประเมินงาน หยิบข้อมูลจากระบบอื่น วางแผน และเขียนหรือรันโค้ดเอง ทำให้มีศักยภาพสูงแต่ก็มีพื้นที่ความเสี่ยงกว้างกว่าซอฟต์แวร์ทั่วไป เพราะการตัดสินใจผิดเพียงครั้งเดียวอาจลุกลามเป็นชุดข้อผิดพลาดต่อเนื่องที่ยากต่อการย้อนกลับ ผู้พัฒนามักเข้าใจผิดว่า AI agents คือเว็บแอปที่แค่เรียก LLM แล้ววางไว้หลัง load balancer แต่ประสบการณ์จริงในระบบ production แสดงให้เห็นว่าภาพแบบนั้นอยู่ได้เพียงสัปดาห์เดียวก่อนจะเกิด incident ที่ไม่เข้ากับคู่มือปฏิบัติการของเว็บแอปแบบเดิม ระบบเหล่านี้ไม่ได้รอ request แต่มี heartbeat หรือ cron ภายในที่ปลุกงานขึ้นมาเอง ทำงานกับฐานข้อมูล vector store และ API ภายนอกโดยไม่ต้องมีผู้ใช้กดปุ่ม

เมื่อซอฟต์แวร์คิดเอง การประกันคุณภาพต้องเริ่มที่บริบท การประเมิน และการสังเกตการณ์
โลกของ software quality assurance กำลังถูกเขย่าโดยความเร็วของ AI ในการสร้างโค้ด เพราะแม้โค้ดจะถูกผลิตได้เร็วขึ้นมาก แต่ความเชื่อมั่นต่อสิ่งที่ถูก deploy กลับไม่ได้โตตามนั้นเลย งานวิจัยหนึ่งสำรวจวิศวกรและผู้นำทีมกว่า 1,100 คน พบว่า 94% ขององค์กรใช้ AI อยู่แล้ว แต่ส่วนใหญ่ยังใช้แค่เป็นเครื่องมือรายคน เช่นช่วยเขียนโค้ดหรือดีบัก'94% ของผู้นำฝ่ายวิศวกรรมบอกว่าองค์กรของตนใช้ AI อยู่ในบางรูปแบบ แต่ส่วนใหญ่ยังใช้เพื่อรองรับงานรายบุคคล เช่นการเขียนโค้ด ดีบัก และทำเอกสาร' ผลคือปริมาณโค้ดเพิ่ม แต่คอขวดก่อนและหลังการ implement กลับตึงขึ้น เมื่อ AI agents ตัดสินใจเองแบบมี state ต่อเนื่อง การประกันคุณภาพจึงต้องขยับจากการเทสฟังก์ชันแยกส่วน ไปสู่กรอบการประเมินทั้ง flow การมีระบบสังเกตการณ์และ incident triage ที่เข้าใจบริบทการตัดสินใจของ agent ตั้งแต่ต้นจนจบ ทีมที่ยังไม่มีระบบกำกับงานวิศวกรรมสำหรับ AI กำลังทำให้โค้ดเร็วแต่ไม่สามารถพิสูจน์ได้ว่าควรปล่อยงานเหล่านั้นสู่ผู้ใช้หรือไม่
การติดตาม การตรวจจับความผิดพลาด และ feature flags ต้องฝังในสถาปัตยกรรมตั้งแต่วันออกแบบ
AI agents ใน production ไม่ใช่บริการ stateless ที่ kill แล้ว spawn ใหม่ได้โดยไม่เสียอะไร เพราะหลายเฟรมเวิร์กทำงานเป็น gateway ที่มี state ของการตัดสินใจและประวัติการใช้เครื่องมืออย่างต่อเนื่อง การรีสตาร์ตโดยไม่คิดจึงอาจทำลายคุณภาพงานและสร้างพฤติกรรมผิดซ้ำ แนวคิดของ failure detection systems สำหรับ agents จึงต้องเน้น trace การตัดสินใจ ไม่ใช่แค่ status ว่าระบบยัง “ขึ้น” อยู่หรือเปล่า เพราะคำถามหลัง incident มักเป็นว่า “ทำไมมันตัดสินใจแบบนั้น” มากกว่าจะเป็น “เซอร์วิสล่มหรือไม่” การออกแบบที่ดีต้องมีการ tracing ตลอดเวลา log แบบอ่านง่าย และระบบประเมินผลที่วัดทั้งผลลัพธ์และเส้นทางที่ agent ใช้ รวมถึงใช้ feature flags และการแบ่งสิทธิ์เขียนข้อมูลเพื่อกันผลกระทบ เมื่อมีข้อผิดพลาด สามารถปิดฟีเจอร์เฉพาะหรือย้อน state ได้อย่างปลอดภัย แทนที่จะปล่อยให้ agent เขียนทุกอย่างลงระบบจริงโดยไม่มีเบรก

จากคำอธิบายยาวเป็นตัวกฎที่บังคับได้: code governance tools สำหรับยุค AI agents
ประสบการณ์ของผู้ที่รัน AI agents บนระบบที่มี endpoint ราว 1,000 จุดมาแล้วกว่าปีแสดงภาพชัดว่า การให้ agent อ่านกติกาเป็นพันบรรทัดไม่ใช่คำตอบ เขาเริ่มจากเขียน feedback เป็นกฎในเอกสาร และกฎเหล่านั้นขยายจนกลายเป็น 18 ไฟล์ยาวรวมกว่า 5,000 บรรทัด แต่เมื่อให้ agent สร้างฟีเจอร์ CRUD ง่าย ๆ ที่มีตัวอย่างอยู่เต็มโค้ดเบส ผลงานกลับออกมาเหมือนงานของทีมจูเนียร์ที่ต่างคนต่างคิด กติกาไม่ถูกใช้ โครงสร้าง endpoint ผิด ธีม UI ไม่ตรง และโค้ดเต็มไปด้วยทางลัดที่ใช้ต่อไม่ได้ ทางออกจึงไม่ใช่เพิ่มคำอธิบาย แต่แปลงกฎสำคัญให้เป็น code governance tools ที่บังคับได้จริง ตั้งแต่ test ที่เขียนก่อนงานและต้องผ่านเพื่อถือว่าเสร็จ ไปจนถึงการกำหนด exit code ให้ผิดแล้วหยุดงาน การแบ่ง write partition ตามบทบาท และการออกแบบโมดูลให้สถานะที่ไม่ถูกต้อง “แทนไม่ได้” ในการคอมไพล์ แก่นคือย้ายจากคำพูดให้ agent “น่าจะทำถูก” ไปสู่โครงสร้างที่ทำให้มันทำผิดไม่ได้ตั้งแต่ระดับ build
จากการใช้เครื่องมือรายคนสู่กระบวนการส่งมอบซอฟต์แวร์แบบ AI-native
ผลสำรวจวิศวกรชี้ว่าผู้นำทีม 88% เชื่อว่าต้องมีระบบงานวิศวกรรมที่ถูกกำกับสำหรับ AI แต่มีเพียง 19% ที่สร้างขึ้นมาแล้ว ช่องว่างนี้สะท้อนว่าทีมส่วนใหญ่ยังติดอยู่กับการใช้ AI เป็นเครื่องมือรายคน ไม่ใช่ส่วนหนึ่งของกระบวนการส่งมอบซอฟต์แวร์แบบใหม่ที่ออกแบบมาสำหรับ agent โดยเฉพาะ เมื่อ AI ช่วยบีบเวลาในการเขียนโค้ด งานก่อนและหลังโค้ดจึงยิ่งสำคัญขึ้น ไม่ว่าจะเป็นการแตกงาน การจัดลำดับความพร้อม การรีวิว การทดสอบ และการสังเกตการณ์ใน production ทีมที่ต้องการใช้ AI agents production deployment อย่างปลอดภัยต้องกำหนดเจ้าของระบบ agent ให้ชัด สร้างช่องทาง observability ที่บอกได้ว่า agent ไหนกำลังทำอะไร ใช้บริบทใด ติดขัดตรงไหน และตัดสินใจเรื่องใหญ่บนหลักฐานอะไร เมื่อมีกรอบการกำกับที่ดี บวกกับ failure detection systems และ code governance tools ที่เข้มแข็ง การใช้ agents จะเปลี่ยนจากความเสี่ยงที่สร้าง incident แปลก ๆ ให้ผู้ใช้เดือดร้อน ไปเป็นโครงสร้างที่เพิ่มความสามารถทีมโดยยังรักษาความเชื่อมั่นของระบบได้


