Claude คิด + Local AI ทำ — Planner-Executor Pattern

Pattern ทำงานยังไง — กลไกจริง 4 ขั้น

หัวใจของ pattern นี้คือการ แบ่งงาน 2 บทบาท: Claude เป็น "วิศวกรอาวุโส" ที่อ่าน requirement, ออกแบบ, เขียน step-by-step plan ส่วน Local AI เป็น "วิศวกรปฏิบัติการ" ที่ทำตาม plan แบบไม่ต้องคิดเอง ลำดับงานจะเป็น:

ขั้นที่	ใครทำ	งานที่ทำ	ผลลัพธ์
1. Intake	Claude	รับโจทย์จากผู้ใช้ ถาม clarifying question ถ้าจำเป็น	requirement ที่ชัดเจน
2. Plan	Claude	แตกเป็น sub-task ระบุไฟล์ที่ต้องแก้, ลำดับ, edge case	structured plan (JSON / markdown)
3. Execute	Local AI	อ่านไฟล์ แก้โค้ด รัน test ตาม plan ผ่าน tool use ของตัวเอง	code diff + log การรัน
4. Verify	Claude	review diff + log ว่าตรง plan ไหม สั่ง retry ถ้าผิด	approve หรือ ส่งกลับ executor

จะเห็นว่าขั้น 1, 2, 4 ใช้ Claude — แต่ token น้อยกว่าขั้น 3 มาก เพราะการคิดแผน + review ใช้ตัวอักษรน้อยกว่าการ implement จริงหลายเท่า ขั้น 3 ที่กิน token มากที่สุดถูกย้ายไป Local AI ทำให้ค่า cloud API ลดลงอย่างมีนัยสำคัญ

ทำไมต้องแยก — เปรียบเทียบ 3 ทางเลือก

องค์กรที่อยากใช้ AI ทำงานจริงมี 3 ทางหลัก: ใช้ cloud อย่างเดียว, ใช้ local อย่างเดียว, หรือ hybrid แบบ planner-executor — ทั้งสามมีจุดเด่นและจุดอ่อนต่างกัน

มิติ	Cloud-only (Claude เท่านั้น)	Local-only (Qwen/DeepSeek เท่านั้น)	Hybrid (Planner-Executor)
คุณภาพ plan	สูงสุด	กลาง — รุ่นเล็กพลาด edge case	สูงสุด (Claude วาง)
ค่าใช้จ่าย token	สูง	เกือบศูนย์ (ค่าไฟ + hardware)	ต่ำกว่า cloud-only มาก (เฉพาะ plan + verify)
โค้ดออกนอกองค์กร?	ออก — ทุก request	ไม่ออกเลย	เฉพาะ plan + diff สั้นๆ ไม่ใช่โค้ดเต็ม
Latency	ดี (Anthropic infra)	เร็วเฉพาะ inference สั้น, ช้าเมื่อ context ยาว	รวม latency = cloud + local (ช้ากว่าทั้งสอง)
Hardware ต้องใช้	ไม่ต้อง	GPU แรง (≥24GB VRAM)	GPU แรง
Setup ซับซ้อนแค่ไหน	ง่ายมาก (API key)	กลาง (Ollama / vLLM)	ซับซ้อนสุด — orchestrator + 2 backend

เห็นชัดว่า hybrid ไม่ใช่ทางที่ง่ายที่สุด — มันคือทางที่ลดต้นทุน + ลดข้อมูลออกได้ แต่แลกกับ complexity ในการ setup องค์กรที่ data sensitivity ต่ำหรือยังไม่ได้ deploy AI ในวงกว้าง การใช้ cloud-only อาจคุ้มกว่า แต่ถ้าใช้ AI ทำงานทุกวันในทีม dev 10+ คน และโค้ดเป็นทรัพย์สินสำคัญ pattern นี้คือทางที่หลายองค์กร enterprise เริ่มไปทาง

Hardware ที่ต้องใช้จริง — แยกตาม model size

