MilerDev

ถ้า AI ตัวเดียวทำงานได้หลายอย่าง แล้วทำไมเราต้องมี AI หลายตัวมาช่วยกันทำงาน?
คำตอบคือ งานที่ซับซ้อนบางประเภทไม่ได้ต้องการ AI ที่ “เก่งทุกอย่าง” แต่ต้องการ AI หลายตัวที่มีหน้าที่ชัดเจน และรู้ว่าเมื่อไหร่ควรส่งงานต่อให้ใคร แนวคิดนี้คือจุดเริ่มต้นของ Subagent และ Multi-agent
🔷 เริ่มจากคำว่า Agent ก่อน
Agent คือ AI ที่ไม่ได้มีแค่ Model สำหรับสร้างคำตอบ แต่ถูกกำหนด Instructions หรือหน้าที่ มี Tools ที่เรียกใช้ได้ และอาจมีความสามารถในการตัดสินใจว่าจะทำอะไรต่อเพื่อให้งานสำเร็จ
เช่น Agent สำหรับ Research อาจค้นเว็บและอ่านเอกสารได้ ส่วน Agent สำหรับ Coding อาจมีเครื่องมือสำหรับอ่านโค้ด แก้ไฟล์ หรือรันคำสั่ง โดยแต่ละ Agent ถูกออกแบบให้เหมาะกับงานคนละประเภท
🔷 แล้ว Subagent คืออะไร?
ลองนึกภาพว่าคุณมี “หัวหน้าทีม AI” หนึ่งตัว เมื่อได้รับงานใหญ่เข้ามา มันไม่จำเป็นต้องทำทุกอย่างด้วยตัวเอง แต่สามารถแบ่งงานบางส่วนให้ Agent ที่เชี่ยวชาญกว่าไปจัดการ
▪️ Research Agent → ค้นหาและรวบรวมข้อมูล
▪️ Coding Agent → เขียนหรือวิเคราะห์โค้ด
▪️ Review Agent → ตรวจสอบความถูกต้อง
▪️ Writing Agent → เรียบเรียงผลลัพธ์ให้อ่านง่าย
Agent ที่ถูกเรียกมาช่วยทำงานย่อยในลักษณะนี้ เรามักเรียกว่า Subagent
ประโยชน์คือเราสามารถแยก Context, Instructions และ Tools ตามหน้าที่ได้ แทนที่จะยัดทุกอย่างไว้ใน Agent ตัวเดียว ซึ่งช่วยให้ระบบออกแบบและควบคุมพฤติกรรมของแต่ละส่วนได้ง่ายขึ้น
🔷 Multi-agent ต่างจาก Subagent ยังไง?
Multi-agent เป็นแนวคิดที่กว้างกว่า หมายถึงระบบที่มี Agent หลายตัวทำงานร่วมกัน โดยความสัมพันธ์ไม่จำเป็นต้องเป็น “หัวหน้า → ลูกทีม” เสมอไป
ตัวอย่างหนึ่งคือ Manager Pattern ที่มี Agent หลักคอยเรียก Specialist Agents มาช่วยทำงาน แล้วนำผลลัพธ์กลับมารวมเป็นคำตอบสุดท้าย อีกแบบคือ Handoff ที่ Agent ตัวแรกวิเคราะห์ว่างานควรไปหาใคร แล้วส่งต่อให้ Specialist Agent รับช่วงการทำงานต่อโดยตรง
นอกจากนี้ยังออกแบบเป็น Pipeline ได้ เช่น
Research Agent → Analysis Agent → Writer Agent → Reviewer Agent
หรือถ้างานแต่ละส่วนไม่ต้องรอกัน ก็สามารถให้หลาย Agent ทำงานพร้อมกัน แล้วค่อยรวมผลลัพธ์ภายหลังได้
🔷 ทำไมไม่ใช้ Agent ตัวเดียวให้จบ?
เพราะเมื่อระบบใหญ่ขึ้น Agent ตัวเดียวอาจต้องแบก Instructions, Tools และ Context จำนวนมาก ทำให้ควบคุม Workflow ยากขึ้น และยากต่อการตรวจสอบว่าแต่ละขั้นตอนผิดพลาดตรงไหน
การแยก Agent ตามความรับผิดชอบจึงคล้ายกับการออกแบบ Software Architecture เราไม่ได้แยก Service เพียงเพราะทำได้ แต่แยกเมื่อมันช่วยให้ Responsibility ชัดขึ้น ดูแลระบบง่ายขึ้น และเลือกเครื่องมือหรือข้อจำกัดให้เหมาะกับแต่ละงานได้
แต่ Multi-agent ก็ไม่ได้ดีกว่าเสมอ เพราะ Agent ที่เพิ่มขึ้นหมายถึง Model Calls ที่เพิ่มขึ้น รวมถึง Latency, Cost และความซับซ้อนในการ Debug ที่สูงขึ้นด้วย
📌 Key Takeaway
Subagent คือการให้ Agent อื่นเข้ามารับผิดชอบงานย่อยเฉพาะด้าน ส่วน Multi-agent คือภาพใหญ่ของการออกแบบระบบให้ Agent หลายตัวทำงานร่วมกันผ่านรูปแบบต่าง ๆ เช่น Manager, Handoff, Pipeline หรือ Parallel Ex*****on
หัวใจสำคัญจึงไม่ใช่ “ยิ่งมี Agent เยอะยิ่งดี” แต่คือการรู้ว่า งานส่วนไหนควรแยกความรับผิดชอบ และ Agent แต่ละตัวควรมี Context, Tools และขอบเขตการตัดสินใจแค่ไหน
ถ้ากำลังสร้าง AI Agent อยู่ ลองกลับไปดู Workflow ของคุณว่า ตอนนี้มีงานส่วนไหนที่ Agent ตัวเดียวกำลังแบกหลายหน้าที่เกินไปหรือเปล่า

