Loop engineering คืออะไร? ความหมายของการออกแบบลูป

ความหมายของการออกแบบลูป

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

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

เหตุผลที่คำนี้ปรากฏขึ้นในปี 2026

คำนี้กำลังได้รับการกำหนดความหมายในที่สาธารณะในขณะนี้ GitHub repository cobusgreyling/loop-engineering มีดาวเกิน 9,600 ดวงภายในสองเดือนนับจากวันที่เผยแพร่ครั้งแรก (ณ เดือนกรกฎาคม 2026) พร้อมข้อความว่า "Stop prompting. Design the loop. Get a score." แนวคิดนี้สรุปการเปลี่ยนแปลงออกเป็นองค์ประกอบหลัก 6 ประการ ได้แก่ การจัดตารางเวลา, worktrees, skills, plugins และ connectors, sub-agents และหน่วยความจำถาวรที่จัดเก็บไว้นอกบทสนทนา

เนื้อหาดังกล่าวอ้างคำพูดของ Boris Cherny ซึ่งเป็นผู้ดูแล Claude Code ที่ Anthropic:

ฉันไม่ได้เขียน prompt ให้ Claude อีกต่อไป ฉันมีลูปที่ทำหน้าที่เขียน prompt ให้ Claude อยู่

repository อีกแห่งหนึ่งคือ AI-Builder-Club/skills มีดาวเกือบ 1,100 ดวง (ณ เดือนกรกฎาคม 2026) และระบุบทบาททั้งสองโดยตรง ได้แก่ "codebase harness" ซึ่งทำให้ repository ปลอดภัยสำหรับให้ agent เรียกใช้การทดสอบและการ deploy และ "loop engineer" ซึ่งสร้าง workflow ที่เริ่มทำงานเมื่อได้รับ trigger ดำเนินงาน และเขียนสิ่งที่เรียนรู้ลงในไฟล์ที่ใช้ร่วมกัน เพื่อให้ลูปถัดไปอ่านได้

ไม่มี repository ใดเป็นผู้คิดค้นแนวทางนี้ การรัน nightly build, linter ใน continuous integration หรือ cron job ที่เปิด ticket ล้วนมีรูปแบบเดียวกันนี้อยู่แล้ว สิ่งที่เปลี่ยนแปลงคือ worker ภายในลูปไม่สามารถคาดการณ์ผลลัพธ์ได้ ซึ่งทำให้ระบบโดยรอบต้องทำงานแตกต่างจากเดิม

4 ส่วนของลูป

ลูปที่ทำงานได้ทุกลูปประกอบด้วย 4 ส่วนนี้ หากขาดส่วนใดส่วนหนึ่ง ลูปนั้นอาจทำงานจนรบกวนคุณในเวลา 3am

• ทริกเกอร์ เหตุการณ์ที่เริ่มการทำงานหนึ่งรอบ เช่น timer, webhook, pull request ใหม่ หรือ alert
• ขอบเขต ไฟล์ ข้อมูลรับรอง และเครือข่ายที่ agent เข้าถึงได้ระหว่างการทำงานรอบนั้น
• การตรวจสอบ การตรวจสอบที่มี exit code ซึ่งใช้ตัดสินใจว่าจะเก็บหรือละทิ้งผลลัพธ์ของการทำงานรอบนั้น
• งบประมาณ ขีดจำกัดของ token เวลา และค่าใช้จ่าย ซึ่งจะยุติการทำงานรอบนั้นไม่ว่าจะสำเร็จหรือไม่

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

Trigger: สิ่งที่ปลุก agent

ตัวตั้งเวลาคือ trigger ที่ตรงไปตรงมาที่สุด และบน Linux server นั้น systemd timer เหมาะกว่า cron เนื่องจากบันทึก log ได้ retry ตามเงื่อนไขที่กำหนด และจะไม่เริ่มสำเนาที่สองของ unit ซึ่งยังทำงานอยู่ คุณสมบัติข้อสุดท้ายช่วยกำจัดปัญหาการทำงานซ้อนที่พบบ่อยที่สุดในลูปของ agent นั่นคือการทำงาน 2 รอบแก้ไข branch เดียวกัน

