เริ่มจากเช้าวันจันทร์หนึ่งวัน
คำว่า “Agent” เข้ามาในห้องประชุม
“ถ้าเรามี AI Agent รับออเดอร์แทนคนได้เลย ทีมจะไม่ต้องเสียเวลาคีย์ข้อมูลอีกใช่ไหม?”
กรรมการผู้จัดการถามหลังเห็นการสาธิตจากผู้ขายซอฟต์แวร์ ฝ่ายขายพยักหน้าเพราะอยากตอบลูกค้าให้เร็วขึ้น ฝ่าย IT เริ่มนึกถึงสิทธิ์ใน ERP ส่วน Finance ถามทันทีว่า “แล้วใครอนุมัติเครดิต?”
ทุกคนกำลังพูดถึงระบบเดียวกัน แต่ในใจนึกถึงคนละอย่าง คนหนึ่งเห็น Chatbot คนหนึ่งเห็นระบบอ่านเอกสาร และอีกคนเห็นพนักงานดิจิทัลที่ทำงานเองตั้งแต่ต้นจนจบ
นี่คือเหตุผลที่บทแรกต้องเริ่มจากการแยกคำ ไม่ใช่เพื่อสอบศัพท์ แต่เพื่อให้คนในห้องตกลงกันได้ว่าเรากำลังมอบหมาย งานอะไร และมอบ อำนาจแค่ไหน ให้ระบบ
เมื่อจบบทนี้ คุณจะไม่ได้เพียงจำคำนิยามสามคำ แต่จะมองงานหนึ่งชิ้นแล้วอธิบายได้ว่าเหตุใดควรใช้ Automation, Copilot, Agent หรือยังควรให้คนทำเอง พร้อมระบุจุดที่ระบบต้องหยุดและคืนการตัดสินใจให้มนุษย์
ภาพใหญ่ก่อนลงรายละเอียด
Agent ไม่ใช่ขั้นสูงสุดที่ทุกงานต้องไปให้ถึง
ลองนึกถึงสายพานในโรงงาน ผู้ช่วยที่นั่งข้างโต๊ะ และพนักงานที่ได้รับมอบหมายให้ไปปิดงาน ทั้งสามแบบทำให้งานเร็วขึ้นเหมือนกัน แต่ทำงานคนละลักษณะ สายพานเดินตามทางที่วางไว้ ผู้ช่วยเสนอทางเลือกให้คน ส่วนพนักงานรับเป้าหมายแล้วตัดสินใจว่าจะเดินไปหาใคร ใช้เครื่องมืออะไร และเมื่อไรควรกลับมาถามหัวหน้า
Automation, Copilot และ Agent ก็แตกต่างกันในทำนองนี้ และไม่ได้เรียงจาก “ล้าสมัย” ไป “ทันสมัย” งานที่มีกฎชัดมักเหมาะกับ Automation เพราะเร็ว ถูก และคาดการณ์ได้ การใช้ Agent กับงานแบบนั้นอาจแพงขึ้น ช้าลง และตรวจยากขึ้นโดยไม่ได้สร้างคุณค่าเพิ่ม
OpenAI อธิบาย Agent ว่าเป็นระบบที่ทำงานแทนผู้ใช้ได้อย่างเป็นอิสระระดับหนึ่ง จัดการลำดับงาน เลือกเครื่องมือ และรู้ว่าเมื่อใดควรหยุดหรือส่งคืนให้คน [1] ขณะที่ Anthropic แยก Workflow ซึ่งเดินตามเส้นทางที่กำหนดไว้ ออกจาก Agent ซึ่งเลือกกระบวนการและเครื่องมือแบบพลวัต และแนะนำให้เริ่มจากวิธีที่ง่ายที่สุดก่อนเพิ่มความซับซ้อน [2]
ความหมายในทางปฏิบัติคือ อย่าถามว่า “ทำ Agent ได้ไหม” เป็นคำถามแรก ให้ถามว่า “งานนี้ต้องการอิสระในการเลือกทางเดินจริงหรือไม่” เพราะทุกระดับของอิสระมาพร้อมต้นทุน การรอผล ความไม่แน่นอน และภาระในการกำกับดูแล
งานชิ้นเดียวกัน แต่อำนาจที่มอบให้ระบบไม่เท่ากัน
“ทำตามกติกานี้”
เส้นทางถูกกำหนดไว้ล่วงหน้า ระบบทำซ้ำได้เร็วและตรวจผลได้ตรงไปตรงมา
“ช่วยฉันคิดและร่าง”
AI ช่วยอ่าน สรุป หรือสร้างร่างแรก แต่คนยังถือพวงมาลัยในแต่ละรอบ
“รับเป้าหมายนี้ไปจัดการ”
ระบบเลือกขั้นตอนและเครื่องมือจากสถานการณ์ ภายใต้สิทธิ์ จุดหยุด และการตรวจของคน
ทำความเข้าใจผ่านงานจริง
ลองให้ทั้งสามแบบช่วยงานเดียวกัน
สมมติว่าลูกค้าส่งใบสั่งซื้อเข้ามาทางอีเมล งานหนึ่งรายการต้องอ่านไฟล์ ตรวจรหัสสินค้า เช็กเครดิต ดูสต็อก สร้าง Order และตอบกลับลูกค้า หากพูดรวม ๆ ว่า “ให้ AI รับออเดอร์” เราจะมองไม่เห็นว่าข้างในมีงานต่างชนิดกันหลายชิ้น
AUTOMATION · งานที่ทางเดินนิ่ง
ตรวจว่าช่องข้อมูลบังคับครบหรือไม่
กฎเขียนได้ชัด: ต้องมี Customer ID, SKU, จำนวน และวันที่ต้องการ หากช่องใดว่างให้ย้ายรายการไปคิว “ข้อมูลไม่ครบ” ระบบไม่ต้องตีความเจตนา ไม่ต้องเลือกเครื่องมือ และไม่ต้องคิดว่าจะทำอะไรต่อ
ทดสอบง่าย ๆ: ถ้าคุณเขียนเป็นประโยค “ถ้า…ให้…” ได้เกือบทุกกรณี และข้อยกเว้นมีน้อย ให้เริ่มจาก Automation
COPILOT · งานที่ต้องใช้ภาษา
ร่างอีเมลขอข้อมูลที่ขาด
ลูกค้าแต่ละรายเขียนไม่เหมือนกัน Copilot ช่วยอ่านบริบทและร่างข้อความให้สุภาพได้ แต่พนักงานยังตรวจชื่อ รายการที่ขาด และน้ำเสียงก่อนกดส่ง AI ช่วยลดงานหน้ากระดาษ โดยไม่ได้รับสิทธิ์สื่อสารแทนบริษัทเอง
ทดสอบง่าย ๆ: ถ้างานจบลงที่ “ร่าง”, “ข้อเสนอ” หรือ “สรุปให้คนพิจารณา” และคนยังตัดสินใจทุกครั้ง นี่คือ Copilot
AGENT · งานที่ต้องเลือกทางเดิน
เตรียม Draft Order จากหลายระบบ
หลังอ่านเอกสาร ระบบต้องเลือกว่าจะค้นลูกค้าก่อนหรือถามข้อมูลเพิ่ม ต้องเรียก Product Master, Credit Service และ Inventory API จากนั้นประเมินว่ารายการนี้เดินต่อได้หรือควรส่งให้ใคร นี่คือจุดที่พฤติกรรมเริ่มเป็น Agent เพราะเส้นทางไม่ได้ตายตัวเหมือนกันทุก Order
ทดสอบง่าย ๆ: ถ้าระบบต้องดูผลจากขั้นก่อนหน้า แล้วเลือกเครื่องมือหรือขั้นถัดไปเองหลายรอบ Agent อาจมีเหตุผล—แต่ต้องมีขอบเขตอำนาจ
เปิดฝากระโปรงดูการทำงาน
Agent ต่างจาก “ถามแล้วตอบ” ตรงที่มันมีวงจร
Chatbot ทั่วไปได้รับคำถามแล้วส่งคำตอบกลับ ส่วน Agent ต้องรักษาสถานะของงานและวนทำจนถึงเงื่อนไขหยุด การวนไม่ได้แปลว่าปล่อยให้ทำไปเรื่อย ๆ แต่หมายถึงทุกครั้งที่ลงมือ ระบบต้องสังเกตผลใหม่และตัดสินใจอย่างมีขอบเขตว่าจะทำอะไรต่อ
วงจรของ Agent ในคำสั่งซื้อหนึ่งรายการ
ส่วนประกอบที่มักถูกมองข้าม
บอกผลลัพธ์ที่ต้องการ ไม่ใช่คำสั่งกว้างว่า “ดูแลออเดอร์ทั้งหมด”
กำหนดแหล่งข้อมูล ขั้นบังคับ ข้อห้าม และเงื่อนไขส่งต่อ
API หรือระบบที่ Agent ใช้อ่านข้อมูลและลงมือทำ โดยให้สิทธิ์เท่าที่จำเป็น
รู้ว่าทำขั้นไหนแล้ว ใช้ข้อมูลเวอร์ชันใด และกำลังรออะไร
เก็บผล Lookup เหตุผล เส้นทางที่เลือก และผู้อนุมัติให้ตรวจย้อนหลังได้
จำกัดเวลา จำนวนรอบ มูลค่า และสถานการณ์ที่ต้องคืนงานให้คน
Autonomy Budget: ให้กุญแจเท่าที่งานต้องใช้
ลองคิดว่า Agent เป็นพนักงานใหม่วันแรก เราคงไม่ยื่นกุญแจทุกห้อง บัตรเครดิตบริษัท และสิทธิ์อนุมัติวงเงินให้ทันที เราจะบอกว่างานของเขาคืออะไร ให้เข้าถึงข้อมูลชุดไหน อนุญาตให้ทำรายการชนิดใด และเมื่อพบข้อยกเว้นต้องถามใคร
กล่อง Order, Product Master, สถานะเครดิตและสต็อกเท่าที่จำเป็น
สร้าง Draft Order, ติดป้าย Exception และร่างข้อความภายใน
แก้ราคา อนุมัติเครดิต ยืนยัน Order หรือส่งข้อความหาลูกค้าเอง
ข้อมูลขัดแย้ง API ล่ม เกินวงเงิน หรือพบเงื่อนไขนอก Policy
NIST แนะนำให้องค์กรแยกบทบาทและความรับผิดชอบของคนกับ AI ให้ชัด รวมทั้งกำหนด Human Oversight ตามบริบท [3] ส่วนแนวทาง ETDA ชี้ถึงความไม่แน่นอนของผลลัพธ์ Generative AI และความจำเป็นของการมีส่วนร่วมของมนุษย์ [4] ดังนั้นคำว่า “มีคนตรวจ” ต้องลงรายละเอียดต่อว่าใครตรวจ เห็นอะไร และมีเวลาตัดสินใจจริงหรือไม่
FICTIONAL RUNNING CASE · ข้อมูลสมมติ
ตามออเดอร์หนึ่งใบ ตั้งแต่อีเมลถึง ERP
ต่อไปนี้เป็นสถานการณ์สมมติของสยามโฟลว์ ไม่ใช่ผลลัพธ์จากลูกค้าจริง เราจะจงใจใส่รายละเอียดที่ทำให้เส้นทางไม่ตรงไปตรงมา เพราะงานจริงแทบไม่เคยเรียบร้อยเหมือน Demo
- จาก
- purchasing@baanmai-example.co.th
- เรื่อง
- PO-7841 — ขอแบ่งส่งสองคลัง
เรียนฝ่ายขาย รบกวนจัดส่งปั๊มรุ่น PX-20 จำนวน 18 ตัว โดย 10 ตัวส่งสมุทรปราการภายในวันศุกร์ ที่เหลือส่งคลังชลบุรีสัปดาห์หน้า ราคาขอใช้ตามใบเสนอราคาเดือนก่อน แนบ PO มาให้ค่ะ
Automation ตรวจสิ่งที่แน่นอน
ระบบรับอีเมล บันทึก Message ID ตรวจชนิดไฟล์ และเช็กว่ามี Customer ID, SKU, จำนวน และสถานที่ส่งครบหรือไม่ งานเหล่านี้ไม่ต้องให้โมเดลเลือกทางเดินเอง
Copilot ช่วยแปลภาษางานให้เป็นข้อมูล
ข้อความ “ราคาตามใบเสนอราคาเดือนก่อน” ยังไม่ใช่รหัส Quote Copilot ช่วยสรุปว่าต้องหาใบเสนอราคาก่อนหน้า และแยกการส่งเป็นสอง Destination แต่ยังไม่ถือว่าข้อมูลนั้นถูกต้องจนกว่าจะตรวจจากระบบหลัก
Agent เลือกว่าจะตรวจอะไรต่อ
Agent ค้น Customer Master จากข้อมูลใน PO จากนั้นค้น Quote ที่ยังมีผล ตรวจ SKU และ Stock แยกตามคลัง เมื่อพบว่า Quote หมดอายุไปสามวัน จึงไม่สร้าง Draft ต่อและส่งรายการให้ Sales Operations พร้อม Quote ID วันหมดอายุ และผลสต็อก
คนรับผิดชอบข้อยกเว้น
Sales Operations เห็นหลักฐานครบและเลือกว่าจะขออนุมัติใช้ราคาเดิมหรือออก Quote ใหม่ Agent ไม่ควรตีความเองว่าลูกค้ารายนี้ “สำคัญพอ” ที่จะยกเว้น Policy
ออเดอร์ใบเดียวใช้ Automation, Copilot, Agent และมนุษย์ร่วมกัน ไม่มีเหตุผลต้องเลือกคำเดียวครอบทั้งกระบวนการ สิ่งที่ทีมออกแบบคือการส่งต่องานและอำนาจระหว่างแต่ละฝ่ายให้พอดี
DECISION WALKTHROUGH
ถ้ามีงานอยู่ตรงหน้า จะเลือกอย่างไร?
ลองใช้ตัวอย่าง “ตรวจเอกสารผู้ขายก่อนต่ออายุสัญญา” แทนการกระโดดไปเลือกเครื่องมือ เราจะถามทีละคำถามและยอมรับว่าหนึ่งกระบวนการอาจได้หลายคำตอบ
กฎชัดพอจะเขียนเป็นเงื่อนไขหรือไม่?
ตรวจวันหมดอายุหนังสือรับรอง ตรวจว่ามีเอกสารบังคับครบ และเตือนก่อนหมดอายุ 30 วัน—ส่วนนี้เป็น Automation ได้ เพราะเกณฑ์ชัดและตรวจผลตรง ๆ
ต้องอ่านภาษาหรือสรุปข้อมูลให้คนหรือไม่?
สรุปเงื่อนไขประกัน ความคุ้มครอง และข้อยกเว้นจากเอกสารหลายหน้า—ให้ Copilot ทำร่างสรุปพร้อมอ้างหน้าต้นทาง แล้วเจ้าหน้าที่ตรวจ
ต้องเลือกเครื่องมือและทางเดินตามสิ่งที่พบหรือไม่?
ถ้าเอกสารขาด ให้ค้นประวัติการติดต่อ เปิด Ticket และเลือกผู้รับผิดชอบตามประเภทผู้ขาย—Agent แบบจำกัดอาจเหมาะ เพราะลำดับงานเปลี่ยนตามสถานะ
การตัดสินใจมีผลผูกพันหรือกระทบสูงหรือไม่?
อนุมัติต่อสัญญา ระงับผู้ขาย หรือยอมรับข้อยกเว้น—ให้ Procurement Owner และ Legal ตัดสินใจ ระบบควรรวบรวมข้อมูล ไม่ใช่รับความรับผิดชอบแทน
ไม่ใช่ “สร้าง Vendor Agent หนึ่งตัว” แต่เป็น Automation สองจุด, Copilot หนึ่งจุด, Agent แบบจำกัดหนึ่งช่วง และ Human Decision หนึ่ง Gate
สัญญาณว่า “ยังไม่ต้องใช้ Agent”
งานมีขั้นตายตัวและกฎครอบคลุมเกือบทุกกรณี
AI ทำเพียงตอบคำถามหรือร่างข้อความหนึ่งครั้งแล้วจบ
ยังไม่มี System of Record หรือข้อมูลที่เชื่อถือให้ตรวจผล
ทีมยังตอบไม่ได้ว่าใครรับงานเมื่อระบบไม่แน่ใจ
TRY IT WITH YOUR ORGANIZATION
อย่าเริ่มจากทั้งองค์กร เริ่มจากเช้าวันหนึ่ง
เลือกเหตุการณ์จริงที่เกิดซ้ำ เช่น อีเมลลูกค้าเข้ามา ใบแจ้งหนี้ถูกส่งถึง Finance หรือพนักงานยื่นคำขอหนึ่งเรื่อง แล้วตามงานชิ้นนั้นจนจบ อย่าเพิ่งเขียนชื่อผลิตภัณฑ์ AI
- เลือกกระบวนการหนึ่งที่มีเจ้าของชัดและเกิดซ้ำอย่างน้อยทุกสัปดาห์
- แบ่งงานเป็นขั้น แล้วทำเครื่องหมายว่าเป็นกฎตายตัว งานช่วยคิด หรืองานหลายขั้นที่ต้องเรียกใช้เครื่องมือ
- ระบุผลกระทบสูงสุดหากระบบทำผิด และกำหนดว่าจุดใดต้องให้คนอนุมัติ
- ลงรายการในแท็บ Business Problem และ Use Case Portfolio ของ Workbook
คำขอเปลี่ยนที่อยู่จัดส่งหลังออกใบกำกับสินค้า
- Automation
- ตรวจเลข Order และสถานะว่าจัดส่งแล้วหรือยัง
- Copilot
- ร่างข้อความอธิบายทางเลือกให้เจ้าหน้าที่ใช้ตอบลูกค้า
- Agent
- ถ้ายังไม่จัดส่ง ให้ดึงข้อมูลจาก Order และสร้าง Change Request แบบ Draft
- Human Gate
- เจ้าหน้าที่ตรวจตัวตน ที่อยู่ใหม่ และผลต่อเอกสารภาษีก่อนอนุมัติ
- เหตุผล
- การแก้ที่อยู่แตะหลายระบบ แต่มีผลด้านการส่งสินค้าและเอกสาร จึงไม่ควรให้ Agent ยืนยันเอง
สิ่งที่ควรได้ ไม่ใช่สิ่งที่ควรกรอกให้ครบ
จบบทนี้แล้ว คุณควรอธิบายแผนที่ของตัวเองได้
แผนที่โอกาส AI 3–5 เรื่อง พร้อมเหตุผลและขอบเขตอำนาจของแต่ละงาน
- รายการโอกาส 3–5 เรื่อง
- ประเภท Automation/Copilot/Agent
- Owner และผลลัพธ์ที่ต้องการ
- Autonomy Boundary เบื้องต้น
หากรายการที่เลือกทุกเรื่องลงท้ายว่า “Agent” ให้กลับไปดูอีกครั้งว่าเรากำลังเลือกระดับต่ำที่สุดที่แก้ปัญหาได้ดีหรือกำลังไล่ตามชื่อเทคโนโลยี
ลองประเมิน Digital Readiness →หยุดคิดก่อนเปิดบทถัดไป
สามคำถามที่ควรถามในห้องประชุม
- ระบบกำลังช่วยเสนอ หรือกำลังลงมือแทนองค์กร—และทุกคนเข้าใจตรงกันหรือยัง?
- ถ้าระบบเลือกทางผิดหนึ่งครั้ง เราหยุด ย้อนกลับ และอธิบายเหตุการณ์ได้หรือไม่?
- มีจุดไหนที่ Automation ธรรมดาจะทำงานได้ถูกกว่า เร็วกว่า และดูแลง่ายกว่า?
Agent ไม่ใช่ปลายทางของทุกงาน คุณค่ามาจากการแบ่งงานให้ถูกระดับ: กฎให้ Automation, ร่างและการคิดร่วมให้ Copilot, งานหลายขั้นที่ต้องปรับทางเดินให้ Agent และ Judgement ที่มีผลกระทบสูงให้มนุษย์รับผิดชอบ
อาการที่บอกว่าทีมกำลังรีบเกินไป
- เรียกทุก Chatbot ว่า Agent
- เริ่มจากผลิตภัณฑ์ที่ซื้อไว้แทนปัญหาธุรกิจ
- ให้สิทธิ์ทำรายการจริงก่อนรู้ Failure Mode
อ่านต่อจากแหล่งต้นทาง
ที่มาของแนวคิดในบทนี้
- ETDA/AIGC — แนวทางการประยุกต์ใช้ Generative AI อย่างมีธรรมาภิบาลสำหรับองค์กร ↗
- NIST — AI Risk Management Framework ↗
- OpenAI — A practical guide to building agents ↗
- Anthropic — Building effective agents ↗
ตรวจสอบแหล่งอ้างอิงล่าสุดเมื่อ 17 กันยายน 2569 · กรณีสยามโฟลว์และแบบฝึกเป็นงานต้นฉบับของ ThinkToFinish และเป็นข้อมูลสมมติทั้งหมด