ใช้ Claude Code แล้วรู้สึกว่า “เก่งนะ แต่บางครั้งแก้โค้ดไปคนละทางกับที่ต้องการ” ปัญหาอาจไม่ได้อยู่ที่ Claude Code แต่อยู่ที่ Workflow ที่เราใช้กับมัน
เพราะ Claude Code ไม่ควรถูกใช้เหมือน Chatbot ที่เราพิมพ์ว่า “ช่วยทำ Feature นี้ให้หน่อย” แล้วรอรับโค้ด แต่ควรใช้เหมือน Developer อีกคนในทีม ที่ต้องรู้ Context เข้าใจ Requirement วางแผนก่อนลงมือ และมีขั้นตอนตรวจงานก่อนส่ง
🔷 Workflow ที่ผมแนะนำคือ Context → Explore → Plan → Implement → Test → Review
▪️ 1. Context — ทำให้ Claude รู้จัก Project ก่อน
ก่อนสั่งงาน ควรให้ Claude เข้าใจว่า Project นี้ใช้ Tech Stack อะไร โครงสร้างเป็นแบบไหน ใช้คำสั่งอะไรในการ Build, Test และ Lint รวมถึงมี Coding Convention อะไรที่ต้องรักษา
Claude Code มีไฟล์ `CLAUDE.md` สำหรับเก็บ Context และ Instruction ของ Project เช่น
`pnpm test` สำหรับรัน Test
ห้ามใช้ `any` ใน TypeScript
แก้ Bug ต้องเพิ่ม Test ที่ reproduce ปัญหาได้ก่อน
ห้าม Force Push เข้า `main`
มองง่าย ๆ ว่า `README.md` เขียนให้คนอ่าน ส่วน `CLAUDE.md` คือคู่มือการทำงานที่ช่วยให้ Claude เข้าใจ Project และกติกาของทีมตั้งแต่เริ่ม Session
▪️ 2. Explore — อย่าเพิ่งให้แก้โค้ด ให้สำรวจก่อน
ถ้าต้องแก้ Bug ในระบบ Login แทนที่จะเริ่มด้วย “แก้ Login ให้หน่อย” ลองสั่งให้ Claude หาไฟล์ที่เกี่ยวข้อง อ่าน Authentication Flow และอธิบายว่า Request วิ่งผ่านส่วนไหนบ้างก่อน
ขั้นตอนนี้สำคัญมาก เพราะเรากำลังลดโอกาสที่ Claude จะรีบแก้จากสมมติฐานที่ผิด และยังช่วยให้เราเห็นด้วยว่ามันเข้าใจ Codebase ตรงกับเราหรือไม่
▪️ 3. Plan — ให้เสนอแผนก่อนลงมือ
เมื่อ Context ชัดแล้ว ให้ Claude สรุป Root Cause ระบุไฟล์ที่ต้องแก้ ผลกระทบที่อาจเกิดขึ้น และวิธี Test หลังแก้เสร็จ
สำหรับงานที่ซับซ้อนสามารถใช้ Plan Mode เพื่อให้ Claude วาง Strategy ก่อน Execute จริง ทำให้เราตรวจ Direction ได้ตั้งแต่ต้น แทนที่จะปล่อยให้เขียนโค้ดไปหลายไฟล์แล้วค่อยพบว่า Approach ผิด
▪️ 4. Implement — ค่อยให้ลงมือแก้
เมื่อ Plan ผ่านแล้ว ค่อยให้ Claude Implement ตามขอบเขตที่ตกลงกัน เช่น “ทำตาม Plan นี้ แต่อย่าแก้ Public API และอย่า Refactor ส่วนที่ไม่เกี่ยวข้อง”
Requirement ที่ชัดเจนจะช่วยควบคุม Scope และทำให้ Diff ที่ได้ตรวจง่ายกว่าการปล่อยให้ Agent ตัดสินใจทุกอย่างเอง
▪️ 5. Test — อย่าใช้คำว่า “น่าจะใช้ได้”
หลังแก้เสร็จ ให้ Claude รัน Unit Test, Integration Test, Type Check, Lint หรือ Build ตามที่ Project ใช้งานจริง และถ้ามี Test Fail ให้ตรวจ Root Cause ก่อนแก้ต่อ
เป้าหมายคือเปลี่ยนจาก “Claude บอกว่าเสร็จแล้ว” ให้กลายเป็น “มีหลักฐานว่าโค้ดผ่านเงื่อนไขที่เรากำหนด”
▪️ 6. Review — ให้ตรวจงานตัวเองอีกรอบ
ก่อน Commit ลองให้ Claude ตรวจ `git diff` แล้วถามว่า มี Logic ที่ผิดหรือไม่ มี Edge Case ที่ตกหล่นหรือไม่ มี Security Issue หรือ Breaking Change หรือไม่ และมีไฟล์ไหนถูกแก้โดยไม่จำเป็นหรือเปล่า
จากนั้น Developer ค่อย Review Final Diff อีกครั้ง เพราะ Claude Code ควรช่วยลดงานที่ต้องทำด้วยมือ ไม่ใช่ลดความรับผิดชอบของคนที่เป็นเจ้าของ Code
📌 Key Takeaway
Workflow ที่ดีไม่ใช่ Prompt → Code แต่คือ Context → Explore → Plan → Implement → Test → Review
ยิ่งงานใหญ่ อย่ารีบให้ AI เขียนโค้ด ให้ลงทุนกับ Context และ Plan ก่อน เพราะหน้าที่ของเรากำลังขยับจาก “เขียนทุกบรรทัดเอง” ไปสู่การกำหนดว่าอะไรควรถูกสร้าง ตรวจว่า Approach ถูกหรือไม่ และใช้ Test ยืนยันว่าผลลัพธ์ทำงานจริง
ถ้าใช้ Claude Code อยู่ ลองเอา Workflow นี้ไปใช้กับ Task ถัดไป แล้วเปรียบเทียบดูว่า Diff ที่ได้สะอาดขึ้น และเวลา Review ลดลงแค่ไหน
ถ้าคิดว่าโพสต์นี้มีประโยชน์ เซฟไว้เป็น Checklist ก่อนเปิด Claude Code รอบหน้า หรือแชร์ให้ Developer ในทีมลองใช้ Workflow เดียวกัน

