Raw LLM, Workflow, Agent: เลือกระดับของระบบ AI ให้พอดีกับงาน

ปีที่ผ่านมา คำว่า “agent” ถูกใช้จนความหมายเลือน — chatbot ก็เรียก agent · เครื่องมือที่เรียก API ตัวเดียวก็เรียก agent · workflow ที่มีหลาย step ก็เรียก agent

นี่ไม่ใช่แค่ปัญหาเรื่องคำ ปัญหาจริงคือเมื่อทีมเริ่มออกแบบระบบใหม่โดยตั้งต้นจากคำว่า “agent” มักลงเอยด้วยระบบที่ overkill — แพง ช้า คาดเดาผลไม่ได้ — ทั้งที่ workflow ธรรมดาตอบโจทย์ได้

คำถามที่ใช่กว่าคือ — ระบบที่ใช้ LLM มีกี่ระดับ · ต่างกันที่อะไร · เราควรเลือกระดับไหน

บทความนี้คือกรอบหนึ่ง สังเคราะห์จากเอกสาร Building Effective Agents ของ Anthropic, A Practical Guide to Building Agents ของ OpenAI, Building LLM Applications for Production ของ Chip Huyen และจากระบบ customer service ที่ทีม Round กำลังสร้างอยู่

สเปกตรัมสี่ระดับ

ทุกระบบที่ใช้ LLM จัดอยู่ในหนึ่งในสี่ระดับนี้ ต่างกันที่ “ใครเป็นคนตัดสินใจว่าจะทำอะไรต่อ”

ระดับ 0 · Raw LLM call — ส่ง prompt เข้า รับ output ออก

เหมาะกับงาน creative ครั้งเดียว · การวิเคราะห์ ad-hoc · การ prototype จุดอ่อนคือไม่มีความจำ ไม่ connect กับระบบอื่น ผลคาดเดายาก — เหมาะกับ “งานชิ้นเดียว” ไม่ใช่ “ระบบ”

ระดับ 1 · Augmented LLM — LLM + tools (เครื่องมือ) + memory (ความจำ) + retrieval (ค้นข้อมูลจาก knowledge base)

LLM ตัวเดียวที่ค้นข้อมูลในฐานความรู้ได้ · เรียก function ได้ · จำ context ได้ Anthropic นิยามระดับนี้เป็น building block พื้นฐานของทุกระบบที่ซับซ้อนกว่านี้ เหมาะกับ chatbot ที่ตอบจาก knowledge base, search assistant แบบ Perplexity

ระดับ 2 · Workflow — LLM อยู่ใน code path ที่คนเขียนไว้

Anthropic นิยามว่า “systems where LLMs and tools are orchestrated through predefined code paths” คนเขียน flow · LLM ทำงานเฉพาะจุดที่กำหนด เช่น classify, generate, summarize, validate นี่คือระดับที่ใช้มากที่สุดในระบบ production จริง แต่มักถูกเรียกผิดว่า agent

ระดับ 3 · Agent — LLM ตัดสินใจ flow เอง

Anthropic นิยามว่า “systems where LLMs dynamically direct their own processes and tool usage” LLM เลือกเองว่าจะใช้ tool ไหน · ทำขั้นตอนไหนก่อน · เมื่อไหร่จะหยุด เหมาะกับงานที่ step ล่วงหน้า predict ไม่ได้จริง ๆ เช่น coding agent, research agent

เส้นแบ่งระหว่างระดับ 2 กับ 3 คือ “ใครตัดสิน flow” — คน (workflow) หรือ LLM (agent) นี่คือเส้นแบ่งสำคัญที่สุดในการออกแบบ และเป็นเส้นที่ marketing มักไม่ขีดให้ชัด เพราะ “agent” ขายได้ง่ายกว่า

กฎข้อแรก: เริ่มจากระดับเล็กสุดเสมอ

Anthropic เขียนใน Building Effective Agents ไว้ว่า:

“consider adding complexity only when it demonstrably improves outcomes”

เพิ่มความซับซ้อนเฉพาะตอนที่มัน พิสูจน์ได้ว่าทำให้ผลลัพธ์ดีขึ้น — และในกรณีของ agent ต้นทุนที่ต้องจ่ายจับต้องได้ทันที

