Multi-agent ใน Claude Code: เลือกวิธีให้ถูกงาน

แก่นของเรื่อง

แนวคิดหลัก: วิธี multi-agent ทั้งสามต่างกันที่ "ใครถือแผน" ไม่ใช่ที่จำนวน agent เลือกวิธีตามคำตอบข้อนี้ แล้วเพิ่ม agent เฉพาะเมื่อได้ของที่ session เดียวให้ไม่ได้

ทำไมถึงได้ผล (กลไก):

• ถ้า LLM ตัดสินว่าจะวนต่อหรือหยุดทีละ turn โครงของงานจะเปลี่ยนทุกครั้งที่รัน ย้าย loop และเงื่อนไขหยุดเข้าโค้ด (workflow) ได้ลำดับงานที่คาดเดาและทำซ้ำได้
• งานย่อยที่เริ่มจาก context สะอาด ไม่ถูกปนด้วยของเก่า ผลจึงนิ่งกว่า และ context หลักไม่บวม (subagent)
• เมื่อโจทย์ต้องการมุมมองที่ขัดกัน การให้ agent คุยและท้าทายกันเองให้ผลที่ session เดียวสร้างไม่ได้ (ทีม)

20% ที่สำคัญที่สุด:

1. ถามก่อนว่า session เดียวพอไหม ค่าเริ่มต้นคือใช่
2. ตัวตรวจต้องเป็นกลไกที่รันจริง ไม่ใช่คำบอกเล่าของ agent
3. ใส่ตัวกัน "ลดมาตรฐานเพื่อให้ผ่าน" ก่อนปล่อยงานยาว

ส่วนที่รอได้: pattern เฉพาะทางอย่าง migrate ใน worktree หรือร่างแผนหลายมุม

ช่วยให้ดีขึ้นอย่างไร

ตัวเลขในตารางเป็นตัวเลขที่รายงานไว้ ยังไม่ได้ตรวจซ้ำในหน้านี้ จึงติดป้าย ยังไม่ทดสอบ จนกว่าจะรันเอง

แถวสุดท้ายของกลุ่มบั๊ก 12 ข้อบอกว่า "ความสามารถในการหาบั๊ก" อิ่มตัวแล้วในชุดทดสอบนั้น ความต่างอยู่ที่ของแถม ไม่ใช่จำนวนบั๊กที่เจอ

ลองใช้

ตัวอย่างประกอบ: ต้นทุนของการแตก agent ที่ไม่จำเป็น

ตัวเลขชุดนี้เป็นของเราเอง ใช้ดูทิศทาง ไม่ใช่ค่าวัด

• diff ของ PR 400 บรรทัด ประมาณ 15 token ต่อบรรทัด = 6,000 token
• session เดียวอ่านครั้งเดียว = 6,000 token
• ส่ง subagent 3 ตัวไปอ่าน diff เดียวกัน = 18,000 token ส่วนต่าง 12,000 token (3 เท่า) ก่อนนับผลสรุปที่ส่งกลับ
• คุ้มก็ต่อเมื่อ context หลักจะเกินขีดจำกัด หรือต้องการ noise ต่ำ หรือเจอบั๊กเพิ่ม มิฉะนั้นจ่ายเพิ่มโดยไม่ได้อะไร

เมื่อไหร่ใช้ เมื่อไหร่ไม่ใช้

ก้าวแรกที่เล็กที่สุด

เลือกงานที่เสร็จไปแล้ว 3 งาน เขียนลงตารางว่าแต่ละงาน "ใครควรถือแผน" ตามตารางข้างบน แล้วเทียบกับที่ทำจริง ไม่ต้องรัน agent เพิ่ม

ทดสอบว่าช่วยจริง

ทดสอบความเข้าใจ

สามวิธี ใครถือแผน

Subagent รันเบื้องหลัง แตกตัว (fork) และสั่งงานต่อได้ Workflow มี pattern ด้านคุณภาพให้ใช้: ตรวจหักล้าง, วนแก้จนเทสต์ผ่าน, migrate ใน worktree, ค้นจนรายการไม่โต, ร่างแผนหลายมุม

