เลิกต่อ agent เป็นเส้นตรง — Graph Engineering กับ Claude

เพราะเราคิดเป็นลำดับ เราเขียนสิ่งที่อยากได้เป็นข้อ ๆ แล้วแปลงเป็นโค้ดตรง ๆ:

// วิธีที่เกือบทุกคนเริ่ม
const a = await agent("อ่าน schema ทั้งหมด")
const b = await agent("หา bug ฝั่ง backend")
const c = await agent("หา bug ฝั่ง frontend")
const d = await agent("หา bug เรื่อง security")
const e = await agent("สรุปทั้งหมด")

โค้ดนี้อ่านง่ายมาก และผิดโดยสิ้นเชิงในแง่เวลา — b, c, d ไม่ได้ใช้ผลของกันและกันเลย แต่ await ทำให้มันต่อคิว ถ้าแต่ละตัวใช้ 3 นาที คุณเสียไป 9 นาที ทั้งที่ควรใช้ 3

คนมักคิดว่า edge คือ “ลำดับ” แต่ไม่ใช่ — edge คือ การพึ่งพาข้อมูล ถ้า node B ไม่ได้ใช้อะไรจาก node A เลย แต่คุณเขียนให้มันรอ A นั่นคือ edge ปลอมที่คุณเผลอสร้างขึ้นมาเอง และมันคือต้นเหตุของเวลาที่หายไปเกือบทั้งหมด

นี่คือจุดที่ทำให้ graph engineering ต่างจาก “สั่ง AI ให้จัดการเอง”

โครงของกราฟ — จะแตกกี่แขนง วนกี่รอบ ถ้าเงื่อนไขนี้แล้วไปทางไหน — เขียนเป็น JavaScript ธรรมดา for, if, map, filter ส่วนโมเดลคิดแค่ “เนื้องานใน node นี้” ไม่ต้องคิดว่าต่อไปทำอะไร

ตัวอย่างโครงของ workflow หนึ่งตัว — ส่วนหัวบอกว่ามีกี่เฟส ส่วนล่างคือกราฟจริง:

export const meta = {
  name: 'audit-pos',
  description: 'หา bug ในระบบ POS แล้วยืนยันทีละข้อ',
  phases: [{ title: 'Find' }, { title: 'Verify' }],
}

phase('Find')
// ...กราฟเริ่มตรงนี้

ท่าพื้นฐานที่สุด: งานหนึ่งชิ้น แตกเป็น N ชิ้นที่ทำพร้อมกันได้

const DIMS = ['ราคา', 'สต็อก', 'สิทธิ์', 'offline']

const results = await parallel(
  DIMS.map(d => () => agent(`หา bug เรื่อง ${d} ในระบบ POS`))
)

ข้อควรรู้: มันไม่ได้ยิงพร้อมกันทั้งร้อยตัวจริง ๆ ระบบมีเพดาน concurrency (ราว 10–16 ตัวพร้อมกัน) ที่เหลือเข้าคิวรอช่องว่าง — คุณส่ง 100 ชิ้นได้ ทุกชิ้นเสร็จครบ แค่ไม่ได้วิ่งพร้อมกันหมด

ขากลับคือ N → 1: เอาผลทั้งหมดมารวมเป็นชิ้นเดียว จุดนี้เรียกว่า barrier (กำแพง) เพราะทุกสายต้องมาถึงก่อน ถึงจะผ่านไปได้

const all = results.filter(Boolean).flatMap(r => r.bugs)
const report = await agent(`สรุป bug ${all.length} ข้อนี้เป็นรายงานเดียว`)

เอา 03 + 04 มาต่อกันได้ทรงที่ใช้บ่อยที่สุดในงานจริง เรียกว่า diamond

ทรงนี้ถูกต้องเมื่อ “รวมผล” จำเป็นต้องเห็นผลของทั้งสามสายพร้อมกันจริง ๆ แต่ถ้ามันไม่จำเป็น เส้นประนั้นคือเวลาที่คุณทิ้งเปล่า — ซึ่งพาเราไปสู่หัวข้อสำคัญที่สุดของบทความ

สมมติงาน 5 ชิ้น แต่ละชิ้นต้องผ่าน 3 ขั้น ลองกดสลับดูว่าต่างกันแค่ไหน

ต่างกันตรงไหน

// pipeline — ค่าเริ่มต้นที่ควรใช้
const out = await pipeline(
  DIMS,
  d   => agent(`หา bug เรื่อง ${d}`, { schema: FINDINGS }),
  res => parallel(res.findings.map(f => () =>
            agent(`ยืนยันว่าจริงไหม: ${f.title}`, { schema: VERDICT })))
)
// bug ของ 'ราคา' เริ่มถูกยืนยัน ขณะที่ 'offline' ยังหาไม่เสร็จ