เขียน unit ที่ /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

และเขียน timer ที่ /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers ควรแสดงคอลัมน์ NEXT ซึ่งมีเวลาที่อยู่ในอนาคต และคอลัมน์ LEFT ที่นับถอยหลัง หากไม่แสดงผล แสดงว่า timer ไม่ได้เปิดใช้งาน เพราะ enable หากไม่มี --now จะกำหนดเวลาให้ทำงานเฉพาะเมื่อ boot ครั้งถัดไปเท่านั้น TimeoutStartSec=1800 มีความสำคัญกว่าที่เห็น: หาก agent ค้างขณะรอ input unit จะอยู่ในสถานะ active ตลอดไป และ timer จะไม่ทำงานอีก อ่านผลการทำงานหนึ่งรอบด้วย journalctl -u agent-loop.service -n 50

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

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n จะออกทันทีด้วย status 1 เมื่อมีการถือ lock อยู่ ทำให้การทำงานรอบที่สองหยุดไปโดยไม่มีเสียง แทนที่จะแข่งขันกับรอบแรก การตั้งค่า systemd service และ timer แบบเดียวกันนี้ใช้ได้กับ job ที่ทำงานเป็นเวลานานทุกชนิดบนเครื่อง ไม่ว่าจะเป็น agent หรือไม่ก็ตาม

ขอบเขต: ให้แต่ละรอบใช้สำเนาของตนเอง

Agent ที่แก้ไข working tree ของคุณอาจทำให้งานที่ยังไม่ได้ commit สูญหายได้ Git worktrees ช่วยแก้ปัญหานี้ได้อย่างประหยัด แต่ละรอบจะมีไดเรกทอรีและ branch ของตนเอง โดยใช้ object store ร่วมกัน

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list จะแสดงหนึ่งบรรทัดต่อหนึ่ง tree พร้อม path, commit และ branch เมื่อรอบการทำงานสิ้นสุดลง git worktree remove /srv/agent/work/triage-01 จะลบไดเรกทอรี และ git worktree prune จะลบรายการที่ไดเรกทอรีหายไปแล้ว เมื่อถึงจุดนี้ การทำงานแบบขนานจะปลอดภัย เพราะ agent สองตัวที่ทำงานบน branch สองรายการในไดเรกทอรีสองแห่งจะไม่สามารถเขียนทับกันได้

ขอบเขตนี้เกี่ยวข้องกับข้อมูลรับรองด้วย Loop ที่ทำงานโดยไม่มีผู้ดูแลจะถือ token ที่มีอายุยาวนาน และแต่ละรอบอาจทำให้ token รั่วไหลเข้าไปใน log, commit หรือ model context ได้ จำกัดขอบเขตของ token ให้ใช้ได้เฉพาะ repository เดียวที่ loop เข้าถึงได้ หากทำได้ ให้เก็บ token ไว้นอก environment ที่ shell ของ agent เองมองเห็น และอ่าน วิธีเก็บความลับให้พ้นจาก AI agents ก่อนอนุญาตให้ loop เข้าถึงระบบ production หากต้องการกั้นขอบเขตให้ชัดเจนยิ่งขึ้น ให้เรียกใช้ loop ทั้งหมดบน VM ชั่วคราวที่สามารถทำลายได้หลังแต่ละรอบ

การตรวจสอบ: ด่านที่ทำให้ลูปปลอดภัย

ส่วนนี้คือสิ่งที่แยกลูปออกจาก cron job ที่เพียงพิมพ์คำสั่ง เอาต์พุตของเอเจนต์เป็นข้อเสนอ ด่านตรวจสอบเป็นผู้ตัดสิน

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail ทำงานจริงในสคริปต์นี้ หากไม่มี -e ระบบจะไม่สนใจว่า git fetch ล้มเหลว และการทำงานจะดำเนินต่อโดยใช้ origin/main ที่ล้าสมัย หากไม่มี -u เมื่อชื่อของตัวแปรสะกดผิด ระบบจะขยายค่าเป็นสตริงว่าง จากนั้นการล้างข้อมูลจะทำงานกับพาธที่ไม่ถูกต้อง แทนที่จะหยุดทำงานพร้อมแสดงข้อผิดพลาดอย่างชัดเจน

