Agent Client Protocol (ACP)

• Agent Client Protocol (ACP) เป็นโปรโตคอลที่มีเป้าหมายเพื่อ ทำให้การสื่อสารเป็นมาตรฐาน ระหว่างตัวแก้ไขโค้ดและ AI coding agent
• ก่อนหน้านี้ หากตัวแก้ไขแต่ละตัวต้องการเชื่อมต่อกับ agent ใด agent หนึ่ง จะต้องมี การผสานรวมแบบคัสตอมแยกต่างหาก ซึ่งก่อให้เกิดปัญหา ข้อจำกัดด้านความเข้ากันได้ และ การผูกติดนักพัฒนา
• ACP มอบวิธีการสื่อสารแบบมาตรฐานเช่นเดียวกับ Language Server Protocol (LSP) ทำให้เมื่อพัฒนาเชื่อมต่อครั้งเดียวแล้ว ก็สามารถเชื่อมต่อได้อย่างอิสระระหว่างตัวแก้ไขและ agent ที่เข้ากันได้ทั้งหมด
• ในตัวแก้ไข สามารถรัน agent เป็น subprocess และสื่อสารผ่าน JSON-RPC over stdio พร้อมรองรับองค์ประกอบ UI เช่น การแสดง diff และ เอาต์พุตแบบ Markdown
• ปัจจุบัน Zed, neovim(CodeCompanion plugin) รองรับ ACP แล้ว และฝั่ง agent ก็มี Gemini CLI ที่ใช้งานร่วมกันได้ โดยมีแผนจะขยายการรองรับต่อไป

---

บทนำ

• Agent Client Protocol (ACP) เป็น โปรโตคอลแบบเปิด ที่ออกแบบมาเพื่อทำให้ปฏิสัมพันธ์ระหว่างเซิร์ฟเวอร์และไคลเอนต์ เช่น การพัฒนาระยะไกล, port forwarding, การรันคำสั่ง เป็นต้น เป็นมาตรฐาน
• ปัญหาเดิม: แม้ AI coding agent และตัวแก้ไขจะเชื่อมโยงกันอย่างใกล้ชิด แต่ การทำงานร่วมกันได้ กลับไม่ได้รับการรับประกันโดยพื้นฐาน
  • ตัวแก้ไขแต่ละตัวต้องสร้าง การผสานรวมแบบคัสตอม สำหรับ agent ทุกตัวที่ต้องการรองรับ
  • agent เองก็ต้องพัฒนา API ของตัวแก้ไขแต่ละรายเพื่อให้เข้าถึงผู้ใช้ได้
  • สิ่งนี้นำไปสู่ ภาระในการผสานรวม, ความเข้ากันได้ที่จำกัด และปัญหา การพึ่งพาผู้ให้บริการสำหรับนักพัฒนา
• ทางออกของ ACP: ACP มอบ โปรโตคอลมาตรฐาน ระหว่าง agent และตัวแก้ไข
  • agent ที่พัฒนา ACP แล้วสามารถทำงานได้บนตัวแก้ไขที่เข้ากันได้ทั้งหมด
  • ตัวแก้ไขที่รองรับ ACP จะเข้าถึง ecosystem ของ agent ที่เข้ากันได้กับ ACP ได้ทั้งหมด
  • เปิดทางให้เกิด นวัตกรรมอย่างอิสระ และทำให้นักพัฒนาสามารถเลือกเครื่องมือที่เหมาะกับ workflow ของตนได้

ภาพรวมของ ACP

• วิธีการทำงาน: โดยทั่วไปผู้ใช้จะทำงานอยู่ใน ตัวแก้ไขโค้ด และเรียกใช้ agent สำหรับงานเฉพาะ
  • agent จะทำงานเป็น subprocess ของตัวแก้ไข
  • สื่อสารกันด้วย JSON-RPC ผ่าน stdio
• รูปแบบข้อมูล: นำรูปแบบ JSON ของ MCP มาใช้ซ้ำ และมี custom type สำหรับองค์ประกอบ UX ของการเขียนโค้ดด้วย agent เช่น การแสดง diff
• รูปแบบข้อความ: ใช้ Markdown เป็นค่าเริ่มต้นเพื่อให้อ่านง่าย
  • สามารถจัดรูปแบบได้หลากหลายโดยไม่ต้องเรนเดอร์ HTML
• แม้โปรโตคอลปัจจุบันยังอยู่ระหว่างการพัฒนา แต่ก็มีความสมบูรณ์เพียงพอสำหรับการสร้าง ประสบการณ์ผู้ใช้ที่น่าสนใจ

สถานะการรองรับในปัจจุบัน

• ตัวแก้ไข
  • Zed: รองรับ ACP ผ่านเอกสารอย่างเป็นทางการ
  • Neovim: ผสานรวม ACP ผ่าน CodeCompanion plugin
  • มีแผนรองรับตัวแก้ไขเพิ่มเติมในอนาคต
