Code Agent Orchestra - วิธีทำให้การเขียนโค้ดแบบมัลติเอเจนต์ทำงานได้อย่างถูกต้อง

• จากวิธีทำงานร่วมกับ AI assistant ตัวเดียวแบบ synchronous loop กำลังเกิดการเปลี่ยนผ่านในปี 2026 ไปสู่โมเดล orchestrator ที่เอเจนต์หลายตัวทำงานแบบ asynchronous โดยแต่ละตัวมี context window และขอบเขตไฟล์ ของตัวเอง
• 3 แพตเทิร์นหลัก ได้แก่ Subagents, Agent Teams, และการมอบหมายงานแบบลำดับชั้น กลายเป็นโครงสร้างพื้นฐานของการเขียนโค้ดแบบมัลติเอเจนต์ โดยมอบประโยชน์ด้านการทำงานขนาน ความเชี่ยวชาญเฉพาะด้าน การแยกส่วน และการเรียนรู้แบบทบต้น
• รายการงานที่ใช้ร่วมกันและการส่งข้อความแบบ peer-to-peer คือกลไกการประสานงานหลักของ Agent Teams ทำให้ปลดล็อก dependency อัตโนมัติและหลีกเลี่ยงคอขวดได้
• ณ ปี 2026 ระบบนิเวศของเครื่องมือแบ่งได้เป็น 3 ชั้น: in-process subagents (Tier 1), local orchestrators (Tier 2), และ cloud asynchronous agents (Tier 3) โดยนักพัฒนาส่วนใหญ่ใช้งานทั้งสามชั้นผสมกันตามวัตถุประสงค์
• คอขวดได้ย้ายจากการสร้างโค้ดไปสู่ Verification และ quality gate กับ human review ผ่านการอนุมัติแผน, hooks, และ AGENTS.md คือปัจจัยหลักที่กำหนดความน่าเชื่อถือของระบบมัลติเอเจนต์

---

การเปลี่ยนผ่านในปัจจุบัน: จาก conductor สู่ orchestrator

• จนถึงเมื่อ 6 เดือนก่อน นักพัฒนาส่วนใหญ่ยังทำงานกับ AI assistant ตัวเดียวแบบ synchronous และ context window เดียวคือขีดจำกัดสูงสุดของงาน
• ปัจจุบัน นักพัฒนาที่มีประสิทธิภาพสูงสุดกำลังเปลี่ยนไปใช้วิธีประสานงานเอเจนต์หลายตัวแบบ asynchronous โดยแต่ละตัวมี context window, ขอบเขตไฟล์ และขอบเขตความรับผิดชอบของตัวเอง
• โมเดล Conductor: ชี้นำเอเจนต์ตัวเดียวแบบ synchronous และเรียลไทม์; เครื่องมือเด่นคือ Claude Code CLI และ agent mode ใน Cursor editor
• โมเดล Orchestrator: ประสานงานเอเจนต์หลายตัวแบบ asynchronous โดยแต่ละตัวมี context window ของตัวเอง; เครื่องมือเด่นคือ Agent Teams, Conductor, Codex และ Copilot Coding Agent
• การเป็น orchestrator ต้องใช้ทักษะใหม่ ได้แก่ การเขียนสเปกให้ชัดเจน การแตกงาน และการตรวจสอบผลลัพธ์

8 ระดับของการเขียนโค้ดที่มี AI ช่วย

• [Orchestration]
  • L8 — สร้าง orchestrator ของตัวเอง: ลงมือสร้าง coordination layer ด้วยโค้ดเองสำหรับการสร้าง การกำหนดเส้นทาง และการจัดการเอเจนต์
  • L7 — มีเอเจนต์เกิน 10 ตัว จัดการเองด้วยมือ: "แย่แล้ว เละเทะไปหมด" context ผิดถูกส่งไปยังเอเจนต์ผิด และเริ่มมีคำถามว่า "ถ้า Claude Code รัน Claude Code จะเกิดอะไรขึ้น?"
  • L6 — agent multiplexing: เพราะการรอชวนเบื่อเลยเปิดเอเจนต์เพิ่มทีละตัว จนสลับไปมาระหว่างหลายสตรีมและหยุดไม่ได้
• [Agent-first]
  • L5 — agent-first, IDE ตามมาทีหลัง: การคุยกับเอเจนต์คือ workspace หลัก ส่วน IDE ใช้สำหรับตรวจโค้ด
  • L4 — diff หายไปและบทสนทนาเป็นตัวนำ: ไม่ต้องรีวิว diff ทุกครั้งอีกต่อไป แต่เฝ้าดูพฤติกรรมของเอเจนต์และโฟกัสที่การกำหนดทิศทาง
