Loop engineering คืออะไร? อธิบายแนวคิดการออกแบบ AI agent

ความหมายของ Loop engineering

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

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

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

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

Repository นี้ให้เครดิต Boris Cherny ซึ่งเป็นผู้นำทีม Claude Code ที่ Anthropic ว่าเป็นหนึ่งในแรงบันดาลใจ โดยคำพูดของเขาที่มีการรายงานอย่างกว้างขวางคือ:

ผมไม่เขียน prompt ให้ Claude อีกต่อไปแล้ว ผมมี loop ที่ทำงานอยู่ซึ่งคอยเขียน prompt ให้ Claude แทน

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

ไม่มี repository ใดที่เป็นผู้คิดค้นแนวทางปฏิบัตินี้ขึ้นมา ผู้ที่เคยรัน nightly build, linter ในระบบ continuous integration หรือ cron job ที่เปิด ticket ต่างคุ้นเคยกับรูปแบบนี้อยู่แล้ว สิ่งที่ใหม่คือการที่ผู้ปฏิบัติงานภายใน loop ในปัจจุบันมีความไม่แน่นอน (non-deterministic) ซึ่งส่งผลให้กลไกที่อยู่ล้อมรอบจำเป็นต้องปรับเปลี่ยนการทำงานตามไปด้วย

องค์ประกอบสี่ส่วนของลูป

ลูปที่ทำงานได้จริงต้องมีองค์ประกอบครบทั้งสี่ส่วนนี้ หากลูปใดขาดส่วนใดส่วนหนึ่งไป ลูปนั้นจะเป็นสาเหตุที่ทำให้คุณต้องตื่นขึ้นมาแก้ไขปัญหาตอนตี 3

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

หากคุณนำองค์ประกอบทั้งสี่นี้มาตั้งเป็นคำถาม คุณจะได้แนวทางการตรวจสอบการออกแบบ (design review) สำหรับเอเจนต์ทุกตัวที่คุณกำลังจะปล่อยให้ทำงานแบบอัตโนมัติ

ตัวกระตุ้น: สิ่งที่ปลุกเอเจนต์ให้ทำงาน

Timer เป็นตัวกระตุ้นที่เรียบง่ายที่สุด และบนเซิร์ฟเวอร์ Linux นั้น systemd timer มีประสิทธิภาพเหนือกว่า cron เพราะสามารถบันทึก log, กำหนดเงื่อนไขการลองใหม่ได้ตามต้องการ และจะไม่เริ่มการทำงานของ unit ซ้ำหากตัวเดิมยังทำงานอยู่ คุณสมบัติสุดท้ายนี้ช่วยขจัดบั๊กที่พบบ่อยที่สุดในลูปของเอเจนต์ นั่นคือการที่สองโปรเซสพยายามแก้ไข branch เดียวกันพร้อมกัน

ขั้นแรก ให้สร้าง user แยกสำหรับเอเจนต์โดยเฉพาะ user นี้ถือเป็นส่วนหนึ่งของขอบเขตความปลอดภัย ดังนั้นให้สิทธิ์เป็นเจ้าของเฉพาะ /srv/agent เท่านั้น:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

จากนั้นเขียน 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 จะเป็นการตั้งเวลาให้ทำงานเฉพาะตอนบูตเครื่องครั้งถัดไปเท่านั้น TimeoutStartSec=1800 มีความสำคัญมากกว่าที่เห็นภายนอก บริการประเภท Type=oneshot จะถูกนับว่ากำลังเริ่มทำงานจนกว่าสคริปต์จะจบการทำงาน และโดยปกติ systemd จะปิดการจำกัดเวลา (timeout) สำหรับ unit ประเภท oneshot ดังนั้นหากไม่มีบรรทัดนี้ เอเจนต์ที่ค้างระหว่างรอ input จะทำให้ unit ติดอยู่ในสถานะ activating ตลอดไป และเมื่อ timer ทำงานในรอบถัดไปก็จะพบว่างานเดิมยังค้างอยู่และไม่เริ่มงานใหม่ แต่เมื่อใส่บรรทัดนี้ systemd จะยุติการทำงานหลังจากผ่านไป 30 นาทีและทำเครื่องหมายว่าล้มเหลว หากคุณเปลี่ยน unit ไปเป็นค่าเริ่มต้นแบบ Type=simple ตัว TimeoutStartSec จะไม่ครอบคลุมถึงตัวการทำงานนั้นอีกต่อไป และ RuntimeMaxSec= จะเป็นค่าที่ใช้จำกัดเวลาแทน คุณสามารถอ่านสถานะการทำงานได้ด้วย 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 จะจบการทำงานทันทีด้วยสถานะ 1 เมื่อมีการล็อกอยู่ ทำให้การทำงานรอบที่สองหายไปอย่างเงียบๆ แทนที่จะเกิดการแย่งทรัพยากรกับรอบแรก ทั้งนี้ การตั้งค่า systemd service และ timer สามารถนำไปใช้กับงานที่ใช้เวลานานบนเซิร์ฟเวอร์ได้ทุกประเภท ไม่ว่าจะเป็นเอเจนต์หรือไม่ก็ตาม

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