• Agent
  • Gemini: รองรับ ACP ผ่าน Gemini CLI
  • มีแผนรองรับ agent เพิ่มเติมในอนาคต

บทสรุป

• ACP ยึดแนวทางจากความสำเร็จของ LSP เพื่อยกระดับการทำงานร่วมกันระหว่าง AI coding agent และตัวแก้ไขอย่างมีนัยสำคัญ
• นักพัฒนาจะไม่ต้องผูกติดกับ agent หรือตัวแก้ไขใดตัวหนึ่งอีกต่อไป และสามารถเลือก ชุดเครื่องมือที่เหมาะสมที่สุด ได้อย่างอิสระ
• การขยายตัวของโปรโตคอลจะช่วยเพิ่ม ความสามารถในการขยายของ ecosystem และยกระดับทั้งประสิทธิภาพและความยืดหยุ่นของ workflow สำหรับนักพัฒนา

[GN⁺]

ความคิดเห็นใน Hacker News

• ลองขอให้ Claude สร้างโปรโตคอลการสื่อสารระหว่าง AI agent กับ IDE/ตัวแก้ไขให้หน่อย พร้อมทั้งพัฒนาไลบรารีสำหรับ Node, Python, Rust และสร้างเว็บไซต์ที่มีหน้า landing page ให้ด้วย

  • พูดตรง ๆ ว่าแอบอยากทดสอบว่า Gemini จะใช้ปลั๊กอิน Sublime Text ที่รองรับโปรโตคอลนี้ได้ไหม ช่วงหลังผู้ใช้ส่วนใหญ่เทไปทาง VSCode กันมากขึ้นเรื่อย ๆ จนเกิดแนวโน้มว่าเครื่องมือใหม่ ๆ จะรองรับแค่ฝั่งนั้น ไม่อยากถูกบังคับให้ย้ายเพียงเพราะเลิกซัพพอร์ต Sublime เพราะ Sublime เป็นเอดิเตอร์ที่ดีมากจริง ๆ และก็ไม่ได้มีบริษัทใหญ่หนุนหลังด้วย

  • และก็ดูเหมือนว่าจะทำให้มันกลายเป็น agent ที่รองรับเฉพาะ Gemini เพื่อกลบร่องรอยได้ด้วย

  • ตลกดี เป็นความอยากที่เห็นแก่ตัวมาก ๆ

• หวังว่าโปรเจ็กต์นี้จะไปได้สวยจริง ๆ Zed กำลังพากลับไปสู่แก่นแท้ของการทำงานร่วมกัน และกระแสนี้อาจเปลี่ยนหมวด agentic IDE ได้ด้วย แบบนี้ Zed ก็ไม่ต้องเสียเวลาไปกับการแข่งขันโดยตรงมากนัก และยังสร้างความแตกต่างได้ด้วย อยากรู้ว่าจะมีการยอมรับในหมู่ CLI agent มากแค่ไหน (แค่เห็น Gemini CLI เชื่อมได้แล้วก็น่ายินดี) การแข่งขันดุเดือดในตลาด LLM และ coding assistant เป็นสิ่งที่ยินดีต้อนรับเสมอ และคิดว่าการเปลี่ยนแปลงแบบนี้จะช่วยลดต้นทุนในการย้ายไปมาระหว่างกันลงเรื่อย ๆ

  • ฉันเองก็เกือบจะย้ายไป Zed แล้วเหมือนกัน มันมีฟีเจอร์ของเอดิเตอร์ที่อยากได้มาหลายปีเกือบครบหมดแล้ว แถมยังมีฟีเจอร์เจ๋ง ๆ ที่ไม่เคยนึกถึงอีกเยอะ เคยถึงขั้นผิดหวังกับสภาพเดิม ๆ จนลองทำต้นแบบเอดิเตอร์เอง แต่พอจะทำเอดิเตอร์ดี ๆ สักตัวจริง ๆ ต้องลงแรงมหาศาล และ Zed ก็เป็นคนลงแรงนั้นมาแล้ว ยินดีมากที่เห็นพวกเขาพยายามร่วมมือกันแบบเปิดกว้าง

  • พูดจากใจเลยว่าอยากให้การเปลี่ยนแปลงครั้งนี้เป็นจุดเริ่มให้ VS Code fork ห่วย ๆ หายไป และอยากให้ Zed ได้รับการยอมรับที่สมควรได้รับด้วย รู้สึกว่า AI editor ทั้งหลายแย่งออกซิเจนของวงการไปหมดแล้วจริง ๆ

• กำลังทำเครื่องมือให้ Claude Code ใช้ ACP ได้อยู่ (เพราะฉันใช้ CC กับ Zed บ่อย) ตอนนี้ทำมาได้ค่อนข้างดีด้วย Claude Code SDK กับไลบรารี ACP Client ยังมีส่วนที่ต้องเกลาอีกนิดหน่อย ตั้งใจว่าจะขัดให้เรียบร้อยขึ้นอีกหน่อยแล้วเปิดในวันพรุ่งนี้

