ECC：别让 Agent 配置失控

Agent 用久了，最先失控的往往不是模型，而是配置。

今天给 Claude Code 加几个 subagent，明天给 Codex 写一套规则，后天又给 Cursor 接 MCP。每个工具都有自己的 agents、skills、hooks、commands、rules 和环境变量。刚开始只是为了提效，时间一长，项目里到处都是散落的提示词和配置文件，谁生效、谁冲突、谁已经过期，反而越来越难说清。

ECC 抓住的就是这个问题。它想做的不是再给某个 Agent 多加一个 prompt，而是把常见 AI 编程工具的配置面统一整理起来：Claude Code、Codex、Cursor、OpenCode、Gemini CLI、Zed、Copilot CLI 这些工具，都尽量放进同一套 operator system 里。

这个项目最有用的地方，是它把“Agent 能力”拆成几类可以管理的东西。

比如 agents，是给不同任务准备的专门角色；skills，是一套可复用的能力说明；hooks，是在工具调用、通知、停止这类节点上插入自动动作；rules 和 commands，则更像项目级的操作规范和快捷入口。再加上 MCP 配置，整套东西会变成一个比较完整的 AI coding 工作台。

问题也在这里。ECC 看起来很全，但全量安装不一定适合每个人。尤其是 hooks，如果直接放进全局配置，就可能影响所有项目。不同安装路径也要选清楚，plugin、manual、global、project 不适合混着叠。否则你以为自己在增强 Agent，实际是在制造更难排查的配置叠加。

如果只是偶尔用 AI 写几段代码，ECC 可能有点重。它更适合已经开始认真搭 AI 编程工作流的人。

比如一个项目里既用 Claude Code，也用 Codex；既要代码审查，又要测试修复、文档生成、Git 操作和上下文整理；还希望不同工具尽量遵守同一批规则。这个时候，配置散落会变成真实成本。不是“多写几个 prompt”这么简单，而是要知道每个工具在什么场景下该调用什么能力，以及哪些自动化不该跨项目乱跑。

从这个角度看，ECC 更像是给 AI coding 准备的配置仓库，而不是单个工具插件。它把很多本来需要自己慢慢攒的东西先打包出来，让你可以按需挑选：要 agents 就装 agents，要 skills 就装 skills，要 hooks 就先看清触发点，不确定就从最少配置开始。

这里最需要克制的是“全都装上”。

Agent 配置有一个很隐蔽的问题：它不像代码依赖那样一眼能看到 import，也不像前端组件那样页面坏了马上暴露。很多规则会在后台影响模型判断，hooks 会在你没注意的时候改写行为，MCP server 也可能让工具多出一堆调用入口。能力变多了，解释成本也会一起变多。

所以 ECC 更稳的用法，不是把仓库里所有东西一次塞进工作区，而是先把它当成清单。先看自己最乱的是哪一块：是 agents 太散，还是 hooks 不知道谁在触发，还是 MCP 配置每个项目都复制一遍。选一块整理，跑一段时间，再决定要不要继续扩展。

另一个有意思的方向，是跨工具的一致性。

现在很多人不是只用一个 AI IDE，而是在 Claude Code、Codex、Cursor、Gemini CLI 之间切换。每个工具都在进化，配置格式和能力边界也不一样。ECC 如果能稳定维护这些映射关系，就能减少一部分重复劳动：同一套工作流思路，不必在每个工具里从零重写。

但这也意味着维护成本会很高。工具更新、插件机制变化、hook 行为调整、MCP 配置变动，都会让这类项目需要持续跟进。对使用者来说，ECC 可以帮你整理配置，但不能替你理解配置。尤其是要放进团队项目时，最好先在单个仓库、小范围工作流里试，不要一上来就全局铺开。

如果把 ECC 当成“AI 编程百宝箱”，很容易失望，因为百宝箱越大，找东西越慢。它更适合被当成一套配置整理方法：把散落的 Agent 能力归类，把自动化边界说清，把不同工具之间重复的规则收拢起来。

对已经用 Agent 写代码、审查、跑测试、接 MCP 的人来说，这类整理迟早要做。自己从零攒一套当然可以，但成本会慢慢冒出来。ECC 的价值就在这里：它提供了一套现成参考，让你少从空白文件开始。

它不会让 Agent 自动变聪明。更准确地说，它是帮你少一点配置混乱，让 Agent 更像在一个有秩序的工作台上干活。