ใช้ Claude Code แล้วรู้สึกว่า “มันก็เขียนโค้ดเก่งนะ แต่ทำไมแก้ไปแก้มาจน Codebase เริ่มเละ”
ปัญหาอาจไม่ได้อยู่ที่ Claude Code แต่อยู่ที่เราใช้งานมันเหมือน Chatbot ที่สั่งว่า “ทำ Feature นี้ให้หน่อย” แล้วปล่อยให้จัดการทุกอย่างเอง ทั้งที่การใช้ Coding Agent ให้ได้ผลดี ควรคิดเหมือนเรากำลังทำงานร่วมกับ Software Engineer อีกคนในทีม
🔷 1. อย่าเริ่มจากสั่งให้เขียน Code ให้เริ่มจากสำรวจ Codebase
ก่อนแก้ Feature หรือ Bug ให้ Claude Code อ่านโครงสร้าง Project และอธิบาย Flow ที่เกี่ยวข้องก่อน เช่น “หาให้หน่อยว่า Authentication Flow เริ่มจากตรงไหน ผ่าน Module อะไรบ้าง และมี Test อยู่ที่ไหน”
วิธีนี้ช่วยให้เราตรวจสอบ Mental Model ของ Agent ก่อนลงมือ เพราะถ้าเข้าใจ Architecture ผิดตั้งแต่ต้น ต่อให้ Code ที่เขียนออกมาดูดี ก็อาจแก้ผิด Layer หรือสร้าง Logic ซ้ำกับของเดิมได้
🔷 2. งานใหญ่ให้ Plan ก่อน Implement
ถ้างานกระทบหลายไฟล์ อย่าเพิ่งสั่งว่า “Implement เลย” แต่ให้วิเคราะห์ Requirement, Files ที่ต้องแก้, Dependency, Edge Case และ Test ที่ควรเพิ่มก่อน โดย Claude Code มี Plan Mode สำหรับวิเคราะห์โดยยังไม่แก้ไฟล์หรือรันคำสั่งที่เปลี่ยนระบบ
▪️ ตัวอย่าง Prompt
“วิเคราะห์ก่อนว่า Feature Rate Limiting ควรเพิ่มตรง Layer ไหน มีไฟล์อะไรได้รับผลกระทบ และควร Test Case อะไรบ้าง ยังไม่ต้องแก้ Code”
เมื่อ Plan สมเหตุสมผลแล้ว ค่อยให้ Implement ทีละส่วน วิธีนี้คล้ายกับการทำ Design Review ก่อน Coding และลดโอกาสที่ Agent จะเปลี่ยน Code เกิน Scope
🔷 3. ใช้ CLAUDE.md เป็น Engineering Handbook ของ Project
แทนที่จะบอก Context เดิมทุก Session ให้เก็บสิ่งที่ Claude ควรรู้ตลอดไว้ใน `CLAUDE.md` เช่น Architecture, Coding Convention, Build Command, Test Command และข้อห้ามสำคัญของ Project ซึ่ง Claude Code สามารถโหลด Project Instructions เหล่านี้มาใช้เป็น Context ได้
ตัวอย่างเช่น
▪️ ใช้ Repository Pattern สำหรับ Database Access
▪️ Business Logic ต้องอยู่ใน Service Layer
▪️ ก่อนจบ Task ต้องรัน Unit Test และ Type Check
▪️ ห้ามแก้ Database Schema โดยไม่ได้รับคำสั่ง
Context ที่ชัดเจนช่วยให้ Agent ทำงานสอดคล้องกับ Engineering Standard ของทีมมากกว่าการหวังให้มันเดา Convention จาก Codebase ทุกครั้ง
🔷 4. อย่าให้ “เขียนเสร็จ” เท่ากับ “งานเสร็จ”
หลัง Implement ให้ Claude Code รัน Test, Lint และ Type Check ที่ Project ใช้งานจริง แล้วให้ตรวจ `git diff` เพื่อหาการเปลี่ยนแปลงที่ไม่เกี่ยวข้องกับ Requirement เพราะ Claude Code สามารถทำงานกับ Test, Shell Command และ Git Workflow ได้โดยตรง
แต่ขั้นสุดท้าย Developer ยังควร Review Diff ด้วยตัวเอง โดยเฉพาะ Authentication, Payment, Permission, Database Migration และส่วนที่เกี่ยวข้องกับ Security
🔷 5. แบ่ง Task ให้เล็กและมี Definition of Done
แทนที่จะสั่ง “สร้างระบบ Login ให้เสร็จ” ลองแบ่งเป็น “เพิ่ม Validation → เขียน Service → เชื่อม API → เพิ่ม Test → รัน Test Suite” แล้วตรวจผลลัพธ์หลังแต่ละช่วง
Claude Code จะมีประโยชน์มากขึ้นเมื่อ Requirement มี Boundary ชัด เพราะเราสามารถรู้ได้ทันทีว่าการเปลี่ยนแปลงไหนเกิดจาก Task ไหน และย้อนกลับได้ง่ายเมื่อ Implementation ไม่เป็นไปตามที่ต้องการ
📌 Key Takeaway
การใช้ Claude Code แบบ Software Engineer ไม่ใช่การหาวิธีให้ AI เขียน Code ให้เยอะที่สุด แต่คือการสร้าง Workflow ที่มี **Context → Plan → Implement → Test → Review**
ให้ AI รับภาระเรื่องการสำรวจ Codebase, Implementation และงานซ้ำ ๆ ส่วนเรายังคุม Architecture, Requirement, Trade-off และคุณภาพของ Code
ถ้าตอนนี้ใช้ Claude Code ด้วยการพิมพ์ Prompt แล้วรอดู Code ลองเปลี่ยนมาใช้ Workflow นี้กับ Task ถัดไป แล้วสังเกตดูว่าจำนวนรอบที่ต้องตามแก้งานลดลงแค่ไหน
ถ้าโพสต์นี้มีประโยชน์ เซฟไว้เป็น Checklist ก่อนเปิด Claude Code ครั้งต่อไป และแชร์ให้ Developer ที่กำลังเริ่มใช้ Coding Agent ได้เลย

