换 AI 编程工具不用重新配置:ECC 2.0 跨工具操作系统来了

跨工具编排 · 控制面板 · 会话适配器 · MCP 精简化 · v2.0.0 —— ECC 从插件集跃迁为 AI 编程助手之间的"操作系统中立层"。

ECC 是什么，以及它为什么能长到 212K star

ECC（Everything Claude Code）最初只是 Claude Code 的一个插件， 但经过多个月的密集迭代，它已成长为连接所有主流 AI 编程工具的 跨工具基础设施。212K star、230+ 贡献者、12 种语言生态， 这些数字背后是一套完整的体系：261 个技能、64 个智能体、 84 条命令，覆盖 Claude Code、Codex、OpenCode、Cursor、 Gemini、Zed 等几乎全部 AI 编程助手的挂载点。

ECC 的核心定位不是做一个"最好用的插件集"， 而是提供一个跨工具的抽象层。不管你用哪个编程助手， 它都提供统一的技能库、规则系统、钩子机制、MCP 约定 和发布门禁。项目主力语言是 JavaScript/TypeScript， 同时适配 Python、Go、Rust 等生态。

v2.0.0 是 2.0 系列正式毕业的稳定版，除了新增控制面板和 新技能族外，还在 rc.1 基础上经过了约 30 个 PR 的加固—— 修复了 Node 21+ 上钩子插件静默不执行、Windows 路径规范化、 会话摘要符号截断等一批实际线上问题。ECC 的 Discord 社区 也在同一次发布中正式上线，包含自动发布、GitHub 事件推送 和社群机器人。

多工具碎片化：谁在替每个助手"搬家"

如果你同时用 Claude Code 做架构设计、Codex 写 API 层、 Cursor 写前端——很快就会发现一个尴尬的现状： 每个工具都独立维护自己的配置入口。

Claude Code -> .claude/ + CLAUDE.md + hooks
Codex      -> .codex/ + codex.json + 专属插件格式
OpenCode    -> .opencode/ 独立存储路径
Cursor      -> .cursorrules + .cursor/ 记忆目录
Gemini CLI  -> 另一套 MCP 声明

这意味着：你在 Claude Code 里积累的代码审查规则、 安全门禁、性能检查器，换到 Codex 全部读不到。 你在 Cursor 里配的各种 MCP 服务声明，其他工具无从知晓。 每次更换主力工具就是一次"搬家"——配置恢复率低， 积累的心得往往流失。

对大团队而言，问题更隐蔽。不同成员习惯不同工具， 但产出要归入同一套 CI 标准和 Review 流程。 A 用 Claude Code 生成的代码带了一套 lint 规则， B 用 Cursor 写出来的却是另一套风格。Review 时， 大家花在"这为什么这么写"上的沟通成本远大于 代码本身的问题。ECC 的解法是：不要求团队统一工具， 而是让所有工具共享同一套底层约定。

v2.0.0 的四项新能力

控制面板：本地面板替代命令行扫视

项目目录下运行 node scripts/control-pane.js 即可在浏览器中 打开实时操作面板。无需任何云服务，数据全部来自本地的 ECC 状态数据库。面板包含：

这个面板的设计思路很直白：当同时有多个 AI 助手在工作时， 靠终端日志一条条翻是不现实的——你需要一张"驾驶舱仪表盘"。

跨工具会话适配器

ecc.session.v1 是整个 2.0 体系的数据底座。 它定义了一套统一的 schema，将 Claude Code、Codex、OpenCode、 dmux 等工具的会话信息映射到同一模型： 哪个智能体、在哪个仓库、正在做什么、挂起了哪些子任务。 配合 ecc.mcp.v1 清单模块，可以自动检测各工具之间 MCP 配置的碎片化和配置漂移。开发期间它甚至靠这个机制 抓到了一个通过命令行参数泄露 API 密钥的真实案例。

工作树生命周期服务

当多个 AI 助手在同一个仓库的不同分支上并行操作时， 传统的 git 工作流容易出问题：合并时机不可预测、 GC 误删未合并的工作树、分支状态难以追踪。 ECC 的工作树生命周期服务提供了可确定的冲突预判 和安全回收机制，让并行操作不再靠"小心别覆盖"来维持。

编排器技能族

orch-* 命名空间是本次新增的一组工作流技能， 包括 orch-add-feature、orch-fix-defect、 orch-build-mvp、orch-pipeline、orch-refine-code 等。 它们与 team-agent-orchestration 技能配合， 实现了"项目经理式"的多智能体编排： 不再是一次只和一个 AI 助手对话，而是由 ECC 将任务 分解为子任务，分派给不同智能体并行执行，再汇总结果。

与新增能力同样重要的是减法： ECC 默认 MCP 连接器从 7 个精简到 1 个（chrome-devtools）。 GitHub、Context7、Exa、Playwright、Memory、 Sequential Thinking 退为可选配置。理由是 MCP 连接器的 30+ 工具 schema 在每个会话里都占用上下文窗口， 而绝大多数操作只需一条 CLI 命令就能完成。 这个决策背后是一份独立的 MCP 连接器策略文档， 新增连接器必须同时满足"通用性"和"MCP 优于 CLI" 两个条件才能进入默认集。

分层架构与适配器优先的设计原则

ECC 2.0 的架构按五层组织，每层处理不同粒度的抽象：

操作员层     CLI · 插件 · TUI · 状态栏 · 发布门禁
适配器层     Claude Code · Codex · OpenCode · Cursor · Gemini
运行时层     工作树 · 会话 · 队列 · 合并冲突 · 通知
可观测层     JSONL 追踪 · 快照 · 风险账本 · 场景验证
安全层       AgentShield · SARIF · 企业联动

最关键的设计约束在适配器层。ECC 没有选"以某工具为主， 其他适配"的常见路线，而是为每个工具维护独立的 适配器合规矩阵。各工具在 schema 层面一视同仁， 没有默认一等公民。session adapter、hook format、 MCP inventory 都是独立实现的。这样当新工具出现时， 只需要新加一个适配器，整个技能库和规则集就能直接复用。

MCP 连接器的策略直接体现了这个项目的工程偏好： 先质疑、再放入、能不用就不用。每个默认连接器都需要 同时证明"对所有用户通用"和"MCP 带来的交互式会话状态 确实优于 CLI 的一行命令"。这种审慎在 LLM 工具链 普遍"什么都往里塞"的风气下显得很务实。

自我改进回路也是 v2.0.0 一个不可忽视的组件。 改进流程被拆分为五个阶段：观察 -> 提案 -> 验证 -> 推广 -> 回滚。每一次优化都先记录 trace 和 artifact， 不直接修改已安装的组件。只有验证器确认"改善了某场景 且没有扩大攻击面"的 playbook 才会进入推广阶段。 这保证了自动优化不会意外破坏已有的工作流。

从整体来看，ECC 2.0 想解决的核心问题不是"再加一个技能"， 而是"你怎么在多个工具之间保持一致的开发习惯"。 控制面板和会话适配器是对这个问题的回答： 你不需要成为任何一个工具的专家，你只需要熟悉 ECC 这套 操作层，就能熟练使用背后所有的 AI 编程助手。