开头：发生了什么
过去 48 小时里，Agent 生态里最值得停下来想一想的不是某个新模型，而是 Skills 与 Harness 这一层同时进入了三个状态：被独立安全研究者拆穿、被大厂正式下注、被 OpenAI 摆上官方仓库。换句话说，这个本来只属于极客圈子的”技能包”层，已经悄悄从工具约定升级成了 agent 基础设施的中心层——而它的合约设计却还停留在 12 个月前的样子。
当一个层开始被所有人同时引用、却没人能解释它的安全边界时，真正的变化就不是”它终于统一了”，而是”它终于变得危险了”。
核心变化
四组几乎同时出现的信号，把 Skills / Harness 从”社区实验”推到了”必须被治理的中间层”：
- grith.ai 长文披露结构性安全漏洞：当前主流的
SKILL.md规范能定义技能的名字、长度上限、触发条件，但没有可移植的方式去限制一个 skill 内嵌的 Python / Bash / JS 能读哪些文件、起哪些进程、连哪些主机。换句话说，“安装一个 agent skill，几小时后就可能把你的 shell 拱手送人”并不是夸张，而是规范的天然结果。 - Tencent TeamAI CLI 开源：把团队的 skills、rules、MCP、knowledge 在 Claude Code、Codex、CodeBuddy、WorkBuddy、OpenCode、Cursor、Qoder 等多套 harness 之间统一同步——核心模式是”团队建一个共享 repo，每个 AI 会话自动 pull 最新 skills/rules”。腾讯正式下场，等于国产大厂承认了这一层的中心地位。
- OpenAI 官方 skills 仓库悄然进入 GitHub Trending Python 第四：与 anthropics/skills、mattpocock/skills、humanlayer/skills、NVIDIA/SkillSpector 一同构成 Skills 生态的中心层。当 OpenAI 自己的 skills 也作为公共仓库被引用时，”Skills 是私有协议”的退路就彻底没了。
- 独立维护者爆发 + supply-chain 防护方案出现：affaan-m/ECC（+1,905 today，单一维护者跨 7 大 harness 的 skills+agents 工具箱）、NousResearch/hermes-agent（+665）、coreyhaines31/marketingskills（+329）、ruvnet/ruflo（+392）——独立开发者已经把 Skills 当成产品来运营；同日 mise 的创建者 Jeff Dickey 推出 packslip（签名 release manifest），把版本化的 agent skills 与其描述的软件绑定，pin 版本 → 验签名 → 校验字节 → activation 改为 opt-in。
这四组信号合起来，是同一件事的不同侧面：Skills 已经从”开发者之间的约定”变成了”agent infra 的事实公共契约层”。问题是，这个契约本身没有沙箱。
为什么值得关注
过去一年里，AI 工程界逐步接受了一个判断：模型本身的差距在缩小，决定胜负的是模型周围的那一层——工具调用、上下文管理、记忆、权限、运行环境。如果再往前一步，这”周围的一层”正在进一步分层：模型层、Agent 框架层、Harness 层（Claude Code / Codex / OpenCode / Hermes 这类”运行 agent 的外壳”）、Skills 层（harness 加载的能力包）、MCP 层（工具与资源的标准化协议）。
在 2025 年中，大部分讨论还停在”模型 vs 模型”；到了 2026 年 9 月，已经没有人再争论 Skills 层是否存在——所有人都在争夺这一层的定义权：
- 独立维护者抢着做跨 harness 工具箱（ECC 同时支持 7 套 harness 是最直白的样本）。
- 国产大厂做团队级 Skills 共享（Tencent TeamAI CLI、阿里 Qoder、字节 deer-flow 都在做类似的事）。
- 官方做”中心仓库”（OpenAI 官方 skills 仓库、anthropics/skills、agentskills.io 兼容层）。
- 安全研究者开始拆解规范的结构性漏洞——不是某个 skill 写得不好，而是
SKILL.md这个合约本身无法区分”PDF formatter（只需 1 个输入文件）”和”deployment helper（需 cloud 凭证 + 网络 + 改 prod 配置权限）”。
这就是这一层值得被严肃对待的原因：它已经成了所有 agent 共同依赖的隐式 OS，但它的权限模型比 1990 年代的移动应用沙箱还粗糙。
对实际工作流的影响
对使用 agent 的人来说，今天之后有三件事需要立刻调整：
- 默认假设任何 skill 都可能被反安全化。grith.ai 的研究里写得最清楚的一句是：”绝大多数 skill 是善意的，但合约本身无法区分 PDF formatter 和 deployment helper。”这意味着高风险动作（删文件、跑 GPU 任务、提交 git、调外部 API）应该放到应用层把关，而不是信任 skill 自己声明的权限。
- 团队级 Skills 共享会变成标配。腾讯 TeamAI CLI 的产品架构是 Team Execution × Team Context × Team Improvement——一旦团队建一个共享 repo，每个 AI 会话自动 pull 最新 skills/rules，单人维护技能包的日子正在结束，未来半年里”AI 团队仓库”会和 Git workflow 一样变成默认配置。
- supply-chain 防护机制会快速跟进。packslip（签名 release manifest）、版本 pinning、签名验证、activation opt-in——这些词今天还只在 grith.ai 这种安全博客里出现，但参照 npm / pip / cargo 的历史，未来 6-12 个月里每一个主流 harness 都会内置类似机制。如果你的工作流已经把多个 skill 串起来，现在是补上”哪些 skill 能做哪些事”的清单的最佳时机。
我的判断
把这一连串信号叠在一起看，能看到一个清晰的拐点：
- 2024 年，Skills 还只是单家厂商（Anthropic）的一个实验性特性。
- 2025 年下半年，Skills 开始被多家 harness 兼容（Codex、OpenCode、Cursor、Gemini CLI 都先后支持）。
- 2026 年 9 月，Skills 同时进入了独立安全拆解 + 国产大厂正式下注 + OpenAI 官方仓库公开三状态——这是任何一项”中间层技术”成熟的标志，也是它必须被治理的起点。
换句话说，Skills 这件事已经赢了——它不再是一个可能被放弃的实验性特性，而是 agent infra 里的事实中心层。真正还没解决的是它如何被治理。参照 MCP 在 2024 年从”各家自定义”走到”跨厂商可互操作协议”的速度，Skills 沙箱标准化（类似 MCP 之于工具调用）的正式提案，可能在未来 2-4 周内就会出现，并且很可能由 OpenAI 与 Anthropic 联合推动。
对开发者来说，这一周最重要的不是装哪一个新 skill，而是重新审视自己已经装了哪些 skill、它们各自能做什么、谁在背后维护、有没有被签名。Skills 层已经从”装饰品”变成”地基”——而地基从来都是先出问题、再被加固的。