AI Agent คืออะไร: 5 ประเภทคลาสสิก กับ 2 นิยามคู่แข่ง

ตัวอย่างที่เก่าแก่ที่สุดในสาขานี้คือเครื่องดูดฝุ่นในโลกที่มีช่องสี่เหลี่ยมสองช่อง A และ B ซึ่งแต่ละช่องอาจสะอาดหรือสกปรกก็ได้¹ มันยังอยู่ในตำราทุกเล่ม เพราะนี่คือโลกที่เล็กที่สุดที่ agent สามารถทำถูกหรือผิดได้

percept เป็นคู่ — ฉันอยู่ที่ไหน และตรงนี้สกปรกหรือไม่ — และ actions คือ SUCK, LEFT และ RIGHT โปรแกรมทั้งหมดมีเพียงบรรทัดเดียว

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

ลองรันมันกับทุก configuration เริ่มต้นของโลกสองช่อง:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

นี่คือ simple reflex agent: มันลงมือตาม percept ปัจจุบันเท่านั้น โดยไม่มีความจำของสิ่งใดก่อนหน้านั้น นี่ไม่ใช่หมวดหมู่ของเล่น — เทอร์โมสตัทก็เป็นแบบนี้ และ call เดียวไปยัง language model โดยไม่มีบทสนทนาพ่วงมาด้วยก็เช่นกัน

ตอนนี้ทำให้มันพังในแบบที่โลกจริงทำ หุ่นดูดฝุ่นจริงมีเซ็นเซอร์ฝุ่นและกันชน ไม่ได้มีช่องที่ติดป้าย A อยู่ใต้พรม เอาตำแหน่งออกจาก percept แล้วไม่เปลี่ยนอย่างอื่น:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

โปรแกรมเดิม สองช่อง จากสถานะเริ่มต้นหนึ่งมันจบในสาม step; จากอีกสถานะหนึ่งมันวิ่งชนกำแพงด้านขวา 500 ครั้ง และคงวิ่งต่อไปจนแบตหมด มันรับรู้ความต่างระหว่างสองสถานการณ์ไม่ได้ จึงทำ action ต่างกันไม่ได้ Russell และ Norvig สรุปผลทั่วไปไว้ในบรรทัดเดียว: infinite loop มักหลีกเลี่ยงไม่ได้สำหรับ simple reflex agent ใน environment ที่สังเกตเห็นได้เพียงบางส่วน¹

มีทางแก้ที่เสียเพียงบรรทัดเดียวและไม่ต้องใช้ memory ควรวัดมันก่อนที่เราจะหยิบอะไรที่ฉลาดกว่านั้นมาใช้

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

รัน 2,000 ครั้งบนทางเดินที่สกปรกทั้งหมดในสามขนาด ใช้ตัวสร้างแบบ seeded ตัวเดียวตลอด:

Randomisation ลบ loop ออกไปได้ทั้งหมด แต่มันก็มีต้นทุน: ห้อง 8 ห้องต้องใช้ 15 moves ถ้าคุณรู้ว่ากำลังทำอะไรอยู่ แต่ agent นี้เฉลี่ย 68.7 และครั้งหนึ่งใช้ถึง 306 นี่คือทั้งบทในภาพย่อ ความสามารถทุกอย่างที่เราเพิ่มเข้ามาซื้อความถูกต้องในกรณีที่ agent ก่อนหน้ารับมือไม่ได้ และคิดราคาเป็นสกุลเงินที่คุณต้องตั้งชื่อให้ได้ก่อน

agent รับรู้ environment ผ่าน sensors และลงมือผ่าน actuators agent program คือฟังก์ชันจาก percepts ไปยัง actions — listing ทุกอันด้านบนคือสิ่งนั้น percept sequence คือทุกอย่างที่รับรู้มาจนถึงตอนนี้ และ simple reflex agent จะละเลยทั้งหมด ยกเว้นรายการล่าสุด

