Integration & handoffs → agent คุยกันยังไง

เดินมาถึงบทนี้ แผนที่ใหญ่ถูกวางไว้แล้ว — ในบทก่อนๆ เราวาด Context Map ว่าระบบ ops-copilot มี agent อะไรบ้างและใครเป็นต้นน้ำ-ปลายน้ำ (บทที่ 5) และสร้าง Anti-Corruption Layer ให้ tool คอยแปลความรกของ backend ไม่ให้ไหลเข้ามาปนใน context ของ agent (บทที่ 6) คำถามที่ยังค้างคือ ตอนที่ agent สองตัวต้องส่งงานข้ามขอบเขตกันจริงๆ มันคุยกันยังไง — และตรงนี้เองที่คำศัพท์สองคำมักถูกเรียกปนกันจน design เพี้ยน

ย้ำก่อนเข้าเรื่อง: การที่ agent ต้องคุยกันเป็นดินแดนของ ข้อยกเว้นที่มีเหตุผลแล้ว ไม่ใช่ค่าเริ่มต้น คุณมาถึงบทนี้ได้เพราะ Multi-agent ผ่านประตูเหตุผล (รักษา context / ขนานงาน / ความเชี่ยวชาญเฉพาะ + ประตูต้นทุนราว ~15×) มาแล้วในบทก่อน งานส่วนใหญ่ยังควรจบใน Agent ที่มีขอบเขตดีตัวเดียวหรือ workflow ธรรมดา บทนี้ว่าด้วย กลไกการส่งต่อ เมื่อการแตกตัวถูกพิสูจน์แล้วเท่านั้น

📦 code ตัวอย่าง

คอร์สนี้เป็น คอร์สออกแบบ ไม่ใช่ทัวร์ SDK — code ในบทนี้คือ ภาพร่าง ของสัญญา handoff, schema ของ tool และโทโพโลยี (Thai Mermaid + pseudo-config สั้นๆ) ไม่ใช่ app ที่รันได้จริง ตัวอย่าง LangGraph / OpenAI Agents SDK / Claude ที่พูดถึงเป็นเชิงอธิบายเท่านั้น ทุกอย่างต่อยอดจาก domain เดิมที่ repo kaen-food-ordering (กำลังจัดทำ) โดยมองมันผ่านเลนส์ ops-copilot ที่ช่วยทีมปฏิบัติการ

delegation กับ handoff เป็นคนละ topology

Delegation กับ Handoff ฟังดูเหมือนกัน — “agent หนึ่งส่งงานให้อีกตัว” — แต่เป็นคนละโทโพโลยีที่ต่างกันสิ้นเชิงตรง ใครถือความเป็นเจ้าของงานหลังส่ง

Delegation (แบบ orchestration) คือ model ที่ How we built our multi-agent research system (Anthropic, Jun 2025) ใช้: มี lead agent ตัวหนึ่งแตกงานใหญ่เป็น subtask แล้วมอบให้ subagent ทำ พอ subagent ทำเสร็จ ผลลัพธ์คืนกลับมาที่ lead แล้ว lead เอาไปประกอบต่อ lead ไม่เคยปล่อยความเป็นเจ้าของบทสนทนาเลย — นี่คือ Orchestrator-Workers ที่เกริ่นไว้ตอนต้นคอร์ส subagent เป็นเหมือนลูกน้องที่หัวหน้าใช้ให้ไปหาข้อมูลมา ไม่ใช่คนที่รับช่วงไปคุยกับลูกค้าแทน

ใน domain เรา: Customer-Support รับเรื่อง “ทำไมออเดอร์ #4821 ช้า” มันไม่ได้ถือ tool อ่านสถานะเอง จึง delegate งานย่อย “ดึงสถานะ + ETA ของ #4821 คืนมาเป็น JSON” ให้ Order-Tracking แล้วรอผลกลับ พอได้ ETA มา Customer-Support ก็ร่างคำตอบเองแล้วตอบลูกค้า — Order-Tracking ไม่เคยเห็นหน้าลูกค้า และ Customer-Support ยังเป็นเจ้าของบทสนทนาตั้งแต่ต้นจนจบ

