เมื่อไรไม่ควรใช้ agent (+ eval)

เจ็ดบทที่ผ่านมาเราลงแรงกับคำถามด้านเดียว: อะไรควรอยู่ใน Agent ที่มีขอบเขตดีตัวเดียว — ภาษาหนึ่งชุด, tool ที่พอดีหน้าที่, บริบทที่แคบพอจะรักษางบ attention, และเปิดประตูให้ Multi-agent เฉพาะเมื่อมีเหตุผลรองรับ บทปิดคอร์สนี้ถอยออกมาถามคำถามที่กลับด้านกัน สองข้อ: เมื่อไรไม่ควรมี agent ตั้งแต่แรก และ จะรู้ได้ยังไงว่า agent ที่ปั้นมาทำงานตรงตามขอบเขตจริง คำถามแรกคือ ประตูต้นทุน คำถามที่สองคือ Eval — และทั้งสองเป็นวินัยของการยับยั้งชั่งใจแบบเดียวกับที่ทั้งคอร์สยืมมาจาก DDD

📦 code ตัวอย่าง

คอร์สนี้เป็น คอร์สออกแบบ ไม่ใช่ทัวร์ SDK — code ในบทคือ ภาพร่าง ของ decision gate, eval rubric และโทโพโลยี (Thai Mermaid + pseudo-config สั้นๆ) ไม่ใช่ app ที่รันได้จริง สิ่งที่วาดด้วย LangGraph / OpenAI Agents SDK / Claude เป็นเพียงตัวอย่างประกอบ ตัวอย่างต่อยอดจาก domain เดิมที่ repo kaen-food-ordering (กำลังจัดทำ) โดยมองมันผ่านเลนส์ ops-copilot ที่ช่วยทีมปฏิบัติการของ platform

ประตูต้นทุน: agent ไม่ใช่อัปเกรดฟรี

ก่อนถามว่า agent จะทำงานได้ดีแค่ไหน ต้องถามก่อนว่ามัน แพงแค่ไหน — เพราะทุกครั้งที่ Agentic Loop วนหนึ่งรอบ มันเอาผล tool กลับเข้า context แล้วเรียก model ใหม่ ต้นทุน token จึงไม่ได้จ่ายครั้งเดียว แต่จ่ายทบทุกรอบ Anthropic ให้ตัวเลขที่ควรจำขึ้นใจใน How we built our multi-agent research system (Anthropic, Jun 2025): จากข้อมูลจริงของเขา agent ตัวเดียวกิน token ราว ~4 เท่าของแชตธรรมดา (chat) และ multi-agent กินราว ~15 เท่าของแชต

ตัวเลขพวกนี้อันตรายถ้าจำครึ่งเดียว กติกาข้อเดียวที่ห้ามลืมคือ บอกเสมอว่าเทียบกับ baseline ไหน:

~4× — single agent เทียบ chat — ที่มา How we built our multi-agent research system
~15× — multi-agent เทียบ chat — ที่มาเดียวกัน (post multi-agent research system)
~3–10× — multi-agent เทียบ single agent ที่ทำงานเดียวกัน — ที่มา When to use multi-agent systems (and when not to) ซึ่งระบุตัวเลขนี้ไว้ตรงๆ (คนละแหล่งกับสองข้อบน ไม่ใช่ค่าที่ได้จากการหาร)

คนที่พูดลอยๆ ว่า “multi-agent แพงกว่า 15 เท่า” โดยไม่บอก baseline มักทำให้คนฟังเข้าใจว่าแพงกว่า agent เดี่ยว 15 เท่า ทั้งที่ความจริงคือแพงกว่า แชต 15 เท่า และแพงกว่า agent เดี่ยว แค่ไม่กี่เท่า การสับ baseline สองอันนี้พาไปสู่การตัดสินใจผิดคนละทิศ นี่คือ “ประตูต้นทุน” ที่บทที่ 5 เกริ่นไว้ในบริบท Orchestrator-Workers: การกระโดดขึ้นแต่ละขั้น — จาก code ธรรมดา → workflow → agent → multi-agent — คือการจ่ายค่าความยืดหยุ่นด้วย token, latency และความไม่แน่นอน มันไม่ใช่อัปเกรดฟรีสักขั้นเดียว

autonomy เหมาะกับงานปลายเปิดในสภาพแวดล้อมที่เชื่อถือได้

