นักพัฒนาโต้เถียงหลัก "ยอมรับอย่างเสรี" ขณะที่ AI Agent ขับเคลื่อนรูปแบบการออกแบบอินเทอร์เฟซใหม่

ทีมชุมชน BigGo
นักพัฒนาโต้เถียงหลัก "ยอมรับอย่างเสรี" ขณะที่ AI Agent ขับเคลื่อนรูปแบบการออกแบบอินเทอร์เฟซใหม่

ขณะที่ระบบปัญญาประดิษฐ์เอเจนต์กลายเป็นสิ่งที่แพร่หลายมากขึ้นในแอปพลิเคชันซอฟต์แวร์ นักพัฒนากำลังต่อสู้กับคำถามพื้นฐานเกี่ยวกับวิธีการออกแบบอินเทอร์เฟซที่ทำงานได้ดีทั้งสำหรับมนุษย์และระบบ AI การเกิดขึ้นของ User Agent Interfaces (UAI) ควบคู่ไปกับ User Interfaces (UI) และ Application Programming Interfaces (API) แบบดั้งเดิมได้จุดประกายการถกเถียงอย่างเข้มข้นเกี่ยวกับความอดทน การจัดการข้อผิดพลาด และปรัชญาการออกแบบ

การอภิปรายมีจุดศูนย์กลางอยู่ที่หลักการหลักที่ได้หล่อหลอมโปรโตคอลอินเทอร์เน็ตมานานหลายทศวรรษ นักพัฒนาบางคนโต้แย้งให้สร้างรูปแบบ feedforward, tolerance, feedback เข้าไปในอินเทอร์เฟซที่หันหน้าไปหา AI ทำให้ระบบสามารถให้อภัยได้มากขึ้นเมื่อ AI Agent ส่งคำขอที่ไม่สมบูรณ์แบบ อย่างไรก็ตาม แนวทางนี้ได้รับการวิพากษ์วิจารณ์อย่างรุนแรงจากผู้ที่เชื่อว่าอินเทอร์เฟซที่เข้มงวดนำไปสู่ซอฟต์แวร์ที่เชื่อถือได้มากกว่า

สามประเภทของอินเทอร์เฟซสำหรับแอปพลิเคชันสมัยใหม่:

  • UI (User Interface): ออกแบบมาสำหรับการใช้งานของมนุษย์โดยเน้นที่รูปแบบการใช้งานที่ง่าย
  • API (Application Programming Interface): สร้างขึ้นเพื่อการเชื่อมต่อระหว่างแอปพลิเคชันและโปรแกรม
  • UAI (User Agent Interface): การออกแบบใหม่ที่เกิดขึ้นสำหรับ AI agents ที่ทำงานแทนมนุษย์

การถกเถียงเรื่องความอดทนแบ่งแยกนักพัฒนา

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

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

สิ่งมหัศจรรย์ของ HTML คือพวกเขาสามารถสร้างมาตรฐาน HTML 5 ซึ่งรวมกฎกรณีพิเศษส่วนใหญ่ที่ใช้โดยเบราว์เซอร์ เช่นนั้นแล้ว เบราว์เซอร์ทั้งหมดจะผ่อนปรน แต่พวกเขาจะผ่อนปรนในแบบเดียวกัน

การพัฒนา HTML เป็นตัวอย่างเตือนใจ:

  • HTML เริ่มต้นด้วยข้อกำหนดการแยกวิเคราะห์ที่เข้มงวด
  • เบราว์เซอร์เริ่มใช้การแยกวิเคราะห์แบบผ่อนปรนเพื่อจัดการกับมาร์กอัปที่เสียหาย
  • HTML5 ในที่สุดได้กำหนดมาตรฐานกฎการจัดการข้อผิดพลาดทั้งหมด
  • ผลลัพธ์: ข้อกำหนดที่ซับซ้อนพร้อมความหมายที่แม่นยำสำหรับอินพุตที่เป็นไปได้ทุกรูปแบบ

เอกสาร AI ได้รับการลงทุนมากกว่า API สำหรับมนุษย์

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

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

เครื่องมือใหม่เกิดขึ้นสำหรับการตรวจจับเอเจนต์

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

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

การรวมศูนย์ Business Logic กลายเป็นสิ่งสำคัญ

ขณะที่แอปพลิเคชันรองรับอินเทอร์เฟซหลายประเภทพร้อมกัน นักพัฒนาเน้นย้ำถึงความสำคัญของการรวมศูนย์ business logic แทนที่จะฝังไว้ในอินเทอร์เฟซเฉพาะ ตัวอย่างเช่น กฎการตรวจสอบวันที่สำหรับระบบการจองควรกำหนดไว้ใน logic หลักของแอปพลิเคชันและเปิดเผยผ่านอินเทอร์เฟซทั้งหมด แทนที่จะใช้งานแยกกันใน date picker ของ UI และ endpoint ของ API

แนวทางสถาปัตยกรรมนี้ช่วยให้มั่นใจในความสอดคล้องกันในวิธีการเข้าถึงฟังก์ชันการทำงานเดียวกันที่แตกต่างกัน ไม่ว่าจะผ่านอินเทอร์เฟซมนุษย์ API แบบดั้งเดิม หรือการโต้ตอบของ AI Agent นอกจากนี้ยังป้องกันปัญหาทั่วไปที่ฟีเจอร์ทำงานแตกต่างกันขึ้นอยู่กับวิธีการเข้าถึง

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

อ้างอิง: UI VS. API. VS. UAI