สั่งงาน agent ตัวหนึ่งไปหลายรอบ ตลอดสามวัน ไม่ได้ของกลับมาเลยสักชิ้น
พอถามซ้ำ คำตอบที่ได้คือความเงียบ งานไม่มาถึงมือ ไม่มีใครบอกว่าติดอะไร เหมือนคำสั่งหายเข้าไปในระบบแล้วไม่กลับมาอีก
โพสต์นี้เกี่ยวกับ AI agent guardrails ไม่ใช่ content filter ที่คอยบล็อกคำตอบ แต่เป็นชั้นของระบบที่รับประกันว่าพฤติกรรมสำคัญจะเกิดขึ้นจริงทุกครั้งที่ agent ทำงาน
คืนนั้นเลยไล่ log ทั้งฝูงย้อนหลังสามวัน แล้วเจอตัวเลขชุดหนึ่ง: ช่วงเวลานั้นเหล่า agent ปฏิเสธงานที่ต้องเขียนไฟล์ 15 ครั้ง แต่รันงานแบบเต็มรูปแบบจริงแค่ 10 ครั้ง และใน 10 ครั้งนั้น 8 ครั้งมาจาก agent ตัวเดียว
ทั้งฝูงมี 9 ตัว แต่ agent ที่ทำงานได้ครบจริงๆ มีแค่ตัวเดียว ที่เหลืออีก 8 ตัว งานไม่ถึงมือเหมือนกันหมดตลอดสามวัน
ตอนแรกนึกว่าตัวนั้นตั้งค่าดีกว่า หรือ prompt ดีกว่า พอเปิดไฟล์ตั้งค่าของทุกตัวเทียบกันทีละไฟล์ ความจริงก็ธรรมดากว่านั้นมาก และน่าเจ็บใจกว่า
ในตัวที่ทำถูก มีบรรทัดหนึ่งที่ตัวอื่นไม่มี บรรทัดที่สอนว่า "ถ้าติดสิทธิ์ ให้ส่งคำขอ approve ไปที่ coordinator"
อีกแปดตัวไม่มีบรรทัดนั้น พอติดสิทธิ์ก็ตอบปฏิเสธในห้องของตัวเอง ห้องที่ไม่มีใครอ่าน ทุกฝ่ายคิดว่าอีกฝ่ายถืองานอยู่ งานเลยตายเงียบทั้งฝูงมาสามวัน
ที่ร้ายคือสามวันนั้นระบบไม่ได้แสดง error เลย ทุกตัวทำงาน "ถูก" ตามมุมมองของตัวเอง ปฏิเสธตาม protocol แจ้งตามช่องทางที่มี ไม่มีอะไรพังให้เห็น มีแต่งานที่ไม่เคยถึงมือคนสั่ง และไม่มีใครตอบได้ว่ามันหายไปไหน
Productize.life บันทึกกรณีนี้จากงานจริง session คืนวันที่ 2 ต่อเช้าวันที่ 3 สิงหาคม 2026: ไล่ log ทั้งฝูงจนเจอ root cause ยกกฎขึ้นเป็น gate ส่วนกลาง แล้วพิสูจน์ด้วย drill จริง ตัวเลขทุกตัวในโพสต์นี้มาจาก log จริง และถูก scrub ชื่อ ห้อง และโครงสร้างภายในออกแล้ว เหลือเฉพาะ principle
ช่วงที่ 1จุดเริ่มต้นที่ใครก็เริ่ม: เขียนกฎลง prompt
ใครก็ตามที่รัน AI agent หลายตัวจะเริ่มด้วยวิธีเดียวกัน อยากให้ agent มีพฤติกรรมแบบไหน ก็เขียนกฎนั้นลง prompt ของมัน จะเรียก charter ก็ดี system instruction ก็ดี วิธีนี้เร็ว ตรงไปตรงมา และไม่ต้องเขียนโค้ดเลย
คำแนะนำเรื่อง AI agent ที่มีอยู่เต็มตลาดก็ชี้ไปทางเดียวกัน เขียน prompt ให้ดี เขียนกฎให้ชัด บอกมันให้ครบทุกข้อ คำแนะนำนี้จริงสำหรับ agent ตัวเดียว แต่พอมีมากกว่าหนึ่งตัว มันเริ่มไม่พอ และส่วนที่ขาดไม่ใช่คุณภาพของข้อความที่เขียน
ถ้ามี agent ตัวเดียว วิธีนี้พอใช้ ลืมก็เตือนได้ พฤติกรรม drift ก็แก้ prompt ใหม่ได้ตรงนั้น
พอมีสองตัว สามตัว เก้าตัว วิธีเดียวกันก็เริ่มเผยข้อจำกัด กฎสำคัญข้อหนึ่งต้อง copy ไปวางในเก้าไฟล์ Agent ตัวใหม่เข้ามาก็ต้องไม่ลืมถ่ายทอด ตัวเก่าที่เคยแก้ setting ก็ต้องตามเช็คว่ากฎยังอยู่ ทุกครั้งที่กฎเปลี่ยนต้อง sync เก้าจุด และไม่มีทางรู้แน่เลยว่าเก้าจุดนั้นตรงกันจริงหรือเปล่า
และกฎก็ไม่ได้มีข้อเดียว ยิ่งฝูงโต กฎที่ต้องถือร่วมกันยิ่งเพิ่ม ทุกข้อต้องคูณด้วยเก้าไฟล์ และทุกไฟล์อัปเดตไม่พร้อมกัน บางตัวถือกฎเวอร์ชันใหม่ บางตัวยังถือเวอร์ชันเก่า โดยไม่มีใครตอบได้ว่าตัวไหนถืออะไรอยู่
แต่ข้อจำกัดพวกนั้นยังเป็นแค่ผิว ปัญหาที่ลึกกว่าอยู่อีกชั้นหนึ่ง
ช่วงที่ 2prompt คือความจำ ไม่ใช่กลไก
มีประโยคหนึ่งที่ได้จากคืนนั้น แล้วน่าจะใช้ได้กับทุกระบบที่มี AI หลายตัวทำงานร่วมกัน: prompt คือความจำ ไม่ใช่กลไก
ความจำคือสิ่งที่ agent นึกได้ บางครั้งนึกได้ บางครั้งนึกไม่ออก และถึงนึกได้ จะทำตามหรือเปล่าก็เป็นอีกเรื่อง ส่วนกลไกคือสิ่งที่ทำงานเหมือนกันทุกครั้ง ไม่ว่า agent จะนึกอะไรออกหรือไม่ออกก็ตาม
กฎที่ "ควรทำตาม" ซึ่งวางอยู่ใน prompt ล้วนๆ กำลังพึ่งสามชั้นพร้อมกันทุกครั้งที่งานวิ่งผ่าน: agent ต้องอ่านบรรทัดนั้นออก ต้องนึกมันออกในตอนที่ต้องใช้ แล้วต้องเลือกทำตามด้วย ชั้นใดชั้นหนึ่งหลุด กฎนั้นก็ไม่เกิด และไม่มีใครรู้ด้วยว่ามันไม่เกิด
agent แปดตัวในคืนนั้นไม่ได้พลาดที่ไม่ยอมทำตามกฎ พวกมันพลาดก่อนหน้านั้น ตั้งแต่ชั้นแรกสุด: ไม่มีโอกาสได้อ่านมันด้วยซ้ำ เพราะบรรทัดนั้นไม่เคยอยู่ในไฟล์ของพวกมันตั้งแต่แรก
อะไรคือสัญญาณว่ากฎถูกวางผิดชั้น?
ตัวเลขจากคืนนั้นทำให้เห็นภาพนี้ชัด: agent ตัวเดียวที่ทำถูกสม่ำเสมอ ท่ามกลางตัวอื่นที่พลาดแบบเดียวกันหมด คือสัญญาณว่าพฤติกรรมนั้นวางอยู่ผิดชั้น
ไม่ใช่เพราะตัวนั้นเก่งกว่า แต่เพราะกฎที่มันทำตามวางอยู่ในความจำของมันเพียงตัวเดียว ในขณะที่อีกแปดตัวไม่มี ถ้ากฎข้อนั้นสำคัญพอที่ระบบจะขาดมันไม่ได้ การที่มี agent แค่ตัวเดียวทำตามได้ คือหลักฐานว่ามันวางผิดที่
ถ้าถูกที่ ทุกตัวจะทำถูกเท่ากัน และทำได้ทุกครั้ง โดยไม่ต้องมีใครคอยเตือน
ลองถามระบบของตัวเองดู: พฤติกรรมที่ต้องเกิดทุกครั้งมีกี่ข้อ และในจำนวนนั้นยังมีกี่ข้อที่อยู่ได้แค่ในความจำของ agent บางตัว ถ้าตอบทันทีไม่ได้ นั่นแหละตัวปัญหา กฎที่ตรวจสอบไม่ได้ว่ามีอยู่จริงหรือเปล่า มีค่าเท่ากับกฎที่ไม่มีอยู่
ช่วงที่ 3ยกกฎขึ้นเป็น gate
วิธีแก้คืนนั้นไม่ใช่การเติมบรรทัดนั้นเข้า prompt ของอีกแปดตัวที่เหลือ ทำแบบนั้นแปดตัวนี้จะหาย แต่ตัวที่เก้า ตัวที่สิบที่เข้ามาใหม่ก็ต้องถ่ายทอดกันอีก มันจะยังเป็นปัญหา copy-and-sync ตลอดไป
สิ่งที่ทำคือยกพฤติกรรมนั้นออกจาก setting รายตัว ขึ้นไปไว้ในโค้ดของ gate ส่วนกลาง ที่ agent ทุกตัวใช้ร่วมกัน
ตั้งแต่นั้น ทุกครั้งที่ agent ตัวไหนปฏิเสธงานเพราะเหตุสิทธิ์ gate จะเห็นการปฏิเสธนั้น แล้วแปลงมันเป็นงานในคิวของ coordinator อัตโนมัติ coordinator คือตัวที่มีสิทธิ์ปลดล็อกงานแบบนี้ (บทบาท "ตัวหัว" ที่คอยประสานงานฝูงแบบนี้ เล่าพร้อมงานจริงไว้ใน Claude Code subagents: ใช้ตัวหัวเป็น orchestrator ที่เหลือเป็นมือ) Agent ที่ปฏิเสธไม่ต้องจำบอกใคร การปฏิเสธไม่ไปตายในห้องที่ไม่มีใครอ่านอีกต่อไป
การเปลี่ยนแปลงสำคัญไม่ได้อยู่ที่จำนวนโค้ด มันอยู่ที่การเปลี่ยนชนิดของกฎ: จาก "ขอร้องให้แต่ละตัวจำ" เป็น "ระบบทำให้มันเกิดเอง"
gate ไม่ได้ทำให้ agent ตัวไหนเก่งขึ้นเลย ทุกตัวยังคิดแบบเดิม ทำงานแบบเดิม ที่เปลี่ยนมีอย่างเดียว: เมื่อตัวไหนติด งานที่ติดนั้นจะไม่ตายคาตัวมันอีกต่อไป
และเพราะมันอยู่ในโค้ด มันจึงมีเทสต์เฝ้าได้ คืนเดียวกันนั้นเอง ตอนแก้โค้ดจุดที่สองในไฟล์เดียวกัน ชุดเทสต์ที่มีอยู่เดิมจับความพลาดของคนแก้ได้หนึ่งดอกก่อนถึง production พฤติกรรมที่วางใน prompt ไม่มีชั้นนี้ มันเปลี่ยนเงียบ และไม่มีใครรู้ว่าเปลี่ยน
เกณฑ์วัดว่าอะไรเป็นของระบบแล้วจริงๆ มีข้อเดียว: ถ้าเปลี่ยน agent ทั้งฝูงเป็นตัวใหม่หมด ไม่ถ่ายทอดอะไรเลย พฤติกรรมนั้นยังเกิดอยู่หรือเปล่า ถ้าตอบว่าไม่ มันยังไม่ใช่ของระบบ เป็นแค่ความจำที่ฝากไว้กับตัวเก่า
และ gate นี้ไม่ได้ตัดสินเองว่างานไหนควรปลดล็อก การตัดสินยังอยู่ที่ coordinator ตามเดิม สิ่งที่ gate รับประกันมีอย่างเดียว: จะไม่มีงานที่ติดแล้วหายเงียบไปเฉยๆ การ route กับการตัดสินคนละชั้นกัน และควรให้อยู่คนละชั้นกันแบบนั้น เรื่องไหนระบบ route เองได้ เรื่องไหนต้องถึงมือคน อ่านต่อใน Human in the Loop ไม่ใช่เรื่องมีคนหรือไม่มีคน: โมเดล 3 ระดับ
คืนเดียวกันนั้นยังเจออีกชั้นของ root cause ด้วย งานชุดแรกที่หายไปเกิดจาก coordinator เองลืมแนบ marker อนุมัติตอนส่งงาน นี่เป็นความผิดพลาดชั้นคน แต่แม้หลังจากวันนั้น coordinator จะไม่พลาดอีกเลย ระบบก็ยังคงต้องการ gate อยู่ดี เพราะความพลาดแค่ครั้งเดียวสร้างการปฏิเสธเงียบหนึ่งครั้ง และการปฏิเสธเงียบหน้าตาเหมือนงานที่กำลังทำอยู่ทุกประการ มองจากข้างนอกแยกไม่ออก
ชั้นแรกคือคน ชั้นสองคือระบบ และชั้นสองสำคัญกว่า เพราะเป็นชั้นเดียวที่ออกแบบให้ความพลาดของชั้นแรกไม่ทำทั้งฝูงเงียบได้
ช่วงที่ 4พิสูจน์ยังไงว่า gate ทำงานจริง?
แก้เสร็จคืนนั้นไม่ได้ประกาศว่าเสร็จ สิ่งที่ทำคือยิง drill จำลองสถานการณ์งานที่ต้องเขียนไฟล์จริงๆ ส่งเข้าห้อง agent ตัวหนึ่ง แล้วดูทั้งสายโซ่ทำงานตามที่อ้างหรือเปล่า
สองรอบแรก drill ไม่เข้า ไม่ใช่เพราะ gate พัง แต่เพราะคนทดสอบพิมพ์ข้อความเทสต์เอง
ระบบมีรูปแบบข้อความตายตัวที่กำหนดไว้ในโค้ด ว่าเป็นข้อความชนิดไหนถึงจะถูกรับรู้ว่าเป็นงานจริง แทนที่จะ copy รูปแบบนั้นจากโค้ดที่เพิ่งอ่านจบ กลับพิมพ์ข้อความเข้าทดสอบจากความจำ ผลคือระบบไม่รับมันเข้าเส้นทางที่ต้องการทดสอบ
อีกรอบยังลืมกฎที่ตัวเองเพิ่งอ่านผ่านในโค้ดนาทีเดียวก่อนหน้า ระบบมี gate ด้านเวลาถืองานไว้ช่วงหนึ่ง พอยิง drill เข้าไปตอนยังอยู่ในช่วงนั้น งานก็ถูกพักไว้ไม่เดินหน้า คนที่กำลังทดสอบระบบที่เพิ่งอ่านโค้ดจบห้านาทีก่อน ลืมกฎที่เขียนอยู่ในโค้ดนั้นเอง หลักการเดียวกับที่เป็นหัวข้อโพสต์นี้: ความจำพึ่งไม่ได้ แม้แต่กับคนที่ยังไม่ทันลืม
รอบที่สาม copy รูปแบบข้อความจากโค้ดตรงๆ อ่าน gate เวลาให้จบก่อนยิง drill ถึงเข้าทาง และให้หลักฐานครบสาย:
- gate บล็อกการเขียนไฟล์จริง agent ทดสอบเขียนอะไรไม่ได้เลย
- การปฏิเสธถูกแปลงเป็นงานไปโผล่ในห้อง coordinator จริง อ่านข้อความที่มาถึงยืนยันได้
- coordinator รับงานต่อ ตอบรับ แล้วเตรียมปลดล็อกตามกระบวนการ
- ตรวจไฟล์ทดสอบที่ควรถูกสร้างระหว่าง drill: ไม่มีอยู่ read-only ทำงานจริง
เทสต์ล็อกพฤติกรรมเป็นจุดๆ ได้ แต่มีแค่ drill ที่พิสูจน์ทั้งสายโซ่ end-to-end ได้ว่าเมื่อเหตุการณ์จริงเกิด งานจะไปถึงมือคนที่ปลดล็อกได้จริง ไม่ใช่แค่แต่ละชิ้นส่วนเขียวอยู่คนเดียว
มีอีกเรื่องที่เกิดขึ้นในคืนนั้น ซึ่งเกือบทำลายการพิสูจน์เองทั้งหมด: เกือบ restart agent ตัวอื่นเพื่อให้รับโค้ดใหม่ ทั้งที่ drill ยังค้างอยู่ ถ้าทำแบบนั้น fix จะไปถึงทุกตัวก่อน drill ได้ยิง เส้นทางการพิสูจน์จะหายไปทันที gate จะเงียบแบบถูกต้องตลอดไป แต่จะไม่มีทางรู้ว่ามันทำงานจริงหรือเปล่า เพราะโอกาสได้เห็นมันทำงานถูก deploy ทับไปแล้ว
ลำดับ deploy กับลำดับพิสูจน์เป็นคนละเรื่องกัน และต้องวางแผนพร้อมกันเสมอ คืนนั้นตัวที่ถูก restart เป็นตัวสุดท้ายคือ agent ที่ใช้ยิง drill นั่นเอง เพราะมันถือสถานะที่ต้องใช้พิสูจน์อยู่ จนกว่าการพิสูจน์จะจบ
ช่วงที่ 5กฎพ่วงสามข้อจากคืนเดียวกัน
คืนนั้นให้กฎเพิ่มมาอีกสามข้อ ทุกข้อเป็นญาติของกฎหลัก:
- การปฏิเสธที่ไม่มีใครอ่าน เท่ากับงานที่หายเงียบ ข้อความแจ้งที่ส่งเข้าห้องซึ่งไม่มีคนอ่าน มีค่าเท่ากับข้อความที่ไม่ได้ส่ง notification ที่ต้องการ action ต้องกลายเป็นงานในคิวของคนที่ปลดล็อกได้เท่านั้น อย่าให้มันจบแค่ข้อความในห้อง หลักเดียวกับสัญญาณเตือนภัย: เงียบไม่ใช่สถานะปกติ สัญญาณที่ส่งออกไปต้องพิสูจน์ได้ว่าถึงมือคนที่ทำอะไรกับมันได้จริง
- ข้อความทดสอบต้อง copy จากรูปแบบจริง ไม่ใช่พิมพ์จากความจำ พลาดสองรอบติดในคืนเดียวจากสาเหตุนี้ นิสัยเดียวกับที่ทำให้เกิดเขียวหลอกได้เสมอ: ป้อนสิ่งที่คิดว่าระบบรับ แทนที่จะป้อนสิ่งที่ระบบรับจริง เคสคู่กันที่เจอในโค้ดชุดเดียวกันคือ parser สองจุดที่อ่านข้อความรูปแบบเดียวกัน แต่ต่างคนต่างมีชุดทดสอบของตัวเอง รูปแบบไม่ตรงกัน ผลคือ parser จุดหนึ่งไม่เคยทำงานกับข้อความจริงได้เลยตั้งแต่เขียน ถ้ามีสองจุดในระบบที่ parse รูปแบบเดียวกัน ทั้งสองจุดควรมี fixture ชุดเดียวกัน
- ลำดับ deploy ต้องเคารพลำดับพิสูจน์ fix ที่ deploy ก่อน fix ก่อนหน้าถูกพิสูจน์ จะทำลายความสามารถในการพิสูจน์นั้นตลอดไป และที่อันตรายที่สุดคือความผิดพลาดชนิดนี้ไม่มี error ไม่มี warning ระบบจะดูถูกต้องเงียบๆ ตลอดไป เพียงแต่ไม่มีใครพิสูจน์มันได้อีก
หลักการบรรทัดเดียว
ตอนนี้ agent ทุกตัวในฝูงทำงานภายใต้ gate เดียวกัน ตัวไหนปฏิเสธงานด้วยเหตุผลอะไร การปฏิเสธนั้นจะไปถึงคิวของ coordinator ทุกครั้ง โดยไม่ต้องพึ่ง prompt ไม่ต้องพึ่งความจำของใคร
หลักการที่อยากทิ้งไว้มีบรรทัดเดียว: พฤติกรรมใดที่ต้องเกิดทุกครั้งเพื่อให้ระบบทำงาน พฤติกรรมนั้นห้ามฝากไว้ใน prompt ของ agent แต่ละตัว ยกมันขึ้นเป็นของระบบ
prompt สอน agent ว่าควรทำอะไร ส่วน gate ทำให้มันเกิดขึ้นจริง สองอย่างนี้ทดแทนกันไม่ได้ ความต่างระหว่าง demo กับ production ก็อยู่ตรงนี้เอง: demo ต้องการแค่ agent ที่ยอมทำตามกฎ แต่ production ต้องการระบบที่รับประกันว่ากฎจะเกิด แม้ตอนที่ agent ลืม
แล้วในระบบของคุณ พฤติกรรมที่ต้องเกิดทุกครั้งทุกงานมีอะไรบ้าง และตอนนี้นอนอยู่ในความจำของ agent ตัวไหนอยู่ คำตอบของคำถามนั้นคือจุดเริ่มต้นของทุกอย่างที่เล่ามาในโพสต์นี้
- งานจริงของผู้เขียน session คืน 2026-08-02 ถึงเช้า 2026-08-03: ไล่ log 3 วันของ fleet จนเจอ root cause (ปฏิเสธรวม 15 ครั้ง, รันเต็มรูปแบบ 10 ครั้ง, 8 ใน 10 มาจาก agent ตัวเดียวที่ charter มีบรรทัด escalation) → ยกพฤติกรรมนั้นขึ้นเป็น gate ส่วนกลาง → พิสูจน์ end-to-end ด้วย drill จริง (3 รอบกว่าจะเข้าทาง, 2 รอบแรกพลาดเพราะพิมพ์ข้อความทดสอบจากความจำ) งานทั้งหมดเป็นงานของผู้เขียนเอง ไม่มีอ้างอิงภายนอก
- scrub แล้ว: ชื่อ agent ตัวจริง, ห้อง, marker และโครงสร้างภายในทั้งหมดถูก abstract ออก เหลือเฉพาะ principle กับตัวเลขจาก log จริง