DeepSeek Harness 确实有点震惊到我了

最近这个DeepSeek Harness实在太火了，

我也是第一时间体验了一下这个黑鲸鱼，但是我的感觉是：这东西的上限是真的高。

其实DeepSeek Harness（为了方便，以下简称DSH）的安装过程特别简单。只需要在终端命令行输入

npx @deepseek-ai/dsh web

就完事了。对，就这么简单。

然后在你的浏览器输入

http://127.0.0.1:3080/

就能启动DSH了。DSH的呈现形式只有webUI，也就是说桌面端、CLI应用它通通没有，而且每次启动都要在终端输入「npx @deepseek-ai/dsh web」。

启动之后其实看起来和Codex没太大区别，同样的侧边栏、同样的工作区选择、同样的模型设置……输入你的api-key之后就可以用起来了。

你可以在这个界面做和Codex、Claude Code一样的那些任务，简直就是DeepSeek版的Codex。但我很快就发现事情并没有这么简单。

01

连前端UI都能魔改了

DSH没有类似Codex的订阅机制，也就是说我在使用的过程中消耗一个token、我的DeepSeek账户钱包里就要少一点点钱。

在Codex里我可以在客户端左下角的设置里随时查看订阅的「每周使用限额」，用了多少额度一目了然。但是用着DSH我必须反复切到DeepSeek开放平台官网去看我的钱包里用掉了多少钱，真的超级麻烦。

所以我第一个想法就是，如果DSH里面也能随时看到这个对话的用量就好了，最好还能直接显示这个对话里我花了多少钱。试着写了提示词之后我真的被DSH的自由度震惊了，它真的编辑了UI界面，在原来的「对话」、「轨迹」后面新添了一个「费用」标签卡。

但是我真的很懒。感觉点标签卡还是麻烦，所以又做了一个可以拖动、可以最小化的悬浮窗，而且设计了一套动画效果，让计价器像水表浮动一样走字。

我最后甚至做了一个把整个主题切换成赛博像素风的选项，按钮直接放在设置里面，按下之后配色会变化，而且所有的图标素材、字体全部变成像素风。

02

原来是插件给了我自由

原来，DSH这么自由是因为它的架构特色——「一切皆插件」。

我看到DSH这个宣传标语的时候真是一头雾水。做了这些测试才明白，DSH的特色是整个Agent上的每个部分都可以快速插拔、快速调整。比如我刚刚修改前端UI的测试能这么轻松地完成，就是因为在DSH里，UI也是一个插件。

换句话说，整个DSH就像是一堆散装的零件，而一开始进入展示给你的只是一个预设的模版而已。你可以在那上面修改任何东西，不止是UI，你还可以调上下文长度、调记忆存储方式、学着控制你的电脑…

传统的Agent产品也有插件，但是那些产品更像是允许你在它原本的基础上加东西、而不允许你改它底层的Agent构建方式。

插件化还有一个好处，那就是丰富的开发者市场。市场上你可以看到用户们自己搓的插件，我打开设置一看，光是DSH预设的插件就已经有了一百多个，插件市场上的插件更是已经有了上千个。

这才刚上线一周，以后各种各样的插件肯定会比现在还要多得多。

03

当Agent只有「鱼的记忆」

为了再深度试试DSH的特色，我还试着用插件化的思路调整了一下DSH的Agent Harness本身。

我自己DIY了一个「鱼的记忆」模式。不是说可以调整上下文窗口吗？我干脆做了一个只有60秒记忆的模式。

这不是在系统提示词里面让模型演出来的，而是我在DSH的Harness架构里确确实实把「context」部分做了修改：每过60秒Agent就会清空一次上下文，你可以体验让一个超级健忘的Agent帮你干活是什么感觉：刚刚还记得你是谁，转头就忘了；刚刚正在整理文件，转头就不记得自己要干什么了……