Rationality คือคำที่บทความส่วนใหญ่อธิบายผิด และเมื่อเข้าใจให้ถูก ส่วนที่เหลือของบทนี้จะใช้งานได้ agent ไม่ได้ rational หรือ irrational ในตัวเอง Russell และ Norvig นิยาม rational agent ว่าเป็น agent ที่สำหรับ percept sequence ที่เป็นไปได้แต่ละชุด เลือก action ที่คาดว่าจะ maximize performance measure ของมัน โดยอิงหลักฐานจาก sequence นั้นและความรู้ที่มีติดตัวมา¹ performance measure ไม่ได้อยู่ข้างใน agent: มันเป็นของผู้ออกแบบ และ rationality ถูกนิยามได้เฉพาะเมื่อเทียบกับสิ่งนั้น

สเปกมักเขียนเป็นสี่อย่าง เรียกว่า PEAS: performance measure, environment, actuators, sensors

สังเกตว่าแถวไหนแปลกกว่าเพื่อน ทีมแทบทั้งหมดที่สร้าง agents ในปี 2026 เขียน E, A และ S ลงไป — tool schemas, integrations, รูปแบบข้อความ — เพราะ code จะรันไม่ได้ถ้าไม่มีสิ่งเหล่านี้ แทบไม่มีใครเขียน P หากไม่มีมัน ประโยคว่า "agent ของเราทำงานได้ดี" ก็ไม่มีความหมายที่ใครตรวจสอบได้ และคำว่า "rational" ก็ใช้กับระบบนั้นไม่ได้เลย ใช้ได้แค่กับเดโม บทที่ 29 ว่าด้วยการเปลี่ยน P ให้เป็นตัวเลข และนี่คือเหตุผลที่บทนั้นมีอยู่

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Task environments ยังถูกจัดหมวดตามแกนเจ็ดแกน โดยห้าแกนในนั้นกำหนดความยากส่วนใหญ่ตรงนี้: observable เต็มที่หรือบางส่วน, deterministic หรือไม่, episodic หรือ sequential, static หรือ dynamic, known หรือ unknown¹ agent ที่คุยกับ tool จริงผ่าน network จริง อยู่ในมุมยากของทั้งห้า — non-deterministic แม้ที่ temperature zero (บทที่ 17) และข้อที่ถูกประเมินต่ำไปคือ unknown เพราะคุณไม่มี model ที่เชื่อถือได้ว่า tool ของคุณเองทำอะไรกับโลก นั่นคือเหตุผลที่ loop ในบทที่ 23 ต้องการ error handling มากกว่า planning

พื้นจริงไม่ได้เป็นมิติเดียว ดังนั้นยกระดับโลกเป็นแผนผัง เครื่องหมาย hash คือกำแพง ดอกจันคือฝุ่น และหุ่นยนต์เริ่มในห้องตรงกลาง:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

การอัปเกรดที่ชัดเจนคือ memory agent เก็บแผนที่: ทุกช่องที่มันเคยยืน และทุกช่องที่กันชนทำงาน กฎของมันคือเดินเข้าไปในช่องติดกันที่ยังไม่เคยไป — ขวา แล้วลง แล้วซ้าย แล้วขึ้น — และถอยออกเมื่อทุกอย่างรอบตัวเป็นที่รู้แล้ว นี่คือ model-based reflex agent: มันรักษาสถานะภายในจากประวัติ percept จึงสามารถลงมือตามสิ่งที่ตอนนี้มองไม่เห็นได้

มันดีขึ้นจริง และยังไม่พอ:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

5,000 moves ยังไม่เคยเห็นพื้นครึ่งหนึ่ง แผนที่ถูกต้องและกฎก็ถูกต้อง สิ่งที่ agent ทำไม่ได้คือใช้แผนที่เพื่อไปสักที่: กฎของมันตอบได้แค่ว่า "ฉันควรก้าวไปยังเพื่อนบ้านสี่ช่องช่องไหน" ดังนั้นเมื่อไม่มีช่องที่ยังไม่เคยไปติดกับมันแล้ว มันไม่มีวิธีแสดงความคิดว่า มีช่องที่ยังไม่เคยไปอยู่ห่างออกไปแปด moves และฉันอยากไปยืนตรงนั้น มันรู้ว่าตัวเองอยู่ที่ไหน แต่มันไม่รู้ว่าอยากไปอยู่ที่ไหน

goal-based agent มีคำอธิบายสถานการณ์ที่อยากทำให้เกิดขึ้นวางทับบน model ของโลก และเลือก actions ด้วยการค้นหา sequence ของ actions จนกว่าจะพบ sequence ที่จบตรงนั้น goals เปลี่ยนการเลือก action จาก lookup เป็น search

