Loop Engineering: ออกแบบวงวนให้ AI agent ทำงานเองจนจบ

เกี่ยวกับบทความนี้

บทความนี้เป็น บทเรียบเรียงของ Kaen ไม่ใช่การแปลจากต้นฉบับเดียว เพราะ “loop engineering” เป็นศัพท์ที่เพิ่งก่อตัวในปี 2026 และยังไม่มีนิยามที่ตกผลึกในที่เดียว

เนื้อหาจึงสังเคราะห์จากหลายแหล่ง โดยอ้างอิงหลักจาก “Loop, Harness, Context Engineering: The Terms Explained” ของ Benjamin Font Pera (Service Lead GenAI, codecentric — 5 กรกฎาคม 2026)

วลีเด่นที่ยกมาตรง ๆ ให้เครดิตเจ้าของ ได้แก่ Boris Cherny (Head of Claude Code, Anthropic) และ Addy Osmani (Engineering Lead, Google Chrome)

เรียบเรียงเพื่อการศึกษา — ไดอะแกรมวาดใหม่เป็น Mermaid (label ของ node เป็นภาษาอังกฤษ) ศัพท์เทคนิคคงไว้เป็นภาษาอังกฤษพร้อมคำอธิบายไทยเมื่อพบครั้งแรก ลิขสิทธิ์ของถ้อยคำและแนวคิดต้นฉบับเป็นของผู้เขียนแต่ละท่าน

ถ้าไล่ดูวิวัฒนาการของการทำงานกับ AI agent จะเห็นว่ามันไต่ขึ้นเป็นชั้น ๆ

เริ่มจาก prompt engineering (เขียนคำสั่งเดียวให้ดี)
ขยับไป context engineering (ดูแลว่าจะให้อะไรอยู่ใน context ของ model ในแต่ละก้าว)
แล้วต่อไป harness engineering (โครงครอบรอบ model — tools, skills, hooks, sensors ที่ล้อม model ไว้)
และล่าสุดคือชั้นบนสุด: loop engineering

จุดเปลี่ยนที่ทำให้ loop engineering กลายเป็นทักษะแยกออกมา สรุปได้ด้วยประโยคเดียวของ Boris Cherny:

“I don’t prompt Claude anymore. I write loops that prompt Claude.” — Boris Cherny, Head of Claude Code (Anthropic)

พูดเป็นภาษาคน: คุณไม่ prompt agent อีกต่อไป — คุณออกแบบระบบที่ prompt agent แทน

เป้าหมายไม่ใช่การเค้นเขียนคำสั่งที่สมบูรณ์แบบต่อหนึ่งเทิร์นอีกแล้ว แต่คือการสร้าง “เครื่องจักร” ที่กระตุ้น agent ซ้ำ ๆ อ่านผลลัพธ์ ตัดสินว่าเสร็จหรือยัง แล้วป้อนงานต่อให้ตัวเอง จนกว่าจะถึงเงื่อนไขจบ โดยแทบไม่ต้องมีมนุษย์คอยพิมพ์สั่งทีละรอบ

Loop engineering คืออะไร

Loop engineering คือการออกแบบ ระบบที่กระตุ้น agent ซ้ำ ๆ ตรวจผลของแต่ละรอบ แล้วป้อนตัวเองต่อ โดยไม่ต้องมีมนุษย์สั่งทีละเทิร์น มันไม่ใช่ตัว model และไม่ใช่ตัว agent เดี่ยว ๆ แต่เป็น เครื่องจักรรอบนอก ที่ตัดสินใจว่าจะเรียก agent เมื่อไร กี่ตัว ให้ทำอะไร ตรวจอย่างไร และเมื่อไรควรหยุด

