1 คะแนน โดย ragingwind 3 시간 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp

แนะนำ Dynamic Workflows ของ Claude Code

บทความนี้เผยแพร่โดยทีม Claude Code ของ Anthropic (Thariq Shihipar, Sid Bidasaria) เพื่ออธิบายฟีเจอร์ Dynamic Workflows ที่เพิ่งเพิ่มเข้ามาใน Claude Code โดย Dynamic Workflows คือแนวทางที่ Claude เขียนโครงสร้างการรันของตัวเอง (harness) ขึ้นมาแบบสด ๆ ในรูปแบบไฟล์ JavaScript ให้เหมาะกับงาน แล้วใช้มันประสานงานซับเอเจนต์หลายตัว แม้ harness พื้นฐานของ Claude Code เดิมจะเหมาะกับงานเขียนโค้ดอยู่แล้ว แต่เมื่อเจองานที่ใช้เวลานาน ต้องทำแบบขนานขนาดใหญ่ หรือจำเป็นต้องมีการตรวจสอบเชิงโต้แย้ง ก็มีข้อจำกัดอยู่ และหัวใจของแนวคิดนี้คือให้ Claude สร้าง harness แบบเฉพาะทางขึ้นมาเองเพื่อแก้ปัญหานั้น

ที่มาของการนำมาใช้และวิธีการทำงาน

  • ข้อจำกัดของคอนเท็กซ์เดี่ยว : เมื่อวางแผนและลงมือทำพร้อมกันในหน้าต่างคอนเท็กซ์เดียว จะมีรูปแบบความล้มเหลว 3 แบบ ได้แก่ agentic laziness ที่ทำงานไปครึ่งทางแล้วประกาศว่าเสร็จ, self-preferential bias ที่ประเมินผลงานของตัวเองในทางเข้าข้างตัวเอง, และ goal drift ที่เป้าหมายดั้งเดิมค่อย ๆ เลือนหายไประหว่างการบีบอัดคอนเท็กซ์
  • โครงสร้างการทำงาน : ระบบจะรันไฟล์ JavaScript เพื่อสร้างและประสานงานซับเอเจนต์ พร้อมใช้ฟังก์ชันมาตรฐานอย่าง JSON, Math, Array ได้ เวิร์กโฟลว์ยังเป็นผู้กำหนดเองด้วยว่าจะใช้โมเดลชนิดใดกับแต่ละซับเอเจนต์ (เช่น Sonnet, Opus) และจะแยก worktree หรือไม่ หากหยุดกลางคันก็สามารถทำต่อได้ผ่านการ resume session
  • วิธีเรียกใช้ : ขอให้ Claude สร้างเวิร์กโฟลว์ให้ หรือใช้คำกระตุ้น "ultracode"

สรุปแพตเทิร์นหลัก (Patterns)

  • Classify and Route : ใช้เอเจนต์ตัวจำแนกประเภทตรวจว่างานเป็นแบบใด ก่อนส่งต่อไปยังเอเจนต์หรือขั้นตอนประมวลผลที่เหมาะสมกับประเภทนั้น และยังใช้เป็นตัวจำแนกผลลัพธ์ในขั้นตอนสุดท้ายได้ด้วย
  • Fan-out and Synthesize : แยกงานใหญ่เป็นหน่วยย่อยหลายส่วน รันเอเจนต์แยกสำหรับแต่ละส่วน แล้วค่อยรวมผลทั้งหมดกลับมาเป็นหนึ่งเดียวในขั้นตอน synthesize เหมาะกับงานย่อยจำนวนมากที่ต้องการคอนเท็กซ์สะอาดแยกจากกัน
  • Adversarial Verification : จับคู่แต่ละเอเจนต์ทำงานกับเอเจนต์ตรวจสอบอีกตัว เพื่อโต้แย้งและตรวจความถูกต้องของผลลัพธ์ตาม rubric (เกณฑ์ประเมิน)
  • Generate and Filter : สร้างไอเดียจำนวนมากก่อน แล้วใช้ rubric และการตรวจสอบช่วยคัดกรอง ตัดรายการซ้ำ และเหลือไว้เฉพาะตัวเลือกคุณภาพสูงสุด
  • Tournament : ให้เอเจนต์ N ตัวแข่งขันทำงานเดียวกันด้วยแนวทางต่างกัน แล้วใช้เอเจนต์กรรมการตัดสินผู้ชนะด้วยการเปรียบเทียบเป็นคู่ (pairwise comparison) ซึ่งอธิบายว่ามีความน่าเชื่อถือกว่าการให้คะแนนแบบสัมบูรณ์
  • Loop Until Convergence : สำหรับงานที่ไม่รู้ปริมาณล่วงหน้า จะวนสร้างเอเจนต์ใหม่ไปเรื่อย ๆ จนกว่าจะไม่มีการค้นพบหรือข้อผิดพลาดใหม่เพิ่มเติม

