การดีบัก AI Agent: แดชบอร์ดของคุณรู้ต้นทุน แต่ไม่รู้สาเหตุ

การดีบักเอเจนต์ AI เริ่มต้นขึ้นตรงจุดที่แดชบอร์ดการสังเกตการณ์ของคุณสิ้นสุดลง เมื่อเอเจนต์เขียนโค้ด AI ทำให้บางอย่างพังและการรันนั้นจบลงแล้ว แดชบอร์ดสามารถบอกคุณได้ว่าการรันนั้นมีค่าใช้จ่ายเท่าใด (โทเค็น ดอลลาร์ ความหน่วง) แต่มันจะเงียบต่อคำถามเดียวที่คุณอยากรู้จริง ๆ: ทำไมเอเจนต์ถึงเปลี่ยนไฟล์นั้น? สิ่งที่ตอบคำถามนี้คือเทรซที่บันทึกไว้ ซึ่งคุณสามารถเปิด อ่าน และเล่นซ้ำได้ เพราะมันส่งคืนการรันนั้นกลับมาให้คุณ แทนที่จะบรรยายจากภายนอก

เหตุการณ์นี้ไม่ได้เป็นเรื่องที่หายากอีกต่อไป นับตั้งแต่เอเจนต์เริ่มทำงานจริง เอเจนต์จะไล่ดูทั่วรีโพซิทอรี แก้ไขหลายไฟล์ รันการตรวจสอบ และรายงานว่าสำเร็จ ทั้งหมดนี้เกิดขึ้นระหว่างพรอมป์สองครั้งที่คุณพิมพ์ห่างกันเพียงไม่กี่นาที ถ้าการแก้ไขหนึ่งในนั้นผิด คุณจะรู้ทีหลัง: หลังจากเทอร์มินัลถูกปิด หลังจากสกรอลแบ็กหายไป หลังจากกระบวนการที่อาจอธิบายตัวเองได้สิ้นสุดลงไปแล้ว สิ่งที่เกิดขึ้นต่อไปขึ้นอยู่กับสิ่งที่คุณเก็บไว้ล้วนๆ ถ้าคำตอบคือแดชบอร์ดค่าใช้จ่าย คุณกำลังจะได้ทำโบราณคดี ถ้าคำตอบคือการบันทึก คุณกำลังจะได้อ่าน

ความผิดพลาดที่คุณไม่สามารถทำซ้ำได้

นี่คือภาพรวมของปัญหา คุณกลับมาที่ repo และพบว่าไฟล์ที่คุณไม่เคยขอให้ใครแตะต้องถูกเขียนใหม่ หรือถูกลบ หรือถูกทำให้ว่างเปล่าจากฟังก์ชันที่ทุกอย่างอื่นต้องพึ่งพา คุณถาม agent ว่าเกิดอะไรขึ้น เซสชันถูกปิดไปแล้ว และแม้ในกรณีที่ transcript ยังหลงเหลืออยู่ บันทึกของ agent เกี่ยวกับการทำงานของมันเองก็เป็นเพียงการสร้างขึ้นใหม่ ไม่ใช่การบันทึกจริง ดังนั้นคุณจึงทำสิ่งที่เป็นธรรมชาติและรันมันอีกครั้ง แล้วคุณได้ผลลัพธ์ที่ต่างออกไป การเรียกใช้เครื่องมือที่ต่างออกไป การแก้ไขที่ต่างออกไป หรืออาจไม่มีข้อผิดพลาดเกิดขึ้นเลยก็ได้ เพราะเส้นทางเดิมนั้นขึ้นอยู่กับการสุ่มตัวอย่าง ขึ้นอยู่กับสถานะของ repo ขึ้นอยู่กับจังหวะเวลา การรันที่คุณจำเป็นต้องตรวจสอบนั้นไม่ได้มีอยู่อีกต่อไปแล้ว

