Agent Teams - การประสานงานทีมเซสชัน Claude Code

 (code.claude.com)
29 คะแนน โดย GN⁺ 2026-02-06 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ฟีเจอร์ทดลองที่รวม อินสแตนซ์ Claude Code หลายตัว ให้เป็นทีมเดียวเพื่อกระจายและประสานงานแบบขนาน โดยเซสชันผู้นำจะสร้างสมาชิกทีม มอบหมายงาน และสรุปผลลัพธ์
  • ต่างจาก Subagent เดิม ตรงที่สมาชิกทีมสามารถส่งข้อความหากันได้โดยตรง และผู้ใช้ก็สื่อสารกับสมาชิกแต่ละคนได้โดยตรงโดยไม่ต้องผ่านผู้นำ
  • มีประสิทธิภาพกับงานอย่างการรีวิวโค้ด การสำรวจสมมติฐานดีบักแบบขนาน และ งานข้ามเลเยอร์ เช่น ฟรอนต์เอนด์ แบ็กเอนด์ และการทดสอบ ขณะที่งานแบบลำดับหรือการแก้ไฟล์เดียวกันเหมาะกับเซสชันเดี่ยวมากกว่า
  • เนื่องจากสมาชิกแต่ละคนมี context window เป็นอิสระของตัวเอง การใช้โทเค็นจึงเพิ่มขึ้นอย่างมาก และค่าใช้จ่ายอาจขยายตามจำนวนสมาชิกทีม
  • รองรับ โหมดแบ่งหน้าจอ ผ่าน tmux หรือ iTerm2 และช่วยเพิ่ม ประสิทธิภาพและคุณภาพของงานพัฒนาที่ซับซ้อน ผ่านการสำรวจแบบขนานและระบบอัตโนมัติด้านการทำงานร่วมกัน

ภาพรวมของ Agent Teams

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

เมื่อใดที่ควรใช้ Agents Teams

  • การวิจัยและรีวิว: ให้สมาชิกหลายคนตรวจสอบคนละแง่มุมของปัญหาพร้อมกัน แล้วแชร์ผลและตรวจทานซึ่งกันและกัน
  • การพัฒนาโมดูลหรือฟีเจอร์ใหม่: สมาชิกแต่ละคนรับผิดชอบไฟล์/โมดูลแยกกัน เพื่อทำงานแบบขนานโดยไม่ชนกัน
  • การดีบักแบบสมมติฐานแข่งขันกัน: ทดสอบสมมติฐานที่ต่างกันพร้อมกันเพื่อหาสาเหตุได้เร็วขึ้น
  • การประสานงานข้ามเลเยอร์: จัดสมาชิกตามเลเยอร์ เช่น ฟรอนต์เอนด์ แบ็กเอนด์ และการทดสอบ เพื่อเปลี่ยนแปลงพร้อมกัน
  • สำหรับงานแบบลำดับ การแก้ไขไฟล์เดียวกัน หรืองานที่มี dependency มาก เซสชันเดี่ยวหรือ Subagent จะมีประสิทธิภาพกว่า

Subagent vs. Agent Team

  • Subagent: มี context window ของตัวเอง แต่ส่งผลลัพธ์กลับไปยังผู้เรียกเท่านั้น เอเจนต์หลักเป็นผู้จัดการทุกงาน ค่าโทเค็นค่อนข้างต่ำกว่า
  • Agent team: มี context window อิสระอย่างสมบูรณ์ แลกเปลี่ยน ข้อความโดยตรง ระหว่างสมาชิกได้ และประสานงานกันเองผ่านรายการงานที่ใช้ร่วมกัน เนื่องจากสมาชิกแต่ละคนเป็นอินสแตนซ์ Claude แยกกัน ค่าโทเค็นจึงสูงกว่า
  • งานเฉพาะทางที่ต้องการเพียงผลลัพธ์เหมาะกับ Subagent ส่วนงานซับซ้อนที่ต้องมีการหารือและทำงานร่วมกันระหว่างสมาชิก เหมาะกับ Agent team

