作者：Lei阅读 --

读 ECC：一个仓库把 Claude Code 的 harness 意见装箱发货

ECC（Everything Claude Code）是 MIT 协议的 Claude Code 插件仓库。它把 plan → test → implement → review → verify → remember → improve 这条工作流固化成 68 个 agent、286 个 skill、94 个命令和一套 hook。读这个仓库不是读框架源码，是读一份被具体化到文件的 harness 意见：每一种日用 agent 编程会踩到的失败模式，都对应一件可 install 的东西。

AILLMAgentAgent 工程上下文工程

一个基本事实：ECC 仓库 2026-01-18 建仓，到 2026-08-25 已 24.2 万 star、3.67 万 fork（数字来自 gh api repos/affaan-m/ECC，当日采样）。这个体量意味着一件事——把 Claude Code 用了十个月的一个人，把他一路踩出来的 harness 决策全部装箱、上架，正好赶上一大群人也需要这种装箱产物。所以这篇文章不谈它火不火，谈它到底装了什么。

先给一句话主张：ECC 不是新框架，也不是新模型。它是一份被写进 68 个 agent、286 个 skill、94 个命令和一套 hook 的 harness 意见——每一种日用 agent 编程的失败模式，都对应一件可 install 的东西。

这是本站 harness 主题的第三篇。《什么才是好的 Harness》 讲原理（判断归模型、物理归代码），《Agent 工程学决策地图》 讲选型（哪些决策已收敛、哪些还没），这一篇讲装箱：当有人把一整套 harness 意见写成一个可 /plugin install 的仓库，它长什么形状。

参考对象是 affaan-m/ECC，全文的观察都来自它的 README.md、SOUL.md、CLAUDE.md、the-shortform-guide.md、the-longform-guide.md 和 CHANGELOG.md（当日 head）——我没有真的把它装到本机跑，这点在文末「诚实的提醒」里会明说，并给出最低成本的验证实验。

名词速查

术语一句话解释
Claude CodeAnthropic 官方的 CLI 编码 agent，也是 ECC 的第一目标 harness
harness包裹模型的那个有状态程序，决定模型每一步看见什么、能对世界做什么；前文详解
skill一份可复用的工作流定义（Markdown + 支持文件），Claude Code 按需加载而不常驻上下文
subagent主 agent 可委派的、有自己独立上下文和权限的子进程
hook挂在 harness 生命周期事件（工具调用前后、会话结束、context compact 前等）上的脚本，跑在模型上下文之外
MCPModel Context Protocol，把外部服务包成模型能调用的工具集
AgentShieldECC 自带的扫描器，把 agent 配置本身（提示词、hook、MCP、权限、密钥、agent 文件）当攻击面来扫

一、装箱的骨架：一条七动词流水线

ECC 的 README.md 把它整个仓库的意图压成一行：

plan -> test -> implement -> review -> verify -> remember -> improve

这条串是 ECC 一切设计的骨架。仓库里几乎每一个 agent、每一个 skill、每一个 hook，都能被指认属于这七个动词里的某一个。理解 ECC，就是理解这条流水线在文件层面是怎么被逐段实现的——以及哪里被刻意留白。

七个动词里，前五个是任何有经验的工程师都会点头的东西。真正让这套东西有复利、区别于「把 prompt 写细一点」的是最后两个：remember 和 improve。它们把一次会话里的战术产出（找到的 bug、能用的排查路径、被否掉的方案）沉淀成可下次装载的东西，让下一次 plan 从更高的起点开始。这条循环——不是流水线的顺序结构——才是 ECC 押注的复利来源。

二、把每一种失败模式对应一件可 install 的东西

README.md 里有一张对照表，把「没有系统」和「装了 ECC」并排放。我把它压成六对，每一对都是一种可复现的 agent 编程失败模式 → ECC 装箱的对应件。

失败模式 1：计划消失在聊天记录里

日常用法：你让 Claude Code「设计一个 X」，它给你一段方案，你说「行，开搞吧」，几十条消息之后你想回头看看当初约定了什么，翻不到，或者翻到的版本已经和实际做的不一致。