มันแย่กว่าการที่ไม่สามารถทำซ้ำได้เสียอีก มันไม่สามารถทำซ้ำได้และถูกทำเครื่องหมายว่าประสบความสำเร็จ การรันหนึ่งครั้งจะออกด้วยรหัส 0 เมื่อเอเจนต์ออกด้วยรหัส 0 แม้ว่าการตรวจสอบภายในรันนั้นจะออกด้วยรหัส 1 ก็ตาม: ไปป์ไลน์สามารถเป็นสีเขียวได้ในขณะที่ขั้นตอนการตรวจสอบภายในรันล้มเหลว และรหัสออกที่คุณจะไว้วางใจโดยธรรมชาตินั้นไม่ได้บอกอะไรคุณเลย

ไม่สำคัญว่าเราเตอร์เลือกโมเดลใดสำหรับการรันครั้งนั้น (GLM 5.3 Flash หรืออะไรก็ตาม): เมื่อกระบวนการสิ้นสุดลง การใช้เหตุผลก็หายไปพร้อมกับมัน หลักฐานมีอยู่เพียงตอนที่การรันยังทำงานอยู่เท่านั้น: พรอมpt์, การเรียกใช้เครื่องมือ, ผลลัพธ์, และดิฟ หากไม่มีอะไรบันทึกไว้ คำถามที่ว่า “ทำไมมันถึงเปลี่ยนไฟล์นั้น” ก็ไม่มีคำตอบ มีเพียงทฤษฎีเท่านั้น

นี่คือรูปแบบความล้มเหลวที่แยกเอเจนต์เขียนโค้ด AIออกจากเครื่องมือทุกตัวที่มาก่อนพวกมัน: ความเสียหายและคำอธิบายเกิดขึ้นในที่เดียวกัน และที่แห่งนั้นก็ปิดลง

แดชบอร์ดวัดอะไร และมันข้ามอะไรไป?

สัญชาตญาณหลังจากที่ระบบทำงานได้ไม่ดีคือการเปิดแดชบอร์ดสำหรับการสังเกตการณ์ และแดชบอร์ดนั้นจะทำงานได้อย่างดีเยี่ยมในหน้าที่ของมัน หน้าที่ของมันคือการดูปริมาณการใช้งาน: โทเคนต่อวัน ต้นทุนต่อโมเดล ความหน่วงเวลา อัตราข้อผิดพลาด สำหรับการวางแผนกำลังการผลิตและการเรียกเก็บเงิน นี่คือเครื่องมือที่เหมาะสมอย่างยิ่ง และหากคุณรันเอเจนต์ในระบบการผลิต คุณควรเปิดมันไว้

แต่คำถามของคุณไม่ใช่คำถามแบบรวมกลุ่ม แต่เป็นแบบเฉพาะเจาะจงและเชิงสาเหตุ: ทำไมการรันครั้งนี้จึงเปลี่ยนแปลงไฟล์นี้? การรวมกลุ่มทำให้มองข้ามระดับความละเอียดที่ตอบคำถามนั้นได้พอดี เมื่อเฉลี่ยข้ามหลายๆ รัน การรันที่คุณสนใจกลายเป็นเพียงสัญญาณรบกวน และภายในรันนั้น การเรียกใช้เครื่องมือที่คุณสนใจก็กลายเป็นสัญญาณรบกวนอีกครั้ง

แดชบอร์ดอธิบายการรันจากภายนอกว่า มันเกิดขึ้น มันมีน้ำหนักเท่าใด และมันมีต้นทุนเท่าใด มันมอบการรันนั้นให้คุณไม่ได้ และ "ทำไม" ไม่ใช่คุณสมบัติของคำอธิบาย หากแต่เป็นคุณสมบัติของลำดับ

• การรันครั้งนี้มีค่าใช้จ่ายเท่าไร — Cost dashboard ตอบคำถามนี้ vs Recorded trace ตอบคำถามนี้

