Tool_Skill_过多处理

Kinger2026/7/23大约 5 分钟

在大模型（LLM）与 Agent 系统中，当“工具（Tools）”的数量和复杂度上升到一定量级，演变成涵盖特定业务场景、包含完整复杂逻辑的“技能（Skills）”时，传统的单层路由或单次 Function Calling 会彻底崩溃。因为你无法一次性把 100 个技能的 Schema 塞进大模型的 Prompt 里（这会导致上下文撑爆、首字延迟暴涨、模型注意力涣散乱调用）。

在认知路由网关架构中，应对“多技能（Multi-Skill）”的工业级标准解法是：两层多叉树路由架构（Two-tier Hierarchical Routing Architecture）。

其核心思想是：先分类，再抠参数；先锁定技能群组（Router Layer），再定点激活具体技能并填补卡槽（Execution Layer）。

一、多技能（Multi-Skill）物理架构拓扑

当系统承载几十甚至上百个技能时，数据流采用纵向分层、横向并发的架构进行收拢：

                ┌──────────────────────────────────────────────────┐
                │          用户复合提问 (User Multi-Skill Query)  │
                └────────────────────────┬─────────────────────────┘
                                         │
                                         ▼
 ┌────────────────────────────────────────────────────────────────────────────────────────┐
 │ 层级 1：高空群组路由器 (Domain/Skill-Group Router)                                     │
 │                                                                                        │
 │ * 任务：完全不看具体参数，只用极快、极便宜的方式，把问题分流到 1~N 个特定的“技能群组”    │
 │ * 实现：向量空间语义匹配 (Semantic Router) 或轻量级二分类小模型 (SLM)                  │
 └───────────────────────┬─────────────────────────┬──────────────────────────────┘
                         │ (命中：AI Infra 群组)    │ (命中：日常办公群组)
                         ▼                         ▼
 ┌────────────────────────────────────────┐ ┌────────────────────────────────────────┐
 │ 层级 2：叶子节点技能激活器              │ │ 层级 2：叶子节点技能激活器              │
 │ (Infra Skill Domain)                   │ │ (Office Skill Domain)                  │
 │                                        │ │                                        │
 │ * 此时大模型只面对该领域特定的 5 个技能  │ │ * 此时大模型只面对该领域特定的 4 个技能  │
 │   - 技能 A: 重启 K8s Pod (Schema)      │ │   - 技能 X: 发送企业邮件 (Schema)      │
 │   - 技能 B: 拉取 Triton 监控 (Schema)   │ │   - 技能 Y: 预定会议室 (Schema)        │
 └───────────────────────┬────────────────┘ └───────────────────────┬────────────────┘
                         │ (并行抠出具体参数 JSON)                           │ (并行抠出具体参数 JSON)
                         ▼                                           ▼
 ┌────────────────────────────────────────────────────────────────────────────────────────┐
 │ 层级 3：多技能有向无环图调度总线 (DAG Async Skill Bus)                                 │
 │                                                                                        │
 │ * 任务：并发拉起底层技能代码（如 asyncio.gather）                                       │
 │ * 特性：[K8s重启技能] ⚡并发运行⚡ [邮件外发技能]                                         │
 └────────────────────────────────────────────────────────────────────────────────────────┘

二、核心架构层的关键机制

1. 高空群组路由器（Top-Level Domain Router）

物理止损线：如果你把 50 个技能的规格书全喂给 LLM，大模型每回答一句话都需要走几万 Token 的算力，高并发下直接卡死。
工业做法：顶层设计为一个极速分流器。我们把技能按照业务归类为一个个域（Domain），例如 Infra技能域、财务技能域、HR人事技能域。
路由加速：用户输入“帮我把死掉的 Pod 删了，然后发个邮件给王总”。顶层路由器（可以使用本地几毫秒就能跑完的 Embedding 向量匹配）瞬间给出判断：激活 Infra域 与 Office域**。其余无关的几十个财务、人事技能对应的 Schema 描述在这一步被物理剪枝（Pruning）**，根本不进入下一层。

2. 领域内动态 Schema 注入（Domain-Specific Context Injection）

按需加载：当请求被下发到指定的“域”之后，网关系统才会从 Redis 或本地内存中，把该域所专属的轻量级技能 Schema 集合动态捞出来。
专业化提取：此时，调用一个中等体量的大模型（如 Qwen-7B 或 GPT-4o-mini），只把当前域的 3~5 个精细的 Pydantic 结构体扔给它。因为干扰选项极少，大模型能够以接近 100% 的准确率，完美抠出具体技能需要的参数卡槽（Slot Filling）。

3. 动态命名空间隔离（Namespace Isolation）

技能防撞名：在企业级开发中，不同的研发团队开发的技能可能重名（例如系统运维部写了一个 delete_node 技能用来删服务器，全栈开发部也写了一个 delete_node 用来删前端 DOM 节点）。
物理隔离：所有的技能在注册时，必须挂载在各自的命名空间（Namespace）下：infra:delete_node 或 frontend:delete_node。顶层路由层在下发时自动带上命名空间前缀，从物理上消灭重名调用带来的系统灾难。

三、两个技能之间有“因果依赖”怎么办？（技能链条传递）

多技能架构中，最经典的一个难题是：技能 B 的执行，必须依赖技能 A 返回的数据作为参数（例如：用户说“帮我查一下今天报错最多的 Pod ID，然后把它的日志拉出来”）。

技能 A：find_top_error_pod() $\to$ 返回 pod_id_99
技能 B：fetch_pod_log(pod_id) $\to$ 需要注入 pod_id

在两层路由架构下，我们不让大模型在最开始就去盲猜这个 ID。而是利用拓扑依赖总线（Dependency Bus）分步激活：

 【 用户原始输入 】 ──> 层级 1 判定 ──> 锁死需要激活 [技能 A] 和 [技能 B]
                                             │
                                             ▼
                                     执行 【 技能 A 】 ──> 拿到底层返回值: "pod_id_99"
                                                                  │
                                                                  ▼ (自动卡槽补全算子)
                                     激活 【 技能 B 】 <── 动态注入: {"pod_id": "pod_id_99"}

静态图依赖分析：层级 2 的大模型在拆解意图时，发现这两个技能都被激活了，但大模型发现自己只有技能 A 的必填参数，缺乏技能 B 的必填参数（此时大模型并不知道 Pod ID 是什么）。
依赖打桩（Stubbing）：大模型会在输出的编排图（DAG）中写入一条逻辑：“执行技能 B，但其参数 pod_id 依赖于技能 A 的输出结果”。
运行时注入（Runtime Slot Injection）：代码协程并发流启动，先跑技能 A。当技能 A 运行完毕吐出 pod_id_99 后，控制面的状态机当场捕获这个返回值，将其作为入参物理塞进技能 B 的 Pydantic 实体中，随后顺畅激活技能 B。

💡 极简架构总结：

面对海量 Skill，核心思维就是“分而治之，层级剪枝”。顶层靠轻量向量/分类模型大刀阔斧斩断无关领域，中层靠细粒度 Schema 强约束精准提取槽位，底层靠依赖总线（DAG）打通 Skill 之间的数据血统。这种架构既能支撑上百个业务技能，又能将端到端延迟控制在极佳的工业水平线内。