Loop Engineering: เลิก Prompt Agent ทีละรอบ แล้วออกแบบวงจรให้มันทำงานแทน

ช่วงแรกของการใช้ AI Agent เรามักวัดกันที่ prompt ครับ

ใครเขียน prompt ดี ใส่ context เก่ง สั่งงานละเอียดกว่า ก็ได้ผลลัพธ์ดีกว่า

แต่ในฝั่ง coding agent และ agent workflow ตอนนี้เริ่มมีคำหนึ่งที่น่าสนใจมากขึ้นเรื่อย ๆ คือ Loop Engineering

แนวคิดนี้ไม่ได้บอกว่า prompt ไม่สำคัญแล้ว แต่มันบอกว่า ถ้าเราต้องคอย prompt agent ทุกขั้นตอนเองตลอด เวลา leverage ก็ยังติดอยู่ที่คน

คำถามใหม่คือ:

เราออกแบบระบบที่ prompt, ตรวจ, เก็บ state และวนกลับมาทำงานต่อเองได้ไหม

1) Loop Engineering คืออะไร

Addy Osmani นิยามไว้ตรงมากครับ

Loop Engineering คือการแทนที่ตัวเราในฐานะ “คนที่คอย prompt agent” ด้วยระบบที่ทำหน้าที่นั้นแทน

จากเดิม:

1. คนพิมพ์ prompt
2. agent ตอบ
3. คนอ่าน
4. คนพิมพ์ต่อ
5. คนตรวจว่าพอหรือยัง

เปลี่ยนเป็น:

1. ระบบค้นหางาน
2. ระบบส่งงานให้ agent
3. agent ลงมือทำ
4. verifier ตรวจผล
5. state ถูกอัปเดต
6. ระบบตัดสินใจว่าจะวนต่อ หยุด หรือส่งต่อให้คน

ถ้าพูดแบบ Data-Espresso:

Prompt Engineering คือการเขียนคำสั่งให้ดี

Loop Engineering คือการออกแบบ workflow ที่ทำให้ agent ทำงานซ้ำได้ โดยไม่หลุดเป้าและไม่ลืมหลักฐาน

2) ทำไมเรื่องนี้เริ่มสำคัญตอนนี้

เพราะ agent tools เริ่มมี primitive ที่ทำ loop ได้จริงมากขึ้น

Addy แยกส่วนประกอบของ loop ไว้ประมาณนี้:

• Automations หรือ schedule เพื่อให้ loop มีจังหวะทำงาน
• Worktrees เพื่อให้ agent หลายตัวทำงานแยกกันโดยไม่ชนกัน
• Skills เพื่อเก็บความรู้และขั้นตอนเฉพาะโปรเจกต์
• Plugins หรือ connectors เช่น MCP เพื่อให้ agent แตะเครื่องมือจริงได้
• Sub-agents เพื่อแยก maker กับ checker
• State หรือ memory ที่อยู่นอก chat เพื่อให้ loop ไม่เริ่มจากศูนย์ทุกครั้ง

ประโยคที่ผมชอบมากคือ:

The agent forgets, the repo doesnt.

แปลไทยแบบง่าย ๆ คือ agent ลืมได้ แต่ repo, state file, issue board, log และเอกสารในระบบไม่ควรลืม

นี่คือจุดที่ทำให้ loop engineering ต่างจากการคุยกับ chatbot แบบยาว ๆ

3) ตัวอย่าง loop ที่คนทำงานเข้าใจง่าย

สมมุติทีม dev มีปัญหา CI fail บ่อย

ถ้าใช้ agent แบบ prompt ทีละรอบ เราอาจพิมพ์ว่า:

“ช่วยดู CI fail ให้หน่อย”

แต่ถ้าเป็น loop เราจะออกแบบแบบนี้:

1. ทุกเช้า loop อ่าน CI failures ของเมื่อวาน
2. จัดกลุ่มว่า fail เพราะ test flake, dependency, lint หรือ bug จริง
3. เขียน summary ลง state file หรือ issue
4. ถ้าเป็น low-risk fix ให้เปิด worktree แล้วให้ implementer agent ลองแก้
5. verifier agent รัน test ซ้ำ
6. ถ้าผ่าน ให้เปิด PR พร้อมหลักฐาน
7. ถ้า ambiguous หรือแตะไฟล์เสี่ยง ให้ส่งให้คน review

นี่ไม่ใช่ prompt เดียวแล้วจบครับ มันคือระบบงานขนาดเล็กที่มีจังหวะ มีขอบเขต มีหลักฐาน และมีจุดส่งต่อให้คน

4) OpenAI Cookbook ชี้อีกด้าน: loop ที่ดีต้องเรียนจาก trace และ eval

อีก source ที่ดีคือ OpenAI Cookbook เรื่อง Agent Improvement Loop

ตัวอย่างนั้นไม่ได้พูดแค่ให้ agent ทำงานซ้ำ แต่ทำเป็น improvement flywheel:

• เก็บ traces ว่า agent ทำอะไรจริง
• เอา human feedback และ model feedback มาตีความ
• เปลี่ยน feedback เป็น eval ที่รันซ้ำได้
• ใช้ HALO วิเคราะห์ว่าควรปรับ harness ตรงไหน
• เขียน handoff ให้ Codex เอาไป implement ต่อ

แก่นของมันคือ loop ที่ดีไม่ใช่แค่ “วนทำงาน”

แต่ต้องวนแล้วฉลาดขึ้นจากหลักฐานเดิมด้วย

ถ้าไม่มี trace, eval, feedback และ handoff ที่ชัด loop จะกลายเป็นแค่ cron job ที่เรียก LLM แพง ๆ ทุกวัน

5) บทเรียนสำหรับธุรกิจไทย

ผมคิดว่า Loop Engineering ไม่ได้สำคัญเฉพาะ dev team ครับ

ธุรกิจทั่วไปก็เริ่มคิดแบบนี้ได้เหมือนกัน

ตัวอย่าง loop ที่ไม่ใช่ coding:

• ทุกเช้าอ่าน inbox ลูกค้า แล้วจัดกลุ่ม lead ที่ต้อง follow-up
• ทุกวันศุกร์อ่านยอดขาย แล้วสรุปสินค้าที่ควร push ต่อ
• ทุกสัปดาห์อ่าน comment/DM แล้วหา pain point ที่ควรทำ content
• ทุกคืนอ่าน ticket support แล้วทำ QA ว่าคำตอบ bot หลุด policy ไหม
• ทุกเดือนอ่าน campaign result แล้วเสนอ experiment รอบถัดไป

สิ่งที่ต่างจาก automation ปกติคือ loop พวกนี้มีส่วนที่ต้องตีความ, สรุป, เลือก next action และตรวจหลักฐาน

แต่สิ่งที่เหมือนกันคือ ถ้าจะใช้จริง ต้องมี process design ไม่ใช่แค่ prompt design

6) จุดเสี่ยง: loop ที่ดีขึ้น อันตรายขึ้นด้วย

เรื่องนี้ต้องพูดตรง ๆ ครับ

Loop ที่ทำงานเก่งขึ้น ไม่ได้แปลว่าปลอดภัยขึ้นโดยอัตโนมัติ

ยิ่ง loop ทำงานได้นานขึ้น แตะ tool ได้มากขึ้น และแก้งานได้เองมากขึ้น ความเสี่ยงก็ยิ่งชัดขึ้น:

• token cost บานโดยไม่มีคนเห็น
• agent แก้ปัญหาผิดทิศซ้ำหลายรอบ
• verifier ตรวจไม่พอ แต่ loop คิดว่าเสร็จแล้ว
• state สกปรก ทำให้รอบถัดไปตัดสินใจผิด
• คนเริ่มไม่เข้าใจว่า loop ทำอะไรไปแล้วบ้าง
• loop แตะ path หรือข้อมูลที่ไม่ควรแตะ

ดังนั้น loop ที่ดีต้องมีทั้งคันเร่งและเบรก

