6 ระดับของ AI Autonomy: จากผู้ช่วย AI สู่ระบบที่ทำงานได้ด้วยตัวเอง

คำว่า “AI agent” ถูกใช้กว้างมาก ตั้งแต่แชตบอตที่ช่วยร่างอีเมล ไปจนถึงระบบที่วางแผน เรียกใช้เครื่องมือ ตรวจผล แก้ความล้มเหลว และเดินงานต่อเอง ความคลุมเครือนี้ทำให้ทีมคุยกันคนละเรื่อง และบางครั้งทำให้ความสามารถของผลิตภัณฑ์ถูกประเมินสูงกว่าหลักฐานจริง

SXP จึงสร้าง SXP AI Autonomy Framework เพื่อถามคำถามที่ใช้งานได้ตรงกว่าเดิมว่า

ระบบนี้รับผิดชอบการดำเนินงานได้มากแค่ไหนอย่างปลอดภัย?

กรอบนี้เป็น taxonomy ที่ SXP สร้างขึ้น โดยนำแนวคิดจากงานวิศวกรรมระบบ ความน่าเชื่อถือ การประเมิน AI และการกำกับดูแลที่เป็นที่ยอมรับมาประกอบ กรอบนี้ ไม่ใช่มาตรฐานสากลของ ISO, NIST หรืออุตสาหกรรม และไม่ใช่ใบรับรอง

ก่อนดูระดับ ต้องแยกสามคำให้ชัด

Automation ไม่เท่ากับ autonomy ระบบอัตโนมัติอาจทำตามลำดับเดิมได้เร็วและสม่ำเสมอ แต่ไม่ได้แปลว่าระบบเลือกการกระทำจากสถานการณ์ ตรวจว่าผลดีพอ หรือฟื้นตัวเมื่อเกิดปัญหาได้

Agent ไม่เท่ากับ agentic system เอเจนต์หนึ่งตัวอาจเลือกเครื่องมือเพื่อจบงานหนึ่งครั้งได้ แต่ระบบ agentic ที่พร้อมรับงานจริงต้องมีสถานะถาวร สัญญางาน จุดตรวจคุณภาพ การจำกัดสิทธิ์ ประวัติการทำงาน การ retry และการส่งต่อให้มนุษย์ที่ชัดเจน

Autonomy ไม่เท่ากับคุณภาพผลิตภัณฑ์ เว็บไซต์ที่ทำงานเรียบง่ายอาจเป็นผลิตภัณฑ์ระดับสูงมาก แม้ autonomy ต่ำ ขณะเดียวกันเดโมที่ปล่อยเอเจนต์ทำงานเองอาจยังไม่พร้อมให้ผู้ใช้จริงแตะเลย

L1–L6: ความรับผิดชอบเพิ่มขึ้น ไม่ใช่คะแนนความฉลาด

L1 — AI Assistant

AI ช่วยคนทำงาน มนุษย์เป็นผู้เริ่มงาน ป้อนบริบท ตัดสินว่าคำตอบใช้ได้หรือไม่ และลงมือขั้นต่อไป ตัวอย่างเช่น ให้โมเดลช่วยสรุปเอกสารหรือร่างข้อความ แล้วคนตรวจและนำไปใช้

L1 มีคุณค่าอย่างมาก เพียงแต่ความรับผิดชอบของการดำเนินงานยังอยู่กับมนุษย์

L2 — AI Workflow

งานเดินตามเส้นทางที่กำหนดไว้ซ้ำได้ อาจเริ่มด้วยปุ่ม ตารางเวลา หรือเหตุการณ์ ระบบรู้ว่าจะเรียกขั้นตอนไหนต่อ มีผลลัพธ์ที่ทำซ้ำได้ และมีพฤติกรรมเมื่อผิดพลาดที่ชัดเจน

ตัวอย่างเช่น งานวิเคราะห์รายสัปดาห์ที่ดึงข้อมูล ตรวจความสด สร้างผลสรุป และส่ง LINE ตามลำดับเดิม AI อาจอยู่ในบางขั้น แต่ตัว orchestration ยังถูกกำหนดด้วยโค้ด

L3 — Tool-Using Agent

เอเจนต์ได้รับเป้าหมายที่มีขอบเขต มองสถานะ เลือกเครื่องมือหรือการกระทำที่ได้รับอนุญาต ตรวจผลขั้นต่ำ และหยุดตามเงื่อนไขที่กำหนด หลักฐานสำคัญไม่ใช่แค่มีโค้ดเรียกเครื่องมือ แต่ต้องเห็นวงจร inspect → act → observe เกิดขึ้นจริง

ระดับนี้ต้องมี guardrail เพราะความสามารถในการเลือกการกระทำคือจุดที่ระบบเริ่มมีอำนาจมากกว่างานอัตโนมัติทั่วไป

L4 — Agentic System