• [ยุค IDE]
  • L3 — โหมด YOLO: เอเจนต์รันได้อย่างอิสระใน IDE ความเชื่อมั่นสูงขึ้น
  • L2 — เอเจนต์ใน IDE, อนุมัติสิทธิ์ด้วยตนเอง: อนุญาตทุกการแก้ไขไฟล์ด้วยตัวเอง ควบคุมแบบ manual ทั้งหมด
  • L1 — ไม่มี AI: เวิร์กโฟลว์การพัฒนาแบบดั้งเดิม
• ตามกรอบ 8 ระดับของการใช้เครื่องมือ AI ที่ Steve Yegge สรุปไว้ นักพัฒนาส่วนใหญ่ยัง อยู่ที่ระดับ 3~4
• ชั้น orchestration เริ่มต้นตั้งแต่ระดับ 6 และต้องใช้ ชุดทักษะที่แตกต่างโดยพื้นฐาน จากความสามารถที่พามาถึงระดับ 5
• เนื้อหานี้ครอบคลุมระดับ 5~8

ข้อจำกัดของเอเจนต์เดี่ยว

• context overload: เอเจนต์ตัวเดียวมีข้อจำกัดด้านปริมาณข้อมูลที่ถือไว้ได้ และโค้ดเบสขนาดใหญ่ก็เกินความสามารถของ context window เดียว
• ขาดความเชี่ยวชาญเฉพาะด้าน: เอเจนต์ที่ต้องจัดการทั้ง data layer, API, UI และการทดสอบ เป็นได้แค่ generalist ขณะที่เอเจนต์ที่รับผิดชอบเฉพาะ data layer จะเขียนโค้ด DB ได้ดีกว่ามาก
• ขาดการประสานงาน: ต่อให้เพิ่ม helper agents ก็ยังไม่สามารถสื่อสารกัน แชร์งาน หรือแก้ dependency ร่วมกันได้ และยิ่งเพิ่มเอเจนต์โดยไม่มี coordination primitives ก็ยิ่งจัดการยากขึ้น
• subagents แก้สองปัญหาแรก ส่วน Agent Teams แก้ได้ครบทั้งสามปัญหา

เหตุผลของมัลติเอเจนต์

• การทำงานขนาน (throughput เพิ่ม 3 เท่า): เอเจนต์ฝั่ง frontend, backend และทดสอบทำงานพร้อมกัน
• ความเชี่ยวชาญเฉพาะด้าน (context ที่โฟกัส): แต่ละเอเจนต์รับรู้เฉพาะไฟล์ที่ตัวเองรับผิดชอบ; เอเจนต์ที่รู้แค่ db.js เขียนโค้ด DB ได้ดีกว่าเอเจนต์ที่ต้องดูทั้งโค้ดเบส
• การแยกส่วน (รันได้อย่างปลอดภัย): Git worktree ให้ working directory แยกอิสระกับแต่ละเอเจนต์ จึงไม่มี merge conflict
• การเรียนรู้แบบทบต้น: ไฟล์ AGENTS.md สะสมแพตเทิร์นและข้อควรระวังข้ามเซสชัน ทำให้ทุกเซสชันช่วยปรับปรุงเซสชันถัดไป
• เอเจนต์ที่โฟกัสงาน 3 ตัวให้ผลงานสม่ำเสมอดีกว่าเอเจนต์ generalist 1 ตัวที่ทำงานนานกว่า 3 เท่า

แพตเทิร์น 1: Subagents — การมอบหมายงานแบบโฟกัส

• ใช้เครื่องมือ Task เพื่อ สร้าง child agents ที่เชี่ยวชาญเฉพาะทางจาก parent orchestrator; เป็นแพตเทิร์นมัลติเอเจนต์ที่ง่ายที่สุดและควรลองก่อน
• ตัวอย่างแบบเจาะจง: หากให้พรอมป์กับ Claude Code ว่า "สร้าง Link Shelf ตัวจัดการบุ๊กมาร์กด้วย Express และ SQLite" parent orchestrator จะย่อยออกเป็นบรีฟสำหรับ subagent 3 ตัว
  • data layer subagent: สร้าง db.js แล้วเขียนรายงาน DATA.md
  • business logic subagent: สร้าง validation.js แล้วเขียนรายงาน LOGIC.md
  • API routes subagent: อ่าน DATA.md และ LOGIC.md แล้วจึงสร้าง server.js
