开源 Agent 套件 ECC 值得装吗：多出来的能力与成本一起算
本文基于 ECC 仓库 commit 591ab5c（2026-07-29）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/affaan-m/ECC 最新代码与文档为准。
判断 ECC 值不值得装，别看它有 281 个技能，要看你愿不愿意让一套第三方规则常驻在每次会话的上下文里、让一批脚本挂在你的工具事件上。 能力是按需加载的，成本是天天付的，这两笔账的计价单位不一样，所以不能放在一起直觉比较。
ECC 采用 MIT 许可证，仓库在 https://github.com/affaan-m/ECC 。它把「计划 → 测试 → 实现 → 审查 → 验证 → 记忆 → 改进」这条链条固化成仓库里的文件，而不是每次靠你在提示词里重述。仓库自己给出的数量是 67 个 agent、281 个技能、94 个命令兼容层。
本站此前写过 Agent 框架横向对比 和 Agent 成本失控的识别与止损，那两篇讲的是跨项目通用的方法论；这一篇不重复那些判断标准，只看 ECC 这一个具体项目把它们落成了哪些目录、哪些配置项、哪些你能当场打开核对的文件。
一、它到底往你机器上放了什么
先把结构摊开。下面这些路径都在仓库里能直接找到，装完之后它们会以不同形态出现在你的配置目录里。
| 组成部分 | 它负责什么 | 仓库位置 | 你什么时候会碰到它 |
|---|---|---|---|
| agent 定义 | 带独立上下文和受限工具集的专职角色 | agents/planner.md、agents/code-reviewer.md | 让它规划或让它换个上下文审查你刚写的代码时 |
| 技能 | 按需加载的工作流剧本 | skills/tdd-workflow/SKILL.md、skills/strategic-compact/SKILL.md | 任务命中某个工作流，模型才把这份文件读进来 |
| 命令兼容层 | 斜杠入口，迁移期保留 | commands/code-review.md、commands/quality-gate.md | 你习惯敲命令而不是描述任务时 |
| 退役命令归档 | 老名字的显式选装区 | legacy-command-shims/commands/context-budget.md | 你按旧教程敲了个命令却提示不存在时 |
| 规则 | 常驻标准，按语言/项目选装 | rules/common/performance.md、rules/typescript/ | 每一次会话，无差别加载 |
| 钩子运行时 | 在模型之外跑的确定性检查 | hooks/hooks.json、scripts/hooks/ | 你每次 Bash、Edit、Write 和会话收尾时 |
| 安装与自检脚本 | 装、修、卸、体检 | scripts/ecc.js、scripts/sync-ecc-to-codex.sh | 装重了、装漏了、想干净卸载时 |
| MCP 配置样例 | 可选的连接器清单 | mcp-configs/mcp-servers.json | 你主动往项目里加连接器时 |
| 能力落位准则 | 决定一个能力该做成什么形态 | docs/capability-surface-selection.md | 你打算自己往里加东西时 |
这张表里真正决定成本结构的是第五行和第六行。技能是按需加载的，你装两百多个和装二十个，闲置时的差别不大；规则是常驻的，你多装一包语言规则，就是每次会话都要付的固定开销。仓库自己也把这条写在安装说明里：先装 rules/common，再加一个你真正在用的语言包，别全拷。
二、多出来的能力，具体多在哪
流程变成产物。 计划不再只是聊天记录里的一段话，而是一份可以被修改、被批准的文件。仓库里的 Plan Canvas 技能更进一步：agent 写完计划后开一个只监听回环地址的浏览器画布，你指着某一段挂一条锚定到该元素的批注（回传的 JSON 里带选择器和原文片段，所以它知道你指的是哪一句），侧栏对话，然后按「Approve plan」或「Request changes」，结论直接落到 /plan 的 CONFIRM 关卡上。它做成了一个说 JSON 的独立命令行 ecc-plan-canvas，所以不绑定某一个工具。
审查换一个上下文来做。 这是最容易被低估的一条。写代码的那个上下文去审自己的代码，会天然复述自己的假设。ECC 的做法是给审查用的 agent 单独的上下文和单独的工具白名单。你可以打开 agents/planner.md 看它的头部：
---
name: planner
description: Expert planning specialist for complex features and refactoring. Use PROACTIVELY when users request feature implementation, architectural changes, or complex refactoring. Automatically activated for planning tasks.
tools: Read, Grep, Glob
model: opus
---
规划角色只给了 Read、Grep、Glob，没有写入权限——它的产出只能是一份计划，物理上写不了代码。这比在提示词里写「请先规划不要动手」可靠得多。同一个文件里还接着一段 Prompt Defense Baseline，约束它不改身份、不泄密、不随意输出可执行内容。
确定性检查跑在模型外面。 hooks/hooks.json 里每条钩子都有一个 id 字段，像 pre:bash:dispatcher、pre:edit-write:suggest-compact、stop:evaluate-session、stop:format-typecheck。它们由 Node 脚本执行，不消耗模型判断力，也不会因为上下文被压缩而失忆。这类机制的通用取舍，本站在 Claude Code hooks 的用法与边界 里单独写过。
会话结束后留下点东西。 收尾阶段的钩子会把会话蒸馏成摘要和带置信度的经验条目，下次开会话时按置信度门槛注入一小部分。跨工具的记忆则走 ecc memory，用一种叫 ecc.memory.v1 的 Markdown 格式，项目级放在 .ecc/memory/，用户级放在 ~/.ecc/memory/。仓库把这套东西的信任边界写得很直白：记忆是未经审核的上下文，不是可执行策略，重要结论要回到权威来源核实。
它自己也把配置当攻击面。 AgentShield 扫的对象不是你的业务代码，而是 CLAUDE.md、settings.json、MCP 配置、钩子、agent 定义和技能文件本身，发现严重问题时以退出码 2 结束，可以直接卡在 CI 上。另有 GateGuard 在破坏性 shell 命令执行前拦一道，rm、带 force 或路径的 git checkout、破坏性的 find -exec 都在其中。
三、多出来的成本，按笔算
常驻上下文。 规则是无差别加载的，会话启动时注入的额外上下文也是。ECC 给了两个逃生口：把注入内容的字符上限调小，或者直接关掉会话启动注入，环境变量分别是 ECC_SESSION_START_MAX_CHARS 和 ECC_SESSION_START_CONTEXT。上下文预算怎么分配是个独立话题，见 Agent 上下文预算怎么定。
连接器的隐性开销。 每个启用的 MCP 服务器都会把工具定义塞进上下文。ECC 的应对是把默认连接器压到一个（chrome-devtools），其余全部改成包着 CLI 或 REST 的技能、或者选装目录项，理由写在 docs/MCP-CONNECTOR-POLICY.md。这里有个容易踩的坑：ECC_DISABLED_MCPS 只在安装和同步流程里过滤 ECC 生成的配置，它不是运行时开关，要实时停用得用工具自己的 /mcp。
模型档位的钱。 docs/token-optimization.md 给的推荐配置是这样一段：
{
"model": "sonnet",
"env": {
"MAX_THINKING_TOKENS": "10000",
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
}
}
思路是：主会话别默认停在最贵的档，扩展思考的预算别一直开满，被派出去做探索和读文件的那些辅助会话换成便宜档。同一份文档还提醒，某些版本里压缩阈值的覆盖变量只能往下调，调不上去，遇到反效果就把它删掉、改用手动压缩。这类计价规则各家不同且会调整，以官方最新说明为准。
装机文件与排错难度。 钩子的命令行是一段很长的 node -e 引导脚本，作用是在各种安装形态下把 ECC 的根目录找出来。功能上没问题，代价是这行命令肉眼几乎不可读——你的钩子哪天不响应，你没法靠扫一眼配置定位。所以 scripts/ecc.js list-installed、doctor、repair 这几个自检入口不是可选项，是必修。
供应链面。 这类套件会往你的家目录写文件、挂钩子、连外部服务。仓库把官方渠道列得很死：GitHub 仓库、npm 上的 ecc-universal 与 ecc-agentshield、GitHub App、插件标识 ecc@ecc、项目站点，并明确写了第三方转载镜像不受维护也未经审核。这条不是客套话，装之前请照着核。
四、四种典型情况下怎么判
你一个人、一个熟悉的仓库、任务多是小改。 装它的边际收益低。你脑子里的流程比它注入的流程更贴合项目，而规则和会话注入的开销天天要付。真要试，走最小档：./install.sh --profile minimal --target claude，这个档位明确排除钩子运行时；或者干脆只手动拷两三个技能目录。
团队五人以上、审查靠自觉、回归靠运气。 这是它最划算的场景。有价值的不是那两百多个技能，而是「计划必须成为产物」「测试证据先于实现」「审查换上下文」这三条被写进文件、而不是写进人的记性。交付口径统一之后，新人接手的成本会明显下降，这部分收益不体现在单次任务上。
你已经有自己的一套规则和钩子。 别整套装。照 docs/capability-surface-selection.md 的路由顺序自己判：每次路径命中都要执行、不需要模型判断的，做成规则；只在任务需要时才该加载的剧本，做成技能；要跨工具反复调用的结构化接口，才值得上 MCP；一次性的本地动作，脚本就够。这份文档的收尾态度也值得抄——拿不准就从小的开始，等结构化边界真的开始回本了再往上提。
你用的不是 Claude Code。 能力是打折的，得先认这个事。Codex 走 scripts/sync-ecc-to-codex.sh 同步，采用只增不删的合并策略并留时间戳备份，但它目前没有对等的钩子执行能力，约束只能靠指令层和沙箱审批。GitHub Copilot 那一侧只有指令文件和 prompt 文件，没有钩子系统也没有委派机制。Cursor 的钩子是靠一个适配器把事件转成 Claude Code 的格式，复用同一批脚本。换句话说，你越往 Claude Code 之外走，拿到的越接近一套指令模板，而不是一套运行时。
五、边界：它明确不管的那些事
它不管你的模型从哪来。仓库不写死传输设置，网关、自建端点、自托管权重都走各自工具的常规配置，ECC 只管工具这一层。
它不替你判断记忆内容的真伪。记忆库第一版是只增不改的，每条都标为未经审核；团队作用域即使提交进版本库，仍然算未经审核的上下文。被召回的内容不能当指令执行——这是仓库写进文档的硬约束，不是建议。
它不保证跨工具功能一致。上一节的打折是常态，不是过渡期的瑕疵。
它不包含记忆库的运行时。技能级安装、最小安装、手动安装和插件安装都不会把 ecc memory 放进 PATH，你得单独装 npm 包。
它不覆盖全部命令。multi- 开头那组多服务编排命令依赖另一个叫 ccg-workflow 的运行时，基础安装不带，没装就跑不通。
它也不承诺替你想清楚该不该拆任务、该不该并行。这些判断题它给的是工作流模板，不是答案。
六、上手与避坑清单
别把两种安装方式叠起来。 装了插件又跑 ./install.sh --profile full，技能、命令、钩子和配置会重复，钩子还会触发两次。踩点在于两条路径各自都是官方推荐的，文档里也各写各的，你很容易先按 A 装完、过两周按 B 又装一遍。避法：每个工具只选一条路径；已经叠了就先卸插件，再从仓库根目录跑卸载，最后删你手动拷过的规则目录，然后重装一次。
插件安装带不进规则。 插件机制本身不分发 rules，所以你装完插件会觉得「规则怎么没生效」。避法：手动 cp -R rules/common 到规则目录，再按栈补一个语言包，拷整个目录而不是目录里的文件，否则相对引用会断。
三个标识不通用。 仓库是 affaan-m/ECC，插件标识是 ecc@ecc，npm 包是 ecc-universal。踩点在于老文章里还留着更长的旧市场标识。避法：认准当前这三个，别互相替换；另外 npm 是按版本标签发的，跟仓库主分支不同步，想要最新的就从 git 装。
别把仓库里的 hooks/hooks.json 直接拷进 settings.json。 那个文件是给插件和仓库用的，路径没被改写；而且较新的 Claude Code 会自动加载已安装插件里的钩子文件，你再拷一份就是双份执行。避法：用安装器带 --modules hooks-runtime 装钩子运行时，让它把命令路径改写好。给这个项目提 PR 的人还要额外注意：别往插件清单里加钩子字段，会触发重复检测报错，仓库里有回归测试专门盯这个。
手动装技能别嵌套目录。 Claude Code 只认技能目录的直接子目录，你为了整洁把它们塞进一个以 ecc 命名的子目录里，就会全部发现不了。避法：平铺。
旧教程里的命令可能已经退役。 比如上下文预算那个命令，现在在 legacy-command-shims/commands/ 里，属于显式选装。踩点在于文档的上手表里还提到它，你敲下去却没反应。避法：先 /plugin list ecc@ecc 看装了什么，需要老名字就从归档目录单拷。
禁用钩子要用真实 ID。 文档示例里的 ID 是示意写法，实际能填的以 hooks/hooks.json 里每条钩子的 id 字段为准，逗号分隔填进 ECC_DISABLED_HOOKS。避法：先 grep 一遍 id 再写。另外强度档位有 ECC_HOOK_PROFILE 可调，GateGuard 挡住你做修复工作时有 ECC_GATEGUARD=off 这条逃生路径，别用完忘了关回去。
同机多工具会互相覆盖会话数据。 记忆持久化默认写在同一个数据根目录下，你在两个工具里都用 ECC，会话摘要和度量会打架。避法：给其中一个设 ECC_AGENT_DATA_HOME，指到独立目录。
记忆内容只能从文件或标准输入喂。 命令行不接受把正文当参数值传，用户作用域的召回还要额外的显式开关。这不是限制你，是防止正文里的指令顺着命令行进到别处。避法：写进临时文件再用 --body-file。
收尾：装之前先答三个问题
第一，你愿意让常驻规则占掉每次会话的一小块预算吗？不愿意，就只拿技能和 agent，别装规则和钩子。第二，你有没有人负责在它出问题时排查？没有的话，node scripts/ecc.js doctor 这行命令得先有人会用。第三，你团队缺的到底是能力还是纪律？缺纪律，这套东西值；缺能力，它补不上。
想继续看的话，按这个顺序读仓库最省时间：先 docs/capability-surface-selection.md 弄清它的设计取向，再 docs/token-optimization.md 把成本旋钮认全，最后打开 agents/planner.md 和 hooks/hooks.json，看它到底是怎么把一句「请先规划」变成一个写不了文件的角色的。工具选型的通用流程可以对照 AI 工具选型流程 再走一遍。
本文属于 ECC 开源 Agent 套件专题（共 40 篇，从选择性安装一直拆到内部机制）。同一批还写了另一种取向的项目——不给你资产、只给你纪律的 superpowers 方法论专题。