ระบบเป็นเจ้าของ workflow ไม่ใช่แค่เอเจนต์หนึ่ง session ต้องมีสถานะที่เป็นแหล่งอ้างอิงถาวร สัญญางานแบบมีโครงสร้าง gate ที่บล็อกผลเสียได้ การจำแนกข้อผิดพลาด retry แบบมีขอบเขต audit trail การจำกัดสิทธิ์ escalation และการ resume จากหลักฐานเดิม

แบบทดสอบง่าย ๆ คือ ถ้าเปลี่ยนโมเดล เปลี่ยนเอเจนต์ หรือปิด session กลางทาง งานปกติยังเดินต่อจากสถานะที่เชื่อถือได้หรือไม่ ถ้ายังต้องให้คนกลับมาเล่าเรื่องทั้งหมดใหม่ ระบบยังไม่ใช่ L4 ที่พิสูจน์แล้ว

L5 — AI Control Plane

ระบบไม่ได้แค่ทำ workflow แต่จัดการ AI และเครื่องมือเป็นทรัพยากร มันเลือกว่าจะใช้โค้ด deterministic, cache, structured data, โมเดลราคาต่ำ โมเดลที่เก่งกว่า เครื่องมือ หรือ worker ใด ตามลักษณะงาน คุณภาพที่วัดได้ ต้นทุน นโยบาย และสถานะจริง

จำนวนเอเจนต์ไม่ใช่หลักฐาน L5 การมีสิบเอเจนต์ที่เดินตาม routing แบบคงที่ยังไม่ใช่ control plane หากผลการประเมินไม่สามารถเปลี่ยนเส้นทางหรือเลือกทรัพยากรใหม่ได้

L6 — Autonomous Operation

มนุษย์กำกับเป้าหมาย นโยบาย และเหตุการณ์ผิดปกติ ส่วนระบบดูแลงานประจำอย่างต่อเนื่อง ตรวจพบปัญหา วินิจฉัย ฟื้นตัว ตรวจผล และเดินหน้าต่อภายใต้ budget, quality objective, rollback ที่ทดสอบแล้ว และ approval gate สำหรับการกระทำความเสี่ยงสูง

หลักฐาน L6 ต้องมาจากการดำเนินงานจริงซ้ำ ๆ และประวัติเหตุขัดข้อง ไม่ใช่การปล่อย Codex ทำงานข้ามคืนหนึ่งครั้ง การซ่อมบั๊กโดยเอเจนต์ใน session ยังเป็นงานพัฒนา ไม่ใช่หลักฐานว่าระบบ production ฟื้นตัวได้เอง

Product Readiness R0–R5 เป็นอีกแกนหนึ่ง

SXP ใช้ระดับความพร้อมผลิตภัณฑ์แยกต่างหาก:

• R0 Concept — มีแนวคิด แต่ยังไม่มีผลิตภัณฑ์ที่ทำงานน่าเชื่อถือ
• R1 Prototype — พิสูจน์แกนของแนวคิดแล้ว แต่ยังไม่ dependable
• R2 Functional — workflow หลักใช้ได้และมี QA พื้นฐาน ยังเหมาะกับผู้พัฒนา
• R3 User Trial — ผู้ใช้เป้าหมายทดลองได้ผ่านเส้นทางและข้อจำกัดที่ชัดเจน
• R4 Production — มี release, rollback, monitoring, security และ quality ที่เหมาะกับ production
• R5 Proven / Mature — มีประวัติใช้งานจริงซ้ำ คุณภาพคงที่ และ feedback ที่วัดได้

ดังนั้น R5 / L2 อาจเป็นคำตอบที่ดีมาก ผลิตภัณฑ์ไม่ต้องเพิ่มเอเจนต์เพียงเพื่อให้ตัวเลขสูงขึ้น

Target autonomy: ควรหยุดตรงไหน

ก่อนยกระดับ ควรถามหกข้อ:

1. ภาระมนุษย์ที่เกิดซ้ำอะไรจะหายไป?
2. ภาระนั้นเกิดบ่อยแค่ไหน?
3. คุณภาพและความล้มเหลววัดได้หรือไม่?
4. ตรวจพบและย้อนกลับความเสียหายได้หรือไม่?
5. ระบบต้องได้รับอำนาจเพิ่มอะไร?
6. ประโยชน์มากกว่าต้นทุน ความซับซ้อน และความเสี่ยงหรือไม่?

หากตอบไม่ได้ การเพิ่ม autonomy อาจเป็นงานสถาปัตยกรรมที่น่าสนใจ แต่ไม่ใช่งานผลิตภัณฑ์ที่มีมูลค่าสูงสุด

Human governance อยู่เหนือทุกระดับ