Handoff (แบบโอนการควบคุม) เป็นคนละเรื่อง OpenAI Agents SDK — Handoffs นิยาม handoff เป็น tool call ชนิดพิเศษที่ “คืน” Agent อีกตัวกลับมาแทน พอ agent เรียก handoff การควบคุมบทสนทนา โอนถาวร ไปยัง agent ปลายทาง — agent เดิมออกจากภาพ ไม่ได้รอผลอะไรกลับมาประกอบต่อ (คำว่า handoff ถือกำเนิดจาก Swarm ซึ่งเป็น project ทดลองที่เลิกใช้ไปแล้ว Agents SDK คือรุ่นสืบทอด — อ้างถึงในฐานะต้นกำเนิดของคำเท่านั้น ไม่ใช่ API ที่ต้องยึด)

ใน domain เรา: ลูกค้าเข้ามาที่ agent คัดกรอง (triage) พิมพ์ว่า “ขอปรับราคาเมนูในร้านฉัน” triage รู้ว่านี่คือภาษาของอีก context จึง handoff ให้ Restaurant-Ops แล้วถอยออก จากวินาทีนั้น Restaurant-Ops เป็นเจ้าของบทสนทนาเต็มตัว triage ไม่กลับมาอีก

สองอย่างนี้ อย่าเรียกด้วยคำเดียว เพราะมันตอบคนละคำถามใน design: delegation ตอบว่า “lead จะยืมมือใครไปทำงานย่อย” ส่วน handoff ตอบว่า “ควรส่งไม้ต่อให้ใครเป็นเจ้าของเรื่องนี้แทน” การสลับสองคำนี้ทำให้ทีมวาง flow ผิด เช่น สร้าง handoff ในที่ที่ควรเป็น delegation แล้วจู่ๆ agent ต้นทางก็หายไปทั้งที่ยังต้องรับผิดชอบผลรวม

flowchart TB
  subgraph DEL["Delegation (Anthropic): ผลคืนกลับ lead"]
    direction LR
    LEAD["Customer-Support (lead)<br/>เป็นเจ้าของบทสนทนาตลอด"]
    SUB["Order-Tracking (subagent)<br/>อ่านสถานะอย่างเดียว"]
    U1["ลูกค้า"]
    LEAD -->|"delegate: ดึง ETA #4821 คืนเป็น JSON"| SUB
    SUB -->|"ผลลัพธ์คืนกลับ lead"| LEAD
    LEAD -->|"ประกอบคำตอบเองแล้วตอบ"| U1
  end
  subgraph HAND["Handoff (OpenAI): ความเป็นเจ้าของโอนถาวร"]
    direction LR
    TRI["Triage agent<br/>รับเรื่องเข้ามา"]
    RO["Restaurant-Ops agent<br/>เป็นเจ้าของต่อจากนี้"]
    U2["ลูกค้า"]
    GONE["control โอนไปแล้ว"]
    TRI -->|"handoff: tool call คืน Agent ใหม่"| RO
    RO -->|"คุยกับลูกค้าต่อโดยตรง"| U2
    TRI -.->|"ออกจากภาพ ไม่กลับมา"| GONE
  end
  classDef lead fill:#c7d2fe,stroke:#3730a3,color:#1a1a1f;
  classDef sub fill:#bbf7d0,stroke:#166534,color:#1a1a1f;
  classDef gone fill:#fed7aa,stroke:#9a3412,color:#1a1a1f;
  class LEAD,TRI lead;
  class SUB,RO sub;
  class GONE gone;