ถ้าต้นทุนคือด้านหนึ่งของเหรียญ ความเหมาะสมของงาน คืออีกด้าน คำแนะนำจาก Building Effective Agents (Anthropic, Dec 2024) ชัดเจน: ให้ agent มี autonomy เต็มเฉพาะกับ งานปลายเปิดที่เดาจำนวนขั้นตอนล่วงหน้าไม่ได้และ hardcode เส้นทางตายตัวไม่ได้ — และให้ปล่อย autonomy นั้น ในสภาพแวดล้อมที่เชื่อถือได้ เท่านั้น “เชื่อถือได้” ในที่นี้หมายถึงสภาพที่ agent ลองแล้วผิดได้โดยไม่ทำลายอะไรถาวร: มี sandbox, การกระทำย้อนกลับได้ หรือมี Guardrail คั่นก่อนถึงจุดที่ย้อนไม่ได้

เหตุผลอยู่ที่ธรรมชาติของ agentic loop เอง Chip Huyen อธิบายไว้ใน Chip Huyen — Agents (Jan 2025) ว่ายิ่ง agent วนหลายก้าว โอกาสพลาดยิ่ง ทบต้น — ถ้าแต่ละก้าวถูก 95% งานสิบก้าวติดก็เหลือความน่าเชื่อถือรวมราว 60% เท่านั้น งานที่ผิดหนึ่งก้าวแล้วเสียหายถาวร (เช่นคืนเงินเกินยอด, ลบข้อมูลจริง) จึงไม่ใช่ที่ของ autonomy เต็มรูป มันคือที่ของ Human-in-the-loop หรือ workflow ที่ล็อกเส้นทางไว้ ใน domain ops-copilot ของเรานี่แปลได้ตรงๆ: การ “อ่านสถานะออเดอร์” อยู่ใน sandbox โดยธรรมชาติ (อ่านอย่างเดียว ผิดก็แค่อ่านใหม่) แต่การ “คืนเงิน” ไม่มีวันเป็น sandbox — มันเป็นเส้นที่ต้องมีคนกั้นเสมอ

เมื่อไร workflow / single agent / ไม่ใช้ agent ชนะ

รวมสองด้าน — ต้นทุนกับความเหมาะสม — เข้าเป็นบันไดตัดสินใจได้เลย หลักยึดยังเป็นข้อเดิมจาก Building Effective Agents: เริ่มจากสิ่งที่ง่ายที่สุดที่แก้ปัญหาได้ แล้วเพิ่มความซับซ้อนเมื่อจำเป็น เท่านั้น ตรงนี้คือจุดที่ต้องแยก workflow / single agent / ไม่ใช้ agent ออกจากกันให้ขาด แล้วไต่ขึ้นทีละขั้นเมื่อขั้นล่างตอบโจทย์ไม่ได้จริงๆ:

ไม่ใช้ agent (code ธรรมดา / workflow) — งานที่เส้นทางตายตัว คาดเดาได้ เขียนเป็นลำดับขั้นได้ เช่น “ลูกค้ากดยกเลิก → เช็กว่ายังไม่เข้าครัว → คืนสถานะ” งานแบบนี้ workflow ชนะขาดเพราะถูก คาดเดาได้ ทดสอบง่าย และไม่มีความไม่แน่นอนของ agentic loop มาให้ปวดหัว
single agent — งานปลายเปิดในสภาพแวดล้อมที่เชื่อถือได้ และมูลค่าคุ้มกับต้นทุน ~4× เช่นตอบคำถามลูกค้าที่รูปคำถามเดาไม่ได้ล่วงหน้า นี่คือ ค่าเริ่มต้น เมื่อพ้นระดับ workflow
multi-agent — เฉพาะเมื่อผ่านประตู 3 เหตุผลจากบทที่ 5 (When to use multi-agent systems (and when not to) (Anthropic/Claude) — context protection / parallelization / specialization) และ มูลค่างานคุ้มกับต้นทุน ~15× เทียบแชต ไม่ใช่เพราะ “มันเป็นคนละ Subdomain”

