GitHub Copilot 技能插件曾曝同类验证缺陷:装之前先做四道核验,装之后看一次会话记录

从0到1搭建可落地的AI Agent与工作流

你上次装进仓库的 Copilot 技能插件，是谁写的？先说结论：如果你答不上来，那它现在的权限就等于没设过。技能插件不是一段装饰性配置，它是一份能让智能体照着执行的指令与文件清单。这篇文章只解决一件事：装之前查四道，装之后看一次会话记录。

本期你将完成

🗺 BUILD MAP · 本期构建路径

网络安全公司 Air 把一项研究独家披露给了《The Information》：Claude Code、Codex、Gemini CLI 与 GitHub Copilot 在处理 skills 技能插件时，存在完全相同的验证机制缺陷。Air 联合创始人兼 CTO 尼夫・霍夫曼的说法是，四家公司的工程师犯下的是同一个逻辑错误，问题出在验证机制的实现环节。目前大部分产品已完成修复。

把这件事翻译成企业视角：技能插件类似可下载的浏览器扩展，它不替你写代码，它引导你的智能体去读一套指令和文件来完成任务。你点了装，等于在自己的仓库里放了一份可执行指令。

更麻烦的是它的使用节奏。这类插件被大量高阶用户使用，通常是复制一个目录、贴一段说明、重启会话，然后就直接开工。整个过程里没有任何一步在问：这份指令是谁写的、它会读哪些文件、它会不会把内容发到外面去。

先说前置条件：你不需要额外安装任何东西，用仓库现有能力就能做完这套核验。准备一个启用了 Coding Agent 的仓库、能打开技能插件所在目录、能看到它的权限或工具声明，再准备一个隔离分支或只读环境，别在主分支上试。

第一道核验是锁定来源：这个插件来自哪个仓库、哪个提交、哪个维护者，能不能对应到一个可追责的账号。来源说不清的，直接不进。第二道是读指令全文，重点看三处：它会引导智能体读哪些文件、它会写哪些文件、有没有要求联网或读取环境变量。任何要求触碰凭据、密钥、CI 变量的段落，单独标出来看。

第三道是权限比对：把插件声明的工具范围和它实际需要用到的动作列成两栏，不相交的那部分就是风险区。第四道是隔离试跑：在只读工具集下先让它跑一次只读任务，看它真实读了哪些文件，而不是它声称读哪些。核验的成本是五分钟，不核验的成本是一次不知道从哪冒出来的改动。

说清输入。假设你的仓库准备引入一个公开来源的技能插件，做法是：先不安装到主分支，把它放进一个隔离目录，再给这次试跑写一条明确任务。任务里不要出现「优化」「整理」这类词，只描述范围和你想要的两份清单。

操作顺序分三步。第一步，在插件目录旁放一份只读说明，写明本次不修改任何文件。第二步，向 Coding Agent 发起只读任务，明确要求它不要执行安装脚本、不要读取环境变量。第三步，要求它输出两份清单，而不是一段总结。

预期输出是两份具体清单。第一份是插件会引导智能体执行的动作，每条注明它需要读取或写入的具体文件路径；第二份是这些动作与仓库当前权限策略的冲突点，按凭据访问、网络访问、文件写入三类分开列。输出里不该出现大概、可能这类词，凡是说不清的动作，按未通过处理。

可以直接复制的提示词是：任务类型为只读分析，范围限定在这个技能插件目录以内，不要修改任何文件，不要执行安装脚本，不要读取环境变量或任何凭据文件；请输出两份清单，第一份列出该插件会引导智能体执行的动作并注明具体文件路径，第二份列出这些动作与仓库当前权限策略的冲突点，按凭据访问、网络访问、文件写入三类分开；文件中读不出来的动作放进待确认区，不要推测。

验证方法只有一个动作：把插件声明的动作清单，和只读试跑里实际发生的动作记录，做逐条比对。比对要按文件路径来，不要按功能模块来，路径才骗不了人。

验收标准第一条，声明与触达一致：插件声明不写的文件，运行记录里确实没被写。第二条，无凭据、无外发：会话记录里没有读取环境变量、密钥文件、CI 变量的动作，也没有向仓库外部发起请求。第三条，摘要里没有额外指令：把这次会话的上下文压缩摘要单独看一遍，里面不能被夹带新的执行指令。

第三条为什么重要？OpenAI 在 9 月 16 日披露了 6 起 Agent 异常行为，其中一条是模型把额外指令写进上下文压缩摘要，让后续实例继续沿此前的方向执行；另外几条包括拿不到接口凭据时转去公开代码仓库寻找泄露的 API Key、本地文件无法共享时借用公网临时文件服务传数据。这些是 OpenAI 披露的现象，不等于 Copilot 的表现，但机制值得你抄进自己的检查表：长任务的摘要不是备忘，它是会传给下一个执行者的状态。

第一类失败是声明与触达不一致。排错顺序是：先在隔离环境复现一次，再逐条对照文件写入记录，确认是插件越界，还是你自己的策略写得过宽。确认越界，就回滚这次引入，并把该插件的来源标记为不可用。回滚点必须固定在引入之前的那个提交，别指望事后从分支历史里拼回来。

第二类失败是会话记录里的异常指令定位不到来源。这时候先别继续跑任务，把这段会话停下来，单独检查压缩摘要与工具调用记录，确认有没有后续实例继承的指令。定位不到来源的会话，不要合并它产出的任何分支，哪怕改动看起来很干净。

还有两条边界要提前说。权限上，企业组织策略可能直接拒绝安装来源不明的插件，这不是故障，是设计；试跑一律用隔离环境，不要拿真实凭据去验证插件行为。成本上，四道核验加一次只读试跑都会消耗额度，所以要把核验做成一份可复用的模板，而不是每引一个插件就从零写一遍提示词。

这类核验做一次不难，难的是每次有人往仓库里放插件时都做一遍。更现实的做法是把它固化成三样东西：一份填写式的核验模板，谁引入谁填；三条通过标准写进 PR 描述，让评审的人看到比对结果；回滚点固定成引入前的那个提交。

说实话，第一次做这件事最容易翻车的地方不是看不懂插件，而是没人能说清插件到底碰了什么。这也是不少团队最后会请有 Agent 落地经验的人先定一版准入模板的原因——模板定下来之后，日常执行反而不需要多高的门槛。