• subagent สองตัวแรกทำงานขนานกันอย่างอิสระ ส่วนตัวที่สามเริ่มได้หลังจากทั้งสองรายงานเสร็จ; parent จัดการ dependency graph เองแบบ manual
• ข้อจำกัดของ subagents: parent ต้องจัดการ dependency graph เองแบบ manual และไม่มีทั้งการส่งข้อความแบบ peer ระหว่างเอเจนต์หรือรายการงานที่แชร์ร่วมกัน; หากจัดการขอบเขตไฟล์ไม่ดีอาจเกิดการชนกันได้
• ต้นทุนรวมประมาณ 220,000 tokens จัดว่าอยู่ในระดับ cost-neutral

• subagents แบบลำดับชั้น (ทีมของทีม)

  • แทนที่ orchestrator จะสร้าง subagent 6 ตัวโดยตรง ก็ใช้โครงสร้าง สร้าง feature lead 2 คน แล้วให้แต่ละ feature lead สร้างผู้เชี่ยวชาญของตัวเองอีก 2~3 คน
  • parent orchestrator ต้องดูแลเพียง 2 เอเจนต์ จึงรักษา context ให้สะอาดได้; feature lead A รับบรีฟว่า "สร้างฟีเจอร์ค้นหา" แล้วไปแตกงานต่อเอง
  • หลักการเดียวกับวิธีทำงานขององค์กรวิศวกรรมจริง: VP ไม่ได้แจกงานให้วิศวกรแต่ละคนโดยตรง แต่ส่งผ่าน tech lead

แพตเทิร์น 2: ทีมเอเจนต์ — การรันแบบขนานอย่างแท้จริง

• เป็นฟีเจอร์ทดลองของ Claude Code เปิดใช้งานด้วยคำสั่ง export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• สถาปัตยกรรม 3 ชั้น:
  • หัวหน้าทีม (Team Lead): แยกย่อยงาน สร้างรายการทาสก์ และสรุปผลลัพธ์
  • รายการทาสก์ที่ใช้ร่วมกัน: ติดตามสถานะ (pending, in_progress, completed, blocked)·การพึ่งพากัน·การล็อกไฟล์
  • สมาชิกทีม (Teammates): Claude Code instance อิสระของแต่ละคน มี context window ของตัวเอง และรันใน tmux split panel
• สมาชิกทีมเลือกทาสก์จากรายการร่วมได้อย่างอิสระ และสื่อสารกันโดยตรงผ่าน peer-to-peer messaging (ไม่ต้องผ่านหัวหน้าทีม)
• เมื่อสมาชิกคนหนึ่งทำทาสก์เสร็จแล้วทำเครื่องหมายว่าเสร็จ ทาสก์ที่เคยถูกบล็อกเพราะพึ่งพางานนั้นจะถูกปลดล็อกโดยอัตโนมัติ
• สามารถสลับการแสดง visual overlay ของรายการทาสก์ได้ด้วย Ctrl+T

• กลไกหลักของทีมเอเจนต์

  • รายการทาสก์ที่ใช้ร่วมกัน: เมื่อเอเจนต์ฝั่งแบ็กเอนด์ทำ API ค้นหาเสร็จและทำเครื่องหมายว่า completed ทาสก์การเขียนเทสต์ที่ถูกบล็อกจะเปลี่ยนเป็นสถานะ pending โดยอัตโนมัติ; การล็อกไฟล์ช่วยป้องกันการแก้ไขพร้อมกัน
  • การส่งข้อความแบบเพียร์: เอเจนต์แบ็กเอนด์ส่งสัญญา API ให้เอเจนต์ฟรอนต์เอนด์โดยตรง — "GET /search?q= returns [{id,title,url}]"; ป้องกันไม่ให้หัวหน้าทีมกลายเป็นคอขวดในการประสานงาน
  • เมื่อสมาชิกทีมว่างงาน ระบบจะแจ้งหัวหน้าทีมโดยอัตโนมัติ

• คำแนะนำหลักสำหรับทีมเอเจนต์

  • สมาชิกทีม 3~5 คน คือจุดที่เหมาะที่สุด; ค่าใช้จ่ายด้านโทเคนเพิ่มขึ้นแบบเส้นตรงตามขนาดทีม
  • การอนุมัติแผน: หากสมาชิกทีมเขียนแผนก่อนลงมือทำ หัวหน้าทีมจะตรวจสอบ อนุมัติ หรือปฏิเสธ; การพบปัญหาสถาปัตยกรรมก่อนมีโค้ดจริงมีต้นทุนถูกกว่ามาก
  • สมาชิกทีมที่โฟกัส 3 คนให้ผลงานดีกว่าสมาชิกทีมที่กระจัดกระจาย 5 คนอย่างสม่ำเสมอ

