บทนำ — agent ไม่ใช่เครื่องมือใหม่ แต่คือบทบาทใหม่
ในช่วงสามปีที่ผ่านมา องค์กรไทยส่วนใหญ่ที่เริ่มทดลองใช้ AI agent มักจะตั้งคำถามผิดข้อ ไม่ใช่ "agent ตัวไหนเก่งที่สุด" หรือ "ใช้โมเดลใหญ่ขนาดไหน" — แต่คือ "เราจะรู้ได้อย่างไรว่าตอนไหน agent ควรทำเอง ตอนไหนควรส่งกลับให้คน"
จากการทำงานร่วมกับ 12 ทีมในช่วงสองปี เราพบว่าโครงการที่ล้มเหลวเกือบทั้งหมดมีสาเหตุเดียวกัน — ทีมไม่ได้ออกแบบจังหวะการ handoff ระหว่างคนและ agent อย่างชัดเจน บทความนี้คือกรอบสามชั้นที่เราใช้ภายใน ALEX เพื่อแก้ปัญหานี้
ปัญหา — ทำไม "ใช้ AI ในงาน" ถึงล้มเหลวบ่อย
องค์กรส่วนใหญ่มอง agent เป็น "เครื่องมือฉลาดที่เพิ่มเข้ามา" ผลที่ตามมาคือทีมไม่รู้ว่างานใดควรเริ่มที่ agent งานใดควรเริ่มที่คน และจังหวะใดที่ agent ต้องหยุดและขอความช่วยเหลือ ความไม่ชัดเจนนี้ทำให้:
- คนในทีมไม่ไว้ใจ agent เพราะไม่รู้ว่ามันจะทำอะไรต่อไป
- agent ทำงานเกินขอบเขต จนต้องตามแก้ภายหลัง
- หรือ — agent ขอความช่วยเหลือถี่เกินไป จนหมดประโยชน์
การแก้ปัญหานี้ไม่ใช่การเปลี่ยนโมเดล แต่คือการออกแบบบทบาทใหม่ในทีม — เหมือนการรับพนักงานใหม่เข้ามา เราต้องบอกชัดเจนว่างานนี้คุณตัดสินใจเองได้ งานนั้นต้องขออนุมัติก่อน
กรอบสามชั้น — Assist, Propose, Decide
เราแบ่งงานของ agent ออกเป็นสามชั้นตามระดับ autonomy คนในทีมและผู้บริหารต้องเห็นพร้อมกันว่างานนี้อยู่ชั้นไหน — ไม่มีงานใดที่ "อยู่ระหว่างชั้น"
ชั้น 1 · Assist — คนนำ agent ช่วย
ชั้นนี้ agent เป็นเพียงผู้ช่วย คนเป็นผู้ลงมือทำงานหลัก agent ให้ข้อมูล สรุปบริบท หรือเสนอตัวเลือก แต่ไม่ได้ทำงานนั้นเอง ตัวอย่าง: ระบบสรุปอีเมล ระบบแนะนำเอกสารที่เกี่ยวข้อง การค้นหาแบบ semantic
งานที่ความผิดพลาดของ agent ไม่สามารถสร้างผลกระทบโดยตรงต่อภายนอกได้ — เพราะคนยังต้องเป็นผู้กดส่ง อนุมัติ หรือลงนาม
ชั้น 2 · Propose — agent ร่าง คนตัดสิน
ชั้นนี้ agent ทำงานเสนอ ร่างผลลัพธ์ขั้นต้น และส่งให้คนตรวจสอบก่อนนำไปใช้ ตัวอย่างที่ชัดเจนคือ Sapien WRITE — agent ร่างเล่มหลักสูตรใหม่ แต่อาจารย์ผู้รับผิดชอบเป็นคนตรวจและอนุมัติ
จุดสำคัญของชั้นนี้คือ agent ต้องอธิบายเหตุผลของตัวเองได้เสมอ ไม่ใช่แค่ส่งร่างมา แต่ต้องบอกได้ว่า "ฉันร่างแบบนี้เพราะเอกสารอ้างอิงตัวที่ 3 ระบุว่า…"
ชั้น 3 · Decide — agent ตัดสินใจเอง คนตรวจเป็นระยะ
ชั้นนี้ agent ตัดสินใจและลงมือทำงานได้เอง ภายในขอบเขตที่กำหนดไว้ล่วงหน้า คนเข้ามาตรวจเป็นรายเดือนหรือรายไตรมาส ไม่ใช่รายครั้ง — เช่น การจัดหมวดหมู่เอกสาร การส่งการตอบกลับ FAQ ที่มีคำตอบยืนยันแล้ว
งานจะอยู่ที่ชั้น Decide ได้ต่อเมื่อมี "ขอบเขตที่กำหนดได้ชัด" และ "audit trail ที่ตามย้อนได้ทุกครั้ง" ถ้าขาดข้อใดข้อหนึ่ง — งานต้องอยู่ที่ Propose
สี่ pilot ที่ใช้กรอบนี้
ระหว่างปี 2024–2025 เราใช้กรอบนี้ออกแบบ 4 โครงการ pilot ในองค์กรที่มีลักษณะต่างกัน — มหาวิทยาลัย โรงพยาบาล สำนักงานราชการ และบริษัทเอกชน ทั้งหมดเริ่มต้นด้วย workshop หนึ่งวันเพื่อจัดงานเข้าสามชั้น
สิ่งที่น่าสนใจคือ 68% ของงานที่ถูกจัดไว้ที่ชั้นใดชั้นหนึ่งในตอนแรก ถูกย้ายชั้นภายใน 90 วัน — ส่วนใหญ่ย้ายลง จาก Decide ไป Propose เมื่อทีมพบว่าขอบเขตยังไม่ชัดพอ
สิ่งที่เราเรียนรู้
1. การจัดชั้นเป็นการตัดสินใจร่วม ไม่ใช่งานของวิศวกร ทีมงาน ผู้บริหาร และผู้ใช้ปลายทางต้องร่วมตกลงพร้อมกัน
2. เริ่มที่ชั้นต่ำเสมอ ทุก pilot ของเราเริ่มที่ Assist หรือ Propose ก่อน ไม่มีใครเริ่มที่ Decide
3. การย้ายชั้น "ลง" คือสัญญาณที่ดี หมายถึงทีมเห็นข้อจำกัดของ agent ชัดขึ้น ไม่ใช่ความล้มเหลว
4. audit trail ต้องออกแบบก่อน deploy ไม่ใช่ตามหลัง เพราะถ้ายังไม่มี ทีมจะไม่กล้าย้ายงานขึ้นชั้น Decide
"agent ที่ดี ไม่ใช่ agent ที่ตัดสินใจได้เก่ง แต่คือ agent ที่รู้ว่าเมื่อไหร่ควรหยุด"
— จากบันทึก workshop กับโรงพยาบาลแห่งหนึ่ง
ก้าวต่อไป
ในไตรมาสถัดไป เรากำลังทดลอง "ชั้น 2.5" — ระดับที่ agent เสนอ ลงมือทำ และแจ้งคน หลัง action เกิดขึ้นแล้ว ภายในขอบเขตจำกัด เพื่อลด latency ในงานที่คนตรวจซ้ำซากเกินไป กรอบเต็มจะถูกเผยแพร่เป็น whitepaper ในปลายปีนี้
หากองค์กรของคุณกำลังออกแบบโครงการ agent — เราเปิดให้นัดคุยฟรี 30 นาที เพื่อช่วยจัดงานเข้าสามชั้นในตอนเริ่มต้น