而且把「上下文」这个插件改好之后，整个模式也顺利加到了模式选择的列表中。这一切想在Codex这种框架相对固定的Agent中就实现不了。

顺便一提，通过Harness调整完整实现这个新模式的设计，从头到尾就花了我20块钱，我感觉真的很值。

不过因为技术力不足，我不是自己写的插件代码，而是用提示词一步步教DSH完成自我修改的。这导致我在做这个功能的过程中也遇到了不少问题。

主要原因是DeepSeek对我的提示词理解有偏差，它一开始真的以为我是想设计一个「鱼」模式，就在系统提示里还加了一堆模型是鱼的人设……然后它又把整个过程弄得像演戏一样一直在重复「我恢复意识了」、「我失忆了」……

所以做出这个模式还是花了些功夫的。不过对于专业的开发者，如果有十足的技术力，能自己写代码直接给DSH魔改各种插件，效果肯定要便捷非常多。

04

透明的轨迹，

我逐渐理解一切

另外，和Codex相比，DSH还有一个很大的特色，就是可以直接查看「轨迹」。

它会把Agent在执行任务时产生的一系列事件全都记录下来，包括模型的推理过程、实际输出、调了什么工具、工具返回了什么结果、用了多少token，还有每一步花了多长时间……

结果出了问题，你直接去翻轨迹就行。看看模型当时收到了什么信息、是不是有信息漏传？到底调了哪个工具、是不是调错了工具？工具吐回来的是什么、是不是工具模块出了问题？这样核查bug原因变得简单很多。

我让DSH给我搓一个吃豆人小游戏的时候，就实打实靠着看轨迹完成过一次debug。

游戏刚做出来的时候，地图上的豆子、游荡的幽灵敌人生成都没问题，但是吃豆人本体怎么都动不了。

于是我让Agent顺着任务的轨迹一步步检查，看模型的输出、看工具调用、看各个阶段返回的结果。最后直接揪出了出问题的那个环节：Agent把地图分成了很多方格，当吃豆人的移动距离大于方格的边长时候，它就会移动一个格子。

为了看起来平滑自然，这里有一个「吸附」的逻辑。但是原来代码里面吸附的范围比边长还大，所以吃豆人怎么也走不起来。

找到原因以后，Agent重新写了移动方式：先确定下一个格子，再让吃豆人一直走到那个格子的中心，走到以后才判断下一步。改完以后，吃豆人终于能正常移动了。

Codex当然也会记录整个任务的执行轨迹，但是对于用户来说大部分是不可见的。DSH把更多内容放进了可以直接查看的轨迹里：模型收到了什么信息、工具返回了什么、结果又怎样进入下一步，我都能看到。对于普通用户来说，有了这些轨迹，也能更好地理解Harness到底是怎么工作的。

而且轨迹这东西对于Agent设计和训练确实有用，尤其是做Agent评测的时候，评测轨迹数据能很好的优化Agent意图识别、工具调用之类的能力。

但是对于普通使用者来说，我上面这个debug的测试，好像全都交给模型自己解决就行了。看到轨迹只是让过程变得透明、让我更理解Agent的行为模式，但是单论debug的速度和效果，和全都交给模型，我只是做端到端的验收完全没区别。

05

DSH的上限是真的高

虽然我是一个代码水平不高的普通用户，但是一通测试下来，我还是被DSH的上限震惊到了，它实在是太自由了。

DSH更多还是为了服务专业的开发者，正如官网上的标签所说，DSH是一个「开发者预览版」，主要服务的还是那些有代码能力，熟悉Agent Harness架构细节的大佬的。想必在他们手里，DSH肯定能玩出更多花样。

而且有了插件化的DSH之后，设计一个全新的Agent真的变轻松了很多。或许之后不只有「鱼的记忆」模式，我们会在大佬手里看到更多稀奇古怪的Agent出现。

撰文|王 芮

微信编辑|泡 泡