• เคล็ดลับด้านความน่าเชื่อถือของทีมเอเจนต์

  • loop guardrail + ขั้นสะท้อนทบทวน: ตั้งเพดาน MAX_ITERATIONS=8 ให้สมาชิกทุกคน; ก่อนลองใหม่แต่ละครั้ง ให้บังคับใช้พรอมป์สะท้อนทบทวนว่า "อะไรล้มเหลว? การเปลี่ยนแปลงที่เฉพาะเจาะจงอะไรจะทำให้แก้ไขได้? กำลังทำวิธีเดิมซ้ำอยู่หรือไม่?" → ลดการเกิดเอเจนต์ติดทางตันได้อย่างมาก
  • สมาชิก @reviewer โดยเฉพาะ: กำหนด Claude Opus 4.6 (อ่านอย่างเดียว) เป็น reviewer ใช้เฉพาะเครื่องมือ lint·test·security scan และทริกเกอร์อัตโนมัติทุกครั้งที่มีอีเวนต์ TaskCompleted; อัตราส่วน reviewer 1 คนต่อ builder 3~4 คน; หัวหน้าทีมจะได้รับเฉพาะโค้ดที่ผ่านการรีวิวแล้วเสมอ

แพตเทิร์น 3: ออร์เคสเตรชันในระดับสเกล

• เมื่อต้องจัดการเอเจนต์ 5, 10, 20 ตัวขึ้นไปข้ามหลาย repo และหลายฟีเจอร์ จะต้องใช้ เครื่องมือ orchestration โดยเฉพาะ
• Tier 1 — sub-agent และทีมภายในโปรเซส: Claude Code sub-agent และทีมเอเจนต์; ใช้เทอร์มินัลเซสชันเดียว ไม่ต้องมีเครื่องมือเพิ่ม; เริ่มจากตรงนี้
• Tier 2 — local orchestrator: รันเอเจนต์หลายตัวใน worktree แยกกัน พร้อมคง dashboard·การรีวิว diff·การควบคุมการ merge; เหมาะที่สุดสำหรับเอเจนต์ 3~10 ตัวบนโค้ดเบสที่คุ้นเคย; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
• Tier 3 — cloud asynchronous agents: มอบหมายทาสก์แล้วปิดโน้ตบุ๊ก รอ PR ได้เลย; รันบน cloud VM; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
• ภายในปี 2026 นักพัฒนาส่วนใหญ่จะใช้ครบทั้งสามชั้น: Tier 1 (งานแบบอินเทอร์แอ็กทีฟ), Tier 2 (สปรินต์แบบขนาน), Tier 3 (จัดการ backlog ตอนกลางคืน)

สปอตไลต์เครื่องมือ

• Conductor by Melty Labs

  • วิธีที่เร็วที่สุดในการเริ่มทำ multi-agent orchestration บน Mac; รัน Claude Code และ Codex agent หลายตัวแบบขนาน โดยแต่ละตัวอยู่ใน git worktree อิสระ
  • มี visual dashboard และ UI รีวิวที่เน้น diff เป็นหลัก; จ่ายเฉพาะค่า API (ใช้ฟรี); รองรับเฉพาะ macOS (Apple Silicon·Intel)
  • เหมาะที่สุดเมื่อทำงานกับ 3~8 ฟีเจอร์แบบขนานใน repo เดียวกัน และต้องการการกำกับดูแลแบบมองเห็นได้

• Claude Code Web

  • เข้าใช้งานได้ที่ claude.ai/code; ทำงานผ่านเบราว์เซอร์ทั้งหมด ไม่ต้องใช้เทอร์มินัล; เชื่อมต่อ GitHub repo แล้วป้อนคำอธิบายทาสก์ → รันบน cloud VM ที่ Anthropic ดูแล
  • รองรับการ steer ระหว่างทาง, การสร้าง PR อัตโนมัติ และการเข้าถึงผ่านแอป iOS
  • ทีม (เทอร์มินัล) คือการทำงานร่วมกับเอเจนต์, ส่วน เว็บ (เบราว์เซอร์) คือการมอบหมายแล้วลุกออกไปทำอย่างอื่น

• GitHub Copilot Coding Agent

  • แตกต่างจากโหมด Copilot agent ใน IDE (ซิงก์และอินเทอร์แอ็กทีฟ); Copilot Coding Agent ของ GitHub เป็นแบบอะซิงก์เต็มรูปแบบ
  • มอบหมาย GitHub issue ใดก็ได้ให้ @copilot หรือเริ่มจากแผง Agents → สร้าง draft PR ในสภาพแวดล้อม GitHub Actions
  • รัน วงจรรีวิวของตัวเอง ก่อนถูกแท็ก; เอเจนต์ภายนอกอย่าง Claude Code·Codex ก็เข้าถึงได้จากแผงเดียวกัน; ทริกเกอร์ได้จาก Slack, Jira, Linear, Azure Boards