• เหตุใดเอเจนต์จึงเปลี่ยนไฟล์นั้น? — แดชบอร์ดต้นทุน: ไม่มีคำตอบ เทียบกับ เทรซที่บันทึกไว้: การแก้ไขตามลำดับพร้อม diff

• เช็คใดล้มเหลวในกรีนรัน? — Cost dashboard ไม่ตอบ เทียบกับ Recorded trace เช็คนั้นพร้อม exit code

• รันความล้มเหลวแบบเดิมซ้ำอีกครั้งได้ไหม — แดชบอร์ดต้นทุน: ไม่ได้ แต่เทรซที่บันทึกไว้: ได้ แบบออฟไลน์และไม่มีค่าใช้จ่าย

ชั้นที่ตอบคำถามนั้นอยู่เบื้องล่าง: ล็อกคำขอที่บันทึกไว้ ซึ่งถูกเก็บบันทึกในขณะที่การรันเกิดขึ้น พร้อมด้วยพรอมพ์ทุกตัวที่ส่งไป การเรียกใช้เครื่องมือทุกครั้ง และการตอบกลับทุกครั้งที่ส่งกลับมา ตามลำดับ ไม่ใช่บทสรุปของการรัน แต่คือตัวการรันเอง

การอ่านการรันหนึ่งครั้งเป็นไทม์ไลน์

การดีบักด้วยการบันทึก ทำให้มันเลิกเป็นเหมือนการขุดค้นโบราณคดี และกลายเป็นการอ่านหนังสือไปเลย โบราณคดีคือสิ่งที่คุณทำเมื่อไม่มีการบันทึก: {{1}}git reflog, stash entries, ประวัติ shell, ความทรงจำของคุณเองเกี่ยวกับสิ่งที่ขอไว้เมื่อตอนกลางวัน{{/1}} ส่วนการอ่านคือสิ่งที่คุณทำเมื่อมีการบันทึก: {{2}}เปิดไทม์ไลน์แล้วเลื่อนดู{{/2}}

ไทม์ไลน์จะแสดงลำดับการทำงานตามที่เกิดขึ้นจริง: พรอมป์ต์ที่เริ่มต้น การเรียกใช้เครื่องมือแต่ละครั้ง การแก้ไขไฟล์แต่ละครั้งพร้อม diff การตรวจสอบแต่ละครั้ง และรหัสออกแต่ละค่า ภาพรวมสถานะของระบบไฟล์จะถูกจับหนึ่งครั้งต่อรอบการสนทนา แทนที่จะจับทุกครั้งที่มีการเรียกใช้เครื่องมือ ซึ่งเพียงพอที่จะเห็นสถานะของ repo ในทุกขั้นตอนของการสนทนา โดยไม่จมอยู่กับสัญญาณรบกวนจากการเรียกใช้ในแต่ละครั้ง สิ่งที่ทำให้สิ่งนี้เป็นการดีบัก ไม่ใช่การเรียกดู คือการอยู่ติดกัน: การแก้ไขและการตรวจสอบที่จับข้อผิดพลาดได้วางอยู่เคียงข้างกัน ตามลำดับ โดยไม่มีอะไรคั่นกลางให้คาดเดา “ทำไม” ส่วนใหญ่เป็นคุณสมบัติของการอยู่ติดกัน

ตัวอย่างรูปธรรมที่อ่านจากบันทึกการแก้ไข: มี 14 เหตุการณ์ รวมถึงการเปลี่ยนแปลงไฟล์ที่พิมพ์เป็น +1 -3 และการตรวจสอบที่ล้มเหลวด้วย exit code 1 การแก้ไขและการตรวจสอบที่ล้มเหลวเนื่องจากการแก้ไขนั้นปรากฏอยู่ติดกันในบันทึก นี่คือความแตกต่างทั้งหมดระหว่างการสร้างรันขึ้นใหม่จากเศษชิ้นส่วนกับการอ่านจากบันทึกจริง มันสำคัญที่สุดสำหรับเอเจนต์เขียนโค้ดบนเทอร์มินัลซึ่งมีเทอร์มินัลเป็นพื้นที่ทำงานที่ปิดตัวลงทันทีที่งานเสร็จ: เส้นเวลาคือสกรอลล์แบ็กที่ยังหลงเหลืออยู่

