前面的文章已经完成了三层分析第一层 Marketplace、Plugin 与 Skill 的目录和配置结构 第二层 Marketplace 与 Plugin 如何安装、缓存和落盘 第三层 Harness 如何扫描 Plugin并将文件转化为运行时能力经过这些步骤Claude Code 当前会话中可能同时存在多种能力来源Claude Code 内置能力 企业 Managed 配置 用户级配置 项目级配置 本地项目配置 项目自定义 Skill 和 Agent 用户自定义 Skill 和 Agent 多个 Marketplace 安装的 Plugin 项目 MCP Server 用户 MCP Server Plugin MCP Server 多个生命周期 Hook当这些能力不存在重名和冲突时Harness 只需要将它们合并。真正复杂的是下面这些场景用户级启用了某个 Plugin 项目级又禁用了它。 项目级要求启用一个 Plugin 但当前开发者不想在本机使用。 用户和项目分别定义了同名 Skill。 项目 Skill 和 Plugin Skill 都叫 code-review。 多个 Plugin 都提供 reviewer Agent。 多个 Hook 同时拦截 Bash。 用户、项目和 Plugin 都定义了同一个 MCP Server。 同一个 Plugin 的不同版本同时存在于 Cache。这时Harness 必须回答哪个配置优先 哪些能力会覆盖 哪些能力可以并存 哪些配置不是覆盖而是合并 冲突按照名称、来源还是 Endpoint 判断 最终加载的是哪个 Plugin 版本因此本篇重点分析User / Project / Local / Managed 如何合并 Skill、Command 和 Agent 的同名规则 Plugin 能力与项目自定义能力的关系 多个 Hook 如何共同执行 MCP Server 与 Tool 如何解决冲突 同一个 Plugin 多版本时如何选择一、先建立 Claude Code 的作用域模型Claude Code 的配置不是来自单一文件而是来自多个层级。最常见的四个作用域是Managed User Project Local此外命令行参数还可以对当前 Session 进行临时覆盖。官方文档给出的普通设置优先级是Managed ↓ Command Line ↓ Local ↓ Project ↓ User其中 Managed 优先级最高User 最低。对应文件大致为作用域典型位置主要用途Managed系统托管配置企业强制策略User~/.claude/settings.json用户全局偏好Project.claude/settings.json团队共享配置Local.claude/settings.local.json当前用户、当前项目覆盖Command LineCLI 参数当前 Session 临时配置这套优先级的核心逻辑是越接近当前环境的配置 通常越具体。 越受管理员控制的配置 通常越不可覆盖。但需要注意不是所有配置项都使用完全相同的“覆盖”规则。Claude Code 中至少存在三种不同的合并方式标量配置 → 高优先级覆盖低优先级 数组和集合配置 → 通常合并或拼接 权限、Hook 等特殊配置 → 使用各自独立的合并逻辑官方设置文档也明确指出普通设置按优先级处理但权限规则并非简单覆盖而是会跨作用域合并。因此不能只记住一条Local Project User还要继续看具体能力属于哪一种合并模型。二、Plugin 启用状态如何合并Plugin 是否进入 Harness Runtime主要由enabledPlugins决定。配置形式为{enabledPlugins:{formattercompany-tools:true,security-reviewcompany-tools:false}}Plugin 使用完整 IDplugin-namemarketplace-name作为配置键。这意味着同名 Plugin 如果来自不同 Marketplace逻辑上仍然是两个不同的 Pluginformattercompany-tools formattercommunity-tools1. Project 可以覆盖 User假设用户级配置为{enabledPlugins:{formattercompany-tools:false}}而项目级配置为{enabledPlugins:{formattercompany-tools:true}}最终项目级配置生效formatter enabled官方文档明确说明Project 设置优先于 User因此用户级将 Plugin 设置为false不能关闭项目级明确启用的 Plugin。这符合普通设置优先级Project User2. Local 可以覆盖 Project如果项目团队要求启用某个 Plugin// .claude/settings.json{enabledPlugins:{formattercompany-tools:true}}当前开发者可以在.claude/settings.local.json中加入{enabledPlugins:{formattercompany-tools:false}}最终当前机器上该 Plugin 被禁用。官方文档也明确推荐如果要在自己的机器上退出项目启用的 Plugin应在 Local 设置中写入false。所以Project Settings → 表达团队期望 Local Settings → 表达当前开发者在本项目中的覆盖完整过程是User formatter false Project formatter true Local formatter false 最终 formatter false因为Local Project User3. Managed 可以强制启用或禁止如果 Plugin 在 Managed 配置中被强制启用那么 User、Project 和 Local 都不能关闭它。Managed true Local false Project false User false 最终 true同样Managed 还可以通过 Marketplace 白名单限制 Plugin 来源并在网络和文件系统操作发生之前阻止未经批准的 Marketplace。因此Managed 不只是普通的更高层配置而是Policy Boundary它代表企业最终安全策略。4. 没有显式配置时使用defaultEnabled如果某个 Plugin 在所有作用域中都没有对应的enabledPlugins条目Claude Code 会回退到 Plugin 自身的defaultEnabled配置。因此最终状态的计算可以抽象成Managed 是否指定 ↓ 否 Local 是否指定 ↓ 否 Project 是否指定 ↓ 否 User 是否指定 ↓ 否 使用 Plugin defaultEnabled伪代码类似functionresolvePluginEnabled(pluginId,scopes,manifest){if(scopes.managed.has(pluginId)){returnscopes.managed.get(pluginId);}if(scopes.local.has(pluginId)){returnscopes.local.get(pluginId);}if(scopes.project.has(pluginId)){returnscopes.project.get(pluginId);}if(scopes.user.has(pluginId)){returnscopes.user.get(pluginId);}returnmanifest.defaultEnabled??true;}这段代码是对官方规则的工程化抽象不代表 Claude Code 的真实内部实现。三、Skill 与 Command 的同名规则Plugin 是否启用只是第一层。Plugin 被启用后Harness 还要处理不同来源能力之间的名称冲突。Skill 是其中规则最明确的一类。Claude Code 当前的 Skill 来源包括Enterprise Skill Personal Skill Project Skill Nested Project Skill Plugin Skill Bundled Skill Legacy Command1. 普通 Skill 的优先级官方 Skill 文档给出的优先级是Enterprise Personal Project Bundled也就是说当不同层级存在同名 Skill 时Enterprise Skill 覆盖 Personal Skill Personal Skill 覆盖 Project Skill 任意自定义 Skill 覆盖同名 Bundled Skill例如内置 /code-review 项目 .claude/skills/code-review/SKILL.md则项目 Skill 会替代内置/code-review。这里有一个容易产生疑问的地方普通 Settings 是 Project 高于 User但 Skill 却是 Personal 高于 Project。这是官方当前明确给出的 Skill 特殊规则。因此需要区分Settings Precedence ≠ Skill Name PrecedenceClaude Code 并没有用一套完全统一的优先级覆盖所有能力类型。2. Skill 与旧 Command 同名时Skill 优先Claude Code 当前已经将自定义 Command 体系合并进 Skill。下面两个文件都可以创建/deploy.claude/commands/deploy.md .claude/skills/deploy/SKILL.md但如果二者同名Skill 优先。因此Skill Legacy Command从架构上看这是为了推动旧的单文件 Command 向功能更完整的 Skill Package 迁移。因为 Skill 除了SKILL.md还可以携带references/ examples/ scripts/ assets/3. Plugin Skill 使用命名空间不与普通 Skill 直接冲突Plugin Skill 不直接使用裸名称而是带 Plugin 命名空间plugin-name:skill-name例如plugin-dev:plugin-structure security-tools:code-review因此下面两个 Skill 可以同时存在项目 Skill /code-review Plugin Skill /security-tools:code-review官方文档明确指出Plugin Skill 使用命名空间所以不会与 Enterprise、Personal、Project 和 Bundled Skill 直接冲突。这意味着项目自定义能力 → 适合覆盖内置默认行为 Plugin 能力 → 通过命名空间与其他来源并存所以“项目 Skill 与 Plugin Skill 谁优先”这个问题通常并不是覆盖关系而是二者同时保留 使用不同调用名称4. 不同 Plugin 的同名 Skill 可以并存假设两个 Plugin 都提供reviewSkillplugin-a:review plugin-b:review它们不会冲突因为完整名称不同。/plugin-a:review /plugin-b:review这也是 Plugin Namespace 的主要价值同名能力 不同来源 可以共存但自动匹配时模型仍然可能同时看到两个语义相似的 Skill Description。此时不再是注册表名称冲突而是Semantic Routing Conflict例如plugin-a:review → General code review plugin-b:review → Security-focused code review如果 Description 写得不够清楚模型可能选错 Skill 同时加载多个 Skill 不确定应该使用哪一个因此命名空间解决了“技术上的名称冲突”但没有完全解决“语义上的能力重叠”。5. Nested Skill 不覆盖而是使用目录限定名Claude Code 还支持 Monorepo 中的嵌套 Skill。例如.claude/skills/deploy/SKILL.md apps/web/.claude/skills/deploy/SKILL.md二者不会简单覆盖。根目录 Skill 保持/deploy嵌套 Skill 会获得目录限定名/apps/web:deployClaude 会根据当前正在处理的文件选择适合的变体用户也可以显式调用限定名称。因此Nested Skill 的处理方式是保留两份 增加目录命名空间 根据工作目录和文件范围路由而不是传统的最后写入覆盖。四、Agent 的同名与作用域规则Claude Code Agent 主要来自Managed Agents Project Agents User Agents Plugin Agents CLI --agents不同来源之间同样存在优先级和命名空间问题。1. Managed Agent 优先于 Project 和 User官方 Subagent 文档明确说明Managed Agent Project Agent User Agent至少在同名冲突时Managed 定义会覆盖 Project 和 User。例如Managed security-reviewer Project security-reviewer User security-reviewer最终生效的是 Managed 版本。这是合理的因为企业可能要求所有项目使用统一的安全审查 Agent不能被个人替换。2. Plugin Agent 使用 Scoped NamePlugin Agent 会自动加载并以带作用域的名称出现在 Agent 选择中。例如plugin-dev:plugin-validator security-tools:reviewer因此项目 Agent reviewer Plugin Agent security-tools:reviewer可以同时存在。这与 Plugin Skill 的命名空间逻辑一致Plugin Capability Plugin Namespace Component Name3. 不同 Plugin 的同名 Agent 可以共存例如plugin-a:reviewer plugin-b:reviewerHarness Registry 中它们是两个不同的 Agent Definition。调用时可以显式选择plugin-a:reviewer plugin-b:reviewer但模型自动委托时仍可能遇到语义重叠。因此Agent Description 应明确区分适用任务 专业领域 可用工具 是否应主动调用 不适用场景4. Plugin Agent 的高风险字段不会参与覆盖Plugin Agent 即使声明hooks mcpServers permissionMode这些字段也会在加载 Plugin Agent 时被忽略。因此不存在下面这种冲突Plugin Agent permissionMode 覆盖 Project permissionMode因为 Plugin Agent 根本无权进入这个优先级竞争。这体现了一个重要设计不是所有配置都应该进入“谁优先”的比较部分高风险配置应该在更低层直接失效。五、Plugin 能力与项目自定义能力谁优先这个问题不能用一句Project Plugin简单回答。因为不同能力类型使用不同策略。1. Skill通常并存不直接覆盖项目 Skill /review Plugin Skill /security-plugin:review二者名称不同因此并存。项目 Skill 可以覆盖同名 Bundled Skill但不会覆盖带 Plugin Namespace 的 Skill。2. Agent通常并存不直接覆盖项目 Agent reviewer Plugin Agent security-plugin:reviewer同样通过 Namespace 共存。3. Hook不是覆盖而是全部合并执行项目 Hook 与 Plugin Hook 如果匹配同一事件不是选择其中一个而是都执行。Project Hook Plugin A Hook Plugin B Hook ↓ 共同加入 Hook Registry具体结果在后面单独分析。4. MCP可能根据名称或 Endpoint 去重项目 MCP 与 Plugin MCP 并不总是同时连接。Claude Code 会根据 MCP 的来源和重复判断规则选择高优先级定义。5. Settings项目或本地可以控制 Plugin 是否加载虽然项目不能覆盖 Plugin 内部同名 Skill但项目可以通过enabledPlugins直接禁止整个 Plugin 进入 Runtime。因此项目对 Plugin 的控制点不是覆盖某个 Plugin Skill而是启用或禁用整个 Plugin如果需要修改 Plugin 中的某个具体 Skill通常应采用Fork Plugin 创建项目 Skill 显式调用项目版本 或者在 Local Scope 禁用原 Plugin六、多个 Hook 如何合并和排序Hook 与 Skill、Agent 最大的不同是Hook 冲突通常不是名称冲突而是事件和行为冲突。多个来源都可能注册PreToolUse PostToolUse SessionStart Stop SubagentStart当多个 Hook 匹配同一个事件时Claude Code 会执行所有匹配 Hook然后合并结果。1. 匹配的 Hook 会全部执行假设存在两个PreToolUseHookHook A 记录所有 Bash 命令 Hook B 阻止 rm -rf当 Agent 尝试执行rm-rf/tmp/build两个 Hook 都会执行。即使 Hook B 返回拒绝Hook A 仍然会完成日志记录。官方文档明确指出一个 Hook 返回deny不会阻止同级 Hook 执行。所以 Hook 模型不是找到第一个匹配项 ↓ 执行并停止而是找到所有匹配项 ↓ 并行或独立执行 ↓ 等待全部完成 ↓ 合并结果2. 不应依赖 Hook 的声明顺序阻止副作用因为所有匹配 Hook 都会执行所以不能设计Hook A 先判断是否危险 Hook B 只有 A 允许后才上传日志然后假设 A 的拒绝一定会阻止 B。官方文档明确提醒不应依赖一个 Hook 的deny来阻止另一个 Hook 的副作用。因此具有副作用的 Hook 必须自行检查安全条件。3. 决策结果采用最严格原则对于PreToolUse权限决策Claude Code 的合并顺序是deny defer ask allow也就是说只要任意一个 Hook 返回deny最终工具调用就会被拒绝。例如Hook Aallow Hook Bask Hook Cdeny 最终deny这是典型的Most Restrictive Wins安全策略。4.additionalContext会聚合如果多个 Hook 返回附加上下文Hook A 这是生产环境 Hook B 该模块包含支付逻辑Claude Code 会保留所有 Hook 的additionalContext并一起传递给模型。因此 Hook 的合并不只是布尔决策还可能是Decision Merge Context Aggregation5. Hook 冲突的真实风险多个 Hook 虽然不会出现简单覆盖但可能出现行为冲突两个 Formatter 重复修改同一文件 一个 Hook 自动 Commit 另一个 Hook 禁止 Git 写操作 多个 Hook 同时访问网络 两个 Hook 修改相同工具输入 一个 Hook 记录敏感信息 另一个 Hook 负责脱敏所以 Hook 系统真正需要的不是简单名称空间而是执行顺序可见 副作用可审计 决策合并规则明确 超时和失败隔离当前官方文档明确了匹配 Hook 全部执行和决策合并方式但并没有把 Hook 设计成传统的、可由用户精细排序的 Middleware Chain。七、MCP Server 如何处理重复和冲突MCP 是 Claude Code 中冲突规则最明确的能力之一。MCP Server 可能来自Local Scope Project Scope User Scope Plugin claude.ai Connector当同一个 Server 在多个地方定义时Claude Code 只连接一次并使用最高优先级来源的完整定义。其优先级是Local Project User Plugin claude.ai Connector1. MCP 配置不会逐字段合并假设 User Scope 定义{type:http,url:https://api.example.com/mcp,headers:{Authorization:Bearer user-token}}Project Scope 定义同名 Server{type:http,url:https://project.example.com/mcp}最终不会得到Project URL User Authorization Header而是完整使用 Project 定义。官方文档明确指出MCP Server 以最高优先级来源的完整 Entry 为准字段不会跨作用域合并。因此MCP Conflict Resolution Whole-entry Replacement而不是Field-level Merge2. Local、Project、User 按名称判断重复对于 Local、Project 和 User MCP重复判断主要使用 Server Name。例如Local database Project database User database最终只连接 Local 的database。3. Plugin 和 Connector 按 Endpoint 判断重复Plugin MCP 和 claude.ai Connector 的去重方式有所不同。官方文档说明前三个普通 Scope → 按名称匹配 Plugin 和 Connector → 按 Endpoint 匹配如果 Plugin MCP 与 Project MCP 指向同一个 URL 或 Command它会被视为重复并由更高优先级来源生效。这意味着 Plugin 不能通过换一个 Server Name重复连接一个项目已经定义的同一 Endpoint。4. Plugin MCP 的 Tool 使用多级命名空间Plugin MCP Tool 通常使用mcp__plugin_plugin_server__tool这种命名方式同时保留Plugin 来源 Server 来源 Tool 名称即使两个 MCP Server 都有query也可以区分mcp__plugin_database-tools_postgres__query mcp__plugin_analytics-tools_clickhouse__query所以 MCP Tool 层面的名称冲突主要通过多级命名空间解决。Server 层面的重复连接则通过 Scope 与 Endpoint 优先级解决。八、不同作用域安装不同版本 Plugin 时如何选择这是最容易被误判的一部分。Claude Code 的本地 Cache 可以同时保留一个 Plugin 的多个版本~/.claude/plugins/cache/ └── marketplace/ └── plugin/ ├── 1.0.0/ ├── 1.1.0/ └── 2.0.0/但磁盘上存在多个版本不代表同一个 Plugin ID 会在同一个 Session 中同时注册多套能力。1. Plugin 的逻辑身份不包含 ScopePlugin 启用配置使用plugin-namemarketplace-name而不是plugin-namemarketplace-namescope所以User Scope 的 formattercompany-tools Project Scope 的 formattercompany-tools在配置逻辑上仍然是同一个 Plugin ID。Scope 主要决定是否启用 配置由谁控制 配置是否共享而不是创建多个并行 Plugin 实例。2. 官方文档明确了启用优先级但未完整公开版本仲裁算法当前官方文档清楚说明了Managed / Local / Project / User 如何决定 Plugin 启用状态也说明 Plugin 安装后会进入版本化 Cache。但对于下面这种极端场景User Scope 安装 1.0.0 Project Scope 要求 2.0.0 Local Scope 又固定 1.5.0官方公开文档并没有给出一套完整、稳定的“版本优先级矩阵”。因此不能简单断言Local Version Project Version User Version因为 Scope 优先级明确作用于 Settings但 Plugin 版本还涉及Marketplace Entry Plugin Manifest Version 安装 Registry 当前 Cache Pointer Plugin Dependency Constraints 更新状态3. 更合理的运行模型根据当前公开结构可以做一个谨慎推断第一步 通过 Scope 解析 Plugin 是否启用 第二步 根据安装 Registry 确定该 Plugin ID 当前解析版本 第三步 从对应版本 Cache 加载一份 Plugin 第四步 旧版本 Cache 只用于正在运行的旧 Session或延迟清理也就是说多个 Scope → 决定启用状态 安装 Registry → 决定当前 Active Version 版本化 Cache → 保存新旧物理副本这是基于公开行为的工程化推断不应当当作 Anthropic 已发布的内部算法。4. 项目配置并不会自动把版本文件提交进仓库项目级启用 Plugin通常只是向.claude/settings.json写入 Plugin ID。它不会把完整 Plugin Cache 和版本副本提交给团队成员。官方文档也说明项目配置中启用外部 Plugin并不会替其他成员自动完成安装每个用户仍需安装并信任 Plugin。因此团队成员可能在不同时间安装到不同版本。这会带来同一项目 不同开发者 Plugin 实际版本不一致如果团队要求可重复构建应进一步使用固定 Marketplace Ref 固定 Plugin Version 固定 Git SHA Plugin Dependency Constraints 企业 Seed Cache而不能只依赖{enabledPlugins:{formattercompany-tools:true}}因为这只表达“需要启用”不一定完整表达“必须是哪个不可变版本”。九、不同能力类型的冲突策略对比到这里可以将 Claude Code 的不同能力冲突规则放在一起比较。能力类型冲突标识主要处理方式Settings配置 Key高优先级 Scope 覆盖Plugin 启用状态pluginmarketplaceManaged Local Project User普通 SkillSkill NameEnterprise Personal Project BundledSkill 与旧 CommandSlash NameSkill 优先Plugin Skillplugin:skill命名空间并存Nested Skilldirectory:skill目录限定名并存普通 AgentAgent NameManaged 优先于 Project/UserPlugin Agentplugin:agent命名空间并存HookEvent Matcher全部执行结果合并MCP 普通 ScopeServer NameLocal Project UserPlugin MCPEndpoint高优先级来源去重MCP Tool多级 Tool NamePlugin Server Tool 命名空间Plugin VersionPlugin ID Registry官方未完整公开多 Scope 版本仲裁这张表说明Claude Code 没有一套统一的“覆盖规则”而是根据不同能力类型采用不同冲突模型。可以归纳成四类。1. 覆盖模型Settings 普通 Skill 普通 Agent MCP Server同一标识只能保留一个最终定义。2. 命名空间模型Plugin Skill Plugin Agent Plugin Command Plugin MCP Tool Nested Skill通过完整名称让多个同名短名称共存。3. 聚合模型Hook Permission Rules additionalContext多个来源共同参与最后合并结果。4. 策略裁决模型Plugin 启用状态 PreToolUse 决策 企业 Marketplace 白名单通过明确的优先级或最严格原则得出最终结果。十、完整冲突计算案例假设当前环境存在以下配置。User Scope启用 formattercompany-tools 定义 reviewer Agent 定义 /deploy Skill 定义 database MCPProject Scope启用 securitycompany-tools 启用 formattercompany-tools 定义 reviewer Agent 定义 /deploy Skill 定义 database MCP 注册 PreToolUse HookLocal Scope禁用 formattercompany-tools 定义本地 database MCP 注册另一个 PreToolUse HookManaged Scope强制启用 complianceenterprise-tools 定义 reviewer Agent 限制 Marketplace 来源最终计算过程可以表示为第一步解析 Plugin 状态 compliance → Managed 强制启用 formatter → Local false 覆盖 Project true 和 User true security → Project true 生效第二步解析普通 Skill /deploy → Personal Skill 高于 Project Skill第三步解析 Agent reviewer → Managed Agent 优先第四步解析 MCP database → Local 定义优先于 Project 和 User → 完整使用 Local Entry不合并字段第五步合并 Hook Project PreToolUse Local PreToolUse → 两者都执行 若任意 Hook deny → 最终 deny最终 Runtime 可能是Enabled Plugins ├── complianceenterprise-tools └── securitycompany-tools Disabled Plugins └── formattercompany-tools Skills └── /deploy → Personal Version Agents └── reviewer → Managed Version MCP └── database → Local Definition Hooks └── PreToolUse ├── Project Hook └── Local Hook十一、从冲突规则看 Claude Code 的设计思想通过这些规则可以看到 Claude Code 的几个明显设计取向。1. 安全策略优先于个人偏好Managed 其他 Scope企业策略无法被个人配置绕过。2. Plugin 能力优先选择并存而不是覆盖Plugin Skill 和 Agent使用命名空间使不同 Marketplace 和不同 Plugin 的能力可以共存。plugin-a:review plugin-b:review这比全局裸名称更适合 Marketplace 生态。3. 本地能力强调开发者控制Local Scope 可以让开发者退出项目启用的 Plugin也可以覆盖 Project 和 User MCP。团队共享默认值 个人本地覆盖这是工程协作中很实用的设计。4. Hook 采用组合而不是替换Hook 被视为多个独立观察者和策略执行者。所有匹配 Hook 执行 最严格决策生效这种设计适合审计和安全控制但也可能带来副作用冲突。5. MCP 强调单一连接和完整 EntryMCP 不跨 Scope 拼接字段避免出现URL 来自 Project Token 来自 User Command 来自 Plugin这种难以审计的混合配置。十二、这套冲突模型的优势1. 企业可以建立不可绕过的策略Managed Scope 可以强制启用安全 Plugin、统一 Agent并限制 Marketplace 来源。2. 团队配置和个人偏好能够共存Project 提供团队默认值Local 允许当前开发者进行有限覆盖。3. Plugin 能力来源清晰通过 Namespace 可以看出能力来自哪个 Plugin4. 同名能力可以在生态中并存不同 Plugin 不需要为全局唯一短名称竞争。5. MCP 配置结果可预测同一 Server 最终只有一份完整定义不会发生字段级混合。6. 安全 Hook 使用最严格结果多个安全策略共同存在时deny不会被其他allow抵消。十三、这套冲突模型的局限1. 不同能力使用不同优先级学习成本较高例如Settings Project User Skill Personal Project读者不能只记住一条统一规则。2. 命名空间解决名称冲突但不解决语义冲突两个 Plugin Skill 虽然可以共存但模型自动匹配时仍可能选错。3. Hook 缺少显式编排顺序多个 Hook 全部执行容易产生重复副作用和行为干扰。4. Plugin 版本一致性仍不够透明项目只声明 Plugin ID 时不一定能保证所有成员使用完全相同的版本。5. Runtime 冲突结果缺少统一可视化用户很难通过一个统一界面看到某个 Skill 为什么来自 User Scope 某个 Plugin 为什么被 Local 禁用 某个 MCP 为什么选择了 Project 版本 某个 Hook 最终为什么阻止操作十四、对自研 Harness 的启发如果设计自己的 Harness Marketplace最好不要让每类能力各自隐藏冲突规则。可以建立统一的Capability Resolution Engine例如publicinterfaceCapabilityResolverT{ResolutionResultTresolve(ListCapabilityCandidateTcandidates,ResolutionContextcontext);}不同能力使用不同 ResolverSettingResolver → Scope Override SkillResolver → Priority Namespace AgentResolver → Priority Namespace HookResolver → Aggregate Most Restrictive Decision McpResolver → Scope Priority Endpoint Deduplication PluginVersionResolver → Version Constraint Lockfile1. 建立统一来源模型origin:type:pluginplugin:security-toolsmarketplace:company-marketscope:projectversion:1.2.0每个 Runtime Capability 都应该能追踪来源。2. 显式声明冲突策略capability:id:reviewtype:skillconflictPolicy:namespaceHook 则可以声明capability:id:block-dangerous-bashtype:hookconflictPolicy:aggregatedecisionPolicy:most-restrictive3. 为 Plugin 引入 Lockfile例如plugins:security-toolscompany-market:version:1.4.2sha256:abcdef...scope:project这样可以避免项目成员都启用了同一个 Plugin 但实际运行版本不同。4. 提供统一诊断命令/capabilities explain review /capabilities conflicts /plugins resolve /hooks trace PreToolUse /mcp explain database例如Capability: reviewer Candidates: 1. Managed reviewer 2. Project reviewer 3. User reviewer Selected: Managed reviewer Reason: Managed definitions override Project and User.5. 将语义冲突纳入治理不仅检测同名冲突还可以检测Description 高度相似 Tool 集合高度重叠 触发范围过宽 多个 Skill 都声称处理同一任务这样可以减少模型路由时的歧义。总结当多个来源同时向 Claude Code Harness 注入能力时Claude Code 并不是简单地后加载覆盖先加载而是根据不同能力类型采用不同冲突策略。普通设置和 Plugin 启用状态主要依赖 ScopeManaged Command Line Local Project UserPlugin 启用配置则使用plugin-namemarketplace-name作为身份并由 Managed、Local、Project、User 逐层决定最终状态。Skill 的规则则更特殊Enterprise Personal Project BundledSkill 与旧 Command 同名时Skill 优先Plugin Skill 通过plugin-name:skill-name避免与普通 Skill 和其他 Plugin 直接冲突。Agent 同样分为普通 Agent 和 Plugin AgentManaged Agent Project / User Agent Plugin Agent → 使用 Scoped Name 独立存在而 Plugin Agent 的hooks、mcpServers和permissionMode不参与优先级竞争因为这些字段在加载时会被忽略。Hook 不采用覆盖模型所有匹配 Hook 都会执行 ↓ 结果统一合并 ↓ PreToolUse 使用最严格决策其中deny defer ask allowMCP Server 则采用明确的 Scope 优先级Local Project User Plugin claude.ai Connector同一 Server 最终只连接一次并完整使用最高优先级来源的 Entry不进行字段级合并。所以Claude Code 的能力冲突模型可以概括成四类覆盖 → Settings、普通 Skill、普通 Agent、MCP 命名空间 → Plugin Skill、Plugin Agent、Plugin Command、MCP Tool 聚合 → Hook、附加上下文、权限规则 策略裁决 → Plugin 启用状态、安全决策、Marketplace Policy从架构角度看真正重要的不是简单规定谁优先于谁而是先判断这类能力应该覆盖 应该并存 应该聚合 还是应该由安全策略裁决只有把不同能力放进正确的冲突模型Harness Marketplace 才能在不断扩展的同时仍然保持可预测、可审计和可治理。下一篇可以继续进入Harness Marketplace 剖析系列 - 之 Claude Code权限、安全与供应链治理重点分析Marketplace 来源如何限制 Plugin 安装前如何建立信任 Project Plugin 为什么需要 Workspace Trust Skill 如何申请工具权限 Hook 和 MCP 为什么属于高风险组件 Plugin 更新时如何识别权限变化 企业如何建立 Marketplace Allowlist Plugin、Agent、Tool 和 Sandbox 如何形成完整安全边界这样就能继续回答当第三方 Plugin 已经被发现、安装、加载并解决能力冲突后Claude Code 如何确保这些能力不会突破用户和企业的安全边界
