如何设计高可用的skill-prompt系统：从架构设计到生产实践

2次阅读

共计 1608 个字符，预计需要花费 5 分钟才能阅读完成。

每次看到对话系统在高峰期响应速度从 200ms 飙升到 2 秒，就知道又有技能服务在『排队等 CPU』了。去年我们电商客服系统就经历过这种噩梦——促销期间大量用户咨询订单状态，串行处理的架构让所有请求在规则引擎前排起长队。更糟的是静态 prompt 管理导致每次调整话术都要全量发布，运维同事凌晨三点被叫醒部署成了家常便饭。

请求处理链路过长时，QPS 会受限于最慢的那个技能
线程阻塞导致资源利用率不足（实测 CPU 使用率常低于 40%）
雪崩风险高：一个技能超时会拖垮整个链路

通过将技能服务拆分为独立 worker 池，我们测得：

订单查询技能：吞吐量提升 3 倍（1200QPS → 3600QPS）
99 线延迟：从 1.2s 降至 380ms
CPU 利用率稳定在 70-80%

# 异步任务分发核心代码
async def dispatch_skill(skill_name: str, params: dict):
    # 从注册中心获取技能节点
    worker = await service_discovery.get_worker(skill_name) 
    try:
        # 设置熔断超时（不同技能可配置不同阈值）async with async_timeout.timeout(SKILL_TIMEOUT[skill_name]):
            return await worker.execute(params)
    except TimeoutError:
        metrics.incr(f'skill_timeout_{skill_name}')
        raise SkillTimeout()

采用 BERT+ 规则混合方案解决纯 NLP 的冷启动问题：

高频意图（如『退货』）用规则引擎保证 100% 召回率
长尾意图通过小样本训练的文本分类模型处理

// 基于 LRU 的 prompt 缓存实现（Go 版本）type PromptCache struct {
    sync.RWMutex
    capacity int
    cache    map[string]*list.Element
    lruList  *list.List
}

func (c *PromptCache) Get(key string) (string, bool) {c.RLock()
    defer c.RUnlock()

    if elem, ok := c.cache[key]; ok {c.lruList.MoveToFront(elem)
        return elem.Value.(*cacheItem).value, true
    }
    return "", false
}

动态加载技能描述文件实现热更新：