เอเจนต์เรียกใช้งานเอนด์พอยต์แปลงรหัสวิดีโอของคุณ เอนด์พอยต์ส่งคืน 202 Accepted และ ID งาน เอเจนต์ ซึ่งไม่ทราบว่า 202 หมายถึงอะไรในระบบของคุณ รายงานว่าการแปลงรหัสเสร็จสมบูรณ์แล้ว และดำเนินการไปยังขั้นตอนถัดไป ซึ่งเป็นการอ่านไฟล์ที่ยังไม่มีอยู่
การดำเนินการที่ใช้เวลานานทำให้เอเจนต์ทำงานผิดพลาดในลักษณะเฉพาะ การเรียกแบบซิงโครนัสมีข้อตกลงที่ชัดเจน: คุณส่ง, คุณรอ, คุณได้รับคำตอบ การเรียกแบบอะซิงโครนัสจะแบ่งออกเป็นจุดเริ่มต้นและจุดสิ้นสุด และช่องว่างระหว่างสองส่วนนี้คือสิ่งที่ทำให้เอเจนต์สับสน พวกมันประกาศความสำเร็จเร็วเกินไป พวกมันจะวนสอบถามซ้ำเป็นพันครั้งในลูปที่แน่นหนา หรือพวกมันจะถูกบล็อกเป็นเวลาหกนาทีโดยยังคงเปิดการสนทนาอยู่
คู่มือนี้ครอบคลุมถึงวิธีออกแบบสัญญาแบบอะซิงโครนัสเพื่อให้เอเจนต์สามารถปฏิบัติตามได้, ควรสอบถามเมื่อใดและควรส่งมอบงานเมื่อใด, วิธีเขียนเครื่องมือเพื่อให้โมเดลทำงานได้อย่างถูกต้อง และวิธีทดสอบเส้นทางทั้งหมดรวมถึงกรณีที่ช้าและล้มเหลว บทความของเราเกี่ยวกับ การกู้คืนข้อผิดพลาดของเอเจนต์ ครอบคลุมด้านความล้มเหลวของการเรียกใช้ API; ส่วนนี้ครอบคลุมถึงกรณีที่สำเร็จแต่ช้า
Apidog เหมาะสมในจุดที่คุณต้องการพิสูจน์ว่าเอเจนต์สามารถจัดการกับงานที่ใช้เวลาสี่นาทีแล้วล้มเหลว ซึ่งไม่ใช่สิ่งที่คุณต้องการค้นพบในสภาพแวดล้อมการผลิต
ทำไมเอเจนต์ถึงจัดการอะซิงโครนัสผิดพลาด
สามพฤติกรรมนี้เป็นสาเหตุหลักของปัญหา
โมเดลถือว่า 2xx หมายถึงเสร็จสิ้น 202 หมายถึงคำขอได้รับการยอมรับสำหรับการประมวลผล และ ข้อกำหนดความหมายของ HTTP ระบุไว้อย่างชัดเจนว่าการประมวลผลอาจยังไม่เสร็จสมบูรณ์ โมเดลที่ได้รับการฝึกฝนด้วยทราฟฟิกคำขอ/การตอบกลับทั่วไปมักจะอ่านค่า 2xx ใดๆ ว่าเป็นการเสร็จสมบูรณ์ เว้นแต่การตอบกลับจะระบุเป็นอย่างอื่นด้วยข้อความ
ลูปมีค่าใช้จ่ายสูง หากเอเจนต์ทำการสอบถามภายในลูปการให้เหตุผลของมัน การตรวจสอบแต่ละครั้งจะมีค่าใช้จ่ายเป็นเทิร์นของโมเดล บวกกับโทเค็นของการสนทนาก่อนหน้า การสอบถามทุกสองวินาทีสำหรับงานที่ใช้เวลาสี่นาทีจะเท่ากับ 120 เทิร์น และการรันจะสิ้นเปลืองบริบทหรือใช้งบประมาณหมดไป บทความของเราเกี่ยวกับ การรักษาสิ่งตอบกลับของเครื่องมือให้อยู่นอกหน้าต่างบริบท อธิบายว่าทำไมสิ่งนี้ถึงเพิ่มขึ้นเร็วกว่าที่ผู้คนคาดคิด
เอเจนต์สูญเสียการติดตามงาน เครื่องมือที่เริ่มทำงานและส่งคืน ID งานได้สร้างสถานะที่เอเจนต์ต้องนำไปใช้ต่อ หาก ID ไปอยู่กลางการสนทนาที่ยาวนาน มันอาจถูกย่อให้สั้นลง และเอเจนต์จะลืมว่ามีงานที่กำลังดำเนินการอยู่
ออกแบบการตอบกลับเพื่อไม่ให้โมเดลอ่านผิดพลาด
การแก้ไขที่มีประสิทธิภาพที่สุดคือการใช้คำพูด ไม่ใช่สถาปัตยกรรม ไม่ว่ารหัสสถานะของคุณจะเป็นอย่างไร ให้เนื้อหาใน Body ระบุอย่างชัดเจนว่าเกิดอะไรขึ้นและต้องทำอะไรต่อไป
{
"status": "processing",
"job_id": "job_7f21c",
"message": "การแปลงรหัสได้เริ่มต้นแล้วและยังไม่เสร็จสมบูรณ์ ห้ามรายงานว่าสำเร็จ ตรวจสอบสถานะด้วย getJobStatus(job_id) หลังจากผ่านไปอย่างน้อย 30 วินาที",
"poll_after_seconds": 30,
"estimated_duration_seconds": 240,
"status_url": "/v1/jobs/job_7f21c"
}
สำหรับผู้ใช้ API ที่เป็นมนุษย์ สิ่งนี้อาจดูรุนแรงเกินไป มันมุ่งเป้าไปที่โมเดล และโมเดลจะปฏิบัติตามคำสั่งที่ชัดเจนในเนื้อหาการตอบกลับได้น่าเชื่อถือกว่าการอนุมานความหมายจากรหัสสถานะมาก รายละเอียดสามประการที่ทำให้สิ่งนี้ใช้งานได้: คำว่า "ไม่เสร็จสมบูรณ์", เครื่องมือถัดไปที่ระบุชื่อ และการรอขั้นต่ำ
AIP-151 ของ Google ว่าด้วยการดำเนินการที่ใช้เวลานาน อธิบายถึงรูปแบบทรัพยากรที่ชัดเจนสำหรับสิ่งนี้ โดยมีออบเจกต์ Operation เดี่ยวที่ประกอบด้วยฟิลด์ done, error และ response การคัดลอกโครงสร้างดังกล่าวจะทำให้คุณมีพื้นผิวที่สอดคล้องกันในทุกเอนด์พอยต์ที่ทำงานช้า ซึ่งสำคัญเพราะเอเจนต์ที่เรียนรู้รูปแบบการสอบถามหนึ่งครั้งจะสามารถจัดการกับทั้งหมดได้
ทำให้การตอบกลับสถานะตรงไปตรงมาเช่นกัน:
{
"job_id": "job_7f21c",
"status": "processing",
"done": false,
"progress_percent": 45,
"elapsed_seconds": 108,
"poll_after_seconds": 45,
"message": "กำลังประมวลผลอยู่ ห้ามดำเนินการในขั้นตอนถัดไป"
}
และเมื่อเสร็จสมบูรณ์ ให้ส่งคืนผลลัพธ์ในบรรทัดหากมีขนาดเล็ก เพื่อให้เอเจนต์ไม่จำเป็นต้องเรียกใช้ครั้งที่สาม:
{
"job_id": "job_7f21c",
"status": "succeeded",
"done": true,
"result": { "output_url": "https://cdn.example.com/out/7f21c.mp4", "duration_seconds": 372 }
}
สอบถามจากภายนอกโมเดล ไม่ใช่ภายในโมเดล
ทางเลือกการนำไปใช้ที่สำคัญที่สุดเพียงอย่างเดียว: ให้การรอคอยอยู่ในตัวห่อหุ้มเครื่องมือของคุณ ไม่ใช่ในลูปการให้เหตุผลของเอเจนต์
import time
def start_and_await_transcode(client, source_url, max_wait=600):
job = client.post("/v1/transcode", json={"source_url": source_url}).json()
job_id = job["job_id"]
delay = job.get("poll_after_seconds", 5)
waited = 0
while waited < max_wait:
time.sleep(delay)
waited += delay
status = client.get(f"/v1/jobs/{job_id}").json()
if status.get("done"):
if status["status"] == "succeeded":
return {"status": "succeeded", "result": status["result"]}
return {"status": "failed", "error": status.get("error")}
delay = min(int(delay * 1.5), 60)
return {
"status": "timed_out",
"job_id": job_id,
"message": f"ยังคงทำงานอยู่หลังจาก {max_wait} วินาที งาน {job_id} ดำเนินการต่อในเบื้องหลัง",
}
จากมุมมองของโมเดล นี่คือการเรียกใช้เครื่องมือเพียงครั้งเดียวที่ใช้เวลาสักครู่และส่งคืนคำตอบสุดท้าย ไม่มีลูปการสอบถามในบริบท, ไม่มี ID งานที่ถูกลืม, ไม่มี 120 เทิร์น การหน่วงเวลาช่วยรักษานับจำนวนคำขอให้สมเหตุสมผล และเพดานจะหยุดงานที่ติดขัดไม่ให้รันค้างอยู่ตลอดไป บทความของ Amazon เกี่ยวกับ การจำกัดเวลา, การลองใหม่ และการหน่วงเวลาแบบมี Jitter เป็นข้อมูลอ้างอิงที่ควรค่าแก่การอ่านก่อนที่คุณจะปรับค่าเหล่านั้น
สองกฎที่ทำให้สิ่งนี้ปลอดภัย กำหนดขีดจำกัดการรอเสมอ และส่งคืน ID งานเมื่อหมดเวลาเสมอ เพื่อให้เอเจนต์หรือมนุษย์สามารถตรวจสอบภายหลังได้ อย่าส่งคืนผลลัพธ์ที่คลุมเครือ: succeeded, failed และ timed_out เป็นผลลัพธ์ที่แตกต่างกันสามอย่าง และโมเดลควรมองเห็นสามคำที่แตกต่างกัน
สำหรับงานที่วัดเป็นชั่วโมงแทนที่จะเป็นนาที การสอบถามภายในตัวห่อหุ้มจะเริ่มไม่มีความหมาย รูปแบบที่เหมาะสมคือเครื่องมือสองอย่าง อย่างหนึ่งสำหรับเริ่มต้นและอีกอย่างสำหรับตรวจสอบ บวกกับบันทึกถาวรของงานที่กำลังดำเนินการอยู่นอกบทสนทนา เพื่อไม่ให้ข้อมูลสูญหายจากการบีบอัด จัดเก็บ job_id, งานที่เกี่ยวข้อง และเวลาที่เริ่มต้น และให้เอเจนต์อ่านรายการนั้นที่จุดเริ่มต้นของการรันแต่ละครั้ง
เมื่อเว็บฮุคคือคำตอบที่ดีกว่า
การสอบถามนั้นเรียบง่ายและใช้งานได้ทุกที่ การเรียกกลับมีประสิทธิภาพมากกว่าและต้องทำงานมากขึ้นในการรัน การแลกเปลี่ยนนี้มีการอธิบายไว้อย่างดีในบทความ การเปรียบเทียบเว็บฮุคกับการสอบถาม ของเรา และเวอร์ชันเฉพาะเอเจนต์จะแคบกว่า
ใช้การสอบถามเมื่อ: งานใช้เวลาไม่กี่วินาทีถึงนาที, เอเจนต์กำลังรอผลลัพธ์เพื่อดำเนินการต่อ หรือเมื่อคุณไม่สามารถโฮสต์เอนด์พอยต์สาธารณะได้ งานส่วนใหญ่ของเอเจนต์จะอยู่ในกรณีเหล่านี้
ใช้เว็บฮุคเมื่อ: งานใช้เวลาหลายชั่วโมง, เอเจนต์เริ่มงานแล้วดำเนินการต่อ หรือเมื่อมีงานหลายงานทำงานพร้อมกันและการสอบถามแต่ละงานนั้นสิ้นเปลือง ค่าใช้จ่ายนั้นเป็นของจริง: คุณต้องมีตัวรับสาธารณะ, การยืนยันลายเซ็น, การจัดการการลองใหม่ และวิธีปลุกเอเจนต์เมื่อมีการเรียกกลับมา คู่มือของเราเกี่ยวกับ การออกแบบเว็บฮุคที่เชื่อถือได้ และ การยืนยันลายเซ็นเว็บฮุค ครอบคลุมพื้นฐานเหล่านั้น
มีทางเลือกกลางที่น่าสนใจ การสตรีมความคืบหน้าของงานผ่าน Server-Sent Events (SSE) ทำให้คุณได้รับเซแมนติกแบบพุชโดยไม่ต้องมีเอนด์พอยต์สาธารณะ เนื่องจากไคลเอ็นต์เป็นผู้ถือการเชื่อมต่อ เหมาะสำหรับเอเจนต์แบบโต้ตอบที่มนุษย์กำลังเฝ้าดู และคู่มือของเราเกี่ยวกับ การสตรีมการตอบกลับ API ด้วย SSE ครอบคลุมการนำไปใช้
ไม่ว่าคุณจะเลือกวิธีใด เส้นทางการเสร็จสมบูรณ์จะต้องเป็นแบบ Idempotent เว็บฮุคมีการลองใหม่, การสอบถามมีการแข่งกัน, และเอเจนต์ที่เห็น "succeeded" สองครั้งไม่ควรเริ่มขั้นตอนถัดไปซ้ำสองครั้ง บทความของเราเกี่ยวกับ Idempotency สำหรับเอเจนต์ AI ครอบคลุมคีย์ที่ทำให้สิ่งนั้นปลอดภัย
ทดสอบเส้นทางที่ช้า ไม่ใช่แค่เส้นทางที่เร็ว
ข้อบกพร่องแบบอะซิงโครนัสซ่อนอยู่เพราะสภาพแวดล้อมการทดสอบทำงานได้เร็ว งานที่ใช้เวลาสี่นาทีในสภาพแวดล้อมการผลิตจะเสร็จสิ้นใน 200 มิลลิวินาทีเมื่อเทียบกับ Stub ในเครื่อง ดังนั้นเอเจนต์จึงไม่เคยสัมผัสกับสถานะที่มันจะพบเจอจริงๆ
สี่สถานการณ์ที่ควรสร้างขึ้นโดยเจตนา
งานที่ช้าจริงๆ จำลองเอนด์พอยต์สถานะเพื่อให้ส่งคืน processing สำหรับการเรียกใช้หลายครั้งแรก และ succeeded หลังจากนั้น สิ่งนี้พิสูจน์ว่าตัวห่อหุ้มมีการสอบถาม, หน่วงเวลา และในที่สุดก็ส่งคืนค่า ใน Apidog คุณสามารถจำลองสิ่งนี้ด้วย Mock ที่เปลี่ยนแปลงตามจำนวนคำขอหรือตามพารามิเตอร์ควบคุม ดังนั้นการทดสอบเดียวกันจะทำงานในลักษณะเดียวกันทุกครั้ง
งานที่ล้มเหลวช้า ส่งคืน processing สามครั้ง จากนั้น failed พร้อมเนื้อหาข้อผิดพลาด เอเจนต์จะต้องรายงานความล้มเหลว แทนที่จะถือว่าการสอบถามที่เสร็จสมบูรณ์คืองานที่เสร็จสมบูรณ์ นี่คือกรณีที่ทำให้เกิดการสูญหายของข้อมูลโดยไม่รู้ตัวเมื่อทำงานผิดพลาด
การหมดเวลา ให้ Mock ส่งคืน processing เกินกว่าขีดจำกัดของตัวห่อหุ้ม และยืนยันว่าเครื่องมือส่งคืน timed_out โดยที่ ID งานยังคงอยู่ ไม่ใช่ข้อยกเว้นและไม่ใช่ความสำเร็จปลอม
การเสร็จสมบูรณ์ซ้ำซ้อน ส่งมอบความสำเร็จสองครั้ง ไม่ว่าจะโดยการลองใหม่ของเว็บฮุคหรือการสอบถามแบบแข่งกัน และยืนยันว่าขั้นตอนปลายน้ำทำงานเพียงครั้งเดียว
บันทึกทั้งสี่สถานการณ์ไว้เพื่อให้สามารถรันใน CI ได้ พวกมันไม่มีค่าใช้จ่ายในการรันซ้ำ และพวกมันจะตรวจจับการถดถอยเมื่อมีคนลดเวลาการหมดลงหรือกลืนข้อผิดพลาดไป แนวทางที่กว้างขึ้นอยู่ในคู่มือ การทดสอบสัญญา API ของเรา
สามงานที่แสดงให้เห็นปัญหา
การสร้างรายงาน เอเจนต์การเงินร้องขอการส่งออกรายไตรมาส ใช้เวลา 90 วินาที ด้วยเครื่องมือที่ซื่อตรง เอเจนต์จะได้รับ ID งาน, ประกาศว่ารายงานพร้อมแล้ว และส่งลิงก์ดาวน์โหลดที่เสียให้กับผู้ใช้ ด้วยตัวห่อหุ้มแบบบล็อก มันจะรอ 90 วินาทีและส่งคืน URL จริง API เดียวกัน, ผลลัพธ์ตรงกันข้าม, และความแตกต่างเดียวคือจุดที่เกิดการรอ
การนำเข้าจำนวนมาก เอเจนต์ฝ่ายปฏิบัติการอัปโหลด 20,000 รายการ การนำเข้าใช้เวลาแปดนาทีและล้มเหลวบางส่วนในแถวที่ 14,000 นี่คือกรณีที่ลงโทษการตรวจสอบความสำเร็จแบบง่ายๆ: งานเสร็จสิ้นแล้ว ดังนั้นสถานะ done เป็นจริง แต่ผลลัพธ์มีรายการแถวที่ถูกปฏิเสธ ส่งคืนผลลัพธ์บางส่วนอย่างชัดเจน พร้อมจำนวน และให้เอเจนต์อ่านสิ่งเหล่านั้นก่อนที่จะดำเนินการต่อ
โมเดลและไปป์ไลน์การสร้าง เอเจนต์เรียกใช้การฝึกอบรมหรือการสร้าง CI ที่ใช้เวลา 40 นาที การสอบถามภายในตัวห่อหุ้มไม่เหมาะสมในกรณีนี้; การรันจะเปิดเทิร์นไว้นานเกินไป เริ่มงาน, บันทึก ID ในที่จัดเก็บถาวร, สิ้นสุดเทิร์น, และให้การตรวจสอบตามกำหนดเวลาหรือการเรียกกลับปลุกการติดตาม บทความของเราเกี่ยวกับ การส่งมอบและส่งผ่านบริบทระหว่างเอเจนต์หลายตัว ครอบคลุมการย้ายสถานะนั้นระหว่างการรันโดยไม่สูญหาย
กำหนดรูปแบบสำหรับผลลัพธ์บางส่วน
งานที่ใช้เวลานานมักจะสิ้นสุดลงระหว่างความสำเร็จกับความล้มเหลว และโมเดลสองสถานะทำให้คุณต้องโกหกเกี่ยวกับเรื่องนี้ ทำให้สถานะที่สามชัดเจน:
{
"job_id": "job_a11f",
"status": "completed_with_errors",
"done": true,
"summary": { "processed": 20000, "succeeded": 19860, "failed": 140 },
"errors_url": "/v1/jobs/job_a11f/errors?limit=50",
"message": "การนำเข้าเสร็จสิ้น 140 แถวล้มเหลวและไม่ถูกบันทึก โปรดตรวจสอบข้อผิดพลาดก่อนรายงานว่าสำเร็จ"
}
สองสิ่งสำคัญใน Payload นั้น จำนวนต่างๆ อยู่ในบรรทัดเดียวกัน ดังนั้นเอเจนต์สามารถตัดสินใจได้โดยไม่ต้องมีการเรียกใช้เพิ่มเติม แถวที่ล้มเหลวอยู่เบื้องหลัง URL ที่มีขีดจำกัด ดังนั้นออบเจกต์ข้อผิดพลาด 140 รายการจึงไม่เข้ามาในบริบทโดยไม่ได้รับเชิญ
จะต้องมีใครสักคนเห็นงานที่หยุดชะงัก
เส้นทางการหมดเวลาจะจบลงด้วย ID งานและข้อความระบุว่างานยังคงทำงานอยู่ นั่นคือค่าที่ส่งคืนที่ถูกต้อง และจะมีประโยชน์ก็ต่อเมื่อมันไปถึงบุคคล
ในกรณีที่เอเจนต์เป็นบริการของคุณเอง ให้ส่งมันไปยังคิวใดๆ ที่ทีมของคุณกำลังเฝ้าดูอยู่ ในกรณีที่เอเจนต์เป็นรันไทม์การเขียนโค้ดที่ทำงานตามที่ได้รับมอบหมาย แพลตฟอร์มที่รันมันมักจะมีที่สำหรับสิ่งนี้ ใน Sharkly การรันที่จบลงด้วยการบล็อกจะยังคงอยู่ใน Task ของมันพร้อมกับสถานะการทำงานและผลลัพธ์ และ Inbox จะแยกรายการที่ต้องการการตอบกลับหรือการตรวจสอบจากมนุษย์ออกจากข้อมูลอัปเดตทั่วไป ประเด็นไม่ใช่เครื่องมือที่เฉพาะเจาะจง แต่คือ "ยังคงทำงานอยู่ ตรวจสอบภายหลัง" ต้องมีผู้รับผิดชอบ มิฉะนั้นมันจะกลายเป็น "ไม่มีใครตรวจสอบ"
รายการตรวจสอบสั้นๆ
- เอนด์พอยต์ที่ทำงานช้าทุกรายการจะส่งคืน ID งาน, URL สถานะ และข้อความภาษาธรรมดาที่ระบุว่างานยังไม่เสร็จสิ้น
- การตอบกลับสถานะมีฟิลด์
doneชนิดบูลีน ไม่ใช่แค่สตริงที่โมเดลต้องตีความ - การสอบถามจะอยู่ในตัวห่อหุ้มเครื่องมือพร้อมการหน่วงเวลาแบบ exponential backoff และขีดจำกัดสูงสุดที่แน่นอน
- การหมดเวลาจะส่งคืน ID งาน เพื่อให้สามารถดำเนินการต่อได้แทนที่จะสูญหาย
- ความสำเร็จ, ความล้มเหลว และการหมดเวลาเป็นค่าที่ส่งคืนสามค่าที่แตกต่างกัน
- งานที่กำลังดำเนินการจะถูกบันทึกไว้นอกบทสนทนาสำหรับงานที่ใช้เวลานานกว่าสองสามนาที
- การจัดการการเสร็จสมบูรณ์เป็นแบบ Idempotent ไม่ว่าสัญญาณจะมาถึงโดยการสอบถามหรือการเรียกกลับ
- การเสร็จสมบูรณ์ที่ช้า, ล้มเหลวช้า, หมดเวลา และซ้ำซ้อน ล้วนมีการทดสอบที่บันทึกไว้
จัดการคำพูดในการตอบกลับและตัวห่อหุ้มให้ถูกต้อง แล้วการดำเนินการที่ใช้เวลานานก็จะหยุดเป็นกรณีพิเศษสำหรับเอเจนต์ มันเรียกใช้เครื่องมือ, รอ, และได้รับคำตอบ ซึ่งเป็นสัญญาที่มันจัดการได้ดีที่สุด ดาวน์โหลด Apidog เพื่อสร้าง Mock สำหรับงานที่ช้าควบคู่ไปกับการทดสอบ
คำถามที่พบบ่อย
API ควรส่งคืน 202 หรือ 200 สำหรับการเริ่มต้นแบบอะซิงโครนัสหรือไม่? 202 Accepted คือรหัสที่ซื่อสัตย์และส่งสัญญาณไปยังไคลเอ็นต์มาตรฐานว่าการประมวลผลยังไม่เสร็จสมบูรณ์ อย่าพึ่งพามันเพียงอย่างเดียวสำหรับเอเจนต์ เนื่องจากเนื้อหาใน Body คือสิ่งที่โมเดลอ่านได้อย่างน่าเชื่อถือที่สุด ใช้ทั้งสองอย่าง
ตัวห่อหุ้มเครื่องมือควรรอนานแค่ไหนก่อนที่จะยอมแพ้? กำหนดขีดจำกัดสูงสุดให้สูงกว่ากรณีที่แย่ที่สุดที่เป็นจริงของเอนด์พอยต์เล็กน้อย โดยทั่วไปคือสองถึงสิบนาที เกินกว่านั้น ตัวห่อหุ้มจะบล็อกการสนทนาไว้นานเกินไป และเครื่องมือ "ตรวจสอบภายหลัง" จะเป็นรูปแบบที่ดีกว่า
ฉันควรใช้ช่วงเวลาการสอบถามนานเท่าใด? เริ่มต้นจากคำแนะนำ poll_after_seconds ของเซิร์ฟเวอร์เองหากมีให้ จากนั้นให้หน่วงเวลาด้วยปัจจัยประมาณ 1.5 โดยมีขีดจำกัดสูงสุดประมาณ 60 วินาที การสอบถามทุกหนึ่งวินาทีอย่างตายตัวเป็นการสิ้นเปลืองคำขอและอาจทำให้เกินขีดจำกัดอัตรา (rate limit) ได้ ดังที่ครอบคลุมใน คู่มือการเกินขีดจำกัดอัตรา ของเรา
เอเจนต์สามารถทำอะไรที่เป็นประโยชน์ในขณะที่รอดำเนินการได้หรือไม่? เฉพาะในกรณีที่ Orchestrator ของคุณรองรับการเรียกใช้เครื่องมือพร้อมกัน หากทำได้ ให้เริ่มงาน, ทำงานอิสระ, แล้วตรวจสอบสถานะ หากทำไม่ได้ ตัวห่อหุ้มแบบบล็อกจะเรียบง่ายและมีข้อผิดพลาดน้อยกว่าตัวกำหนดเวลาที่สร้างขึ้นเอง
ฉันจะหยุดไม่ให้เอเจนต์อ้างว่าสำเร็จเร็วเกินไปได้อย่างไร? ระบุด้วยข้อความในเนื้อหาการตอบกลับ, เปิดเผยฟิลด์ done ชนิดบูลีน และทำให้เครื่องมือการเสร็จสิ้นเป็นที่เดียวที่ผลลัพธ์ปรากฏ หากการตอบกลับเริ่มต้นไม่มีผลลัพธ์ ก็ไม่มีอะไรที่โมเดลจะรายงานว่าเป็นผลลัพธ์ได้
เว็บฮุคสามารถทำงานได้กับเอเจนต์ที่รันบนแล็ปท็อปหรือไม่? ไม่ได้โดยตรง เนื่องจากไม่มีเอนด์พอยต์สาธารณะ ใช้ Tunnel สำหรับการพัฒนา ดังในคู่มือของเราเกี่ยวกับการ ทดสอบ API ในเครื่องด้วยบริการเว็บฮุค หรือใช้วิธีการสอบถาม (polling) จนกว่าเอเจนต์จะทำงานในสถานที่ที่สามารถระบุที่อยู่ได้