ในโรดแมปของทุกผลิตภัณฑ์มักจะมีหัวข้อที่เขียนว่า "AI Agent" คำนี้ฟังดูเหมือนความก้าวหน้า มันส่งสัญญาณถึงผู้บริหารว่าทีมของคุณกำลังสร้างอนาคต ไม่ใช่แค่การดูแลรักษาปัจจุบัน แต่ความจริงที่น่าอึดอัดใจซึ่งวิดีโอสาธิตส่วนใหญ่ไม่บอกคุณก็คือ: เอเจนต์ (agent) เป็นวิธีที่แพงที่สุดและคาดเดาได้ยากที่สุดในการทำงานให้สำเร็จ สำหรับงานทางธุรกิจส่วนใหญ่ มันเป็นเครื่องมือที่ผิดประเภทอย่างสิ้นเชิง วิศวกรที่เก่งที่สุดไม่ใช่คนที่รีบเร่งสร้างมันขึ้นมา แต่คือคนที่รู้ว่าเมื่อไหร่ควรจะหยุด
กับดักของการจำแนกประเภท (The Classification Trap)
ลองสังเกตทีมที่กำลังกำหนดขอบเขตเอเจนต์ตัวแรกของพวกเขาดู แล้วคุณมักจะเห็นอะไรประมาณนี้: มีอีเมลสนับสนุนส่งมา LLM อ่านหัวข้อและเนื้อหา ตัดสินใจว่าเป็นคำถามเรื่องการเรียกเก็บเงินหรือบั๊กทางเทคนิค แล้วส่งไปยังคิวที่เหมาะสม ทีมเรียกสิ่งนี้ว่าเอเจนต์ แต่มันไม่ใช่
สิ่งที่พวกเขาสร้างขึ้นคือ flow ที่เป็นแบบ deterministic (กำหนดผลลัพธ์ได้แน่นอน) โดยมีการเรียกใช้โมเดลเพียงครั้งเดียวภายในนั้น ขั้นตอนถูกกำหนดไว้ตายตัว: รับอีเมล, เรียกโมเดล, ส่งไปยังคิว ไม่มีการวนลูป ไม่มีการใช้เครื่องมือ (tool use) และไม่มีช่วงเวลาที่ระบบจะหยุดเพื่อทบทวนแผนใหม่หากความพยายามครั้งแรกล้มเหลว มันไม่ได้ค้นหาฐานความรู้ ไม่ได้เขียนโค้ด หรือตรวจสอบสถานะคำสั่งซื้อระหว่างทาง มันตัดสินใจเพียงครั้งเดียวแล้วก็ผ่านไป การนำการเรียกใช้งานเพียงครั้งเดียวนั้นไปห่อหุ้มไว้ใน microservice ไม่ได้ทำให้มันกลายเป็นเอเจนต์
ต้นทุนที่แท้จริงของการเข้าใจผิดว่า flow คือเอเจนต์ ไม่ใช่แค่เรื่องโครงสร้างพื้นฐานที่เพิ่มขึ้น แต่มันคือความไม่แน่นอน (non-determinism) ที่คุณดึงเข้ามาโดยไม่ได้ประโยชน์อะไรเลย อีเมลฉบับเดียวกันอาจถูกส่งไปคนละที่ในเช้าวันอังคารเทียบกับบ่ายวันพุธ เพียงเพราะค่า temperature ไม่เป็นศูนย์ หรือ prompt เกิดการคลาดเคลื่อน (drift) คุณต้องจ่ายราคาแพงระดับเอเจนต์ ทั้งในแง่ของความหน่วง (latency) ค่า token และภาระในการประเมินผล (evaluation overhead) ในขณะที่ flow ที่มีขั้นตอนการจำแนกประเภทเพียงขั้นตอนเดียวสามารถแก้ปัญหาได้เร็วกว่าและถูกกว่า
ไล่ลำดับจากล่างขึ้นบน (Work Down the Ladder)
ปัญหาส่วนใหญ่มีวิธีแก้ที่ง่ายกว่าซึ่งให้ผลลัพธ์ได้ดีไม่แพ้กัน ให้คิดซะว่าเป็นบันได และเริ่มจากขั้นล่างสุด
แก้ไขกระบวนการ (Fix the process). บางครั้งงานนั้นเกิดขึ้นเพียงเพราะระบบสองระบบทำงานไม่สอดคล้องกัน ข้อมูลลูกค้าใน CRM ไม่ซิงค์กับแพลตฟอร์มการจัดการตั๋ว (ticketing platform) ทำให้ต้องมีคนมาเชื่อมช่องว่างนี้ด้วยตัวเองทุกเช้า อย่าใช้เอเจนต์มาทำหน้าที่เชื่อมช่องว่างนี้ แต่จงกำจัดมันทิ้งไป หากท่อข้อมูล (data pipeline) ทำงานได้อย่างถูกต้อง งานนี้ก็จะหายไปเอง
ใช้การคิวรี (Use a query). หากคำตอบคือการค้นหาหรือการรวมข้อมูลแบบง่ายๆ ก็จงจัดการมันแบบนั้น "เมื่อวันอังคารที่แล้วเราคืนเงินไปเท่าไหร่?" ไม่จำเป็นต้องใช้การใช้เหตุผล (reasoning) แต่มันต้องการ SQL เอเจนต์ที่แปลภาษาธรรมชาติเป็น SQL อาจฟังดูหรูหรา จนกระทั่งคุณตระหนักว่าภาระในการดูแลรักษานั้นสูงกว่าการเขียน query ที่มีการทำเอกสารกำกับไว้สามชุดเพื่อให้ทีมรันจากแดชบอร์ด
สร้าง deterministic flow (Build a deterministic flow). เมื่อกฎเกณฑ์ถูกกำหนดไว้ตายตัวและผลลัพธ์สามารถทำซ้ำได้ ให้ใช้ตรรกะที่ชัดเจน (explicit logic) หากมูลค่าคำสั่งซื้อเกินเกณฑ์ที่กำหนด ให้ส่งเรื่องต่อไปยังฝ่ายการเงิน หากผู้ใช้ไม่มีความเคลื่อนไหวเป็นเวลาสามสิบวัน ให้ส่งอีเมลเพื่อดึงดูดการใช้งานอีกครั้ง โค้ดสามารถจัดการเรื่องนี้ได้โดยไม่มีความผันแปรและสามารถตรวจสอบได้ทั้งหมด (full observability) คุณสามารถทำ unit-test ได้ แต่คุณไม่สามารถทำ unit-test กับ "ความรู้สึก" (vibe) ได้
ใช้ flow ที่มีการเรียกโมเดลเพียงครั้งเดียว (Use a flow with one model call). นี่คือจุดที่การจำแนกประเภท (classification), การติดแท็กความรู้สึก (sentiment tagging) หรือการสกัดข้อมูล (data extraction) ทำงาน โมเดลจะตัดสินใจเพียงครั้งเดียวภายในสคริปต์ที่ตายตัว คุณนำเอกสารเข้า สกัดเลขที่ใบแจ้งหนี้ และเขียนลงในฐานข้อมูล ขั้นตอนรอบข้างถูกเขียนโค้ดไว้ตายตัว (hardcoded) โมเดลไม่ได้เลือกสิ่งที่จะทำต่อไป แต่มันทำหน้าที่เพียงแค่ระบุสิ่งที่มันเห็น นี่เป็นรูปแบบที่มีประสิทธิภาพ แต่มันก็ยังคงเป็น flow อยู่ดี
สร้างเอเจนต์เป็นลำดับสุดท้าย (Build an agent last). เก็บขั้นตอนนี้ไว้สำหรับงานที่การกระทำถัดไปขึ้นอยู่กับสิ่งที่โมเดลค้นพบระหว่างการทำงานจริงๆ หากระบบต้องอ่านอีเมล ตระหนักว่าต้องไปค้นหาข้อมูลการจัดส่งใน logistics API พบว่าการจัดส่งล่าช้า และจากนั้นจึงร่างการตอบกลับแบบเฉพาะเจาะจงตามข้อมูลใหม่นั้น เมื่อนั้นคุณถึงจะเข้าสู่ขอบเขตของเอเจนต์ เส้นทางไม่สามารถวาดไว้ล่วงหน้าได้ เพราะโมเดลจะเป็นผู้ตัดสินใจว่าจะทำอะไรหลังจากได้รับข้อเท็จจริงใหม่ๆ
การทดสอบด้วยไวท์บอร์ด (The Whiteboard Test)
มีวิธีรวดเร็วในการยุติการถกเถียงในที่ประชุม ลองให้ทีมของคุณวาดแผนผังการตัดสินใจ (decision branches) ลงบนไวท์บอร์ด
หากคุณสามารถวางแผนทุกเส้นทางได้ก่อนที่โมเดลจะทำงาน ให้สร้าง flow วาดรูปทรงข้าวหลามตัด เขียน if-statements แล้วก็จบไป ความสามารถในการคาดเดาได้คือฟีเจอร์ ไม่ใช่ข้อจำกัด
หากตัวโมเดลเองต้องเป็นผู้ตัดสินใจว่าขั้นตอนต่อไปคืออะไร หากมันเป็นคนเลือกเครื่องมือ กำหนดพารามิเตอร์ และวนกลับมาคิดใหม่ นั่นแสดงว่าคุณต้องการเอเจนต์ การกำหนดเส้นทางแบบไดนามิก (dynamic routing) คือเส้นแบ่งเขต อย่าข้ามเส้นนั้นโดยไม่ตั้งใจเพียงเพราะคุณอยากลองใช้ API ใหม่ๆ
ภาษีแฝง (The Hidden Tax)
การสาธิตทำให้เอเจนต์ดูเหมือนทำงานได้อย่างราบรื่นไร้แรงเสียดทาน แต่ในสภาพแวดล้อมการใช้งานจริง (production) จะเผยให้เห็น "ภาษี" สี่ประการที่พอกพูนขึ้นอย่างรวดเร็ว
ความไม่แน่นอน (Non-determinism). สิ่งเดียวกัน