เอเจนต์ที่แก้ไข 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 พร้อมพาธ, commit และ branch เมื่อการทำงานสิ้นสุดลง git worktree remove /srv/agent/work/triage-01 จะลบ worktree นั้นออก แต่จะลบได้เฉพาะเมื่อ tree นั้นสะอาดเท่านั้น หาก tree มีไฟล์ที่ไม่ได้ติดตาม (untracked files), ไฟล์ที่ถูกติดตามแต่มีการแก้ไข (modified tracked files) หรือมี submodules อยู่ Git จะปฏิเสธการทำงานจนกว่าคุณจะเพิ่ม --force เข้าไป ซึ่งเป็นเหตุผลว่าทำไมสคริปต์ gate ด้านล่างจึงบังคับให้ลบเฉพาะพาธที่ทิ้งการทำงานนั้นไป git worktree prune จะล้างรายการที่ไดเรกทอรีหายไปแล้ว การวนลูปแบบขนานจะปลอดภัยในจุดนี้ เพราะเอเจนต์สองตัวบนสอง branch ในสองไดเรกทอรีจะไม่สามารถเขียนทับงานของกันและกันได้

ขอบเขตยังรวมถึงเรื่องข้อมูลประจำตัว (credentials) ด้วย การวนลูปที่ทำงานโดยไม่มีผู้ดูแลจะถือครองโทเค็นที่มีอายุการใช้งานยาวนาน และทุกการทำงานคือโอกาสที่โทเค็นจะรั่วไหลลงใน log, commit หรือบริบทของโมเดล ควรจำกัดขอบเขตของโทเค็นให้ใช้ได้เฉพาะ repository ที่ลูปนั้นเข้าถึง เก็บโทเค็นไว้นอกสภาพแวดล้อมที่ shell ของเอเจนต์มองเห็นหากทำได้ และอ่าน วิธีเก็บความลับให้ห่างจาก AI agents ก่อนที่คุณจะมอบสิทธิ์การเข้าถึงระดับ production ให้กับลูป สำหรับการป้องกันที่เข้มงวดขึ้น ให้รันลูปทั้งหมดบน VM แบบใช้แล้วทิ้งที่คุณสามารถทำลายได้หลังจบการทำงานแต่ละครั้ง เครื่องมือที่คุณเลือกใช้ก็เป็นส่วนหนึ่งของการกำหนดขอบเขตก่อนที่คุณจะเริ่มเขียนโค้ด ดังนั้นจึงควรศึกษา การเปรียบเทียบระหว่าง managed sandbox ของ Cowork กับ Claude Code บนเครื่องของคุณเอง ก่อนตัดสินใจว่าคุณจำเป็นต้องสร้างระบบแยกส่วนด้วยตัวเองมากน้อยเพียงใด

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

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

#!/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 การพิมพ์ชื่อตัวแปรผิดจะขยายผลเป็นสตริงว่าง และการล้างข้อมูลจะทำงานกับ path ที่ผิดแทนที่จะแจ้งเตือนความล้มเหลวอย่างชัดเจน บรรทัดสุดท้ายไม่มี --force โดยเจตนา หากการทำงานทิ้งไฟล์ที่ไม่ได้ติดตามหรือไม่ได้ commit ไว้ใน tree ตัว git จะปฏิเสธการลบ และ -e จะยุติการทำงานด้วยข้อผิดพลาดหลังจาก push แทนที่จะลบงานที่ยังไม่มีใคร commit ทิ้งไปโดยเงียบๆ

