ECC：给 AI 编码代理加装一套工程化流程与工具箱

ECC 是一个面向 AI 编码代理的“代理框架性能优化系统”。它想解决的不是“代理能不能写代码”，而是代理写完代码之后缺少工程约束的问题：ECC 让代理先规划再动手、用测试验证改动、换一个干净上下文审查自己的产出、记住重要信息，并把重复出现的成功经验沉淀成可复用的技能和工作流。用项目自己的话说，不必在每个提示词里重建这套过程，安装一次，让它成为代理工作方式的一部分。

项目托管在 GitHub 的 affaan-m/ECC 仓库，采用 MIT 许可证。平台元数据显示该仓库约有 303,435 个 Star、44,733 个 Fork；这些是 GitHub 指标，与 Hugging Face 的 Likes 或 Downloads 无关。主要语言为 JavaScript，创建于 2026 年 1 月，最近更新于 2026 年 11 月。

包含哪些组件

根据 README，ECC 提供 71 个代理、314 个技能和 98 个旧版命令入口，另有钩子、规则、记忆、持续学习以及 AgentShield 安全扫描。代理按用途分工，覆盖规划、审查、构建修复、安全、架构和领域任务；技能覆盖 TDD、研究、安全、文档、前端、数据、机器学习、运维等方向。

• Agents：面向具体工程任务的专用代理。
• Skills：可复用的工作流与知识单元。
• Commands：便捷入口，项目正在向以技能为主的界面迁移。
• Hooks 与 memory：运行时约束、会话摘要、持续学习、直觉与上下文控制。
• Rules：按语言或项目选择性加载的标准，而不是全部常驻。
• AgentShield：扫描提示词、钩子、MCP 配置、权限、密钥和代理文件。

支持哪些编码代理

ECC 目前与 Claude Code 配合最完整，同时提供 Codex 和 Qoder 的原生插件路径，并为 Cursor、OpenCode、Gemini、Zed、GitHub Copilot、Antigravity、Qwen 等提供能力受限的适配器。README 明确提醒，不同 harness 的功能并不对等，使用前应查看支持状态矩阵。

安装方式上，项目强调每个 harness 只选一种安装路径，不要叠加。比如 Claude Code 可以使用引导式安装或原生插件命令；Codex 可以使用原生仓库市场插件，也可以走已标记为废弃的同步脚本，但两者不应同时使用。重复安装到同一个 harness 可能导致技能、命令、钩子或配置重复。

安装与运行环境

ECC 2.2 提供面向 Claude Code、Codex 和 Kimi Code 的引导式安装。通用 npm 包要求 Node.js 18 或更高版本；Claude 插件安装还要求 PATH 中存在 Git 和 Claude Code 2.1 或更高版本。README 给出的引导安装命令包括 npx ecc-universal@2.2.3 setup，以及 pnpm、Yarn 2+、Bun 对应的包运行器写法。

项目区分了三个公开标识：GitHub 源码仓库是 affaan-m/ECC，Claude 市场/插件标识是 ecc@ecc，npm 包名是 ecc-universal。README 说明这种命名是有意为之，三者不能互换。npm 发布按版本标签切分，因此 ecc-universal 跟踪的是 2.1、2.2 等发布版本，而不是每次推送到主分支的提交。

项目还提示只从官方渠道安装：GitHub 仓库、npm 包 ecc-universal 与 ecc-agentshield、GitHub App、插件标识 ecc@ecc 以及项目网站 ecc.tools。第三方重新上传或非官方镜像不受项目维护和审查，可能包含恶意软件。

适用场景与注意事项

ECC 适合已经在使用 Claude Code、Codex 等编码代理，并希望把规划、测试验证、代码审查、安全检查和经验沉淀变成固定流程的开发者。它更像是在代理之上加一层工程化的工作系统，而不是替代代理本身。

需要注意的几点：项目功能在不同 harness 上并不完全一致；安装时应避免同一 harness 叠加多种方式；许可证为 MIT，但 README 中提到的 ECC Pro 是面向私有仓库的托管 GitHub App，属于另一项付费服务，开源仓库本身保持 MIT 许可。平台元数据中的许可证标识仅用于说明仓库许可，不应推断项目内图片或其他资源的授权情况。

项目主页：https://github.com/affaan-m/ECC

项目地址：ECC