เส้นแบ่งสำคัญคือ ชั้นที่อยู่ข้างล่าง (context, harness) ตอบคำถามว่า “หนึ่งรอบของ agent จะทำงานได้ดีแค่ไหน” ส่วน loop engineering ตอบคำถามว่า “เราจะร้อยหลาย ๆ รอบเข้าด้วยกันให้มันเดินไปเองจนจบงานได้อย่างไร”

ต้นฉบับของ Font Pera สรุปสั้น ๆ ว่า loop คือ “ระบบที่กระตุ้น agent ซ้ำ ๆ แตกลูก agent มาช่วย ตรวจผล และหล่อเลี้ยงตัวเองต่อไปโดยไม่ต้องมีมนุษย์ป้อนทีละเทิร์น”

อีกมุมที่ช่วยให้เห็นภาพคือสมการที่ Font Pera ใช้กับ harness ว่า Agent = Model + Tool Harness + User Harness — ตัว agent หนึ่งตัวคือ model ที่ถูกห่อด้วย harness สองด้าน loop engineering คือชั้นที่เอา “agent สำเร็จรูป” ตัวนี้ไปวางในเครื่องจักรที่เรียกใช้มันซ้ำ ๆ

ดังนั้นคุณภาพของ agent แต่ละตัวจึงกลายเป็น “วัตถุดิบ” ที่ loop เอาไปทำซ้ำ ไม่ใช่สิ่งที่ loop จะไปเสกให้ดีขึ้นได้เอง

วงจรแกน: reason → act → observe

หัวใจที่หมุนอยู่ข้างในทุก loop คือวงจรเล็ก ๆ ที่ชื่อว่า ReAct loop (reason + act)

แนวคิดนี้มาจากงานวิจัยที่เสนอให้ model สลับระหว่างการให้เหตุผล (reasoning trace) กับการลงมือทำ (action) ไปด้วยกัน แทนที่จะคิดจบทั้งก้อนแล้วค่อยทำ และมันคือเครื่องยนต์เดียวกับที่ขับเคลื่อนเครื่องมืออย่าง Claude Code และ Cursor อยู่ทุกวันนี้

agent จะวนอยู่ในสี่จังหวะ: reason (คิดว่าก้าวต่อไปควรทำอะไร) → act (ลงมือด้วยการเรียก tool) → observe (อ่านผลที่กลับมา) → แล้วถามตัวเองว่า ถึงเงื่อนไขจบหรือยัง ถ้ายัง ก็วนกลับไป reason ใหม่ด้วยข้อมูลที่เพิ่งได้มา

flowchart LR
  Reason["Reason (plan next step)"] --> Act["Act (call a tool)"]
  Act --> Observe["Observe (read the result)"]
  Observe --> Decision{"Done?"}
  Decision -->|No| Reason
  Decision -->|Yes| Stop["Stop and hand back"]

ภาพ 1 — วงจรแกน reason → act → observe ของ ReAct loop ทุก loop engineering ที่ซับซ้อนกว่านี้ล้วนสร้างทับวงจรนี้ จุดที่คนมักออกแบบพลาดที่สุดคือกล่อง Done? ตรงกลาง เพราะถ้าเงื่อนไขจบไม่ชัด agent ก็จะวนไม่รู้จบ หรือหยุดก่อนงานเสร็จ

สังเกตว่าตัววงจรนี้ไม่มีอะไรใหม่ — สิ่งที่ loop engineering เพิ่มเข้ามาคือการ ออกแบบสิ่งที่อยู่รอบวงจร: อะไรจุดชนวนให้มันเริ่ม ใครเป็นคนตรวจ observe ว่าถูกจริง และกล่อง Done? ตัดสินด้วยเกณฑ์อะไร

สี่ชั้นของการทำงานกับ agent

Font Pera ชำแหละสามคำ — context, harness, loop — และเน้นว่ามัน ไม่ใช่ทางเลือกแทนกัน แต่เป็นชั้นที่ซ้อนทับกัน โดยชั้นบนสร้างอยู่บนชั้นล่างเสมอ ในบทเรียบเรียงนี้เราวาง prompt engineering เป็นชั้นฐานที่รองรับทั้งหมดไว้อีกชั้น จึงเห็นเป็นสี่ชั้นดังภาพ

