Arm A | Cursor Agent Swarm บิลต่างเกือบ 8 เท่า: Planner-Worker Model Routing

ข่าวนี้คืออะไรในภาษาคนทำงาน

Cursor เผยบทความ Agent swarms and the new model economics เมื่อวันที่ 20 กรกฎาคม 2026 ครับ

ทีมทดลองให้ Agent Swarm สร้าง SQLite ใหม่ด้วย Rust จากคู่มือ 835 หน้า โดยไม่ได้ให้ source code, ชุดทดสอบที่ใช้ให้คะแนน, SQLite binary หรือ internet access ระหว่างรัน

โครงสร้างของ swarm มีสองบทบาทหลัก:

• Planner ใช้โมเดลที่เก่งกว่าเพื่อแตกเป้าหมาย ตัดสินใจเรื่อง design และมอบหมายงาน
• Worker ใช้โมเดลที่เร็วและถูกกว่าเพื่อทำงานย่อยที่มีขอบเขตชัด

Cursor ทดลอง model mix สี่แบบใน new swarm ตั้งแต่ GPT-5.5 ทำทั้ง Planner และ Worker ไปจนถึง Opus 4.8 เป็น Planner แล้วให้ Composer 2.5 เป็น Worker

ที่สี่ชั่วโมง คะแนนของ new swarm อยู่ระหว่าง 73% ถึง 85% และทุก configuration ไปถึง 100% ของชุดทดสอบในภายหลัง แต่ต้นทุนต่างกันมากครับ

• Opus 4.8 Planner + Composer 2.5 Workers: $1,339
• GPT-5.5 ทำทั้งสองบทบาท: $10,565

เอา $10,565 หาร $1,339 จะได้ประมาณ 7.89 เท่า

จุดนี้ไม่ควรสรุปแบบง่าย ๆ ว่า Composer ชนะ GPT-5.5 หรือโมเดลถูกดีกว่าโมเดลแพงนะครับ สิ่งที่การทดลองทำให้เห็นชัดกว่าคือ ต้นทุนของ Agent System ขึ้นกับว่าเราเอาโมเดลไหนไปทำบทบาทอะไร

ทำไม Worker ถึงทำให้บิลโต

Cursor ระบุว่า Worker ใช้ token อย่างน้อย 69% ของทุก run และมากกว่า 90% ในหลาย run

เรื่องนี้สมเหตุสมผล เพราะ Planner อาจตัดสินใจไม่กี่ครั้ง แต่ Worker ต้องลงมือกับงานย่อยจำนวนมาก เช่น อ่าน context เฉพาะส่วน เขียนโค้ด รันเครื่องมือ แก้ข้อผิดพลาด และส่งผลลัพธ์กลับมา

ใน run ที่ใช้ GPT-5.5 ทั้งสาย ค่า Worker อย่างเดียวอยู่ที่ $9,373

ส่วน run ที่ใช้ Opus 4.8 วางแผน แล้วให้ Composer 2.5 ทำงาน ค่า Worker fleet อยู่ที่ $411 และต้นทุนรวมทั้ง run อยู่ที่ $1,339

นี่คือความต่างระหว่าง จำนวนครั้งที่ต้องใช้ judgment สูง กับ ปริมาณงาน execution ที่ต้องทำซ้ำ

ถ้าเราใช้ frontier model กับทุก step เรากำลังซื้อ judgment ราคาแพงแม้ในงานที่ instruction ชัดแล้ว

แต่ถ้าเราใช้โมเดลเล็กกับทุก step เราอาจประหยัดค่าเรียก model แล้วเสียเงินกับ retry, review และ rework แทน

Model Routing ที่ดีจึงไม่ใช่การเลือกตัวถูกที่สุดครับ แต่คือการใช้ intelligence ให้ตรงกับความกำกวมและความเสี่ยงของงาน

แยก Planner, Worker และ Reviewer อย่างไร

1. Planner ซื้อความสามารถในการลดความกำกวม

Planner เหมาะกับงานที่ยังต้องตอบคำถาม เช่น:

• เป้าหมายจริงคืออะไร
• ต้องแตกงานออกเป็นกี่ส่วน
• architecture หรือวิธีทำแบบไหนเหมาะกว่า
• trade-off ด้านเวลา ต้นทุน และความเสี่ยงคืออะไร
• งานถือว่าผ่านเมื่อไร
• เมื่อไรควรเปลี่ยนแผนหรือหยุด

ตรงนี้ frontier model อาจคุ้ม เพราะ decision หนึ่งครั้งส่งผลต่อ Worker จำนวนมาก

