การวิเคราะห์พฤติกรรมเอเจนต์: สิ่งที่ Claude Code เปิดเผยเกี่ยวกับ AI Agent ในระบบจริง

เมื่อวันที่ 31 มีนาคม 2026 มีรายงานสาธารณะระบุว่า Claude Code เวอร์ชันที่เผยแพร่ผ่าน npm มี source map หลุดรวมไปโดยไม่ตั้งใจ ทำให้ซอร์สโค้ด TypeScript ภายในจำนวนมากถูกเปิดเผย Ars Technica, Zscaler และสื่ออื่น ๆ รายงานว่ามีประมาณ 512,000 ถึง 513,000 บรรทัด ในไฟล์ TypeScript ราว 1,900 ไฟล์ Anthropic ชี้แจงว่าเหตุการณ์นี้เป็นปัญหาด้านการแพ็กเกจรีลีส และไม่มีข้อมูลลูกค้าที่ละเอียดอ่อนหรือข้อมูลรับรอง (credentials) เกี่ยวข้อง

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

สิ่งนี้ชี้ไปสู่ศาสตร์ใหม่ที่กำลังก่อตัว คือ การวิเคราะห์พฤติกรรมเอเจนต์ (Agent Behavior Analysis หรือ ABA) เป้าหมายคือการแปลงทุกการโต้ตอบ การเรียกโมเดล การเรียกเครื่องมือ การรออนุมัติ สถานะที่ถูกบล็อก ความสัมพันธ์ระหว่างเซสชัน และเหตุการณ์ด้านธรรมาภิบาล ให้กลายเป็นเทเลเมทรีที่สืบค้น เชื่อมโยง และตรวจสอบได้

Production Agent ไม่ใช่แค่ตัวห่อหุ้มโมเดล

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

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

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

• เอเจนต์เรียกใช้เครื่องมือใด?
• ขอบเขตสิทธิ์ใดถูกนำมาใช้?
• มนุษย์อนุมัติการกระทำนั้นหรือไม่?
• เอเจนต์ถูกบล็อกเพื่อรออินพุตจากผู้ใช้หรือไม่?
• เอเจนต์ย่อยได้รับบริบทที่ถูกต้องสืบทอดมาหรือไม่?
• การกระทำนี้เป็นของเซสชันหรือเซสชันแม่ใด?
• ข้อมูลใดเข้าสู่เทรซ และข้อมูลใดถูกปกปิด (redact)?

สิ่งเหล่านี้คือคำถามด้าน observability แต่ไม่ใช่คำถาม APM ทั่วไป

ชั้นของ Agent Observability ทั้งสามชั้นคืออะไร?

การวิเคราะห์สาธารณะที่ได้จากซอร์สอธิบายว่า Claude Code มีชั้น observability แยกกันสามชั้น ความแตกต่างนี้ใช้ได้แม้กับทีมที่สร้างรันไทม์เอเจนต์ของตัวเองตั้งแต่ต้น

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

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

ทำไม Correlation Key จึงสำคัญกว่าการมี Log มากขึ้น

ระบบเอเจนต์สืบสวนได้ยาก เพราะการกระทำเดียวกันอาจปรากฏในหลายรูปแบบ เอเจนต์อาจเป็น:

• เอเจนต์ย่อยในเครื่อง
• สมาชิกทีมใน swarm
• โพรเซสแบบสแตนด์อโลน
• เวิร์กเกอร์ที่เฟรมเวิร์กเป็นผู้จัดการ
• ผู้ช่วยเขียนโค้ดภายใน IDE
• ผู้เข้าร่วมเวิร์กโฟลว์ที่ถูกเรียกผ่าน MCP

การทำความเข้าใจทั้งหมดนี้ต้องอาศัย correlation key ที่คงที่:

• user.id
• session.id
• organization.id
• agentId
• parentSessionId
• agentType
• teamName

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

Semantic Span ดีกว่าการวัดเวลาระดับฟังก์ชัน

การติดตามแบบดั้งเดิมเริ่มจากฟังก์ชัน คำขอ และการเรียกฐานข้อมูล แต่การติดตามเอเจนต์ต้องใช้อนุกรมวิธานระดับสูงกว่า:

• agent.interaction
• agent.llm_request
• agent.tool
• agent.tool.blocked_on_user
• agent.tool.execution
• agent.hook

span blocked_on_user ควรได้รับความสนใจเป็นพิเศษ ในระบบเอเจนต์ เวลาไม่ได้มีแค่เวลาของเครื่อง การรออนุมัติ การยืนยันด้วยมือ เทิร์นที่ถูกขัดจังหวะ และการตัดสินใจของมนุษย์ ล้วนเป็นส่วนหนึ่งของเส้นทางรันไทม์

การแยกเวลาส่วนนี้ออกมาช่วยให้ทีมตอบคำถามที่คมชัดขึ้น:

• เทิร์นช้าเพราะโมเดลช้าหรือไม่?
• การทำงานของเครื่องมือช้าหรือไม่?
• เอเจนต์รอการอนุมัติจากผู้ใช้อยู่หรือไม่?
• เครื่องมือที่มีความเสี่ยงสูงถูกปฏิเสธบ่อยหรือไม่?
• เอเจนต์ย่อยหยุดชะงักเพราะขาดสิทธิ์หรือไม่?

นี่คือคุณค่าหลักของ Agent Behavior Analysis มันไม่ได้แสดงแค่ว่ามีการเรียก API ใด แต่แสดงว่าพฤติกรรมของเอเจนต์ดำเนินไปอย่างไร หยุดที่ไหน และขอบเขตใดกำหนดสิ่งที่เกิดขึ้นต่อไป

อนุกรมวิธานคือธรรมาภิบาล

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

อนุกรมวิธานที่ดีคือกลไกธรรมาภิบาล การวิเคราะห์สาธารณะที่ได้จากซอร์สของ Claude Code เน้นรูปแบบที่สำคัญต่อระบบองค์กร:

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

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

สิ่งที่ TrueWatch นำมาจากรูปแบบนี้

ทิศทางการออกแบบข้างต้นสอดคล้องกับแนวทางของ TrueWatch ต่อ AI agent observability

ข้อมูลยืดหยุ่น ไม่ผูกกับรูปทรงเอเจนต์ตายตัว ตัวตนของเอเจนต์ไม่ตายตัว ทีมอาจใช้ OpenClaw, Claude Code, Codex, เอเจนต์ภายใน, ผู้ช่วยที่เชื่อมต่อผ่าน MCP หรือเวิร์กโฟลว์เฉพาะผลิตภัณฑ์ โดยแต่ละตัวส่งฟิลด์ต่างกัน TrueWatch ถูกสร้างมาเพื่อรับข้อมูล observability ที่หลากหลายและทำให้สืบค้นได้ โดยไม่บังคับให้ทุกทีมใช้สคีมาเดียวกันที่ตายตัวตั้งแต่วันแรก เพราะฟิลด์ที่มีประโยชน์ถัดไปอาจเป็น sessionId, parentSessionId, skillName, teamName, approvalState หรือสิ่งที่ทีมยังไม่เคยต้องใช้

การรวบรวมและการประมวลผลแยกจากกัน DataKit รวบรวมเทเลเมทรีในสภาพแวดล้อมเป้าหมาย ส่วนการประมวลผลด้วย pipeline จะแยกวิเคราะห์ กรอง เพิ่มเติมข้อมูล และปกปิดข้อมูลก่อนถึงแพลตฟอร์ม สิ่งนี้สะท้อนบทเรียนจากการวิเคราะห์ Claude Code ว่าธรรมาภิบาลควรเริ่มใกล้จุดรวบรวม ไม่ใช่หลังจากข้อมูลกระจายไปทุกปลายทางแล้ว

DQL ให้ผู้ปฏิบัติงานมีระนาบการสืบค้นเดียว พฤติกรรมเอเจนต์ข้ามประเภทข้อมูล การสืบสวนครั้งเดียวอาจต้องใช้ trace span เมตริกโทเค็น log เหตุการณ์ บันทึกการอนุมัติ และข้อมูลบริการ DQL เชื่อมการเรียกเครื่องมือ trace ID ความผิดปกติของโทเค็น error log และความสัมพันธ์ของบริการเข้าด้วยกัน โดยไม่ต้องให้ใครสลับไปมาระหว่างระบบที่ไม่เกี่ยวข้องกัน

