Agent Client Protocol ( ACP ) ที่ออกแบบมาเพื่อสร้างมาตรฐานการสื่อสารระหว่างโปรแกรมแก้ไขโค้ดและ AI coding agents กำลังสร้างปฏิกิริยาที่หลากหลายจากชุมชนนักพัฒนา แม้ว่าโปรโตคอลนี้จะมีเป้าหมายเพื่อแก้ไขปัญหาการรวมระบบคล้ายกับที่ Language Server Protocol ได้ปฏิวัติการรวมระบบ language server แต่ข้อเสนอแนะในช่วงแรกเผยให้เห็นความกังวลเกี่ยวกับเวลาและความจำเป็น
ความกังวลเรื่องการแพร่หลายของโปรโตคอล
นักพัฒนากำลังแสดงความสงสัยเกี่ยวกับการแนะนำโปรโตคอลอีกตัวหนึ่งในพื้นที่ AI coding ที่พัฒนาอย่างรวดเร็ว ชุมชนชี้ให้เห็นว่าโปรโตคอลที่คล้ายกันอย่าง AG-UI มีอยู่แล้ว ทำให้เกิดคำถามเกี่ยวกับการแยกส่วน บางคนโต้แย้งว่าสาขานี้ยังไม่เป็นผู้ใหญ่เพียงพอสำหรับความพยายามในการสร้างมาตรฐาน โดยแนะนำว่าการนำไปใช้งานจริงควรมาก่อนการกำหนดโปรโตคอล
ความกังวลเรื่องเวลาสะท้อนถึงรูปแบบที่กว้างขึ้นในเทคโนโลยีเกิดใหม่ที่มาตรฐานที่แข่งขันกันหลายตัวสามารถสร้างความสับสนมากกว่าความชัดเจน นักวิจารณ์กังวลว่าการรีบสร้างโปรโตคอลก่อนที่เทคโนโลยีพื้นฐานจะมีเสถียรภาพอาจนำไปสู่การสร้างมาตรฐานที่เร็วเกินไป
โปรโตคอลที่แข่งขัน/เกี่ยวข้อง
- Language Server Protocol (LSP): มาตรฐานที่ได้รับการยอมรับสำหรับการรวม language server
- AG-UI Protocol: โปรโตคอลที่มีอยู่แล้วซึ่งมีวัตถุประสงค์คล้ายคลึงกับ ACP
- Model Context Protocol (MCP): การแสดงข้อมูลแบบ JSON ที่ถูกนำมาใช้ซ้ำโดย ACP
การอภิปรายการนำไปใช้ทางเทคนิค
การเลือกใช้ JSON-RPC แทน stdio เป็นวิธีการสื่อสารได้รับการวิจารณ์จากนักพัฒนาที่ใส่ใจเรื่องประสิทธิภาพ บางคนโต้แย้งว่า JSON-RPC เพิ่มภาระที่ไม่จำเป็นสำหรับการรวมระบบ editor โดยชอบทางเลือกที่มีน้ำหนักเบากว่า การตัดสินใจทางเทคนิคนี้เน้นให้เห็นความตึงเครียดที่ดำเนินอยู่ระหว่างการสร้างมาตรฐานและการเพิ่มประสิทธิภาพในเครื่องมือนักพัฒนา
นอกจากนี้ ยังมีคำถามเกิดขึ้นว่าทำไม ACP ไม่สามารถขยาย Language Server Protocol ที่มีอยู่แล้วแทนที่จะสร้างมาตรฐานใหม่ทั้งหมด สิ่งนี้แสดงให้เห็นว่านักพัฒนาบางคนมอง protocol นี้ว่าอาจซ้ำซ้อนกับโครงสร้างพื้นฐานที่มีอยู่
แนวทางทางเลือกที่ได้รับความนิยม
ส่วนสำคัญของชุมชนสนับสนุนวิธีการรวมระบบที่ง่ายกว่าที่ปฏิบัติต่อ AI agents เหมือนนักพัฒนามนุษย์ แนวทาง prompt coding นี้เกี่ยวข้องกับ AI agents ที่ทำงานอย่างอิสระและส่งการเปลี่ยนแปลงผ่านระบบควบคุมเวอร์ชันมาตรฐาน ซึ่งช่วยขจัดความจำเป็นในการใช้โปรโตคอลการรวมระบบ editor ที่ซับซ้อนทั้งหมด
ผมพอใจที่จะปฏิบัติต่อ AI เหมือนนักพัฒนามนุษย์: ผมขอให้ AI เขียนฟีเจอร์แล้วผมก็อ่าน commit หาก commit ไม่เป็นไปตามที่ผมต้องการ ผมจะ git reset --hard ปรับปรุง prompt ของผมและขอให้ AI ทำงานนั้นอีกครั้ง
ปรัชญานี้แสดงให้เห็นว่านักพัฒนาบางคนชอบการรักษาขอบเขตที่ชัดเจนระหว่างสภาพแวดล้อมการพัฒนาของพวกเขาและเครื่องมือ AI มากกว่าการรวมระบบอย่างลึกซึ้ง
การรับใช้ในช่วงแรกและความเป็นจริงของตลาด
แม้จะมีการวิจารณ์ แต่ ACP ได้รับการสนับสนุนเริ่มแรกจาก Zed editor และ neovim ผ่าน CodeCompanion plugin โดยมี Gemini เป็น agent ตัวแรกที่ได้รับการสนับสนุน อย่างไรก็ตาม ระบบนิเวศเริ่มแรกที่จำกัดทำให้เกิดคำถามเกี่ยวกับการรับใช้ที่กว้างขึ้น โดยเฉพาะอย่างยิ่งเมื่อพิจารณาถึงการครอบงำของ Visual Studio Code ในตลาด editor
ความสำเร็จของโปรโตคอลน่าจะขึ้นอยู่กับว่าผู้เล่นรายใหญ่ในระบบนิเวศเครื่องมือการพัฒนาจะยอมรับหรือไม่ หากไม่มีการสนับสนุน editor อย่างกว้างขวาง แม้แต่โปรโตคอลที่ออกแบบมาอย่างดีที่สุดก็อาจดิ้นรนเพื่อได้รับความสนใจที่มีความหมาย
สถานะการสนับสนุน ACP ปัจจุบัน
Editors ที่รองรับ:
- Zed (รองรับแบบ native)
- neovim (ผ่าน plugin CodeCompanion)
Agents ที่รองรับ:
- Gemini CLI
ข้อมูลจำเพาะทางเทคนิค:
- การสื่อสار: JSON-RPC ผ่าน stdio
- รูปแบบข้อความ: Markdown (ค่าเริ่มต้นสำหรับเนื้อหาที่ผู้ใช้อ่านได้)
- สถาปัตยกรรม: Agents ทำงานเป็น sub-processes ของ code editors
- การแสดงข้อมูล JSON: นำรูปแบบ MCP มาใช้ซ้ำในส่วนที่เป็นไปได้
บทสรุป
แม้ว่า ACP จะจัดการกับความท้าทายการรวมระบบที่แท้จริงในพื้นที่ AI coding แต่การตอบรับของมันเน้นให้เห็นความซับซ้อนของการสร้างมาตรฐานใหม่ในโดเมนเทคโนโลยีที่พัฒนาอย่างรวดเร็ว การตอบสนองที่หลากหลายของชุมชนนักพัฒนาแสดงให้เห็นว่าความสำเร็จจะไม่ขึ้นอยู่กับคุณค่าทางเทคนิคเท่านั้น แต่ยังขึ้นอยู่กับเวลา การสนับสนุนระบบนิเวศ และว่าโปรโตคอลสามารถแสดงให้เห็นข้อได้เปรียบที่ชัดเจนเหนือทางเลือกที่ง่ายกว่าหรือไม่ ขณะที่ตลาด AI coding assistant ยังคงเติบโต ชะตากรรมของ ACP อาจเป็นกรณีศึกษาในความท้าทายของการสร้างมาตรฐานที่เร็วเกินไปในพื้นที่เทคโนโลยีเกิดใหม่
อ้างอิง: Introduction