เอเจนต์ของคุณทำงานได้ดีในการสาธิต มันอ่านตั๋ว เรียกใช้ API สามตัว และโพสต์สรุปที่ชัดเจน จากนั้นคุณก็ปล่อยมันออกสู่ตลาด หนึ่งสัปดาห์ต่อมา มันส่งอีเมลถึงลูกค้ารายเดิมสองครั้ง ใช้โทเค็นจนหมดงบประมาณหนึ่งวันในการวนซ้ำการลองใหม่ (retry loop) และส่งเพย์โหลดที่ส่วนหน้าของคุณไม่สามารถประมวลผลได้
ช่องว่างระหว่างต้นแบบที่ใช้งานได้จริงกับเอเจนต์ที่เชื่อถือได้คือจุดที่ทีมส่วนใหญ่ประสบปัญหา ตัวโมเดลเองมักจะไม่ใช่ต้นเหตุของปัญหา ปัญหาอยู่ที่ส่วนที่มักถูกมองข้าม: การเรียกใช้ API ที่เอเจนต์ทำระหว่างทางเพื่อหาคำตอบ เอเจนต์คือการวนซ้ำของการเรียกใช้เครื่องมือ (tool calls) และการเรียกใช้เครื่องมือแต่ละครั้งคือคำขอ HTTP ที่อาจล้มเหลว, ถูกจำกัดความเร็ว (throttle), หมดเวลา (time out) หรือส่งคืนบางสิ่งที่คุณไม่ได้คาดหวัง หากคุณข้ามการทดสอบการเรียกใช้เหล่านั้นเหมือนที่คุณทดสอบ API ที่ใช้งานจริง เอเจนต์ของคุณก็อาจเกิดเหตุการณ์ไม่คาดฝันได้จากเพียงการตอบสนองที่ไม่ถูกต้องเพียงครั้งเดียว
นี่คือส่วนที่น่าอุ่นใจ: ความน่าเชื่อถือของเอเจนต์สามารถทดสอบได้ คุณไม่จำเป็นต้องเชื่อว่าโมเดลจะทำงานได้อย่างถูกต้องเสมอไป คุณควรทดสอบเส้นทางความล้มเหลวโดยเจตนา ก่อนที่ผู้ใช้ของคุณจะพบมันเอง คู่มือนี้จะจัดประเภทความล้มเหลวของเอเจนต์ออกเป็นห้าโหมด และแสดงวิธีแก้ไขแต่ละโหมด งานนี้เกิดขึ้นที่ขอบเขตของ API ดังนั้นคุณจึงต้องมีแพลตฟอร์มที่สามารถชี้ไปยังการพึ่งพิง (dependencies) ของเอเจนต์เพื่อออกแบบสัญญา (contract), จำลองความล้มเหลว (mock the failures) และตรวจสอบผลลัพธ์ที่ส่งกลับมา Apidog ทำหน้าที่นั้นได้ และจะแสดงตัวอย่างการทำงานด้านล่าง
เอเจนต์ล้มเหลวที่ขอบเขตของ API ไม่ใช่ที่พร้อมต์
เมื่อเอเจนต์ทำงานผิดปกติในการใช้งานจริง สัญชาตญาณคือการแก้ไขพร้อมต์ บางครั้งก็ช่วยได้ แต่บ่อยครั้งความล้มเหลวไม่ได้เกี่ยวข้องกับการใช้คำพูด เอเจนต์ร้องขอข้อมูลจาก API จริง และการตอบสนองนั้นช้า, ผิดรูปแบบ, ถูกจำกัดจำนวนครั้ง (rate-limited) หรือมีรูปแบบที่แตกต่างจากที่เอเจนต์คาดไว้ จากนั้นโมเดลก็ใช้เหตุผลจากอินพุตที่ไม่ดีและทำบางสิ่งที่มั่นใจแต่ผิดพลาด
ลองดูว่าขั้นตอนเดียวของเอเจนต์ประกอบด้วยอะไรบ้าง โมเดลเลือกเครื่องมือ โค้ดของคุณเปลี่ยนการเลือกนั้นให้เป็นคำขอ HTTP บริการภายนอกตอบกลับ โค้ดของคุณป้อนผลลัพธ์กลับไปยังโมเดล มีการส่งต่อสี่ครั้ง และสามในนั้นเป็นการรวม API ทั่วไป ไม่ใช่การเรียนรู้ของเครื่อง (machine learning) นี่เป็นข่าวดี เพราะการรวม API เป็นปัญหาที่แก้ไขได้ด้วยการทดสอบ คุณรู้วิธีจำลองจุดเชื่อมต่อที่ช้า (mock a slow endpoint) หรือยืนยันกับโครงสร้าง JSON (assert on a JSON schema) อยู่แล้ว เอเจนต์เพิ่มความเสี่ยง เนื่องจากโมเดลจะดำเนินการตามสิ่งที่ได้รับแทนที่จะส่งข้อยกเว้นที่ชัดเจน
ดังนั้นคำถามเกี่ยวกับความน่าเชื่อถือจึงไม่ใช่ “โมเดลฉลาดพอหรือไม่” แต่เป็น “ฉันได้ทดสอบทุกวิถีทางที่การเรียกใช้ API ของเอเจนต์อาจผิดพลาดไปหรือไม่” ห้าโหมดนี้ครอบคลุมปัญหาเกือบทั้งหมด
โหมดความล้มเหลวที่ 1: การเรียกใช้เครื่องมือที่เบี่ยงเบนจากสัญญา
ความล้มเหลวของเอเจนต์ที่พบบ่อยที่สุดคือการเรียกใช้เครื่องมือที่ไม่ตรงกับ API ที่กำลังเรียก โมเดลอาจสร้างพารามิเตอร์ขึ้นมาเอง, ลืมส่งฟิลด์ที่จำเป็น, ส่งสตริงในตำแหน่งที่สคีมาต้องการจำนวนเต็ม หรือเรียกใช้จุดเชื่อมต่อที่ถูกต้องแต่มีอาร์กิวเมนต์ที่ไม่มีความหมาย สมมติว่าเอเจนต์จองเรียกใช้ POST /reservations ด้วย guests: "two" แทนที่จะเป็น guests: 2 API อาจส่งคืนรหัส 400 หรือแย่กว่านั้นคือ 200 พร้อมข้อผิดพลาดที่ซ่อนอยู่ในเนื้อหา และเอเจนต์ก็ดำเนินการต่อไปราวกับว่าสำเร็จแล้ว
คุณสามารถตรวจจับสิ่งนี้ได้ด้วยการทดสอบการเรียกใช้เครื่องมือในฐานะสัญญา กำหนดสคีมาสำหรับเครื่องมือแต่ละตัวที่เอเจนต์สามารถเรียกใช้ได้ จากนั้นยืนยันว่าคำขอที่ส่งออกไปตรงตามข้อกำหนด: ฟิลด์ที่จำเป็นมีอยู่, ประเภทถูกต้อง, ค่า enums ใช้ได้ เมื่อเอเจนต์สร้างการเรียกใช้ที่ละเมิดสัญญา คุณต้องการให้สิ่งนั้นล้มเหลวอย่างชัดเจนในการทดสอบ ไม่ใช่เงียบๆ ในการใช้งานจริง บทแนะนำของเราเกี่ยวกับการ ทดสอบการเรียกใช้เครื่องมือของ AI agent จะเจาะลึกในเรื่องนี้ และวิธีการที่กว้างขึ้นสำหรับการ ทดสอบเอเจนต์ที่เรียกใช้ API ของคุณ ครอบคลุมการตั้งค่าตั้งแต่ต้นจนจบ
การดำเนินการที่เป็นประโยชน์: รวบรวมสคีมาของเครื่องมือที่เอเจนต์ของคุณใช้ โหลดลงใน Apidog และเรียกใช้การเรียกเครื่องมือจริงของเอเจนต์เทียบกับคำจำกัดความเหล่านั้น ความไม่ตรงกันจะปรากฏเป็นความล้มเหลวในการตรวจสอบ (validation failures) โดยระบุฟิลด์ที่ผิดพลาดอย่างชัดเจน
โหมดความล้มเหลวที่ 2: ข้อผิดพลาดต้นทางและการจำกัดจำนวนครั้ง
การเรียกใช้ภายนอกทุกครั้งที่เอเจนต์ทำสามารถส่งคืนรหัส 429, 500 หรือไม่มีอะไรเลยก่อนที่จะหมดเวลา เอเจนต์ที่สร้างมาอย่างดีจะจัดการสิ่งเหล่านี้ด้วยการลองใหม่ (retries) และการถอยกลับ (backoff) เอเจนต์ที่เปราะบางอาจยอมแพ้ตั้งแต่ข้อผิดพลาดแรก หรือที่อันตรายกว่านั้นคือพยายามลองใหม่มากเกินไปจนกระตุ้นให้เกิดการจำกัดความเร็วเพิ่มขึ้นและวนซ้ำจนใช้งบประมาณของคุณหมด คำถามที่ถูกถามบ่อยที่สุดในกระดานสนทนา Anthropic SDK คือเกี่ยวกับ รูปแบบสำหรับการกู้คืนข้อผิดพลาดของเอเจนต์ ซึ่งแสดงให้เห็นว่าปัญหานี้พบบ่อยเพียงใด
คุณไม่สามารถทดสอบการกู้คืนกับ API ที่ทำงานปกติได้ เพราะ API ที่ทำงานปกติไม่เคยส่งคืนข้อผิดพลาดที่คุณต้องจัดการ นี่คือจุดที่การจำลอง (mocking) เข้ามามีบทบาทสำคัญ สร้างการจำลองการพึ่งพิงของเอเจนต์ (mock of the agent’s dependency) และกำหนดลำดับ: รหัส 429 พร้อมเฮดเดอร์ Retry-After จากนั้น 500 แล้วตามด้วยความสำเร็จ ตอนนี้ให้ดูว่าเอเจนต์ของคุณทำอะไร มันถอยกลับด้วยความผันผวน (jitter) หรือไม่? มันเคารพเฮดเดอร์หรือไม่? มันยอมแพ้อย่างนุ่มนวลหลังจากพยายามมาหลายครั้งแล้วหรือไม่ หรือเปิดวงจรเบรกเกอร์ (circuit breaker) เพื่อหยุดการโจมตีบริการที่ล่มอย่างชัดเจน? และหากการกระทำที่ลองใหม่ไม่เป็นแบบ Idempotent การทำซ้ำจะส่งผลให้เรียกเก็บเงินสองครั้งหรือส่งซ้ำสองครั้งหรือไม่? คีย์ Idempotency คือสิ่งที่ทำให้การลองใหม่ปลอดภัยที่จะทำซ้ำ
การจำกัดจำนวนครั้ง (Rate limits) ควรได้รับการทดสอบเป็นพิเศษ หากคุณยังไม่เคยเห็นว่าเอเจนต์ของคุณมีพฤติกรรมอย่างไรเมื่อผู้ให้บริการจำกัดความเร็ว โปรดอ่านคู่มือของเราเกี่ยวกับ ความหมายของการตอบสนองที่เกินขีดจำกัดจำนวนครั้ง จากนั้นจำลองสถานการณ์ดังกล่าว คู่มือเฉพาะเรื่อง การกู้คืนข้อผิดพลาดของ AI agent ครอบคลุมรูปแบบการลองใหม่, การหมดเวลา, การถอยกลับ และวงจรเบรกเกอร์อย่างละเอียด
โหมดความล้มเหลวที่ 3: ผลลัพธ์ที่ไม่แน่นอน
แม้จะตั้งค่าอุณหภูมิเป็นศูนย์ คุณก็ยังไม่ได้รับผลลัพธ์ที่เหมือนกันทุกไบต์ในการรันแต่ละครั้ง นักพัฒนาค้นพบสิ่งนี้อยู่เสมอ มี เธรด vLLM ที่ยาวเหยียดเกี่ยวกับ seed และอุณหภูมิที่ไม่เพียงพอสำหรับการทำซ้ำได้ การเปลี่ยนแปลงด้านฮาร์ดแวร์, การรวมกลุ่ม (batching) และฝั่งผู้ให้บริการ ล้วนทำให้เกิดความแปรปรวน หากการทดสอบของคุณยืนยันสตริงที่ตรงเป๊ะ การทดสอบเหล่านั้นจะกลายเป็นแบบไม่เสถียร (flaky) และการทดสอบที่ไม่เสถียรก็จะถูกละเลย ซึ่งแย่กว่าไม่มีการทดสอบเลย สรุปของเราเกี่ยวกับ สาเหตุของการทดสอบที่ไม่เสถียร สามารถนำมาใช้ได้โดยตรงที่นี่
วิธีแก้คือการยืนยันที่โครงสร้างและความหมาย ไม่ใช่ที่ข้อความที่ตรงเป๊ะ ตรวจสอบว่าการตอบสนองถูกต้องตามสคีมา JSON ตรวจสอบว่าการเรียกใช้เครื่องมือมีรูปแบบและเป้าหมายที่ถูกต้อง ตรวจสอบว่าคำตอบที่เป็นตัวเลขอยู่ในช่วงที่สมเหตุสมผล ตรวจสอบว่ามีคีย์ที่จำเป็นและไม่มีฟิลด์ที่ต้องห้าม การทดสอบที่ระบุว่า “การตอบกลับมี total อยู่ระหว่าง 0 ถึงมูลค่าตะกร้าสินค้า” จะยังคงใช้งานได้แม้มีความแปรปรวนตามธรรมชาติของโมเดล และยังคงสามารถตรวจจับการถดถอยที่แท้จริงได้ คู่มือเกี่ยวกับ การทดสอบ AI agent ที่ไม่แน่นอน แสดงชุดกลยุทธ์ทั้งหมด และบทความเกี่ยวกับ วิธีการทำงานของหน่วยความจำเอเจนต์ แสดงให้เห็นว่าทำไมสถานะถึงทำให้เรื่องนี้ยากขึ้น
โหมดความล้มเหลวที่ 4: ค่าใช้จ่ายที่ควบคุมไม่ได้
เอเจนต์วนซ้ำ และการวนซ้ำก็มีค่าใช้จ่าย เอเจนต์ที่ติดขัดเพียงตัวเดียวที่พยายามเรียกซ้ำข้อผิดพลาดหลายพันครั้ง สามารถเปลี่ยนค่าใช้จ่ายเล็กน้อยให้เป็นจำนวนมากได้ในชั่วข้ามคืน รายงานภาคสนามหนึ่งฉบับในการสนทนา SDK อธิบายถึงการลดค่าใช้จ่ายของเอเจนต์จาก 500 ดอลลาร์ต่อเดือนเหลือ 80 ดอลลาร์โดยไม่สูญเสียคุณภาพ ซึ่งแสดงให้เห็นทั้งความเร็วที่ค่าใช้จ่ายเพิ่มขึ้น และช่องว่างที่มักจะซ่อนอยู่ในการออกแบบ
ค่าใช้จ่ายเป็นปัญหาด้านความน่าเชื่อถือ ไม่ใช่แค่ปัญหาทางการเงินเท่านั้น เพราะข้อผิดพลาดที่ทำให้สิ้นเปลืองเงิน (การวนซ้ำ, การเรียกซ้ำซ้อน, บริบทที่ใหญ่เกินไป) ยังทำให้เอเจนต์ทำงานช้าและคาดเดาไม่ได้อีกด้วย ติดตามโทเค็นต่อการรัน, จำกัดงบประมาณต่องาน และแคชเท่าที่คุณทำได้ สำหรับด้าน Command-line คู่มือของเราเกี่ยวกับ การลดค่าใช้จ่ายโทเค็นของเอเจนต์ มีวิธีดำเนินการที่เป็นรูปธรรม เมื่อคุณทดสอบเส้นทางการกู้คืนเทียบกับการจำลอง ให้สังเกตจำนวนการเรียกใช้ด้วย เอเจนต์ที่สำเร็จแต่ต้องเรียกใช้ถึงสี่สิบครั้งกว่าจะถึงจุดนั้น ถือเป็นเหตุการณ์ที่อาจเกิดค่าใช้จ่ายสูงรออยู่
โหมดความล้มเหลวที่ 5: การขาดราวกั้นความปลอดภัย (guardrails)
ความล้มเหลวที่เจ็บปวดที่สุดคือเมื่อเอเจนต์ทำตามที่ได้รับคำสั่งอย่างถูกต้อง แต่ผลลัพธ์ยังคงไม่ดี มันส่งอีเมล, ลบข้อมูล หรือสั่งซื้อ เพราะไม่มีอะไรขวางกั้นระหว่างการตัดสินใจของโมเดลกับการกระทำจริง กระดาน SDK มีเธรดที่น่าจดจำเกี่ยวกับเอเจนต์ที่ส่งอีเมลเวลาตีสามถึงเจ้านายของใครบางคน ครั้งแรกตลก ครั้งที่สองแพง
ราวกั้นความปลอดภัย (Guardrails) เปรียบเสมือนเข็มขัดนิรภัย กำหนดรายการที่อนุญาต (allowlist) สำหรับการกระทำที่เอเจนต์สามารถทำได้โดยไม่ต้องมีการอนุมัติ กั้นการเรียกใช้ที่ทำลายล้างหรือไม่สามารถย้อนกลับได้ด้วยการยืนยันจากมนุษย์ ให้เอเจนต์มีโหมด dry-run ที่อธิบายว่าจะทำอะไรโดยไม่ต้องดำเนินการจริง จากนั้นทดสอบว่าราวกั้นความปลอดภัยใช้งานได้: จำลองจุดเชื่อมต่อที่มีผลข้างเคียง (side-effecting endpoint), รันเอเจนต์ และยืนยันว่ามันเข้าสู่เส้นทางการยืนยันแทนที่จะดำเนินการจริง แนวทางความปลอดภัยเช่น OWASP Top 10 สำหรับแอปพลิเคชัน LLM เป็นรายการตรวจสอบที่แข็งแกร่งสำหรับสิ่งที่ควรป้องกัน คู่มือเกี่ยวกับ ราวกั้นความปลอดภัยของ AI agent ครอบคลุมเกตการอนุมัติ (approval gates) และการควบคุมขอบเขตความเสียหาย (blast-radius control) อย่างลึกซึ้ง
วิธีการจัดโครงสร้างการทดสอบเอเจนต์
ห้าโหมดนี้มีรูปแบบการทดสอบร่วมกัน และคุณสามารถนำกลับมาใช้ใหม่ได้:
- รวบรวมสคีมาของเครื่องมือที่เอเจนต์ของคุณสามารถเรียกใช้ได้ เพื่อให้คุณมีสัญญาสำหรับยืนยัน
- จำลองการพึ่งพิงแต่ละรายการเพื่อให้คุณควบคุมเวลา, รหัสสถานะ และเนื้อหา และเพื่อหลีกเลี่ยงผลข้างเคียงจริง
- ขับเคลื่อนเอเจนต์ผ่านสถานการณ์ต่างๆ รวมถึงเส้นทางที่ไม่พึงประสงค์ที่ API จริงจะไม่สร้างขึ้นตามคำขอ
- ยืนยันสิ่งที่เอเจนต์ส่งและวิธีการตอบสนอง: รูปแบบคำขอ, พฤติกรรมการกู้คืน, จำนวนการเรียกใช้ และไม่ว่าราวกั้นความปลอดภัยจะทำงานหรือไม่
วนซ้ำขั้นตอนนั้นสำหรับเครื่องมือหนึ่งตัว จากนั้นเพิ่มเครื่องมือถัดไป การตั้งค่านี้คุ้มค่าตั้งแต่ครั้งแรกที่ตรวจจับการเรียกใช้เครื่องมือที่เสียได้ก่อนที่ผู้ใช้จะพบ
รายการตรวจสอบความน่าเชื่อถือของเอเจนต์
ก่อนที่เอเจนต์จะนำไปใช้งานจริง โปรดตรวจสอบรายการนี้:
- การเรียกใช้เครื่องมือทุกครั้งได้รับการตรวจสอบเทียบกับสคีมา และการละเมิดสัญญาทำให้การทดสอบล้มเหลว
- มีการจำลองการตอบสนอง 429, 500 และหมดเวลาจากต้นทาง และเอเจนต์สามารถกู้คืนได้ด้วยการถอยกลับ
- การกระทำที่ลองใหม่เป็นแบบ Idempotent ดังนั้นการทำซ้ำจึงไม่สามารถเรียกเก็บเงินสองครั้งหรือส่งซ้ำสองครั้งได้
- การทดสอบยืนยันที่โครงสร้างและความหมาย ไม่ใช่สตริงที่ตรงเป๊ะ ดังนั้นความแปรปรวนปกติจึงไม่ทำให้เกิดความไม่เสถียร
- มีการวัดการใช้โทเค็นต่อการรัน และงบประมาณสูงสุดจะหยุดการวนซ้ำที่ควบคุมไม่ได้
- การกระทำที่ทำลายล้างอยู่เบื้องหลังรายการที่อนุญาต (allowlist) หรือเกตการอนุมัติจากมนุษย์
- เส้นทางราวกั้นความปลอดภัยได้รับการทดสอบด้วยการจำลอง ไม่ใช่การคาดเดา
ทำเครื่องหมายทั้งเจ็ดข้อนี้ และคุณได้ทดสอบวิธีที่เอเจนต์อาจล้มเหลวในการใช้งานจริงแล้ว
Apidog เหมาะสมกับอะไร (และไม่เหมาะสมกับอะไร)
ทำความเข้าใจบทบาทของเครื่องมือให้ชัดเจน Apidog ไม่ใช่เฟรมเวิร์กของเอเจนต์, โฮสต์โมเดล หรือชุดทดสอบประเมินผล ไม่ได้สร้างหรือรันเอเจนต์ของคุณ แต่สิ่งที่ทำคือจัดการเลเยอร์ API ที่เอเจนต์ของคุณพึ่งพา ซึ่งเป็นจุดที่ความล้มเหลวเหล่านี้เกิดขึ้น
ในทางปฏิบัติ นั่นหมายถึงสามสิ่ง คุณออกแบบและจัดเก็บสัญญาสำหรับเครื่องมือที่เอเจนต์ของคุณเรียกใช้ เพื่อให้คุณสามารถตรวจสอบคำขอที่ส่งออกไปเทียบกับสัญญาเหล่านั้นได้ คุณจำลองการพึ่งพิงเหล่านั้นและกำหนดการตอบสนองที่ล้มเหลว (429, 500, หมดเวลา, เนื้อหาผิดรูปแบบ) ที่ API จริงจะไม่สร้างขึ้นตามคำขอ เพื่อให้คุณสามารถฝึกซ้อมการกู้คืนได้ และคุณเขียนคำยืนยันเกี่ยวกับการตอบสนอง (สคีมา, รูปแบบ, ช่วง, คีย์ที่จำเป็น) ที่สามารถรองรับผลลัพธ์ที่ไม่แน่นอนได้ นั่นคือสิ่งที่เหมาะสมอย่างแท้จริง: Apidog ทดสอบ API ที่เอเจนต์ของคุณเรียกใช้, จำลองความล้มเหลวที่คุณต้องจัดการ และตรวจสอบผลลัพธ์ที่ส่งกลับมา ภาพรวมของเราเกี่ยวกับการ ทดสอบ AI agent จัดวางสิ่งนี้ไว้ในภาพรวม QA ที่กว้างขึ้น
คำถามที่พบบ่อย
ความน่าเชื่อถือของเอเจนต์เป็นปัญหาของโมเดลหรือปัญหาทางวิศวกรรม? ส่วนใหญ่เป็นปัญหาทางวิศวกรรม การเลือกโมเดลมีความสำคัญ แต่ความล้มเหลวที่ทำให้เกิดเหตุการณ์ (การเรียกใช้เครื่องมือที่ไม่ถูกต้อง, การจำกัดจำนวนครั้งที่ไม่ได้รับการจัดการ, การขาดราวกั้นความปลอดภัย) เป็นปัญหาการรวมระบบและการทดสอบที่คุณสามารถแก้ไขได้โดยไม่ต้องเปลี่ยนโมเดล
ฉันสามารถทดสอบเอเจนต์โดยไม่ต้องเรียกใช้ API จริงที่มันเรียกได้หรือไม่? ได้ และคุณควรทำเช่นนั้น จำลองการพึ่งพิงเพื่อให้คุณสามารถบังคับให้เกิดการตอบสนองข้อผิดพลาด, ควบคุมเวลา และหลีกเลี่ยงผลข้างเคียงได้ นั่นเป็นวิธีเดียวที่เชื่อถือได้ในการทดสอบเส้นทางการกู้คืนและราวกั้นความปลอดภัย
ฉันจะเขียนการทดสอบอย่างไรเมื่อผลลัพธ์เปลี่ยนแปลงทุกครั้งที่รัน? ยืนยันที่โครงสร้างและความหมายแทนที่จะเป็นข้อความที่ตรงเป๊ะ ตรวจสอบการตอบสนองเทียบกับสคีมา, ตรวจสอบรูปแบบการเรียกใช้เครื่องมือ และใช้ช่วงสำหรับตัวเลข คู่มือ การทดสอบ AI agent ที่ไม่แน่นอน ครอบคลุมเรื่องนี้โดยละเอียด
ฉันควรทดสอบอะไรก่อน? ราวกั้นความปลอดภัยในการกระทำที่ทำลายล้าง จากนั้นเป็นการกู้คืนข้อผิดพลาด สองสิ่งนี้จะปกป้องคุณจากความล้มเหลวที่แพงที่สุด: เอเจนต์ดำเนินการที่เป็นอันตราย หรือเอเจนต์วนซ้ำจนใช้งบประมาณของคุณหมด
เริ่มต้นด้วยโหมดความล้มเหลวเพียงโหมดเดียว
คุณไม่จำเป็นต้องทดสอบทั้งห้าโหมดพร้อมกัน เลือกโหมดที่คุณกังวลมากที่สุด ซึ่งมักจะเป็นราวกั้นความปลอดภัยหรือการกู้คืนข้อผิดพลาด และฝึกซ้อมกับตัวจำลองในสัปดาห์นี้ กำหนดความล้มเหลว, รันเอเจนต์ และดูว่ามันทำอะไร ครั้งแรกที่คุณเห็นเอเจนต์ของคุณจัดการกับสถานการณ์จำลอง 429 ด้วยการถอยกลับอย่างถูกต้อง แทนที่จะวนซ้ำจนงบประมาณหมด คุณจะเชื่อมั่นในมันมากขึ้น และด้วยเหตุผลที่ดีกว่าการสาธิตที่สมบูรณ์แบบ
ดาวน์โหลด Apidog เพื่อออกแบบสัญญา, จำลองความล้มเหลว และยืนยันการตอบสนองที่เอเจนต์ของคุณพึ่งพา