Agent ตัวเดียวมักชนะทั้งฝูง: บทเรียนจาก Anthropic สำหรับคนที่ชอบตั้ง Multi-Agent

ผมต้องสารภาพก่อนครับว่าผมเป็นคนชอบตั้งฝูง agent

ให้ตัวหนึ่งวางแผน อีกตัวเขียนโค้ด อีกตัวเขียน test ตัวสุดท้ายรีวิว เปิด Claude ไว้หน้าต่างหนึ่ง Codex อีกหน้าต่าง Cursor agent อีกแท็บ แล้วนั่งดูมันส่งงานต่อกันเป็นทอด ๆ มันให้ความรู้สึกเหมือนคุมทีมเล็ก ๆ ที่ไม่ต้องนอน ซึ่งสำหรับคนที่ดูแลทีม junior สี่ทีมอยู่แล้วอย่างผม ภาพนี้ดึงดูดมาก

ช่วงนี้ในไทม์ไลน์ X มีหัวข้อที่ขึ้น trending ว่า Anthropic บอกว่า agent ตัวเดียวมักชนะทีม agent ทั้งเรื่องต้นทุน ความเร็ว และคุณภาพ ผมอ่านพาดหัวแล้วรู้สึกเหมือนโดนแซว เลยตามไปอ่านต้นฉบับจริง ๆ ไม่ใช่แค่โพสต์สรุป

โพสต์นี้เป็นตอนต่อในซีรีส์ Critical Thinking ครับ ต่อจากการให้ agent ทำงานแทนโดยไม่ให้มันคิดแทน และนิสัยการ verify คราวนี้คำถามไม่ใช่ "เชื่อผลงานของ agent ได้แค่ไหน" แต่เป็น "เราจำเป็นต้องมี agent หลายตัวขนาดนั้นจริงไหม"

จุดยืนของผมสั้น ๆ คือ multi-agent ไม่ใช่ของผิด แต่มันควรเป็นสิ่งที่ต้องพิสูจน์ว่าคุ้ม ไม่ใช่ค่าเริ่มต้น

Anthropic พูดอะไรจริง ๆ

ก่อนจะเชื่อหรือเถียงอะไร ผมอยากแยกให้ชัดก่อนว่าแหล่งข้อมูลหลักมีอะไรบ้าง เพราะโพสต์สรุปหลายเจ้าเอาตัวเลขจากคนละบทความมายำรวมกัน

1. Building agents: When to fold subagents into your main agent loop (22 ตุลาคม 2026, เขียนโดย Diane Sarkis) นี่คือต้นเรื่องของกระแสรอบนี้ ใจความหลักคือ จากงานกับลูกค้าองค์กร ทีม Applied AI ของ Anthropic เห็นว่าการใช้ subagent น้อยลง แล้วหันไปใช้ agent loop เดียวที่ค่อย ๆ โหลด context ผ่าน skills และโหลด tools ผ่าน tool search เท่าที่งานต้องใช้ (เขาเรียกว่า progressive disclosure) ช่วยให้คุณภาพดีขึ้น พร้อมกับลดต้นทุนและ latency

ตัวเลขในบทความนี้มีน้อยกว่าที่พาดหัวทำให้รู้สึกครับ ที่ผมเจอคือ ลูกค้ารายหนึ่งที่ลองเทียบ harness แบบ multi-agent กับ agent loop เดียว พบว่าแบบ loop เดียว runtime เร็วขึ้นราว 2 เท่า และ Anthropic เล่าว่าตัด system prompt ของ Claude Code สำหรับโมเดลรุ่นใหม่ลงไปได้มากกว่า 80% ส่วนหนึ่งมาจากการเปลี่ยนไปโหลด skills และ tools แบบ progressive แต่ ไม่มีตารางเปรียบเทียบคุณภาพหรือตัวเลขต้นทุนเป็นเปอร์เซ็นต์ ใครที่อ้างว่า "ประหยัดได้ X%" จากบทความนี้ ผมหาที่มาไม่เจอครับ

