OpenAI、Anthropic、Gemini，哪些概念已经开始统一？
OpenAI, Anthropic, Gemini: which concepts are converging?前两篇一直在研究 Skill。顺着查下去，我发现 OpenAI、Claude、Gemini 的 Agent 产品里，开始反复出现一些很像的东西：
Skill、MCP、Plugin / Extension、Hooks、Subagents，还有 AGENTS.md、CLAUDE.md、GEMINI.md。
一开始很容易陷进名词里。后来把它们放在一起看，我觉得更有意思的是：
越基础、越需要跨工具复用的能力，越开始走向统一；越往上走到怎么组合、怎么安装、怎么管理，三家反而还保留着自己的做法。
已经真正开始统一的：Skill 和 MCP
目前最明确的两个例子是 Skill 和 MCP。
它们都来自 Anthropic，但后来都走向了开放标准。
Skill：把一类事情的做法保存下来
Skill 解决的是：
这类任务，AI 应该怎么做？
最基本是一份 SKILL.md，复杂一点还可以带 references、scripts、assets。
前面拆过的 make-photo-stamp-archive 就是一个很简单的例子：作者把构图、印章选择、不能修改的东西、最后怎么检查等设计方法整理成 Skill。
现在 Claude Code、Codex、Gemini CLI 都已经支持 Agent Skills。
这意味着同一套做事方法，开始可以跨 Agent 使用。
当然，同一个 Skill 不代表三家最后产出的结果一定一样。
例如图章 Skill 可以把同样的设计规则交给 Codex、Claude Code 或 Gemini CLI，但最后图片效果还取决于宿主提供什么 image model、什么编辑工具，以及模型本身怎么理解这些规则。
所以 Skill 更像是可迁移的“方法”，而不是把底层模型能力也一起打包走。
MCP：把外部能力接给 AI
MCP（Model Context Protocol）解决的是另一个问题：
AI 怎么使用外部的数据和工具？
比如一个 GitHub MCP server，可以向 Agent 提供：
- 读取 repo
- 搜索 issue
- 查看 PR
- 修改某些资源
以前每家 AI 产品都可能单独开发一套 GitHub integration。
有了 MCP 以后，外部服务可以按照共同协议开放能力，支持 MCP 的 Agent 再去调用。
所以 Skill 和 MCP 放在一起很容易理解：
Skill = 应该怎么做
MCP = 做的时候可以调用什么
一个退款 Skill 可以规定先查订单、再检查规则、最后决定是否退款；真正读取订单、执行退款的能力，则可以由外部系统通过 MCP 提供。
这两层最适合标准化，因为它们天然有跨平台复用的价值。
再往上一层，大家开始长得很像，但没有完全统一
Skill 和 MCP 都只是组件。
当 Agent 能做的事情越来越多，下一个问题自然出现了：
这些能力怎么组合起来给用户使用？
这里三家的答案已经很像，但还不是同一个标准。
OpenAI 叫 Plugin。
Claude Code 也叫 Plugin。
Gemini CLI 叫 Extension。
它们都可以把若干能力组织在一起，例如：
- Skills
- MCP servers
- Hooks
- Subagents
- 配置和资源
但具体怎么写 manifest、怎么声明权限、怎么安装、怎么展示、生命周期怎么管理，各家还是自己的设计。
我现在反而觉得这很合理。
因为到了这一层，已经不只是技术接口，还牵涉：
产品 UI、权限、安全、Marketplace、认证、本地运行环境、用户体验。
这些正是平台希望做出差异的地方。
所以未来更可能出现的情况不是：
OpenAI、Claude、Gemini 最后连 Plugin 文件夹都长得一模一样。
而是：
里面越来越多使用共同组件，外面的组合方式仍然可以不同。
一个比较理想的结构可能是：
可迁移的核心
├── Skills
├── MCP
├── scripts
└── assets
不同平台的包装
├── OpenAI Plugin
├── Claude Plugin
└── Gemini Extension
底下尽量共用，上面薄薄适配一层。
AGENTS.md / CLAUDE.md / GEMINI.md 也不只是名字不同
这三个文件都在解决一个很现实的问题：
有些项目规则，不应该每次开新 session 都重新告诉 AI。
例如：
- repo 怎么运行
- 测试命令是什么
- 哪些目录不能动
- coding conventions
- review 时重点检查什么
Codex 使用 AGENTS.md，Claude Code 使用 CLAUDE.md，Gemini CLI 使用 GEMINI.md。
但它们的区别不只是文件名。
不同 Agent 对这些文件：
- 从哪里开始读取
- 子目录规则怎么继承
- 哪个规则优先
- 是否支持 import
- 什么时候动态加载
都有自己的机制。
所以真正值得统一的不是“大家最后都把文件改名叫 AGENT.md”。
文件名一样没有太大意义。
更有价值的是：项目规则能不能尽量被不同 Agent 复用，而不用维护三份慢慢漂移的副本。
Hooks 和 Subagents 又属于另一种情况
这两个概念三家也越来越常见，但目前更接近共同的设计模式，而不是统一标准。
Hooks
解决的是：
某个事件发生时，有什么动作必须执行。
例如：
代码修改后自动 formatter；提交前必须跑 security check。
这里尤其适合放那些不应该交给模型“记得就做”的事情。
Subagents
解决的是：
一个任务太大时，怎么把其中一部分交给更专门的 Agent。
例如主 Agent 负责整个开发任务，同时把代码搜索、测试、研究分别交给不同 subagent。
三家的基本思路越来越接近，但配置、权限、context 和调度方式仍然不同。
所以这里不是“统一标准”，而是：
大家面对同一个 Agent 工程问题，自然走到了相似的设计模式。
为什么有些东西会统一，有些不会？
研究到这里，我觉得背后的规律其实挺清楚。
如果一个东西需要被很多不同系统共同使用，标准化的价值就很大。
比如：
“怎么描述一套 AI 工作方法？”→ Skill
“AI 怎么和外部工具通信？”→ MCP
如果不统一，每个 Builder 都要为每个平台重新做一遍。
但到了：
“这些能力在我的产品里怎么组合、怎么展示、怎么授权？”
这已经进入产品设计。
这里保持差异，反而有价值。
所以我现在会把整个 Agent 生态粗略看成两层：
更值得标准化的底层组件
- Skill：方法
- MCP：工具和数据连接
可以保持差异的上层编排
- Plugin / Extension：怎么打包
- Project instructions：怎么管理长期上下文
- Hooks：怎么管理生命周期
- Subagents：怎么做任务编排
- UI / Workspace：最终怎么给人使用
边界当然还会继续变化，但这个方向已经比较明显。
对 Builder 来说，我觉得这件事真正有用的地方
不是终于记住了六个新名词。
而是做自己的东西时，可以开始有意识地区分：
核心能力，尽量放在可迁移的地方
自己积累的方法，可以优先整理成标准 Skill。
需要给 AI 提供外部工具，如果适合，可以优先考虑 MCP。
这样未来换模型、换 Agent，核心东西还在。
平台相关的部分，尽量做薄
如果只是为了适配 Codex、Claude Code 或 Gemini CLI 的安装方式，不需要把真正的产品逻辑都写死在这一层。
平台变化很快，包装可以重新做。
不要把所有事情都交给模型判断
需要经验和判断的：
→ Skill + Model
必须稳定发生的：
→ scripts / hooks
需要外部能力的：
→ MCP
需要分工的：
→ subagents
这一层边界想清楚，比选哪家 Agent 更重要。
所以这次研究下来，我对 Builder 最实际的提醒是：
尽量让自己真正积累的东西，不依赖某一家 AI 产品才能存在。
模型会换，Agent 会换，Plugin 的格式也可能继续变。
但你的方法、知识、工具和工作流程，如果一开始就尽可能放在可迁移的层里，换一个宿主，可能只需要重新接外面那一层。