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/ECCECCEverything 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 预算的隐性消耗。速览五类载体面的定位载体面定位典型负载触发方式rules/规则确定性、常开、无模型裁量的约束安全底线、路径级编码不变式、运行时约束路径或事件匹配即注入skills/技能按需加载的工作流与高 token 剧本多步流程、领域 playbook、编排层模型判断相关后才加载MCP连接器有状态、结构化的长驻工具/资源面跨会话、跨客户端的交互式工具客户端常驻会话中调用CLI/ 仓库脚本一次性本地确定性动作lint/test/build 包装、本地转换、安装器按需执行一次直接API调用工作流内部的一个窄远程步骤单点远程集成查询一次远程服务在 skill 或脚本内部调用决策顺序五问路由漏斗原文档给出的核心决策工具是一组按顺序提问的路由漏斗。按此顺序自问命中即归属对应载体面是否每次路径/事件匹配都必须发生且不允许模型裁量参与→ 放进rule规则。是否主要是剧本、工作流或建议层只在任务真正需要时才应被加载→ 放进skill技能。该能力是否需要结构化、可交互的工具/资源接口并被多个 harness 或多个客户端反复调用→ 放进MCP连接器。是否只是一个无需保持服务器存活的简单本地动作→ 用本地CLI入口或仓库脚本如有需要再包一层 skill。是否只是更大工作流内部的一个窄远程集成步骤→ 直接在 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.mdECC 默认只随安装带一个 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 的文档查询 skillplaywright 换成了官方 CLI 驱动的 e2e skillsequential-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 要求在接入前先判断它是否真的需要那么宽的载体面。示例映射把决策落到具体能力上原文档给出的五组典型判定对应关系如下具体能力载体面判定仓库侧对应参照对api/**的所有编辑始终生效的后端认证不变式rulerules/common/security.md 式的确定性安全约束更深的 API 设计与分页 playbookskill领域型 SKILL.md如 skills/github-ops/SKILL.md跨多个 harness 复用的远程搜索工具面MCPmcp-configs/mcp-servers.json 中的 opt-in 条目读取本地文件并写报告的一次性仓库分析器本地CLI/ 脚本可选由skill包装scripts/下的一次性脚本集群更广的客户运营工作流中创建一次账单门户会话的步骤工作流内部直接API调用skills/documentation-lookup/SKILL.md 式的窄远程集成注意后三行的演化语义同一个远程搜索能力在规模变大后可以升级为 MCP而账单门户会话创建如果未来变成核心、高频、多客户端调用就触发了毕业信号。落地启发式拿不准就从最小开始原文档最后给出了一条务实的启发式——如果你不确定先选更小的表面确定性不变式 → 先用rule引导/工作流 → 先用skill一次性执行 → 先用脚本只有当结构化服务器边界明显在为自己付账时才升级到MCP。这套启发式可以进一步提炼为两条长期适用的操作原则窄化优先narrowest-first每次把能力放进当前最窄且仍能保证正确性的载体面用 token 预算与运维成本作为约束方程而不是用功能清单。识别毕业信号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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考