เริ่มต้นใช้งานลูป

• แทนที่จะสั่ง coding agent ด้วยพรอมป์ต์ทุกครั้ง กำลังเปลี่ยนไปใช้รูปแบบการทำงานของเอเจนต์ที่ วนรอบการทำงานซ้ำจนกว่าจะเป็นไปตามเงื่อนไขหยุด
• ทีม Claude Code จัดประเภทลูปตาม 4 เกณฑ์ ได้แก่ วิธีการทริกเกอร์, วิธีการหยุด, primitive ที่ใช้, ประเภทงานที่เหมาะสม
• ประเภทลูปหลักประกอบด้วย 4 แบบคือ Turn-based, Goal-based, Time-based, Proactive
• ไม่ใช่ทุกงานที่ต้องใช้ลูปซับซ้อน โดยควร เริ่มจากวิธีที่ง่ายที่สุดก่อน แล้วค่อยเลือกใช้แพตเทิร์นตามความเหมาะสม
• คุณภาพของผลลัพธ์จากลูปขึ้นอยู่กับระบบแวดล้อม จึงต้องให้ความสำคัญกับ การรักษาคุณภาพโค้ดและการจัดการการใช้โทเค็น

---

ความหมายของลูปและเกณฑ์การจัดประเภท

• ทีม Claude Code ให้นิยามลูปว่าเป็น เอเจนต์ที่ทำซ้ำวงจรการทำงานจนกว่าจะเป็นไปตามเงื่อนไขหยุด
• เสนอเกณฑ์ 4 ข้อสำหรับการจำแนกลูป
  • ถูกทริกเกอร์อย่างไร
  • หยุดอย่างไร
  • ใช้ Claude Code primitive อะไรบ้าง
  • เหมาะที่สุดกับงานประเภทใด
• ไม่จำเป็นต้องใช้ลูปที่ซับซ้อนเสมอไป โดยควร ให้ความสำคัญกับวิธีแก้ที่เรียบง่ายก่อน แล้วค่อยเลือกใช้แพตเทิร์นตามต้องการ

ลูปแบบ Turn-based

• ถูกทริกเกอร์ด้วย พรอมป์ต์จากผู้ใช้ และจะหยุดเมื่อ Claude ตัดสินว่างานเสร็จแล้ว หรือเมื่อจำเป็นต้องมีบริบทเพิ่มเติม
• เหมาะกับ งานระยะสั้น ที่ไม่ได้อยู่ในกระบวนการประจำหรือกำหนดเวลาใด ๆ
• วิธีจัดการคือ เขียนพรอมป์ต์ให้ชัดเจน และลดจำนวนเทิร์นด้วยการปรับปรุงการตรวจสอบผ่าน skills
• ทุกพรอมป์ต์เริ่มต้นลูปแบบแมนนวลที่ผู้ใช้สั่งในแต่ละเทิร์น ซึ่งเรียกว่า agentic loop
  • Claude รวบรวมบริบท → ลงมือทำ → ตรวจสอบงาน → ทำซ้ำหากจำเป็น → ตอบกลับ
  • ตัวอย่าง: เมื่อขอให้สร้างปุ่ม like ระบบจะอ่านโค้ด แก้ไข รันทดสอบ แล้วส่งผลกลับ จากนั้นผู้ใช้ตรวจสอบด้วยตนเองและเขียนพรอมป์ต์ถัดไป
• ขั้นตอนการตรวจสอบสามารถเข้ารหัสกระบวนการแบบแมนนวลไว้ใน SKILL.md เพื่อขยายขอบเขตการตรวจสอบด้วยตนเองของ Claude
  • ต้องมีเครื่องมือหรือคอนเน็กเตอร์ที่ช่วยให้ดูผลลัพธ์ วัดผล หรือโต้ตอบได้
  • ยิ่งเป็นการตรวจสอบเชิงปริมาณ ก็ยิ่งตรวจสอบด้วยตนเองได้ง่าย

• ตัวอย่าง SKILL.md (verify-frontend-change)

  • กฎสำหรับ ตรวจสอบแบบ end-to-end ก่อนประกาศว่าการเปลี่ยนแปลง UI เสร็จสมบูรณ์
  • ห้ามรายงานว่าเสร็จเพียงเพราะแก้ไขไฟล์สำเร็จ ต้องตรวจสอบเหมือนผู้รีวิวที่เป็นมนุษย์
    • เริ่ม dev server แล้วเปิดหน้าที่แก้ไขในเบราว์เซอร์
    • โต้ตอบกับองค์ประกอบที่เปลี่ยนด้วยตนเอง (คลิกปุ่ม, input, toggle) ตรวจดูการเปลี่ยนสถานะ และเก็บภาพหน้าจอก่อน-หลัง
    • ตรวจใน browser console ว่าจำนวน error และ warning ใหม่เป็น ศูนย์
    • รัน performance trace และตรวจ Core Web Vitals ด้วย Chrome Devtools MCP
  • หากขั้นตอนไหนล้มเหลว ให้แก้ไขแล้วเริ่มใหม่ตั้งแต่ข้อ 1 และ ห้ามส่งคืนงานในสถานะที่ตรวจสอบเพียงบางส่วน