flowchart TD
  START["งานที่อยากให้ AI ช่วยในทีมปฏิบัติการ"]
  Q1{"ขั้นตอนตายตัว<br/>คาดเดาเส้นทางได้ไหม?"}
  W["ไม่ใช้ agent<br/>code ธรรมดา / workflow<br/>ถูก คาดเดาได้ ทดสอบง่าย"]
  Q2{"สภาพแวดล้อมเชื่อถือได้/มี sandbox<br/>และผิดแล้วกู้คืนได้ไหม?"}
  H["ยังไม่ให้ autonomy เต็ม<br/>workflow + human-in-the-loop<br/>คั่นก่อนการกระทำที่ย้อนไม่ได้"]
  Q3{"มูลค่างานคุ้มต้นทุน<br/>~4× token ของ chat ไหม?"}
  SA["single agent ที่มีขอบเขตดี<br/>1 bounded context<br/>เริ่มที่นี่เสมอ"]
  Q4{"มี 1 ใน 3 เหตุผล isolation<br/>และคุ้ม ~15× token ของ chat?"}
  MA["multi-agent (orchestrator-workers)<br/>ข้อยกเว้นที่ต้องพิสูจน์"]
  START --> Q1
  Q1 -->|"ใช่ ตายตัว"| W
  Q1 -->|"ปลายเปิด"| Q2
  Q2 -->|"ไม่"| H
  Q2 -->|"ใช่"| Q3
  Q3 -->|"ไม่คุ้ม"| W
  Q3 -->|"คุ้ม"| SA
  SA --> Q4
  Q4 -->|"ยังไม่ผ่าน"| SA
  Q4 -->|"ผ่าน พิสูจน์ได้"| MA
  classDef plain fill:#bbf7d0,stroke:#166534,color:#1a1a1f;
  classDef def fill:#c7d2fe,stroke:#3730a3,color:#1a1a1f;
  classDef gate fill:#fde68a,stroke:#b45309,color:#1a1a1f;
  classDef exc fill:#fca5a5,stroke:#7f1d1d,color:#1a1a1f;
  class W,H plain;
  class SA def;
  class Q1,Q2,Q3,Q4 gate;
  class MA exc;

คำบรรยายภาพ: บันไดตัดสินใจ “ควรใช้ agent ไหม” อ่านจากบนลงล่างเป็นชุดประตู (เหลือง) — งานตายตัวตกไปที่ workflow (เขียว), งานที่สภาพแวดล้อมไม่น่าเชื่อถือหรือย้อนไม่ได้ตกไปที่ workflow + human-in-the-loop, งานปลายเปิดที่คุ้มต้นทุน ~4× ถึงจะได้ single agent (น้ำเงิน) ซึ่งเป็นค่าเริ่มต้นเมื่อพ้น workflow และ multi-agent (แดง) เป็นปลายทางเดียวที่ต้องผ่านประตูสองชั้น: มี 1 ใน 3 เหตุผล isolation และ คุ้มต้นทุน ~15× เทียบแชต ย้ำวินัยเดิมของทั้งคอร์ส — การไปถึงกล่อง single agent หรือ multi-agent ไม่ใช่ “เป้าหมาย” ที่ต้องไต่ให้สุด เส้นทุกเส้นถูกลากบน discontinuity ของภาษา/ความไว้ใจ/ต้นทุน ไม่ใช่บนตำแหน่งงานหรือ subdomain และคำตอบที่ถูกสำหรับงานส่วนใหญ่คือกล่องเขียวหรือน้ำเงิน ไม่ใช่แดง

eval: วัดที่ปลายทาง ไม่ใช่เส้นทาง

สมมติผ่านประตูต้นทุนแล้ว งานนี้คุ้มที่จะเป็น agent จริง คำถามถัดมาคือ รู้ได้ยังไงว่ามันทำงานถูก — และนี่คือจุดที่ agent ต่างจาก code ธรรมดาที่สุด code deterministic test ด้วยการเทียบ output กับค่าที่คาดไว้เป๊ะๆ แต่ agent เดินไปถึงคำตอบเดียวกันได้ หลายเส้นทาง จะวัดมันด้วยไม้บรรทัดแบบเดิมไม่ได้ ต้องมี eval ที่ออกแบบมาเพื่อความไม่แน่นอนนี้โดยเฉพาะ

เริ่มด้วย ~20 query จริง ก่อน อย่าเพิ่งไปสร้างชุดทดสอบพันเคสอัตโนมัติตั้งแต่วันแรก Anthropic แนะนำใน How we built our multi-agent research system (Anthropic, Jun 2025) ว่า eval ที่ดีเริ่มจากตัวอย่างจำนวนน้อยแต่ เป็นของจริง — ราว 20 query ที่มาจากการใช้งานจริง ก็พอจับสัญญาณ regression ก้อนใหญ่ได้แล้ว การรอจนมีชุดใหญ่ “ครบสมบูรณ์” ค่อยเริ่มวัด มักแปลว่าไม่ได้เริ่มวัดเลย

