开源 Agent 套件 ECC 的评测线：改完配置到底是变好还是变差

本文基于 ECC 仓库 commit 591ab5c（2026-07-29）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/affaan-m/ECC 最新代码与文档为准。

你改了一版提示词、换了个模型、往 CLAUDE.md 里多塞了三条规则，然后觉得”好像顺手了”——这个”好像”就是绝大多数团队 Agent 调优的全部证据链。 ECC 这套装在编码 Agent 之上的增强件里，有几块技能是专门用来把这个”好像”换成可以重跑的数字的。它们值得看，但也不是拿来即用的成品，得先搞清楚每一块管到哪一步。

站内之前写过 Agent 评测集怎么构建、Agent 评测方法 和 Agent 回归测试，那三篇讲的是通用方法论——不依赖任何具体工具，你换成别的框架照样成立。这一篇不重复那些，它只回答一件事：一个真实存在、你现在就能 clone 下来翻的开源项目，把这套方法论落成了什么形状，哪些片段可以直接抄，哪些看着像但其实不是那回事。

一、先分清哪几块真的在管 Agent 评测

ECC 仓库根目录下 skills/ 有 281 个技能，agents/ 有 67 个 agent，commands/ 有 94 个命令。用名字搜”eval”和”benchmark”能捞出十来个目录，但它们不属于同一条线。

最容易踩的一个坑：skills/benchmark-methodology/SKILL.md 名字听着像 Agent 基准测试方法论，实际打开一看，它做的是竞品评分——给一组竞争对手在九个加权维度（定位清晰度、品牌语调、视觉与站点工艺、服务打包、证据与可信度、企业级成熟度、思想领导力、定价透明度，加上客户自己的”战略张力”双轴）上按 1–5 分打分，产出竞品档案卡。它的前置技能是 competitive-platform-analysis，后续交给 competitive-report-structure。跟你的 Agent 一分钱关系都没有。

同样，skills/benchmark/SKILL.md 管的是页面性能与 API 延迟基线（LCP、CLS、INP 那一套，以及 p50/p95/p99），skills/benchmark-optimization-loop/SKILL.md 管的是”把它变快 20 倍”这类优化搜索。都是好东西，但不是 Agent 评测。

真正在管 Agent 行为质量的是这几块：

组成部分	它负责什么	仓库位置	你什么时候会碰到它
agent-eval	多个编码 Agent 在同一批任务上的横向对比，产出通过率、耗时、一致性	skills/agent-eval/SKILL.md	选型、换模型、Agent 自身版本升级后做回归
eval-harness	用 pass@k / pass^k 口径给单个 Agent 的任务完成度定通过标准	skills/eval-harness/SKILL.md	给某个功能定”做到什么算完成”，以及改动后验回归
agent-self-evaluation	五轴自评分（准确、完整、清晰、可执行、精简），带证据规则	skills/agent-self-evaluation/SKILL.md，脚本在同目录 scripts/evaluate.py	想让 Agent 在收工前自己复查一遍输出
agent-evaluator	把上面那套评分交给一个独立角色执行，只评不重做	agents/agent-evaluator.md	不信任自评、想要一个第三方视角打分时
ai-regression-testing	针对”同一个模型既写代码又审代码”这类盲区的回归测试策略	skills/ai-regression-testing/SKILL.md	Agent 改完接口或后端逻辑之后
benchmark-methodology	竞品九维打分与评分纪律（不是 Agent 评测）	skills/benchmark-methodology/SKILL.md	做市场竞品分析时；它的偏差控制清单可以借

分清这张表，比读任何一篇 README 都省时间。

二、agent-eval：把”哪个 Agent 更好”变成能重跑的任务

skills/agent-eval/SKILL.md 开头有一句挺直白的自述：每一次”哪个编码 Agent 最好”的比较都是凭感觉跑的，这个工具是把它系统化。

它的做法是 YAML 任务定义。仓库里给的模板长这样：

name: add-retry-logic
description: Add exponential backoff retry to the HTTP client
repo: ./my-project
files:
  - src/http_client.py
