ECC（affaan-m/ECC）：把七个编码智能体收进一套「Harness 操作系统」

一、导读

ECC（仓库 affaan-m/ECC，官网 ecc.tools）是一个把编码智能体的"操作系统层"做成开源件的项目：68 个子代理、292 个技能、94 个命令、一套基于 hooks 的运行时强制机制，以及会自己学习的"直觉（instinct）"与跨工具的 memory vault。它当日涨星 837（GitHub Trending daily，2026-09-20 页面），累计 263,652 星、39,452 fork（GitHub API，2026-09-20 抓取），MIT 协议。它最值得读的不是"配置包有多大"，而是它把三件脏活工程化了：跨 harness 的配置可移植性、上下文预算的硬约束、以及"代理自己改自己"这件事的安全边界。

二、项目速览

项目	详情
仓库	affaan-m/ECC（官网 ecc.tools；Claude 插件标识 ecc@ecc，npm 包 ecc-universal）
定位	自述为"agent harness operating system"：跨 harness 的技能/记忆/安全/研究工作流层
主语言	JavaScript（Node.js CLI + 大量 Markdown 资产；另含 Python hooks 与 ecc2/ Rust 控制面原型）
Star 总数	263,652（GitHub API，2026-09-20 抓取）；fork 39,452，watcher 1,345，开放 issue 208
当日涨星	+837（Trending daily，2026-09-20 页面，当日第 2）
License	MIT（仓库根 LICENSE；商业层 ECC Pro 为独立服务）
首次发布	仓库创建于 2026-01-18；v2.0.0 于 2026-06-10 发布
近期版本	v2.2.1（2026-09-08）、v2.2.0（2026-08-28）、v2.1.0（2026-07-27）；README 另称当前版本 2.2.2（2026-08-31），与 Release 页口径不一（待确认）
组件规模	68 agents / 292 skills / 94 commands（README 当前口径；第三方在 2.0.0 时期记录为 67/277/92，属版本漂移）
社区与商业	Discord 社区；ECC Pro + GitHub App（私有仓库自 19 美元/席/月起）；第三方媒体在 2.0.0 时期记录 289 位贡献者、34.3k fork

三、为什么是它

它赌的是一个很具体的团队痛点：没人只用一种 harness。 你在 Claude Code 里写的安全规则不会跟到 Cursor，在 Codex 里调顺的 TDD 流程在 OpenCode 里不存在，于是同一份规范被抄成三四个版本，各自悄悄漂移。ECC 的技术主张是"把配置层抽出来共享"，而不是让团队先统一工具——它的跨工具能力矩阵明确写着：与 Claude Code 完全对齐只是"主参考实现"，Codex、Cursor、OpenCode 都是部分对齐，GitHub Copilot 干脆不是对齐目标。这种诚实的降级声明，比"支持一切"更可信。

第二，它把大模型代理的成本问题当成架构问题处理。 上下文窗口是代理最稀缺的资源：每个 MCP 工具的 schema、每条常驻规则、每次会话的原始转录都在吃预算。ECC 的对策是三层——选择性安装（只装你要的模块，低上下文档位直接不装 hooks 运行时）、渐进式加载（技能按需载入而非全量常驻）、以及把 MCP 默认连接器从六个砍到一个，改用 CLI 包装的技能（第三方评测记录）。同时它在配置层给出模型分层建议：日常用 Sonnet、子代理用 Haiku、把 MAX_THINKING_TOKENS 从默认 31,999 降到 10,000，官方文档称这分别对应约 60% 与 70% 的成本下降（官方口径，未给测试环境）。

第三，它把"自我改进"做成了有证据链的闭环。 会话被 hooks 100% 捕获（v1 用 Stop 钩子、v2 改用 Pre/PostToolUse），由后台 Haiku 观察者抽取"原子直觉"，每条直觉带 0.3–0.9 置信度与证据，可聚类"进化"成技能/命令/子代理，并且 v2.1 起默认按项目隔离——这正是对"记忆污染"这一常见失败模式的正面回应。

