การวิเคราะห์: สิ่งที่จริงๆ แล้วเปลี่ยนไปเมื่อเอเจนต์ AI ย้ายจากการสาธิตสู่การผลิต
ตัวอย่างเอเจนต์ในสองปีที่ผ่านมานั้นน่าประทับใจแต่ส่วนใหญ่ทำไม่สำเร็จ การปรับใช้ที่ประสบความสำเร็จมีการตัดสินใจออกแบบเพียงเล็กน้อย — และไม่ใช่สิ่งที่ตัวอย่างเน้น
คำตอบโดยย่อ
ทำไมตัวอย่างของเอไอเอเจนต์ถึงทำงานได้ แต่การนำไปใช้ในผลิตจึงล้มเหลว?
Demos ทำการรันเส้นทางสุขสันต์สั้น ๆ หนึ่งครั้งโดยมีมนุษย์สังเกต Production รันหลายพันแบบโดยไม่มีการดูแล ที่ซึ่งอัตราข้อผิดพลาดในแต่ละขั้นตอนสะสมและขอบเขตสิทธิ์ที่ไม่จำกัดทำให้การตัดสินใจผิดพลาดกลายเป็นเหตุการณ์ การปรับใช้ที่ประสบความสำเร็จจะจำกัดขอบเขต ตรวจสอบแต่ละขั้นตอนอย่างถูกวิธีโดยค่าใช้จ่ายต่ำ และกั้นการกระทำที่ไม่สามารถยกเลิกได้ทุกครั้ง
ประเด็นสำคัญ
- การเปิดตัวเอเจนต์ที่สำเร็จจะจำกัดอยู่ในโดเมนที่จำกัด มีเครื่องมือเพียงไม่กี่อย่างและสัญญาณความสำเร็จที่ชัดเจน
- การตรวจสอบที่ราคาถูกเป็นตัวบ่งชี้ความสำเร็จที่แข็งแรงที่สุด — ซึ่งก็เป็นเหตุผลที่ทำให้การเขียนโค้ดเป็นสิ่งแรก
- การประเมินได้เปลี่ยนจากความรู้สึกเป็นการใช้เส้นทางที่บันทึกไว้เพื่อเปรียบเทียบกับการเปลี่ยนแปลง
- การสร้างมาตรฐานเครื่องมือผ่าน MCP ได้เปลี่ยนงานการรวมระบบจากโค้ดเชื่อมต่อแบบเฉพาะกิจไปสู่เซิร์ฟเวอร์ที่นำกลับมาใช้ใหม่ได้
มีเส้นโค้งที่คุ้นเคยสำหรับโปรเจกต์เอเจนต์ ต้นแบบทำสิ่งที่น่าตกใจในสัปดาห์แรก เมื่อถึงสัปดาห์ที่หก มันก็สามารถสร้างข้อมูลที่ดูเหมือนจะสมเหตุสมผลได้จากอินพุตที่ไม่มีใครคาดคิด และทีมก็กำลังถกเถียงกันว่าจะเพิ่มโมเดลอีกตัวหรือยอมแพ้
โปรเจกต์ที่ผ่านพ้นมาได้ไม่ได้ค้นพบโมเดลที่ดีกว่า พวกเขาเปลี่ยนรูปร่างของปัญหา
คณิตศาสตร์ที่ทำให้เดโมล้มเหลว
ลองพิจารณางานที่แบ่งออกเป็นขั้นตอน โดยแต่ละขั้นตอนเอเจนต์จะทำสำเร็จถูกต้อง 95% ของเวลา นั่นเป็นอัตราที่ดีสำหรับขั้นตอนที่เปิดกว้างซึ่งต้องใช้การตัดสินใจ
เมื่อเชื่อมโยงสามขั้นตอนเข้าด้วยกัน ประมาณ 86% ของการทำงานจะสำเร็จ เชื่อมโยงยี่สิบขั้นตอน และประมาณหนึ่งในสามจะสำเร็จ เชื่อมโยงห้าสิบขั้นตอน และคุณจะเหลือเพียง 8%
เดโมแสดงให้คุณเห็นการทำงานหนึ่งครั้งของงานห้าขั้นตอน และมนุษย์ก็เงียบๆ รีสตาร์ทสองครั้งที่ผิดพลาด การผลิตทำงานเวอร์ชันยี่สิบขั้นตอนหนึ่งหมื่นครั้งโดยไม่มีใครเฝ้าดู
ทุกสิ่งที่ตามมาคือการตอบสนองต่อคณิตศาสตร์นี้
สิ่งที่การใช้งานที่สำเร็จมีร่วมกัน
ขอบเขตที่แคบ ไม่ใช่ "จัดการการดำเนินงาน" แต่เป็น "กระทบยอดระบบใบแจ้งหนี้สองระบบนี้" สาขาน้อยลง เครื่องมือน้อยลง วิธีการผิดพลาดน้อยลง เอเจนต์เกือบทั้งหมดที่รอดจากการติดต่อกับการผลิตมีความทะเยอทะยานน้อยกว่าเดโมที่ให้เหตุผล
การตรวจสอบราคาถูก นี่คือตัวทำนายที่แข็งแกร่งที่สุด เอเจนต์การเขียนโค้ดทำงานได้ก่อนเพราะการทดสอบให้สัญญาณอัตโนมัติที่ชัดเจน: เอเจนต์สามารถลอง ตรวจสอบ และลองอีกครั้งโดยไม่ต้องมีมนุษย์ ในกรณีที่การตรวจสอบมีค่าใช้จ่ายสูง เช่น ความเห็นทางกฎหมาย การตัดสินใจเรื่องราคา ผลลัพธ์ของเอเจนต์จะต้องได้รับการตรวจสอบโดยบุคคล ซึ่งจะจำกัดประโยชน์และเปลี่ยนกรณีทางธุรกิจ
ขอบเขตการอนุญาตภายนอกโมเดล อ่านอย่างกว้างขวาง เขียนอย่างแคบ ประตูอนุมัติสำหรับการใช้จ่ายเงิน ติดต่อลูกค้า ลบข้อมูล ปรับใช้ สิ่งนี้บังคับใช้ในขณะทำงาน ไม่เคยด้วยคำแนะนำในพรอมต์: เอเจนต์ที่อ่านเนื้อหาที่ไม่น่าเชื่อถือคือเอเจนต์ที่คำแนะนำสามารถปนเปื้อนได้
งบประมาณ ขั้นตอนสูงสุด เวลาผนังสูงสุด โทเค็นสูงสุด เอเจนต์ที่วนลูปในการตอบสนองเครื่องมือที่ผิดรูปแบบคือเหตุการณ์การเรียกเก็บเงินที่ไม่มีจุดสิ้นสุดตามธรรมชาติ
บันทึกที่สามารถเล่นซ้ำได้ การเรียกใช้เครื่องมือและผลลัพธ์ทั้งหมดถูกจัดเก็บ เมื่อมีบางอย่างผิดพลาด "มันทำอะไรไปจริงๆ" จะต้องสามารถตอบได้ทันที ทั้งเพื่อแก้ไขและเพื่อตอบสนองผู้ตรวจสอบบัญชีที่เพิ่มขึ้นเรื่อยๆ
การประเมินผลเติบโตขึ้น
การเปลี่ยนแปลงที่มีผลกระทบมากที่สุดคือการมองเห็นน้อยที่สุด งานเอเจนต์ในช่วงแรกถูกประเมินโดยการเฝ้าดู ซึ่งไม่สามารถขยายขนาดได้และไม่สามารถจับการถดถอยได้
แนวทางปฏิบัติปัจจุบันคือการบันทึก เส้นทาง - ลำดับเต็มของขั้นตอน การเรียกใช้เครื่องมือ และผลลัพธ์จากการทำงานจริง - และเล่นซ้ำกับทุกการเปลี่ยนแปลงพรอมต์ โมเดล หรือชุดเครื่องมือ แต่ละเส้นทางมีการยืนยันเกี่ยวกับลักษณะของการทำงานที่ถูกต้อง โมเดลเวอร์ชันใหม่จะไม่ถูกนำมาใช้เพราะมีคะแนนดีกว่าในเกณฑ์มาตรฐานสาธารณะ แต่จะถูกนำมาใช้เพราะไม่ทำลายชุดที่บันทึกไว้
การเปลี่ยนแปลงที่สองคือ การให้คะแนนต่อขั้นตอน อัตราการผ่านตลอดจะบอกคุณว่ามีบางอย่างผิดปกติ การให้คะแนนระดับขั้นตอนจะบอกคุณว่าเครื่องมือการดึงข้อมูลส่งคืนผลลัพธ์ที่ล้าสมัยในวันจันทร์
เครื่องมือกลายเป็นโครงสร้างพื้นฐาน
ในช่วงเวลาหนึ่ง ผลิตภัณฑ์เอเจนต์ทุกตัวเขียนตัวเชื่อมต่อของตัวเอง Model Context Protocol ได้เปลี่ยนการเปิดเผยเครื่องมือให้เป็นอินเทอร์เฟซมาตรฐาน: เซิร์ฟเวอร์อธิบายสิ่งที่นำเสนอ และไคลเอ็นต์ที่เข้ากันได้สามารถใช้งานได้ สิ่งนี้ได้ย้ายงานการรวมระบบจากกาวเฉพาะในแต่ละแอปพลิเคชันไปยังเซิร์ฟเวอร์ที่นำกลับมาใช้ใหม่ได้ซึ่งได้รับการบำรุงรักษาเพียงครั้งเดียว
ผลกระทบในทางปฏิบัติมีความธรรมดาและใหญ่: คำถามที่น่าสนใจเปลี่ยนจาก "ฉันจะเชื่อมต่อเอเจนต์ของฉันกับระบบนี้ได้อย่างไร" เป็น "เอเจนต์ของฉันควรได้รับอนุญาตให้ทำอะไรกับระบบนี้" นั่นเป็นคำถามด้านธรรมาภิบาล และเป็นคำถามที่ถูกต้อง
ที่ที่มันไม่ได้ผล
ควรกล่าวอย่างตรงไปตรงมา เพราะความล้มเหลวไม่ค่อยได้รับการเผยแพร่:
- การดำเนินงานอัตโนมัติระยะยาว เอเจนต์ที่ปล่อยให้ทำงานเป็นเวลาหลายชั่วโมงด้วยเป้าหมายที่เปิดกว้างยังคงลอยไป และต้นทุนของการเลี้ยวผิดจะสะสมอย่างเงียบๆ
- งานที่มีการตรวจสอบราคาแพง หากมนุษย์ต้องอ่านผลลัพธ์ทั้งหมดเพื่อทราบว่าถูกต้องหรือไม่ เอเจนต์ก็ช่วยประหยัดการพิมพ์ ไม่ใช่งาน
- สภาพแวดล้อมที่มีความแปรปรวนสูง เว็บไซต์ที่มีการเปลี่ยนแปลงเลย์เอาต์ ระบบที่ส่งคืนข้อผิดพลาดที่ไม่สอดคล้องกัน กระบวนการที่มีข้อยกเว้นที่ไม่ได้บันทึกไว้
- ฝูงชนเพื่อตัวของมันเอง สถาปัตยกรรมหลายเอเจนต์ช่วยได้เมื่อส่วนย่อยของงานต้องการเครื่องมือและบริบทที่แตกต่างกันอย่างแท้จริง เมื่อนำไปใช้กับงานที่เอเจนต์เดียวสามารถทำได้ พวกเขาจะเพิ่มความล้มเหลวในการประสานงาน
สรุปอย่างตรงไปตรงมา
เอเจนต์ทำงานได้ในปัจจุบันเมื่อเป้าหมายชัดเจน ขอบเขตแคบ ผลลัพธ์ตรวจสอบได้ง่าย และรัศมีระเบิดถูกจำกัดด้วยสิ่งที่นอกเหนือจากการตัดสินใจที่ดีของโมเดล นั่นเป็นหมวดหมู่ที่แท้จริงและกำลังเติบโต — และเป็นหมวดหมู่ที่เล็กกว่าคำว่า "agentic" ในการประกาศผลิตภัณฑ์
ทีมที่ประสบความสำเร็จในการจัดส่ง โดยส่วนใหญ่แล้ว คือทีมที่ยอมรับสิ่งนั้นก่อน
คำถามที่พบบ่อย
- กรณีการใช้งานของเอเจนต์ใดที่ทำงานจริงในสภาพการผลิต?
- งานวิศวกรรมซอฟต์แวร์ที่ทำการทดสอบ การจัดการสนับสนุนลูกค้าและการเขียนเอกสาร การวิจัยและการรวบรวมข้อมูล การซ่อมแซมข้อมูลระหว่างระบบ ทั้งสี่อย่างนี้มีการตรวจสอบผลลัพธ์ที่ราคาถูก
- ในทางปฏิบัติ ตัวแทนการผลิตมีความเป็นอิสระมากน้อยเพียงใด
- น้อยกว่าที่การตลาดสัญญาไว้ รูปแบบที่พบบ่อยคือการให้การเข้าถึงกว้างขวางพร้อมการตรวจสอบก่อนอนุญาตสำหรับการใช้จ่ายเงิน การติดต่อลูกค้า หรือการลบข้อมูล
- ความเสี่ยงทางเทคนิคหลักคืออะไร?
- การฉีดโค้ดผ่านเนื้อหาที่ตัวแทนอ่าน การประมวลผลข้อความของผู้โจมตีโดยเอเจนต์ที่ประมวลผลอีเมล หน้าเว็บ หรือคอมเมนต์การ pull request เป็นข้อความที่ควบคุมได้โดยผู้โจมตี และไม่มีโค้ดใดที่สามารถทำให้มันปลอดภัยได้อย่างเชื่อถือได้ การบรรเทาคือจำกัดการกระทำที่เอเจนต์ได้รับอนุญาต
- ระบบหลาย-agent ทำได้ดีกว่าบุคคลเดียวหรือไม่?
- เฉพาะเมื่อส่วนย่อยจำเป็นต้องใช้เครื่องมือหรือบริบทที่แตกต่างกันเท่านั้น มิฉะนั้น ความซับซ้อนในการประสานงานและโหมดความล้มเหลวเพิ่มเติมทำให้ผลลัพธ์แย่ลง ไม่ใช่ดีขึ้น