2. When to use multi-agent systems (and when not to) (23 มกราคม 2026) บทความนี้มาก่อน และให้กรอบคิดที่ผมว่ามีประโยชน์ที่สุด ประโยคที่ผมจดไว้คือ multi-agent มักถูกใช้ในสถานการณ์ที่ agent ตัวเดียวทำได้ดีกว่า และ multi-agent มักใช้ token มากกว่าแบบ single agent ราว 3–10 เท่าสำหรับงานที่เทียบเท่ากัน

3. How we built our multi-agent research system (13 มิถุนายน 2025) บทความนี้มักถูกยกมาเป็นหลักฐานฝั่ง "multi-agent ดีกว่า" เพราะระบบ lead agent กับ subagent ของเขาทำคะแนนดีกว่า single agent ถึง 90.2% บน eval ภายในด้าน research แต่ในบทความเดียวกันก็บอกว่า multi-agent ใช้ token ราว 15 เท่าของการแชตทั่วไป (agent ตัวเดียวใช้ราว 4 เท่า) และบอกตรง ๆ ว่างานโค้ดส่วนใหญ่มีส่วนที่ทำขนานกันได้จริงน้อยกว่างาน research

4. Building effective agents (ธันวาคม 2024) ต้นทางของหลักคิดทั้งหมด คือให้หาทางที่ง่ายที่สุดเท่าที่ทำได้ แล้วค่อยเพิ่มความซับซ้อนเมื่อจำเป็น ซึ่งบางครั้งอาจหมายถึงไม่ต้องสร้างระบบ agent เลยด้วยซ้ำ

พออ่านครบสี่ชิ้น ผมว่าเรื่องนี้ไม่ใช่การกลับลำครับ Anthropic พูดเรื่อง "เริ่มจากง่ายก่อน" มาตั้งแต่ปลายปี 2024 สิ่งที่เปลี่ยนคือโมเดลเก่งขึ้นจนโครงสร้างหลายอย่างที่เราสร้างไว้ช่วยมัน กลายเป็นภาระแทน บทความเดือนตุลาคมใช้คำทำนองว่า โครงสร้างส่วนใหญ่กำลังทำงานที่โมเดลไม่ต้องการให้ใครทำแทนแล้ว

ทำไมฝูง agent ถึงแพ้บ่อยกว่าที่คิด

ตอนอ่าน ผมพยายามแปลเหตุผลของ Anthropic ให้เป็นภาษาของคนคุมทีม แล้วพบว่ามันคือปัญหาเดียวกับทีมคนเลยครับ

ทุกการส่งต่อ ข้อมูลหายไปนิดหนึ่ง

บทความเดือนตุลาคมบอกว่า เมื่อแตก agent ตามประเภทของปัญหา มันจะเล่น "เกมกระซิบ" ส่งข้อมูลไปมา และทุกครั้งที่ส่งต่อ ความครบถ้วนของข้อมูลก็ลดลง แม้จะเรียก subagent เป็น tool แต่ละครั้งก็ยังได้ผลสรุปที่ตกหล่นกลับมา

ผมเห็นเรื่องนี้ชัดมากใน setup ของตัวเอง agent ที่วางแผนรู้ว่าลูกค้าเจ้านี้ห้ามแก้ schema ของตารางเก่า แต่พอสรุปแผนส่งให้ agent ที่เขียนโค้ด ข้อจำกัดนั้นกลายเป็นแค่บรรทัดเดียวในรายการยาว ๆ แล้ว agent ที่เขียน test ก็ไม่รู้เรื่องนี้เลย สุดท้ายคนที่จับได้คือผมตอนรีวิว ซึ่งก็คือจุดเดียวกับที่จะจับได้ถ้าใช้ agent ตัวเดียวตั้งแต่แรก

Coordination กิน token มากกว่างานจริง

บทความเดือนมกราคมเล่าการทดลองที่แบ่ง agent เป็น planner, implementer, tester และ reviewer แล้วพบว่า subagent ใช้ token ไปกับการประสานงานมากกว่าการทำงานจริง

ตอนอ่านย่อหน้านี้ผมหัวเราะออกมาเลยครับ เพราะนั่นแทบจะเป็น setup ที่ผมภูมิใจ ผมไม่ได้วัดตัวเลขละเอียดเหมือน Anthropic เลยไม่ขอเดาว่าเปลืองไปเท่าไหร่ แต่พอกลับไปไล่ log ดู ข้อความที่ agent ส่งหากันจำนวนมากคือการเล่าซ้ำว่าก่อนหน้านี้เกิดอะไรขึ้น ไม่ใช่การเขียนโค้ด

