เอเจนต์ AI อัตโนมัติ 4 ตัว สามารถตรวจพบข้อผิดพลาดของซอฟต์แวร์ แก้ไขโค้ดที่มีปัญหา และยืนยันการแก้ไขได้ทั้งหมดภายในเวลาไม่ถึงหนึ่งนาที ต้องขอบคุณเวิร์กโฟลว์ใหม่ที่ขับเคลื่อนด้วย observability ซึ่งสร้างขึ้นสำหรับงาน SigNoz hackathon
ระบบนี้มีชื่อว่า AgentOps ทำหน้าที่เฝ้าดู SigNoz เพื่อตรวจจับการพุ่งสูงขึ้นของข้อผิดพลาด (error spikes) ดึง logs และ traces ที่เกี่ยวข้อง ระบุไฟล์และบรรทัดที่เกิดปัญหาได้อย่างแม่นยำ แก้ไขซอร์สโค้ดใน sandbox จากนั้นจึงส่งคำขอ (request) ซ้ำอีกครั้งเพื่อพิสูจน์ว่าบั๊กได้รับการแก้ไขแล้ว แต่ละรอบการทำงานจะเสร็จสิ้นภายใน 30-60 วินาที และกระบวนการทั้งหมดดำเนินไปได้โดยไม่ต้องมีการป้อนคำสั่ง (prompt) จากมนุษย์เลยแม้แต่ครั้งเดียว
ทำไม observability ถึงสำคัญสำหรับ AI agents
แนวทางปฏิบัติแบบ SRE ดั้งเดิมจะมองว่า logs, metrics และ distributed traces คือ "ดวงตา" ของบริการ เมื่อคำขอ (request) ล้มเหลว วิศวกรจะไล่ตาม trace ไปยังส่วนประกอบที่เป็นต้นเหตุ หลักการเดียวกันนี้กำลังขับเคลื่อน AgentOps แต่ "บริการ" ที่ถูกเฝ้าสังเกตในที่นี้ก็คือตัว AI agent เอง
ทุกเครื่องมือที่เอเจนต์เรียกใช้งาน ไม่ว่าจะเป็นการเรียกใช้ language model, การแก้ไขไฟล์ระบบ หรือการรันตัวทดสอบ (test runner) จะสร้าง span ขึ้นใน trace โดย span จะบันทึกเวลาเริ่มต้น ระยะเวลา และสถานะความสำเร็จ เพื่อให้เอเจนต์สามารถดูได้ว่าแต่ละขั้นตอนการใช้เหตุผล (reasoning step) ใช้เวลานานเท่าใดและสำเร็จหรือไม่ การนำ span เหล่านั้นมาเชื่อมต่อกันจะช่วยให้เอเจนต์สร้างภาพรวมของกระบวนการคิดของตัวเองได้อย่างสมบูรณ์ เหมือนกับที่มนุษย์ทำเมื่อทำการดีบั๊กด้วยตนเอง
การเปลี่ยนแปลงที่สำคัญคือการเปลี่ยนจาก "observability ในฐานะเลเยอร์การรายงานผล" ไปสู่ "observability ในฐานะการรับรู้" AgentOps จะป้อนข้อมูล trace กลับไปยังเอเจนต์ ช่วยให้พวกมันสามารถใช้เหตุผลเกี่ยวกับสิ่งที่ตัวเองทำได้แบบเรียลไทม์ ผลลัพธ์ที่ได้คือลูปที่ AI ไม่เพียงแต่สร้างสมมติฐานขึ้นมาเท่านั้น แต่ยังตรวจสอบสมมติฐานนั้นด้วย telemetry ชุดเดียวกับที่ใช้ในการตรวจพบปัญหาอีกด้วย
เวิร์กโฟลว์ 4 ขั้นตอน
- Monitor – ตัวเฝ้าสังเกต (watcher) ขนาดเล็กจะสแกน SigNoz เพื่อหาข้อผิดพลาดที่เพิ่งรายงานเข้ามาใหม่
- Diagnose – เอเจนต์จะดึง logs และ traces ที่เกี่ยวข้อง สกัด stack trace และระบุไฟล์ต้นทางรวมถึงเลขบรรทัดที่ทำให้เกิดความล้มเหลว
- Fix – เอเจนต์จะเขียน patch ลงในบรรทัดที่ระบุโดยใช้ sandboxed file-system server ซึ่ง sandbox จะบังคับใช้สิทธิ์การเข้าถึงที่เข้มงวดและทำการ rollback โดยอัตโนมัติหากการแก้ไขนั้นละเมิดนโยบาย
- Verify – เอเจนต์จะส่งคำขอเดิมซ้ำอีกครั้งกับโค้ดที่ได้รับการ patch แล้ว หาก trace แสดงผลการทำงานที่ปกติ การแก้ไขจะถูก commit แต่หากไม่เป็นเช่นนั้น เอเจนต์จะเริ่มทำซ้ำอีกครั้ง
ทุกขั้นตอนถูกจัดการโดยชุดเอเจนต์เดียวกัน โดยแต่ละตัวทำหน้าที่เป็น micro-service อัตโนมัติ ทั้งกระบวนการสามารถสังเกตได้ผ่าน span ที่รองรับ OpenTelemetry ซึ่ง SigNoz จะนำข้อมูลเข้ามาและแสดงผลในรูปแบบภาพ (visualise)
บทเรียนอันล้ำค่าด้านความน่าเชื่อถือ
ความชัดเจนของข้อผิดพลาด
สถานะ "failed" แบบกว้างๆ ไม่ได้บอกอะไรเลย ทีมงานจึงได้เพิ่มเหตุผลความล้มเหลวที่ละเอียดขึ้น เช่น "สมมติฐานผิด" หรือ "patch ทำให้กระบวนการพัง" เพื่อให้เอเจนต์ในขั้นตอนถัดไปสามารถตัดสินใจได้ว่าจะลองใหม่ (retry) ย้อนกลับ (backtrack) หรือยกเลิก (abort) ซึ่งเลียนแบบวิธีการระบุสาเหตุที่แท้จริง (root causes) ในการทำ post-mortem ของมนุษย์
ความหน่วงของข้อมูล
Telemetry ไม่ได้ปรากฏขึ้นในทันที ปัจจุบันเอเจนต์จึงมีการหยุดพักช่วงสั้นๆ และการตรวจสอบความถูกต้อง (sanity check) เพื่อให้แน่ใจว่า logs ที่จำเป็นมาถึงแล้วก่อนที่จะยืนยันการแก้ไข หากไม่มีการป้องกันนี้ เอเจนต์อาจดำเนินการโดยใช้ข้อมูลที่ไม่สมบูรณ์และทำให้เกิดผลลัพธ์ที่ผิดพลาด (false positive)
ขอบเขตความปลอดภัย
การอนุญาตให้ AI เขียนโค้ดมีความเสี่ยงเรื่องการยกระดับสิทธิ์ (privilege escalation) sandbox จึงทำงานอยู่หลัง filesystem server ที่แยกต่างหาก ซึ่งจะจำกัดขอบเขตการเขียนไว้เพียงแค่ repository เป้าหมายเท่านั้น และจะกู้คืนสถานะก่อนหน้าโดยอัตโนมัติหากการทดสอบล้มเหลว โมเดลการควบคุม (containment model) นี้ช่วยควบคุมอำนาจของ AI ให้อยู่ในขอบเขตที่เหมาะสม
ข้อจำกัดของ Token
Large language models ใช้ API tokens และโควตารายวันอาจหมดลงระหว่างการตรวจสอบ AgentOps จึงติดตามการใช้งาน token ต่อหนึ่งเหตุการณ์ และจะจำกัด (throttle) การเรียกใช้งานเพิ่มเติมเมื่อถึงเกณฑ์ที่กำหนด เพื่อป้องกันไม่ให้เกิดความล้มเหลวในการแก้ไขแบบต่อเนื่องเมื่อโควตาหมดลง
สิ่งที่การสาธิตพิสูจน์ให้เห็น
ทีมงานได้ใส่บั๊กใหม่เอี่ยมที่ไม่เคยปรากฏใน codebase มาก่อน AgentOps ตรวจพบความผิดปกติ ไล่สายไปยังบรรทัดที่ถูกต้อง สร้างการแก้ไขที่ถูกต้อง ใช้ patch ใน sandbox และยืนยันว่าคำขอสำเร็จ ทั้งหมดนี้เกิดขึ้นโดยไม่มีการแก้ไขโค้ดด้วยตนเองหรือการป้อน prompt ใหม่เลย เวลาที่ใช้ตั้งแต่ต้นจนจบยังคงไม่ถึงหนึ่งนาที ซึ่งตรงกับระยะเวลา 30-60 วินาทีที่รายงานไว้
มุมมองต่าง: ความเป็นอิสระไม่ใช่คำตอบสำหรับทุกปัญหา
สิ่งที่ต้องจับตามองต่อไป
- Telemetry ที่ไม่ยึดติดกับโมเดล – เมื่อผู้ให้บริการรายต่าง ๆ เริ่มเปิดเผย spans ที่รองรับ OpenTelemetry มากขึ้น แนวทางนี้อาจกลายเป็นกลางต่อผู้ให้บริการ (vendor-neutral) ซึ่งจะช่วยให้การนำไปใช้งานในเทคโนโลยีที่หลากหลาย (heterogeneous stacks) ทำได้ง่ายขึ้น
- กลไกการควบคุมที่ขับเคลื่อนด้วยนโยบาย – การฝังนโยบายที่สามารถกำหนดค่าได้เพื่อระบุว่าเอเจนต์สามารถแก้ไขไฟล์ใดได้บ้าง หรือชุดการทดสอบ (test suites) ใดบ้างที่ต้องผ่านก่อนการ commit จะช่วยตอบโจทย์ด้านการกำกับดูแล (governance)
- การจัดสรรงบประมาณโทเคนโดยคำนึงถึงต้นทุน – การจัดสรรโทเคนแบบไดนามิกตามความรุนแรงของเหตุการณ์สามารถป้องกันการใช้โควตาจนหมด ในขณะที่ยังคงความสามารถในการจัดการกับบั๊กที่มีผลกระทบสูงไว้ได้
AgentOps แสดงให้เห็นว่าวงจรการแก้ไขบั๊กสามารถใช้เวลาเพียง 30-60 วินาที การทดลองนี้เป็นการพิสูจน์แนวคิด (proof-of-concept) ว่าความสามารถในการสังเกตการณ์ (observability) สามารถนำมาใช้โดยผู้ช่วยซอฟต์แวร์อัตโนมัติได้