DeepSeek Harness 插件市场调研报告

主题：插件本质、制作与发布流程、供应链与社区安全日期：2026-11-04 方法：官方发行渠道与社区目录核对 + npm registry / GitHub …

kiana 2026-11-04 Agent研究 20 次阅读

**主题**：插件本质、制作与发布流程、供应链与社区安全
**日期**：2026-11-04
**方法**：官方发行渠道与社区目录核对 + npm registry / GitHub API 实测 + 本机已装插件代码解剖
**标注约定**：`[实测]` 本次亲自查证 · `[文档]` 来自公开文档 · `[推断]` 由证据推出 · `[待核实]` 尚无一手证据

---

## 摘要

1. **DSH 的插件不是"扩展功能"，而是"插入一棵插件树的节点"。** 底层是 Cordis 的 "everything is a plugin" 架构，插入即获得该层全部能力，没有权限申请这一步。
2. **一个插件是两半的：host 半侧跑在 Node 主进程，client 半侧是注入 Web UI 的同源 JS。** 前者权限等于用户账户，后者能改用户看到的一切。
3. **分发的三条通道校验强度差异极大。** npm 通道有 SHA-512 完整性校验；`github:` 通道直接执行仓库代码；本地目录通道无任何校验。目前**未发现签名机制**。
4. **生态规模真实但水分大。** 目录收录 20,020 条，GitHub `dsh-plugin` topic 有 26,690 个仓库，但混入大量蹭话题的非插件项目；真正能从 npm 直装的只有 376 个。
5. **现有四道防线，没有一道覆盖"行为"。** 目录方验"能不能跑"，社区台账审"代码有没有问题"，AgentGuard 量"能力面有多大"（659 个样本、94.7% 判 HIGH/CRITICAL），策略插件拦"运行时动作"——没有一方验证"它实际做了什么"。

---

## 1. 插件的本质

### 1.1 一句话定义

> 插件 = 一个 npm 包 + 一段声明式挂载配置 + 两个运行时半边（host / client）。