ถ้าคุณยังมอง AI เขียนโค้ดเป็นแค่ช่องแชตที่เราส่งโจทย์เข้าไป แล้ว Copy Code กลับมาใช้ คุณอาจกำลังมองความสามารถของ AI Coding ต่ำกว่าที่มันทำได้ในวันนี้
เพราะแนวคิดของ Claude Code จาก Anthropic คือการขยับ AI จาก “ผู้ช่วยตอบคำถามเรื่องโค้ด” มาเป็น Coding Agent ที่สามารถเข้าไปทำงานกับ Codebase และเครื่องมือที่ Developer ใช้อยู่จริงได้
🔷 Claude Code คืออะไร
Claude Code คือ Agentic Coding Tool จาก Anthropic ที่สามารถอ่านและค้นหาโค้ดภายใน Project, แก้ไขไฟล์, Run Command, เขียนและรัน Test รวมถึงทำงานร่วมกับ Git และเครื่องมือใน Development Workflow ได้
พูดง่าย ๆ คือ จากเดิมที่เราถาม AI ว่า “โค้ดส่วนนี้ผิดตรงไหน” แล้วนำคำตอบไปแก้เอง เราสามารถบอก Claude Code ว่า “หา Bug ที่ทำให้ Login ล้มเหลว แก้ให้ และรัน Test ตรวจสอบด้วย” แล้วให้มันเข้าไปสำรวจ Codebase และลงมือทำงานตามโจทย์
🔷 ไม่ได้ใช้งานได้แค่ใน Terminal
Claude Code เริ่มต้นจากการทำงานใกล้ชิดกับ Terminal แต่ปัจจุบัน Anthropic ขยายช่องทางใช้งานไปทั้ง IDE, Desktop, Web, Mobile, GitHub และช่องทางอื่น ๆ ทำให้ Workflow ไม่ได้จำกัดอยู่กับการนั่งพิมพ์ Command หน้าเครื่องอย่างเดียว
ที่น่าสนใจคือ Cloud Sessions สามารถรับงานจาก Browser แล้วนำไปทำงานบน Cloud Environment แยกออกจากกันได้ เช่น เปิด Session หนึ่งให้แก้ Bug อีก Session ให้เพิ่ม Test และอีก Session ให้จัดการ Backend Change พร้อมกัน
🔷 แล้วต่างจากการถาม AI เขียน Code ปกติอย่างไร
▪️ Chat แบบเดิม
เราให้ Context → AI สร้าง Code → เรานำ Code ไปใส่ Project → Run → เจอ Error → กลับมาถามใหม่
▪️ Agentic Coding
เราให้เป้าหมาย → Agent สำรวจ Project → อ่านไฟล์ที่เกี่ยวข้อง → แก้ Code → Run Test หรือ Command → ตรวจผล → ปรับงานต่อ
ความต่างสำคัญจึงไม่ใช่แค่ว่า “ใครเขียน Code เก่งกว่า” แต่คือ AI สามารถเข้าไปอยู่ใน Development Workflow และจัดการงานหลายขั้นตอนได้มากขึ้น
🔷 ตัวอย่างงานที่เหมาะ
สมมติ Project มี API หลายสิบไฟล์ และ Test ตัวหนึ่ง Fail แทนที่จะ Copy Error มาถามทีละรอบ เราสามารถให้ Claude Code ไล่หาต้นเหตุจาก Codebase, ตรวจไฟล์ที่เกี่ยวข้อง, แก้ Implementation และ Run Test เพื่อยืนยันผลได้
นอกจาก Debug แล้ว Anthropic ยังวาง Claude Code สำหรับงานอย่าง Feature Implementation, Refactoring และ Testing รวมถึงสามารถเชื่อมต่อเครื่องมือผ่าน CLI และ MCP เพื่อขยายสิ่งที่ Agent เข้าถึงและทำงานร่วมด้วยได้
🔷 สิ่งที่ Developer ควรเข้าใจก่อนใช้
Claude Code ไม่ได้แปลว่าเราควรปล่อย AI แก้ Production Code โดยไม่ตรวจ เพราะเมื่อ Agent สามารถอ่านไฟล์ แก้ Code และ Run Command ได้ ความสามารถที่เพิ่มขึ้นก็มาพร้อมกับสิทธิ์การเข้าถึงที่ต้องจัดการให้เหมาะสม
ดังนั้น Workflow ที่ดีคือกำหนด Scope ให้ชัด ตรวจ Diff, Review Code, Run Test และใช้ Version Control เป็น Safety Net เหมือนที่เราทำกับ Code จาก Developer คนอื่นในทีม
📌 Key Takeaway
Claude Code ทำให้การใช้ AI เขียนโปรแกรมเปลี่ยนจาก “ถามแล้ว Copy Code” ไปสู่ “มอบหมายงานแล้วให้ Agent ทำงานกับ Codebase” ซึ่งเป็นการเปลี่ยนวิธีคิดจาก AI Coding Assistant ไปสู่ Agentic Software Development
สำหรับ Developer คำถามที่น่าสนใจต่อจากนี้จึงอาจไม่ใช่แค่ “AI เขียน Code ได้ดีแค่ไหน” แต่เป็น “เราจะออกแบบ Workflow ให้คนกับ Coding Agent ทำงานร่วมกันอย่างไรให้เร็วและยังควบคุมคุณภาพได้”

