夜雨聆风前三篇我们看清了现状：Agent 扩展的零件统一了，安装包没统一，而且短期内不会统一。
那作为同时用多个 agent 的人，我到底怎么干活？总不能每个工具各维护一套、各改一份吧——那迟早乱套，迟早有人改错版本。
这篇讲我的真实做法。一句话概括：一套源码、多个运行时、薄适配器。
我同时用两个 agent：Claude Code 是主力，Codex 是次要的，偶尔也会想试试 OpenCode。日常我要维护的不只是「几条 prompt」，而是一个私有插件市场——里面有自研的能力，也有从社区沉淀下来的插件，加起来几十个，还在增长。
如果按最朴素的办法，我得在每个 agent 里各存一份、各维护一份。Claude Code 里配一套，Codex 里配一套，将来再加 OpenCode 再配一套。问题是：
• 同一个能力改了，要记得去好几个地方改 • 哪个版本是最新的？说不清 • 团队协作时，谁的改动覆盖了谁？
这套玩法在两个 agent 时还能勉强撑，到三个就崩了。所以我换了个思路。
核心思路：源码市场做主，运行时做出口
第一个、也是最关键的认知转变：别在 agent 运行时里直接配，要让一个「源码市场」当唯一真相源（single source of truth）。
具体说，我把所有插件相关的源码，统一放在一个 git 仓库里（我管它叫「市场仓库」）。这个仓库内部，直接按插件零件来组织——
• 可复用技能放 skills/，每个是一个 SKILL.md 目录• 外部工具连接放 MCP 相关配置 • hooks、脚本等辅助内容也各有归处
注意，AGENTS.md（项目指令）我也放在这个仓库里，但它不走适配器——它是项目级配置，直接放到各运行时的项目根目录就行，和「插件」是两个分发维度。
为什么要按插件零件组织？因为这些零件本身就是跨工具通用的，前三篇已经论证过。源码仓库对齐插件零件，等于让仓库的内容天然具备「可移植性」。
而 Claude Code、Codex 这些 agent 运行时，在这个架构里只是「分发出口」，不是主仓库。它们各自的工作目录，是源码市场「同步过去」的结果，不是「原地维护」的对象。
这一步想通了，后面都顺。
薄适配器：只翻译，不含逻辑
源码市场是标准的，但各 agent 运行时要的格式不一样——Claude Code 要 .claude-plugin/ 那套结构和 manifest，Codex 要它自己的格式。
我的做法是：给每个运行时写一个薄的同步逻辑（适配器），把源码市场的内容翻译成该运行时需要的格式和目录。
这个适配器严格只做三件事：
1. 格式转换：把标准层的源码，转成该运行时要的目录结构和 manifest 字段 2. 路径映射：把源码市场里的相对路径，映射到该运行时的实际安装路径 3. 命名空间处理：保证组件名在该运行时里不冲突
核心能力本身——skill 的内容、MCP server 的实现——只有一份，零重复。 适配器不含任何业务逻辑，只做搬运和翻译。这样核心能力的修改，天然在所有运行时生效。
但这里有个关键问题：不同运行时支持的组件类型不一样，不能无脑全量同步。 S03 讲过，一个插件里有十几种组件（skills/commands/agents/hooks/mcpServers/lspServers/assets/dependencies/…），而 Claude Code 和 Codex 对这些组件的支持程度不同。我按两家最新的官方文档，给我的两个运行时各列了一张支持矩阵：
$skill 调用，做格式转换 | |||
每个组件分三级：
• native（原生支持）：该运行时直接认识，同步时原样搬过去 • partial（部分支持）：支持但有差异（字段名不同、加载方式不同），适配器做降级转换 • unsupported（不支持）：该运行时不认这个组件，安静跳过，并记一条日志
这张矩阵一眼能看出一个关键事实：skills、hooks、MCP 这几个核心组件，两个运行时都是 native——这正是薄适配器能跑通的地基。差异主要在 commands/agents 的细节，以及 LSP、后台监控这类 Claude Code 独有的外围组件。适配器就按矩阵的级别走——native 直接搬、partial 做转换、unsupported 跳过。不同运行时的差异被矩阵显式管理，而不是埋在代码里、等到运行时出问题才发现。
这张矩阵还有个红利：哪天要加新运行时（比如 OpenCode），第一件事就是给它填一列——哪些组件 native、哪些 partial、哪些 unsupported。填完，适配器的行为就定了一大半。
目前这套适配器覆盖 Claude Code 和 Codex 两个运行时（我的主力组合）。OpenCode 在架构上完全能用同样的方式扩展——但说实话，我还没实际给它写适配器，所以这一块我没有完整的实战论据，先不多吹。等真做了再补。
踩过的几个坑
这套思路听着干净，落地时有不少细节：
• 目录结构和字段名差异：两家的 manifest 字段名、目录约定都不完全一样，适配器要逐个对齐，不能想当然。 • skill 格式的细微差别：SKILL.md 这个格式虽然跨工具，但不同运行时对 frontmatter 字段、加载时机的处理有细微差别。大多数能通用，少数要特殊处理。 • 组件类型不齐：某个运行时可能不支持另一种运行时支持的组件类型（比如某类 hook），遇到就要降级或跳过，不能硬塞。 • 同步要幂等：跑一次同步和跑十次，结果得一样；不能重复安装、不能漏、更不能悄悄覆盖用户在本地的临时改动。
这些坑都不是「思路错了」，而是「适配层要足够细致」。好在它们都集中在适配器里，改一次，所有同步都受益。
收益：改一处，多处生效
撑过前期的搭建，收益就很明显了：
• 改一处多处生效：源码市场改一个 skill，同步后 Claude Code 和 Codex 同时更新，不用各改一遍。 • 标准层升级自动受益：MCP 协议演进、SKILL.md 格式更新时，因为我的源码就是对齐标准层的，两个运行时几乎不用动就跟着升级。 • 新增运行时成本低：哪天我要正式接 OpenCode，只要再写一个适配器，核心能力零改动——这是这套架构最大的红利。 • 团队协作顺畅：市场仓库是共享的 git 仓库，谁改了什么、什么时候改的、为什么改，都可追溯、可 review。
方法论：核心下沉，适配做薄
把上面这些提炼成可复用的方法论，就四句话：
1. 核心能力下沉到标准层：把绝大多数内容做成 AGENTS.md、SKILL.md、MCP、ACP 这些已统一的零件。它们天然跨工具，是整个架构的地基。 2. 适配层做薄：每个运行时只保留差异适配（格式、路径、命名空间），绝不重复业务逻辑。适配器越薄，维护越省。 3. 源码市场做主，运行时做出口：一个 git 仓库当唯一真相源，各运行时是同步过去的分发出口，不在运行时里原地维护。 4. 先用起来，等标准：别纠结上层「安装包」统一不统一，先把能统一的零件层吃透。标准没来，照样能跨工具复用。
这套做法的本质，是把赌注押在「已经统一的零件层」，而不是押在「还没统一的安装包层」。前者稳定、可移植；后者还在变，不值得把核心能力绑死在上面。
展望：Agent 的 npm 会从哪来
最后说说我怎么看未来——既然安装包层短期统一不了，那「Agent 的 npm」到底会怎么来？
第一，它不会从天而降，会先从某个子问题突破。 我判断突破口是「registry + 权限治理」——「从哪装」和「装完安不安全」是跨厂商都受益的刚需，厂商在这层有合作动机（比如共建可信 registry），而不必直接交出自己的市场。
第二，真正完整的统一插件模型，需要五件一起成熟：标准 manifest、可信 registry、权限模型、签名验证、依赖解析。少任何一件，都只是半成品。有意思的是，那个还没成气候的 open-plugin-spec，已经把这五件都列进了未来规划——说明方向大家看得清，缺的是推力和时间。
第三，谁最可能促成？ 我赌有分发渠道的玩家。Anthropic 的 claude-plugins-official 已经是个 3.2 万 star 的官方市场雏形，它最有条件把「标准层」也一起带上去；其次是社区或 Linux Foundation 这类中立组织，在 registry 和权限治理上做跨厂商的活。纯靠一个实验性项目（像 open-plugins 现在这样），很难。
所以我的押注很明确：赌零件层，不赌安装包层。 把能力做厚在 AGENTS.md、SKILL.md、MCP、ACP 上，适配层做薄。这样无论上层的标准最终怎么收敛、谁最终胜出，你的核心能力都不用重写，迁移成本永远最低。
结尾
整个系列讲下来，一句话收束：Agent 插件的零件统一了，安装包没有，而且短期不会统一。 在这个过渡期，最务实的活法，不是等一个完美标准，而是把能力沉淀在已经统一的零件层，用薄适配器在多个 agent 间复用。
这不只是我一个人的做法——它适用于所有在多个 AI 编码工具之间辗转、又不想重复造轮子的人。
零件层在赢，先把这层做厚。
关注「言午 AI 进化论」，这是这个系列的最后一篇。如果你也在维护跨 agent 的插件，欢迎来交流你的活法。
