Claude Opus 5.5 ทำงาน 18 ชั่วโมง: วิธีออกแบบ API สำหรับเอเจนต์ที่ทำงานระยะยาว

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

ลองใช้ Apidog วันนี้

Anthropic กล่าวว่า Claude Opus 5.5 ทำงานต่อเนื่องได้ 18 ชั่วโมงหรือมากกว่านั้น

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

นี่คือปัญหาการออกแบบ API ไม่ใช่ปัญหาโมเดล นี่คือสิ่งที่พัง และสิ่งที่ต้องเปลี่ยน

สิ่งที่ Anthropic เผยแพร่จริง

ตัวเลขจากผู้จำหน่ายสำหรับโมเดลใหม่ เพื่อให้เราเถียงจากแผ่นเดียวกัน:

เกณฑ์มาตรฐานจากประกาศเดียวกัน: Terminal-Bench 4.0 66.4%, OSWorld 2.0 81.8%, AutomationBench 40.0%, FrontierCode v1.1 54.4%, CursorBench 4.0 57.8%, Humanity's Last Exam 67.7% เมื่อใช้เครื่องมือ, Chartography 89.0%, GDPval-AA v2.1 ที่ 1846 Elo, และความพยายามในการหลบเลี่ยงขอบเขตที่สำเร็จลดลง 85%

ตัวเลข 18 ชั่วโมงคือสิ่งที่ส่งผลกระทบต่อโครงสร้างพื้นฐานของคุณ คะแนนเกณฑ์มาตรฐานเปลี่ยนว่าคุณเลือกโมเดลใด ระยะเวลาต่อเนื่องเปลี่ยนสิ่งที่ API ของคุณต้องอยู่รอด

สมมติฐานหกข้อที่เลิกเป็นจริง

แต่ละข้อมีวิธีแก้ที่น่าเบื่อ เข้าใจดี และมักถูกข้ามไปเพราะไม่มีอะไรบังคับให้ต้องทำ ตอนนี้มีบางสิ่งกำลังบังคับ

คืนแฮนเดิล ไม่ใช่ทำงาน

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

POST /v1/reports HTTP/1.1 Host: api.example.com Idempotency-Key: 01J9Z4KCQ7M3XN2YB8V6H0 Content-Type: application/json {"dataset": "orders_2026_q3", "format": "parquet"} 

HTTP/1.1 202 Accepted Location: /v1/jobs/job_01J9Z4KD Retry-After: 5 Content-Type: application/json { "id": "job_01J9Z4KD", "status": "queued", "created_at": "2026-09-23T04:12:09Z", "api_version": "2026-08-01" } 

จากนั้นทรัพยากรสถานะจะบรรจุทุกสิ่งที่เอเจนต์ต้องการเพื่อตัดสินใจว่าจะทำอะไรต่อไป:

{ "id": "job_01J9Z4KD", "status": "running", "progress": { "completed": 41200, "total": 180000, "unit": "rows" }, "started_at": "2026-09-23T04:12:11Z", "updated_at": "2026-09-23T05:47:02Z", "expires_at": "2026-09-24T04:12:09Z", "retry_after_seconds": 15, "result_url": null, "error": null } 

สี่ฟิลด์ทำงานจริง progress พร้อม unit ที่ชัดเจนช่วยให้โมเดลใช้เหตุผลว่าการรอมีความสมเหตุสมผลหรือไม่ แทนที่จะเดาจากเวลาที่ผ่านไป retry_after_seconds ทำให้จังหวะการ poll อยู่ภายใต้การควบคุมของเซิร์ฟเวอร์ ซึ่งสำคัญเมื่อผู้เรียกไม่มีความรู้สึกเรื่องความสุภาพ expires_at บอกเอเจนต์ว่าแฮนเดิลใช้ได้นานแค่ไหน เพื่อให้มันบันทึกจุดตรวจก่อนที่จะสูญเสียมันไป และ api_version ผูกงานเข้ากับสัญญาที่มันถูกสร้างขึ้นภายใต้ สิ่งเดียวที่ขวางระหว่างการดีพลอยตอน 3 ทุ่มของคุณกับการรันที่เริ่มตั้งแต่รุ่งเช้า

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

ทำให้ idempotency มีอายุยืนกว่างาน

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

การเปลี่ยนแปลงสามอย่างมีต้นทุนน้อยมาก:

