สร้างแพลตฟอร์มสตรีมมิงและธนาคารไปพร้อมกัน — จัดวางกองเอเจนต์ AI ให้ลงมือพัฒนาฟีเจอร์จริง แล้วปรับจูนการแบ่งงานด้วยการวัดผล

บทนำ

ผมสร้างสองระบบไปพร้อมกันด้วยตัวคนเดียว ระบบหนึ่งคือแพลตฟอร์มรวมบริการที่มัดวิดีโอและเพลงเข้าด้วยกัน อีกระบบคือระบบธนาคารที่สร้างเองซึ่งใช้สำหรับการชำระเงินของมัน เพื่อผลักดันทั้งสองไปข้างหน้าพร้อมกัน ผมไม่ได้ขอให้ AI ตัวเดียวทำทุกอย่าง ผมประกอบกองเอเจนต์ย่อย (fleet) ที่แบ่งตามบทบาท — ผู้ลงมือทำ ผู้ตรวจสอบ ผู้ประสานงาน — แล้วรันงานฟีเจอร์จริงผ่านมัน

ความต่างระหว่าง AI ในฐานะ “เพื่อนคู่คิด” กับ AI ในฐานะ “เอเจนต์” เขียนไว้ใน ฉันใช้ GitHub Copilot เป็นเวลาหนึ่งเดือน และใช้ Claude Code เป็นเวลาสองวัน พาร์ทเนอร์และเจ้าหน้าที่เขียนโค้ดเป็นสองสิ่งที่แตกต่างกัน บทความนี้ไปอีกขั้น — เลิกใช้เอเจนต์เป็นผู้เล่นรอบด้านตัวเดียว จัดวางมันเป็น “กอง” แล้วปรับจูนผ่านการพัฒนาจริง — บันทึกของการออกแบบและการวัดผล

เมื่อเอเจนต์ตัวเดียวทำทุกอย่าง อะไรพัง

ให้เอเจนต์ตัวหนึ่งเขียนโค้ด แล้วขอให้เอเจนต์ตัวเดิมนั้น “ตรวจสอบ” ดูเรียบง่าย แต่อ่อนแอ: มันสงสัยโค้ดของตัวเองไม่ได้ (ถูกลากด้วยบริบทที่เพิ่งเขียน) บริบทของมันสกปรก และความสามารถกับต้นทุนก็ไม่สมดุล คำตอบไม่ใช่ “ตัวเดียวที่ฉลาดกว่า” แต่เป็นหลายตัวที่แบ่งตามบทบาท

[ตัวเดียวทำทุกอย่าง]
  เอเจนต์ตัวเดียว ─▶ ทั้งลงมือ ตรวจสอบ ค้นคว้า ทั้งหมด
        └─ ผ่อนปรนกับโค้ดตัวเอง / บริบทสกปรก / ต้นทุนไม่สมดุล

[แบ่งเป็นกอง]
  ผู้ลงมือ ─▶ ผู้ตรวจสอบ (มุมมองต่าง สิทธิ์ต่าง) ─▶ ผู้ประสานงานกำกับภาพรวม
        └─ ตรวจด้วยสายตาอิสระ / บริบทถูกแยก / จัดสรรความสามารถตามงาน

แบ่งตามบทบาท: coder → reviewer และ orchestrator

รากฐานคือ เมื่อผู้ลงมือ (coder) เขียนเสร็จ เอเจนต์อีกตัว — ผู้ตรวจสอบ (reviewer) — ตรวจด้วยสายตาอิสระ แล้วส่งข้อทักท้วงกลับไปยังผู้ลงมือ เหนือขึ้นไปคือผู้ประสานงาน (orchestrator) ที่ไม่ลงมือทำเอง กำกับอย่างเดียว

                        ┌─▶ coder (ลงมือ) ─┐
  orchestrator (กำกับ)  ┤                  ├─▶ reviewer (ตรวจสอบ) ─▶ ข้อทักท้วงกลับไปยัง coder
                        └─▶ แตกงาน/ขนาน ───┘         │
                                ▲                    └─ วนไปมาจนกว่าจะดี
                                └─────────────────────┘

ใน Claude Code บทบาทในแผนภาพนี้แสดงเป็นไฟล์นิยาม 1 ไฟล์ต่อเอเจนต์ 1 ตัว โดยแต่ละไฟล์ระบุบทบาท เครื่องมือที่ใช้ได้ และโมเดลที่กำหนด แผนภาพข้างบนกลายเป็นการตั้งค่าข้างล่าง