ไม่ได้เร็วขึ้นอย่างที่รู้สึก

อันนี้ผมคิดว่าเป็นความเข้าใจผิดที่ใหญ่ที่สุด บทความเดือนมกราคมบอกว่า multi-agent มักใช้เวลารวมนานกว่า single agent เพราะปริมาณการคำนวณที่เพิ่มขึ้น และประโยชน์หลักของการทำขนานคือ ความละเอียดครอบคลุม ไม่ใช่ความเร็ว

ฟังดูขัดกับบทความ research ปี 2025 ที่บอกว่าการให้ subagent ทำงานขนานกันช่วยลดเวลา research ของคำถามซับซ้อนได้ถึง 90% แต่ผมว่าสองอย่างนี้ไม่ได้ขัดกันครับ อย่างหลังคือการเทียบระบบ multi-agent แบบรันทีละตัวกับแบบรันขนาน ในงานที่แตกเป็นทางแยกอิสระได้จริง ไม่ได้บอกว่า multi-agent เร็วกว่า agent ตัวเดียวในงานทั่วไป

ยิ่งหลายตัว ยิ่งดูแลยาก

บทความเดือนตุลาคมยกตัวอย่างบริษัทหนึ่งที่มี subagent ผู้เชี่ยวชาญเป็นโหลอยู่ใน agent ที่คุยกับลูกค้า แล้วพบว่าทำให้ประสบการณ์ที่สม่ำเสมอและตรงแบรนด์ดูแลได้ยาก และเพิ่ม latency จนกระทบผู้ใช้

ในมุม PM ผมแปลว่า ทุก agent ที่เพิ่มคือ prompt อีกชุดที่ต้องดูแล จุดพังอีกจุดที่ต้อง debug และ "ใครเป็นเจ้าของ" อีกคำถามหนึ่ง ซึ่งเหมือนการเพิ่มคนในทีมทุกประการ ต่างกันแค่ agent ไม่บ่นให้เราได้ยิน

แต่ multi-agent ก็ยังมีที่ของมัน

สิ่งที่ทำให้ผมเคารพบทความนี้คือ Anthropic ไม่ได้บอกให้เลิกใช้ subagent ครับ เขาเขียนไว้ชัดว่า subagent ยังมีที่ของมัน และให้ใช้เมื่อ

1. agent loop เดียวเจอ คุณภาพตกที่วัดได้ จาก context ที่บวมเกินไป หรือ
2. มีหลายงานที่ต้องทำ ขนานกัน ด้วย context window ใหม่ ที่ทิ้งได้เมื่องานเสร็จ หรือ
3. agent ตัวเดียว เลือก tool ไม่ถูก หรือมีคำสั่งที่ขัดกันใน system prompt

บทความเดือนมกราคมพูดคล้ายกันแต่ให้ภาพที่ใช้ง่ายกว่า คือให้แบ่งงานตาม context ไม่ใช่ตาม ประเภทของปัญหา ขอบเขตที่แบ่งได้ดีคือ ทาง research ที่แยกกันอิสระ, component ที่มี interface ชัดเจน และการ verify แบบ blackbox ส่วนขอบเขตที่แบ่งแล้วมักพังคือ ขั้นตอนต่อเนื่องของงานชิ้นเดียวกัน, component ที่ผูกกันแน่น และงานที่ต้องใช้ state ร่วมกัน

ส่วนฝั่ง Claude Code โดยตรง บทความเรื่อง subagent ใน Claude Code (เมษายน 2026) บอกว่า subagent คุ้มเมื่อการแยก context, การทำขนาน หรือมุมมองใหม่ช่วยได้จริง และไม่ควรใช้กับงานต่อเนื่องที่ขั้นถัดไปต้องการผลเต็ม ๆ ของขั้นก่อนหน้า การแก้ไฟล์เดียวกัน งานเล็ก ๆ หรืองานที่ agent ต้องคุยกันเอง