บล็อก if ! npm test คือแนวคิดทั้งหมด รหัสทางออกของการตรวจสอบที่คุณเชื่อถืออยู่แล้ว ไม่ว่าจะเป็นชุดทดสอบหรือเครื่องมือตรวจสอบชนิดข้อมูล จะเป็นตัวตัดสินว่าจะ push หรือทำลาย branch นั้น ลูปที่ไม่มีด่านตรวจสอบจะสร้างงานที่ไม่มีใครมีเวลาตรวจสอบ ซึ่งแย่กว่าการไม่สร้างงานเลย ลูปที่มีด่านตรวจสอบจะสร้าง branch ที่ผ่านเกณฑ์เดียวกับที่ branch ของผู้มีส่วนร่วมที่เป็นมนุษย์ต้องผ่านอยู่แล้ว

เลือกด่านตรวจสอบที่รายงานผลล้มเหลวตามจริง ชุดทดสอบที่ผ่านเมื่อไม่มีการเปลี่ยนแปลงใด ๆ จะสอนลูปว่าการไม่ทำอะไรเลยถือเป็นความสำเร็จ Repository ที่มีการทดสอบไม่เข้มแข็งจะได้ลูปที่ไม่เข้มแข็งเช่นกัน นี่คือเหตุผลที่ repository ที่กำลังได้รับความนิยมจะจัดให้ "เตรียม codebase ให้พร้อมสำหรับเอเจนต์" มาก่อน "เขียนลูป"

งบประมาณ: สิ่งที่ทำให้การทำงานหยุดลง

เอเจนต์ที่ลองใหม่ตลอดไปคือเอเจนต์ที่มีค่าใช้จ่ายไม่จำกัด กำหนดเพดานเวลาตามนาฬิกาให้ทุกลูป โดยบังคับใช้ผ่าน TimeoutStartSec ข้างต้น กำหนดจำนวนครั้งที่ลองใหม่ภายในสคริปต์ และกำหนดเพดานค่าใช้จ่ายโดยบัญชีของผู้ให้บริการ จากนั้นบันทึกค่าใช้จ่ายของการทำงานแต่ละครั้ง เพื่อให้คุณเห็นว่าลูปเริ่มใช้ทรัพยากรเกินขอบเขตก่อนที่ใบแจ้งหนี้จะแสดงผล การควบคุมค่าใช้จ่ายสำหรับ agent VPS ที่ทำงานตลอดเวลา ครอบคลุมด้านการบันทึกบัญชี และ การจัดการบริบทที่เอเจนต์เก็บไว้ระหว่างแต่ละรอบ ครอบคลุมปัจจัยสำคัญที่สุดประการหนึ่งของค่าใช้จ่ายต่อการทำงาน เนื่องจากลูปที่อ่าน repository เดิมซ้ำทุก 30 นาทีจะมีค่าใช้จ่ายทุก 30 นาที

ค่าใช้จ่ายเป็นเหตุผลที่ลูปมักเหมาะกว่าการเปิด session เดียวยาว ๆ การทำงานที่เริ่มต้นใหม่ ทำงานเฉพาะอย่าง และสิ้นสุดลง จะรักษาบริบทให้มีขนาดเล็ก session ที่เปิดทิ้งไว้เป็นเวลาแปดชั่วโมงจะเก็บความผิดพลาดก่อนหน้าทั้งหมดไว้ในประวัติ และมีค่าใช้จ่ายสำหรับ transcript ทั้งหมดในทุกการโต้ตอบ

รูปแบบที่ repositories ซึ่งกำลังได้รับความนิยมกำหนดไว้

repository loop-engineering แสดงรูปแบบสำหรับระบบจริงไว้ 7 รูปแบบ และควรอ่านในลักษณะรายการตัวเลือก ไม่ใช่คำประกาศแนวคิด ได้แก่ การคัดแยกงานประจำวัน ระบบติดตาม pull request ที่ตรวจสอบความคิดเห็นในการรีวิวและตอบกลับ ระบบกวาดงาน continuous integration ที่นำ build ซึ่งล้มเหลวกลับมาดำเนินการ ระบบกวาดตรวจ dependency ระบบร่าง changelog การล้างงานหลัง merge และการคัดแยก issue