barrier ถูกต้องเมื่อไหร่

เมื่อขั้นถัดไปจำเป็นต้องเห็นผลของทุกชิ้นพร้อมกันเท่านั้น มีอยู่สามกรณีจริง ๆ:

1. ต้องตัดของซ้ำข้ามทุกชิ้นก่อน ไม่งั้นงานขั้นถัดไปจะทำซ้ำโดยเปล่าประโยชน์
2. ต้องเช็กยอดรวมเพื่อออกก่อนเวลา — เช่น “ถ้าไม่เจอ bug เลยสักข้อ ข้ามขั้นยืนยันทั้งหมด”
3. prompt ของขั้นถัดไปอ้างถึงผลของชิ้นอื่น เช่น “เทียบข้อนี้กับที่เหลือแล้วจัดอันดับ”

ไม่ต้องมีของวิเศษ ใช้ if ธรรมดา สิ่งที่ทำให้มันเป็น “routing” คือคุณตัดสินใจจาก ผลของ node ก่อนหน้า ไม่ใช่จากที่เดาไว้ล่วงหน้า

const triage = await agent('จัดหมวดปัญหานี้', { schema: TRIAGE })

if (triage.kind === 'security') {
  return await agent('ตรวจเชิงลึกด้านความปลอดภัย', { effort: 'high' })
}
if (triage.kind === 'typo') {
  return await agent('แก้คำผิด', { effort: 'low' })
}
return await agent('ตรวจแบบมาตรฐาน')

ประโยชน์จริงคือไม่จ่ายค่าเส้นทางที่ไม่ได้เดิน — งานง่ายไม่ต้องผ่านด่านตรวจ 5 ชั้น

agent ตัวเดียวที่พูดจาน่าเชื่อถือ ยังผิดได้ วิธีแก้ไม่ใช่ prompt ให้ดีขึ้น แต่คือเพิ่ม node ที่พยายามหักล้าง

const votes = await parallel(['ถูกต้อง', 'reproduce ได้', 'กระทบผู้ใช้จริง'].map(lens => () =>
  agent(`ลองหักล้างข้อนี้ในมุม ${lens}: ${claim} — ถ้าไม่แน่ใจให้ตอบว่าหักล้างได้`,
        { schema: VERDICT })
))
const real = votes.filter(Boolean).filter(v => !v.refuted).length >= 2

ไม่ใช่ทุก node ที่ต้องใช้ของแพง node กวาดข้อมูลกับ node ตัดสินใจ ควรคนละระดับ

agent('ลิสต์ไฟล์ที่แก้ใน branch นี้',  { effort: 'low' })
agent('ตัดสินว่า bug นี้จริงหรือไม่', { effort: 'high' })

ถ้าคุณกำลังหา bug แล้วบอกว่า “หาให้ครบ 10 ข้อ” คุณกำลังเดา — อาจมี 3 หรือ 40 ท่าที่ถูกคือวนจน ไม่เจอของใหม่ติดกัน K รอบ

const seen = new Set(), confirmed = []
let dry = 0

while (dry < 2) {
  const found = (await parallel(FINDERS.map(f => () => agent(f.prompt, { schema: BUGS }))))
    .filter(Boolean).flatMap(r => r.bugs)

  const fresh = found.filter(b => !seen.has(key(b)))   // ← ตัดกับ seen
  if (!fresh.length) { dry++; continue }

  dry = 0
  fresh.forEach(b => seen.add(key(b)))
  confirmed.push(...(await verifyAll(fresh)))
}

คุณไม่จำเป็นต้องรู้รูปร่างกราฟตั้งแต่ก่อนเริ่มงาน — รู้ก่อนตอนสั่งแตกแขนงก็พอ ท่าที่ใช้จริงคือ ลูกผสม: สำรวจก่อนด้วยตัวเอง แล้วค่อยเอาผลไปกางเป็นกราฟ

// 1) สำรวจเองก่อน — ยังไม่ต้องแตกแขนง
const files = await agent('ลิสต์ router ทั้งหมดในแอปนี้', { schema: FILES })

// 2) รูปร่างกราฟเพิ่งจะรู้ตรงนี้
const audits = await pipeline(
  files.paths,
  p => agent(`ตรวจ ${p}`, { schema: FINDINGS }),
  r => verifyAll(r.findings)
)

อีกท่าคือให้ขนาดของกราฟผูกกับงบที่มี:

while (budget.total && budget.remaining() > 50_000) {
  // เดินอีกรอบเท่าที่งบยังเหลือ
}

รวมทุกอย่างข้างบนเป็นกราฟเดียวที่ใช้งานได้จริง

