Claude Fable 5 และการเปลี่ยนแปลง Mythos API: สิ่งที่ยังใช้งานได้ (พร้อมวิธีทดสอบ)

Anthropic ได้เปิดตัวโมเดล Fable และ Mythos ด้วยชุดกฎที่แตกต่างจากที่นักพัฒนาคุ้นเคย และเสียงตอบรับก็ดังกระหึ่ม การอภิปรายส่วนใหญ่มาจากสองประเด็นหลัก: ข้อกำหนดการเก็บรักษาข้อมูล 30 วันใหม่สำหรับทราฟฟิก Fable และ Mythos และการเปลี่ยนแปลงของ Guardrail หลายรายการที่เกิดขึ้นโดยไม่มีการเตือนล่วงหน้ามากนัก หากคุณใช้งานอะไรก็ตามกับ Claude API ในการผลิต การเปลี่ยนแปลงเหล่านี้ส่งผลกระทบต่อคุณโดยตรง

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

สิ่งที่เปลี่ยนไปจริง ๆ

สามสิ่งกำลังถูกรวมเข้าด้วยกันในการอภิปราย ลองแยกพวกมันออกจากกันแล้วภาพจะชัดเจนขึ้น

การเก็บรักษาข้อมูล. การเปลี่ยนแปลงหลักคือหน้าต่างการเก็บรักษาข้อมูล 30 วันที่ใช้กับคำขอ Fable และ Mythos ในทางปฏิบัติหมายความว่าข้อมูลคำขอและข้อมูลการตอบกลับที่เกี่ยวข้องกับโมเดลเหล่านั้นจะถูกเก็บไว้เป็นระยะเวลาที่กำหนด แทนที่จะถูกลบทันที ทีมที่มีข้อผูกมัดในการจัดการข้อมูลอย่างเข้มงวดให้ความสำคัญกับเรื่องนี้ เพราะมันเปลี่ยนสิ่งที่คุณสามารถรับปากกับผู้ใช้ของคุณได้ หากนโยบายความเป็นส่วนตัวของคุณระบุว่า “เราไม่เก็บรักษาพรอมต์” พฤติกรรมการเก็บรักษาข้อมูลของผู้ให้บริการต้นน้ำของคุณก็จะเป็นส่วนหนึ่งของข้อเรียกร้องนั้นแล้ว

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

การเข้าถึงด้วยโปรแกรม. นี่คือส่วนที่นักพัฒนาส่วนใหญ่จำเป็นต้องดำเนินการ อินเทอร์เฟซ API, โมเดลการยืนยันตัวตน และรูปแบบคำขอหลักยังไม่ถูกแทนที่ คีย์ที่มีอยู่ของคุณ, การเรียกใช้ messages ของคุณ และสคีมาการใช้เครื่องมือของคุณยังคงใช้งานได้ดี สิ่งที่อาจเปลี่ยนแปลงไปโดยที่คุณไม่รู้ตัวคือพฤติกรรม: พรอมต์ใดบ้างที่ถูกปฏิเสธ, การเรียกใช้ใช้เวลานานเท่าใดภายใต้ภาระงาน และการตอบกลับแบบสตรีมมิ่งมีลักษณะอย่างไรเมื่อ Guardrail ทำงานกลางคันระหว่างการสร้าง

สรุปสั้นๆ: สัญญามีความเสถียร แต่พฤติกรรมไม่รับประกันความเสถียร และนโยบายเกี่ยวกับข้อมูลของคุณเข้มงวดขึ้น การรวมกันนี้คือเหตุผลของการทดสอบทั้งหมด

สิ่งที่ยังคงใช้งานได้

ก่อนที่คุณจะเขียนใหม่ใดๆ ให้ยืนยันสิ่งที่ยังไม่เปลี่ยนแปลง เพื่อที่คุณจะได้ไม่ต้องแก้ไขปัญหาที่คุณไม่มี

