การติดตามการเรียกใช้เครื่องมือ AI Agent: บันทึกอะไรบ้างในทุกคำขอ

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

INFO  agent run started
INFO  calling tool: updateOrder
INFO  tool returned 200
INFO  agent run completed

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

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

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

สามชั้น หนึ่งร่องรอยการทำงาน

เอเจนต์สร้างเหตุการณ์ในสามระดับ และทีมส่วนใหญ่บันทึกแค่ระดับกลางเท่านั้น

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

ชั้นเครื่องมือ คือตัวดำเนินการของคุณ มันตรวจสอบพารามิเตอร์, ใช้บังคับนโยบาย, แมปการเรียกใช้กับคำขอ HTTP และจัดการผลลัพธ์

ชั้น HTTP คือการสื่อสารผ่านเครือข่าย เมธอด, URL, ส่วนหัว (headers), เนื้อหา (body), สถานะ, ความหน่วง

การดีบักมักจะข้ามชั้นต่างๆ เสมอ “เอเจนต์ส่ง ID ลูกค้าผิด” เป็นปัญหาด้านการให้เหตุผลที่มองเห็นได้เฉพาะที่ชั้น HTTP เท่านั้น “API ส่งคืนโค้ด 200 พร้อมเนื้อหาว่างเปล่า” เป็นปัญหา HTTP ที่ปรากฏเป็นการให้เหตุผลที่แปลกประหลาดในอีกสามขั้นตอนต่อมา หากสามชั้นนี้ไม่เชื่อมโยงกันด้วยตัวระบุร่วม คุณจะติดอยู่กับการเชื่อมโยงด้วยการประทับเวลา ซึ่งจะหยุดทำงานทันทีเมื่อมีการทำงานสองรายการทับซ้อนกัน

ดังนั้นกฎข้อแรกคือ: หนึ่ง Trace ID ต่อการทำงานของเอเจนต์หนึ่งครั้ง, หนึ่ง Span ID ต่อการเรียกใช้เครื่องมือหนึ่งครั้ง, และทั้งสองอย่างจะถูกประทับบนทุกบันทึกในทุกชั้น OpenTelemetry traces จำลองรูปแบบนี้ไว้อย่างแม่นยำอยู่แล้ว และมีชุด GenAI semantic conventions ที่เพิ่มขึ้นเรื่อยๆ สำหรับการตั้งชื่อแอตทริบิวต์เพื่อให้ข้อมูลของคุณเคลื่อนย้ายได้

สิ่งที่ต้องบันทึกในการเรียกใช้เครื่องมือแต่ละครั้ง

บันทึกที่ตอบคำถามที่แท้จริงได้มีรูปร่างประมาณนี้:

{
  "trace_id": "run_01J8ZK3M2Q",
  "span_id": "call_004",
  "parent_span_id": "call_003",
  "timestamp": "2026-08-26T14:03:11.482Z",
  "agent": "billing",
  "step": 4,

  "tool_name": "refundOrder",
  "tool_args": { "orderId": "ord_92", "amount": 1200, "reason": "duplicate" },
  "tools_available": ["getOrder", "listOrders", "refundOrder", "voidInvoice"],

  "http": {
    "method": "POST",
    "url": "/v1/orders/ord_92/refund",
    "request_body_hash": "sha256:1f4c...",
    "status": 200,
    "duration_ms": 412,
    "retry_count": 1,
    "idempotency_key": "9f2b7c14-6d3a-4b18"
  },

  "outcome": "success",
  "tokens": { "prompt": 8420, "completion": 96 },
  "policy": { "approval_required": true, "approved_by": "user_31", "dry_run": false }
}

ห้าฟิลด์ทำงานอย่างมีนัยสำคัญ

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

tools_available อธิบายการเลือก หากโมเดลเลือกเครื่องมือแปลกๆ คำถามแรกคือมีตัวเลือกอื่นอะไรอีกบ้าง ฟิลด์นี้ใช้พื้นที่เพียงไม่กี่ไบต์และให้คำตอบได้ทันที

retry_count แยกความแตกต่างระหว่าง “API ช้า” กับ “API ล้มเหลวสองครั้งแล้วจึงทำงานได้” หากไม่มีฟิลด์นี้ การพยายามสามครั้งจะดูเหมือนเป็นการเรียกใช้ครั้งเดียว

