Claude Agent Team: อย่าให้ AI ตัวเดียวเขียน รีวิว และ Deploy เอง

มี X Article ของ Hanako ที่กำลังถูกแชร์เยอะในสาย Claude Code และ AI coding agent

หัวข้อคือ “How to Build a Claude Agent Team: One Writes Code, One Reviews, One Deploys”

แกนของบทความเรียบง่ายมากครับ

อย่าใช้ Claude session เดียวให้ทำทุกอย่าง

ให้แยกเป็น 3 agent:

1. Writer: เขียน code หรือแก้งาน
2. Reviewer: อ่าน diff แล้วหาปัญหา
3. Deployer: deploy เฉพาะงานที่ผ่าน review แล้ว

ถ้ามองแบบ developer นี่คือ workflow ของ coding agent

แต่ถ้ามองแบบเจ้าของธุรกิจ นี่คือหลักการที่ใหญ่กว่านั้นมาก

มันคือ separation of duties สำหรับ AI

หรือพูดให้ตรงที่สุด:

อย่าให้ AI ตรวจงานตัวเอง

ทำไม agent ตัวเดียวถึงไม่พอ

คนหนึ่งคนเขียน code เอง review PR ตัวเอง แล้วกด deploy เองตอนตีสาม

ผู้จัดการ engineering ทุกคนรู้ว่ามีความเสี่ยง

ไม่ใช่เพราะคนนั้นไม่เก่ง

แต่เพราะคนที่สร้างงานมักมองไม่เห็น blind spot ของงานตัวเอง

AI ก็มีปัญหาเดียวกันครับ

ถ้า agent ตัวเดียวรับ task, เขียน code, แก้ bug, รัน test, สรุปผล, แล้วบอกว่าเสร็จ มันมีแรงจูงใจทางโครงสร้างให้ปิดงาน

มันรู้ context ของสิ่งที่มันทำมากเกินไป มันจำเหตุผลของตัวเองได้ มันอาจ defend solution เดิมโดยไม่รู้ตัว มันอาจตรวจแบบผ่าน ๆ เพราะเชื่อว่างานที่ทำมาถูกแล้ว

นี่ไม่ได้แปลว่า AI ไม่ควรตรวจงาน

แต่แปลว่า review ที่ดีควรมาจาก context ที่แยกออกมา

Reviewer ควรเห็น diff, requirement, test result และ risk checklist

ไม่ใช่เห็นเส้นทางความคิดทั้งหมดของ Writer แล้วเผลอเห็นด้วยไปกับมัน

นี่คือเหตุผลที่ writer/reviewer/deployer pattern น่าสนใจ

มันไม่ได้เริ่มจากคำถามว่า “จะเพิ่ม agent กี่ตัว”

มันเริ่มจากคำถามว่า “งานนี้ต้องแยกหน้าที่อะไรบ้าง”

Writer: คนสร้างงาน ไม่ใช่คนอนุมัติ

Writer agent มีหน้าที่ชัดมาก

ทำ implementation ทำตาม pattern ของ codebase ไม่ refactor สิ่งที่ไม่เกี่ยว ไม่ review งานตัวเอง ไม่ประกาศว่างานพร้อม deploy เอง

สำหรับงาน code นี่แปลตรงตัว

แต่สำหรับงานธุรกิจทั่วไป Writer อาจเป็น agent ที่ร่างโพสต์, ร่างอีเมล, สรุปรายงาน, ทำ proposal, หรือเตรียมคำตอบลูกค้า

สิ่งที่สำคัญคือ Writer ไม่ควรถูกออกแบบให้เป็น judge ของงานตัวเอง

ถ้ามันร่างข้อความขายคอร์ส มันไม่ควรเป็นคนตัดสินเองว่า claim ปลอดภัยไหม

ถ้ามันวิเคราะห์ยอดขาย มันไม่ควรเป็นคนยืนยันเองว่า metric ถูกต้องไหม

ถ้ามันแก้ workflow ใน CRM มันไม่ควรเป็นคนบอกเองว่า deploy ได้

