ECC 能力载体面（Capability Surface）选型指南：把每个能力放进 Rule、Skill、MCP、CLI 与 API 中最窄的那一层

ECC 能力载体面（Capability Surface）选型指南：把每个能力放进 Rule、Skill、MCP、CLI 与 API 中最窄的那一层

【免费下载链接】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）本质是一个面向 Claude Code、Codex、Opencode、Cursor 等编码 Agent 的能力包：rules/、skills/、MCP 连接器、仓库脚本与 CLI、以及直接调用的远程 API，都是它可以承载能力的"载体面（surface）"。本指南基于仓库中的 docs/capability-surface-selection.md 决策文档展开，用于回答一个几乎所有 Agent 工程都会遇到的核心问题：一个新能力应该以什么形态交付？读完本文后，你将掌握 ECC 的"五问路由漏斗"，能够在确定性约束、按需剧本、跨客户端长驻工具、一次性本地动作与窄远程集成之间做出低成本、低抖动、可维护的放置决策，并理解其背后的仓库级实现证据。

为什么 ECC 需要一份"载体面选型"文档

ECC 不会把这几类载体面视为可互换的容器。正如同名文档开篇所强调的：目标是把每个能力放进在保证正确性的前提下最窄的那个载体面，从而：

• 控制 token 开销——例如 MCP 工具 schema 会注入到每一次会话，一个默认 MCP 无论是否被用到都会占用每个用户的上下文窗口；
• 避免无谓的运行时负担——长驻服务、进程启动、认证握手都有代价；
• 减少供应链拖累——少引入一个第三方依赖，就少一份安全审计与安装维护成本。

换句话说，"放在哪一层"不是组织洁癖，而是直接影响每次 Agent 会话的 token 消耗、启动速度与出故障概率的工程决策。仓库中 docs/token-optimization.md 专门讨论如何降低 token 消耗，其思路与载体面选型一脉相承：把大量确定性规则注入每次匹配的编辑，或把 ~30 个工具 schema 常驻每个会话，都是对 token 预算的隐性消耗。

速览：五类载体面的定位

决策顺序：五问路由漏斗

原文档给出的核心决策工具是一组按顺序提问的路由漏斗。按此顺序自问，命中即归属对应载体面：

1. 是否每次路径/事件匹配都必须发生，且不允许模型裁量参与？→ 放进rule（规则）。
2. 是否主要是剧本、工作流或建议层，只在任务真正需要时才应被加载？→ 放进skill（技能）。
3. 该能力是否需要结构化、可交互的工具/资源接口，并被多个 harness 或多个客户端反复调用？→ 放进MCP（连接器）。
4. 是否只是一个无需保持服务器存活的简单本地动作？→ 用本地CLI入口或仓库脚本；如有需要再包一层 skill。
5. 是否只是更大工作流内部的一个窄远程集成步骤？→ 直接在 skill 或脚本里调用外部API。

这条链路的本质是"由窄到宽、由轻到重"：从零常驻开销的规则开始，只有在当前载体面装不下的需求出现时，才升级到更宽的表面。

逐层详解：每种载体面的适用边界

Rule（规则）：确定性、常开的约束

何时用规则：

• 路径级（path-scoped）的编码不变式，例如"所有api/**的改动必须满足认证鉴权不变式"；
• 安全底线与权限约束，例如"代码中禁止硬编码密钥"；
• 应当始终生效的 harness/运行时约束；
• 不依赖模型自由裁量的确定性提醒。

何时不要用规则：

• 大型 playbook——它会膨胀每一次匹配到的编辑；
• 可选工作流；
• 只有部分时候才有价值的昂贵领域上下文。

在 ECC 仓库中，规则层按"公共层 + 语言层"组织：rules/README.md 说明了rules/common/存放语言无关的通用原则（coding-style、git-workflow、testing、performance、patterns、hooks、agents、security），各语言目录（rules/typescript/、rules/golang/、rules/python/等）在此之上叠加框架特有内容，且语言规则优先于公共规则（类似 CSS 特异性或.gitignore优先级）。这正体现了文档中"确定性、常开、路径匹配即注入"的定位——规则被设计为分层覆盖的常设约束，而不是按需阅读的参考材料。可以查看 rules/common/security.md 看到它的形态：一份"提交前必查"清单式的确定性安全底线。而规则的"事件匹配即注入"在实际运行中由 hooks 承载——hooks/hooks.json 中定义了大量PreToolUse/Edit|Write匹配器，把规则脚本挂到具体工具或事件上，确保每次触发都无模型裁量地执行。

