Workflow ต่างกับ Agent

บทที่แล้วเราเปิดกล่อง runtime ออกมาดูข้างใน — harness สี่ชิ้น, loop แบบ gather → act → verify → repeat และ stop policy ที่เป็นนโยบายประกอบ5 clause ก่อนจะลงมือสร้าง runtime ตัวนั้นทีละชิ้นในบทหลังๆ มีคำถามหนึ่งข้อที่ต้องตอบให้จบ ก่อน เอื้อมมือไปหา harness ด้วยซ้ำ — สิ่งที่คุณกำลังจะสร้างควรเป็น agent จริงๆ หรือควรเป็นแค่ workflow ธรรมดา บทนี้เป็นบทวางจุดยืน (thesis) ของทั้งคอร์ส code น้อย แต่เส้นแบ่งที่ลากในบทนี้จะกำกับทุกบทที่เหลือ

📦 code ตัวอย่าง

บทนี้ยังต่อยอด agent Order ตัวเดิมจากคอร์ส #15 (พร้อม context layer จากคอร์ส #16) — repo kaen-food-ordering (กำลังจัดทำ) code ในบทนี้แสดง สองรูปทรง ของ Order flow เดียวกัน — แบบ workflow ที่เราคุมลำดับเอง กับแบบ agent ที่ model คุมลำดับเอง — เพื่อให้เห็นเส้นแบ่งด้วยตา ไม่มี API surface ใหม่ ทุกกติกาฝั่งแชตจากบทที่ 1 ยังยึดเดิมทุกข้อ

เส้นแบ่งเดียวที่ทั้ง taxonomy ตั้งอยู่บนมัน

Anthropic ลากเส้นแบ่งสถาปัตยกรรมไว้ประโยคเดียว และเราจะยกมาทั้งสองครึ่งเพราะทุกคำมีน้ำหนัก — workflow คือ “systems where LLMs and tools are orchestrated through predefined code paths” ส่วน agent คือ “systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”

อ่านช้าๆ เส้นแบ่งอยู่ที่คำถามเดียว: ใครเป็นคนกำหนดลำดับของขั้นตอน?

ใน workflow ลำดับถูกเขียนตายไว้ใน code C# ของคุณ — model ถูกเรียกในจุดที่คุณวางไว้ ตามลำดับที่คุณคุม model เป็นแค่ขั้นตอนหนึ่งในเส้นทางที่คุณออกแบบ
ใน agent ลำดับถูกกำหนดโดย ตัว model เอง ผ่าน loop — model ตัดสินว่าจะเรียก tool ตัวไหน เมื่อไร กี่ครั้ง แล้วจึงประกาศว่าเสร็จ นี่คือ harness กับ stop policy จากบทที่ 1 ที่ทำงานอยู่

พูดอีกอย่าง: harness และ loop จากบทที่ 1 คือสิ่งที่ทำให้ของกลายเป็น agent ไม่ใช่ workflow ถ้าคุณถอด while ออกแล้วเรียงลำดับการเรียก model เองใน code สิ่งที่เหลือคือ workflow และนี่คือประเด็นที่ต้องกลืนให้ลง — มูลค่าจริงส่วนใหญ่ที่ทีมสร้างได้ในโปรดักชันคือ workflow ไม่ใช่ agent 🔁 (บทที่ 1 · loop คือเครื่องยนต์ เปิดกล่อง runtime นั้นไว้แล้ว บทนี้ถามว่าเมื่อไรควรเปิดมัน)

เส้นแบ่งนี้ต่างจากคำถามเรื่อง 'ขอบเขต' ของคอร์ส #12

คอร์สนี้สอน กลไก ของ runtime — workflow กับ agent ต่างกันเชิงโครงสร้างอย่างไร ส่วนคำถามว่า “งานนี้ควรเป็น agent กี่ตัว ขอบเขตของแต่ละตัวอยู่ตรงไหน” เป็นเรื่องของคอร์ส #12 Agent as Bounded Context เส้นแบ่ง workflow/agent เป็นคนละแกนกับเส้นแบ่งขอบเขต — แต่ทั้งสองแกนเดินตามหลักเดียวกันคือ เริ่มจากสิ่งที่ง่ายที่สุด