涨星动因可归为三条叠加：趋势位与社区自发传播（榜单徽章、多语言 README、13 种语言文档）、"配置即产品"的差异化（同类项目多是单一 harness 的配置包或清单）、以及商业分层给出的想象空间（Pro + GitHub App + 企业报告）。需要克制看待的是：263k 星的项目主要由一人高频迭代，跨七个 harness 意味着七处上游变更风险，社区对"技能越多越好吗"本身也有明显分歧。

四、架构原理

4.1 整体架构：五层运行面

官方 docs/ECC-2.0-REFERENCE-ARCHITECTURE.md 给出的是当前最权威的架构声明——ECC 要做的是 harness 操作系统，而不仅是一堆命令、代理与技能的目录集。它把系统切成五个横向层（下图为该文档层的重组与仓库实体的对应）：

┌──────────────────────────────────────────────────────────────┐
│ ① Operator Surface  操作面                                    │
│   CLI（ecc）· Claude 插件（ecc@ecc）· 斜杠命令 · HUD/状态行   │
│   · 发布闸门与 PR 检查 · Plan Canvas 计划评审                 │
├──────────────────────────────────────────────────────────────┤
│ ② Harness Adapter Layer  适配层                               │
│   Claude Code · Codex · OpenCode · Cursor · Gemini · Zed      │
│   · 终端类（dmux/orca/superset/ghast）· 纯终端                │
│   统一出口：AGENTS.md + DRY hook 适配器（root 为唯一真源）    │
├──────────────────────────────────────────────────────────────┤
│ ③ Worktree / Session / Queue Runtime  运行时                  │
│   worktree 生命周期 · pane/session/todo · 检查项              │
│   合并与冲突队列 · 通知状态 · 归属与交接导出（handoff）       │
├──────────────────────────────────────────────────────────────┤
│ ④ Observability & Evaluation Loop  观测与评测环               │
│   JSONL 轨迹 · 状态快照 · 风险台账 · harness 审计             │
│   场景规格（scenario spec）· 验证器 · 可晋升 playbook · RAG 集│
├──────────────────────────────────────────────────────────────┤
│ ⑤ Security & Commercial Platform  安全与商业平台              │
│   AgentShield 策略/SARIF · ECC Tools 检查 · 计费              │
│   · Linear/GitHub 同步 · 企业报告                             │
└──────────────────────────────────────────────────────────────┘

值得注意的是这份文档的写法：它把每层的"外部参考压力"（跨 harness 适配、worktree 编排、HUD、自改进环等方向的公开项目）与"ECC 要落地的具体增量"一一对应，并要求每一项最终都落成适配器、检查、可观测信号、安全策略或发布闸门，而不是停留在策略备忘录。第④层的自改进环明确规定：任何改进必须先存"轨迹 + 产物"，经验证器证明"改善场景且不扩大爆炸半径"后才允许晋升为 playbook，并保留回滚路径。第⑤层则说明 AgentShield 要从"好用的扫描器"升级为策略平台：策略 schema（组织基线、严重度、责任人、例外、过期、证据、审计轨迹）、SARIF 输出、面向 OSS/团队/企业/受监管场景的策略包。

4.2 分层模块拆解

资产层（root 即真源）。 仓库目录本身就是它的"数据模型"：agents/（68 个子代理，Markdown + frontmatter 声明 tools、model）、skills/（292 个按需载入的工作流）、commands/（94 个迁移期斜杠命令 shim）、rules/（common/ 加 TypeScript/Python/Go/Swift/PHP/ArkTS 等语言分目录）、hooks/（hooks.json 声明 PreToolUse/PostToolUse/Stop/SessionStart 等事件与脚本）、scripts/（跨平台 Node.js 安装、修复、同步、编排与检查）。官方明确：根目录是唯一真源，各平台适配器只做"打包或映射"，不维护副本。