Skill（技能）：按需加载的工作流与剧本

何时用 skill：

• 多步工作流；
• 强判断（judgment-heavy）的引导；
• 足够昂贵、只应"按需加载"的领域 playbook；
• 对脚本、API、MCP 工具及相邻 skill 的编排（orchestration）。

何时不要用 skill：不要把静态不变式倒进 skill 里当垃圾场——那些真正想要确定性路由的东西应当用 rule。这正是 rules/README.md 中 "Rules vs Skills" 一节的表述：rules 告诉你"该做什么"，skills 告诉你"怎么做"；rules 定义广泛适用的标准与检查清单，skills 提供具体任务的深度可操作参考（如python-patterns、golang-testing）。

仓库侧的形态佐证：skills/ 下有数百个领域技能目录，每个技能以根目录的SKILL.md为核心。文件头采用 YAML frontmatter，通过description让模型在"何时加载"上做相关性判断——这与文档"load only when relevant"的要求严格对应。例如 skills/github-ops/SKILL.md 的 description 精确描述"何时激活"（issue triage、PR 管理、CI 调试……），正文则给出多步操作剧本。

技能还分"可发布"与"仅本地"两类，见 docs/SKILL-PLACEMENT-POLICY.md：仓库内skills/下的 curated 技能会被写进 manifests/install-modules.json 并随安装发布；而 learned / imported / evolved 技能存放在用户主目录下（如~/.claude/skills/learned/），仅本地生效、永不发布。也就是说，一个能力被选为 skill 之后，仍要进一步决定它是否值得作为 curated 技能进入安装清单。

MCP：跨客户端、有状态、可复用的长驻工具面

何时用 MCP，当能力受益于：

• 结构化工具输入/输出；
• 可复用的资源或提示；
• 跨客户端反复使用；
• 一个在 Claude Code、Codex、Cursor、OpenCode 及相关 harness 间稳定工作的接口；
• 一个长驻服务进程的运维开销物有所值。

何时避免 MCP：

• 任务只是一次性本地命令；
• 服务器唯一的工作是"shell out 一次"；
• 服务器的安装/运行时负担超过产品价值。

ECC 对这个载体面的态度极为克制。参见仓库配套的 docs/MCP-CONNECTOR-POLICY.md：ECC 默认只随安装带一个 MCP 连接器chrome-devtools，因为它满足两条标准——通用性（对每个目标 harness 的几乎所有用户都适用）且MCP 确实胜过 CLI/API 包装（交互式 CDP 会话的价值在于"被保持的会话"，而非一次性命令）。其余绝大多数能力都以"skill 包装 CLI 或 REST API"的形态存在，或作为 mcp-configs/mcp-servers.json 中的 opt-in 条目供用户自行启用。该 JSON 中_comments也明确写着 "Keep under 10 MCPs enabled to preserve context window"（保持启用数低于 10 个以保护上下文窗口），且支持用ECC_DISABLED_MCPS环境变量在安装/同步时过滤默认连接器。

值得注意的是：mcp-servers.json中保留了github、context7、exa-web-search、playwright、sequential-thinking等条目，但它们不再是默认连接器——2026 年 6 月的审计把其中的 GitHub 换成了ghCLI + skill（因为 ~30 个工具 schema 拖累每个会话），context7 换成了直接打 REST API 的文档查询 skill，playwright 换成了官方 CLI 驱动的 e2e skill，sequential-thinking则整体删除（现代 harness 的原生扩展思考已覆盖）。这正是"载体面选型不是一次性的"的活案例：能力与载体面的匹配会随平台演进被重新审计。

CLI / 仓库脚本：一次性的本地确定性动作

倾向使用本地脚本或 CLI，当：

• 动作是确定性的；
• 启动成本低；
• 工作流基本发生在本地；
• 暴露一个长驻工具/资源面没有收益。

这通常是以下场景的正确选择：lint/test/build 包装器、本地转换、小型安装器、每次调用运行一次的内容生成。在 ECC 仓库中，scripts/目录下的脚本集群（doctor.js、status.js、sessions-cli.js、skill-create-output.js等）与scripts/hooks/下的钩子脚本都是这一形态；它们按需执行、不需要长驻进程，复杂度远低于部署一个 MCP 服务器。