ECC 的答案是 /plan + Plan Canvas：/ecc:plan "..." 让 planner agent 生成的方案落到一份可编辑的 Markdown 文件，2.1 版本又加了一个本地 loopback 浏览器界面（ecc-plan-canvas），可以在页面上点选、标注、批准或打回。批注结果直接接进 /plan 的 CONFIRM gate。计划从「消息流里的一段话」变成一份「有版本、可锚点批注、可 diff」的工件。

这是《好的 harness》里那句「判断归模型、物理归代码」的一个例子——「你要先看到并批准计划」在提示词里是恳求，在 Plan Canvas 里是物理。

失败模式 2：「请用 TDD」是可以被忘的一句话

同样一句「请 TDD」，模型会做到第二轮，然后写完实现和测试一起交上来。TDD 本身对模型是一种不自然的顺序，全靠提示词维持是脆的。

ECC 的答案是 tdd-workflow skill，它把流程拆成有闸门的 RED → GREEN → REFACTOR：必须先捕获 RED 证据（一份失败的测试），再进入实现。这不是靠提示词嘱咐，是靠 skill 里显式的证据要求。走完一遍留下的东西不再是「一段代码」，而是「计划 + 失败测试 + 通过测试 + review 报告 + 最终校验」这一串证据。

失败模式 3：写代码的上下文顺便 review 自己

这个是我认为 ECC 最微妙的一件事。同一段上下文一边写实现、一边说「我 review 一下自己」，几乎必然带盲区——它已经内化了自己的选择，看不到本可以问「为什么不用另一条路」的角度。

ECC 的答案是 fresh-context reviewer：/code-review 走 code-reviewer subagent，subagent 有独立上下文，不继承主 agent 的 chain-of-thought。它拿到的是产物（diff + 计划），不是过程。这是把「换个人来 review」这条工程常识做成了物理约束——主 agent 想让 reviewer 视而不见都做不到。

有代价：subagent 只知道字面的查询，不知道你为什么想这么问。ECC 的 longform 指南里明确写了对策——迭代式检索（orchestrator 拿到 subagent 返回后追问、最多 3 轮）、传目的而不只是查询。这是清醒的取舍，不是没看到问题。

失败模式 4：上下文窗口是唯一稀缺资源

在 Claude Code 里挂满 MCP 是新手最常见的乐观陷阱。装了 20 个 MCP、每个 5-10 个工具，实际可用上下文从 200k 缩成 70k。longform 指南给的经验值是「配置里 20-30 个 MCP，同时启用 < 10 个 / 活跃工具 < 80 个」。

ECC 在这一点上给了两个具体设计：

一是单默认 connector 政策——README.md 明说「ECC ships exactly one default connector (chrome-devtools); everything else is a skill wrapping a CLI/REST API or an opt-in catalog entry」。June 2026 有一次审计把之前六个默认 MCP 全部下架，退回到 skill + CLI 的形式。理由是很多 MCP 只是在包 CLI，包一层要交上下文的税。

二是 skill 是按需加载的。ECC 装了 286 个 skill，但它们不像 rules 那样常驻上下文——只在任务需要时被 planner 找出来。所以「286 个 skill」和「常驻上下文」是两件事。规则（rules）才是常驻的，所以 ECC 显式要求你只安装你实际用的语言那一包（rules/common + 一门语言），别一次全上。

一句话：ECC 把上下文视为唯一稀缺资源，把所有其他东西——skill、instinct、session summary、memory vault——都设计成「持久化到磁盘、按需装回」。仓库的口号原句是 Optimize the context window. Persist everything else.

失败模式 5：学到的东西下次会话就没了

上一次调试花了两小时踩出来的排查路径，下周同类问题再来时，模型不记得。你要么再花两小时，要么写一段「记得那次我们……」但这只对你自己这个 harness 用户有意义，agent 是重开的。

ECC 的答案分两层：

  • instinct（continuous learning）：Stop hook 在会话结束时把「非平凡的发现」——一段调试技巧、一个 workaround、一个项目内的固定模式——写成新 skill。下一次相似问题出现，skill 被自动加载。用 Stop hook 而不是 UserPromptSubmit 是刻意的选择——后者每条消息都跑，加延迟；前者一次会话跑一次。
  • Memory Vault（ecc memory）：跨 harness 的本地 Markdown 记忆格式，Claude、Codex、Kimi、Hermes 都能读同一份。这是把「记忆」从「Anthropic 的私有格式」升格为「你自己的可移植资产」。仓库明确写了它是未审阅的上下文，不是执行策略——被 recall 出来的内容不能被当命令执行，要当参考核对。