เริ่ม Agent team แรก

  • ค่าเริ่มต้นคือปิดไว้ ให้ตั้งค่าตัวแปรแวดล้อม CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS เป็น 1 หรือเพิ่มตัวแปรแวดล้อมนี้ใน settings.json เพื่อเปิดใช้งาน
  • หลังเปิดใช้งานแล้ว ให้บรรยาย โครงสร้างทีมและงาน ด้วยภาษาธรรมชาติ แล้ว Claude จะ สร้างทีมและ spawn สมาชิก พร้อมประสานการทำงาน
    • > I'm designing a CLI tool that helps developers track TODO comments across their codebase. Create an agent team to explore this from different angles: one teammate on UX, one on technical architecture, one playing devil's advocate.
    • กำลังออกแบบเครื่องมือ CLI สำหรับติดตาม TODO โดยให้สมาชิกสามคนสำรวจแยกกันในมุม UX สถาปัตยกรรมทางเทคนิค และบทบาทคัดค้าน แล้วสรุปผลรวมเข้าด้วยกัน
    • เมื่อทำแบบนี้ Claude จะสร้าง รายการงานที่ใช้ร่วมกัน จากนั้นสร้างสมาชิกแต่ละคนให้ไปสำรวจประเด็นต่าง ๆ สรุปผล และพยายาม จัดเก็บทีมเมื่อทำงานเสร็จ
  • เทอร์มินัลของผู้นำจะแสดงรายชื่อสมาชิกทั้งหมดและสถานะงาน โดยสามารถใช้ Shift+Up/Down เพื่อเลือกสมาชิกและส่งข้อความโดยตรงได้

การควบคุม Agent team

  • การเลือกโหมดการแสดงผล

    • โหมด In-process: สมาชิกทุกคนทำงานภายในเทอร์มินัลหลัก ใช้ Shift+Up/Down เพื่อเลือกสมาชิกและส่งข้อความได้ ไม่ต้องตั้งค่าเพิ่มเติม
    • โหมด Split panes: สมาชิกแต่ละคนแสดงใน pane แยก ทำให้ดูเอาต์พุตพร้อมกันได้ ต้องใช้ tmux หรือ iTerm2
    • ค่าเริ่มต้น "auto" จะใช้ split pane หากกำลังรันอยู่ใน tmux session ไม่เช่นนั้นจะทำงานแบบ in-process
    • เมื่อตั้งค่าเป็น "tmux" จะเปิด split-pane mode พร้อมตรวจจับ tmux และ iTerm2 อัตโนมัติ
    • สามารถ override ได้ด้วย teammateMode ใน settings.json หรือใช้แฟลก claude --teammate-mode in-process เพื่อตั้งเป็นเซสชันเดี่ยว

  • การกำหนดสมาชิกและโมเดล

    • Claude จะตัดสินใจจำนวนสมาชิกตามลักษณะงานโดยอัตโนมัติ แต่สามารถระบุจำนวนที่แน่นอนและโมเดลเองได้ด้วยคำสั่งอย่าง "Create a team with 4 teammates" (เช่น Sonnet)

  • การบังคับให้อนุมัติแผนก่อน

    • สำหรับงานที่ซับซ้อนหรือมีความเสี่ยง สามารถใช้ โหมดแผนแบบอ่านอย่างเดียว กับสมาชิก เพื่อบล็อกการลงมือทำจนกว่าผู้นำจะอนุมัติ
    • เมื่อสมาชิกทำแผนเสร็จ จะส่งคำขออนุมัติไปยังผู้นำ และเมื่อผู้นำอนุมัติจึงเริ่มลงมือ หากถูกปฏิเสธจะนำ feedback ไปปรับแล้วส่งใหม่
    • เกณฑ์การตัดสินของผู้นำสามารถกำหนดผ่าน prompt ได้ เช่น "อนุมัติเฉพาะแผนที่รวม test coverage"

  • โหมด Delegate

    • จำกัดให้ผู้นำใช้เฉพาะ เครื่องมือสำหรับประสานงาน แทนการลงมือทำเองโดยตรง เช่น spawn สมาชิก ส่งข้อความ ยุติสมาชิก และจัดการ task
    • หลังเริ่มทีมแล้ว กด Shift+Tab เพื่อสลับไปโหมด delegate

  • การสนทนาโดยตรงกับสมาชิก

    • เนื่องจากสมาชิกแต่ละคนเป็น Claude Code session ที่แยกจากกันอย่างสมบูรณ์ จึงสามารถส่งคำสั่งเพิ่มเติม ถามต่อ หรือเปลี่ยนแนวทางได้โดยตรง
    • ในโหมด in-process ให้เลือกด้วย Shift+Up/Down แล้วส่งข้อความ กด Enter เพื่อตรวจดูเซสชัน กด Escape เพื่อหยุดเทิร์นปัจจุบัน และกด Ctrl+T เพื่อสลับการแสดง task list
    • ในโหมด split-pane ให้คลิก pane นั้นเพื่อโต้ตอบโดยตรง

  • การมอบหมายและการ claim task

    • ใช้ รายการงานที่ใช้ร่วมกัน เพื่อประสานงานทั้งทีม โดยสถานะของงานมีสามขั้นคือ pending, in progress, completed
    • สามารถตั้งค่า dependency ระหว่าง task ได้ และ task ที่ยังมี dependency ค้างอยู่จะ claim ไม่ได้
    • ผู้นำสามารถมอบหมาย task โดยชัดเจน หรือให้สมาชิก claim อัตโนมัติ งานถัดไปที่ยังไม่ถูกมอบหมายและไม่ติดบล็อกหลังจากทำงานก่อนหน้าเสร็จ
    • ใช้ file lock เพื่อป้องกันไม่ให้หลายคน claim task เดียวกันพร้อมกัน

  • การยุติสมาชิกและการจัดเก็บทีม

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