goal คือ "ไม่มีช่องสกปรกเหลืออยู่" search คือ breadth-first walk ไปยังช่องสกปรกที่ใกล้ที่สุด และ path ที่มันคืนมาคือ plan

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

ยี่สิบเจ็ด moves พื้นสะอาด แต่ดูคอลัมน์แบตเตอรี่และช่วงสุดท้ายของ plan คอลัมน์ 0 ปูพรม: การข้ามช่องปูพรมใช้แบตเตอรี่ 6 หน่วย ช่องกระเบื้องใช้ 1 หน่วย agent กลับบ้านขึ้นคอลัมน์ 0 เพราะนั่นคือ 4 moves แทนที่จะเป็น 8 และ 4 moves บนพรมเหล่านั้นใช้ 24 หน่วย ในขณะที่ทางอ้อม 8 moves จะใช้ 13

มันทำอย่างอื่นไม่ได้ goal เป็นการทดสอบแบบ binary: พื้นสะอาดหรือไม่สะอาด ทุก plan ที่จบด้วยพื้นสะอาดตอบโจทย์เท่ากัน ดังนั้นเมื่อมีหลาย plan ที่สำเร็จ agent ไม่มีอะไรให้ใช้เลือก การชอบความสำเร็จหนึ่งมากกว่าอีกความสำเร็จต้องใช้ตัวเลขเหนือ outcomes และตัวเลขนั้นคือ utility function agent ที่ maximize มันคือ utility-based agent

การเปลี่ยนใน code คือ term เดียวใน search Breadth-first search นับ moves; ทำให้มันนับ cost แทน แล้วคุณก็ได้ Dijkstra's algorithm และ agent คนละตัว:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

เพิ่ม 4 moves แต่ใช้แบตเตอรี่น้อยลง 11 หน่วย: ถูกลง 21 เปอร์เซ็นต์ goal เดิม แผนที่เดิม code เดิมยกเว้น term เดียว agent สองตัวต่างกันเพียงสิ่งที่มันพยายามทำให้ดี และมันเลือกเส้นทางกลับบ้านต่างกัน

นี่เป็นจุดแรกด้วยที่ agent ต้องการบางอย่างที่มันผลิตเองไม่ได้ ต้องมีใครสักคนตัดสินว่าหน่วยแบตเตอรี่หนึ่งหน่วยมีค่าเท่าไรเมื่อเทียบกับ move หนึ่งครั้ง Utility คือ performance measure ที่เขียนในรูปแบบที่ agent คำนวณด้วยได้ และการเขียนมันคือหน้าที่ของผู้ออกแบบ เมื่อคนพูดว่า agent "optimized ผิดสิ่ง" แทบไม่เคยหมายถึง bug พวกเขาหมายถึงบรรทัดนี้ถูกเขียนอย่างไม่ระวัง

ตอนนี้ให้ฝุ่นกลับมา ห้องสี่ห้องสกปรกขึ้นใหม่ด้วยอัตราต่างกันสี่ค่า และ agent ไม่เคยถูกบอกค่าเหล่านั้น มันไปเยี่ยมได้หนึ่งห้องต่อ tick และเห็นเฉพาะห้องนั้น performance measure คือ room-ticks ที่ใช้ไปในสภาพสกปรกตลอด 4,000 ticks — ยิ่งต่ำยิ่งดี

learning agent ตามการแยกส่วนในตำรา คือแบบใดแบบหนึ่งข้างต้นบวกอีกสามส่วน: learning element ที่เปลี่ยน agent, critic ที่บอกว่า agent ทำได้ดีแค่ไหนเทียบกับ performance standard คงที่ และ problem generator ที่เสนอ actions ที่น่าลองเพราะสิ่งที่มันจะสอน¹ สาม policy ใน environment เดียวกัน ตัวแรกไม่เรียนรู้; ตัวที่สองและสามเรียนรู้สิ่งเดียวกันแต่ใช้ต่างกัน

อัตราที่ซ่อนอยู่คือ 0.35 สำหรับครัว, 0.05 สำหรับโถง, 0.02 สำหรับห้องทำงาน และ 0.01 สำหรับห้องใต้หลังคา — และ learner A หาเจอ มันระบุได้ถูกต้องว่าครัวเป็นห้องที่สกปรกที่สุดในบ้าน จากนั้นก็ไปครัวทุก tick ตลอดส่วนที่เหลือของ simulation ขณะที่อีกสามห้องสกปรกค้างอยู่ตลอดไป มันแย่กว่าการไม่เรียนรู้เลยห้าเท่า และมันไม่ได้เสีย