ถ้า Planner แจกงานไม่ชัด Worker จะไม่ได้แค่พลาดหนึ่งครั้ง แต่พลาดซ้ำทั้งต้นไม้ของงาน

2. Worker ซื้อ throughput

Worker เหมาะกับงานที่มี input, output และ stop condition ชัด เช่น:

• แก้ไฟล์หนึ่งชุดตาม spec ที่กำหนด
• ดึง field จากเอกสารตาม schema
• สร้าง draft หลายชิ้นจาก source pack เดียว
• ตรวจ URL, format หรือ metadata ตาม checklist
• รัน test แล้วคืนผลพร้อม diff

งานเหล่านี้ไม่ได้แปลว่าง่ายเสมอไปครับ แต่ความกำกวมควรถูกลดลงก่อน Worker เริ่ม

ถ้า Worker ต้องตัดสินใจ architecture ใหม่เองทุกตัว เราไม่ได้แยกบทบาทจริง เพียงเปลี่ยนชื่อ agent เท่านั้น

3. Reviewer ซื้อความมั่นใจก่อนรับงาน

Cursor ยังอธิบายเรื่อง review lenses ว่า reviewer ที่เห็นข้อมูลคนละแบบสามารถจับข้อผิดพลาดคนละชนิดได้

ใน workflow ธุรกิจ Reviewer อาจเป็น:

• deterministic test
• rule หรือ schema validator
• model อีกตัวที่ตรวจจาก clean context
• ผู้เชี่ยวชาญหรือเจ้าของงาน

ไม่จำเป็นต้องใช้ frontier model ตรวจทุกอย่าง ถ้างานตรวจได้ด้วย code หรือ rule ให้ใช้เครื่องมือ deterministic ก่อนครับ

ใช้ model judgment เมื่อปัญหาเป็นเรื่องความหมาย คุณภาพ ความเสี่ยง หรือข้อยกเว้นที่ rule ตัดสินไม่ได้

Model Routing Policy แบบง่าย

ก่อนเลือก model ให้ถามเรื่องงาน ไม่ใช่ถามว่า model ไหนเก่งสุด

ใช้โมเดลแรงขึ้นเมื่อ

• เป้าหมายยังคลุมเครือ
• ต้องวาง architecture หรือ trade-off สำคัญ
• ความผิดพลาดส่งผลสูง
• context หลายส่วนขัดกัน
• Worker พลาดซ้ำใน pattern เดิม
• ไม่มี verifier ที่ตรวจผลได้ชัด

ใช้โมเดลเร็วหรือประหยัดขึ้นเมื่อ

• task ถูกแตกจนแคบ
• instruction และตัวอย่างชัด
• output มี schema หรือ test ตรวจได้
• retry มีขอบเขต
• ความผิดพลาดย้อนกลับได้
• มี escalation path ไปหา Planner หรือคน

ใช้ deterministic tool เมื่อ

• กฎเขียนเป็น code ได้
• format, type, schema หรือ test ตัดสิน pass/fail ได้
• การคำนวณต้องได้ผลเดิมทุกครั้ง
• ไม่ต้องใช้ judgment ทางภาษา

Routing ที่ดีอาจเป็น frontier Planner, efficient Worker และ deterministic Reviewer ก็ได้ ไม่จำเป็นต้องเป็น LLM สามตัวครับ

Operator Kit: Planner-Worker Model Routing Canvas

ใช้ Canvas นี้กับ workflow เดียวเป็นเวลา 7 วันก่อนขยายครับ

A. นิยามงานและผลลัพธ์ที่รับได้

Workflow:
Owner:
Trigger:
Input:
Accepted outcome:
Definition of Done:
ความเสียหายถ้าผิด: ต่ำ / กลาง / สูง
ย้อนกลับได้หรือไม่:

B. แยกบทบาท

Planner ต้องตัดสินใจอะไร:
1.
2.
3.

Worker ต้องส่งมอบอะไร:
1.
2.
3.

Reviewer ตรวจด้วยอะไร:
- deterministic test / rule:
- model review:
- human approval:

C. Route model ตามความยาก

Planner model:
เหตุผลที่ต้องใช้ระดับนี้:
Max budget / turns:

Worker model:
เหตุผลที่เหมาะกับงาน volume:
Max budget / retries ต่อ task:

Reviewer:
เครื่องมือหรือ model:
จุดที่ต้องส่งให้คน:

D. ตั้ง escalation trigger

ส่งกลับ Planner เมื่อ:
- Worker fail ซ้ำ ___ ครั้ง
- เจอ requirement ขัดกัน
- ต้องเปลี่ยน architecture
- เกิน budget หรือ timeout
- confidence ต่ำกว่าเกณฑ์

