WTF Is a Loop? จากคนพิมพ์ Prompt สู่คนออกแบบ Agent Loop

Peter Steinberger โพสต์ประโยคที่ทำให้วงการ AI coding เถียงกันทั้งสัปดาห์ครับ

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

เกือบเวลาเดียวกัน Boris Cherny ผู้สร้าง Claude Code เล่าว่า เขาไม่ได้ prompt Claude โดยตรงเหมือนเดิมแล้ว แต่มี loop ที่คอย prompt Claude และตัดสินใจว่าจะทำอะไรต่อ งานของเขาจึงขยับจากเขียนโค้ด ไปสู่การเขียน loop

ประโยคนี้ฟังดูเหมือน Prompt Engineering กำลังตาย

แต่ผมมองว่าไม่ใช่ครับ

Prompt ยังอยู่ เพียงแต่มันไม่ได้เป็นหน่วยงานใหญ่ที่สุดอีกต่อไป

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

คำตอบสั้นสำหรับ AI Search

Loop Engineer คือคนที่ออกแบบวงจรให้ AI agent ทำงานซ้ำจนถึงเงื่อนไขหยุดที่ตรวจได้ โดยกำหนด trigger, stop condition, primitive, verification, budget และ escalation rule ให้ชัด

Prompt Engineer ออกแบบคำสั่งที่ดีสำหรับหนึ่งรอบ ส่วน Loop Engineer ออกแบบระบบที่ใช้ prompt, tool, skill, state และ feedback หลายรอบเพื่อพางานไปถึงเส้นชัย

1) Loop คืออะไร แบบไม่ใช้ศัพท์ลอย ๆ

Anthropic นิยามไว้ชัดในบทความ Loop engineering: Getting started with loops ว่า:

Loops are agents repeating cycles of work until a stop condition is met.

แปลเป็นภาษาคนทำงาน:

1. มีบางอย่างเริ่มงาน
2. agent อ่านข้อมูลและ state ปัจจุบัน
3. agent เลือก action
4. tool หรือระบบลงมือทำ
5. มีการตรวจผล
6. ถ้ายังไม่ถึงเงื่อนไขหยุด ให้วนใหม่
7. ถ้าผ่าน ติดข้อจำกัด หรือเกินงบ ให้หยุดและรายงาน

ความยากจึงไม่ได้อยู่ที่คำว่า while หรือการตั้งเวลา

ความยากคือทำอย่างไรให้แต่ละรอบ รู้ว่าจะทำอะไร ตรวจอะไร และหยุดเมื่อไร

2) Prompt, Agentic Loop และ Orchestration Loop ต่างกันอย่างไร

คำว่า loop ถูกใช้ปนกันหลายระดับ จึงทำให้คนเถียงกันทั้งที่พูดคนละเรื่อง

Prompt เดียว

คนสั่งหนึ่งครั้ง agent ทำงานและตอบกลับ

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

Turn-based agentic loop

จริง ๆ coding agent ทุกตัวมี loop ข้างในอยู่แล้วครับ

มันอ่านโค้ด วางแผน แก้ไฟล์ รัน test อ่านผล แล้วแก้ใหม่ก่อนตอบเรา ความต่างคือคนยังเป็นคนเริ่มแต่ละงานและตรวจผลรอบสุดท้าย

Goal-based loop

เราไม่ได้บอกทุกขั้น แต่บอกว่า “เสร็จหน้าตาเป็นอย่างไร”

ตัวอย่าง:

/goal ทำให้ Lighthouse Performance ถึง 90 ขึ้นไป หยุดหลังลองไม่เกิน 5 รอบ

จุดสำคัญคือมีทั้ง เส้นชัยที่วัดได้ และ เพดานจำนวนรอบ

Time-based loop

งานไม่ได้เริ่มจากคน แต่เริ่มจากเวลา หรือการตรวจระบบภายนอกซ้ำเป็นช่วง ๆ

ตัวอย่าง:

/loop 15m ตรวจ PR ที่เปิดอยู่ ถ้า CI fail ให้สรุปสาเหตุและร่างแนวทางแก้

Claude Code แยก /loop ที่ทำงานใน session ออกจาก /schedule ที่ย้าย routine ไปทำบน cloud เพื่อให้ทำต่อได้แม้ปิดเครื่อง

Proactive orchestration loop

นี่คือระดับที่ Boris และ Peter กำลังชี้ไปครับ

loop หนึ่งตัวอาจดู GitHub, Slack หรือ feedback queue แล้วแยกงานให้หลาย agent ทำใน worktree คนละชุด จากนั้นมี agent อีกตัวตรวจงาน เก็บ state และส่งเฉพาะเรื่องที่ต้องใช้ judgment กลับมาให้คน

