Plan big, execute small: cookbook ของ Anthropic วัดจริงว่าให้โมเดลใหญ่วางแผน แล้วโมเดลถูกอ่านเว็บ ประหยัดลง ~2.5 เท่า เร็วขึ้น ~3 เท่า

หมายเหตุ: นี่คือโพสต์ตามเก็บ (catch-up) — cookbook นี้ถูก commit ลง repo เมื่อ 2 กรกฎาคม 2026 และแก้ไขรอบสุดท้าย 6 กรกฎาคม 2026 ไม่ใช่ของที่เพิ่งออกวันนี้ แต่เป็นเนื้อหาที่ตรงกับคนสร้าง agent มากพอจะเขียนถึง

---

Anthropic เพิ่มโน้ตบุ๊กใหม่ชื่อ CMA_plan_big_execute_small.ipynb ลงใน claude-cookbooks ว่าด้วย coordinator pattern — แยกงาน “คิด” ออกจากงาน “อ่าน”

ข้อสังเกตตั้งต้นของ cookbook ตรงและคม: งาน agent ส่วนใหญ่ประกอบด้วยงานสองแบบที่ต่างกันมาก — การวางแผนและตัดสินใจซึ่งมีปริมาณน้อย กับการอ่านและลงมือทำแบบกลไกซึ่งมีปริมาณมหาศาล งานค้นข้อมูลบนเว็บคือกรณีสุดขั้ว: การตรวจสอบข้อเท็จจริงยี่สิบข้อกับแหล่งอ้างอิงจริง หมายถึงการลากหน้าเว็บหลายแสนโทเคนผ่านโมเดล และถ้าโมเดลนั้นคือ frontier model ค่าอ่านจะกลืนบิลทั้งใบ

รูปแบบ: coordinator ที่ไม่มีเครื่องมือเป็นของตัวเอง

โครงสร้างมีแค่สอง agent

Worker คือ agent ธรรมดา — โมเดลถูก, ชุดเครื่องมือถูกจำกัดเหลือแค่ web_search + web_fetch, และ system prompt หนึ่งอัน worker แต่ละตัวค้นคำถามย่อยของตัวเองใน session thread แยก หน้าเว็บมหึมาที่มันอ่านจึงไม่เคยเข้า context ของใครอื่น

Coordinator ไม่มีเครื่องมือเป็นของตัวเองเลย มีแค่ฟิลด์ multiagent ที่ระบุรายชื่อ worker ในโรสเตอร์ ฟิลด์เดียวนี้แหละที่ทำให้มันเป็น coordinator — เซิร์ฟเวอร์จะแถมเครื่องมือ create_agent, send_to_agent, wait_for_agents, list_agents ให้อัตโนมัติ ส่วน worker ได้ submit_result กับ send_to_parent มาแบบเดียวกัน คุณไม่ต้องนิยามเครื่องมือพวกนี้เอง

มีสองเรื่องที่ cookbook เตือนไว้เกี่ยวกับความสัมพันธ์นี้

1. โรสเตอร์ถูก snapshot ตอนสร้างหรืออัปเดต coordinator — ถ้าคุณแก้นิยาม worker ต้องอัปเดตหรือสร้าง coordinator ใหม่
2. เรื่องที่เห็นได้ยากกว่า: coordinator มองไม่เห็นอะไรเลยเกี่ยวกับ agent ในโรสเตอร์ของมัน — ไม่เห็น prompt ไม่เห็นชื่อ ไม่เห็นคำอธิบาย เครื่องมือ create_agent ของมันรับแค่ชื่อ agent เปล่า ๆ กับสตริงงาน ทุกอย่างที่ coordinator “เชื่อ” เกี่ยวกับ worker มาจาก system prompt ของตัวมันเอง และไม่มีอะไรบนเซิร์ฟเวอร์บังคับให้ตรงกัน ถ้าคำอธิบายใน prompt ของ coordinator กับ prompt จริงของ worker เพี้ยนจากกัน จะไม่มี error ให้เห็น

การวัดที่ตั้งใจให้ยุติธรรม