สรุปกรณีการใช้งาน (Use Cases)

  • รีแฟกเตอร์และย้ายระบบขนาดใหญ่ : แยกงานตาม callsite, เทสต์ที่ล้มเหลว, หรือระดับโมดูล แล้วให้ซับเอเจนต์ในแต่ละ worktree แก้ไข จากนั้นมีเอเจนต์อีกตัวรีวิวเชิงโต้แย้งก่อนรวมกลับเข้าด้วยกัน มีกรณีใช้งานจริงในการเขียนใหม่จาก Zig ไปเป็น Rust และหากสั่งให้หลีกเลี่ยงคำสั่งที่ใช้ทรัพยากรหนัก ก็สามารถดันความขนานได้สูงขึ้น
  • Deep research (สกิล /deep-research) : กระจายการค้นหาเว็บแบบ fan-out เพื่อรวบรวมแหล่งข้อมูล ตรวจสอบคำอ้างด้วยการยืนยันเชิงโต้แย้ง แล้วสังเคราะห์เป็นรายงานพร้อมการอ้างอิง ยังประยุกต์ใช้กับการเขียนรายงานสถานะบน Slack หรือสำรวจโค้ดเบสเชิงลึกได้ด้วย
  • การตรวจสอบข้อเท็จจริง (Fact-Checking) : เริ่มจากเอเจนต์ที่ระบุคำกล่าวอ้างเชิงข้อเท็จจริงทั้งหมดในรายงาน จากนั้นซับเอเจนต์ตรวจสอบแต่ละคำกล่าวอ้างกับแหล่งที่มา และมีเอเจนต์ตรวจสอบอีกชั้นประเมินคุณภาพของแหล่งข้อมูลด้วย
  • การจัดเรียงและจัดอันดับเชิงคุณภาพ : งานที่ประมวลผลรวดเดียวได้ยาก เช่น การเรียงตั๋วซัพพอร์ตมากกว่า 1,000 บรรทัดตามระดับความรุนแรง สามารถแก้ด้วยไปป์ไลน์แบบ tournament ที่เปรียบเทียบเป็นคู่ หรือแบ่งเป็นบัคเก็ตเพื่อประมวลผลแบบขนานแล้วค่อยรวมผล
  • การตรวจสอบกฎและการทำ CLAUDE.md อัตโนมัติ : ตั้งเอเจนต์ตรวจสอบแยกตามกฎเพื่อจับสิ่งที่ตกหล่น และใช้อีกเอเจนต์ในบทบาทผู้ตั้งข้อสงสัยเพื่อตรวจความสมเหตุสมผลของกฎนั้นเอง ในทางกลับกัน ยังสามารถจัดกลุ่มรูปแบบการแก้ไขที่เกิดซ้ำจากเซสชันล่าสุดและโค้ดรีวิว เพื่อสรุปกฎใหม่โดยอัตโนมัติได้
  • ดีบักความล้มเหลวที่เกิดเป็นพัก ๆ และการวิเคราะห์หลังเหตุการณ์ : ให้เอเจนต์อิสระตั้งสมมติฐานจากหลักฐานที่แยกจากกัน เช่น log, ไฟล์, ข้อมูล แล้วให้คณะผู้ตรวจสอบและผู้โต้แย้งประเมินสมมติฐานแต่ละข้อ ใช้ได้ไม่เฉพาะกับโค้ด แต่รวมถึงการวิเคราะห์สาเหตุยอดขายตก หรือปัญหาใน data pipeline ด้วย
  • Triage และจัดการแบ็กล็อก : จำแนกคิวซัพพอร์ตและบั๊กรายงาน ลบรายการซ้ำกับรายการเดิม แล้วตัดสินใจแก้อัตโนมัติหรือส่งต่อให้มนุษย์ รูปแบบ quarantine ที่แยกเอเจนต์ซึ่งอ่านคอนเทนต์ภายนอกที่ไม่น่าเชื่อถือ ออกจากเอเจนต์ที่ทำการกระทำซึ่งมีสิทธิ์จริง เป็นแนวทางที่แนะนำ และเมื่อใช้ร่วมกับ /loop ก็สามารถทำงานแบบต่อเนื่องได้
  • การสำรวจเชิงสร้างสรรค์และการประเมิน (Eval) : ในงานที่มีรสนิยมเข้ามาเกี่ยวข้อง เช่น ดีไซน์หรือการตั้งชื่อ สามารถสร้างหลายตัวเลือกก่อน แล้วให้เอเจนต์รีวิวใช้ rubric ให้คะแนนและคัดเลือก อีกทั้งยังใช้กับการประเมินแบบเบา ๆ เพื่อให้คะแนนและปรับปรุงคุณภาพของสกิลเองได้
  • Model Routing : ใช้เอเจนต์ตัวจำแนกตรวจความซับซ้อนของงานล่วงหน้า แล้วเลือกส่งต่อไปยัง Sonnet หรือ Opus ตามความเหมาะสม