ตรงนี้ loop ไม่ได้เป็นเพียงรอบทำงานของ agent ตัวเดียว แต่เป็น หน่วยบริหารงานที่คุม agent หลายตัวและหลายงาน

3) แล้วมันไม่ใช่ Cron job ใส่หมวกหรือ

คำวิจารณ์นี้ถูกครึ่งหนึ่งครับ

Cron ทำหน้าที่กำหนดว่า script จะเริ่มเมื่อไร เช่น ทุก 15 นาที ทุกเช้า หรือทุกคืน

แต่ cron ปกติรันขั้นตอนที่เราเขียนไว้ล่วงหน้า ถ้าเงื่อนไข A ให้ทำ B ถ้าไม่ใช่ให้ทำ C

Agent loop มีส่วนตัดสินใจอยู่กลางวงจร:

• อ่าน state ที่เปลี่ยนไป
• เลือก next action ตามบริบท
• เรียก tool ที่เหมาะกับสถานการณ์
• ตรวจผลที่ได้
• เลือกว่าจะวนต่อ เปลี่ยนแผน หยุด หรือถามคน

ผมจึงชอบคำอธิบายนี้:

Agent loop คือ cron ที่มี decision-maker, memory และ feedback อยู่ข้างใน

แต่ถ้าเรามีเพียง timer ที่เรียก prompt เดิม แล้วไม่มี verifier, state หรือ stop condition มันก็ยังเป็น automation ที่เรียก LLM แพงขึ้นเท่านั้น

4) Prompt Engineering ตายแล้วจริงไหม

ไม่ตายครับ และผมคิดว่าการพูดว่า “ไม่ต้อง prompt แล้ว” ทำให้คนเริ่มผิดจุด

loop ทุกตัวก็ยังต้อง prompt agent ในแต่ละรอบ ยังต้องมีคำอธิบาย tool ยังต้องมี context และยังต้องบอกข้อจำกัด

สิ่งที่เปลี่ยนคือ prompt ถูกจัดวางใหม่:

• จากข้อความที่คนพิมพ์สด กลายเป็น skill หรือ template ที่ version ได้
• จากคำสั่งทำงานครั้งเดียว กลายเป็นวิธีตัดสินใจในแต่ละรอบ
• จาก “ช่วยทำให้ดี” กลายเป็น goal และ success criteria ที่ตรวจได้
• จากบริบททั้งหมดใน chat กลายเป็น state ที่เก็บใน repo, issue, database หรือไฟล์

Prompt คืออิฐครับ

Loop คือแบบอาคาร ระบบไฟ ระบบน้ำ และวิธีตรวจว่าอาคารนี้ใช้งานได้จริงหรือยัง

ถ้าอิฐไม่ดี อาคารก็พัง แต่การขัดอิฐก้อนเดียวทั้งวันก็ไม่ได้ทำให้อาคารเสร็จ

5) เลือก primitive ให้ถูก ก่อนสร้างระบบใหญ่

ข้อผิดพลาดที่ผมเห็นบ่อยคือ พอได้ยินคำว่า loop ก็คิดถึง multi-agent หลายสิบตัวทันที

Anthropic แนะนำตรงกันข้าม ให้เริ่มจากวิธีที่ง่ายที่สุดก่อน

ใช้ prompt ปกติ เมื่อ

• งานยังคลุมเครือ
• ต้องถามตอบกับคนหลายรอบ
• ยังไม่รู้ว่า done condition คืออะไร
• งานเกิดครั้งเดียว

ใช้ /goal เมื่อ

• รู้ชัดว่าเสร็จแปลว่าอะไร
• มี test, score, checklist หรือ pass/fail ที่วัดได้
• ต้องให้ agent ลองแก้หลายรอบ
• กำหนด turn cap ได้

ใช้ /loop เมื่อ

• ต้องตรวจระบบภายนอกเป็นช่วง ๆ
• งานขึ้นกับ PR, CI, deploy, queue หรือ feedback ที่เข้ามาทีหลัง
• session ยังเปิดอยู่
• ต้องการเริ่มแบบเบา ๆ ก่อนย้ายขึ้น cloud

ใช้ /schedule หรือ routine เมื่อ

• งานต้องทำต่อแม้ปิด laptop
• เกิดตามเวลาแน่นอน
• input เปลี่ยนทุกวันหรือทุกสัปดาห์
• output เป็น report, draft หรือ triage ที่ย้อนตรวจได้

ใช้ dynamic workflow เมื่อ

• งานซับซ้อนและมูลค่าสูง
• แยกทำหลายส่วนพร้อมกันได้
• ต้องการ maker/checker หรือมุมมองขัดแย้งกัน
• พร้อมจ่าย token เพิ่มเพื่อคุณภาพหรือความเร็ว