ตัดสินที่ end-state ไม่ใช่ golden trajectory นี่คือหัวใจของบทนี้ กับดักที่พบบ่อยคือบันทึกเส้นทาง “ที่ถูกต้อง” ไว้หนึ่งเส้น (golden trajectory) แล้ว diff เส้นที่ agent เดินจริงกับมันทีละก้าว — วิธีนี้พังเพราะ agent ที่ทำงานถูกอาจเลือก tool คนละตัว สลับลำดับ หรือลองผิดแล้วแก้ตัวเองระหว่างทาง ทุกความต่างที่ไม่ใช่ความผิดจริงจะถูกนับเป็น fail หมด (false negative เพียบ) ทางที่ถูกกว่าคือถามว่า ปลายทางถูกไหม: ออเดอร์ที่ลูกค้าถามได้สถานะที่ถูกต้องกลับไปหรือเปล่า, เคสถูกปิดด้วยผลที่ตรงนโยบายไหม — นี่คือ outcome-eval ส่วนตัว process ให้ตรวจ เป็นจุดๆ ที่สำคัญแทน ไม่ใช่เทียบทั้งเส้น: “มันเรียก guardrail คืนเงินก่อนโอนจริงไหม”, “มันหลุดไปแตะ tool นอกขอบเขตหรือเปล่า” — เป็น checkpoint ไม่กี่จุด ไม่ใช่ trajectory-diff

LLM-as-judge เรียกครั้งเดียวด้วย rubric เมื่อ output เป็นภาษาธรรมชาติที่ไม่มีคำตอบตายตัว ให้ใช้ model อีกตัวเป็นผู้ตัดสิน (LLM-as-judge) โดยป้อน rubric ที่เขียนเกณฑ์ไว้ชัด — ถูกตามข้อเท็จจริงไหม, ครบทุกประเด็นที่ถามไหม, อยู่ในนโยบายไหม — แล้วให้ judge ให้คะแนนทุกเกณฑ์ใน การเรียกครั้งเดียว Anthropic พบว่า judge เดี่ยวที่ถือ rubric ครบทุกมิติได้ผลนิ่งและถูกกว่าการซอยเป็น judge หลายตัวเรียกหลายครั้ง

seed_set: 20            # query จริงจากการใช้งาน ไม่ใช่พันเคสสังเคราะห์
judge: outcome          # ตัดสินที่ end-state ไม่ diff เส้นทางทั้งเส้น
end_state_checks:
  - สถานะ/ETA ที่คืนตรงกับความจริงของออเดอร์
  - ตอบครบประเด็นที่ลูกค้าถาม
process_spot_checks:    # ตรวจเป็นจุด ไม่ใช่ trajectory-diff
  - ไม่เรียก tool นอกขอบเขต (เช่น issue_refund)
  - เรียก human-approval guardrail ก่อนการกระทำที่ย้อนไม่ได้
llm_judge:
  calls: 1              # เรียกครั้งเดียว ถือ rubric ครบทุกมิติ
  rubric: [ถูกตามข้อเท็จจริง, ครบประเด็น, อยู่ในนโยบาย]

error analysis ด้วยมือ: อ่าน transcript แล้วตั้งชื่อความพลาด

eval อัตโนมัติบอกว่า คะแนนตก แต่ไม่ได้บอกว่า ตกเพราะอะไร — ส่วนนั้นยังต้องใช้คน นี่คือ human-in-the-loop ในบทบาทที่คนมักลืม: ไม่ใช่แค่กั้นการกระทำเสี่ยงตอน runtime แต่คือคนที่นั่งอ่าน transcript ตอนวัดผลด้วย วินัยที่ได้ผลคือ อ่าน 20–50 transcript ด้วยมือ แล้วทำ error analysis — ดูว่า agent พลาดตรงไหน คิดอะไรอยู่ตอนพลาด ยิ่งอ่านของจริงมาก ยิ่งเจอ failure mode ที่ automated eval มองข้าม

ขั้นที่ทำให้ error analysis กลายเป็นของใช้ได้จริงคือ ตั้งชื่อ class ความพลาด อย่าปล่อยให้ความผิดเป็นกองข้อสังเกตกระจัดกระจาย ให้จัดเป็นหมวดที่ซ้ำได้ สามหมวดที่ครอบเคสส่วนใหญ่:

planning — วางแผน/แตกงานผิดตั้งแต่ต้น เช่นเข้าใจคำถามลูกค้าผิดทิศ หรือเลือกกลยุทธ์ที่ไม่มีวันตอบโจทย์
tool — เลือก tool ผิดตัว กรอก parameter ผิด หรืออ่านผลลัพธ์ที่ tool คืนมาผิด
efficiency — ปลายทางถูกแต่เปลืองเกินเหตุ วนซ้ำ เรียก tool ซ้ำๆ ผลาญ token โดยไม่จำเป็น (หมวดนี้เชื่อมกลับประตูต้นทุนตรงๆ)

พอความพลาดมีชื่อ มันก็นับได้ จัดลำดับได้ และแก้ตรงจุดได้ — planning ที่พลาดบ่อยมักแก้ที่ System Prompt, tool ที่พลาดบ่อยมักแก้ที่ schema/description ของ tool (คือ ACL จากบทที่ 6), efficiency ที่แย่มักแก้ที่ขอบเขตหรือ Agent Memory วง eval จึงไม่ใช่การให้เกรดครั้งเดียวจบ แต่เป็นวงที่หมุนกลับมาปรับ design

flowchart LR
  Q["1. เก็บ ~20 query จริง<br/>seed set จากงานจริง"]
  RUN["2. รัน agent<br/>เก็บ transcript + end-state"]
  JUDGE["3. ตัดสินที่ end-state (outcome-eval)<br/>+ LLM-as-judge ตาม rubric เรียกครั้งเดียว<br/>+ ตรวจ process เป็นจุด ไม่ใช่ trajectory-diff"]
  HUMAN["4. human-in-the-loop<br/>อ่าน 20-50 transcript ด้วยมือ<br/>error analysis"]
  CLASS["5. ตั้งชื่อ class ความพลาด<br/>planning / tool / efficiency"]
  FIX["6. แก้ system prompt / tool / guardrail<br/>ตาม class ที่พลาดบ่อยสุด"]
  Q --> RUN --> JUDGE --> HUMAN --> CLASS --> FIX
  FIX -->|"วนซ้ำ"| Q
  classDef step fill:#c7d2fe,stroke:#3730a3,color:#1a1a1f;
  classDef human fill:#fde68a,stroke:#b45309,color:#1a1a1f;
  class Q,RUN,JUDGE,FIX step;
  class HUMAN,CLASS human;

คำบรรยายภาพ: วง eval หมุนหกก้าว — เก็บ ~20 query จริงเป็น seed set, รัน agent เก็บ transcript, ตัดสินที่ end-state ด้วย outcome-eval บวก LLM-as-judge (rubric เรียกครั้งเดียว) และตรวจ process เป็นจุดๆ ไม่ใช่ diff ทั้งเส้นทาง สองก้าวสีเหลืองคือส่วนที่คนยังต้องลงมือ: อ่าน 20–50 transcript ทำ error analysis และตั้งชื่อ class ความพลาด (planning/tool/efficiency) ก่อนป้อนกลับไปแก้ system prompt/tool/guardrail แล้ววนใหม่ จุดสำคัญคือลูกศรตัดสิน (ก้าว 3) ชี้ที่ ปลายทาง ไม่ใช่เทียบเส้นทางที่ agent เดินกับเส้น golden

ทำไมต้อง eval: เพราะ agent ไม่ใช่ aggregate

บทที่ 5 และ 6 พูดข้อควรระวังเดียวกันไว้แล้ว และมันมาบรรจบที่บทนี้พอดี ใน DDD ตัว aggregate รักษา invariant แบบ atomic — กฎธุรกิจถูกบังคับ ณ ขอบทุกครั้งที่ commit ไม่มีทางที่สถานะจะละเมิดกฎแล้วรอด แต่ context ของ agent ไม่ได้ ให้การรับประกันแบบนั้น พอ context ถูก compact หรือ summarize เพื่อกันไม่ให้ยาวเกิน กฎที่เคยฝังอยู่ (เช่น “คืนเงินต้องมีคนอนุมัติ”) อาจถูกย่อหายหรือเพี้ยนได้ การบังคับกฎของ agent จึงเป็นแบบ best-effort ไม่ใช่ atomic