หลักที่อยู่ใต้ taxonomy ทั้งอัน: หาทางที่ง่ายที่สุดก่อน

ก่อนจะไล่ pattern ทั้งห้าในบทถัดๆ ไป ต้องปักหลักคิดที่รองรับทั้ง taxonomy ไว้ก่อน Anthropic รายงานสิ่งที่เขาพบจากการช่วยหลายทีมสร้าง agent ตรงๆ — “Consistently, the most successful implementations weren’t using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns.” ระบบที่สำเร็จที่สุดไม่ได้ใช้ framework ที่ซับซ้อน แต่ประกอบจาก pattern ง่ายๆ ที่ต่อกันได้

หลักที่ตามมาคือแกนกลางของทั้งคอร์ส — “When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed.” หาทางที่ง่ายที่สุดก่อน แล้ว ค่อย เพิ่มความซับซ้อน เมื่อจำเป็น เท่านั้น ประโยคนี้คือมาตรวัดที่เราจะใช้ตัดสินทุก pattern ในบทที่ 3–8: multi-actor structure ในบทที่ 4/5 ไม่ใช่ “อัปเกรด” ที่เอื้อมไปหยิบ แต่เป็น ข้อยกเว้น ที่ต้องพิสูจน์ว่าคุ้ม

และข้อสรุปที่แหลมที่สุดของหลักนี้คือ บางทีคำตอบที่ถูกคือ อย่าสร้าง agent เลย — “This might mean not building agentic systems at all. Agentic systems often trade latency and cost for better task performance, and you should consider when this trade-off makes sense.” agent แลก latency และ cost เพื่อได้ task performance ที่ยืดหยุ่นขึ้น การแลกนี้ต้องคุ้มก่อนถึงจะทำ ไม่ใช่ทำเพราะมันฟังดูล้ำกว่า

เส้นเลือกตรงๆ ที่ Anthropic ให้ไว้คือ — “Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.” งานที่นิยามชัด เดินเส้นเดิมทุกครั้ง → workflow (คาดเดาได้ เทสได้) ส่วนงานที่ต้องการความยืดหยุ่นและให้ model ตัดสินใจเองในสเกลใหญ่ → agent

Order flow เดียวกัน สองรูปทรง

ลองเอา flow เดียวกันจาก agent Order — “ออเดอร์ล่าช้าไหม ถ้าล่าช้าให้คืนเงินแล้วแจ้งลูกค้า” — มาเขียนทั้งสองแบบ วางเทียบกันจะเห็นเส้นแบ่งชัดที่สุด

แบบ workflow — ลำดับ getOrder → ตรวจ → ร่างข้อความ → issueRefund ถูกเขียนตายไว้ใน code C# model ถูกเรียก หนึ่งครั้ง ในจุดเดียวที่เราวางไว้ (ร่างข้อความ) ส่วนการตัดสินใจว่า ล่าช้าไหม และ สั่งคืนเงินเมื่อไร เป็น if กับการเรียก method ธรรมดา ไม่ใช่ model:

// WORKFLOW — เส้นทางถูกกำหนดล่วงหน้าใน code; "เรา" คุมลำดับ model เป็นแค่ขั้นตอนหนึ่ง
async Task<string> HandleLateOrder(string orderId, CancellationToken ct) {
    Order order = await GetOrder(orderId);                          // 1. code ตัดสินว่าเรียกอะไรก่อน ไม่ใช่ model
    if (!order.IsLate) return "ออเดอร์ยังอยู่ในกำหนด";               // 2. gate: แตกแขนงด้วย if ธรรมดา
    ChatResponse note = await client.GetResponseAsync(              // 3. เรียก model "หนึ่งครั้ง" เพื่อร่างข้อความ
        $"ร่างข้อความแจ้งลูกค้าว่าออเดอร์ {orderId} ล่าช้าและกำลังคืนเงิน", cancellationToken: ct);
    await IssueRefund(orderId, order.Total);                        // 4. code สั่ง write action เอง ไม่ใช่ model
    return note.Text;                                              // ลำดับ 1→2→3→4 ตายตัว รันกี่ครั้งก็เดินเส้นเดิม
}

