AI Agent Observability: สิ่งที่ต้องติดตามในโปรดักชัน
AI agent observability คือศาสตร์ของการบันทึกการเรียกเครื่องมือทุกครั้ง การเรียก LLM ทุกครั้ง และทุกดอลลาร์ที่เอเจนต์อัตโนมัติใช้ — จับการตัดสินใจที่ไม่เป็นเชิงกำหนด ต้นทุนสะสม และความพยายาม prompt injection ที่ APM แบบดั้งเดิมไม่เคยต้องจัดการ หากไม่มีสิ่งนี้ ฝูงโปรดักชันก็ดำเนินการบนความศรัทธา และเอเจนต์ที่ติดตัวเดียวสามารถเผาเวลา compute หลายชั่วโมงก่อนที่ใครจะเห็นบิล
AI agent observability คืออะไร
AI agent observability คือศาสตร์ของการจับ telemetry ที่มีโครงสร้างจาก AI agent อัตโนมัติ — execution trace, การใช้จ่าย token, เวอร์ชัน prompt, การตรวจสอบ tool call และเหตุการณ์ด้านความปลอดภัย — เพื่อให้วิศวกรสามารถ debug, กำกับดูแล และเพิ่มประสิทธิภาพเอเจนต์ที่รันในโปรดักชัน
TL;DR
- การ observe เอเจนต์ยากกว่าการ observe แอป เพราะ control flow ของเอเจนต์ถูกตัดสินโดย LLM ณ รันไทม์ ไม่ใช่จากโค้ดที่มนุษย์เขียน
- สัญญาณ 4 ตัวสำคัญ: trace แบบ end-to-end, ต้นทุนรายเอเจนต์, การจัดเวอร์ชัน prompt และโมเดล และการจับเหตุการณ์ด้านความปลอดภัย (ความพยายาม prompt injection, การปฏิเสธ ACL, การตัดงบประมาณ)
- agent framework ส่วนใหญ่ไม่มี observability ในตัว — ทีมต่อ LangSmith, Langfuse หรือ Arize Phoenix และค้นพบช่องว่างหลังเหตุการณ์โปรดักชันครั้งแรก
- แดชบอร์ด mesh ของ OpenLegion บันทึก tool call, request LLM, รายการต้นทุน และเหตุการณ์ความปลอดภัยทุกตัวเป็นค่าเริ่มต้น — ไม่มีโค้ด instrumentation ไม่มีการผสานเอเจนต์ของบุคคลที่สาม
- การ observe ต้นทุนคืองบประมาณที่คุณไม่รู้ว่ากำลังใช้อยู่: หากไม่มีเพดานรายเอเจนต์ เอเจนต์ที่ติดตัวเดียวสามารถเผาหลายร้อยดอลลาร์ในการเรียก API ในคืนเดียว
ทำไม AI Agent Observability จึงต่าง
Datadog, Honeycomb, New Relic — เครื่องมือ APM แบบดั้งเดิมทุกตัวสร้างบนสมมติฐานสองข้อ: path ของโค้ดเป็นเชิงกำหนด และ request handler เขียนโดยมนุษย์ เอเจนต์อัตโนมัติทำลายทั้งสองในสี่ทางเฉพาะ:
- control flow ถูกสร้าง ไม่ใช่เขียนเป็นโค้ด เอเจนต์ตัดสินใจ ณ รันไทม์ว่าจะเรียกเครื่องมือ, retry, ส่งต่อให้เอเจนต์อื่น หรือยอมแพ้
- ต้นทุนไร้ขอบเขตเป็นค่าเริ่มต้น การเรียก LLM แต่ละครั้งสามารถเชื่อมต่อกับการเรียกมากขึ้น หากไม่มีเพดานงบประมาณรายเอเจนต์ ลูปที่หลุดควบคุมคือใบแจ้งหนี้ที่หลุดควบคุม
- พื้นที่เสียคู่: การล้มเหลวมาตรฐาน (timeout, 5xx) บวกการล้มเหลวเฉพาะ LLM (ชื่อเครื่องมือที่ hallucinate, JSON ที่ผิดรูป, การปฏิเสธ, ความสำเร็จของ prompt injection)
- ความสามารถในการตรวจสอบเป็นข้อกำหนดด้านการปฏิบัติตาม ไม่ใช่ของแถม ทีมที่ถูกควบคุมต้องพิสูจน์ว่าเอเจนต์ทำอะไร เมื่อใด ด้วย prompt ใด บนข้อมูลของใคร
ผลกระทบในทางปฏิบัติ: แดชบอร์ด APM มาตรฐานบอกคุณว่าการรันเอเจนต์ใช้เวลา 12 วินาที ไม่ได้บอกว่าเอเจนต์เรียก LLM ไป 47 ครั้งกว่าจะถึงตรงนั้นเพราะ hallucinate ชื่อคอลัมน์ฐานข้อมูลในความพยายามที่ #3 และเข้าสู่ลูป retry
สัญญาณ 4 ตัวที่คุณต้องการจริง ๆ
1. Execution trace แบบ end-to-end
การรันเอเจนต์ทุกครั้งจำลองเป็นต้นไม้: งานแม่ → tool call → การเรียก LLM ไปกลับ → การส่งต่อเอเจนต์ลูก latency ระดับ span, สถานะ และ input/output อนุสัญญา semantic GenAI ของ OpenTelemetry กำลังบรรจบกันตรงนี้ เครื่องมือที่นำไปใช้ — Langfuse, Arize Phoenix, Helicone — ทำงานร่วมกันได้
2. ต้นทุนต่อเอเจนต์ ต่องาน ต่อผู้ให้บริการ
จำนวน token, การแปลงเป็นดอลลาร์ต่อผู้ให้บริการ และการรวมตามเอเจนต์ โครงการ และทีม ต้นทุนคือสัญญาณงบประมาณที่ควรตัดการเรียกใช้งานแบบเข้มงวด ไม่ใช่แค่กราฟหลังเหตุการณ์
3. การจัดเวอร์ชัน prompt และโมเดล
เมื่อเอเจนต์ regress มันคือการเปลี่ยน prompt, การอัปเกรดโมเดล หรือการดริฟต์ของข้อมูลต้นน้ำ หากไม่มี prompt ที่จัดเวอร์ชันและตรึงไว้กับการรัน คุณไม่สามารถบอกได้ Prompt registry (LangSmith Hub, Langfuse Prompts, Promptlayer) แก้สิ่งนี้ทั้งหมด รันไทม์ต้องบันทึกว่าการรันแต่ละครั้งใช้เวอร์ชันใดจริง ๆ
4. เหตุการณ์ด้านความปลอดภัย
ความพยายาม prompt injection, การปฏิเสธ ACL, การบล็อก SSRF, การตัดงบประมาณ, การ hit การกรอง unicode เหล่านี้คือเหตุการณ์ที่ผู้ตรวจสอบการปฏิบัติตามถาม — และเหตุการณ์ที่บ่งบอกการโจมตีกำลังเกิดขึ้นกับฝูงเอเจนต์ของคุณ
OpenLegion ติดตามอะไรเป็นค่าเริ่มต้น
| สัญญาณ | สิ่งที่จับ | ที่ดูได้ |
|---|---|---|
| Trace | ทุก tool call, request LLM, การส่งต่อเอเจนต์พร้อม timing | แดชบอร์ด mesh → Agent Runs |
| ต้นทุน | Token เข้า/ออก, ต้นทุนเป็นดอลลาร์ต่อผู้ให้บริการต่อเอเจนต์ | แดชบอร์ด → แผง Cost |
| Prompt | hash ของ system prompt, เวอร์ชัน, โมเดล, parameter ต่อการรัน | มุมมองรายละเอียดต่อการรัน |
| ความปลอดภัย | การปฏิเสธ ACL, การตัดงบประมาณ, การบล็อก SSRF, การ hit ตัวกรอง | แดชบอร์ด → log ความปลอดภัย |
| สุขภาพ | การใช้ resource ของคอนเทนเนอร์, latency ของ mesh, สถานะ browser pool | แดชบอร์ด → แผง Fleet |
แดชบอร์ดเป็นส่วนหนึ่งของรันไทม์โอเพนซอร์ส — ไม่ใช่บริการแบบจัดการที่ต้องสมัครสมาชิก การดีพลอย self-host เก็บ telemetry ทั้งหมดบนโครงสร้างพื้นฐานของคุณ
สแต็กการ Observe แบบโอเพนซอร์ส vs แบบจัดการให้
หากคุณรัน agent framework อื่น เครื่องมือเสริมชั้นนำคือ LangSmith (ระบบนิเวศ LangChain, จัดการให้), Langfuse (โอเพนซอร์ส, self-host ได้), Arize Phoenix (โอเพนซอร์ส, เน้นการประเมิน) และ Helicone (แบบ proxy, ผสานง่าย) แต่ละตัวต้องการโค้ด instrumentation ในเอเจนต์ของคุณ — wrap LLM client, เพิ่ม callback handler, ตั้งค่า trace exporter ภาระการผสานสเกลตามขนาดฝูงของคุณ
mesh ของ OpenLegion อยู่ใน path การเรียกของการดำเนินการเอเจนต์ทุกตัวโดยการออกแบบ — vault ข้อมูลรับรอง, ประตู ACL, ตัวติดตามต้นทุน และตัวบันทึก trace ทั้งหมดอยู่ร่วมในโซนที่เชื่อถือได้ ไม่มีขั้นตอน instrumentation ข้อแลกเปลี่ยน: คุณนำรันไทม์ OpenLegion มาใช้ ไม่ใช่แค่ชั้น observability
ดูการเปรียบเทียบ AI agent frameworkสำหรับภูมิทัศน์เต็ม หรือหน้า vs LangGraphสำหรับการเทียบเคียงด้าน observability โดยเฉพาะ
มุมมองของ OpenLegion
Agent observability คือ APM ใหม่ — และระบบนิเวศ AI กำลังทำซ้ำทุกข้อผิดพลาดที่ APM ใช้เวลาทศวรรษในการแก้ Telemetry แยกข้าม SDK เฉพาะผู้ขาย ราคาสเกลตามปริมาณ event ดังนั้นฝูงที่ยุ่งที่สุดจ่ายมากที่สุดเพื่อดูตัวเอง ฟีเจอร์ "ขั้นสูง" เช่นการเตือนและการคงข้อมูลอยู่หลังแพลนระดับองค์กร OpenLegion ยืนตรงข้าม: แดชบอร์ด, trace, ledger ต้นทุน และ log เหตุการณ์ความปลอดภัยมาพร้อมกับแพลตฟอร์ม AI agent ไม่ใช่การขายเพิ่ม การรันทุกตัวบันทึก trace เต็มเป็นค่าเริ่มต้น คุณ self-host ข้อมูล คุณเป็นเจ้าของการคงข้อมูล และคุณสามารถ export ไปยัง OpenTelemetry ได้หากต้องการส่งต่อไปยัง Datadog หรือ Honeycomb อยู่ดี
เอเจนต์โปรดักชันต้องการ observability ระดับโปรดักชัน — ในตัว ไม่ใช่ต่อเสริม
คำถามที่พบบ่อย
AI agent observability คืออะไร
AI agent observability คือการบันทึกพฤติกรรมรันไทม์ของเอเจนต์อัตโนมัติแบบมีโครงสร้าง — tool call, การเรียก LLM, เวอร์ชัน prompt, ต้นทุน และเหตุการณ์ด้านความปลอดภัย — เพื่อให้วิศวกร debug การล้มเหลว, เพิ่มประสิทธิภาพต้นทุน และตรวจสอบการตัดสินใจ มันแยกจาก APM แบบดั้งเดิมเพราะ control flow ของเอเจนต์ถูกตัดสินโดย LLM ไม่ใช่จากโค้ดที่มนุษย์เขียน
AI agent observability ต่างจาก LLM observability อย่างไร
LLM observability ติดตามการเรียกโมเดลแต่ละครั้ง — prompt, response, latency, ต้นทุน token AI agent observability ติดตามกราฟการเรียกใช้งานเต็มที่เอเจนต์เดินทางเพื่อทำงานให้สำเร็จ ซึ่งโดยทั่วไปเกี่ยวข้องกับการเรียก LLM หลายครั้งบวก tool call, การส่งต่อให้เอเจนต์อื่น, การ retry และการเปลี่ยน state LLM observability เป็นชุดย่อยของ agent observability
ฉันต้องการเครื่องมือ observability แยกหรือไม่หากใช้ Datadog อยู่แล้ว
Datadog และเครื่องมือ APM ที่คล้ายกันจัดการ latency, ข้อผิดพลาด และการใช้ resource ได้ดี แต่ไม่เข้าใจต้นทุน token LLM, การจัดเวอร์ชัน prompt หรือ semantic ของ agent trace เนทีฟ ทีมส่วนใหญ่จับคู่เครื่องมือ observability เนทีฟของเอเจนต์ (Langfuse, Arize Phoenix, LangSmith) กับ APM ที่มีอยู่ หรือนำรันไทม์อย่าง OpenLegion มาใช้ ซึ่งมาพร้อม telemetry ในตัวและ export OpenTelemetry ไปยัง APM ใดที่ใช้อยู่ได้
ฉันควรติดตามอะไรสำหรับ AI agent cost observability
ติดตามจำนวน token (input และ output) ต่อผู้ให้บริการต่อเอเจนต์ต่อการรัน, ต้นทุนเป็นดอลลาร์คำนวณตามราคาผู้ให้บริการปัจจุบัน, การรวมรายเอเจนต์รายวันและรายเดือน และเหตุการณ์ตัดงบประมาณเมื่อเอเจนต์ถูกหยุดเพราะเกินโควต้า หากไม่มีเพดานงบประมาณรายเอเจนต์ แม้แต่ observability ที่ดีเลิศก็บอกคุณเรื่องการหลุดควบคุมเฉพาะหลังบิลมา
AI agent observability ควรจับเหตุการณ์ด้านความปลอดภัยใดบ้าง
อย่างน้อย: การตรวจจับ prompt injection, การปฏิเสธ ACL (เอเจนต์พยายามดำเนินการนอกขอบเขตสิทธิ์), การบล็อก SSRF, การ hit การกรอง unicode และ path traversal, การตัดงบประมาณ และ log การเข้าถึง vault ข้อมูลรับรอง เหล่านี้คือเหตุการณ์ที่ผู้ตรวจสอบการปฏิบัติตามถาม และเหตุการณ์ที่บ่งบอกการโจมตีที่ใช้งานอยู่ต่อฝูงเอเจนต์ของคุณ
Observability ของ OpenLegion เทียบกับ LangSmith อย่างไร
LangSmith เป็นบริการ observability แบบจัดการสำหรับระบบนิเวศ LangChain — มีฟีเจอร์ tracing, การประเมิน และการจัดการ prompt ที่แข็งแกร่ง แดชบอร์ดของ OpenLegion มาพร้อมกับรันไทม์เอง, self-host เป็นค่าเริ่มต้น และบันทึกสัญญาณเดียวกัน (trace, ต้นทุน, prompt, เหตุการณ์ความปลอดภัย) โดยไม่ต้อง instrumentation ในโค้ดเอเจนต์ LangSmith ผสานข้าม framework ใดก็ตามที่นำมาใช้ OpenLegion observability ทำงานอัตโนมัติภายในรันไทม์ OpenLegion