จุดที่ทำให้ cookbook นี้น่าเชื่อคือ มันรันฝั่งเปรียบเทียบด้วย ไม่ใช่แค่โชว์ตัวเลขฝั่งตัวเอง

โจทย์คืองานแบบ coverage — ข้อเท็จจริงยี่สิบข้อ (อุทยาน 10 แห่ง × 2 คุณสมบัติ) ที่แต่ละข้อต้องยืนยันกับแหล่งอ้างอิงที่เชื่อถือได้ (nps.gov) งานประเภทนี้คือจุดที่รูปแบบนี้ได้เปรียบ เพราะ การอ่านเป็นสิ่งบังคับ ไม่มีใครตอบจากความจำได้ เหลือแค่คำถามว่าการอ่านนั้นถูกคิดเงินในอัตราไหน และเกิดขึ้นแบบขนานหรือไม่

ฝั่งควบคุมคือ frontier agent ตัวเดียวที่มีเครื่องมือเว็บสองตัวเหมือนกัน และนี่คือรายละเอียดที่ทำให้การเปรียบเทียบมีความหมาย: cookbook บังคับให้ agent เดี่ยว ยึดมาตรฐานการตรวจสอบเดียวกัน คือทุกข้อเท็จจริงต้องยืนยันจากการ fetch อิสระสองครั้ง ขัดแย้งเมื่อไหร่ต้องตรวจซ้ำและติดธงไว้

เหตุผลอยู่ในบรรทัดนี้ของ cookbook เอง: ถ้าปล่อยให้ frontier model ใช้ดุลพินิจของตัวเอง มันจะประหยัด — อ่านแหล่งเดียวต่อข้อเท็จจริงแล้วจบถูก ๆ แต่นั่นคือ สินค้าคนละเกรด ไม่ใช่งานเดียวกันในราคาต่างกัน

ตัวเลข และสิ่งที่ตัวเลขไม่ได้บอก

ผลบนรันของผู้เขียน:

ตัวชี้วัด	ผล
ค่าใช้จ่าย	ทีมถูกกว่าราว 2.5 เท่า
เวลา (wall-clock)	ทีมเร็วกว่าราว 3 เท่า
สัดส่วน input token ที่คิดในอัตรา worker	84–98%

ทั้งสองฝั่งอ่านพอ ๆ กัน — นั่นคือประเด็นทั้งหมดของการล็อกมาตรฐานการตรวจสอบ สิ่งที่ต่างคือ อัตราค่าอ่าน และ รูปทรงของงาน: การค้นยี่สิบครั้งของทีมวิ่งขนานกันใน worker thread ราคาถูก ส่วน agent เดี่ยวไล่บดทีละข้อแบบอนุกรมใน context ราคา frontier

cookbook เตือนเองว่า ปริมาณโทเคนแกว่งไปมาในแต่ละรัน ให้ถือว่าอัตราส่วนที่พิมพ์ออกมาเป็นแค่ตัวอย่างหนึ่งตัว โครงสร้างต่างหากที่เป็นส่วนที่เสถียร

และนี่คือข้อควรระวังสี่ข้อที่ cookbook เขียนไว้เอง — น่าสนใจกว่าตัวเลขเสียอีก

• ต้องล็อกความเข้มงวดให้เท่ากัน ไม่งั้นการเปรียบเทียบไม่มีความหมาย (ตามที่อธิบายข้างบน)
• การ delegate มีต้นทุนขั้นต่ำ worker thread แต่ละตัวจ่ายค่า setup คงที่ การซอยงานเดิมให้เป็น brief ที่แคบลงและเยอะขึ้น กลับทำให้บิลแพงขึ้น — ความละเอียดของ brief มีจุดที่เหมาะสมของมัน
• มาตรฐานการตรวจสอบครอบคลุมแค่สิ่งที่คุณใส่ลงไป ทั้งสองฝั่งยืนยันข้อเท็จจริงครบยี่สิบข้อกับ nps.gov จริง — แต่ทั้งสองฝั่งสร้าง รายชื่ออุทยาน ขึ้นมาจากความจำของโมเดล ซึ่งพลาด
• คำถามแบบ discovery ไม่ใช่จุดแข็งของรูปแบบนี้ งานแบบหาคำตอบเดียวที่ซ่อนอยู่ในพื้นที่ค้นหาใหญ่ (สไตล์เบนช์มาร์ก BrowseComp) ให้รางวัลกับสัญชาตญาณการค้นของ frontier model มากกว่า ช่องว่างจะแคบลง