ปัจจัยที่ทำให้ pattern นี้ "เล่นได้จริง" คือ Local AI ต้องเก่งพอ โดยเฉพาะเรื่อง instruction following และ tool use ไม่งั้นต่อให้ Claude เขียน plan ละเอียดแค่ไหน executor ก็พังกลางคัน รุ่นที่ใช้งานได้จริงในงาน coding/agent ปี 2569 (May 2026) มีดังนี้:

Model	Params	VRAM ที่ต้องใช้ (4-bit quant)	เหมาะกับงาน
Qwen2.5-Coder-7B	7B	~6GB	งานเล็ก เช่น autocomplete — instruction following ไม่แข็งพอเป็น executor
Qwen2.5-Coder-14B	14B	~10GB	งาน single-file refactor — ขีดล่างที่เล่น executor ได้
Qwen2.5-Coder-32B	32B	~22GB	งานหลายไฟล์ + tool use — sweet spot ของ pattern นี้
DeepSeek-V3	671B (MoE, active 37B)	~380GB (FP8)	งาน enterprise — ต้อง multi-GPU cluster
Llama 3.3 70B	70B	~42GB	general-purpose executor — instruction following ดีมาก

การเลือก hardware จะกำหนดว่าจะใช้ model ไหนได้ — ไม่ใช่กลับกัน เพราะ GPU เป็นต้นทุนหลัก ตัวอย่าง hardware ที่จับคู่ในไทย:

Hardware	VRAM	รัน model ได้	เหมาะกับ
RTX 4090	24GB	Qwen2.5-Coder-32B (ตึงๆ)	ทีม dev 1-3 คน
RTX 5090	32GB	Qwen2.5-Coder-32B (สบาย) / Llama 70B (quant หนัก)	ทีม dev 3-5 คน
A6000	48GB	Llama 70B (4-bit) ได้สบาย	ทีม 5-10 คน, on-prem inference server
Mac Studio M3 Ultra 256GB	~192GB unified	DeepSeek-V3 (4-bit) ได้	ทีม R&D, low concurrency
H100 / B200 cluster	80-192GB ×N	DeepSeek-V3 FP8, multi-tenant	องค์กรขนาดใหญ่ shared infra

หลายองค์กรไทยที่เริ่มทดลอง pattern นี้เลือก RTX 5090 หรือ A6000 ก่อน เพราะคุ้มและรองรับ Qwen2.5-Coder-32B ซึ่งเป็น executor ที่ "ใช้งานได้จริง" ในงาน coding ทั่วไป รายละเอียดเรื่องการ deploy model บน server เองดูเพิ่มได้ที่ Ollama Self-Host — ความปลอดภัยที่ต้องระวัง และ DeepSeek Self-Host — แนวทาง deploy บน hardware องค์กร

เครื่องมือที่ใช้ implement pattern นี้ได้จริง

ตอนนี้ (พ.ค. 2569) มี framework หลายตัวที่รองรับ planner-executor architecture ออกมา — ไม่ต้องเขียน orchestrator เอง:

เครื่องมือ	บทบาท	เหมาะกับ
Claude Agent SDK	framework สำหรับสร้าง agent ที่ใช้ Claude เป็น planner + เรียก sub-agent ที่ใช้ model อื่นได้	ทีม dev ที่อยากคุม flow เอง
Ollama	รัน Local AI model + เปิด OpenAI-compatible API ให้ orchestrator เรียก	ทุก setup ที่ใช้ Local AI
vLLM	serving framework สำหรับ Local AI ที่ throughput สูงกว่า Ollama มาก	production multi-user
MCP (Model Context Protocol)	protocol มาตรฐานที่ Claude และ Local AI ใช้คุยกับ tool / data source เดียวกัน	setup ที่อยาก plug-and-play ทุกชั้น
LangGraph	graph-based orchestrator ที่ระบุ flow planner → executor → verifier ได้ชัด	ทีมที่ workflow ซับซ้อน, ต้องการ resumable run

การ start จริงในองค์กรไทย แนะนำ pattern: Claude Agent SDK (planner) → เรียก Ollama ที่ host Qwen2.5-Coder-32B บน RTX 5090 (executor) — ทุก tool call ที่ executor ต้องการ ใช้ MCP server เดียวกับที่ planner ใช้ — เพื่อให้ทั้งสองชั้นเห็น context เหมือนกัน ดูเพิ่มเรื่อง Ollama ในบทความ Ollama คืออะไร — Local AI ที่รันบนเครื่องคุณเอง