วิธีการทำงานภายในของ Agent team

  • เส้นทางการเริ่มทีม

    • ผู้ใช้ร้องขอทีม: อธิบาย task ที่เหมาะกับการทำงานแบบขนานและขอให้สร้าง agent team อย่างชัดเจน
    • Claude เสนอให้ใช้ทีม: หาก Claude เห็นว่าลักษณะงานเหมาะกับการประมวลผลแบบขนาน ก็จะเสนอให้สร้างทีมและดำเนินการหลังผู้ใช้ยืนยัน
    • ทั้งสองกรณีจะไม่มีการสร้างทีมโดยไม่ได้รับการอนุมัติจากผู้ใช้

  • องค์ประกอบสถาปัตยกรรม

    • Team lead: Claude Code session หลัก ทำหน้าที่สร้างทีม spawn สมาชิก และประสานงาน
    • Teammates: อินสแตนซ์ Claude Code แยกต่างหาก แต่ละคนทำ task ที่ได้รับมอบหมาย
    • Task list: รายการงานที่ใช้ร่วมกัน ซึ่งสมาชิกสามารถ claim และทำให้เสร็จได้
    • Mailbox: ระบบส่งข้อความสำหรับการสื่อสารระหว่างเอเจนต์
    • dependency ของ task ถูกจัดการอัตโนมัติ ดังนั้นเมื่อสมาชิกคนหนึ่งทำ task เสร็จ task ที่เคยถูกบล็อกจะถูกปลดบล็อกโดยไม่ต้องแทรกแซงด้วยมือ
    • การตั้งค่าทีมจะถูกเก็บใน ~/.claude/teams/{team-name}/config.json และ task list จะถูกเก็บไว้ในเครื่องที่ ~/.claude/tasks/{team-name}/
    • ใน config มีอาร์เรย์ members เพื่อบันทึกชื่อสมาชิก agent ID และ agent type ของแต่ละคน

  • สิทธิ์การใช้งาน

    • สมาชิกจะเริ่มต้นโดย สืบทอดการตั้งค่าสิทธิ์ จากผู้นำ และหากผู้นำรันด้วย --dangerously-skip-permissions สมาชิกทั้งหมดก็จะใช้แบบเดียวกัน
    • หลังจาก spawn แล้ว สามารถเปลี่ยนโหมดของสมาชิกแต่ละคนได้ แต่ไม่สามารถกำหนดสิทธิ์แยกรายคนตอน spawn ได้

  • Context และการสื่อสาร

    • สมาชิกแต่ละคนมี context window อิสระของตนเอง และตอน spawn จะโหลด project context เช่น CLAUDE.md, MCP server และ skill เหมือนกับเซสชันปกติ
    • ประวัติการสนทนาของผู้นำจะไม่ถูกส่งต่อไปยังสมาชิก โดยจะส่งเฉพาะ prompt ตอน spawn เท่านั้น
    • การส่งข้อความอัตโนมัติ: ข้อความที่สมาชิกส่งจะถูกส่งต่อถึงผู้รับโดยอัตโนมัติ ผู้นำไม่ต้องคอย polling
    • การแจ้งเตือนเมื่อว่าง: เมื่อสมาชิกทำงานเสร็จและหยุดแล้ว ระบบจะแจ้งผู้นำโดยอัตโนมัติ
    • รายการงานที่ใช้ร่วมกัน: เอเจนต์ทุกคนสามารถดูสถานะ task และ claim งานที่พร้อมทำได้
    • วิธีส่งข้อความมีทั้ง message (ถึงสมาชิกคนเดียว) และ broadcast (ถึงทั้งทีม ซึ่งมีต้นทุนเพิ่มตามขนาดทีม จึงควรใช้อย่างระมัดระวัง)

  • การใช้โทเค็น

    • Agent team ใช้ โทเค็นมากกว่าอย่างชัดเจน เมื่อเทียบกับเซสชันเดี่ยว และเพิ่มขึ้นตามจำนวนสมาชิกที่ active
    • สำหรับงานวิจัย รีวิว และการพัฒนาฟีเจอร์ใหม่ ค่าโทเค็นที่เพิ่มขึ้นมักคุ้มค่า แต่สำหรับงาน routine เซสชันเดี่ยวจะคุ้มค่ากว่า