• ค่าเรียก LLM สูงกว่ามาก — task หนึ่งอาจเรียก LLM 10-50 ครั้ง เทียบกับ workflow ที่เรียก 1-3 ครั้ง
• latency สูง — รอ LLM คิดหลาย step ต่อเนื่อง
• errors compound (ข้อผิดพลาดสะสม) — พลาด 1 step ทำให้ทั้ง chain พัง
• คาดเดาผลไม่ได้ — run เดิมสองครั้งอาจได้ผลคนละแบบ

ในงาน production จริง แทบทุกระบบที่ทำงานได้ดีในระยะยาวมี workflow เป็นโครงหลัก · agent มีที่ใช้จริง แต่สัดส่วนของ agent แท้ ๆ เล็กกว่าที่หลายคนคิด — ตัวอย่างที่ agent ชนะจริงดูในส่วนถัดไป

วิธีปฏิบัติ — เริ่มจาก raw LLM ก่อน · ถ้าไม่พอเพิ่ม retrieval · ยังไม่พอใส่ลงใน workflow · เฉพาะ flow ที่ predict ไม่ได้จริง ๆ ค่อยใช้ agent ห้ามทำกลับด้าน เพราะถ้าเริ่มจาก agent แล้วใช้ได้พอประมาณ คนจะไม่กลับมา simplify ระบบ overkill จะถูกถือว่า “ก็ทำงานได้นี่” ไปตลอด

เมื่อ agent ชนะ workflow

มีงานบางประเภทที่ workflow ตอบไม่ได้ — และ agent ชนะอย่างชัดเจน

Coding agent — เช่น Claude Code, Cursor Composer · “ไฟล์ไหนต้องแก้” ขึ้นกับโจทย์เฉพาะหน้า · workflow ที่กำหนด step ไว้แน่นอนทำได้แค่ task ซ้ำซาก ส่วนปัญหา code จริงต้องการ flexibility ที่ตัดสินใจ ณ จุดนั้น

Research agent — เช่น Perplexity Deep Research, OpenAI Deep Research · เส้นทาง research ขึ้นกับสิ่งที่พบระหว่างทาง · ไม่สามารถ predict step ทั้งหมดตั้งแต่ต้นได้

Dynamic problem-solving — งานที่ต้องลองหลาย approach, verify ผลก่อนตัดสินใจ step ต่อไป เช่น debugging task ที่ซับซ้อน

จุดร่วมของทั้งสามคือ “flow ขึ้นกับสิ่งที่ค้นพบระหว่างทาง” ไม่ใช่ “flow predict ได้ตั้งแต่ต้น”

ที่สำคัญ — ระบบจริงในตลาดส่วนใหญ่เป็น hybrid ไม่ใช่ pure workflow หรือ pure agent · เช่น Cursor มี autocomplete (workflow) + Composer (agent) · Perplexity มี standard search (workflow) + Deep Research (agent) · ระบบ customer service หลายตัวมี routing (workflow) + agent escalation เฉพาะ case ซับซ้อน

การเลือก “workflow หรือ agent” ในทางปฏิบัติคือเลือกที่ระดับ subtask ไม่ใช่ระดับ ระบบทั้งหมด

ห้ารูปแบบของ workflow

ระดับ workflow ไม่ใช่ “ระบบเดียว” แต่มี pattern ย่อยที่ Anthropic จัดไว้ห้าแบบ ระบบ production ส่วนใหญ่ลงในหนึ่งหรือหลายรูปแบบนี้ผสมกัน

1 · Prompt chaining — แบ่งงานเป็นขั้นต่อเนื่อง output ของขั้นก่อนเป็น input ของขั้นต่อไป ใช้เมื่องานแตกเป็น subtask ชัดเจน เช่น generate outline → expand each section → review

2 · Routing — classify input ก่อน แล้วส่งไปยัง handler เฉพาะทาง ใช้เมื่อ input มีหลายประเภทที่ต้องการ prompt หรือ model ต่างกัน เช่น refund query, complaint, order

3 · Parallelization — รัน LLM หลายตัวพร้อมกัน รวมผลที่ปลาย แยกเป็น sectioning (แบ่งงานเป็นชิ้น) และ voting (หลาย LLM ตอบคำถามเดียวกัน เอา majority หรือ average)

4 · Orchestrator-workers — central LLM แตกงานเป็นชิ้น delegate ให้ worker แล้วรวมผลเอง ใช้เมื่อ subtask predict ล่วงหน้าไม่ได้ เป็น hybrid ระหว่าง workflow กับ agent

