大家好！我是韩老师。
先说今天这篇有点不一样------不是我又翻了哪家公司的新闻来讲，而是这回的主角，是我自己参与做的一个东西。
事情是这样的：今天 GitHub 和 JetBrains 几乎同一时间，各自发了一条官宣，说的是同一件事------GitHub Copilot 现在正式成为 JetBrains AI Assistant 的原生默认 Agent 之一。这背后那条把 Copilot 接进 JetBrains 的"管道"，正是我手上做的活儿。
先看视频一睹为快：
GitHub Copilot 正式成为 JetBrains AI Assistant 的原生默认 Agent 之一
下面是 GitHub 和 JetBrains 的官宣：
Copilot Agent is now available in JetBrains AI Assistant - GitHub Changelog
https://blog.jetbrains.com/ai/2026/06/github-copilot-now-an-integrated-agent/
被一家大厂官宣已经够让人有点恍惚了，两家在同一天一起官宣同一个功能，这种感觉确实有点上头。但激动归激动，今天我还是想认真把这件事讲清楚：它到底是什么，为什么值得做，以及对你这个每天在 IDE 里写代码的人，意味着什么。
先把背景补齐：Copilot 早就在 JetBrains 里了，那这次到底新在哪？
很多用 IntelliJ、PyCharm、GoLand 的同学会问：我装 GitHub Copilot 插件不是好几年了吗，天天用，这有啥好官宣的？更懂行的还会补一句：Copilot 不是早就能在 AI Assistant 里用了吗？
两个都问得对。所以得把"新"到底新在哪，掰开说清楚。
先理清这里其实有三条路：
- GitHub Copilot 独立插件：你用了好几年的那个，补全、聊天，照旧用，这次不受影响。
- 以前：通过 ACP Registry 手动装进 AI Assistant。其实 Copilot 早就能在 JetBrains AI Assistant 里用了------但你得自己去 ACP Registry 把它当成一个第三方 ACP Agent 装进来。能用，但属于"知道的人才会去折腾"的进阶玩法。
- 现在：成为原生默认 Agent 之一。这次的变化是------Copilot 不用你再去 Registry 手动装了，它直接出现在 AI Assistant 的 Agent 选择器里，跟 JetBrains 官方自带的那些 Agent 摆在一起，默认就在那儿，开箱即选。
所以这次官宣的分量，不在于"Copilot 第一次进 AI Assistant"------那早就能干了；而在于它从一个需要手动安装的第三方选项，升格成了默认就在桌上的一等公民。从"装得进来"到"默认就在"，差的这一步，正是这篇想讲的东西------ACP。
一句话讲清 ACP
ACP（Agent Client Protocol）是一套标准，规定"代码编辑器"和"AI 编程 Agent"之间该怎么对话。
用一个类比快速过一遍，方便跟上：
- LSP - 解决「编辑器 ↔ 语言能力」：一个 language server 写一次，VS Code、Neovim、JetBrains 都能用。
- MCP - 解决「Agent ↔ 外部工具/数据」：Agent 想读数据库、调 API，统一走 MCP。
- ACP - 解决的是中间那层「Agent ↔ 编辑器」：Agent 作为一个独立进程跑着，编辑器只负责把用户输入递过去、把 Agent 吐出来的东西（对话、代码 diff、计划、预览）渲染出来。
它最早由 Zed 编辑器团队发起，JetBrains 也很早就深度参与其中------思路和 LSP 一脉相承：把"谁来实现 Agent"和"谁来展示 Agent"彻底解耦。 也正因为 JetBrains 从一开始就在这条船上，这次它把 Copilot 提为原生默认 Agent，才显得顺理成章------它不是临时接了个外部协议，而是在兑现自己早就押注的方向。
为什么这件事重要？因为在 ACP 之前，"让 Copilot 出现在 JetBrains 里"这种事，本质是一次专门的定制集成：Copilot 团队要为 JetBrains 的界面、生命周期、API 单独写一套对接代码；换个编辑器，再写一套。这就是典型的 N×M 胶水------N 个 Agent 乘以 M 个编辑器，谁都累。
而有了 ACP，事情变成了：Copilot 只要把自己实现成一个标准的 ACP Agent，任何支持 ACP 的编辑器都能把它接进去，不用我为每个编辑器单独适配。 这正是我这边在做的事------让 Copilot 学会说 ACP 这门"普通话"。
这次官宣，具体宣了什么
JetBrains 那条公告里，把这次更新拆成了三点，我按重要性给你重排一下：
第一，GitHub Copilot 成为原生默认 Agent。 在 AI Chat 里打开 Agent 选择器，选 GitHub Copilot，当前这轮对话就交给它了。这是"一等公民"那一步。
第二，Copilot 的模型可以直接切换。 你能在 AI Chat 里选支持的 Copilot 模型，还能调整推理深度（reasoning depth）------简单任务用快的、便宜的，复杂任务往深里推。在速度、深度和成本之间自己找平衡，这件事终于不用切来切去了。
第三，支持真正的多步骤编码任务。 这是 Agent 和"高级补全"的本质区别：你把一个复杂任务丢给 Copilot，它能基于你的工程去推理、提改动建议、执行命令，然后和你来回迭代，直到把活儿干完------而不是给你一段代码就完事。
GitHub 那边的官宣口径和这个是对齐的：Copilot 作为一个标准 ACP Agent，正在走出"只在自家产品里"的边界，开始出现在更多它本身没有深度定制过的编辑器里------JetBrains 是这条路上很关键的一站。
为什么"JetBrains 把 Copilot 设为默认"是个信号
单看功能，这是 AI Assistant 多了一个默认可选的 Agent。但放到行业里看，它在确认一件正在发生的事：Agent 和 IDE 的连接方式，正在标准化。
这里有意思的地方在于 JetBrains 的双重身份。它自己是有 AI 野心的------有 AI Assistant，有自家的 Junie，完全可以走"只推自家 Agent"的封闭路线；同时它又是 ACP 的共建者之一，亲手参与定义了这套开放协议。一家既想做强自家 Agent、又深度参与开放标准的公司，最后选择把 Copilot 这种"竞品阵营的 Agent"设成原生默认------这本身就是一种表态：它赌的不是"我家 Agent 一定最强"，而是"开放的连接方式一定会赢"。
说得再直白一点：判断一个协议会不会赢，最硬的指标是------那些最有动机自成一派的玩家，愿不愿意上这条船。 JetBrains 本可以只玩自己，结果它不但亲手在建，还把竞品请进了自家默认位。一个从编辑器侧长出来的开放协议，正被这样一批本可以自成一派的公司推着往前走，这比任何官方背书都有说服力。
对我个人来说，做这件事最有意思的地方也在这儿：我不是在帮 Copilot 多打通一个编辑器，而是在帮它从"绑定在某个产品里的功能"，变成"一个能插进任何 ACP 宿主的独立 Agent"。 通了 JetBrains，下一个就是任何愿意说 ACP 的地方。一次实现，到处接入------这正是当年 LSP 给语言生态带来的那种杠杆。
它具体怎么用
讲了半天协议，落到手上其实很简单。如果你是 JetBrains 用户，今天就能试：
- 更新到支持的 JetBrains IDE 版本，装好（或更新） AI Assistant。
- 打开 AI Chat，点 Agent 选择器，在列表里选 GitHub Copilot，把当前对话切给它。
- 挑模型、调推理深度：在 AI Chat 里选一个支持的 Copilot 模型，简单任务用轻量档，复杂任务往深里调。
- 丢一个真任务给它：别只拿它当补全。给它一个"改一处逻辑 + 跑测试 + 修到通过"这种多步骤任务，感受一下 Agent 和补全的差别。
接下来会发生什么
JetBrains 和 GitHub 公告里也给了 roadmap，几个点我挺期待：
- NES（Next Edit Suggestions）：预测你"下一步最可能改哪儿"，让多步骤改动更顺。
- Skills：把可复用、专业化的能力模块做成能随手调用的东西，高频流程更一致。
- 更深的多工具编排：进一步提升 Copilot 在 IDE 里规划、执行、迭代复杂任务的能力。
这些背后大多和 ACP 这条通道能传多少信息、能力边界开到多大有关------也就是我接下来要继续啃的地方。
写在最后
被 GitHub 和 JetBrains 同一天官宣，对我是个挺特别的纪念。但比"上了官宣"更让我觉得值的，是这件事背后的那个判断正在被验证：Agent 不该被焊死在某一个编辑器里，编辑器也不该被绑死在某一个 Agent 上。 中间那层用一个开放协议解耦掉，所有人都能受益。
JetBrains 把 GitHub Copilot 请进了默认位，而 GitHub Copilot 这边 ACP 的活儿，刚好是我在做。能在这条正在成形的路上添一块砖，挺好。
如果你在 JetBrains 里写代码，今天就去 Agent 选择器里把 GitHub Copilot 点出来试试------这回，它是"原生"的了。