ไม่ใช่ “ปล่อย agent ทำงานเองหมด” แต่คือ “ออกแบบให้ agent ทำงานซ้ำในกรอบที่ตรวจได้”

Operator Kit: 9 จุดเช็กก่อนปล่อย Agent Loop ให้ทำงานจริง

ใช้ checklist นี้ก่อนทำ loop ไม่ว่าจะเป็น coding, content, sales, support หรือ report automation

1. Goal ชัดใน 1 ประโยค loop นี้ทำงานอะไร และเสร็จแปลว่าอะไร
2. Non-goal ชัด loop นี้ห้ามทำอะไร เช่น ห้าม merge, ห้าม deploy, ห้ามส่งหาลูกค้า, ห้ามแตะ payment
3. Scope ชัด repo, folder, issue, CRM view, sheet, inbox หรือ data source ไหนที่ loop อ่านและเขียนได้
4. State อยู่นอก chat ต้องมี state file, issue board, CRM field หรือ log ที่รอบถัดไปอ่านต่อได้
5. Skill หรือ SOP ถูก version อย่าใส่ prompt ยาว ๆ ใน schedule แล้วลืมอัปเดต ให้แยกเป็น skill/template/playbook
6. Maker กับ checker แยกกัน agent ที่ทำงานไม่ควรเป็นคนเดียวกับ agent ที่บอกว่าเสร็จแล้ว
7. Proof ก่อน action ทุก output สำคัญต้องมี test, diff, source link, screenshot, metric หรือ trace
8. Budget และ kill switch มีจริง กำหนดจำนวนรอบ, token cap, max PR, max message, max retry และเงื่อนไขหยุด
9. Human gate อยู่ตรงจุดเสี่ยง งานแตะลูกค้า เงิน ข้อมูลส่วนตัว production หรือ public channel ต้องหยุดให้คน approve

ถ้าทีมยังตอบ 9 ข้อนี้ไม่ได้ ผมแนะนำให้เริ่มที่ L1 report-only loop ก่อนครับ

ให้ loop อ่าน สรุป และเสนอ action แต่ยังไม่ให้มันแก้หรือส่งอะไรเอง

พอ proof เริ่มนิ่ง ค่อยขยับไป assisted mode ทีละส่วน

7) Data-Espresso take

ในความเห็นของผม Loop Engineering เป็นคำที่ดี เพราะมันทำให้เราเลิกมอง AI Agent เป็นแค่คนตอบคำถาม

มันบังคับให้เราถามคำถามที่เป็นระบบมากขึ้น:

• agent เริ่มงานจากไหน
• ใครกำหนด done condition
• state อยู่ตรงไหน
• ใครตรวจงาน
• ถ้า fail แล้ววนยังไง
• ถ้าเสี่ยงแล้วหยุดตรงไหน

นี่คือภาษาเดียวกับการทำธุรกิจจริงครับ

ธุรกิจไม่ได้ต้องการ AI ที่พูดเก่งอย่างเดียว ธุรกิจต้องการงานที่วิ่งได้ ตรวจได้ และไม่ทำให้ทีมต้องมาตามเก็บกวาดทีหลัง

สรุป

Loop Engineering คือก้าวถัดไปจาก Prompt Engineering สำหรับงาน agentic workflow

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

สำหรับทีมไทย ผมจะสรุปแบบนี้:

อย่าเพิ่งถามว่าจะใช้ agent ตัวไหน ให้ถามก่อนว่า loop งานไหนในธุรกิจควรถูกออกแบบใหม่

เริ่มจาก loop ที่เสี่ยงต่ำ วัดผลง่าย และมี human gate ชัด เช่น report summary, issue triage, content QA, lead follow-up หรือ CI summary

สุดท้าย AI Agent ที่น่าไว้ใจ ไม่ใช่ agent ที่วิ่งเองได้ไกลที่สุดครับ แต่คือ agent ที่รู้ว่าเมื่อไรต้องวนต่อ เมื่อไรต้องหยุด และเมื่อไรต้องส่งงานกลับมาให้คนตัดสินใจ