• Jules by Google

  • เอเจนต์เขียนโค้ดบนคลาวด์แบบอะซิงก์ของ Google ที่ ขับเคลื่อนด้วย Gemini; เชื่อมต่อ GitHub repo → คำอธิบายทาสก์ → Jules สร้างแผน → หลังอนุมัติจึงรันบน cloud VM → ส่งคืน PR ที่มีทั้งกระบวนการให้เหตุผลทั้งหมดและ terminal log
  • มี audio changelog, การหยุดทาสก์ระหว่างทาง และ Jules Tools CLI สำหรับส่ง GitHub issue เข้ามาโดยตรง
  • อ่าน AGENTS.md ของ repo โดยอัตโนมัติโดยไม่ต้องตั้งค่าเพิ่ม

• OpenAI Codex Web

  • แต่ละทาสก์รันอยู่ใน sandbox container อิสระ ที่ preload GitHub repo ไว้ล่วงหน้า
  • มีระบบนิเวศของพื้นผิวการใช้งานที่เชื่อม Web, CLI (โอเพนซอร์ส), แอป macOS, IDE extension และการเชื่อมกับ GitHub ผ่านบัญชี ChatGPT
  • ฟีเจอร์ Verifiable Evidence: ส่งคืนการอ้างอิง terminal log และผลลัพธ์การทดสอบของทุกทาสก์ ทำให้ตรวจสอบย้อนหลังสิ่งที่รันได้

• Cursor Cloud Agents + Glass

  • เริ่มเอเจนต์ได้จากเว็บ, แอปเดสก์ท็อป, Slack, Linear, GitHub, API, PWA (ติดตั้งที่ cursor.com/agents)
  • Glass: อินเทอร์เฟซใหม่ของ Cursor ที่เปลี่ยนการจัดการเอเจนต์ให้เป็นหน้าจอหลัก ส่วนเอดิเตอร์เดิมกลายเป็นเครื่องมือเสริมที่เปิดใช้เมื่อจำเป็น
  • สะท้อนแพตเทิร์นที่ control plane กลายเป็นประสบการณ์หลัก ทั่วทั้งระบบนิเวศ และเอดิเตอร์กลายเป็นเพียงเครื่องดนตรีชิ้นหนึ่งด้านล่าง

• Vibe Kanban

  • แก้ปัญหา "doomscrolling gap" (ช่วงว่าง 2~5 นาทีระหว่างที่เอเจนต์ทำงาน); สร้างการ์ดทาสก์แล้วลากไปที่ "In Progress" เพื่อสร้าง worktree และ branch แยกให้แต่ละงาน
  • รีวิว diff และส่งฟีดแบ็กให้เอเจนต์ที่กำลังรันอยู่ได้จากในบอร์ด; รองรับ Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI และอื่น ๆ; ข้ามแพลตฟอร์ม (Mac, Windows, Linux), ฟรี, BYOK

เคล็ดลับสำหรับการขยายขนาด

• การทำ Model Routing แบบหลายโมเดล

  • ไม่ใช่ทุกงานที่ต้องใช้โมเดลที่แพงที่สุด; สร้างไฟล์ MODEL_ROUTING.md เพื่อกำหนดเส้นทางตามบทบาท:
    • แผน·สถาปัตยกรรม → โมเดล Gemini/Claude/OpenAI ที่ราคาย่อมเยา
    • การนำไปใช้จริง → Sonnet, Opus หรือ Codex
    • การรีวิว → โมเดลด้านความปลอดภัยโดยเฉพาะ

• สคริปต์วงจรชีวิตของ worktree

  • ทำงานซ้ำ ๆ ให้เป็นอัตโนมัติด้วย shell alias สามตัว:
    • agent-spin <feature>: สร้าง worktree + branch + เริ่ม agent
    • agent-merge <feature>: rebase + review + สร้าง PR
    • agent-clean: ลบ worktree ที่เสร็จแล้ว
  • bash ราว 12 บรรทัด; Conductor จัดการสิ่งนี้ในรูปแบบภาพ

• อนุญาตเฉพาะ AGENTS.md ที่มนุษย์เขียน

  • งานวิจัยของ ETH Zurich โดย Gloaguen et al. ยืนยันว่า ไฟล์ AGENTS.md ที่สร้างโดย LLM ไม่ให้ประโยชน์ และทำให้อัตราความสำเร็จลดลงเฉลี่ย ~3% พร้อมเพิ่มต้นทุนการอนุมานเกิน 20%
  • ไฟล์คอนเท็กซ์ที่นักพัฒนาเขียน ช่วยเพิ่มประสิทธิภาพได้ ~4%
  • อย่าอนุญาตให้ agent เขียนลง AGENTS.md โดยตรงเด็ดขาด; หัวหน้าทีมต้องอนุมัติทุกบรรทัด
  • ทำให้กระชับและแบ่งส่วนให้ชัดเจน: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY

ด่านคุณภาพ: เชื่อใจได้ แต่ต้องตรวจสอบ

• ด่านคุณภาพสามชั้น

  • การอนุมัติแผน: สมาชิกทีมเขียนแผนก่อนเริ่มเขียนโค้ด → หัวหน้าทีมตรวจและอนุมัติหรือปฏิเสธ → จึงค่อยลงมือพัฒนา; ค่าใช้จ่ายในการแก้แผนที่แย่นั้นถูกกว่าการแก้โค้ดที่แย่มาก
  • Hooks: การตรวจสอบอัตโนมัติของเหตุการณ์ใน lifecycle; hook TeammateIdle จะตรวจว่าการทดสอบทั้งหมดผ่านก่อนที่ agent จะหยุดทำงาน; hook TaskCompleted จะรัน lint·test ก่อนทำเครื่องหมายว่าเสร็จ; หาก hook ล้มเหลว agent จะทำงานต่อจนกว่าจะผ่าน
  • การเรียนรู้แบบทบต้นผ่าน AGENTS.md: เก็บรูปแบบ ข้อควรระวัง และความชอบด้านสไตล์ที่ค้นพบ; ทุก agent จะอ่านเมื่อเริ่มเซสชัน และมีการเพิ่มข้อมูลในทุกเซสชัน

• คอขวดได้ย้ายไปอยู่ที่การตรวจสอบ

  • agent สามารถสร้างผลลัพธ์ที่น่าทึ่งได้ด้วยความเร็วที่น่าประหลาดใจ; ส่วนที่ยากคือการมั่นใจว่าผลลัพธ์นั้นถูกต้อง
  • การที่เทสต์ผ่านก่อนเปลี่ยนแปลง ไม่ได้การันตีว่าจะจับ regression จากการเปลี่ยนแปลงได้
  • agent อาจเขียนเทสต์ที่ถูกต้องในเชิงเทคนิค แต่พลาดเคสสำคัญ
  • ด้วยข้อจำกัดของ context window agent ที่ทำงานกับโค้ดเบสขนาดใหญ่จึงอาจพลาดข้อจำกัดสำคัญที่อยู่นอกมุมมองปัจจุบัน
  • สภาพแวดล้อมที่ไม่เสถียรซึ่งเป็น edge case ที่น่ารำคาญสำหรับนักพัฒนาคนเดียว จะกลายเป็น ตัวบล็อกเชิงระบบ เมื่อมี agent 40 ตัวเจอเทสต์ที่ไม่เสถียรเดียวกันพร้อมกัน
  • จนกว่าโครงสร้างพื้นฐานด้านการตรวจสอบจะตามความสามารถด้านการสร้างให้ทัน การรีวิวโดยมนุษย์ยังคงเป็น ระบบความปลอดภัย ไม่ใช่ต้นทุนเสริมแบบเลือกได้

Ralph Loop และ agent ที่พัฒนาตัวเองได้

• แพตเทิร์น Ralph Loop

  • Geoffrey Huntley และ Ryan Carson เป็นผู้ทำให้แพร่หลาย; เป็นแพตเทิร์นเบื้องหลังแนวคิด “ส่งงานได้แม้ตอนหลับ”; เครื่องมือแยกของ Carson ชื่อ ralph (snarktank/ralph) ใช้งานลูปหลัก ส่วนโปรเจกต์ Antfarm เพิ่มการ orchestration แบบหลาย agent บน OpenClaw
  • วงจร 5 ขั้นตอน: Pick (เลือกงานถัดไปจาก tasks.json) → Implement (ลงมือเปลี่ยนแปลง) → Validate (รัน test·type·lint) → Commit (เมื่อผ่านการตรวจแล้วจึง commit และอัปเดตสถานะงาน) → Reset (รีเซ็ต context ของ agent แล้วไปงานถัดไป)
  • อินไซต์สำคัญ: การรีเซ็ตในแต่ละรอบช่วยป้องกันไม่ให้ความสับสนสะสม; งานเล็กที่มีขอบเขตชัดเจนทำให้เกิด hallucination น้อยกว่าและสร้างโค้ดที่สะอาดกว่าการใช้พรอมป์ต์ขนาดยักษ์เพียงครั้งเดียว
  • กลไกความปลอดภัย: ส่งข้อผิดพลาดกลับไปเป็น feedback เพื่อให้ลองใหม่อัตโนมัติ แต่หากติด deadlock เกิน 3 ครั้งให้หยุดและมอบหมายใหม่; ทำงานบน feature branch เสมอ; กำหนดเพดานจำนวนรอบ เวลา และโทเค็น; ให้ agent สร้าง PR → มนุษย์รีวิวก่อน merge
  • รักษาช่องทางความทรงจำ 4 แบบระหว่างการรีเซ็ต context: ประวัติ git commit, progress log, ไฟล์สถานะงาน (tasks.json), และ AGENTS.md ในฐานะความทรงจำเชิงความหมายระยะยาว

