8 月 18 日早上，我重新打开 GitHub 看了一眼 yjh051108/dsh-routing-suite。
5355 星。
这个仓库北京时间 8 月 15 日清晨才创建，差不多 3 天时间就冲过了 5000 星。更夸张的是，我昨天看到 Trendshift 收录它时，页面截图还只有 2.5k。
短短一天，数字又翻了一大截。
但我把 README、源码、实验记录，甚至作者后来专门写的勘误声明都翻了一遍以后，发现这个项目最有意思的地方其实很好理解：
它想给 DeepSeek Harness 装一个“思考变速箱”。
写一个新东西时，少开会，赶紧做。
碰到维护、修 Bug、重构这类任务时，先把情况摸清，再下手。
任务说得模棱两可，就再判断一次应该挂哪个挡。
模型还是那个 DeepSeek V4，改变的是模型进入任务时的工作方式。
5000 多星的仓库，其实是两个项目绑成了一套
第一次看到 yjh051108/dsh-routing-suite 这个名字，很容易以为它本身是一个巨大的 DeepSeek 插件。
实际仓库非常小。
它主要负责把两个项目组合起来：
dsh-routing-suite├─ dsh-super-injector└─ dsh-Router-standard第一个 yjh051108/dsh-super-injector，可以理解成 DeepSeek Harness 的“运行时手术台”。
它提供一整套 dev_* 工具，可以在 Harness 运行过程中注入插件、热重载、卸载、侧挂测试、转正，甚至清理插件留下的残余路由。
开发一个 DSH Plugin，以前可能是：
改代码→ Build→ 装插件→ 重启 Harness→ 发现问题→ 再改→ 再重启Super Injector 想把它变成：
改代码→ Build→ 自动热重载→ 继续测试甚至 Agent 自己都可以调用：
dev_inject_plugindev_reload_packagedev_uninject_plugin去管理自己的运行环境。
这个东西很硬核，但它并不是这次“DeepSeek 效果变化”的核心。
真正让这个项目火起来的，是第二个：
yjh051108/dsh-router-standard它做的事情可以概括成一句话：
先看任务，再决定 DeepSeek 应该怎么思考。
写代码和修代码，为什么要给 DeepSeek 挂不同的挡？
作者研究 DeepSeek V4 时发现一个挺有意思的现象。
同一个模型，只要换一下 Persona、System Prompt，以及第一轮能看到的工具，它整个工作节奏就可能发生很大变化。
有一种状态特别喜欢：
先分析→ 再分析→ 再看看→ 做计划→ 重新检查→ 最后才动手另外一种状态则更像：
先看一下→ 直接做→ 跑一下→ 有问题就改→ 交付这两种风格没有绝对的好坏。
比如让 Agent 接手一个存在了两年的项目：
修复登录模块升级以后出现的权限 Bug它一上来就改代码，风险很高。
这种任务更适合先读：
README配置调用链相关文件历史实现然后再动。
可如果任务换成：
帮我做一个简单的网页版倒计时工具模型如果花半天研究“项目哲学”“潜在架构”“未来扩展”，体验又会非常奇怪。
这种任务通常应该赶紧把第一版写出来，然后运行、验证、修改。
dsh-router-standard 就在中间加了一层自动判断。
现在源码里直接写着两大组关键词。
如果任务里出现：
开发创建写一个生成从零做一个网页网站构建实现新项目更倾向走 react。
如果出现：
修复调试重构维护排查报错优化审查迁移兼容更倾向走 spec。
两边打平，或者根本判断不出来，就进入 weak。
于是整个过程很像自动挡汽车：
用户任务任务分类┌──────────┬──────────┬──────────┐│ spec │ react │ weak ││ 先研究 │ 直接做 │ 再判断 │└──────────┴──────────┴──────────┘这就是我觉得“思考变速箱”最贴切的原因。
它调的不只是 Prompt，连第一轮工具都一起换了
继续往源码里看，这个项目比“自动换提示词”多做了一步。
它连模型第一轮看到的工具都要控制。
spec 偏向维护和排查，所以第一轮核心工具是：
readeditglobgrepshell明显是“先读、先找、先搞清楚”。
react 偏向创建和实现，第一轮则变成：
readwriteeditshell重点已经开始往“写东西”偏。
更聪明的一点是，这种限制不会持续整个任务。
只要 DeepSeek 真正完成第一次 Tool Call，Router 就重新放开完整的 Standard 工具集。
可以把它理解成：
第一步只给最适合当前任务的一小套工具模型进入正确工作状态第一次真正行动完整工具箱全部打开它控制的是开局。
这一点其实很重要。
Agent 长任务很像下棋，第一步走歪以后，后面很容易沿着原来的上下文继续往下滑。
作者把这种现象叫 Path Commitment，也就是路径一旦形成，后续很难彻底切换。
所以 Router 最关心的是：
第一轮究竟让 DeepSeek 以什么身份出现、看到什么工具、用什么节奏启动。
这也解释了为什么项目甚至提供：
dev_router_status查看当前模式；
dev_router_mode手动换挡；
以及：
dev_mode_subagent单独拉一个不同思考模式的 Subagent 干活。
比如主 Agent 正在慢慢排查一个复杂项目，但其中突然需要：
给我写一个数据转换脚本可以单独开一个 react Subagent，让它快速完成，不需要把当前主会话已经形成的思考轨迹全部推翻。
这个设计比单纯改几个 Prompt 有意思多了。
简单任务快收敛，复杂任务还会自动多想一层
现在 Router 又加入了一层复杂度判断。
源码里的规则很直接。
任务长度超过大约 120 个字符，或者出现：
架构重构全面详细设计系统优化分析这类关键词，就会更倾向把任务当成复杂任务。
简单任务得到的引导更偏：
判断任务类型→ 选择工作方式→ 尽快行动复杂任务则会额外要求：
认真考虑架构考虑边界情况考虑集成点不要把时间浪费在无关环境检查上信息够了就开始产出每轮思考都要形成一个决定或明确还缺什么这个小设计我觉得挺实用。
因为 Agent 最烦人的两种情况刚好相反。
一种是想得太少：
看到问题→ 猜一个原因→ 立刻改→ 把项目改坏另一种是想得太多：
检查 Node 版本检查系统版本重新看目录重新 grep重新确认刚才已经确认过的东西……后者我相信经常用 Coding Agent 的朋友都见过。
Router 试图做的是根据任务复杂程度改变“刹车距离”。
简单活早点停。
复杂活允许多跑一会，但每一段推理都要产生新的信息。
那些“性能提升”到底靠不靠谱？
这个项目最容易被传播歪的地方也在这里。
社区现在已经开始出现：
“DeepSeek Flash 装完性能暴涨。”
甚至还有“Flash 可以达到 GLM 5.3”这样的说法。
我不建议现在这么理解。
dsh-router-standard 确实做了非常多实验，仓库里从 P1 一路测到了 P20 多，后来还继续增加。
比如作者在 V4 Pro 上，把 Persona 从偏 spec 到偏 react 分成 21 个位置，每个位置重复测试。
结果挺有意思。
模型行为没有随着参数慢慢变化，而是出现了几个明显区域：
0 ～ 0.15稳定偏 spec0.20 ～ 0.45容易混合、摇摆0.50 ～ 1.0稳定偏 react中间那一段作者现在甚至把它当成“陷阱区”，自动路由时尽量避开。
在真实任务里，也确实测出过明显差距。
例如维护类项目里，偏先分析的模式可以跑到 98、99 一类高分。
换成从零制作 Mario 网页游戏，直接执行型的 Code 模式拿到了 10/10，另一种更偏分析的配置只有 6/10。
这组结果非常有启发：
没有一种 Agent 工作方式可以包打天下。不过作者自己的数据同样显示，在一些没那么难的任务里，几种模式最后都能拿到 10/10。
区别可能只剩：
谁用了 2 轮。
谁用了 3 轮。
谁用了 4 轮。
所以现阶段比较合理的理解应该是：
Router 能显著改变 DeepSeek V4 在 Agent 环境里的行为轨迹，有些复杂任务中，这种改变会进一步影响完成质量、速度和稳定性。
至于：
模型整体能力提高多少？能不能超过某个其他模型？Benchmark 总分提升多少？目前这个仓库还没有给出足够证据支持这么大的结论。
最有意思的一幕，是作者自己推翻了自己
这个项目爆火过程中还发生了一件挺少见的事。
作者最开始给这些实验现象做了一套非常大胆的理论解释。
大致认为 DeepSeek 内部可能存在两种被后训练出来的稳定思考模式，并提出所谓“双吸引子”假说，还进一步推导了很多结论。
结果继续实验以后，作者发现自己把“现象”解释成“底层机制”了。
8 月 16 日，他专门写了一份很长的勘误声明。
README 最上方甚至直接放了一句话：
我错了，而且错得很有代表性。原先关于“双吸引子”“官方刻意设计双模式”“模型不可能自己路由”等强解释，被作者明确作废或者降级成待验证假说。
不过实验数据、探针方法和 Router 工程实现继续保留。
作者现在给出的说法谨慎了很多。
DeepSeek V4 的不同思考轨迹之间可能存在一个行为“断层”，这个断层究竟为什么产生，目前还缺乏证据。
他们真正完成的工程工作，是：
发现这个断层→ 测量它→ 找到比较稳定的区域→ 根据任务把模型推向不同区域我反而觉得这一段特别值得讲。
开源项目最怕的是几组漂亮数字出来以后，理论越讲越玄。
这个作者至少在发现证据对不上以后，公开把自己前面的解释划掉了。
所以研究这个项目时，我建议把两件事情分开：
实验现象，有一定数据。
底层原因，目前还没有定论。
想马上装的朋友，我反而建议先别急着跑“一键安装”
这里有个挺大的反差。
项目已经 5355 星。
安装体验还非常符合“刚出生 3 天”的气质。
README 里提供的是：
git clone --recurse-submodules https://github.com/yjh051108/dsh-routing-suite.gitcd dsh-routing-suite.\install.ps1看上去非常舒服。
但目前 GitHub Issue 里已经有人集中反馈 Windows 安装问题，包括 PowerShell 文件编码、预设复制目录、子模块缺少编译后的 lib、Shell 脚本 CRLF 等。
其中有一个路径问题尤其值得注意。
Router 实际目录是：
preset├─ router-standard└─ router-spec而当前一键脚本的复制方式，可能把目录再多套一层。
结果就是文件明明复制过去了，DeepSeek Harness 却找不到：
preset.yml另外 Super Injector 的源码仓库默认也没有直接带构建好的 lib/index.js。
一键脚本发现这个文件不存在时，会提醒你先 Build，但并不会自动完成整个构建。
所以如果你只是想尝鲜“思考变速箱”，我目前更倾向于先单独研究 Router Standard，没必要为了体验路由功能，把 Super Injector 整套开发环境一起折腾进去。
Router 安装成功以后，新建会话时会出现：
Router Standard (experimental)看到这个选项，再开始测试。
最适合做的第一组对照也非常简单。
给它两个完全不同的任务：
帮我从零做一个简单网页记事本然后再开新会话：
帮我排查这个旧项目启动后登录失效的问题再分别调用：
dev_router_status看看两边到底被分到了什么模式。
这比直接拿一个 Benchmark 分数判断它“有没有提升”，更容易理解 Router 到底改变了什么。
5000 星真正值得看的，是 Agent 开始学会“什么时候该聪明”
前几天研究 DeepSeek Harness 时，我一直觉得它真正有价值的地方，会慢慢从 DeepSeek 模型本身转到外围生态。
ModLens 给纯文本模型接上视觉。
这个项目又给模型加了一层思考模式路由。
再往后完全可能出现更多类似的能力：
模型视觉路由工具路由思考深度路由Subagent 路由模型路由最终 Agent 做一个任务之前，先决定：
该用哪个模型？
要不要深度思考？
先读还是先写？
要不要开 Subagent？
要开放哪些工具？
什么时候停止继续想？
这时候 Harness 做的已经不只是“给模型装工具”。
它开始负责组织模型怎么工作。
所以 dsh-routing-suite 这 5355 星，我觉得真正值得关注的并不是某个夸张的“性能翻倍”。
它让一个挺抽象的问题突然变得很具体：
强模型当然重要。
但真正干活的时候，知道什么时候该多想，什么时候该少想，可能同样重要。
DeepSeek Harness 现在有人给它装上了一个自动变速箱。
至于这台车最终能不能跑得更快、更稳，还得继续看后面的实测。
热门跟贴