ให้ความสำคัญกับ High Cardinality Session ID, trace ID, agent ID, ชื่อเครื่องมือ เวอร์ชันโมเดล รูปแบบพรอมต์ และตัวระบุเวิร์กสเปซอาจเพิ่มขึ้นอย่างรวดเร็ว TrueWatch มอง cardinality เป็นปัญหาด้านสถาปัตยกรรม ไม่ใช่เชิงอรรถ เพื่อให้ทีมเก็บรายละเอียดที่มีประโยชน์ไว้ได้โดยไม่ทำให้แบ็กเอนด์ observability กลายเป็นเหตุการณ์ถัดไป

สี่สถานการณ์ในองค์กรสำหรับ Agent Behavior Analysis

1. การระบุที่มาของต้นทุนโทเค็น

เอเจนต์บริการลูกค้าเริ่มใช้งานจริง พอสิ้นเดือน ค่าใช้จ่าย API ของโมเดลสูงกว่าที่คาดไว้มาก log ของแอปพลิเคชันแสดงยอดการใช้งานรวม แต่ตอบคำถามที่แท้จริงไม่ได้ว่า สกิล เวอร์ชันพรอมต์ โมเดล หรือรูปแบบเซสชันใดที่ทำให้ค่าใช้จ่ายเพิ่มขึ้น

ด้วย Agent Behavior Analysis ทีมสามารถจัดกลุ่มการใช้โทเค็นตามแอปพลิเคชัน โมเดล สกิล เซสชัน เครื่องมือ หรือเวอร์ชันพรอมต์ ต้นเหตุมักเป็นเรื่องเล็ก เช่น สกิลประวัติคำสั่งซื้อใหม่ที่แบกบริบทมากเกินไปในแต่ละเทิร์น การแก้ไขมักง่าย แต่การมองเห็นต่างหากที่ยาก

2. การใช้เครื่องมือเสี่ยงและการหยุดฉุกเฉิน

เอเจนต์ปฏิบัติการได้รับสิทธิ์ให้รันงานบำรุงรักษาฐานข้อมูล แต่เงื่อนไขขอบเขตผิดพลาด ทำให้เอเจนต์เริ่มพยายามรัญการดำเนินการ SQL ประเภทอันตราย

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

3. เดดล็อกหลายเอเจนต์

ทีมรัน swarm ที่ประกอบด้วยเอเจนต์ด้านความต้องการ เอเจนต์เขียนโค้ด และเอเจนต์ทดสอบ เวิร์กโฟลว์ค้าง เอเจนต์ด้านความต้องการเชื่อว่าส่งมอบงานแล้ว ขณะที่เอเจนต์ทดสอบรอผลลัพธ์โค้ดที่ไม่เคยมาถึง

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

4. การตรวจสอบการปฏิบัติตามข้อกำหนดและการตรวจจับสิทธิ์เกินจำเป็น

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

Agent Behavior Analysis สามารถบันทึกได้ว่าในแต่ละขั้นตอนมีการใช้ MCP server เครื่องมือ ชุดข้อมูล และขอบเขตสิทธิ์ใด ความพยายามเรียกเซิร์ฟเวอร์ที่ไม่ได้รับอนุมัติหรือแหล่งข้อมูลดิบสามารถถูกบันทึก บล็อก และทบทวนได้ ไม่ใช่แค่การมอนิเตอร์ แต่เป็นส่วนหนึ่งของกลไกควบคุมการปฏิบัติตามข้อกำหนด

คำถามที่พบบ่อย

Q: Agent Behavior Analysis คืออะไร? A: Agent Behavior Analysis (ABA) คือแนวปฏิบัติในการแปลงทุกการโต้ตอบของเอเจนต์ ไม่ว่าจะเป็นการเรียกโมเดล การเรียกเครื่องมือ การรออนุมัติ สถานะที่ถูกบล็อก และความสัมพันธ์ระหว่างเซสชัน ให้เป็นเทเลเมทรีที่สืบค้น เชื่อมโยง และตรวจสอบได้ แทนที่จะมองกิจกรรมของเอเจนต์เป็น log แบบแบนราบ

