最近整理 DeepSeek Harness 插件时，我做了一件一开始觉得没什么必要、后来发现非常重要的事情：
实际安装一遍插件。
刚开始整理插件的时候，我记录的信息主要是：
- 插件名
- GitHub
- 描述
- Star
- 更新时间
理论上这些已经足够判断一个项目是否值得尝试。
但真正开始安装后，会发现：
README 里写着能安装，和今天真的能安装，是两件不同的事。
这篇记录一下我遇到的几个典型问题，以及为什么我觉得 Agent 插件后面需要比普通插件更多的验证信息。
一、README 是文档，不是运行结果
一个典型插件 README 通常会给出：
some-plugin-install-command
看起来很简单。
但实际执行时，可能遇到：
- 依赖下载失败
- 版本不兼容
- build script 被阻止
- 环境变量缺失
- 插件没有正常注册
- README 使用的是旧版命令
这些问题不一定说明插件有 Bug。
有些只是因为：
插件发布以后，Harness、包管理器或者依赖环境发生了变化。
因此“有安装命令”只能证明作者提供了安装路径。
不能证明：
当前环境下安装路径仍然成立。
二、Agent 插件还有一个额外问题：权限
普通库安装以后，通常由业务代码决定它什么时候运行。
Agent 插件的能力边界更宽。
很多插件可能直接拥有：
Filesystem
Shell
Network
Git
API Token
Browser
这意味着用户在执行安装命令之前，其实需要知道两件事：
第一：
它能做什么？
第二：
它为了完成这些功能，需要接触什么？
例如一个 Git 自动化插件：
方案 A 只封装几个固定 Git 操作。
方案 B 直接给 Agent Shell 权限。
两者在 README 中都可能写成：
Git automation
但风险边界明显不同。
所以我觉得 Agent 插件的信息页里，权限应该成为和功能描述一样重要的字段。
三、我后来增加了一个简单的安装验证流程
我目前采用的方式并不复杂。
首先准备一个相对干净的 profile，然后执行插件提供的安装方式。
主要记录五件事：
1. 安装命令是否能够执行
先解决最基础的问题。
2. 依赖是否完整
有没有需要手动补的 package 或 runtime。
3. 是否出现额外脚本
例如 build script、postinstall 等。
4. Harness 是否识别插件
安装完成不代表注册完成。
5. 是否需要额外人工操作
例如：
- 批准脚本
- 配置 Token
- 修改配置文件
- 重启
- 手工指定路径
最后得到的结果可能只是：
Installed cleanly
或者：
Installed, manual approval required
但我发现，这一句信息对真正准备安装插件的人非常有用。
四、安装成功也不等于安全
这里还需要区分一个概念。
安装验证只能说明：
我按照当前步骤运行后，它能不能正常进入 Harness。
它并不能证明：
- 插件没有安全问题
- 所有功能都正常
- 不存在供应链风险
- 不会执行危险操作
所以我觉得比较合理的插件信息应该分层：
基础元数据
- 作者
- GitHub
- Star
- 更新时间
- License
能力信息
- 插件做什么
- 属于什么分类
- 适合什么场景
权限信息
- Shell
- Filesystem
- Network
- Token
安装信息
- 安装命令
- 依赖
- 是否完成实际验证
这四层结合起来，比一个简单排行榜更有意义。
五、当插件达到几千个以后，数据质量比数量重要
目前我整理到的 DeepSeek Harness 相关插件已经超过 2500 个。
一开始很容易把目标变成：
收录更多。
但真正处理这些数据后，会发现问题其实变成了：
怎么减少无效信息？
例如：
- 重复项目
- 长期不维护
- README 缺失
- 没有独立 package
- 只是 Demo
- 大型仓库里的子目录
- 安装方式失效
所以现在我反而觉得：
插件 Marketplace 的核心不应该只是 Discovery。
它还应该承担一定程度的：
Verification。
六、把这些信息集中起来
因为自己一直在 GitHub topic、registry 和 repo 之间查，我把整理结果做成了一个可搜索页面：
DSH Marketplace
目前主要还是一个持续完善中的索引。
除了 2500+ 插件和分类搜索之外，我现在更想继续补的是：
- 安装方式
- License
- 权限
- 维护状态
- 实际安装验证
如果已经知道 repo，也做了一个简单 CLI：
npx dshmarketplace-cli add owner/repo
但相比“再多收录几千个插件”，我现在更想优先把已有插件的有效信息做完整。
总结
Agent 插件和传统插件最大的区别之一，是它往往拥有更大的执行能力。
这意味着生态发展到一定阶段后，仅仅解决：
哪里有插件？
是不够的。
还需要逐渐回答：
它现在还能装吗？
它需要什么权限？
它最近还维护吗？
安装过程中发生了什么？
如果未来 Agent 真正进入大量生产工作流，我觉得插件验证、权限透明和供应链信息，最终都会成为 Marketplace 很重要的一部分。