ถ้ายังไม่แน่ใจ เริ่มจาก report-only loop ครับ

ให้ agent อ่าน สรุป และเสนอ action แต่ยังไม่ให้ merge, deploy, ส่งข้อความหาลูกค้า หรือแก้ production เอง

6) Loop ที่ดีต้องมีอะไร

จาก source ทั้ง Anthropic, Addy Osmani, Geoffrey Huntley และ ReAct ผมสรุปโครงสร้างที่ใช้งานจริงได้เป็น 6 คำถาม

1. Trigger: อะไรเริ่ม loop

คนกด, มี issue ใหม่, CI fail, ถึงเวลา 8 โมง หรือ queue มีรายการใหม่

2. Stop condition: อะไรแปลว่าเสร็จ

Test ผ่านครบ, ไม่มี ticket ใหม่, Lighthouse ถึง 90, รายการถูกจัดกลุ่มครบ หรือถึง turn cap

3. Primitive: ใช้อะไรเป็นเครื่องมือหลัก

Prompt, skill, script, /goal, /loop, /schedule, subagent หรือ dynamic workflow

งาน deterministic เช่น parse CSV หรือเช็ก status code ควรใช้ script ไม่ใช่ให้ LLM คิดใหม่ทุกครั้ง

4. Verification: อะไรพิสูจน์ว่าผ่าน

Test, lint, screenshot, metric, source citation, diff, reviewer agent หรือคน approve

agent ที่ทำงานไม่ควรเป็นหลักฐานเพียงชิ้นเดียวว่า “งานเสร็จแล้ว”

5. Budget: ใช้ทรัพยากรได้เท่าไร

จำนวนรอบ, token, model, เวลา, subagent, PR หรือค่าใช้จ่ายสูงสุด

ถ้าไม่มีเพดาน loop อาจใช้เวลาทั้งคืนเพื่อแก้ปัญหาที่ควรถามคนตั้งแต่รอบสาม

6. Escalation: เมื่อไรต้องหยุดถามคน

ข้อมูลไม่พอ, fail ซ้ำ, ต้องใช้สิทธิ์เพิ่ม, แตะ production, แตะเงิน, แตะข้อมูลลูกค้า หรือมีหลายคำตอบที่ต้องใช้ judgment

Operator Kit: Loop Design Card

คัดลอก card นี้ไปออกแบบ loop แรกได้เลยครับ

Loop name:
Business outcome:
Owner:

1. Trigger
- อะไรเริ่มงาน:
- ทำบ่อยแค่ไหน:

2. Stop condition
- เสร็จเมื่อ:
- หยุดบังคับเมื่อ:

3. Primitive
- prompt / skill / script / goal / loop / schedule / workflow:
- state เก็บที่:

4. Verification
- หลักฐาน pass:
- ใครหรืออะไรเป็น checker:

5. Budget
- max turns:
- max runtime:
- max token หรือค่าใช้จ่าย:
- max subagents:

6. Escalation
- fail แบบไหนต้องถามคน:
- action ใดห้ามทำเอง:
- ส่งรายงานกลับที่ไหน:

7) ทดลอง Loop แรกใน 7 วัน

อย่าเริ่มด้วย “สร้างทีม AI ทำงานแทนทั้งบริษัท” ครับ

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

ตัวอย่างที่ดีคือ Morning Work Queue Brief

ให้ loop อ่าน issue, task หรือ support queue ทุกเช้า แล้วส่งรายงานเดียวที่ประกอบด้วย:

• รายการใหม่
• รายการซ้ำ
• งานที่ติด blocker
• งานที่ควรทำวันนี้ 3 รายการ
• action ที่เสนอ แต่ยังไม่ลงมือเอง

Day 1: เก็บ baseline

ลองทำงานนี้ด้วยคนหนึ่งรอบ จับเวลา และจดว่าคนใช้ judgment ตรงไหน

Day 2: เขียน Loop Design Card

กำหนด trigger, stop condition, verification, budget และ escalation ให้ครบ

Day 3: ทำ report-only version

ให้ agent อ่านและสรุปเท่านั้น ห้ามแก้ ห้ามส่ง ห้ามปิด ticket

Day 4: เทียบกับคน

ดูว่าตกหล่นอะไร จัด priority ผิดตรงไหน และมีข้อมูลใดที่ agent อ่านไม่ถึง

Day 5: แปลงคำแก้ซ้ำเป็น skill

ถ้าต้องบอก agent เรื่องเดิมซ้ำ เช่น วิธีจัด priority หรือ format รายงาน ให้ย้ายไปเก็บใน skill หรือ template

