เมื่อระบบมีหลายเอเจนต์ ทำไมพังทีเดียวทั้งเส้น?
ทีมที่เริ่มใช้ Agent-to-Agent มักได้ความเร็วเพิ่มขึ้น แต่ถ้า orchestration ไม่ดี พออัปเดตครั้งเดียวจะพังเป็นลูกโซ่ทันที
บทความนี้สรุปหลักการออกแบบที่ทำให้ multi-agent workflow อยู่ใน production ได้จริง
Pain Point หลักของ Agent-to-Agent ตอนอัปเดต
1) Contract ไม่ชัด ระหว่าง agent - อาการ: agent B อ่าน output จาก agent A ไม่ได้ - สาเหตุ: ไม่มี schema กลาง และไม่มี fallback format
2) Retry ซ้ำจนเกิดงานซ้ำ - อาการ: สร้างโพสต์ซ้ำ, ยิง API ซ้ำ, state เพี้ยน - สาเหตุ: ไม่มี idempotent key และไม่มี dedupe step
3) Agent ตัวเดียวพังแล้วลากทั้ง flow ลง - อาการ: งานหยุดทั้ง pipeline - สาเหตุ: ไม่มี isolation และไม่มี dead-letter queue
Architecture ที่แนะนำ
ชั้นที่ 1: Planner - แตกงาน, จัด dependency, กำหนด output schema
ชั้นที่ 2: Executors - ทำงานเฉพาะทาง เช่น generate content, generate image, patch API
ชั้นที่ 3: Verifier - ตรวจ contract, ตรวจ completeness, ป้องกันข้อมูลผิดเข้า production
ชั้นที่ 4: Publisher - เขียนจริง, log จริง, trigger audit จริง
กฎเหล็ก 6 ข้อเพื่อกันระบบพัง
1. ทุก handoff ต้องมี schema ชัด 2. ทุกงาน write ต้อง idempotent 3. มี retry แบบ backoff ไม่ใช่ยิงถี่ 4. มี timeout ต่อ agent 5. มี circuit breaker เมื่อ error เกิน threshold 6. มี dead-letter queue สำหรับงาน fail ถาวร
แผนแก้ระบบที่พังอยู่ตอนนี้
1. ทำ flow map ของ agent ทั้งเส้น 2. ใส่ contract test ระหว่าง node 3. แยกจุด write ออกเป็น final stage เดียว 4. เพิ่ม post-run audit หลัง publish ทุกครั้ง 5. เก็บ incident template เดียวกันทั้งทีม
สรุป
Agent-to-Agent ไม่ได้ทำให้ระบบนิ่งเองอัตโนมัติ สิ่งที่ทำให้เสถียรคือ contract ที่ชัด, การแยกหน้าที่ที่ถูกต้อง, และระบบ recovery ที่ดี ถ้าจัด 3 อย่างนี้ได้ การอัปเดตจะไม่ใช่ช่วงลุ้นอีกต่อไป