บันทึกหรืออนุมาน: สิ่งที่ trace รู้เทียบกับสิ่งที่ trace คำนวณได้

ไทม์ไลน์บอกให้ทราบถึงสิ่งที่เกิดขึ้นตามลำดับ กราฟเชิงเหตุผลบอกให้ทราบว่าอะไรนำไปสู่อะไร และช่องว่างระหว่างทั้งสองสิ่งนี้คือจุดที่ความไว้วางใจต้องถูกสร้างขึ้น

กราฟเชื่อมโยงเหตุการณ์: การแก้ไขนี้ จากนั้นคือการตรวจสอบที่ล้มเหลวนี้ ขอบบางส่วนเป็นข้อเท็จจริงที่บันทึกไว้ เช่น การเรียกใช้เครื่องมือที่สร้าง diff นั้นอยู่ใน trace โดยตรง ส่วนอื่น ๆ ถูกอนุมาน เช่น ข้อสรุปของกราฟที่ว่าการตรวจสอบล้มเหลวเนื่องจาก diff นั้น orca graph ติดป้ายทุกขอบว่าบันทึกไว้หรืออนุมาน และระบุชื่อกฎที่ใช้ไม่ว่าจะกรณีใด คุณจึงรู้เสมอว่ากำลังดูสิ่งที่การรันได้ทำลงไป หรือสิ่งที่เครื่องมือคำนวณเกี่ยวกับการรัน

ความแตกต่างนั้นถูกบังคับใช้ ไม่ใช่เพียงแค่ความปรารถนา: เส้นเชื่อมที่ถูกอนุมานจะไม่ถูกเขียนกลับเข้าไปในเทรซ เทรซยังคงเป็นบันทึกที่เที่ยงตรงถึงสิ่งที่เกิดขึ้น การอนุมานคือมุมมองที่อยู่บนเทรซ ซึ่งคุณสามารถตรวจสอบ ตั้งคำถาม และโต้แย้งได้ เรื่องนี้สำคัญที่สุดเมื่อมีเอเจนต์มากกว่าหนึ่งตัวเข้ามาเกี่ยวข้อง เมื่อเอเจนต์รีแฟกเตอร์และเอเจนต์เขียนเทสต์แก้ไขไฟล์เดียวกัน คำถามที่ว่า 'เอเจนต์ใดเป็นต้นเหตุ' คือคำถามแท้จริงที่การระบุต้นเหตุแบบหลายเอเจนต์ มีไว้เพื่อตอบ เส้นเชื่อมที่แอบเลื่อนตัวเองจากการเป็นข้ออนุมานไปเป็นข้อเท็จจริง คือสิ่งที่ทำให้คุณลงเอยด้วยการดีบั๊กเรื่องเล่าแทนที่จะดีบั๊กรันจริง

ทำซ้ำได้บ่อยเท่าที่ต้องการโดยไม่มีค่าใช้จ่าย

การอ่านช่วยอธิบาย การเล่นซ้ำช่วยพิสูจน์ เมื่อคุณมีสมมติฐาน (การตรวจสอบล้มเหลวเพราะการแก้ไขได้ลบการเรียก reset ออกไป) คุณต้องการรันมันอีกครั้งและดูมันเกิดขึ้น การรันเอเจนต์จริงอีกครั้งทำให้คุณได้เส้นทางใหม่และค่าใช้จ่ายใหม่

