300 Action ที่ Agent ยิงอัตโนมัติทุกวัน แล้วใครเป็นคนอนุมัติก่อนมันลงมือทำจริง

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

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

บทความนี้อธิบายว่า Tool Approval ทำงานอย่างไรใน Vercel AI SDK ควรวางไว้ตรงจุดไหนของระบบ และข้อผิดพลาดที่ทีมมักเจอเมื่อเริ่มใช้กลไกนี้จริง

Tool Approval คืออะไร ทำงานต่างจาก Agent ที่ทำงานอัตโนมัติเต็มรูปแบบตรงไหน

โดยปกติเมื่อ Agent ตัดสินใจว่าต้องเรียก Tool ตัวใดตัวหนึ่ง ระบบจะรัน Tool นั้นทันทีแล้วส่งผลลัพธ์กลับให้โมเดลใช้ต่อ Tool Approval เปลี่ยนพฤติกรรมนี้เฉพาะกับ Tool ที่ทีมกำหนดไว้ล่วงหน้าว่าต้องการจุดตรวจ โดยเมื่อ Agent ตัดสินใจเรียก Tool เหล่านั้น ระบบจะหยุดรอสัญญาณอนุมัติก่อน ไม่รันทันทีตามที่โมเดลสั่ง

สัญญาณอนุมัติที่ว่านี้ไม่จำเป็นต้องมาจากคนเสมอไป ทีมกำหนดเป็นกฎอัตโนมัติได้เช่นกัน เช่นถ้าจำนวนเงินที่ต้องคืนต่ำกว่าเกณฑ์ที่กำหนด อนุมัติอัตโนมัติทันที แต่ถ้าสูงกว่าเกณฑ์ ต้องส่งให้คนตรวจก่อนเสมอ วิธีนี้ทำให้ทีมไม่ต้องเลือกระหว่างอัตโนมัติเต็มรูปแบบกับให้คนตรวจทุกรายการ แต่แบ่งตามระดับความเสี่ยงจริงของแต่ละ Action

จุดสำคัญคือ Tool Approval ทำงานที่ระดับ Tool แต่ละตัว ไม่ใช่ที่ระดับ Agent ทั้งตัว ทำให้ Agent เดียวกันเรียก Tool บางตัวได้ทันทีโดยไม่ต้องรออนุมัติ ขณะที่ Tool อีกตัวที่เสี่ยงกว่าต้องผ่านจุดตรวจก่อนเสมอ ไม่ต้องแยก Agent เป็นสองตัวเพื่อแบ่งระดับความเสี่ยง

Action แบบไหนควรมีจุดอนุมัติ แบบไหนปล่อยอัตโนมัติได้

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

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

ตารางนี้สรุปตัวอย่างการแบ่งระดับ Action ตามความเสี่ยง เพื่อช่วยทีมตัดสินใจว่าจุดไหนควรมี Tool Approval:

ขั้นตอนจริงเมื่อ Agent เจอ Tool ที่ต้องรออนุมัติ

1. Agent ประมวลผลคำขอแล้วตัดสินใจว่าต้องเรียก Tool ที่ทีมกำหนดไว้ว่าต้องอนุมัติก่อน เช่น Tool คืนเงิน
2. ระบบหยุดการทำงานของ Tool นั้นไว้ชั่วคราว แล้วส่งรายละเอียดของ Action ที่กำลังจะเกิดขึ้นออกไปยังจุดตรวจที่กำหนดไว้ ไม่ว่าจะเป็นคนหรือกฎอัตโนมัติ
3. ถ้าเป็นกฎอัตโนมัติและ Action นั้นผ่านเกณฑ์ที่ตั้งไว้ ระบบอนุมัติทันทีโดยไม่ต้องรอคน แล้ว Tool ทำงานต่อเหมือนปกติ
4. ถ้าต้องรอคนตรวจ ระบบจะค้าง Session นั้นไว้จนกว่าจะได้รับคำตอบ ระหว่างนี้ผู้ใช้ปลายทางอาจเห็นข้อความแจ้งว่ากำลังรอการยืนยันแทนที่จะได้ผลลัพธ์ทันที
5. เมื่อได้รับการอนุมัติหรือปฏิเสธ ระบบส่งผลนั้นกลับไปให้ Agent ใช้ตัดสินใจขั้นตอนถัดไป ถ้าถูกปฏิเสธ Agent ต้องมีทางอธิบายให้ผู้ใช้เข้าใจ ไม่ใช่ค้างเฉย ๆ โดยไม่บอกอะไรเลย