ลูปแบบ Goal-based (/goal)

• ถูกทริกเกอร์ด้วย พรอมป์ต์แบบแมนนวล แบบเรียลไทม์ และหยุดเมื่อบรรลุเป้าหมายหรือถึงจำนวนเทิร์นสูงสุด
• เหมาะกับงานที่มี เกณฑ์สิ้นสุดที่ตรวจสอบได้
• วิธีจัดการคือกำหนดเงื่อนไขความสำเร็จให้ชัดเจน และตั้งเพดานจำนวนเทิร์นแบบชัดแจ้ง เช่น "ลอง 5 ครั้งแล้วหยุด"
• ในงานซับซ้อนที่ทำไม่จบในเทิร์นเดียว เอเจนต์จะทำงานได้ดีขึ้นเมื่อ วนปรับปรุงซ้ำ (iterate)
• เมื่อกำหนดสถานะเสร็จสมบูรณ์ด้วย /goal แล้ว Claude จะไม่หยุดก่อนเวลาเพียงเพราะคิดว่า "ดีพอแล้ว"
  • ทุกครั้งที่ Claude พยายามหยุด evaluator model จะตรวจสอบว่าเงื่อนไขครบหรือยัง และจะให้ทำต่อจนกว่าจะบรรลุเป้าหมายหรือถึงจำนวนเทิร์นที่กำหนด
  • เกณฑ์แบบกำหนดแน่นอน เช่น จำนวนเทสต์ที่ผ่าน หรือค่า threshold ของคะแนนเฉพาะ มักได้ผลดี
• ตัวอย่าง
  • /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

ลูปแบบ Time-based (/loop และ /schedule)

• ถูกทริกเกอร์ตาม ช่วงเวลาที่กำหนด และหยุดเมื่อผู้ใช้ยกเลิก หรืองานเสร็จสิ้นแล้ว (เช่น merge PR หรือเคลียร์คิวหมด)
• เหมาะกับ งานที่ทำซ้ำ หรือการเชื่อมต่อกับสภาพแวดล้อม/ระบบภายนอก
• วิธีจัดการคือกำหนดช่วงเวลาให้ห่างขึ้น หรือเปลี่ยนไปใช้ การตอบสนองตามเหตุการณ์ แทนการอิงเวลา
• งาน agentic บางอย่างมีลักษณะวนซ้ำ โดยตัวงานเหมือนเดิมแต่เปลี่ยนแค่อินพุต เช่น สรุปข้อความ Slack ทุกเช้า
• งานที่พึ่งพาระบบภายนอกสามารถเชื่อมต่อได้โดยตรวจสอบเป็นช่วง ๆ และตอบสนองเมื่อมีการเปลี่ยนแปลง เช่น PR ที่มี code review หรือ CI ล้มเหลว
• /loop จะ รันพรอมป์ต์ซ้ำ ตามช่วงเวลาที่กำหนด
  • /loop 5m check my PR, address review comments, and fix failing CI
• /loop ทำงานบนคอมพิวเตอร์ของผู้ใช้และจะหยุดเมื่อออกจากระบบ ส่วน /schedule สามารถสร้าง routine แล้ว ย้ายไปทำงานบนคลาวด์ ได้

ลูปแบบ Proactive

• ถูกทริกเกอร์ด้วย เหตุการณ์หรือกำหนดเวลา โดยไม่มีการแทรกแซงจากมนุษย์แบบเรียลไทม์
• แต่ละงานจะจบเมื่อบรรลุเป้าหมาย ส่วนตัว routine เองจะทำงานต่อไปจนกว่าผู้ใช้จะปิด
• เหมาะกับ โฟลว์งานซ้ำที่นิยามไว้ชัดเจน เช่น รายงานบั๊ก การจัดหมวดหมู่ issue การย้ายระบบ หรือการอัปเกรด dependency
• วิธีจัดการคือส่ง routine ไปยังโมเดลที่เล็กและเร็วกว่า และใช้โมเดลที่ทรงพลังที่สุดเฉพาะจุดที่ต้องใช้การตัดสินใจ
• สามารถประกอบเป็น ลูประยะยาว ได้ด้วยการใช้ primitive ข้างต้นร่วมกับ auto mode, dynamic workflows (research preview) เป็นต้น

• ตัวอย่างการออกแบบระบบจัดการ feedback

  • ใช้ /schedule (research preview) รัน routine เพื่อตรวจสอบรายงานใหม่
  • ใช้ /goal เพื่อกำหนดความเสร็จสมบูรณ์ และใช้ skills เพื่อบันทึกวิธีการตรวจสอบ
  • ใช้ Dynamic workflows เพื่อ orchestration เอเจนต์ที่ทำหน้าที่จัดหมวดหมู่ แก้ไข และตรวจทานแต่ละรายงาน
  • ใช้ Auto mode เพื่อให้ routine ทำงานได้โดยไม่ต้องรอการยืนยันสิทธิ์
  • ตัวอย่างพรอมป์ต์แบบรวม: /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

