การออกแบบข้อผิดพลาด API สำหรับเอไอเอเย่นต์: ข้อผิดพลาดที่กู้คืนได้เอง

API ของคุณส่งคืน 400 Bad Request พร้อมเนื้อหา {"error": "invalid input"} นักพัฒนาที่เป็นมนุษย์เปิดเอกสาร ตรวจสอบเพย์โหลด พบว่ามีฟิลด์หายไป และแก้ไขได้ในเวลาไม่ถึงนาที เอเจนต์อ่านข้อความสองคำเดียวกันนี้ ไม่มีอะไรให้ดำเนินการ และทำสิ่งเดียวที่ทำได้คือ: ส่งคำขอเดิมอีกครั้ง จากนั้นก็อีกครั้ง จากนั้นก็ยอมแพ้และแจ้งให้ผู้ใช้ทราบว่า API เสียหาย

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

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

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

สามคำถามที่ข้อผิดพลาดต้องตอบ

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

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

ฉันควรลองใหม่เมื่อใด และเมื่อไหร่? ข้อผิดพลาด 4xx บางอย่างสามารถลองใหม่ได้และบางอย่างไม่สามารถทำได้ 429 สามารถลองใหม่ได้หลังจากรอ 409 อาจลองใหม่ได้หลังจากอ่านสถานะใหม่ 422 ไม่สามารถลองใหม่ได้โดยไม่ต้องเปลี่ยนเพย์โหลด ระบุให้ชัดเจน

ฉันควรเปลี่ยนอะไรให้ตรงจุด? นี่คือฟิลด์ที่ API ส่วนใหญ่ละเว้น "การตรวจสอบล้มเหลว" ไม่มีประโยชน์ "ฟิลด์ customer.postal_code จำเป็นต้องระบุเมื่อ country เป็น US" คือการแก้ไขที่เอเจนต์สามารถนำไปใช้ในการลองครั้งถัดไปได้

ใส่สามสิ่งนี้ลงในทุกข้อผิดพลาด แล้วพายุการลองใหม่ของเอเจนต์ส่วนใหญ่จะหายไป

ใช้รูปแบบข้อผิดพลาดที่มีโครงสร้าง

อย่าสร้างรูปแบบใหม่ RFC 9457, Problem Details for HTTP APIs ได้กำหนดรูปแบบไว้แล้ว และมีการรองรับอย่างดี:

{
  "type": "https://api.example.com/errors/validation-failed",
  "title": "Validation failed",
  "status": 422,
  "detail": "The field 'customer.postal_code' is required when 'country' is 'US'.",
  "instance": "/v1/orders",
  "errors": [
    {
      "field": "customer.postal_code",
      "code": "required_conditional",
      "message": "Required when country is US. Provide a 5-digit or 9-digit US postal code.",
      "example": "94107"
    }
  ],
  "retryable": false,
  "next_action": "Add customer.postal_code to the request body and send again."
}

สี่ส่วนนี้มีความสำคัญต่อเอเจนต์

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

อาร์เรย์ errors สามารถอ่านได้โดยเครื่องจักร โดยมีหนึ่งรายการต่อปัญหา พร้อมเส้นทางฟิลด์ที่เอเจนต์สามารถแมปกลับไปยังเพย์โหลดที่ส่งไปได้ ส่งคืนความล้มเหลวทั้งหมดในครั้งเดียว การส่งคืนทีละรายการจะเปลี่ยนการแก้ไขครั้งเดียวให้เป็นการเดินทางไปกลับห้าครั้ง

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

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

คู่มือการออกแบบข้อผิดพลาด API ของ Google ได้ข้อสรุปที่คล้ายกันจากมุมมองที่แตกต่างกัน โดยเฉพาะอย่างยิ่งว่ารายละเอียดข้อผิดพลาดควรอยู่ในรายการที่มีโครงสร้างมากกว่าในข้อความบรรยาย