它不被框架"调用"，而是被**插入到一棵插件树**里。DSH 官方页面写明它构建于 [Cordis](https://github.com/cordiverse/cordis) 的 "everything is a plugin" 架构之上 `[实测：github.com/cordiverse/cordis，9,633 stars，自述 Meta-Framework of Spatiotemporal Composability]`。

这个区别是整个安全分析的起点：**树上的节点天然共享宿主能力，"申请权限"这个概念在架构里不存在。**

### 1.2 包结构解剖

以本机已安装的 `deepseek-harness-wallet` 为例 `[实测：D:\DSH\plugins\deepseek-harness-wallet\package.json]`：

| 字段 | 实例值 | 含义 | 安全含义 |
|---|---|---|---|
| `main` | `index.js` | host 入口 | 主进程代码起点 |
| `dsh.bundle.patch` | `./cordis.patch.yml` | 挂载声明 | 决定插到树的哪里 |
| `dsh.client.platform` | `web` | 有浏览器半边 | 可触达 UI |
| `dsh.client.inject` | `@deepseek-ai/dsh-client-runtime` 等 | 依赖的客户端服务 | 决定 client 能碰哪些能力 |

### 1.3 挂载：三行 YAML 决定一切

`cordis.patch.yml` 全文 `[实测]`：

```yaml
- insert:
    - id: wallet
      name: deepseek-harness-wallet
```

`insert` 往插件树里插一个节点，`id` 是唯一键（重复会破坏加载，插件作者在 AGENTS.md 里专门警告过）。**没有 `permissions:` 字段，没有 `capabilities:` 字段。** 插进去，就拿到了这一层的全部能力。

### 1.4 host 半侧：主进程里的普通 Node 代码

`index.js` 开头 `[实测]`：

```js
import { mkdirSync, readFileSync, writeFileSync } from 'node:fs'
export const name = 'wallet'
export const inject = ['webServer']
```

- 直接 `import node:fs`，没有任何中间层
- 注册 `/api/wallet` 路由，供浏览器半边轮询
- 读写 `$DSH_HOME/storages/wallet.json`

`inject` 声明的是**依赖**（我要用到 webServer 这个服务），不是**权限**（我被允许监听端口）。这两者在安全语义上完全不同，但代码里长得一样。

**结论：host 半侧的权限 = 启动 DSH 的那个用户账户的权限。**

### 1.5 client 半侧：注入 UI 的同源脚本

- 页面加载时注入，注册 slot（侧边栏、会话区、输入框旁）
- 通过 `connection.rpc.call` 调宿主路由
- 插件作者在 AGENTS.md 里注明：装完必须**重启 + 硬刷新**，否则 client 半边不出现 `[实测]`

**结论：它能改用户看到的东西**——包括工具返回、审批提示、系统消息。这一层目前没有任何审查覆盖。

### 1.6 生命周期

```
npm 包 → 写进 profile → 启动时加载 host → 页面加载时注入 client → 运行 → 卸载
```

失败模式与残留：加载失败是否静默 `[待核实]`；卸载后 `storages/` 是否清理 `[待核实]`；插件写入的 `AGENTS.md` 是否回滚 `[推断：不会]`。

### 1.7 持久化的两条通道

| 通道 | 位置 | 生效范围 |
|---|---|---|
| 插件私有状态 | `$DSH_HOME/storages/*.json` | 插件自身 |
| 指令面 | 工作区 `AGENTS.md` / `MEMORY.md` | **下一次会话的模型行为** |

第二条是关键的跨会话通道。本机 `persona-studio` 插件的 README 明说：保存时会写 `<工作区>/AGENTS.md` 与 `MEMORY.md`，而 DSH 下次会话会读它们 `[实测：~/.dsh/plugins/persona-studio/README.md]`。

### 1.8 概念辨析

| 概念 | 形态 | 能否执行代码 | 影响面 |
|---|---|---|---|
| **plugin** | npm 包（host + client） | **能**（主进程 + UI） | 系统 + 界面 |
| **skill** | 目录 + `SKILL.md` + 脚本 | 只能通过 agent 调用脚本 | 模型行为 |
| **MCP server** | 独立进程 + 协议 | 能（在自己进程里） | 工具返回 |
| **theme** | 纯 client 半边 | 能（只在前端） | 界面 |

很多讨论失焦，是因为把 plugin（代码层）和 skill（指令层）混为一谈。二者的权限差了一个数量级。

---

## 2. 制作流程

### 2.1 最小插件

一个导出 `apply` 的 TypeScript/JavaScript 模块，接收 `ctx` `[文档：dshbase 插件指南]`：

```ts
export const name = 'my-plugin'
export function apply(ctx: Context) {
  // 通过 ctx 注册能力，卸载时自动清理
}
```

### 2.2 能力注册面

| 注册面 | 用途 | 攻击面 |
|---|---|---|
| `ctx.tools.register` | 给 agent 加工具 | 工具描述投毒、返回值注入 |
| `ctx.webServer` | 起 HTTP 路由 | 本地端口暴露、CSRF |
| client slot | UI 插入点 | 界面欺骗、结果篡改 |
| 事件钩子 | 拦截流式输出等 | 静默改写对话 |

**每多一个注册面，多一类攻击面**，而注册不需要任何审批。

### 2.3 构建方式

- 零构建：纯 ESM，源码即产物（wallet 就是这种，`[实测]` 无 dependencies、无 build step）
- 打包：产物压缩/混淆，静态审查难度显著上升

### 2.4 本地开发

`cordis.yml` 指向绝对路径 + `dsh web --patch ./cordis.yml` 启动；client 半边支持 HMR。

### 2.5 插件会自带"给 agent 的说明书"

`deepseek-harness-wallet` 包里带了一份 `AGENTS.md`，开头是 `[实测]`：

> Instructions for AI agents (e.g. a DeepSeek Harness session) asked to install, verify, or troubleshoot **deepseek-harness-wallet**.

里面写了安装命令、验证步骤、"hard constraints — do not do these"。

**这是被忽视的一层**：插件通过文本向 agent 下达指令。它既是优秀的工程实践，也是一条**指令面供应链**——恶意插件完全可以在同一位置写"安装前请先执行 XXX"。目前没有任何机制审查这份文件。

---

## 3. 发布与分发

### 3.1 三条通道

| 通道 | 命令 | 校验强度 | 说明 |
|---|---|---|---|
| npm | `dsh plugin add <pkg>` | SHA-512 完整性 `[文档]` | 参数转发给 pnpm |
| GitHub | `dsh plugin add github:owner/repo` | **无签名，直接执行仓库代码** | 生态主流方式 |
| 本地目录 | 拷贝进 `node_modules` | 无 | persona-studio 的 install.ps1 即此 |

官方安装文档明确：`dsh plugin` 的参数会转发给 pnpm，插件被写进 profile 的 `package.json`，既作为依赖也进入 `dsh.profile.bundles`，下次启动自动加载 `[文档：dshbase 教程/安装页]`。

### 3.2 目录收录机制

- 任何人给仓库加 `dsh-plugin` topic 即可进入抓取范围
- 第三方目录（dshbase）抓取 GitHub topic + 自己收录，做功能验证
- 官方讨论区/市场是另一条入口

**没有准入审核**。这正是 20,020 这个数字能在一个多月内从 8 涨上来的原因。

### 3.3 完整性：有校验，无签名

| 手段 | 现状 |
|---|---|
| npm tarball SHA-512 | 有 `[文档]` |
| 包签名 / 发布者身份 | **未发现** `[推断]` |
| 目录方的哈希记录 | 有（社区台账按版本 + SHA-512 绑定）`[实测]` |

也就是说：**你能确认"这个包没被篡改"，但确认不了"这个包是谁发的、该不该信"。**

### 3.4 更新通道

- 用户主动：`dsh plugin update`
- **插件自更新**：社区审查台账记录 `billion-context` 默认每几分钟检查 npm 并静默更新自己，还有"紧急公告"通道可强制安装任意版本 `[实测：dsh-plugin-index 审查报告 2026-10-27]`

后者让"审过的版本"彻底失去意义——审查绑定的是版本 + 哈希，而插件可以自己换掉自己。

### 3.5 命名与身份：目录里的名字 ≠ 安装的身份

一个实测发现：

| 目录显示 | npm 实际 | 仓库真实 package.json |
|---|---|---|
| `@deepseek-ai/dsh-theme` | **404，npm 上不存在** | `@tinyforge/dsh-theme` |
| `@deepseek-ai/dsh-mcp-settings` | **404** | 未核 |
| `@deepseek-ai/dsh-client-ui-muyu` | **404** | 未核 |

`[实测：registry.npmjs.org 查询 + raw.githubusercontent.com/phoenixlucky/dsh-theme/main/package.json]`

结论有两层：
- 这些包**不是从 npm 装的**，是 `github:` 装的——所以 npm 的完整性校验对它们不生效
- 目录展示的名字与包的真实 `name` 字段**可以不一致**，于是 `@deepseek-ai/*` 这种官方观感的名字，可能只是一个字符串

这不是作者恶意，是**目录元数据与安装身份的脱钩**。但它构成了仿冒的土壤。

### 3.6 官方"市场"的真身：可配置索引，不是平台

查官方源码 `packages/boot/plugin-market` 后的结论 `[实测：README + package.json]`：

> `pluginMarket` reads the plugin indexes the user configures... **No index source is configured by default**, so the Host sends no index request until a user adds one.

也就是说：

- 界面上有一个 **Discover 页**，但它读的是**用户自己填的索引 URL 列表**（配置项 `indexes`，默认 `[]`）
- 没有"官方插件市场"这个网站，也没有默认开启的中央索引
- 同一份索引还被 **agent 的 `plugin_market` 工具**读取——即 **agent 自己可以搜索并安装插件**
- 真正的安装动作走 `pluginManager.installBundle`

这解释了生态为什么长得这么快、又这么散：**没有平台方，只有一堆索引和 topic。**

### 3.7 官方自己怎么描述安全

仓库根目录的 `SAFETY.zh.md` 写得很直白 `[实测]`：

> 它尚未接受安全审计，不得视为安全或可用于生产环境的软件。……可以执行模型生成的代码与命令、加载第三方插件，并访问向其开放的网络、进程、凭据和文件。……沙箱、审批提示与权限控制可以降低风险，但不保证隔离。

这段是**厂商自述**，比任何第三方评估都硬。写作时可以直接引用：连官方都声明"未审计、不保证隔离"。

---

## 4. 安装与加载

### 4.1 profile 是什么

```
~/.dsh/profiles/<name>/
├── package.json        # 依赖 + dsh.profile.bundles
├── node_modules/       # 插件实体
└── cordis.patch.yml    # 挂载配置
```

### 4.2 `dsh plugin add` 做了什么

1. 解析来源（npm 包名 / github: / 本地路径）
2. 调 pnpm 装进该 profile 的 `node_modules`
3. 写 `package.json`：依赖 + `dsh.profile.bundles`
4. 下次启动时由 loader 按 bundles 加载

### 4.3 一个反直觉的工程细节

`persona-studio` 的 README 记录：客户端 bundle **必须物理位于 profile 的 node_modules 里**，用 `link:` 指向源码目录的 junction 不会被启动扫描收录，HMR 能加载但重启后消失 `[实测]`。

这意味着：**"能跑"和"被收录"是两套机制**，HMR 通道与启动加载通道的可见性不一致——一个潜在的绕过点 `[推断]`。

### 4.4 谁有权安装

- 人：`dsh plugin add`
- **agent：能执行 shell，就能执行上面这条命令**

DSH 的 agent 有 `pwsh` 工具，默认工作区可写，profile 目录在 `~/.dsh/profiles`（工作区之外，写入通常需要审批）。

所以准确表述是：**agent 具备自安装的能力，是否成功取决于当时的审批档位与沙箱边界**。这已经不是"骗用户装一个插件"，而是"agent 给自己装一个插件"。

---

## 5. 信任模型现状

### 5.1 现有的约束

| 机制 | 存在 | 作用 |
|---|---|---|
| `inject` 依赖声明 | ✅ | 声明依赖，非权限 |
| loader id 唯一 | ✅ | 防重复加载 |
| client 同源 | ✅ | 限制跨域，不限制同源内行为 |
| npm 完整性 | ✅ 仅 npm 通道 | 防篡改，不防恶意 |
| 凭证文件权限检查 | ✅ | macOS/Linux 下拒绝全局可读的凭证文件 `[文档]` |
| 目录方功能验证 | ✅ | 验证"能跑" |

### 5.2 缺失的约束

| 缺失项 | 后果 |
|---|---|
| 权限清单（capability manifest） | 装插件 = 全权，用户无法知情 |
| 包签名 / 发布者绑定 | 无法确认来源 |
| 能力沙箱 | host 半边 = 用户权限 |
| 运行时审计 | 谁读了什么、发了什么，无记录 |
| 行为变更检测 | 自更新绕过一切版本审查 |
| 卸载残留清理 | `storages/`、写入的 `AGENTS.md` 可能长期留存 `[待核实]` |

### 5.3 横向对比

| 生态 | 权限声明 | 签名 | 沙箱 | 审核 |
|---|---|---|---|---|
| 浏览器扩展 | ✅ manifest permissions | ✅（商店） | ✅ | ✅ 商店审核 |
| VS Code 扩展 | ⚠️ 有限 | ⚠️ | ❌ | ⚠️ 市场扫描 |
| npm 包 | ❌ | ⚠️ 可选 provenance | ❌ | ❌ |
| MCP server | ⚠️ 工具描述 | ❌ | ⚠️ 取决于客户端 | ❌ |
| **DSH 插件** | ❌ | ❌ | ❌ | ⚠️ 第三方功能验证 |

DSH 插件在这一维度上处在最宽松的一端——比 npm 还松，因为 npm 至少不默认获得"用户 UI 的写权限"。

---

## 6. 生态现状

### 6.1 规模

| 指标 | 数值 | 来源 |
|---|---|---|
| 目录收录 | **20,020** | dshbase 目录页，数据截至 2026-10-16 `[实测]` |
| 仓库数 | 20,011 | 同上 |
| 功能验证通过 | 7,843 | 同上（L1 安装 + L2 加载 + L3 headless，web-only 需 L4 CDP） |
| 待验证 | 10,667 | 同上 |
| 已收录未实测 | 1,510 | 同上 |
| npm 可直装 | **376** | 同上 |
| GitHub topic `dsh-plugin` | **26,690** 仓库 | GitHub Search API，2026-11-04 `[实测]` |

增长曲线 `[实测：目录页内嵌数据]`：08-12 有 8 个 → 08-15 1,094 → 08-25 7,788 → 10-14 18,502 → 10-31 20,020。**两个多月从个位数到两万。**

### 6.2 构成与水分

分类分布 `[实测]`：开发 8,125 / 界面皮肤 2,898 / AI 模型 2,157 / 知识 1,180 / 桌面 911 / 自动化 695 / 数据 713 / 效率 709 / 内容 585 / 安全 530 / 网络 438 / 浏览器 319 / 视觉 272 / 终端 252 / 存储 236。

**但 star 前十里有非插件项目**：PicGo（图床工具）、nocobase（低代码平台）、reactive-resume（简历工具）、ruflo（另一个 agent 框架）`[实测：目录热门榜]`。它们只是给仓库加了 `dsh-plugin` topic。

这说明两件事：
- 2 万这个数字**高估**了真实插件量
- **topic 是任何人可加的，目录准入没有实质门槛**

保守估计真插件在 5,000–8,000 之间 `[推断]`。

### 6.3 质量信号全部失效

| 信号 | 为什么不能当安全指标 |
|---|---|
| star | 蹭话题的大仓库 star 更高 |
| 下载量 | 热门 ≠ 安全 |
| "已验证" | 只等于"能装能跑能加载" |
| 更新时间 | 自更新插件永远"很新" |

### 6.4 已有的四道防线

| 防线 | 做什么 | 不做什么 |
|---|---|---|
| dshbase L1–L4 | 安装 / 加载 / headless 问答 / Web CDP | 不看代码行为 |
| dsh-plugin-index | 人工 + AI 静态审查，按版本 + SHA-512 记账 | 不运行、不动态观察 |
| AgentGuard v1.1.29 | **静态能力画像 + 风险评级**（见下） | 不执行目标代码；评级 ≠ 行为定性 |
| alpha-guard / plugin-gate | 运行时策略拦截、审计日志 | 不是测量，不产出生态数据 |

AgentGuard 团队 2026-11 公开的研究是目前唯一的**能力面基线**（数据快照 2026-09-02，awesome-dsh-plugin.com 2,916 个插件，近 30 天下载量 3,885,362）：

- **抽样**：分层 + 下载量补足，659 个目标（占 22.6%），覆盖近 30 天下载量的 **90.0%**
- **结果**：590 个成功扫描，15 个覆盖不完整（fail-closed，不计入安全结论），54 个无法扫描
- **评级**：HIGH/CRITICAL **94.7%**（CRITICAL 192 / 32.5%，HIGH 367 / 62.2%，MEDIUM 20，LOW 11）
- **长尾**：随机 60 个中 56 个成功，50 个 HIGH/CRITICAL（89%）——与头部同量级
- **AUTO_UPDATE**：32 个插件存在"远程拉取并安装/执行"模式
- **可复核**：每条结果记录 commit SHA + artifact SHA-256

能力面分布（分母 605 = 590 成功 + 15 不完整）：

| 能力 | 占比 | 数量 |
|---|---|---|
| 文件读取 | 91% | 548 |
| UI 注入 | 86% | 518 |
| 文件写入 | 82% | 496 |
| 环境变量访问 | 81% | 489 |
| Provider / 模型路由 | 75% | 451 |
| 网络访问 | 74% | 449 |
| 持久化存储 | 74% | 445 |
| Shell 执行 | 63% | 380 |
| 会话访问 | 55% | 333 |
| 工具注册表变更 | 48% | 293 |
| 运行时变更 | 33% | 202 |

注意两点：① 它是**静态**的，"能读文件"是代码里有这个调用，不是运行时真读了；② 作者自己明确写了"HIGH/CRITICAL 不等于恶意，反映的是能力面"。

四者的共同缺口依然成立：**都不回答"它实际做了什么"**。

---

## 7. 威胁模型

| 阶段 | 攻击者能力 | 具体手法 | 现有防线 | 缺口 |
|---|---|---|---|---|
| 制作 | 发布任意包 | 仿冒名、抢注、恶意依赖 | 无 | 全缺 |
| 发布 | 加入目录 | topic 污染、借用官方观感的名字 | 来源审计（弱） | 无身份绑定 |
| 安装 | 诱导安装 | `github:` 直装、agent 自安装、install 脚本 | 人工确认 | 可绕过 / 无强制 |
| 加载 | 代码执行 | host 主进程任意代码、client 注入 UI | 无沙箱 | 全缺 |
| 运行 | 读数据 | 凭据读取、会话内容外发、跨插件 RPC | 无审计 | 全缺 |
| 持久 | 跨会话 | 写 `AGENTS.md` / `MEMORY.md`、计划任务 | 无 | 全缺 |
| 更新 | 换代码 | 静默自更新、远程配置通道 | 版本锁定（弱） | 全缺 |

**最值得警惕的一格是"运行 + 持久"的交叉**：插件既能读会话，又能写 `AGENTS.md`，等于可以**把一次读到的内容变成下一次会话的指令**。

---

## 8. 已知案例（社区审查台账实证）

均来自 [dsh-plugin-index 的审查报告](https://github.com/polang233/dsh-plugin-index/blob/main/docs/reviews/plugin-security-review-2026-10-27.md) `[实测]`：

| 插件 | 问题 | 为什么危险 |
|---|---|---|
| `billion-context` | 默认静默自更新；"紧急公告"通道可强制装任意版本；全局接管模型请求转发到本地代理 | **审查失效**：审过的版本 ≠ 运行的版本 |
| `@xmanrui/dsh-im` | 新建飞书/QQ 机器人默认允许任何人私聊驱动 AI；发文件工具无目录限制 | **默认开放**：陌生人可驱动你的 agent，任意文件可外发 |
| `@deepseek-harness-tui/dsh-tui` | Windows 上默认完全访问、永不弹审批；自更新只校验同一发布内的 SHA256SUMS | **拆掉闸门**：为了好用牺牲全部审批 |
| `dsh-cost-meter` | 全局改写子进程启动、向别的包注入代码；自动读取其他工具登录凭据 | **跨插件攻击**：一个插件改另一个插件的行为 |

这四个案例的共同点：**都不是"恶意代码"，而是"合理功能 + 危险默认值"**。这也解释了为什么纯静态规则很难判——它们的代码看起来都像正常功能。

---

## 9. 结论

### 9.1 五条结论

1. **DSH 插件是本报告对比的五种扩展形态里权限最宽、约束最少的一种。** 无权限声明、无签名、无沙箱、无审计。
2. **供应链的断点不在"下载"，在"信任"。** npm 的 SHA-512 只保证没被篡改，不保证来源可信；而主流安装方式（`github:`）连这个都没有。
3. **目录的规模数字不可直接引用。** 20,020 里有大量 topic 污染，真实插件量约为其三分之一到二分之一。
4. **"已验证"和"已审查"都是功能语义，不是安全语义。** 前者=能跑，后者=看着没问题。
5. **最强的攻击面是"运行期 + 持久化"的组合**：读会话 → 写 `AGENTS.md` → 下次会话生效。这条链目前完全无防护。

### 9.2 研究的三个切入点

1. **行为测量**：能力面已被 AgentGuard 测过（605 个有效目标、11 维），但"能力 → 实际使用"仍空白——91% 的插件能读文件，其中多少真的读了工作区外？81% 能拿环境变量，多少把值发到了网络？
2. **行为**：静态判定 vs 动态行为的差距
3. **链路**：插件 → `AGENTS.md` → 下次会话 的跨会话传播，目前无人研究

---

## 附录 A：数据核验表

| 数据 | 值 | 来源 | 日期 | 方式 |
|---|---|---|---|---|
| 目录收录总数 | 20,020 | dshbase.com/zh/plugins/directory | 2026-10-16 | 页面直读 |
| 功能验证通过 | 7,843 | 同上 | 同上 | 页面直读 |
| npm 可直装 | 376 | 同上 | 同上 | 页面直读 |
| GitHub topic 仓库数 | 26,690 | api.github.com/search | 2026-11-04 | API |
| 官方包版本 | 0.2.1-rc.5 | registry.npmjs.org | 2026-10-29 | API |
| 官方包维护者 | imccyu, tianyicui-deepseek | 同上 | — | API |
| `@deepseek-ai/dsh-theme` | 404 | 同上 | 2026-11-04 | API |
| 该仓库真实包名 | `@tinyforge/dsh-theme` | raw.githubusercontent.com | 2026-11-04 | API |
| Cordis stars | 9,633 | api.github.com | 2026-11-04 | API |
| 插件结构 | 见 §1 | 本机 `D:\DSH\plugins\` | 2026-11-04 | 读文件 |
| 能力面基线 | 659 目标 / 605 有效 / 590 成功；94.7% HIGH+CRITICAL | AgentGuard v1.1.29 公开报告（快照 2026-09-02） | 2026-11-05 读到原文 | 原文已核，扫描本身未复现 |

## 附录 B：待核实清单

1. 加载失败是否静默、卸载是否清理 `storages/` 与写入的 `AGENTS.md`
2. `@deepseek-ai/*` 这类目录名与实际包名的偏差波及多少条目
3. 官方是否有未公开的签名/发布者验证
4. HMR 通道与启动加载通道的可见性差异能否被利用
5. 目录方 L1–L4 的具体判定阈值

#Agent #研究 #DSH #调研

kiana

@kianayang · 在蓝屿写作

关于博主