บทเรียนคือบทของ utility learner A maximize "ความน่าจะเป็นที่ห้องที่ฉันกำลังจะไปเยี่ยมสกปรก" performance measure คือ "room-ticks ที่ใช้ไปในสภาพสกปรก" ตัวเลขคนละตัว; ตัวที่สองคือสิ่งที่ critic ให้คะแนน และไม่มีใครบอก agent learner B คูณอัตราที่เรียนรู้มาเดียวกันด้วยเวลานับตั้งแต่การเยี่ยมครั้งล่าสุด — ฝุ่นที่มันคาดว่าจะพบ ไม่ใช่โอกาสที่จะพบฝุ่นใด ๆ — และชนะ patrol ที่มันเริ่มต้นมา

รายละเอียด implementation หนึ่งอย่างตัดสินผลลัพธ์ ใน learner B เวอร์ชันแรก ห้องที่ไม่พบฝุ่นเลยในสามครั้งได้ rate เท่ากับศูนย์เป๊ะ — และศูนย์คูณอะไรก็เป็นศูนย์ ดังนั้นมันจึงไม่เคยถูกเยี่ยมอีก และ estimate ก็ไม่มีวันถูกแก้ การ smooth เศษส่วน successes บวกหนึ่ง หารด้วย trials บวกสอง เปลี่ยน 11,895 เป็น 1,576 "ยังไม่เคย observe" กับ "วัดแล้วออกมาเป็นศูนย์" เป็นคำกล่าวคนละแบบ และระบบที่เก็บสองอย่างนี้ไว้ใน field เดียวกันจะตัดสินใจในแบบที่ย้อนกลับไม่ได้

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

ทั้งห้าประเภทอยู่ใน production วันนี้ภายใต้ชื่ออื่น

สองแถวใกล้กันยิ่งกว่าการเปรียบเทียบ และมันมีต้นทุนเป็นเงิน

chat คือ model-based reflex agent ที่ model ของมันไม่ได้อยู่ภายใน ในตำรา state เป็นตัวแปรภายใน agent program ใน chat มันคือ transcript: มันอยู่ฝั่งคุณ ถูกส่งซ้ำทั้งชุดในทุก call และถูกสร้างใหม่จากศูนย์ภายใน model ทุกครั้ง นั่นคือบิลกำลังสองจากบทที่ 16 และมันคือ object เดียวกับที่ตำราวาดเป็นกล่องติดป้าย "state" นี่คือความต่าง วัดจากคำถาม follow-up หนึ่งคำถาม โดยมีและไม่มีสองข้อความก่อนหน้า:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

model เดียวกัน user input สามคำเหมือนกัน และอันที่สองคือหุ่นทางเดินที่วิ่งชนกำแพง ไม่มี tools ในการรันนั้น ดังนั้นเลข 15 จึงถูกแต่งขึ้น — แต่ state คือสิ่งที่ทำให้ follow-up มีความหมาย คุณสร้างมันใหม่ทุกครั้งและจ่าย input token 2.3× เพื่อมันบนบทสนทนาสอง turn บทที่ 16 วัดแล้วว่า multiplier นั้นไปถึงเท่าไรเมื่อถึง turn ที่สี่สิบ

Reflexion คือ learning agent ที่เปลี่ยน input ของมันแทนที่จะเปลี่ยน program ในการแยกส่วนของตำรา learning element แก้ไข performance element Reflexion ปล่อย weights ไว้เหมือนเดิมและเขียนข้อความสะท้อนคิดลงใน episodic buffer ที่ความพยายามถัดไปจะอ่าน³ learning element คือ prompt, memory คือแถวใน database, performance element คือ model แช่แข็ง — และ diagram ก็คือของตำรา ไม่เปลี่ยน

