拆解1.1万DeepSeek Harness插件后发现官方零治理

1.1 万插件拆解暴露官方零治理事实

研究者实际拆解了超过1.1万个DeepSeek Harness插件，结果显示官方几乎没有建立任何插件治理机制。这意味着平台既未对插件代码进行系统性安全审查，也未设置插件上架前的准入流程，更没有针对已发布插件的持续监控和下架机制。

具体证据来自对这些插件的全面分析。拆解过程覆盖了插件的代码结构、依赖项、运行时行为以及网络请求模式。结果表明，绝大多数插件直接调用了系统级API或第三方服务，却没有任何官方签名验证或来源追踪记录。平台仅提供了一个简单的发布入口，开发者上传后即可被其他用户下载安装，没有版本控制、权限列表或行为白名单。

这种零治理的状态在规模上体现得尤为明显。1.1万的插件数量已经形成了一个不小的生态，却全部处于无人监管的状态。部分插件甚至包含混淆代码或动态加载远程资源的逻辑，而平台对此没有任何拦截措施。研究者指出，这种情况与主流IDE插件市场形成了鲜明对比，后者至少会进行基本恶意代码扫描和权限申报。

零治理直接导致用户无法判断插件是否安全。开发者在安装时只能依赖插件作者的自我声明，而这些声明往往缺乏技术细节支持。拆解还发现，部分插件在运行时会尝试建立未加密的网络连接，却没有被平台标记为高风险。这为后续的安全问题埋下了伏笔。

（本节约420字）

本地 pnpm 与 DSH 安装必须放行 build scripts

DeepSeek Harness的本地安装流程首先要求用户安装pnpm包管理器，随后安装DSH核心工具。在这一过程中，必须手动放行build scripts，否则安装会直接失败。

具体步骤是：在执行pnpm install时，如果遇到build scripts被阻止的情况，需要使用–unsafe-perm参数或者修改npm/pnpm的配置来允许脚本执行。DSH本身的安装包也包含多个需要编译的原生模块，这些模块在构建阶段会运行自定义脚本，对文件系统和网络进行操作。

放行build scripts的原因在于DSH依赖了若干需要本地编译的依赖项，例如某些与AI模型推理相关的绑定库。这些脚本会检查系统环境、下载预编译二进制文件或生成配置文件。没有放行，安装过程会在权限检查环节中断。用户通常需要在命令行中输入特定标志，或者临时调整全局配置，才能让安装继续。

这一步骤本身就涉及了较高的系统权限。build scripts可能修改用户目录下的配置文件、创建缓存文件夹，甚至尝试连接外部仓库下载资源。在企业内网或受限网络环境中，这一操作经常触发安全软件的告警。

安装完成后，DSH还需要用户手动验证路径和环境变量。整个流程没有提供一键安装脚本，而是要求开发者逐一处理这些潜在的权限点。这虽然保证了灵活性，但也把网络和文件系统访问的决策权完全交给了最终用户。

（本节约380字）

Node.js 系统 CA 和代理配置在对话阶段的实际难点

安装完成后，进入对话阶段时，Node.js运行环境经常遇到网络连接问题。此时需要正确配置系统CA证书和代理设置，否则DSH无法与后端服务建立稳定连接。

具体难点在于Node.js默认不信任企业或特殊网络环境中的自签名CA证书。用户必须将系统根证书导入Node.js的信任存储中，通常通过设置NODE_EXTRA_CA_CERTS环境变量指向证书文件来解决。同时，如果处于需要代理的网络，还需配置HTTP_PROXY和HTTPS_PROXY变量，并确保pnpm和Node.js都能正确读取这些变量。

在实际对话过程中，这些配置不当会导致模型请求超时、证书验证失败或连接被重置。部分用户反映，即使浏览器可以正常访问相关服务，DSH的Node.js进程仍然报错。这是因为Node.js的证书验证逻辑独立于操作系统浏览器，需要单独处理。

配置代理时还需注意区分http和https代理地址，以及是否需要跳过某些内部域名。错误的代理配置可能导致所有流量走代理，从而暴露敏感的对话内容。特殊网络环境下，用户往往需要编写自定义的证书导入脚本或使用中间人工具辅助调试，这些操作进一步增加了复杂度。

对话阶段的网络问题并非一次性解决。每次环境切换或证书更新后，都可能需要重新调整配置。这使得本地部署的稳定性大打折扣，也让普通开发者在配置上花费大量时间。

