ECC 在 OpenClaw Harness 上的安装落地与健康检查：基于 .openclaw 目录的完整实战指南

本篇指南聚焦当前仓库为 OpenClaw（多智能体 Harness）预置的 .openclaw 集成层：它对应 ECC（Everything Claude Code）配置体系在 OpenClaw Harness 上的标准化安装目录，说明用一行命令完成手动安装、落地后的组件目录结构、为何绝不触碰 OpenClaw 原生配置，以及如何用 ecc-universal doctor 校验安装健康。读完你可以直接在本地为 OpenClaw 部署一套共享编码规则、可复用技能、斜杠命令与 Agent 指令，并掌握相应的底层安装器实现原理。

一、.openclaw/README.md 是什么：ECC 的 OpenClaw 集成入口

在当前仓库根目录下的 .openclaw/README.md 是一份面向 OpenClaw Harness 的“落地说明文档”。它声明该目录承载 ECC（Everything Claude Code）针对 OpenClaw Harness 的整套配置，并浓缩回答三个问题：装了什么、怎么手动装、装完注意什么。

从仓库结构看，ECC 是一个典型的“一源多目标”Harness 优化体系（项目描述中称为 agent harness performance optimization system），同类配置还出现在 .claude、.codex、.cursor、.opencode 等 Harness 命名空间中，而 OpenClaw 是众多受支持的安装目标之一。.openclaw/README.md 相当于该目标门类的“说明书与健康标准”：它不描述 ECC 全量能力，只精确描述 OpenClaw 场景下应出现的组件与最小安装路径，这与文档“主次分明、聚焦于本 Harness 目标”的定位一致。

二、ECC 会为 OpenClaw 安装什么

文档明确列出安装后在 .openclaw 目录中落地的四类内容，构成了 OpenClaw Harness 感知 ECC 能力的全部入口：

安装项	作用	仓库侧源内容
rules/ecc/	共享编码规则与工程规范	仓库根 rules 目录（含各语言/框架子目录，另有 rules/README.md 总览）
skills/ecc/	可复用技能库	仓库根 skills 目录下数百个可复用 Skill
commands/	斜杠命令（slash commands）	仓库根 commands 目录的命令文档与脚本
AGENTS.md	Agent 指令与项目级引导	仓库根 AGENTS.md

这一清单与安装清单 manifests/install-modules.json 相互印证：其中 rules-core、agents-core、commands-core、platform-configs 等模块的 targets 数组均把 openclaw 列为受支持目标，且 platform-configs 模块的 paths 中直接包含 ".openclaw"——也就是说，仓库内的 .openclaw 目录本身会作为配置源被搬运到安装目标中。

需要特别说明的是：当前仓库中的 .openclaw 目录仅含 README 与配置命名空间本身，真正的规则、技能、命令文件均位于仓库根，安装器负责在落地时按目标布局组织到对应子路径，因此“源码归源码、布局归布局”，这正是 ECC 统一清单驱动设计的体现。

三、手动安装：一行命令完成 OpenClaw 目标部署

文档给出的标准手动安装命令为：

bash ./install.sh --target openclaw --profile minimal

拆解这条命令，它在安装器语义中包含两层关键参数：

• --target openclaw：显式指定安装目标为 OpenClaw。从 scripts/doctor.js 的帮助文本可见其对 openclaw 目标的定位是“Install shared rules/skills/commands into ~/.openclaw/”，即向用户主目录下的 .openclaw 写入共享规则、技能与命令；
• --profile minimal：选用名为 minimal 的预置安装档。查 manifests/install-profiles.json 可知该档描述为“不含 Hook 运行时的低上下文 Claude Code 配置”，会依序装配 rules-core、agents-core、commands-core、platform-configs、workflow-quality 五个模块。结合上一节的 openclaw 目标匹配关系，minimal 恰好与文档列举的四类安装产物一一对应，且刻意排除了 hooks-runtime——这与 OpenClaw 目标不配置 ECC Hook 的设计一致（install-modules.json 中 hooks-runtime 模块的目标列表本就只覆盖 claude/cursor/opencode 等，不含 openclaw）。

3.1 install.sh 其实是一个 bash 包装器

从源码看，install.sh 并非安装逻辑本体，而是一个“Legacy shell 入口”：

• 通过 readlink 循环解析符号链接，定位真实的仓库/包根目录（便于在 npm bin 软链场景下仍能找到源码）；
• 当以 git clone 方式运行时，若缺少 node_modules 会自动执行 npm install --no-audit --no-fund；
• 在 MSYS2/Git Bash 环境下调用 cygpath -w 将 POSIX 路径转为 Windows 路径，规避 Git Bash 自动路径转换导致的重复路径问题；
• 最终 exec node scripts/install-apply.js "$@" 把参数透传给 Node 运行时。

真正干活的是 scripts/install-apply.js，它提供完整的参数语法，除 --profile 外还可组合使用 --modules <id,id,...>、--with <component> / --without <component>、--skills <skill-id>、--dry-run、--json 以及 --config <path>。因此面向 OpenClaw 的安装并不只有 minimal 一种选择，你可以例如用：

