Skill 冲突的本质不是缺少一个“裁判”，而是职责边界模糊、语义描述重叠。模型在选择 Skill 时，会把用户请求与各个 Skill 的名称、描述做语义匹配；如果两个 Skill 的适用场景和描述在模型看来高度相似，就会出现多个 Skill 抢同一个任务的情况。

解决 Skill 冲突，优先从设计层治根，而不是一上来就写硬编码优先级。

第一步是消除重叠。先判断冲突的两个 Skill 到底是不是在做同一件事：如果本质上是同一能力，就合并成一个 Skill；如果是两件不同的事，只是描述相似，就重新划清边界。描述里要写清适用场景、触发信号和负向约束，让模型能区分“什么时候用它”和“什么时候不用它”。如果两个能力路径很少同时使用，也应拆开放置，避免不必要的上下文竞争。

第二步是利用特异性，让模型自己选对。Skill 天然存在通用与专用的层次。比如系统里同时有“通用文档处理”和“合同解析”两个 Skill，面对合同时，应该优先触发合同解析。做法不是额外维护一张复杂优先级表，而是在专用 Skill 的描述中写足专属触发信号，例如“专门处理合同、条款解析、风险识别”；通用 Skill 则明确处理常规文档。范围越具体，描述越能表达优先级。

第三步才是显式仲裁。只有当两个 Skill 确实都相关、无法从描述上彻底拆开时，才引入上层编排或主 Agent 决策。常见兜底方式包括：专用规则压过通用规则；主 Agent 根据上下文分派；必要时双跑择优；高风险场景交给人工确认。

显式仲裁必须可观测。系统要记录每次是哪两个 Skill 发生争抢、最终选了谁、为什么这样选。真实运行日志不是为了事后甩锅，而是为了反向优化 Skill 描述和边界，最终把更多冲突消灭在设计阶段。