นี่คือเหตุผลรากของทั้งบท: ถ้าการรักษาขอบเขตเป็น best-effort คุณก็ พิสูจน์ ด้วยการออกแบบอย่างเดียวไม่ได้ ต้อง วัด ว่ามันยังถูกรักษาไว้จริงหลังผ่านหลายรอบ eval คือครึ่งที่วัดได้ของคำว่า best-effort — คู่กับ agent memory ที่ดึงข้อเท็จจริงสำคัญกลับขึ้นมาย้ำ และ guardrail ที่ hard-stop การกระทำย้อนไม่ได้นอก context กล่าวอีกแบบ: aggregate การันตีขอบเขตด้วยตัวมันเอง แต่ agent ต้องการ ระบบสามชั้น — memory + guardrail + eval — มาทดแทนการันตีที่มันไม่มี เรื่อง eval ลึกกว่านี้ (dataset design, การกัน judge bias, การวัด regression เป็นระบบ) เป็นหัวข้อของ คอร์ส Evals ในอนาคตของแก่น บทนี้ปักหมุดแค่หลักคิด: วัดที่ปลายทาง เริ่มจากน้อยแต่จริง และให้คนอ่าน transcript

ปิดคอร์ส: DDD คือคำศัพท์ของความยับยั้งชั่งใจ

แปดบทที่ผ่านมาไม่มี domain ใหม่สักบท มีแต่ domain ฟู้ดเดลิเวอรีเดิมที่มองผ่านเลนส์ agent — และทุกบทย้ำวินัยข้อเดียว: รู้ก่อนว่าอะไรควรอยู่ใน agent ที่มีขอบเขตดีตัวเดียว แล้วค่อยแตกเมื่อมีเหตุผลจริง Bounded Context บอกว่าขอบเขตอยู่ตรงไหน, Ubiquitous Language กลายเป็น system prompt กับชื่อ tool, Context Map มาก่อนการนับจำนวน agent, ACL กั้นความรกของ backend ที่ขอบ, published language ทำให้ agent คุยกันได้โดยไม่ปนเปื้อน และบทนี้ปิดด้วยประตูต้นทุนกับ eval

วงการ agent ปี 2024–2025 กำลังค้นพบสิ่งที่ DDD พูดมาสองทศวรรษด้วยตัวเอง — “อย่าแยกถ้าไม่มี discontinuity จริง”, “เริ่มจากสิ่งที่ง่ายที่สุด”, “ภาระพิสูจน์อยู่ที่ฝ่ายที่อยากแยก” ทั้ง Anthropic, Cognition และ Simon Willison ลงเอยที่คำแนะนำเดียวกัน: เริ่มที่ single agent เสมอ นั่นคือคือคุณค่าที่แท้จริงของการเอา DDD มาจับงานนี้ — มันไม่ใช่ศัพท์เท่ๆ ที่แปะทับของใหม่ แต่คือ คำศัพท์ของความยับยั้งชั่งใจ ที่มีมาก่อน พร้อมใช้กับยุคที่แรงกดดันให้ “แตก agent ให้เยอะเข้าไว้” ดังที่สุด ครั้งหน้าที่มีคนเสนอ multi-agent เป็นคำตอบแรก คุณมีทั้งคำถามและคำศัพท์ที่จะถามกลับว่า ทำไม — และนั่นคือทั้งหมดที่คอร์สนี้อยากมอบให้

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิดที่บทนี้ (และทั้งคอร์ส) ยืนอยู่บนได้ที่คลังอ้างอิง DevIQ:

Bounded Context — ขอบเขตที่ model และภาษาหนึ่งชุดคงความหมายไว้ วิทยานิพนธ์ที่ทั้งแปดบทยืมมาสวมร่างให้ agent
Subdomain — การจำแนก core/supporting/generic ที่บอกว่างานไหนคุ้มจะเป็น agent ปลายเปิด งานไหนควรเป็น workflow หรือซื้อสำเร็จ

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

ข้อ 1 / 3

ตัวเลข "multi-agent กิน token ราว ~15 เท่า" เป็นการเทียบกับ baseline ใด?

เมื่อไร​ไม่​ควร​ใช้ agent (+ eval)

ประตู​ต้นทุน: agent ไม่ใช่​อัปเกรด​ฟรี

autonomy เหมาะ​กับ​งาน​ปลาย​เปิด​ใน​สภาพ​แวดล้อม​ที่​เชื่อถือ​ได้

เมื่อไร workflow / single agent / ไม่​ใช้ agent ชนะ

eval: วัด​ที่​ปลายทาง ไม่ใช่​เส้นทาง

error analysis ด้วย​มือ: อ่าน transcript แล้ว​ตั้ง​ชื่อ​ความ​พลาด

ทำไม​ต้อง eval: เพราะ agent ไม่ใช่ aggregate

ปิด​คอร์ส: DDD คือ​คำ​ศัพท์​ของ​ความ​ยับยั้ง​ชั่งใจ