ผังตัดสินใจ

flowchart TD
    A[งานใหม่] --> B{session เดียวพอ?}
    B -->|ใช่| S[ใช้ session เดียว]
    B -->|ไม่| C{ขั้นตอนรู้ล่วงหน้า และต้องทำซ้ำ?}
    C -->|ใช่| W[workflow]
    C -->|ไม่| D{ต้องถกหรือต่อรองข้ามบทบาท?}
    D -->|ใช่| T[ทีม]
    D -->|ไม่| U[subagent]

หลักการที่ใช้ได้ทุกวิธี

เคสที่พังและบทเรียน

ใน incident ที่ทั้ง workflow และทีมโต้วาทีหาสาเหตุเจอ การซักค้านทำให้คำอธิบายแม่นขึ้น ไม่ได้ทำให้เจอสาเหตุเพิ่ม

Risks

Warning ตัวเลขทั้งหมดในหน้านี้ (90/90, 104/104, 86/86, 0.62 USD, 12 ข้อ) เป็นผลรันครั้งเดียวต่อกรณี บน Claude Code รุ่น v2.1.296 และยังไม่ได้ตรวจซ้ำ อย่าใช้เป็นฐานตัดสินต้นทุนหรือความน่าเชื่อถือ

• Agent Teams เปลี่ยนเร็วเพียงพอที่เนื้อหาอ้างอิงต้องเขียนใหม่ทั้งชุด (ตีความ: ยังไม่นิ่ง) อย่าสร้างงานจริงบน behavior ที่ยังไม่ผ่านการใช้งานซ้ำ
• ผลที่ทุกวิธีเจอบั๊กครบ 12 ข้อบอกแค่ว่าชุดทดสอบนั้นอิ่มตัว ไม่ได้บอกว่าวิธีไหนดีกว่าบน repo จริง
• การเพิ่ม agent เพิ่มค่าใช้จ่ายแน่นอน แต่ผลดีไม่แน่นอน ต้องมีเกณฑ์ผ่านที่ตั้งไว้ก่อนรัน

Decision / next steps

Recommendation ตั้งค่าเริ่มต้นเป็น session เดียว แล้วย้ายไปวิธีอื่นเมื่อมีเหตุผลชัดหนึ่งข้อ: context ล้น, ต้องรันซ้ำโดยไม่มีคนเฝ้า, หรือต้องการมุมมองที่ขัดกัน ก่อนปล่อยงานยาว ให้ใส่สองอย่างเสมอ คือตัวตรวจที่รันจริง และ diff guard

ตัวย่อที่ใช้ในหน้านี้

ตัวย่อ PR, API, LLM, USD และชื่อ curl, tsconfig, hook เป็นความรู้ทั่วไป ไม่ได้นิยามไว้ในหัวข้อนี้ สัญลักษณ์ n ใน "n เท่ากับ 1" หมายถึงจำนวนตัวอย่างที่รัน

Summary

Recommendation เลือกวิธี multi-agent ตามคำตอบข้อเดียว: ใครถือแผน

• Claude ตัดสินทีละ turn = subagent, สคริปต์ถือแผน = workflow, agent ถกกันเอง = ทีม, งานทั่วไป = session เดียว
• ตัวตรวจต้องรันจริงและต้องมี diff guard กันการลดมาตรฐานเพื่อให้ผ่าน
• แบ่งงานด้วยเจ้าของไฟล์ ตรวจโหมดจริงหลังเลือกตัวเลือกที่เปลี่ยนความหมาย ตั้ง permission ล่วงหน้า
• ตัวเลขที่รายงานเป็นผลรันครั้งเดียว ยังไม่ทดสอบซ้ำ
• วัดผลของตัวเองด้วยบั๊กที่ฝังไว้ และเกณฑ์ผ่านที่ตั้งก่อนรัน