หยุดและถามคนเมื่อ:
- แตะข้อมูลสำคัญหรือการเงิน
- ต้อง publish, deploy หรือแก้ production
- ไม่มีหลักฐานตรวจผล
- ผลลัพธ์ย้อนกลับไม่ได้

E. เก็บหลักฐาน 7 วัน

จำนวนงานทั้งหมด:
Accepted outcomes:
Pass rate:
Planner cost:
Worker cost:
Reviewer / tool cost:
Retry count:
Human review time:
Escalation count:
Cost per accepted outcome:
ปัญหาที่เกิดซ้ำ:

F. ตัดสินใจ

Decision: keep / route / improve / reduce scope / stop
สิ่งที่จะปรับรอบหน้าเพียง 1 จุด:
วันที่ review ครั้งถัดไป:

หัวใจของ Canvas ไม่ใช่ทำให้ทุกงานถูกที่สุดครับ แต่คือรู้ว่า เงินถูกใช้กับ judgment, execution และ review ตรงไหน แล้วปรับ role mix จากหลักฐาน

ตัวอย่างกับงานที่ไม่ใช่ Coding

สมมติทีมใช้ Agent ทำรายงานลูกค้ารายสัปดาห์

Planner อาจต้องอ่านโจทย์ เลือก metric กำหนดโครงเรื่อง และระบุว่า claim ไหนต้องมี source

Worker หลายตัวอาจดึงข้อมูลจากระบบที่กำหนด สร้าง chart ตาม template และร่าง section ย่อย

Reviewer แบบ deterministic ตรวจตัวเลขรวม, date range, URL และ missing fields ส่วน editor ตรวจว่าคำอธิบายไม่เกินหลักฐาน

ถ้าใช้ model แรงสุดกับการจัด format ทุกตาราง ค่าใช้จ่ายจะโตตามจำนวน report

แต่ถ้าใช้ model เล็กตัดสินใจ narrative ทั้งหมด รายงานอาจถูก format แต่ตีความผิด

การแยก role ทำให้เราใช้ intelligence แพงในจุดที่มี leverage และใช้ automation ประหยัดในจุดที่เป็น volume

ข้อจำกัดที่ต้องรู้

อย่างแรก นี่เป็นผลทดลองที่ Cursor รายงานเอง ไม่ใช่ independent benchmark

อย่างที่สอง งานคือการสร้าง SQLite ด้วย Rust จาก documentation ซึ่งมี test suite และ behavior ที่ตรวจได้ชัด งานประเภท strategy, customer support, creative หรือการตัดสินใจธุรกิจอาจได้ผลต่างกัน

อย่างที่สาม Cursor ปิด source code, hidden tests, SQLite binary และ internet access ระหว่าง run ซึ่งช่วยลด runtime lookup แต่ไม่สามารถพิสูจน์ว่า model ไม่เคยเห็นแนวคิดหรือ implementation ของ SQLite ตอน training

อย่างที่สี่ ค่าใช้จ่ายผูกกับ pricing, model version และ harness ในช่วงเวลานั้น ตัวเลข $1,339 และ $10,565 ไม่ควรถูกเอาไป forecast ค่าใช้จ่ายของบริษัทโดยตรง

อย่างที่ห้า แท่งที่มีเครื่องหมายดอกจันใน chart เป็น informal solo runs เพื่อ calibrate cost ไม่ใช่ controlled comparison บทความนี้จึงไม่ใช้แท่งเหล่านั้นสรุปคุณภาพ

สุดท้าย อย่าแปลคำว่า efficient Worker ว่าโมเดลเล็กต้องทำได้ทุก task ครับ ถ้า Worker fail ซ้ำ ใช้ review time สูง หรือเจอความกำกวมใหม่ ระบบต้อง route ขึ้น ไม่ใช่บังคับให้ทำต่อเพราะอยากประหยัด

สรุป

สิ่งที่น่าสนใจจาก Cursor Agent Swarm ไม่ใช่แค่ตัวเลขเกือบ 8 เท่า

มันคือภาพของ AI Team ที่ไม่ได้ใช้ model เดียวทำทุกอย่าง

Planner ใช้ intelligence ลดความกำกวม Worker ใช้ throughput ทำงานที่ชัด และ Reviewer ใช้ test, model หรือคนตรวจผลตามความเสี่ยง

เริ่มจาก workflow เดียว แยกบทบาท ตั้ง escalation แล้วเก็บ cost กับ pass rate 7 วันครับ

โมเดลที่คุ้มที่สุด ไม่ใช่ตัวที่ถูกหรือเก่งที่สุด แต่คือตัวที่อยู่ถูกบทบาทใน workflow