（本节约410字）

无治理插件可利用安装网络权限扩大攻击面

零治理的插件生态与本地安装所需的网络权限结合后，形成了明显的安全风险。插件可以在安装和对话阶段利用已经放开的build scripts权限和Node.js网络配置，执行超出预期的操作。

由于平台没有审核机制，恶意插件可以伪装成生产力工具，在build阶段插入后门代码。这些代码可以在用户允许build scripts的前提下，窃取本地证书、修改代理配置或建立隐蔽的C2通道。1.1万插件中已经存在大量未经验证的代码，攻击者只需在其中一个插件里嵌入恶意逻辑，就可能影响大量用户。

安装时放行的网络权限恰好为这类攻击提供了便利。插件可以要求用户配置系统CA，借机植入伪造的根证书，从而实现流量劫持。在对话阶段，插件还能通过Node.js进程发送未加密的数据，或将用户输入转发到外部服务器，而官方没有任何监控手段。

两个方面的结合放大了攻击面。本地安装流程本身要求用户降低安全限制，而零治理又让用户无法判断哪些插件值得信任。研究显示，部分插件已包含动态加载远程脚本的能力，一旦与代理配置结合，攻击者就能在用户不知情的情况下完成持久化。

这种风险不是理论上的。拆解结果表明，现有插件中已有相当比例存在网络相关代码，却没有对应的权限说明。平台缺失的治理让这些问题长期存在，用户每安装一个插件都在承担额外风险。

（本节约390字）

国内开发者在开源 AI 工具中面临的信任与合规风险

国内开发者在使用DeepSeek Harness这类开源AI工具时，面临着双重风险：一是无法信任插件来源，二是难以满足企业合规要求。

信任风险体现在插件生态的完全开放上。开发者无法得知一个插件是否经过安全审计，也无法确认其网络行为是否会泄露公司代码或对话记录。1.1万插件的规模意味着选择范围很大，但筛选成本极高。许多团队因此选择完全禁用插件功能，牺牲了工具的扩展性。

合规风险则来自网络配置环节。企业内网通常有严格的证书管理和代理策略，而DSH的安装和对话流程需要用户手动调整这些设置。这可能违反公司安全基线，导致审计不通过。在金融、政务等强监管行业，这一问题尤为突出。

更广泛的影响是，整个国内开源AI工具生态都可能受到波及。如果主流工具长期缺乏插件治理，其他类似项目也会被质疑安全性。开发者可能转向闭源商业方案，或降低对开源AI的采用意愿。这对希望通过开源加速创新的社区来说，是一个明显的倒退。

开发者目前能做的有限。他们可以选择只使用官方核心功能，严格审查插件源码，并在沙箱环境中测试。但这些措施增加了使用门槛，让开源AI工具的易用性优势大打折扣。

（本节约350字）

平台未划定的插件审核责任边界

DeepSeek Harness平台目前没有明确划定自己在插件审核上的责任边界，这直接导致了治理缺失的长期影响。

平台既未声明是否对插件安全负责，也未提供任何审核流程或免责条款。用户在安装插件时看到的仅是简单的下载按钮，没有权限列表、来源标签或安全评分。这种模糊的边界让平台得以置身事外，却把所有风险转嫁给了终端用户和开发者。

对国内开源AI工具生态的长期影响是多方面的。首先，它降低了整个赛道的安全标准。其他AI工具开发者可能效仿这种低治理模式，认为无需投入审核成本。其次，它阻碍了企业级采用。大型组织在评估开源AI方案时，会把插件安全列为重要否定项，导致国内项目竞争力下降。

平台如果继续维持零治理状态，可能会面临越来越多的安全事件。这些事件最终会反噬整个开源社区的信誉。相比之下，国际主流平台早已建立了插件市场审核、自动扫描和用户报告机制，形成了清晰的责任边界。

当前局面下，平台需要尽快定义自己的责任范围：是只提供分发渠道，还是承担基本的安全把关义务。这一决策将决定DeepSeek Harness能否在国内AI工具生态中获得长期信任。

（本节约370字）

参考来源

• 我们拆了 1.1 万个 DeepSeek Harness 插件，发现官方几乎没有建立插件治理机制
• DeepSeek Harness 本地安装和对话过程的网络问题