Writer ควรสร้าง artifact ที่คนอื่นตรวจต่อได้

เช่น diff, draft, report, checklist, JSON output, summary พร้อม source, หรือไฟล์ที่ระบุว่าเปลี่ยนอะไรบ้าง

สำหรับ Data-Espresso ผมจะเรียกสิ่งนี้ว่า proof artifact

AI ไม่ควรจบงานด้วยประโยคว่า “เสร็จแล้วครับ”

ควรจบด้วยหลักฐานว่าเสร็จอย่างไร

Reviewer: คนหาจุดผิด ต้องมีสิทธิ์จำกัด

Reviewer agent ไม่ใช่ Writer ตัวที่สอง

Reviewer มีหน้าที่หาปัญหา

อ่าน diff อ่าน requirement เช็ค edge cases เช็ค security เช็ค policy เช็คว่า output ตรงกับ source หรือไม่ เช็คว่ามีอะไรถูกแต่งขึ้นหรือเปล่า

ใน X Article ต้นทาง Reviewer ถูกกำหนดให้ “finds bugs, never fixes them”

ผมชอบหลักนี้มาก

เพราะถ้า reviewer แก้เองทันที มันเริ่มกลายเป็น writer อีกตัว และ loop จะเริ่มเบลอ

ในช่วงแรกของการทำ AI agent team ให้ธุรกิจ ผมแนะนำให้ Reviewer เป็น read-only ก่อน

ให้มันเขียน report ให้มันบอก line number ให้มันบอก severity ให้มันบอกว่า approve หรือ reject แต่ยังไม่ให้มันแตะ action สำคัญ

ถ้าต้องแก้ ให้ feedback กลับไปที่ Writer

นี่ทำให้เรามองเห็น handoff

และที่สำคัญ ทำให้มนุษย์ audit ได้ว่า AI ปฏิเสธงานเพราะอะไร หรือ approve เพราะอะไร

Deployer: คน ship ต้อง conservative ที่สุด

Deployer agent ควรเป็น agent ที่น่าเบื่อที่สุดในระบบ

และนั่นคือเรื่องดี

หน้าที่ของมันไม่ใช่สร้างของใหม่ ไม่ใช่เถียงกับ reviewer ไม่ใช่ปรับ code เพิ่มเองตอนก่อน deploy

หน้าที่คือ ship เฉพาะสิ่งที่ผ่าน gate แล้ว

สำหรับ code คือ:

• เห็น approval จาก reviewer
• รัน test suite
• ถ้า test fail ให้หยุด
• สร้าง deployment summary
• ระบุว่าเปลี่ยนอะไร ทดสอบอะไร deploy อะไร และต้อง monitor อะไรต่อ

สำหรับงานธุรกิจ Deployer อาจแปลเป็น Publisher หรือ Operator

เช่น:

• publish draft หลัง editor approve
• ส่ง LINE broadcast หลัง owner approve
• อัปเดต CRM หลังข้อมูลผ่าน validation
• สร้าง invoice draft แต่ยังไม่ส่งจนกว่าคน approve
• เปิด campaign แบบ paused ไม่ใช่ live ทันที

หลักคือ agent ที่ใกล้ production ต้อง conservative กว่า agent ที่อยู่ใน draft layer

ยิ่ง action กระทบเงิน ลูกค้า ข้อมูลส่วนตัว หรือ public brand มากเท่าไร ยิ่งต้องมี approval gate ชัดเท่านั้น

Claude Code docs ยืนยัน primitive นี้แล้ว

ถ้าอ่านเอกสาร Claude Code จะเห็นว่า pattern นี้ไม่ได้เป็นแค่ meme บน X

Claude Code มี subagents ที่รันใน context window แยกกัน พร้อม system prompt, tool access และ permission ของตัวเอง

เอกสาร Agent SDK อธิบายว่า subagents ใช้เพื่อแยก context, รันงานพร้อมกัน, ใช้ instruction เฉพาะทาง และจำกัด tool access ได้

