Google 軟แวร์วิศวกร Addy Osmani ได้เขียนบทความเมื่อวันที่ 7 มิถุนายน โดยให้คำนิยาม “Loop Engineering” ว่าเป็นวิธีการออกแบบตัวแทน (agent) ด้วยการใช้ Prompt AI โดยให้ระบบอัตโนมัติมาทดแทนการที่วิศวกรต้องเขียนและควบคุมด้วยมือ ซึ่งประกอบด้วยบล็อกหลัก 5 ชิ้น ได้แก่ Automations, Worktrees, Skills, Plugins/Connectors และ Sub-agents
คำจำกัดความและหน้าที่ของบล็อกทั้ง 5 ชิ้น
ตามกรอบแนวคิดของ Addy Osmani อธิบายว่า:
Automations（ระบบอัตโนมัติ）： งานที่ถูกกระตุ้นตามตารางเวลา (schedule) ทำหน้าที่ดำเนินการอัตโนมัติในส่วนของ “Discovery（การค้นหา/สำรวจ）” และ “Triage（การคัดแยก/จัดลำดับความสำคัญ）” Osmani อธิบายว่า Automations คือกลไกหลักที่ทำให้ลูปกลายเป็นวงรอบที่แท้จริง ไม่ใช่แค่การ “รันครั้งเดียวจบ” Codex app ใช้ Automations ในรูปแบบหน้าต่าง (pagination) และมีคำสั่ง /goal (รันจนกว่าจะถึงเงื่อนไขที่กำหนด); ส่วน Claude Code ทำให้ได้ฟังก์ชันเดียวกันด้วยงานตามกำหนดเวลา (scheduled tasks), cron, /loop, /goal และ GitHub Actions
Worktrees（ทรีงาน/ไดเรกทอรีย่อยของงาน）： ใช้กลไก git worktree เพื่อสร้างไดเรกทอรีทำงานที่แยกกันสำหรับตัวแทนที่ทำงานแบบขนาน (parallel) เพื่อป้องกันความขัดแย้งจากที่หลายตัวแทนแก้ไขไฟล์เดียวกันพร้อมกัน Codex app จะมี worktree สำหรับแต่ละ thread โดยอัตโนมัติ; Claude Code ทำด้วย git worktree และใช้แฟลก --worktree เพื่อให้การแยกตัวทำงานในลักษณะเดียวกัน
Skills（ทักษะ）： ใช้รูปแบบไฟล์ SKILL.md เพื่อบันทึกความรู้ของโปรเจกต์ แนวปฏิบัติ และขั้นตอนการบิลด์ลงในเอกสารภายนอก ทำให้ตัวแทนไม่ต้องคาดเดาบริบทของโปรเจกต์ใหม่ทุกครั้งที่รัน ทั้งสองเครื่องมือใช้รูปแบบ SKILL.md เหมือนกัน Osmani ระบุว่าการอธิบายอย่างชัดเจนย่อมดีกว่าคำบรรยายที่คลุมเครือ
Plugins / Connectors（ปลั๊กอินและคอนเนกเตอร์）： สร้างบน MCP（Model Context Protocol）ทำให้ตัวแทนเข้าถึงระบบภายนอกได้ เช่น Issue Tracker ฐานข้อมูล endpoint ของ API และเครื่องมือสื่อสารต่างๆ Codex app และ Claude Code ต่างก็รองรับ MCP เช่นกัน Osmani ยืนยันว่าคอนเนกเตอร์ชุดเดียวกันมักนำไปใช้ได้โดยตรงในทั้งสองเครื่องมือ
Sub-agents（ซับเอเจนต์）： แยก “ตัวแทนสำหรับการลงมือทำ (execution agent)” ออกจาก “ตัวแทนสำหรับการตรวจสอบ (verification agent)” เป็นบทบาทอิสระ โดยสั่งงานคนละชุดหรือแม้แต่ใช้คนละโมเดลเพื่อให้ตรวจทานกันเอง ลดโอกาสที่ตัวแทนประเมินตัวเองอย่างลำเอียงเกินไป Codex app กำหนดไว้ใน .codex/agents/ ด้วยรูปแบบ TOML; Claude Code กำหนดไว้ใน .claude/agents/ โดยนิยาม Task subagents และ agent teams
หน่วยความจำภายนอก（State）：คำจำกัดความและหน้าที่ขององค์ประกอบที่หก
Osmani ให้คำนิยาม “หน่วยความจำภายนอก” ว่าเป็น “สิ่งใดก็ตามที่อยู่เหนือการสนทนาเพียงครั้งเดียว และใช้บันทึกว่าสิ่งใดทำไปแล้ว รวมถึงขั้นตอนถัดไปคืออะไร” เช่น ไฟล์ Markdown หรือบอร์ด Linear เหตุผลว่าทำไมจึงจำเป็น: โมเดลภาษาขนาดใหญ่ไม่เก็บความจำระหว่างการรันแต่ละครั้ง ดังนั้นความคืบหน้าจึงต้องถูกจัดเก็บไว้นอกโมเดล ไม่ใช่ในบริบท (context window) ของตัวโมเดล
เครื่องมือทั้งสองรองรับกลไกนี้ด้วย: Codex app เชื่อมต่อ Linear ผ่าน Markdown หรือผ่าน Connector; Claude Code เชื่อมต่อ Linear ผ่าน AGENTS.md ไฟล์ความคืบหน้า หรือการเชื่อมต่อผ่าน MCP
คำถามที่พบบ่อย
ความแตกต่างหลักระหว่าง Loop Engineering กับการทำ Prompt Engineering แบบดั้งเดิมคืออะไร?
ตามกรอบของ Addy Osmani การทำ Prompt Engineering แบบดั้งเดิมให้วิศวกรเป็นคนเขียน Prompt ด้วยมือ และโต้ตอบกับตัวแทนทีละรอบ; ส่วน Loop Engineering ออกแบบให้ Automations เป็นตัวกระตุ้นอัตโนมัติ, Worktrees แยกตัวทำงานแบบขนาน, Skills ให้ความรู้, Connectors เชื่อมต่อเครื่องมือ, และ Sub-agents แยกบทบาทระหว่างการลงมือทำกับการตรวจสอบเป็นระบบครบชุด ทำให้บทบาทของวิศวกรจาก “ควบคุมตัวแทนโดยตรง” เปลี่ยนเป็น “ออกแบบระบบที่ทำงานให้ตัวแทนรันได้เอง”
Codex app และ Claude Code ตอนนี้รองรับบล็อกอะไรบ้าง?
จากการเปรียบเทียบของ Osmani ณ เวลาที่บทความเผยแพร่ เครื่องมือทั้งสองรองรับบล็อกทั้ง 5 ชิ้นและกลไกหน่วยความจำภายนอกอย่างครบถ้วน ความแตกต่างหลักอยู่ที่ชื่อเรียกและพาธ (path) ที่เฉพาะเจาะจง: ความสามารถของ Automations มีคู่เทียบกัน, Worktrees อิงตาม git worktree, Skills ใช้รูปแบบ SKILL.md, Plugins/Connectors อิงตาม MCP, และ Sub-agents ใช้ไฟล์กำหนดค่าภายในไดเรกทอรี .agents/
Sub-agents “การแยกการลงมือทำกับการตรวจสอบ” ทำได้อย่างไร?
ตามที่ Osmani อธิบาย การออกแบบ Sub-agents แยกให้ “ตัวแทนที่เขียนโค้ด” กับ “ตัวแทนที่ตรวจสอบโค้ด” เป็นคนละบทบาท สามารถใช้คำสั่งที่แตกต่างกันหรือแม้แต่ใช้โมเดลที่แตกต่างกันได้ Claude Code 的คำสั่ง /goal ใช้หลักการเดียวกันเช่นกัน คือให้โมเดลใหม่เป็นผู้ประเมินว่างานเสร็จสมบูรณ์หรือไม่ ไม่ใช่ให้โมเดลที่ทำงานเป็นคนประเมินตัวเอง Osmani เรียกสิ่งนี้ว่าแนวคิด “คนทำกับคนตรวจ” ซึ่งนำไปใช้กับเงื่อนไขการหยุด (stopping condition) เองด้วย