การเล่นซ้ำการบันทึกทำให้คุณได้รันเดียวกัน: การรันซ้ำทำงานโดยบล็อกเครือข่าย ดังนั้นจึงไม่เสียโทเค็นและไม่มีความแปรปรวน เหตุการณ์เดียวกัน ทุกครั้ง แบบออฟไลน์ นี่คือคุณสมบัติที่เปลี่ยนการดีบักเอเจนต์จากการพนันเป็นวิศวกรรม: ความล้มเหลวกลายเป็นสิ่งที่กำหนดได้ และความล้มเหลวที่กำหนดได้จะได้รับการแก้ไข

เครื่องมือนี้ก็ไม่ใช่กล่องดำเช่นกันOrcaReplayเป็นโอเพนซอร์สภายใต้ Apache-2.0 และรูปแบบเทรซอยู่ภายใต้ CC BY 4.0 ดังนั้นใครก็อาจนำไปสร้างใหม่ได้: บันทึกของคุณจะไม่ตกเป็นตัวประกันของรูปแบบกรรมสิทธิ์ และของเราก็รวมอยู่ด้วย และมันถูกทดสอบจริง ไม่ใช่แค่สาธิต: มีการทดสอบ 1393 รายการบน Node 20 และ Node 22 คุณสามารถอ่านซอร์สโค้ด ตรวจสอบรูปแบบ และรันชุดทดสอบด้วยตัวเอง ก่อนจะวางใจให้มันดูแลการรันของทีมคุณ

ข้อสรุป

แดชบอร์ดคือใบแจ้งหนี้ เทรซที่บันทึกไว้คือการรันที่แท้จริง หากแผนการดีบักเอเจนต์ AI ของคุณไปจบลงที่แดชบอร์ดค่าใช้จ่าย คุณไม่ได้มีแผนการดีบัก แต่มีระบบเรียกเก็บเงิน แดชบอร์ดจะบอกคุณได้เสมอว่าการรันนั้นมีค่าใช้จ่ายเท่าไร แต่จะไม่มีวันบอกคุณได้ว่าทำไมเอเจนต์ถึงลบไฟล์ของคุณ เพราะ "ทำไม" อยู่ในลำดับเหตุการณ์ และลำดับเหตุการณ์จะคงอยู่ก็ต่อเมื่อคุณเก็บมันไว้

วิธีการทั้งหมดมีสี่ขั้นตอน:

บันทึกการวิ่ง

• อ่านไทม์ไลน์

• ตรวจสอบขอบของกราฟ

• เล่นซ้ำสิ่งที่ทำให้คุณกลัวได้ฟรี บ่อยเท่าที่ต้องการ

หมายเหตุด้านแหล่งข้อมูล: ตัวเลขทุกตัวในบทความนี้เป็นข้อมูลที่ผู้จำหน่ายรายงาน (vendor-reported) จากผลิตภัณฑ์ของเราเองและจากคลัง OrcaReplay พร้อมเอกสารประกอบ ได้แก่ พฤติกรรม exit-code ของการรันครั้งหนึ่ง การบันทึกการแก้ไข 14 เหตุการณ์พร้อม diff แบบ +1 -3 และการตรวจสอบ exit-1 การติดป้ายขอบใน orca graph จังหวะการสร้างสแนปช็อตหนึ่งครั้งต่อเทิร์น การรีเพลย์แบบออฟไลน์เมื่อบล็อกเครือข่ายไว้ และชุดทดสอบ 1393 รายการบน Node 20 และ Node 22 บทความนี้ไม่ได้อ้างอิงการวัดจากบุคคลที่สามที่ใดเลย ชุดทดสอบ 1393 รายการเป็นข้อกล่าวอ้างเพียงข้อเดียวที่คุณสามารถตรวจสอบได้ด้วยตนเอง โดยการโคลนคลังและรันมัน รายการทั้งหมดได้รับการตรวจสอบล่าสุดเมื่อวันที่ 2026-09-04