⚠️ Trade-off + ความเสี่ยงที่ต้องรู้ก่อน deploy

Pattern นี้ไม่ใช่ silver bullet — มันแก้ปัญหาเรื่องต้นทุน + privacy แต่สร้างปัญหาใหม่ 4 อย่างที่หลายทีมเจอตอนใช้จริง

1. Plan-Execute mismatch

Claude เขียน plan สมบูรณ์แบบ แต่ Local AI อ่านแล้วเข้าใจไม่ครบ ทำตามไปครึ่งทาง แล้วเดาเอง — สาเหตุหลักคือ executor model ไม่แข็งพอ ทางแก้: ต้อง verify ทุก batch และ retry ถ้า diff ไม่ตรง plan

2. Round-trip latency สูง

งานที่เร็วๆ ใน cloud-only ใช้ 10 วินาที พอเป็น hybrid อาจกลายเป็น 30-60 วินาที เพราะรอ network 2 ทาง + Local AI inference — ไม่เหมาะกับงานที่ต้องการ real-time response แต่เหมาะมากกับ batch job หรือ background task

3. Context drift ระหว่าง 2 model

Claude มี context window ใหญ่ (200K-1M) แต่ Local AI ส่วนใหญ่มี ~32K-128K ถ้า plan ยาว + ต้องอ่านโค้ดประกอบ Local AI อาจ truncate context สำคัญทิ้ง — เหมือนปัญหาที่บทความ Claude Dreaming — เมื่อ AI เริ่มฝัน อธิบายไว้เรื่อง memory consolidation

4. Debugging ยากขึ้น 2 เท่า

ถ้าผลลัพธ์ผิด ต้องไล่ดูว่า plan ผิด (Claude) หรือ execution ผิด (Local) — log ต้องครบทั้งสองชั้น และต้องมี mechanism replay ได้ ไม่งั้นโยนความผิดให้กันไปมาแบบหา root cause ไม่ได้

ความเสี่ยง	วิธี mitigate	ใครต้องทำ
Plan-Execute mismatch	Claude verify step สุดท้ายเสมอ, set retry budget	Dev / Orchestrator
Round-trip latency	ใช้กับ batch / background ไม่ใช่ real-time UX	Architect
Context drift	บีบ plan ให้สั้น, แบ่ง sub-task ขนาดเล็ก, summarize file	Planner (Claude)
Debugging ซับซ้อน	centralized logging, replay infra, observability เต็มชั้น	DevOps

Use case ในองค์กรไทย — เริ่มจากไหนดี

ทีมที่ไม่เคยทำ AI agent มาก่อน ไม่ควรเริ่มจาก pattern นี้ในงาน production ทันที — ควรเริ่มจาก task ที่ impact ต่ำ + verify ได้ง่าย ก่อน 3 use case ที่เหมาะเริ่มต้น:

A. Code review / refactor (low-risk)

Claude อ่าน PR + เขียน comment ว่าควรแก้อะไร → Local AI ลงมือแก้เป็น draft commit → คนรีวิวก่อน merge ความผิดพลาดถ้ามีก็แค่ draft commit ไม่ deploy

B. Data migration scripts

Claude วิเคราะห์ schema เก่า/ใหม่ เขียน plan การ migrate → Local AI generate SQL/Python script ตาม plan → รัน dry-run ใน staging — เป็นงาน batch ไม่กลัว latency

C. Documentation generation

Claude วาง outline เอกสาร (จากการอ่าน codebase) → Local AI เขียน detail แต่ละ section → Claude review ภาพรวม — งานนี้แทบไม่มี downside แม้ผลลัพธ์ไม่ perfect

