一次授权测试结束，真正需要交付的东西通常有三样：目标是什么、试过哪些路径、哪条路径真的走通了。这三样如果只存在于对话流里，下一个接手的人要往上翻几百条消息，还得自己脑补因果关系。dsh-pentest 想解决的就是这件事：它把渗透过程拆成结构化的六张表，再用四个视图分别回答不同的问题。插件本体是 @howmp/dsh-pentest，MIT，站点快照 607 星、综合分 69.0，当前 npm 版本 0.1.0-rc.37。
对话流缺的是什么
聊天记录是线性的，而测试过程是分叉的。一个 goal 下面会挂若干 intent（想验证什么），每个 intent 可能产出一条 fact（观察到什么），fact 又可能推导出新的 intent；只有走通的那条才变成 finding（漏洞）。这些关系在自然语言里靠「然后」「因此」粘连，机器读不懂，人也难核对。
插件把这些关系直接建成边：spawns 从 goal 指向 intent，yields 从 intent 指向 fact，derived_from 从 fact 指回 intent，proves 从 intent 指向 finding；资产之间另用 parent 表示父子。关系一旦成为数据，读者就不必再从语气里猜。
六张表与确定性 id
storage domain 叫 pentest，version 2，六张表分别是 goals / intents / facts / findings / assets / edges。节点与边的 id 形如 <kind>-<n>，按会话计数。
这一点值得多说一句。id 是确定性的，不是随机 uuid，所以同一条记录在工具返回、存储层、会话投影里是同一个名字，模型可以跨调用直接引用「intent-7」。而 pentest_add_goal 会重置整张图并把计数归零，所以 id 只在一次 engagement 内有意义——这也解释了为什么它不适合跨会话续跑。
记录落在 $DSH_HOME/storages/pentest-sessions.db，sqlite 后端；宿主其它域仍然是默认的 json 后端，两者互不影响。备份时如果只备了会话库，渗透记录其实是另一份文件。
写入路径也不是自由拼装：goal 先立，intent 必须恰好挂一个锚点，finding 的 reproducibleSteps 至少一条，asset 传空字符串表示根资产。这些约束在工具层就挡住了残缺记录，图里不会出现没有出处的漏洞。
四个视图各回答一个问题
Web 页签下有四个子标签，它们不是同一份数据的四种皮肤，而是四个不同的提问方式。
探索链路是 @xyflow/react 画的图，边上带关系胶囊（意图链 / 产出 / 推导自 / 证实），回答「我是怎么走到这里的」。漏洞视图按严重度列 finding，每条带描述、可复现步骤和影响资产，回答「到底破了什么、怎么复现」。资产视图有列表和图两种模式，回答「哪些东西在范围内、父子关系如何」。报告视图把全部内容渲染成 Markdown，可复制可保存，回答「怎么交给别人」。
图布局是静态分层的：可以平移缩放，节点不能拖拽。这属于设计取向而非未完成——位置由层级决定，同一次会话每次打开看到的结构都一致，读者不会因为上次随手拖过就找不到节点。
页签本身按会话注册，不是全局开关：当前会话或列表祖先链命中 pentest 预设名、pentest-* 复制预设名，或者该会话带 pentestMounted 标记才显示，其余会话隐藏。
Web 图是窗口，不是全量
会话投影的节点与资产各保留最新 200 条。窗口按新到旧逐出，被保留记录仍然指向的锚点（intent、父资产）优先留下，边跟随端点清理，所以留下来的链路始终连得上。
但窗口就是窗口。truncated 里的 dropped 是逐出的记录数，refused 是因锚点已不在窗口而被拒的写入数，两者都是累计值。长会话里觉得图少了东西，先看这两个数，再去 pentest_state 或 pentest_report 读存储层——那两个工具读的是全量。
子 agent 的记录为什么不在父图里
这是一个容易误判成缺陷的边界。插件不向会话日志追加任何事件：会话日志的词汇表归宿主所有，自造的 tool/call 会让 0.2 读取端判定整条生命周期非法，后果是整个会话永久打不开（issue #32）。所以 pentest_submit 只写存储域。
结果是：子 agent 提交的 fact / asset / finding 进了库，但不进父会话的 Web 图。要看得用 pentest_state、pentest_graph、pentest_report。父图折叠的只是决策 agent 自己记录的 pentest_add_* 调用。
装之前要知道的三件事
仓库已于 2026-10-09 归档，不再受理 issue、不发新版本、不适配新版 DSH；已发布的 npm 包仍可安装，也可以 fork 自维护。安全扫描为 🔵「含敏感能力」，证据项包含读写与删除本地文件，尚无人工评估，站点也未做风险分级——这三句话不该被略过。
版本口径上，站点安装检查写「未声明 dsh 版本约束」，但 README 明确要求 DSH >= 0.1.6、Node >= 22.5，以 README 为准。另外 authorization 参数只是审计留痕，会写进状态与最终报告，它不是门禁；扫描与利用动作仍然受部署沙箱与审批约束，能测什么只取决于你有没有拿到明确授权。
总结
它的价值不在替你完成攻击，而在把授权范围内的推理过程变成可查询、可交付的结构；同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：需要向客户交付可复现报告的授权测试项目；多人接力、要求记录能被下一个人读懂的团队；想把探索路径与漏洞证据分开管理的场景；已经用 DSH 且版本在 0.1.6 以上的环境。
不适合：没有书面授权、想拿它扫公网的人；宿主停在 0.1.6 之前又不愿钉 0.1.0-rc.32 的环境；Node 低于 22.5 的机器；需要长期维护承诺的生产团队——仓库已归档。
标签：dsh-pentest、DeepSeek Harness、授权测试、会话记录
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。