bash ./install.sh --target openclaw --modules rules-core,commands-core --with some-component

做精细裁剪，或加 --dry-run 先预览将要落地的文件而不实际写入。

3.2 源码侧的“OpenClaw 目标适配器”

安装器之所以能理解“目标叫 openclaw、根目录是 ~/.openclaw、状态文件叫 ecc-install-state.json”，是因为注册表中挂载了专门的适配器。核心证据有三处：

• scripts/lib/install-targets/openclaw-home.js：声明适配器 id: 'openclaw-home'、target: 'openclaw'、kind: 'home'，并以 rootSegments: ['.openclaw'] 表达“用户主目录下的一级目录”，同时定义安装状态文件为 ecc-install-state.json；
• scripts/lib/install-targets/helpers.js：维护 '.openclaw': 'openclaw' 的目录名到目标名的映射；
• scripts/lib/install-targets/registry.js：把 openclawHome 适配器统一注册进目标注册表。

从这一结构可以推断：安装完成后，~/.openclaw/ecc-install-state.json 会记录本次安装的模块与目标元数据，供后续健康检查与增量安装判定使用。

四、设计边界：绝不触碰 OpenClaw 自身配置

文档在 Notes 一节做出了一条明确承诺：

OpenClaw 自身的配置文件（openclaw.json、config.toml、.env 等）不会被 ECC 安装所触碰。

这是 ECC 与 Harness 集成时最重要的边界原则：ECC 只做“能力追加”（写入自己的 rules/skills/commands/AGENTS.md 与状态文件），不干预 Harness 的启动配置、模型路由、凭据与运行参数。对使用者而言，这意味着：

• 安装 ECC 后 OpenClaw 原有的行为与安全设置不受影响，卸载只需移除 ECC 自身产物；
• openclaw.json / config.toml 中关于模型、工具、Agent 的既有配置可放心保留，不存在被覆盖的升级风险；
• 若 OpenClaw 后续调整自身配置导致功能异常，排查时可先隔离 ECC 影响面，因为二者写入路径完全分离。

该原则同样体现在模块设计上：OpenClaw 目标默认不安装 hooks-runtime，即 ECC 不会向该 Harness 注入运行期 Hook 拦截逻辑，进一步降低了侵入性。

五、安装后的健康检查：ecc-universal doctor

文档提供的健康检查命令为：

npx ecc-universal doctor --target openclaw

这条命令的语义可从仓库源码得到印证：

• 仓库在 package.json 中以 "name": "ecc-universal" 命名包，bin 将 ecc-universal 指向 scripts/ecc.js，因此 npx ecc-universal doctor ... 实际路由到同一套 doctor 实现；
• 底层的 scripts/doctor.js 用法声明为 node scripts/doctor.js [--target <supported-targets>] [--json]，支持 --target 显式指定目标、--json 输出结构化结果以便脚本消费。

于是你也可以跳过 npx 直接执行：

node scripts/doctor.js --target openclaw

doctor 会以 openclaw 为目标校验安装健康度，覆盖安装状态文件是否存在、模块清单是否齐备、目录结构是否符合预期等内容；--json 模式适合接入 CI 或本地自动化巡检。文档将健康检查列为安装后的默认收尾动作，这与“安装 → 校验”闭环的工程习惯一致。

六、参考同类目标理解 OpenClaw 定位（可选视野）

虽然本文聚焦 OpenClaw，但理解它在 ECC 目标矩阵中的位置有助于判断适用边界。doctor 帮助文本与安装清单显示，ECC 支持 claude（默认、含托管 rules 与扁平 skills）、claude-project、cursor、codex、opencode、gemini、openclaw、hermes、kimi、adal 等十余个目标；其中 openclaw 属于“共享规则/技能/命令写入用户主目录”的家庭目录（home）型目标，与 cursor/codex 这类“项目内 .xxx 目录”型目标在写入位置上不同。这一差异决定了：

• OpenClaw 的 ECC 能力是跨项目共享的（写于 ~/.openclaw/），而非绑定到单一代码仓库；
• 使用 --profile minimal 时不会部署 Hook 运行时，因而天然适配“尽量少侵入 Harness”的 OpenClaw 集成策略。

小结

围绕 .openclaw/README.md，可以把 ECC 对 OpenClaw 的集成概括为一条主线：内容上安装 rules/ecc、skills/ecc、commands、AGENTS.md 四类能力；操作上执行 bash ./install.sh --target openclaw --profile minimal 即可完成最小安装；边界上绝不写 OpenClaw 自身的 openclaw.json、config.toml、.env；验收上用 npx ecc-universal doctor --target openclaw 校验健康。配合 scripts/lib/install-targets/openclaw-home.js、manifests/install-modules.json 与 manifests/install-profiles.json 等源码清单，你既能在命令行中快速落地，也能在出问题时深入安装器内部定位根因。