prompt: |
  Add retry logic with exponential backoff to all HTTP requests.
  Max 3 retries. Initial delay 1s, max delay 30s.
judge:
  - type: pytest
    command: pytest tests/test_http_client.py -v
  - type: grep
    pattern: "exponential_backoff|retry"
    files: src/http_client.py
commit: "abc1234"  # pin to specific commit for reproducibility

四个设计点值得抄。

第一，commit 字段把任务钉死在一个基线提交上。没有这一条，你今天跑的通过率和两周后跑的没有可比性——代码库自己变了。这也是”评测集”和”随手写的测试用例”的分界线。

第二，判定器分了三类：代码型（pytest、command，跑测试或构建）、模式型（grep，匹配文件里是否出现某个结构）、模型型（llm，把实现丢给模型按一段问题清单判分）。仓库的最佳实践里明确说了每个任务至少要带一个确定性判定器，因为模型判定器会引入噪声。这一条挺关键：模型判官很好写，但它自己就是个随机源，全靠它你分不清是 Agent 变差了还是判官今天心情不同。

第三，每次运行开一个独立的 git worktree，不依赖 Docker。这样多个 Agent 并行跑不会互相踩，也不会污染基线仓库。相关的取舍在 Agent 工作区隔离 里讨论过——worktree 隔离的是文件系统，不隔离网络、不隔离全局配置、不隔离你机器上的凭证。

第四，采集的指标是四列：通过率、成本、耗时、一致性。一致性的定义是重复多次运行下的通过率（技能文档里的说法是 3/3 这样的形式）。它单独成一列，是因为 Agent 非确定性，一次通过说明不了什么。最佳实践里给的建议是每个 Agent 至少跑 3 次、准备 3–5 个能代表真实工作负载的任务而不是玩具例子，并且把成本和通过率放在一起看——通过率高但花销高好几倍的方案未必是对的选择。

要注意的是，这块技能自己不带 CLI 实现。文档里的安装章节只有一句提示：从它的仓库安装，安装前先审源码。技能文件末尾指向的是另一个第三方仓库。也就是说 ECC 在这里提供的是用法约定和判断标准，工具本体要你自己去装、自己去审。这是好事也是代价，第五节会展开。

三、eval-harness：给”算不算做完”定一个可复述的口径

skills/eval-harness/SKILL.md 走的是另一条路。它不比较工具，它给单次开发定通过标准，说法叫 eval-driven development，把评测当成 AI 开发的单元测试：先定义期望行为，再写实现，每次改动都对着跑。

它把评测分成两类，这个分法直接可用。能力型评测测的是”Agent 现在能做以前做不了的事”，写成一段带成功标准勾选项的定义；回归型评测测的是”改动没有弄坏已有功能”，要写明基线（SHA 或者检查点名称）和上一轮的结果，格式是 X/Y passed (previously Y/Y)。把上一轮结果写进模板里，这个细节比看起来重要——它逼你每次都做对比而不是只看当前数字。

判分器分四级：代码判分（确定性检查，文档里给的例子是 grep -q 加 npm test、npm run build 这种退出码判断）、规则判分（正则或 schema 约束）、模型判分（LLM 按评分表打 1–5 分并给出理由）、人工判分（标注风险等级，交人裁决）。文档明确写了安全相关的检查永远不要全自动化。

指标口径上，它用两个：pass@k 是”k 次尝试里至少成功一次”，pass^k 是”k 次全部成功”。给出的推荐阈值是能力型评测 pass@3 不低于 0.90，发布关键路径上的回归型评测 pass^3 要等于 1.00。这两个口径的差别就是”能不能做到”和”稳不稳定”的差别，混着用会得出很乐观的错误结论。

产物放哪儿也定死了：定义写在 .claude/evals/<feature>.md，运行历史写在 .claude/evals/<feature>.log，发布快照写在 docs/releases/<version>/eval-summary.md。这个布局本身没什么魔法，价值在于它把评测当成和代码同级的资产——技能文档里把这条列进最佳实践，说评测要跟代码一起做版本管理。

