DeepSeek Harness 发布了：一个产品经理的看法

昨天，DeepSeek 在 GitHub 上开源了 DeepSeek Harness，代号 dsh。截至我动笔时，这个项目已经拿到 5 万 3 千多颗星、4300 多个 fork。作为一个在银行数字化条线摸爬滚打、平时也折腾点 AI 工具的产品经理，我第一反应不是"又一个框架"，而是：这次 DeepSeek 终于不卷模型了，它开始卷"AI 怎么干活"。

一、dsh 不是模型，是 agent 的"操作系统"

很多人看到 DeepSeek 两个字，条件反射以为是新模型。但 dsh 跟 V3、R1 没关系，它是一个开源的 agent harness，也就是给 AI agent 搭台子的框架。用官方的话说：Everything is a Plugin。

这句话听起来像口号，实则很狠。传统 agent 框架通常有一个"主脑"，然后工具、记忆、沙箱、权限都挂上去。dsh 的做法是反过来的：主脑本身也是插件，工具是插件，session 是插件，审批流程是插件，连 agent loop 也是插件。你可以像搭积木一样组装一个 agent，不想用默认的 loop，换；不想用默认的 shell provider，换；甚至不想让模型访问网络，直接把 web 插件卸载掉。

这种设计让我想到一个词：可逆。Cordis 作为底层，所有插件注册都是 effect，卸载时会自动回滚。这意味着你临时加载一个实验性功能，搞砸了也不会把整棵树搞坏。对开发者来说，这是比"高度可扩展"更实在的安全感。

二、为什么 53k star 一点都不虚

开源一天拿到 5 万多星，乍看夸张。但考虑到 DeepSeek 上半年的热度，以及这次 dsh 瞄准的痛点，这个数字其实有迹可循。

当前 agent 开发最大的噪音不是"缺模型"，而是"缺共识"。Claude Code、Codex CLI、OpenCode、Cline、Roo Code、各种 MCP 服务器……每个都有一套自己的调用方式、上下文格式、权限模型。开发者经常在一个项目里要面对三四种 agent 工具，彼此不兼容。dsh 的出现，像是要在混乱中建一个中间层：它不逼你选边站，而是让你把各家能力都封装成插件，挂到同一棵 Cordis 树上。

更关键的是，DeepSeek 这次把姿态放得很低。README 第一句就是"developer preview"，第二句警告"会有破坏性变更"。这种坦诚反而增加了可信度。太多框架发布时把自己吹成终极方案，结果半年弃坑。dsh 直接告诉你：现在就是毛坯房，欢迎一起来装修。

三、从产品视角看，dsh 真正想解决什么

我用产品经理的视角看 dsh，不能只看技术架构，要看它背后假设的使用场景。

我认为 dsh 至少瞄准了三个场景：

第一，企业内私有化 agent。 很多公司想做内部智能助手，但不敢把代码和文档交给 Claude Code 或 Copilot。dsh 的插件化意味着你可以只加载本地 shell、本地文件系统、本地 LLM provider，网络功能整个拔掉。自主可控这件事，在国内不是加分项，是入场券。

第二，多模型混合编排。 dsh 的 LLM 层是 service definition + consumer 模式，DeepSeek 只是默认 provider 之一。你完全可以把 Claude、GPT、Kimi、本地模型并排挂上，让不同任务走不同模型。这对我们做内部工具的人来说特别有吸引力：复杂推理走一个模型，日常问答走另一个，成本控制就在眼前。

第三，agent 工作流的长期运行。 dsh 里有 session、compaction、workflow、todo 这些模块，显然不只是想做一个"一次性命令行 agent"。它在为能跑几天、几周的任务做准备，比如持续监控、批量数据处理、自动化运维。这才是 agent 真正该去的地方，不是替代你写一行代码，而是替代你盯着一堆脚本跑。

四、从日常工作看，dsh 对我意味着什么

坦白说，dsh 让我有点兴奋，也有点紧张。

兴奋的是，如果 dsh 生态真能起来，我们团队内部很多重复性工作可以变得更"轻"也更"准"。现在我们不少协作流程还依赖各自独立的 agent 工具，有的跑脚本，有的调接口，有的靠人工串起来。如果未来这些能统一到一个 harness 里，用插件的方式组合文件操作、网页查询、日程提醒、邮件通知，那意味着更少的适配成本，更低的人为出错概率。

