AI agents ที่พังไม่ใช่ปัญหาของโมเดล แต่เป็นปัญหาของระบบ
AI agents คือระบบที่ใช้โมเดลภาษาขนาดใหญ่ร่วมกับเครื่องมือและโครงสร้างพื้นฐาน เพื่อให้ตัดสินใจ ลงมือทำงาน และโต้ตอบกับสภาพแวดล้อมได้เองแบบกึ่งอัตโนมัติหรืออัตโนมัติเต็มรูปแบบในสเกลองค์กร โดยเป้าหมายไม่ใช่แค่ตอบแชทให้สวย แต่ต้องทำงานซ้ำได้อย่างไว้ใจได้ภายใต้ข้อจำกัดของระบบจริงและผลลัพธ์ทางธุรกิจที่มีเดิมพันสูง. ในโลกของการทดลอง demo มักดูราบรื่น แต่พอเข้าสู่ production ความซับซ้อนที่แท้จริงก็โผล่ขึ้นมา: การสังเกตผิด การ hallucinate การควบคุมสถานะระบบ และความล้มเหลวที่เกิดขึ้นใน 30% ของกรณีที่ไม่เป็นไปตามแผน. บทความนี้ชี้ว่ารากปัญหาไม่ได้อยู่ที่ “โมเดลคิดผิด” เท่านั้น แต่อยู่ที่เราออกแบบ monitoring, การตัดสินใจ และ execution layer ไม่สอดคล้องกับความเสี่ยงในโลกจริง.
Monitoring แบบเดิมมองเห็นแค่แอปไม่ล่ม แต่ไม่เห็นว่า agent เพ้อหรือวนลูป
Lyubo ในฐานะ Product Manager ของ Progress AI Observability เล่าว่าทีมจำนวนมากเริ่มสร้าง AI agents แล้ว demo แรกมักประกอบร่างได้เร็ว แต่พอรันใน production ทุกอย่างซับซ้อนขึ้นทันที. เรื่องใหญ่คือเครื่องมือ production monitoring แบบเดิมบอกเราได้แค่ว่าแอปยังรันอยู่ แต่ตอบไม่ได้เลยว่าทำไม agent ถึงเลือกใช้เครื่องมือผิด มองข้าม context ที่สำคัญ ติดอยู่ในลูปที่แพง หรือให้คำตอบที่ดูน่าเชื่อถือแต่ผิด. ในโลกของ AI agent failures นี่ไม่ใช่ bug เล็ก ๆ แต่คือจุดเริ่มต้นของความเสียหายที่ผู้ใช้อาจไม่รู้ตัวด้วยซ้ำ เพราะระบบแจ้งเตือนบอกเพียงว่า “ทุกอย่างยัง up” ขณะที่เนื้อในเริ่มเพี้ยน. แนวคิด observability แบบใหม่จึงพยายามย้ายทีมวิศวกรรมจากโหมด “รู้แค่ว่ามีอะไรบางอย่างผิด” ไปสู่การเข้าใจว่า “ผิดเพราะอะไร ต้องแก้อะไร และเวอร์ชันใหม่ดีขึ้นจริงหรือไม่”. หากองค์กรยังมอง monitoring แค่ uptime ก็ไม่มีทางรู้ทันเมื่อ agent สร้างคำตอบลอย ๆ ที่ไม่ผูกกับความจริงจนพาธุรกิจพัง.
Agent ที่หยุดอยู่หน้าจอแจ้งเตือน: เมื่อการตรวจพบดีแล้ว แต่การลงมือยังติดคอคน
ในหลายอุตสาหกรรม ตั้งแต่ระบบรักษาความปลอดภัยไปจนถึง monitoring โครงสร้างพื้นฐาน การตรวจจับเหตุผิดปกติพัฒนาไปไกลแล้ว เลเยอร์ sensing ฉลาดขึ้นมาก ทั้งด้านการจำแนก การลด false positive และการเพิ่ม recall. แต่เกือบทุก demo ของ agentic AI จบในจุดเดิม: ระบบสังเกตบางอย่าง สรุปสิ่งที่เห็นได้สวยงาม แล้วส่งการตัดสินใจกลับไปให้คนฝั่งหน้าจอ. ตรงจุด handoff นี้เองที่สิ่งซึ่งถูกเรียกว่า agentic กลายเป็นเพียงระบบแจ้งเตือนราคาแพง เพราะองค์กรกลับไปพึ่งความสนใจของมนุษย์ ซึ่งขยายตัวได้ช้ากว่าความสามารถในการตรวจจับของเครื่องจักร. “An alert is a request for a human's attention. Attention scales far more slowly than detection does.” คือประโยคที่อธิบายปัญหานี้ได้ชัด. ข้อมูลจากการสำรวจโดย Forrester Consulting ยังชี้ว่าแม้ 86% ขององค์กรจะขยับเกินเฟส pilot ของ AI agents แล้ว แต่มีเพียง 34% ที่เชื่อใจการกระทำของ agent เหล่านั้นจริง ๆ. ความเชื่อใจจึงไม่ได้ผูกกับระดับความฉลาดของโมเดล แต่กลับผูกกับความพร้อมด้าน governance การเชื่อมระบบ และการจัดการ API/MCP ซึ่งเป็น “งานท่อ” ที่หลายทีมละเลย.
Execution layer: ชั้นที่ขาดหาย ทำให้ระบบพังตอนต้องลงมือจริง
เมื่อ AI agents เริ่มออกจากโลกของแชทไปทำงานที่เกี่ยวข้องกับการทำธุรกรรม เช่น การเชื่อมต่อกระเป๋า crypto เพื่อส่งธุรกรรมหรือโต้ตอบ smart contract ปัญหาไม่ได้อยู่ที่การสร้างธุรกรรมบนกระดาษ แต่คือการทำให้ execution เชื่อถือได้ภายใต้ข้อจำกัดโลกจริง. สถาปัตยกรรมยุคแรกมักเป็น AI → Wallet → RPC → Blockchain โดยคิดว่าหลัง agent ตัดสินใจแล้ว wallet จะดูแลที่เหลือเอง. แต่นั่นคือการโยนภาระสามอย่างให้อุปกรณ์ที่ถูกออกแบบมาไม่ตรงงาน: การสร้าง intent การตัดสินใจว่าอะไรควรถูก execute และการส่งธุรกรรมให้สำเร็จในเงื่อนไขเครือข่ายที่เปลี่ยนแปลงตลอด. งานวิจัยด้าน autonomous blockchain agents จึงเสนอรูปแบบใหม่: AI → Intent Layer → Execution Layer → Blockchain. Execution layer แยกชัดว่ามีหน้าที่ดูแลทุกอย่างที่แปลง intent ให้เป็นธุรกรรมที่ไว้ใจได้ ตั้งแต่การประกอบธุรกรรม การจำลองก่อนรัน การจัดการ nonce ความซ้ำซ้อนของ RPC logic การ retry การคืนค่า state ให้ตรง และการจัดเส้นทางข้าม chain. กล่าวสั้น ๆ การล่มส่วนใหญ่เกิดระหว่าง execution ไม่ใช่ตอน reasoning. หากองค์กรยังมอง execution เป็นเพียง “wallet เซ็นแล้วจบ” agentic AI reliability ก็จะติดเพดาน เพราะทุกข้อผิดพลาดใน reasoning จะถูกขยายเป็นความเสียหายที่ย้อนคืนไม่ได้.
ความไว้ใจใน enterprise AI deployment เกิดจากการรอดเวลาพลาด ไม่ใช่แค่ตอน demo สวย
Yaron Schneider ผู้ร่วมก่อตั้งและ CTO แห่งหนึ่งเตือนว่าการประเมิน AI agents ใน production มักจ้องแต่ผลลัพธ์ด้านบวก: ทำงานสำเร็จไหม ตอบถูกไหม demo ดูดีหรือเปล่า แต่สิ่งที่ชี้ว่าบริษัทจะยอมให้ agent ทำงานจริงคือ “เกิดอะไรขึ้นใน 30% ของเคสที่ผิดพลาด”. ในบริการการเงิน agent ที่จัดการ workflow การโอนเงินพลาดไม่ได้แปลว่าแค่เปิด ticket แต่แปลว่าความรับผิดทางกฎหมายอาจลามทั้งองค์กร ใน healthcare การเข้าถึงข้อมูลโดยไม่ถูกตรวจสอบอาจกระทบความปลอดภัยผู้ป่วยและเสี่ยงละเมิดข้อบังคับ. อุตสาหกรรมที่ถูกกำกับจึงไม่สามารถมอง failure เป็นเรื่องเล็ก และนั่นทำให้คำว่า production-ready ต้องเข้มงวดกว่าเดิม. เขาชี้ว่าทีมที่จริงจังกับ enterprise AI deployment ต้องเปลี่ยนจากการ optimize เคสทั่ว ๆ ไป ไปออกแบบโดยตั้งต้นจาก “ความล้มเหลวหายากแต่มีผลกระทบสูง”. ตัวอย่างเช่น การออกแบบ state management ที่สามารถ resume workflow ที่ค้างอยู่โดยไม่ต้อง replay การเรียก LLM ทั้ง 10 ขั้นจนเปลืองต้นทุนและสร้างปัญหาด้าน audit เมื่อ agent ล้มเหลวที่ขั้นที่ 9. การเน้นเพียงความแม่นยำเฉลี่ยสูง ๆ จึงไม่พอ; การอยู่รอดและกู้คืนเมื่อเกิด AI agent failures ต่างหากที่สร้างความไว้ใจระยะยาว.
