今天遇到一个问题，让我啼笑皆非。
DeepSeek 的 Harness 把 OpenCode 给卡死了！
这个 Bug 极其隐蔽，一般人都想不到它们之间还有关联。最后另一个 Agent 帮我揪出了问题的本质，我瞬间感叹，这个世界就是一个草台班子。
一堆 Agent 也都是草台班子，但是随着问题的深入，我发现这个问题的复杂性，好像一切也情有可原了！
我来捋一捋这个问题，非常有意思。
这个问题的起因是：
我想白嫖 Ox 模型，目前有两种方法，一种是 OpenRouter，一种是 OpenCode。OpenRouter 已经跑通了，但是很快就面临人太多、容易断的问题。
我就想着在 OpenCode 上玩一下，毕竟我开了 $5 的订阅，应该会好一些！
一玩就玩出问题了！
打开 OpenCode 的 CLI 版本之后，模型可以找到，可以选择，但是发什么都是加载中......试了很多次都不行。这又是一个极其讨厌的东西，没有任何提示，就这么一直卡着。
OpenCode 也算是赫赫有名了，20 万 Star 的开源项目，没想到出现这种问题。
我又要开始炮轰它了！网上总是这个牛逼那个牛逼，一到我手里，立马就发现各种问题。
但是这个问题确实不好解决。
我初步排查了一下，它的 GUI 版本是可以，CLI 版本就不行。但是目前 GUI 版本始终找不到 Ox 模型，所以我必须用 CLI。吐槽二连：为什么同一家公司的产品，一个已经更新，另一个就死活找不到呢。
我也怀疑过网络问题，因为我的网络确实很复杂，有很多虚拟网卡，但问题是，同一时间，其他工具联网正常，它自己的 GUI 版也联网正常，只有 CLI 不正常。你说气不气人，就是偏偏你要用的用不了。GUI 可以，CLI 不行，也可能和虚拟网络有关......Windows 系统下有些可以被代理，有些不能被代理。
这个问题，我没时间，也没能力推进了。
我只能搬出了"牛来"模型的兄弟"牛来 Plus"了。
经过一顿分析，这个牛来 Plus 果然厉害。花了 1 个小时，排查了 10 个方向，最终定位到了问题的关键。
问题的关键就是 DSH，DeepSeek 家的 Harness！
牛来 Plus 是这么描述的：
ruby
问题与软件版本、网络、API 服务端、密钥全部无关。
根因：
你从 `C:\Users\tony`(主目录)启动 opencode 时，它会把主目录当作项目，并对整个目录执行 git 快照(实际命令是 `git ls-files --others --exclude-standard`,我抓到卡住时这个 git 子进程烧了 50 多秒 CPU 还没走完)。而你的主目录里有一个毒瘤目录：
C:\Users\tony.dsh\profiles\node_modules@deepseek-ai\
├─ cordis → (junction) npm-cache 里的 cordis
├─ cordis-plugin-include → (junction) npm-cache 里的 cordis-plugin-include
└─ ...多个目录联接互相嵌套成环它明确指出，卡死 OpenCode 的就是 DSH 的一个毒瘤目录。
DSH 是真的不太好用。安装就慢得要死，文件一大堆，一点都不优雅。
它的依赖包里有互相嵌套：
cordis 依赖 cordis-plugin-include，而 cordis-plugin-include 又依赖回 cordis。
导致：物理上你只是在两个目录之间来回打转，但"走过的路牌"每绕一圈就变长一截，永远走不完。
往深了推，这个问题如果只是 Node 还没问题，但是 Git 做一些遍历路径的操作就出现问题了！
也就是这个问题现在来到了 Git 这一边了。
因为 Git 不认识 Windows 传送门，它把传送门当成普通目录傻乎乎地往里走，就被循环传送了。
所以 OpenCode 卡死的问题，是因为它开始的时候会做一些 Git 相关操作，遇到了 DSH 的目录，然后卡死了。
我查了一下，我的用户目录下有一百多万的文件......平时搞各种开源项目，安装各种开发工具，用户目录有无数的配置和缓存文件。出了问题实在是太难排查了！
很多文件，还不一定是我创建的，可能就是各种 Agent 创建的。
另外一个问题是，OpenCode 为什么要在工作目录做一个 Git 操作呢？它主要是为了让你写错代码的时候可以回滚吧~~但是为什么其他软件就不这么搞，它却要这么搞呢，天知道啊。
所以 OpenCode 自身的处理逻辑肯定有问题，具体是什么问题，我还没深入分析！
各种开源软件，各种 Agent，玩起来是爽，想怎么玩就怎么玩。但是 Bug 也是真的多，而且没人为此负责。
OpenCode 和 DSH 这种都已经是 20 万左右 Star 的项目了，没想到放在一起就出现问题了。
当然，这个问题也不全怪它们任何一个。OpenCode 可以赖 DSH，DSH 可以赖 Git，Git 可以赖 OpenCode，形成完美的甩锅闭环了。
其实 Git 是没太大责任的，OpenCode 默认做 Git 操作这个事情就不合理，DSH 的依赖包有这么个毒瘤多少也有点问题。
后来发现 DSH 可能也不是关键，我只能说可能。因为后面分析说，DSH 官方推荐的两种安装方式同时都做了，才导致 junction 循环。
另外一个问题是，可能即便没有这个 DSH，在用户目录执行，也会特别慢。
所以 OpenCode 自己这个锅也不小！
当然再往后推，我自己也有责任了，我为啥要在用户目录启动 OpenCode 呢？
但是 O 哥说了句公道话，这个绝对不能赖用户，因为 CMD 命令默认就指向用户目录，用户完全有道理这么做。这属于不建议，但是允许的范畴。
然后 DSH 应该也算次要责任，只是它的 .dsh 在遍历的时候比较靠前，所以先抓到它了。
自然也不能赖 Windows 的 junction 机制！
主要责任还是 OpenCode！
它应该预防这种事情发生，这个问题不是新问题，其他的软件都有对这种场景的防御机制。
这个问题，如果没有 AI 协助，我基本是解决不了。
所以，不用 Agent 也不行！我们已经基本丧失独立处理底层问题的能力。
充分证明这个世界就是一个又一个草台班子推着前进的。
其实帮我排查这个问题的牛来 Plus 也是有点东西的，我发现它分析各种系统和网络问题非常强。
如果大家有兴趣，我可以分享一下它探索的过程，它是如何分析这个问题，又是如何发现错误，又是如何递进的，这个过程看一圈，感觉可以学到好多知识。这是真正意义上的"思维链"！
不过，我觉得大部分人可能没心思看这些细节的~~！
我决定把这个坑留着，不去修复它，以后作为一个测试题目，我感觉我是在电脑上养蛊啊~~哈哈哈！
测了几个模型了，大家表现差异还是很大的。有的人根本找不到思路，有的人要思考特别久，有的人一下子就抓住了关键，很快定位问题了。