ข้อดีและจุดแตกต่าง

  • จุดแตกต่าง : เวิร์กโฟลว์แบบ static ที่สร้างด้วย Claude Agent SDK หรือ claude -p เดิม จำเป็นต้องเขียนให้เป็นงานอเนกประสงค์เพื่อรองรับกรณีทั่วไป แต่ Dynamic Workflows แตกต่างตรงที่ Claude จะเขียน harness แบบเฉพาะงานขึ้นมาทันทีในตอนนั้น
  • ข้อดี : เมื่อมีเอเจนต์หลายตัวแยกคอนเท็กซ์กัน แต่ละตัวจะโฟกัสกับเป้าหมายของตัวเอง ทำให้ลดปัญหาความขี้เกียจ การเข้าข้างผลลัพธ์ของตัวเอง และ goal drift ได้ในเชิงโครงสร้าง อีกทั้งยังมีความพร้อมในด้านการใช้งานจริง เช่น การ resume session ที่ถูกขัดจังหวะ การกำหนดงบ token ("use 10k tokens") การใช้ร่วมกับ /goal และ /loop ตลอดจนการกดปุ่ม "s" เพื่อบันทึกและแชร์ผ่านไดเรกทอรี ~/.claude/workflows หรือผ่านสกิล
  • ข้อเสียและข้อควรระวัง : การใช้ token อาจเพิ่มขึ้นมาก จึงไม่เหมาะกับทุกงาน ผู้เขียนเองก็ชี้ชัดว่า งานเขียนโค้ดทั่วไปไม่ได้จำเป็นต้องมีคณะรีวิว 5 คนเสมอไป และแนะนำให้ถามตัวเองก่อนว่า "จำเป็นต้องใช้การประมวลผลมากขึ้นจริงหรือไม่" แนวปฏิบัติที่ดีที่สุดก็ยังอยู่ระหว่างการก่อตัว

Dynamic Workflows ทำให้ Claude Code ขยับจากการเป็นผู้ช่วยเขียนโค้ดเดี่ยว ไปสู่เมตาออร์เคสเตรเตอร์ที่คอยประสานงานเอเจนต์หลายตัว นี่เป็นแนวทางที่อยู่กึ่งกลางระหว่างไปป์ไลน์แบบ static กับเอเจนต์อัตโนมัติเต็มรูปแบบ และน่าจะเห็นประสิทธิภาพเด่นชัดในงานโครงสร้างระยะยาว เช่น การย้ายโค้ด, deep research, triage และการวิเคราะห์หลังเหตุการณ์ อย่างไรก็ตาม ด้วยต้นทุน token ที่สูงและแนวปฏิบัติที่ยังไม่ตกผลึก จึงควรพิจารณาความเหมาะสมของแต่ละแพตเทิร์นอย่างรอบคอบ และเริ่มจาก "quick workflow" ขนาดเล็กก่อน

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น