同类产品坐标系
六维对比表 + 形态之争 + 互操作姿态 + 一棵「我该用/该学哪个」的决策树。
对比不是为了排名次。这张表要回答的是一个更实际的问题：当你想改某一件事的时候，在各家分别要付出什么代价——这才是「插件化」到底值多少钱的度量衡。
dsh 那一列出自本仓库源码，逐条可点到源码坐标；其余三列是二手整理，凡未逐条验证的格子都带 待核对 标记。这不是占位符，是这一页的内容框架的一部分——发现错的地方，以各家官方文档为准。
1.1 六维对比表
| dshDeepSeek 官方 | OpenCode社区开源 | Codex CLIOpenAI | Claude CodeAnthropic | |
|---|---|---|---|---|
| 界面形态 | Web UI 优先；同时给 CLI、ACP、JSON-RPC 三条自动化入口 | 终端优先，多客户端 待核对 | 终端 待核对 | 终端为主，另有桌面 / IDE / Web 入口 待核对 |
| 扩展模型 | 一切皆插件，无特权核心；capability seam 三角色，227 个包全部平级 | plugin hook + 自定义工具 + MCP 待核对 | 配置 + MCP 待核对 | hooks + skills + MCP + subagent 待核对 |
| 模型接入 | 自家适配器 seam：llm 定义 + llm-deepseek 实现，换厂商＝再写一个 provider |
开箱支持大量 provider 待核对 | OpenAI 系为主 待核对 | Anthropic 系为主 待核对 |
| 会话真相 ★ | append-only 事件日志；消息、fork、resume、遥测全部由 deriveMessages() 投影出来 |
SQLite 存储 待核对 | 各自实现，未公开为契约 待核对 | 各自实现，未公开为契约 待核对 |
| 互操作姿态 ★ | 把竞品当可编排的子能力：树内就有 subagent-claude-code、subagent-codex、两套 hooks 桥接与 ACP |
以自身为中心，通过 MCP 接外部能力 待核对 | 同上 待核对 | 同上，另有 subagent 编排 待核对 |
| 上下文工程 | 每个包 README 必须写清模型看见什么、花多少 token、对 KV cache 有什么影响，CI 卡 | 未见对等的公开工程契约 待核对 | ||
| 开源与成熟度 | 全开源（MIT）；developer preview，会有破坏性变更，生态还小 | 全开源，社区规模领先 待核对 | CLI 开源，后端闭源 待核对 | 闭源产品 待核对 |
表 1.1 带 ★ 的两维是 dsh 真正的分野所在，M3 与 M5 各有一整节展开；「上下文工程」那一行是 M4 的全部内容。
1.2 表格之外，三个值得展开的判断
形态之争：终端 vs Web，底下是产品 vs 平台
这个争论的表面是交互偏好，底下其实是定位差异：一个在做产品，一个在做平台。
终端优先的产品把「手感」当第一优先级——启动速度、键盘流、在 SSH 里能用。dsh 选 Web 优先，代价是它在 SSH 场景里天然吃亏，换来的是：一个能渲染富交互卡片的前端（packages/client 一个 group 就有 40 个包，占全仓 17.6%），以及一个可以被插件长出新 UI 的宿主——M6 里模型现场造的工具能带自己的界面，靠的就是这个。
谁都没错，但选错了参照物就会得出荒唐结论：拿 dsh 的终端手感去比 OpenCode，跟拿 OpenCode 的可替换性去比 dsh，是同一种错误。
互操作：把竞品当成自己的一个子能力
dsh 树内就住着 Claude Code 和 Codex 的 subagent provider 与 hooks 桥接：
| 包 | 它做什么 |
|---|---|
subagent-claude-code | 通过官方 Claude Agent SDK 启动一个真实的 Claude Code 子代理 |
subagent-codex | 启动一个真实的 Codex app-server 子代理 |
subagent-acp | 通过 ACP 启动一个进程外子代理 |
hooks-claude-code / hooks-codex | 把你已有的 hooks.json 指过来，那些外部 shell hook 就照原样跑 |
「你也可以是我的一个插件」——这个姿态本身，比任何一条功能对比都更能说明它的自我定位。而且它在结构上是诚实的：这两个 provider 是独立的可选 bundle，不进 dsh-base，也不进 @deepseek-ai/dsh 的默认生产依赖闭包，你不装就完全没有它们的运行时。
hooks 这个包的 README 里还藏了一句很有态度的话：规范的扩展面是 harness 自己那套类型化拦截点，「native hook」不过是一个挂在那些拦截点上的普通 Cordis 插件；这两个桥接包只是把外部 shell hook 协议翻译到同一个面上。它没有把别人的扩展模型当成一等公民，而是当成了一个需要适配的方言。
1.3 选型决策树
「我该用哪个」和「我该学哪个」是两个问题。下面这棵树先问你想改什么，再给答案——注意最后一条分支。
你想改的，到底是哪一层？
Claude Code