flowchart TB
  subgraph Stack["Four layers of agent engineering"]
    direction TB
    L4["Loop - run autonomously"]
    L3["Harness - guides and sensors"]
    L2["Context - right tokens per step"]
    L1["Prompt - one good instruction"]
    L4 --> L3 --> L2 --> L1
  end

ภาพ 2 — สี่ชั้น: prompt เป็นฐาน context ดูแลว่าจะป้อนอะไรต่อ model harness ล้อมด้วย guides (context/rules ที่ให้ก่อนสร้าง code) และ sensors (การตรวจหลังสร้างเพื่อให้แก้ตัวเองได้) และ loop คือชั้นบนสุดที่ทำให้ทั้งกองนี้เดินเองซ้ำ ๆ

หลักการที่ต้องจำให้ขึ้นใจคือ แต่ละชั้นขยายจุดอ่อนของชั้นที่อยู่ข้างล่าง loop ไม่ได้ “แก้” harness ที่ห่วยหรือ context ที่มั่ว มันแค่ ทำซ้ำ สิ่งที่อยู่ข้างล่าง ดังนั้นถ้าข้างล่างดี loop จะขยายผลดีทวีคูณ แต่ถ้าข้างล่างพัง loop ก็ยิ่งพังเร็วและพังหลายรอบขึ้น

loop คือตัวขยาย ไม่ใช่ตัวแก้

Font Pera เตือนว่า loop ที่วนทับ context ห่วย ๆ หรือ harness ที่ตรวจงานไม่เป็น จะ คูณปัญหาให้ใหญ่ขึ้น ไม่ใช่ลดปัญหาลง ถ้า harness ของคุณดี loop จะยิ่งได้ผล ถ้า harness แย่ loop จะยิ่งพังเร็ว — จึงต้องลงทุนกับ harness engineering และ context engineering ให้แน่นก่อน แล้วค่อยขึ้นมาเล่นชั้น loop

องค์ประกอบที่ต้องออกแบบใน1 loop

การเขียน loop ที่ดีคือการตอบคำถามห้าข้อให้ครบ ไม่ใช่แค่ “สั่งให้ agent วน ๆ ไป”:

Trigger — อะไรจุดชนวนให้ loop เริ่ม (คนกดปุ่ม, commit ใหม่, cron, หรือ agent ตัวอื่นเรียก)
Topology — โครงว่าจะใช้ agent เดี่ยว, หลายตัวขนานกัน, หรือ agent หลักแตก sub-agent ไปทำงานย่อยแล้วสรุปกลับ
Verifier — ใคร (หรืออะไร) เป็นคนตัดสินว่าผลของแต่ละรอบ “ถูก” จริง เช่น test suite, linter, type checker หรือ agent ตรวจสอบแยกอีกตัว
Stop rule / termination condition — เกณฑ์ที่บอกว่า “เสร็จแล้ว” อย่างชัดเจน ไม่งั้น loop จะวนไม่จบหรือเผา token ทิ้งเปล่า ๆ
การแยก recoverable error จาก hard blocker — ความผิดพลาดแบบไหนที่ agent ลองใหม่เองได้ (เช่น test แดง แก้แล้วรันซ้ำ) กับแบบไหนที่ต้องหยุดแล้วเรียกมนุษย์ (เช่น สิทธิ์ไม่พอ, requirement กำกวม)

flowchart LR
  Trigger["Trigger (what starts the run)"] --> Topology["Topology (single / multi / sub-agents)"]
  Topology --> Work["Reason - Act - Observe"]
  Work --> Verifier["Verifier (is this correct?)"]
  Verifier --> Stop{"Stop rule met?"}
  Stop -->|"Recoverable error"| Topology
  Stop -->|"Hard blocker"| Halt["Halt and ask a human"]
  Stop -->|"Done"| Finish["Terminate"]