它还列了几条反模式，值得贴在墙上：把提示词过拟合到已知的评测样例上；只测正常路径；一门心思追通过率却忽略成本和延迟的漂移；让不稳定的判分器把守发布关卡。第一条和第四条是最常见的自欺方式。

有个细节要如实说：这块技能的集成章节写了 /eval define、/eval check、/eval report 三条命令形式，但 commands/ 目录里并没有对应的命令文件，与 eval 沾边的只有 commands/learn-eval.md（它做的是从会话里提取可复用模式、自评质量后决定存到全局还是项目目录）。所以那三条命令你别当成开箱即用的入口，把它理解成技能文档描述的调用约定更稳妥。

四、评分要有证据，这条纪律可以直接搬

skills/agent-self-evaluation/SKILL.md 给的是五轴评分表：准确性抓幻觉和写错的 API 名，完整性抓漏掉的边界情况和需求，清晰度抓结构混乱，可执行性抓”你应该 X”却不给做法，精简度抓冗余和废话。1–5 分，5 分是”没有合理的改进空间”。

真正可搬的是它的证据规则：任何低于 5 的分数都必须给出具体证据，3 分不能只写”还可以更好”，必须指出到底缺什么、错在哪。文档里那句口号是”把差距摆出来，不要只报个名”。

配套的 agents/agent-evaluator.md 把这套评分交给一个独立角色跑，角色约束写得很硬：不重做原任务，不在方案没有事实错误时提替代方案，没有正确性证据就不给 5 分，也不因为用户没要的功能缺失而扣分。它拿到的 Bash 权限是只读白名单——允许 grep、cat、ls、find、head、tail、wc、stat，git 相关命令要求带 --no-pager，写文件、删文件、推远端、装包一律禁止；确实需要越界时要先说明意图和预期影响、拿到明确确认再动。这个权限收口写法本身就是个可抄的模板，思路和 最小权限设计 是一致的。

顺带一提，前面说的 skills/benchmark-methodology/SKILL.md 虽然评的是竞品不是 Agent，但它那节偏差控制写得相当扎实：不要合成单一综合分（加权平均会掩盖真正重要的不对称）、区分”自称”和”已证实”、警惕审阅者对自己偏好风格的加分、在定稿前把所有对象的分数并排重读一遍确认同一个”4 分”含义一致。把”竞品”换成”Agent 配置版本”，这几条照样成立。

五、边界与代价：它明确不管的事

这套东西不是托管评测平台，几件事它压根不碰。

不提供运行环境和数据。 agent-eval 靠你本地的 git worktree 跑，任务里写的 pytest、npm run build 得在你机器上能跑通。没有沙箱镜像、没有云端队列、没有结果数据库。跑十几个任务乘三次重复，占的是你自己的 CPU 和 API 额度。

工具本体不在仓库里。 agent-eval 技能文档只给了用法和一句”安装前先审源码”，实现指向另一个第三方仓库。你要装一个别人的 CLI，让它读你的代码库、开 worktree、调多个 Agent 的凭证。这条链路上任何一环出问题，代价都落在你机器上。装之前至少确认它跑了哪些命令、往哪里写文件、把什么发到了网络上。

它不判断业务价值。 通过率、耗时、一致性这三样都在测”Agent 有没有把你写的那句话做到”，测不了”这句话本身该不该做”。评测集写歪了，你会得到一个高分且方向错误的 Agent。这也是评测集构建本身要单独当项目做的原因。

模型判分器的成本和漂移它不替你兜。 反模式清单里点了名：追通过率的同时忽略成本和延迟漂移是错的。但 harness 自己不给你预算护栏，得自己盯。各家模型服务商的计费与限制规则不同且会调整，以官方最新说明为准。

评测本身会腐化。 commit 字段钉住了基线，也意味着基线会过期——被钉住的那个提交越老，任务和真实代码库的距离越远。评测集需要定期重钉、重写，这块维护成本没人替你付。

