开源 Agent 套件 ECC 的 94 个命令导航：分组线索与调用链
本文基于 ECC 仓库 commit 591ab5c（2026-07-29）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/affaan-m/ECC 最新代码与文档为准。
在 ECC 这套 harness 增强件里，命令目录里的 94 个 .md 文件才是唯一的事实来源，两份索引文档都只是它的投影，而且投影会失真。 你如果指望靠一张速查表把 94 条命令记下来，多半会在第三天放弃；但你如果知道这些命令是按几条互不重叠的线索堆起来的，再知道每条命令的正文自己就写着它要干什么，导航这件事就退化成了「按线索缩小范围，然后打开那个文件读三十秒」。
这篇讲的是后一种用法。
一、你面对的不是一张平铺的菜单
ECC 是一套装在编码 Agent 之上的增强件，采用 MIT 许可证。它往你的 harness 里塞三类东西：agents/ 目录下 67 个 agent 定义、skills/ 目录下 281 个技能、commands/ 目录下 94 个命令。三者数量差得很远，这本身就是第一条导航线索——命令是最窄的那一层，它更像是入口按钮，真正的行为分散在 agent 和技能里。
仓库里有两份东西试图帮你索引这 94 条命令：
COMMANDS-QUICK-REF.md 是人写的速查表，顶部交代了背景（94 条命令全局安装，在会话里敲 / 唤起），下面按主题切成一串分组：核心工作流、测试、代码审查、构建修复、编排式功能工作流、PRP 工作流、Epic 协作、规划与架构、会话管理、跨 harness 记忆 CLI、学习与改进、重构清理、文档与调研、循环与自动化、项目与基础设施、市场营销，末尾还有一张「已退休命令」对照表和一段决策指引。
docs/COMMAND-REGISTRY.json 是机器生成的清单，每条命令一个对象，带 command、description、type、primaryAgents、allAgents、skills、path 七个字段，末尾附一段 statistics。
两份东西的可信度不一样，第四节展开说。先说分组。
二、命令按三条线索分组，你得同时用
线索一：命名前缀就是家族。 打开 commands/ 扫一眼文件名，几个前缀立刻跳出来——orch- 是编排式功能工作流（新增功能、从设计文档起 MVP、改既有功能、修缺陷、行为保持的重构、评审 diff），prp- 是 PRD 到 PR 的那一串，epic- 是围绕 GitHub issue 的协作动作，multi- 是多模型协作，hookify- 管钩子规则，instinct- 管学到的经验条目，loop- 和 gan- 是两类循环。认前缀比认功能快得多。
线索二：语言/框架 × 动作的二维网格。 另一大批命令是「语言名 + 动作」的笛卡儿积：审查有 /python-review、/go-review、/kotlin-review、/rust-review、/cpp-review、/flutter-review、/react-review、/vue-review、/fastapi-review；构建修复有 /go-build、/kotlin-build、/rust-build、/cpp-build、/gradle-build、/flutter-build、/react-build；测试有 /go-test、/kotlin-test、/rust-test、/cpp-test、/flutter-test、/react-test。
这张网格是有洞的，而洞本身就是信息：Python 和 Vue 有审查命令，却没有对应的构建修复和测试命令。同时 agents/ 目录里躺着 django-reviewer.md 和 django-build-resolver.md，commands/ 里却找不到任何 django 命令。也就是说，能力面比命令面宽——有些 agent 只能被直接点名调用，没有斜杠入口。docs/COMMAND-AGENT-MAP.md 末尾专门为 typescript-reviewer 列了一张「直接使用的 agent」表，写明「还没有专门的斜杠命令时，直接调这个 agent」。
线索三：这条命令属于哪个协作阶段。 速查表的分组走的是这条线索，它跨语言、跨前缀。同一件事在不同阶段有不同入口：想让模型先想清楚再动手用 /plan；想把计划扔进浏览器里批注和批准用 /plan-canvas；想让两个独立的模型评审都点头才放行，用 /santa-loop。这条线索最贴近你的实际工作流，但最难靠文件名猜出来，速查表在这里是有价值的。
三条线索谁都不能单独用。你按前缀能找到家族，按网格能找到语言，按阶段才能判断此刻该敲哪一个。
三、每天真会用到的其实就那么几条
94 条里绝大多数是你一年碰不到两次的。按仓库自带的决策指引和命令描述判断，高频的是这几类：
开工前的 /plan。 它的命令文件写得很明确：复述需求、评估风险、给出分步实现计划，然后等你确认后再碰代码。这个「等确认」是写进命令正文的硬约束，不是随手一提。
写完之后的 /code-review。 它一条命令带两种模式：不给参数就评审本地未提交的改动，给一个 PR 号或 PR 链接就切到 PR 模式。命令文件开头的模式选择逻辑就是照着 $ARGUMENTS 里有没有 PR 标识来分叉的。
构建崩了的 /build-fix。 它会先探测项目的构建系统，再把活派给对应的构建修复 agent，你不用自己记是该敲 /rust-build 还是 /cpp-build。当然你知道栈的时候直接敲专用的那条更省一次判断。
跨天工作的会话三件套。 /save-session 把会话状态存到 ~/.claude/session-data/，/resume-session 把最近一次捞回来接着干，/sessions 用来浏览、检索和管理这些历史。另有 /checkpoint，它是在跑完验证检查之后创建、校验或列出工作流检查点——注意先后顺序，它记录的是「验证过了」这个事实。
不是斜杠命令的那一族：ecc memory。 速查表专门辟了一节讲清楚，这几条是 ecc CLI 命令而非斜杠命令，它们操作的是一个可直接阅读的 Markdown 记忆库，横跨 Claude、Codex、Hermes、OpenClaw、Kimi 等多个 harness。子命令是 init、save、handoff、search、read、doctor，另有一个可选的本地 stdio MCP 服务 ecc-memory-mcp。两条设计约束写在同一节里，都很硬：记忆正文只能用 --stdin 或 --body-file 传，故意不接受命令行取值；召回的记忆是不可信上下文，不是可执行指令，也不是策略。
四、命令背后到底调起了谁
一条斜杠命令落地时可能是四种东西之一：内联执行的提示词、委派给某个 agent、转交给某个技能、或者调一个脚本。分清楚这个很重要，因为它决定了出问题时你该去哪个文件里看。
| 组成部分 | 它负责什么 | 对应仓库位置 | 你什么时候会碰到它 |
|---|---|---|---|
| 命令文件 | 一条斜杠命令的全部正文，含 frontmatter 里的 description 和 argument-hint | commands/plan.md、commands/code-review.md | 想确切知道某条命令会做什么、接什么参数 |
| agent 定义 | 被命令委派的专职角色 | agents/code-reviewer.md、agents/go-build-resolver.md | 命令描述里出现「invokes the … agent」 |
| 技能 | 命令转交出去的完整工作流 | skills/tdd-workflow/、skills/verification-loop/ | 命令被退休、工作流搬进技能之后 |
| 手写的命令-agent 对照表 | 命令与 agent/技能的关系图谱 | docs/COMMAND-AGENT-MAP.md | 改名或删 agent 时排查引用 |
| 机器生成的命令清单 | 扫描命令目录产出的结构化 JSON | docs/COMMAND-REGISTRY.json | 想批量统计或做二次工具 |
| 清单生成脚本 | 决定清单里每个字段怎么来的 | scripts/ci/generate-command-registry.js | 发现清单字段可疑时 |
| 安装清单与档位 | 决定哪些东西装到哪个 harness 目录 | manifests/install-modules.json、manifests/install-profiles.json | 只想装一部分能力时 |
| 退休命令留档 | 老命令文件的兼容层 | legacy-command-shims/commands/ | 老教程里的命令敲不出来时 |
| 钩子运行时 | 在工具调用前后插入检查 | hooks/hooks.json | 装完发现某类调用被拦下 |
现在说那个失真。COMMAND-REGISTRY.json 里的 type、primaryAgents、skills 三个字段不是人工标注的，是脚本从命令正文里正则推断出来的。生成脚本里的分类函数长这样：
function inferCommandType(content, commandName) {
const lower = `${commandName}\n${content}`.toLowerCase();
if (commandName.startsWith('multi-') || lower.includes('orchestrat')) {
return 'orchestration';
}
if (lower.includes('test') || lower.includes('tdd') || lower.includes('coverage')) {
return 'testing';
}
它是把命令名和整篇正文拼起来转小写，然后按关键词顺次匹配。只要正文里任何一处出现了 test 这三个字母，这条命令就被打成 testing。结果就是清单末尾统计里 testing 那一栏占了一多半，连「回答一个题外问题」的 /aside 和「拉取最新仓库改动并重装」的 /auto-update 都被归进了 testing。这个 type 字段可以拿来做粗筛，不能拿来当分类事实。
agent 和技能的抽取同样是正则。它先把 agents/ 和 skills/ 目录下真实存在的名字读成集合，再拿几组模式去正文里捞，捞到的名字只有在集合里才保留。所以它有两个方向的偏差：一是漏。绝大多数命令的 primaryAgents 是空数组，包括 /code-review 和 /build-fix——它们的正文里没有以脚本认得的写法点名 agent，但手写的对照表里明明白白写着 /code-review 对应 code-reviewer、/build-fix 对应 build-error-resolver。二是多。技能的匹配模式里有一条会把正文中任何形如 /xxx 的记号当作候选技能名，于是 /plan 因为正文提到了 plan-canvas 就被记上了一个 plan-canvas 技能依赖，/multi-plan 也因此挂上了 accessibility。
反过来，手写的那份对照表也有它的时差：它至今还列着 /tdd、/e2e、/verify、/eval、/orchestrate、/claw，而速查表的退休表里已经写明这些命令被技能取代了，命令文件挪进了 legacy-command-shims/commands/，不在默认安装面里，维护中的工作流在 tdd-workflow、e2e-testing、verification-loop、eval-harness 这些技能里。
同样的时差还有更细的：速查表说 /cost-report 从一个 cost-tracker SQLite 数据库生成报告，而 commands/cost-report.md 自己写的是从 ~/.claude/metrics/costs.jsonl 读取，每次会话结束由 stop:cost-tracker 钩子追加一行 JSON，每行是该会话的累计快照，所以要按 session_id 取最新一行再跨会话求和。这条命令的真实行为在命令文件里，不在速查表里。
结论只有一句：索引用来缩小范围，命令文件用来确认行为。 顺带一提，/plan 的命令文件里还写着「默认内联执行，默认不要调 Task 工具或任何子 agent」，理由是让这条命令在只装了命令、没装 agent 文件的插件式安装里也能用；而对照表把它标成走 planner agent。两边都不算错，但你要是照着对照表去 debug 为什么没看到 agent 被拉起来，就白花时间了。仓库里还有一条 /ecc-guide 命令，它的定位就是从仓库当前形态回答「我该用哪个面」，而不是背诵可能过期的目录统计。
想理解斜杠命令这个机制本身是怎么回事、自己怎么写一条，可以先看站内的 斜杠命令怎么写 和 Claude Code 上手教程——那两篇讲的是通用方法论和自建路径；这篇讲的是一个真实开源项目把这套方法论铺到 94 条命令规模之后，长成了什么样、哪里开始变形。同理，技能机制、子 agent 的用法 和 钩子机制 讲的是底层机制，ECC 只是这些机制上的一种具体堆法。
五、边界与代价：它放弃了什么
这套东西不是纯读的，它会往你机器上写文件、挂钩子、并且允许接外部服务。该讲清楚的代价有这些。
它是全局装的，而且不止装进一个 harness。 安装配置的 schema 里，目标枚举是 claude（写进 ~/.claude/）、claude-project（写进当前项目的 ./.claude/）、cursor、antigravity、codex、gemini、opencode、codebuddy、joycode、qwen、zed、hermes、openclaw、kimi。安装档位在 manifests/install-profiles.json 里，一共七个：minimal 明确说明不装钩子运行时，opencode 档也刻意排除了钩子运行时、要用得显式加模块，developer 是默认工程档，full 是把当前已分类的模块全装，另有 core、security、research。没挑档位就一把梭的话，94 条命令会一次性挤进你的补全列表，这对上下文和你自己的注意力都是开销。
钩子会介入你的工具调用。 hooks/hooks.json 里配的是标准的钩子生命周期，其中 PreToolUse 就带着匹配 Bash 的条目。这意味着装了钩子运行时之后，你的 Bash 调用会先过一段本地脚本。好处是能拦住不该发生的事，代价是多了一层你自己得会排查的间接层——一旦某个命令莫名其妙不动了，钩子是第一嫌疑人。
它明确不管的事。 它不替你决定模型和额度怎么花，/model-route 只给一个模型档位建议，/cost-report 只把本地记录的消耗汇总给你看；各家服务商的计费与限制规则不同且会调整，以官方最新说明为准。它也不保证命令描述与实现同步——上一节那几处漂移就是现成的例子。语言覆盖不齐，你用的栈没进那张网格就只能走通用命令。记忆库是可直接阅读的 Markdown，给了你可审计性，代价是这些文件摊在你的磁盘上；ecc memory doctor 存在的意义正是承认它们会坏——它报告格式异常的文件、重复的 ID、断掉的链接和跳过的符号链接。
六、上手清单：为什么会踩，怎么避
别拿 COMMAND-REGISTRY.json 的 type 当分类依据。 会踩是因为它长得像人工标注的结构化数据，字段名也很正经。避法是先花两分钟读一遍 scripts/ci/generate-command-registry.js 里的推断函数，看清它是关键词匹配，然后只把这份 JSON 当索引和批量统计的原料，分类以速查表的主题分组为准。
别信任何一份文档里的 agent 归属，去读命令文件。 会踩是因为两份索引一份靠正则、一份靠手工，各有各的失真方向，而它们互相不校验。避法是任何一条你打算依赖的命令，动手前先打开 commands/<名字>.md 读它的 frontmatter 和前二十行，那里写着 description、argument-hint 和执行方式。
老教程里的命令敲不出来，先查退休表再报 bug。 会踩是因为 /tdd、/e2e、/verify、/eval、/orchestrate 这些名字在网上的旧文里到处都是，而它们已经变成技能了，命令文件挪进了 legacy-command-shims/commands/ 且不在默认安装面。避法是看速查表末尾的退休对照表，找到对应技能名，直接调技能。
装之前先挑档位，别默认全量。 会踩是因为一把梭最省事，装完才发现命令列表长得没法用、钩子还改了 Bash 的行为。避法是先看 manifests/install-profiles.json 的七个档位描述，选定后再用 /project-init 出一份 dry-run 的接入计划——这条命令的定位就是探测项目技术栈、参照安装清单给出干跑方案，命令文件里写明它应当从 dry-run 起步，只有你明确批准之后才写文件。
/checkpoint 之前先跑验证。 会踩是因为名字听着像「随手存个档」。它的描述是在跑完验证检查之后创建、校验或列出工作流检查点，顺序反了，你存下来的就是一个没被验证过的状态点，后面回滚时会误判。
记忆正文别塞进命令行。 会踩是因为 --body 这种写法太顺手了，而这套 CLI 故意不提供。避法是记住它只接 --stdin 和 --body-file，顺带把这条习惯带回你自己的工具里。
收尾：三十秒的自检
用之前问自己三句：这条命令的文件我打开过吗；它在我这台机器上会写哪些目录；它失败的时候我知道该看哪个文件吗。三句都有答案，94 这个数字就不吓人了。
要继续往下读，顺序建议是 COMMANDS-QUICK-REF.md 先扫一遍建立主题地图，再挑三五条你真会用的去读 commands/ 下对应的原文，然后是 manifests/install-profiles.json 决定装多少，最后才是 docs/COMMAND-AGENT-MAP.md 和 docs/COMMAND-REGISTRY.json——把这两份当地图看，别当合同看。至于它到底怎么把 67 个 agent 和 281 个技能编排起来协作，那是另一个层面的事，命令这一层只是入口。
本文属于 ECC 开源 Agent 套件专题（共 40 篇，从选择性安装一直拆到内部机制）。同一批还写了另一种取向的项目——不给你资产、只给你纪律的 superpowers 方法论专题。