Loop vs Graph Engineering: How to Write an Article With Each (Step by Step)
โดย Nokka (นก-กา) | 16 สิงหาคม 2026
บทความนี้เขียนโดย AI (DeepSeek V4 Pro) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)
🇹🇭 ข้ามไปอ่านภาษาไทย · 🇬🇧 Read in English
English
Most writing about loop engineering and graph engineering assumes you are building a serious production system [1]. But most people are not. They have a simple job, a single AI, and a vague sense that "there must be a better way than just prompting it once."
This guide is for that person. It uses one concrete, relatable task, writing an article, and shows you step by step how to build it two ways: as a loop, and as a graph. By the end, you will know which one to reach for and why.
The example task: writing an article
Let us pick something almost everyone has tried: writing an article from a topic.
You have a topic, say "how to use loop engineering." You want the AI to turn that topic into a finished, publishable article. That means researching, outlining, drafting, editing, and checking. No database, no multi-agent team, no production infrastructure. Just one AI and one job: write a good article.
First, the two ideas in one sentence each
Loop engineering is about repeating a cycle until the evidence says you are done. You do a step, check the result, and if it is not good enough, you do it again with feedback. The shape is a circle.
Graph engineering is about drawing the exact path the work must follow [2]. You define the steps as nodes, and the arrows between them as the only allowed transitions. The shape is a map.
Both solve the same problem: getting an AI to do a multi-step job reliably. They just answer a different question. A loop asks "is it good enough yet?" A graph asks "what is allowed to happen next?"
Writing the article as a loop, step by step
A loop has four parts. Here is how you build each one for the article task, with the actual prompts you would use. (If you want the deeper theory first, the Harness vs Loop vs Graph piece covers the concepts.)
Step 1: Define the trigger
What starts the cycle? For us, it is simple: you hand the AI a topic. The trigger is "a topic exists."
In practice, this is your first prompt. You give the AI the topic and ask it to write a first draft:
"Write a 1,200-word article on 'how to use loop engineering.' Explain it in plain language for a beginner."
That is it. You do not over-engineer the first prompt, because the loop is going to fix whatever is wrong with the draft anyway. The first draft is just raw material.
Step 2: Define the goal
What does "done" look like? Not "write a good article," which is vague. A real goal is concrete and checkable. For our article, the goal is a five-point checklist:
- The intro states the point in the first two sentences.
- Every claim has a source or an example.
- The structure is clear (headings, short paragraphs).
- There are no typos or grammar errors.
- The length is under 1,500 words.
The key word is "checkable." Every item on this list is something you can look at and say yes or no. If your goal is "make it engaging," you cannot check that. If your goal is "the intro states the point," you can.
Step 3: Define the evidence
How do you know if the goal is met? You need a check that is not just the AI saying "I did it." The AI that wrote the draft is the worst judge of its own work, because it will always say it is fine.
For a simple task, the check is a second AI pass, with a different role. You ask a fresh AI (or the same AI with a fresh, neutral prompt) to act as an editor:
"You are an editor. Read this article and score it against this checklist: (1) intro states the point, (2) every claim has a source, (3) clear structure, (4) no typos, (5) under 1,500 words. Return PASS or FAIL. If FAIL, list exactly which items failed and why."
This is the heart of the loop. The check is separate from the writing, so it can be honest. The writer says "I did it." The editor says "no, item 2 failed, three claims have no source."
Step 4: Define the stop rule
When does the cycle end? "Stop when the check passes, or after three attempts, whichever comes first."
The three-attempt cap matters. Without it, a loop can spin forever: the writer fixes one thing, the editor finds another, the writer fixes that, the editor finds a third. The cap says: after three rounds, stop and hand it to a human. This is the difference between a loop that helps and a loop that burns tokens forever.
The full loop, in one picture
Here is the whole thing as a cycle:
Topic → Write draft → Editor checks → PASS → Done
↑ │
│ │ FAIL
│ ↓
└── Rewrite with feedback
Write, check, rewrite, check again, stop at pass or three tries. The shape is a circle, and the intelligence is in the check, not in the model.
Writing the article as a graph, step by step
A graph has nodes and edges. Here is the same task drawn as a graph. (LangGraph is the most common tool for this, but the concept works with any framework [3].)
Step 1: List the nodes
Each node is one step. For writing an article, the natural nodes are:
- Research (gather facts and sources)
- Outline (decide the structure)
- Draft (write the full text)
- Check (run the editor pass)
- Revise (fix what the check found)
- Finalize (hand it over)
Notice the difference from the loop already: the graph breaks the work into more, smaller steps. A loop treats "write" as one big step. A graph splits it into research, outline, and draft, because each is a distinct node with a distinct job.
Step 2: Draw the edges
Each edge is an allowed transition. The key difference from a loop is that you decide the exact path in advance. The work must flow in this order, and no other:
Research → Outline → Draft → Check → (if pass) → Finalize
↘ (if fail) → Revise → Check
The edges are the rules. "Draft" cannot go back to "Research." "Outline" cannot skip to "Check." The path is fixed, and that is the point: you are encoding the correct order of work into the structure itself, so the AI cannot do it in the wrong order.
Step 3: Add the branch condition
The edge out of "Check" is conditional: it goes to "Finalize" only if the check passes, and to "Revise" only if it fails. This is the router, and it is the heart of a graph.
A router is just a rule: "if the check says pass, go right; if it says fail, go left." It is the same editor check from the loop, but now it is a fixed point in a map instead of a point in a circle. The difference is that in a graph, the branch is explicit and visible, not implicit.
Step 4: Add a safety edge
To stop infinite loops, add a counter: after "Revise" runs three times, the edge goes to "Finalize" anyway, with a note that a human should review. This is failure containment.
This is the same three-attempt cap from the loop, but drawn as an edge. The graph makes the safety rule visible: there is a literal arrow that says "after three revisions, go to Finalize no matter what."
The full graph, in one picture
Research → Outline → Draft → Check ──(pass)──→ Finalize
│
└──(fail)──→ Revise ──→ Check
│
└──(3rd fail)──→ Finalize (human review)
Six nodes, a few edges, one conditional branch, one safety edge. The shape is a map, and the intelligence is in the edges, not in the nodes.
The comparison, side by side
| Loop | Graph | |
|---|---|---|
| Core question | "Is it good enough yet?" | "What is allowed next?" |
| Shape | A circle | A map |
| What you design | The check + the stop rule | The nodes + the edges |
| Where the intelligence lives | In the evidence/check | In the edges/branches |
| Best when | The task is "write until good" | The task has a fixed sequence |
| Hardest part | Writing a good check | Drawing the right edges |
Which one should you use?
For a simple task like writing an article, the honest answer is: start with a loop. Here is why.
A loop is easier to build because you only have to design one thing well: the check. If your check is good, the loop works. A graph asks you to design the whole map up front, which is more work and more places to get it wrong.
But there is a clear signal for when to switch to a graph: when the task has a fixed sequence that must not change. If your work is "research, then outline, then draft, always in that order, with a branch at the check step," that is a graph, and forcing it into a loop makes it messier, not simpler.
A useful rule of thumb: if you can describe the task as "write it, check it, fix it, repeat," use a loop. If you can describe it as "first research, then outline, then draft, and if the check fails then revise," use a graph.
The one thing both have in common
Here is the lesson that matters more than the loop-versus-graph choice: in both cases, the intelligence is not in the model. It is in the structure you build around it.
A loop works because the check is honest. A graph works because the edges are correct. The model is just the worker. The structure is the brain. If you remember nothing else, remember that: when a simple AI task keeps failing, the fix is almost never a better model. It is a better loop or a better graph.
ภาษาไทย
งานเขียนส่วนใหญ่เกี่ยวกับ loop engineering และ graph engineering มักสมมติว่าคุณกำลังสร้างระบบ production จริงจัง แต่คนส่วนใหญ่ไม่ได้เป็นแบบนั้น พวกเขามีงานง่ายๆ AI ตัวเดียว และความรู้สึกคลุมเครือว่า "น่าจะมีวิธีที่ดีกว่าการ prompt มันครั้งเดียว"
คู่มือนี้เขียนเพื่อคนคนนั้น มันใช้งานจริงที่ทุกคนคุ้นเคยหนึ่งงาน คือการเขียนบทความ และแสดงให้คุณเห็นทีละขั้นว่าสร้างมันสองแบบยังไง: แบบ loop และแบบ graph จบแล้วคุณจะรู้ว่าควรเลือกแบบไหนและทำไม
งานตัวอย่าง: การเขียนบทความ
เลือกงานที่เกือบทุกคนเคยลอง: เขียนบทความจากหัวข้อ
คุณมีหัวข้อ สมมติว่า "วิธีใช้ loop engineering" คุณอยากให้ AI เปลี่ยนหัวข้อนั้นเป็นบทความที่เสร็จและพร้อมเผยแพร่ นั่นแปลว่าต้องค้นข้อมูล, วางโครง, เขียน draft, แก้ไข และตรวจ ไม่มี database ไม่มีทีม multi-agent ไม่มี infrastructure production แค่ AI ตัวเดียวกับงานชิ้นเดียว: เขียนบทความดีๆ สักชิ้น
ก่อนอื่น สองแนวคิดในประโยคเดียว
Loop engineering คือการวนซ้ำจนกว่าหลักฐานจะบอกว่าเสร็จ คุณทำขั้นตอนหนึ่ง ตรวจผล และถ้ายังไม่ดีพอ คุณทำอีกครั้งพร้อม feedback รูปร่างคือวงกลม
Graph engineering คือการวาดเส้นทางที่งานต้องเดินให้ชัด [2] คุณกำหนดขั้นตอนเป็นโหนด และลูกศรระหว่างมันเป็น transition ที่อนุญาตเท่านั้น รูปร่างคือแผนที่
ทั้งสองแก้ปัญหาเดียวกัน: ทำให้ AI ทำงานหลายขั้นตอนได้อย่างน่าเชื่อถือ แต่มันตอบคำถามต่างกัน loop ถามว่า "ดีพอหรือยัง?" graph ถามว่า "อะไรได้รับอนุญาตให้ทำต่อ?"
เขียนบทความแบบ loop ทีละขั้น
loop มี 4 ส่วน นี่คือวิธีสร้างแต่ละส่วนสำหรับงานเขียนบทความ พร้อม prompt จริงที่คุณจะใช้ (ถ้าอยากอ่านทฤษฎีลึกก่อน ดู Harness vs Loop vs Graph)
ขั้นที่ 1: กำหนดตัวกระตุ้น
อะไรเริ่มวงจร? สำหรับเรา ง่ายๆ: คุณยื่นหัวข้อให้ AI ตัวกระตุ้นคือ "มีหัวข้อแล้ว"
ในทางปฏิบัติ นี่คือ prompt แรกของคุณ คุณให้หัวข้อ AI แล้วขอให้มันเขียน draft แรก:
"เขียนบทความ 1,200 คำเรื่อง 'วิธีใช้ loop engineering' อธิบายเป็นภาษาง่ายๆ สำหรับมือใหม่"
แค่นั้น คุณไม่ต้อง over-engineer prompt แรก เพราะ loop จะแก้จุดที่ draft ผิดอยู่แล้ว draft แรกเป็นแค่วัตถุดิบ
ขั้นที่ 2: กำหนดเป้าหมาย
"เสร็จ" หน้าตาเป็นยังไง? ไม่ใช่ "เขียนบทความดีๆ" ซึ่งคลุมเครือ เป้าหมายจริงต้องชัดเจนและตรวจได้ สำหรับบทความเรา เป้าหมายคือ checklist 5 ข้อ:
- บทนำบอกประเด็นใน 2 ประโยคแรก
- ทุกข้ออ้างมีแหล่งที่มาหรือตัวอย่าง
- โครงสร้างชัด (มีหัวข้อ, ย่อหน้าสั้น)
- ไม่มีพิมพ์ผิดหรือไวยากรณ์ผิด
- ความยาวไม่เกิน 1,500 คำ
คำสำคัญคือ "ตรวจได้" ทุกข้อในลิสต์คือข้อที่คุณดูแล้วตอบได้ว่าใช่หรือไม่ใช่ ถ้าเป้าหมายคุณคือ "ทำให้น่าอ่าน" คุณตรวจไม่ได้ แต่ถ้าเป้าหมายคือ "บทนำบอกประเด็น" คุณตรวจได้
ขั้นที่ 3: กำหนดหลักฐาน
คุณรู้ได้ยังไงว่าเป้าหมายถึงแล้ว? คุณต้องมีตัวตรวจที่ไม่ได้มีเพียง AI บอกว่า "ฉันทำแล้ว" AI ที่เขียน draft คือผู้ตัดสินงานตัวเองที่แย่ที่สุด เพราะมันจะบอกว่างานดีเสมอ
สำหรับงานง่ายๆ ตัวตรวจคือ AI รอบที่สอง ที่มีบทบาทต่างออกไป คุณขอ AI ตัวใหม่ (หรือ AI ตัวเดิมด้วย prompt ใหม่ที่เป็นกลาง) ให้ทำตัวเป็นบรรณาธิการ:
"คุณคือบรรณาธิการ อ่านบทความนี้แล้วให้คะแนนเทียบ checklist นี้: (1) บทนำบอกประเด็น, (2) ทุกข้ออ้างมีแหล่งที่มา, (3) โครงสร้างชัด, (4) ไม่มีพิมพ์ผิด, (5) ไม่เกิน 1,500 คำ คืนค่า PASS หรือ FAIL ถ้า FAIL ให้ลิสต์ว่าข้อไหนไม่ผ่านและเพราะอะไร"
นี่คือหัวใจของ loop ตัวตรวจแยกจากตัวเขียน เพื่อให้มันซื่อสัตย์ได้ ตัวเขียนบอกว่า "ฉันทำแล้ว" ตัวตรวจบอกว่า "ไม่ ข้อ 2 ไม่ผ่าน มี 3 ข้ออ้างที่ไม่มีแหล่งที่มา"
ขั้นที่ 4: กำหนดกฎการหยุด
วงจรจบเมื่อไหร่? "หยุดเมื่อตรวจผ่าน หรือหลังพยายาม 3 ครั้ง แล้วแต่อะไรถึงก่อน"
วงเงิน 3 ครั้งสำคัญ ถ้าไม่มี loop จะวนไม่จบ: ตัวเขียนแก้จุดหนึ่ง ตัวตรวจเจออีกจุด ตัวเขียนแก้จุดนั้น ตัวตรวจเจอจุดที่สาม วงเงินบอกว่า: หลัง 3 รอบ หยุดแล้วส่งให้มนุษย์ นี่คือความต่างระหว่าง loop ที่ช่วย กับ loop ที่เผา token ไม่จบ
loop ทั้งหมดในภาพเดียว
นี่คือทั้งหมดในรูปวงจร:
หัวข้อ → เขียน draft → บรรณาธิการตรวจ → PASS → เสร็จ
↑ │
│ │ FAIL
│ ↓
└── เขียนใหม่พร้อม feedback
เขียน, ตรวจ, เขียนใหม่, ตรวจอีก หยุดที่ pass หรือ 3 ครั้ง รูปร่างคือวงกลม และความฉลาดอยู่ที่ตัวตรวจ ไม่ใช่ที่โมเดล
เขียนบทความแบบ graph ทีละขั้น
graph มีโหนดและเส้นเชื่อม นี่คืองานเดียวกันวาดเป็น graph (LangGraph คือเครื่องมือที่ใช้บ่อยสุด แต่แนวคิดใช้ได้กับ framework ไหนก็ได้ [3])
ขั้นที่ 1: ลิสต์โหนด
แต่ละโหนดคือหนึ่งขั้น สำหรับการเขียนบทความ โหนดตามธรรมชาติคือ:
- ค้นข้อมูล (รวบรวมข้อเท็จจริงและแหล่งที่มา)
- วางโครง (ตัดสินโครงสร้าง)
- เขียน draft (เขียนเนื้อหาเต็ม)
- ตรวจ (รันตัวตรวจบรรณาธิการ)
- แก้ไข (แก้จุดที่ตัวตรวจเจอ)
- สรุปจบ (ส่งมอบงาน)
สังเกตความต่างจาก loop ตรงนี้แล้ว: graph แบ่งงานเป็นขั้นที่เล็กกว่าและมากกว่า loop มอง "เขียน" เป็นขั้นใหญ่ขั้นเดียว graph แยกเป็นค้นข้อมูล, วางโครง และเขียน draft เพราะแต่ละอันคือโหนดที่ต่างกัน มีงานที่ต่างกัน
ขั้นที่ 2: วาดเส้นเชื่อม
แต่ละเส้นคือ transition ที่อนุญาต ความต่างสำคัญจาก loop คือคุณตัดสินเส้นทางล่วงหน้า งานต้องไหลตามลำดับนี้เท่านั้น ไม่มีทางอื่น:
ค้นข้อมูล → วางโครง → เขียน draft → ตรวจ → (ถ้าผ่าน) → สรุปจบ
↘ (ถ้าไม่ผ่าน) → แก้ไข → ตรวจ
เส้นเชื่อมคือกฎ "เขียน draft" กลับไป "ค้นข้อมูล" ไม่ได้ "วางโครง" ข้ามไป "ตรวจ" ไม่ได้ เส้นทางถูกตรึง และนั่นคือประเด็น: คุณฝังลำดับงานที่ถูกต้องลงในโครงสร้างเอง เพื่อให้ AI ทำผิดลำดับไม่ได้
ขั้นที่ 3: เพิ่มเงื่อนไขแยกสาขา
เส้นที่ออกจาก "ตรวจ" เป็นแบบมีเงื่อนไข: ไป "สรุปจบ" เฉพาะเมื่อผ่าน และไป "แก้ไข" เฉพาะเมื่อไม่ผ่าน นี่คือ router และมันคือหัวใจของ graph
router ก็แค่กฎ: "ถ้าตรวจบอกว่าผ่าน ไปขวา ถ้าบอกว่าไม่ผ่าน ไปซ้าย" มันคือตัวตรวจบรรณาธิการตัวเดียวกับใน loop แต่ตอนนี้มันเป็นจุดตรึงในแผนที่ แทนที่จะเป็นจุดในวงกลม ความต่างคือใน graph การแยกสาขาชัดเจนและมองเห็นได้ ไม่ใช่โดยนัย
ขั้นที่ 4: เพิ่มเส้นปลอดภัย
เพื่อหยุดการวนไม่จบ เพิ่มตัวนับ: หลัง "แก้ไข" ทำงาน 3 ครั้ง เส้นจะไป "สรุปจบ" อยู่ดี พร้อมโน้ตว่าควรให้มนุษย์ตรวจ นี่คือ failure containment
นี่คือวงเงิน 3 ครั้งตัวเดียวกับใน loop แต่วาดเป็นเส้น graph ทำให้กฎปลอดภัยมองเห็นได้: มีลูกศรจริงๆ ที่บอกว่า "หลังแก้ไข 3 ครั้ง ไปสรุปจบไม่ว่าอะไรจะเกิดขึ้น"
graph ทั้งหมดในภาพเดียว
ค้นข้อมูล → วางโครง → เขียน draft → ตรวจ ──(ผ่าน)──→ สรุปจบ
│
└──(ไม่ผ่าน)──→ แก้ไข ──→ ตรวจ
│
└──(ไม่ผ่านครั้งที่ 3)──→ สรุปจบ (ให้มนุษย์ตรวจ)
6 โหนด ไม่กี่เส้น หนึ่งเงื่อนไขแยกสาขา หนึ่งเส้นปลอดภัย รูปร่างคือแผนที่ และความฉลาดอยู่ที่เส้นเชื่อม ไม่ใช่ที่โหนด
เปรียบเทียบเคียงข้าง
| Loop | Graph | |
|---|---|---|
| คำถามหลัก | "ดีพอหรือยัง?" | "อะไรทำต่อได้?" |
| รูปร่าง | วงกลม | แผนที่ |
| ส่วนที่คุณออกแบบ | ตัวตรวจ + กฎหยุด | โหนด + เส้นเชื่อม |
| ความฉลาดอยู่ที่ | หลักฐาน/ตัวตรวจ | เส้นเชื่อม/การแยกสาขา |
| เหมาะเมื่อ | งานคือ "เขียนจนดี" | งานมีลำดับตายตัว |
| ส่วนที่ยากสุด | เขียนตัวตรวจให้ดี | วาดเส้นเชื่อมให้ถูก |
ควรเลือกแบบไหน?
สำหรับงานง่ายๆ อย่างการเขียนบทความ คำตอบตรงๆ คือ: เริ่มจาก loop นี่คือเหตุผล
loop สร้างง่ายกว่า เพราะคุณต้องออกแบบให้ดีแค่สิ่งเดียว: ตัวตรวจ ถ้าตัวตรวจดี loop ก็ทำงาน graph ขอให้คุณออกแบบแผนที่ทั้งหมดล่วงหน้า ซึ่งงานมากกว่าและจุดที่พลาดได้ก็มากกว่า
แต่มีสัญญาณชัดว่าเมื่อไหร่ควรเปลี่ยนไปใช้ graph: เมื่องานมีลำดับตายตัวที่ห้ามเปลี่ยน ถ้างานคุณคือ "ค้นข้อมูล แล้ววางโครง แล้วเขียน draft ตามลำดับเสมอ โดยมีแยกสาขาที่ขั้นตรวจ" นั่นคือ graph และการยัดมันเข้า loop จะทำให้ยุ่งขึ้น ไม่ใช่เรียบขึ้น
กฎง่ายๆ ที่ใช้ได้: ถ้าคุณอธิบายงานได้ว่า "เขียน, ตรวจ, แก้, ทำซ้ำ" ใช้ loop ถ้าคุณอธิบายได้ว่า "ค้นข้อมูลก่อน แล้ววางโครง แล้วเขียน draft และถ้าตรวจไม่ผ่านก็แก้ไข" ใช้ graph
สิ่งเดียวที่ทั้งสองมีร่วมกัน
นี่คือบทเรียนที่สำคัญกว่าการเลือก loop หรือ graph: ทั้งสองกรณี ความฉลาดไม่ได้อยู่ในโมเดล แต่มันอยู่ในโครงสร้างที่คุณสร้างรอบมัน
loop ทำงานเพราะตัวตรวจซื่อสัตย์ graph ทำงานเพราะเส้นเชื่อมถูกต้อง โมเดลเป็นแค่คนงาน โครงสร้างคือสมอง ถ้าคุณจำอะไรได้แค่อย่างเดียว จำสิ่งนี้: เมื่องาน AI ง่ายๆ ล้มเหลวซ้ำๆ ทางแก้แทบไม่เคยเป็นโมเดลที่ดีกว่า แต่มันคือ loop หรือ graph ที่ดีกว่า
References
[1] Nokka. "The Intelligence Isn't in the AI Agents, It's in the Arrows Between Them". dev.to. https://dev.to/sarantoon/the-intelligence-isnt-in-the-ai-agents-its-in-the-arrows-between-them-21h4
[2] Codez (@0xCodez). "Graph Engineering with Claude: 14-Step roadmap from 0 to graph architect". X. https://x.com/0xCodez/status/2079165300625330317
[3] LangChain. "LangGraph: Low-level orchestration framework for stateful, long-running agents". https://langchain-ai.github.io/langgraph/
บทความนี้เป็นคู่มือ how-to ที่อธิบาย loop และ graph engineering ด้วยตัวอย่างงานเขียนบทความ อ้างอิงจากบทความก่อนหน้าของ Nokka, ต้นฉบับของ Codez และ LangGraph ข้อมูล ณ 16 สิงหาคม 2026 Nokka
ผมเขียนคู่มือนี้เพราะสังเกตว่าเนื้อหาเรื่อง loop และ graph engineering ส่วนใหญ่เขียนให้คนที่สร้างระบบ production ซึ่งทำให้คนที่แค่อยากทำงานง่ายๆ รู้สึกว่ามันไกลตัวเกินไป แต่ความจริงแล้ว แนวคิดทั้งสองใช้ได้กับงานที่ทุกคนคุ้นเคยอย่าง "เขียนบทความ" ได้ทันที และนั่นคือจุดที่ควรเริ่ม
ถ้าคุณลองเอา loop หรือ graph ไปใช้กับงานเขียนของตัวเองแล้ว บอกผมในคอมเมนต์ได้ว่าอันไหนเหมาะกับงานคุณมากกว่ากันครับ
Top comments (0)