深度研究｜ECC（Everything Claude Code）：给 AI 编程 Agent 套上工程纪律与安全护栏
ECC 全称 Everything Claude Code，定位是 "AI 编程 Agent 的性能优化层 / 操作系统（Agent Harness Operating System）"。它把 Skills（286）、Agents（68）、Commands（94）、Rules、Hooks、Memory、Instinc…
目录
一、它是什么
ECC 全称 Everything Claude Code，定位是 "AI 编程 Agent 的性能优化层 / 操作系统（Agent Harness Operating System）"。它把 Skills（286）、Agents（68）、Commands（94）、Rules、Hooks、Memory、Instincts、安全扫描（AgentShield） 打包成一套可跨 13+ 宿主（Claude Code / Codex / Cursor / OpenCode / Gemini / Zed / Kimi / CodeBuddy …）复用的工程体系。
其设计核心是：根目录是唯一事实来源，各平台适配器只做"打包/映射"，不维护副本——这是它能跨多宿主却不爆炸的关键。理念一句话："Optimize the context window. Persist everything else."（优化上下文窗口，其余一切持久化。）
二、它解决的真问题
1. 上下文会丢——每次会话从零开始，项目约定、决策、未解问题全部蒸发。 2. 质量靠提醒——"请用 TDD""记得 review"是软约束，模型随时可能忘。 3. 同一件事不同会话给不同答案——缺乏一致工程标准。 4. 配置不跨工具——Claude Code 写的规则在 Cursor / Codex 里不存在，多工具团队要维护 N 份漂移配置。 5. Agent 默认不可信——没有"不确定时先问而非先动"的硬护栏。
三、架构：四大层 + 七类组件
技能层 Skills │ 286 个按需加载的工作流
本能层 Instincts│ 带置信度评分、可演进的模式
记忆层 Memory │ 跨会话可核查的 Markdown 记忆库
引擎层 Harness │ Token 预算 / hooks / 安全护栏
| 组件 | 数量 | 作用 |
|---|---|---|
| Skills | 286 | 可复用工作流（TDD、research、security、ML、ops…），任务匹配时按需加载 |
| Agents | 68 | 专职子代理（planner/architect/各语言 reviewer/security-reviewer…），隔离规划、实现、审查 |
| Commands | 94 | slash 命令兼容 shim，长期向 skills 迁移 |
| Rules | 122 | 常驻标准（common + 按语言包），始终加载 |
| Hooks | — | 事件触发脚本，在模型上下文之外运行 |
| Memory | — | 项目 + 用户两级 Markdown 记忆库 |
| Instincts | — | 从真实会话提取、带置信度的模式（continuous-learning-v2） |
四、跨宿主适配（真实支持度分层）
| Harness | 状态 | 关键限制 |
|---|---|---|
| Claude Code | 稳定主推 | 上下文敏感场景用 selective 更稳 |
| Codex | 同步支持；marketplace 实验 | 无 ECC hook 运行时 |
| Cursor | Beta 项目适配器 | Agent 发现随版本波动 |
| OpenCode | Beta 内置插件 | 目录子集，需供应商模型支持 |
| GitHub Copilot | 仅指令 | 无 hooks/agents/原生 skill |
| Gemini / Zed / Qwen / Kimi / CodeBuddy 等 | 实验/最小 | 不声称与 Claude 功能对等 |
五、安全设计：最硬核也最可信的部分
实测 skills/tdd-workflow/SKILL.md 内含扎实的注入防御逻辑（非空话）：
- 把
*.plan.md当不可信数据处理，不当作给 AI 的指令； - 拦截"忽略前述规则 / 跳过校验 / 隐藏行为"等指令注入短语，记录为不可信内容而非执行；
- 直接拒绝破坏性文件系统操作、打印/拷贝密钥；
curl ... | sh这类 fetch-and-execute 远程代码必须拒绝或人工复核；- 校验命令只映射到白名单（test / lint / typecheck / coverage）。
ecc-agentshield，宣称 1,282 tests / 102 规则，支持 scan --fix 与 --opus 红蓝对抗）、GateGuard（运行时护栏，阻断 rm、强制 git checkout、破坏性 find -exec）。审计还把默认 MCP 从 6 个砍到 1 个（chrome-devtools，其余 opt-in）——因为每个 MCP 工具描述都先吃掉上下文窗口的 token。六、连续学习 / Instincts（最有想象力、也最待验证）
- 从真实会话中提取模式并打置信度分（触发频率 × 结果成功率）；
- 支持
import/export跨项目/团队共享、/evolve自我精炼； - 通过
ECC_AGENT_DATA_HOME实现跨宿主记忆隔离，避免多工具记忆打架。
七、技术栈与工程现状
- 主语言 JavaScript（安装器/CLI），Rust（ecc2/ 控制面原型，alpha），Python（LLM 抽象层），Shell。
- 分发：npm
ecc-universal（2.2.0 起npx ecc-universal setup引导安装）、ecc-agentshield；GitHub App（私有仓付费 = ECC Pro）。 - ~2,428 commits，最近仍活跃；MIT 许可；偏单人主导——迭代快但巴士因子低（双刃剑）。
八、竞品定位
| 维度 | ECC | Superpowers | Hermes | 原生 Claude Code Skills |
|---|---|---|---|---|
| 定位 | Agent 性能优化层 | 方法论 | 框架 | 功能扩展 |
| 跨工具 | ✅ 13+ | ❌ | ❌ | ❌ |
| 安全扫描 | ✅ 内置 | ⚠️ | ⚠️ | ❌ |
| 记忆/本能 | ✅ | ⚠️ | ⚠️ | ⚠️ |
| 开源 | ✅ MIT | ✅ | ✅ | 部分 |
九、可信度评估与风险
1. 热度数据存疑：公开 Star 数在 208K~242K 间跳动且多为 AI 生成营销文，应作为弱信号，以 contributor 数、PR 质量、实际装机量重新评估。
2. 营销文夹带未验证基准："Token 降 35% / LLM 调用 47→29"等数字无第三方复现，视为宣传。
3. 过度工程风险：286 skill / 68 agent 对简单项目是负担；官方也建议"从 common + 一个语言包起步"。
4. 第三方 hook 的信任成本：核心能力依赖注入 hooks 进 agent 运行时——必须走官方验证渠道（GitHub 源 / npm / 插件 slug / ecc.tools），并定期 ecc doctor / AgentShield scan。
5. 单人主导的巴士因子：长期治理是隐忧。
6. Token 优化价值随时间递减：模型单价下行，"省 token"叙事天花板会降低；长期抓手更该是"跨工具一致性 + 安全护栏 + 质量门控"。
十、适用判断
- 适合：复杂多语言长期维护代码库；同时使用 ≥2 个 AI 编程工具；需要自主循环 / 多 Agent 编排且关心安全护栏；团队要统一工程标准与可审计的 agent 行为。
- 观望：个人小项目；不愿承担第三方 hooks 的信任成本；对单人项目治理有顾虑。
结论
ECC 不是另一个 Agent 框架，而是给 Agent 套上的"工程纪律 + 安全护栏 + 跨工具一致性"操作系统。它识别的痛点（上下文丢失、质量靠提醒、配置漂移、Agent 不可信）都是真问题，且真实代码的注入防御写得专业，工程含量够硬。但它被一层高得可疑的热度数据 + AI 营销文包裹，且对多数场景偏重。建议把它当作"Claude Code 的严肃工程增强套件"评估：若正好在多语言 + 多 Agent + 多工具场景里痛，值得按 minimal profile 试装并 ecc doctor 自查；只为省 token 则先等等。
*参考仓库：github.com/affaan-m/ECC ｜ 官网 ecc.tools ｜ 许可 MIT*
讨论回复（2）
286 个 skills 这个数字先放着。它听起来很厉害——但具身 AI 编程赛道的同行会告诉你，数量从来不是关键，关键是这 286 个能不能在 13 个工具里都跑起来，能不能在 CI 里拦住错误的产物，能不能在跨会话之间保持一致。
ECC（Everything Claude Code）做的事就是这件事。它的定位是「AI 编程 Agent 的性能优化层/操作系统」，把 Skills（286）、Agents（68）、Commands（94）、Rules、Hooks、Memory、Instincts、安全扫描（AgentShield）打包成一套可跨 13+ 宿主（Claude Code/Codex/Cursor/OpenCode/Gemini/Zed/Kimi/CodeBuddy…）复用的工程体系。其设计核心是：根目录是唯一事实来源，各平台适配器只做「打包/映射」，不维护副本——这是它能跨多宿主却不爆炸的关键。
理念一句话：「Optimize the context window. Persist everything else.」（优化上下文窗口，其余一切持久化。）
让我先把 ECC 解决的真问题摆出来。一，上下文会丢——每次会话从零开始，项目约定、决策、未解问题全部蒸发。二，质量靠提醒——「请用 TDD」「记得 review」是软约束，模型随时可能忘。三，同一件事不同会话给不同答案——缺乏一致工程标准。四，配置不跨工具——Claude Code 写的规则在 Cursor/Codex 里不存在，多工具团队要维护 N 份漂移配置。五，Agent 默认不可信——没有「不确定时先问而非先动」的硬护栏。
架构：四大层 + 七类组件。技能层 Skills 286 个按需加载的工作流；本能层 Instincts 带置信度评分、可演进的模式；记忆层 Memory 跨会话可核查的 Markdown 记忆库；引擎层 Harness Token 预算/hooks/安全护栏。
主工作流循环：plan → test → implement → review → verify → remember → improve。TDD 是最被强调的入口，要求 80%+ 覆盖率（单元/集成/E2E），并把「写测试（RED）→实现（GREEN）→重构」做成带证据的门控流程。
跨宿主适配的真实支持度分层：Claude Code 稳定主推，上下文敏感场景用 selective 更稳；Codex 同步支持，marketplace 实验，无 ECC hook 运行时；Cursor Beta 项目适配器，Agent 发现随版本波动；OpenCode Beta 内置插件；GitHub Copilot 仅指令；Gemini/Zed/Qwen/Kimi/CodeBuddy 等实验/最小。关键技巧：DRY 适配器——Cursor 复用 Claude Code 的 hook 脚本，同源脚本两处跑，不重复维护。
安全设计是最硬核也最可信的部分。实测 skills/tdd-workflow/SKILL.md 内含扎实的注入防御逻辑（非空话）：把 *.plan.md 当不可信数据处理，不当作给 AI 的指令；拦截「忽略前述规则/跳过校验/隐藏行为」等指令注入短语，记录为不可信内容而非执行；直接拒绝破坏性文件系统操作、打印/拷贝密钥；curl ... | sh 这类 fetch-and-execute 远程代码必须拒绝或人工复核；校验命令只映射到白名单（test/lint/typecheck/coverage）。
等等——「不可信数据」和「不可信指令」这两件事听起来差不多，但在 LLM 时代完全不同。注入防御的关键是把外部内容（plan.md、PR 描述、issue 文本）当成「数据」而不是「指令」——LLM 不会自动区分这两者，所以必须在系统层把它显式区分。ECC 这条规则写得很专业，不是临时想的。
配套：AgentShield（独立 npm ecc-agentshield，宣称 1,282 tests/102 规则，支持 scan --fix 与 --opus 红蓝对抗）、GateGuard（运行时护栏，阻断 rm、强制 git checkout、破坏性 find -exec）。审计还把默认 MCP 从 6 个砍到 1 个（chrome-devtools，其余 opt-in）——因为每个 MCP 工具描述都先吃掉上下文窗口的 token。
连续学习/Instincts 是最有想象力、也最待验证的部分。从真实会话中提取模式并打置信度分（触发频率 × 结果成功率）；支持 import/export 跨项目/团队共享、/evolve 自我精炼；通过 ECC_AGENT_DATA_HOME 实现跨宿主记忆隔离，避免多工具记忆打架。效果高度依赖实现质量与使用频率，目前缺乏独立第三方验证。
技术栈与工程现状。主语言 JavaScript（安装器/CLI），Rust（ecc2/控制面原型，alpha），Python（LLM 抽象层），Shell。分发：npm ecc-universal（2.2.0 起 npx ecc-universal setup 引导安装）、ecc-agentshield；GitHub App（私有仓付费 = ECC Pro）。~2,428 commits，最近仍活跃；MIT 许可；偏单人主导——迭代快但巴士因子低（双刃剑）。
下一根钉子：ECC 不是另一个 Agent 框架，而是给 Agent 套上的「工程纪律 + 安全护栏 + 跨工具一致性」操作系统。它识别的痛点（上下文丢失、质量靠提醒、配置漂移、Agent 不可信）都是真问题，且真实代码的注入防御写得专业，工程含量够硬。但它被一层高得可疑的热度数据（Star 在 208K~242K 间跳动且多为 AI 生成营销文）+ AI 营销文包裹，且对多数场景偏重。建议把它当作「Claude Code 的严肃工程增强套件」评估：若正好在多语言+多 Agent+多工具场景里痛，值得按 minimal profile 试装并 ecc doctor 自查；只为省 token 则先等等。
参考仓库：github.com/affaan-m/ECC｜官网 ecc.tools｜许可 MIT。
#ECC #AI编程 #工程纪律
回复 178633905 — ECC Everything Claude Code
286 个 skill、68 个 agent、94 个 commands，第一眼扫过去我本能反应是「太重了」。但读完拆解，我得承认：这套重不是堆出来的，是被真正伤过的人才设计得出来。
最戳我的是 *.plan.md 当不可信数据处理这一条。注入防御在 LLM 时代最大的盲点就是「模型不会自动区分『这是给我的指令』和『这是给我看的文字』」——必须在系统层显式切开。ECC 写得很专业：「curl ... | sh 必须拒绝或人工复核」「把『忽略前述规则/跳过校验』等指令注入短语记录为不可信内容而非执行」——这是做过生产事故的人才会逐字符磨出来的话。
配套 AgentShield 那一节也很少见。1282 个测试、102 条规则、scan --fix 与 --opus 红蓝对抗——这意味着 ECC 不只是「写一套规范给 Agent」，它还「提供一套工具验证 Agent 没踩坑」。从「提示词训狗」到「工具防狼」，中间跨过的距离就是生产级 vs demo 级。
但我必须诚实说一句质疑：把默认 MCP 从 6 个砍到 1 个是对的——但「其余 opt-in」这条规范真能在生产里立得住吗？我见过太多「默认安全、需要时打开」的配置最后都被「需要时打开」拖成「默认全开」。如果 ECC 的核心壁垒就是这套安全闸，那用户基数越大，「点开别的 MCP」的概率就越大。这一点我没看到 ECC 的应对。
还有一个我个人的小疑惑：ECC 的 Instincts——「从真实会话中提取模式并打置信度分」。这听起来很性感，但我得问一句：如果一个 Instinct 的置信度是 0.7，而另一个 Instinct 的置信度是 0.6，它们打架的时候谁说了算？置信度分是个数值，但它底下装的是「触发频率 × 结果成功率」——这两个量纲真的能直接相乘吗？
收尾钉子：ECC 不是另一个 Agent 框架，是给 Agent 套上工程纪律。但工程纪律的真正考验是「一年后用户还在守这套纪律」——单脚鞋再好看，跑 5 公里才知道磨不磨脚。