AI Agent ควรอ่าน log ก่อนแก้บั๊กไหม? ควรครับ เพราะ log คือหลักฐานว่าอะไรเกิดขึ้นจริง เวลาไหน และเกิดกับใคร ส่วนการแก้ก่อนดูหลักฐานคือให้ AI เดาแล้วเอา production มาลองผิดลองถูก ซึ่งผมไม่ทำเด็ดขาด 555
AI เก่งเรื่องอ่านข้อมูลหลายกองพร้อมกันมากก็จริง แต่ยิ่งมันตอบเก่ง เรายิ่งต้องแยกให้ได้ว่าอะไรเป็น fact อะไรเป็น hypothesis และอะไรยังไม่รู้ บทความนี้ไม่ได้สอนให้จำคำสั่ง terminal นะครับ ผมอยากเล่าวิธีคิดที่ผมใช้กับระบบธุรกิจจริง: ให้ agent สืบก่อน ค่อยแก้เป็นขั้น ๆ
ทำไม AI Agent ต้องอ่าน log ก่อนแก้บั๊ก?
เพราะ symptom ที่เราเห็นมักไม่ใช่ต้นเหตุครับ Log ทำให้ AI Agent เรียงเหตุการณ์ แยกสิ่งที่เพิ่งเปลี่ยน และชี้ว่าอะไรควรตรวจต่อ ก่อนที่ใครจะไป restart หรือแก้ code แบบสุ่ม ๆ
เวลาเว็บช้า คนมักพูดว่า server ล่ม เวลาอีเมลไม่ออก คนมักโทษ SMTP แต่ของจริงอาจเป็น cron ไม่รัน, webhook หาย, database lock หรือ token หมดอายุ ถ้าเริ่มจากคำตอบที่ฟังดูคุ้นเคย เรามักซ่อมของที่ไม่ได้พัง แล้วปัญหาจริงก็ยังอยู่เหมือนเดิม
ผมให้ AI เริ่มด้วยคำถามแคบ ๆ เช่น “ตั้งแต่ 14:00 มี error อะไรบ้าง, request ไหนเริ่มผิดปกติ, และก่อนหน้านั้นมี deploy หรือ config เปลี่ยนไหม” คำสั่งสำคัญคือ ห้ามแก้ ห้าม restart ในรอบแรก ให้เก็บ timeline พร้อมจุดอ้างอิงมาก่อน ถ้ามันตอบว่า “น่าจะ...” แต่ไม่มี timestamp หรือหลักฐานให้เปิดตาม ผมยังถือว่าไม่ใช่คำตอบครับ
เคสจริง: ทำไมข้อมูลแชตถึงดูเหมือนมีคนใช้ผิดปกติ?
เคสหนึ่งทำให้ผมเห็นชัดว่า log ช่วยกันการแก้ผิดจุดได้มากแค่ไหนครับ ในระบบ Newton มีข้อมูลเวลาที่ลูกค้าใช้งานล่าสุดบางเครื่องขึ้นเวลาเดียวกันผิดธรรมชาติ ถ้าดูแค่ dashboard จะเหมือนลูกค้าหลายคนเพิ่งเข้ามาพร้อมกัน ทั้งที่ความจริงไม่ใช่เลย
ตอนแรกเรามีข้อมูลจาก CLI แค่ทางเดียว และมี script บางส่วนพิมพ์ผลลัพธ์หลายบรรทัดโดยไม่มี label พอเครื่องไหนไม่มีข้อมูลในบรรทัดแรก ผลจากบรรทัดถัดไปก็เลื่อนช่องทันที เวลาแก้ไข workspace ซึ่งเป็นงานระบบประจำวันเลยถูกเอาไปแสดงเป็นเวลาคุยกับ AI แทน ตัวเลขที่ซ้ำกันไม่ใช่พฤติกรรมลูกค้า แต่เป็นข้อมูลหลอกที่เกิดจาก format ของผลลัพธ์เอง
ผมให้ agent เก็บหลักฐานจาก session ของทั้ง 3 engine ที่ใช้จริง แล้วเทียบกับ log ของ job ระบบ ผลคือเจอว่าเวลาซ้ำตรงกับ cron ที่แตะไฟล์ credential ตอนประมาณตีห้าของไทย ไม่ใช่เวลาคนคุยเลย หลังจากนั้นจึงแก้ให้ทุกค่าออกพร้อม prefix ชัด ๆ เช่น AUTH, CHAT และ WORK เพื่อไม่มีช่องไหนเลื่อนทับกันอีก
ผลลัพธ์เชิงตัวเลขคือ จากเครื่องลูกค้า 75 เครื่อง ที่สำรวจ เราแยกได้ว่ามี 58 เครื่อง ที่มี session ใช้งานจริงในอย่างน้อยหนึ่ง engine ส่วนที่เหลือไม่ควรถูกตีความว่า “เงียบ” จากเวลา artifact เดิม ถ้าผมรีบตั้ง alert จากตัวเลขผิด ๆ ก่อนอ่าน log เราคงทักลูกค้าผิดคนและวัด activation เพี้ยนทั้งระบบครับ
AI Agent ควรอ่านอะไรนอกจาก log?
Log เป็นจุดเริ่ม ไม่ใช่ศาลตัดสินคดีครับ หลังเห็นสัญญาณแล้ว AI ควรเทียบกับสถานะจริงของระบบ, code หรือ config ที่เปลี่ยนล่าสุด, database และวิธีทำให้ปัญหาเกิดซ้ำได้
ผมชอบให้ agent แบ่งรายงานเป็นสามหัวข้อ: facts ที่เห็นจากหลักฐาน, assumptions ที่ยังต้องพิสูจน์ และ unknowns ที่ข้อมูลยังไม่พอ วิธีนี้กันนิสัยของทั้งคนและ AI ที่ชอบเชื่อเรื่องแรกที่ฟังสมเหตุผลเกินไป
ตัวอย่างเช่น log บอกว่า request error หลัง deploy นั่นเป็น fact แต่ “deploy ตัวนั้นทำให้พัง” ยังเป็นแค่ hypothesis อาจมี token หมดอายุพอดี หรือ service ปลายทางล่มในเวลาเดียวกันก็ได้ ถ้าจะพิสูจน์ต้องดู diff ของ code, response จาก dependency และลอง reproduce ใน environment ที่ปลอดภัยก่อน รายละเอียด flow ที่ผมใช้ให้ AI สืบปัญหา production ไว้ใน AI Agent แก้ปัญหาระบบ production ได้ไหม ครับ
ให้ AI อ่าน log ระบบปลอดภัยไหม?
ปลอดภัยได้ถ้าให้มันอ่านเท่าที่จำเป็นและแยกสิทธิ์อ่านออกจากสิทธิ์แก้ครับ การเห็น log ไม่ควรทำให้ agent ได้กุญแจ deploy, ลบข้อมูล หรือเปลี่ยนบัญชีลูกค้าไปด้วย
ผมพยายามไม่ให้ secret หลุดลงใน report ตั้งแต่ต้น ถ้าต้องดูข้อมูลลูกค้า ก็ให้มันอ้างอิงเป็น id หรือสรุป pattern แทนการคัดข้อมูลทั้งหมดออกมาใส่แชต และถ้าสิ่งใดอ่านไม่ได้เพราะถูกปิดไว้ ผมจะไม่แก้ด้วยการให้สิทธิ์กว้างทันที แต่ถามก่อนว่ามี source อื่นที่ตอบคำถามเดียวกันได้ไหม
หลักนี้ต่อยอดจากเรื่อง AI Agent ควรมีสิทธิ์เข้าถึงอะไรบ้าง เลยครับ สิทธิ์ที่ดีไม่ใช่สิทธิ์ที่ agent ทำได้ทุกอย่าง แต่เป็นสิทธิ์น้อยที่สุดที่ยังทำงานนั้นได้จริง และเมื่อมันพบเหตุผิดปกติ ก็หยุดส่งหลักฐานให้คนตัดสินใจแทนที่จะพยายามเป็นฮีโร่
Workflow ให้ AI Agent อ่าน log แล้วแก้บั๊กอย่างปลอดภัยทำยังไง?
ลำดับที่ผมใช้คือ เก็บหลักฐาน → สร้างสมมติฐาน → ทำให้เกิดซ้ำ → เขียน test → ทำ patch เล็กที่สุด → ตรวจผลครับ ขั้นเหล่านี้อาจดูเยอะ แต่ช่วยลดรอบแก้แบบเดาสุ่มลงเยอะกว่ามาก
เริ่มจากบอก symptom ให้ตรวจได้: ใครเจออะไร เมื่อไหร่ และผลที่ควรเป็นคืออะไร จากนั้นให้ agent อ่านช่วง log ที่เกี่ยวข้อง ไม่ใช่โยน log ทั้ง server ให้มันอ่านจน noise เต็มไปหมด เมื่อมีข้อสรุป ให้มันชี้ว่าหลักฐานบรรทัดไหนรองรับ และอะไรจะหักล้างสมมติฐานนั้นได้
ถัดมาคือ reproduce ถ้าทำให้ปัญหาเกิดซ้ำไม่ได้ เราจะไม่รู้ว่าการแก้หายเพราะ patch หรือแค่จังหวะดี จากนั้นค่อยให้ AI เขียน test ที่ fail ก่อนแก้และ pass หลังแก้ แล้วสร้าง patch ที่แคบที่สุด ผมยังให้คน approve เสมอเมื่อจะ deploy, แตะข้อมูลจริง หรือเปลี่ยนสิ่งที่ลูกค้าเห็น เพราะความเร็วไม่ใช่ข้ออ้างให้เอาลูกค้าเป็น environment ทดสอบครับ
ถ้าคุณกำลังเริ่มแตก workflow แบบนี้กับงานธุรกิจ ไม่ต้องเป็น dev ก็ทำได้ครับ สิ่งที่ต้องฝึกคือแปลงปัญหาให้ตรวจได้ และกำหนดว่า AI ควรหยุดตรงไหน ผมสอนไว้แบบจับมือทำที่ คอร์ส LearnAI ครับ
เมื่อไหร่ควรให้ AI แก้เอง และเมื่อไหร่ต้องหยุดถามคน?
ให้ AI ทำเองได้เมื่อ action นั้นย้อนกลับง่าย ขอบเขตแคบ และมีเกณฑ์ตรวจชัดครับ ถ้ากระทบเงิน สิทธิ์ลูกค้า ข้อมูลสำคัญ หรือเผยแพร่สู่สาธารณะ ต้องมีคนอนุมัติ
งานอย่างรวม log, สรุป incident, เปิด ticket, รัน test หรือสร้าง draft patch มักปล่อยให้ทำเองได้ เพราะผลยังอยู่ภายในและตรวจซ้ำได้ แต่การ restart ระบบ, migrate database, ส่งข้อความถึงลูกค้า หรือ deploy เป็นคนละระดับ ต่อให้ agent เสนอถูก 99 ครั้ง ความผิดพลาดครั้งที่ 100 อาจแพงกว่าประโยชน์ทั้งหมด
วิธีคิดนี้ไม่ได้ทำให้ AI ช้าจนไม่มีประโยชน์นะครับ ตรงกันข้าม คนได้รับเฉพาะเรื่องที่ต้องใช้ judgement พร้อมหลักฐานและทางเลือกแล้ว ลดเวลาจากการเปิดหลายหน้าจอเองไปมาก ผมเคยอธิบายเส้นแบ่งนี้ไว้ใน AI Agent ควรขออนุมัติเมื่อไหร่ ด้วยครับ
คำถามที่พบบ่อย
AI Agent ควรอ่าน log ก่อนแก้บั๊กไหม?
ควรครับ เพราะ log ช่วยยืนยันว่าอะไรเกิดขึ้นจริง เวลาไหน และกระทบส่วนใด ทำให้ AI แยกข้อเท็จจริงจากสมมติฐานก่อนเสนอทางแก้
ให้ AI Agent อ่าน log ระบบปลอดภัยไหม?
ปลอดภัยขึ้นเมื่อให้สิทธิ์อ่านเฉพาะที่จำเป็น ปิดบัง secret และแยกสิทธิ์อ่านออกจากสิทธิ์แก้ production การอ่าน log ไม่ควรทำให้แก้ระบบได้อัตโนมัติ
log ไม่พอสำหรับแก้บั๊กต้องดูอะไรเพิ่ม?
ต้องเทียบกับสถานะปัจจุบัน เช่น code หรือ config ที่เพิ่งเปลี่ยน, database, health check และวิธีทำให้ปัญหาเกิดซ้ำ Log คือหลักฐานชิ้นหนึ่ง ไม่ใช่คำตอบทั้งหมด
AI Agent แก้บั๊กเองได้แค่ไหน?
มันช่วยรวบรวมหลักฐาน สร้างสมมติฐาน เขียน test และทำ patch แบบร่างได้ดี แต่ deploy ลบข้อมูล หรือเปลี่ยนสิ่งที่กระทบลูกค้าควรมีคนอนุมัติเสมอ
ถ้าคุณอยากมี AI ที่ไม่ใช่แค่บอกให้ลองแก้ตามนี้ แต่มีพื้นที่ทำงานของตัวเองไว้เปิดหลักฐาน สร้าง test และช่วยเดินงานต่อแบบคุมสิทธิ์ได้ ลองดู Newton ครับ ผมสร้างมันจากวิธีทำงานที่ใช้กับธุรกิจตัวเองทุกวันนี่แหละ: ให้ AI เร็วได้เต็มที่ แต่ไม่ให้การเดาเร็วกว่า evidence
— Pond