เจาะลึก Claude Code Workflows การทำงานและปัญหาที่พบ
วิเคราะห์การทำงานของ Claude Code Workflows และปัญหาการจัดการโมเดล พร้อมข้อจำกัดด้านต้นทุนโทเค็น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Claude Code Workflows สร้างสคริปต์ในรันไทม์พิเศษที่ห้ามใช้ฟังก์ชัน Date.now()
- การจัดการกระบวนการทำโดยตัวฮาร์ดเนสของ Claude Code ไม่ใช่ตัวโมเดลหลัก
- การเปิดใช้งาน ultracode อาจทำให้ต้นทุนโทเค็นพุ่งสูงขึ้นอย่างรวดเร็ว
- ข้อแนะนำหลักจากเอกสารระบุว่ารูปแบบไปป์ไลน์ดีกว่าการรันแบบขนาน
เครื่องมือ Workflow ทำหน้าที่สร้างสคริปต์ซึ่งเป็นภาษาย่อยของ JavaScript โดยจะรันอยู่ภายในรันไทม์พิเศษ สคริปต์นี้ถูกครอบด้วยฟังก์ชัน async ทำให้สามารถใช้ top-level async / await และ return ได้ แต่จะไม่อนุญาตให้ใช้ฟังก์ชันบางอย่างเช่น Date.now() เนื่องจากจะไปทำลายความสามารถในการทำงานต่อ (resummability)
สคริปต์ดังกล่าวมีชุดคำสั่งพื้นฐานที่ควบคุมชั้นการจัดระเบียบ โดยแบ่งเวิร์กโฟลว์ออกเป็นเฟสต่างๆ เช่น ดีไซน์ การพัฒนา และการตรวจสอบ ซึ่งเป็นเพียงการแบ่งตามการแสดงผลเป็นหลัก ด้านการจัดการแบบมัลติเอเจนต์นั้นไม่ใช่เรื่องใหม่ แต่จุดที่ต่างออกไปคือกระบวนการนี้ถูกควบคุมโดย Claude Code เอง ไม่ใช่ตัว Claude หลังจากที่สคริปต์ถูกสร้างและเริ่มรันแล้ว ฮาร์ดเนส (แอปพลิเคชัน Claude Code) จะเป็นผู้จัดการการทำงานทั้งหมด ขณะที่เซสชันหลักของ Claude จะใช้โทเค็นน้อยมากหรืออาจเป็นศูนย์หากมันพักการทำงาน
จุดนี้แตกต่างจาก Agent Teams ที่ Claude ต้องทำหน้าที่เป็นหัวหน้าทีมคอยควบคุมกิจกรรมของเอเจนต์อื่นๆ ทั้งหมด และยังดีกว่าการใช้กลุ่มย่อยอิสระเนื่องจากซับเอเจนต์ต้องคอยรายงานกลับมาที่ Claude ทำให้เกิดกระบวนการส่งต่อที่ Claude ต้องเข้ามาจัดการตรงกลาง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การเปลี่ยนแปลงนี้ถือเป็นการเปลี่ยนผ่านครั้งสำคัญ ไม่ใช่แค่รูปแบบที่ดีกว่า เนื่องจากระบบฮุกทำงานนอกลูปของเอเจนต์ โดยไม่เผาผลาญหน้าต่างบริบทของเซสชันหลัก และไม่ต้องพึ่งพาโมเดลในการตัดสินใจที่ยากลำบากในขณะที่เอเจนต์กลุ่มใหญ่ทำงานระยะยาว อย่างไรก็ตาม เวิร์กโฟลว์มักถูกมองว่าใช้งานจริงได้ยากและมีค่าใช้จ่ายสูง ปัจจุบันปลั๊กอิน Claude Code อนุญาตให้ผู้ใช้นำเวิร์กโฟลว์ที่บันทึกไว้มาใช้งานได้ แต่แหล่งข้อมูลส่วนใหญ่กลับไม่ได้ทำเช่นนั้น โดยมักจะใช้งานระบบจำลอง ultracode หรือพอร์ตเวิร์กโฟลว์ไปยังระบบอื่นแทน
การวิเคราะห์เชิงลึกชี้ให้เห็นว่า การเปลี่ยนมาให้ฮาร์ดเนสจัดการเวิร์กโฟลว์แทนที่จะให้โมเดล AI ควบคุมเองโดยตรง เป็นความพยายามแก้ปัญหาคอขวดด้านบริบท (Context Window) และช่วยประหยัดโทเค็นในงานระยะยาว อย่างไรก็ตาม ความท้าทายหลักอยู่ที่การที่ผู้ใช้งานหรือแม้แต่ตัว AI เองยังคงเผลอปล่อยให้เกิดการใช้ทรัพยากรเกินจำเป็นหากมีการตั้งค่าหรือคำสั่งกระตุ้นที่ไม่รัดกุมพอ
ปัญหาสำคัญประการหนึ่งในคำจำกัดความของ Workflow คือการเลือกโมเดลในแต่ละเฟส โดยค่าเริ่มต้นระบบจะละเว้นการระบุและให้สืบทอดโมเดลจากเซสชันหลัก ซึ่งมักจะถูกต้องที่สุด คำแนะนำคือให้ตั้งค่าโมเดลเฉพาะเมื่อมั่นใจจริงๆ เท่านั้น แต่ในทางปฏิบัติ โมเดลอย่าง Fable หรือ Opus มักจะละเลยคำแนะนำนี้หากไม่ได้รับคำสั่งอย่างเจาะจงทุกครั้ง ทำให้อาจต้องเขียนโค้ดฮาร์ดโค้ดไว้หากต้องการใช้โมเดลที่ต่างออกไป
นอกจากนี้ เมื่อเปิดใช้งาน ultracode สามัญสำนึกเรื่องต้นทุนโทเค็นมักจะถูกมองข้าม ระบบฮาร์ดเนสยังไม่สามารถแยกแยะระหว่างการเอ่ยถึง (mention) กับการใช้งานจริงได้ ทำให้ข้อความที่มีคำว่า ultracode ถูกกระตุ้นการทำงานขึ้นมาโดยไม่จำเป็น ประเด็นสำคัญอีกข้อจากเอกสารคือคำเตือนที่ระบุว่า "ไปป์ไลน์ดีกว่าการทำงานแบบขนาน" เนื่องจากการทำงานแบบขนานที่มีสิ่งกีดขวาง (barrier latency) จะทำให้เวลาของเอเจนต์ที่ทำงานเร็วต้องสูญเปล่าไปกับการรอคอยเอเจนต์ที่ช้าที่สุด
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น