บอกว่าเมื่อไหร่จะกลับมา

สำหรับสิ่งที่ไม่ถาวร ให้บอกว่าเมื่อไหร่ เอเจนต์ที่รู้ว่าจะต้องรอ 30 วินาที ก็จะรอ 30 วินาที เอเจนต์ที่ไม่รู้จะเลือกเวลาเอง ซึ่งมักจะสั้นเกินไป

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/problem+json

{
  "type": "https://api.example.com/errors/rate-limited",
  "title": "Rate limit exceeded",
  "status": 429,
  "detail": "You have used 1000 of 1000 requests in the current minute window.",
  "retryable": true,
  "retry_after_seconds": 30,
  "next_action": "Wait 30 seconds before sending this request again. Do not retry sooner."
}

ส่วนหัว Retry-After ยอมรับได้ทั้งการหน่วงเวลาเป็นวินาทีหรือวันที่ HTTP; วินาทีเป็นสิ่งที่ไคลเอนต์ดำเนินการได้ง่ายกว่า ส่งเป็นส่วนหัวสำหรับไคลเอนต์มาตรฐานและทำซ้ำในเนื้อหาสำหรับโมเดล การทำซ้ำราคาถูกและผู้บริโภคทั้งสองจะได้รับสิ่งที่อ่านได้ดีที่สุด รายละเอียดการจำกัดอัตราครอบคลุมใน คู่มือการเกินขีดจำกัดอัตรา ของเราและใน วิธีการใช้การจำกัดอัตรา API หากคุณอยู่ฝั่งเซิร์ฟเวอร์

รูปแบบเดียวกันนี้ใช้กับ 503 ระหว่างการบำรุงรักษา และ 409 กับทรัพยากรที่ถูกล็อก ข้อผิดพลาดใดๆ ที่การรอคอยเป็นการตอบสนองที่ถูกต้องควรมีตัวเลขกำกับ

ห้ามเผยแพร่ข้อมูลภายใน ห้ามส่งคืนค่าว่างเปล่า

โหมดความล้มเหลวสองโหมดที่อยู่ตรงข้ามกันสุดขั้ว และทั้งสองโหมดสร้างความเสียหายต่อเอเจนต์

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

อย่างที่สองคือข้อผิดพลาดว่างเปล่า: 500 ที่ไม่มีเนื้อหา หรือ {"error": true} เอเจนต์ไม่เรียนรู้อะไรเลย และทางเลือกเดียวคือลองใหม่หรือหยุด

เส้นทางตรงกลางคือข้อผิดพลาดสาธารณะที่เสถียรพร้อมรหัสอ้างอิง:

{
  "type": "https://api.example.com/errors/internal",
  "title": "Internal error",
  "status": 500,
  "detail": "The order could not be created due to an internal error. No order was created.",
  "retryable": true,
  "retry_after_seconds": 5,
  "request_id": "req_01J8ZK3M2Q",
  "next_action": "Retry once after 5 seconds. If it fails again, stop and report request_id req_01J8ZK3M2Q."
}

คีย์ idempotency สำหรับเอเจนต์ AI

request_id ช่วยให้คุณกลับไปที่บันทึกของคุณได้เมื่อมนุษย์อ่านบันทึกในที่สุด จับคู่กับแนวทางปฏิบัติในคู่มือ ความสามารถในการตรวจสอบ API ของเรา เพื่อให้ ID สามารถแก้ไขเป็นบางสิ่งบางอย่างได้จริง

ข้อผิดพลาดเป็นส่วนหนึ่งของข้อกำหนด

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

responses:
  '201':
    description: Order created
    content:
      application/json:
        schema: { $ref: '#/components/schemas/Order' }
  '422':
    description: >
      Validation failed. Not retryable without changing the request body.
      The errors array names each invalid field.
    content:
      application/problem+json:
        schema: { $ref: '#/components/schemas/Problem' }
  '429':
    description: >
      Rate limited. Retryable. Wait for retry_after_seconds before sending again.
    content:
      application/problem+json:
        schema: { $ref: '#/components/schemas/Problem' }

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