# ~/.claude/agents/*.md (ตัดตอนจากนิยามของแต่ละเอเจนต์ย่อย)
orchestrator : { model: opus,   tools: [Agent, Read, Grep, ...] }   # ผู้ประสานงาน (กำกับเท่านั้น)
rag-reviewer : { model: opus,   tools: [Read, Grep, Bash, ...]  }   # ผู้ตรวจสอบ
rag-coder    : { model: sonnet, tools: [Read, Write, Edit, ...] }   # ผู้ลงมือ

วางแผนภาพกับการตั้งค่าเทียบกัน จุดสำคัญคือ ผู้ตรวจสอบไม่มีเครื่องมือ Write / Edit reviewer แก้ไขผลงานของผู้ลงมือโดยตรงไม่ได้ ถ้าการตรวจสอบและการลงมืออยู่ในมือเดียวกัน ก็จะไถลกลับไปสู่ “ผ่อนปรนกับตัวเอง” อย่าผสมเส้นแบ่งบทบาท — บังคับที่ระดับสิทธิ์

ครั้งแรกที่ผมรันกองนี้แบบทะลุปลายบน API ธนาคารจริง สายโซ่อนุกรมแบบซ้อน (ลงมือ → ตรวจสอบ → คอมมิตเฉพาะทาง) ทำงานได้โดยไม่มีข้อผิดพลาดด้านสิทธิ์ นี่คือค่าที่วัดได้

# ค่าที่วัดได้จาก orchestrator กำกับฟีเจอร์จริง (API ยืนยันตัวตน)
rag-coder (ลงมือ)        … ~11.6 นาที / ~136k โทเคน   ← ขั้นที่หนักที่สุด
rag-reviewer (ตรวจสอบ)   … ~6.7 นาที  /  ~73k โทเคน
คอมมิตเฉพาะทาง (แยก)     … ~34 วินาที /  ~40k โทเคน    ← ราว 1/3 ของการลงมือ; แยกงานประจำเบา ๆ ไปอีกตัว

จำนวนโทเคนสะท้อนน้ำหนักของขั้นงานโดยตรง การลงมือหนักที่สุด งานประจำอย่างการคอมมิตใช้เพียง 1/3 ดังนั้นการลงมือที่หนักไปที่โมเดลกำลังหลัก งานประจำเบาแยกไปอีกตัว — ตัวเลขกลายเป็นฐานของการจัดสรรครั้งถัดไป

จัดสรรโมเดลตามความเหมาะสม

หัวใจของการปรับจูนกองคือ จะกำหนดโมเดลใดให้บทบาทใด เป้าหมายไม่ใช่การประหยัดโทเคน แต่คือการจัดสรรความสามารถและต้นทุน ผมถือมันเป็น “บันได” ในแผนภาพก่อน แล้วเผาลงในคำสั่ง (CLAUDE.md) เป็นข้อความ

ความสามารถ↑  fable ─── เลื่อนขั้นเฉพาะก้าวที่ยากที่สุดก้าวเดียว ตามการตัดสิน
             opus ──── ตรวจสอบ / ออกแบบ / ความปลอดภัย (ปกป้องไว้)
             sonnet ── สร้าง / เขียนโค้ดประจำวัน (กำลังหลัก)
             haiku ─── งานกลไก / ง่าย
ต้นทุน↓ (ยิ่งล่างยิ่งถูก)

# CLAUDE.md (วินัยการปฏิบัติงาน ตัดตอน) — ตรึงบันไดข้างบนเป็นถ้อยคำ
การเลือกโมเดลคือ "ความเหมาะสมเพื่อประสิทธิภาพสูงสุด" เป็นอันดับแรก = การประหยัดโทเคนไม่ใช่เป้าหมาย
ตรวจสอบ / ออกแบบ / ตัดสินความปลอดภัย = opus ปกป้องไว้ (ไม่ตระหนี่)
⛔ การลดงานตรวจสอบไปโมเดลถูกเพื่อให้ถูก คือการวางแกนผิด — ห้าม

ครั้งหนึ่ง ด้วยความตั้งใจจะลดต้นทุน ผมลดแม้แต่ผู้ตรวจสอบไปโมเดลที่เบากว่า แล้ววางแกนผิด เลือกด้วย “งานนี้ต้องการความสามารถที่สมน้ำสมเนื้อหรือไม่” ไม่ใช่ “ลดให้ถูกได้แค่ไหน” ความถูกไม่ใช่เป้าหมาย การจัดสรรความสามารถต่างหากคือเป้าหมาย

การมอบหมายมี “ต้นทุนเชิงโครงสร้าง”

