- Agent Client Protocol (ACP) là một giao thức nhằm chuẩn hóa giao tiếp giữa trình soạn thảo mã và các tác nhân AI hỗ trợ lập trình
- Trước đây, để mỗi trình soạn thảo có thể kết nối với một tác nhân cụ thể, cần có tích hợp tùy biến riêng; điều này dẫn đến giới hạn tương thích và vấn đề khóa chặt nhà phát triển
- Tương tự như Language Server Protocol (LSP), ACP cung cấp một phương thức giao tiếp chuẩn hóa, để chỉ cần triển khai một lần là có thể kết nối tự do giữa mọi trình soạn thảo và tác nhân tương thích
- Trình soạn thảo chạy tác nhân dưới dạng tiến trình con và giao tiếp bằng JSON-RPC over stdio; giao thức cũng hỗ trợ các thành phần UI như hiển thị diff và đầu ra dựa trên Markdown
- Hiện tại Zed, neovim (plugin CodeCompanion) đã hỗ trợ ACP; phía tác nhân có Gemini CLI tương thích, và phạm vi hỗ trợ sẽ tiếp tục được mở rộng
Giới thiệu
- Agent Client Protocol (ACP) là một giao thức mở được thiết kế nhằm chuẩn hóa các tương tác client-server như phát triển từ xa, chuyển tiếp cổng, thực thi lệnh, v.v.
- Vấn đề hiện tại: tác nhân AI hỗ trợ lập trình và trình soạn thảo có mối liên kết chặt chẽ, nhưng khả năng tương tác không được đảm bảo mặc định
- Mỗi trình soạn thảo phải xây dựng tích hợp tùy biến cho từng tác nhân mà họ muốn hỗ trợ
- Tác nhân phải triển khai API của từng trình soạn thảo cụ thể mới có thể tiếp cận người dùng
- Điều này gây ra chi phí tích hợp, khả năng tương thích hạn chế và vấn đề phụ thuộc vào nhà cung cấp
- Giải pháp của ACP: ACP cung cấp giao thức chuẩn hóa giữa tác nhân và trình soạn thảo
- Tác nhân triển khai ACP có thể hoạt động trên mọi trình soạn thảo tương thích
- Trình soạn thảo hỗ trợ ACP có thể tiếp cận toàn bộ hệ sinh thái tác nhân tương thích ACP
- Điều này cho phép đổi mới độc lập, đồng thời giúp nhà phát triển chọn công cụ tối ưu cho quy trình làm việc của mình
Tổng quan về ACP
- Cách hoạt động: người dùng chủ yếu làm việc trong trình soạn thảo mã, rồi gọi tác nhân khi cần xử lý một tác vụ cụ thể
- Tác nhân chạy dưới dạng tiến trình con của trình soạn thảo
- Giao tiếp bằng JSON-RPC thông qua stdio
- Định dạng dữ liệu: tái sử dụng định dạng JSON của MCP, đồng thời có thêm các kiểu tùy chỉnh cho trải nghiệm lập trình với tác nhân như hiển thị diff
- Định dạng văn bản: mặc định sử dụng Markdown để tăng khả năng đọc cho người dùng
- Có thể tạo định dạng phong phú mà không cần render HTML
- Giao thức hiện vẫn đang được phát triển, nhưng đã đủ hoàn thiện để xây dựng những trải nghiệm người dùng hấp dẫn
Tình trạng hỗ trợ hiện tại
- Trình soạn thảo
- Tác nhân
- Gemini: hỗ trợ ACP qua Gemini CLI
- Sẽ có thêm hỗ trợ cho các tác nhân khác
Kết luận
- ACP kế thừa bài học thành công của LSP để cải thiện mạnh mẽ khả năng tương tác giữa tác nhân AI hỗ trợ lập trình và trình soạn thảo
- Nhà phát triển không còn bị ràng buộc vào một tác nhân hay trình soạn thảo cụ thể, mà có thể tự do lựa chọn tổ hợp công cụ tối ưu
- Việc mở rộng giao thức sẽ nâng cao khả năng mở rộng của hệ sinh thái, đồng thời tăng hiệu quả và tính linh hoạt của quy trình làm việc dành cho nhà phát triển
1 bình luận
Ý kiến trên Hacker News
Tôi từng nghĩ đến việc nhờ Claude tạo ra một giao thức liên lạc giữa AI agent và IDE/trình soạn thảo, đồng thời phát triển luôn các thư viện cho Node, Python, Rust, thậm chí dựng cả một website có landing page
Thành thật mà nói, tôi khá bị cám dỗ muốn thử xem Gemini có dùng được plugin Sublime Text triển khai giao thức này hay không. Dạo gần đây hầu hết người dùng đều đang đổ dồn về VSCode, nên các công cụ mới có xu hướng chỉ hỗ trợ bên đó. Tôi không muốn bị ép phải chuyển đi chỉ vì Sublime không còn được hỗ trợ nữa; Sublime thật sự là một trình soạn thảo rất tốt, mà cũng không phải sản phẩm được chống lưng bởi một công ty khổng lồ
Và cũng có thể làm nó thành một agent chỉ hỗ trợ Gemini để che giấu dấu vết
Buồn cười thật, đúng là một mong muốn quá tự lấy mình làm trung tâm
Tôi rất mong dự án này thành công. Zed đang quay trở lại với bản chất của sự cộng tác, và có vẻ xu hướng này cũng có thể tạo ra thay đổi cho cả nhóm IDE agentic. Như vậy Zed sẽ không cần tốn thời gian cạnh tranh trực diện mà vẫn tạo được khác biệt. Tôi cũng tò mò mức độ được chấp nhận của nó trong giới CLI agent sẽ ra sao (thấy Gemini CLI đã tích hợp rồi cũng khá vui). Sự cạnh tranh khốc liệt trong thị trường LLM và trợ lý lập trình lúc nào cũng đáng hoan nghênh; tôi nghĩ những thay đổi kiểu này sẽ liên tục làm giảm chi phí chuyển đổi giữa các công cụ
Tôi cũng gần như sắp chuyển hẳn sang Zed rồi; nó có gần như mọi tính năng tôi mong muốn ở một trình soạn thảo suốt nhiều năm qua, lại còn có nhiều tính năng hay ho mà tôi chưa từng tưởng tượng tới. Tôi từng thất vọng với hiện trạng đến mức tự làm thử một bản mẫu trình soạn thảo, nhưng để tạo ra được một editor tốt thực sự đòi hỏi rất nhiều công sức. Zed đã bỏ ra công sức đó. Tôi hoan nghênh nỗ lực hợp tác cởi mở của họ
Tôi nói thật lòng, hy vọng thay đổi này sẽ là dịp để các bản fork VS Code cẩu thả biến mất bớt. Zed cũng xứng đáng nhận được sự công nhận tương xứng. Cảm giác như các AI editor đang hút hết oxy của cả ngành vậy
Tôi đang làm một công cụ để Claude Code có thể dùng ACP (vì tôi dùng CC và Zed khá thường xuyên). Cho đến giờ mọi thứ tiến triển khá ổn với Claude Code SDK và thư viện ACP Client. Vẫn còn vài chỗ cần chỉnh sửa, nhưng tôi định mài giũa thêm một chút rồi ngày mai sẽ mở mã nguồn
Đã có một ACP mang tên agentcommunicationprotocol.dev, nên cái tên này có thể gây nhầm lẫn. Dù hai dự án có khác nhau, đây vẫn là điều khiến tôi bận tâm
Điều tôi tò mò nhất là tại sao không thể bao phủ các nhu cầu của LLM bằng cách dùng LSP server hoặc mở rộng giao thức LSP
Tôi thấy thoải mái hơn khi đối xử với AI như một lập trình viên thật. Ví dụ, tôi yêu cầu AI triển khai tính năng, sửa bug hoặc refactor, rồi đọc các commit kết quả. Nếu không thích commit đó, tôi sẽ
git reset --hard, cải thiện prompt rồi giao lại cho AI. Tôi gọi cách này là “prompt coding”. Tôi không cần có sự tương tác trực tiếp giữa môi trường lập trình của mình và AI; nó làm việc như một lập trình viên con người, không đụng vào editor của tôi giải thích liên quanDạo này người ta nói viết prompt tốt hơn, nhưng tôi hơi nghi ngờ điểm đó. AI đúng là hữu ích cho một số tác vụ rất cụ thể, nhưng nó vẫn nói nhảm khá nhiều, đặc biệt là chuyện bịa ra những thứ không tồn tại như API thì rất khó chấp nhận
Tôi không để AI tự commit. Gần như lúc nào tôi cũng phải sửa nhiều chỗ trong kết quả của AI. Tôi thấy tiếc thời gian nếu cứ phải lặp lại việc reprompt, nên nếu nó không đưa ra thứ tôi muốn ngay từ đầu thì tôi thường tự sửa luôn. Nếu ngay từ đầu nó đã hiểu đúng điều tôi cần và đưa ra đoạn mã phù hợp, lúc đó niềm tin của tôi vào AI sẽ tăng lên nhiều
Tôi hy vọng ý tưởng này sẽ lan rộng hơn. Có một điều tôi thắc mắc là khác biệt giữa việc tìm kiếm file và các file chưa lưu. Trên thực tế, các agent thường dùng những thứ như ripgrep để tìm trong hệ thống file, nhưng vấn đề là nếu giao thức cho phép đọc và ghi cả các file chưa lưu thì độ chính xác sẽ gặp vấn đề, vì ripgrep không thể tìm trong các file chưa lưu
Tôi rất mong Anthropic đưa giao thức này vào Claude Code, ít nhất là đạt mức tích hợp như đang có trong VSCode. Và sẽ rất tuyệt nếu ít nhất agent có thể truy cập được thông tin chẩn đoán của editor
MCP ban đầu cũng khởi đầu bằng JSON-RPC chạy trên stdio. Với sự xuất hiện của các môi trường như GitHub Codespaces, devcontainers, hay “background agents”, tôi cũng tự hỏi liệu có thể sẽ có bước tiến kiểu JSON over SSE hay không. Hiện tại môi trường phát triển của tôi là dùng Claude Code trên máy cục bộ còn ứng dụng chạy trong container; agent có thể tự chủ chạy
docker compose exec backend. Trở ngại để áp dụng quy trình làm việc với git worktree là việc chia sẻ database engine (do thiếu tài nguyên cục bộ) và thời gian migration ban đầu. Đưa phần gánh nặng đó lên cloud cũng là một kịch bản khá thú vịTôi hy vọng những giao thức như thế này sẽ trở nên phổ biến để tôi không còn phải luôn bị trói vào một IDE duy nhất nữa