• ทำให้ agent ฉลาดขึ้นเมื่อเวลาผ่านไป

  • การสะท้อนตนเองผ่าน REFLECTION.md: หลังทุกงาน บังคับให้เขียนว่า “อะไรที่น่าประหลาดใจ, รูปแบบหนึ่งอย่างที่จะเพิ่มใน AGENTS.md, การปรับปรุงพรอมป์ต์หนึ่งอย่าง”; หัวหน้าทีมจะตรวจและรวมเฉพาะบทเรียนที่อนุมัติแล้ว
  • งบประมาณโทเค็นและเกณฑ์การหยุด: ตั้งเพดานต่อ agent (เช่น ฟรอนต์เอนด์ 180,000 โทเค็น, แบ็กเอนด์ 280,000 โทเค็น); หยุดชั่วคราวอัตโนมัติเมื่อใช้ถึง 85% ของงบและแจ้งหัวหน้าทีม; หากติด deadlock จากข้อผิดพลาดเดิมเกิน 3 ครั้ง ให้ยุติและมอบหมายให้ agent ตัวใหม่
  • Beads / หน่วยความจำถาวร: แพตเทิร์น “beads” ของ Gastown — บันทึกแบบ immutable บน git ของทุกการตัดสินใจและผลลัพธ์พร้อมที่มาแบบครบถ้วน; agent เรียกดู beads ในอดีตผ่าน task graph และ data plane ที่ query ได้ด้วย SQL; เป็นความทรงจำเชิงสถาบันแบบมีโครงสร้างและ query ได้ ไม่ใช่แค่ RAG แบบเวกเตอร์ธรรมดา

วินัยที่ทำให้ทั้งหมดนี้ทำงานได้

• คอขวดของมนุษย์ไม่ใช่บั๊ก แต่เป็นฟีเจอร์

  • เมื่อเขียนโค้ดด้วยความเร็วแบบมนุษย์ เราจะเจอความเจ็บปวดตั้งแต่ต้น; เทสต์ล้มเหลว, ถูกทักใน code review, พบโค้ดซ้ำ — ความเจ็บปวดเกิดทันทีจึงแก้ไปพร้อมกับการเดินหน้า
  • แต่ในกองทัพ agent ที่ถูก orchestration ไม่มีคอขวดตามธรรมชาติ; ความผิดพลาดเล็ก ๆ (code smell, ความซ้ำซ้อน, abstraction ที่ไม่จำเป็น) จะถูกขยายทบต้นด้วยความเร็วที่ตามแก้ไม่ทัน
  • เพราะหลุดออกจากลูปไปแล้ว คุณจะไม่รู้สึกถึงความเจ็บปวดจนกว่าสถาปัตยกรรมจะไม่สามารถรองรับฟีเจอร์ใหม่ได้อีก
  • นี่คือเหตุผลที่ต้องมี ด่านคุณภาพทุกชั้น (การอนุมัติแผน, hooks, งบประมาณโทเค็น, การรีวิวโดยมนุษย์): ถ้าไม่มี คุณจะใช้ agent coding พาตัวเองไปจนตัน

• มอบหมายงานได้ แต่ต้องเก็บวิจารณญาณไว้เอง

  • สิ่งที่ควรมอบให้ agent ทำ: งานที่ขอบเขตชัดเจนและมีเกณฑ์ผ่าน/ไม่ผ่านชัด, boilerplate, migration, test scaffolding, การลองสำรวจแนวทางที่คุณไม่มีเวลาลองเอง
  • สิ่งที่ต้องถือไว้เอง: การออกแบบสถาปัตยกรรมและ API (agent อาจเรียนรู้สถาปัตยกรรมที่ไม่ดีจำนวนมากจากข้อมูลฝึก และนำแพตเทิร์นระดับ enterprise มาใช้ตรง ๆ กับสตาร์ทอัพ), การตัดสินใจว่าจะไม่สร้างอะไร (การพูดว่า No เป็นความสามารถที่ agent ไม่มี), การรีวิวผลลัพธ์ของ agent ด้วย context ของทั้งระบบ
  • หากคุณสูญเสียความเข้าใจต่อระบบของตัวเอง คุณจะสูญเสียความสามารถในการแก้ไข ขยาย และตรวจจับการทำงานผิดปกติ