Tool ที่ Developer ใช้ง่าย อาจเป็น Tool ที่ AI ใช้ยากก็ได้
เวลาสร้าง API เรามักคิดถึง Developer Experience ว่าชื่อ endpoint เข้าใจง่ายไหม parameter ชัดหรือเปล่า และ documentation ดีแค่ไหน แต่พอ API นั้นถูกเปิดให้ AI Agent เรียกผ่าน Tool use หรือ MCP ผู้ใช้งานคนแรกกลับไม่ใช่มนุษย์ แต่คือ “โมเดล”
🔷 Tool ที่ดีต้องสื่อสารกับโมเดลได้ดี
เวลาโมเดลจะเรียก Tool มันไม่ได้เข้าใจระบบของเราเหมือน Developer ที่อ่าน README มาทั้งหน้า แต่มันต้องตัดสินใจจากข้อมูลอย่างชื่อ Tool, description และ input schema ว่า Tool ไหนเหมาะกับงาน และควรส่ง argument อะไรเข้าไป
เพราะฉะนั้น `search`, `get`, `execute` อาจเป็นชื่อที่สั้นและดูสะอาดสำหรับเรา แต่สำหรับโมเดลมันแทบไม่ได้บอกเลยว่า “ควรเรียกฉันเมื่อไหร่”
▪️ ชื่อ Tool ต้องบอก Intent
ลองเทียบ `search` กับ `search_customer_orders` แบบหลังอาจยาวกว่า แต่ลดพื้นที่ในการตีความ เพราะโมเดลเห็นแล้วพอเดาได้ทันทีว่า Tool นี้ใช้ค้นหาอะไร
หลักคิดง่าย ๆ คือ อย่าตั้งชื่อเพียงเพื่อให้คนเขียนโค้ดสะดวก แต่ตั้งชื่อเพื่อช่วยให้โมเดล “เลือก Tool ถูกตัว”
▪️ Description ต้องช่วยตัดสินใจ ไม่ใช่แค่อธิบาย
`Search orders` ยังไม่ค่อยช่วยเท่าไร เพราะโมเดลยังไม่รู้ว่าค้นจากอะไรและควรใช้ตอนไหน
Description ที่ดีควรบอกว่า Tool ทำอะไร เหมาะกับสถานการณ์ไหน รับข้อมูลอะไร และมีข้อจำกัดสำคัญอะไร เช่น “Search customer orders by order ID, email, or date range ใช้เมื่อต้องการค้นหา order ที่มีอยู่แล้ว ไม่ใช้สำหรับสร้าง order ใหม่”
นี่เหมือนติดป้ายหน้าประตูให้ชัดว่า ห้องนี้คืออะไร ใครควรเข้า และไม่ควรเข้ามาทำอะไร
▪️ Input Schema ต้องลดการเดา
ถ้า Tool รับ parameter อย่าง `type`, `value`, `mode`, `data` เยอะ ๆ โมเดลต้องเดาความหมายจากบริบท และยิ่งมี Tool หลายตัว ความคลุมเครือก็ยิ่งสะสม
แทนที่จะใช้ `date: string` ถ้าระบบต้องการวันที่รูปแบบ `YYYY-MM-DD` ก็ควรกำหนดให้ชัด รวมถึง enum, required field, default behavior และข้อจำกัดต่าง ๆ เพราะ schema ไม่ได้มีไว้ validate input อย่างเดียว แต่มันคือส่วนหนึ่งของ interface ระหว่างระบบกับโมเดล
▪️ Output ก็ต้องออกแบบให้โมเดลใช้ต่อได้
Tool ที่คืน text ก้อนใหญ่ทุกครั้งอาจอ่านง่ายสำหรับคน แต่ Agent อาจต้องเสีย context เพิ่มเพื่อแกะข้อมูลที่ต้องการออกมา
ถ้าข้อมูลมีโครงสร้างชัด การคืน structured output จะช่วยให้ระบบนำผลลัพธ์ไปใช้ต่อได้ตรงกว่า และใน MCP เองก็รองรับ structured content และ output schema สำหรับกรณีลักษณะนี้
🔷 MCP ไม่ได้ทำให้ Tool ดีขึ้นโดยอัตโนมัติ
MCP ช่วยสร้างมาตรฐานให้ AI Client เชื่อมต่อกับ Tools, Resources และระบบภายนอกได้เป็นรูปแบบเดียวกัน แต่คุณภาพของ Tool ยังขึ้นอยู่กับคนออกแบบ
ถ้าเราเอา API เดิมมา wrap เป็น MCP Tool โดยไม่คิดเรื่อง Tool selection, description, schema และ output ใหม่ เราอาจได้ระบบที่ “เชื่อมต่อได้” แต่โมเดลยังเรียกผิด ส่ง parameter ผิด หรือไม่รู้ว่าควรใช้ Tool ไหนอยู่ดี
📌 Key Takeaway
เวลาออกแบบ Tool สำหรับ AI อย่าถามแค่ว่า “Developer จะเรียก API นี้ง่ายไหม” แต่ให้ถามเพิ่มว่า “ถ้าโมเดลเห็นแค่ชื่อ description และ schema มันจะรู้ไหมว่าควรเรียก Tool นี้เมื่อไหร่ ต้องส่งอะไร และจะเอาผลลัพธ์ไปทำอะไรต่อ”
เพราะในโลกของ Agentic AI การออกแบบ Tool ก็คือการออกแบบ UX ให้โมเดล
ถ้าคุณกำลังทำ AI Agent หรือ MCP Server ลองเปิด Tool definitions ของตัวเองดู แล้วถามว่า ถ้าตัด documentation และความรู้เกี่ยวกับระบบทั้งหมดออก เหลือแค่สิ่งที่โมเดลเห็น มันยังเข้าใจ Tool ของคุณอยู่หรือเปล่า

