企业官网建设流程全解析

ECC 技术架构完整解析：让 AI 编码代理拥有计划、测试与记忆的工作系统

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC

ECC（Everything Claude Code）是一套面向 AI 编码代理的 agent harness 性能优化系统：68 个专职代理、285 个技能、事件钩子与跨工具记忆库，把「先计划、再测试、后复盘」的工程流程固化成可安装的工作流。

一个真实痛点：规则说三遍，长会话忘掉一半

先说它帮你解决什么：你让 Claude Code 加一个功能，它跳过测试直接写代码；你提醒「记得 TDD、别留 console.log」，长会话压缩上下文后又忘了一半；最后让它自己检查代码，结果写代码的和检查代码的是同一个上下文，等于自己批自己的卷子。

问题不在模型能力，而在于流程没有被固化。ECC 的做法是把工程流程从「每次都要叮嘱的口头要求」变成「装一次、永久生效的系统层」，官方一句话概括：

Optimize the context window. Persist everything else.（优化上下文窗口，其余全部持久化。）

核心机制：五种组件各管一件事，串成一条工作流

ECC 最关键的设计，是把「代理怎么干活」拆成五类组件，每类只回答一个问题，按任务需要协同工作。

用一个生活化的类比：像一支外卖团队的运转手册——规则是规章制度，技能是各类订单的标准流程，代理是按单分工的骑手，钩子是闸口的自动校验，直觉是老骑手攒下的经验教训。

一次典型任务的数据流大致是：

• 输入：你敲一句/ecc:plan "加用户登录"，planner 代理产出实现蓝图，你确认后进入执行；
• 处理：tdd-guide 技能先写失败测试（RED）→ 实现到通过（GREEN）→ 重构并守住 80% 覆盖率 → code-reviewer 以全新上下文复审；
• 输出：不只是代码，而是一条证据链：计划、失败测试、通过测试、评审结论、构建验证结果。

设计取舍：为什么「上下文只装要紧的」

ECC 的所有取舍都围绕一个事实：上下文窗口是稀缺资源。它的取舍逻辑可以拆成四条。

• 技能按需加载，而不是全量塞入。285 个技能如果常驻，每次会话都在为不相关的流程付 token 成本；代价是技能发现依赖各工具（harness）的加载机制，手动复制时目录结构不对就会失效。
• 确定性检查交给钩子，交给模型只做建议。模型自检是概率性的，脚本检查是确定性的，所以「提交前查密钥、console.log 告警、编辑后跑 tsc」这类规则全部在模型上下文之外执行；代价是钩子只能做模式匹配式的检查，理解不了语义。
• 评审必须换一个新上下文。写码和审码同上下文等于自己批改，ECC 强制用独立代理评审；代价是每轮评审多一次调度开销，长任务里这笔开销不小。
• 规则坚持「只装你用的」。rules 常驻意味着永久开销，所以安装器让你只拷rules/common加一个语言包；代价是装少了约束就弱，需要自己权衡。

需要如实说明的限制：全量安装会占用可观的上下文，官方文档明确警告——启用过多 MCP 工具可能把 200k 窗口压到 70k 可用；跨 harness 支持也不对等，Claude Code 最完整，Codex 的钩子退化为指令驱动，Gemini 等只算兼容层。细节见跨 harness 架构文档。

配置速览：10 行 JSON 看懂钩子怎么拦截

看懂 ECC 的「强制力」从哪里来，最直接的方式是看一条钩子配置。下面是短指南里的真实示例：命令命中 npm/pnpm/cargo 等长任务、而你又没开 tmux 时，给出提醒：

{ "PreToolUse": [ { "matcher": "tool == \"Bash\" && tool_input.command matches \"(npm|pnpm|cargo)\"", "hooks": [{ "type": "command", "command": "echo '[Hook] 建议用 tmux 保活会话' >&2" }] } ] }

规则很简单：退出码 2 表示阻断，非零加 stderr 表示告警。这类检查不经过模型，因此不会「忘了执行」，也不会被话术绕过。更多钩子清单（提交前质量检查、编辑后自动格式化、会话摘要等）见钩子说明。

上手指南：3 步安装并跑通第一个「计划-测试-复盘」循环

适合谁用：用 AI 编码代理做日常开发、想在团队里统一工程标准、或同时混用多个代理工具（Claude Code + Codex + Cursor）的开发者。对「代理配置本身是否安全」有顾虑的人，也可以用它自带的 AgentShield 扫描一遍。

1. 克隆仓库：git clone https://gitcode.com/GitHub_Trending/ev/ECC
2. 选一种安装方式，别叠加。低上下文路径（不含钩子运行时）：./install.sh --profile minimal --target claude；拿不准装哪些组件，先问内置顾问：node scripts/ecc.js consult "security reviews" --target claude。Claude Code 插件用户则直接用 README 顶部的两条/plugin命令，装完即止。
3. 装完跑第一圈：/ecc:plan "加登录功能"出计划并确认 → 激活tdd-workflow技能 → 完成后/code-review复审。用node scripts/ecc.js doctor可随时体检安装状态。

在 Claude Code 里用/plugins可以直观看到 ECC 与各类 MCP 的连接状态，便于控制「只留该留的」：

横向对照：它和手写 CLAUDE.md 差在哪

一句话结论：手写规则文件给的是「标准」，ECC 给的是「标准 + 分工 + 闸门 + 记忆」的完整系统。

延伸：生态衔接与接下来值得关注的三个方向

ECC 不是孤立插件，而是一个持续扩张的生态：安全侧的AgentShield把「代理配置本身」当攻击面来扫描（提示注入、钩子、密钥泄露）；记忆侧的Memory Vault用可检视的ecc.memory.v1Markdown 格式，让 Claude、Codex、Kimi 等工具共享上下文与交接；发行侧有 npm 包ecc-universal和仓库内 ecc2/ 的 Rust 控制面原型。想深入上下文经济学、记忆与并行代理，可以从长篇指南读起。

接下来三个方向值得留意：

• 2.2 引导式安装向导：一条npx ecc-universal setup完成多 harness 的预检、安装与更新，替代现在的手动多路径安装；
• 记忆库的信任机制：当前所有记忆条目都是「未审查、仅创建」状态，人工确认后的晋升流程是下一步重点；
• ecc2 控制面：Rust 原型已提供 dashboard、会话恢复与守护进程命令，目标是把会话编排从脚本层提升到常驻服务层。

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC