เอเจนต์วิจัยพบบัญชีของลูกค้า ยืนยันแผน และดึงใบแจ้งหนี้สี่ฉบับล่าสุด มันส่งต่อให้เอเจนต์ฝ่ายเรียกเก็บเงินพร้อมสรุปสั้นๆ ว่า: “ลูกค้าต้องการคืนเงิน” เอเจนต์ฝ่ายเรียกเก็บเงิน ซึ่งตอนนี้ไม่รู้อะไรเลยเกี่ยวกับบัญชี แผน หรือใบแจ้งหนี้ ก็เริ่มต้นด้วยการขอรหัสบัญชี
ทุกข้อเท็จจริงที่เอเจนต์แรกเก็บรวบรวมถูกทิ้งไปที่ขอบเขต นั่นคือปัญหาการส่งต่องาน และมันทำให้คุณเสียค่าใช้จ่ายสองเท่า: ครั้งแรกในการเรียกใช้ API ที่ซ้ำซ้อน และครั้งที่สองในข้อผิดพลาดที่เกิดขึ้นจากเอเจนต์ตัวที่สองทำงานโดยมีข้อมูลน้อยกว่าตัวแรก
คู่มือนี้ครอบคลุมสิ่งที่ต้องคงอยู่ในการส่งต่องาน สามวิธีที่ทีมส่งผ่านสถานะและเวลาที่แต่ละวิธีทำงาน เหตุใดบทสรุปจึงสูญเสียข้อมูลมากกว่าที่ผู้คนคาดคิด และวิธีทดสอบว่าการส่งต่องานนำส่งข้อมูลได้ตามที่กล่าวอ้าง โพสต์ของเราเกี่ยวกับ เหตุใดเอเจนต์จึงล้มเหลวในการทำงานจริง ถือว่าสถานะที่หายไปเป็นโหมดความล้มเหลวหลัก นี่คือเวอร์ชันหลายเอเจนต์ของปัญหานี้
Apidog ปรากฏขึ้นเนื่องจากการแก้ไขที่ถูกที่สุดมักจะเป็นการหยุดส่งข้อมูลทั้งหมดและส่งผ่านตัวระบุแทน ซึ่งจะใช้ได้ก็ต่อเมื่อเอเจนต์ทุกตัวสามารถดึงระเบียนเดียวกันด้วยวิธีเดียวกันได้
สิ่งที่จำเป็นต้องข้ามขอบเขตจริงๆ
ไม่ใช่ทุกอย่าง การส่งต่อที่คัดลอกการสนทนาทั้งหมดนั้นผิดพลาดพอๆ กับการไม่คัดลอกอะไรเลย เพียงแต่เป็นคนละทิศทางกัน: เอเจนต์ตัวที่สองจะได้รับหน้าต่างบริบทเต็มรูปแบบและต้องพิจารณาว่าส่วนใดสำคัญ
มีสี่หมวดหมู่ที่ควรแยก
ตัวระบุ (Identifiers) รหัสบัญชี, รหัสคำสั่งซื้อ, รหัสงาน, หมายเลขตั๋ว สิ่งเหล่านี้มีขนาดเล็ก เสถียร และช่วยให้เอเจนต์ผู้รับสามารถดึงข้อมูลที่ต้องการได้ทุกอย่าง เป็นสิ่งที่มีค่าที่สุดในการส่งผ่านและเป็นสิ่งที่มักถูกละทิ้งมากที่สุด
การตัดสินใจที่ทำไปแล้ว (Decisions already made) “ลูกค้ามีสิทธิ์ได้รับการคืนเงินภายใต้นโยบาย 3” เอเจนต์ผู้รับจะต้องไม่นำเรื่องนี้มาพิจารณาซ้ำ หากเป็นเช่นนั้น คุณจะมีเอเจนต์สองตัวที่ไม่เห็นด้วยกันในงานเดียว
ข้อจำกัด (Constraints) ขีดจำกัดงบประมาณ, การอนุมัติที่ได้รับ, การดำเนินการที่ทำไปแล้ว การสูญเสียสิ่งเหล่านี้เป็นสาเหตุที่ทำให้งานถูกเรียกเก็บเงินซ้ำสองครั้ง หรือขอการอนุมัติซ้ำอีกครั้ง มันเชื่อมโยงโดยตรงกับโพสต์ของเราเกี่ยวกับ idempotency สำหรับเอเจนต์ AI
คำถามที่ยังเปิดอยู่ (Open questions) สิ่งที่เอเจนต์แรกไม่สามารถแก้ไขได้ การส่งผ่านสิ่งนี้อย่างชัดเจนจะช่วยป้องกันไม่ให้เอเจนต์ตัวที่สองสรุปเอาเองโดยไม่บอกกล่าว
สิ่งที่ไม่จำเป็นต้องข้ามไป: การตอบกลับ API ดิบ, บันทึกการให้เหตุผล, และสิ่งใดก็ตามที่เอเจนต์ผู้รับสามารถดึงมาได้ด้วยตัวเองในการเรียกครั้งเดียว
สามวิธีในการส่งผ่านสถานะ
ส่งต่อการสนทนาทั้งหมด ง่ายและใช้ได้ผลสำหรับเอเจนต์สองตัวในงานสั้นๆ งานเดียว มันจะล้มเหลวทันทีที่บันทึกการสนทนายาวขึ้น เพราะเอเจนต์ผู้รับจะใช้ทรัพยากรส่วนใหญ่ไปกับการอ่านประวัติ และข้อเท็จจริงที่เกี่ยวข้องจะถูกฝังอยู่ตรงกลาง โพสต์ของเราเกี่ยวกับ การเก็บการตอบสนองของเครื่องมือไว้นอกหน้าต่างบริบท อธิบายว่าทำไมตรงกลางนั้นจึงเป็นที่ที่โมเดลสูญเสียข้อมูลไป
ส่งต่อบทสรุป เอเจนต์ตัวแรกเขียนข้อความส่งต่องาน; ตัวที่สองเริ่มต้นจากข้อความนั้น นี่คือค่าเริ่มต้นในเฟรมเวิร์กส่วนใหญ่และเป็นวิธีที่ข้อมูลสูญหายในลักษณะเฉพาะ: โมเดลจะสรุปโดยเน้นไปที่เรื่องราวและละเว้นตัวระบุ หากขอสรุป คุณจะได้ “ลูกค้าเป็นสมาชิกมาสองปีแล้วและรู้สึกหงุดหงิด” แทนที่จะเป็น “บัญชี 8812, แผนโปร, ใบแจ้งหนี้สี่ฉบับ, อนุมัติการคืนเงินสำหรับใบแจ้งหนี้ inv_44”
ส่งต่ออ็อบเจกต์การส่งต่องานที่มีโครงสร้าง เอเจนต์ตัวแรกกรอกข้อมูลในสคีมา เอเจนต์ตัวที่สองอ่านฟิลด์ ไม่ใช่อ่านข้อความเรียงความ วิธีนี้ต้องใช้เวลาในการตั้งค่ามากกว่า แต่เป็นวิธีที่เชื่อถือได้
{
"task_id": "task_2026_08_26_0031",
"from_agent": "research",
"to_agent": "billing",
"entities": {
"customer_id": "cus_8812",
"invoice_ids": ["inv_41", "inv_42", "inv_43", "inv_44"],
"subscription_id": "sub_119"
},
"decisions": [
{ "decision": "refund_eligible", "value": true, "basis": "policy 3.2, charged twice in one cycle" }
],
"constraints": {
"max_refund_cents": 4900,
"human_approval_granted": false,
"actions_taken": ["read_invoices"]
},
"open_questions": ["Customer has not confirmed which invoice to refund"],
"summary": "Customer cus_8812 was double-charged in August. Refund of one invoice is approved under policy 3.2, up to 4900 cents. Awaiting the customer's choice of invoice."
}
ข้อความเรียงความยังคงปรากฏอยู่ในฟิลด์ summary เนื่องจากมันมีรายละเอียดปลีกย่อยที่สคีมาไม่มี มันอยู่เคียงข้างฟิลด์ที่มีโครงสร้าง แทนที่จะแทนที่ ซึ่งเป็นประเด็นสำคัญทั้งหมด
ตรวจสอบความถูกต้องของอ็อบเจกต์ก่อนที่จะส่งต่องาน หาก customer_id หายไป ให้แจ้งข้อผิดพลาดทันทีที่ขอบเขต แทนที่จะปล่อยให้เอเจนต์ตัวที่สองไปค้นพบในอีกสามการเรียกหลังจากนั้น
ส่งผ่านข้อมูลอ้างอิง ไม่ใช่เพย์โหลด
การส่งต่องานในเวอร์ชันที่แข็งแกร่งที่สุดแทบจะไม่มีการส่งข้อมูลใดๆ เลย มันส่งผ่าน ID และเอเจนต์ผู้รับจะดึงข้อมูลที่ต้องการ
วิธีนี้ใช้ได้ผลด้วยเหตุผลสามประการ สถานะยังคงเป็นปัจจุบัน ดังนั้นหากมีบางอย่างเปลี่ยนแปลงระหว่างเอเจนต์สองตัว ตัวที่สองจะเห็นค่าปัจจุบันแทนที่จะเป็นสำเนาที่ล้าสมัย การส่งต่องานยังคงมีขนาดเล็ก เพียงไม่กี่ร้อยไบต์แทนที่จะเป็นหลายหมื่นโทเค็น และการตรวจสอบเส้นทางจะดีขึ้น เนื่องจากทุกการอ่านจะปรากฏเป็นการเรียก API แทนที่จะเป็นข้อความที่คัดลอกระหว่างพร้อมต์
ต้องมีสิ่งเดียวเท่านั้นคือ: เอเจนต์ทุกตัวสามารถเข้าถึง API เดียวกันได้ด้วยสิทธิ์ที่ถูกต้อง ซึ่งไม่ใช่เรื่องง่าย เอเจนต์แต่ละตัวต้องมีข้อมูลรับรองของตัวเองที่กำหนดขอบเขตตามสิ่งที่ทำ ซึ่งเป็นข้อโต้แย้งในโพสต์ของเราเกี่ยวกับ คีย์ API ที่มีสิทธิ์น้อยที่สุดสำหรับเอเจนต์ เอเจนต์ฝ่ายเรียกเก็บเงินที่ถือโทเค็นวิจัยแบบอ่านอย่างเดียวไม่สามารถออกใบคืนเงินได้ และเอเจนต์วิจัยที่ถือโทเค็นเรียกเก็บเงินเป็นปัญหาด้านรัศมีระเบิด (blast-radius problem)
ในกรณีที่การดึงข้อมูลซ้ำจะมีราคาแพงหรือช้า ให้แคชระเบียนนั้นไว้ใน orchestrator ของคุณและส่งผ่านข้อมูลอ้างอิงไปยังรายการแคช เอเจนต์ผู้รับยังคงขอข้อมูลอย่างชัดเจน ดังนั้นรูปแบบยังคงเหมือนเดิม แต่การอ่านครั้งที่สองนั้นมีต้นทุนต่ำ
จุดที่การส่งต่องานล้มเหลว
ความล้มเหลวสี่ประการครอบคลุมเหตุการณ์ส่วนใหญ่
ตัวระบุที่หายไป บทสรุปกล่าวว่า “ลูกค้า” และไม่เคยให้ ID ดังนั้นเอเจนต์ตัวที่สองจึงค้นหาตามชื่อ พบสองรายการที่ตรงกัน และเลือกผิดตัว ป้องกันปัญหานี้โดยการตรวจสอบว่า ID เอนทิตีที่จำเป็นมีอยู่ก่อนที่จะอนุญาตให้มีการส่งต่องาน
การกระทำซ้ำซ้อน เอเจนต์ตัวแรกส่งอีเมลไปแล้ว การส่งต่องานไม่ได้บันทึกไว้ เอเจนต์ตัวที่สองส่งซ้ำอีกครั้ง บันทึก actions_taken ในอ็อบเจกต์การส่งต่องานและตรวจสอบก่อนที่จะมีการเขียนใดๆ โดยมีคีย์ idempotency ที่ทำให้การทำซ้ำไม่ก่อให้เกิดอันตราย
การอนุมัติที่สูญหาย มนุษย์อนุมัติการคืนเงินในขณะที่เอเจนต์ตัวแรกกำลังทำงานอยู่ เอเจนต์ตัวที่สองไม่ทราบเรื่องนี้ จึงถามอีกครั้ง ผู้ใช้จะมองว่าการแจ้งเตือนครั้งที่สองเป็นระบบที่ไม่รับฟัง บันทึกการอนุมัติเป็นข้อจำกัดที่ชัดเจน และถือว่าเป็นการอนุมัติที่จำกัดขอบเขตสำหรับงานนั้นๆ ไม่ใช่สำหรับเอเจนต์
การสร้างข้อมูลอย่างมั่นใจ (The confident invention) เอเจนต์ผู้รับต้องการค่าที่การส่งต่องานไม่ได้ส่งมา และแทนที่จะสอบถาม มันกลับสร้างค่าขึ้นมาเองที่เข้ากับเรื่องราว นี่เป็นความล้มเหลวที่อันตรายที่สุดเพราะดูเหมือนว่าเป็นงานที่เสร็จสมบูรณ์แล้ว การป้องกันคือฟิลด์ open_questions บวกกับกฎที่เข้มงวดในพร้อมต์ของเอเจนต์ผู้รับ: หากตัวระบุที่จำเป็นหายไป ให้หยุดและสอบถาม
การวนซ้ำทำให้ทั้งสี่ประการแย่ลง เมื่อเอเจนต์ A ส่งต่อให้ B และ B ส่งกลับให้ A สถานะจะเสื่อมลงในการส่งผ่านแต่ละครั้ง เหมือนกับสำเนาของสำเนา กำหนดขีดจำกัดจำนวนการส่งต่อและส่งผ่านอ็อบเจกต์งานต้นฉบับผ่านทุกๆ ครั้งแทนที่จะสร้างใหม่ที่แต่ละขอบเขต
ทดสอบขอบเขต ไม่ใช่แค่เอเจนต์
การส่งต่องานคือจุดเชื่อมต่อ ดังนั้นให้ทดสอบเหมือนจุดเชื่อมต่อ
ยืนยันความถูกต้องของอ็อบเจกต์การส่งต่องาน รันเอเจนต์ตัวแรกกับสถานการณ์ที่กำหนดและตรวจสอบอ็อบเจกต์ที่สร้างขึ้น: มีตัวระบุที่จำเป็น, มีการบันทึกการตัดสินใจ, มีการแสดงรายการการดำเนินการ นี่คือการยืนยันแบบกำหนดตายตัวสำหรับเพย์โหลดที่มีโครงสร้าง แม้ว่าเอเจนต์ที่สร้างขึ้นจะไม่เป็นแบบกำหนดตายตัว ซึ่งเป็นสิ่งที่ทำให้เป็นแบบทดสอบที่ใช้งานได้จริง แนวทางทั่วไปอยู่ในคู่มือของเราสำหรับการ ทดสอบเอเจนต์ที่ไม่ใช่แบบกำหนดตายตัว
ทดสอบผู้รับแยกกัน ป้อนอ็อบเจกต์การส่งต่องานที่สร้างขึ้นเองให้กับเอเจนต์ฝ่ายเรียกเก็บเงินและตรวจสอบว่ามันทำอะไร จากนั้นป้อนอ็อบเจกต์ที่จงใจเสียหาย โดยไม่มีรหัสลูกค้า และยืนยันว่ามันสอบถามแทนที่จะเดา การทดสอบครั้งที่สองนี้คือการจับการสร้างข้อมูล
รันทั้งสองแบบกับม็อก (mocks) การทดสอบการส่งต่องานที่ออกใบคืนเงินจริงเป็นการทดสอบที่คุณจะทำเพียงครั้งเดียว ชี้เอเจนต์ทั้งสองไปยังเอนด์พอยต์ที่จำลองขึ้นเพื่อให้ชุดทดสอบสามารถทำงานได้ทุกครั้งที่มีการเปลี่ยนแปลง โดยทำตามโพสต์ของเราเกี่ยวกับ การรันเอเจนต์กับม็อกแทนที่จะเป็นระบบการผลิต ใน Apidog ม็อกจะมาจากคำจำกัดความ API เดียวกันที่เอเจนต์ทั้งสองเรียกใช้ ดังนั้นทั้งสองจะไม่แตกต่างกัน
บันทึกทุกการส่งต่องาน บันทึกอ็อบเจกต์ทั้งหมดที่แต่ละขอบเขตพร้อมกับ ID งาน เมื่อการรันแบบหลายเอเจนต์ผิดพลาด บันทึกการส่งต่องานจะบอกคุณว่าเอเจนต์ตัวใดมีข้อมูลและตัวใดทำหาย ซึ่งมักจะเป็นการสอบสวนทั้งหมด โพสต์ของเราเกี่ยวกับ การติดตามการเรียกใช้เครื่องมือของเอเจนต์ ครอบคลุมสิ่งที่ควรอยู่ในบันทึกนั้น
สิ่งที่เฟรมเวิร์กมอบให้คุณ
เฟรมเวิร์กการจัดการส่วนใหญ่มาพร้อมกับ handoff primitive และสิ่งสำคัญคือต้องรู้ว่าแต่ละอันส่งผ่านอะไรข้ามขอบเขตจริงๆ ก่อนที่คุณจะพึ่งพามัน
เอกสารประกอบการส่งต่องานของ OpenAI Agents SDK จำลองการส่งต่องานเป็นเครื่องมือที่เอเจนต์สามารถเรียกใช้ได้ ซึ่งหมายความว่าโมเดลจะเป็นผู้ตัดสินใจว่าจะถ่ายโอนการควบคุมเมื่อใด สิ่งนี้สะดวกและทำให้การตัดสินใจอยู่ในส่วนที่คาดเดาได้น้อยที่สุดของระบบของคุณ ดังนั้นจึงควรจับคู่กับการตรวจสอบความถูกต้องในระหว่างการส่งออก
แนวทางการทำงานแบบหลายเอเจนต์ของ LangGraph ใช้แนวทางตรงกันข้าม: สถานะเป็นอ็อบเจกต์กราฟที่ชัดเจนซึ่งทุกโหนดอ่านและเขียน สิ่งนี้สอดคล้องอย่างใกล้ชิดกับการส่งต่องานที่มีโครงสร้างที่อธิบายไว้ข้างต้น และงานหลักที่เหลืออยู่คือการตัดสินใจว่าฟิลด์ใดบ้างที่จำเป็น
บทความของ Anthropic เรื่อง การสร้างระบบวิจัยแบบหลายเอเจนต์ คุ้มค่าที่จะอ่านสำหรับรายละเอียดการปฏิบัติงาน โดยเฉพาะอย่างยิ่งเกี่ยวกับจำนวนคำสั่งที่เอเจนต์ย่อยต้องการก่อนที่จะสามารถทำงานได้อย่างมีประโยชน์ด้วยตัวเอง
ประเด็นร่วมกันคือ: ทุกเฟรมเวิร์กจะส่งผ่านบางสิ่ง ไม่มีเฟรมเวิร์กใดตัดสินใจแทนคุณว่าข้อเท็จจริงใดมีความสำคัญ รายการนั้นเป็นของคุณที่จะเขียน และเป็นสิ่งที่มีค่าควรแก่การตรวจสอบเมื่อการทำงานผิดพลาด
เก็บอ็อบเจกต์งานไว้นอกการสนทนา
การเปลี่ยนแปลงโครงสร้างหนึ่งประการช่วยป้องกันข้อผิดพลาดได้ทั้งตระกูล จัดเก็บสถานะงานไว้ในที่ที่คงทน โดยใช้ task ID เป็นคีย์ และให้เอเจนต์ทุกตัวอ่านและเขียน แทนที่จะส่งผ่านทางข้อความ
การสนทนาเป็นที่เก็บสถานะที่ไม่ดี มันถูกบีบอัด ตัดทอน และเขียนใหม่ด้วยการสรุป และการดำเนินการเหล่านั้นไม่มีรายการใดที่ทราบว่าคุณไม่สามารถสูญเสียฟิลด์ใดได้ แถวในฐานข้อมูลไม่มีปัญหานั้น
รูปแบบนี้เล็กมาก เมื่อเริ่มรอบ เอเจนต์จะโหลดอ็อบเจกต์งาน เมื่อดำเนินการ มันจะเพิ่มข้อมูลลงใน actions_taken และบันทึก เมื่อส่งต่องาน มันจะส่งผ่าน ID งาน และเอเจนต์ผู้รับจะโหลดอ็อบเจกต์เดียวกัน ไม่มีสิ่งสำคัญใดๆ เดินทางไปในพร้อมต์ ดังนั้นจึงไม่มีสิ่งสำคัญใดๆ ที่จะถูกสรุปออกไปได้
นอกจากนี้ยังช่วยให้คุณมีจุดเริ่มต้นใหม่ หากการทำงานหยุดลงที่ขั้นตอนที่สี่ อ็อบเจกต์งานยังคงเก็บทุกสิ่งที่สามขั้นตอนแรกได้สร้างไว้ และการลองใหม่จะเริ่มต้นจากจุดนั้นแทนที่จะเริ่มต้นจากศูนย์
แพลตฟอร์มสามารถเก็บสถานะได้ที่ไหน
หากเอเจนต์ของคุณทำงานเป็น CLI runtimes บนเครื่องของนักพัฒนา อ็อบเจกต์งานที่คงทนที่อธิบายไว้ข้างต้นคือสิ่งที่คุณสร้าง แพลตฟอร์มการจัดการงานของเอเจนต์บางแห่งได้จำลองสิ่งนี้ไว้แล้ว และเป็นสิ่งที่มีค่าควรที่จะรู้ว่ามันมีลักษณะอย่างไรก่อนที่คุณจะสร้างของคุณเอง
Sharkly เป็นระบบจัดการงานสำหรับผู้คนและเอเจนต์ที่สร้างขึ้นโดยอิงจากหน่วยนี้โดยตรง งาน (Task) จะประกอบด้วยเป้าหมาย สถานะ ผู้รับผิดชอบ เอเจนต์หรือทีม (Crew) ที่ได้รับมอบหมายให้ดำเนินการ ความคิดเห็น และสถานะการดำเนินการและผลลัพธ์ของเอเจนต์ ทีม (Crew) จะจับคู่เอเจนต์ผู้นำกับเอเจนต์และผู้คนอื่นๆ ดังนั้นงานที่ต้องการผู้เชี่ยวชาญหลายคนจะถูกมอบหมายให้กับกลุ่มที่นำกลับมาใช้ใหม่ได้ แทนที่จะส่งต่อกันไปมาผ่านพร้อมต์ เนื่องจากสถานะอยู่บนงาน (Task) แทนที่จะอยู่ในการสนทนา การส่งต่องานระหว่างเอเจนต์สองตัวจึงไม่ขึ้นอยู่กับการสรุปผลที่ดีของเอเจนต์ตัวใดตัวหนึ่ง
รันไทม์ยังคงเป็นสิ่งที่คุณใช้งานอยู่แล้ว Claude Code, Codex และอื่นๆ ดำเนินการทำงานบนคอมพิวเตอร์ที่คุณลงทะเบียน; แพลตฟอร์มจะจัดหารายการงาน, การมอบหมาย, และวงจรการตรวจสอบรอบๆ สิ่งเหล่านั้น หากคุณกำลังสร้างรูปแบบ durable-task ด้วยตัวเอง เอกสารประกอบของ Sharkly เป็นแหล่งอ้างอิงที่มีประโยชน์สำหรับฟิลด์ที่สำคัญ
รายการตรวจสอบสำหรับการส่งต่องาน
- มีสคีมาที่กำหนดไว้สำหรับการส่งต่องาน และได้รับการตรวจสอบที่ขอบเขต
- ตัวระบุเอนทิตีเป็นฟิลด์ที่จำเป็น ไม่ใช่ฟิลด์ทางเลือก
- การตัดสินใจมีพื้นฐานรองรับ เพื่อไม่ให้ผู้รับต้องทำการให้เหตุผลซ้ำ
- การดำเนินการที่ทำไปแล้วจะถูกบันทึกและตรวจสอบก่อนที่จะมีการเขียนใดๆ
- การอนุมัติและงบประมาณเดินทางไปพร้อมกับงาน ไม่ใช่ไปพร้อมกับเอเจนต์
- คำถามที่ยังเปิดอยู่มีความชัดเจน และผู้รับจะสอบถามแทนที่จะสรุปเอาเอง
- ข้อมูลจะถูกส่งผ่านโดยการอ้างอิงในกรณีที่การดึงข้อมูลซ้ำมีต้นทุนต่ำ
- จำนวนการส่งต่อถูกจำกัด และอ็อบเจกต์งานต้นฉบับจะยังคงอยู่ตลอดทุกการส่งต่อ
- ทุกการส่งต่องานจะถูกบันทึกพร้อมกับ ID งาน
- การทดสอบขอบเขตทำงานใน CI โดยใช้ม็อก ซึ่งรวมถึงการส่งต่องานที่จงใจไม่สมบูรณ์
ความล้มเหลวส่วนใหญ่ของระบบหลายเอเจนต์ไม่ใช่ความล้มเหลวในการให้เหตุผล แต่เป็นข้อเท็จจริงที่มีอยู่ในเอเจนต์ตัวหนึ่งแต่ไม่มีในตัวถัดไป ออกแบบขอบเขตให้เป็นอินเทอร์เฟซ โดยมีสคีมาและการทดสอบ และเอเจนต์ตัวที่สองจะหยุดถามคำถามที่เอเจนต์ตัวแรกตอบไปแล้ว ดาวน์โหลด Apidog เพื่อเก็บม็อกและการทดสอบขอบเขตไว้ข้าง API ที่เอเจนต์ทั้งสองพึ่งพา
คำถามที่พบบ่อย
การส่งต่องานที่มีโครงสร้างคุ้มค่าสำหรับเอเจนต์สองตัวหรือไม่? สำหรับเอเจนต์สองตัวในงานสั้นๆ การส่งผ่านการสนทนามักจะใช้ได้ดี อ็อบเจกต์ที่มีโครงสร้างจะคุ้มค่าเมื่อมีเอเจนต์สามตัวขึ้นไป ในงานที่ใช้เวลานาน หรือทุกที่ที่การส่งต่องานข้ามกระบวนการหรือขอบเขตการทำงาน
โมเดลควรเขียนอ็อบเจกต์การส่งต่องาน หรือโค้ดควรสร้างมันขึ้นมา? โค้ดควรสร้างในส่วนที่ทำได้ ตัวระบุ การดำเนินการที่ทำไปแล้ว และการอนุมัติ ควรถูกเติมโดย orchestrator ของคุณจากสิ่งที่เกิดขึ้นจริง ไม่ใช่จากความทรงจำของโมเดล ปล่อยให้โมเดลเขียนเฉพาะ summary และคำถามที่ยังเปิดอยู่เท่านั้น
ฉันจะหยุดการเสื่อมถอยของบริบทในวงจรได้อย่างไร? ส่งผ่านอ็อบเจกต์งานเดียวตลอดการทำงานทั้งหมดและอัปเดตมัน แทนที่จะสร้างใหม่ที่แต่ละขอบเขต จากนั้นจำกัดจำนวนการส่งต่อ หากงานต้องการมากกว่าไม่กี่ครั้ง การแบ่งส่วนงานอาจผิดพลาด
แล้วเฟรมเวิร์กที่มีการรองรับการส่งต่องานในตัวล่ะ? ใช้มัน และตรวจสอบว่าพวกมันส่งผ่านอะไรจริงๆ หลายเฟรมเวิร์กส่งผ่านประวัติข้อความเท่านั้น ซึ่งหมายความว่าตัวระบุจะยังคงอยู่ได้ก็ต่อเมื่อปรากฏในข้อความ เพิ่มเพย์โหลดที่มีโครงสร้างควบคู่ไปกับสิ่งที่เฟรมเวิร์กส่งผ่าน
เอเจนต์ย่อยจำเป็นต้องมีข้อมูลรับรอง API แยกต่างหากหรือไม่? ใช่ โดยกำหนดขอบเขตตามสิ่งที่แต่ละตัวทำ การแบ่งปันคีย์ที่มีประสิทธิภาพเพียงคีย์เดียวระหว่างเอเจนต์จะทำให้คุณไม่สามารถจำกัดความเสียหายและบอกได้ว่าเอเจนต์ตัวใดทำการเรียก โพสต์ของเราเกี่ยวกับ คีย์ API ที่มีสิทธิ์น้อยที่สุดสำหรับเอเจนต์ ครอบคลุมการตั้งค่านี้
ฟิลด์สรุปควรมีเนื้อหามากแค่ไหน? ไม่กี่ประโยค ครอบคลุมเจตนาและรายละเอียดปลีกย่อยที่ฟิลด์ที่มีโครงสร้างไม่สามารถรองรับได้ หากเริ่มแสดงรายการ ID และจำนวนเงิน สิ่งเหล่านั้นควรอยู่ในฟิลด์ที่มีโครงสร้างซึ่งสามารถตรวจสอบได้