outcome ควรกำหนดเป็น enum ที่ชัดเจน ไม่ใช่สิ่งที่อนุมานจากรหัสสถานะ เช่น success, failed, timed_out, blocked_by_policy, rejected_by_human สองตัวสุดท้ายมีความสำคัญเนื่องจากการเรียกใช้ที่ถูกบล็อกเป็นการทำงานของ guardrail ไม่ใช่ข้อผิดพลาด และการนำมารวมกันจะทำให้ อัตราความล้มเหลวของคุณผิดเพี้ยนไป

policy คือบันทึกการตรวจสอบของคุณ เมื่อมีคนถามว่าการกระทำที่ก่อให้เกิดความเสียหายได้รับการอนุมัติหรือไม่ นี่คือคำตอบ มันจับคู่กับการบังคับใช้ที่อธิบายไว้ในโพสต์ของเราเกี่ยวกับ AI agent guardrails

บันทึกการตัดสินใจ ไม่ใช่แค่การกระทำ

ข้อผิดพลาดของเอเจนต์ที่ยากที่สุดคือการเลือก ดังนั้นให้บันทึกข้อมูลให้เพียงพอที่จะสร้างการตัดสินใจเหล่านั้นขึ้นมาใหม่ได้

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

บันทึกโมเดลและการตั้งค่าของมัน รหัสโมเดล (Model ID), อุณหภูมิ (temperature) และเวอร์ชันของพรอมต์ (prompt version) ควรอยู่ในบันทึกการทำงาน พฤติกรรมจะเปลี่ยนแปลงไปตามเวอร์ชันของโมเดล และหากไม่มีฟิลด์นี้ คุณอาจต้องใช้เวลาทั้งวันในการตรวจสอบโค้ดของคุณเอง

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

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

ปกปิดข้อมูลก่อนที่คุณจะจัดเก็บ

ร่องรอยการทำงานของเอเจนต์อันตรายเป็นพิเศษเพราะมันมีทั้งคำขอและการให้เหตุผลที่เกี่ยวข้อง และพรอมต์มักจะเก็บรวบรวมข้อมูลส่วนบุคคล

สี่กฎนี้จะช่วยให้จัดการได้

• ห้ามเก็บข้อมูลประจำตัว (credentials) โดยเด็ดขาด ลบ Authorization, API keys, คุกกี้ และ URL ที่ลงนามแล้ว บันทึกเพียงตัวระบุข้อมูลประจำตัว เช่น Key ID ไม่ใช่ค่าจริง โพสต์ของเราเกี่ยวกับ API keys ที่มีสิทธิ์น้อยที่สุดสำหรับเอเจนต์ ครอบคลุมเหตุผลที่คุณต้องการตัวระบุนั้น: มันบอกคุณว่าเอเจนต์ตัวไหนเป็นผู้กระทำ
• ปกปิดที่ขอบเขต ไม่ใช่ในคิวรี การกรองเมื่ออ่านหมายความว่าความลับถูกเขียนลงดิสก์, ถูกจำลอง และถูกสำรองไว้ ให้ปกปิดใน logging middleware ก่อนที่บันทึกจะออกจากกระบวนการ
• แฮชเนื้อหาที่คุณไม่สามารถจัดเก็บได้ การแฮชเนื้อหาคำขอยังคงช่วยให้คุณพิสูจน์ได้ว่าการเรียกใช้สองครั้งเหมือนกัน ซึ่งเป็นสิ่งที่คุณต้องการส่วนใหญ่สำหรับการตรวจสอบข้อมูลซ้ำซ้อน โดยไม่ต้องเก็บเพย์โหลดไว้
• กำหนดระยะเวลาการเก็บรักษาตามความอ่อนไหว ร่องรอยการทำงานแบบเต็มสำหรับหนึ่งสัปดาห์, สรุปที่ถูกปกปิดสำหรับหนึ่งปี การดีบักส่วนใหญ่เกิดขึ้นภายในไม่กี่วัน; คำถามเกี่ยวกับการตรวจสอบส่วนใหญ่มาถึงภายในไม่กี่เดือน

