跨IDE统一AI代理插件规范：从Compound Engineering看上下文共享与工具链复用

碎片化现状与统一需求

当前 AI 辅助编程工具呈现爆发式增长，Claude Code、OpenAI Codex、Cursor、GitHub Copilot、Qwen Code 等各自构建了独立的插件生态。开发者在不同 IDE 间切换时面临严重的上下文断层：在一个工具中积累的代码理解、项目记忆、工作流偏好无法平滑迁移到另一个环境。这种碎片化不仅降低了多工具协作的效率，更使得团队难以建立统一的 AI 辅助开发规范。

Compound Engineering Plugin 的出现提供了一个值得关注的解决路径。该项目由 Every Inc 维护，是目前少有的明确以 "跨 IDE 统一" 为设计目标的 AI 代理插件方案，支持 Claude Code、Codex、Cursor、GitHub Copilot、Qwen Code、OpenCode、Pi、Gemini CLI、Kiro CLI 等 9 种以上工具。其核心设计理念是 "复合工程"—— 将 80% 的精力投入规划与评审，20% 用于执行，通过系统化的工作流实现知识累积与复用。

架构设计：核心工作流与跨平台适配

Compound Engineering 的核心是一组结构化的代理技能（skills），包括 /ce-strategy（策略制定）、/ce-brainstorm（需求脑暴）、/ce-plan（实现规划）、/ce-work（任务执行）、/ce-code-review（代码评审）和 /ce-compound（知识固化）。这些技能形成闭环：从策略锚定到需求澄清，再到计划制定、执行落地、质量评审，最后将经验沉淀为可复用的知识资产。

跨平台适配是该插件的技术亮点。针对不同 IDE 的插件规范差异，项目采用了分层适配策略：

原生支持层：Claude Code 提供了最完善的插件市场机制，支持通过 /plugin marketplace add 注册市场后直接安装，无需额外转换。

转换适配层：Codex、OpenCode、Pi、Gemini CLI、Kiro CLI 等工具通过 bunx @every-env/compound-plugin CLI 工具进行格式转换。该转换器读取统一的插件源码，生成各目标平台所需的配置文件和目录结构。

混合层：Cursor 和 GitHub Copilot 介于两者之间，既支持原生插件安装，也提供了从 Claude Code 兼容格式自动转换的能力。

工程实践：Manifest 转换与上下文共享

实现多 IDE 兼容的关键在于建立统一的插件描述规范与灵活的转换机制。

统一 Manifest 结构：参考 Cursor Plugins 仓库的规范设计，一个标准的跨 IDE 插件应包含以下核心文件：

• .cursor-plugin/plugin.json：插件元数据，定义名称、版本、作者、依赖
• skills/SKILL.md：技能定义，使用 frontmatter 描述触发条件、参数、行为
• rules/*.mdc：规则文件，定义代码风格、约束条件
• mcp.json：MCP 服务器配置，实现与外部工具的集成

转换器实现要点：Compound Engineering 的转换器 CLI 处理以下关键映射：

• 技能（skills）到各平台原生命令的映射，如将 /ce-plan 映射为 Codex 的相应指令
• 代理（agents）的注册与调度，Codex 目前原生插件规范暂不支持自定义 agents，需要额外的 Bun 安装步骤补充
• 上下文文件的同步机制，确保 STRATEGY.md 等核心文档在各 IDE 间保持一致

上下文共享机制：项目通过文件系统级别的约定实现上下文共享。STRATEGY.md 作为策略锚点存储项目核心信息（目标问题、解决方案、用户画像、关键指标），位于仓库根目录，所有 IDE 均可读取。/ce-compound 生成的知识沉淀存储于 docs/ 目录，形成可浏览的经验时间线。这种基于文件系统的共享方式避免了复杂的同步协议，具有良好的可移植性。

可落地的实施路径

基于 Compound Engineering 的实践，构建跨 IDE 兼容的 AI 代理插件可遵循以下步骤：

第一阶段：规范定义（1-2 天）

• 定义插件的 plugin.json manifest，包含 id、name、version、author、description
• 设计技能目录结构，每个技能包含 SKILL.md（定义）和可选的 *.ts（实现）
• 建立规则文件目录，使用 .mdc 格式定义代码约束

第二阶段：核心 IDE 适配（3-5 天）

• 优先实现 Claude Code 原生支持，验证技能调用链
• 开发转换器 CLI，处理技能到 Codex/Cursor 指令的映射
• 测试上下文文件（如 STRATEGY.md）在各 IDE 中的读写一致性

第三阶段：扩展兼容（2-3 天）

• 针对 OpenCode、Pi、Gemini CLI、Kiro CLI 等平台运行转换器
• 处理平台特定限制（如 Pi 缺乏原生 subagent 原语，需依赖 pi-subagents 插件）
• 建立 CI 流程，验证各平台安装与基础功能

兼容性检查清单

在部署跨 IDE 插件前，建议完成以下检查：

局限与演进方向

当前跨 IDE 插件方案仍存在一些结构性限制。Codex 的原生插件规范尚未支持自定义 agents，导致需要额外的 Bun 安装步骤作为补充，增加了使用复杂度。OpenCode、Pi、Gemini CLI、Kiro CLI 等平台的转换器依赖可能随目标平台演进而需要更新，存在维护成本。

更根本的挑战在于各 IDE 的插件规范仍在快速迭代，缺乏行业统一标准。Compound Engineering 采用的 "转换器 + 约定" 模式是一种务实的过渡方案，但长期来看，建立类似 MCP（Model Context Protocol）的跨平台协议层可能是更可持续的方向。

参考来源

• EveryInc/compound-engineering-plugin - 跨 IDE AI 代理插件实现
• cursor/plugins - Cursor 官方插件规范与目录结构

ai-systems