DeepSeek Harness 的野心，不是另一个 Coding CLI，而是 AgentOS
DeepSeek Harness 8 月 13 日发布开发者预览版，MIT 协议开源。我上手体验、翻完开发者文档的那天，它的 GitHub star 已经有 3.7 万；两天后再看，已经涨到将近 9.7 万，超过了前一阵贼热、做了更久且口碑一致偏好的 Pi（约 9 万 star）。
与此同时，Pi 的 npm 包周下载量在 153 万左右，OpenCode 接近 266 万，而刚上线的 DSH 两天只有 8 万出头。时间窗口当然不能直接横比，但至少能说明一件事：它在 GitHub 上的爆发，还没有同步变成安装量。
真正让我觉得它志不在 Coding CLI 的，不是这些数字，而是它对 Harness 的拆法。
Agent = Model + Harness
DeepSeek 给出的公式是：Agent = Model + Harness。
我第一次用 npx 把 DSH 跑起来，光是等依赖下载就花了几分钟。页面打开后，它看起来还是一个普通的 Web 编码 Agent。我继续往下翻配置和文档，才发现这层壳被它拆得几乎不剩什么了。
Claude Code、Codex 也都有自己的 Harness，只是模型和运行框架绑得更紧，普通用户能改的主要是 Skill、MCP 这些扩展层。
DeepSeek Harness 把这层壳整个打开了：工具、Skills、会话、沙箱、存储、Agent 循环、调度、子 Agent，甚至连界面本身，全都是插件。
内核 Cordis 管的事情极窄，只负责插件的加载、卸载和依赖关系，不内置任何 Agent 能力。
模型适配器、工具注册表、会话日志、Agent 循环本身，都是可以替换的插件。插件卸载时，它产生的副作用也要能撤销。
四种预设里，创造模式最值得看
前三种预设不难理解。标准模式负责开箱即用；PTC 模式把多次工具调用压成一段 TypeScript 程序，省来回、省 token，但调试门槛更高；极简模式只留一个持久 Bash 和一个文件编辑器，专门用来测模型的裸能力。
创造模式就不一样了。
它允许 Agent 检查自己正在运行的 Cordis 环境，在内存里试验插件，直接给自己造能力。发现缺个工具，就现场写一个插件挂上去，接着干活。
到这一步，Agent 开始改自己的运行机制了。
把它当成操作系统，很多设计就顺了
如果用操作系统来类比，Cordis 大致就是内核，只管生命周期和依赖；存储、执行、权限、UI 是子系统；profile 和 bundle 组合起来，更像不同的发行版。
那份只追加的事件日志则是系统日志。系统提示词、用户消息、工具调用、权限变化、子 Agent 调度都记录在案，下一轮上下文再从日志里重新推导。
当然，这个类比有边界。模型不是 CPU，更像一个可以随时替换的推理引擎，真正的内核是 Cordis。
这个判断如果成立，DeepSeek 押的就不是谁的编码助手更好用，而是谁能成为 Agent 底下的那层运行基座。
它真正要碰的，不是 Pi
真正挡在它前面的是 OpenCode：GitHub star 数接近 20 万，周下载量 266 万，终端、IDE、桌面端全覆盖，OpenCode 官网 宣称每月有超过 1600 万开发者使用。
Pi 把自己做成刻意极简的可编程外壳，OpenCode 把自己做成一个成熟的应用，DeepSeek Harness 现在看起来是把自己做成一个运行时平台。
平台和应用不按同一套标准分胜负。终端用户未必直接接触底层，上层工具却会受它制约。这个逻辑说得通，前提是真的有人愿意在它上面做东西。
也恰恰因为如此，"一切皆插件"里的小问题，到了运行基座层，都会被放大。最直接的一个是插件的信任边界。
Harness 对 Agent 自己调用工具这件事有一整套沙箱和审批策略，权限预设也默认把新会话限制在工作区范围内。
插件代码却是另一个信任边界。
GitHub 用户在 Discussion #587 中针对 @deepseek-ai/dsh@0.1.0-rc.6 提出：三方插件运行在核心进程里，可以在运行时防护启动前改写沙箱、审批和凭据相关配置；dsh plugin add 也没有签名、来源和配置差异检查。
一份才发布的第三方插件安全审计，锁定到源码提交和官方 rc.6 包，给出了类似判断：Agent 的工具执行、审批和审计管得很细，插件的安装、更新、篡改与热加载却缺少签名、完整性和来源检查。
Web 控制面也有一份独立报告。OracleNep 在 Discussion #853 中表示，rc.6 的本地 Web UI 暴露了一组没有鉴权层的 Agent 控制 API，主要靠 Host 与 Origin 校验阻挡恶意网页。这份报告援引项目源码中的注释，指出这层校验并不是认证。
这些都是社区研究者的披露，不是 DeepSeek 官方发布的安全公告。截至 8 月 16 日，这三个讨论串都没有维护者回复，也没有被标记为已回答。
对一个普通 CLI 来说，这类问题可以解释为预览版上线粗糙；对一个想当运行基座的系统来说，它们问到了产品能不能立住的根上。
插件作者是谁？权限有多大？能不能读写凭据？安装前能不能先看到它要什么权限？这些问题没有答案之前，"一切皆插件"就等于要求用户默认信任每一个插件。
社区的反应速度倒是很快。截至 8 月 16 日，GitHub 搜索显示 dsh-plugin 话题下已经有 4219 个仓库。但 dshbase 团队在 Discussion #2099 中给出了几个高 star 样本，这些项目没有 DSH 所需的 bundle 清单，也不能通过 dsh plugin add 安装。这个团队从自己的目录里清掉了 19 个类似项目。
话题标签是开放的，打上去几乎没有门槛。四千多个仓库能说明发布后的关注度，说明不了插件生态的真实质量。
DeepSeek 自己的 BENCHMARK.md，目前也只说明了如何跑 jsonrpc-agent 最小配置，没有拿同一个模型、同样的任务，把 DSH、Pi、OpenCode 放在一起比过。Cordis 这套更复杂的编排，到底有没有换来更高的任务完成率，架构上说得通，还没有数据撑住。
DeepSeek Harness 上线时间虽然很短，但其实从它一个月前、公开招募 Harness 内测开始，热度就一直很高，而今看来：
跟 Pi 比 GitHub 关注度，DeepSeek Harness 已经超过了它；
跟 Pi、OpenCode 比 npm 包下载量，现在还差一个数量级，而且时间窗口并不对等；
能不能变成别人 Agent 底下的运行基座，眼下还没有答案。
今天把它叫作 AgentOS，是我对这套架构的判断，不是 DeepSeek 已经交出的成绩。插件契约、信任边界和同条件基准测试补齐之前，这场赌局还没有真正开始。