แบบ agent — คือ middleware loop จากบทที่ 1 ที่เราไม่ได้เขียนลำดับใดๆ เลย เราแค่ยื่น tool ทั้งสามให้แล้วปล่อยให้ model วางแผนเองว่าจะเรียกอะไรก่อน กี่ครั้ง แล้วจึงหยุด:

// AGENT — model กำหนดลำดับของตัวเองผ่าน tool ใน loop
IChatClient agent = anthropic.AsIChatClient("claude-opus-4-8")   // bare id, ตัวอย่าง ณ 2026-07 — ไม่ต่อ suffix วันที่
    .AsBuilder().UseFunctionInvocation().Build();

ChatResponse resp = await agent.GetResponseAsync(
    "ออเดอร์ A-1002 อยู่ไหน ถ้าส่งช้าให้คืนเงิน", options, ct);
// เราไม่ได้เขียนว่า getOrder ก่อนหรือ getDeliveryStatus ก่อน — model ตัดสินลำดับนั้นเอง แล้ว loop หยุดเมื่อไม่มี tool call

code สองก้อนนี้ทำงานเดียวกันบนเคสง่ายๆ แต่ราคาต่างกันคนละเรื่อง แบบ workflow ให้ ความคาดเดาได้และความสม่ำเสมอ — ทุกครั้งที่ล่าช้าจริงจะเดิน getOrder → refund → แจ้ง เป๊ะ เทสได้ตรงไปตรงมา และรู้ต้นทุนล่วงหน้า (เรียก model หนึ่งครั้ง) ส่วนแบบ agent ยืดหยุ่นกว่า — รับคำถามพลิกแพลงได้โดยไม่ต้องแก้ code — แต่แลกมาด้วยจำนวนรอบที่ คาดเดายาก (จึงต้องมี stop policy) และต้นทุน token ที่โตขึ้น สำหรับ Order flow ที่นิยามชัดแบบนี้ workflow มักเป็นคำตอบที่ถูก และคุณเก็บ agent ไว้ให้กับงานที่เส้นทางพยากรณ์ไม่ได้จริงๆ

flowchart TB
  subgraph WF["Workflow — code กำหนดเส้นทาง"]
    direction TB
    A1["getOrder"] --> A2{"ล่าช้าไหม<br/>code ตัดสินด้วย if"}
    A2 -->|"ไม่"| A3["แจ้งยังไม่ถึงกำหนด"]
    A2 -->|"ใช่"| A4["ร่างข้อความ<br/>เรียก model 1 ครั้ง"]
    A4 --> A5["issueRefund<br/>code สั่งเอง"]
  end
  subgraph AG["Agent — model กำหนดเส้นทาง"]
    direction TB
    B1["model วางแผนใน loop"] --> B2{"เรียก tool ไหนต่อ<br/>model ตัดสิน"}
    B2 -->|"ยังไม่จบ"| B3["dispatch tool<br/>ผนวกผลกลับ"]
    B3 --> B1
    B2 -->|"ไม่มี tool call"| B4["ตอบ แล้วจบ"]
  end
  classDef model fill:#b91c1c,stroke:#7f1d1d,color:#f8fafc;
  class B1,B2 model;

คำบรรยายภาพ: flow เดียวกันสองรูปทรง ฝั่งซ้าย (workflow) การแตกแขนงและลำดับอยู่ใน code — if เป็นคนตัดสินว่าล่าช้าไหม code เป็นคนสั่ง issueRefund model ถูกเรียกแค่จุดเดียว ฝั่งขวา (agent) ช่องสีแดงคือจุดที่ model เป็นผู้ตัดสินลำดับเอง — เลือก tool ถัดไปใน loop จนกว่าจะไม่มี tool call แล้วจึงหยุด เส้นแบ่งคือ “ใครกำหนดลำดับ” ไม่ใช่ “งานยากแค่ไหน”

