Anthropic แนะ “ยุบ subagent กลับเข้า agent loop เดียว” พร้อมปล่อย single-agent-loop-kit เป็น skill ของ Claude Code ที่ช่วย audit ระบบ multi-agent แล้วพับทีละตัวโดยวัดด้วย eval ก่อน-หลัง

ช่วงปีที่ผ่านมา สถาปัตยกรรม “orchestrator + subagent เฉพาะทาง” แทบเป็นแบบแผนมาตรฐานของ agent ระดับองค์กร แต่เมื่อ 22 ต.ค. 2026 Anthropic เผยแพร่บทความ “Building agents: When to fold subagents into your main agent loop” (เขียนโดย Diane Sarkis บน claude.com) ที่เสนอสิ่งที่สวนทางกัน: จากการเปรียบเทียบใน deployment ขององค์กรหลายแห่ง ทีม Applied AI พบว่า agent ตัวเดียวที่ใช้ skills มักชนะทั้งแบบ “prompt เดียวรวมทุกอย่าง” และแบบ subagent ในด้านคุณภาพ และบ่อยครั้งยังถูกกว่าและหน่วงน้อยกว่าต่องานด้วย ลูกค้ารายหนึ่งที่วัดเทียบ harness แบบ multi-agent กับ agent loop เดียว พบว่าแบบหลัง เร็วขึ้นราว 2 เท่า

บทความนี้ไม่ได้มีแค่หลักการ เพราะ Anthropic ปล่อย repo anthropics/single-agent-loop-kit (Apache-2.0, commit แรก 21 ต.ค.) ออกมาพร้อมกันด้วย ตัว kit เป็น skill ของ Claude Code ที่อ่านโค้ด orchestration ของเรา ให้คำตัดสินกับ subagent แต่ละตัว แล้วพับมันเข้า loop หลักทีละตัว โดยวัด eval ก่อนและหลังทุกครั้ง

ปัญหาที่ Anthropic เห็นซ้ำ ๆ: agent กลายเป็นผังองค์กร

บทความเรียกอาการนี้ว่า Conway’s law ของ agent คือแต่ละทีมสร้าง subagent ของตัวเอง แล้วทีม platform ก็เอา orchestrator มาครอบไว้ข้างบน ผลที่ตามมามีหลายข้อ:

• Context หายระหว่างส่งต่อ: ทุกครั้งที่ subagent ส่งงานกลับ ข้อมูลจะถูกย่อเป็นสรุปที่ตกหล่น บทความเปรียบว่าเป็น “telephone game”
• Subagent sprawl: มี subagent ซ้ำซ้อนกันเป็นร้อยตัวโดยไม่มีมาตรฐานและไม่มีเจ้าของชัดเจน
• “Frankenprompt”: ทุกทีมเพิ่มประโยคของตัวเองลงใน system prompt จนกฎขัดกันเองและน้ำเสียงไม่สม่ำเสมอ
• Eval แยกส่วน: แต่ละทีม optimize eval ของงานย่อยตัวเอง แต่ไม่มีใครดูภาพรวมทั้งระบบ

บทความยังระบุว่าในงานออกแบบที่ลูกค้าเสนอมาหลายชิ้น ทั้ง intent classifier, pipeline หลายขั้นแบบตายตัว และ orchestrator ที่ครอบอยู่บนสุด “ทำงานที่โมเดลไม่จำเป็นต้องให้ใครทำแทนอีกแล้ว” ทางที่บทความเสนอคือ system prompt ที่ชัดเจนหนึ่งชุด, data tool บาง ๆ 4–5 ตัว และ guardrail ฝั่ง output ที่เข้มงวด ซึ่งครอบคลุม use case ส่วนใหญ่ได้แล้ว เหตุผลหลักคือโมเดลรุ่นใหม่ตั้งแต่ Opus 4.5 เป็นต้นมาจัดการงานใน loop เดียวได้มากกว่าที่ทีมส่วนใหญ่คาดไว้ บทความยกตัวอย่างว่า Anthropic เองลด system prompt ของ Claude Code สำหรับโมเดลรุ่นใหม่ลง กว่า 80% และส่วนหนึ่งของที่ลดได้มาจากการโหลด skill และ tool เฉพาะตอนที่ต้องใช้