ทดสอบข้อผิดพลาด ไม่ใช่แค่ความสำเร็จ

เส้นทางข้อผิดพลาดคือจุดที่การครอบคลุมการทดสอบพังทลายลง เพราะการกระตุ้นให้เกิดต้องใช้ความพยายาม การจำลอง (Mocking) ช่วยลดความพยายามนี้ได้

ภาพแสดงหน้าจอ Apidog สำหรับการกำหนด Mock Rule สำหรับ API Response

กำหนดการตอบสนองข้อผิดพลาดแต่ละรายการในโครงการ API ของคุณ จากนั้นจำลอง (mock) เพื่อให้เอเจนต์สามารถตอบสนองทุกกรณีตามต้องการ ใน Apidog คุณสามารถเพิ่มการตอบสนองความล้มเหลวลงในการกำหนดจุดสิ้นสุดและสลับการจำลองไปมาระหว่างกัน ซึ่งจะช่วยให้คุณมีวิธีที่ทำซ้ำได้ในการเรียกใช้เอเจนต์กับ 422, 429 และ 500 โดยไม่ทำลายสิ่งใดๆ ที่เป็นของจริง โพสต์ของเราเกี่ยวกับ การรันเอเจนต์กับ Mock API แทน Production ครอบคลุมพฤติกรรมในวงกว้าง

ห้ากรณีที่ต้องสร้าง:

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

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

คุณค่าของข้อผิดพลาดที่ดีขึ้น

คุณค่าจะปรากฏในสามที่ และง่ายต่อการวัดเมื่อคุณดู

ลดการลองใหม่ที่สิ้นเปลือง เอเจนต์ที่เผชิญกับ {"error": "invalid input"} โดยทั่วไปจะลองส่งเพย์โหลดที่เหมือนกันสองหรือสามครั้งก่อนที่จะเลิก แต่ละครั้งที่พยายามจะเสียเวลาของโมเดลและการสนทนาทั้งหมดเป็นบริบท การตอบสนองที่ระบุฟิลด์ที่หายไปมักจะสร้างการพยายามแก้ไขที่ถูกต้องเพียงครั้งเดียว นั่นคือความแตกต่างระหว่างสี่การเรียกและสองการเรียกในการตรวจสอบความถูกต้องที่ผิดพลาดตามปกติ

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

ลดเวลาในการดีบัก เมื่อมีบางอย่างที่จำเป็นต้องมีคน request_id บวกกับ detail ที่แม่นยำจะเปลี่ยนการค้นหาบันทึกให้เป็นการค้นหาครั้งเดียว นี่เป็นข้อโต้แย้งเดียวกันกับที่คู่มือ การตรวจสอบ API ของเรากล่าวถึงเกี่ยวกับการเชื่อมโยง โดยนำไปใช้กับช่วงเวลาที่การทำงานหยุดชะงัก

มีประโยชน์ที่สี่ที่อาจมองข้ามไป: การปรับปรุงเดียวกันนี้ช่วยให้นักพัฒนาที่เป็นมนุษย์ด้วย ไม่มีใครเคยบ่นว่าข้อความข้อผิดพลาดเจาะจงเกินไปว่าฟิลด์ใดผิดพลาด

ออกแบบสำหรับการส่งต่อปัญหาด้วย

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

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

A screenshot of the Sharkly inbox, showing a task in the 'Needs Review' status.

อย่าบังคับให้เอเจนต์ต้องวิเคราะห์ข้อความบรรยาย

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

{ "message": "Sorry, that didn't work. Please check your details and try again." }

