夜雨聆风
本地模型接管OpenClaw工单分流
这篇内容来自Hugging Face Blog，讨论用本地模型在OpenClaw代码仓做工单分流，把分类、路由和优先级判断交给Gemma与Qwen组成的agent系统，在DGX Spark这类本地算力设备上实时运行。
这类把Gemma、Qwen塞进本地agent做工单分流的思路，本质是在用算力换控制权。对做AI应用的人来说，真正的变化不是模型更强，而是可以不依赖闭源API也跑起实时系统。
- OpenClaw：每天处理大量 issue 与 PR，需要 triage、优先级排序与维护者路由
- 方案：在 agent harness（Pi）中用 Gemma、Qwen 做分类任务，配合 structured outputs 输出标签
- 区别于 BERT：不是单模型分类器，而是 agent + 本地模型组合流程
- 硬件：NVIDIA GB10，128GB unified memory，可跑 gemma-4-26b-a4b
- 性能：可达 hundreds of tokens per second，支持高并发推理
- 目标：构建实时通知系统，只筛选自己负责的 P0 issue
- 背景：闭源模型（GPT-5、Opus、Sonnet、Claude Fable 5）存在可用性波动风险
本地agent正在替代“纯API分类”链路
在这个架构里，模型不再只是推理接口，而是被嵌入到持续运行的工作流中，通过结构化输出直接参与系统决策。OpenClaw这种高频协作仓库，本质是在验证一个问题：当issue规模上来之后，人工triage已经成为瓶颈。
从工程角度看，这类方案的关键不在“用了哪个模型”，而在于agent编排与结构化输出的稳定性。一旦分类标签设计不合理，Gemma或Qwen再强也会在路由环节放大错误。另一个现实问题是本地算力门槛，NVIDIA GB10级别硬件才能撑起高并发，否则延迟会直接影响通知系统的实时性。对做AI应用落地的人来说，这更像是在搭一个“私有调度层”，而不是单纯替换模型API。
留言聊聊
你们现在做issue triage，是API为主还是本地模型为主？
往期推荐
- ·Kimi K2.6 对决 GPT-5.4，编码能力不输美系巨头
- ·3090跑Qwen3.6-27B，80.2tok/s实测翻倍
- ·DeepSeek-R1 完全开源复现：350k 数据集与 7B 模型解析
点击公众号头像 → 历史消息，可翻阅以上文章