เป็นเวลาตี 3 แล้ว เอเจนต์ของคุณทำงานจัดการคิวตั๋วสนับสนุนในขณะที่คุณหลับ ตั๋วใบหนึ่งดูเหมือนเป็นการส่งเรื่องให้ผู้บริหาร เอเจนต์จึงเขียนสรุปและส่งอีเมลไปให้เจ้านายของคุณ สรุปนั้นถูกต้อง ไวยากรณ์ก็ดี ปัญหาคือไม่มีใครขออีเมลนั้น ไม่มีใครได้อ่านก่อน และไม่มีอะไรจะหยุดมันได้เมื่อเอเจนต์ตัดสินใจส่ง เอเจนต์ทำตามที่ได้รับคำสั่งอย่างเคร่งครัด นั่นคือส่วนที่ควรทำให้คุณนอนไม่หลับ
ความล้มเหลวที่สร้างความเสียหายมากที่สุดไม่ใช่กรณีที่โมเดลเข้าใจผิดหรือกระบวนการล่ม สิ่งเหล่านั้นเป็นความล้มเหลวที่ชัดเจน และมักจะถูกตรวจพบได้ง่าย แต่ความล้มเหลวที่อันตรายนั้นเงียบ เอเจนต์ทำตามที่ได้รับคำสั่งอย่างแม่นยำ แต่ผลลัพธ์ก็ยังคงไม่ดี เพราะมันส่งอีเมล ลบข้อมูล หรือสั่งซื้อไปแล้ว โดยไม่มีอะไรมาคั่นกลางระหว่างการตัดสินใจของโมเดลกับการดำเนินการจริง
Guardrails (รั้วป้องกัน) คือสิ่งที่เข้ามาอยู่ตรงนั้น Guardrail คือชั้นที่ตรวจสอบการกระทำก่อนที่จะเกิดขึ้น และตัดสินใจว่าจะอนุญาต บล็อก หรือถามมนุษย์ก่อน คู่มือนี้ครอบคลุม Guardrail สี่ประเภทที่คุณสามารถสร้างได้ (รายการที่อนุญาตการดำเนินการ, ด่านอนุมัติ, โหมดทดลองทำงาน (dry-run), และข้อจำกัดขอบเขตความเสียหาย) จากนั้นเป็นขั้นตอนที่ทีมส่วนใหญ่ข้ามไป: การพิสูจน์ว่า Guardrail ทำงาน หากคุณต้องการบริบทที่กว้างขึ้นก่อน หลักสำคัญของเราในหัวข้อ เหตุใดเอเจนต์ AI จึงล้มเหลวในการทำงานจริง จะแบ่งประเภทความล้มเหลวของเอเจนต์ออกเป็นห้าโหมด และ Guardrail ที่ขาดหายไปคือโหมดที่ห้า
จัดเรียงการดำเนินการตามระดับความเสียหายที่อาจเกิดขึ้น
ไม่ใช่ทุกการดำเนินการที่ต้องการด่านป้องกัน เอเจนต์ที่อ่านปฏิทิน ดึงข้อมูลพยากรณ์ หรือสอบถามรายงานแบบอ่านอย่างเดียว สามารถทำงานได้อย่างเต็มที่โดยไม่ต้องมีมนุษย์คอยเฝ้า การใส่การอนุมัติเข้าไปสำหรับสิ่งเหล่านี้จะทำให้ทีมของคุณถูกฝึกให้คลิก “ใช่” โดยไม่คิด ซึ่งทำให้การอนุมัติไร้ค่าเมื่อถึงเวลาที่จำเป็นจริงๆ
ดังนั้น Guardrail แรกคืองานการจัดเรียง แบ่งการดำเนินการที่เอเจนต์ของคุณสามารถทำได้ออกเป็นสองรายการ รายการที่อนุญาต (allowlist) จะเก็บการเรียกที่ปลอดภัยที่จะทำงานโดยอัตโนมัติ: การอ่าน, การค้นหา, การค้นหาแบบ idempotent, อะไรก็ตามที่สามารถย้อนกลับได้ ทุกสิ่งอื่นที่นอกเหนือจากนี้ต้องมีด่านป้องกัน: การส่ง, การลบ, การชำระเงิน, การเขียนไปยังระบบบันทึก, อะไรก็ตามที่ลูกค้าหรือเพื่อนร่วมงานจะเห็น การทดสอบที่มีประโยชน์สำหรับรายการที่สองคือคำถามที่ว่า “หากเอเจนต์ทำสิ่งนี้ผิดพลาดร้อยครั้ง จะแย่แค่ไหน” หากคำตอบเลวร้ายกว่าการแค่ยักไหล่ การดำเนินการนั้นไม่ควรอยู่ในรายการที่อนุญาต
ซื่อสัตย์กับกรณีตรงกลาง การดำเนินการ POST ที่สร้างฉบับร่างสามารถย้อนกลับได้ แต่การดำเนินการ POST ที่สร้างฉบับร่างแล้วส่งอีเมลนั้นไม่สามารถย้อนกลับได้ การเรียกสองครั้งที่ดูคล้ายกันในโค้ดของคุณอาจอยู่คนละด้านของเส้นแบ่ง จัดเรียงตามผลลัพธ์ที่ตามมา ไม่ใช่ตามคำกริยา HTTP
ให้มนุษย์เข้ามาเกี่ยวข้องในการดำเนินการที่ก่อความเสียหาย
เมื่อคุณรู้ว่าการดำเนินการใดเป็นอันตราย Guardrail ถัดไปคือด่านอนุมัติ: เอเจนต์จะหยุดก่อนการดำเนินการ แสดงสิ่งที่ต้องการจะทำ และรอให้บุคคลยืนยัน นี่คือรูปแบบมนุษย์อยู่ในวงจร (human-in-the-loop) และเป็น Guardrail ที่มีมูลค่าสูงสุดที่คุณสามารถเพิ่มได้ เพราะมันเปลี่ยนความผิดพลาดที่ย้อนกลับไม่ได้ให้กลายเป็นการร้องขอที่ถูกปฏิเสธ
ด่านที่ดีควรแสดงข้อมูลให้มนุษย์มากพอที่จะตัดสินใจ ไม่ใช่แค่ “เอเจนต์ต้องการส่งอีเมล” แต่ต้องแสดงผู้รับ หัวข้อ และเนื้อหา ไม่ใช่แค่ “ลบหนึ่งระเบียน” แต่ต้องระบุว่าระเบียนใดและเพราะเหตุใด นักพัฒนาที่อนุมัติการดำเนินการไม่ควรต้องเชื่อสรุปของเอเจนต์เกี่ยวกับสิ่งที่จะทำ แสดงคำขอที่แท้จริง
ทำให้การปฏิเสธผ่านด่านเป็นเรื่องง่าย หากการปฏิเสธการดำเนินการช้าหรือไม่ชัดเจน ผู้คนจะอนุมัติโดยอัตโนมัติ และคุณก็จะกลับไปสู่การไม่มี Guardrail เลย กระดานสนทนาของ Anthropic SDK มีการถกเถียงกันซ้ำๆ เกี่ยวกับการ เพิ่มขั้นตอนการอนุมัติโดยมนุษย์ก่อนที่เอเจนต์จะดำเนินการ และประเด็นที่กลับมาพูดถึงอยู่เสมอคือ ด่านนั้นจะต้องอ่านเข้าใจได้: ผู้ตรวจสอบที่ไม่สามารถเห็น payload ที่เป็นรูปธรรมได้ ก็ไม่สามารถตัดสินใจได้อย่างแท้จริง บันทึกการอนุมัติและการปฏิเสธทุกครั้งด้วย เมื่อมีสิ่งใดหลุดรอดไปได้ บันทึกคือวิธีที่คุณจะรู้ว่าด่านใดล้มเหลว
ให้เอเจนต์มีโหมดทดลองทำงาน (dry-run)
ด่านอนุมัติปกป้องระบบที่ใช้งานจริง โหมดทดลองทำงาน (dry-run) ปกป้องความมั่นใจของคุณก่อนที่จะถึงขั้นนั้น ในโหมด dry-run เอเจนต์จะทำทุกอย่างตามปกติ เลือกเครื่องมือ สร้างคำขอ ตัดสินใจเรื่องอาร์กิวเมนต์ แต่จะหยุดที่ขั้นตอนสุดท้ายและรายงานสิ่งที่จะส่งแทนที่จะส่งจริงๆ
สิ่งนี้มีค่าพอที่จะมีสวิตช์แยกเป็นของตัวเองด้วยเหตุผลสองประการ ประการแรก มันช่วยให้คุณสามารถเฝ้าดูการทำงานของเอเจนต์เต็มรูปแบบกับข้อมูลจริงโดยไม่มีผลข้างเคียงใดๆ ซึ่งเป็นวิธีที่ปลอดภัยในการดูว่าเอเจนต์ทำงานอย่างไรในงานใหม่ ประการที่สอง มันทำให้เจตนาของเอเจนต์สามารถตรวจสอบได้ คุณจะได้รับบันทึกการเรียกทั้งหมดที่เอเจนต์ต้องการทำ เรียงตามลำดับ พร้อมอาร์กิวเมนต์ และคุณสามารถอ่านมันได้เหมือนแผน หากแผนผิด คุณก็ค้นพบได้ฟรี การมีมุมมอง เครื่องมือดีบักเอเจนต์ AI โดยเฉพาะ สำหรับการเรียกที่ตั้งใจไว้เหล่านั้น จะเปลี่ยนข้อความคลุมเครือที่ว่า “เอเจนต์ทำอะไรแปลกๆ” ให้กลายเป็น “มันพยายามเรียกใช้ endpoint สำหรับการลบในขั้นตอนที่สี่” ที่เฉพาะเจาะจง
โหมดทดลองทำงาน (dry-run) ไม่เหมือนกับด่านอนุมัติ และคุณต้องการทั้งคู่ Dry-run มีไว้สำหรับการพัฒนาและ staging ที่ซึ่งทุกอย่างไม่เป็นจริง ส่วนด่านอนุมัติมีไว้สำหรับ production ที่ซึ่งทุกอย่างเป็นจริง
จำกัดขอบเขตความเสียหาย
รายการที่อนุญาต (allowlists), ด่านป้องกัน (gates) และโหมดทดลองทำงาน (dry-run) ล้วนตัดสินใจว่าการดำเนินการเดียวจะเกิดขึ้นหรือไม่ แต่ข้อจำกัดขอบเขตความเสียหาย (blast-radius limits) จะตัดสินใจว่าเอเจนต์สามารถก่อความเสียหายได้มากน้อยเพียงใดจากการดำเนินการหลายอย่าง รวมถึงการดำเนินการที่คุณอนุมัติไปแล้วด้วย สิ่งเหล่านี้คือขีดจำกัดสูงสุดของความเสียหายทั้งหมด
ข้อจำกัดสามประการมีความสำคัญที่สุด ขอบเขต (Scopes): ให้ข้อมูลรับรองแก่เอเจนต์ที่สามารถเข้าถึงได้เฉพาะสิ่งที่จำเป็นเท่านั้น เอเจนต์ที่จัดการปัญหาของโปรเจกต์เดียวควรมีโทเค็นที่กำหนดขอบเขตสำหรับโปรเจกต์นั้น ไม่ใช่คีย์ผู้ดูแลระบบสำหรับองค์กรทั้งหมด โควต้า (Quotas): กำหนดจำนวนครั้งที่การดำเนินการสามารถทำงานได้ภายในช่วงเวลาหนึ่ง เพื่อให้ลูปที่ติดขัดชนกับขีดจำกัดแทนที่จะส่งอีเมลเป็นพันฉบับ ขีดจำกัดการใช้จ่าย (Spend caps): กำหนดเพดานสูงสุดสำหรับโทเค็นและการดำเนินการใดๆ ที่มีค่าใช้จ่าย ต่องานและต่อวัน เพื่อให้เอเจนต์ที่ทำงานผิดพลาดหยุดทำงานเอง แทนที่จะเรียกเก็บเงินคุณไปจนถึงไตรมาสหน้า
ข้อจำกัดเหล่านี้ยังเป็นตาข่ายนิรภัยของคุณเมื่อ Guardrail ที่ละเอียดอ่อนกว่าพลาดไป เอเจนต์ที่เล็ดลอดผ่านด่านป้องกันไปได้ก็ยังไม่สามารถเกินขอบเขตของมันได้ หากต้องการทราบว่าขีดจำกัดทำงานหรือไม่ คุณต้องเฝ้าดูมัน ดังนั้นจงติดตามจำนวนที่ส่งผลต่อขีดจำกัดแต่ละอย่าง, การเรียกต่อการดำเนินการ, การใช้จ่ายต่องาน, อัตราข้อผิดพลาดใกล้เพดานสูงสุด เหมือนที่คุณทำกับ API observability ในบริการใดๆ ที่ใช้งานจริง OWASP ระบุความเสี่ยงพื้นฐานโดยตรง “อำนาจที่มากเกินไป (Excessive agency)” อยู่ใน OWASP Top 10 สำหรับแอปพลิเคชัน LLM และทุกขีดจำกัดในที่นี้คือวิธีที่จะลดทอนอำนาจนั้นลง
วิธีทดสอบ Guardrail
นี่คือความจริงที่น่าอึดอัด Guardrail ทุกตัวที่กล่าวมาข้างต้นคือสาขาในโค้ดของคุณที่ทำงานเฉพาะเมื่อมีสิ่งอันตรายกำลังจะเกิดขึ้น สาขาเหล่านั้นเป็นเส้นทางที่ถูกใช้งานน้อยที่สุดในระบบทั้งหมด ซึ่งทำให้พวกมันมีแนวโน้มที่จะเสียหายโดยไม่มีใครสังเกตเห็นมากที่สุด ด่านป้องกันที่ไม่เคยทำงานดูเหมือนกับด่านป้องกันที่ทำงานแล้วถูกละเลย Guardrail ที่คุณไม่ได้ทดสอบคือ Guardrail ที่คุณไม่มี
คุณไม่สามารถทดสอบสิ่งนี้กับ API ที่ใช้งานจริงได้ เพราะการทดสอบกับ API ที่ใช้งานจริงหมายถึงการส่งอีเมลจริงออกไปเพื่อดูว่าคุณต้องการทำเช่นนั้นหรือไม่ วิธีการคือการจำลอง (mock) endpoint ที่มีผลข้างเคียง และยืนยันว่าเอเจนต์ใช้เส้นทางใด
วงจรมีลักษณะดังนี้:
- จำลอง endpoint ที่ก่อให้เกิดความเสียหาย สร้างการจำลองของ API สำหรับการส่ง, การลบ หรือการชำระเงิน เพื่อไม่ให้มีการแตะต้อง API จริง การจำลองจะบันทึกสิ่งที่ได้รับและส่งคืนการตอบสนองตามที่คุณกำหนด
- รันเอเจนต์ในการดำเนินการที่เป็นอันตราย ขับเคลื่อนมันผ่านสถานการณ์ที่ควรจะกระตุ้น Guardrail: ตั๋วส่งเรื่องให้ผู้บริหาร, คำขอการลบ, หรือคำสั่งซื้อที่มีมูลค่าสูง
- ยืนยันเส้นทาง ไม่ใช่ผลลัพธ์ ตรวจสอบว่าการจำลอง endpoint ที่ใช้งานจริงไม่ได้รับการเรียกใช้เลย และคำขออนุมัติถูกส่งออกไปแทน พร้อมกับ payload ที่ถูกต้อง เงื่อนไขที่ผ่านคือ “เอเจนต์ถาม” แทนที่จะเป็น “เอเจนต์ส่ง”
- ทดสอบในทิศทางอื่นด้วย เรียกใช้การดำเนินการที่ปลอดภัยและยืนยันว่ามันผ่านไปโดยตรงโดยไม่มีการอนุมัติที่ไม่จำเป็น ด่านที่บล็อกทุกอย่างก็พังพอๆ กับด่านที่ไม่บล็อกอะไรเลย
นั่นคือรูปแบบ คู่มือของเราเกี่ยวกับ วิธีทดสอบเอเจนต์ AI ที่เรียกใช้ API ของคุณ จะอธิบายการตั้งค่าทั้งหมด และวิธีการที่กว้างขึ้นสำหรับ การทดสอบเอเจนต์ AI และ API ครอบคลุมรูปแบบการยืนยันที่สามารถรับมือกับโมเดลที่ไม่แน่นอนได้ ประเด็นที่ต้องจำไว้: ยืนยันว่าผลข้างเคียงไม่เกิดขึ้นและการอนุมัติเกิดขึ้น หากการทดสอบของคุณตรวจสอบเฉพาะเส้นทางที่ราบรื่น (happy path) มันก็จะผ่านในวันที่ด่านป้องกันพัง
Apidog เหมาะสมกับตรงไหน (และไม่เหมาะสมกับตรงไหน)
ระบุหน้าที่ของเครื่องมือให้ชัดเจน Apidog ไม่ใช่เฟรมเวิร์กของเอเจนต์, โฮสต์โมเดล, ไลบรารี Guardrail หรือแพลตฟอร์มการประเมิน มันไม่ได้สร้างเอเจนต์ของคุณ, ไม่ได้รันมัน, หรือตัดสินใจว่าการดำเนินการใดปลอดภัย โค้ดของคุณและชั้นการประสานงานของคุณเป็นเจ้าของรายการที่อนุญาต (allowlist), ด่านป้องกัน (gate), สวิตช์ dry-run และขีดจำกัดต่างๆ
สิ่งที่ Apidog เป็นเจ้าของคือชั้น API ที่ Guardrail เหล่านั้นป้องกัน ซึ่งเป็นจุดที่การทดสอบเกิดขึ้น คุณจำลอง endpoint ที่มีผลข้างเคียง (การส่ง, การลบ, การเรียกเก็บเงิน) เพื่อให้เอเจนต์ของคุณสามารถฝึกซ้อมการดำเนินการที่เป็นอันตรายโดยไม่มีผลลัพธ์จริง คุณตั้งโปรแกรมการจำลองเหล่านั้นให้ส่งคืนการตอบสนองที่บริการจริงจะให้ รวมถึงความล้มเหลวด้วย และคุณยืนยันสิ่งที่เอเจนต์ส่ง: ว่าการเรียกใช้งานจริงไม่มีการรับส่งข้อมูล, ว่าคำขออนุมัติถูกส่งออกไป, ว่า payload ตรงกัน นั่นคือความเหมาะสมอย่างแท้จริง Apidog ทดสอบ API ที่เอเจนต์ของคุณเรียกใช้และจำลอง API ที่ก่อให้เกิดความเสียหาย เพื่อให้คุณสามารถพิสูจน์ได้ว่าเอเจนต์ใช้เส้นทางอนุมัติ
คำถามที่พบบ่อย
ความแตกต่างระหว่าง allowlist กับ approval gate คืออะไร? Allowlist จะตัดสินใจว่าการดำเนินการใดที่ไม่จำเป็นต้องมีมนุษย์เข้ามาเกี่ยวข้อง จึงทำงานโดยอัตโนมัติ Approval gate คือสิ่งที่การดำเนินการที่ไม่ได้อยู่ใน allowlist จะต้องเจอ: การหยุดชั่วคราวเพื่อให้บุคคลยืนยันก่อนที่จะดำเนินการ Allowlist ทำการจัดเรียง; gate ทำการหยุด
Guardrail ทำให้เอเจนต์ทำงานช้าลงมากเกินไปหรือไม่? เฉพาะในกรณีที่คุณตั้งด่านป้องกันผิดจุดเท่านั้น เก็บการอ่านที่สามารถย้อนกลับได้ไว้ใน allowlist เพื่อให้ทำงานได้อย่างเต็มที่ และสงวนด่านป้องกันไว้สำหรับการดำเนินการที่มีค่าใช้จ่ายสูงหรือยากที่จะย้อนกลับ Allowlist ที่จัดเรียงอย่างดีหมายความว่าขั้นตอนส่วนใหญ่จะไม่หยุดชะงัก
ฉันสามารถทดสอบ Guardrail โดยไม่ต้องเรียกใช้ API จริงได้หรือไม่? ได้ และคุณควรทำด้วย ซิมูเลท endpoint ที่มีผลข้างเคียง เรียกใช้เอเจนต์ในการดำเนินการที่เป็นอันตราย และยืนยันว่าการซิมูเลทนั้นไม่ได้รับการเรียกใช้เลยในขณะที่เส้นทางการอนุมัติทำงาน นี่คือวิธีพิสูจน์ว่าด่านป้องกันทำงานได้โดยไม่กระตุ้นผลข้างเคียงที่คุณพยายามป้องกัน
ฉันควรใส่อะไรไว้หลังด่านป้องกันเป็นอันดับแรก? สิ่งที่แก้ไขยากที่สุด เช่น การชำระเงิน, การลบ, และสิ่งใดก็ตามที่ส่งผลถึงลูกค้าหรือเพื่อนร่วมงาน หากการทำซ้ำโดยไม่ตั้งใจเพียงครั้งเดียวจะก่อให้เกิดความเสียหายร้ายแรง สิ่งนั้นควรอยู่หลังด่านป้องกัน ไม่ใช่อยู่ใน allowlist
เริ่มต้นด้วยการดำเนินการที่สร้างความเสียหายมากที่สุดของคุณ
คุณไม่จำเป็นต้องมี Guardrail ทั้งสี่ชนิดในวันแรก เลือกการดำเนินการเดียวที่ทำให้คุณกลัวที่สุด ซึ่งเป็นสิ่งที่คุณไม่อยากอธิบายในการตรวจสอบเหตุการณ์ และตั้งด่านป้องกันสำหรับสิ่งนั้นในสัปดาห์นี้ จากนั้นเขียนการทดสอบ: จำลอง endpoint, รันเอเจนต์ และยืนยันว่ามันถามก่อนที่จะดำเนินการ เมื่อคุณเห็นการทดสอบนั้นล้มเหลวเป็นครั้งแรกที่คุณพังด่าน คุณจะเชื่อมั่นใน Guardrail ด้วยเหตุผลที่แท้จริง ไม่ใช่เพราะมันไม่เคยถูกทดลองใช้
ดาวน์โหลด Apidog เพื่อจำลอง endpoint ที่ก่อให้เกิดความเสียหาย, ตั้งโปรแกรมการตอบสนอง, และยืนยันว่าเอเจนต์ของคุณใช้เส้นทางอนุมัติแทนที่จะเป็นเส้นทางจริง