เอเจนต์สามารถตอบสนองต่อสิ่งนี้ได้ด้วยการคาดเดาเท่านั้น ที่แย่กว่านั้นคือทีมงานมักจะจับคู่กับสถานะ 200 ดังนั้นไลบรารีไคลเอ็นต์จึงไม่เห็นความล้มเหลวด้วยซ้ำ

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

รายการตรวจสอบสำหรับข้อผิดพลาดที่เอเจนต์อ่านได้

ข้อผิดพลาดทุกรายการใช้รูปแบบที่มีโครงสร้างที่สอดคล้องกันทั่วทั้ง API
detail ระบุฟิลด์หรือเงื่อนไขเฉพาะ ไม่ใช่หมวดหมู่
ข้อผิดพลาดในการตรวจสอบความถูกต้องส่งคืนปัญหาทั้งหมดพร้อมกันพร้อมเส้นทางฟิลด์
ค่าบูลีน retryable ปรากฏในทุกข้อผิดพลาด
ข้อผิดพลาดที่สามารถลองใหม่ได้จะระบุเวลาที่ต้องรอเป็นวินาที ทั้งในส่วนหัวและในเนื้อหา
ความล้มเหลวในการเขียนระบุว่ามีการสร้างหรือเปลี่ยนแปลงอะไรหรือไม่
ข้อผิดพลาดทุกรายการมีรหัสอ้างอิงที่สามารถค้นหาได้ในบันทึกของคุณ
ไม่มี Stack trace, ไม่มีข้อความ Framework, ไม่มี SQL
การตอบสนองข้อผิดพลาดได้รับการบันทึกในข้อกำหนดพร้อมคำอธิบายที่เอเจนต์สามารถเข้าใจได้
มีการจำลองสำหรับข้อผิดพลาดแต่ละรายการ และการทดสอบที่บันทึกไว้จะรันใน CI

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

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

ฉันควรใช้ RFC 9457 หรือรูปแบบข้อผิดพลาดของฉันเอง? ใช้ RFC 9457 เว้นแต่คุณจะมีรูปแบบที่สอดคล้องกันในการใช้งานจริงอยู่แล้ว ความสอดคล้องสำคัญกว่าการทำให้เป็นมาตรฐาน: การเปลี่ยนครึ่งหนึ่งของจุดสิ้นสุดของคุณไปเป็นรูปแบบใหม่นั้นแย่กว่าการรักษารูปแบบเดียวไว้ทุกที่ เพิ่มส่วนขยาย retryable และ next_action ลงในรูปแบบใดก็ตามที่คุณใช้

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

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

รายละเอียดมากเกินไปแค่ไหน? หยุดเมื่อผู้เรียกมีข้อมูลเพียงพอที่จะดำเนินการ ชื่อฟิลด์ กฎ และค่าตัวอย่างมักจะเพียงพอ ตัวระบุภายใน ข้อความคำค้นหา และ stack frames ถือว่าเกินขีดจำกัด

ข้อความแสดงข้อผิดพลาดนับรวมใน Context Window หรือไม่? ใช่ และข้อผิดพลาดที่ละเอียดถี่ถ้วนที่ซ้ำกันในการลองใหม่จะเพิ่มขึ้นอย่างรวดเร็ว รักษาให้อยู่ภายใต้ไม่กี่ร้อยโทเค็น โพสต์ของเราเรื่อง การตัดทอนการตอบสนอง API สำหรับเอเจนต์ ใช้ได้กับความล้มเหลวพอๆ กับความสำเร็จ

ฉันจะหยุดเอเจนต์ไม่ให้ลองข้อผิดพลาดที่ไม่สามารถลองใหม่ได้ได้อย่างไร? ตั้งค่า retryable: false ระบุไว้ใน next_action และบังคับใช้ในตัวห่อเครื่องมือ (tool wrapper) เพื่อไม่ให้การตัดสินใจของโมเดลเป็นเพียงผู้พิทักษ์เดียว การใช้ทั้งเข็มขัดและสายคาดถูกต้องในที่นี้