1. เผยแพร่หน้าต่าง — คืนเวลาหมดอายุในการตอบกลับเพื่อให้ผู้เรียกใช้เหตุผลได้ แทนที่จะจัดทำเอกสารครั้งเดียวแล้วหวัง
2. บอกเมื่อคุณเล่นซ้ำ — ส่วนหัว Idempotency-Replayed: true เปลี่ยนการไม่ดำเนินการแบบเงียบๆ ให้เป็นสิ่งที่เอเจนต์สามารถดำเนินการได้
3. ปฏิเสธความไม่ตรงกันอย่างชัดเจน — คีย์เดียวกัน เนื้อหาต่างกัน หมายความว่าผู้เรียกทำสถานะของตัวเองหายไป ให้คืน 409 พร้อมลายนิ้วมือคำขอเดิมแทนที่จะให้ผลลัพธ์ที่เก่า

HTTP/1.1 200 OK Idempotency-Replayed: true Idempotency-Expires: 2026-09-24T04:12:09Z 

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

สมมติว่าข้อมูลรับรองหมดอายุกลางงาน

การรัน 18 ชั่วโมงมีอายุยืนกว่า access token อายุสั้นเกือบทุกตัว นั่นคือท่าทีความปลอดภัยที่ถูกต้อง แต่เฉพาะเมื่อ API ของคุณทำให้ความแตกต่างนั้นชัดเจน

คืน 401 พร้อมความท้าทาย WWW-Authenticate: Bearer [REDACTED]="invalid_token" เมื่อโทเค็นหมดอายุ และสงวน 403 ไว้สำหรับ principal ที่ขาดสิทธิ์ เอเจนต์ปฏิบัติต่อสิ่งเหล่านี้ต่างกันมาก: อย่างหนึ่งหมายถึงรีเฟรชและดำเนินการต่อ อีกอย่างหมายถึงหยุดและรายงาน การรวมมันเข้าด้วยกันเป็นความล้มเหลวทั่วไปคือวิธีที่คุณจะได้เอเจนต์ที่เผาเวลาสี่ชั่วโมงลองใหม่สิ่งที่มันจะไม่ได้รับอนุญาตให้ทำ

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

ปฏิบัติต่อสตรีมเสมือนสามารถกลับมาทำต่อได้ ไม่ใช่เสมือนการเชื่อมต่อ

สตรีมยาวๆ หลุด ให้ถือว่าเป็นเรื่องปกติ และออกแบบการเชื่อมต่อใหม่แทนที่จะออกแบบการเชื่อมต่อ

สำหรับ server-sent events นั่นหมายถึงการให้ทุกเหตุการณ์มี id ที่เพิ่มขึ้นเรื่อยๆ, การเคารพส่วนหัวคำขอ Last-Event-ID เมื่อเชื่อมต่อใหม่, และการส่งความคิดเห็น keepalive ในช่วงเวลาที่สั้นกว่า idle timeout ที่สั้นที่สุดระหว่างคุณกับไคลเอนต์ ระบุชื่อคีย์การตั้งค่าในเอกสารของคุณเอง เพราะผู้อ่านต้องไปเปลี่ยนมัน: idle_timeout.timeout_seconds บนโหลดบาลานเซอร์ AWS, proxy_read_timeout ใน nginx, timeout บนบริการ Cloud Run ประเด็นไม่ใช่ค่าที่เจาะจง แต่คือค่ามีอยู่จริง สั้นกว่างาน และไม่มีใครดูมันตั้งแต่สร้างบริการมา คู่มือการสตรีม SSE ของเราครอบคลุมรูปแบบการส่งข้อมูล; ส่วนที่เฉพาะกับเอเจนต์คือการกลับมาทำต่อ

ส่วนหัว rate limit ก็สำคัญกว่าปกติเช่นกัน RateLimit-Limit, RateLimit-Remaining และ RateLimit-Reset ช่วยให้โมเดลกำหนดจังหวะของตัวเองตลอดการรันยาว และ Retry-After ในทุก 429 ขจัดการเดา เอเจนต์ที่ได้รับตัวเลขจะเคารพมัน เอเจนต์ที่ไม่ได้รับอะไรเลยจะคิด backoff ขึ้นมาเอง และสิ่งประดิษฐ์ของมันจะไม่ดีไปกว่าของคุณ

ด้านต้นทุนคือการตัดสินใจในการออกแบบ

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

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

ขนาดไม่ใช่แค่สมมติฐาน OpenAI เปิดเผยว่านักวิจัยค่ามัธยฐานใช้จ่ายมากกว่า $600 ต่อวันกับเอเจนต์เขียนโค้ด โดยเปอร์เซ็นไทล์ที่ 90 สูงกว่า $7,000 ต่อวัน นั่นคือค่าใช้จ่ายของงานเอเจนต์อย่างต่อเนื่องเมื่อไม่มีใครปรับให้เหมาะสม และเป็นส่วนหนึ่งของสาเหตุที่ การเปิดตัวโมเดลสามตัวในสองวัน ล้วนนำด้วยต้นทุนต่องานแทนต้นทุนต่อโทเค็น เลขคณิตของว่าเมื่อใดการแคชจะคืนทุนอยู่ใน รายละเอียดต้นทุนการแคชของ Opus 5.5 ของเรา

