日常工作知识库

Appearance

大模型 Agent 技能（Skills）臃肿与相似冲突的路由分流最佳实践 ​

归类：AI 研发效能 / AI Agent 架构 发生时间：2026-07-09 状态：✅ 已解决 | 📝 持续维护

一、问题背景 ​

在企业级 AI Agent（如 Claude Code、Hermes、OpenClaw 等）的工程化开发与私有部署中，随着业务场景的增加，系统的**技能数（Skills / Tools）**会迅速膨胀。

此时会面临两大核心痛点：

  1. 技能臃肿（Bloat）：当有数十甚至上百个 Skills 堆积在同一个 Agent 的上下文时，大模型的推理性能、调用准确率均会明显下降。
  2. 技能冲突（Conflict）：当存在两个语义或名字接近的技能时（例如 git-mr-review 与 local-diff-review），AI 或用户该如何精准区分，避免调错？

本文将从大模型的本质机理出发，结合业内的工程实践，总结出应对这两类问题的设计规范与路由分流最佳实践。

二、技能过多对大模型判断与执行的影响 ​

在 LLM 底层，Skills / Tools 通常是以 JSON Schema 或 Function Descriptions 的形式被拼接到 System Prompt 中。Skills 膨胀会带来以下负面影响：

影响维度具体表现根源机理
推理速度与成本首字延迟（TTFT）增加，Token 消耗呈线性甚至指数级上升。每次调用均需将所有工具定义输入上下文，增加了计算开销。
注意力分散（Lost in the Middle）模型容易忽略位于 Prompt 中部的工具，导致“放着好工具不用却自己瞎编”。长上下文窗口中，模型对于输入中间段信息的提取召回率显著下降。
幻觉调用与混淆模型选择工具的准确率大幅降低，容易将 A 技能的参数传递给 B 技能。工具之间的语义重叠度高，在高维语义空间中模型的分类决策边界变得模糊。

三、语义接近的技能冲突：如何有效区分？ ​

当面临两个功能或描述极为相似的技能时（例如：都是代码审查，一个是团队级的 GitLab MR 审查，另一个是本地提交的 Git diff 检查），可以通过以下方式在 AI 侧和用户侧建立清晰的隔离带：

1. AI 侧区分（面向 Agent 引擎的提示词与元数据） ​

  • 高对比度的语义边界（Pre-conditions）：在技能描述的 Description 中显式注明反向排除场景。例如：
    • GitLab MR 审查：“仅用于已提交到 GitLab 的 Merge Request 远程链接审查，绝对不要用于本地未提交的修改。”
    • 本地 Diff 审查：“仅针对本机工作区尚未 Push 的局部代码改动进行审查，绝对不要用于 MR 链接。”
  • 结构化参数约束（Schema Constraints）：利用类型和枚举强制区分。如果 A 技能接收 URL 格式，B 技能接收本地 Path 格式，模型在进行参数填充校验（JSON Schema Validate）时能通过参数特征直接过滤掉不匹配的技能。
  • 分层命名空间（Hierarchical Naming）：避免扁平命名，使用 namespace:domain:action 格式（如 git:mr:review 与 local:file:review），使模型建立层次化的调用逻辑。

2. 用户侧区分（面向人机交互的引导设计） ​

  • 明确的唤醒关键字 / 指令语法：例如通过前缀或者 Slash Command（/mr-review vs /local-review）强约束，减少用户自由输入带来的歧义。
  • 主动询问与澄清机制（Clarification Loop）：当 AI 计算出两个工具的调用置信度非常接近时（例如相似度得分均在 0.7-0.8 之间），禁止直接执行，而是主动抛出交互卡片供用户二次确认：“检测到您的需求与 MR审查 和 本地Diff 均相符，请问您指的是哪一个？”

四、业内外解决 Skills 膨胀与路由的最佳实践 ​

为了防止 Agent 系统因为 Skills 堆积而退化，业内（如 AutoGen、LangChain 生产实践）主要采用以下分流架构：

1. 动态路由与工具剪枝（Tool Pruning / Vector Routing）—— 避免一次性全量加载 ​

  • 原理：将所有 Skills 的 Description 向量化（Embedding）存入向量数据库。
  • 流程：
    1. 用户输入 Prompt ➡️
    2. Router LLM 或向量数据库对用户意图进行检索 ➡️
    3. 仅挑选语义最相关的 Top-5 技能动态注入本次 Dialog ➡️
    4. 模型在极小的候选池中进行 Tool Call。
  • 收益：将上下文中的 Tool 数量恒定保持在个位数，首字延迟大降，模型选择准确率接近 100%。

2. 主从 Agent 架构（Orchestrator-Worker Pattern）—— 语义域隔离 ​

  • 原理：不采用“一个 Agent 挂载所有工具”的扁平设计，而是将大任务拆分。
  • 结构：
  • 收益：主控 Agent 只需要理解子域，没有任何具体的重度 Tool 负担；每个 Worker Agent 只有与其业务强相关的 2-3 个工具，完全消开了跨业务域的技能冲突。

3. 基于环境状态的“硬过滤”（State-based Pre-filtering） ​

  • 原理：在将 Skills 暴露给模型之前，先执行本地脚本来判断当前环境是否具备调用条件。
  • 实例：如果当前工作区内没有 .git 文件夹，Agent 框架在系统层直接将所有 Git 相关的 Skills 移除出可用列表，不让其进入 LLM 的上下文。

五、使用建议与小结 ​

对于需要维护自定义 Skills 库的团队，建议遵循以下设计标准：

  1. 技能单一职责：一个 Skill 只干一件事，宁可参数简单，也不要写一个支持“十八般武艺”的全能巨型 Skill。
  2. 描述重于代码：大模型选错工具，90% 都是因为技能的 Description 写得不够清晰。编写 Description 时，必须遵循 适用场景 + 限制条件 + 输入样例 的标准模板。
  3. 引入 Worker 分流：当全局 Skills 数量超过 10 个时，应主动升级到主从多 Agent 架构或引入动态 Tool 剪枝路由，从架构层面根治“Skills 臃肿”带来的心智衰退。