หลังจาก 3 use case แรกได้ผลแล้ว ค่อยขยับไปงานที่ risk สูงขึ้น เช่น generate test cases, refactor module, หรือ implement feature เล็กๆ ตาม spec แนวคิดเรื่อง AI ทำงานเป็นทีมที่มีบทบาทต่างกันนี้ใกล้เคียงกับที่บทความ AI Agent Team — เมื่อ AI ทำงานเป็นทีม เคยอธิบายไว้ในระดับ multi-agent

ที่ Saeree ERP มอง Pattern นี้ยังไง

Saeree ERP กำลังพัฒนา AI Assistant สำหรับงาน ERP โดยตรง — และในการพัฒนา/บำรุงรักษาตัวระบบเอง ทีมเราใช้ pattern hybrid ที่ใกล้เคียงกับที่บทความนี้อธิบาย เพราะลูกค้าจำนวนมากเป็นองค์กรที่ โค้ดและ schema ฐานข้อมูลออกนอกองค์กรไม่ได้ (หน่วยงานราชการ, รัฐวิสาหกิจ, ผู้ผลิตที่มี IP สำคัญ) การให้ Claude วางแผนแล้ว Local AI implement ภายใต้ผู้ดูแลในออฟฟิศ จึงเป็นทางที่ เคารพ data residency โดยไม่เสียคุณภาพการคิด

สำหรับลูกค้าที่ deploy Saeree ERP แบบ on-premise เราเห็น pattern นี้เป็น roadmap สำหรับการเปิด AI feature ในระบบจริงในระยะถัดไป — เพราะมันแก้ปัญหา "อยากใช้ AI แต่ข้อมูลออกนอกองค์กรไม่ได้" โดยตรง

สรุป — Hybrid ดีอย่างไร (และไม่ดีอย่างไร)

ข้อดี	ข้อเสีย / ความเสี่ยง
ลดค่า cloud API ลงได้มาก (เฉพาะ plan + verify ส่งขึ้น cloud)	ต้องลงทุน hardware + setup orchestrator
โค้ด/ข้อมูลส่วนใหญ่อยู่ในองค์กร — data residency ตามนโยบาย	Local AI ต้องเก่งพอ — รุ่นต่ำกว่า 14B มักไม่พอ
ใช้จุดแข็งของแต่ละ model ตรงตามที่มันถนัด	Latency รวมสูงขึ้น 2-3 เท่าเทียบ cloud-only
Scale ได้ตามจำนวน executor ไม่ผูกกับ quota ของ vendor	Debug ยากขึ้น — ต้องไล่ทั้ง planner + executor
เปลี่ยน executor model ได้ในอนาคต โดยไม่กระทบ planner	ต้องมี SRE/DevOps ที่ดูแล GPU server เป็น

"การใช้ AI ที่ฉลาดที่สุดในที่ที่ต้องคิด และใช้ AI ที่ถูกที่สุดในที่ที่ต้องทำ คือ pattern ที่จะกำหนดเศรษฐศาสตร์ของ AI ในองค์กร 2-3 ปีข้างหน้า"

คำถามที่เหลือไว้ให้คิด

ทุก request ที่ทีมคุณส่งไป cloud AI วันนี้ — มีกี่ % ที่จริงๆ แล้วเป็นงาน "ทำตามขั้นตอน" ที่ไม่ต้องใช้สมองระดับ Claude? และถ้าคุณย้ายแค่ส่วนนั้นไป Local AI จะประหยัดค่า token ได้กี่ % ในแต่ละเดือน? ตัวเลขนี้คือสิ่งที่ควรประเมินก่อนตัดสินใจลงทุน hardware

หากองค์กรของคุณกำลังประเมินสถาปัตยกรรม AI สำหรับใช้กับระบบหลักภายใน — ทั้ง ERP, HR หรืองาน internal automation — นัดหมายปรึกษาทีม Saeree ERP เพื่อช่วยออกแบบ deployment ที่เหมาะกับ data policy และ scale ขององค์กรคุณ

แหล่งอ้างอิง

• Anthropic — Claude Agent SDK Overview
• Anthropic — Building Effective Agents (orchestrator-workers pattern)
• Ollama — Qwen2.5-Coder model card
• DeepSeek — DeepSeek-V3 technical report
• vLLM — vLLM serving documentation
• Model Context Protocol — MCP specification