5 · Evaluator-optimizer — LLM ตัวหนึ่ง generate · อีกตัว evaluate · loop จนผ่านเกณฑ์ ใช้เมื่อมี criteria ชัด และ iterative refinement ให้ผลลัพธ์ดีจริง เช่น translation, code review, code generation

รูปแบบ 1-3 ครอบคลุม production system ส่วนใหญ่ · รูปแบบ 4-5 ใกล้ agent มากขึ้น แต่ยังมี code path กลางที่คนคุมอยู่

Case: ระบบที่ดูเหมือน agent แต่เป็น workflow

เพื่อไม่ให้เป็นทฤษฎีลอย — ลองดู pattern จากระบบ customer service ที่ทีมเรากำลังพัฒนาอยู่ตัวหนึ่ง ตอบลูกค้าใน LINE และ Telegram โดยใช้ LLM

ผิวเผินมันคือ “AI agent ตอบลูกค้า” แต่จริง ๆ ทุกข้อความที่เข้าระบบต้องผ่าน 10 gates ที่กำหนดไว้แน่นอน ก่อน ที่ LLM จะถูกเรียก

ตรวจ noise → ระบุ thread → ระบุตัวตน → ตรวจ clarity → ตรวจ idle → match mandate → check constraints → vet blast radius → ack strategy → dispatch

LLM ทำงานที่ จุดเดียว ในกลาง pipeline — generate reply ภายใต้ constraints ที่ pipeline กำหนดให้ LLM ไม่ได้ เลือกว่าจะ escalate หรือไม่ · ไม่ได้ เลือก workflow · ไม่ได้ เลือก tool

นี่คือ workflow รูปแบบ routing + chaining ที่บริสุทธิ์ ไม่ใช่ agent ตามนิยามของ Anthropic

ทำไมต้องออกแบบแบบนี้ — เพราะ customer service มี constraint ที่ agent ตอบไม่ได้

• ทุก reply ต้อง audit ได้ (compliance)
• ทุก action ต้อง bounded (ห้าม AI ตัดสินใจ refund เอง)
• ทุก decision ต้อง replay ได้ (debug เมื่อลูกค้าร้องเรียน)

ในระบบ agent ที่ LLM ตัดสินใจ flow เอง คำถาม “ทำไม AI ทำแบบนี้” ตอบยากมาก เพราะ path เกิดจาก reasoning ของ LLM ที่ผลไม่คงที่

บทเรียนใหญ่ — เวลาเห็น “AI agent ที่ลูกค้าใช้งานอยู่จริง” ในตลาด หลังบ้านมักเป็น workflow ที่ออกแบบดี + อาจมี agent loop แทรกเฉพาะจุด · คำว่า “agent” ในความหมาย marketing กว้างกว่า “agent” ในความหมาย architecture มาก

มุมมองของ model maker

vendor LLM แต่ละค่ายมีจุดยืนต่างกันชัด และต้องเข้าใจ incentive ก่อนฟังคำแนะนำ — เพราะคนสร้างโมเดลก็คือคน ขาย การเรียก LLM ให้เรา

Anthropic เน้น “เริ่มเล็กสุดเสมอ” ใน Building Effective Agents ระบุชัดว่า workflow เพียงพอสำหรับงานส่วนใหญ่ · agent ควรใช้เฉพาะตอน flexibility จำเป็นจริง — เป็น vendor LLM ที่หาได้น้อยที่ออกมาบอกว่า “อย่าใช้ของฉันถ้าไม่จำเป็น”

OpenAI เน้น tool calling และ multi-agent ใน Practical Guide to Building Agents เน้น “เมื่อไหร่ควรสร้าง agent” มากกว่า “เมื่อไหร่ไม่ควร” เสนอ pattern อย่าง manager pattern (agent หลักสั่ง sub-agent) และ decentralized handoff (agent ส่งต่อกันเอง) — assume ตั้งแต่ต้นว่าระบบจะเป็น agent

ทั้งสองค่ายเห็นตรงกันเรื่อง guardrails (กรอบความปลอดภัย), observability (การตรวจสอบสิ่งที่ระบบทำ), และ human-in-the-loop (คนตรวจกลางทาง) ที่จุดเสี่ยง · แต่ต่างกันที่ “default starting point”

อีกมุมที่ควรอ่านคือบทความของ Chip Huyen ผู้เขียน AI Engineering — เธอกล่าวประโยคที่ฝังใจคนทำ production:

“It’s easy to make something cool with LLMs, but very hard to make something production-ready with them”

ระยะห่างระหว่าง demo ที่ดูดี กับระบบที่ใช้งานได้ในระยะยาว คือระยะของ engineering discipline — ส่วนใหญ่คือการเลือกใช้ระดับให้ เล็กกว่า ที่ใจอยากใช้

คำถามสี่ข้อก่อนเลือกระดับ

ก่อนเลือกระดับสำหรับงานของตัวเอง ตอบสี่คำถามนี้

1. flow predict ได้ไหม? ถ้าตอบ ใช่ → workflow · ถ้าตอบ ไม่จริง ๆ → ค่อยพิจารณา agent · “predict ไม่ได้จริง ๆ” คือเส้นทางขึ้นกับสิ่งที่พบระหว่างทาง ไม่ใช่แค่ “มีหลาย case”

2. cost และ latency รับได้แค่ไหน? agent มักช้ากว่า 5-10 เท่า และแพงกว่า 10-100 เท่าต่อ task เทียบกับ workflow · ถ้า requirement คือ “ตอบใน 2 วินาที ราคาต่อข้อความต่ำกว่าบาท” agent ตกเกณฑ์ทันที

3. errors ที่ compound มี cost เท่าไหร่? ถ้าพลาดที่ step หนึ่งแล้ว step ถัดไปทำต่อบน pattern ที่พลาด — cost เท่าไหร่ ถ้าตอบ “สูง — เงินลูกค้า, ชื่อเสียงบริษัท, ความปลอดภัย” workflow ปลอดภัยกว่า

4. audit ได้ไหม? สำหรับงาน regulated (financial, healthcare, customer service) — ต้อง trace ได้ว่า “ทำไม AI ทำอย่างนี้” · agent ที่ตัดสินใจเอง trace ยากกว่า workflow มาก

ถ้าตอบทั้งสี่ข้อแล้วยังเลือก agent — มีเหตุผลพอ · ถ้ายังตอบไม่ครบ — กลับไปที่ workflow ก่อน

บทสรุป

ในยุคที่ทุกคนพูดเรื่อง agent ความรู้สึกที่ฝังในใจคนเริ่มสร้างระบบใหม่ มักเป็น “ถ้าไม่ใช้ agent คือล้าหลัง” — แต่ความจริงคือ production system ส่วนใหญ่ในตลาดเป็น hybrid ที่มี workflow เป็นโครงหลัก แล้วมี agent loop แทรกเฉพาะ subtask ที่ต้องการ flexibility · agent มีที่ของมัน แต่ที่ของมัน เฉพาะเจาะจง กว่าที่ marketing บอก

เป้าหมายของระบบ AI ที่ดีไม่ใช่ “ใช้ AI ให้มากที่สุด” หรือ “ใช้ AI ให้ฉลาดที่สุด” แต่คือ “ใช้ AI ในระดับที่พอดีกับงาน ไม่มากไป ไม่น้อยไป”

ก่อนเริ่มเขียน code ของระบบใหม่ ลองถามทีม — เราต้องการระดับไหนจริง ๆ คำตอบมักจะเล็กกว่าที่คิด

และเมื่อตัดสินใจระดับได้แล้ว กลับไปที่คำถามใหญ่ของ Open Loop, Closed Loop — ระดับนี้ทำให้ loop ของงาน ปิดได้ หรือเปล่า

ขอบเขตของบทความนี้

บทความนี้ตอบแค่คำถาม “เลือกระดับของระบบไหน” — แต่การออกแบบระบบที่ใช้ LLM ในงานจริงยังต้องตัดสินใจอีกสองแกนสำคัญที่เป็นอิสระจากกัน:

• Local LLM vs Cloud LLM — ต้นทุน GPU vs ค่า token, latency, vendor lock-in, fine-tuning
• Data security — PII handling, data residency, prompt injection, audit trail สำหรับ regulated industry

ทั้งสองเรื่องจะเขียนเป็นบทความแยก เพราะแต่ละแกนตัดสินใจอิสระจากกัน

แหล่งอ้างอิงหลัก: Building Effective Agents · Anthropic · A Practical Guide to Building Agents · OpenAI (PDF) · Building LLM Applications for Production · Chip Huyen · Workflows and Agents · LangChain Docs