ไม่ได้บอกว่า “ห้ามใช้ subagent”

บทความระบุชัดว่า subagent ยังมีที่ใช้ใน 3 กรณี:

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

ถ้าจำเป็นต้องแยก บทความแนะนำให้แบ่ง “ตาม context” ไม่ใช่ “ตามประเภทปัญหา” คือมอบงานที่แทบไม่ต้องพึ่งข้อมูลจากส่วนอื่นของระบบ แล้วให้ subagent ส่งผลกลับมาแบบกระชับ เช่น งานค้นคว้าที่แยกเป็นสายอิสระ หรือการตรวจแบบ black-box ส่วน subagent ที่ยังเก็บไว้ ควรให้ agent หลัก เรียกมันเป็น tool และกำหนด schema ของคำตอบร่วมกัน แทนการ handoff ให้ subagent คุยกับผู้ใช้เอง

ตัวเลขเชิงปฏิบัติอีกข้อที่ควรจดไว้คือ เมื่อนิยาม tool เกิน 30–50 ตัว การเลือก tool ของโมเดลมักแย่ลง บทความจึงแนะนำให้จัดกลุ่ม tool ตามเจตนาของผู้ใช้ (ไม่ใช่ API ละหนึ่ง tool) และใช้ tool search แบบ deferred loading ข้อมูลอ้างอิงอย่างนโยบายหรือ spec สินค้าควรอยู่หลัง search tool หรือเป็นไฟล์อ้างอิงใน skill และไม่ควรให้โค้ดดึงมาแปะลงใน prompt เอง

kit ทำงานอย่างไร และบทเรียนจากตัวอย่าง

ตาม README ขั้นตอนมี 3 ระยะ คือ Measure → Combine → Fold:

git clone https://github.com/anthropics/single-agent-loop-kit
cp -r single-agent-loop-kit/skill <your repo>/.claude/skills/single-agent-loop
# แล้วใน Claude Code: "Run the single-agent-loop skill."

skill จะ audit ก่อน แล้วหยุดแสดงคำตัดสินของ subagent แต่ละตัวว่าเป็น fold / merge / call as tool / keep จากนั้นจะหยุดถามเราทุกครั้งก่อนรัน eval ที่เสียเงิน (พร้อมประมาณจำนวน token) หลังได้ baseline และหลังแต่ละการเปลี่ยนแปลง ถ้ายังไม่มี eval มันจะร่างงานทดสอบให้ราว 10 ข้อแล้วให้เรากำหนดว่าแต่ละข้อแบบไหนนับว่า “ทำเสร็จ” ในชุดมีสคริปต์อย่าง coupling_map.py (ใช้ trace หาว่า subagent ไหนถูกเรียกคู่กันบ่อย), chain_coverage.py (ตรวจว่า eval มีงานครอบทุก chain ที่เกิดใน production) และ reference_loop/loop.py ซึ่งเป็น loop ตัวอย่างที่มีการเรียก tool ขนานกันเป็นชุด, งบ turn และค่าใช้จ่าย และ write gate ส่วนงานย่อยจะส่งต่อให้คำสั่ง /claude-api build-eval, hillclimb, prompt-audit และ cost-optimize ที่มีอยู่แล้ว