ภาพ 3 — กายวิภาคของ loop ที่ออกแบบมาดี: ผลของ verifier ป้อนเข้ากล่อง stop rule ซึ่งแตกทางเป็นสามกรณี — วนต่อ (recoverable), หยุดถามคน (hard blocker), หรือจบ (done) loop ที่ขาดเส้น “hard blocker → ask a human” คือ loop ที่จะดันทุรังทำผิดต่อไปเรื่อย ๆ

สองข้อที่ยากที่สุดในรายการนี้คือ verifier กับ stop rule และมักพังด้วยกัน กับดักคลาสสิกคือปล่อยให้ agent ตัวที่ทำงานเป็นคน “ตัดสินเอง” ว่างานเสร็จ — ซึ่งก็เหมือนให้นักเรียนตรวจข้อสอบตัวเอง

verifier ที่เชื่อถือได้จึงควร เป็นอิสระจากตัวที่ผลิตงาน เช่น test suite ที่รันจริง, type checker หรือ agent ตรวจสอบที่มี context สะอาดแยกต่างหาก

ส่วน stop rule ก็ต้องผูกกับสัญญาณที่ปลอมยาก ถ้าเกณฑ์จบคือ “agent บอกว่าเสร็จ” มันจะเรียนรู้ที่จะพูดว่าเสร็จ (บทเรียน Goodhart ฉบับย่อ) แต่ถ้าเกณฑ์จบคือ “test ทั้งชุดผ่านและ diff ไม่แตะ file ต้องห้าม” การโกงก็ยากขึ้นมาก

ในทางเครื่องมือ Osmani ให้ชุด “อิฐก่อสร้าง” (building blocks) ที่ใช้ประกอบ loop จริงในทางปฏิบัติ:

Automations — สิ่งที่จุดชนวนและกำหนดจังหวะการรัน (คือ trigger นั่นเอง)
Worktrees — พื้นที่ทำงานแยกเป็นสัดส่วน ให้หลายรอบ/หลาย agent ทำงานขนานกันโดยไม่ชนกัน
Skills — เอกสารความสามารถที่คงอยู่ ให้ agent หยิบใช้ซ้ำได้ทุกรอบ
Plugins & connectors — ช่องต่อเข้ากับ tool และข้อมูลภายนอก (รวมถึง MCP)
Sub-agents — ตัวช่วยที่รับงานย่อยและตรวจผลให้

และก้อนสุดท้ายที่ขาดไม่ได้คือ memory — สถานะที่อยู่ นอก context เช่น file markdown, บอร์ด Linear หรืออะไรก็ตามที่ “อยู่รอดข้ามรอบ” เพราะ context window ถูกรีเซ็ตทุกครั้งที่รอบใหม่เริ่ม สิ่งที่ต้องจำข้ามรอบจึงต้องเก็บไว้ข้างนอก

ระดับของ loop: จากง่ายไปยาก

ไม่ใช่ทุก loop จะซับซ้อนเท่ากัน มองเป็นสามระดับจากง่ายไปยากได้:

flowchart LR
  L1["Single-turn tool loop"] --> L2["Task loop (build + verify)"]
  L2 --> L3["Autonomous self-prompting loop"]

ภาพ 4 — สามระดับของ loop ยิ่งขยับไปทางขวา ยิ่งปล่อยให้ระบบตัดสินใจเองมากขึ้น และยิ่งต้องการ verifier กับ stop rule ที่แข็งแรงขึ้นตามไปด้วย