适配层（多 harness 目录）。 仓库根同时存在 .claude-plugin/、.codex/、.opencode/、.cursor/，以及 .gemini/、.kimi/、.qwen/、.trae/、.zed/、.kiro/、.hermes/、.openclaw/、.codebuddy/、.pi/、.adal/ 等十余个 harness 目录。跨工具能力矩阵把它讲得很清楚：指令统一走 AGENTS.md（Copilot 例外，读 .github/copilot-instructions.md）；技能、代理/委派、hooks、MCP 配置在各 harness 上保真度不同。Codex 支持"经显式信任的原生 hook 子集"，Cursor 走 hook 适配器——第三方记录其适配器为 .cursor/hooks/adapter.js，把 Cursor 的 hook 格式转成 Claude Code 的（Cursor 有 15 个 hook 事件，Claude Code 为 8 个）。

安装与生命周期层（控制面雏形）。 docs/SELECTIVE-INSTALL-ARCHITECTURE.md 描述了它真正想解决的契约问题：安装系统必须能确定性地回答"请求了什么、解析成什么、复制或生成了什么、做了什么目标特定变换、ECC 拥有什么因而可以安全删除或修复"。已落地的骨架包括机器可读的 manifests/install-modules.json 与 install-profiles.json、JSON Schema 校验、依赖展开与目标过滤、scripts/lib/install/* 的请求归一化与执行器，以及持久化 install-state 与 list-installed/doctor/repair/uninstall 生命周期命令。文档自陈的局限是：部分模块的目标特定合并/删除语义仍是脚手架级。

可观测与评测层。 第④层的落地形态是 JSONL 轨迹、状态快照、风险台账与 harness 审计，配套验证命令 npm run harness:audit -- --format json 与 npm run observability:ready；官方还提供只读的 evaluator/RAG 原型，用"陈旧 PR 打捞"场景记录了第一个 scenario spec、轨迹、报告、候选 playbook 与验证器结果，并要求存在"坏提案被拒绝"的回归夹具。

4.3 核心机制与算法原理

（1）instinct 学习闭环：从观察到可复用行为。 这是 ECC 最有技术含量的部分，细节在 skills/continuous-learning-v2/SKILL.md（v2.1.0）。其流水线是：hooks 在 PreToolUse/PostToolUse 抓取提示与工具调用（v1 用会话结束的 Stop 钩子，官方称 v2 的 100% 可靠性由此而来）→ 写入 observations.jsonl → 后台观察者（Haiku）周期性分析 → 模式检测（用户纠正、错误解决、重复工作流）→ 生成或更新带置信度的原子 instinct → 用 /evolve 聚类成技能/命令/子代理。

单条 instinct 的 schema 就是一个可审计的小对象：

---
id: prefer-functional-style
trigger: "when writing new functions"
confidence: 0.7          # 0.3 = 试探；0.9 = 近乎确定
domain: "code-style"     # code-style / testing / git / debugging / workflow
source: "session-observation"
scope: project           # project 或 global
project_id: "a1b2c3d4e5f6"
---
动作：优先函数式而非类；证据：观察到 5 次函数式偏好、用户在一次修正中否决了类式写法

v2.1 的关键改进是默认项目隔离：存储从全局 ~/.claude/homunculus/ 迁到 ${XDG_DATA_HOME:-~/.local/share}/ecc-homunculus/projects/<hash>/，项目识别按优先级为 CLAUDE_PROJECT_DIR → git remote get-url origin（哈希后跨机器可移植）→ git rev-parse --show-toplevel → 全局兜底；当同一模式在两个以上项目出现时才允许 /promote 晋升为全局。命令面为 6 个：/instinct-status、/evolve、/instinct-export、/instinct-import、/promote、/projects。后台观察者默认关闭，配置为每 5 分钟、至少 20 条观察才分析一次。

（2）上下文预算的硬控制。 这是 ECC 与"堆配置"路线的分野所在。会话起始注入的额外上下文有上限（默认 8000 字符）、注入的 instinct 数量有上限（默认 6 条）、注入门槛有置信度下限（默认 0.7），且会按项目与检测到的技术栈相关性加权排序；会话临时文件默认保留 30 天后清理。hooks 有 minimal|standard|strict 档位，可按 ID 关闭单个 hook。官方 token 优化指南进一步给出模型分层配置：

{ "model": "sonnet",
  "env": { "MAX_THINKING_TOKENS": "10000", "CLAUDE_CODE_SUBAGENT_MODEL": "haiku" } }

（3）安全机制：AgentShield 与 GateGuard。 AgentShield 把"代理配置本身"当作攻击面来扫描：CLAUDE.md、settings.json、MCP 配置与 hooks 都在范围内，检测维度含密钥、权限审计与 hook 注入；--opus 会跑红队/蓝队/审计三段式流程（第三方记录）。GateGuard 则在运行时拦破坏性 shell 命令（rm、强制的 git checkout、破坏性 find -exec）。第⑤层文档还规划了 MCP 供应链情报（npm/pip 溯源、CVE、仿冒包、依赖信誉）与提示注入语料库。

4.4 性能优化手段与设计取舍

取舍一：把"全量常驻"换成"按需载入"。 292 个技能若全部常驻，任何会话都会在写第一行提示前就被自己的配置吃掉预算。ECC 的方案是技能按需加载 + 命令降级为兼容 shim + 选择性安装档位（--profile minimal 明确不含 hooks 运行时）。代价是能力不再"默认在场"：官方专门给出 /ecc consult "security reviews" 这类"先查有哪些组件再决定装什么"的路径，等于把发现成本转移给用户。

取舍二：把 MCP 换成 CLI 包装的技能。 从六个默认 MCP 连接器砍到一个，本质是用"多一次命令调用"换"常驻 schema 的 token 占用"。这在上下文紧张的本地模型上收益明显，但会牺牲 MCP 的结构化返回与工具发现体验。

取舍三：跨 harness 采用"降级保真"而不是"假装一致"。 一个根目录 + DRY 适配器的代价是：不同 harness 的能力上限不同（Copilot 不支持 hooks、Codex 不支持 Claude 式 hook），于是同一份规范在不同工具里是"指令级强制"还是"hook 级强制"并不一致。ECC 的应对是公开能力矩阵与逐 harness 说明，而不是掩盖差异。

取舍四：学习系统的可靠性优先于激进程度。 观察者默认关闭、要求最少 20 条观察、置信度门槛 0.7、项目默认隔离、晋升需要跨两个项目——这些默认值都在压制"学到错误东西"的概率。代价是冷启动慢、需要用户主动开观察者。

4.5 与其他架构路线的差异

单一 harness 的配置包/技能集（大量"我的 Claude Code 配置"仓库、以及 addyosmani/agent-skills 这类技能集）解决的是"某一种工具的用法沉淀"，价值在内容质量，不解决跨工具漂移；ECC 是内容 + 适配器 + 生命周期三层打包。harness 自身（Claude Code、Codex、Cursor、OpenCode）负责模型调用、权限与会话，ECC 只在其上做操作系统层，因此要持续承担上游 API 变更的传导风险。Agent 编排 IDE / worktree 工具（Orca、Superset、dmux、Ghast）强在并行执行与工作区管理，ECC 把它们当作"要吸收的压力"（worktree 生命周期事件、会话分组、通知、合并队列），ecc2/ 里的 Rust 控制面原型尚属早期。通用记忆工具：ECC 的记忆不是"存一大段转录"，而是把会话蒸馏成摘要、instinct 与可复用技能，代价是表达能力有限（原子化、单触发单动作），换来可解释、可导出、跨工具可读。

五、应用场景

场景一：多 harness 团队的工程标准统一

痛点：团队里有人用 Claude Code、有人用 Cursor、有人用 Codex；同一个"提交前必须跑测试与类型检查"的规范被抄成三份，各自漂移。 做法：把规范下沉到根目录的 AGENTS.md + rules/，用 ECC 的多 harness 向导一次性落到各自目录；Claude Code 走插件，Codex 走原生子集，Cursor 走 hook 适配器。

npx ecc-universal@2.2.2 install --guided      # 一次选定多个 harness
npx ecc-universal@2.2.2 setup                 # 仅配置 Claude Code 插件

收益与量化：规范只需维护一份，Claude Code 与 Cursor 都从同一 AGENTS.md 读取项目标准，评审时只需审一份 diff；按官方能力矩阵，技能/代理/hook 面在 Claude Code 上保真最高，Codex 支持"经显式信任的原生 hook 子集"，其余 harness 为部分对齐。注意 hooks 事件数本身不等价（Cursor 15 vs Claude Code 8），迁移时要逐项对照能力表而不是对照文件数量。边界：Copilot 明确不是对齐目标（无 hooks，仅指令引用）；把 ECC 当"跨工具完全等价"来承诺会翻车。

场景二：把 TDD 从"提示词里的请求"变成门禁

痛点："请用 TDD"只是希望；模型会忘、会跳过 RED 阶段，评审时才发现没有失败测试的证据。 做法：用 /ecc:plan 先把计划落成可编辑产物，再激活 tdd-workflow：先定义接口 → 写失败测试（RED）→ 最小实现（GREEN）→ 重构 → 覆盖度验证，随后用全新上下文的评审者复查。

/ecc:plan "Add usage-based billing alerts"
  → 确认/编辑计划 → 激活 tdd-workflow → 采集 RED 证据
  → 实现至 GREEN → 全新上下文评审 → 回归测试修问题 → 验证构建/类型/lint

收益与量化：官方把 TDD 定义为"带证据的 RED → GREEN → REFACTOR 门禁流程"，技能模板写明的验收线是覆盖度 80% 以上；hooks 可在提示词之外做确定性检查（示例：编辑 TS/JS 文件时命中 console.log 即告警）。边界：hook 级强制在 Claude Code 上最完整，Codex 依赖 AGENTS.md 的指令级约束，不能当成编译期保证；另外 RED 证据要落盘留痕才有意义——把测试命令与输出写进会话产物，评审时可直接引用，而不是口头声称跑过。

场景三：跨会话、跨工具的"记忆与交接"

痛点：长任务结束时状态散落在聊天记录里；换到另一个工具继续做，等于从零复述背景。 做法：用 memory vault 与交接能力把会话蒸馏成可读文件，再在另一个 harness 里召回；用 instinct 命令管理沉淀下来的行为与作用域。

/context-budget        # 检查上下文压力
/save-session          # 或 /learn-eval：结束长会话时落盘
/resume-session        # 之后恢复
/ecc memory            # 统一 memory vault（2.2 线能力）
/instinct-export       # 导出直觉库；配合 /instinct-import 跨人共享

收益与量化：官方对记忆的定义是"会话被蒸馏为摘要、instinct 与可复用技能"，而不是保存巨大转录；instinct 可导出/导入，跨工具以文件层共享，项目注册表（projects.json，12 位哈希 ID）让同一仓库在不同机器上得到同一作用域。对多人团队，把验证过的直觉库导入到共享位置，等于把"个人踩坑经验"变成可复用的团队资产。边界：原生 Windows 上观察者进程会被 Job Object 连带杀掉（issue #2489），连续学习实质变成 no-op；memory vault 的 Windows 写入亦有未决缺陷（#2626）。

场景四：审计并加固"代理配置"本身

痛点：代理配置（CLAUDE.md、hooks、MCP、权限）是新的攻击面：提示注入、hook 注入、密钥泄漏、过宽权限都可能从这里进。 做法：先扫描再修复，必要时做红蓝对抗式复核；运行时再叠加破坏性命令拦截。

npx ecc-agentshield scan --path .        # 或 /security-scan
npx ecc-agentshield scan --fix           # 自动修复安全项
npx ecc-agentshield scan --opus          # 红队/蓝队/审计三段式

收益与量化：扫描范围覆盖 CLAUDE.md、settings.json、MCP 配置与 hooks，维度含密钥、权限与 hook 注入（第三方记录）；配合 GateGuard 在 rm、强制 git checkout、破坏性 find -exec 执行前拦截，可把"代理手滑"挡在提示词层之外。第⑤层路线图将其扩展到 SARIF 输出与策略包（OSS/团队/企业/受监管），意味着结果能接入 GitHub 代码扫描与 CI 门禁。边界：SARIF 与策略包属规划能力（落地程度待确认）；--fix 只应作用于安全项，企业环境要先做误报回归。

场景五：上下文成本治理（订阅额度与本地模型）

痛点：Opus + 31,999 思考 token + 六个常驻 MCP，一天就把额度烧完；本地模型上下文更紧，代理坚持不了几步。 做法：关闭不需要的常驻面（选择性安装、hook 档位、MCP 精简），再按官方建议做模型分层与思考预算控制，并配合压缩策略。

npx ecc-universal@2.2.2 install --profile minimal --target claude
export ECC_HOOK_PROFILE=minimal        # minimal / standard / strict
/context-budget                        # 看上下文压力与成本
/compact                               # 在任务断点手动压缩（strategic-compact 给建议）

收益与量化：官方 token 优化指南声称 Sonnet 替代 Opus 可省约 60%、思考预算从 31,999 降到 10,000 可省约 70% 隐藏成本、子代理用 Haiku 便宜约 80%（均为官方口径，未给基准环境，宜自行复测）；会话起始注入默认上限 8000 字符、instinct 注入默认最多 6 条，都是可控旋钮。边界：降配会牺牲复杂架构推理与自动化程度；minimal 档不含 hooks 运行时，等于放弃运行时强制与持续学习。

六、快速上手

最小路径（Claude Code）：

npx ecc-universal@2.2.2 setup                 # 引导式向导，安装 ecc@ecc 插件
# 或声明式写入 ~/.claude/settings.json：
# { "extraKnownMarketplaces": { "ecc": { "source": { "source": "github", "repo": "affaan-m/ECC" } } },
#   "enabledPlugins": { "ecc@ecc": true } }
/plugin list ecc@ecc                          # 确认安装
/ecc:plan "describe the feature"              # 从计划开始用

多 harness：npx ecc-universal@2.2.2 install --guided；源码检出可用 ./install.sh --profile minimal --target claude（Windows 对应 install.ps1）。自建模型或网关只需按 harness 常规方式配置（例如 ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN），ECC 的 hooks/技能/命令不绑定特定供应商。

七、横向对比

维度	ECC（affaan-m/ECC）	单一 harness 配置包 / 技能集	harness 原生（Claude Code 等）	并行编排 IDE（Orca/Superset/dmux 类）	通用 agent 框架（LangGraph 类）
解决的问题	跨工具配置/记忆/安全/评测的共享层	单工具用法沉淀	模型调用、权限、会话	多 worktree 并行与评审	从零构建 agent 应用
跨 harness 可移植	核心卖点（Claude Code 为主参考，Codex/Cursor/OpenCode 部分对齐）	无	无	各异	不涉及 harness
自我学习	instinct + 置信度 + 项目隔离 + 晋升	通常无	部分（原生记忆）	少	需自建
安全审计	AgentShield（配置/hook/MCP/密钥）+ GateGuard 运行时拦截	少	权限模型为主	少	依赖自建
上下文控制	选择性安装、按需技能、注入上限、MCP 精简（6→1）	取决于作者	会话级压缩	不涉及	需自建
成本结构	MIT 本体免费；商业层自 19 美元/席/月起	免费	按订阅/用量	多为商业	自建运维

补充口径：第三方在 2.0.0 时期记录 Claude Code 侧 67 agents/277 skills，而 OpenCode 为 12 agents/37 skills（组件口径，非质量口径）；同一来源记录 Cursor 的 hook 事件数为 15、Claude Code 为 8。

八、局限、风险与社区观察

上下文膨胀是这套路线绕不开的质疑。 292 个技能、68 个子代理天然诱使人"全装上"，而社区讨论（Reddit r/ClaudeCode "技能太多了"、多篇"技能蔓延"审计）与第三方评测都指出：把无用指令塞满上下文可能让代理表现更差；ECC 官方讨论区也承认"会话被塞满每个技能、每个 MCP 工具和长历史时，代理会挣扎"。它的默认值（按需加载、注入上限、最小档安装）是对这一批评的回应，但效果取决于使用者是否克制。

单维护者高频迭代的耦合风险。 第三方评测特别指出：一个跨七个 harness 的项目，就有七处上游 hook API / 配置格式变更会打破它；从 2026-01 建仓到 2.0 稳定版只用五个月，v2.0.0 → v2.2.1 约三个月。建议锁版本、跟 CHANGELOG 与逐 harness 限制页。另需注意 README 的"当前版本 2.2.2（2026-08-31）"与 Release 页最新 v2.2.1（2026-09-08）口径不一致，安装应以实际 tag 与 registry 校验为准（待确认）。

平台差异真实存在。 官方支持矩阵自陈三平台核心可用但能力不平齐，已知未决问题包括：原生 Windows 观察者进程被 Job Object 杀死导致持续学习失效（#2489）、memory vault 原生 Windows 写入缺陷（#2626）、macOS 系统 Bash 3.2 下独立 GAN 路径不兼容且存在分数解析缺陷（#2674）。开放 issue 208 个（API，2026-09-20），相对 263k 星的项目规模属于低位，但其中包含跨平台硬骨头。

安全与治理的边界。 AgentShield 与 GateGuard 降低了风险，但"让代理读你的配置、hooks 与 MCP"本身需要信任链：扫描器、--fix 与 --opus 都应在受控环境验证后再进主线；第⑤层的策略包/SARIF 属规划项，不能当既有能力。

商业分层与 License。 本体 MIT，但私有仓库分析与团队能力走 ECC Pro + GitHub App（README 标注自 19 美元/席/月起），企业落地要区分"开源部分可自托管"与"商业服务边界"。

九、小结与行动建议

ECC 把"代理的配置、记忆、安全与评测"从散落的个人 dotfiles 升级成有契约、有生命周期、有降级声明的系统层；它的真正价值不在 292 个技能的内容，而在"选择性安装 + 按需加载 + 项目隔离学习 + 配置安全扫描"这套工程约束。落地建议：

1. 先用 minimal 档跑一周：npx ecc-universal@2.2.2 install --profile minimal --target claude，只保留规则、代理与核心工作流，用 /context-budget 观察上下文压力，再决定是否开 hooks 与持续学习。
2. 把"记忆"当有作用域的数据治理：默认保持项目隔离，只有确认跨项目复用的模式才 /promote；定期 /instinct-export 备份并审查置信度分布。
3. 配置即攻击面：先扫自己：接入团队仓库前跑 npx ecc-agentshield scan --path .，把发现项纳入 PR 门禁，再考虑 --fix 批量处理。
4. 多 harness 场景按保真度排优先级：Claude Code 作为主参考实现享受完整 hooks 与技能面；Codex/Cursor 接受部分对齐并用 AGENTS.md 兜底；Copilot 不要纳入对齐承诺。
5. 锁版本 + 自建回归：固定 ecc-universal 版本，跨 harness 升级前用 npm run harness:audit -- --format json 与 npm run observability:ready 做基线，并确认 Windows/macOS 的已知缺陷是否影响你的平台。

资料来源（抓取日期 2026-09-20 至 2026-09-21）：GitHub Trending daily 页面（2026-09-20）与 GitHub REST API（仓库元数据、Releases、根目录与 docs/ 列表）；仓库内 README.md、docs/ECC-2.0-REFERENCE-ARCHITECTURE.md、docs/continuous-learning-v2-spec.md、skills/continuous-learning-v2/SKILL.md（v2.1.0）、docs/token-optimization.md、docs/SELECTIVE-INSTALL-ARCHITECTURE.md；第三方分析 augmentcode.com（ECC 224k 星、289 贡献者、AgentShield/GateGuard/适配器细节，2.0.0 时期）、pasqualepillitteri.it（instinct 与上下文过载风险）、8labs.id 指南（较早组件计数），以及 ECC 官方 Discussions（#2213 2.0.0 发布、#740 使用反馈）；社区批评来自 Reddit r/ClaudeCode 与 dev.to/Medium 的"技能蔓延/上下文膨胀"讨论（二手）。凡属第三方转述、官方未给基准的数字或口径不一致处，文中均已标注"官方口径"或"待确认"。