ลูป (loop) คือความสามารถหนึ่งของ Claude Code เครื่องมือ AI ช่วยเขียนโค้ดของ Anthropic ที่ขับเคลื่อนด้วยโมเดล Claude พูดง่าย ๆ คือการให้ agent (ตัว AI ที่ลงมือทำงานให้เอง) ทำงานวนซ้ำเป็นรอบ ๆ ด้วยตัวเอง จนกว่าจะถึงเงื่อนไขหยุด (stop condition) ที่เรากำหนดไว้ นี่เป็นนิยามเฉพาะของ Claude Code เอง ไม่ใช่นิยามที่ใช้กันทั่วทั้งวงการ แต่ที่น่าสนใจคือ จริง ๆ แล้วเราวนลูปแบบนี้อยู่แล้วทุกครั้งที่พิมพ์สั่ง คือพิมพ์ prompt (คำสั่งที่เราพิมพ์บอก) หนึ่งครั้ง Claude ก็ไปทำงานมาให้รอบหนึ่ง เราตรวจ แล้วพิมพ์สั่งต่อ วนไปเรื่อย ๆ โดยมีเราเป็นคนเริ่มรอบใหม่เองทุกครั้ง ดังนั้นการ "ออกแบบลูป" ก็คือการเขียนเงื่อนไขหยุดลงไปครั้งเดียว แล้วปล่อยให้ agent วนเองแทนเรา ไม่ต้องมานั่งกดทีละครั้งอีก

แนวคิดเรื่องลูปทั้งหมดนี้มาจากบทความ Getting started with loops ที่ Claude Code team (@ClaudeDevs) เพิ่งเผยแพร่ ซึ่งแบ่งลูปออกเป็น 4 แบบด้วยเกณฑ์เดียวกัน 4 ข้อ คือ อะไรเป็นตัวเริ่มลูป (trigger), ลูปหยุดด้วยเงื่อนไขอะไร, ใช้เครื่องมือพื้นฐาน (primitive) ตัวไหนของ Claude Code, และเหมาะกับงานประเภทไหน ก่อนจะไล่ทีละแบบ มีหลักสำคัญข้อหนึ่งที่ควรจำไว้ คือไม่ใช่ทุกงานต้องใช้ลูปที่ซับซ้อน ให้เริ่มจากวิธีที่ง่ายที่สุดก่อนเสมอ แล้วค่อยหยิบลูปแบบที่ยากขึ้นมาใช้เฉพาะตอนที่จำเป็นจริง ๆ

เริ่มจากลูปที่เราใช้อยู่ทุกวัน

ลูปแบบแรกชื่อ turn-based loop หรือที่บทความเรียกว่า agentic loop เป็นลูปที่เราคุมเองทุก turn (การสั่งงานหนึ่งรอบ) โดย trigger คือ prompt ทุกครั้งที่เราพิมพ์ และลูปจะหยุดเมื่อ Claude ตัดสินว่างานเสร็จแล้ว หรือเมื่อต้องการข้อมูลเพิ่มจากเรา

ภายในหนึ่ง turn Claude ทำงานหลายขั้นตอนต่อเนื่องในรอบเดียว คือเก็บ context (ข้อมูลแวดล้อมที่เกี่ยวข้อง) ลงมือแก้ ตรวจงานของตัวเอง ทำซ้ำถ้ายังไม่เรียบร้อย แล้วค่อยส่งงานกลับมา เช่น ถ้าสั่งให้มันทำปุ่ม like หนึ่งปุ่ม มันจะอ่านโค้ดเดิม แก้ไข รันเทสต์ แล้วส่งงานที่มันเชื่อว่าใช้ได้กลับมาให้เราตรวจ จากนั้นเราถึงพิมพ์สั่งรอบต่อไป

ลูปแบบนี้เหมาะกับงานสั้น ๆ ที่ไม่ได้เป็นส่วนหนึ่งของกระบวนการหรืองานตามตารางประจำ ถ้าอยากให้แต่ละรอบคุ้มค่าขึ้น ทำได้สองทาง คือเขียน prompt ให้เจาะจงเพื่อลดจำนวน turn ที่ต้องวน และทำให้ขั้นตอนตรวจงานดีขึ้นด้วย skills (ไฟล์ทักษะที่สอนขั้นตอนให้ Claude ทำตามได้)

