# 两个 Skill 触发条件差不多，如何优化

> 聊聊 Agent 开发里的 Skill 触发冲突

## 前言

前两天刷小红书，看到一道 Agent 方向的问题：

***一个 Agent 里装了两个 Skill，触发条件有交集，用户一句话过来俩都想触发，怎么优化***

这题看着简单，加个优先级不就完了？我之前也是这么想的。

后来仔细研究了下，才知道没那么简单。

**优先级治标不治本。**
> ![01-scene-intro.png](https://developer.qcloudimg.com/http-save/yehe-1367556/15a178cfb3bd84e2b656feb04396d8da.png)

## 为啥会冲突

先了解下触发机制。

***Skill 不走 if-else，模型拿着用户请求，跟每个 Skill 的 description 做语义匹配，分数够高才把整个 Skill 加载进上下文。***

所以 description 就是路由信号。

俩 Skill 的描述写得像，匹配分数就挨得近，模型要么随机挑一个，要么来回横跳。

同样的提问，这次走 A，下次走 B。

社区有篇文章举过一个例子：code-review 和 code-quality-check，两个描述都有"评审代码"。

>用户说"看看这段代码"

> 大模型：来，给我解释解释什么叫看看。

这种问题难在在于它也不报错，就是"看起来好像不太对"。

我们一开始是怀疑模型的问题，最后查半天发现是路由的问题。
![02-flowchart-why-conflict.png](https://developer.qcloudimg.com/http-save/yehe-1367556/f3e0495429afe42105a729aab4b2203f.png)

## 弯路：优先级只能治本

我最开始想的方案是给每个 Skill 配个优先级数字，冲突时根据优先级路由。

用起来发现维护难度太高了。

skill 一多，两两之间谁优先级高，已经记不清了。

而且优先级高不代表这次就该选它，比如用户今天想问 PR review，我们把"大而全"的评审 skill 放在前面，这肯定不太行。

现在我只给高风险操作留优先级，比如碰数据的压过只读的。

得到的认知：

> 优先级是仲裁工具，只能覆盖"出事了怎么办"，无法覆盖"平时该选谁"的场景。

![03-comparison-priority.png](https://developer.qcloudimg.com/http-save/yehe-1367556/123a02d3cecfb1d0d9003869d7b53470.png)

## 该合并就合并

其实冲突频繁，说明职责边界没划分干净。

两个 Skill 老冲突，最可能的结论是它们本来就该是一个（高内聚？）。

合并的标准：**两个Skill 在流程上的差异，值不值得维护两份？**

如何不值得就合成一个，内部用条件分支区分。

例如对评审 skill 合并之后，正文要写清楚"commit 前的整体评审走流程 A，PR review 走流程 B"。

直接就一个入口，也能省点 token。

我看网上的标准答案也是这个意思，原话大意是"**如果两个 Skill 经常冲突，通常说明它们应该被合并成一个"。**

所以，真要拆成两个，就在设计阶段把边界区分清楚：

**每个 Skill 只管一个不重叠的领域（低耦合？）**。

这跟微服务拆分一个道理，两个服务总是要一起改，那tm就是拆错了啊。
![04-framework-merge.png](https://developer.qcloudimg.com/http-save/yehe-1367556/5c12fdb0a05a7f2977d716a25a767399.png)

## description 里写上"不该用"

**设计上边界划清了，执行上描述就需要同步改下。**

我们都知道：**写"什么时候该用"不够，"什么时候不能用"也得写**

```markdown
# review-quality 的 description
审查代码变更，检查代码质量、规范和最佳实践。
触发场景：用户要求常规代码审查、code review。
排除场景：用户明确要求安全扫描、漏洞审计时，不触发此技能，
由 review-security 负责。

# review-security 的 description
扫描代码中的安全漏洞，基于 OWASP Top 10 做安全审计。
触发场景：用户明确要求安全检查、漏洞扫描。
排除场景：普通代码质量检查，由 review-quality 负责。
```

描述互相把对方的场景写进"排除清单"，等于约定好冲突时的优先级。

触发短语也要枚举用户的说法，"日报""工作总结""今天干了啥"都得覆盖，不然漏触发比误触发还难排除，真的。

Anthropic 的 Skill 规范要求 description 写触发条件。

我觉得还得加一句：不触发条件也得写。成本为零，性价比高。
![05-infographic-description-exclusion.png](https://developer.qcloudimg.com/http-save/yehe-1367556/11ff3a714b662ca61543d98408424ddb.png)

## 实在拆不开，只能路由层兜底

Skill 是自研框架管理的话，路由层还有几个操作：

- **互斥声明**：Skill 里写明"如果 A 已触发，本 Skill 不触发"
- **置信度打分**：最高分过阈值、需要第二名拉开差距才直接选
- **平局澄清**：把决策交还用户，问一句"你是想做整体评审，还是安全扫描"

大家总想让 Agent 全自动，但请求实在模糊的时候，不如问一句吧。
![06-framework-routing-fallback.png](https://developer.qcloudimg.com/http-save/yehe-1367556/38391e11f463a9bd874f79d4a7c48faa.png)

## 测试验证

写法改没改对，需要跑一轮测试用例验证一下。

构造一批"应该触发"的正面用例，一批"不该触发"的负面用例，改完 description 就跑一遍，看误触发和漏触发。

跟单元测试一个思路，断言对象从函数输出变成了"这个请求该用哪个"。

不合格再改描述，改完再跑。
![07-infographic-test-validation.png](https://developer.qcloudimg.com/http-save/yehe-1367556/f141c91783414e24ec6a6371675e1613.png)

## 总结

- 撞车的根源是 description 语义太近，路由随机，难排查
- 优先级是兜底不是方案，经常冲突的俩 Skill，多半该合并
- 拆不开就在 description 里互相写排除场景，最后拿正负例回归进行验证


一个 Agent 里装了两个 Skill，触发条件有交集，用户一句话过来俩都想触发，怎么优化

两个 Skill 触发条件差不多，如何优化

十倍工程师

人工智能

后端

架构设计

优化Agent Skill触发冲突需从设计源头解决：优先合并高频冲突的Skill，用条件分支区分流程；若必须拆分，则在description中明确“排除场景”和触发短语，形成互斥约定；仅对高风险操作设置优先级兜底，最后用正负例测试验证路由准确性。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

两个 Skill 触发条件差不多，如何优化-腾讯云开发者社区-腾讯云

两个 Skill 触发条件差不多，如何优化

两个 Skill 触发条件差不多，如何优化

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