กรณีการใช้งาน

  • รีวิวโค้ดแบบขนาน

    • ผู้รีวิวเพียงคนเดียวมักโฟกัสกับปัญหาได้ทีละประเภท จึงควรแยกเกณฑ์รีวิวเป็นโดเมนอิสระ เช่น ความปลอดภัย ประสิทธิภาพ และ test coverage
    • ให้ผู้รีวิวแต่ละคนใช้ตัวกรองต่างกันกับ PR เดียวกัน แล้วผู้นำสรุปผลทั้งหมดเมื่อเสร็จ

  • การสืบสวนด้วยสมมติฐานแข่งขันกัน

    • เอเจนต์เดี่ยวมักหยุดค้นหาเมื่อพบคำอธิบายหนึ่งแล้ว จึงควรจัดสมาชิกให้มี โครงสร้างเชิงปฏิปักษ์ อย่างชัดเจน
    • สมาชิกแต่ละคนสืบสวนสมมติฐานของตัวเอง พร้อมพยายามหักล้างทฤษฎีของสมาชิกคนอื่นไปพร้อมกัน ในรูปแบบ การถกเถียงเชิงวิทยาศาสตร์
    • ช่วยป้องกัน anchoring bias ที่เกิดจากการสืบสวนแบบลำดับ และทำให้ทฤษฎีที่ยังอยู่รอดมีโอกาสเป็นสาเหตุรากจริงมากขึ้น

แนวปฏิบัติที่ดี

  • ให้บริบทกับสมาชิกอย่างเพียงพอ: แม้ project context จะถูกโหลดให้อัตโนมัติ แต่ประวัติการสนทนาของผู้นำไม่ถูกส่งต่อ ดังนั้นใน prompt ตอน spawn ควรมีรายละเอียดที่เกี่ยวข้องกับงาน
  • กำหนดขนาด task ให้เหมาะสม: ถ้าเล็กเกินไป overhead ในการประสานงานจะมากกว่าประโยชน์ ถ้าใหญ่เกินไปก็เสี่ยงทำงานนานโดยไม่มีการเช็กอินและเสียเปล่า หน่วยงานที่จบในตัวเองพร้อมผลลัพธ์ชัดเจน เช่น ฟังก์ชัน ไฟล์ทดสอบ หรือรีวิว จะเหมาะกว่า
  • หากผู้นำเริ่มลงมือทำแทนสมาชิกโดยตรง ให้สั่งด้วยข้อความว่า "Wait for your teammates to complete their tasks before proceeding"
  • ตอนเริ่มใช้งานครั้งแรก ควรเริ่มจาก งานวิจัยและงานรีวิว ที่มีขอบเขตชัดเจนและยังไม่ต้องเขียนโค้ด เช่น รีวิว PR สำรวจไลบรารี หรือสืบสวนบั๊ก
  • ป้องกันการชนกันของไฟล์: หากสมาชิกสองคนแก้ไฟล์เดียวกัน อาจเกิดการเขียนทับ จึงควรแบ่งงานให้แต่ละคนรับผิดชอบชุดไฟล์ต่างกัน
  • ตรวจสอบความคืบหน้าของสมาชิกเป็นระยะ ปรับทิศทางเมื่อแนวทางไม่เวิร์ก และสรุปผลทันทีเมื่อเริ่มมีผลลัพธ์