ถ้าคุณเขียนโปรแกรม คุณคงไม่กล้าแก้โค้ดแล้ว Deploy ขึ้น Production โดยไม่รัน Test
แต่แปลกตรงที่พอเป็น AI หลายทีมกลับแก้ Prompt เปลี่ยน Model เพิ่ม Tool แล้วตัดสินจากการลองถามไม่กี่ครั้งว่า “ดูดีขึ้นนะ น่าจะใช้ได้”
นี่คือเหตุผลว่าทำไมเราต้องมี Evals
🔷 Evals คือ Unit Test ของยุค AI
ในโลก Software เรามี Unit Test เพื่อเช็กว่า เมื่อให้ Input แบบนี้ Function ควรให้ Output แบบไหน และเมื่อเราแก้ Code แล้ว Behavior เดิมที่ควรทำงานยังทำงานอยู่หรือไม่
โลกของ AI ก็ต้องการสิ่งเดียวกัน เพียงแต่ปัญหาคือ Output ของ AI ไม่ได้เป็น Deterministic แบบ Function ทั่วไป เพราะถามคำถามคล้ายกัน โมเดลอาจตอบต่างกันได้
ดังนั้น Evals หรือ Evaluations จึงเป็นชุดการทดสอบที่ช่วยตอบคำถามว่า “ระบบ AI ของเราทำงานได้ดีตามเกณฑ์ที่ต้องการจริงหรือเปล่า”
🔷 ตัวอย่างง่าย ๆ
สมมติเราสร้าง AI สำหรับตอบคำถามลูกค้า และกำหนดว่ามันต้องทำ 3 อย่างให้ได้
▪️ ตอบข้อมูลสินค้าถูกต้อง
▪️ ไม่แต่งข้อมูลที่ไม่มีอยู่จริง
▪️ ถ้าไม่รู้คำตอบ ต้องบอกว่าไม่รู้และส่งต่อให้เจ้าหน้าที่
แทนที่จะลองถาม 5 คำถามแล้วบอกว่า “โอเค ใช้ได้” เราสามารถสร้าง Test Cases 100 เคสจากสถานการณ์จริง แล้วกำหนดเกณฑ์ว่าแต่ละคำตอบควรมีพฤติกรรมแบบไหน
จากนั้นทุกครั้งที่เราเปลี่ยน Prompt เปลี่ยน Model เพิ่ม RAG หรือแก้ Workflow เราก็รัน Evals ชุดเดิมอีกครั้ง
ถ้าคะแนนจาก 92% ลดเหลือ 76% เราจะรู้ทันทีว่า สิ่งที่คิดว่าเป็น Improvement อาจสร้าง Regression ในจุดอื่นขึ้นมาแล้ว
🔷 แล้วใครเป็นคนตรวจคำตอบของ AI
นี่เป็นส่วนที่ต่างจาก Unit Test แบบดั้งเดิม เพราะคำตอบของ AI หลายอย่างไม่มีคำตอบเดียวที่ถูกต้อง
เราจึงเลือกวิธีตรวจให้เหมาะกับงานได้ เช่น
▪️ Exact Match ใช้กับคำตอบที่ต้องตรงเป๊ะ เช่น Classification หรือ JSON field
▪️ Rule-based Grader ตรวจเงื่อนไข เช่น ต้องมีข้อมูลบางอย่าง หรือห้ามมีข้อมูลบางอย่าง
▪️ LLM-as-a-Judge ให้โมเดลอีกตัวประเมินตาม Rubric ที่กำหนด
▪️ Human Evaluation ให้คนตรวจในงานที่ต้องใช้ Context หรือ Judgment สูง
และในระบบจริง มักไม่ได้เลือกแค่วิธีเดียว แต่ผสมหลายแบบเข้าด้วยกัน
🔷 Evals ที่ดีไม่ได้เริ่มจาก “จะวัด AI ยังไง”
แต่มันเริ่มจากคำถามที่สำคัญกว่านั้นว่า
“สำหรับ Product ของเรา คำว่า AI ทำงานได้ดี หมายความว่าอะไร”
เพราะถ้าเรายังตอบคำถามนี้ไม่ได้ ต่อให้เปลี่ยนจาก GPT เป็น Claude หรือเปลี่ยน Prompt อีก 20 รอบ เราก็ยังไม่รู้จริง ๆ ว่าระบบดีขึ้นหรือแค่ “รู้สึกว่าดีขึ้น”
📌 Key Takeaway
การสร้าง AI Application ที่ Reliable ไม่ควรจบแค่ Prompt Engineering แต่ต้องมี Evaluation Engineering ควบคู่กันไป
ถ้า Unit Test ช่วยให้เรามั่นใจว่า Code ยังทำงานตามที่ออกแบบไว้ Evals ก็ช่วยให้เรามั่นใจว่า AI ยังมี Behavior ตามที่ Product ต้องการ
ก่อนแก้ Prompt หรือเปลี่ยน Model ครั้งต่อไป ลองอย่าเพิ่งถามว่า “ตัวไหนตอบดีกว่า”
ลองถามก่อนว่า “เรามี Test ที่พิสูจน์เรื่องนั้นแล้วหรือยัง”
ถ้าคุณกำลังสร้าง AI Product หรือ AI Agent ลองเริ่มง่าย ๆ ด้วยการเก็บ 20 เคสจริงที่ระบบของคุณต้องทำให้ดี แล้วเปลี่ยนมันให้กลายเป็น Eval Dataset ชุดแรกของคุณ