บล็อก if ! npm test คือหัวใจสำคัญของแนวคิดนี้ exit code ของการตรวจสอบที่คุณเชื่อถือได้ ไม่ว่าจะเป็น test suite หรือ type checker จะเป็นตัวตัดสินว่า branch นั้นจะถูก push หรือถูกทำลาย ลูปที่ไม่มีประตูกั้นจะสร้างงานที่ไม่มีใครมีเวลาตรวจสอบ ซึ่งแย่ยิ่งกว่าการไม่มีงานเลย ลูปที่มีประตูกั้นจะสร้าง branch ที่ผ่านเกณฑ์มาตรฐานเดียวกับที่ branch ของผู้ร่วมพัฒนาที่เป็นมนุษย์ต้องผ่าน ประตูกั้นที่ผ่านการตรวจสอบ (green gate) ไม่ได้บอกว่า agent แก้ไขโค้ดไปมากน้อยเพียงใด ดังนั้นจึงควรจับคู่การตรวจสอบนี้เข้ากับคำสั่งพื้นฐาน เช่น กฎที่ทำให้ agent เลือกการเปลี่ยนแปลงที่เล็กที่สุดที่ใช้งานได้ ซึ่งจะช่วยรักษาขนาดของ diff ให้เล็กพอที่การตรวจสอบจะทำได้โดยไม่สิ้นเปลืองทรัพยากร

เลือกประตูกั้นที่ล้มเหลวอย่างตรงไปตรงมา test suite ที่ผ่านการทดสอบแม้ใน diff ที่ว่างเปล่าจะสอนให้ลูปเข้าใจว่าการไม่ทำอะไรเลยคือความสำเร็จ Repository ที่มีชุดทดสอบอ่อนแอจะได้ลูปที่อ่อนแอตามไปด้วย นี่คือเหตุผลที่ repository ยอดนิยมมักให้ความสำคัญกับ "การเตรียม codebase ให้พร้อมสำหรับ agent" ก่อน "การเขียนลูป" หากคุณต้องการทราบว่าชุดทดสอบของคุณจะตรวจพบ regression ได้จริงหรือไม่ แทนที่จะแค่รันโค้ดผ่านๆ ไป mutation testing คือการตรวจสอบที่ให้คำตอบนั้น และ agent ที่ส่งรายงานหลักฐานที่รันซ้ำได้กลับมาแทนการขอให้คุณอ่าน diff จะเปลี่ยนคำตอบนั้นให้เป็นสิ่งที่คุณสามารถยืนยันได้ด้วยตนเอง

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

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

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

รูปแบบที่ repository ยอดนิยมนำมาประมวลผลเป็นมาตรฐาน

Repository ด้าน loop-engineering ได้ระบุรูปแบบการทำงานในระดับ production ไว้ 8 รูปแบบ (ข้อมูล ณ 2026-10-27) ซึ่งควรพิจารณาว่าเป็นรายการทางเลือกมากกว่าจะเป็นหลักการที่ตายตัว ได้แก่ การคัดกรองงานประจำวัน (Daily triage), loop ขนาดเล็กที่รันเป็น GitHub Action โดยไม่มีไฟล์สถานะ, ผู้ช่วยดูแล pull-request ที่คอยเฝ้าดูความคิดเห็นในการรีวิวและตอบกลับ, ตัวจัดการ continuous-integration ที่คอยเก็บงาน build ที่ล้มเหลว, ตัวจัดการ dependency, ผู้ร่าง changelog และการทำความสะอาดหลังการ merge รวมถึงการคัดกรอง issue

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

นอกจากนี้ ทั้งหมดยังมีบันทึกที่เป็นลายลักษณ์อักษรร่วมกัน ทั้งสอง repository จะผลักสถานะออกจากบทสนทนาไปเก็บไว้ในไฟล์ภายใน repository แทน ได้แก่ สิ่งที่รันไปแล้ว สิ่งที่พบ และสิ่งที่ตัดสินใจ ไฟล์นั้นคือหน่วยความจำของ loop และเป็นเหตุผลที่ทำให้ loop ที่สองสามารถต่อยอดจากงานของ loop แรกได้แทนที่จะต้องเริ่มต้นใหม่ทั้งหมด นอกจากนี้ยังเป็นวิธีที่คุณใช้ตรวจสอบ (audit) agent หลังจากเหตุการณ์เกิดขึ้นแล้ว เนื่องจากบริบทของโมเดลจะหายไปทันทีที่การรันสิ้นสุดลง การประสานงานแบบสด (live coordination) เป็นช่องทางแยกต่างหาก และ Claude Code session หนึ่งสามารถส่งต่องานให้อีก session หนึ่งบนเครื่องเดียวกันได้ ในขณะที่ทั้งคู่ยังคงรันอยู่ แต่ไม่มีสิ่งใดในการแลกเปลี่ยนนั้นที่จะคงอยู่ยาวนานกว่า session ดังนั้นไฟล์จึงยังคงเป็นส่วนที่คุณสามารถกลับมาอ่านย้อนหลังได้

