最近 DeepSeek Harness 的变化有点密集。
前脚视觉模型刚刚正式上线，让 DSH 从“主要靠文字和代码理解任务”，进一步获得了直接处理图片的能力。后脚我又发现，一个已经接近 9 万 Star 的开源项目 OpenDesign，正在干另一件很有意思的事：
给 DeepSeek Harness 补一套完整的“设计工作台”。
而且这次并不是给 DSH 装一个普通 MCP，让它多几个工具。
OpenDesign 0.19.1 已经把 DeepSeek Harness 当成了一个真正的原生 Agent Runtime，可以直接读取 DSH 的模型、推理档位、思考过程、工具调用和 Session，还专门整理了 19 个面向设计场景的 DSH 插件。
简单理解就是：
以前我们一直在想办法让 Agent 更聪明。
现在已经有人开始认真解决另一个问题：
Agent 会写代码以后，怎么让它做出来的东西别那么“AI 味”？
一、OpenDesign 到底是干什么的？
第一次看到 OpenDesign，我很容易把它理解成又一个“AI 生成网页”的工具。
仔细研究后发现并不是。
OpenDesign 自己给出的定位是：
“The open-source Claude Design alternative”。
也就是一个开源版的 Claude Design。
它能做网页原型、桌面界面、手机 App、Dashboard、PPT、图片、文档和视频，最终还能导出 HTML、PDF、PPTX、MP4 等真正可以交付的文件。
但它比较特别的一点是，OpenDesign 自己并不要求必须使用某一个固定 Agent。
Codex、Claude Code、Cursor、OpenCode、Hermes，包括现在的 DeepSeek Harness，都可以成为它背后的“设计引擎”。
可以把两边的分工理解成：
OpenDesign 负责设计系统、Skill、视觉规范、预览、批注和交付；
DeepSeek Harness 负责理解任务、读写项目、修改代码、运行工具和执行 Agent 工作流。
OpenDesign README 里有一句话，我觉得总结得很准确：
“Your CLI becomes the design engine, your laptop becomes the studio.”
你的 CLI Agent 变成设计引擎，你的电脑则变成一个设计工作室。
二、这次最重要的变化：DSH 不是通过 MCP 接进去的
OpenDesign 本来已经支持很多编程 Agent。
例如给 Codex 安装 OpenDesign MCP，可以执行：
od mcp install codexHermes 也是类似的思路：
od mcp install hermes但 DeepSeek Harness 不一样。
在 OpenDesign 的兼容列表里，它被明确标记成：
Native runtime。
设置命令也是：
od agent setup deepseek-harness这个区别看着不大，底层其实完全是两回事。
MCP 更像是给现有 Agent 增加一套工具。
而 Native Runtime 的意思是：
OpenDesign 直接负责启动和管理 DSH，让 DeepSeek Harness 成为 OpenDesign 自己的 Agent 执行后端。
为了实现这个效果，OpenDesign 甚至专门为 DSH 做了一个名为：
open-design的 Profile，并增加了一层很薄的：
@open-design/dsh-runtime连接组件。
DeepSeek Harness 自己的模型、工具、Sandbox、Session 和 API Key 依然全部由 DSH 管理，OpenDesign 并没有重新造一个 DeepSeek Agent。
它只是把两套系统真正接通了。
三、连“思考过程”和工具调用都能直接传回来
普通软件所谓“兼容某个 CLI”，很多时候只是启动命令行程序，然后读取终端输出。
终端里打印什么，就想办法解析什么。
OpenDesign 这次明显走得更深。
它启动 DSH 时用的是：
dsh --profile open-design --stdio然后两边通过结构化 JSONL 协议通信。
OpenDesign 可以把当前工作目录、用户需求、模型、推理档位以及需要恢复的 Session ID 交给 DSH。
DeepSeek Harness 再把执行过程分成不同事件送回来：
thinkingtexttool_calltool_resultusageresult所以 OpenDesign 知道哪一段是模型思考，哪一段是正式回复，什么时候调用了工具，工具返回了什么，消耗了多少 Token，以及任务最后到底成功、取消还是失败。
这也是为什么在 OpenDesign 里面用 DSH，不只是看到一大坨终端文字。
它可以把整个 Agent 工作过程重新做成自己的图形化工作流。
四、进程关掉了，DSH 还能接着刚才的活继续干
还有一个设计我觉得非常实用。
OpenDesign 并不会为了保持上下文，让一个 DSH 进程永远挂在后台。
第一次让 DSH 做设计时，它会启动一个新的 DSH 进程，并获得一个 Session ID。
任务完成以后，这个进程可以退出。
等你下一句说：
“按钮再大一点，标题往上挪。”
OpenDesign 会重新启动一个 DSH 进程，但同时带上刚才的：
resume_session_idDeepSeek Harness 会从自己的持久化 Session 里恢复之前的工作。
可以理解成：
进程重新开了，但是脑子没有重新开始。
更重要的是，OpenDesign 不需要每一次都重新把整段聊天历史塞给模型。
DSH 自己负责恢复原来的执行历史，OpenDesign 只需要把这一轮的新要求交过去。
做持续几十轮的网页、App 或设计修改时，这个机制就很重要。
五、真正有意思的是：它开始给 DSH 补“审美”
DeepSeek Harness 本身当然会写前端。
你让它做一个登录页、Dashboard 或 Landing Page，它完全有能力完成。
问题是：
会写页面，和会做设计，是两回事。
字体怎么搭配？
间距应该怎么统一？
按钮、卡片、颜色、响应式断点有没有一套规则？
整个页面到底应该是什么视觉气质？
如果没有这些约束，再聪明的 Agent 也很容易做出那种熟悉的“AI 页面”——渐变背景、大圆角卡片、到处发光，看起来什么都有，就是不像真正的产品。
OpenDesign 给出的思路是：
DeepSeek HarnessDESIGN.mdDesign SystemFrontend SkillReferencePreview / Review让 Agent 不只是接到一句“帮我做漂亮一点”，而是拿到明确的设计规则。
OpenDesign 现在已经积累了 151 套 Design System 和大量 Skill、Plugin。
它自己也专门强调过一句：
“Composability is not taste.”
能组合各种工具，不等于有审美。
这个判断我非常认同。
六、他们甚至专门给 DSH 整理了 19 个设计插件
继续往 OpenDesign 源码里翻，我还发现它已经单独建立了一套：
“DeepSeek Harness plugins for design”。
目前收录 19 个 DSH 原生设计插件，大致分成四类：
视觉输入、Canvas 与生成式 UI、设计工作流、Workspace 与 Preview。
比如 dsh-openpencil，可以让 DSH 直接操作真正可以编辑的矢量画布，而不只是生成一张静态图片。
deepseek-harness-genui 更有意思。
当文字交流太复杂时，Agent 可以直接临时生成一个 React + TypeScript 小界面。
假设它需要你从十几个方案里选三个。
以前只能给你列一长串文字。
现在可以直接生成一个选择界面，你点完以后，选择结果还能重新回到当前 Agent Task，下一轮 DSH 继续根据你的选择干活。
还有 dsh-web-preview。
DSH 刚做完网页，右边就能直接预览。
你可以点某一个页面元素，写一句：
“这个按钮太大了。”
插件会把对应的 Selector、HTML 和批注意见一起交给 Agent。
DSH 不用猜你说的是页面里的哪个按钮，可以直接定位修改。
甚至还有 dsh-hyperframes，把 HyperFrames 的 HTML、CSS、GSAP 视频制作工作流带进 DSH。
所以现在围绕 DeepSeek Harness，已经逐渐出现这样一条链：
看参考图→ 理解设计→ 写页面→ 实时预览→ 人工批注→ Agent 修改→ 做动效→ 输出视频这已经明显不只是“代码 Agent”了。
七、已经装了 DSH，实际接入反而不复杂
如果电脑里已经安装并配置好了 DeepSeek Harness，最核心的操作并不多。
先确保 DSH 自己可以正常运行，并已经在：
dsh web里面配置好 DeepSeek API Key 和模型。
然后安装 OpenDesign，在终端执行：
od agent setup deepseek-harnessOpenDesign 会给 DSH 安装或修复自己的 open-design Profile 连接组件。
随后回到 OpenDesign 的本地 Agent 页面重新扫描。
正常情况下，就可以直接看到 DeepSeek Harness。
模型列表也不是 OpenDesign 自己写死的。
它会执行：
dsh --profile open-design --models读取你本机 DSH 当前真正拥有的模型目录，连模型支持的 Reasoning Effort 也会一起读取。
API Key 仍然由 DeepSeek Harness 自己保管，OpenDesign 不需要知道你的 Key 明文。
这一点我觉得做得比较克制。
八、现在想尝鲜，有一个版本坑必须提前知道
这里也有一个很现实的问题。
OpenDesign 0.19.1 当前代码明确验证的 DeepSeek Harness 版本还是：
0.1.0-rc.6它自己的 @open-design/dsh-runtime 依赖同样锁在这一代。
但 DeepSeek Harness 最新已经发布：
0.1.1-rc.1也就是说：
OpenDesign 和 DSH 的更新速度暂时出现了时间差。
OpenDesign 对更高版本并不会一律禁止运行，如果版本可以识别，可能只会显示 untested-version。
真正的硬检查是：
dsh --profile open-design --probe也就是确认 OpenDesign Profile 的通信协议还能正常工作。
所以如果刚接触，我不建议看到 DSH 最新版就一路猛升。
至少目前应该知道：
“能启动”和“OpenDesign 已经正式验证兼容”，不是一回事。
最后
这次 OpenDesign 原生接入 DeepSeek Harness，我觉得真正值得关注的并不是：
“DSH 又多支持了一个软件。”
它背后出现了一个很明显的新趋势。
过去一年，大家一直在给 Agent 补能力。
联网、终端、浏览器、Skill、MCP、子 Agent、长期记忆，一个接一个往上加。
Agent 终于开始真的能干活以后，下一个问题已经来了：
它做出来的东西到底好不好看、好不好用、像不像一个真正的产品？
OpenDesign 做的事情，就是开始给这些强 Agent 补这一层。
模型负责聪明。
DeepSeek Harness 负责行动。
OpenDesign 负责把设计系统、审美规则、预览、批注和交付接进来。
如果这条路线继续发展下去，以后我们可能真的不需要专门寻找一个所谓的“AI 设计模型”。
给现有的强 Agent 装上一套成熟的设计工作台，它就可能直接变成设计 Agent。
这次 DeepSeek Harness，已经开始走到这一步了。
热门跟贴