• มี ACP ที่ชื่อ agentcommunicationprotocol.dev อยู่แล้ว เลยอาจทำให้ชื่อสับสนได้ แม้สองโปรเจ็กต์นี้จะต่างกัน แต่ก็เป็นจุดที่ชวนกังวล

  • เดือนมีนาคม 2025 IBM เปิดตัว Agent Communication Protocol (ACP) แต่ตอนนี้ตัดสินใจเลิกใช้ชื่อ ACP แล้ว และจะนำงานที่เกี่ยวกับ ACP ไปรวมกับโปรโตคอล Agent2Agent (A2A) ของ Google แทน การตัดสินใจนี้เกิดขึ้นท่ามกลางการยุบทีมพัฒนา ACP ทั้งหมด และแนวโน้มของอุตสาหกรรมที่กำลังหนุน A2A ภายใต้การนำของ Linux Foundation เพื่อหลีกเลี่ยงปัญหามาตรฐาน AI agent ที่แตกเป็นเสี่ยง ๆ และมุ่งไปรวมกันเป็นโอเพนโปรโตคอลที่ชุมชนขับเคลื่อน อ่านรายละเอียดได้ที่นี่

• สิ่งที่สงสัยที่สุดคือทำไม LSP server หรือการขยายโปรโตคอล LSP ถึงไม่สามารถครอบคลุมสิ่งที่ LLM ต้องการได้

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

• ฉันสบายใจกับการปฏิบัติต่อ AI เหมือนเป็นนักพัฒนามนุษย์จริง ๆ เช่น ขอให้มันทำฟีเจอร์ แก้บั๊ก หรือรีแฟกเตอร์ แล้วค่อยไปอ่าน commit ที่ได้ ถ้าไม่ชอบ commit นั้นก็ git reset --hard แล้วปรับปรุงพรอมป์ต์ก่อนสั่ง AI ใหม่ ฉันเรียกวิธีนี้ว่า "prompt coding" ไม่จำเป็นต้องมีการโต้ตอบโดยตรงระหว่างสภาพแวดล้อมการเขียนโค้ดของฉันกับ AI มันทำงานเหมือนนักพัฒนามนุษย์ที่ไม่ต้องมาแตะเอดิเตอร์ของฉันเลย คำอธิบายที่เกี่ยวข้อง

  • ช่วงนี้มีคนพูดกันว่าการเขียนพรอมป์ต์ดีขึ้นแล้ว แต่ฉันยังค่อนข้างสงสัย AI มีประโยชน์กับงานบางอย่างที่เฉพาะมาก ๆ ก็จริง แต่ก็ยังพูดเพ้อเจ้ออยู่เยอะ โดยเฉพาะเวลามันแต่งเรื่องที่ไม่มีจริงขึ้นมาอย่าง API แบบนั้นรับยากมาก

  • ฉันไม่ให้ AI เป็นคน commit ด้วยซ้ำ แทบทุกครั้งฉันต้องแก้ผลลัพธ์จาก AI หลายจุด การเสียเวลาไล่ reprompt ซ้ำ ๆ มันไม่คุ้ม ถ้ามันตอบไม่ตรงที่ต้องการตั้งแต่แรก ฉันก็เลือกแก้เองเลย ถ้ามันเข้าใจสิ่งที่ฉันต้องการตั้งแต่ต้นและให้โค้ดมาตรงใจจริง ๆ ตอนนั้นความเชื่อมั่นต่อ AI ก็จะสูงขึ้นมาก

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

• หวังมากว่า Anthropic จะนำโปรโตคอลนี้ไปใช้ใน Claude Code อย่างน้อยก็หวังว่าจะได้การเชื่อมต่อในระดับเดียวกับที่มีใน VSCode และอย่างน้อยที่สุดก็น่าจะเข้าถึงข้อมูลวินิจฉัยจากเอดิเตอร์ได้

• ตอนแรก MCP ก็เริ่มจาก JSON-RPC บน stdio เหมือนกัน พอมีสภาพแวดล้อมอย่าง GitHub Codespaces, devcontainers, และ "background agents" ก็เลยสงสัยว่าจะมีพัฒนาการแบบ JSON over SSE ตามมาหรือไม่ ตอนนี้สภาพแวดล้อมพัฒนาของฉันคือใช้ Claude Code บนเครื่องโลคัล ส่วนแอปรันอยู่ในคอนเทนเนอร์ และ agent ก็สามารถรัน docker compose exec backend ได้เองแบบอัตโนมัติ อุปสรรคของการเอาแนวทาง git worktree มาใช้คือการต้องแชร์ database engine (เพราะทรัพยากรเครื่องโลคัลไม่พอ) และเวลาในการทำ initial migration ซึ่งการโยนภาระพวกนี้ขึ้นคลาวด์ก็ดูเป็นสถานการณ์ที่น่าสนใจ

• หวังว่าโปรโตคอลแบบนี้จะแพร่หลายจนฉันไม่ต้องถูกผูกติดกับ IDE ตัวเดิมอยู่ตลอดไป