คำบรรยายภาพ: ซ้ายคือ delegation — Customer-Support (lead, น้ำเงิน) ยืมมือ Order-Tracking (subagent, เขียว) ไปดึง ETA แล้ว ผลคืนกลับ lead ซึ่งประกอบคำตอบเองและเป็นเจ้าของบทสนทนาตลอด ขวาคือ handoff — triage โยนการควบคุมให้ Restaurant-Ops แบบ ถาวร แล้วออกจากภาพ (ส้ม) ทั้งสองเป็นดินแดนของข้อยกเว้นที่พิสูจน์แล้ว ไม่ใช่ค่าเริ่มต้น — และย้ำตามวินัยเดิม: เส้นที่แบ่ง lead ออกจาก subagent ในภาพนี้ลากบนจุดที่ ภาษาและระดับความไว้ใจเปลี่ยน ไม่ใช่ตามตำแหน่งงานหรือ subdomain “subagent” บางตัวจริงๆ อาจเป็นแค่ workflow หรือ tool ที่ยังไม่ต้องเป็น agent เต็มตัว และบางกล่องอาจยุบรวมกันได้ งานส่วนใหญ่ยังควรจบใน agent ที่มีขอบเขตดีตัวเดียว ภาพนี้เพียงอธิบาย กลไกส่งต่อ เมื่อการแตกตัวถูกพิสูจน์แล้วเท่านั้น

สัญญาข้ามขอบเขตคือ published language

ไม่ว่าจะ delegation หรือ handoff สิ่งที่ข้ามเส้นแบ่งไปไม่ใช่ “ข้อความ” ลอยๆ แต่คือ สัญญา และสัญญานั้นคือ Published Language — ภาษากลางที่เอกสารไว้ชัดสำหรับแลกเปลี่ยนข้าม context เหมือน API ระหว่างทีม ไม่ใช่ภาษาธรรมชาติที่ปลายทางตีความเอาเอง

สัญญาที่ดีต้องพกของครบสี่อย่าง:

objective — เป้าหมายชัดว่าจะให้ทำอะไร วัดผลได้
รูปแบบผลลัพธ์ (output format) — คืนกลับมาเป็นอะไร มี field อะไรบ้าง (schema ที่นิ่ง)
ให้ใช้ tool/source ไหน — ดึงจากแหล่งไหน ไม่ปล่อยให้ subagent เดาเองว่าจะไปเอาข้อมูลจากที่ใด
ขอบเขตชัด — ทำแค่ไหน หยุดตรงไหน อะไรที่ห้ามแตะ

delegate_to: order-tracking            # subagent ปลายทาง
task:
  objective: "ดึงสถานะปัจจุบันและ ETA ของออเดอร์ #4821"     # 1) objective ชัด วัดผลได้
  output_format:                       # 2) รูปแบบผลลัพธ์ที่ต้องคืน
    status: enum[cooking, picked_up, delivering, delivered]
    eta_minutes: int
    last_event_at: iso8601
  source: order-status-service         # 3) ดึงจากแหล่งนี้เท่านั้น ห้ามเดา
  scope: "อ่านอย่างเดียว ห้ามแก้สถานะ ห้ามติดต่อลูกค้าเอง"   # 4) ขอบเขตชัด

ทำไมต้องละเอียดขนาดนี้ Anthropic เล่าตรงๆ ใน post เดียวกันว่าคำสั่ง delegation ที่กำกวมคือสาเหตุความพังที่พบบ่อย — subagent ที่ได้โจทย์คลุมเครือจะ ทำงานซ้ำกัน (สองตัวไปดึงข้อมูลก้อนเดียวกัน) หรือ ตกหล่น (ทุกตัวคิดว่าอีกตัวจะทำ) สัญญาที่คมชัดคือสิ่งที่รักษาไม่ให้ context และงบของทั้งระบบเปลืองไปกับงานซ้ำและช่องโหว่

delegate_to: order-tracking
task: "เช็กออเดอร์ #4821 ให้หน่อย"
# ไม่บอก objective ให้ชัด ไม่บอก output format ไม่บอกแหล่ง ไม่บอกขอบเขต
# → subagent เดาเอง: อาจไปแก้สถานะ หรือติดต่อลูกค้าซ้ำกับ lead
# → subagent อีกตัวที่ได้โจทย์คลุมเครือคล้ายกันก็ดึงข้อมูลก้อนเดียวกันซ้ำ

สังเกตว่า field ในสัญญาก็คือ Ubiquitous Language ของเส้นแบ่งนั้นตรงๆ — ถ้าคำว่า “order” ของ Customer-Support กับของ Order-Tracking หมายคนละอย่าง ตรงนี้แหละที่ ACL จากบทที่แล้วต้องแปล published language จึงวางอยู่บน context map อีกที ไม่ใช่สองสิ่งแยกกัน