การรักษาคุณภาพโค้ด

• คุณภาพของผลลัพธ์จากลูปขึ้นอยู่กับ ระบบแวดล้อม ดังนั้นการออกแบบระบบจึงสำคัญ
• รักษาความสะอาดของ codebase: Claude จะเดินตามแพตเทิร์นและคอนเวนชันของ codebase เดิม
• จัดให้มีวิธีตรวจสอบด้วยตนเอง: ใช้ skills เพื่อเข้ารหัสความหมายของสภาพที่ "ดี" ตามมาตรฐานทีม
• ทำให้เข้าถึงเอกสารได้ง่าย: เอกสารของ framework และ library มักมี best practice ล่าสุดอยู่เสมอ
• ใช้ second agent สำหรับ code review: ผู้รีวิวที่มีบริบทใหม่จะมีอคติน้อยกว่าและไม่ถูกกระทบจากกระบวนการให้เหตุผลของเอเจนต์หลัก โดยใช้ skill /code-review ที่มีมาให้หรือ Code Review สำหรับ Github
• หากผลลัพธ์รายชิ้นไม่ถึงมาตรฐาน อย่าแก้แค่ปัญหาเฉพาะหน้า แต่ควรเข้ารหัสให้ ปรับปรุงตัวระบบเอง ได้ด้วย

การจัดการการใช้โทเค็น

• ลูปควรมีขอบเขตที่ชัดเจน และใช้หลักการต่อไปนี้
• เลือก primitive และโมเดลให้เหมาะสม: งานเล็กไม่จำเป็นต้องใช้ multi-agent หรือลูป และบางงานใช้โมเดลที่ถูกกว่าและเร็วกว่าได้
• กำหนดเกณฑ์ความสำเร็จและการหยุดให้ชัดเจน: ระบุสถานะเสร็จสมบูรณ์ให้เฉพาะเจาะจงเพื่อไม่ให้จบเร็วเกินไป
• ทำ pilot ก่อนรันขนาดใหญ่: dynamic workflows สามารถสร้างเอเจนต์ได้เป็นร้อย ควรเริ่มจากขอบเขตเล็กเพื่อวัดการใช้งานก่อน
• ใช้งานสคริปต์กับงานที่เป็น deterministic: การรันสคริปต์ถูกกว่าการให้โมเดลหาเหตุผลทีละขั้น เช่น PDF skill อาจเตรียมสคริปต์กรอกฟอร์มไว้ให้ แทนการสร้างโค้ดใหม่ทุกครั้ง
• อย่ารัน routine ถี่เกินความจำเป็น: ปรับช่วงเวลาให้สอดคล้องกับความถี่ของการเปลี่ยนแปลงในสิ่งที่ต้องเฝ้าดู
• ทบทวนการใช้งาน: /usage ใช้วิเคราะห์การใช้ตาม skills, subagents และ MCPs, /goal แบบไม่มีอาร์กิวเมนต์จะแสดงจำนวนเทิร์นปัจจุบันและการใช้โทเค็น, /workflows จะแสดงการใช้โทเค็นของแต่ละเอเจนต์และหยุดได้ทุกเมื่อ

การเริ่มต้น

• สรุปตามประเภทของลูป
  • Turn-based: มอบหมายการตรวจสอบ (check), ใช้เมื่อมีการสำรวจหรือการตัดสินใจ, ใช้ custom verification skills
  • Goal-based: มอบหมายเงื่อนไขการหยุด, ใช้เมื่อรู้สถานะความเสร็จสมบูรณ์, ใช้ /goal
  • Time-based: มอบหมายการทริกเกอร์, ใช้เมื่องานมาถึงตามตารางจากนอกโปรเจกต์, ใช้ /loop และ /schedule
  • Proactive: มอบหมายตัวพรอมป์ต์, ใช้กับงานที่ทำซ้ำและนิยามชัดเจน, ใช้ทุกอย่างข้างต้นร่วมกับ dynamic workflows
• วิธีเริ่มคือมองงานที่คุณทำอยู่แล้ว แล้วเลือก งานหนึ่งที่คุณเป็นคอขวด เพื่อพิจารณาว่าส่วนไหนมอบหมายได้
  • เขียนเช็กลิสต์การตรวจสอบได้หรือไม่
  • เป้าหมายชัดเจนเพียงพอหรือไม่
  • งานเข้ามาตามตารางเวลาหรือไม่
• เมื่อมีไอเดียแล้ว ให้ลองรันลูป สังเกตจุดที่ติดขัดหรือรันเกินจำเป็น และอย่ากลัวที่จะ ปรับปรุงแบบวนซ้ำ