• การยืนยันตัวตน. คีย์ API และเฮดเดอร์ x-api-key ยังคงทำงานเหมือนเดิม คุณไม่จำเป็นต้องหมุนเวียนคีย์เนื่องจากการเปลี่ยนแปลงเหล่านี้ แม้ว่าการหมุนเวียนคีย์จะเป็นสุขอนามัยที่ดีก็ตาม ดู เอกสารอ้างอิง API ของ Anthropic สำหรับสัญญาเฮดเดอร์ปัจจุบัน
• รูปแบบ Messages API. ตัวบอดี้คำขอ, ฟิลด์ model, max_tokens, พรอมต์ system และอาร์เรย์ messages ไม่มีการเปลี่ยนแปลง โค้ดที่เขียนขึ้นสำหรับ Messages API ยังคงทำงานได้
• การใช้เครื่องมือ. การนิยามเครื่องมือของคุณและการทำงานแบบไป-กลับของ tool_use / tool_result ยังคงมีพฤติกรรมเหมือนเดิม หากคุณสร้างเอเจนต์บนการเรียกฟังก์ชัน การเชื่อมต่อยังคงอยู่
• การสตรีมมิ่ง. เหตุการณ์ที่ส่งจากเซิร์ฟเวอร์ยังคงสตรีมโทเค็นในลักษณะเดียวกัน สิ่งที่อาจแตกต่างกันคือเนื้อหาของสตรีมเมื่อ Guardrail เข้ามาแทรกแซงระหว่างทาง
• นามแฝงของโมเดล. หากคุณตรึงโมเดลด้วย ID เต็มแทนที่จะเป็นนามแฝงที่ไม่แน่นอน คุณจะสามารถควบคุมได้ว่าโมเดลใดจะตอบกลับ การตรึงเป็นวิธีป้องกันที่ดีที่สุดของคุณจากการเปลี่ยนแปลงพฤติกรรมอย่างเงียบ ๆ

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

วิธีทดสอบการรวมระบบของคุณด้วย Apidog

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

1. สร้างค่าพื้นฐานที่ดีที่ทราบ

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

POST https://api.anthropic.com/v1/messages
x-api-key: {{ANTHROPIC_API_KEY}}
anthropic-version: 2023-06-01
content-type: application/json

{
  "model": "claude-fable-5",
  "max_tokens": 1024,
  "messages": [
    { "role": "user", "content": "Summarize this support ticket and label its priority: ..." }
  ]
}

จัดเก็บคีย์ API เป็นตัวแปรสภาพแวดล้อมใน Apidog แทนที่จะฮาร์ดโค้ดมัน วิธีนี้จะช่วยให้คีย์ไม่อยู่ในคำขอที่คุณบันทึกไว้ และช่วยให้คุณสลับระหว่างสภาพแวดล้อมการทดสอบ (staging) และการผลิต (production) ได้ด้วยเมนูแบบเลื่อนลงเพียงครั้งเดียว รูปแบบเดียวกันนี้ใช้ได้ไม่ว่าคุณจะกำลังทดสอบ Claude, SDK ของ Claude Code หรือโมเดลอื่น ๆ ที่อยู่เบื้องหลังคีย์เดียวกัน

2. ยืนยันการตอบกลับ อย่าเพียงแค่ดูผ่านๆ

ค่าพื้นฐานจะมีประโยชน์ก็ต่อเมื่อคุณตรวจสอบโดยอัตโนมัติ ใน Apidog ให้เพิ่มการยืนยัน (assertions) ไปยังคำขอ:

• สถานะคือ 200
• stop_reason คือ end_turn ไม่ใช่ max_tokens หรือการปฏิเสธ
• ตัวบอดี้การตอบกลับมีฟิลด์ที่มีโครงสร้างที่แอปของคุณแยกวิเคราะห์ (เช่น ป้ายกำกับลำดับความสำคัญ)
• เวลาตอบกลับยังคงอยู่ภายใต้งบประมาณการหมดเวลาของคุณ

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

3. จงใจทดสอบเส้นทางการปฏิเสธและ Guardrail

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

4. จำลอง Anthropic เพื่อให้การทดสอบของคุณเองไม่ขึ้นกับ API จริง

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

5. ตรวจสอบพฤติกรรมที่อ่อนไหวต่อการเก็บรักษาข้อมูล

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

6. ทดสอบภายใต้ภาระงานและการหมดเวลา

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

รายการตรวจสอบเชิงปฏิบัติ