และนี่คือขีดจำกัดที่ตรงไปตรงมาของการจับคู่ ห้าประเภทจัดหมวด agent program ในปี 2026 program นั้นถูกผ่ากลาง: บางส่วนเป็น code ของคุณ บางส่วนอยู่ใน weights ที่คุณไม่ได้ train เมื่อ model ตัดสินใจเองว่าจะ call tool goal test อยู่ใน program ของคุณหรืออยู่ใน model? อนุกรมวิธานไม่มีคำตอบ เพราะตอนมันถูกเขียน ไม่มีที่อื่นให้มันอยู่ — และคำถามนั้นคือจุดที่สองนิยามสมัยใหม่แยกทางกันพอดี

นิยามทั้งหลายคือข้อถกเถียงเรื่องพฤติกรรม และตัดสินได้ง่ายกว่ามากเมื่อมี trace อยู่ตรงหน้า

loop ด้านล่างส่งบทสนทนาไปยัง model; ถ้าคำตอบมี tool call ก็ execute tool, append ผลลัพธ์ แล้วส่งทั้งหมดอีกครั้ง มันรันกับ Qwen2.5-0.5B-Instruct แบบ local หลัง endpoint รูปทรง OpenAI บนเครื่องนี้ — seam จากบทที่ 14 ดังนั้น loop ไม่รู้และไม่สนใจว่าอะไรอยู่หลัง port

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

สองบรรทัดแบกแนวคิดทั้งหมด และทั้งสองถูกทำเครื่องหมายไว้; ที่เหลือเป็น bookkeeping พฤติกรรมทั้งสามมองเห็นได้ในการรันเดียว เมื่อถามสิ่งที่มันทำเองได้ model ตอบ เมื่อถามสิ่งที่มันทำเองไม่ได้ มัน call:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

และมัน หยุด — พฤติกรรมที่สาม และเป็นพฤติกรรมที่พลาดง่ายที่สุด เพราะดูเหมือนไม่มีอะไรเกิดขึ้น loop จบเพราะ turn 2 กลับมาโดยไม่มี tool call ไม่มีใครตัดสินใจเรื่องนั้น; model ตัดสินใจ โดย emit prose termination condition ของ program นี้คือสัญญาณของการไม่มีอยู่

อีกสองการรันคุ้มพื้นที่ เมื่อถูกขอให้เปรียบเทียบสองเมือง model ออก ทั้งสอง tool calls ใน turn เดียว ได้ค่าทั้งสองกลับมา แล้วเปรียบเทียบผิด:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

tools ทำงาน parallel call ทำงาน loop ทำงาน คำตอบเป็นเท็จ โดยมีตัวเลขที่ถูกต้องทั้งสองค่านั่งอยู่ใน transcript การห่อ model ด้วย loop ไม่ได้ทำให้มัน reason; มันให้ความสามารถแก่ model ที่ผิดในการลงมือตามความผิดนั้น — ซึ่งคือ บทที่ 30 ล่วงหน้า และครึ่งหนึ่งของบทที่ 29

ตอนนี้ลบ return ที่ทำเครื่องหมายไว้ แล้วปล่อยให้ loop รันจนถึง cap แทน คำถามเดิม model เดิม:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

input token สี่เท่า wall clock สี่เท่า และตอนจบที่ agent ลืมไปแล้วว่าถูกถามอะไร และกำลังซักผู้ใช้เกี่ยวกับคำถามที่พวกเขาตอบไปแล้วใน turn แรก คำตอบที่ถูกต้องอยู่บนหน้าจอตั้งแต่ turn 2 และทุก turn หลังจากนั้นทำให้ transcript แย่ลง

ดังนั้น agent ไม่ใช่ loop มันคือ loop บวกกฎสำหรับออกจากมัน และอันนี้มีกฎแบบนั้นอยู่หนึ่งข้อพอดี บทที่ 23 หาได้ห้าข้อ และแสดงว่าอะไรพังเมื่อแต่ละข้อหายไป

ขอยกคำพูดแทนการ paraphrase เพราะ paraphrase คือที่ที่ความสับสนถูกผลิตขึ้น

นิยามที่หนึ่งวางเส้นแบ่งไว้ที่ใครควบคุม flow Building effective agents ของ Anthropic ตั้งชื่อความกำกวมและตัดสินมัน:

"ที่ Anthropic เราจัดหมวดความแปรผันทั้งหมดนี้เป็น agentic systems แต่ขีดเส้นแบ่งเชิงสถาปัตยกรรมที่สำคัญระหว่าง workflows กับ agents: Workflows คือระบบที่ LLMs และ tools ถูก orchestrate ผ่านเส้นทาง code ที่กำหนดไว้ล่วงหน้า ส่วน agents คือระบบที่ LLMs กำกับกระบวนการและการใช้ tool ของตัวเองแบบ dynamic โดยยังคงควบคุมวิธีที่พวกมันทำงานให้สำเร็จ"⁴

การทดสอบคือคำถามเกี่ยวกับ source code ของคุณ: ใครเลือก step ถัดไป? switch ใน program ของคุณ: workflow. model: agent. เอกสารเดียวกันบอกว่า agents "โดยทั่วไปก็แค่ LLMs ที่ใช้ tools ตาม environmental feedback ใน loop" — ซึ่งตรงกับ listing ด้านบนพอดี

นิยามที่สองวางเส้นแบ่งไว้ที่ความเป็นอิสระจากผู้ใช้ A practical guide to building agents ของ OpenAI เปิดหน้าคำนิยามแบบนี้:

"ในขณะที่ซอฟต์แวร์ทั่วไปช่วยให้ผู้ใช้ทำให้ workflows คล่องตัวและ automate ได้ agents สามารถทำ workflows เดียวกันในนามของผู้ใช้ด้วยระดับความเป็นอิสระสูง Agents คือระบบที่ทำงานให้สำเร็จอย่างเป็นอิสระในนามของคุณ"⁵

อีกสองประโยคถัดมา บนหน้าเดียวกัน มันยกเว้นว่า:

"Applications ที่ integrate LLMs แต่ไม่ใช้มันเพื่อควบคุม workflow execution — เช่น simple chatbots, single-turn LLMs หรือ sentiment classifiers — ไม่ใช่ agents"⁵

อ่าน quotation เหล่านั้นตามลำดับ ประโยคเปิดขีดเส้นที่ independence: สิ่งนี้ออกไปทำงานให้เสร็จโดยไม่มีฉันหรือไม่? ประโยคที่สี่ขีดเส้นที่ control of execution ซึ่งเป็นเส้นของ Anthropic พอดี การทดสอบคนละแบบ หน้าเดียวกัน และมีระบบจริงที่สองแบบนี้ให้คำตอบไม่ตรงกัน

ข้างใต้มีการชนกันของคำศัพท์ และมันทำให้เกิดข้อถกเถียงใน meeting จริง ในเอกสารแรก workflow คือสถาปัตยกรรม และเป็นสิ่งที่ ไม่ใช่ agent ในเอกสารที่สอง workflow คือ "sequence ของ steps ที่ต้อง execute เพื่อให้ถึง goal ของผู้ใช้" — คือตัวงานเอง ซึ่ง agent ทุกตัวมีอย่างหนึ่ง "เราแทน workflow ด้วย agent" ฟังรู้เรื่องตามนิยามแรก และแทบไม่มีความหมายตามนิยามที่สอง

สามระบบที่มีอยู่ในปี 2026 ภายใต้ทั้งสองนิยาม

สองในสามเปลี่ยนฝั่ง นั่นไม่ใช่ความล้มเหลวของเอกสารใดเอกสารหนึ่ง มันเป็นคำเตือนเกี่ยวกับ meeting ประเภทหนึ่งที่คนสองคนเห็นด้วยกันหมดว่าระบบทำอะไร แต่ใช้เวลาหนึ่งชั่วโมงถกเถียงว่าจะเรียกมันว่าอะไร

นิยามชนกันเพราะแต่ละนิยามยุบคำถามอิสระสองข้อให้เหลือคำเดียว แยกมันออก แล้วความไม่ลงรอยจะกลายเป็นตาราง ซึ่งมีประโยชน์กว่าคำตัดสิน

นิยามแต่ละแบบโต้แย้งคนละ cell และอีกสอง cell ไม่มีข้อพิพาทเลย ดังนั้นเมื่อ label สำคัญ — ในสัญญา, risk review, postmortem — สองประโยคที่ควรเขียนไม่ใช่ "มันเป็น agent หรือไม่" แต่เป็น ใครเลือก step ถัดไป และ ใครเฝ้าดูอยู่ ทั้งสองตอบได้ด้วยการอ่าน code ไม่ต้องใช้นิยามของใคร และเมื่อรวมกันก็ถือผลลัพธ์ทุกอย่างที่ label เคยยืนแทน