直接 API 调用：工作流内部的一个窄远程步骤

倾向在既有 skill 或脚本内直接调用 API，当：

• 集成面很窄；
• 远程动作是更大工作流的一部分；
• 暂时不需要可复用的传输层接口。

一旦同一远程集成变得核心化、高频化、多客户端化，才构成"毕业"为 MCP 载体的信号（见下文"落地启发式"）。

仓库中的直接 API 调用的典型样本是 skills/documentation-lookup/SKILL.md：它针对 Context7 的公开 REST 接口（/api/v2/libs/search、/api/v2/context）做两次无状态调用——resolve-library-id后再query-docs，并用 bearer key 认证；由于"没有会话状态需要维持"，它被实现为一个 skill 而非 MCP 服务器。同样地，skills/exa-search/SKILL.md 面向持有 API key 的用户提供 Exa 搜索能力，而默认搜索路径交给各 harness 原生 WebSearch。

成本与可靠性偏置：两可时的取舍

当两个选项都可行时，原文档给出明确的默认偏置顺序：

• 优先更小的运行时表面（smaller runtime surface）；
• 优先更低的 token 开销（lower token overhead）；
• 优先外部活动部件更少的路径（fewer external moving parts）；
• 优先 ECC 原生打包，而非引入又一个第三方依赖。

同时有一条硬性政策：不要把外部插件/包依赖常态化为一等 ECC 载体面，除非该能力确实值得承担维护、安全与安装负担。这一偏置在仓库中有非常具体的落地——docs/MCP-CONNECTOR-POLICY.md 的审计记录把六个"默认连接器"降级为 skill、脚本或直接删除，核心论据无一例外都是 token 开销、会话状态必要性、通用性（universality）与 API key 门槛。默认连接器集合"数量远低于十个，实践中 2026 年的严肃 harness 是零到两个外加原生内建"。

Repo 政策：引进"想法"而非"依赖"

当从外部仓库引入灵感时，ECC 的政策是：

• 复制底层想法，而不是外部依赖本身；
• 把它重打包为 ECC 原生的 rule / skill / 脚本 / MCP 载体面；
• 如果功能已被实质性扩展或重塑以适配 ECC，就重命名它；
• 避免随交付附带"请用户安装无关第三方包"的指令——除非该依赖是有意引入、经过审计且处于工作流核心位置。

这一点与上一节"优先 ECC 原生打包"一致，也与载体面选型本身呼应：外部仓库通常以"MCP 服务器"或"CLI 包"的形态被引入，而 ECC 要求在接入前先判断它是否真的需要那么宽的载体面。

示例映射：把决策落到具体能力上

原文档给出的五组典型判定，对应关系如下：

注意后三行的演化语义：同一个"远程搜索"能力在规模变大后可以升级为 MCP；而"账单门户会话创建"如果未来变成核心、高频、多客户端调用，就触发了毕业信号。

落地启发式：拿不准就从最小开始

原文档最后给出了一条务实的启发式——如果你不确定，先选更小的表面：

• 确定性不变式 → 先用rule；
• 引导/工作流 → 先用skill；
• 一次性执行 → 先用脚本；
• 只有当结构化服务器边界明显在"为自己付账"时，才升级到MCP。

这套启发式可以进一步提炼为两条长期适用的操作原则：

1. 窄化优先（narrowest-first）：每次把能力放进当前最窄且仍能保证正确性的载体面，用 token 预算与运维成本作为约束方程，而不是用功能清单。
2. 识别"毕业信号"：CLI 被多客户端反复调用、单一远程 API 变成工作流核心、stateless 请求开始需要会话状态/认证握手/流式返回——这些是把它提升到skill（包装编排）再到MCP（长驻工具面）的触发条件；反之亦然，平台原生能力吸收掉你的服务器功能时（如同sequential-thinking被原生扩展思考取代），就该做降级或删除审计。

载体面选型在 ECC 中不是一次性设计，而是随 harness 演进持续进行的"能力路由治理"：它以 docs/capability-surface-selection.md 的决策漏斗为统一语言，以 docs/MCP-CONNECTOR-POLICY.md、docs/SKILL-PLACEMENT-POLICY.md 等配套政策为落地约束，最终目标只有一个——让每个能力的运行时表面恰好等于其问题规模。

【免费下载链接】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