ทดสอบเส้นทางยาวก่อนที่เอเจนต์จะเจอ

ไม่มีสิ่งใดในนี้ที่ตรวจสอบได้โดยการคลิกส่งครั้งเดียวและอ่าน 200 ความล้มเหลวอยู่ในชั่วโมงที่เก้า

ใน Apidog ให้จำลองวงจรชีวิตทั้งหมดเป็นสถานการณ์ทดสอบแทนที่จะเป็นคำขอเดียว: ตรวจสอบว่าการเรียกสร้างคืน 202 พร้อม Location และ Retry-After, วนลูปเอนด์พอยต์สถานะจนถึงสถานะสิ้นสุด, และยืนยันว่า progress.completed ไม่เคยเคลื่อนถอยหลัง การยืนยันสุดท้ายจับบั๊กจริงได้มากกว่าการตรวจสอบรหัสสถานะใดๆ เพราะความคืบหน้าที่ไม่เพิ่มขึ้นเรื่อยๆ คือสิ่งที่ทำให้เอเจนต์เริ่มต้นใหม่

จากนั้นทำให้มันพังโดยเจตนาด้วย mock server ให้บริการงานที่คงสถานะ running เป็นเวลายี่สิบรอบการ poll แล้วจึงล้มเหลว ให้บริการ 429 โดยไม่มี Retry-After และดูว่าไคลเอนต์ของคุณทำอะไร ให้บริการ 401 กลางทางเพื่อยืนยันว่าเส้นทางการรีเฟรชทำงานในขณะที่งานกำลังดำเนินการ การทดสอบ SSE ของ Apidog จะคงการเชื่อมต่อสตรีมไว้และตรวจสอบเหตุการณ์แต่ละรายการ ซึ่งเป็นวิธีปฏิบัติเพียงวิธีเดียวในการตรวจสอบว่าการกลับมาทำต่อด้วย Last-Event-ID คืนเคอร์เซอร์ที่ถูกต้องแทนที่จะเล่นซ้ำจากศูนย์ เชื่อมสถานการณ์เข้ากับ CI เพื่อให้การเปลี่ยนแปลง timeout ในอนาคตล้มเหลวในการทดสอบแทนที่จะทำให้การรันข้ามคืนของลูกค้าล้มเหลว Apidog เริ่มต้นใช้ฟรี และสถานการณ์ที่คุณสร้างครั้งเดียวจะครอบคลุมทุกเอนด์พอยต์ที่ใช้เวลานานที่คุณเป็นเจ้าของ

รายการตรวจสอบสั้นๆ

• การดำเนินการที่ใช้เวลานานคืน 202 พร้อมแฮนเดิลงาน ไม่เคยถือการเชื่อมต่อ
• การตอบกลับสถานะมี progress, หน่วย, ช่วงการ poll ที่เซิร์ฟเวอร์เลือก และเวลาหมดอายุ
• งานผูกเวอร์ชัน API ที่สร้างขึ้นด้วย
• หน้าต่าง idempotency ถูกเผยแพร่, การเล่นซ้ำถูกติดป้าย, การใช้คีย์ซ้ำกับเนื้อหาที่เปลี่ยนไปคืน 409
• 401 สำหรับโทเค็นที่หมดอายุสามารถแยกได้จาก 403 สำหรับการถูกปฏิเสธ
• งานเป็นของ principal ไม่ใช่อินสแตนซ์ของโทเค็น
• สตรีมมี event id, เคารพ Last-Event-ID, และส่ง keepalive ภายใน idle timeout ที่สั้นที่สุดบนเส้นทาง
• ทุก 429 มี Retry-After, และส่วนหัว rate limit มีอยู่เสมอ
• สเปกและคำจำกัดความเครื่องมือถูกทำให้เป็นอนุกรมแบบ byte-stable เพื่อให้แคชฝั่งไคลเอนต์คงอยู่

Opus 5.5 ไม่ได้คิดค้นข้อกำหนดเหล่านี้ขึ้นมา มันเพียงลบข้ออ้างสุดท้ายสำหรับการข้ามมัน เพราะไคลเอนต์ที่เคยยอมแพ้ก่อนที่จะพบรอยร้าว ตอนนี้ทำงานผ่านรอยร้าวเหล่านั้นตรงๆ เป็นเวลาสิบแปดชั่วโมง