โลกอินเทอร์เน็ตตัดสินไปแล้วว่านี่คือปีแห่งเอเจนต์ (agent) ชื่อของ LangGraph, CrewAI และ AutoGen ปรากฏอยู่ในทุกโรดแมปของวิศวกร ทีมต่าง ๆ กำลังทดสอบความทนทานของเลเยอร์การจัดการ (orchestration layers) ถกเถียงกันระหว่างการใช้ state machines กับการสวมบทบาท (role-play) และสงสัยว่าไลบรารีไหนจะทำให้โมเดลภาษาขนาดใหญ่ (LLMs) ทำงานได้อย่างเป็นอิสระ (autonomous) ในที่สุด
นี่คือความจริงที่น่าอึดอัด: การเปรียบเทียบส่วนใหญ่นั้นยังเร็วเกินไป ตัวเฟรมเวิร์กไม่ใช่ส่วนที่ยาก ส่วนที่ยากคือเราหยุดนิยามคำศัพท์ของเรา ตอนนี้ใคร ๆ ก็เรียกทุกอย่างว่าเป็นเอเจนต์ การเรียกใช้เครื่องมือ (tool call) ไม่ใช่เอเจนต์ แชทบอท (chatbot) ก็ไม่ใช่เอเจนต์ การนิยามที่สะเพร่าเช่นนี้จะนำไปสู่การวิศวกรรมที่แย่ ระบบที่ซับซ้อนเกินความจำเป็น และระบบล่มในขั้นตอนการใช้งานจริง (production outages) ซึ่งจริง ๆ แล้วสามารถหลีกเลี่ยงได้ด้วยสคริปต์ง่าย ๆ เพียงตัวเดียว
ก่อนที่คุณจะเลือกเฟรมเวิร์ก จงนิยามสิ่งที่คุณกำลังสร้างขึ้นมาจริง ๆ ก่อน
สิ่งที่เอเจนต์เป็นจริง ๆ
เอเจนต์ไม่ได้ถูกกำหนดโดยโมเดลที่มันรันอยู่หรือจำนวนการเรียก API ที่มันทำ แต่มันถูกกำหนดโดยพฤติกรรมของมัน มันต้องมีวัตถุประสงค์ที่ชัดเจน มันต้องตัดสินใจได้ว่าขั้นตอนต่อไปคืออะไรโดยไม่ต้องมีมนุษย์มาวางแผนเส้นทางไว้ล่วงหน้า มันต้องจัดการกับความล้มเหลวเมื่อขั้นตอนนั้นพัง และมันต้องรู้ว่าเมื่อไหร่ควรหยุด
ลองนึกถึงระบบสนับสนุนที่อ่านอีเมลที่ส่งเข้ามา จัดประเภทว่าเป็นคำขอคืนเงิน ดึงหมายเลขคำสั่งซื้อ สอบถามฐานข้อมูลการจัดส่ง ตรวจสอบช่วงเวลาตามนโยบายการคืนสินค้า ร่างคำตอบ และทำเครื่องหมายว่าตั๋วนี้ได้รับการแก้ไขแล้ว หากฐานข้อมูลหมดเวลา (timeout) มันจะรอและลองใหม่ หากช่วงเวลาตามนโยบายมีความคลุมเครือ มันจะแจ้งเตือนให้มนุษย์เข้ามาจัดการ เมื่อส่งคำตอบแล้ว มันก็จะหยุด นั่นคือเอเจนต์ ส่วนการเป็นแค่ตัวหุ้ม (wrapper) รอบการเรียก LLM เพียงครั้งเดียวเพื่อคืนค่า JSON นั้นไม่ใช่เอเจนต์ ไม่ว่าทีมการตลาดจะแปะสติกเกอร์คำว่า "agent" ลงไปมากแค่ไหนก็ตาม
ความแตกต่างนี้สำคัญเพราะความซับซ้อนมีต้นทุน ระบบที่ไม่ต้องการความเป็นอิสระ (autonomy) ก็ไม่ควรต้องจ่ายราคาให้กับมัน
รูปแบบที่แท้จริงของ AI ในการใช้งานจริง
ระบบ AI ส่วนใหญ่ที่รันอยู่ในขั้นตอนการใช้งานจริง (production) ในขณะนี้เป็นระบบเฉพาะทาง (narrow) พวกมันทำสิ่งเดียวได้ดี เช่น การคัดกรองตั๋วสนับสนุนเข้าคิว การดึงวันหมดอายุจากเอกสารที่สแกน การจับคู่คำถามของลูกค้ากับบทความในฐานความรู้ที่มีอยู่ พวกมันไม่ใช่เครื่องยนต์การใช้เหตุผลทั่วไป (general reasoning engines) และการแสร้งทำเป็นว่าพวกมันเป็นเช่นนั้นจะนำไปสู่การออกแบบระบบที่เกินความจำเป็น (overengineering) ในรูปแบบที่แย่ที่สุด
นอกจากนี้ยังนำไปสู่ความหมกมุ่นที่ทำลายล้างต่อการเปิดตัวโมเดลใหม่ ๆ ทีมงานต่างวิ่งไล่ตามโมเดลพื้นฐาน (foundation model) ตัวล่าสุดราวกับว่ามันจะมาชดเชยสถาปัตยกรรมที่สะเพร่าได้ แต่มันจะไม่เป็นเช่นนั้น โมเดลที่มีความสามารถมากขึ้นที่รันอยู่ภายในลูปที่เปราะบางและไม่มีการจัดการข้อผิดพลาด จะเพียงแค่ล้มเหลวด้วยความมั่นใจที่สูงขึ้นและมีอาการหลอน (hallucinations) ที่สร้างสรรค์มากขึ้น เลิกวิ่งไล่ตามเกณฑ์มาตรฐาน (benchmarks) แล้วเริ่มวิ่งไล่ตามโครงสร้าง (structure) แทน
เฟรมเวิร์กไม่ใช่ผลิตภัณฑ์
LangGraph ให้ state machines และวงจร (cycles) ที่ชัดเจน CrewAI เน้นการจัดการแบบอิงบทบาท (role-based orchestration) ที่เอเจนต์จะสวมบทบาทต่าง ๆ ส่วน AutoGen เน้นที่เอเจนต์แบบสนทนา (conversational agents) ที่คุยกันเองเพื่อแก้ปัญหา ทั้งหมดนี้เป็นเครื่องมือที่มีความสามารถ และยังเป็นแนวทางที่แตกต่างกันโดยสิ้นเชิงในการควบคุมลำดับการทำงาน (control flow)
แต่เฟรมเวิร์กที่คุณเลือกนั้นมีความสำคัญน้อยกว่ารูปแบบ (patterns) ที่คุณบังคับใช้ภายในนั้น ผมเคยเห็นทีมที่ส่งมอบระบบอัตโนมัติที่แข็งแกร่งมากโดยใช้เพียง Python และ Redis เพราะพวกเขาเคารพในขอบเขตการทำงาน ผมเคยเห็นทีมอื่นพังทลายลงภายใต้น้ำหนักของการจัดการ (orchestration) ที่หรูหรา เพราะพวกเขาใช้เฟรมเวิร์กเป็นสิ่งทดแทนการออกแบบ
หากการส่งต่องาน (handoffs) ของคุณคลุมเครือ เครื่องมือของคุณเปราะบาง และตรรกะการลองใหม่ (retry logic) ของคุณไม่มีอยู่จริง โลโก้บนไฟล์ requirements.txt ของคุณก็ช่วยคุณไม่ได้
สามสิ่งที่ควรค่าแก่การสละเวลาของคุณจริง ๆ
หากคุณกำลังสร้างระบบเอเจนต์ (agentic systems) จงทุ่มเทความพยายามของคุณไปที่สามด้านนี้
การออกแบบเครื่องมือ (Tool design). ทุกฟังก์ชันที่เอเจนต์ของคุณสามารถเรียกใช้ได้คือภาระที่ห่อหุ้มด้วยอินเทอร์เฟซ จงออกแบบพวกมันให้รัดกุม ตรวจสอบข้อมูลนำเข้า (inputs) อย่างเข้มงวด ส่งคืนข้อผิดพลาดที่อ่านออกได้จริง ไม่ใช่แค่การ dump ค่า 500 ออกมา เครื่องมือที่ดีคือเครื่องมือที่เอเจนต์สามารถใช้เหตุผลเกี่ยวกับมันได้เมื่อมีบางอย่างผิดพลาด
การจัดการความล้มเหลว (Failure handling). สมมติว่าทุก LLM