handoff มีจุดอ่อนที่ delegation ไม่มี: พอโอนการควบคุมไป ถ้าเราส่งไปแค่ ข้อความสุดท้าย หรือagent ปลายทางจะไม่เห็น “เหตุผลระหว่างทาง” ที่พาเรื่องมาถึงจุดนี้ Cognition — Don’t Build Multi-Agents ชี้จุดนี้คมมาก: ระหว่างที่ agent ทำงาน มันตัดสินใจโดยนัยเต็มไปหมด — เลือกตีความคำขอแบบหนึ่ง เลือกเชื่อข้อมูลชิ้นหนึ่ง ถ้า handoff ส่งไปแค่ประโยคสุดท้าย agent ตัวใหม่จะตัดสินใจบนข้อมูลไม่ครบ และลงเอยด้วยการตัดสินใจที่ ขัด กับสิ่งที่ทำมาแล้ว

ทางแก้ของ Cognition ตรงไปตรงมา: เมื่อส่งงานต่อ ให้ share trace เต็ม — ประวัติการตัดสินใจ ข้อความ และผลของ tool ทั้งเส้น ไม่ใช่แค่ message ก้อนเดียว agent ปลายทางจะได้สืบสายว่าทำไมถึงมาถึงตรงนี้ ก่อนตัดสินใจก้าวต่อไป

ตรงนี้ต้องพูดความจริงข้อหนึ่งให้ชัด แม้ทั้งคอร์สจะเทียบ agent กับ bounded context: agent ไม่ใช่ aggregate ใน DDD, aggregate รักษา invariant ของมันแบบ atomic — ผ่านขอบเขตแล้วการันตีว่ากฎไม่มีวันแตก แต่ context ของ agent ไม่ใช่แบบนั้น หลังผ่าน compaction หรือ summarization “ขอบเขต” ของมันเป็นแค่ best-effort — บทสรุปอาจตัดข้อเท็จจริงชิ้นเดียวที่สำคัญที่สุดทิ้งไป การ handoff ข้าม agent จึงเปราะกว่าการข้ามขอบเขต aggregate เสียอีก เพราะเราสมมติไม่ได้เลยว่า invariant รอดผ่านบทสรุปมา ด้วยเหตุนี้วินัยเรื่องนี้จึงต้องพึ่งสามอย่างเสมอ: Agent Memory ภายนอกที่จำสิ่งสำคัญไว้แบบคงทน, Guardrail ที่ re-check กฎซ้ำตรงขอบเขต, และ Eval ที่วัดว่า handoff รักษาสิ่งที่ต้องรักษาไว้ได้จริง — การบังคับกฎเป็น best-effort ไม่ใช่ atomic นี่คือราคาของการทำงานบนภาษาธรรมชาติ

มีข้อควรระวังกลับด้านซ่อนอยู่: “share trace เต็ม” ใช้กับ การส่งต่องานที่ทำค้างไว้ (handoff หรือ delegation ที่ต้องสานต่อ) — ปลายทางต้องตัดสินใจแบบเดียวกับที่ต้นทางจะตัดสิน จึงต้องเห็นเท่ากัน แต่มีงานอีกแบบที่ตรงกันข้าม: งานที่ เป็นก้อนปิดในตัว เช่นการตรวจงาน ยิ่งโอน context น้อยยิ่งดี — และนั่นพาไปสู่ pattern ที่ดีที่สุดของทั้งบท

pattern ที่พิสูจน์แล้วดีที่สุดคือ verification subagent