อีกคันโยกหนึ่งคือการมอบหมาย grep จำนวนมากและการอ่านบันทึกยาว ๆ ให้เอเจนต์ย่อยที่มีพื้นที่ทำงานว่างเปล่าของตัวเอง (บริบทที่แยกออกมา) ต่างหากจากตัวหลัก ให้เอเจนต์ย่อยอ่าน ตัวหลักรับแค่บทสรุป — เพื่อไม่ให้บริบทของตัวหลักจมอยู่ในข้อมูลจิปาถะ

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

# ผลของการจัดวางการตรวจสอบไฟล์จำนวนมากไปยัง 3 ตัวแบบขนาน
เป้า: ย่นเวลาด้วยการขนาน  ─▶  จริง: ต้นทุนเชิงโครงสร้างของการเรียกหลายตัว
                                    เหนือกว่าระดับโมเดล กินบริบทถึง 80%+
คำตัดสิน: การตรวจสอบนี้คือ "งานหนักตัวเดียวที่ต้องมองภาพรวม" = ไม่เหมาะกับการแยก
          → ให้ตัวหลักประมวลผลตรง ๆ ทีเดียวจะถูกกว่า

ดังนั้นจะมอบหมายหรือไม่ ตัดสินจากลักษณะของงาน

  การอ่านที่ยืดยาว (บันทึกจำนวนมาก อ่านทั้งฉบับ)   → มอบหมาย (แยกออกเพื่อปกป้องบริบทตัวหลัก)
  งานที่ขนานได้อย่างอิสระ (การแปลงจำนวนมาก)        → มอบหมาย (การขนานได้ผล / จำกัดการรันพร้อมกันที่ 2–4)
  งานหนักตัวเดียวที่ต้องมองภาพรวม                   → ตัวหลักตรง ๆ (ต้นทุนคงที่ของการแยกสูง)

กองไม่ได้อยู่ยงคงกระพัน: เมื่อพัง ให้วัดแล้วกู้คืน

กองแข็งแกร่ง แต่ไม่ใช่ไม่มีวันพัง อีกวันหนึ่ง เมื่อผมจัดวางงานแปลงชุดที่อิสระสูงไปยัง 4 ตัวแบบขนาน API ไม่เสถียร และมากกว่าครึ่งค้างกลางคัน (ค้าง = การตอบสนองหยุดกลางกระแสข้อมูล) สิ่งที่ได้ผลไม่ใช่การเชื่อเกินไปว่า “มอบหมาย = เร็ว” แต่คือวินัยของการวัดแล้วกู้คืน

① วัดความเสียหายด้วยเมทริกซ์การมีอยู่ … มี 21/32 ขาด 11 (การเขียนเป็นทั้งไฟล์ทีเดียว = ไม่มีไฟล์ที่ขาดครึ่ง)
② จัดวางเฉพาะตัวที่ล้มเหลวใหม่ ด้วยภาระที่ลดลง … ลดส่วนแบ่งของแต่ละตัว
③ ตัวที่ยังล้มอยู่ ทำตรง ๆ ในตัวหลัก … ทำให้เสร็จอย่างแน่นอนด้วยมือในที่ที่เสถียร
④ ยืนยันความสอดคล้องด้วยการตรวจแบบกลไก … ลิงก์ภายใน 0 ข้อผิดพลาด

ผมไล่รายการตัวที่ขาดได้เพราะการเขียนเป็นทั้งไฟล์ทีเดียว — การค้างไม่ทิ้งไฟล์ที่เขียนครึ่ง ๆ ไว้ ความเร็วถูกออกแบบไปพร้อมกับวิธีที่มันพัง

”กองที่ไม่พลาดพลั้ง” เหนือกว่า “ตัวเดียวที่รอบด้าน”

สร้างสองระบบไปพร้อมกัน สิ่งที่ตกผลึกคือ ความแข็งแกร่งของเอเจนต์ไม่ได้ตัดสินด้วยความฉลาดของตัวเดียว แบ่งตามบทบาท (การลงมือและการตรวจสอบไปยังสายตาต่าง สิทธิ์ต่าง) จัดสรรความสามารถ (โมเดลแข็งแรงให้สิ่งที่พลาดไม่ได้ โดยไม่ตระหนี่) วัดต้นทุนเชิงโครงสร้างของการมอบหมาย (งานหนักตัวเดียวไปที่ตัวหลักตรง ๆ) และออกแบบวิธีที่มันพัง (แม้ล้ม ก็คงรูปให้วัดความเสียหายแล้วกู้คืนได้) สิ่งที่แข็งแกร่งไม่ใช่ตัวเดียวที่ฉลาดกว่า แต่คือกองที่ปิดช่วงเวลาไม่ฉลาดด้วยโครงสร้างและวินัย

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