AI Agent ความเชื่อถือได้คืออะไรในโลกการผลิตจริง
AI Agent ความเชื่อถือได้คือระบบอัตโนมัติที่ออกแบบให้ workflow ของมันยังคงทำงานต่อเนื่องและรักษาสถานะได้แม้จะเกิดการ crash, deploy ใหม่ หรือ restart โครงสร้างพื้นฐาน ขณะเดียวกันต้องยังสามารถปรับปรุงคุณภาพผลลัพธ์ผ่านการทดสอบและประเมินแบบรวดเร็วซ้ำได้หลายร้อยครั้งต่อวัน โดยไม่สร้างภาระให้ระบบผลิตหลัก ทำให้ธุรกิจใช้ AI ได้ทั้งในงานวิจัยลึกและงานปฏิบัติการประจำวันอย่างมีเสถียรภาพและตรวจสอบได้ ความท้าทายของ AI ความทนทานคือการต้องได้ทั้งความทนต่อความล้มเหลวและความเร็วในการทดลองพร้อมกัน ถ้า workflow ถูกผูกติดกับ runtime หนักที่เน้น durability เพียงอย่างเดียว การปรับ prompt เล็กน้อยเพื่อดูผลย่อมกลายเป็นรอบทดสอบที่ช้าและสิ้นเปลืองทรัพยากร ในทางกลับกัน ถ้าเน้นแต่วงทดสอบเบาๆ ในเครื่องเดียว ระบบจะไม่มีการยืนยันว่าขั้นตอนยาวๆ จะรอดจากการ deploy หรือการรีสケジュลดได้ ดังนั้นหัวใจของการออกแบบคือการแยก “ตรรกะธุรกิจ” ออกจาก “ที่ที่มันรัน” แล้วให้ runtime มาเติมภายหลัง เพื่อให้โค้ดเดียวกันใช้ได้ทั้งใน production และ eval.
ดุลยภาพระหว่างระบบ workflow ผลิตภาพกับวงทดลองเร็ว
เมื่อพูดถึงระบบ workflow ผลิตภาพสำหรับ AI Agent เรากำลังพูดถึงลำดับขั้นตอนที่สามารถอยู่รอดจาก deploy, crash และการย้ายงานข้าม worker โดย state ต้องถูกบันทึกหลังทุกขั้น เพื่อให้ระบบ replay ประวัติและกลับมาทำต่อจากจุดเดิมได้ นี่คือสิ่งที่จำเป็นสำหรับ agent ที่ทำงานวิจัยลึกเป็นชั่วโมงพร้อมเรียก LLM และ tools หลายสิบครั้ง AI ความทนทานจึงต้องพึ่ง durable execution ที่ทำให้ผลลัพธ์แต่ละขั้นอยู่ได้เกินอายุโปรเซสเดียว. แต่สำหรับทีมที่กำลังปรับปรุงคุณภาพ LLM การประเมินแบบรวดเร็วต้องการ loop ที่เบา โลคอล และไม่ต้องพึ่งคิวงานหรือคลัสเตอร์ใดๆ ควรเปลี่ยนโค้ดบรรทัดเดียว โหลดชุดข้อมูลหลายร้อยตัวอย่าง แล้วรันดูคะแนนรวมในไม่กี่วินาที โดยไม่มีการ persist state หรือกระจายงานข้ามระบบ โครงสร้าง workflow ที่บังคับใช้ runtime หนักเพื่อทุกการรันจึงขัดกับเป้าหมายนี้อย่างชัดเจน ทางออกที่สมเหตุสมผลคือเขียน orchestration เป็นตรรกะกลางที่ไม่รู้ว่ารันที่ไหน แล้วให้ทั้ง runtime durability-first และ eval runtime เบามาอิมพลีเมนต์ผ่าน interface เดียวกัน.
Runtime-agnostic: แบบแผนสถาปัตยกรรมเพื่อ AI ความทนทาน
แนวคิด runtime-agnostic คือการหยุดเขียน orchestration ตรงกับ runtime ใด runtime หนึ่ง แล้วหันมาเขียนกับ interface กลางที่ runtime ทุกตัวต้องรองรับ เมื่อทำเช่นนี้ ตรรกะธุรกิจของ AI Agent ไม่ต้องรู้ว่ามันกำลังรันบน workflow engine หนักหรือบน eval harness เบา ผลคือโค้ดชิ้นเดียวกันถูกใช้ทั้งใน production และการทดสอบออฟไลน์ ทำให้ลดบั๊กประเภท “เวอร์ชันทดสอบกับเวอร์ชันปล่อยจริงไม่เหมือนกัน” ลงทั้งกลุ่ม. จุดสำคัญคือระบบต้องบังคับให้ตรรกะนี้ runtime-agnostic โดยดีไซน์ ไม่ใช่อาศัยวินัยนักพัฒนา เมื่อมีโค้ดที่ผูกติดกับ runtime ใด runtime หนึ่ง build ต้องล้มทันที แน่นอนว่าการตัดขาดเช่นนี้มีต้นทุน เพราะ orchestration จะเสียการเข้าถึงฟีเจอร์ native ของแต่ละ runtime โดยตรง ทุกความสามารถใหม่ต้องถูกเดินสายผ่านเลเยอร์กลางก่อน แต่สำหรับโครงการที่ต้องการทั้งความทนทานระดับระบบกระจายและการวน eval ที่รวดเร็ว การลงทุนด้านสถาปัตยกรรมนี้คุ้มค่าอย่างชัดเจน และเป็นพื้นฐานให้ AI Agent ความเชื่อถือได้สามารถอยู่รอดแม้โครงสร้างพื้นฐานล้มเหลว ขณะเดียวกันก็รักษาสถานะและประวัติการทำงานที่ต้องการได้.
Knowledge Graph ทดสอบ: ทำให้ AI Agent จำผลิตภัณฑ์ได้
ปัญหาของ agent ทดสอบแบบเดิมคือมันเริ่มทุกครั้งจากศูนย์ เหมือนผู้ใช้ใหม่ที่ไม่รู้ว่าหน้าไหนเปราะ บั๊กไหนชอบกลับมา และ flow ไหนซับซ้อน ทำให้การทดสอบช้ากว่าและค่าดำเนินการสูงกว่าที่ควร ในทางปฏิบัติ หนึ่งในวิธีให้ agent มี “ความจำผลิตภัณฑ์” ที่ใช้ได้คือการสร้าง Knowledge Graph ทดสอบ ซึ่งเป็นโครงสร้างแทนผลิตภัณฑ์ที่ agent ใช้เหตุผลเหนือมันก่อนจะเขียนเคสทดสอบแรก. โดยนิยาม Knowledge Graph คือการแปลงผลิตภัณฑ์ให้กลายเป็นชุดของเพจ แอ็กชัน เทสต์ และความล้มเหลวที่ผ่านมา ที่เชื่อมโยงกันเป็นเครือข่ายความทรงจำที่ agent สามารถ query ได้ ต่างจากการโยนสกรีนช็อตและข้อมูลดิบกองใหญ่ให้โมเดล นี่คือความจำแบบมีโครงสร้าง จุดเริ่มต้นคือให้ agent crawl สำรวจแอปเหมือนผู้ใช้ใหม่ เก็บข้อมูลเพจและ flow จากนั้นความสังเกตถูกสร้างเป็น entity เช่น project, feature, page, action, test, document, section, chunk พร้อม metadata ระดับ action เช่นสกรีนช็อต HTML รอบๆ เวกเตอร์ embedding และจำนวนครั้งที่ถูกเยี่ยมชม เมื่อผู้ใช้สรุปคำสั่งทดสอบด้วยภาษาธรรมดา ตัวช่วยจะดึง slice ที่เกี่ยวข้องของกราฟออกมา แล้วออกแบบเทสต์ตาม “intent” แทนการตามสคริปต์คงที่.
Agentic testing กับ Knowledge Graph: จับบั๊กแอบซ่อนในโลกแอปที่เปลี่ยนตลอด
ความแตกต่างสำคัญระหว่าง agentic testing กับ scripted testing คือ scripted เน้นขั้นตอน ขณะที่ agentic เน้นเจตนา Classic automation จะบอกให้ไปหน้า /checkout หา element ตาม data-testid กด แล้ว assert ข้อความ แต่ agentic testing ให้ agent เป้าหมาย เช่น “ตรวจว่าผู้ใช้ใช้ส่วนลดและจบขั้นตอน checkout ได้” จากนั้นปล่อยให้มันสังเกต UI ลงมือ ทำประเมินผล และตัดสินใจขั้นต่อไปเอง. เมื่อ checkout flow ถูกโมเดลเป็น knowledge graph agent ที่สร้างเทสต์ใกล้ logic ส่วนลดในอนาคตจะไม่เห็นเพียงว่ามีหน้า checkout มันรู้ด้วยว่า action ไหนอยู่บนหน้านั้น ใช้ทำเป้าหมายอะไร และแม้กระทั่งว่าครั้งหนึ่งยอดรวมเคยคำนวณใหม่ไม่ถูกหลังผู้ใช้ถอดคูปองออก นี่คือการใช้ความจำโครงสร้างเพื่อ “เรียนรู้พฤติกรรมแอปตามเวลา” แล้วจับบั๊กที่สคริปต์เดิมไม่เคยครอบคลุม เป้าหมายจึงไม่ใช่การสร้างกองสคริปต์ทดสอบให้ใหญ่ขึ้น แต่คือปล่อยให้ agent สำรวจแอปเหมือนผู้ใช้จริงเพื่อหาเงื่อนไขผิดปกติที่มนุษย์และสคริปต์อัตโนมัติหลงมองข้าม. Knowledge Graph ที่อัปเดตแบบเพิ่มพูนทำให้โครงสร้างความรู้ทนต่อการ refactor และดีไซน์ใหม่ของ UI ทำให้ AI Agent ความเชื่อถือได้ยังคงตามทันผลิตภัณฑ์ที่เปลี่ยนเร็ว โดยไม่ต้องเริ่มเรียนรู้จากศูนย์ทุกครั้ง.
