抽象税、风险与常见问答
这套做法要付什么代价、现在上手有什么风险、跟 MCP 到底什么关系。
前面九个模块都在讲这套设计好在哪。这一页只讲代价、风险和边界——如果你读完本站要做一个决定，需要的是这一页。
10.1 抽象税：这套纪律具体贵在哪
M2.4 已经算过一次账，这里补三笔更具体的。
一、逐文件 100% 覆盖率不是「测得好」
它是合并门禁（test:coverage，不是 test），statements / branches / functions / lines 四项全 100%，跑在 packages/*/*/src 上。仓库自己对这个门槛的解释很清醒：
「一个未被覆盖的行，往往是门禁正确指出的死代码，而不是一个待补的测试。行覆盖是必要的，从来不是充分的——它证明的是那些行跑过了，不是这个功能按发布的样子工作。」
但代价是真实的：它对新贡献者的门槛极高。你加三行防御性代码，就得为那三行造出触发条件；造不出来，你会被迫删掉它们——这正是规则想要的效果，可对第一次提 PR 的人来说，这个反馈循环很挫败。
二、双语文档把每次改动的写作量翻倍
742 篇 Agent Note，739 篇有中文对照；docs/ 下几乎每篇都有 .zh.md 和 .i18n.yaml；每个包的 README 也是。verify-translation-pairing 用 git blob hash 盯着，改了一侧不带另一侧就红。
对一个双语团队，这是可行的；对一个不是的团队，这条几乎不可能抄。能抄的是它的机制——用 hash 记录「上次确认一致」的状态——而不是它的范围。
三、227 个包意味着 227 份边界要维护
包边界不是免费的：每一个都有自己的 package.json、tsconfig.json、导出面、peerDependencies、以及一份要过 publint 和 knip 的清单。附录的包地图显示，50 个分组里有一半只有 3 个包或更少——最小编制。这说明切分是有纪律的，但也说明「一个能力至少三个包」这条规则被执行得很彻底，包括那些也许本来不需要三个包的能力。
10.2 稳定性风险：现在上手，你在赌什么
1. README 第一节：「DeepSeek Harness 目前处于 developer preview 并在快速迭代。会有破坏兼容性的变更。」（原文这句是全大写。）
2. AGENTS.md 的预发布姿态：「在第一个正式发布时删掉本节。在没有外部消费者的情况下，优先要正确的地基而不是小的爆炸半径：可以自由重命名或重新分包，并同步更新每一处引用。后端拒绝旧的磁盘格式。」
3. 会话格式版本：SESSION_FORMAT_VERSION 现在是 0，AGENTS.md 明写「不作任何兼容承诺」。而且 SessionEventMap 的成员默认 required-on-read——一个不认识某个事件类型的构建会拒绝整份日志，除非那个事件带了 ignorable: true。
再叠上 M7.4 实测的速度：73 天、13,147 个 commit、最近 7 天 92 个合并。把这三件事放在一起看，结论很清楚——
| 你想干什么 | 现在合适吗 |
|---|---|
| 学这套方法论 | 非常合适。方法论不会因为接口变了就失效，而且 742 篇决策记录是随时可读的。 |
| 写一个树外插件玩 | 合适。注册面（ctx.tools、ctx.systemPrompt、seam 接口）比内部实现稳定得多。 |
| 当日常主力 agent 用 | 可以试，但别指望会话数据能跨版本活下来。格式版本是 0。 |
| 基于它做产品 | 现在不行。「预发布姿态」那段话还在，就意味着大规模重命名随时可能发生。 |
| fork 出去改核心 | 算清楚 M7.4 那笔账再说。 |
10.3 生态差距：老实说这是最大的短板
本站不给 star 数对比（那是二手数据，且随时在变）。给几个能在本仓库里数出来的事实：
| 维度 | 树内现状（核对于 commit b150a55） |
|---|---|
| 模型适配器 | 2 个：llm-deepseek（自家）和 llm-pi-ai（通用多 provider 适配器，见 10.4 的 FAQ） |
| 搜索 provider | 3 个：deepseek-official / exa / perplexity |
| subagent provider | 6 个，含 Codex 和 Claude Code |
| 持久化后端 | 2 个：JSONL 和 SQLite |
| 社区插件 | 官方给了一个约定：给你的插件仓库打 dsh-plugin 这个 topic。规模请自行去看那个 topic 页面——这是本站不做二手统计的地方。 |
诚实的结论：seam 数量很多，但每个 seam 背后的实现数量还很少，而且绝大多数是官方自己写的。Lab 4 结尾那个判断标准反过来看也成立——一个 seam 只有官方实现，说明它还没经过外部实现的检验。这套架构的价值主张能不能兑现，取决于未来一年有没有人真的往这些 seam 里塞第三方实现。
10.4 常见问答
跟 MCP 到底什么关系？
不是替代关系，是不同层的东西。
dsh 树内有 @deepseek-ai/dsh-mcp-client：一个 MCP 客户端桥接插件，连外部 MCP server，把它们的工具以 mcp__<serverName>__<rawName> 的名字注册到 ctx.tools 上，对模型来说就是原生工具。cordis.yml 里一个 server 一个插件实例。
差别在于能碰到的东西：
| MCP server | Cordis 插件 | |
|---|---|---|
| 加工具 | ✓ | ✓ |
| 改 prompt 装配 | ✗ | ✓ |
| 拦截 turn / 工具调用 | ✗ | ✓ |
| 替换某个能力的实现 | ✗ | ✓ |
| 被别的插件 inject | ✗ | ✓ |
| 跨产品复用 | ✓ | ✗ |
| 进程隔离 | ✓ | ✗ |
值得注意的是 CLI 的处理方式：它预装了 dsh-mcp-client 供补丁层使用，但默认不启用任何 MCP server，理由写在 CLI 参考里——「每个 server 命令都是沙箱之外的可信可执行代码。」
能不能接非 DeepSeek 的模型？
能，而且树内就有现成的通道。
@deepseek-ai/dsh-llm-pi-ai 是一个基于 @earendil-works/pi-ai 的通用多 provider 适配器：一个插件实例拥有一组按路由做键的 provider profile，每个请求用 GenerateOptions.provider 选 profile、用 GenerateOptions.model 在那条路由的目录里解析模型。
它的设计里有一句很关键的话：一条 pi-ai 没有内置的路由可以被直接声明出来，于是「一个 OpenAI 兼容网关、一台自托管服务器、或者一个比已安装目录更新的 provider」变成了配置，而不是一次代码改动。
再往下一层，ctx.llm 本身就是一个 seam。要接一个协议完全不同的厂商，就是再写一个 provider——跟 Lab 4 做的事一模一样，只是接口换成了 LLM 适配器（cookbook 里有 adding-an-llm-adapter.md）。
Web UI 能换壳吗？非要用 Web 吗？
不是非要。形态由 profile 决定：
dsh --profile web—— 浏览器应用（base + web-app）dsh --profile headless "跑一下测试"—— 一次性任务，不开任何端口。README 写明：shipped headless profile 不挂 ApiProxy、Host、HTTP server、Web runtime 或浏览器客户端；成功的一次运行不往 stderr 写任何东西、不开监听端口。- ACP / JSON-RPC SDK —— 两条纯自动化入口
- 第三方终端形态 —— CLI 参考里给的例子就是
dsh plugin --profile tui add github:deepseek-harness/turtle-ui然后dsh --profile tui
换句话说，UI 是 bundle 层的一个选择，不是产品的固有形态。至于「换壳」——packages/client 有 40 个包，浏览器 UI 本身也是插件化的（M6 里动态插件能往 Slot 里注册界面就是证据），但这条路本站没有实测，深度未知。
我不用 dsh，读这个站有什么用？
本站给的答案是决策树的最后一格：学它不等于用它。
最可迁移的三样东西，都不需要你装任何东西：
- M4 的 Model Experience 契约——「模型看见什么 / 花多少 token / 对 KV cache 有什么影响」这三行，任何有 prompt 的项目都能加。
- M8 的 Agent Note 体系——路径即状态的 ADR 变体，加上「非平凡改动必须同 PR 留记录」这条硬规则。
- M8 的三级规范形态——门禁 > skill > 散文，能往上走一级就往上走。
这个站会一直更新吗？
不承诺。每一页顶部都有「最后核对于 v0.1.1-rc.2 · commit b150a55」，这个标记就是它的保质期声明——上游速度见 M7.4，你可以自己判断某一页过期了多少。
发现不一致的地方，以仓库为准。本站所有一手断言都留了源码坐标，就是为了让你能自己去核对。