สิ่งที่รูปแบบเหล่านี้มีร่วมกันคืองานที่มีขอบเขตแคบและมีเงื่อนไขผ่านที่ชัดเจน "แก้ build ที่ล้มเหลว" มีเงื่อนไขผ่านที่เครื่องอ่านได้ แต่ "ปรับปรุง codebase" ไม่มีเงื่อนไขดังกล่าว จึงไม่กลายเป็น loop แต่กลายเป็นงานยุ่งเหยิงที่มีตารางเวลา

รูปแบบเหล่านี้ยังมีบันทึกที่เขียนไว้อย่างเป็นระบบ ทั้ง 2 repositories ผลักสถานะออกจากบทสนทนาไปเก็บไว้ในไฟล์ภายใน repository ได้แก่ สิ่งที่ทำงาน สิ่งที่พบ และสิ่งที่ตัดสินใจ ไฟล์ดังกล่าวคือหน่วยความจำของ loop และทำให้ loop ที่ 2 สามารถต่อยอดจากงานของ loop แรกได้ แทนที่จะค้นพบข้อมูลเดิมซ้ำ นอกจากนี้ยังเป็นวิธีตรวจสอบการทำงานของ agent ภายหลังได้ด้วย เนื่องจาก context ของโมเดลจะหายไปทันทีที่การทำงานสิ้นสุดลง

วงจรล้มเหลวตรงไหน

ความล้มเหลวเหล่านี้น่าเบื่อและเกิดซ้ำในหลายทีม

• ไม่มีจุดควบคุม ผลลัพธ์สะสมโดยไม่มีใครตรวจสอบ ความเชื่อมั่นลดลง และมีการปิดวงจร
• ทำงานทับซ้อนกัน มีการทำงาน 2 รายการบน branch เดียว หรือมี agent 2 รายการใน working tree เดียว จนเกิดความขัดแย้งที่ agent ต้องพยายามแก้ไข
• การเปลี่ยนแปลงโดยไม่มีการแจ้งเตือน วงจรยังทำงานผ่านต่อไป เพราะการตรวจสอบอ่อนเกินกว่าจะทำให้ล้มเหลว
• ขอบเขตไม่จำกัด trigger ที่ทำงานกับทุก commit ใน repository ที่มีการใช้งานสูง จะกลายเป็นปัญหาด้านค่าใช้จ่ายภายใน 1 วัน

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

เริ่มต้นโดยไม่ต้องรู้คำศัพท์

คุณไม่จำเป็นต้องใช้เฟรมเวิร์ก เซิร์ฟเวอร์ Linux ขนาดเล็กที่เปิดทำงานตลอดเวลา ที่เก็บ Git ซึ่งชุดทดสอบล้มเหลวเมื่อควรล้มเหลว ตัวตั้งเวลา systemd 1 ตัว และเชลล์สคริปต์ 1 รายการที่มี if อยู่ภายใน จะทำให้เกิดวงจรการทำงานที่สมบูรณ์ นี่เป็นจุดเริ่มต้นที่เหมาะกับคนส่วนใหญ่จริง ๆ เพราะคำถามด้านการออกแบบจะได้รับคำตอบจากการใช้งานจริง ไม่ใช่จากการเลือกเครื่องมือ เมื่อวงจรหนึ่งทำงานได้เสถียรแล้ว การเรียกใช้งานวงจรที่สองก็แทบเป็นเพียงการเพิ่มตัวตั้งเวลาอีก 1 ตัวและ worktree อีก 1 รายการ ดู วิธีเรียกใช้ coding AI agent บน VPS สำหรับการตั้งค่าพื้นฐาน และดู ตัวเลือก AI agent แบบโฮสต์เองในปัจจุบัน หากคุณต้องการให้ agent ทำงานบนฮาร์ดแวร์ที่คุณควบคุมเอง

FAQ

งาน loop engineering แตกต่างจาก prompt engineering หรือไม่