ตัวอย่างที่เอกสารยกมาเองก็คล้าย pattern นี้มาก เช่น code-reviewer, test-runner, style-checker, security-scanner และ test-coverage subagents

เอกสาร dynamic workflows ไปไกลกว่านั้น

มันบอกว่า workflow คือ JavaScript orchestration script ที่คุมการ spawn subagents, branching, loop, intermediate results และ final synthesis

ความต่างสำคัญคือ แผนไม่ได้อยู่ในหัวของ chat ยาว ๆ อย่างเดียว

แผนถูกย้ายไปอยู่ใน script ที่อ่านได้ รันซ้ำได้ และควบคุมได้

ส่วน Claude Code Review ก็ใช้ multiple specialized agents ตรวจ PR diff แล้วมี verification step เพื่อลด false positives ก่อนโพสต์ inline comment

แปลเป็นภาษาธุรกิจ:

Claude ecosystem กำลังบอกเราว่า agent ที่ดีไม่ได้อยู่ที่ prompt อย่างเดียว

แต่อยู่ที่โครงสร้างรอบ agent

ใครได้ context อะไร ใครใช้ tool อะไรได้ ใครทำงานพร้อมกันได้ ใครตรวจใคร ใครมีสิทธิ์ลงมือจริง และ proof อยู่ตรงไหน

Boris Cherny เป็น proof ของทิศทาง ไม่ใช่สูตรสำเร็จที่ต้อง copy

ในหลายบทสัมภาษณ์ Boris Cherny ผู้สร้างและหัวหน้า Claude Code พูดชัดว่า workflow ของเขาเปลี่ยนจากการเขียน code เอง ไปเป็นการ prompt Claude และล่าสุดไปสู่การเขียน loop ที่ prompt Claude อีกที

บางสรุประบุว่าเขารัน Claude หลาย instance พร้อมกันจากโทรศัพท์ และมี agent จำนวนมากทำงานเบื้องหลัง

ประเด็นที่ผมอยากให้จับ ไม่ใช่ตัวเลข

ไม่ใช่ว่า SME ไทยต้องไปรัน agent หลักร้อยตัวพรุ่งนี้

ประเด็นคือ role ของมนุษย์กำลังเปลี่ยน

จากคนทำงานทุกบรรทัด เป็นคนออกแบบระบบงาน จากคนคอยกดทุกขั้น เป็นคนกำหนด rule, gate, review, budget และ proof จากคนถาม AI เป็นครั้ง ๆ เป็น manager ของ AI coworker หลายบทบาท

นี่คือจุดที่ผมคิดว่า OPB Stack และ Business OS สำคัญ

เพราะถ้าธุรกิจไม่มี workspace, memory, tool scope, approval gate และ log proof การเพิ่ม agent จะกลายเป็นความวุ่นวายที่เร็วขึ้นเท่านั้น

ใช้กับ SME อย่างไร

อย่าเริ่มจาก agent team สิบตัว

เริ่มจากหนึ่ง workflow ที่เกิดซ้ำและมีความเสี่ยงพอให้ต้องตรวจ

ตัวอย่างที่เหมาะ:

1. Content workflow

Writer ร่างบทความหรือโพสต์ Reviewer ตรวจ claim, tone, source, forbidden promises Publisher เตรียม draft พร้อมรูปและ meta แต่รอ owner approve ก่อน publish

2. Customer support workflow

Writer ร่างคำตอบลูกค้า Reviewer ตรวจ policy, product facts, refund rule, privacy risk Operator ส่งให้คน approve หรือส่งเฉพาะกรณี low-risk ที่กำหนดไว้แล้ว

3. Sales admin workflow

Writer สรุป lead และความต้องการ Reviewer ตรวจว่า quote ตรง package จริงไหม Operator สร้าง proposal draft หรือ CRM update พร้อม proof

4. Data report workflow

Analyst agent ทำ analysis Reviewer ตรวจ metric definition และ source file Reporter ทำ executive summary พร้อม caveat และ chart

5. Code workflow

Writer แก้ issue Reviewer ตรวจ diff, security, edge cases Deployer รัน test, build, smoke check และ deploy เฉพาะที่ผ่าน gate