export const meta = {
  name: 'audit-pos',
  description: 'หา bug ระบบ POS แยกตามมิติ แล้วยืนยันทีละข้อ',
  phases: [{ title: 'Find' }, { title: 'Verify' }],
}

const DIMS = [
  { key: 'money',   effort: 'high',   p: 'ตรวจการคำนวณเงิน ส่วนลด ภาษี การปัดเศษ' },
  { key: 'stock',   effort: 'medium', p: 'ตรวจการตัดสต็อก คลังรวม การขายแตกหน่วย' },
  { key: 'perm',    effort: 'high',   p: 'ตรวจสิทธิ์ role และการรั่วข้ามร้าน (org_id)' },
  { key: 'offline', effort: 'medium', p: 'ตรวจคิว offline การ sync ซ้ำ idempotency' },
]

const LENSES = ['ถูกต้องเชิงตรรกะ', 'สร้างซ้ำได้จริง', 'กระทบผู้ใช้จริง']

const out = await pipeline(
  DIMS,
  // ── ขั้น 1: หา (แต่ละมิติเริ่มพร้อมกัน)
  d => agent(d.p, { label: `find:${d.key}`, phase: 'Find',
                   effort: d.effort, schema: FINDINGS }),

  // ── ขั้น 2: ยืนยัน (เริ่มทันทีที่มิตินั้นเสร็จ ไม่รอมิติอื่น)
  (res, d) => parallel((res?.findings ?? []).map(f => () =>
    parallel(LENSES.map(lens => () =>
      agent(`ลองหักล้างในมุม ${lens}: ${f.title}\n${f.detail}`,
            { label: `verify:${d.key}`, phase: 'Verify',
              effort: 'high', schema: VERDICT })))
    .then(vs => ({
      ...f, dim: d.key,
      real: vs.filter(Boolean).filter(v => !v.refuted).length >= 2,
    }))))
)

const confirmed = out.flat().filter(Boolean).filter(f => f.real)
log(`ยืนยันแล้ว ${confirmed.length} ข้อ จากที่เจอทั้งหมด ${out.flat().length}`)
return { confirmed }

สังเกตว่ามิติ money ที่เจอ bug ก่อน จะเริ่มถูกยืนยันทันที ขณะที่ offline ยังหาไม่เสร็จด้วยซ้ำ — นั่นคือ pipeline ทำงาน

เช็กลิสต์ก่อนปล่อยกราฟลงสนาม

1. วาดกราฟก่อน แล้วค่อยเขียนโค้ด — ถ้าวาดไม่ออก แปลว่ายังไม่เข้าใจงาน
2. ทุก edge ตอบได้ว่า “ข้อมูลอะไรไหลผ่านเส้นนี้”
3. ลบ edge ที่ตอบไม่ได้ทิ้ง มันคือ edge ปลอม
4. เลือก pipeline เป็นค่าเริ่มต้น ใช้ barrier เมื่อพิสูจน์ได้ว่าจำเป็น
5. ทุก parallel() มี .filter(Boolean)
6. node ที่แตกแขนง ใช้ schema เพื่อให้ผลกลับมาเป็นข้อมูล ไม่ใช่ข้อความ
7. node ตัดสินใจสำคัญ ผ่านด่านตรวจอย่างน้อย 1 ชั้น
8. ผู้ตรวจถูกสั่งให้หักล้าง และไม่แน่ใจ = หักล้าง
9. ผู้ตรวจหลายตัว มองคนละมุม ไม่ใช่ถามซ้ำคำถามเดิม
10. ระดับ effort เหมาะกับความยากของแต่ละ node
11. ลูปมีเงื่อนไขจบที่ชัดเจน และตัดซ้ำกับ seen
12. ทุกจุดที่จำกัดขอบเขต มี log() กำกับ
13. รันซ้ำแล้วได้โครงเดิม (ไม่ใช้ Date.now()/Math.random() ในสคริปต์)
14. ขนาดกราฟสมกับงาน — “เช็กเร็ว ๆ” ไม่ต้องมี 40 node

1. Codez (@0xCodez). Graph Engineering with Claude: 14-Step roadmap from 0 to graph architect. X Article, 2026 — โพสต์ต้นทาง
   โครงหัวข้อ 14 ขั้นและคำว่า fan-out / barrier / diamond มาจากบทความนี้
2. Anthropic. Claude Code — Workflow & subagents — สเปกของ agent(), parallel(), pipeline(), phase(), log() ที่ใช้ในตัวอย่างทั้งหมด
3. Anthropic Engineering. Building effective agents — ที่มาของหลัก “เริ่มจากโครงที่ง่ายที่สุดที่ใช้ได้”
4. Anthropic Engineering. How we built our multi-agent research system — ที่มาของท่ากวาดหลายช่องทางแล้วสังเคราะห์