ทั้งหมดนี้ไม่ใช่เรื่องใหม่ Wooldridge และ Jennings สำรวจความหมายแข่งขันของคำว่า "agent" ในปี 1995;⁶ Franklin และ Graesser ถามคำถามเดียวกับบทนี้ในปี 1996 รวบรวมนิยามที่ใช้อยู่ แล้วพบว่ามันไม่เห็นพ้องกัน⁷ survey ปี 2023 ยังนิยาม agents จากหลักการพื้นฐาน — "entities ประดิษฐ์ที่ sense environment ของตน, make decisions, และ take actions"⁸ — เพราะไม่มีสิ่งที่ตกลงกันได้ให้ cite และ CoALA อธิบาย parts แทนที่จะขีดเส้นแบ่งใด ๆ⁹ สามสิบปีของการปฏิเสธที่จะเห็นพ้องบอกว่าคำนี้ทำงานมากกว่าหนึ่งหน้าที่

ตอนนี้มาถึงผลที่มาถึงก่อนปรัชญา ซึ่งก็คือบิล

ทุกการวัดตรงนี้มีรูปทรงเดียวกัน single call ใช้ input token 39; คำถามเดียวกันกับ tool หนึ่งตัวใช้ 420 ในสอง calls; loop ที่ถูกถอด stopping rule ใช้ 1,688 ในหก calls การเติบโตแย่กว่า linear เพราะ turn n แบกทุก turn ก่อนหน้ามาด้วย: คอลัมน์ prompt ของการรันหก turn นั้นอ่านได้เป็น 187, 238, 261, 302, 327, 373 บทที่ 16 derive ว่ายอดรวมคือ $\Theta(n^2)$ และ fit curve บนบทสนทนาจริง agent เปลี่ยนทุกงานให้เป็นบทสนทนานั้น ไม่ว่ามนุษย์จะเคยเห็นมันหรือไม่

ถ้าจำนวน token ที่วัดได้เหล่านั้นถูกส่งไปยัง commercial endpoint ด้วยราคาที่บทที่ 16 อ่านเมื่อ 6 กันยายน 2026 — $2.00 ต่อ input token หนึ่งล้าน และ $12.00 ต่อ output หนึ่งล้าน — การรันทั้งสี่คิดราคาได้แบบนี้:

แถวสองเทียบกับแถวหนึ่งคือเลขที่ควรจำ ต้นทุนเจ็ดเท่าครึ่ง เพื่อคำตอบที่แย่ลงสำหรับคำถามที่ model รู้อยู่แล้ว ไม่มีอะไร misconfigured: มี tool อยู่ model จึงใช้มัน — และข้อค้นพบของบทที่ 18 ว่าราคาของแคตตาล็อก ไม่ใช่ความแม่นของมัน คือสิ่งที่ทำให้เจ็บ มีเดโมที่ถูกที่สุดตรงนี้ด้วยแคตตาล็อกที่มีรายการเดียว

นั่นคือเหตุผลที่ครึ่งที่มีประโยชน์ของเอกสารทั้งสองคือครึ่งที่พูดถึงการไม่สร้างสิ่งนี้ Anthropic พูดตรง: หาทางออกที่ง่ายที่สุดเท่าที่เป็นไปได้ แล้วเพิ่มความซับซ้อนเฉพาะเมื่อจำเป็น ซึ่ง "อาจหมายถึงการไม่สร้าง agentic systems เลย" เพราะ agentic systems "แลก latency และ cost กับ task performance ที่ดีขึ้น" และ "สำหรับ applications จำนวนมาก การ optimize single LLM calls ด้วย retrieval และ in-context examples มักเพียงพอแล้ว"⁴ กรณี ที่ควร ใช้ agent ของมันแคบ: ปัญหา open-ended ที่คุณคาดจำนวน steps ไม่ได้และ hardcode path ไม่ได้ ใน environment ที่คุณไว้ใจ พร้อมยอมรับ "cost ที่สูงขึ้น และโอกาสเกิด compounding errors"⁴ หน้าคัดกรองของ OpenAI เป็นภาพสะท้อนกลับด้าน — judgement ซับซ้อน, rule sets ที่ maintain ไม่ไหว, unstructured data — และจบแบบเดียวกัน: "มิฉะนั้น deterministic solution อาจเพียงพอ"⁵