การแก้ปัญหา

  • เมื่อไม่เห็นสมาชิกทีม: ในโหมด in-process ให้กด Shift+Down เพื่อวนสมาชิกที่ active ตรวจสอบว่างานซับซ้อนพอสำหรับโครงสร้างทีมไหม หากขอ split pane ให้ตรวจว่า tmux ติดตั้งอยู่ใน PATH แล้วหรือยัง และถ้าใช้ iTerm2 ให้ตรวจว่าติดตั้ง CLI it2 และเปิดใช้งาน Python API แล้ว
  • มี permission prompt มากเกินไป: เนื่องจากคำขอสิทธิ์ของสมาชิกจะ bubble up ไปยังผู้นำ จึงควร อนุมัติงานทั่วไปไว้ล่วงหน้าใน permission settings ก่อน spawn สมาชิก
  • สมาชิกหยุดหลังเกิดข้อผิดพลาด: ตรวจดูเอาต์พุตของสมาชิกคนนั้น แล้วสั่งเพิ่มเติมโดยตรง หรือ spawn สมาชิกทดแทนเพื่อทำงานต่อ
  • ผู้นำหยุดก่อนงานเสร็จ: ให้สั่งผู้นำให้ทำต่อ หรือกำหนดให้รอจนสมาชิกทำเสร็จก่อนเข้าสู่โหมด delegate
  • มี tmux session ที่ถูกทิ้งค้างไว้: หากยังมี tmux session ค้างหลังปิดทีม ให้ตรวจด้วย tmux ls แล้วลบด้วย tmux kill-session -t <session-name>

ข้อจำกัด

  • ไม่สามารถกู้คืน in-process teammates session ได้: /resume และ /rewind จะไม่กู้คืน in-process teammates และหลังการกู้คืน ผู้นำอาจส่งข้อความไปยังสมาชิกที่ไม่มีอยู่แล้ว จึงต้อง spawn สมาชิกใหม่
  • สถานะ task ล่าช้า: หากสมาชิกไม่ทำเครื่องหมายว่างานเสร็จ dependency task อาจยังถูกบล็อกอยู่ ต้องอัปเดตสถานะเองหรือขอให้ผู้นำเร่งสมาชิก
  • การยุติล่าช้า: สมาชิกจะถูกยุติได้ก็ต่อเมื่อคำขอปัจจุบันหรือการเรียกใช้เครื่องมือของตนเสร็จสิ้นแล้วเท่านั้น
  • หนึ่งทีมต่อหนึ่งเซสชันเท่านั้น: หากจะเริ่มทีมใหม่ ต้องจัดเก็บทีมปัจจุบันก่อน
  • ไม่รองรับทีมซ้อนทีม: สมาชิกไม่สามารถสร้างทีมของตัวเองหรือ spawn สมาชิกเพิ่มได้ มีเพียงผู้นำเท่านั้นที่จัดการทีมได้
  • ผู้นำคงที่: เซสชันที่สร้างทีมจะเป็นผู้นำถาวรของทีมนั้น ไม่สามารถเลื่อนสมาชิกเป็นผู้นำหรือโอนความเป็นผู้นำได้
  • กำหนดสิทธิ์ตอน spawn ได้แบบรวมเท่านั้น: สมาชิกทุกคนเริ่มด้วยโหมดสิทธิ์เดียวกับผู้นำ และไม่สามารถกำหนดสิทธิ์แยกรายคนตอน spawn ได้
  • Split pane ต้องใช้ tmux หรือ iTerm2: ไม่รองรับ split-pane mode ใน VS Code integrated terminal, Windows Terminal และ Ghostty

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
kuthia 2026-02-06

