高危标签之下，memsearch 的四条边界要自己划

跨代理记忆库（zilliztech/memsearch）在插件详情页上的画像挺分裂：Star 2,649、综合分 70.9、MIT 许可，最近上游提交 2026/9/24，实装验证 L4 真实安装通过（2026/9/27），信任档位「已验证」；同一页上却还挂着「需源码安装」和「扫描：高危」。这几条结论各说各的、互不覆盖，混在一起读就会判断失准。这篇不教配置，只拆四个最容易踩错边界的点。想先横向看一遍同类插件的标注口径，可以到 完整插件清单与汉化避坑指南。

先分清它身上并存的三个状态

能装、被静态扫描标成高危、本站真实装成功——这是三条独立结论。安装兼容性检查是程序自动比对 npm 包、engines 声明与入口文件得出的，明确写着未做人工实机验证；安全扫描是另一套自动静态分析，与人工评估相互独立；实装验证则是真在 dsh 环境里装了一次。任何一条都推不出另外两条。下面四个坑，都来自把其中一条当成了另一条。

坑一：安全扫描的「高危」不是「恶意」，但也不能读成「没事」

现象。 安全区一片红：「静态扫描发现安装期即执行代码，或命令参数由运行时变量拼接（参数来源无法静态判定，从严处理）」，并列出「命令参数由运行时变量拼接」「读写/删除本地文件」「发起外部网络请求」三类标签，共 143 处证据，只展示前 85 条，且标注尚无人工评估。

原因。 这是静态源码扫描的产物，标的是「能力」而不是「意图」。一个要读写 .memsearch/ 下的 Markdown、要调用 memsearch CLI、要向嵌入服务发请求的插件，本来就会命中这些类别。对「命令参数由运行时变量拼接」这一项，扫描器采取从严处理——不是判定它一定有问题，而是参数来源无法在静态层面判定，于是按最坏情况计。反过来也一样：没有人工评估，意味着这份清单既不能当罪证，也不能当背书。

解决。 自己复核，去看证据里的具体调用点。条目都带文件与行号，比如 plugins/dsh/index.js 里用 bash 包装 command -v 的那处 execFileSync，plugins/opencode/index.ts 里把命令字符串拼出来再 execSync 的写法，以及集中在 plugins/dsh/client.js 的若干 fetch。逐条看参数从哪来——配置项、用户输入，还是固定字符串。也要知道它的真实短板：它确实会执行外部命令、确实会删本地文件，测试文件里就有多处递归 rmSync，这不是误报。

坑二：没声明 engines.node 和 dsh 版本约束，低版本环境不会明确报错

现象。 安装兼容性检查里两项写着「未声明 engines.node」「未声明 dsh 版本约束」，npm 包一栏是未发布到 npm、仅可源码安装，入口文件一项是缺少入口声明。你换一台 Node 版本偏低的机器，装完不一定跳错，更常见的是行为反常，或者干脆没有任何反应。

原因。 包没把运行前提写进 package.json，包管理器就无从校验，安装阶段也不会拦你。dsh 与插件自己都还在 developer-preview 阶段，加载方式与接口都在动，版本对不上时往往表现为静默失败而非显式报错——这类问题最难查，因为日志里没有可疑行。

解决。 装前自查两件事：本机 Node 版本、本机 dsh 版本，和详情页的检查结论对一遍；缺版本约束时这条只能靠人工比。详情页本身也提示，dsh 与插件都处于 developer-preview 阶段，装任何插件前建议先备份 ~/.dsh 配置，出问题好回滚。花这一分钟，比事后猜要值。

坑三：记忆文件位置随平台变，找错目录会以为「根本没生效」

现象。 装了插件、正常聊了几轮，回项目目录执行 ls .memsearch/memory/，空的。第一反应是插件没工作，于是开始重装、翻配置。

原因。 工作区下的 .memsearch/memory/ 是 Claude Code、Codex、DSH、OpenCode 的默认落点；OpenClaw 不一样，它把记忆放在自己的 agent 工作区里——主 agent 在 ~/.openclaw/workspace/.memsearch/memory/，其它 agent（比如名为 work 的那个）在 ~/.openclaw/workspace-work/.memsearch/memory/。同一份记忆层，各平台的目录约定并不统一。

解决。 按平台先确认路径再下结论：非 OpenClaw 的平台查项目工作区下的 .memsearch/memory/，OpenClaw 按 agent 名去对应 workspace 目录里找，验证方式都是看有没有按天生成的 .md 文件。另外记住 OpenClaw 有两个显式开关——会话访问与提示注入，不开会真的不工作，改完还要重启网关；这两步和目录位置是两码事，别混在一起排查。

坑四：配置优先级链搞错，改了就是不生效

现象。 改了 .memsearch.toml 里的集合名（或别的项），重启后行为纹丝不动，config get 回读也没按你写的走。

原因。 集合判定不是只看你手上那个文件，而是一条优先级链：集成派生的默认值 → ~/.memsearch/config.toml → .memsearch.toml → 显式的 –collection 或 Python 参数；链上没有集成派生的默认值时，才回落到内置集合。~/.memsearch/config.toml 在你家里目录，平时不会想到去看，但它排在项目文件前面；改在链条偏后位置，被前面一层盖住，表现就是「改了不生效」。

解决。 从链条前段往后逐层查，确认哪一层真正决定了当前值，再改在生效的那层；改完回读一次再重启，别凭印象认定已经生效。用 Python API 传参时也要注意它在这一链里属于靠后一环，不能想当然地以为优先级最高。

总结

几个状态标签并存时，先分清「自动扫描说了什么」「本站验证做了什么」再决定装不装，比盯着红字焦虑有用；类似的标注口径差异，在 完整插件清单与汉化避坑指南 里还能看到更多样本可对照。

适合与不适合

适合：愿意逐条读扫描证据、自己评估能力清单的人；同时在跑多个 AI 代理、确实需要跨平台记忆复用的人；Node 与 dsh 版本较新、且习惯装前备份 ~/.dsh 的用户。

不适合：把「高危」当成木马、或反过来当成「官方审计通过」的人——两种读法都不对；所在环境 Node 与 dsh 版本偏低、又不想逐项自查的人——它没声明 engines，低版本只会静默失败；完全离线又不换嵌入提供方的环境——默认 ONNX 模型首次要联网下载约 558MB，且这套复杂度只服务于跨平台共享记忆这一件事。

标签：memsearch、DeepSeek Harness、安全扫描解读、配置优先级、跨代理记忆

本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。