Single-turn tool loop — วงจร reason-act-observe หนึ่งงานสั้น ๆ เช่น “ค้น file อ่าน แล้วตอบ” นี่คือ ReAct loop เปล่า ๆ ที่จบในไม่กี่รอบ
Task loop (build + verify) — วนสร้างแล้วตรวจไปเรื่อย ๆ จนงาน หนึ่งงาน เสร็จตามเกณฑ์ เช่น “เขียน feature นี้ให้ผ่าน test ทั้งหมด” agent จะแก้-รัน test-อ่านผล-แก้ใหม่ วนจน verifier บอกว่าผ่าน
Autonomous self-prompting loop — ระบบที่ prompt ตัวเอง ต่อเนื่อง หยิบงานถัดไปมาทำเองโดยไม่รอคน มักประกอบจาก worktrees + sub-agents + memory และเดินได้เป็นชั่วโมงหรือเป็นวัน นี่คือระดับที่ Cherny พูดถึงเมื่อบอกว่าเขา “เขียน loop ที่ prompt Claude” แทนการ prompt เอง

ภาพที่เป็นรูปธรรมของระดับที่สาม เช่น ระบบอ่าน backlog เป็นแหล่ง trigger หยิบงานทีละใบ แตกออกเป็นหลาย worktree (สำเนา repo แยกสาขา) ให้ sub-agent แต่ละตัวลุยคนละงานขนานกัน แต่ละตัววน task loop ของตัวเองจน test ผ่าน

แล้วเขียนสรุปความคืบหน้าลง memory ที่อยู่นอก context เพื่อให้รอบถัดไป (หลัง context ถูกรีเซ็ต) รู้ว่าทำอะไรไปแล้วและเหลืออะไร วงนอกสุดคอยเช็คว่า backlog หมดหรือยัง — ถ้ายัง ก็จุดชนวนรอบใหม่เอง

ความปลอดภัย: loop ที่ปล่อยไว้ = loop ที่ทำผิดโดยไม่มีคนดู

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

“A loop running unattended is also a loop making mistakes unattended.” — Addy Osmani, Engineering Lead (Google Chrome)

นั่นคือ loop ที่รันโดยไม่มีคนเฝ้า ก็คือ loop ที่ ทำผิดพลาดโดยไม่มีคนเฝ้า ไปพร้อมกัน ความเร็วและความอัตโนมัติที่เราตื่นเต้น กลายเป็นตัวขยายความผิดพลาดได้เท่า ๆ กับที่มันขยายผลงาน Osmani ชี้สามความเสี่ยงที่คนมักไม่รับมือ:

Lack of verification — ไม่มีใครตรวจ loop จึงวิ่งต่อทั้งที่ผลลัพธ์ผิด โดยไม่มีสัญญาณเตือน
Loss of understanding — ความเร็วของ automation บังไม่ให้เราเข้าใจปัญหาที่แท้จริงข้างใต้
Cognitive capitulation — การยอมรับผลลัพธ์ของ agent แบบไม่คิด แทนที่จะใช้วิจารณญาณตรวจสอบ

Font Pera ตบท้ายด้วยประโยคที่ควรแปะไว้หน้าจอ: ใครก็ตามที่สร้าง loop โดยไม่จัดการสามความเสี่ยงนี้ ก็แค่กำลังสร้าง “linter ราคาแพงที่หลอนเอาเอง” (an expensive linter that hallucinates)

อย่าปล่อย loop ที่ไม่มี sensor

ทางแก้ไม่ใช่การเลิกใช้ loop แต่คือการทำให้กล่อง Done? และ verifier แข็งแรงจริง โยงกลับไปที่ sensors ของ harness engineering — test, type check, lint, การตรวจข้ามด้วย sub-agent — เพราะ sensor คือดวงตาที่ทำให้ loop รู้ตัวว่าเพิ่งทำพัง ยิ่งปล่อยให้ autonomy สูงเท่าไร guardrail ยิ่งต้องแน่นเท่านั้น

