DeepSeek Harness v0.1 以“一切皆插件”为核心理念，重新定义 AI 编程框架。作者亲手打造赛博朋克风 GUI，却也因此遇到性能瓶颈，插件化架构背后的真实代价在这里被完整揭开。核心内容：1. DeepSeek Harness v0.1 正式发布，其“Everything is a plugin”的设计思路意味着，不只是外围扩展能力，连模型适配器、工具注册表、会话日志、Agent Loop 等核心模块都可以被替换。开发者只需挂载插件，无需改动核心逻辑即可扩展功能。底层基于 Cordis 元框架，支持热插拔、可回溯以及依赖管理。2. 作者尝试自制赛博朋克风格 GUI，并介绍了桌面化实现方案。3. 插件化设计带来的性能问题逐渐显现：内存占用高、CPU 满载、多窗口情况下明显卡顿。
DeepSeek 这次终于正式下场了。
8 月 13 日，DeepSeek 发布 Harness v0.1。消息一出，很多人都在讨论同一个话题：国产版 Claude Code 真的来了？
大家之所以会如此兴奋，其实并不难理解。过去一年，Codex 和 Claude Code 已经把 AI 编程工具推到了新阶段：你不需要再一行一行教它写代码，而是直接给它一个任务，让它自己读文件、改代码、执行命令，最后再把结果反馈给你。
但 Harness 走的是另一条路线。它不是把 Agent 封装成一个不可拆分的产品，而是把整套 AI Agent 系统拆开给开发者看：模型可以替换，工具可以替换，Agent 如何调用工具也可以重新组合；继续拆解下去，连会话、权限管理和 UI 界面也都能做成插件。
DeepSeek 用一句很直接的话概括这套设计：Everything is a plugin。
也就是，一切皆插件。
在 DeepSeek Harness 中，Agent 被拆成了多个可以独立替换、自由组合的模块。
当我看到 UI 也能被替换时，脑子里立刻冒出了一个很实际的想法：能不能把它做成类似 Codex 的桌面应用？
我不想每次都去打开 PowerShell，也不想记住启动命令，更不想一直对着浏览器地址栏工作。我想要的是双击桌面图标，就能直接看到项目、会话和设置；如果视觉效果还能再酷一点，比如极光、粒子、扫描线全都安排上，那就更好了，哪怕有点“光污染”也无所谓。
于是，我真的给 DeepSeek Harness 做了一个 GUI。
赛博朋克风GUI
我保留了 DeepSeek 官方 Harness 原本的模型、会话和工具系统，把桌面启动和视觉表现交给外面这一层外壳。启动器会先拉起本地服务，等页面准备完成后，再通过 Edge 的应用模式打开一个独立窗口。
这种方式其实很巧妙。Edge 会自动隐藏地址栏、标签页和侧边栏，同时使用单独的用户目录；用户看到的更像是一款桌面端 AI 编程工具，而不是一个普通网页，电脑也不需要额外安装一套打包后的 Chromium。
应用打开后的第一眼，确实已经有几分 Codex 桌面端的感觉了。
顶部保留了文件、编辑、视图和帮助；左侧可以看到“新对话”“拉取请求”“站点”“已安排”“插件”等入口，中间依旧使用 Harness 的真实会话界面。背景中有缓慢移动的极光，粒子之间会自动连线，窗口边缘还跑着霓虹灯效。
这就是我给 Harness 做出的赛博朋克桌面端。
但很快，它就开始卡了。
我让 Harness 检查自己的 UI
我在会话里输入了一句很直接的话：“你自己检查下你的 UI 为啥这么卡。”
Harness 并没有只给我一段泛泛而谈的前端性能优化建议。它开始主动排查进程、端口、内存和 CPU 使用情况，沿着连接继续定位到承载页面的 Edge 渲染进程；随后又打开主题文件，统计其中使用了多少动画、模糊效果和阴影样式。
整轮诊断持续了四分多钟，在三轮会话中总共执行了十四步。最终结果也很清晰：本地 Harness 服务本身几乎不忙，真正吃资源的是 Edge 的渲染进程——内存占用接近七百兆，采样时几乎吃满一个 CPU 核心；而当时电脑只剩大约 1.6GB 可用内存，页面滚动和流式输出都已经开始变得发涩。
另外还有一个非常朴素的原因。为了检查页面，我当时同时开着 Edge 应用窗口和 Codex 内嵌浏览器，两套 Chromium 内核都在渲染同一套霓虹动画。
两个窗口同时发光，电脑自然就得渲染两遍。
这次“自检”让我第一次真正感受到 DeepSeek Harness 的能力。当前会话使用的是 PTC 模式，模型会先写一段 TypeScript，把一组相关工具放到同一次执行里；它能顺着真实运行环境不断往下追查，而不是每做一步就停下来重新请求模型。
但与此同时，我也碰到了一个更值得思考的问题：Harness 确实已经有能力查清自己的卡顿原因，可一款真正好用的桌面产品，应该在用户察觉之前就把这些性能问题先处理掉。
于是，我打开了设置。
一百六十个插件，两个“设置”
Harness 的插件列表里，大约有 160 个组件。
当你继续往下滚动时，会越来越明白，“一切皆插件”绝不是一句营销口号。模型和会话是插件，PowerShell 与文件工具也是插件；权限控制、消息反馈和会话统计还可以继续拆分，而到了用户每天都会接触的层面，主题、布局、设置页和侧边栏依然能够被替换。
四种内置预设，本质上也是四套不同的插件组合。标准模式负责完整编码任务，PTC 模式更擅长把多步工具调用编排在一起；极简模式只保留少量工具，创造模式则可以检查运行时状态并尝试新的插件组合。
对开发者来说，看到这里确实很难不兴奋。过去选择一款 AI Agent，通常意味着要把它整套接受下来；而 DeepSeek Harness 允许你保留喜欢的部分，再把不合适的部分替换掉。
然后，我就在自己刚做好的界面里，看到了两个“设置”。
一个来自我额外叠加上去的 Codex 风格外壳，另一个则属于 Harness 原本的 Web 界面。新的左侧导航虽然已经画好，但官方侧边栏依然还留在页面结构里。窗口宽度发生变化时，两套布局会争抢同一块空间；一旦遮罩范围或点击区域稍微计算错一点，按钮就可能被挡住，弹窗也可能无法正常关闭。
截图看起来已经很赛博朋克，但当鼠标真正点下去时，你依旧会碰到原来那套网页结构。
这才是 UI 插件真正麻烦的地方。
插件化解决的是系统可组合性；而流畅性、一致性和可恢复性，最终仍然要靠产品层来完成。
为了解决这个问题，我一开始采用的是最快的方法：保留官方页面，在外层增加顶部菜单、左侧导航和动态背景。这样做确实很快，也确实能迅速做出较强的视觉冲击；但问题是，这套方案并没有真正接管 Harness 的布局、设置以及会话相关插件。
如果想把 UI 完整替换掉，开发者还得继续处理焦点切换、滚动行为、窗口尺寸变化以及弹窗层级等细节。官方页面一旦更新，新的桌面端 UI 还要继续跟着适配。CSS 的确可以让页面一夜之间变酷，但日常使用体验，只能靠一次次真实点击慢慢打磨出来。
性能表现同样不会因为插件化而自动变好。为了让页面在无人操作时依旧保持动态效果，我加入了十二组关键帧动画、二十多处阴影，以及多处毛玻璃滤镜。极光在持续移动，扫描线在不断流动，粒子网络一直在计算位置；只要窗口没有关闭，渲染进程就始终有工作要做。
所以下一版要做什么，其实已经很明确了：窗口失去焦点后暂停粒子效果，模型生成时减少背景重绘，毛玻璃只保留在真正需要区分层级的区域；同时深入 Harness 的 UI 插件层，只保留一套导航和一套设置。
它也许会少一点闪耀感，但会更像一款你每天都愿意打开的 AI 编程工具。
写在最后
做完这轮改造之后，我对 DeepSeek Harness 的判断其实是矛盾的。说实话，这种“万物皆插件”的设计到底是不是利大于弊，现在还很难下一个简单结论。
插件化架构确实极大提升了灵活性，也满足了很多开发者和重度用户的 DIY 需求；但如果从用户体验角度来看，和 Claude Code 或 Codex 这种原生一体化产品相比，它目前给人的整体感受并没有那么顺手。
不过，这也引出了一个更值得讨论的问题：如果未来的 Agent 越来越像一个可自由组合的系统，那么产品本身究竟该由谁来完成？是框架作者、插件开发者、做 UI 的人，还是最后那个把所有模块装配到一起的用户？
这个问题，或许还需要时间来回答。
登录查看剩余 70% 内容