การคิดเงินอยู่ใน API แล้ว

สิ่งที่ทำให้รูปแบบนี้วัดได้จริง: session thread ทุกตัวมีฟิลด์ usage สะสมแบบมี type และ session.usage รวมทั้งทีม วิธีอ่านคือ list threads ออกมา ตัวที่ parent_thread_id เป็น None คือ coordinator ที่เหลือคือ worker — ส่วน session ของ agent เดี่ยวก็ไม่มี child thread เลย

รายละเอียดที่คนทำ agent ควรจำ: /v1/models รายงาน capability แต่ไม่รายงานราคา ราคาต่อโมเดลจึงต้องอยู่ในโค้ดคุณเอง ส่วนแคช — cache write อายุ 5 นาทีคิด 1.25 เท่า ของอัตรา input, อายุ 1 ชั่วโมงคิด 2 เท่า, ส่วน cache read คิด 0.1 เท่า

ช่องว่างราคาระหว่างชั้นโมเดลคือสิ่งที่ทำให้ทั้งหมดนี้คุ้ม (ราคาต่อล้านโทเคน input/output):

โมเดล	Input	Output
Claude Fable 5	$10	$50
Claude Opus 4.8	$5	$25
Claude Sonnet 5	$3 ($2 ราคาแนะนำถึง 31 ส.ค. 2026)	$15 ($10)
Claude Haiku 4.5	$1	$5

เมื่อ 84–98% ของ input token ย้ายจากแถวบนไปแถวล่าง เลขมันก็เดินตามนั้นเอง

ระวังอย่าสับสนกับ advisor tool

มีอีกพรีมิทีฟหนึ่งที่แก้ปัญหาใกล้เคียงกันแต่คนละตัว และไม่ใช่ของใหม่: advisor tool ซึ่งให้ executor model ที่เร็วและถูก ปรึกษา advisor model ที่ฉลาดกว่ากลางคัน advisor อ่านบทสนทนาทั้งหมด ผลิตแผนหรือการแก้ทิศทาง แล้ว executor ทำงานต่อ

ข้อแตกต่างเชิงโครงสร้าง: advisor คือการปรึกษาระหว่างการ generate ครั้งเดียว ส่วน coordinator คือการ delegate ข้าม thread แบบขนาน และ advisor tool ใช้ beta header advisor-tool-2026-03-01 — มาตั้งแต่มีนาคม 2026 ไม่ใช่ของที่เพิ่งประกาศ ข้อบังคับสำคัญคือ advisor model ต้องเก่งเท่าหรือเก่งกว่า executor ถ้าจับคู่ผิดจะได้ HTTP 400

หมายเหตุการตรวจสอบ: รายงานรอบสัปดาห์นี้บางแห่งอ้างตัวเลขเบนช์มาร์กของ “advisor pattern” และ “orchestrator pattern” (เช่น 92% ของประสิทธิภาพที่ 63% ของต้นทุน) โดยอ้างอิงโพสต์บนโซเชียล เราตรวจสอบทั้งเอกสาร advisor tool และตัวโน้ตบุ๊กแล้ว ไม่พบตัวเลขชุดนั้นในต้นทางทั้งสองแห่ง จึงเลือกไม่รายงานตัวเลขดังกล่าว และรายงานเฉพาะตัวเลขที่อยู่ใน cookbook จริง (2.5 เท่า / 3 เท่า / 84–98%)

มุมมอง AI Curator