สำหรับการออร์เคสตราแบบมัลติเอเจนต์ ดูเหมือนว่าประเด็นสำคัญจะอยู่ที่การรักษาผลลัพธ์เชิงความหมายไว้อย่างไรในกระบวนการบีบอัดคอนเท็กซ์นะครับ เหมือนวิทยาการด้านการรู้คิดเลยครับ
 
GN⁺ 2026-02-06
ความคิดเห็นจาก Hacker News

  • น่าสนใจที่นวัตกรรมในช่วง 1 ปีที่ผ่านมาไหลไปในทางที่ เน้นวิศวกรรม เป็นหลัก
    แม้จะมีแนวคิดใหม่ ๆ อย่าง MCP, agent, skill ออกมาไม่ขาดสาย แต่ปัญหาพื้นฐานอย่าง ภาพหลอน·ความไม่แม่นยำ·บริบทพังทลาย ก็ยังไม่ได้รับการแก้ไข
    ปัญหาแบบนี้ดูเหมือนจะต้องแก้ด้วย งานวิจัยพื้นฐาน มากกว่าวิศวกรรมอย่างเดียว
    การปรับปรุงและการประกาศต่าง ๆ ตอนนี้ให้ความรู้สึกเหมือนเป็นส่วนหนึ่งของ วงจร hype เพื่อรักษาความคาดหวังของนักลงทุน
    พูดตรง ๆ คือเริ่มเหนื่อยกับ narrative เรื่อง AI แล้ว อยากให้ข้ามไปถึงจุดที่ชัดเจนเสียทีว่าเทคโนโลยีนี้มีประโยชน์จริง ๆ ตรงไหน

  • ฟีเจอร์แบบนี้ก็ดูเจ๋งดี แต่ก็สงสัยว่าจะมีสักกี่คนที่เปิดรัน agent ได้ทั้งวัน
    ตอนใช้ Cursor รู้สึกว่า การใช้ token สูงมากจนต้องอัปเกรดเป็น Ultra แต่ก็ยังรู้สึกว่าการใช้งานไม่ได้เพิ่มขึ้นเป็นสัดส่วน
    โชคดีที่ฝั่ง โอเพนซอร์ส LLM กำลังไล่ตามมาเร็ว เลยยังพอมีความหวัง

    • ผมเองยังใช้โควตา Claude Max เดือนละ 200 ครั้งไม่หมดเลย ทั้งที่เขียนโค้ดทุกวันและทำงานค่อนข้างหนัก
    • ของพวกนี้จริง ๆ ยังอยู่ใน ช่วงทดลอง ก็อาจล้มเหลวแบบ Gas Town ได้
    • หลายบริษัทสามารถจ้างวิศวกรจูเนียร์เงินเดือน 150,000 ดอลลาร์ได้ ถ้าค่าสมาชิก AI แพงกว่านั้นก็เป็นปัญหา
      ยิ่งไปกว่านั้น ตอนนี้ที่พูดถึงกันไม่ใช่ Cursor แต่เป็น Claude Code ต่างหาก แนะนำให้ลองใช้ Claude Max มากกว่า
    • คนที่จะรันของแบบนี้ได้ทั้งวัน น่าจะมีแค่ สตาร์ตอัป 2 คนที่ได้เงิน VC
    • Claude Code Max ให้ ความคุ้มค่า 30 เท่าต่อราคา token ดังนั้นถ้าใช้ไม่หมดก็เป็นเรื่องของคุณเอง อาจจะถูกกว่าค่าไฟด้วยซ้ำ

  • ก่อนหน้านี้ Steve Yegge เคยเสนอไอเดีย agent orchestrator ให้บริษัทอย่าง Anthropic
    (Welcome to Gas Town)
    พอเห็นว่า Anthropic ออก Agent Teams มาแล้ว ก็ดูเหมือนว่าพวกเขาจะเตรียมการมาตั้งแต่ตอนนั้น หรือไม่ก็ไปลงเอยที่ข้อสรุปเดียวกัน
    ไม่ว่ายังไงก็น่าสนใจที่วิสัยทัศน์ของ Steve ได้รับการพิสูจน์แล้ว บางทีฤดูกาล “ฝึก polecat” อาจกำลังจะมาถึงก็ได้

    • ผมก็ไม่รู้จัก GasTown หรือ Beeds มาก่อน แต่ก็เคยสร้างอะไรคล้าย ๆ กัน มันเป็น ก้าวถัดไปที่เป็นธรรมชาติมาก
      claude-code-orchestrator
    • ผมเองก็เคยลองทำ โครงสร้าง agent team แบบง่าย ๆ ก่อนกระแส GasTown โดยรัน Claude หลายอินสแตนซ์ใน tmux session และซิงก์ด้วย .claude.lock
      มันทำงานได้ค่อนข้างดี แต่ยังไม่มีประสิทธิภาพมากพอ คอขวดคือความเร็วในการเขียนสเปกและคุณภาพของ QA
    • จริง ๆ แล้วโครงสร้างแบบนี้เป็นแนวคิดที่มีอยู่แล้วใน เฟรมเวิร์ก actor เทียบกับระบบอย่าง Akka ก็ไม่ได้ใหม่อะไร
      พอเห็นว่า LLM provider เพิ่งมาเรียนรู้เรื่องพวกนี้ตอนนี้ ก็รู้สึกว่าพวกเขากำลัง เติบโตแบบเรียลไทม์
      คำว่า Kubernetes for agents ก็ไม่ได้เกินจริง ผมเองก็เชื่อมใช้แบบนั้นในเครื่องเหมือนกัน
    • คิดว่าเป็นไปไม่ได้ที่วิศวกร Anthropic จะไม่รู้ไอเดียแบบนี้ เพราะมีคนพูดกันเยอะตั้งแต่ยุคแรกของ ChatGPT แล้ว
    • จริง ๆ ระบบ multi-agent แบบนี้มีอยู่มากใน arxiv และ GitHub ตั้งแต่ปี 2023
      ตอนนั้นแค่โมเดลยังไม่ฉลาดพอและ context window เล็กเกินไป แต่ตอนนี้มันเป็นไปได้จริงแล้วเท่านั้นเอง

  • ผมใช้เวิร์กโฟลว์ที่ให้ Claude Code หลายอินสแตนซ์ทำงานร่วมกันเป็น tmux-based CLI agent มาสักพักแล้ว
    ฟีเจอร์ orchestration รอบนี้มีประโยชน์กว่ามาก เพราะแชร์ task list ร่วมกันได้ และมี agent หลักคอยประสานงาน
    ใช้ เครื่องมือ tmux-cli เพื่อทำงานร่วมกันระหว่าง agent แบบอัตโนมัติได้

  • ไม่ได้เรียนรู้เรื่องนี้มาจนถึงตอนนี้ เพราะคิดว่าเดี๋ยวมันก็ต้อง มีมาให้ในตัวอยู่แล้ว แต่ตอนนี้น่าจะถึงเวลาลองใช้แล้ว

  • กังวลว่าค่าสมาชิก $20/เดือน ของผมน่าจะอยู่ไม่ถึง 10 นาที

    • ถ้าจ่ายเองในฐานะบุคคล การใช้ Kimi หรือ GLM ดูสมเหตุสมผลกว่า
    • ผมก็คิดเหมือนกัน ว่าสงสัยว่าโครงสร้างแบบนี้จะ สร้างมูลค่าได้จริงหรือเปล่า
    • ในบางงาน Haiku ก็ให้ผลลัพธ์ที่ดีพอสมควร

  • มันดูคล้าย Gas Town

    • ถ้าโปรเจกต์มันไปทาง เพี้ยนหรือเล่นมุก มากเกินไป สุดท้ายก็มักมีโคลนที่จริงจังกว่านิดหน่อยมาชนะ
    • แต่ตอนนี้ polecat หายไปไหนแล้วก็ไม่รู้ ชวนสงสัยว่าอารมณ์ขันของตลาดหายไปหรือเปล่า
    • ไม่รู้ว่า Gas Town คืออะไร แต่ผมก็ใช้โครงสร้างคล้าย Claude Code Agent Teams มาสักพักแล้ว
      ถ้าสร้าง sub-agent จากบทสนทนาหลักเพื่อแยกงาน ก็สามารถทำงานได้นานโดยไม่สูญเสียบริบท
    • ดีไซน์ดูเรียบง่ายกว่า เป็นโครงสร้าง agent ผู้นำหนึ่งตัวกับ worker หลายตัว ดูสะอาดกว่าระบบบทบาทซับซ้อนของ Gas Town
    • แต่ก็เสียดายที่ ไม่มี polecat

  • ผมยังไม่สามารถปล่อยให้ Claude Code รับผิดชอบ งานใหญ่แบบอิสระ ได้
    ถ้าจะรักษาคุณภาพโค้ด ผมยังต้องเข้าไปมีส่วนร่วมกับกระบวนการออกแบบโดยตรง
    agent team กลับอาจเพิ่มภาระในการรีวิวและรีแฟกเตอร์มากขึ้นด้วยซ้ำ

    • ถ้าเข้ารหัสโครงสร้าง codebase และกฎการใช้แพตเทิร์นเป็น skill ก็สามารถให้ sub-agent คอยกำกับสิ่งเหล่านี้ได้
      การแยก agent สำหรับวางแผน·ออกแบบ·QA·รีวิว แล้วให้ทำงานร่วมกันแบบนี้แหละคือแก่นของฟีเจอร์นี้
    • ยังมีวิธีเพิ่มคุณภาพด้วยการสร้าง โมเดลเชิงปฏิปักษ์ ภายใน Claude เช่น ให้ agent หนึ่งแก้ อีก agent หนึ่งตรวจสอบ
    • มนุษย์เองก็แบ่งงานใหญ่เป็นชิ้น ๆ เหมือนกัน ถ้าให้ Claude ตั้ง แผนและเกณฑ์การทดสอบ ไว้ก่อน ก็จะทำงานได้มีประสิทธิภาพขึ้น
    • ในทางปฏิบัติ ทุก ๆ 3~4 ครั้งจะมี 1 ครั้งที่ต้อง ปรับจูนหรือหยุดกลางทาง และมีแต่คนที่ชำนาญเท่านั้นที่สังเกตได้
    • มี งานวิจัย เกี่ยวกับการแบ่งงานและรวมผลลัพธ์ของ LLM อยู่เหมือนกัน
      บทความที่เกี่ยวข้อง

  • ผมกำลังมองหา multi LLM orchestration ที่ใช้ Opus เป็นตัวหลัก และให้ sub-agent เป็น Gemini หรือ Codex

    • มีเครื่องมือที่รองรับโครงสร้างแบบนี้ เช่น Coder-Codex-Gemini, ccg-workflow, claude_code_bridge
      ทั้งหมดเป็นโปรเจกต์ที่ นักพัฒนาชาวจีน ทำ แต่จากที่ลองใช้มาก็ถือว่ายอดเยี่ยมทีเดียว
    • ถ้าใช้ AgentWorkforce/relay ก็สามารถกำหนด LLM ที่ต้องการให้เป็น ลีด/ออร์เคสเตรเตอร์ ได้
      ผมสรุปประสบการณ์ไว้ใน โพสต์บน Twitter
    • ผมใช้ Opus เขียนโค้ดและใช้ Codex รีวิว แต่ละงานจะเรียก review skill เพื่อรัน Codex
      ใช้ โค้ด review skill และ Greptile PR analyzer ควบคู่กันไป
    • ถ้าในอนาคต Cursor รองรับ ฟีเจอร์ทำงานร่วมกันหลายโมเดล แบบนี้ ก็น่าจะมีประโยชน์มากจริง ๆ
    • อย่างในตัวอย่าง Pied-Piper
      ก็สามารถจัดโครงแบบให้ GPT-5.2 Codex Max วางแผน, Opus 4.5 ลงมือทำ, และ Gemini รีวิวได้

  • ตอนที่ผมทำทางเลือกแทน Beads เอง สุดท้ายก็สร้างเสร็จเป็น ระบบ agent ที่ซิงก์กับโปรเจกต์ GitHub ซึ่งมีโครงสร้างคล้ายกัน
    ตั้งใจว่าจะโอเพนซอร์สในเร็ว ๆ นี้ และคิดว่าในระยะยาวการเชื่อมกับ ระบบ ticket จะมีประโยชน์มากกว่า
    ยิ่งมีทางเลือกแบบ agnostic ที่ไม่ผูกกับ agent ตัวใดตัวหนึ่งเพิ่มขึ้นเท่าไร ก็ยิ่งดี