Arkme 即我迁移 DSH：桌面客户端插件化案例审计

这个案例能够证明什么

Arkme（即我）公开了一个把账号、记录、聊天、Bot、社区、通话和扩展市场接入 DeepSeek Harness 的插件仓库。它展示了一种可复用的迁移方式：保留原产品的账号、数据和后端服务，把能力包装成 DSH Host Service，再同时提供给 Agent Tools、浏览器 SDK 和内置 UI。

这是一篇社区案例审计，不是效果背书。作者在 X 长文中描述了桌面客户端迁移后的团队使用体验，但 52DSH 没有取得其内部指标，也没有安装客户端或登录真实账号。本文只把公开仓库、npm 包和作者原帖能支持的事实写入正文。

项目	审计结果
插件包	@senguoyun/dsh-arkme@0.1.13
审阅 commit	5b04536139a3bde2c4cb22945988ef1ebc4a76c4
DSH peer dependency	多个包声明 ^0.1.0-rc.5
当前官方 DSH 基线	0.1.1-rc.2，本站未完成兼容实测
许可证	package.json 标记 UNLICENSED，仓库根目录没有 LICENSE
主要数据	账号、记录、聊天、关系、Bot、通话、扩展
外部依赖	Arkme 后端、对象存储及账号服务
编辑验证	仓库与 npm 源码审阅，未运行生产服务

迁移后的结构

仓库把同一组业务能力分成三种消费面：

Arkme 外部服务与用户数据
          │
          ▼
Host Service（认证、权限、幂等、错误语义）
          │
     ┌────┼─────────┐
     ▼    ▼         ▼
Agent Tools   Browser SDK   内置 UI
     │            │          │
     └──────── DSH Profile ───┘

对应源码目录包括：

目录	作用
src/services/	按账号、记录、聊天等领域实现 Host Service
src/tools/	注册 Agent 可调用的 Tools、Schema 与 grant
src/sdk/	给其他 DSH 浏览器插件使用的 SDK
src/client/	Arkme 内置 UI 与状态交互
src/extensions/	扩展安装、发布、验签和持久运行

仓库说明这些模块使用 DSH 公开扩展点，不导入 DSH 私有源码路径。这个边界有利于跟随 DSH 升级，但“使用公开 API”并不自动保证新版本兼容，仍要在每个目标版本中重新构建和验收。

这个迁移方法值得借鉴的地方

后端继续负责真实业务

账号、数据存储、权限、幂等和错误语义仍由 Arkme Host 层处理。DSH Agent 不是数据库的直接拥有者，也不应该让每个 Tool 各自实现一套认证逻辑。这比把 Token 和 HTTP 请求散落在提示词或 UI 中更容易审计。

一种能力提供三个入口

同一 Host Service 可以被 Agent Tool、浏览器 SDK 和内置 UI 调用。产品不必为每个新界面复制业务逻辑；用户界面和 Agent 工作流可以围绕统一能力合同组合。

凭据不进入浏览器侧

源码包含 macOS Keychain、Windows Credential Locker 等凭据存储路径，并把访问 Token、刷新 Token和签名 URL 保留在 Host。浏览器和 Tool 只拿最小结果或不透明引用。这是正确的方向，但仍要验证日志、异常、调试接口和插件扩展不会泄露凭据。

扩展可以继续扩展

插件还实现了面向外部插件的能力合同与市场控制。这说明 DSH 可以作为产品的插件宿主，而不仅是聊天 UI。不过扩展安装、发布和验签属于高风险供应链功能，不能只检查主插件，还要审计后续安装的每个扩展。

如何建立一个隔离的复核环境

由于包当前标记为 UNLICENSED，公开可读不代表自动获得复制、修改或商用许可。实际安装前应先向权利人确认许可。以下命令只表示仓库 README 给出的技术路径，不构成使用授权：

export DSH_HOME=/absolute/path/to/isolated-arkme-dsh-home

dsh plugin --profile web add @senguoyun/dsh-arkme@0.1.13
dsh --profile web --dump-config
dsh web

测试环境必须与日常 DSH 数据分开，并使用专门的 Arkme 测试账号。安装前检查 npm 包内容、原生依赖 sharp 的安装脚本、实际请求域名和 Profile 新增的 Bundle。

预期 --dump-config 只出现 Arkme 相关配置层。若 npm peer dependency 与当前 DSH 版本发生冲突，应停止测试，不要使用 --force 绕过。

需要重点验证的数据边界

这个插件处理的不是演示数据，而是可能包含个人通信和关系的数据。验收至少应覆盖：

1. 登录凭据是否只写入系统安全存储，并使用仅属主可读的本地状态文件。
2. Access Token 刷新失败、退出登录和账号切换后，旧 Token 是否被清理。
3. Tools 能读取哪些记录、聊天、联系人、通话和媒体。
4. 写操作是否要求明确用户意图，并执行账号作用域和权限检查。
5. 文件上传、对象存储签名 URL 和图片处理是否限制大小、类型与过期时间。
6. 外部插件能否越过 SDK 能力合同直接获得 Host 凭据或内部定位信息。
7. 日志、异常、浏览器状态和 Agent 上下文是否包含个人消息或 Token。
8. 删除、发送、评论、发布等外部副作用是否有确认、幂等和审计记录。

如果 Agent 使用远程模型，还要确认哪些聊天、记录或个人资料会进入模型上下文。Host 侧保管 Token 只能解决凭据暴露问题，不能自动解决业务数据外传问题。

作者公开结果与可验证事实要分开

作者原帖列举了“决策镜子”“对话天气”“人生剪影”“数字蒸馏和回复”等团队自建功能，并认为迁移 DSH 后用户可以自行组合需求。这些属于作者提供的应用案例和观点，仓库本身不能证明使用效果、用户规模或生产稳定性。

公开证据可以确认的是：

• Arkme 发布了 DSH 插件源码和 npm 包；
• 插件包含 Tools、SDK、UI、账号、数据与扩展市场相关实现；
• npm 0.1.13 的 peer dependency 以 DSH 0.1.0-rc.5 系列包为起点；
• 仓库在审阅时没有开放许可证；
• 作者公开了 macOS 与 Windows 客户端下载入口，但本站没有下载或运行二进制文件。

因此，合适的结论是“这是一个可研究的 DSH 产品迁移样本”，而不是“该架构已被独立证明可以减少团队或替代开发人员”。

卸载与回滚

从同一个隔离 Profile 移除插件：

export DSH_HOME=/absolute/path/to/isolated-arkme-dsh-home
dsh plugin --profile web remove @senguoyun/dsh-arkme
dsh --profile web --dump-config

配置层消失后再停止测试环境。插件卸载不会自动删除 Arkme 云端账号、聊天、记录、对象存储文件或系统凭据；必须按服务自己的退出登录、撤销授权和数据删除流程分别处理。

如果你准备把现有产品接入 DSH，先从DeepSeek Harness 架构解析和DSH 插件安装指南建立最小原型，再决定哪些能力应该成为 Tool、SDK 或 UI，避免一开始就复制整个产品。