ด่านสี่คำถามก่อนเอื้อมหา harness

ก่อนตัดสินใจสร้าง agent ให้เดินผ่านด่านสี่คำถามนี้ — ถ้าตอบ “ไม่” ข้อใดข้อหนึ่ง ให้ถอยไปทำ workflow:

ความซับซ้อน (complexity) — เส้นทางพยากรณ์ล่วงหน้าไม่ได้จริงไหม? ถ้าเส้นทางเป็น decision tree ที่คุณเขียนออกมาเป็น if/switch ได้ครบ นั่นคือ workflow อย่าใส่ loop
มูลค่า (value) — ความยืดหยุ่นที่ได้จาก agent คุ้มกับ latency และ cost ที่แลกไปไหม? งานปริมาณมากที่มาร์จินบางอาจกินราคา agent ไม่ไหว
ความเป็นไปได้ (viability) — model ทำงานนี้ใน loop ได้เชื่อถือพอไหม หรือ error จะสะสมจนพัง? (บทที่ 8 จะให้ตัวเลขว่าทำไม error ยิ่งหลายรอบยิ่งทบ)
ต้นทุนของความผิด (cost of error) — ถ้า agent ตัดสินผิดกลาง loop (เช่นสั่ง issueRefund เกิน) ความเสียหายรับได้ไหม หรือต้องมี checkpoint คุม? write action ที่มีผลข้างเคียงยกระดับต้นทุนข้อนี้ทันที

ด่านนี้ไม่ได้บอกว่า agent ไม่ดี — มันบอกว่า agent มี ราคา และราคานั้นต้องมีคนจ่ายด้วยมูลค่าที่ได้กลับมา นี่คือหลัก “เพิ่มความซับซ้อนเมื่อจำเป็นเท่านั้น” ที่ลงมือทำได้จริง

บันไดของบทที่เหลือ — ทุกขั้นคือจุดบนเส้นเดียวกัน

pattern ทั้งหมดในคอร์สนี้เรียงอยู่บนบันไดความง่าย-ก่อน-ซับซ้อนเส้นเดียว ไล่จากล่างขึ้นบน:

บทที่ 3 — prompt chaining & routing (workflow): ต่อการเรียก model เป็นลำดับตายตัวพร้อม gate และจัดเส้นทางด้วยการ classify — เส้นทางใน code ยังไม่ใช่ agent
บทที่ 4 — parallelization (workflow): แตกงานอิสระออกวิ่งขนาน — เฉพาะเมื่อ subtask อิสระต่อกันจริง
บทที่ 5 — orchestrator-workers (workflow ที่ก้ำกึ่ง): model นำแตกงานเอง — pattern ที่แพงที่สุด ต้องพิสูจน์ว่าคุ้ม
บทที่ 6 — evaluator-optimizer: สร้าง → ประเมิน → ปรับ ใน loop และ เมื่อไรไม่ควร reflect
บทที่ 7 — ความทนทาน: tool-error recovery, retry, timeout, idempotency
บทที่ 8 — 🔁 autonomous-agent capstone: ประกอบทุกอย่างเป็น agent จริงที่มี compound stop policy — และปิดคอร์สด้วยความซื่อสัตย์ว่า agent แพงกว่า ใช้สิ่งที่ง่ายที่สุดที่ได้ผล

ทุก pattern ในบทที่ 3–6 ยังเป็น workflow — เส้นทางอยู่ใน code ของคุณ agent เต็มตัวที่ model คุมลำดับเองรอไว้ที่บทที่ 8 ที่เดียว นั่นคือลำดับที่ตั้งใจ: เราไต่ความซับซ้อนขึ้นทีละขั้น ไม่กระโดดไปหา autonomous loop ตั้งแต่แรก