ตัวอย่าง examples/support-desk (router + 6 subagent) ทดลองได้ฟรีโดยไม่ต้องใช้ API key ด้วย KIT_MODEL=fake บทความเองก็ยอมรับตรง ๆ ว่าการพับ subagent ไม่ได้ปลอดภัยเสมอ ในการทดลองกับ support agent ตัวอย่าง การพับ subagent ตัวหนึ่งทำให้ latency ลดลง แต่ทำให้งานที่เคยผ่านพัง เพราะ agent หลักถือ tool ค้นคำสั่งซื้ออยู่ในมือแล้วตอบเอง โดยไม่ถาม specialist ด้านขนส่งเรื่องวันส่งของ และความผิดพลาดนี้โผล่ใน 1 จาก 2 รอบ เท่านั้น บทความจึงแนะนำให้รันแต่ละงานมากกว่าหนึ่งรอบ และให้ดูว่างานไหนพลิกผล ไม่ใช่ดูแค่คะแนนรวม

ข้อที่ควรรู้: README ระบุว่า repo นี้เป็น “Reference implementation. Not maintained and not accepting contributions.” และใน example-run ทีมงานได้ ลบผลวัดและข้อสรุปออกจาก write-up โดยเหลือไว้แค่ log ดิบที่ให้รัน compare.py เอง ดังนั้นตัวเลข “เร็วขึ้น 2 เท่า” ในบทความจึงมาจากลูกค้ารายเดียวที่ไม่ได้ระบุชื่อ ไม่ใช่ benchmark ที่ตรวจซ้ำได้

มุมมอง AI Curator

ผมคิดว่านี่เป็นบทความแนวปฏิบัติที่สำคัญที่สุดของ Anthropic ในรอบหลายเดือน เพราะมันยอมรับกลาย ๆ ว่ารูปแบบ “multi-agent ทุกอย่าง” ที่อุตสาหกรรม (รวมถึง Anthropic เอง) ช่วยกันโปรโมตมาเป็นปี หลายกรณีเป็นแค่การชดเชยข้อจำกัดของโมเดลรุ่นเก่า แต่ก็ควรอ่านด้วยสายตาที่มีวิจารณญาณ ข้อเสนอนี้เข้ากับธุรกิจของ Anthropic พอดี เพราะ loop เดียวที่ context ยาวบนโมเดลแพงก็หมายถึง token ของ Opus และ Fable ที่ใช้มากขึ้น และสิ่งที่ถูกส่งเสริมควบคู่กันคือ skills, tool search และคำสั่ง /claude-api ซึ่งเป็นของ Claude ทั้งหมด ตัวเลข 2 เท่าก็มาจากลูกค้ารายเดียว ข้อสรุปที่ปลอดภัยกว่าจึงเป็นประโยคปิดท้ายของบทความเอง คือ “measure, change one thing at a time, and keep what holds up”

สำหรับทีมไทยที่กำลังสร้าง agent ให้ธนาคาร ประกัน หรือ e-commerce ซึ่งมักแบ่งงานตามแผนกและเจอ “Frankenprompt” แบบที่บทความบรรยายอยู่แล้ว ผมว่าคุณค่าจริงของ kit นี้อยู่ที่ วินัยเรื่อง eval มากกว่าตัวสถาปัตยกรรม คือมี eval end-to-end ราว 10 ข้อที่ทีมกลางเป็นเจ้าของ, ตรวจว่ามีงานครอบทุก chain ที่เกิดใน production และรันแต่ละงานหลายรอบ วิธีคิดนี้นำไปใช้ได้แม้ระบบจะรันบน Gemini, Typhoon หรือโมเดล open-weight (ตัว kit ต้องรันใน Claude Code แต่ README ระบุว่า skill อ่านโค้ด orchestration ได้โดยไม่ผูกกับ framework ใด) แต่สำหรับโมเดลเล็กที่รันเอง ข้อสมมติว่า “โมเดลจัดการ loop ยาวได้เอง” อาจยังไม่เป็นจริง และ subagent อาจยังจำเป็นอยู่ ซึ่งเป็นสิ่งที่ eval ควรเป็นตัวตัดสิน ไม่ใช่บทความ

แหล่งข่าว

• Claude — Building agents: When to fold subagents into your main agent loop (22 ต.ค. 2026)
• GitHub — anthropics/single-agent-loop-kit
• Claude — The anatomy of effective commerce agents
• Claude Platform Docs — Tool search tool