ในบรรดา pattern multi-agent ทั้งหมด ตัวที่คุ้มค่าสม่ำเสมอที่สุดคือ verification / reviewer subagent — agent แยกตัวหนึ่งที่มี bounded context เดียวคือ “ตัดสินว่าผลงานชิ้นนี้ผ่าน spec ไหม” มันได้ผลเพราะสามอย่างพร้อมกัน: (1) โอน context น้อยมาก — ส่งไปแค่ ตัวชิ้นงาน + เกณฑ์รับ ไม่ต้องส่งเหตุผลของคนทำ (ที่จริงการเห็นเหตุผลของคนทำยิ่งทำให้ผู้ตรวจ ลำเอียง ตาม), (2) bounded context สะอาด — ภาษาของมันคือ “ผ่าน / ไม่ผ่าน + เหตุผล” เท่านั้น, และ (3) มันเป็น delegation ไม่ใช่ handoff — ผลคืนกลับ lead ความเป็นเจ้าของไม่ย้าย ด้วยสามข้อนี้ reviewer subagent จึงเป็นการแตก multi-agent ที่คุ้มค่าสม่ำเสมอที่สุด — จับของเสียได้จริงโดยแทบไม่เพิ่มความเสี่ยงเชิงขอบเขต เพราะมันไม่เคยถือความเป็นเจ้าของงานเลย

ใน domain เรา: ก่อน Restaurant-Ops จะ commit การปรับราคาเมนู มันส่งข้อเสนอ (เมนู, ราคาใหม่) + เกณฑ์ (ห้ามต่ำกว่าต้นทุน, อยู่ในช่วงที่ร้านอนุญาต) ให้ verification subagent ตรวจ subagent คืน “ผ่าน” หรือ “ไม่ผ่าน + เพราะราคาต่ำกว่าต้นทุน 12%” กลับมา Restaurant-Ops ยังเป็นเจ้าของการตัดสินใจ และ Human-in-the-loop ยังกั้นการ commit จริงที่ย้อนกลับไม่ได้อยู่ดี — verification subagent แค่กรองของเสียออกก่อนถึงมือคน

นี่คือหน้าตาของ “multi-agent ที่คุ้มจริง”: แคบ, มูลค่าสูง, โอน context น้อย, เป็น delegation ไม่ใช่ handoff — ไม่ใช่ การตั้ง agent หนึ่งตัวต่อหนึ่ง Subdomain แล้วปล่อยให้คุยกันมั่ว

สิ่งที่จะทำต่อ

บทนี้ปิดกลไกการส่งต่อ — delegation กับ handoff เป็นคนละ topology, สัญญาข้ามขอบเขตคือ published language ที่พกครบสี่อย่าง, และการส่งต่องานค้างต้อง share trace เต็มเพราะขอบเขตของ agent เป็น best-effort ไม่ใช่ atomic บทสุดท้าย (บทที่ 8) ปิดคอร์สด้วยคำถามที่ตรงข้ามกับความตื่นเต้นทั้งหมดนี้: เมื่อไรไม่ควรใช้ agent เลย — ประตูต้นทุน, งานที่ workflow หรือ code ธรรมดาชนะขาด, และการวัดผลด้วย eval ที่ดูปลายทางไม่ใช่เส้นทาง

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิด DDD ที่บทนี้ยืมมาใช้กับการส่งต่องานข้าม agent ได้ที่คลังอ้างอิง DevIQ:

Context Map — แผนที่ความสัมพันธ์ระหว่าง bounded context ทุกอัน; published language คือสัญญาที่วิ่งอยู่บนเส้นความสัมพันธ์เหล่านี้ระหว่าง agent
Anti-Corruption Layer — เมื่อ handoff พาบทสนทนาข้ามเข้าไปในภาษาของอีก context ฝั่งรับยังต้องมี ACL แปลกลับ ไม่ให้ model แปลกๆ ของต้นทางรั่วเข้ามาปน

เช็กความเข้าใจ — บทที่ 7

ข้อ 1 / 3

delegation ต่างจาก handoff อย่างไร?

Integration & handoffs → agent คุย​กัน​ยังไง

delegation กับ handoff เป็น​คนละ topology

สัญญา​ข้าม​ขอบเขต​คือ published language

handoff เสีย​ข้อมูล จึง​ต้อง share trace เต็ม

pattern ที่​พิสูจน์​แล้วดี​ที่สุด​คือ verification subagent

สิ่ง​ที่​จะ​ทำ​ต่อ