Autonomy ที่ดีไม่ใช่การเอามนุษย์ออกจากระบบทั้งหมด แต่คือการย้ายมนุษย์ออกจากงาน routine debugging และให้คนอยู่ตรงจุดที่ต้องใช้ความรับผิดชอบจริง เช่น การเผยแพร่สู่สาธารณะ ธุรกรรมทางการเงิน ข้อมูลส่วนบุคคล ความปลอดภัย การสื่อสารภายนอก และการเปลี่ยนแปลงที่ย้อนกลับยาก

ประโยค “Founder is not the debugger” จึงไม่ได้แปลว่า founder ไม่ต้องตัดสินใจ แต่หมายถึงระบบต้องรับผิดชอบการตรวจจับ จำแนก และจัดการความผิดพลาดประจำวันได้ตามระดับที่อ้าง ส่วน founder ควรตัดสินใจเรื่องทิศทาง ความเสี่ยง และข้อยกเว้น

สิ่งที่มักทำให้ประเมินสูงเกินจริง

• นับจำนวนโมเดลหรือเอเจนต์แทนการดูความรับผิดชอบ
• ถือว่า CI และ browser QA ขั้นสูงคือ L4 ทั้งที่ไม่มี persistent task state
• เรียก workflow แบบเส้นตรงว่า agent เพราะมี LLM อยู่หนึ่งขั้น
• ให้คะแนนเฉลี่ยจน recovery หรือ security ที่ขาดหายถูกกลบ
• เปลี่ยน UNKNOWN หรือ PARTIAL ให้เป็น pass เพราะ “น่าจะมี”
• อ้าง L6 จากงาน unattended เพียงครั้งเดียว
• เพิ่ม model calls ทั้งที่โค้ด deterministic, cache หรือ structured data ทำงานได้ดีกว่า
• ลด human approval เพื่อทำให้รายงานดู autonomous ขึ้น

ในกรอบ SXP mandatory gate เป็นแบบสะสม UNKNOWN ไม่เท่ากับ PASS, PARTIAL ผ่านเงียบ ๆ ไม่ได้ และระดับที่อ้างต้องไม่สูงกว่าระดับที่พิสูจน์

หลักฐานจากระบบ SXP หกระบบ

การ calibration รอบ v1.0 แสดงรูปแบบที่ตั้งใจให้ต่างกัน:

• Web และ Analytics หยุดที่ระดับเป้าหมายต่ำกว่าระบบอื่น เพราะ autonomy เพิ่มไม่ได้สร้างคุณค่าพอ
• METAMI แยก product สำหรับเด็กออกจาก production/quality operations; runtime ของเด็กยัง deterministic แต่การดำเนินงานมี state, gate, audit และการ resume
• Game Factory มี automated play, soak, builds และการซ่อมจากหลักฐาน แต่ยังไม่ขึ้น L4 จนกว่าจะมี persistent workflow state และ recovery controller
• Commerce มี private-beta workflow จริง แต่ยังไม่อ้าง tool-using agent จนกว่าจะมี observed action loop ที่ยอมรับแล้ว
• Studio มีระบบควบคุมการผลิตที่เป็น L4 แต่ยังไม่อ้าง L5 จนกว่าคุณภาพที่วัดได้จะเปลี่ยน routing ได้จริง

บทเรียนสำคัญคือ maturity ไม่ได้มาจากการทำทุกระบบให้มีเลขเดียวกัน แต่มาจากการพิสูจน์ระดับที่เหมาะกับงานแต่ละประเภท

ประเมิน workflow ของคุณเองอย่างไร

เริ่มจากเลือก ขอบเขตเดียว เช่น “ผลิตรายงานรายสัปดาห์” ไม่ใช่ “บริษัทของเรา” แล้วทำตามลำดับนี้:

1. ระบุ trigger, เป้าหมาย, สถานะ, เครื่องมือ และจุดหยุด
2. เก็บหลักฐานจากโค้ด ทดสอบ runtime, deployment และเหตุการณ์จริง
3. ไล่ mandatory gate จาก L1 ขึ้นไป หยุดทันทีที่ gate ใดไม่ผ่าน
4. ประเมิน readiness และ assurance แยกจาก autonomy
5. เลือก target ด้วยภาระจริง คุณภาพ ความเสี่ยง และต้นทุน
6. ทำ next best action ที่ปิด gate แรก ไม่ใช่สร้างระบบใหม่ทั้งชุด

ผลลัพธ์ควรเขียนว่า “Likely Proven Level” พร้อม missing mandatory gates และ caveat ไม่ควรเรียกว่า certification

Autonomy ที่น่าเชื่อถือไม่ใช่เรื่องว่าระบบดูฉลาดเพียงใด แต่คือเรารู้หรือไม่ว่ามันรับผิดชอบอะไร พิสูจน์อย่างไร ล้มเหลวแบบไหน ฟื้นตัวได้แค่ไหน และเมื่อใดที่ต้องหยุดเพื่อให้มนุษย์ตัดสินใจ