ถ้าคุณใช้ AI แล้วรู้สึกว่า “ต้องเขียน Prompt ให้เก่งกว่านี้ คำตอบถึงจะดีขึ้น” ปัญหาอาจไม่ได้อยู่ที่ Prompt ตั้งแต่แรก
เพราะต่อให้เขียน Prompt ละเอียดแค่ไหน ถ้า AI ไม่มีข้อมูลที่ควรรู้ ไม่เห็นบริบทของงาน หรือได้รับข้อมูลที่ไม่เกี่ยวข้องเยอะเกินไป คำตอบที่ได้ก็อาจยังไม่ดีอยู่ดี
🔷 Prompt Engineering กับ Context Engineering ต่างกันอย่างไร
Prompt Engineering คือการออกแบบ “คำสั่ง” ว่าเราต้องการให้ AI ทำอะไร เช่น กำหนด Role, Task, Constraints, Examples และ Output Format เพื่อช่วยให้โมเดลเข้าใจสิ่งที่เราต้องการได้ชัดเจนขึ้น
ส่วน Context Engineering มองกว้างกว่านั้น เพราะไม่ได้ถามแค่ว่า “เราควรสั่ง AI อย่างไร” แต่ถามว่า “AI ควรได้รับข้อมูลอะไรบ้าง ก่อนที่จะเริ่มทำงาน”
▪️ Prompt Engineering = สั่งอะไร และสั่งอย่างไร
▪️ Context Engineering = ก่อนทำงาน AI ควรรู้อะไร เห็นอะไร จำอะไร และเข้าถึงอะไรได้บ้าง
ลองนึกภาพว่าเราจ้าง Developer คนหนึ่งมาแก้ Bug ในระบบ แล้วบอกว่า “วิเคราะห์สาเหตุของ Bug นี้ให้ละเอียด พร้อมเสนอวิธีแก้ที่ปลอดภัยและกระทบระบบน้อยที่สุด”
Prompt นี้ถือว่าชัด แต่ถ้า Developer คนนั้นไม่เห็น Source Code, Error Log, Stack Trace, Architecture และประวัติการแก้ไขล่าสุด ต่อให้คำสั่งดีแค่ไหน เขาก็ทำได้แค่คาดเดา
AI ก็ไม่ต่างกัน
🔷 Context ที่ดีประกอบด้วยอะไรบ้าง
สำหรับงานทั่วไป Context อาจเป็นข้อมูลเกี่ยวกับเป้าหมาย กลุ่มเป้าหมาย ตัวอย่างงานเดิม ข้อจำกัด และสิ่งที่เคยคุยกันก่อนหน้า
แต่สำหรับระบบ AI หรือ AI Agent จริง ๆ Context อาจรวมถึง System Instructions, Conversation History, Memory, Documents จาก RAG, ผลลัพธ์จาก Search หรือ API รวมถึง Tools ที่ AI สามารถเรียกใช้ได้
ประเด็นสำคัญจึงไม่ใช่ “ใส่ข้อมูลให้เยอะที่สุด” แต่คือ “ใส่ข้อมูลที่จำเป็นในเวลาที่เหมาะสม”
เพราะ Context Window มีขีดจำกัด และการโยนข้อมูลทุกอย่างเข้าไปไม่ได้แปลว่า AI จะฉลาดขึ้นเสมอไป ข้อมูลที่เก่า ซ้ำ หรือไม่เกี่ยวข้องสามารถรบกวนสิ่งที่โมเดลควรให้ความสำคัญได้
🔷 แล้วทำไม Context Engineering ถึงสำคัญขึ้น
เมื่อเราใช้ AI แบบถามหนึ่งคำถามแล้วจบ Prompt Engineering อาจเพียงพอในหลายกรณี แต่เมื่อ AI เริ่มทำงานแบบหลายขั้นตอน ใช้ Tools ค้นข้อมูล อ่านเอกสาร เรียก API และทำงานต่อเนื่องแบบ Agent ปัญหาจะเปลี่ยนจาก “เขียนคำสั่งอย่างไร” เป็น “แต่ละขั้นตอนควรส่งข้อมูลอะไรให้โมเดล”
นี่คือเหตุผลที่ Developer ต้องเริ่มคิดเรื่อง Retrieval, Memory, Tool Design, Context Selection, Trimming และ Summarization ควบคู่ไปกับ Prompt
Prompt ที่ดีช่วยให้ AI เข้าใจ “งานที่ต้องทำ”
แต่ Context ที่ดีช่วยให้ AI มี “ข้อมูลที่จำเป็นสำหรับทำงานนั้น”
📌 Key Takeaway
Prompt Engineering ไม่ได้หมดความสำคัญ แต่ควรมองว่าเป็นส่วนหนึ่งของภาพที่ใหญ่กว่า
ถ้าต้องการให้ AI ทำงานได้ดีและสม่ำเสมอ อย่าถามแค่ว่า “Prompt นี้เขียนดีพอหรือยัง” แต่ให้ถามเพิ่มว่า “ตอนที่ AI ต้องตอบ มันมีข้อมูลที่ถูกต้องและจำเป็นอยู่ตรงหน้าหรือยัง”
บางครั้งการแก้ Context ให้ถูกจุด อาจมีประโยชน์กว่าการนั่งแก้ Prompt เดิมอีกสิบรอบ
ถ้าคุณกำลังสร้าง AI Workflow, RAG หรือ AI Agent ลองกลับไปดูระบบของตัวเองว่า วันนี้คุณกำลังทำแค่ Prompt Engineering หรือเริ่มออกแบบ Context Engineering แล้ว