Agent 系列日记 5：为什么 Skill 路由比 ReAct 控制器更适合个人助理

Mon, 29 Jun 2026 00:00:00 +0000

从 luck-agent 到 Hermes-lite，我花了两年时间才想清楚这个问题：80% 的请求不需要"思考"，只需要"路由"。

回顾：ReAct 控制器模式的困境

2024 年做 luck-agent 的时候，我采用的是经典的 ReAct 模式（Reasoning + Acting）：

用户输入 → 大模型推理（意图识别 → 规划 → 工具选择 → 执行）→ 输出

所有请求，不管简单还是复杂，都走同一个推理链。一个"查 QPC 里有没有 VPS 相关的记录"的请求，也要经过：

理解自然语言
判断意图类别
选择工具（search_qpc）
构造查询参数
执行并解释结果

问题很明显：

Token 消耗大：每次推理要带上完整的 system prompt + 工具定义，光上下文就吃掉 3000-5000 token
延迟高：一个简单查询要等模型完成完整推理链，响应时间 3-8 秒
上下文窗口压力：随着工具数量增加（现在 Hermes-lite 有 20+ 个工具），system prompt 越来越大

我当时就在知识库里记了一条：

“对于个人助理场景，相比最初的 ReAct 控制器模式，Skill 技能路由更适合当前 luckagent：80% 请求是固定模式，不需要复杂推理，技能比 Agent 更稳定，成本更低，响应更快。”

Skill 路由的核心思想

一句话：预定义技能映射，轻量分类先路由，只加载需要的工具和 prompt。

用户输入 → 轻量路由（关键词/意图 → 技能）→ 加载专用 prompt + 工具 → 执行

路由表设计

# 简化版路由逻辑
ROUTING_RULES = {
 "qpc": {
 "keywords": ["QPC", "知识库", "记一下", "记录"],
 "skill": "qpc",
 "tools": ["feishu_bitable_read", "feishu_bitable_write"],
 "prompt": "qpc_skill_prompt" # 只加载 QPC 相关的 prompt
 },
 "vps": {
 "keywords": ["VPS", "服务器", "防火墙", "Docker"],
 "skill": "gcp-vps-ops",
 "tools": ["terminal", "read_file"],
 "prompt": "vps_skill_prompt"
 },
 "blog": {
 "keywords": ["博客", "文章", "Hugo", "发布"],
 "skill": "hugo-blog",
 "tools": ["terminal", "read_file", "write_file"],
 "prompt": "blog_skill_prompt"
 }
}

对比：同样"查 QPC"操作

指标	ReAct 模式	Skill 路由
上下文 token	~4000（全量工具定义）	~800（仅 QPC 相关）
首次响应延迟	3-8s	0.5-1.5s
工具调用次数	2-3 次（推理+执行）	1 次（直接执行）
准确率	92%（模型可能选错工具）	98%（路由确定性高）

Hermes-lite 的 Skill 实现