ออกแบบเกณฑ์อนุมัติอย่างไรไม่ให้กลายเป็นคอขวด

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

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

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

เมื่อไรควรให้คนอยู่ในวงจร เมื่อไรปล่อยอัตโนมัติเต็มรูปแบบ

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

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

ในบางกรณี การคงจุดอนุมัติไว้ถาวรสำหรับ Action ที่มีความเสี่ยงสูงสุดก็เป็นการตัดสินใจที่ถูกต้อง ไม่ใช่ทุกอย่างต้องมุ่งไปสู่ความอัตโนมัติเต็มรูปแบบ โดยเฉพาะ Action ที่ผลกระทบรุนแรงจนไม่คุ้มกับความเสี่ยงแม้จะมีอัตราความผิดพลาดต่ำมากก็ตาม

ตัวอย่างสมมติ Agent จัดการคำขอคืนเงินที่วางเกณฑ์อนุมัติแบบผสม

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

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

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

ทำแบบนี้แล้วพัง เพราะทีมมักพลาดจุดเหล่านี้

• ไม่ได้ตั้ง Timeout ให้กับ Session ที่รออนุมัติ — ถ้าคนที่ต้องอนุมัติไม่ตอบภายในเวลาที่เหมาะสม Session ค้างอยู่แบบนั้นโดยไม่มีทางออกให้ผู้ใช้ปลายทาง
• ให้ Agent ตัดสินใจเองว่า Action ไหนต้องอนุมัติ — เกณฑ์ควรถูกกำหนดไว้ล่วงหน้าโดยทีมที่เข้าใจความเสี่ยงจริง ไม่ใช่ปล่อยให้โมเดลประเมินเองว่าความเสี่ยงมากหรือน้อย
• ไม่มี Log ว่าใครอนุมัติอะไรตอนไหน — เมื่อเกิดปัญหาย้อนหลัง ไม่มีทางตรวจสอบได้ว่าการอนุมัตินั้นผ่านเกณฑ์ที่ถูกต้องจริงหรือเป็นความผิดพลาดของคนที่กดอนุมัติเร็วเกินไป
• ตั้งเกณฑ์เดียวใช้กับทุกสถานการณ์ — ไม่แยกตามลูกค้า ประเภทธุรกรรม หรือช่วงเวลา ทำให้บาง Action ถูกตรวจเข้มเกินจำเป็น ขณะที่บาง Action หลุดผ่านเกณฑ์ทั้งที่ควรถูกตรวจ

สรุป

Tool Approval คือกลไกที่ทำให้ Agent หยุดรอการอนุมัติก่อนเรียก Tool ที่มีความเสี่ยงสูง แทนที่จะลงมือทำทันทีตามที่โมเดลตัดสินใจเอง เหมาะกับระบบที่ Agent ต้องจัดการ Action จำนวนมากจนคนตรวจทุกรายการไม่ทัน โดยแบ่งตามระดับความเสี่ยงแทนที่จะเลือกระหว่างอัตโนมัติเต็มรูปแบบกับให้คนตรวจทุกอย่าง

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

• Tool Approval หยุด Agent ไว้ก่อนเรียก Tool ที่มีความเสี่ยงสูง รอการอนุมัติจากคนหรือกฎที่วางไว้
• แบ่งตามระดับความเสี่ยงของแต่ละ Action ไม่ใช่เลือกระหว่างอัตโนมัติเต็มรูปแบบกับให้คนตรวจทุกอย่าง
• เกณฑ์อนุมัติควรเริ่มเข้มแล้วผ่อนตามข้อมูลจริง พร้อมทบทวนเป็นระยะ
• ต้องมี Log และพฤติกรรม Default ที่ชัดเจนเมื่อไม่มีการตอบรับภายในเวลาที่กำหนด

คำถามที่พบบ่อย