ส่ง error แบบมีโครงสร้างเพื่อให้ coordinator กู้คืนได้
แนวคิด
ในระบบหลาย agent เมื่อ subagent ตัวหนึ่งล้มเหลว วิธีที่มันส่งข้อมูลความล้มเหลวกลับไปหา coordinator เป็นตัวชี้ขาดว่าระบบจะกู้คืนได้อย่างชาญฉลาดหรือไม่ error ที่มีโครงสร้างคือกุญแจ มันควรบอกอย่างน้อยสี่อย่าง คือ ชนิดของความล้มเหลว, query หรือสิ่งที่พยายามทำ, ผลบางส่วนที่ได้มา, และทางเลือกที่พอเป็นไปได้
ลองพิจารณา Sample Question ข้อ 8 ของ exam guide subagent ค้นเว็บ time out ระหว่างค้นหัวข้อยาก คำถามคือควรออกแบบให้ข้อมูลความล้มเหลวไหลกลับสู่ coordinator แบบไหน คำตอบที่ถูกคือส่ง structured error context กลับไป ประกอบด้วยชนิดความล้มเหลว query ที่ลอง ผลบางส่วน และทางเลือก coordinator จึงมีข้อมูลพอจะตัดสินใจว่าจะลองใหม่ด้วย query อื่น เปลี่ยนวิธี หรือเดินหน้าด้วยผลบางส่วน
เทียบกับตัวเลือกที่แย่กว่า การ retry เองแบบ exponential backoff แล้วคืนแค่ "search unavailable" กว้าง ๆ ซ่อนบริบทมีค่าไป การกลืน timeout แล้วคืนผลว่างที่ทำเครื่องหมายว่าสำเร็จ กันการกู้คืนทุกทาง และการโยน exception ไปจบทั้ง workflow ก็ตัดโอกาสที่กลยุทธ์กู้คืนจะสำเร็จ
ทำไมสำคัญ
เอกสาร handle tool calls ของ Anthropic วางรากฐานของหลักนี้ เมื่อ tool ล้มเหลว ให้คืน tool_result พร้อมตั้ง is_error เป็น true และใส่ข้อความ error ที่ให้ข้อมูล docs เน้นชัดว่าอย่าคืน error กว้าง ๆ แบบ "failed" แต่ให้บอกว่าเกิดอะไรขึ้นและควรลองอะไรต่อ เช่น "Rate limit exceeded. Retry after 60 seconds." ข้อความแบบนี้ให้บริบทที่โมเดลใช้ปรับตัวหรือกู้คืนได้โดยไม่ต้องเดา
หลักเดียวกันขยายขึ้นไปที่ระดับ subagent เมื่อ subagent ทำงานในบริบทแยกของตัวเอง เอกสาร subagents ของ Claude Code อธิบายว่ามันคืนเฉพาะบทสรุปกลับให้ผู้ประสานงาน ไม่ใช่ประวัติการค้นทั้งหมด บทสรุปนั้นจึงต้องบรรจุข้อมูลกู้คืนให้ครบ ถ้า subagent สรุปแค่ว่า "ล้มเหลว" coordinator ก็ตาบอด แต่ถ้าสรุปเป็น error ที่มีโครงสร้าง coordinator จะเห็นทั้งสาเหตุ สิ่งที่ลองแล้ว และทางเลือก
สิ่งที่ต้องเข้าใจให้ลึกคือ error ที่มีโครงสร้างเปลี่ยนการจัดการความล้มเหลวจาก "หยุดหรือลองสุ่ม" เป็น "ตัดสินใจอย่างมีข้อมูล" ผลบางส่วนมีค่ามาก เพราะ coordinator อาจเดินหน้าด้วยของที่มีอยู่แล้วเติมส่วนที่ขาดทีหลัง แทนที่จะทิ้งงานทั้งก้อน แนวปฏิบัติที่ดีคือให้ subagent จัดการกู้คืน transient failure ในระดับตัวเองก่อน แล้ว propagate ขึ้นไปเฉพาะ error ที่แก้เองไม่ได้ พร้อมแนบสิ่งที่พยายามและผลบางส่วนไปด้วย
ตัวอย่าง
{
"failure_type": "timeout",
"attempted_query": "AI impact on music industry 2025",
"partial_results": ["บทความ 2 ชิ้นที่โหลดทัน"],
"suggested_alternatives": ["ลด scope เป็นรายปี", "เปลี่ยนคำค้นให้แคบลง"]
}
โครงสร้างแบบนี้ให้ coordinator มีทุกอย่างที่ต้องใช้ตัดสินใจกู้คืน แทนที่จะรู้แค่ว่า "ล้มเหลว"
เช็คความเข้าใจ
structured error context ที่ subagent ควรส่งกลับ coordinator ประกอบด้วยอะไรบ้าง และทำไมจึงดีกว่าสถานะกว้าง ๆ
ตาม docs เมื่อ tool ล้มเหลวควรคืน error อย่างไร และ subagent ควรจัดการ transient failure แบบใด