ดังนั้น ในอนุกรมวิธานของบทนี้: จำนวน steps คงที่ในลำดับคงที่คือ pipeline และการเรียกมันว่า agent จะไม่ทำให้มันเร็วขึ้น ถ้าจำนวน steps ขึ้นกับสิ่งที่คุณพบระหว่างทาง คุณต้องการ loop — และคุณซื้อความยืดหยุ่นนั้นด้วย N calls, transcript กำลังสอง และระบบที่สามารถผิด N ครั้งแทนที่จะผิดครั้งเดียว

ตอนนี้คุณมีอนุกรมวิธาน, นิยามสมัยใหม่ทั้งสอง, สองแกนที่ทำให้มันเข้ากันได้ และ loop สั้น ๆ ที่ตอบ, call และหยุด

loop นั้นมีวิธีจบหนึ่งทาง: model หยุดขอ tools บทที่ 23 ทำให้มันพังโดยตั้งใจเจ็ดครั้ง และแต่ละครั้งเพิ่มชิ้นส่วนหนึ่งเข้าไป งานที่เป็นไปไม่ได้ แล้วมันไม่เคยจบ — turn cap หนึ่งคืนของการรัน แล้วบิลมาถึง — budget เป็นดอลลาร์ tool ที่ล้มเหลว — error ที่ model ลงมือตามได้ call เดิมสองครั้ง — idempotency key ไฟล์ที่มันไม่ควรแตะ — human approval รีสตาร์ตกลางทาง — session persistence tool ที่ใช้เวลาสามนาทีในความเงียบ — progress และ cancellation สิ่งที่ได้ออกมาคือ harness ไฟล์ที่ส่วนที่เหลือของคอร์สนี้รันอยู่บนมัน

ซึ่งทิ้งคำถามที่ diagonal ที่เป็นข้อพิพาทของบทนี้ถามจริง ๆ ไว้ loop ที่ตัดสิน step ถัดไปเองต้องตัดสินใจว่าจะหยุดเมื่อไร และเราเพิ่งเห็นแล้วว่าเกิดอะไรขึ้นเมื่อมันทำไม่ได้: หก turns, บิลสี่เท่า และ agent ที่ซักผู้ใช้เกี่ยวกับคำถามที่มันตอบไปแล้ว Stopping ไม่ใช่ condition เดียว มีกี่อย่าง และอะไร fire ก่อน?

LLM Powered Autonomous Agents (2023) ของ Lilian Weng คือการแยกส่วน language agent ออกเป็น planning, memory และ tool use ที่เป็นที่รู้จักที่สุด และเป็นสิ่งที่ควรอ่านต่อคู่กับเอกสาร vendor สองฉบับ; components สามอย่างของมันคือบทที่ 23, 24 และ 18 ของคอร์สนี้ ตามลำดับ

ตัวเลขทุกตัวในบทนี้ผลิตบนเครื่องนี้และไม่มีอะไรถูก estimate ทางเดิน, แผนผังพื้น, agents สี่ตัวที่เดินมัน และ patrol policies สามแบบ คือ TypeScript ด้านบน รันบน Node 22; ตัวเลขของ randomized agent เป็น means จาก seeded runs อย่างละ 2,000 ครั้ง และตัวเลข patrol เป็น seeded runs เดี่ยว 4,000 ticks model traces มาจาก Qwen2.5-0.5B-Instruct ใน float32 บน CPU ด้วย greedy decoding เสิร์ฟผ่าน loopback โดย local Python endpoint ขนาดเล็กที่โหลด weights และพูดรูปทรง OpenAI chat-completions — seam เดิมอีกครั้ง โดย tensors อยู่ฝั่ง Python และ loop อยู่ฝั่ง TypeScript — ดังนั้น token counts คือ tokenizer ของ model นั้น และ latencies คือของเครื่องนั้น ตัวเลขเดียวที่เอามาจากที่อื่นคือราคาสองค่าบน cost table ซึ่งเป็น rate ที่บทที่ 16 อ่านจากหน้า pricing ของ OpenAI เมื่อ 6 กันยายน 2026 นำมาใช้กับ token counts ที่วัดในเครื่องเพื่อเป็น illustration ไม่ใช่ observed invoice