Prompt engineering ปรับปรุงข้อความเดียว เช่น การใช้ถ้อยคำ ตัวอย่าง และรูปแบบผลลัพธ์ ส่วน loop engineering ปรับปรุงวงจรที่ล้อมรอบข้อความนั้น ได้แก่ trigger ที่เริ่มการทำงาน, sandbox ที่ใช้ทำงาน, การตรวจสอบที่ยอมรับหรือปฏิเสธผลลัพธ์ และ budget ที่ยุติการทำงาน คุณยังต้องมี prompt ที่ดีภายใน loop แต่ prompt จะไม่ใช่สิ่งที่ต้องปรับทุกวันอีกต่อไป เพราะ gate และ trigger มีผลต่อผลลัพธ์มากกว่า

ต้องใช้ framework เพื่อสร้าง agent loop หรือไม่

ไม่จำเป็น systemd timer, git worktree สำหรับแต่ละรอบ, shell script ที่จบด้วยคำสั่งทดสอบ และ spend cap ในบัญชี provider ครอบคลุมองค์ประกอบทั้งหมดตามนิยามนี้ Framework เพิ่มอินเทอร์เฟซสำหรับการจัดตาราง รูปแบบหน่วยความจำที่ใช้ร่วมกัน และการกำหนดเส้นทางระหว่างหลาย agent ซึ่งมีประโยชน์เมื่อคุณเรียกใช้หลาย loop แต่สิ่งเหล่านี้ไม่ใช่ข้อกำหนดเริ่มต้นสำหรับ loop แรก

codebase harness คืออะไร

คือชุดองค์ประกอบที่ทำให้ agent ทำงานใน repository ได้โดยไม่มีมนุษย์อยู่ด้วย ได้แก่ การตั้งค่าด้วยคำสั่งเดียว, การทดสอบที่ทำงานแบบไม่โต้ตอบและแสดงความล้มเหลวอย่างชัดเจน, linter และวิธี deploy หรือ preview การเปลี่ยนแปลง คำนี้เกิดขึ้นในช่วงเดียวกับกระแส repository ในปี 2026 ที่เกี่ยวข้องกับ loop engineering การทดสอบในทางปฏิบัติทำได้ง่าย: หากผู้ร่วมพัฒนาที่เป็นมนุษย์คนใหม่ไม่สามารถเริ่มจาก clone ไปจนถึงการทดสอบที่ผ่านทั้งหมดด้วยคำสั่งเดียว agent ก็ทำไม่ได้เช่นกัน

จะหยุด agent loop ไม่ให้สร้างค่าใช้จ่ายสูงได้อย่างไร

กำหนดเพดานไว้ 3 จุด ตั้งค่า TimeoutStartSec ใน systemd unit เพื่อให้ยุติการทำงานที่ค้างอยู่ กำหนดจำนวน retry สูงสุดภายใน script แทนการวนซ้ำจนกว่าจะสำเร็จ และกำหนด hard spend limit ในบัญชี API เพราะนี่คือเพดานเดียวที่ agent ไม่สามารถหาวิธีหลีกเลี่ยงได้ จากนั้นบันทึกค่าใช้จ่ายต่อรอบ เนื่องจาก loop ที่มีค่าใช้จ่ายเพิ่มเป็น 2 เท่ามักเป็น loop ที่ขอบเขตงานขยายออกไปโดยไม่มีการกำหนดไว้อย่างชัดเจน

งานใดควรนำมาทำเป็น loop ก่อน

เลือกงานที่มีเงื่อนไขผ่านซึ่งอ่านได้ด้วยเครื่อง และมี blast radius ต่ำ การแก้ไข build ที่ล้มเหลว การอัปเดต dependency และการสร้าง changelog ใหม่ล้วนเหมาะสม เพราะ test suite หรือ diff สามารถยืนยันผลลัพธ์ได้ งานที่ไม่มีขอบเขตชัดเจน เช่น การ refactor หรือการออกแบบ ยังไม่เหมาะสม เนื่องจากไม่มีสิ่งให้ gate ตรวจสอบ และ loop ที่ไม่มี gate เป็นวิธีราคาแพงในการสร้างภาระงานสำหรับการ review