พอเอามาวางเทียบกับงานของผม เคสที่ multi-agent ช่วยได้จริงมีไม่กี่แบบครับ

• ไล่อ่าน codebase ใหญ่ที่ไม่คุ้นเคย ให้ subagent แยกกันไปสำรวจคนละโมดูล แล้วส่งกลับมาแค่ข้อสรุป context หลักไม่บวมไปด้วยไฟล์ที่ไม่เกี่ยว
• รีวิวด้วยสายตาที่ไม่มีอคติ ให้ agent อีกตัวที่ไม่เห็นบทสนทนาก่อนหน้ามาตรวจผลงาน เพราะตัวที่เขียนมาเองมักเชื่อในสิ่งที่ตัวเองเพิ่งทำ ซึ่งตรงกับ pattern verification subagent ที่ Anthropic เล่าไว้ และเป็นเรื่องเดียวกับที่ผมเขียนในโพสต์เรื่อง verify
• งานที่แยกกันได้จริง เช่น แปลเอกสารหลายภาษา หรือค้นข้อมูลหลายแหล่งที่ไม่ต้องรู้ผลของกันและกัน

ที่เหลือ ซึ่งคือฟีเจอร์ส่วนใหญ่ที่ทีมผมทำทุกวัน เป็นงานต่อเนื่องที่ผูกกันแน่น และ agent ตัวเดียวที่มี context ครบมักทำได้ดีกว่า

ตารางที่ผมใช้ก่อนจะแตก agent ตัวใหม่

ผมสรุปเป็นตารางไว้ใช้กับตัวเองและแชร์ให้ lead ทั้งสี่ทีมครับ คำถามตั้งต้นคือ "ถ้าใช้ agent ตัวเดียวกับ skills ที่ดี จะมีปัญหาอะไรที่วัดได้ไหม"

สองแถวท้ายสำคัญที่สุดครับ เพราะเป็นจุดที่ผมเคยกระโดดไปแตก agent ทันทีที่รู้สึกว่ามันเริ่มงง ทั้งที่ปัญหาจริงคือ tool เยอะเกินไปหรือ prompt เขียนขัดกันเอง บทความเดือนตุลาคมบอกว่าเมื่อจำนวน tool definition เกินราว 30–50 ตัว การเลือก tool มักแย่ลง ซึ่งแก้ได้ด้วยการจัด tool ใหม่ ไม่ต้องเพิ่ม agent

Checklist ก่อนเพิ่ม agent ตัวใหม่

ผมใช้รายการนี้ก่อนจะเพิ่ม agent เข้าไปใน workflow ไม่ว่าจะเป็น Claude, Codex หรือ Cursor ครับ

ก่อนแตก

• เขียนได้ไหมว่า agent ตัวเดียวพังตรงไหน เป็นตัวอย่างงานจริง ไม่ใช่ความรู้สึก
• ลองแก้ด้วยการปรับ prompt, จัดกลุ่ม tool หรือย้ายความรู้ไปเป็น skill แล้วหรือยัง
• งานที่จะแยกออกไป ต้องการแค่ input ชัด ๆ แล้วส่งผลกลับมาได้ โดยไม่ต้องรู้ประวัติทั้งหมดใช่ไหม
• งานที่แยกไม่ต้องแก้ไฟล์หรือ state เดียวกับ agent อื่นใช่ไหม

ถ้าตัดสินใจแตก

• กำหนด format ของผลที่ส่งกลับให้ชัด จะได้รู้ว่าอะไรหายไประหว่างทาง
• มีชุดทดสอบเล็ก ๆ ไว้เทียบแบบมีกับไม่มี subagent บทความเดือนตุลาคมบอกว่าเริ่มจากตัวอย่างดี ๆ แค่ 10 ชิ้นก็พอ
• รันแต่ละเคสมากกว่าหนึ่งรอบ เพราะบางอย่างพังแค่บางรอบ
• ดูว่าเคสไหนเปลี่ยนจากผ่านเป็นไม่ผ่าน ไม่ใช่ดูแค่คะแนนรวม

ทบทวนเป็นระยะ