จุดที่ลูปทำงานล้มเหลว

ความล้มเหลวเหล่านี้เป็นเรื่องปกติและเกิดขึ้นซ้ำๆ ในหลายทีม

• ไม่มีการตรวจสอบ (No gate): ผลลัพธ์สะสมมากขึ้นเรื่อยๆ โดยไม่มีใครตรวจสอบ ความเชื่อมั่นจึงลดลงและลูปถูกปิดการใช้งานในที่สุด
• การทำงานซ้อนทับ (Overlap): การรันงานสองครั้งบน branch เดียวกัน หรือการมี agent สองตัวใน working tree เดียวกัน ทำให้เกิดความขัดแย้งที่ agent พยายามแก้ไขเอง
• การเบี่ยงเบนอย่างเงียบเชียบ (Silent drift): ลูปยังคงผ่านการทดสอบเพราะเงื่อนไขการตรวจสอบอ่อนเกินไปจนไม่พบข้อผิดพลาด
• ขอบเขตไม่จำกัด (Unbounded scope): ทริกเกอร์ที่ทำงานทุกครั้งที่มีการ commit ใน repository ที่มีการใช้งานสูง จะกลายเป็นปัญหาด้านค่าใช้จ่ายภายในเวลาเพียงหนึ่งวัน

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

เริ่มต้นใช้งานโดยไม่ต้องพึ่งพาเฟรมเวิร์ก

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

FAQ

Loop engineering ต่างจาก prompt engineering อย่างไร?

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

ฉันจำเป็นต้องใช้ framework เพื่อสร้างลูปของเอเจนต์หรือไม่?

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

Codebase harness คืออะไร?

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

ฉันจะป้องกันไม่ให้ลูปของเอเจนต์สร้างค่าใช้จ่ายจำนวนมากได้อย่างไร?

จำกัดไว้ใน 3 จุด ตั้งค่า TimeoutStartSec ใน unit ประเภท Type=oneshot ของ systemd ดังที่กล่าวข้างต้น เพื่อให้การทำงานที่ค้างอยู่ถูกยุติลง (สำหรับบริการประเภท Type=simple ให้ใช้ RuntimeMaxSec แทน) กำหนดจำนวนครั้งการลองใหม่ภายในสคริปต์แทนการวนลูปจนกว่าจะสำเร็จ และตั้งค่าจำกัดการใช้จ่ายสูงสุดในบัญชี API เพราะนั่นเป็นเพดานเดียวที่เอเจนต์ไม่สามารถหลบเลี่ยงได้ นอกจากนี้ควรบันทึกค่าใช้จ่ายต่อรอบการทำงานไว้ด้วย เพราะลูปที่มีค่าใช้จ่ายเพิ่มขึ้นเป็นสองเท่ามักเป็นลูปที่ขอบเขตงานขยายตัวออกไปโดยไม่รู้ตัว

งานประเภทใดที่ควรเปลี่ยนเป็นลูปก่อน?

เลือกงานที่มีเงื่อนไขการผ่านที่เครื่องจักรตรวจสอบได้และมีผลกระทบวงกว้างต่ำ เช่น การแก้ไข build ที่ล้มเหลว, การอัปเดต dependency และการสร้าง changelog ใหม่ เพราะชุดการทดสอบหรือ diff สามารถพิสูจน์ผลลัพธ์ได้ ส่วนงานที่ปลายเปิด เช่น การ refactor หรือการออกแบบ ยังไม่เหมาะในขณะนี้ เพราะไม่มีสิ่งที่ตัวคัดกรองจะตรวจสอบได้ และลูปที่ไม่มีตัวคัดกรองเป็นวิธีที่สิ้นเปลืองในการสร้างภาระงานตรวจสอบ (review debt) ให้กับผู้อื่น