配了三年 AI coding tools，今天才发现插件写完只能在 IDE 里用——这件事被 Agent Plugins 1.0 彻底打破了

配了三年 AI coding tools，今天才发现插件写完只能在 IDE 里用——这件事被 Agent Plugins 1.0 彻底打破了

GitHub Copilot 的插件从来就是各玩各的。VS Code 里的插件没法拿到 CLI 用，CLI 里的插件跟 Copilot app 也不通。你要是想让自己写的工具在三个地方都能跑，得维护三套代码。这是 2026 年做 AI 编程工具的现实，直到上周 Agent Plugins 1.0 正式 GA。

一次构建，四个地方跑起来

8月12日，GitHub Copilot Agent Plugins 1.0 正式发布，官方覆盖了 VS Code、Copilot CLI、GitHub Copilot SDK 和 Copilot app 四个入口。换句话说，你写一个插件，四个消费者都能调用，不需要额外适配。官方把它定位成 plugin once, use everywhere——这话说得很直白，但确实是这次最核心的价值。

在这之前，GitHub Copilot 的扩展生态是割裂的。VS Code 插件走的是 VS Code 自己的扩展协议，CLI 走的是自己的插件机制，Copilot app 又是另一套逻辑。开发者要是想覆盖全部入口，要么写三套代码，要么只选一个入口放弃其他。Agent Plugins 1.0 用统一的插件 manifest 和调用协议把这三个入口捏在了一起。

Agent Plugins 1.0 能干什么

从官方文档和 changelog 来看，Agent Plugins 1.0 解决了三个实际问题：

第一，插件定义统一了。开发者通过一个 manifest 描述插件的能力、参数和返回值，Copilot 的各个端点都按同一套契约解析这个 manifest，不需要针对每个入口单独适配。

第二，Copilot app 的插件管理更直观了。8月25日的更新让插件管理页面 Customize tab GA 了，用户可以查看每个插件的版本号，单独更新或一键全量更新。这是插件生态走向成熟的信号——光有分发能力还不够，得有管理界面才能让用户真正用起来。

第三，Copilot CLI 那边补了子任务管理的能力。/tasks 可以管理所有子 agent 和它们的 Task，队列里可以排 prompt、shell 命令和支持的斜杠命令，同时支持 headless 模式下 –plan 加上 –mode autopilot 的组合，跑一个 agent 做计划然后执行。

实际场景是什么

举个例子。你写了一个企业内部代码审查插件，能调内部的 scan API、读 PR 上下文、输出修复建议。Agent Plugins 1.0 之前，如果你想让它同时在 VS Code 开发时、CLI CI 流水线里和 Copilot app 手机上看进度都能用，得写三套集成代码。现在你维护一套 manifest，在三个端点注册一次，就能全部覆盖。

这不是小改进。GitHub Copilot 现在的月活用户规模已经很大，插件生态的统一意味着一次开发，全链路覆盖真正成了可落地的工程目标，而不是社区里喊了两年还没实现的口号。

接下来怎么用

如果你已经在写 Copilot 插件，先确认你的 manifest 规范是否对齐了 1.0 的标准；如果还没写过但有想法，现在是最好的时间点——VS Code、CLI、app 三端同构的生态第一版已经 GA，平台红利还在。

Agent Plugins 1.0 的意义不只是一个版本号，是 GitHub 终于把 Copilot 从 IDE 里的补全工具往跨端 AI 工作流平台这个方向推了一把。