สิ่งที่มีค่าที่สุดใน cookbook นี้ไม่ใช่ตัวเลข แต่คือระเบียบวิธี เนื้อหาการตลาดเรื่อง multi-agent เกือบทั้งหมดเปรียบเทียบ “ระบบใหม่ของเรา” กับ baseline ที่ไม่มีใครใช้จริง แต่โน้ตบุ๊กนี้ทำสิ่งที่ยากกว่า: มันรัน frontier model ตัวเดียวด้วยเครื่องมือชุดเดียวกัน แล้วบังคับให้มันขยันเท่ากัน — เพราะรู้ว่าถ้าไม่บังคับ agent เดี่ยวจะชนะด้านราคาโดยแอบลดคุณภาพงานลง การยอมเขียนประโยคว่า “ถ้าปล่อยตามใจ frontier model จะถูกกว่าทีมของเรา” ลงในเอกสารการตลาดของตัวเอง เป็นความซื่อสัตย์ที่หายาก

และข้อควรระวังข้อที่สองคือของจริงที่จะทำให้คุณเสียเงิน สัญชาตญาณของวิศวกรคือ “ถ้าแบ่งงานแล้วถูกลง ก็แบ่งให้ละเอียดขึ้นสิ” — cookbook บอกตรง ๆ ว่าลองแล้วบิลแพงขึ้น เพราะทุก worker thread จ่ายค่า setup คงที่ นี่คือรูปแบบเดียวกับ overhead ของ thread ในระบบปฏิบัติการ หรือ N+1 query ในฐานข้อมูล การขนานไม่ฟรี และจุดคุ้มทุนต้องวัด ไม่ใช่เดา

สำหรับทีมไทยและ SEA เรื่องนี้ตรงประเด็นเป็นพิเศษ งบค่า token คือข้อจำกัดจริงของสตาร์ตอัปในภูมิภาคนี้ในแบบที่ไม่ใช่สำหรับบริษัทใน Bay Area และงานที่คนไทยทำเยอะที่สุดกับ LLM — สรุปเอกสารราชการ ตรวจสอบข้อมูลข้ามหลายแหล่ง ประมวลผลเอกสารภาษาไทยจำนวนมาก — เป็นงาน coverage แทบทั้งหมด ไม่ใช่งาน discovery นั่นแปลว่ามันตกอยู่ในช่องที่รูปแบบนี้ได้เปรียบชัดเจนที่สุด พอดี

แต่มีข้อควรระวังเฉพาะภาษาไทยที่ cookbook ไม่ได้พูดถึง: tokenizer กินโทเคนภาษาไทยเปลืองกว่าภาษาอังกฤษมาก สำหรับเนื้อหาปริมาณเท่ากัน ด้านหนึ่งนี่ยิ่งทำให้การย้ายงานอ่านไปอยู่กับ worker ราคาถูกคุ้มกว่าเดิม เพราะฐานที่ประหยัดได้ใหญ่ขึ้น อีกด้านหนึ่งคุณจะชน context limit ของ worker เร็วกว่าที่ตัวอย่างภาษาอังกฤษบอก ดังนั้นอย่าลอกขนาด brief จาก cookbook มาตรง ๆ — วัดกับข้อความไทยจริงของคุณเองก่อน

ท้ายที่สุด ผมอ่านโน้ตบุ๊กนี้ว่าเป็นสัญญาณเรื่องทิศทางราคา เมื่อผู้ให้บริการโมเดลลงมือเขียนคู่มือสอนลูกค้าให้ ใช้โมเดลแพงของตัวเองให้น้อยลง นั่นแปลว่าการแข่งขันด้านราคาบีบพอที่ “ต้นทุนต่องานสำเร็จ” จะกลายเป็นตัวชี้วัดที่สำคัญกว่าคะแนนเบนช์มาร์กดิบไปแล้ว — ซึ่งเป็นข่าวดีสำหรับคนสร้างของ

แหล่งข่าว

• CMA_plan_big_execute_small.ipynb — Anthropic Claude Cookbooks (GitHub)
• Advisor tool — เอกสาร Claude Platform
• BrowseComp: a benchmark for browsing agents (arXiv 2504.12516)
• claude-cookbooks repository