ทำตามรายการนี้เพียงครั้งเดียว แล้วคุณจะรู้ว่าสถานะของคุณเป็นอย่างไร:

• [ ] ตรึง ID โมเดลเต็ม; หยุดพึ่งพานามแฝงที่ไม่แน่นอนสำหรับเส้นทางการผลิต
• [ ] บันทึกการตอบกลับที่เป็นค่าพื้นฐานสำหรับทุกพรอมต์ที่แอปของคุณพึ่งพา
• [ ] เพิ่มการยืนยันสำหรับสถานะ, stop_reason และฟิลด์ที่คุณแยกวิเคราะห์
• [ ] บันทึกรูปแบบการปฏิเสธและข้อผิดพลาด; ยืนยันว่าสิ่งเหล่านี้ไม่เปลี่ยนแปลงอย่างเงียบๆ
• [ ] จำลอง Messages API เพื่อให้ CI ไม่เรียกใช้เอนด์พอยต์จริง
• [ ] ตรวจสอบเพย์โหลดขาออกเทียบกับหน้าต่างการเก็บรักษา 30 วัน
• [ ] ทดสอบพฤติกรรมการหมดเวลาและการลองใหม่ภายใต้ภาระงานซ้ำๆ

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

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

ฉันจำเป็นต้องเปลี่ยนคีย์ API ของฉันเนื่องจากการเปลี่ยนแปลง Fable และ Mythos หรือไม่? ไม่ การยืนยันตัวตนไม่มีการเปลี่ยนแปลง การหมุนเวียนคีย์ตามกำหนดเวลายังคงเป็นแนวปฏิบัติที่ดี แต่การเปลี่ยนแปลงเหล่านี้ไม่ได้บังคับ

โค้ด Messages API และการใช้เครื่องมือที่มีอยู่ของฉันจะเสียหรือไม่? สัญญาการร้องขอและการตอบกลับมีความเสถียร ดังนั้นโค้ดของคุณยังคงทำงานได้ สิ่งที่อาจเปลี่ยนแปลงคือพฤติกรรม; การปฏิเสธ, ความหน่วง และเนื้อหาที่สตรีมภายใต้ Guardrail นั่นเป็นปัญหาในการทดสอบ ไม่ใช่การเขียนใหม่

การเปลี่ยนแปลงการเก็บรักษาข้อมูล 30 วันคืออะไร? รายงานอธิบายถึงหน้าต่างการเก็บรักษาข้อมูล 30 วันที่ใช้กับทราฟฟิก Fable และ Mythos หากข้อผูกมัดด้านความเป็นส่วนตัวของคุณขึ้นอยู่กับพฤติกรรมการเก็บรักษาข้อมูลของผู้ให้บริการต้นน้ำ ให้พิจารณาสิ่งนี้และยืนยันว่าคุณส่งข้อมูลใดไปบ้าง ควรตรวจสอบเอกสารการใช้ข้อมูลปัจจุบันของ Anthropic สำหรับข้อกำหนดที่เป็นทางการเสมอ

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

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

สรุป

การเปลี่ยนแปลง Fable และ Mythos เป็นเรื่องจริง แต่สำหรับนักพัฒนาส่วนใหญ่แล้ว นี่คือเรื่องราวเกี่ยวกับพฤติกรรมและนโยบาย ไม่ใช่เรื่องราวของ API ที่เสีย คีย์ของคุณใช้งานได้, การเรียกใช้ Messages ของคุณใช้งานได้, เครื่องมือของคุณใช้งานได้ สิ่งที่ต้องระวังคือส่วนที่เปลี่ยนแปลงอย่างเงียบๆ: การปฏิเสธ, ความหน่วง และสิ่งที่ข้อมูลของคุณทำหลังจากออกจากระบบของคุณ ตรึงโมเดลของคุณ, บันทึกค่าพื้นฐาน, ยืนยันสิ่งเหล่านั้น และจำลองระบบต้นน้ำเพื่อให้การทดสอบของคุณประหยัดและน่าเชื่อถือ ดาวน์โหลด Apidog และเปลี่ยนจาก “ฉันคิดว่ามันยังใช้งานได้” เป็น “ฉันตรวจสอบแล้ว และนี่คือหลักฐาน”