紧张的是，dsh 把"工具"和"模型"拆得更开了。过去大家可能会把某个 agent 能力强弱简单归因于模型强不强；未来会更清楚，关键在 orchestration。这其实是一件好事，透明化会让大家更理性地评估 agent 的真实价值，但也会加速内卷：谁能把插件生态玩顺，谁就能在内部效率上领先。

另外，dsh 提到的 subagent、self-modification、guard 这些模块，让我意识到 agent 的边界正在模糊。以前 agent 是"被调用"的，dsh 似乎在探索 agent 主动检查自己、修改自己、委托其他 agent 的边界。这不是科幻，这是架构上在为更高度的自主性铺路。

五、冷静一下：现在还不是 all in 的时候

虽然我说了不少好话，但 dsh 目前还是开发者预览版，README 自己都写了"会有破坏性变更"。现在跑生产环境，风险很高。

有几个地方我会继续观望：

生态成熟度。 "一切皆插件"听着美好，但插件多了，版本兼容、依赖冲突、权限边界都会变成噩梦。Cordis 能否撑住大规模生态，还要时间验证。

文档和学习曲线。 从我读到的 architecture.md 和 AGENTS.md 来看，dsh 的概念密度不低。profile、bundle、cordis.patch.yml、event map、capability event……这些名词对普通开发者有一定门槛。如果 DeepSeek 不能在接下来几个月做出好教程和好示例，热度会快速退潮。

商业模式。 开源很热闹，但长期维护需要资源。DeepSeek 会把 dsh 作为吸引开发者用自家模型的入口，还是真的独立运营一个中立的 harness，这是两个完全不同的故事。我倾向于前者，但这不代表它不能成功。

六、dsh 和 MCP 不是竞争对手，是两条路

很多人会问：dsh 是不是要替代 MCP？我的看法是，不是替代，而是两条不同层级的设计。

MCP 解决的是"模型怎么调用外部工具"的问题，它更像一个协议。你定义好工具 schema，模型通过统一接口调用。dsh 解决的是"agent 怎么组织自己的内部结构"的问题，它更像一个操作系统。你可以把 MCP 服务器封装成一个 dsh 插件，也可以把 dsh 的一个 capability 暴露成 MCP 工具。

打个比方：MCP 是 USB-C 接口标准，dsh 是电脑主板。你可以用 USB-C 接键盘、显示器、硬盘，但主板决定这些设备怎么协同工作。未来最可能的场景是：MCP 继续繁荣，dsh 成为众多 harness 中的一种选择。真正有竞争力的，不是协议本身，而是谁能围绕协议长出好用的插件、示例和开发者社区。

七、结语

DeepSeek Harness 的发布，标志着 DeepSeek 从"卖模型"走向"卖基础设施"。这不是能立刻改变普通人生活的产品，但很可能成为未来几年 agent 生态的关键底座之一。如果哪天 dsh 能让我更自然地组合文件、浏览器、日历和代码环境，我会第一个在团队里说：兄弟们，咱们该升级了。

八、写在最后：热度之后看什么

接下来 30 天，我关注的不是 dsh 的 star 数能不能破十万，而是三个更朴素的指标：

第一，有没有真实项目把 dsh 用在生产里。Star 可以刷，生产案例骗不了人。

第二，插件生态有没有自然增长。dsh 的灵魂是 plugin，如果一个月之后 GitHub 上只有官方插件，那"everything is a plugin"就只是 PPT。

第三，文档有没有变得友好。再强的架构，也需要普通开发者能看懂。我希望能看到更多 cookbook 和端到端示例，而不是只有 architecture.md。

在此之前，我的建议是：去 GitHub 点个 star，本地 npx @deepseek-ai/dsh web 跑起来看看，但不要急着把它搬进关键工作流。让子弹再飞一会儿——反正 dsh 自己也说了，它还在快速迭代， breakage 在所难免。

我们需要的，不是又一个被过度承诺的框架，而是一个真能留下来的 agent 基础设施。dsh 有潜力，但潜力不等于结果。DeepSeek，接着干。