dsh-manager 插件深度分析
§1摘要与结论
别名：三硬依据 E1/E2/E3、第三方插件依赖分析、宿主消费点对齐 | 英文：dsh-manager Plugin Deep Analysis | 类型：案例 / analysis
§2局部关系图
§3原理 · 为什么
该案例把知识图谱的依赖证据模型迁移到第三方插件分析。命题是：一个包「依赖什么」不能只看清单，而须由三层证据交叉确认——编译依赖来自清单声明，运行时依赖来自上下文服务注入与调用，组合依赖来自装配文件中的挂载位置；三者结合才能区分「声明了但没用」「没声明却在用」「在哪被装配」三种情况。在此之上做需求溯源，把每项功能映射到它解决的痛点，再把设计问题分为高、中、低并按证据列出。方法要求所有结论附源码行号，使判断可被复核而非停留在印象；同时要求把第三方插件消费的宿主能力对齐到知识库中真实存在的节点标识，而不是泛化的包名，从而让新分析与既有图谱无缝互查。三硬依据的价值在于把「依赖」从单一来源的断言变成可交叉验证的证据链：声明、注入、装配分别对应发布、运行与部署三个视角，任一口径单独使用都可能误导。因此证据链须逐条落到源码行号，使不同视角之间的冲突能被准确定位而非被平均掉。
§4机制 · 如何运作
执行先克隆源码并记录提交哈希，主 Agent 只读装配文件与提取上游节点，把大体量代码拆给并行的探索子 Agent：服务端半区负责服务注入证据、远程调用面、功能机制与安全观察，浏览器半区负责插槽注入清单、字典、面板结构与设计问题观察。两路均以行号固证，主 Agent 裁决后组装结构化数据（若干核心节点、宿主依赖桩节点、边、功能、需求与设计问题），再生成单页交互图。两路并行不仅提高吞吐，也让证据来自不同视角：服务端半区聚焦运行时注入与远程调用面，浏览器半区聚焦插槽注入与界面结构，二者在「同一插件如何横跨两个半边」上互补；主 Agent 的裁决职责是把两半区口径统一，并对设计问题按高危、中危、低危排序，避免以风格偏好冒充缺陷。分析结论包括：该插件是传输面注册型宿主扩展，双半边架构经同源接口闭合，四大功能与六类痛点一一对应，九项设计问题含鉴权弱与脚本补丁自认非硬边界等。
§5工程 · 怎么落地
工程要点有三：其一，宿主依赖桩必须带组别与拓扑层标注，并尽量对齐知识库真实节点标识，使第三方分析可回查宿主结构；其二，可视化用单页交互图，本地内置依赖、点击弹详情卡，门控覆盖编码无替换字符、标签闭合、内嵌数据合法、本地依赖路径存在、无外部内容分发网络、画布实际着色与交互可用；其三，渲染验证不迷信视觉模型：对深底小字，视觉转写多次互相矛盾，应改用像素计数确认非空白加实例接口逐节点取真值，视觉模型只用于布局与乱码级粗检。方法论按需裁剪：版本级联工作流只复用其源码获取规范与三依据判定，差异分析部分不适用。对齐宿主节点标识有两个好处：桩节点带有组别与拓扑层后读者能直接理解其在宿主中的位置，且分析结果可与既有图谱数据互查，形成「主图加增量分析」的组合，而不必重建平行体系。
§6权衡卡
设计问题裁决触及第三方上游，价值高但需谨慎：应以证据与影响排序，避免把风格偏好当缺陷。
以三层证据加行号固证提高了结论可信度，代价是分析成本高、需要读装配与源码并维持证据链条，轻量巡检并不划算。
渲染验证的方法教训是取舍的典型——视觉模型适合粗检而不适合精确标签核验，过度信任会把幻觉当成结论，改用确定性接口取真值虽更可靠却要求被测系统暴露可查询状态；此外以行号固证会使报告偏长，用于速览时需另行抽取结论层。
- 把宿主能力对齐到既有图谱节点增强了互查性，却引入对上游图谱版本的依赖：图谱演进后桩节点映射可能失效，需回归维护，因此第三方分析应与图谱版本绑定并标注基线。
- 并行拆分服务端与浏览器半区提高了吞吐，但两半区口径需主 Agent 统一裁决，否则会出现同一功能描述不一致。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7案例带
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
网申 v3 多模块解耦
一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。
preset 通道耦合分析
对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
harness 源码架构解析
对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。
dsh 插件依赖增量定位
以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。
MCP 四件套选型对比
对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。
Claude Code 架构逆向
以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。
控制理论⊗Agent 设计
将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§8信源与核验
核验结论：依赖须由编译声明、运行时服务注入与组合装配三层证据交叉确认；本案例发现该插件声明只注入插槽服务却实际消费多项服务，仅看声明会误判 [LOC-027]
§9原始关系清单
展开：本节点的全部原始关系边（3 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 案例印证 | → ESS-G-02 | 依赖倒置与依赖规则 E-960 | 违背：依赖声明不实（声明一项却消费多项）削弱依赖倒置 |
| 案例印证 | → ESS-G-03 | 边界与接口隔离 E-959 | 印证：双半边架构以同源接口维持清晰边界 |
| 案例印证 | → MTH-O-06 | 粒度与边界设定 E-961 | 张力：双单体大文件反映边界粒度过粗，难独立变更 |