• สเปกคือแรงทวีคูณ

  • เมื่อ orchestration agent 50 ตัวให้ทำงานขนานกัน ความคิดที่กำกวมไม่เพียงแค่ทำให้ช้าลง แต่จะ ถูกขยายไปทั่วการรันแบบขนานนับสิบ
  • ความต่างระหว่างผลลัพธ์ธรรมดากับผลลัพธ์ยอดเยี่ยมนั้นแทบทั้งหมดขึ้นอยู่กับ คุณภาพของสเปก
  • สเปกที่กำกวมจะขยายข้อผิดพลาดไปทั้ง fleet; สเปกที่แม่นยำพร้อมสถาปัตยกรรม ขอบเขตการเชื่อมต่อ edge case และ invariant ที่ชัดเจน จะขยายเป็นการพัฒนาที่แม่นยำไปทั้งระบบ
  • งานเชิงกลของการพิมพ์โค้ดกำลังถูกทำให้เป็นอัตโนมัติ; งานเชิงความคิดในการเข้าใจระบบกำลังถูก ขยายแรง ไปทั่วทั้ง fleet ของผู้ปฏิบัติงานอัตโนมัติ

โมเดลแบบโรงงาน

• เราไม่ได้อยู่ในขั้นแค่เขียนโค้ดอีกต่อไป แต่กำลังอยู่ในขั้นของการ สร้างโรงงานที่ผลิตซอฟต์แวร์
• สายการผลิต 6 ขั้นตอน: Plan (เขียนสเปกพร้อมเกณฑ์การยอมรับ) → Spawn (สร้างทีมและมอบหมาย agent) → Monitor (เช็กความคืบหน้าทุก 5~10 นาทีและแก้ blocker โดยไม่ต้อง hover) → Verify (รันเทสต์·รีวิวโค้ด; การตรวจสอบคือคอขวด) → Integrate (merge branch·แก้ conflict) → Retro (อัปเดต AGENTS.md ด้วยรูปแบบใหม่; การเรียนรู้แบบทบต้น)
• เคล็ดลับเชิงปฏิบัติ:
  • ตั้ง WIP limit: อย่ารัน agent มากเกินกว่าที่คุณจะรีวิวได้อย่างมีความหมาย; จุดเหมาะสมคือ 3~5 ตัว
  • กำหนดเกณฑ์การหยุด: หากติด deadlock จากข้อผิดพลาดเดิมเกิน 3 ครั้ง ให้หยุดและมอบหมายใหม่
  • เช็กอินแบบอะซิงก์: ตรวจความคืบหน้าทุก 5~10 นาที; ปล่อยให้ agent ทำงานอย่างอิสระ
  • หนึ่งไฟล์มีเจ้าของคนเดียว: อย่าให้ agent สองตัวแก้ไฟล์เดียวกัน; conflict ทำลายความเร็ว

5 แพตเทิร์นที่เริ่มใช้ได้วันนี้

1. แยกย่อยเป็นซับเอเจนต์: สร้างลูกเอเจนต์ที่โฟกัสเฉพาะด้านด้วยเครื่องมือ Task พร้อมบรีฟเฉพาะและความเป็นเจ้าของไฟล์; ไม่ต้องตั้งค่า; เริ่มได้เลยวันนี้
2. ความขนานด้วยทีมเอเจนต์: เปิดใช้ CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1; สร้างหัวหน้าทีม + สมาชิก 3 คน; ประสานงานด้วยรายการงานที่แชร์ร่วมกัน
3. แยกสภาพแวดล้อมด้วย Git worktree: ให้แต่ละเอเจนต์มี worktree ของตัวเอง; ไม่มี merge conflict; Conductor จัดการให้อัตโนมัติ
4. quality gate เพื่อความเชื่อมั่น: กำหนดให้ต้องอนุมัติแผนสำหรับการเปลี่ยนแปลงที่มีความเสี่ยง; เพิ่ม hook ให้รันการทดสอบเมื่องานเสร็จ; อย่าเชื่อผลลัพธ์จากเอเจนต์โดยไม่มีการตรวจสอบ
5. สะสมการเรียนรู้ด้วย AGENTS.md: บันทึกแพตเทิร์น ข้อควรระวัง และสไตล์ที่ต้องการ; ทุกเซสชันจะอ่านและอัปเดต; ความรู้จะถูกสะสมและขยายผลทบต้น

[kurthong]

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

[stroke33]

เหตุผลสูงสุดที่ใช้ Claude Code แบบหอบแฮ่ก ๆ — ทำออร์เคสเตรชันของตัวเองด้วยมัลติเอเจนต์

ตอนนี้รันเอเจนต์อยู่ 5 ตัว แต่โทเค็นหมดเร็วชะมัดจนแทบร้องไห้