ทุก workflow ควรตอบคำถาม 7 ข้อนี้ก่อน:

1. Input มาจากไหน
2. Source of truth คืออะไร
3. Agent ไหนสร้างงาน
4. Agent ไหนตรวจงาน
5. Agent ไหนมีสิทธิ์ลงมือจริง
6. Action ไหนต้องถามมนุษย์
7. Proof สุดท้ายคืออะไร

ถ้าตอบไม่ได้ อย่าเพิ่งเพิ่ม agent

หลุมพราง: agent เยอะไม่ได้แปลว่าปลอดภัยขึ้น

นี่คือจุดที่ต้องพูดตรง ๆ

AI agent team ที่ออกแบบไม่ดี อาจแย่กว่า agent ตัวเดียว

เพราะมันทำพลาดพร้อมกันได้เร็วกว่า

หลุมพรางที่เจอบ่อย:

• ทุก agent ใช้ context เดียวกันหมด เลย bias เหมือนกัน
• Reviewer มีสิทธิ์ write/deploy เหมือน Writer
• Deployer แก้เพิ่มเองก่อน ship
• ไม่มี artifact กลางให้ audit
• ไม่มี stop condition
• ไม่มี budget control
• ไม่มี human approval ใน action เสี่ยง
• ทุกอย่างคุยกันใน chat ยาว ๆ แต่ไม่มี state ที่ตรวจย้อนหลังได้

ถ้าจะทำให้ดี ต้องเริ่มจาก boundary

Reviewer ควรอ่านได้มากกว่าเขียน Deployer ควร act ได้เฉพาะหลังผ่าน gate Writer ควรถูกจำกัดไม่ให้ยุ่งกับสิ่งนอก scope และมนุษย์ต้องเห็น proof ก่อนเชื่อคำว่า done

จาก Prompt ไปสู่ Operating System

ผมคิดว่า pattern นี้สรุปการเปลี่ยนผ่านของ AI Agent ได้ดีมาก

ยุคแรก เราแข่งกันเขียน prompt ให้ดี

ยุคถัดมา เราเริ่มเขียน CLAUDE.md, Skills, hooks, subagents, workflows, cron, review rules และ approval gates

พูดง่าย ๆ คือเราไม่ได้แค่คุยกับ AI

เรากำลังสร้างระบบปฏิบัติการเล็ก ๆ ให้ AI ทำงานในนั้น

สำหรับธุรกิจไทย นี่คือมุมที่สำคัญกว่า headline เรื่อง agent หลักร้อยตัวมาก

คุณไม่ต้องมี agent เยอะที่สุด

คุณต้องมี workflow ที่ปลอดภัยที่สุดพอจะให้ AI ทำงานจริง

มี context พอ มีหน้าที่ชัด มี reviewer แยก มี approval gate มี deploy proof มี log ให้ย้อนดู มีมนุษย์ถือ judgment

AI Agent Team ที่ดีจึงไม่ใช่การทำให้มนุษย์หายไป

แต่มันทำให้มนุษย์เลิกเป็นคอขวดในทุกขั้นเล็ก ๆ และกลับไปอยู่ในตำแหน่งที่ควรอยู่:

กำหนดเป้าหมาย กำหนดขอบเขต ตัดสินความเสี่ยง และอนุมัติสิ่งที่กระทบของจริง

ถ้าจะเริ่มใช้ pattern นี้ในทีม ผมแนะนำให้เริ่มเล็กมาก

เลือก workflow เดียว แยก Writer และ Reviewer ก่อน ยังไม่ต้อง auto deploy ให้ทุกอย่างเขียนลงไฟล์ ให้ proof อ่านได้ ให้คน approve แล้วค่อยเพิ่ม Deployer ตอนที่ review gate น่าเชื่อถือแล้ว

AI ตัวเดียวอาจทำงานเร็ว

แต่ AI team ที่ออกแบบดี จะทำงานแบบมีหลักฐานและมีความรับผิดชอบมากกว่า