AI Agent ที่ใช้การได้ใน 75 นาที คืออะไร และยังไม่พออย่างไร
AI agent ในบริบทนี้คือระบบแชตบอตหรือโปรแกรมที่ใช้โมเดลภาษา รับคำขอจากผู้ใช้ ตัดสินใจว่าต้องทำอะไร เลือกเครื่องมือหรือ API ที่เกี่ยวข้อง แล้วลงมือทำงานให้เสร็จแบบกึ่งอัตโนมัติ โดยใช้เครื่องมือและเฟรมเวิร์กยุคใหม่เราสามารถสร้างต้นแบบให้ทำงานได้ภายในเวลาประมาณเจ็ดสิบห้านาที ตั้งแต่ส่วนติดต่อผู้ใช้ แดชบอร์ด การเรียกใช้เครื่องมือ ไปจนถึงให้โมเดลวางแผนและดำเนินงานเองได้
สิ่งที่หลายทีมมองข้ามคือ AI agent ที่สร้างเร็วขนาดนั้นมักยังไม่มีการควบคุม ไม่มีขอบเขต ไม่มีจุดให้คนหยุดอนุมัติ และไม่มีหลักฐานว่าใครทำอะไรไว้เลย มันเหมือนมังกรที่ฝึกให้บินแต่ยังไม่ได้ใส่กรงหรือสายจูง เมื่อยังเป็นแค่ต้นแบบ เราอาจกล้าเปิดให้เพื่อนร่วมทีมเล่น แต่การทำ AI agent deployment ให้กลายเป็น production-ready chatbot สำหรับลูกค้า ต้องเพิ่มชั้นการกำกับดูแล การทดสอบความปลอดภัย และระบบเฝ้าระวัง ซึ่งใช้เวลาอย่างน้อยอีกหนึ่งสัปดาห์และยังต้องดูแลต่อเนื่อง
สิ่งที่ต้องมี ก่อนพา AI Agent ขึ้นโปรดักชัน
ก่อนคิดถึงฟีเจอร์ใหม่ สิ่งสำคัญคือโครง AI governance setup ให้ชัด ว่าระบบจะถูกตรวจสอบ ย้อนรอย และหยุดได้เมื่อไหร่ ไม่ใช่ปล่อยให้เอเจนต์ทำทุกอย่างที่ทำได้โดยไม่มีกรอบ ข้อดีคือเราสามารถใช้กรอบคิดจากมาตรฐานอย่างกฎหมายด้าน AI ที่เน้นเรื่องการตรวจสอบย้อนหลัง การเก็บบันทึก และการมีมนุษย์กำกับ มาประกอบการออกแบบได้ตั้งแต่วันแรก ซึ่งแหล่งอ้างอิงหนึ่งสร้างขอบเขตของเอเจนต์โดยเทียบกับข้อกำหนดของ EU AI Act แม้ระบบของเขาจะไม่จัดอยู่ในกลุ่มเสี่ยงสูงก็ตาม
สิ่งที่ควรมีอย่างน้อย ได้แก่ การทำ logging ให้ทุกการกระทำของระบบมีบันทึกที่อยู่เกินกว่าหนึ่งเซสชัน การทำ attribution ให้แยกออกว่าการเปลี่ยนแปลงใดมาจากคนหรือจากโมเดล เพราะถ้าตอบไม่ได้บันทึกเหล่านั้นเป็นแค่ตัวเลขนับ ไม่ใช่เส้นทางตรวจสอบ ต้องมี explicit intervention points คือจุดที่ระบบหยุดรอคนตัดสินใจ แม้เทคนิคจะทำต่อได้ และกำหนด boundaries ว่าเอเจนต์แตะต้องได้แต่ระบบ ตารางข้อมูล และประเภทคำสั่งใด หากคำขอเกินขอบเขตต้องนิยามให้ชัดว่าจะจัดการอย่างไร
ขั้นตอนจาก 75 นาทีสู่หนึ่งสัปดาห์ วิธีตั้งสายพานความปลอดภัย
การทำให้ AI agent deployment ไปถึงระดับ production-ready chatbot ไม่ใช่เรื่องการเขียนโค้ดเพิ่มเป็นหลัก แต่มาจากการจัดสภาพแวดล้อมให้ควบคุมได้ ข้อสำคัญคือยอมรับว่าระยะเวลาจะกลับด้านจากที่เราคุ้นเคย งานโชว์ผลลัพธ์ใช้เวลาหลักชั่วโมง แต่งานกำกับดูแลและ agent safety testing กินเวลาหลักสัปดาห์และต่อเนื่อง เพราะต้องลองใส่ข้อจำกัด แล้วดูว่ามันตีความข้อจำกัดนั้นอย่างไร แหล่งอ้างอิงหนึ่งเล่าว่าแต่ละรอบของการทดลองกฎใหม่ ทำให้เห็นช่องว่างระหว่างข้อกำหนดที่คนเขียน กับข้อจำกัดที่โมเดลตีความ และช่องว่างนั้นกว้างกว่าที่คิดเสมอ
- เริ่มจากทำต้นแบบให้ใช้การได้ภายในเวลาไม่เกินเจ็ดสิบห้านาที เน้นให้เอเจนต์รับคำขอ เลือกเครื่องมือ และทำงานจบได้ครบลูป โดยยังไม่ต้องสนใจระบบกำกับที่ซับซ้อนนัก
- เพิ่มระบบ logging และ attribution ให้ทุกการเรียก API การแก้ไขข้อมูล และการตอบกลับผู้ใช้ถูกบันทึก พร้อมระบุได้ชัดว่าใครหรืออะไรเป็นผู้กระทำ เพื่อเตรียมเป็น audit trail ที่ตรวจสอบย้อนหลังได้
- ออกแบบ explicit intervention points เช่น การขออนุมัติเมื่อมีการเขียนข้อมูลสำคัญ การเชื่อมต่อระบบภายนอก หรือการรันคำสั่งที่กระทบผู้ใช้จริง ให้เอเจนต์หยุดรอมนุษย์ แม้จะมีความสามารถทำต่อเองได้
- กำหนด boundaries เชิงเทคนิคและธุรกิจ เช่น เอเจนต์จะเข้าถึงเฉพาะฐานข้อมูล ตาราง หรือชุด API ที่อนุญาตไว้เท่านั้น และนิยามพฤติกรรมเมื่อคำขออยู่นอกขอบเขต เช่น ปฏิเสธ แจ้งเตือน หรือส่งต่อให้คนจัดการ
- ทำ agent safety testing เป็นรอบๆ โดยลองให้เอเจนต์ทำงานภายใต้กฎที่กำหนดทั้งกรณีปกติและกรณีเบี่ยงเบน แล้วดูผลลัพธ์ว่าเคารพขอบเขตหรือไม่ ปรับกฎที่หลวมจนเอเจนต์ทำสิ่งที่ไม่คาดคิด หรือเข้มเกินจนปฏิเสธงานที่คนยังมองว่าโอเค ซึ่งเป็นสองข้อผิดพลาดที่เกิดขึ้นบ่อยในงานลักษณะนี้
ควรเตรียมใจว่ารอบการทดสอบเหล่านี้จะไม่สิ้นสุดง่ายๆ แม้ผู้เขียนต้นทางจะบอกว่าใช้เวลาหนึ่งสัปดาห์เพื่อทำให้ระบบปลอดภัยขึ้น แต่ก็ยังไม่เสร็จ และอธิบายว่า สิ่งที่แยกระบบที่เอาไปให้ลูกค้าใช้ได้ ออกจากระบบที่เปิดให้เพื่อนร่วมงานใช้กันเอง คือส่วนที่ใช้เวลาทั้งสัปดาห์ และยังต้องใช้เวลาอีกต่อไป
ออกแบบทีมใหม่ให้ดูการตัดสินใจของ AI แทนการดูโค้ดอย่างเดียว
เมื่อ AI กลายเป็นคนเขียนโค้ดหลัก งานของทีมต้องขยับจากการตรวจโค้ดไปสู่การดูตรรกะและการตัดสินใจของเอเจนต์ ในแนวทาง mob programming แบบใหม่ AI จะนั่งในตำแหน่ง driver แทนคน แต่ทีมยังอยู่หน้าจอเดียวกัน ช่วยกันตั้งโจทย์ ส่งงานให้เอเจนต์ แล้วดูไปพร้อมกันว่ามันเลือกวิธีไหน หลังจบจึงคุยกันว่าทำไมถึงเลือกแบบนั้น มีวิธีอื่นหรือไม่ และสิ่งนี้สอนอะไรกับสมาชิกที่อาวุโสน้อยกว่า
แนวทางนี้ทำให้ประสบการณ์การสอนงานกลับมา เพราะคนที่เพิ่งเริ่มต้นไม่ต้องนั่งอ่านโค้ดจากเอเจนต์เงียบๆ แต่ได้ดูสดๆ ว่ารุ่นพี่ตั้งคำถามกับโค้ดเหล่านั้นอย่างไร แทนที่ทีมจะหมดไฟกับการรีวิวโค้ดจำนวนมาก โดยเฉพาะเมื่อข้อมูลวิจัยบางชุดพบว่าคนสามารถรีวิวโค้ดได้อย่างมีความหมายราวสี่ร้อยบรรทัดต่อชั่วโมงและจะเริ่มล้าหลังจากหนึ่งชั่วโมง เมื่อเอเจนต์สร้างงานเพิ่มขึ้น การย้ายโฟกัสไปที่คุณภาพของการตัดสินใจและการกำกับดูแล แทนที่จะพยายามรีวิวทุกบรรทัด จึงเป็นทางออกที่สอดคล้องกับขีดจำกัดทางความคิดของมนุษย์
ใช้เอเจนต์หลายตัวแบบขนานให้คุ้ม โดยไม่จมในความวุ่นวาย
เพื่อแก้ปัญหาช่วงรอเอเจนต์ตอบ นักพัฒนาหลายคนเปลี่ยนมาทำงานแบบขนาน เปิดหลายเอเจนต์ที่ทำงานแบบ asynchronous แต่ละตัวมี context window ของตัวเอง มีขอบเขตไฟล์และความรับผิดชอบชัด ใช้เทคนิคอย่าง git worktrees เพื่อให้แต่ละเอเจนต์ทำงานบนบราน์ชแยกกัน ลดการเหยียบเท้ากันเอง แนวคิดนี้ช่วยเปลี่ยนเวลารอให้กลายเป็นเวลาบริหารงานอื่น เช่น ระหว่างที่เอเจนต์หนึ่งรีแฟกเตอร์โค้ด อีกตัวเขียนเทสต์ไปพร้อมกัน
อย่างไรก็ตาม การวิ่งเอเจนต์ขนานกันก็มีกับดัก เมื่อจำนวนเอเจนต์เกินสามหรือสี่ตัว มันจะเริ่มไม่ชัดว่ารีวิวไหนเป็นของงานใด งานไหนเป็นของนักพัฒนาคนไหน จน diff ไม่มีเจ้าของที่แท้จริง การรีวิวกลายเป็นแค่พิธีอนุมัติไม่ใช่การตรวจจริง ตรงนี้คือหนึ่งในข้อผิดพลาดหลักของทีมสายเอเจนต์ เพราะคิดแต่เรื่องเพิ่มความเร็วโดยไม่ออกแบบการประสานงานและกลไกความปลอดภัยเพิ่ม งานจริงๆ ของ AI agent deployment ในยุคนี้จึงไม่ได้อยู่ที่การสร้างเอเจนต์ให้ทำอะไรแปลกใหม่ แต่คือการควบคุมให้มันทำเฉพาะสิ่งที่เราขอ และไม่ทำเกินนั้น ซึ่งเป็นงานกำกับและทดสอบมากกว่างานพัฒนา
บทเรียนที่สำคัญคือ การมีเอเจนต์หลายตัวเป็นเรื่องดีเมื่อทีมยังสามารถผูกงานแต่ละชิ้นเข้ากับคนรับผิดชอบ มีขั้นตอนรีวิวจริง และมีสายการตรวจสอบจาก log และ attribution ที่ชัดเจน แหล่งอ้างอิงหนึ่งสรุปไว้ว่าการทำให้เอเจนต์ทำงานน่าประทับใจเป็นเรื่องของสุดสัปดาห์ แต่การทำให้มันทำในสิ่งที่เราขอ และไม่ทำอย่างอื่น คือส่วนที่กินเวลาทั้งสัปดาห์และไม่เคยจบ