เปลี่ยนร่องรอยการทำงานให้เป็นชุดทดสอบ

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

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

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

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

สามการสอบสวนที่ร่องรอยการทำงานต้องอยู่รอด

• “เอเจนต์เรียกเก็บเงินผิดลูกค้า” คุณต้องมีพารามิเตอร์ที่โมเดลสร้างขึ้น, URL ที่ได้รับการแก้ไขแล้ว และขั้นตอนก่อนหน้านั้น เก้าในสิบครั้ง ID มาจากผลลัพธ์ของเครื่องมือก่อนหน้าที่คืนค่ามามากกว่าหนึ่งรายการ และโมเดลเลือกรายการแรก ร่องรอยการทำงานจะแสดงผลลัพธ์ก่อนหน้า ความกำกวม และการเลือก หากไม่มี tool_args คุณก็จะได้เพียง 200 และลูกค้าที่ไม่พอใจอย่างมาก
• “มันหยุดทำงานเมื่อวันอังคาร” เปรียบเทียบการทำงานที่ดีและการทำงานที่ผิดพลาดแบบฟิลด์ต่อฟิลด์ รหัสโมเดล, แฮชของชุดเครื่องมือ, เวอร์ชันพรอมต์, ขนาดการตอบสนองเฉลี่ย มีบางอย่างเปลี่ยนไป และหนึ่งในสี่สิ่งนั้นมักจะเป็นสาเหตุ นี่คือเหตุผลที่บันทึกการทำงานประกอบด้วยการกำหนดค่า ไม่ใช่แค่เหตุการณ์เท่านั้น: การเปรียบเทียบความแตกต่างจะทำได้ก็ต่อเมื่อทั้งสองฝ่ายบันทึกฟิลด์เดียวกัน
• “มีใครอนุมัติสิ่งนี้หรือไม่” บล็อกนโยบายคือคำตอบทั้งหมด และจะต้องถูกเขียนขึ้น ณ เวลาที่มีการตัดสินใจ ไม่ใช่สร้างขึ้นใหม่ในภายหลัง approval_required, approved_by และการประทับเวลาจะเปลี่ยนการสนทนาที่ตึงเครียดให้กลายเป็นการค้นหาข้อมูล

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

การสุ่มตัวอย่าง และสิ่งที่ไม่ควรสุ่มตัวอย่างโดยเด็ดขาด

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

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

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

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

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

ร่องรอยการทำงานควรอยู่ที่ไหน

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

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

มันไม่ได้มาแทนที่การติดตามที่อธิบายไว้ที่นี่ และก็ไม่ได้มาแทนที่รันไทม์ด้วยเช่นกัน; Claude Code และ Codex ยังคงทำงานอยู่ สิ่งที่มันเปลี่ยนไปคือที่ที่บันทึกจะไปอยู่เมื่อเอเจนต์ไม่ใช่บริการที่คุณได้ติดตั้งใช้งาน

เฝ้าดูสี่ตัวเลข

ร่องรอยการทำงานจะมีประโยชน์ก็ต่อเมื่อมีคนดูเท่านั้น ตัวเลขทั้งสี่นี้สมควรอยู่ในแดชบอร์ด

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

รายการตรวจสอบ

• หนึ่ง Trace ID ต่อการทำงานหนึ่งครั้ง, หนึ่ง Span ID ต่อการเรียกใช้เครื่องมือหนึ่งครั้ง, และประทับบนทั้งสามชั้น
• พารามิเตอร์ของโมเดลถูกบันทึกก่อนการปรับให้เป็นมาตรฐาน
• รายการเครื่องมือที่พร้อมใช้งานถูกบันทึกในการเรียกใช้ทุกครั้ง
• ผลลัพธ์ถูกบันทึกเป็น enum ที่ชัดเจน รวมถึงบล็อกนโยบาย
• จำนวนการลองใหม่แยกต่างหากจากจำนวนการเรียกใช้
• โมเดล, อุณหภูมิ, เวอร์ชันพรอมต์ และแฮชชุดเครื่องมือในบันทึกการทำงาน
• ผลลัพธ์ของเครื่องมือดิบถูกจัดเก็บไว้ ไม่ใช่แค่เวอร์ชันที่ตัดแต่งแล้วที่ส่งให้โมเดล
• ข้อมูลประจำตัวถูกลบใน middleware, เนื้อหาถูกแฮชในกรณีที่ไม่สามารถจัดเก็บได้
• การเก็บรักษาถูกจัดระดับตามความอ่อนไหวของข้อมูล
• ร่องรอยการทำงานที่ล้มเหลวสามารถแปลงเป็นชุดทดสอบที่เล่นซ้ำได้

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

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