这两层加起来，是 ECC 押注的复利来源：agent 编程不该像考试，每次坐下重开一张白卷。

失败模式 6：默认信任 agent 配置

大多数人不把 .claude/hooks/、.mcp.json、AGENTS.md 当攻击面看。但它们完全是攻击面——一个提示词注入的 skill 文件、一个恶意的 hook 命令、一个把 secrets 通过 MCP 外泄的服务，都是真实威胁模型。

ECC 的答案是内建 AgentShield（也作为独立 npm 包 ecc-agentshield 发行），可以扫 prompt、hook、MCP config、权限、secrets 和 agent 文件本身。命令是 /security-scan 或 npx -y ecc-agentshield scan --path .。这不是通用代码扫描器，是专门针对 agent 配置的扫描器——这个类别本身近一年才被认真看待。

三、跨 harness 的赌注：一份意见、N 个 adapter

到目前为止我讲的所有 skill / hook / subagent，主要说的都是 Claude Code 场景。但 ECC 的野心比这大——install.sh --target ... 后可以是 claude、codex、cursor、opencode、gemini、zed、kimi、antigravity、qwen、hermes、openclaw、codebuddy、joycode。GitHub Copilot 通过 .github/copilot-instructions.md 和 .github/prompts/ 提供指令层。

这个赌注展开了讲是这样：如果 harness 意见足够抽象，它应该独立于 harness 本身。ECC 把 skill 定义成 Markdown + frontmatter、把 rules 定义成 Markdown、把 memory 定义成 ecc.memory.v1 的 Markdown——都是 harness 无关的文本格式。每个 adapter 负责把这些文本翻译成目标 harness 的原生格式（Claude Code 的 skill 目录、Codex 的 AGENTS.md、Cursor 的 .cursor/agents/、Kimi 的 .kimi-code/）。

这个赌注对不对，短期难验证。但方向是清醒的：模型层在收敛（Sonnet/Haiku/Opus 之外，Kimi、Qwen 都能跑 code agent），harness 层在分化（每个厂商都出自己的 CLI 和 IDE agent），这中间的「意见层」是空的——ECC 想去填这个空。它的直接对手不是任何单个 harness，而是「每个 harness 各自的官方 skill/rules 生态」。

值得注意的一个自我限定：README 里对每个 harness 的能力对等有明确「support matrix」，Cursor 和 Kimi 的 hook 支持都被显式标注为「adapter 不配置」。ECC 没有假装能力完全一致——「意见可移植」不等同「运行环境等价」，这个诚实是加分项。

四、灰度：我不打算全盘吞下的部分

按本站证据纪律，凡是我没亲手验过的判断，都要标出来。以下是我读完仓库之后的观点（不是事实）：

  1. 68 个 agent、286 个 skill 的绝对数量让我担心。skill 是按需加载的，但「按需」的判断本身要花上下文——planner 要过一遍索引，才知道调哪个。索引本身的成本会随目录规模非线性增长。这个担心可能是错的（如果 skill 索引做得足够工程化），但值得读者自己测一下：装完后跑一次 /context-budget，对比装 ECC 前后的 baseline 上下文占用。
  2. 一个人在 7 个 harness 上每周发版是仓库自己的宣传口径。它是真的还是有社区维护，git shortlog -sn 可以验；如果真是单人维护，长期可持续性是真风险。这不是黑仓库——是提醒读者，任何 SaaS-adjacent 的开源仓库都值得看 bus factor。
  3. SOUL.md 里的「Core Identity」和 README 里的数字不完全对齐（前者写「30 agent、135 skill、60 command」，后者写「68/286/94」）——这是一份内部文档没跟上主 README 的迭代。这是小事，但读的时候要意识到：仓库大且演化快，不是每份文档都是最新真相。
  4. 一些营销措辞（「trending repository of the day」badge、「Agent Harness Operating System」的自称）读起来偏重。这不影响技术判断，但读代码之前要能把营销和工程分开——不然容易高估「装上就变好」的即时效果。

五、平台工程角度：一个 gateway/eval 团队看它，看到什么