จุดที่หลายคนมองข้ามคือขั้นตอนตรวจงานนี่แหละ ถ้าปกติเราตรวจงานด้วยมือทุกครั้ง ลองบันทึกขั้นตอนนั้นลงเป็นไฟล์ SKILL.md เพื่อให้ Claude ตรวจงานตัวเองได้ครบขึ้น ยิ่งให้ Claude มีเครื่องมือหรือ connector (ตัวเชื่อมต่อกับเครื่องมือภายนอก) ที่ช่วยให้มันมองเห็นผลลัพธ์ วัดผล หรือลองโต้ตอบกับงานได้ ก็ยิ่งดี และยิ่งวัดผลออกมาเป็นตัวเลข (quantitative) ได้ Claude ก็ยิ่งตรวจงานตัวเองได้ง่ายขึ้น

พอเป้าหมายชัด ก็ไม่ต้องคอยถามว่าดีพอหรือยัง

ลูปแบบที่สองคือ goal-based loop เรียกใช้ด้วยคำสั่ง /goal โดยยังเริ่มจาก prompt ที่เราพิมพ์เองแบบ real-time เหมือนแบบแรก แต่สิ่งที่ต่างออกไปคือเงื่อนไขหยุด เพราะมันจะวนทำงานต่อจนกว่าจะบรรลุเป้าหมาย หรือจนกว่าจะครบจำนวน turn สูงสุดที่เราตั้งเพดานไว้

หัวใจของ /goal คือการบอกล่วงหน้าว่าคำว่า "เสร็จ" หน้าตาเป็นยังไง พอกำหนดเกณฑ์ความสำเร็จไว้ชัด Claude ก็ไม่ต้องมานั่งตัดสินเองทุกรอบว่า "ดีพอหรือยัง" ทุกครั้งที่มันจะหยุด จะมี evaluator model (โมเดลอีกตัวที่ทำหน้าที่ตรวจ) มาเช็คว่าเข้าเงื่อนไขที่ตั้งไว้หรือยัง ถ้ายังไม่ถึงก็ส่งงานกลับไปทำต่อ วนแบบนี้จนบรรลุเป้าหมายหรือครบเพดาน turn ที่กำหนด

ลูปแบบนี้เหมาะกับงานที่มีเกณฑ์จบงาน (exit criteria) ที่ตรวจสอบได้จริง โดยเกณฑ์แบบที่ผลลัพธ์แน่นอน (deterministic) อย่างจำนวนเทสต์ที่ต้องผ่าน หรือคะแนนที่ต้องถึงระดับที่ตั้งไว้ ใช้กับ /goal ได้ผลดีมาก เคล็ดลับคุมให้อยู่มือคือ ตั้งเกณฑ์ความสำเร็จให้ชัด และกำหนดเพดาน turn ไปเลย เช่น "ให้หยุดหลังลองครบ 5 ครั้ง"

งานที่วนมาเป็นรอบ ปล่อยให้ลูปคอยเช็คตามเวลา

ลูปแบบที่สามเปลี่ยนตัว trigger จาก "เราพิมพ์สั่ง" มาเป็น "ช่วงเวลาที่ตั้งไว้ล่วงหน้า" โดยจะวนไปจนกว่าเราจะสั่งยกเลิกเอง หรือจนกว่างานจะเสร็จสมบูรณ์ เช่น PR (pull request ชุดการแก้โค้ดที่รอรวมเข้าโปรเจกต์) merge (รวมเข้าโค้ดหลัก) แล้ว หรือคิวงานว่างหมดแล้ว

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

เครื่องมือของลูปแบบนี้มีสองตัว คือ /loop สั่งให้ Claude Code รัน prompt เดิมซ้ำตาม interval (รอบเวลาที่ตั้งไว้) ที่กำหนด แต่ข้อควรรู้คือมันรันอยู่บนเครื่องของเราเอง ถ้าปิดเครื่องลูปก็หยุด ดังนั้นถ้าอยากให้มันวนต่อแม้ปิดเครื่อง ก็ย้ายขึ้น cloud ด้วยการสร้าง routine (งานที่ตั้งเวลาให้รันเอง) ผ่านคำสั่ง /schedule ส่วนเคล็ดลับประหยัดคือ ตั้งรอบเวลาให้ยาวขึ้นเท่าที่ยอมรับได้ หรือถ้าทำได้ ให้ลูปทำงานตาม event (เหตุการณ์ที่เกิดขึ้นจริงในระบบ) แทนการนับเวลาไปเฉย ๆ