自评分不能当质量门。 agent-self-evaluation 文档自己写了这不是通过/失败的关卡，是一个反思步骤。同一个模型写完又给自己打分，盲区是继承的——skills/ai-regression-testing/SKILL.md 里那个真实案例把这条描述得很具体：一个字段没在响应里补全的问题连着改了三轮，每轮都是模型自己改完自己审、每轮都判”看起来没问题”，同一处盲区第四次冒头时才被自动化测试第一次跑就抓住；文档把”沙箱路径和生产路径不一致”点名为 AI 引入回归里最常见的那一类，反模式清单里也直接写了别拿模型自审当自动化测试的替代品。结论很朴素：让写代码的和判对错的不是同一个东西。

六、上手与避坑清单

别按名字挑技能。 会踩是因为 benchmark-methodology 这种名字太像 Agent 基准测试了，直接装上会得到一套竞品打分流程，跑起来还一本正经。避法很简单：打开 SKILL.md 看 frontmatter 的 description 和 ## When to Activate，两处对不上你的场景就别装。

第一批任务别写玩具例子。 会踩是因为”给函数加个 docstring”这类任务所有 Agent 都能过，跑出来一排满分，什么也没测出来。技能文档给的做法是准备 3–5 个代表真实工作负载的任务。挑那些你上周真让 Agent 干过、并且它翻过车的活。

每个任务至少配一个确定性判定器。 会踩是因为模型判定器写起来最快，一段自然语言就完事，于是全用它。结果是判官自身的波动混进了结果，Agent 到底变没变差你分不出来。测试、构建、grep 匹配这类退出码判断先上，模型判定器只用来补那些确实没法用代码表达的部分。

单次运行的结论不要往外发。 会踩是因为 Agent 非确定性，跑一次很容易得到 100% 或者 0%。至少跑 3 次看一致性列，这也是 pass@k 和 pass^k 要分开报的原因。

不要把 pass@3 当成稳定性证明。 会踩是因为两个指标名字太像。pass@3 是”三次里至少成一次”，一个三次只成一次的 Agent 照样满足 pass@3。发布关键路径上要看的是 pass^3。

评测定义要进版本库。 会踩是因为评测一开始都写在临时文件或者聊天记录里，两周后没人知道当初的通过标准是什么，也就没法解释这次的数字为什么变了。harness 给的位置是 .claude/evals/ 下的定义文件加日志文件，跟着代码一起提交。

注意这类套件会往你的机器上写东西。 ECC 仓库根目录带 install.sh 和 install.ps1，还有 hooks/、mcp-configs/、integrations/ 这些目录。技能、命令、钩子最终都要落到你的配置目录里，钩子还会在会话事件上自动触发。装之前先读安装脚本，知道它改了哪些文件、注册了哪些钩子，之后才好回滚。

别指望它替你写评测集。 会踩是因为”评测框架”这个词容易让人以为装完就有分数看。这套东西提供的是格式、口径和纪律，任务、提示词、判定标准全都要你写。写这批任务的时间，才是真正的成本大头。

收尾：一份最小自检

改配置之前，先回答四个问题：改动前的基线数字是什么、用哪几个任务测、通过标准是确定性判定还是模型判定、跑几次。四个都答不上来，那么改完之后的”感觉更好了”就仍然只是感觉。

想动手的话，按这个顺序读仓库文件最省事：先 skills/eval-harness/SKILL.md（拿口径和产物布局），再 skills/agent-eval/SKILL.md（拿任务 YAML 的结构和判定器分类），然后 skills/ai-regression-testing/SKILL.md（看 AI 自审盲区的真实案例），最后按需翻 skills/agent-self-evaluation/SKILL.md 和 agents/agent-evaluator.md（拿评分表和只读权限白名单的写法）。项目采用 MIT 许可证，这几段格式和纪律照着搬没有障碍——但工具本体和评测内容，还得你自己攒。

本文属于 ECC 开源 Agent 套件专题（共 40 篇，从选择性安装一直拆到内部机制）。同一批还写了另一种取向的项目——不给你资产、只给你纪律的 superpowers 方法论专题。