เรื่องความเสี่ยงของการปล่อย AI ทำงานเองอ่านต่อได้ที่ AI Autonomy ใน Code Generation ซึ่งพบว่าแม้โจทย์เล็ก ๆ agent ก็ยังขยายขอบเขตงานเอง อ้างว่า test ผ่านทั้งที่ไม่ผ่าน และละเมิดกฎที่ตั้งไว้

แล้วเมื่อไรควรขยับไปเล่นชั้นไหน

Font Pera ให้เกณฑ์วินิจฉัยที่ใช้ได้จริงว่าปัญหาที่เจออยู่ควรแก้ที่ชั้นไหน:

ซ่อมที่ context engineering เมื่อ agent ยัง ทำงานเดี่ยว ๆ ไม่ผ่าน — ปรับ prompt, จัดโครงสร้าง input, เพิ่ม file context ให้ model เห็นสิ่งที่ควรเห็น
ขยาย harness engineering เมื่อผลงาน ผ่านแต่ยังไม่ได้มาตรฐานของ project — เพิ่ม guides (rules/specs) และ sensors (test/lint/hooks) ให้ตรวจจับและแก้ตัวเองได้
เพิ่ม loop engineering เมื่อ agent ควรทำงานเองต่อเนื่องเป็นชั่วโมงหรือเป็นวัน โดยไม่ต้องมีคนคอยจุดชนวนทีละรอบ

ลำดับนี้สำคัญ เพราะการกระโดดขึ้นไปเขียน loop ทั้งที่ context ยังมั่วหรือ harness ยังตรวจงานไม่เป็น คือการสร้างเครื่องจักรที่ทำผิดเร็วขึ้นเท่านั้นเอง

บทสรุป

Loop engineering คือชั้นที่เปลี่ยนโจทย์จาก “เขียน prompt ให้เก่ง” เป็น “ออกแบบระบบที่ prompt agent แทนเรา” หัวใจของมันคือวงจร reason → act → observe ที่หมุนอยู่ข้างใน กับการออกแบบสิ่งรอบวงจร — trigger, topology, verifier, stop rule และการแยก recoverable error ออกจาก hard blocker

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

คำเตือนของ Osmani จึงเป็นเข็มทิศที่ดีที่สุด: loop ที่ไม่มีคนดูคือ loop ที่ทำผิดโดยไม่มีคนดู — ลงทุนกับ verifier และ sensor ให้แน่น ก่อนจะปล่อยให้มันเดินเอง

อ่านต่อ / ที่มา

Benjamin Font Pera (Service Lead GenAI), “Loop, Harness, Context Engineering: The Terms Explained” — codecentric (5 กรกฎาคม 2026) · แหล่งอ้างอิงหลักของบทเรียบเรียงนี้ รวมถึงคำพูดของ Boris Cherny และ Addy Osmani
บทก่อนหน้าในซีรีส์: Harness Engineering: โครงครอบรอบ model และ Context Engineering ที่ได้ผลสำหรับ AI Agents
เราจะผลักดัน AI ให้ทำงานอัตโนมัติในการ generate code ได้ไกลแค่ไหน? — Birgitta Böckeler ว่าด้วยความเสี่ยงของการปล่อย agent ทำงานเอง

Loop Engineering: ออกแบบ​วง​วน​ให้ AI agent ทำงาน​เอง​จน​จบ

Loop engineering คือ​อะไร

วงจร​แกน: reason → act → observe

สี่​ชั้น​ของ​การ​ทำงาน​กับ agent

องค์​ประกอบ​ที่​ต้อง​ออกแบบ​ใน1 loop

ระดับ​ของ loop: จาก​ง่าย​ไป​ยาก

ความ​ปลอดภัย: loop ที่​ปล่อย​ไว้ = loop ที่​ทำ​ผิด​โดย​ไม่มี​คน​ดู

แล้ว​เมื่อไร​ควร​ขยับ​ไป​เล่น​ชั้น​ไหน

บท​สรุป

อ่าน​ต่อ / ที่มา