ลูปที่ทำงานเองโดยไม่ต้องมีคนนั่งเฝ้า

ลูปแบบที่สี่คือ proactive loop ที่มี event หรือตารางเวลาเป็น trigger โดยไม่ต้องมีคนคอยกำกับแบบ real-time แต่ละงานย่อยจะจบเมื่อบรรลุเป้าหมายของมันเอง ส่วนตัว routine ทั้งก้อนก็รันไปเรื่อย ๆ จนกว่าเราจะปิดมันเอง

จริง ๆ แล้ว proactive loop ไม่ใช่ของใหม่ทั้งหมด แต่คือการเอาลูปสามแบบก่อนหน้ามาประกอบกับฟีเจอร์อีกสองตัวของ Claude Code คือ auto mode (โหมดที่ให้ทำงานต่อเนื่องได้โดยไม่หยุดถามสิทธิ์) และ dynamic workflows (การจัด agent หลายตัวให้ทำงานประสานกันอัตโนมัติ) ฟีเจอร์ทั้งสองตัวยังอยู่ในสถานะ research preview เมื่อเอาทั้งหมดมารวมกัน ก็ใช้กับงานที่ต้องรันต่อเนื่องนาน ๆ ได้

ลองดูตัวอย่างการประกอบลูปสำหรับจัดการ feedback ที่ไหลเข้ามาเรื่อย ๆ:

1. /schedule รัน routine ที่คอยเช็ครายงานใหม่เป็นรอบ ๆ
2. /goal กำหนดว่างานแต่ละชิ้น "เสร็จ" หน้าตาเป็นยังไง พร้อมใช้ skills บันทึกวิธีตรวจสอบไว้
3. Dynamic workflows คอยจัด agent ให้ไปคัดแยกแต่ละรายงาน ลงมือแก้ แล้วรีวิวการแก้นั้นอีกครั้ง
4. Auto mode ทำให้ทั้งลูปวิ่งได้ต่อเนื่องโดยไม่ต้องหยุดขออนุญาตกลางทาง

proactive loop เหมาะกับงานที่เกิดซ้ำเป็นชุดและนิยามไว้ชัด เช่น รับ bug report (รายงานข้อผิดพลาด), คัดแยก issue (รายการปัญหาที่ต้องแก้), งาน migration (การย้ายหรือแปลงระบบ) หรือการอัปเกรด dependency (ไลบรารีที่โปรเจกต์เรียกใช้) วิธีคุมค่าใช้จ่ายคือ ให้โมเดลที่เล็กและเร็วกว่าเป็นตัวหลักของ routine แล้วดึงโมเดลที่เก่งที่สุดมาใช้เฉพาะจังหวะที่ต้องตัดสินใจจริง ๆ (judgment call)

สรุปสั้น ๆ เลือกลูปให้ตรงงาน

พอเห็นครบทั้ง 4 แบบแล้ว จะสังเกตว่ามันไล่จากแบบที่เราคุมเองมากที่สุด ไปจนถึงแบบที่ปล่อยให้ agent ทำงานเองมากที่สุด เลือกให้ตรงงานได้จากตารางนี้:

ให้ลูปวนเร็วขึ้น โดยงานไม่หลุดมาตรฐาน

ยิ่งปล่อยให้ลูปวนเองมากขึ้น คำถามที่ตามมาทันทีคือ แล้วคุณภาพงานจะไม่หลุดเหรอ บทความให้แนวทางไว้หลายข้อ:

• รักษา codebase (กองโค้ดทั้งโปรเจกต์) ให้สะอาดไว้ก่อน เพราะ Claude มักทำตามแบบแผนและธรรมเนียมการเขียนโค้ด (pattern และ convention) ที่มีอยู่แล้วในโปรเจกต์
• ให้ Claude มีวิธีตรวจงานตัวเอง ด้วยการเขียนนิยามว่า "ดี" หน้าตาเป็นยังไงเอาไว้ใน skills
• ทำให้เอกสาร (docs) เข้าถึงง่าย เพราะ doc ล่าสุดของ framework หรือ library (เครื่องมือและชุดโค้ดสำเร็จรูปที่โปรเจกต์เรียกใช้) ช่วยให้มันเขียนโค้ดได้ตรงตามแนวทางล่าสุด
• ใช้ agent อีกตัวมาช่วยรีวิวโค้ด เพราะ reviewer ที่มองงานด้วย context แยกจาก agent ตัวที่ลงมือทำจะไม่ลำเอียงตามเหตุผลของอีกฝ่าย ใช้ skill /code-review ที่มีมาให้ หรือ Code Review for GitHub ก็ได้

