开源role-model 是一个面向 AI 模型路由的开放协议及参考路由实现，旨在为每个任务分配合适的模型。其核心思想是让路由决策变得可解释、可移植，解决开发者面临的"该用哪个模型处理这个请求"的经典问题。
支持的混合路由场景
参考路由器支持三种部署形态的混合路由：
- Local / Local：在本地模型之间路由（如 llama-swap 节点），基于角色、任务和能力
- Local / Cloud：在本地模型和云端模型之间路由，基于成本、延迟和任务难度
- Cloud / Cloud：在多个云服务商之间路由（如 OpenAI、DeepSeek、Moonshot），基于能力和成本考量
缓存命中率干到99%以上，这事直接改写了AI推理的成本公式！
DeepSeek Harness插件即将上线，role-model这套专门干智能路由的协议终于要跟DSH插件生态正面撞上了——但这两套东西到底怎么拧到一块去？
DSH开源那天，GitHub上炸了锅。DeepSeek Harness在2026年8月13日正式开源，MIT协议。官方给了一个公式：Agent（千里马）=Model（好马）+Harness（好鞍）。
Harness干的事是模型本身不干的那部分——替模型记住上下文、替它调用工具、替它在文件和终端之间跑腿。
整个架构就一句话：“一切皆插件”。模型适配器是插件，工具注册是插件，Agent主循环是插件，沙箱是插件，审批策略是插件，甚至UI都是插件。
这套role-model做的事情特别简单：每次AI请求进来，它替你做决定——用哪个模型处理这个请求。本地跑得动的就本地跑，本地跑不动的扔云端，云端太贵的切到便宜的备胎。就这一个事，被拆成了四个模块：请求描述、端点描述、路由策略、可观测性记录。每个模块都给你讲得明明白白，路由决策为什么这么做，每一步都有据可查。
DSH那边呢？它把模型提供者、记忆后端、工具集成、路由策略全做成了可替换的插件。换一个向量数据库，跟换一个模型提供商走的是同一套注册流程。这套设计本身没毛病，问题在于——DSH自带的模型选择器就那么几个选项。你要做细粒度的任务感知路由，得自己动手搭。
这就怪了。一个号称“一切皆插件”的框架，跟一个专门做路由决策的协议，竟然没有现成的拧螺丝说明书。
装好role-model不用三分钟，但端口得钉死！
先拆第一个问题：role-model怎么装。
官方给了三种方式。macOS和Linux直接跑一行命令：
bash
curl -fsSL https://raw.githubusercontent.com/try-works/role-model/main/scripts/install.sh | sh
装完以后启动器在~/.local/bin/role-model。Windows用户跑PowerShell：
powershell
irm https://raw.githubusercontent.com/try-works/role-model/main/scripts/install.ps1 | iex
装完在%LOCALAPPDATA%\Programs\role-model\下面。不想用脚本的，自己去GitHub Releases拖对应平台的压缩包。
装完以后，role-model默认跑在http://127.0.0.1:3456。这个端口记住了，后面DSH那边要往这里指。
但光装一个role-model没用。你得让DSH知道，模型路由这事交给role-model来管。
DSH的安装门槛在主流Agent框架里算低的。最快的方式是npx一键启动：npx @deepseek-ai/dsh web。前提是机器上有Node.js v22.19以上。跑起来之后浏览器打开http://127.0.0.1:3080，就是它的Web UI。
两个服务都跑起来了，一个在3456，一个在3080。但怎么让它们说话？
现成插件兜个底，复杂度路由能先跑通！
社区里已经有人把路由这事干了。
llm-adaptive这个插件，给DSH的模型选择器加了一个adaptive选项。选了这个之后，每次LLM请求先过一个flash分类器——low、medium、high、critical四个档位。判断完了按配置好的链路由到对应的后端模型。分类结果还有120秒的决策缓存，同一个问题短时间内不再重复判断。
装法也简单：
bash
dsh plugin add llm-adaptive
装完重启DSH的web服务，在/model选择器里选adaptive（自动路由）就行。
但注意，llm-adaptive的路由配置来自一个pool.json文件，路径在~/.dsh/tools/cc-switch-sync/pool.json。这个文件里要配classifier和routing.levels两块。也就是说，你得自己维护一套模型池的配置——哪些模型属于low档、哪些属于medium档、哪些属于high档、哪些属于critical档。
这跟role-model的理念有重合，但不等同。role-model做的是“任务感知”路由——根据请求的任务类型、所需能力、模态、工具需求来做决策。llm-adaptive做的是“复杂度感知”路由——按复杂度档位来分。
手动指向能通，但路由决策又踢回给人了！
在官方DSH插件出来之前，还有一个过渡方案：把role-model当成一个独立的路由服务跑着，DSH这边通过自定义模型端点指向role-model的接口。
DSH的设置界面里有一个“模型高级配置”页面。在这里新增一个端点，URL填role-model跑的那个地址http://127.0.0.1:3456，模型名称填你在role-model里配置好的端点标识。保存之后，DSH的模型选择器里就会出现这个自定义端点。
但这个方案有个坑：DSH的“模型高级配置”目前只能配单个端点，做不到role-model那种“一个请求过来自动判断用哪个端点”的效果。你得在DSH这边手动切换模型——等于把路由决策的活又推回给人了。
所以这个方案只能算“让两者能通信”，算不上“协同工作”。
99%缓存命中率，把决策本身做成稳定信号！
那缓存命中率99%是怎么回事？
DeepSeek的API有个缓存系统。实测显示，Harness的缓存命中率大多在99%左右，有几次直接干到了100%。缓存命中的Token享受50倍的折扣，成本直接打骨折。
但缓存有个致命弱点：系统提示词里一旦混入动态内容，整个前缀缓存就废了。DeepSeek的缓存机制本质上是一个无情的字符串比较器——前缀必须完全匹配才能命中。
role-model的路由决策是可解释、可移植的。每次路由决策都记录在案——为什么选这个模型、基于什么任务类型、成本多少、延迟多少。这套记录本身就成了稳定的上下文。同样的任务类型反复出现，路由决策重复，前缀缓存就能稳定命中。
dsh-model-router这个插件做了一个更极致的操作。简单问题直接在廉价模型上跑一次零前缀的流式回答，主会话的模型和前缀缓存碰都不碰。具体做法是：用zero-prefix flash judge先做一个快速判断——SIMPLE还是AGENTIC，只消耗64个token，连thinking都关掉。判断结果是SIMPLE的，直接在廉价模型上跑一个one-shot流式回答，主模型根本不参与。主会话的缓存永远不会被简单问题污染。这样一来，复杂任务的缓存命中率自然就上去了。
99%的缓存命中率就是这么来的——不是靠运气，是靠把“该走哪条路”这个决策本身变成了可缓存、可重复的稳定信号。
但这里面有个悖论。缓存命中率越高，说明路由决策越稳定、越重复。但AI任务本身是多样化的，今天写代码、明天改文档、后天调参数。如果路由决策太稳定，是不是意味着路由策略太死板、没有针对不同任务做细粒度区分？
反过来想，如果路由策略做得足够细——按任务类型、按所需能力、按模态、按工具需求来区分——那同一类任务的请求自然会走到同一个模型端点，缓存命中率自然就高了。高缓存命中率恰恰说明路由粒度做得对，而不是做得糙。
路由粒度越细缓存越高，配置文档还差口气！
DSH插件即将带来的“更丰富的路由元数据和任务分类体系”，本质上就是在把路由粒度继续做细。任务分类越细，同类请求的聚集效应越强，缓存命中率越高。这是一个正循环。
但正循环的前提是——你得先把这个路由层搭起来。
现在DSH插件还没正式发布，社区里已经有人在用llm-adaptive和dsh-model-router做过渡方案了。等官方插件一出，这些过渡方案可能会被统一到role-model的协议规范里。
到时候配置方式会变成这样：装role-model运行时、装DSH插件、在DSH设置里选role-model路由、在role-model那边配路由策略——完事。