如果你用 Claude Code 做真实项目，可能遇到过这样的重复劳动：隔一天重新打开项目，又要解释一遍技术栈；code review 里强调过几次的规矩，换个文件还是会被违反。
ECC（Everything Claude Code）试图把这些要求固化成一套可安装的工作流。它一次提供 68 个 agent、292 个 skill、94 个命令，以及 hooks、记忆和安全扫描，定位是 agent harness 的操作系统。
它值得试，但全量安装不适合所有人。安装前真正要算的不是费用，而是上下文占用。
ECC 固化了什么工作流
官方将它概括为：
plan -> test -> implement -> review -> verify -> remember -> improve
也就是先计划，再写测试，然后实现；接着用一个干净上下文审查代码，运行验证，把有用的经验记下来，最后将反复验证有效的方法沉淀成可复用的 skill。安装后，这套流程会成为工具的默认行为，不必每轮对话都重新交代。
ECC 的组件可以拆成五类：
- Skills：可复用的工作流，例如 TDD、安全审查和深度调研，需要时加载。
- Agents：拥有独立上下文和工具权限的专职 agent，将规划、实现和审查分开。
- Rules：项目或语言规范，常驻加载。常驻也意味着持续占用上下文，需要挑选。
- Hooks：由事件触发、在模型上下文之外运行的脚本。
- Instincts：从真实会话中学习的模式，带有置信度，在相关场景中才被召回。
可以把它理解成给 AI 编程工具装一套公司制度：agent 是岗位，skill 是 SOP，rules 是员工手册，hooks 是门禁，instinct 是老员工经验。制度越多，规范性越强，首次使用时需要阅读和注入的内容也越多。
安装前先确认版本，并避免重复安装
官方推荐的引导式安装命令是：
npx ecc-universal@2.2.1 setup
它会检查官方市场和本机已有的安装范围，再决定安装、更新，或将插件移动到选择的作用域。以后更新、切换作用域、修改 hook 配置，仍然使用这条命令；需要同时配置多个编程工具时，可以改用 install --guided。
前置条件是：
- Node.js 18 或更新版本；
- Claude Code 2.1 或更新版本；
- Git。
原文记录的发布版本是 2.2.1，发布于 8 月底。版本号固定只说明安装目标版本，不代表这个版本已经完成安全审计。
一个工具应当只选一条安装路径，不要在插件之上再叠加手动安装。重复安装最典型的症状不是报错，而是同一个 hook 被触发两次。
重点不是装多少，而是上下文占多少
官方平台支持表明确提醒：插件会把已安装的组件目录告诉模型；如果在意上下文占用，应使用选择性安装或手动安装。
这意味着 292 个 skill 并非只躺在硬盘里，它们的存在和描述本身就会占用上下文。全量安装更适合机器配置充足的重度用户，或只想先体验的尝鲜者。长期使用更适合从窄范围开始。
只安装规则、agent、命令和核心工作流，不安装 hook 运行时：
npx ecc-universal@2.2.1 install --profile minimal --target claude
已经知道需要哪些能力，可以直接点名安装：
./install.sh --target claude --skills tdd-workflow,security-review
不知道该选什么，可以让它推荐：
node scripts/ecc.js consult "security reviews" --target claude
它会返回匹配的组件、相关配置档和预览命令。真正安装前先预览，可以确认它要写入哪些文件。
组件彼此独立。有时最省事的办法只是复制文件：将某个 agent 的 Markdown 文件放进 ~/.claude/agents，将某个 skill 放进 ~/.claude/skills，不必引入整套系统。
安装后还可以用环境变量限制注入量：
# 会话开始时注入的额外上下文上限，默认 8000 字符
export ECC_SESSION_START_MAX_CHARS=4000
# 本地小模型或上下文吃紧时，关闭这部分注入
export ECC_SESSION_START_CONTEXT=off
# 每次注入的已学习经验数量，默认 6 条
export ECC_MAX_INJECTED_INSTINCTS=6
# 经验的置信度门槛，范围 0 到 1，默认 0.7
export ECC_INSTINCT_CONFIDENCE_THRESHOLD=0.7
如果上下文越来越沉，可以运行 /context-budget 查看占用来源，再移除不需要的 rules。
同样值得控制的还有 MCP。每个 MCP 的工具描述都要从 200k 窗口中切出一部分；开启过多时，可用窗口可能被压到约 70k。原文给出的经验值是：单个项目的 MCP 控制在 10 个以内，活跃工具控制在 80 个以内。
Hooks 很有价值，也最需要审查
hooks 是 ECC 中真正会在本机执行命令的部分。官方将 hooks、MCP 服务和项目指令都归为可执行配置：hooks 可以运行 shell，MCP 可能持有凭证，项目指令会进入模型上下文，三者都不能当作普通配置文件随手复制。
安装器在这一步设置了确认门槛：如果安装会落地 hook 运行时，而命令中没有明确指定 --enable-hooks 或 --no-hooks，安装器会先打印 hooks 能做什么，然后暂停，不写入任何内容。
还要注意 Claude Code 2.1 之后会自动加载插件里的 hooks 配置，不应再把同一份配置复制进自己的 settings.json，否则会触发两次。插件清单文件也不能重复声明 hooks，否则会报重复加载错误。这个问题曾在项目中反复修复，最终由回归测试固定下来。
开启 hooks 后主要得到两类能力：
- GateGuard：在危险命令执行前拦截，例如
rm、带路径或强制参数的git checkout，以及find中的-exec。 - AgentShield：检查 agent 配置、hooks、MCP 配置、权限和密钥，把编程工具本身当成攻击面审查。
这也是 ECC 的安全价值所在：不仅检查业务代码，也检查为 AI 编程工具添加的配置。
支持的工具和系统存在差异
ECC 列出了十几个编程工具的适配，但不能据此认为它们能力相同。官方也提醒，stable、beta 和 experimental 是能力描述，不是营销分级。
- Claude Code：唯一的 stable 主线，功能最完整。
- Codex：有原生插件，但 hooks 需要单独做信任决定，也不复用 Claude 的 hook 配置档。
- Cursor 和 OpenCode：属于 beta，安装内容只是组件目录的子集。
- GitHub Copilot：只有指令文件，没有 hooks、运行时 agent、委派或原生 skill 发现，不能按首屏描述去预期完整能力。
操作系统也有实际缺口：
- Windows 原生环境下，持续学习的观察进程和记忆库写入仍有未关闭的问题单；依赖 shell 的可选功能需要 Git Bash 或 WSL。
- macOS 自带的 Bash 3.2 过旧，有一条可选路径无法在其上运行。
- 核心 Node CLI 可在三大平台使用，问题主要集中在可选能力。
跨工具共享记忆的命令行工具不会随插件安装或最小安装自动进入 PATH，需要单独安装 npm 包，才能使用 ecc memory 命令组。
这些情况下可以先不装
- 上下文本来就紧张，或主力使用本地小模型：从
minimal起步，甚至只复制两个需要的文件。 - 只需要 TDD 或安全审查一两项能力：直接安装对应组件，不必引入整套系统。
- 主力工具不是 Claude Code：先查看支持矩阵中对应的一行，再决定是否值得折腾。
- 团队无法审查可执行配置：先不要启用 hooks；规则和 agent 这类纯文本组件可以先使用。
结论
很多 AI 编程增强项目停留在提示词合集。ECC 更进一步，把流程、岗位、记忆和安全扫描做成可安装组件，并在文档中区分 beta 能力和未修复的问题单。
它同时暴露了一个矛盾：能力依靠安装扩展，上下文却需要节省。292 个 skill 的价值不在于全部启用，而在于需要的那三五个能力正好可用。
这类项目热度上升后，第三方转载和镜像也会增多。原文特别建议只从官方仓库、官方 npm 包、官方 GitHub App 和官网安装。此类工具拥有本机执行权限，来源一旦出错，后续安全设计都无法弥补。