จาก "ป้อนคำสั่ง AI เอง" สู่ "ออกแบบ loop", และทำไม loop หนึ่งวันถึงกลายเป็น graph
โดย Nokka (นก-กา) | 23 สิงหาคม 2026
บทความนี้เขียนโดย AI (deepseek-v4-pro via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)
ก่อนอื่น, ทำความเข้าใจศัพท์
ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:
- Loop Engineering (วิศวกรรมลูป): การออกแบบระบบที่ prompt agent ให้เองอัตโนมัติ แทนที่มนุษย์นั่งพิมพ์ทีละคำสั่ง
- Graph Engineering (วิศวกรรมกราฟ): การจัดหลาย agent, loop, tool และ evaluator เป็นกราฟชัดเจน (nodes + edges + shared state + routing)
- Generator/Evaluator Separation (แยกคนทำกับคนตรวจ): หลักการที่โมเดลที่เขียนโค้ด ต้องไม่เป็นคนตรวจงานตัวเอง
ถ้าให้อุปมา: ถ้า harness คือ "รถยนต์หนึ่งคัน" loop คือ "ระบบขับเคลื่อนอัตโนมัติที่รถวิ่งไปเอง" และ graph คือ "เครือข่ายถนนทั้งเมืองที่รถหลายคันประสานกัน"
จุดเปลี่ยน: มนุษย์หยุดเป็นคนกดปุ่ม "start"
12 บทก่อนหน้านี้ ทั้งหมดตั้งอยู่บนสมมติฐานเดียว: คุณนั่งอยู่หน้าคีย์บอร์ด พิมพ์คำสั่งทีละคำสั่ง
คุณเขียน AGENTS.md, สร้าง state management, จำกัด scope ด้วย feature list, จบ session สะอาด, แต่ "ไกปืน" ของทุกอย่างคือคุณเสมอ
Loop engineering คือการส่ง "ปุ่ม start" ให้ระบบ ไม่ใช่สละการควบคุม แต่ยกระดับมันขึ้นไปอีกชั้น
/goal: loop ที่ง่ายที่สุด
ต้นปี 2026, Claude Code และ Codex ปล่อยฟีเจอร์เดียวกันแทบพร้อมกัน: /goal
/goal "All tests pass, zero lint warnings, merge to main"
แล้วคุณปิด laptop ไปนอน 8 ชั่วโมงต่อมา agent วิเคราะห์, เขียนโค้ด, test, แก้, merge เองหมด, retry ตอน fail, เปลี่ยนวิธีตอนติด, หยุดตอนเสร็จ
ความต่างระหว่าง /goal กับ prompt ปกติมีแค่ 1 อย่าง แต่เปลี่ยนทุกอย่าง:
| Prompt ปกติ | /goal |
|
|---|---|---|
| คุณให้อะไร | ทำอะไรต่อไป | หน้าตาตอนจบเป็นยังไง |
| agent ทำอะไร | รันครั้งเดียว | วนจนสำเร็จ |
| ใครตัดสินว่าเสร็จ | คุณ | เงื่อนไขหยุดที่ตรวจสอบได้ |
| คุณเดินไปไหนได้ไหม | ไม่ได้ | ได้ทันทีที่พิมพ์ |
ทำไม /goal ถึงเกิด (4 ขั้นวิวัฒนาการ)
- พิมพ์ทีละคำสั่ง, "เขียนฟังก์ชันนี้", "เพิ่ม test", "แก้ตรรกะนี้" คุณคือ scheduler ทั้ง pipeline
- prompt ยาวหลายขั้น, "วิเคราะห์ก่อน, แล้วเขียน, แล้วรัน test, ถ้า fail ก็แก้" แต่คุณยังต้องเฝ้า
- agent คิดเอง, หลังแต่ละขั้นดูผลแล้วตัดสินใจต่อเอง แต่ปัญหา: "เสร็จ" ที่มาจากปาก agent เองเชื่อถือได้ไหม? คำตอบ: ไม่
- ตัดสินเสร็จแบบอิสระ, เอา "ตัดสินว่าเสร็จ" ออกจากมือ agent ไปให้ผู้ตัดสินอิสระ (โมเดลอื่น, สคริปต์, test command)
มิถุนายน 2026: 3 คนจุดชนวนเดียวกันใน 1 สัปดาห์
- Peter Steinberger (ผู้สร้าง OpenClaw): "คุณไม่ควร prompt coding agent อีกต่อไป คุณควรออกแบบ loop ที่ prompt agent ของคุณ"
- Boris Cherny (หัวหน้า Claude Code ที่ Anthropic): "ผมไม่ prompt Claude แล้ว ผมมี loop รันคอย prompt Claude และตัดสินใจว่าจะทำอะไร งานของผมคือเขียน loop"
- Addy Osmani (Google Chrome): ตั้งชื่อแนวคิดนี้ว่า "Loop engineering" เมื่อ 7 มิ.ย. 2026 [1]
Cherny เปิดเผยตัวเลข: 30 วันต่อเนื่อง โค้ดทั้งหมดของ Claude Code ถูกเขียนโดย AI แบบอัตโนมัติ, 259 PR ที่ merge, กว่า 80% ของ production code ถูกเขียนโดย Claude, อัตราสำเร็จ 76% กับงาน open-ended
6 primitives ของ loop
Osmani แยก loop ออกเป็น 5 บล็อก + 1 ชั้นความจำที่ร้อยผ่านทั้งหมด:
1. Automations, หัวใจที่เต้น
ไม่มี automation, loop ก็ไม่ใช่ loop, มันคือการรันครั้งเดียวด้วยมือ ทั้ง Claude Code และ Codex มีระบบ schedule เต็มรูปแบบ (ใน session, บนเครื่อง, บน cloud, ตาม event)
2. Worktrees, แยกงานในสเกลใหญ่
พอรัน agent มากกว่า 1 ตัว ไฟล์ชนกันคือความล้มเหลวที่เลี่ยงไม่ได้ git worktree แก้ปัญหานี้: แต่ละ agent ทำงานบน branch ของตัวเองใน directory ของตัวเอง ชนกันไม่ได้ทางกายภาพ
3. Skills, หยุดอธิบายโปรเจกต์ซ้ำ
Skill คือโฟลเดอร์ที่มี SKILL.md + scripts + references, เขียน convention และ build step ครั้งเดียว อ่านทุกครั้งที่รัน
4. Connectors, ให้ loop แตะเครื่องมือจริง
สร้างบน MCP protocol, อ่าน issue tracker, query database, ยิง API, ส่งข้อความ Slack ได้
5. Sub-agents, แยก "คนทำ" กับ "คนตรวจ"
การแยกที่สำคัญที่สุด: โมเดลที่เขียนโค้ด มัน "ใจดีเกินไป" ในการให้คะแนนงานตัวเอง ต้องมี agent ตัวที่สอง, ต่าง instruction, บางทีต่างโมเดล, มาคอยจับจุดที่ตัวแรก "พูดตัวเองให้เชื่อ"
6. External State, ความจำของ loop
โมเดลลืมทุกอย่างระหว่างรัน ความจำต้องอยู่บน disk (markdown file, issue tracker) ไม่ใช่ใน context window
ตัวอย่างจริง: Karpathy's autoresearch
มีนาคม 2026 Karpathy ปล่อยโปรเจกต์ Python 630 บรรทัด ให้ GPU 1 ตัว + ทิศทางวิจัย แล้วมันรันทั้งคืน ทำ experiment ฝึกโมเดล ML เป็นร้อยๆ ตัว เก็บเฉพาะตัวที่ดีขึ้นจริง, 66,000+ ดาวในไม่กี่วัน [2]
หัวใจคือ 3 ไฟล์ แบ่งงานกันชัด: prepare.py (แก้ไม่ได้, fixed infrastructure), train.py (ให้ AI agent แก้ได้ทุกอย่าง), program.md (คุณเขียน methodology เป็นภาษาธรรมชาติ, แก้เฉพาะไฟล์นี้)
มนุษย์ไม่แตะโค้ด แต่แตะทิศทาง, agent ไม่แตะทิศทาง แต่แตะโค้ด, งานของคุณเปลี่ยนจากการเขียน Python เป็น "เขียนวัฒนธรรมองค์กรของการวิจัย"
มันเป็น "ratchet loop" 9 ขั้น: อ่านทิศทาง → สำรวจ → ตั้งสมมติฐาน → แก้โค้ด → snapshot → รัน 5 นาที → ประเมิน → เก็บหรือ revert → วนใหม่ รัน ~12 experiment/ชั่วโมง, ข้ามคืน 8 ชั่วโมง = ~100 experiment ผลจริง: 700 ความพยายาม เจอ improvement ที่ stack ได้จริง ~20 ตัว ลดเวลาฝึก nanochat ลง 11%
แล้วทำไม loop ถึงกลายเป็น graph
6 สัปดาห์หลัง loop engineering ดัง 18 ก.ค. 2026 Steinberger ทวีตว่า "ยังคุยเรื่อง loop อยู่หรือเปล่า หรือย้ายไป graph กันแล้ว?"
Hamel Husain ตีพิมพ์ "Loop Engineering Is Dead. Enter Graph Engineering", เนื้อหาทั้งบทความคือ GIF "Stop it" ตัวเดียว ทั้งคู่ "ล้อเล่น" แต่เรื่องตลกอยู่ได้แค่ weekend เดียว, คอร์ส, roadmap, tool stack ท่วม timeline ทันที
เรื่องตลกทำให้ไอเดียฮิต แต่มันไม่ได้สร้างไอเดีย, จริงๆ แล้ว Josh Simmons เขียนเรื่อง graph engineering จริงจังตั้งแต่วันที่ 4 ก.ค. 2 สัปดาห์ก่อนเรื่องตลก
ความต่างที่แท้จริง: loop กับ graph
ประโยคที่คมสุดมาจาก Luis Catacora (อ้างในคอร์ส Learn Harness Engineering) [3]:
"Loops มีพื้นที่ให้อภัยเยอะ Graph บังคับให้คุณยอมรับว่า workflow ของคุณส่วนใหญ่ยังไม่ได้ถูกจำลอง"
- Loop คือการตัดสินใจแบบเลื่อนออกไป, agent ตัวเดียวรับงานทั้งหมด ติดตรงไหนค่อยว่ากัน สถาปัตยกรรมเลื่อนได้ ราคาถูก แต่ failure mode มองไม่เห็น เพราะ agent เองไม่รู้ว่ามันติดตรงไหน
- Graph คือการตัดสินใจล่วงหน้า, ต้องประกาศโครงสร้างทั้งหมดไว้ก่อน ใครเป็นเจ้าของอะไร งานขึ้นต่อกันยังไง fail แล้วกลับไปตรงไหน งานมากกว่า แต่ได้ readability, auditability, และการซ่อมเฉพาะจุด
ตรงไปตรงมา: loop ซ่อนปัญหาไว้ใน loop, graph วางปัญหาลงบนกระดาษ, อันแรกเหมาะกับการสำรวจ, อันหลังเหมาะกับ production
graph ไม่ใช่ workflow (แค่เปลี่ยนชื่อ)
คนมีประสบการณ์ถามว่า "นี่มัน workflow ธรรมดาไม่ใช่เหรอ DAG, state machine, เราใช้กันมาเป็นสิบปีแล้ว"
สัญชาตญาณนี้ถูกครึ่งเดียว โครงกระดูกเหมือนกัน (nodes + edges + state + routing) แต่ครึ่งที่ผิดอยู่ใน nodes:
| Workflow node | Graph node | |
|---|---|---|
| คืออะไร | deterministic function | full agent |
| ตัวอย่าง | Python function, shell script | "research ปัญหานี้", "review โค้ดนี้" |
| edge | hardcoded (if, switch) |
dynamic routing (ตัดสินโดย output หรือโมเดล) |
graph คือ generalization ของ workflow, node ถูกขยายจาก "function" เป็น "agent", edge จาก "โค้ด static" เป็น "routing แบบไดนามิก"
3 ความล้มเหลวเชิงโครงสร้างของ loop เดี่ยว (ทำไมต้อง graph)
- Goodhart's Law, กด metric ตัวเดียวแรงพอ มันก็เลิกวัดสิ่งที่ควรวัด (bot ปิด ticket เก่ง จน churn พุ่ง 2 เท่า)
- ตาบอดขึ้นบน, loop ถามไม่ได้ว่า "เป้าหมายนี้ถูกต้องไหม" thermostat ถามไม่ได้ว่า 68°F คืออุณหภูมิที่ถูกไหม
- ความขัดแย้ง, loop หลายตัวไล่เป้าหมายที่ขัดกันเอง (loop เร่งความเร็ว บั่นทอน loop ความละเอียด)
Graph มีไว้ตอบคำถามที่ loop เดียวตอบไม่ได้: loop ไหน feed loop ไหน, loop ไหนเป็นเจ้าของเป้าหมาย, loop ไหน veto ได้, metric ไหนห้ามขยับ
ข้อควรระวัง: graph ไม่ใช่ยาวิเศษ
3 ถังน้ำเย็น:
- ตัวเลขปลอม, อ้างว่า "graph ให้ +18% accuracy, -85% cost" เป็นของปลอม (ตัวเลขจริงมาจาก paper ท่อเคมี ที่ baseline คนละตัว)
- รูปร่างไม่ใช่กำแพงรับน้ำหนัก, สิ่งที่อยู่รอดจริงคือ replayability, observability, recoverability ไม่ใช่ว่าต่อ node ยังไง
- Orchestration Tax, เริ่ม agent ถูก, ปิด loop ของ agent แพง เพราะ "คุณคือ GIL ของ agent ทั้งหมด", ความสนใจของคุณเป็น serial resource ที่ parallel ไม่ได้
สรุปมุมมองของผม
ผมมองว่านี่คือ "ยอดปิรามิด" ของ harness engineering: harness ทำให้รันครั้งเดียว reliable, loop ทำให้รันต่อเนื่องอัตโนมัติ, graph ทำให้หลาย loop ประสานกัน
แต่จุดสำคัญที่สุดไม่ใช่ชื่อ, loop หรือ graph ล้วนเป็น "ขั้น" ที่ทับกัน ไม่ใช่แทนที่กัน ทุก node ใน graph ยังมี prompt, context, และ loop ของตัวเองข้างใน
ถ้าคุณจะเริ่ม ขอแค่ 1 อย่าง: หางานที่คุณทำซ้ำอาทิตย์ละ 2 ครั้ง, เขียน goal + stopping condition, แยกคนทำกับคนตรวจ, เพิ่ม memory file, แล้วตั้ง timer, แล้วค่อยไต่บันไดขึ้นไป
คุณเคยลอง /goal, /loop หรือ autoresearch แล้วหรือยังครับ? แล้วงานไหนที่คุณอยากทำให้มัน "รันเอง" มากที่สุด? คอมเมนต์เล่าให้ฟังได้ครับ
แหล่งอ้างอิง
[1] Osmani. "Loop Engineering". 2026. https://addyosmani.com/blog/loop-engineering/
[2] Karpathy. "autoresearch". 2026. https://github.com/karpathy/autoresearch
[3] Learn Harness Engineering, Lecture 13-14. 2026. https://github.com/walkinglabs/learn-harness-engineering
บทความนี้วิเคราะห์จาก Addy Osmani, Karpathy และ walkinglabs/learn-harness-engineering ข้อมูล ณ 23 สิงหาคม 2026 Nokka
Top comments (0)