我自己在做的 Veral 平台 是 LLM 网关 + 路由 + 评测方向的。从这个角度看 ECC，几件事有共鸣：

  • Skill = 版本化的 prompt+workflow 资产。这跟内部 prompt registry 的动机重合——把 prompt 从代码里剥出来、独立版本化、可被观测和评估。ECC 把 skill 目录做成了半个 prompt registry。
  • pass@k 和 pass^k 被 longform 指南显式引入（k=3 时 pass@k=91% 但 pass^k=34%）。这是把统计评测语言带进 agent 编程实践的一步。要「能工作一次」用 pass@k，要「稳定生产」用 pass^k——这个区分对 eval pipeline 设计有直接借鉴意义。
  • Memory Vault 是可读的 Markdown 格式，不是 SQLite 或专有格式。这个选择让「跨 harness 的记忆共享」变成一个文件级的问题，不需要中间服务。对内部平台的启发是——协议先跑，服务后加。
  • 单默认 connector 政策是很好的克制样本。平台默认能力太多会 crowding out，用户学习成本上升。ECC 主动把默认 MCP 从 6 个砍到 1 个，把其余转成 skill，这个方向是对的。

分歧的地方：ECC 的复利假设建立在「个人开发者」这一层——skill 是我自己的、rules 是我自己的、instinct 是我自己的。到团队层面，这些资产的沉淀和治理就是另一回事：谁批准新 skill 进主线？skill 之间冲突怎么解？谁跑 eval 验证 skill 有效？这些问题 ECC 现在没答，也不该由它答——是平台层要接的活。

六、带得走的东西

一份读者可以直接拿去用的对照表。这不是发明的定律，是把 ECC 表格化了给读者用：

你遇到的日常问题单靠提示词的做法装箱化之后的做法（ECC 名义）
计划埋在聊天记录里「记得刚才我们说要 X」/plan 产生可编辑 Markdown + Plan Canvas 评审
「请 TDD」被忘反复提醒tdd-workflow skill，RED 证据不齐不给进 GREEN
自己 review 自己有盲区「请仔细检查」/code-review 走独立上下文 subagent
MCP 挂太多，上下文缩水「精简一下工具吧」单默认 connector + skill 包 CLI
上次学到的东西下次没了手抄笔记Stop hook 归纳 instinct + Memory Vault 跨 harness
不知道 agent 配置本身是否安全假设默认安全/security-scan / ecc-agentshield 扫 agent 面

每一行都是同一个模式的实例：一句提示词的恳求，被换成一件可 install 的物理约束。这就是 ECC 装箱工作的所有秘密——它没有发明新的 harness 原理，它把「所有已知的好实践」翻译成了文件。

诚实的提醒

  • 我没有把 ECC 装到本机跑通过 /plugin install ecc@ecc。全文的判断来自阅读仓库 head（README.md、SOUL.md、CLAUDE.md、the-shortform-guide.md、the-longform-guide.md、CHANGELOG.md）以及 GitHub API 采样（star/fork 数、创建日期）。所以本文属于「文档级阅读」而不是「装机实测」。
  • 数字（68/286/94、24.2 万 star）是 2026-08-25 采样，README 表格与 gh api 交叉核对，但仓库演化快——读者读到本文时数字很可能已经变。
  • 「fresh-context reviewer 更少盲区」是广被引用的工程直觉，也是 ECC 押注的方向，但据我所知目前没有公开的对照实验（我知道的话会附上）。所以这条属于「可信的默认假设」，不是「已验证事实」。

最低成本的验证实验（读者可跑，10-20 分钟）：

  1. 在一个非关键项目里 /plugin marketplace add https://github.com/affaan-m/ECC 和 /plugin install ecc@ecc。
  2. 记录装 ECC 前后：Claude Code 打开时的初始上下文占用（/context-budget）、启用的 MCP 数量、活跃工具数。
  3. 走一次真实的小任务：/ecc:plan "..." → tdd-workflow → /code-review。观察每一步是不是真的强制了那件事（比如 RED 证据是不是真的被 gate 卡住）。
  4. 结束后跑 /security-scan 或 npx -y ecc-agentshield scan --path .，看它扫出了什么。

这套实验的目的是回答一个具体问题：「装箱化」的价值是不是能被你本地感知到？ 如果答案是「有」，即使你不用 ECC，你也知道自己接下来要往哪个方向搭工具。

参考来源

工程实践：

本站相关：