หลักปิดท้ายสามข้อ ที่บทหลังๆ จะจ่ายคืน

ตอน Anthropic สรุป taxonomy เขาทิ้งหลักไว้สามข้อที่กำกับทุกบทลงมือของคอร์สนี้:

“Maintain simplicity in your agent’s design.” — รักษาความเรียบง่ายของ design ไว้ (บทที่ 4/5/8 หมุนรอบข้อนี้)
“Prioritize transparency by explicitly showing the agent’s planning steps.” — ให้เห็นขั้นการวางแผนของ agent อย่างโปร่งใส (บทที่ 8 พิมพ์ trace ทุก tool call ก็มาจากข้อนี้)
“Carefully craft your agent-computer interface (ACI) through thorough tool documentation and testing.” — ประณีตกับ agent-computer interface ผ่านการเขียน doc ของ tool และการเทสอย่างจริงจัง

ข้อสุดท้ายมีกฎนิ้วหัวแม่มือที่คุ้มค่าจำ — “think about how much effort goes into human-computer interfaces (HCI), and plan to invest just as much effort in creating good agent-computer interfaces (ACI).” ทุ่มแรงกับ interface ที่ tool คุยกับ model เท่ากับที่คุณทุ่มให้ interface ที่คนคุยกับเครื่อง — บทที่ 7 เรื่องความทนทานคือ ACI ที่ทำจริง

สรุปก่อนไปต่อ

เส้นแบ่งของบทนี้มีแกนเดียว: ใครกำหนดลำดับ — code ของคุณ (workflow) หรือตัว model เอง (agent) harness กับ loop จากบทที่ 1 คือสิ่งที่ทำให้ของกลายเป็น agent แต่หลักที่อยู่ใต้ทั้ง taxonomy คือ หาทางที่ง่ายที่สุดก่อน แล้วค่อยเพิ่มความซับซ้อนเมื่อจำเป็น — และบางทีคำตอบที่ถูกคืออย่าสร้าง agent เลย งานที่นิยามชัดอย่าง Order flow ส่วนใหญ่คือ workflow ที่คาดเดาได้และเทสได้ บทหน้าเราลงมือ workflow pattern แรก — prompt chaining ที่ต่อการเรียก model เป็นลำดับพร้อม gate และ routing ที่ classify แล้วจัดเส้นทาง

🔗 อ้างอิงต้นทางของบทนี้

บทนี้อิงต้นทางที่ลงวันที่กำกับ อ่านต่อได้โดยตรง:

Anthropic, “Building Effective Agents” (2024-12-19) — เส้นแบ่ง workflow (“orchestrated through predefined code paths”) กับ agent (“dynamically direct their own processes and tool usage”), หลัก “finding the simplest solution possible, and only increasing complexity when needed”, คำเตือน “not building agentic systems at all”, เส้นเลือก workflow-vs-agent และหลักปิดท้ายสามข้อ (simplicity / transparency / ACI)

เช็กความเข้าใจ — บทที่ 2

ข้อ 1 / 3

ตามเส้นแบ่งของ Anthropic อะไรคือความต่างเชิงโครงสร้างระหว่าง workflow กับ agent?

Workflow ต่าง​กับ Agent

เส้น​แบ่ง​เดียว​ที่​ทั้ง taxonomy ตั้ง​อยู่​บน​มัน

หลัก​ที่​อยู่​ใต้ taxonomy ทั้ง​อัน: หา​ทาง​ที่​ง่าย​ที่สุด​ก่อน

Order flow เดียวกัน สอง​รูปทรง

ด่าน​สี่​คำถาม​ก่อน​เอื้อมหา harness

บันได​ของ​บท​ที่​เหลือ — ทุก​ขั้น​คือ​จุด​บน​เส้น​เดียวกัน

หลัก​ปิด​ท้าย​สาม​ข้อ ที่บทหลังๆ จะ​จ่าย​คืน

สรุป​ก่อน​ไป​ต่อ