• ทุกครั้งที่เปลี่ยนโมเดลรุ่นใหม่ ลองถอด subagent ออกทีละตัวแล้วดูว่ายังจำเป็นไหม
• agent ไหนที่ถูกเรียกคู่กันเสมอ หรือใช้ข้อมูลชุดเดียวกัน เป็นตัวเลือกแรกที่ควรรวม

ข้อทบทวนข้อแรกผมได้มาจากวิธีที่ Anthropic แนะนำให้ย้ายระบบ คือรวม subagent ทีละตัว เริ่มจากตัวที่ถูกใช้บ่อยที่สุด เปลี่ยน prompt ของมันเป็น skill และเปลี่ยน API call เป็น MCP tool แล้วเทียบผล eval ก่อนตัดสินใจว่าจะเก็บตัวไหนไว้ เขายกตัวอย่างว่าตอนลองรวม subagent ใน support agent ตัวอย่าง latency ลดลงจริง แต่ process ที่เคยผ่านกลับพัง เพราะ agent หลักตอบเองโดยไม่ถามข้อมูลวันส่งของจาก specialist อีกตัว ผมชอบที่เขาเล่าเคสที่พังด้วยครับ มันย้ำว่าการรวมก็ต้องวัด ไม่ใช่รวมเพราะกระแส

สิ่งที่ผมเปลี่ยนในทีม

ผมไม่ได้รื้อทุกอย่างในวันเดียวครับ แต่มีสามเรื่องที่เปลี่ยนแล้ว

ค่าเริ่มต้นคือ agent ตัวเดียว งานฟีเจอร์ปกติของทีม junior เริ่มจาก agent ตัวเดียวที่มี context ของ ticket, AC และ convention ของโปรเจกต์ครบ ถ้าใครอยากแตก agent ต้องตอบ checklist ข้างบนได้ ซึ่งต่อเนื่องจากที่ผมเขียนไว้ว่าAC ที่ดีคือ context ที่ดีที่สุดสำหรับ agent

ย้ายความรู้ไปเป็น skill แทนการสร้าง agent หลายตัวใน setup เดิมของผม จริง ๆ แล้วคือ "agent ที่รู้ convention ของทีม" ซึ่งเป็นความรู้ ไม่ใช่ผู้ทำงานอีกคน การเก็บเป็น skill ที่ agent หลักโหลดเมื่อต้องใช้ ตรงกับสิ่งที่ Anthropic อธิบายว่า skill เหมาะเมื่อ agent ต้องรู้ว่าทีมทำงานแบบไหน

เก็บ subagent ไว้ที่เดียวที่มันชนะชัด คือการรีวิว agent ที่ไม่เห็นบทสนทนาเดิมยังจับสิ่งที่ตัวเขียนมองข้ามได้บ่อย จุดนี้ผมยังไม่มีตัวเลขเปรียบเทียบที่วัดอย่างเป็นระบบนะครับ เป็นการสังเกตจากการใช้งาน และกำลังทำชุดทดสอบเล็ก ๆ ไว้ยืนยันอยู่

ที่ผมยอมรับยากที่สุดคือ setup ฝูง agent ที่ผมภูมิใจ ส่วนหนึ่งตอบโจทย์ความรู้สึกของผมมากกว่าตอบโจทย์งาน มันดูเป็นระบบ ดูเหมือนบริหารทีม แต่พอถามว่ามันทำให้ผลงานดีขึ้นแค่ไหน ผมไม่มีตัวเลขไหนตอบได้เลย

ท้ายที่สุด

ผมว่าบทเรียนนี้ใช้ได้กับทีมคนด้วยครับ ทุกคนที่คุมทีมรู้ดีว่าการเพิ่มคนไม่ได้แปลว่างานเร็วขึ้นเสมอ บางครั้งมันแค่เพิ่มการประชุม เพิ่มการส่งต่อ และเพิ่มช่องให้ข้อมูลตกหล่น agent ก็ไม่ต่างกัน

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

ส่วนฝูง agent ของผม ไม่ได้ลบทิ้งนะครับ แค่ลดเหลือตัวที่พิสูจน์ได้ว่าคุ้ม ซึ่งตอนนี้เหลืออยู่ตัวเดียว คือตัวที่คอยบอกว่าตัวหลักทำพลาดตรงไหน