คุมค่า token ไม่ให้ลูปกินงบบานปลาย

ลูปที่ไม่มีขอบเขตชัดคือลูปที่กิน token (หน่วยที่ใช้คิดค่าประมวลผลของโมเดล) ไปเรื่อย ๆ โดยไม่รู้ตัว ดังนั้นทุกลูปควรมีขอบเขตที่กำหนดไว้ชัดเจน หลักคุมค่าใช้จ่ายมีดังนี้:

• เลือก primitive และโมเดลให้พอดีกับงาน งานเล็ก ๆ ไม่จำเป็นต้องใช้หลาย agent หรือหลายลูป บางงานใช้โมเดลที่ถูกและเร็วกว่าก็พอ
• กำหนดเกณฑ์ความสำเร็จและเงื่อนไขหยุดให้ชัด ระบุว่า "เสร็จ" หน้าตาเป็นยังไงให้เจาะจง Claude จะได้ไปถึงคำตอบเร็วขึ้น แต่ก็อย่าให้เร็วจนงานไม่ครบ
• ทดลองสเกลเล็กก่อน (pilot) เพราะ dynamic workflows สามารถแตก agent ย่อยออกมาได้เป็นร้อยตัว ควรวัดการใช้งานบนงานเล็กก่อนขยาย
• ใช้สคริปต์กับงานที่ผลลัพธ์แน่นอน เพราะการรันสคริปต์ถูกกว่าการให้ Claude นั่งคิดใหม่ทีละขั้น เช่น PDF skill ที่มีสคริปต์กรอกฟอร์มแนบมาให้รันซ้ำได้เลย แทนที่จะให้ Claude คิดโค้ดขึ้นใหม่ทุกครั้ง
• อย่าตั้งให้ routine รันบ่อยเกินจำเป็น ตั้งรอบเวลาให้พอดีกับความถี่ที่สิ่งที่เฝ้าดูจะเปลี่ยนแปลงจริง ๆ

อยากรู้ว่าลูปกิน token ไปเท่าไหร่ ก็มีคำสั่งไว้ส่องได้หลายตัว เช่น /usage จะแจกแจงการใช้งานล่าสุดแยกตาม skills, subagent (agent ย่อยที่ถูกเรียกมาช่วยงาน) และ MCP (ช่องเชื่อมต่อเครื่องมือภายนอก) ถ้าพิมพ์ /goal เปล่า ๆ โดยไม่ใส่ argument (ค่าที่ป้อนต่อท้ายคำสั่ง) มันจะโชว์จำนวน turn และ token ที่ใช้ไปแล้ว ส่วน /workflows โชว์ token ของแต่ละ agent และให้เราสั่งหยุด agent ตัวไหนก็ได้ทุกเมื่อ ถ้าอยากลงลึกกว่านี้ บทความแนะนำให้อ่านหน้า running agents in parallel รวมถึงหน้า loop, schedule, goal และ dynamic workflows ใน Claude Code Docs โดยตรง

ลองให้ลูปจัดการงานคอขวดของคุณสักงาน

วิธีเริ่มที่ดีที่สุดไม่ใช่การรื้อทุกอย่างมาทำเป็นลูป แต่คือหยิบงานที่คุณทำอยู่แล้วมาดูสักงาน โดยเลือกงานที่ทุกอย่างต้องมารอให้คุณทำคนเดียว แล้วถามตัวเองสามข้อเกี่ยวกับงานนั้น:

1. เขียน verification check (วิธีตรวจว่างานทำถูกต้องหรือยัง) ให้งานนี้ได้ไหม ถ้าได้ ลองใส่ลงใน skill ให้ turn-based loop ตรวจเอง
2. เป้าหมายของงานนี้ชัดพอที่จะบอก /goal ล่วงหน้าได้หรือยัง
3. งานนี้มาตามตารางเวลา หรือมาจาก event ภายนอกหรือเปล่า ถ้าใช่ นี่คือที่ทางของ /loop, /schedule หรือ proactive loop

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

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

---

ที่มา: บทความ Getting started with loops จาก Claude Code team (@ClaudeDevs)