• ฉันควรใช้ OpenTelemetry หรือเครื่องมือสังเกตการณ์เอเจนต์ที่สร้างขึ้นโดยเฉพาะดี? ใช้ OpenTelemetry สำหรับการขนส่งและโมเดลร่องรอยการทำงาน เนื่องจากมันจัดการการเชื่อมโยงอยู่แล้วและโครงสร้างพื้นฐานของคุณก็น่าจะรองรับ เครื่องมือเฉพาะสำหรับเอเจนต์จะเพิ่มมุมมองที่มีประโยชน์เข้ามา; ข้อมูลพื้นฐานยังคงควรเคลื่อนย้ายได้
• การติดตามแบบเต็มรูปแบบมีค่าใช้จ่ายในการจัดเก็บเท่าไหร่? น้อยกว่าที่คนส่วนใหญ่คาดไว้ หากคุณจัดลำดับชั้นข้อมูล เพย์โหลดแบบเต็มสำหรับไม่กี่วันและบันทึกข้อมูลแบบมีโครงสร้างที่ไม่มีเนื้อหาสำหรับระยะเวลานานขึ้นจะช่วยลดปริมาณข้อมูลส่วนใหญ่ลง การดัมพ์พรอมต์เป็นส่วนที่มีค่าใช้จ่ายสูง ดังนั้นให้แฮชและวัดขนาดแทนการจัดเก็บโดยค่าเริ่มต้น
• ฉันจำเป็นต้องบันทึกข้อความเหตุผลของโมเดลหรือไม่? โดยปกติแล้วไม่จำเป็น เครื่องมือที่มันเลือก, พารามิเตอร์ที่มันสร้าง และตัวเลือกที่มีอยู่จะอธิบายการตัดสินใจส่วนใหญ่ได้ ในกรณีที่ผู้ให้บริการเปิดเผยเนื้อหาเหตุผล ให้จัดเก็บเฉพาะการทำงานที่ล้มเหลวและถือว่าเป็นข้อมูลที่ละเอียดอ่อน
• ฉันจะติดตามการทำงานข้ามเอเจนต์หลายตัวได้อย่างไร? ใช้ Trace ID เดียวกันสำหรับงานทั้งหมด และให้แต่ละเอเจนต์มี Span ของตนเอง โดยมีการบันทึกการส่งมอบงาน (handoff) เป็นเหตุการณ์ โพสต์ของเราเกี่ยวกับ การส่งมอบงานระหว่างหลายเอเจนต์ ครอบคลุมสิ่งที่ควรอยู่ในบันทึกการส่งมอบนั้น
• จะเกิดอะไรขึ้นหากเอเจนต์ทำงานบนเครื่องของลูกค้า? บันทึกข้อมูลในเครื่อง, ปกปิดข้อมูลอย่างเข้มงวด และส่งเฉพาะเมตริกแบบรวมเท่านั้น เว้นแต่ผู้ใช้จะเลือกเข้าร่วม ชื่อเครื่องมือ, ผลลัพธ์ และระยะเวลาการทำงาน มักจะเพียงพอสำหรับการตรวจสอบระดับ fleet โดยไม่ต้องส่งเพย์โหลดออกจากอุปกรณ์
• แฮชเนื้อหาคำขอมีประโยชน์จริงหรือไม่? ใช่ สำหรับคำถามที่พบบ่อยที่สุด มันพิสูจน์ได้ว่าการเรียกใช้สองครั้งเหมือนกัน ซึ่งช่วยแก้ไขการสอบสวนการเขียนซ้ำซ้อนส่วนใหญ่ โดยไม่ต้องเก็บเพย์โหลดเอง จับคู่กับ idempotency keys ที่ควรจะป้องกันการซ้ำซ้อนได้