Q: การรั่วไหลซอร์สของ Claude Code เปิดเผยอะไรจริง ๆ? A: ตามรายงานสาธารณะ ปัญหาการแพ็กเกจในรีลีส npm ของ Claude Code ทำให้ source map ซึ่งครอบคลุมประมาณ 512,000–513,000 บรรทัด ในไฟล์ TypeScript ราว 1,900 ไฟล์ ถูกเปิดเผย Anthropic ระบุว่าไม่มีข้อมูลลูกค้าที่ละเอียดอ่อนหรือข้อมูลรับรองถูกเปิดเผย

Q: ทำไม APM มาตรฐานจึงไม่เพียงพอสำหรับ AI Agent? A: APM มาตรฐานติดตามคำขอ ความหน่วง และสุขภาพของโครงสร้างพื้นฐาน ระบบเอเจนต์ต้องมีชั้นระดับเซสชันที่จำลองความหมายทางธุรกิจ ได้แก่ การเรียกเครื่องมือ การรออนุมัติ และการทำงานของ hook โดยยึดกับการโต้ตอบของผู้ใช้หนึ่งครั้ง ไม่ใช่แค่คำขอ HTTP

Q: Correlation key ใน agent observability คืออะไร? A: Correlation key คือตัวระบุที่คงที่ เช่น sessionId, agentId, parentSessionId และ teamName ที่ช่วยให้แพลตฟอร์ม observability สร้างภาพขึ้นมาใหม่ได้ว่าเอเจนต์ใดทำอะไร ในเซสชันใด และเซสชันแม่หรือทีมใดที่เอเจนต์นั้นสังกัดอยู่

Q: TrueWatch จัดการข้อมูลเอเจนต์ที่มี high cardinality อย่างไร? A: TrueWatch มอง cardinality เป็นเรื่องด้านสถาปัตยกรรมแทนที่จะเป็นเรื่องที่คิดทีหลัง ทีมจึงเก็บ session ID, trace ID, agent ID และรูปแบบพรอมต์ไว้ในระดับรายละเอียดที่จำเป็นต่อการสืบสวนได้ โดยไม่ทำให้แบ็กเอนด์ไม่เสถียร

Production Agent ทุกตัวต้องมี Behavior Analysis

ตามคำแถลงสาธารณะของ Anthropic เหตุการณ์ source map ของ Claude Code เป็นข้อผิดพลาดด้านการแพ็กเกจ ไม่ใช่การละเมิดข้อมูลลูกค้า บทเรียนที่กว้างกว่าของเหตุการณ์นี้คือเรื่องงานวิศวกรรมรันไทม์ของเอเจนต์

เอเจนต์ระดับโปรดักชันต้องมี observability ฝังอยู่ในการออกแบบ การวิเคราะห์ผลิตภัณฑ์ เทเลเมทรีมาตรฐาน การติดตามระดับเซสชัน semantic span คีย์เชื่อมโยง การควบคุมความเป็นส่วนตัว การจัดการ high cardinality และการเก็บกวาดเมื่อล้มเหลว ไม่ใช่ส่วนเสริมความสวยงาม แต่เป็นโครงสร้างพื้นฐาน

Claude Code ส่วนใหญ่สังเกตรันไทม์ของตัวเอง แต่ observability ระดับองค์กรมีงานที่ยากกว่า คือต้องสังเกตเอเจนต์หลากหลายประเภท ทั้งเอเจนต์แบบ white-box เอเจนต์ของเฟรมเวิร์ก เอเจนต์ภายในแบบปิด และเครื่องมือที่เชื่อมต่อผ่าน MCP โดยยังคงให้ข้อมูลสืบค้นได้ เชื่อมโยงกันได้ และอยู่ภายใต้ธรรมาภิบาล

นี่คือทิศทางของ observability สำหรับ Toby AI Agents คือทำให้ทุกการโต้ตอบ การเรียกเครื่องมือ การเรียกโมเดล การรออนุมัติ สถานะที่ถูกบล็อก และความสัมพันธ์ระหว่างเซสชัน มองเห็นได้เพียงพอให้ทีมดีบัก ตรวจสอบ และดำเนินงานได้

ลองใช้ TrueWatch ฟรี →