大家好！我是韩老师。
之前提到了 GitHub Copilot 正式成为 JetBrains AI Assistant 的原生默认 Agent 之一。当时我重点讲的是：GitHub Copilot 不再只是一个需要单独安装和切换的插件，而是可以作为原生 Agent，直接运行在 JetBrains AI Assistant 里。
但 ACP 的力量远不止于此。
现在，通过 ACP（Agent Client Protocol），GitHub Copilot 又跑进了 JetBrains Air。不是重新给 Air 做一套专用集成，也不是把某个 IDE 插件硬塞进去，而是同一个 GitHub Copilot Agent，通过一套标准协议，接入了另一个全新的开发环境。
Demo：
这件事看起来只是“Air 多了一个 Agent”，背后其实指向了一个更大的变化：AI 编程 Agent 正在从某个编辑器里的功能，变成可以在不同宿主之间流动的独立能力。
ACP 到底厉害在哪
一句话解释：ACP 是一套用来连接代码编辑器和 AI 编程 Agent 的开放协议。
如果你熟悉 LSP，可以把它理解成类似的思路。LSP 让同一个 language server 可以服务不同编辑器；ACP 则让同一个 Agent 可以进入不同的开发环境。编辑器负责界面、代码展示和交互，Agent 负责理解任务、调用工具、修改代码和推进工作。
没有 ACP 时，一个 Agent 想支持多个编辑器，通常要分别对接每个产品的 API、界面和生命周期。Agent 越多、编辑器越多，中间的适配代码就越多。
有了 ACP，双方只需要对齐同一套协议：
- Agent 实现一次 ACP，就能被不同的 ACP Client 接入；
- 编辑器支持一次 ACP，就能容纳不同团队做的 Agent；
- 用户可以留在熟悉的开发环境里，自由选择更适合当前任务的 Agent。
这才是协议真正的杠杆。它解决的不是“再加一个下拉选项”，而是把 Agent 和 IDE 之间原本一对一的绑定关系拆开。
GitHub Copilot 支持 ACP，是一个很明智的选择
GitHub Copilot 已经拥有 VS Code、Visual Studio、JetBrains IDE 等成熟入口。站在产品视角，继续围绕这些自家或深度合作的入口做体验，当然是最稳妥的路线。
但支持 ACP，意味着 GitHub Copilot 又往前走了一步：它不再只依赖某一个插件外壳，而是能够以 Agent 的形态进入任何支持 ACP 的 Client。
前一篇文章里，它成为 JetBrains AI Assistant 的原生默认 Agent；这一次，它又进入了 Air。以后出现新的 ACP Client，也不必每次都从零造一套集成。一次实现，多处运行，这正是开放协议最有价值的地方。
对 GitHub Copilot 来说，这也是一个很明智的生态选择。未来真正稀缺的可能不再是“某个编辑器里有没有 AI”，而是用户能不能在不同工作环境中，继续使用同一个熟悉、可靠、拥有完整能力的 Agent。
谁更早成为标准生态里可复用的一等公民，谁就更容易出现在下一代开发工具里。
为什么我推荐在 Air 里试 GitHub Copilot
Air 这次发布不只加入了 Java language support，还开放了通过 ACP 添加 Agent 的入口。GitHub Copilot、OpenCode，以及其他兼容 ACP 的 Agent，都可以被接进来；本地模型也能通过相应的 Agent 配置运行。
这让 Air 变成了一个很直观的 ACP 体验场：左边是任务，中间是 Agent 对话，右边是代码；底部的 Agent 选择器则把不同 Agent 放在同一个工作流里。你不需要为了比较 Agent 来回换编辑器，也不用改变项目本身。
我尤其推荐先试 GitHub Copilot。原因很简单：很多开发者本来就有 GitHub Copilot 订阅和使用习惯，模型选择、账号权限和 Agent 能力也已经比较完整。现在只需要补一段 ACP 配置，就能把这套能力带进 Air。
四步把 GitHub Copilot 接进 Air
开始前，先确认本机已经安装 Node.js，终端里可以使用 npx；你的 GitHub 账号也需要具备可用的 GitHub Copilot 权限。
第一步：添加一个 ACP Agent
打开 Air，在底部的 Agent 选择器中点击 Add ACP Agent...。
Air 会打开它的 acp.json。这个文件就是 ACP Agent 的启动清单：每个条目告诉 Air，要用什么命令启动对应的 Agent。
第二步：写入 GitHub Copilot 配置
把下面这段配置放进 acp.json：
{ "agent_servers": { "GitHub Copilot npx": { "command": "npx", "args": [ "@github/copilot-language-server", "--acp" ] } }}
这里真正关键的是 --acp。它让 @github/copilot-language-server 以 ACP Agent 的方式启动，Air 则作为 ACP Client 与它通信。
名称可以按自己的习惯修改，command 和 args 则决定实际启动哪个 Agent。GitHub Copilot 之外，其他 ACP Agent 也是同样的思路：按照对方文档，把对应的启动命令和参数写进 agent_servers 即可。
第三步：登录 GitHub
保存配置后，回到 Agent 选择器，选择刚添加的 GitHub Copilot。第一次使用时，Air 会显示 Authentication required，点击 Sign in with GitHub 完成授权。
认证完成后，GitHub Copilot 就不再是配置文件里的一段命令，而是 Air 当前任务中真正可用的 Agent。
第四步：选择模型，直接开始干活
现在可以在 GitHub Copilot 的模型列表中选择 Auto，也可以指定账号当前可用的模型，然后直接给它一个真实的编码任务。
别只问一句“你是谁”。更适合的测试方式，是让它读当前 Repo、修改一处代码、运行测试，再根据结果继续修。这样才能看出 ACP 传递的不只是聊天文本，而是一整套 Agent 工作流。
真正值得关注的，不是又多了一个入口
今天是 GitHub Copilot 进入 Air，明天可能是更多 Agent 进入更多开发环境。
对开发者来说，这意味着选择权。你可以选择喜欢的编辑器，也可以选择擅长当前任务的 Agent，不必接受两者被强行捆绑。
对编辑器来说，这意味着不必独自做完所有 AI 能力。把 ACP Client 做好，就能接入快速增长的 Agent 生态。
对 Agent 团队来说，这意味着一次实现不再只服务一个入口。新宿主出现时，只要它支持 ACP，Agent 就有机会直接进入，而不是重新排期做一轮专用集成。
所以，GitHub Copilot 支持 ACP 的意义，不只是“现在能在 Air 里用了”。更重要的是，它选择把自己做成一个可以被不同开发环境承载的 Agent。
这条路很像当年的 LSP：一开始只是少写几份适配代码，后来改变了整个工具生态的协作方式。
现在就可以试
如果你已经在用 Air 和 GitHub Copilot，可以直接按这四步操作：
- 在 Air 的 Agent 选择器中点击 Add ACP Agent...；
- 把 GitHub Copilot 的
npx 启动配置写入 acp.json； - 选择 GitHub Copilot，并完成 GitHub 登录；
- 选一个模型，交给它一个需要读代码、改代码和跑命令的真实任务。
配置只要几分钟，但它展示的是一件更长远的事：Agent 不必属于某一个 IDE，IDE 也不必只服务某一个 Agent。
这就是 ACP 的力量。
推荐阅读：