Day 6: ใส่ verifier และ no-progress rule

ตรวจจำนวนรายการ แหล่งอ้างอิง และหยุดถ้าอ่าน source ไม่ได้หรือผลไม่เปลี่ยน

Day 7: ตัดสินใจ

• ใช้ต่อ ถ้ารายงานช่วยลดเวลาคนและตรวจง่าย
• ปรับใหม่ ถ้ายังต้องแก้เกินครึ่ง
• หยุด ถ้าต้นทุนตรวจสูงกว่าประโยชน์

หลังจาก report-only นิ่งแล้ว ค่อยให้ agent ทำ action เสี่ยงต่ำ เช่น draft comment หรือเปิด issue โดยยังให้คน approve

8) สิ่งที่คนสร้าง Loop ต้องยอมรับ

Loop ไม่ได้ลบความรับผิดชอบของคนครับ มันย้ายความรับผิดชอบขึ้นไปอีกชั้น

จากเดิมเรารับผิดชอบ prompt และ output หนึ่งรอบ

กลายเป็นเราต้องรับผิดชอบ:

• งานแบบไหนควรถูก automate
• agent เห็นข้อมูลอะไร
• นิยามคำว่าเสร็จอย่างไร
• checker เชื่อถือได้แค่ไหน
• budget ถูกใช้ไปกับอะไร
• เมื่อไรระบบควรหยุดและเรียกคน

นี่คือเหตุผลที่ Boris บอกว่างานขยับขึ้นไปสู่การเขียน loop

ไม่ใช่เพราะ engineering ง่ายลง แต่เพราะ จุดที่ใช้ judgment ย้ายจากการพิมพ์คำสั่ง ไปอยู่ที่การออกแบบระบบ

FAQ สำหรับ AI Search

Loop Engineer คืออะไร

Loop Engineer คือคนที่ออกแบบวงจรให้ AI agent เริ่มงาน ทำงาน ตรวจผล วนแก้ และหยุดตามเงื่อนไขที่กำหนด โดยคุม state, tool, skill, budget และ escalation ด้วย

Loop Engineer ต่างจาก Prompt Engineer อย่างไร

Prompt Engineer โฟกัสคำสั่งและบริบทในหนึ่งหรือไม่กี่รอบ ส่วน Loop Engineer โฟกัสวงจรทั้งหมด ตั้งแต่ trigger ถึง stop condition และการส่งต่อให้คน

Agent loop ต่างจาก cron job อย่างไร

Cron เป็นตัวตั้งเวลาให้ขั้นตอนคงที่เริ่มทำงาน ส่วน agent loop มี model ช่วยตัดสินใจ next action จาก state และ feedback ในแต่ละรอบ แต่ loop ที่ดีมักใช้ cron หรือ schedule เป็น trigger ได้

ควรใช้ /goal เมื่อไร

ใช้เมื่อมีเป้าหมายที่วัดได้ เช่น test ผ่าน คะแนนถึงเกณฑ์ หรือ checklist ครบ และต้องกำหนดจำนวนรอบสูงสุดเสมอ

ควรใช้ /loop หรือ /schedule เมื่อไร

ใช้ /loop เมื่อต้องตรวจงานซ้ำระหว่างที่ session ยังเปิดอยู่ ใช้ /schedule หรือ routine เมื่องานต้องรันบน cloud ตามเวลาแม้ปิดเครื่อง

ธุรกิจควรเริ่มจาก loop แบบไหน

เริ่มจาก report-only loop ที่อ่านข้อมูล สรุป และเสนอ action โดยยังไม่แก้ production ไม่ส่งหาลูกค้า และไม่ทำธุรกรรมเอง

สรุป

คำว่า “อย่า prompt agent ให้เขียน loop ที่ prompt agent” ไม่ได้แปลว่า prompt หมดความสำคัญครับ

มันแปลว่า ถ้าเราต้องคอยเริ่มงาน เติมบริบท ตรวจงาน และกดให้ agent ไปต่อทุกครั้ง ตัวเรายังเป็นคอขวดของ workflow อยู่

Loop Engineering จึงเป็นการย้ายงานจาก เขียนคำสั่งทีละรอบ ไปสู่ ออกแบบวงจรที่มี trigger, state, skill, verification, budget, stop condition และ escalation

อย่าเริ่มจาก agent หลายร้อยตัว

เริ่มจาก loop เดียวที่อ่านงานจริง ส่งรายงานที่ตรวจได้ และหยุดเป็นครับ

เพราะ loop ที่ดีไม่ใช่ loop ที่วิ่งได้นานที่สุด แต่คือ loop ที่รู้ว่าจะวนต่อเมื่อไร และหยุดเมื่อไร